LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP Listen VI

I'm experimenting with the network queue example found in C:\Program Files\National Instruments\LabVIEW 2009\examples\general\queue.llb\Network Queue Example.  In the server, a TCP Open Connection occurs at localhost:NetQueueData.  The server also does a TCP Listen at NetQueueEnd:8155.  The Client does (more or less) the oppposite.  It opens a connection to localhost:NetQueueEnd and listens on NetQueueData:8154.  The problem I have is the comment found in the client....

 

"The listener must start first in the Server before this VI opens the connection. This delay makes sure this happens."

 

I have a Server (of sorts) that is always running.  The clients, however, are going to come and go.  What I mean is that I plan to kick off the server (from TestStand) in its own thread.  Then teststand will call test VIs one by one.  Each (when it's running) will be the client.  I would like each client to (as described above) connect to localhost:NetQueueEnd and listen on NetQueueData:8154.  It will send a command to the server, the server (listening on 8155) performs the client command and replies to the client who receives on 8154.  The client determines pass/fail and tells TestStand.  Then TS calls the next (client) and we repeat the above sequence.

 

Is there any chicken/egg problems with trying to establish a listener at the client AFTER the server has already established the TCP connection?  Any other concerns with what I'm proposing?

0 Kudos
Message 1 of 9
(5,371 Views)

I must admit I'm a little confused by your question, but the words Network Queue reminded me that I had worked on an example library of VIs that operate almost exactly like the queue functions themselves, but that can send and receive data over the network.

 

You might give these a try (saved in LV2009). You simply host your queue using the Server polymorphic functions, and use the Client polymorphic functions to access them across the network. There is built-in support for three datatypes: string, variant, and object (LVOOP).

 

You might give these a try. It's about as simple as using named queues (hopefully 🙂 ).

 

NQ.PNG

Message Edited by Jarrod S. on 11-05-2009 10:47 PM
Jarrod S.
National Instruments
Message 2 of 9
(5,352 Views)

I basically have two VIs running.  One is a client, one is a server, although it can be argued that both are servers and both are clients.  One gets the title of Server, though, because he's always running, and the client runs for a bit, sends a message to the server, gets a reply, and is done.  Then another client does the same thing, all controlled by TestStand. 

 

My problem, though is that I TCP_Listen at the server for the Client's TCP message and I TCP_Listen at the client for the Server message.  However, what I'm seeing is that the listen has to happen before the TCP Connection (associated with that Listen) is created.  How do I get this to work?  Does the Network Queue (OO version) do anything differently?

0 Kudos
Message 3 of 9
(5,330 Views)
If I were to use this, where would I start?  Do I use (and grow) the provided project?  I'm just not following the flow.
0 Kudos
Message 4 of 9
(5,314 Views)

mrbean wrote: 

My problem, though is that I TCP_Listen at the server for the Client's TCP message and I TCP_Listen at the client for the Server message.  However, what I'm seeing is that the listen has to happen before the TCP Connection (associated with that Listen) is created.


Why does your client need to listen to the server?  TCP packets go both directions, so there shouldn't be a need to establish two different connections between the same two programs.

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

This is correct. You can simply transmit in both directions on one TCP communication line if you like.

 

When I have established bidirectional communication schemes in the past, where each side creates a listener, I would include a handshaking step. Even though both sides have a listener, one is still considered the server. First the client creates its own listener. Then the client connects to the server. After that connection is successfully established, the server connects back to the client.

 

Jarrod S.
National Instruments
0 Kudos
Message 6 of 9
(5,300 Views)

I agree with Nathan; I see no need for two connections.  

 

A TCP connection is just like a telephone connection: Somebody has to dial the phone, and somebody else has to have their ringer turned on.   

 

After the connection is made, the two ends are equals; who talks and who listens is up to you - they can both transmit and they can both receive.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

Message 7 of 9
(5,294 Views)
If you are truly implementing a queue then you can't use it for bi-directional communication. You generally want only one task pulling messages off the queue. However, in the problem above you could configure it such that the server always maintains a receive queue for itself that the clients can use to send messages back to the server. The clients themselves would never need to start a listener. When the client start s it would request its its message queue from the server. The server would maintain a listening queue which it creates when it starts that the clients owuld use to return messages back to the server. The server is the only one who actually needs the have the TCP listener.


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

I have yet another question about the example in C:\Program Files\National Instruments\LabVIEW 2009\examples\general\queue.llb\Network Queue Example.  It's really more of a general question but it's easier to point to this example for reference.

 

In this example, the the two TCP Open Connection calls (one in Client, one in Server) set up the connection using 'loclhost' for the address then they provide a service name instead of a specific port.  This makes perfect sense - almost.  If you specify a service name, LabVIEW queries the NI Service Locator for the port number that the server registered.  However, the only way to register a port number is to call a TCP Listen.  I did find that if you go to the Tools::Options::VI Server, you can uncheck the "Use default" in the 'Protocols' TCP/IP area, and you can specify ONE port and service name.  Is there a way to create multiple port/servicename associations.  Otherwise, I don't see how you reliably create TCP Connections within localhost and a specific port.  It seems like there is a possibility of selecting a port that is used already.  I get Error 63 when I try.  In other parts of my code I successfully create TCP/IP connects to specific IP addresses (non-localhost) but I can't get this localhost thing to work.

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