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