What does "limited sockets implementation" mean?

I am wondering what the phrase limited sockets implementation means. (This is in the PAC Control Reference Guide (1701) in the notes about the Accept Incoming Communication command). Is this the same as the “iterative server” model? And does this mean that a concurrent server model cannot be implemented (easily)?

The reason I am asking is that I have a similar (maybe he same) application as asked about in this question about multiple clients. The suggestions in that post indicated to me that PAC Control does not easily handle concurrent client connections from a single server socket channel.

We have a distributed control system where one controller is a coordinator – it is responsible for moving material around the system, the other controllers (up to 9) are subordinates, receive material and perform processing. Material handling requires sharing data.

We are considering using TCP/IP to share this, specifically Send Numeric Table and Receive Numeric Table. The idea is that the coordinator will accept connections (in a server socket) from the processing modules (who are the clients).

The protocol is simple – the client sends a table with its values. The coordinator copies the values to a table used by other charts in the strategy. The coordinator (server) replies with a numeric table containing status data.

The server logic for handling a single client would be to create the server socket, then enter an outer loop to wait for and accept communications. After Accepting the client connection, the server would go into an inner loop where it waits for a numeric table, copies the received table into one that the charts use, then copy its status table into one which gets sent to the client. In the event of an error, the buffer would be cleared, the channel closed, the the outer loop would restart.

I do not see how to do this with PAC_Control. I do see that once we get a connection, we can start a chart to process requests from the connected client. But to implement a concurrent model, when the second client connects, we would need to start that chart again in its own thread, which we cannot do if the chart is already processing requests from the first client.

I guess it depends on how long it will take to transfer the data from a client and how much buffer is available in the TCP stack for another client that is sending data. You could handle simultaneous clients though too, but it takes a bit more work, and in your case with the receive numeric table commands you would need to run in separate charts since these are blocking calls.

See my post in HTTP Interfacing and ports

How large are the tables you are sending and have you considered using the scratchpad?

Here is a test implementation of a TCP server that will accept up to four simultaneous clients. It listens on port 8910 and stores whatever is received in an string output table, indexed by connected client. I tested this with a telnet client.

TCPServer.Archive.D11112019.T150015.zip (7.1 KB)

“Limited sockets implementation”. I think it means to be able to realize the basic functions of TCP / IP communication. After all, the purpose of OPTO22 controller is different from that of PC. It’s just my own point of view. My TCP / IP communication application is relatively simple. R1 controller exchanges data with 5 pcs, and R1 controller serves as the server. I use and 5 charts, each chart uses a port and a PC communication, listening and exchanging data using the same port.

The tables are not big (128 bytes). I am not sure that scratch pads are a good fit for numerous reasons.

Data are not changed frequently, and when they are, several changes are made at the same time and are associated with each other.

Some of the controllers are legacy Opto Controllers (LCM4, etc.) that use the legacy version of Factory Floor, which does not have scratch pad commands (transmit / receive tables was the recommended mechanism for peer-to-peer communication).

That shouldn’t be an issue to implement. You would want the chart that processes the request to loop through all connected clients - so you need to store some state for each one. The strategy I attached gets the IP address of the client, but doesn’t do anything with it. You would probably want to use the IP to identify which client connected so you know where to store that clients data.

Your communication process chart needs to limit any blocking calls - since you are only transmitting 128 bytes which should all be in one packet, the send/receive table command should return right away (Check for data first by using the GetNumCharsWaiting command). Any processing you do on the data received should probably be handled in another chart - unless it is minimal.

Also, you will need a comm handle created for each client you expect to be connected. If you review the strategy I attached it demonstrates most of this.