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

[LeiJ]

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

[MikeS81 · Accepted solution]

Hi Lei,

you can check for a valid reference before using the read function. Can you upload a picture of your code? Can it be that you unawares close a reference?

Mike

[LeiJ]

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

[rolfk]

---

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

[Glauber]

Hey guys,

I'm having the same problem - I get error 66 when trying to read on a TCP connection after a successful listen.

I have an off-the-shelf client I want to communicate with and I wrote a LabVIEW server for this purpose.

Below is a wireshark capture of the network traffic taken when I tried the connection.

The address ending on 5 is the client and 50 is my server.

Does anyone have an idea about what might be happening?

Any help is appreciated!

Thanks,

Glauber