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 want to make a multiple client and server network using TCP/IP.

I have 30 remote sensors over Wi-Fi to send data to a server with LabView.  This is fixed.

The server have a router that communicates with the sensors and is connected to the PC by net cable.

I want to find the most efficient way of communication from the point of view of resources and, most importantly, the response speed of the system, because I want to update the screen as quickly as possible, sending more data per second from sensors.

I think I have (only?) two options:

* 1) Open 30 simultaneous ports and treat them in parallel to decode and display the data from each sensor.
* 2) Using two loops: one to listen new connections and the other to speak, placing them in "queue" and then decoding each one separately to display data from each sensor. See http://www.ni.com/white-paper/3982/en/

NOTE: For now I only have 4 sensors tested with method 1: It takes about 3 minutes to establish communication (why?), and then it works correctly.

Which method would you recommend? Why?

Thank you all in advance!

0 Kudos
Message 1 of 12
(9,842 Views)

I would use option three. I would have the server listen for new connections and whenever it receives a new connection it would dynamically call a VI which would then run as a task to service that one client. You could set a maximum number of clients the server would support if you wanted. This method would be very flexible and expandable. BTW, your server would only need to listen to a single port. All of your clients would use that one single port to connect to the server. Each client process could then post data to a queue that your UI is using to receive data updates. You could also use user events to pass the data to your UI. I generally prefer to use a cluster with a string and a variant to pass the data. The string is a message name and the data can be whatever is required for that particular message type. When you process the message it will know what type of data it should be for that message and can use the variant to data VI to access the data.

 

As for your 3 minute connect issue I suspect that your clients are trying to do some type of name lookup before connecting. I know the string to IP and IP to string VIs try to do a name lookup.



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
Message 2 of 12
(9,829 Views)

Ok Mark. Thanks.

 

Your solution is efficient, flexible and adaptable.

But from the viewpoint of efficiency in terms of speed of response, to open a single port and decode the source of each message is better than Method 1?

 

Thank you.

0 Kudos
Message 3 of 12
(9,822 Views)

I have used this method extensively and have not experienced any performance issues. The only different between N number of dedicated ports and a single server would be the time it takes to spawn the client processing task. Also, a single server would probably use less system resources since you only have one listening task. Not to mention you don't have to coordinate your port number for each client.

 

Here is one of our basic server tasks:

 

Wait for connection.PNG

 

And here is the code for the Spawn Handler subVI:

 

Spawn Listener.PNG

 

This code was developed several versions back. If I were to write it today I would use the "Start Asynchronous Call" method to spawn the client processing task.



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
Message 4 of 12
(9,819 Views)

Thank you Mark, very much.

 

It looks very interesting. I'll analyze the performance.

 

Only that I do not know the other subVIs displayed (could be my old version of LabView?)

 

Thank you!

0 Kudos
Message 5 of 12
(9,810 Views)
Solution
Accepted by ElectroniCHE

I assume you are referring to "Start Asynchronous Call". That was added in LV2011. If you are using an older version the method I posted above works just fine. In fact, we still use that VI (Spawn Connection Handler, which is one we wrote) in both LV 2011 and LV 2012.

 

I actually posted that library recently. You can find that code here. That code implements a network based queue. You can look at it as an example of a server that spawns handlers for each client that establishes a connection.



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
Message 6 of 12
(9,805 Views)

mark,

 

I have a similar question. I have one pc connected to multiple sensors (which act as servers). The sensors would each be routed through at switch. Each sensor communicate wirelessly to multiple devices. I want to send an http get request to each of these connected devices to pull data. I can currently only do it for one sensor. I am not sure how to connect to multiple sensors simultaneously.

0 Kudos
Message 7 of 12
(9,023 Views)

Hi Mark,

I did not find where to download "Wait for Connections.Vi"

I downloaded Network Queue Class, but icons are different from what I see here.

I need to spawn requests from many clients, and the idea of having Reentrant Vis that manage each connections seems what I'm looking for.

But I did not find the code a for the example you posted here.

Would you help me?

PincoG_0-1734516201294.png

 

0 Kudos
Message 8 of 12
(107 Views)

I understand now that all what I need is emebedded in the class data.

Where do I find some instructions in using this class?

 

For exemple, where do I put my reentrant vi to manage the connection?

0 Kudos
Message 9 of 12
(81 Views)

If you simply are adding multiple clients to to post to the queue simply but a create client queue in each spot you will be need to post data. As with any queue you should only have one process which is dequeuing elements. It would be very rare to ever have multiple processes dequeuing elements and would require additional logic so things are processed correctly. Can you describe in a bit more detail about what you are trying to accomplish.

 

This implementation is simply a drop in replacement for a native LabVIEW queue.



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 10 of 12
(51 Views)