TCP backend should handle out of order responses

[pdegoeje]

A libmodbus client can become stuck reading what it thinks are invalid responses (wrong transaction ID), while only one (the first) response is delayed beyond the timeout.

client: modbus_read_registers (tid = 1) -> ETIMEDOUT
client: modbus_read_registers (tid = 2)
server: send tid = 1 response
client: tid mismatch -> EBADDATA
client: modbus_read_registers (tid = 3)
server: send tid = 2 response
client: tid mismatch -> EBADDATA
client: modbus_read_registers (tid = 4)
server: send tid = 3 response
client: tid mismatch -> EBADDATA
etc.

The assumption that all responses are in order is incorrect, even if only a single thread is responsible for I/O.

A more robust way of handling this would be to discard responses where the TID doesn't match the request and wait for the correct response to arrive or for the timeout to occur, whichever happens first.

Ideally there would be an asynchronous API so multiple request/responses can be in-flight at any time, but that would be quite a bit of additional work.

[stephane]

Not triaged yet but it seems it could be interesting to add in a major release (3.4 or 4.0 material)

[marekm72]

As a workaround, I've just found it helps to call modbus_flush before starting each new request (modbus_set_slave, then read/write registers etc.) when talking to a few RTU slaves on a common RS485 bus behind TCP-to-RTU gateway (MikroTik KNOT). On RS485 there can only be one request at a time "in flight" anyway - so when starting a new request, we should forget the previous one (discard late error 11 response from the gateway after no response from the RS485 device behind it). Without the modbus_flush workaround, things work fine for some time until first RTU timeout (or CRC error), then it starts working erratically and "netstat -t" shows increasing Recv-Q on the TCP socket. On relatively error-free slow and properly terminated RS485 this can happen only after a long time - I've found the issue only after adding another device to the RS485 which increased load slightly and caused some signal reflections, enough to cause some rare CRC errors after a few minutes.