LabVIEW
TCP connection indicator
electric550 wrote:I continued to search the forum and found this that is basically the same problem....
http://forums.ni.com/ni/board/message?board.id=170&message.id=296249&query.id=189593#M296249
I see that the explained solution was to send periodic data to make sure that the connection is still on, but my situation requires limited data to be sent so I would rather find a solution that relies only on the actual connection indications. I looked through the error indicators, but none of them seem to provide the proper indication. If anybody can provide a solution that relies only on the connection itself I would greatly appreciate it.
There is no fail proof way to detect that the connection has been dropped by the peer. You can try to do a TCP Read on a connection with a not to long timeout and detect if you get anything else than a timeout error or valid data. If you do get an error that is not a timeout it usually is the disconnected by peer error. But that can and sometimes does fail, if the connection remains hanging in the disconnecting state for some reasons.
There isn't any way to passively detect a connection loss reliably. If the remote side properly closes down the connection, then you will see the connection closed by peer error, but if it simply drops out while in idle state, this may never occur. The only way to reliably detect the fact that the remote side has been disconnected, unexepectedly shutdown, cable broken, or whatever is to attempt some sort of data transfer. So it needs to be able to accept incoming commands even if it is as simple as a a status inquiry that needs to be answered with at least a short, "yes I'm still there" but it could be also a command to retrieve some information such as current settings, data values or such.
So look through the documentation and see if there is a command in your device that does not change anything in the device but gives you a response in some way. Then use that to poll your device periodically (not several times a second, but probably also not only every hour) and use the error of the TCP Read that follows your TCP Write to determine the connection state.
You mention that your program already does TCP Reads. How are they initiated? Does the device simply spew data periodically? Or do you request the data with a command? In both cases you do know that there should be a response and that since there isn't something must be wrong with your device and you can safely assume that it went somehow belly up. The right thing to do then is to not ignore the timeout error after the period that you know the device should have answered, but instead close the connection and attempt to reconnect again, which will then give you an according error if the device is still not reachable.
And no you can't open up yellow LabVIEW nodes any further. They call directly C functions in the LabVIEW kernel, so there is nothing that could be made visible to you anymore. Those LabVIEW kernel functions ultimately call the platform network socket APIs, a very powerful but also quite cumbersome API to work with as programmer. Be happy that you do not have to deal with that level of programming.
electric550 wrote:
That was just bugging me because I know that the TCP IP protocol itself has error checking capabilities so I figured there would be some way to use just TCPIP to check the connection status. I will just use the periodic message passing to check the connection for now.
The protocol has indeed error checking capabilities. But they are mostly targetted to guaranteeing errorless data transfer, not to guarantee a connection itself. TCP/IP is connection oriented and it guarantees, that you can detect if the data has been transferred successfully, but not that there is still a valid connection when you are not transferring data at all. When the protocol was defined continuous copper or glasfiber wire from one end to the other was not very common, with all kinds of (very) slow gateways in between such as dialup connections, and it was not the intention to slow down such bottlenecks even more by having the protocol inherently transfer control messages all the time.
The reasoning looks quite sane to me: We guarantee that the data is transfered successfully or the sender receives an error indication. If someone wants to monitor the connection state, he can always transfer control messages him/herself and deduct the connection state in that way.
That said there are nowadays options to enable inherent keep alive control messages on TCP/IP connections, but the device must support that (many don't since that requires according support in the TCP/IP socket stack that many embedded stacks lack) and the option has to be enabled on the sender side, which is not a built in feature of LabVIEW. Enabling or disabling socket options requires you to fiddle around with direct Winsock API calls through the Call Library Node, but considering that there are two sides where this could go wrong, I think that is not a good option. Just use a status inquiry of your device to poll it periodically and all is well.
NordicViking wrote:Talking about guaranteeing correct sending of tcp-messages: When I do a TCP-Write on my RT-device towards a windows PC, and the connection is interrupted beforehand, the tcp-write-vi does not give an error, even though the data cannot have reached the PC for sure. It seems, this is a poor implementation of the tcp/ip-stack on the RT-System.
Anywone else ever saw this problem?
That is standard behaviour. The write function for a TCP socket does not return with an error in asynchronous operation since it does not wait for the data to be acknowledged by the remote site. That is how asynchronous TCP/IP sockets work and LabVIEW uses asynchronous sockets internally. You only get an error on write when the refnum is invalid or the buffer for the associated socket could not be filled for some reasons.
