Date: Thu, 19 Jul 2007 09:31:52 -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: <469F91F8.1010406@elischer.org> In-Reply-To: <20070719084812.GS4053@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ;-) > >>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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?469F91F8.1010406>