public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Hangs in all FreeBSD ATHTTP, HTTP apps, system monitor, TCP apps  on TIME_WAIT
@ 2007-06-11 21:56 Tad
  2007-06-11 22:42 ` Andrew Lunn
  0 siblings, 1 reply; 2+ messages in thread
From: Tad @ 2007-06-11 21:56 UTC (permalink / raw)
  To: ecos-discuss

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [ECOS] Hangs in all FreeBSD ATHTTP, HTTP apps, system monitor, TCP apps  on TIME_WAIT
  2007-06-11 21:56 [ECOS] Hangs in all FreeBSD ATHTTP, HTTP apps, system monitor, TCP apps on TIME_WAIT Tad
@ 2007-06-11 22:42 ` Andrew Lunn
  0 siblings, 0 replies; 2+ messages in thread
From: Andrew Lunn @ 2007-06-11 22:42 UTC (permalink / raw)
  To: ecos; +Cc: ecos-discuss

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

Please send a patch for the documentation. We will review it in the
usual manor.

      Thanks
        Andrew

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-06-11 21:54 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-06-11 21:56 [ECOS] Hangs in all FreeBSD ATHTTP, HTTP apps, system monitor, TCP apps on TIME_WAIT Tad
2007-06-11 22:42 ` Andrew Lunn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).