Preventing two softwares write to the same TCP/IP port at the same

[Thang Nguyen]

Hi,

I don't sure if Window allows two software programs write to the same TCP/IP port at the same time or not, but currently my system has two programs (1 LabView and 1 C#) having to write data to the same device by a same port. I would like to know which VI I should use to check if that TCP/IP port is busy or not and how I should do to wait on that port.

Best regards,

Thang Nguyen

[jdunham]

QUOTE (Thang Nguyen @ Jan 7 2009, 07:10 AM)

I don't sure if Window allows two software programs write to the same TCP/IP port at the same time or not, but currently my system has two programs (1 LabView and 1 C#) having to write data to the same device by a same port. I would like to know which VI I should use to check if that TCP/IP port is busy or not and how I should do to wait on that port.

You should be able to use TCP Open Connection with a reasonable timeout. If the connection is successfully established, you can send or receive data. If the device is not ready for LabVIEW, then the Open Connection function should wait until it is. If the device is fancy enough, it may be able to handle simultaneous connections.

Since the messages are coming from the same system, you may also need to make sure that the local port (which is usually auto-numbering) is not conflicting, but LabVIEW's default is to choose an unused local port.

[Rolf Kalbermatter]

QUOTE (jdunham @ Jan 7 2009, 12:45 PM)

You should be able to use TCP Open Connection with a reasonable timeout. If the connection is successfully established, you can send or receive data. If the device is not ready for LabVIEW, then the Open Connection function should wait until it is. If the device is fancy enough, it may be able to handle simultaneous connections.

Since the messages are coming from the same system, you may also need to make sure that the local port (which is usually auto-numbering) is not conflicting, but LabVIEW's default is to choose an unused local port.

They never can be conflicting. TCP/IP mandates that at least one of these (TCP source address, TCP target address, TCP source port or TCP target port) must be different for any two connections. Otherwise the routing engine would get utterly confused.

Since the listen socket (the device) uses a single address and port and the connections come from the same computer, the connection must be opened on different ports. Yes LabVIEW TCP Open Connection uses auto port selection and always uses a currently non used port for that. You can define a specific port to open but if that port is already in use TCP Open Connection will fail.

And if the device allows multiple connections it will receive an individual socket for each incoming connection so it can easily determine from which source a specific command comes. If it can't handle multiple connection it will normally simply not accept new connections and the second and any further connection attempt will fail with a timeout.

It could be also that the device principially does accept multiple connections but its execution engine is buggy in the sense that it can not handle multiple connections without creating a mess. This would be a design problem of the device.

Rolf Kalbermatter