TCP Session Data Loss

[JRobinson]

Hi,

We are using the FMD88-10 in about 80 sites to report sensor data up to a central server. Communications is via the ethernet port and, mostly, a 3G modem/router. I use TCPConnect to establish a session to the central listener and a PRINT$ to transfer a data string then close the session. This every 2 minutes. It is generally successful.

I recently attempted to add a second data message into the session. This consistently fails at a number of sites. It seems those that fail are the sites where the ACK for the first data message takes longer than about 500mSec.

If I start Trilogy and On-Line monitoring to the site, the problem drops to only a small number of transmissions though.

I have included a .jpg of a trace from Wireshark, obtained with a SharkTap connected to the Ethernet port of an FMD-10 where I have the problem.

It appears to me that the second PSH is sent (line 5) with the sequence of the first if the first has not received the ACK (arrives in line 6).

I really need a workaround or suggestion as to how I can avoid this problem. I have tried a number of mechanisms but with no success.

I can provide Wireshark traces of a number of the failed messages if that would be of use.

Thanks

[support]

Please send your wireshark recording to support@triplc.com. Also please include a copy of the invoice of your purchase of FMD PLC as well as the PLC's firmware version (go to Controller and select "Get PLC Hardware Info") so that we can diagnose your reported issues.

[support]

Thank you for sending the Wireshark recording. According to our analysis, the issue was caused by slow [ACK] sent by the server which occurred onlly after the client has sent the second data packet. As a result the second packet overwrote the regen buffer and was sent as a duplicate packet (using the same Seq and Ack # as the first packet)  The server therefore ignored the second data packet because it has already successfully received the first data packet and simply drop any duplicate transmission it received. The slow [ACK] sent by the server was therefore the trigger of the out-of-sequence packets.

We recommend the following possible solutions:

1) Program the server to send a data response such as "OK"+CRLF back to the client after the client have sent the data. This allows a handshake between the client and the server at the application layer since the TBASIC software can determine that the first packet has been received before sending the second data packet. This has other advantages, which is for the client to resend the first data packet in case it is actually lost in the cyberspace. In some situations, a continuous communication loss could signal something seriously wrong and the PLC could be programmed to reboot a network switch, a router or a modem or even to reboot itself in order to restore communication especially in a remote, unattended installation.

Or,

2) Concatenate the second data string with the first data string and sent out as a single packet. This would save some bandwidth too. You can embed the CRLF as terminator between the two data packets such as:

PRINT #4  A$; "\0D\0A"; B$

Where A$ and B$ are the data strings for the first set  and second set of data respectively. "\0D\0A" would append the CR+LF to the A$ and followed by B$ and will end with a second set of CR+LF.

However, the above two strings would be sent out in a single data packet which your server can then easily separate them into two data packets.

3) Schedule the second data string to be sent later than the longest [ACK] delay it could experience.  A delay of 10 to 20 seconds will ensure that the first data packet is either completely sent or aborted by the client and it can then send the second data packet.

[JRobinson]

Have been concatenating data messages to the 256 output buffer  with the PRINT #4 A$;B$;C$;D$ mechanism then introduced a timer to hold off until (hopefully) the ACK is received to that before the next one. This works well for our application.

In new applications of TCP CONNECT and data uploads I would  implement the recommended server acknowledge as the better solution.  Can't assume that the ethernet port is fully implementing the TCP sliding window.

Thank you for the extensive analysis and support. Much appreciated