LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What is the best method to implement multiple client-server TCP/IP communication?

Solved!
Go to solution

I'm trying to achieve this:

I have got all the hardware that I need on a, let call it, Server machine.

From may pc connected by the network, they may be able to open the client when they need.

Any client should open, as I figured my solution, an Agent on the Server Machine, the client as an UI and the user with that request data. Tha agent answer the commands from the client.

There could be un undefined number of clients, and so an undefined number of Agents answering their requests.

I'm not sure the Queue could be my ideal solution, the first problem that I see is that the communication need to be bidirectional. Clients send command and wait for an answer.

I've done something similar, only with TCP, but only one-to-one.

I'm tryng to figure a central application that opens many Agent reentrant application, but I cannot figure how to keep the connections with any agent locally.

Maybe I could use one port from all to clients to the central server app, and than use as many port as needed with agents.

0 Kudos
Message 11 of 12
(122 Views)

In this case the network queue isn't exactly what you want/need. What you need to do is create a server application that listens on a known port/service name. This server will create a listener to receive connection requests from the clients. Whenever a client connects to the server the server will spawn a handler for that particular client. This client handler will process all of the communication between the client and the server. Your server will also need a separate process which does you actual server processing. I don't know specifically what your server is required to do but this process would need a means to communication with the individual clients handlers to pass data between them and service specific requests.

 

Your client application(s) would then connect using TCP to the server application. There is no need to manage the ports for the client since those will be dynamically assigned. A TCP by nature is bidirectional so you will be able to send and receive on that single connection. This connection is specific to a single client. As mentioned above your server process will need to maintain whatever data/state information you will be sharing with the clients. Your server process should also maintain a list of active client connections so that if you shutdown the server you can gracefully disconnect all of the currently connected clients.

 

For applications similar to this I use the Actor Framework to implement the server and client handlers. The Actor Framework automatically provides a means to pass messages between the server process and the individual client handlers.

 

You will need to implement some basic protocol which will be used between the server and clients. If it is a LabVIEW only implementation you can use a message class and flatten the class and send it over the connection. If application written in some other languages are going to be used then you will need some basic messaging scheme. One that is very common is to have messages comprised of a message type, could be string or number, a message length and message data. The format of the message data is specific to each message. Both the sender and receiver need to agree on the data format for each message type. A generic method for passing the data could be to use JSON format. This is a decent format since virtually every language has JSON parsers.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 12 of 12
(105 Views)