httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: [PATCH] Last lingering cleanup, setsockopt error messages
Date Mon, 07 Apr 1997 05:45:16 GMT
+1 based on a read but no testing.  See comments below.

On Sun, 6 Apr 1997, Roy T. Fielding wrote:

> + /*
> +  * More machine-dependent networking gooo... on some systems,
> +  * you've got to be *really* sure that all the packets are acknowledged
> +  * before closing the connection, since the client will not be able
> +  * to see the last response if their TCP buffer is flushed by a RST
> +  * packet from us, which is what the server's TCP stack will send
> +  * if it receives any request data after closing the connection.
> +  *
> +  * In an ideal world, this function would be accomplished by simply
> +  * setting the socket option SO_LINGER and handling it within the
> +  * server's TCP stack without blocking the server process on close().
> +  * Unfortunately, many OS vendors just haven't figured that out.
> +  * For those that have, see USE_SO_LINGER below.  For the others,
> +  * we have created a home-brew lingering_close.

I'm not sure that comment is valid.  In an ideal world there would be 
some way in the API, but all the definitions of SO_LINGER I have
seen _DO_ block the process while doing their stuff.  I'm not sure
SO_LINGER is worthwhile even on systems that do implement it "correctly".

eg. from freebsd:

     SO_LINGER controls the action taken when unsent messages are queued on
     socket and a close(2) is performed.  If the socket promises reliable de-
     livery of data and SO_LINGER is set, the system will block the process on
     the close(2) attempt until it is able to transmit the data or until it
     decides it is unable to deliver the information (a timeout period, termed
     the linger interval, is specified in the setsockopt() call when SO_LINGER
     is requested).  If SO_LINGER is disabled and a close(2) is issued, the
     system will process the close in a manner that allows the process to con-
     tinue as quickly as possible.

Also, are you _sure_ that the extra call to sock_disable_nagle
isn't necessary?  I can certainly imagine some OSes resetting it when
an accept() is done or only allowing it to be set after there is
a connection... 

View raw message