AN003. Time Delays When the DS is Opening TCP Connection to the PC
What's in this Application Note
Some of our Customers have noticed that sometimes, when the DS is trying to establish a TCP connection to the PC, it takes pretty long time to connect. It looks as if PC is ignoring a connection request. This problem is often encountered when the DS is trying to "re-connect" after an abrupt reboot (i.e. due to power loss). This Application Note explains why this happens and what can be done to counter the problem.
Contents:
How connection delay happens
Using "connect immediately" mode to let the DS handle reconnects
Using modem commands and DTR line to monitor connection status and repair connections
How connection delay happens
Connection delay problem is related to how "TCP stack" on the PC handles existing TCP connections. We will explain this on the example of one frequent communications scenario:
| • | The DS establishes a TCP connection to the PC (for example, because it has some serial data to send). Connection is accepted immediately. PC identifies this connection by a combination of three parameters: remote host's IP (i.e. IP-address of the DS), remote host's port (i.e. port number on the DS from which this connection was established- 10001 by default), and local port on the PC to which this connection was established (i.e. "listening" port of your application or VSP). |
| • | The DS suddenly reboots, for instance due to power loss. Your PC doesn't know about this so it thinks that this TCP connection is still alive. |
| • | The DS is powered on again and makes an attempt to connect to the PC. Once again, it tries to open a connection from port 10001. PC responds with "ACK", as if this was a regular data packet. Basically, PC just ignores this connection attempt. Long time needs to pass before PC realizes that this connection is dead already. |
| • | The DS notices that the PC did not respond to the connection request and sends "RST" packet to reset the connection. At the same time, the DS discards the data it was going to send to the PC and goes to "IDLE" state. |
| • | When new serial data is received by the DS the latter makes another attempt to make a connection. This time the source port on the DS is 10002, not 10001. This is because source port from which the DS is establishing its TCP connection is incrementing with each connection attempt (this is normal, PC does this too). |
| • | PC gets this new connection attempt and treats it as a completely new connection. This is because in the unique combination of source IP + source port + destination port something is now different: the source port number has changed. Because of this, PC accepts this new connection immediately. |
The following network log made by WinDUMP sniffer software illustrates the above scenario. The DS is at 192.168.100.97 and the PC is at 192.168.100.90.
==========
*** DS makes an attempt to connect to the PC ***
192.168.100.97.10001 > 192.168.100.90.1002: S 640000:640000(0) win 1024 <mss 255> (DF)
192.168.100.90.1002 > 192.168.100.97.10001: S 10461646:10461646(0) ack 640001 win 8415 <mss 1460> (DF)
192.168.100.97.10001 > 192.168.100.90.1002: . ack 1 win 1024 (DF)
*** Connection is now established ***
*** DS reboots abruptly ***
*** DS makes an attempt to establish connection again ***
192.168.100.97.10001 > 192.168.100.90.1002: S 256000:256000(0) win 1024 <mss 255> (DF)
*** PC replies with ACK which is not correct, so DS resets this connection attempt, discards data ***
192.168.100.90.1002 > 192.168.100.97.10001: . ack 1 win 8415 (DF)
192.168.100.97.10001 > 192.168.100.90.1002: R 640001:640001(0) win 8415 (DF)
*** DS tried to connect again, this time from a different port, this time connection is accepted ***
192.168.100.97.10002 > 192.168.100.90.1002: S 640000:640000(0) win 1024 <mss 255> (DF)
192.168.100.90.1002 > 192.168.100.97.10002: S 10470652:10470652(0) ack 640001 win 8415 <mss 1460> (DF)
192.168.100.97.10002 > 192.168.100.90.1002: . ack 1 win 1024 (DF)
==========
Bottom line: the first connection attempt by the DS after an abrupt reboot can fail. If your serial device just sends several bytes of data and waits for TCP connection to be established then this may never happen. You serial device needs to resend the same data second time after a delay- only then TCP connection may be finally accepted by the PC.
There are two ways of speeding thins up and prevent the PC from delaying the connection.
Using "connect immediately" mode to let the DS handle reconnects
Program Connection Mode (CM) setting to 0 (connect immediately)- this way the DS will make infinite attempts to connect unstill succeeded. This way your serial device doesn't need to send data repeatedly to have connection established. Most of the time connection will be ready.
Using modem commands and DTR line to monitor connection status and "repair" connections
Modem commands (officially called serial-side parameters and instructions) give your serial device a way to monitor connection status and control connection establishment/termination. Instead of sending serial data and hoping it will pass through your serial device you can first make sure that connection is, indeed, established.
Here is a brief description of how this might work:
| • | Your serial device first makes the DS enter the serial programming mode. |
| • | Your serial device then uses Establish Connection (CE) instruction to make the DS start connection establishment procedure. |
| • | After this, your serial devices uses Echo (X) command to check the result (c flag in the reply). If connection is not found to be established rather quickly and c flag is unexpectedly returns to "*" then your serial device can conclude that the DS has returned to idle mode because the PC did not respond to the connection establishment request. |
| • | Then, the serial device can quickly issue another Establish Connection (CE) instruction and, again, monitor connection status via Echo (X) command. |
| • | After the Echo command shows that connection is established (c flag="C") the serial device uses Logout (O) command to make the DS exit the serial programming mode. Data exchange can start after that. |
The above procedure, although seemingly lengthy, takes only a fraction of a second to complete.
One remaining question is: how to detect that connection has been broken while being in the "normal mode". Indeed, when the DS in the serial programming mode connection status can be verified at any time through an Echo command . But how to do this when the DS is in the data mode and Echo command cannot be issued?
This is done by programming the DTR Mode (DM) setting to 1 (connection status). In this case the DTR line of the DS shows whether network connection is established or not. Once the line is "dropped" the serial device will know that something has happened to the connection. At this time the serial device should force the DS into the serial programming mode and use modem commands to "repair" the connection.