From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24235 invoked by alias); 13 Dec 2007 09:53:15 -0000 Received: (qmail 24227 invoked by uid 22791); 13 Dec 2007 09:53:15 -0000 X-Spam-Check-By: sourceware.org Received: from an-out-0708.google.com (HELO an-out-0708.google.com) (209.85.132.244) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Dec 2007 09:53:09 +0000 Received: by an-out-0708.google.com with SMTP id c25so162757ana.15 for ; Thu, 13 Dec 2007 01:53:07 -0800 (PST) Received: by 10.100.171.10 with SMTP id t10mr3747861ane.58.1197539587184; Thu, 13 Dec 2007 01:53:07 -0800 (PST) Received: by 10.100.42.19 with HTTP; Thu, 13 Dec 2007 01:53:07 -0800 (PST) Message-ID: Date: Thu, 13 Dec 2007 14:33:00 -0000 From: "=?ISO-8859-1?Q?=D8yvind_Harboe?=" To: ecos-discuss@ecos.sourceware.org Cc: "Anthony Tonizzo" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Google-Sender-Auth: 11501cab9630f70c Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Idle timeout and maximum # of sockets for athttpd X-SW-Source: 2007-12/txt/msg00057.txt.bz2 > > 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.. I hate options :-) I guess if it was to be an option I would like to have a minimize # of sockets 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. 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. 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... --=20 =D8yvind 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