lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] listening connection issue


From: JM
Subject: Re: [lwip-users] listening connection issue
Date: Tue, 16 Mar 2010 16:56:56 -0700 (PDT)

Thanks for the thorough reply.  I should have mentioned, however, that this is no ordinary webserver; it's very simple and specialized.  The app communicating through lwIP only understands two incoming requests, "GET /" and " GET /cgi-bin/smap".  When the former is seen, the webpage is constructed on the fly, and contains no images; just text entry spaces and a submit button.  When the latter is submitted by Firefox/IE, following the GET is all the text entered on the webpage, which is parsed by my app.  So my guess is one connection is opened.  I can't see how it could work with two, but this is good to know for future projects in which I may have something more complex.

--- On Tue, 3/16/10, David Empson <address@hidden> wrote:

From: David Empson <address@hidden>
Subject: Re: [lwip-users] listening connection issue
To: "Mailing list for lwIP users" <address@hidden>
Date: Tuesday, March 16, 2010, 6:03 PM

JM wrote:
 
> I fixed the tcp_close issue and it works fine, although the connection issue was a lack of  MEMP_NUM_TCP_PCB.  It seems that
> memp[1] in lwip_status is MEMP_NUM_TCP_PCB.
>
> The interesting thing is that when accepting incoming connections, it will use all the MEMP_NUM_TCP_PCB available, whether
> 4, 8, or 15, but not show any errors if it's roughly 4 or higher.  And, I'm only maintaining one connection at a time, as it's via a web
> browser.  Why is this?
 
If you have multiple elements on the page, the web browser may be opening several connections at the same time: one to get the HTML of the page itself, and one to fetch each image referenced on the page (or similar). If you have lots of images on the page, the web browser will want to open lots of connections, but it may have a built-in limit to only use 4 connections at a time.
 
The second part of the explanation is that after each connection is closed, the PCB may be remaining in one of the TIME_WAIT states for up to two minutes, to allow for cleanly discarding any late arriving repeated packets.
 
If a new SYN arrives, LWIP will allocate a PCB in the CLOSED state first. If there aren't any available, it will reallocate one that is in a TIME_WAIT state. If there aren't any of those either (i.e. there are MEMP_NUM_TCP_PCB open connections) it will count an error and ignore the SYN, relying on the client to retry later. (If you have enabled TCP_LISTEN_BACKLOG and there are already pcb->backlog active connections, subsequent SYNs will be ignored. This doesn't count an error.)
 
Assuming the browser's limit on simultaneous connections is 4, this leads to three scenarios:
 
(a) MEMP_NUM_TCP_PCB < 4
 
Some connection attempts by the browser will fail and SYNs will have to be retried. LWIP will count some errors due to failed connections.
 
(b) MEMP_NUM_TCP_PCB >= 4 but less than the number of images on the page
 
The browser will use up all of the CLOSED PCBs while fetching the page, and will then start reusing PCBs that have been closed but are still in a TIME_WAIT state. This won't be counted as an error. All the PCBs will be used up to fetch that page and will be in a TIME_WAIT state afterwards, where they will remain for two minutes.
 
(c) MEMP_NUM_TCP_PCB >= number of images on the page
 
The browser won't use all the PCBs to fetch the page, but all the ones it did use will be in a TIME_WAIT state for two minutes. If the browser accesses another page during this time delay (or another client connects) then some of the PCBs will need to be reassigned from the TIME_WAIT state once all the CLOSED ones have been used.
 
In either (b) or (c), you will only get errors reported if you have overlapped connections from several clients. Assuming all clients have a limit of 4 simultaneous connections, you would require MEMP_NUM_TCP_PCB >= 4 * number_of_simultaneous_clients to avoid counting any errors. If you have fewer PCBs and the same number of clients then some connections will fail, causing errors to be counted, and some clients will have to retry their SYNs, resulting in additional delays observed by the user while the page is loading (in addition to network delays and performance constraints in your server).
 
The key question is how common is this limit of 4 simultaneous connections? I can't see it as a configurable option in Firefox but haven't looked at the HTTP RFCs closely to see if it is part of the standard.
 
The use of HTTP 1.1 and persistent connections may allow the client to manage with fewer than 4 simultaneous connections to the server.
 

-----Inline Attachment Follows-----

_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users


reply via email to

[Prev in Thread] Current Thread [Next in Thread]