1 port multiple connections?

[electric550]

Is it possible to have multiple connections on the same port using labview. I was looking at the TCP Listen VI help and it states the following...

TCP Listen Details

When a listen on a given port begins, you cannot use another TCP Listen VI to listen on the same port. For example, if a VI has two TCP Listen VIs on its block diagram and you start a listen on port 2222 with the first TCP Listen VI, you cannot listen on port 2222 with the second TCP Listen VI.

if (typeof(writeVarRefs)=="function"){writeVarRefs("647");} if(typeof(lvrthelp647) != "undefined"){document.writeln(lvrthelp647)} if(typeof(lvfpga647) != "undefined"){document.writeln(lvfpga647)} if(typeof(lvemb647) != "undefined"){document.writeln(lvemb647)} if(typeof(lvpdahelp647) != "undefined"){document.writeln(lvpdahelp647)} if(typeof(lvtpchelp647) != "undefined"){document.writeln(lvtpchelp647)} if(typeof(lvblackfin647) != "undefined"){document.writeln(lvblackfin647)} if(typeof(lvdsp647) != "undefined"){document.writeln(lvdsp647)}

1. So if the TCP Listen VI cannot do this, is there a different VI that can?

2. If there is no VI for this purpose, is there some way to handle this using Labview?

[MikeS81]

Hi electric550,

you need only this vi. Use the example finder and search for tcpi/ip. See the client server example, they show how show can create multiple connections to one server.

Mike

[electric550]

Thanks, I thought I had checked all the examples but it looks like the one that keeps track of the connection ID's works on the same port for multiple connections.

[Mark_Yedinak]

A TCP server will use a single port number for incoming connections. However to serve multiple connections at the same time it will need to spawn a separate task for each connection. TCP connections are uniquely identified using both the source and destination port as well as the pair of IP addresses. Even though clients use the same port number to connect to the server each connection is actually unique. If the server does not spawn a task to process the connection that you will be limited to a single client at a time.

[mrbean]

I have a client on one PC (some legacy CVI code running as an exe) and I need to send messages to it via another PC (another client) over ethernet.  I plan on using the approach found in the examples C:\Program Files\National Instruments\LabVIEW 8.5\examples\comm\TCP.llb\Multiple Connections - Client 1.vi.  I plan on creating a server whose purpose would be to receive messages from either client and route the message to the other client.  Client 1 (legacy CVI) would stay running as long as the server, but client2 would connect and disconnect often, as he would be implemented through multiple VIs and called (step by step) from TestStand.  So, Client2 would connect, send a msg through the server to Client1.  Clent1 would perform some function (since he's really the UUT I'm trying to test), build a response message and send it to server who would send it on to Client2, who would determine Pass/Fail and tell TestStand.  That Client2 would close, and the next TestStand step (and thus the next Clent2) would open another Client2 TCP Conn and repeat.  Does this sound like a logical approach?

[Mark_Yedinak]

This sounds like a reasonable approach. The only time you may run into an issue would be if you have multiple clients (more than one client 1 or client 2) at the same time. In that situation your routing would have to be much more intelligent. If you have a single client 1 and only a single client 2 at any given ttime this should work quite well.Your intediary server would need to spawn the client tasks and use a queue to pass data between them. Each client task could have it's own input queue (named) which you could use to pass the messages directly between them. The server would only need to spawn the tasks. You might need some message when you connect to identify to the server what type of client it is.

[mrbean]

I'm a little confused as to why (or how) I would spawn these cleints from the server.  Server (on test pc) would be launched as my first step in TestStand sequence (current plan is to make server its own exe).  Client1 is on separate PC, and runs automatically when powered up (second step in sequence file).  Client1 is running on older Windows 2000 system, and is launched via a batch file located in the C:\Documents and Settings\All Users\Start Menu\Programs\Startup folder.  Then Client2 (subsequent TestStand VI calls) would conn to server, send msg, disconnect.  I haven't completely thought this through, so I'm trying to understand your ideas.  In the Multiple Connections example, they use the Date Server Queue VI to distinguish the clients.  There's probably a more modern method/approach for this (named queue?).  Anyway, I appreciate your help.

[Mark_Yedinak]

You need to spawn the tasks that service the connection when a client connects to the server. The client can be anywhere on the network and the server doesn't spawn it. However, when the client establishes a connection with the server the server will spawn a task to service that connection.

This method would use dynamic calls to start the tasks for the client processing. This would allow the server to service any number of connections. Though in your case knowing where to pass messages could get a bit tricky.

Think of a web server. It sits on port 80. At any time their can be multiple clients connected to it. Each time a connection is made at the server it spawns a task to service the connection and goes back to listening for new connections.

[mrbean]

I see (I think).  Are you referring to (in other terms) a Callback routine that handles the request?

[Mark_Yedinak]

---

@mrbean wrote:

I see (I think).  Are you referring to (in other terms) a Callback routine that handles the request?

---

In a manner of speaking yes. But it really isn't a call back per se. It is an actual task/process that gets started when the connection is established. A call back is simply a piece of code that gets run in repsonse to an event. It is not a separate task. The server will spawn a true task to service the connection. This task will run as long as the connection is kept open.