|
From: | David Empson |
Subject: | Re: [lwip-users] Slow release time of closed TCP PCBs |
Date: | Fri, 19 Jun 2009 14:46:50 +1200 |
"Kieran Mansley" <address@hidden> wrote:
On Thu, 2009-06-18 at 11:00 +0200, Lou Cypher wrote:Simon Goldsmith <address@hidden> wrote: > What you are seeing is that the PCBs are remaining in a wait-state for > some time. This is to prevent packets from the old (closed) connection > being possibly accept on a new connection. The port stays known to the > stack and it can send RST packets when new packets for that port are> received. However, while these PCBs are not yet freed, they are *not* > in> an active state any more, thus tcp_slowtmr is correct. Everything is clear, does make sense to me. How long can be "some time"? :)2 * TCP_MSL See tcp_slowtmr() where it handles the "TIME-WAIT" pcbs For the default TCP_MSL, that would be 2 minutes.
One thing I don't understand about this discussion: the tcp_alloc() function tries to allocate a new PCB, but if that fails, it tries killing a PCB in the TIME_WAIT state (picking the oldest one), then it retries the allocation.
This should mean that even if all PCBs are used, it will be possible to start a new connection as long as at least one recent connection has closed (and has got far enough through the FIN/ACK handshakes, but hasn't reached the 2 * TCP_MSL timeout).
This code is similar in LWIP 1.2.0, 1.3.0 and CVS-head, and it works fine for us using the raw API, but I haven't looked at implications for higher level APIs.
What piece of information am I missing, and why isn't it working for Lou?
[Prev in Thread] | Current Thread | [Next in Thread] |