Me too. The TCP encapsulation is a similar incarnation of networking
ignorance as the time-based framing constraints of Modbus/RTU (which
are violated by practically all PC hosts).
The real question, what do you do, if you do not get a response from
the Modbus/TCP connection within a reasonable time (maybe 100 ms) ?
* Send the request again using the old connection ?
* Make an orderly connection shutdown (which may fail if the other
node is down) and then make a new three way connect handshake and wait
it to complete, before sending the request again ?
TCP/IP might be attractive in some cases, if keep-alive messages are
sent say 10 times a second, instead of the default 2 hour cycle.
In practice, you have to monitor the transaction timeouts
(milliseconds) as well as monitoring the health of the TCP/IP
connection and restart it as needed with up to tens of seconds of
delay.
In a real time control system, if the data that does not arrive in
time,it is useless and in some cases harmful, if it can't be flagged
as obsolete. A TCP/IP implementation tries to buffer up to 64 KiB of
data and when e.g. a cable is reconnected, all those old messages are
sent at once, which could cause a lot of havoc.
A serial frame system, Ethernet level MAC frames and UDP/IP frames
work nearly the same way, it is just a question of different
transports. In all these cases, if you do not get a valid response
after a few retries, the other end is unreachable and there is no need
to break and remake any connections.