Re: close_wait on solaris

--MimeMultipartBoundary
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Henrik Nordstrom wrote:
> [handy info snipped]
> As I have said before, I think that using shutdown() in a client is a
> violation against HTTP. RFC 2068, section 8.1.4:
>=20
> When a client or server wishes to time-out it SHOULD issue a gracefu=
l
> close on the transport connection. Clients and servers SHOULD both
> constantly watch for the other side of the transport close, and
> respond to it as appropriate. If a client or server does not detect
> the other side's close promptly it could cause unnecessary resource
> drain on the network.
>=20
> This, combined with the fact that there is only one close operation in
> TCP (FIN =3D=3DI have no more data to send) indicates that shutdown() =
is
> not legal to use when more data is expected, except where it is
> important that previously send but un-acknowledged data is received
> properly (=3D=3Dby a server/proxy).
>=20
> The same section also says:
>=20
> Servers SHOULD NOT close a connection in the middle of transmitting
> a response, unless a network or client failure is suspected.
>=20
> The question is: Is a TCP FIN on a active connection a sign of client
> failure or not?

If you are expecting data from a client, then yes. If you are:
1) Waiting for the first request on a persistant conn, and read()=3D=3D0,
then close the conn.
2) If you are sending a response on a persistant conn, and read()=3D=3D0,
then do not continue writing until the response is finished or
write()<=3D0, then close.
3) Waiting for the request on an non-persistant conn, and read()=3D=3D0 t=
hen
close.
4) Waiting for the _body_ of a _request_ and read()=3D=3D0, then close.

Otherwise, from memory, a client can shutdown() the sending side of the
connection to indicate that it has no more data to send, which will
cause the conn to read EOF at the reciever.

> If client shutdown() is allowed while waiting for a response then there
> is no way to detect aborts on stalled connections until either a
> keep-alive check or timeout.

I believe it is (as above) and that you are correct. I think the HTTP
spec (as quoted) implicitly deprecates shutdown() from the client, but I
do not believe the condition will never be encountered. It's probably a
violation, but I think that a couple bits of documentation floating
around (like the TCP/IP FAQ [err..I _think_..something of that order]
actually recommends using shutdown() for just these sorts of cases.
Personally, it looked like trouble to me.

D

> ---
> Henrik Nordstr=F6m
> Sparetime Squid Hacker

--=20
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d- s++: a C++++$ UL++++B+++S+++C++H++U++V+++$ P+++$ L+++ E-
W+++(--)$ N++ w++$>--- t+ 5++ X+() R+ tv b++++ DI+++ e- h-@=20
------END GEEK CODE BLOCK------

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:47 MDT