No Error 66 returned from TCP Read when expected

[RedSoxFanatic]

Description       : See attached VI. While in the “TCP Read” loop, the Ethernet connection is physically disconnected.

Problem            : No Error 66 is returned from the TCP Read.

[BEHajder]

Hello Red Sox Fan, I tried your vi using LV 8.0 with a remote I/O rack (IP 172.16.17.201, port 502). I got error 66 when I unplugged the cable while it was running, it took a few moments though.

[RedSoxFanatic]

Thanks for testing this. As it turns out when I disconnect the Ethernet cable I do indeed get the Error 66. Our real test is a VME reset (not disconnecting the cable) which resets our target. After doing the VME reset, Windows (host) recognizes that the ethernet connection is lost, but the TCP read (sample program I posted) on the host does not. We're now looking into jumper settings on our target board to see if that is where the problem lies.

Thanks again.

[RedSoxFanatic]

Does anyone know why the TCP Read takes so long to report the TCP connection has been lost? When we attempt a TCP Read with a 1 ms timeout (nothing to read either), then disconnect the Ethernet cable, it takes on the order of 5 seconds to report the loss of connection! UGGH! I don't understand why it doesn't report it on the FIRST instance.

[Ching_F.]

Hello Red Sox Fan,

The TCP Error 66 is not the user defined timeout error.  The user defined timeout error is actually Error 55.  Error 66 occurs when the connection has been closed by the peer.  Please refer to the following KnowledgeBase for more information regarding these two errors. 

Best of luck on your application, and have a great day!!

[RedSoxFanatic]

Hello -

Actually, the timeout error is 56 and I am trapping that. When I call TCPRead, I need to know if the connection has been closed by the peer (66) - this is what takes 5 or more seconds.

[Ching_F.]

Hi Red Sox Fan,

Thanks for clarifying for me.  The reason it takes so long to report a connection loss is because TCP is a lossy communication protocol.  If packets are lost, they are sent again.  There must be time to verify that the missing information is due to a connection loss and not just dropped packets due to the lossy nature of TCP.

Please let me know if you have any further questions, and have a wonderful day!!

[RedSoxFanatic]

Thanks for your reply -

I still have a problem with this. If I disconnect the ethernet cable, Windows immediately displays a message that a network cable is unplugged, but the TCPRead takes over 5 seconds to report an Error 66. I have started using a Windows API to determine if the NIC is disconnected - which works great (takes about 45 microseconds). However, I am connected to a target multiple IPs and need to know if one of the connections is closed. By the time the 5 or more seconds is up and the Error 66 occurs, the individual target processor has already rebooted - which for our application is NOT a good thing.

[Ben]

Just a thought....

The Watch-dog timer may be useful.

Done thinking...

Ben

[tst]

Rolf has more details in this crosspost.

David, when crossposting it is considered polite to provide a link so that people can see what other people already said and not waste their time.