Hi,

I'm currently in stage of designing my Modbus/TCP client software library which will run on a Windows PC.

As you probably know the Modbus/TCP design allows servers to handle a multiple concurrent transactions:

a) The server use one dedicated TCP connection per each client. Clients issue a transaction and wait until the reply from the server comes back before issuing another one. So there is always only one transaction pending per TCP connection.

b) The server use one dedicated TCP connection per each client. Clients can pipeline multiple requests in a quick succession (while obeying a limit imposed by server) before they wait for the replies to arrive. So there can be more than one transaction pending per TCP connection.

Since my Modbus library needs to interface with almost every Modbus/TCP server device available on the hardware market and I don't have an access to many of these devices myself, I'd like to ask you the following questions:

1) What kind of design (a or b) is the most widely used in the real Modbus server devices available on the market?

2) Will it be worth supporting both kind of design in a Modbus software library?

3) Are there any other designs I forgot to mention here?

Please take a little time and share your opinion with me. I will much appreciate it!

Thanks in advance,
Ivo

 

Your option a) is really the same as option b) with a limit of 1 outstanding message on the connection. So make your client work as option b) but give the user a setting that they can use to limit the number of outstanding queries per connection. Something like 1 to 4 would cover most servers.

So somewhere in your configuration of the remote servers you will ask the user to enter these types of settings:

remote IP Address,
Query Reply Timeout,
Maximum number of outstanding queries

There are a number of Modbus/TCP servers out there that only support 1 outstanding query on a socket. A default setting of 1 would ensure that you can communicate with all possible servers but the user could bump up the setting to get better throughput if required.

Scott Henson
Niobrara R&D Corp.
[email protected]

 

Thanks Scott for your suggestion. I will make the MaxNumberOfPendingQueriesPerSocket user-adjustable and also introduce the ability for the client to establish multiple concurrent socket connections with a single remote server (if it's possible) in case the server does not support the request pipelining.

Just one more question regarding the Modbus server design. My component library will also contain a Modbus/TCP server component in order to allow creating both sides of a Modbus connection. I'll make it multi-threaded so that it will create a separate thread for each client connection. This should lead to increased throughput in communication between the remote clients and my server. But I still wonder how to realize the server support for client request pipelining. Imagine, for instance, the remote client will issue five request to my server in a quick succession. Should my server process the requests in a row (one by one) or should it make use of its multithreaded design and spawn a new thread for each pipelined request? I'm asking because I think that some commercial clients may require the requests to be processed and returned in the order they were pipelined, and some other client may not. Is this a relevant question?

Thanks in advance, again.
Ivo

 

Don't worry about the order of the replies for a pipeline. If a client is going to pipeline messages on a socket then it absolutely must keep track of the "Transaction Identifier" (the first 2 bytes of the Modbus/TCP message) to match up the replies to the queries. If they don't keep track of the transaction identifier then they are just asking for trouble.

For example, consider a two port Modbus/TCP to Modbus serial bridge with port 1 at 1200 baud and port 2 at 19200. Obviously, a message intended for port 1 will take longer to reply than the same message for port 2. The bridge must internally keep track of which message is intended for each Modbus/TCP reply but it should not hold up a reply just because it is out of sequence. The transaction identifier will tell the client which reply is which.

If the client can't handle this situation then pipelining should be disabled and two single-threaded sockets should be opened instead.

Scott Henson
Niobrara R&D Corp.
[email protected]

 

Sure this is a relevant question.

Default is certainly you'll need to reply stricting in the order received. Assuming your processing in active memory, comparing the times inherent in garden-variety "TCP/IP" and in a modern high-end CPU I'd doubt you'd gain very much performance by not processing them in order in a single thread. In other words, your X threads would create X responses in parallel that just need to be queued back into a serialized TCP/IP system anyway.

I think it's safe to assume any client who cares for that extra performance of parallel server processing would be using multiple/parallel MB/TCP sockets. I'd let that be my guide in when to process in series or in parallel. X packets in 1 socket get processed by 1 thread in strict series, while X packets in X sockets can get processed by X threads in parallel. That won't break any client out there.

best regards
- Lynn A Linse, www.digi.com