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.