httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: lingering_close
Date Sun, 02 Feb 1997 15:53:37 GMT
Marc Slemko wrote:
> On Sat, 1 Feb 1997, Jim Jagielski wrote:
> > If there server timesouts, it means that it either hasn't rec'd any
> > data in awhile, or else it has listened to the maximum persiticonns
> > that it wants. In the first case, there's no data to read. In the
> > 2nd it doesn't seem to make sense to me that the server must
> > contibue listening to requests just to ignore them... Maybe I'm
> > missing the point though, it certainly wouldn't be the 1st time :)
> You also have to remember the (normally) very short keepalive timeout.
> The server has to keep listening until it knows the client has all the
> data, ie. the FIN which signals a close to the client application.  That
> is what lingering_close() does. It is fine to say it shouldn't have to,
> but this is a very low level protocol issue and I have seen no other
> solution.

I don't see why the server needs to keep on listening if it decides
to close the connection. What about an inactivity timer? It hasn't
heard from the client in awhile and wishes to close the link.
The above states that the server needs to wait an indifinite
amount of time since there is a possibility that as soon as he
decides to close the link, the client could wake up and start
spewing data. Alternately, if we have a slow client, or
one with an extremely large number of persisticonns, or both,
then the server is at the mercy of the client and can do nothing
as far as closing the link until the client says that it's OK
(basically). Again, this seems to be much more than the server
is required to do. We cannot hope to handle all the cases esp
with buggy clients that may not correctly determine the socket
status before firing up requests.

As currently coded, lingering_close() violates the above "rule"
since it includes a timeout that might kick in before the
server finishes listening to all the data.

      Jim Jagielski            |       jaguNET Access Services           |
                  "Not the Craw... the CRAW!"

View raw message