Prevent TCP IP connection to be interupted

[aucman]

Hi!

What would be the best way to ensure that TCP IP connection remains open (continious read from device) and uninterrupted.

I have two software that connect to device via TCP/IP. I developed one software in Labview and reading from device is successful. The problem is that if I connect with other software while I am connected through Labview the connection on Labview breaks and I get an error. 

Is there a way to ensure uninterrupted TCP/IP connection in Labview?

[Bob_Schor]

Are you connecting to the same Port?  I don't know enough technical details about TCP/IP, so I don't know under what conditions multiple simultaneous connections are allowed ...

Bob Schor

[aucman]

Yes on the same port. The problem is that I do not want to allow simultaineous connections. I want whoever gets the connection first to keep it without others to interfere. But as I was testing normal open connection, read, write, if I wanted to connect with another software on the same Ip with the same port the first connection is interrupted.

[Bob_Schor]

I don't know how TCP/IP (or even if TCP/IP) blocks requests for a particular Port if it is already communicating using that port.  It seems like it should be possible, but this is beyond my level of expertise.

If you find out how to do this, be sure that the Solution is posted here, as I'm sure others will be interested.

Bob Schor

[nathand]

---

@Bob_Schor wrote:

I don't know how TCP/IP (or even if TCP/IP) blocks requests for a particular Port if it is already communicating using that port.  It seems like it should be possible, but this is beyond my level of expertise.

---

If you have no idea what the solution is, it may not be worth replying (twice) 😉

I'm assuming here that the device acts as the server, and LabVIEW as the client (that is, you use TCP Open in LabVIEW, and not Wait on Listener). If this is the case, there's nothing you can do about it, unfortunately. The only thing you can do in LabVIEW is catch the error and reconnect to the device, which will most likely cause the other software to lose its connection. If that software also tries to do an automatic reconnect, you'll have a mess where each program repeatedly causes the server to drop the connection from the other one.

There is no way for a device to know that a connection died versus just hasn't sent any data in a long time, unless the protocol specifies a keep-alive or heartbeat. So, the options for the device are: accept multiple connections, which causes problems if two clients send conflicting commands; not accept new connections when one is already open, which causes problems if a client dies without properly closing the connection; or do what sounds like is being done here, and always use the most-recently established connection, dropping any others that are already open.

[aucman]

Hi!

Tnx for the answer. I am new with the Labview so I think I made a mistake by using TCP Open connection. I will try using TCP Listener which by default looks like it will solve my problem.

At first my approach was to connect to device and send commands and receive a response. But now this problem of multiple connections also has to be solved so I never thought that TCP Open connection is a problem becuase the basic communication worked ok.

http://www.ni.com/white-paper/2710/en/

I somehow didnt read very well this article the first time 🙂

"Because anyone can initiate a connection to a server, you might want server access control. The following block diagram shows how the server uses the remote address output value of the TCP Listen VI to determine whether a remote client has permission to access the server."

[nathand]

---

@aucman wrote:

Tnx for the answer. I am new with the Labview so I think I made a mistake by using TCP Open connection. I will try using TCP Listener which by default looks like it will solve my problem.

---

Most likely you don't have this option. In TCP, one side is always the server and the other is the client. The server waits on a listener. The client opens a connection. If your device acts as a server, then your LabVIEW code must act as the client, so you can't use a listener. The idea of client-server applies only when opening a connection; once the connection is established, communication is symmetric and bi-directional.

[aucman]

hmmm...I have IP address of the device and a port. Yes I probably dont have TCP Listener option because TCP Listener doesnt need an IP address 🙂

So TCP Open connection is the right approach. So all I need is to prevent other computers to connect with the device in case device already has established connection. 

Now I will tell you that I already have a Labview program that is communicating with the device and is successfully blocking other connection while connection is established with that program and device. The problem is that I do not have a source code of this Labview program and I am trying to do my own version of communication with the device because some new things could be added that current program doesnt do.

So there must be a way becuase I already have a working solution (but no source to see it)

[nathand]

I'd guess there's a command you can send to the device to tell it to stop accepting other connections. There's nothing specifically in LabVIEW or the TCP protocol that will do it. Do you have full documentation for the device? Another option is to start up Wireshark and observe the communication between the current program and the device.

EDIT: is it possible the existing program automatically reconnects, so you never see that it dropped the connection?

[rolfk]

Technically a TCP/IP connection is defined by the four specific information points IP address and port number on both ends. At least one of them needs to be different for a TCP/IP connection to exist more than once between two endpoints. So assuming you open a connection from the client side using autmatic port assignement (the default since a client usually doesn't care on which port the local side of its connection is bound), this should work.

However that is the specific capability of the TCP/IP socket library routing capability. A client and/or server or a specific protocol can impose additional limitations on this. As it is described here, the server application seems to accept new connections even if it is already serving another one but then drops the first connection forcefully. That is unusual but definitely possible to implement in a server, possibly intentional but just as possible a bug in the server application.

That is if you don't (have to) specifiy a local port on the client side. If you do then yes the new connection started on the same machine will have all four information elements to be the same for both connections and whoever comes last in establishing such a connection will snatch it away from anyone else. In that case this is an inherent property of the TCP/IP spec and there is no possibility to avoid this, safe from using different local port numbers on the client side (if the server allows that!) It's possible to imagine a server application that only allows connections from a specific port (range) although that would be a pretty unusual TCP/IP protocol specification.