Why tcp closed by peer when trying to read msg after the successful Listen?

Question

Hi everyone,
I had trouble to read data after Listen function return a good connection ID. The embedded application is running in ARM processor and I build a PC application with Labview to read the device status via TCP connecion. There are required two TCP connections between embedded application and PC application with specific port to listen on each side. After exchange port number by UDP message, both sides know the destination port to send msg. I can send request to embedded apllication in one TCP connection then listen to other TCP connection for reply. By monitroing the traffic of network card, I can see the successful TCP open sequence and in coming reply data, but Labview application shows error 66 "network connection closed by peer" when trying to read data, which is quite strange. I already see those data with network monitor tool, such as wire shark.
Did anybody experience the similar problem? and provide some suggestion? Is it problem of configuration of Labview? windows XP? I am using Labview 6.1.
Thanks
Lei
Solved!
Go to Solution.

Answer 1

LeiJ wrote:
Thanks Mike,
The problem was solved. It is timing issue. There is another while loop in code which sends heartbeat UDP message regularly for ervry 10 seconds, and this cause the problem of TCP read function. If I stop or remove this thread of while loop, the read function works fine. The UDP heartbeat message is only need to use once at first beginning to broadcast port number when setup TCP connection. Possibly I can send the heartbeat somewhere esle. I think the TCP error code 56 (timeout) and 66 (network connection closed by peer) is not distinguished in TCP read function. Thank you for reply and suggestion.
Regards
Lei
Actually LabVIEW distinguish between these errors very specifically. If you get an error 66 the connection was closed for sure, either explicitedly by the peer of implicitedly by the TCP IP stack after loosing the connection for to long such as when the Ethernet card would be disabled.
The issue most likely is that your client after sending back an open-package expects a specific response in a specific amount of time and closes the connection down if it does not get a valid response. Seems like a good measure to try to minimize the resources on your embedded target that need to be allocated when a badly behaving client is looping in a connection attempt.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions