Rick,
Yes, you can open another connection while the old one is in TIME_WAIT.
You must allocate a new PCB to establish a new connection (you can't reuse the
existing one).
While your station is in TIME_WAIT, the other station might still be trying to
close the connection and may have missed your ACK, so it is in the LAST_ACK
state until it gets an ACK from you, or its own timer expires. If it has
received your ACK then it is already in the CLOSED state. You can't tell.
If you reopen a connection to the same station using the same port numbers at
both ends, there could be problems since it will look like the same connection.
This is avoided by using a different/random local port number when you open a
new connection. (I haven't looked into how lwip handles this.)
If you have spare PCBs then this will proceed as normal, and the old PCB will
remain in the TIME_WAIT state until its timer expires, at which point it is
closed and freed by tcp_slowtmr().
If you have no spare PCBs, then tcp_alloc() or tcp_new() will look for any PCBs
in the TIME_WAIT state and immediately close the oldest one, freeing it so it
can be reallocated. If this happens and the other station had missed your first
ACK, then when it retries the FIN it will get a RST response and this will
result in it closing the old connection anyway.
If you are getting a callback on transition to the CLOSED state and you are
overlapping a new connection with the TIME_WAIT state of the old one, then your
callback handler must pay attention to which PCB was closed, so you don't think
your new connection has closed.
----- Original Message -----
From: Rick Culver
Sent: Thursday, February 14, 2008 11:30 AM
David,
Thanks for the prompt reply, this was helpful. My slow timer is working just
fine and I discovered that if I wait for 2 minutes the state does eventually
change to CLOSED. Is it valid to conclude that when the state goes to
TIME_WAIT that the connection is properly closed at that point and can be
openned again? Or do I have to wait for the timeout to complete before
attempting to start a new connection? What do you think?
Rick
----- Original Message -----
From: David Empson
Sent: Wednesday, February 13, 2008 4:00 PM
Rick Culver wrote:
I am using CALLBACK API and a single TCP connection. If I close the
connection from the remote end everything is fine the state eventually goes
back to CLOSED. However, if I try to close the connection from my end with
tcp_close() the state goes from 4 to 5 to 6 to 10 and never goes to the CLOSED
(0) state. Am I missing a step in closing the connection or what seems to be
the problem. I appreciate any help you can provide.
Using symbolic names, that's ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, then
TIME_WAIT.
This means you have sent FIN, received ACK, received FIN and sent ACK, so
the connection is fully closed. The TIME_WAIT state is there to deal with
ACKing retries of the received FIN if your first ACK reply was lost. It
transitions automatically to CLOSED after a timeout.
If the connection is closed by the other end first, a different series of
states are used: CLOSE_WAIT, LAST_ACK, then CLOSED. The events are receive FIN,
send ACK, close() called locally, send FIN, receive ACK. The TIME_WAIT state is
not used, but the LAST_ACK state also has a timeout (if the ACK never arrives).
From a quick glance at the source code in lwip 1.2.0, the timeout in the
TIME_WAIT and LAST_ACK states is handled by tcp_slowtmr(), based on the
expression 2 * TCP_MSL (two minutes) divided by TCP_SLOW_INTERVAL.
If your timer implementation has a problem, e.g. tcp_slowtmr() isn't being
called at all, or isn't being called at the rate specified in
TCP_SLOW_INTERVAL, then this would explain a timeout never occurring, or taking
much longer than expected._______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
