Jump to content

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


Recommended Posts

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

Link to comment

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.

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.