Date: Thu, 19 Jul 2007 09:33:28 -0700 From: Julian Elischer <julian@elischer.org> To: Eygene Ryabinkin <rea-fbsd@codelabs.ru> Cc: Julian Elischer <julian@ironport.com>, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Wierd networking. Message-ID: <469F9258.1070500@elischer.org> In-Reply-To: <469F91F8.1010406@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > Eygene Ryabinkin wrote: >> Julian, good day. >> >> Wed, Jul 18, 2007 at 12:12:15PM -0700, Julian Elischer wrote: >>>> Seems like it is the effect of the SS_NOFDREF check in the >>>> netinet/tcp_input.c, at least it is present in the rev. 1.281.2.5. >>>> >>>> See the post >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074837.html >>>> >>>> >>> That makes perfect sense.. >>> thankyou. >> >> You're welcome ;))) >> >>> I will check this avenue of inquiry. possibly we should do a shutdown() >>> and let the file descriptor exist for a few seconds. >> >> Yes, it is a way to do it. And we may even calculate the amount >> of time: as I understand, the time estimate is roughly equal to the >> (TCP window)/(connection bandwidth). The BW is not determined well, >> but we can try to extract this from the time interval between two >> successive packets that came from the remote side and the size of >> these packets. > > > In the code in question I found that there already existed code to do > this exactly, except it was only enabled under __LINUX__. > it has an event loop, and it continues to keep the file descriptor in > the read-interest set until it starts to return EOF, indicating that the > other end has also done the close. (or the socket has timed out of > FIN_WAIT_1). I have simply enabled it for FreeBSD OR linux ;-) 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 :-) > > >> >>> From the other hand, we may not want to have the per-connection >> estimate and set it to some small amount of MSLs. >> >> Another way to deal with the problem is not to send the FIN's after >> the one provoked by the closed descriptor. As I understand, the >> SS_NOFDREF check is a optimization to avoid processing unneeded >> data in the TCP stack. So we may just silently blackhole the >> successive packets, at least some of them. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?469F9258.1070500>