buildup of Windows time_wait talking to fbsd 4.10

[Mike Silbersack]

On Tue, 11 Jan 2005, Lars Erik Gullerud wrote:

> You didn't mention what MTA you are using, so I don't know if this is a 
> similar (application-level) issue, or if it's FreeBSD 4.10 that causes some 
> additional delay before initiating a TCP CLOSE, but either way, this might be 
> the behaviour you are observing, in which case you will need to figure out 
> how to get the FreeBSD side to tear down the connection, or preferably you 
> should look at tuning some registry stuff on your Windows server - like 
> setting the MSL time (default 2 minutes) to a much lower value, and perhaps 
> upping the no. of max simultaneous connections.
>
> HTH,
>
> /leg

An additional change which might help is to increase the number of 
ephemeral ports Windows will use.  I think it uses 1024-5000 by default, 
you could up that to 1024-65535.

I haven't tried the instructions listed here (and I don't know if they 
work on non-Server versions of windows), but they look useful:

http://support.microsoft.com/default.aspx?scid=kb;en-us;812873

FWIW, when doing some benchmarking of apache vs thttpd a long while ago, I 
found results similar to Lars.  When I used one program for benchmarking, 
the TIME_WAIT sockets would build up on the client side.  When I used 
another program, the TIME_WAIT sockets built up on the server-side, and 
were subsequently recycled.

We may have changed something in FreeBSD which changes timing and causes 
the TIME_WAIT state to shift between 4.7 and 4.10, but as it's probably 
timing related, I don't know if it's really something that can be "fixed".

Anyway, it might still help if Len used tcpdump to capture a server-side 
TIME_WAIT from 4.7 and a client-side TIME_WAIT from 4.10 so that we can 
compare the difference.  A dump from the server side should be fine for 
both cases.

Mike "Silby" Silbersack