[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1285617653.2512.67.camel@edumazet-laptop>
Date: Mon, 27 Sep 2010 22:00:53 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Willy Tarreau <w@....eu>
Cc: Julian Anastasov <ja@....bg>, netdev@...r.kernel.org
Subject: Re: TCP: orphans broken by RFC 2525 #2.17
Le lundi 27 septembre 2010 à 21:24 +0200, Willy Tarreau a écrit :
> Hi Julian
>
> [removed Davem from the CC upon his request, not to pollute him]
>
> On Mon, Sep 27, 2010 at 12:12:24PM +0300, Julian Anastasov wrote:
> > If it is not already mentioned, the application can
> > know if sent data is acked. I think, ioctl SIOCOUTQ is for
> > this purpose. May be the application that wants to send
> > reliably HTTP error response before closing should do something
> > like:
> >
> > - add this FD in some list for monitoring instead of keeping
> > large connection state
> > - use shutdown SHUT_WR to add FIN after response
> > - use setsockopt SO_RCVBUF with some low value to close the
> > RX window, we do not want the body
> > - wait for POLLHUP (FIN), not for POLLIN because we want to
> > ignore data, not to read it. Still, data can be read and
> > dropped if needed to release the socket memory
> > - use timer to limit the time we wait our data to be acked
> > - use SIOCOUTQ to know if everything is received in peer and
> > then close the fd
>
> Thanks very much for this suggestion. I was looking for something
> like this and even looked at the tcp_info struct, but it did not
> look very easy to use.
>
> Still, I think that polling on POLLIN and checking with SIOCOUTQ
> on every read to see if the out queue is now empty would do the
> trick, without forcing to read huge amounts of unnecessary data.
>
> I'll simply enclose that inside a #ifdef LINUX and that should be
> OK. It kinda sucks to be able to workaround low level issues at the
> application level but at least this workaround is acceptable.
Just a point :
RFC1122 :
A host MAY implement a "half-duplex" TCP close sequence, so
that an application that has called CLOSE cannot continue to
read data from the connection. If such a host issues a
CLOSE call while received data is still pending in TCP, or
if new data is received after CLOSE is called, its TCP
SHOULD send a RST to show that data was lost.
Maybe only linux respects the RFC ? ;)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists