[ECOS] Hangs in all FreeBSD ATHTTP, HTTP apps, system monitor, TCP apps on TIME_WAIT

[Tad <ecos_removethispart at ds3switch dot com>]

Should the eCos documentation specifically mention in the app 
description that apps such as athttpd, httpd and any that use tcp 
connections will hang once max_sockets has been reached?

It seems that a lot of people get confused when this happens and then 
dig through the newsgroups and network stack for several days before 
figuring it out, when one simple line in the app description would fix 
this...esp before implementing a particular app then finding out it was 
the wrong one to choose!

FYI The suggested fixes to TIME_WAIT timeout don't actually seem to work 
since the value is hardcoded in several tcp_input places.  Also, the 
suggested fixes to "increase your socket count" aren't very helpful with 
many of our memory-limited systems...and that just delays the problem 
anyhow.

In particular (as I recall):

Embedded HTTP app uses a new connection for each GET request, so after 
max_sockets (16 default) - a few page loads, HTTP app will hang until 
TIME_WAIT (x2?) times out unused connections.

ATHTTP: is better/worse: GET's can be made to use a single connection 
(chunked/vs non-chunked transfers I think it was), but POSTs still may 
use a new connection for each, and more nefariously, another FreeBSD 
network stack bug causes accept() to hang forever when max_sockets is 
reached.  It's not really great when athttp hangs after a single user 
clicks 7 web buttons (7 + misc other sockets = 16)

It seems to this author that a way to dump sockets in TIME_WAIT would be 
VERY desirable.  Sure, that's not great the 1 time in a million that an 
old msg arrives in 2 minutes on that closed socket, but isn't it better 
than having one's apps hanging in front of the user the other 99% of the 
time (and have to allocate space for 64 sockets and subject to DOS if 
someone puts those 64 sockets into time-waits)  At a minimum, the huge 
socket space used by sockets in TIME_WAIT should be freed up if the only 
other solution is to implement 64+ sockets of memory.

Please document that athttp/http hang will be common on small 
socket-count implementations in the user reference for ecos. thx!

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss