HTTPD problems

[Altera_Forum]

Hello 

 I have problems with the eCos HTTPD package. When I make several refreshs in succession from a web browser the first requests are handled successfully but later the requests time out. After I have waited for some time I can make again some successful refreshs. The more sockets available the more successful requests can be made before the time-out issue occurs. But this should be no problem because the socket is always closed after the response has been sent. If there are 16 sockets available 1 sockets is used as the server socket and the remaining 15 can be used by client connections. After 15 http requests in short succession the next request times out. The select call which waits for a new client connection does not return for this request. If I wait for some time and issue another request it succeeds again. Any ideas what the problem might be?

[Altera_Forum]

After a lot of debugging I found that the problem was TCPTV_MSL from tcp_timer.h. This is the maximum segment lifetime and the default value is 30 seconds. When a socket is closed it is not immediately returned to the pool of available sockets, the socket is returned after 2 * TCPTV_MSL time (60s). So it is really easy to run out of sockets if you refresh the browser several times or navigate quickly. The default implementation of the ecos http daemon is not usable in my opinion. Other people encountered similar problems (http://groups.google.de/group/clinet.list.freebsd-bugs/browse_thread/thread/8501571128148cd2/6a2ea5304bdc9cd1?lnk=st&q=tcptv_msl&rnum=10&hl=en#6a2ea5304bdc9cd1). So I think in a resource-limited system the TCPTV_MSL value should be reduced, e.g 3 seconds. 

I wonder how other tcp/ip stacks handle this, especially those that target embedded systems.

[Altera_Forum]

thanks 

  <div class='quotetop'>QUOTE (orsino @ Mar 1 2007, 04:50 AM) <{post_snapback}> (index.php?act=findpost&pid=21941)</div>  --- Quote Start ---  After a lot of debugging I found that the problem was TCPTV_MSL from tcp_timer.h. This is the maximum segment lifetime and the default value is 30 seconds. When a socket is closed it is not immediately returned to the pool of available sockets, the socket is returned after 2 * TCPTV_MSL time (60s). So it is really easy to run out of sockets if you refresh the browser several times or navigate quickly. The default implementation of the ecos http daemon is not usable in my opinion. Other people encountered similar problems (http://groups.google.de/group/clinet.list.freebsd-bugs/browse_thread/thread/8501571128148cd2/6a2ea5304bdc9cd1?lnk=st&q=tcptv_msl&rnum=10&hl=en#6a2ea5304bdc9cd1). So I think in a resource-limited system the TCPTV_MSL value should be reduced, e.g 3 seconds. I wonder how other tcp/ip stacks handle this, especially those that target embedded systems.[/b]  --- Quote End ---