Wierd networking.

[Julian Elischer]

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.