[ECOS] Re: Idle timeout and maximum # of sockets for athttpd

[ECOS] Re: Idle timeout and maximum # of sockets for athttpd

[Anthony Tonizzo]

> I don't quite understand CYG_HTTPD_SOCKET_IDLE_TIMEOUT
> in detail, but it is hardwired to 300 seconds which appears to be
> rather long for the default maxim # sockets (16).

The time of 5 minutes before an inactive socket is closed was
chosen without much concern to the maximum number of
sockets. Its intentions were mainly to close sockets that have
been inactive for more than 5 minutes, regardless of the reason:
In other words I felt that with persistent connections (and very
few sockets available to begin with) it is important to reclaim
any and all resource you might think are not actively used.

The sockets might be dead, or the user of the client might just be
enjoying a sandwich before she comes back surfing: Either way
if the socket is idle for 5 minutes I want to be able to reclaim it for
connections that actually carry some traffic.

We can make a case for making this a CDL option..

> Could CYG_HTTPD_SOCKET_IDLE_TIMEOUT be set to 0?
> What would happen?

I can interpret this question two ways:

1) CYG_HTTPD_SOCKET_IDLE_TIMEOUT equal 0 means that
there is no timeout (i.e. remove the call to
cyg_httpd_close_unused_sockets(). In this case the sockets will
be opened forever. You are now at the mercy of the stack to
determine that a socket is dead. Might work, but I have not
experimented with it. Now, your delay is even more hardcoded
(this time inside the stack itself.)
2) CYG_HTTPD_SOCKET_IDLE_TIMEOUT is active and equal 0
in which case, with the current code you would effectively resort
to closing each connection after the request was served. In other
words, you void the advantages of persistent connections by
reverting to HTTP 1.0. If you think 16 sockets are not enough
with persistent connections you will hate the alternative, where a
single web page with a lot of pictures can exhaust the number of
sockets.

Tony

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

Re: [ECOS] Re: Idle timeout and maximum # of sockets for athttpd

[Tom Deconinck]

On Dec 13, 2007 4:14 PM, Øyvind Harboe <oyvind.harboe@zylin.com> wrote:
> [the awful truth deleted]
>
> Now I understand the awful truth. I wonder if there is anything that
> could be done
> to clue other athttpd users onto that they need to increase # of
> sockets to avoid
> the waiting problem....
>
>
> --
> Øyvind Harboe
> http://www.zylin.com - eCos ARM & FPGA  developer kit
>
> --
>
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>

Hi,

Just a thought: maybe you can disable the socket linger timeout (=the
time it waits to completely close a socket).
I've done it in the past on Linux, so I don't know if you can do it
with the eCos networking stack.
Or you can try resetting a socket when you know it's closed, it's a
violation of normal way of working, but if it does the trick...

Tom

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

[ECOS] Re: Idle timeout and maximum # of sockets for athttpd

[Øyvind Harboe]

[the awful truth deleted]

Now I understand the awful truth. I wonder if there is anything that
could be done
to clue other athttpd users onto that they need to increase # of
sockets to avoid
the waiting problem....


-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA  developer kit

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

[ECOS] Re: Idle timeout and maximum # of sockets for athttpd

[Anthony Tonizzo]

Oyvind:


> I hate options :-) I guess if it was to be an option I would like to
> have a minimize # of
> sockets option.

Not quite sure how you want to achieve that. By the patches you yourself
have submitted, you are by now pretty familiar with the way sockets are
handled and disposed. The only way to mnimize sockets is to use persistent
connection, and that is something that is already there by virtue of HTTP 1.1
support. It does make a huge difference because, as I said, a single request
was all it took to freeze older HTTP 1.0 versions of atHTTPD. At this point,
assuming that you do not use the CYG_HTTPD_MODE_CLOSE_CONN
flag too often, the number of sockets used is only dependent by how many
different clients connecto to the server.

> Is there a reason I would not want to minimize the # of sockets used?
> I guess athttpd would typically be used for some sort of logging/configuration
> server. Performance is not so much an issue at that point.

For a web server used only for configuration you are certainly capable of
dropping the number of sockets.

> The minimum # of sockets would then presumably be with
> CYG_HTTPD_SOCKET_IDLE_TIMEOUT  being somewhat near the length
> of processing a request. 5 seconds seems like a reasonable default at
> that point...

That would not work, unfortunately. When you close() a socket, that socket
is not returned to the pool right away. The stack (or, to use the
lastest Microsoft
buzzword, the "TCP Chimney", I am not kidding you!) holds on to it for a couple
of more minutes to make sure that stray data is not still in the wire (back when
the giants walked the earth, TCP connections could take that much to deliver the
goods...) This time, spent by the stack waiting, is on top of whatever time you
set for CYG_HTTPD_SOCKET_IDLE_TIMEOUT.

During this time you better have some spare sockets available, otherwise
the whole thing will freeze until a socket _is_ finally relesed. Your
request, which
has been pending since it was received, is now going to be served, but you are
not going to like the constant waiting.

Because of all this, I have always found that 16 sockets are not a bad number
at all. Once you have opened all your files, there is still enough
left for a few
HTTP connections.

Cheers!
Tony

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