How to check if the client session is connected or not?

[MyZQL]

Is there any method like handler.IsConnected() to check the connection state to avoid reconnect a connected session or for other purposes?

[alexjoedt]

Hey @MyZQL,
there is no IsConnected() method, and you don't need one. The client manages reconnection automatically: Send() reuses an existing connection if healthy and re-dials transparently if not. Exposing connection state would create a TOCTOU, race the socket can drop between your check and the next operation. If you need explicit lifecycle control (e.g. eager connect at startup), call handler.Connect(ctx) once - it's a noop if the connection is still open and subsequent Send() calls will reuse that connection.

[MyZQL]

@alexjoedt I have tried out that if the net cable was cut or the server was closed, and then the net cable was reconnected and the server was up again , the ModbusTCP client did not repair the connection and just simply return a *net.OpError.

[alexjoedt]

That’s exactly what we’ve just noticed, and we think this PR will fix it

[MyZQL]

@alexjoedt The handle.IsConnected() method is useful on the scene of multi-channel management and displaying. Maybe we can use an encapsulated flag var isConnected bool to update the connection status when the handler is connected or closed.

[alexjoedt]

Hey @MyZQL, fair point - thanks for bringing this up again.

Our concern with IsConnected() is that mb.conn != nil doesn't actually tell you whether the remote device is reachable. It only reflects the internal lifecycle of the cached socket. This leads to two misleading situations:

False positive: if the cable is cut, IsConnected() would still return true until the next Send() discovers the dead socket.

False negative: the idle timeout can close the cached socket even though the device is perfectly reachable, IsConnected() would return false, even though the next Send() would reconnect and succeed just fine.

So for a monitoring/display use case, the value could be wrong in both directions, which might actually make things harder to debug rather than easier.

Do you have any ideas on what a better API could look like for your use case?