On Sat, 3 Sep 2011, Jarrod Lee Petz wrote:
3. Does FreeBSD handle this situation? How? I can't seem to find much info
on TIME_WAIT assassination in FreeBSD is mentioned in RFC 6056
I'm not familiar with the RFC side here, but I can confirm that FreeBSD will
recycle TIMEWAIT connections more quickly than specified when load is very
high. This is done on the basis of allocated space; the sysctl:
net.inet.tcp.maxtcptw
Instructs the stack regarding how much state to retain -- this is implemented
by adjusting the allocation limit on the tcptw zone. On my system, it seems
to auto-tune to about 5000 connections, a value derived from the global limit
on the number of sockets on the box I'm looking at -- your mileage may vary.
The resource limit case can occur in tcp_twstart(), when uma_zalloc() returns
NULL on failing to allocate new TIMEWAIT state for a connection. At that
point, it forces an early scan of TIMEWAIT connections (which normally happens
on 2msl intervals) with a 'reuse' argument of 1, authorising premature reuse.
Without too close an analysis, it appears on face value to implement LRU: we
reuse storage held by the connection that has been in TIMEWAIT the longest.
Robert
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
