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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
