Date: Fri, 20 Jul 2007 10:55:18 -0700 From: Julian Elischer <julian@ironport.com> To: Eygene Ryabinkin <rea-fbsd@codelabs.ru> Cc: FreeBSD Net <freebsd-net@freebsd.org>, Julian Elischer <julian@elischer.org> Subject: Re: Wierd networking. Message-ID: <46A0F706.6020701@ironport.com> In-Reply-To: <20070720072227.GD4053@void.codelabs.ru> References: <469D4C9D.7090302@ironport.com> <469D4FB6.9040609@elischer.org> <3DBBD4E3-ABEA-451A-8E6A-02E9CBAD6A37@mac.com> <20070718055228.GA4053@void.codelabs.ru> <469E660F.8000109@ironport.com> <20070719084812.GS4053@void.codelabs.ru> <469F91F8.1010406@elischer.org> <469F9258.1070500@elischer.org> <20070720072227.GD4053@void.codelabs.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------050007080702000501050000 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Eygene Ryabinkin wrote: > Julian, good day. > > Thu, Jul 19, 2007 at 09:33:28AM -0700, Julian Elischer wrote: > >> replying to myself.. the comment in the code in question said: >> >> /*-----------------------------------------------------------------*/ >> >>> /** if the elaborateTCPFin option is set, keeps the socket open >>> * and drains it until the other side closes it. Solves a problem >>> * with IE spewing extra client data to a Linux socket, then reporting >>> * an error in response a TCP reset (rather than FIN) from Linux */ >>> >> which is EXACTLY the problem I was seeing :-) >> > > I assume that you're talking about Squid code? > no this is a proprietary cache program.. > Do you think that FreeBSD TCP/IP stack should also do something > about this problem? The situation where one side closes the > descriptor while other it still trying to push the data is legal: > for example, one side invokes close() but some data from other side > is in transit, so we will see some unneccessary FIN packets. Or > you believe that fixing this is irrelevant? > I think that the possible courses of action are: 1/ Ignore further incoming data, but ACK it. (this is basically what the userland code does in this case) 2/ Stop ACKing the data, and let the other end time out. 3/ Send a RST --------------050007080702000501050000--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46A0F706.6020701>