Idiomatic way to invert server <-> client workflow

[mbait]

I have a hardware Modbus gateway that does RTU <-> TCP conversion. It can connect to a spefieid IP itself. What would be the best way to implement a TCP server that would:

1. Listen for incoming connections from a gateway.
2. For each accepted connection send a holding register read request back to the gateway.
3. Read and process the reply.
4. Goto 1.

I went through the source code and found the serial forwarder example that briefly resembles that I need, but still it requires a separate remote Modbus server to forward its requests to, whereas I'd like to stay within the same established TCP connection. I also came up with a hacky solution that instantiates a Modbus TCP client with an empty host, initiates a genenric TCP bind/accept loop, and for each accepted socket does modbus_client.socket = tcp_client_socket. So now I do have access to read_holding_registers() and etc. That kind of works, but is prone to errors as some built-in things like reconnection or request retries do not work.

So my question is - should I look deeper or is my idea not compatible with pymodbus architecture whatsoever?

[janiversen]

I do not think I understand what you want...A client needs a server to talk to and visaversa.

therefore if you en essence are building a forwarder (sounds like it) the client part needs somewhere to connect.

As I understand it:

• somewhere there is client that connect to your program
• your program is a server (in order to listen)
• your program wants to forward the request, so it contains a client
• where do the client part connect to, it cannot be the external client since it's not a server.

Our example serial forwarder seems to do what you mostly want (apart from the part I do not understand)

[mbait]

Let put it simpler - there's a client and I'm running a server. I want my server to poll the client's registers as soon as the client connected. The thing is the server class instance, ModbusTcpServer doesn't contain the client's methods such as read_input_registers(). From the raw TCP exchange point of view it doesn't matter whether the socket is a server socket or a client socket, so there should be a way to invert the "request -> response" Modbus logic. Or am I wrong?

[janiversen]

Then let me put it simple too.

A server cannot poll a client, that is against the protocol. The client is the initiator, issues requests to a server and the server responds.