Date: Fri, 20 Jul 2007 11:22:27 +0400 From: Eygene Ryabinkin <rea-fbsd@codelabs.ru> To: Julian Elischer <julian@elischer.org> Cc: Julian Elischer <julian@ironport.com>, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Wierd networking. Message-ID: <20070720072227.GD4053@void.codelabs.ru> In-Reply-To: <469F9258.1070500@elischer.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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? -- Eygene
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070720072227.GD4053>