std.socket - problems closing socket

[Regan Heath]

On Mon, 03 Oct 2011 12:57:56 +0100, simendsjo <simendsjo at gmail.com> wrote:

> On 03.10.2011 11:36, Regan Heath wrote:
>> For a "graceful" close you're supposed to ensure there is no data
>> pending.  To do that you:
>>
>> shutdown(SD_SEND);  // send only, not recv
>> <enter a loop reading all data remaining on the socket>
>> close();
>>
>> The loop should read until recv returns 0.  If recv returns -1 and the
>> socket is blocking it should error/exit.  If recv returns -1 and the
>> socket is non-blocking it should check for [WSA]EWOULDBLOCK (and
>> select/sleep + loop) or error/exit.
>>
>> The reason to do this is to flush all the data from the socket buffers
>> on the remote and local ends, otherwise a close can cause remote
>> buffered data to cause a "connection broken" error on the remote end,
>> and/or (I am guessing a little here) may cause the socket to close while
>> negotiating a graceful close, and/or remain in a TIME_WAIT state due to
>> buffered data or data "in flight".
>>
>> ... are you setting any close options/timeouts i.e. LINGER?
>
> Thanks.

:)

> recv returns -1 for many requests. The errors are only WSAECONNABORTED  
> and WSAECONNRESET as described here:  
> http://msdn.microsoft.com/en-us/library/ms740668.aspx

To help me understand (I know nothing about fastcgi or nginx) can you  
clarify...
1. Your D code is the client side, connecting to the web server and  
sending GET/POST style requests?
2. You get these ABORTED and RESET errors on the client side?
3. As #3 even after doing as I described, shutdown(SEND), recv, then close?

If yes to all the above, then it sounds like the web server/fastcgi is  
closing the socket without reading all the data you're sending, which  
probably means you're sending something it's not expecting.  I would start  
by verifying exactly what data you're sending, and that it's all expected  
by the remote end.

> I'm doing socket.shutdown(SocketShutdown.SEND) now after sending all my  
> data and reading until I receive 0 or -1. (doesn't really matter as  
> sending the FastCGI EndRequest makes the server shut it down as it  
> doesn't handle multiplexing)

So, the socket closure is initiated by fastcgi/the web server.  This  
supports the theory that it's not reading some of your data, because it's  
not expecting it, and this is likely the cause of the ABORT/RESET errors  
you're seeing.

> I have tried with linger too, but it doesn't help:
> socket.setOption(SocketOptionLevel.SOCKET, SocketOption.LINGER,  
> std.socket.linger(1, 30));

The default LINGER options should be fine, as-is.  But, double check the D  
socket code just in case it is setting different LINGER options by default  
(I haven't used it, or looked myself, sorry).

> Could this be caused by some bad settings on the webserver?

It is possible, but I would double check your requests first.  There may  
be a setting, or settings for aborting connections which take too long, or  
fail to send certain data, or connect from the wrong IP, or...  If your  
requests are otherwise working, then I suspect you're sending some 'extra'  
data which is not being read.

> PS: Seems my computer can handle about 16000 TIME_WAIT before it starts  
> "hanging".

You'll be running out of operating system handles or similar at that point  
:p

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/