Modbus TCP messages on TCP disconnection

Hello All,

I would like to know whether there is any reference in the Modbus standards regarding handling of Modbus TCP messages that are put in queue before TCP disconnection.(These messages has not been send out in the physical line)

Should it be retransmitted on successful re-connection or whether it should be discarded on time-out.
 
If you think of this in terms of separating your Modbus application from the TCP connection, I believe the answer should become clearer.

Focusing on the Modbus application layer, if your device is a client, it will send a request message to the TCP layer and start its timeout timer. If your client application does not receive a response within the timeout time, a timeout occurs and the message is discarded (and any messages received later with that transaction identifier would be discarded as not matching any outstanding request transaction identifiers).

If your device is a server, it will wait to receive a request message from the TCP layer. Once a request is received, the server applicaiton will process the request and send a response message to the TCP layer. After that, what happens to the message is outside of the scope of the server application.

The TCP layer is responsible for establishing the connection and transmitting and receiving the messages. Most implementations are done using an existing TCP/IP stack, so you typically don't have to worry about this layer. But if a message is enqueued, the TCP layer will try to transmit or retransmit the message according to standard TCP retransmission algorithms. Take a look at section 4.2 in the spec that rtuorme linked for more details.
 
I think there is no way to know what happened with the data offered to the TCP layer, but not sent out by the Ethernet layer. A close of the connection (socket close) can of course wait until the data is sent out (and ack'ed by the server) but this could, worst-case, take a very long time if the server is no longer responding. So I think all TCP/IP implementations will just discard the data. However if the data was already out of the TCP/IP layer and waiting in the Ethernet driver queue to be sent out, I guess it will still be sent out. The connection close also requires Ethernet traffic, and this will be neatly queued behind the data.

Note that when a TCP/IP connection is closed, it is only a half-way close (no data can be sent, but data can still be received). The server must also close its end of the connection before it fully disappears. Now I don't think that TCP/IP socket also mimic this behavior (although I have never tried to close a socket and then see whether data can still be received on it).

But, I won't bet on it. Even if it works on one OS, it may not work on another OS. I consider closed = closed. Make no assumptions on queued traffic in the Ethernet layer. Also you don't know how the server behaves if it sees that the client closes its parts of the connection, I consider it likely that it will also stop processing incoming traffic and send out any outgoing traffic.
 
Top