Connection closing in Modbus-TCP


Thread Starter

Satoshi Sakai

I'm a PLC vendor. I have a question about behavior of Modbus-TCP client (master) PLC. In our PLC, TCP connection is opened automatically before sending a query and closed immediately after receiving a reply from a server. End users are not able to control connection open/close. It is done automatically by PLC. So the same port is opened and closed many times in a short time in most practical cases.

I would like to know if this behavior is compliant with standard Modbus implementation. I'm afraid closing connection would be handled separately from query handling.

Lynn August Linse

It is not 'normal' behavior in the TCP/IP world, but some misguided engineers on early Modbus/TCP created hacked IP stacks so their TCP/IP acted more like UDP/IP. This was great for the first gen Momentum PLC, which had very limited socket count, as such thrashing of sockets with an open queue gave the illusion of having many more sockets, so a few dozen PLC could talk peer to peer with only 8 socket resources.

However, many TCP/Ip implementations put timing limits (delays) on reusing sockets, so this behavior means you may 'run out' of sockets. Other systems literally spawn a full new task/process for each socket open, which results in memory fragmentation & CPU loading problems. (The Modicon hack basically keep the task/sockets 'active' and just moving them through states, so they could be closed & reopened in a few CPU cycles. Modicon eventually admitted this caused compatibility issues & somewhere in mid 2000's (?) they stopped doing this, or added configurable behavior.)

So final answer. You should NOT do this if you are creating a client, but your server MUST handle as gracefully as possible since you cannot control if the client is doing the socket-thrash.

In some of my code, I penalize such clients, so when they close one socket & open another, I add a 1 second lag to 'throttle' the open & their lust for new sockets. Since they expect the 'open queue', they tend to handle the delay fine. Otherwise they might try to open/close 50 to 100 sockets a second, and allowing that in my system which spawns threads and allocates new buffers all the time, this risks CPU overload.