LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

multiple sockets connected to one port

Hello I am running a LabVIEW VI that is based on the Labview TCPServer example. I am wondering what the best way to deal with multiple connections to a single port would be. For example I have a device(could be thought of as the same thing as the TCPClient vi) that connects to the server using the port number and the IP address. The communication works fine when there is only one device trying to connect to the server, the problem occurs when two devices try to connect to the server. When the first device connects all data sent shows up fine, when the second device connects, the status on the device indicates a proper connection but none of the data sent shows up on the server side. I assume that I must do something with the connection ID to distinguish between the two connections, but I was wondering if there was an example or something that deals with this issue, or if someone would like to explain how I could get the data to show up properly. Any help is appreciated, thanks!
0 Kudos
Message 1 of 9
(5,496 Views)

One idea is that you have the server listen on that 1 port.  If the server gets a request for a connection, then the server can open up another port that is unique for that one connection.  It sends the new port number back to the requester on the original port values.  The requester now can request a connection on that new port number and close off the connection on the original port number and free it up for future requesters.

 

Basically the single port number becomes a means for the clients to connect to the server and the server will dynamically create a new port number that the client can establish its real connection with.

0 Kudos
Message 2 of 9
(5,487 Views)

I am hoping that there is something similar to the java api where there is some way I can start a new threads to handle multiple connections on the same port. I would assume that if java has it LabVIEW would have something similar. Unfortunately I am not sure how to go about finding out how to do such a thing in LabVIEW.

 

The way that I assume the TCPListen.vi works is that there is some mechanism polling the specified port and ip address waiting for a request for a connection. Once a request is received the VI creates a connection ID so that the other subvi's can perform operations on the specific connection. It also looks as though the TCPListen.vi continues to listen for new connections, because the clients indicate a connection when more then one of them are run trying to connect to the same port and IP.

 

So my question is either, how to start a parallel process to handle the new connections, or where can I find the new connection ID (because the indicator only shows the connection id of the first client to connect). Basically I am having trouble distinguishing between the multiple connections on the same port.I would like to keep all of the clients sending data through the same port if possible.Each client identifies itself in its data message so keeping the data organized is not a problem. 

 

I also looked at the data socket examples, mainly because the Java examples I was looking at used "Sockets". I ran into similar troubles finding a way to create distinguishable connections using DS's as well. Anyways, any help is appreciated. Thanks.

 

 

 

0 Kudos
Message 3 of 9
(5,445 Views)

Each connection has it's own unique connection ID - so what you need to do is to create a connection handler for each connection. This can be done dynamically to allow for any number of connections. There is an example of such an architecture here:

 

http://zone.ni.com/devzone/cda/tut/p/id/3982

 

 

0 Kudos
Message 4 of 9
(5,440 Views)
Simply create a subtask for handling the connection. When you get a new connection dynamically spawn a new copy of the subtask to handle that connection. You could add some code in your server task to minimize the number of concurrent connections if you want or need to have a limit. In addition, if your subtasks need to communicate with a central task use a queue or notifier. Make sure you also provide a method for cleaning shutting everything down and terminating the connections if the server needs to shut down services. A notifier works well for this.


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 5 of 9
(5,425 Views)
Both those options sound good, and I am currently working on implementing the multi connection TCP Server system mentioned in that link, but I figured I would ask if there are any actual vi examples of multi-threading or using the multi TCP server? Thanks again for the help already I think this type of thing will work for what I am doing.
0 Kudos
Message 6 of 9
(5,407 Views)
I don't have a specific example but all you need to implement this is available in a couple of different examples. The server example will show how you accept a connection. The dynamic call examples will show you how to spawn individual tasks. If you combine these two principles you basically have the multi-connection server you are looking for.


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 7 of 9
(5,405 Views)

I have been trying to build a vi like the vi shown at the url that was posted above...

 

http://zone.ni.com/devzone/cda/tut/p/id/3982

 

I cannot find the queue vi's they look like the background might be white indicating that they are possibly some custom vi's if so is there a place to download the library. I have gone through the queue vi's that are available in the pallet but the ones that I found were a little different. Is the example available for download anywhere? Any help is appreciated thanks.

0 Kudos
Message 8 of 9
(5,233 Views)

Those examples were created with a much earlier version of LV.  Possibly 6.1 based on the write-up.  And a comment was added that was dated 2001.  The appearance of the queue functions have changed since then.

 

All the functions are there, they are just yellow now, and the other colors (blacks, purples) have been removed.

 

In the upper diagram, in order:  obtain queue, enqueue element.

In the lower diagram, in order:  obtain queue, queue status, deqeeue element

0 Kudos
Message 9 of 9
(5,219 Views)