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>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46A0F706.6020701>