Sign in to follow this  
Followers 0
san26141

No Error 66 returned from TCP Read when expected

9 posts in this topic

What error, if any, does it return? the error might be something like

59 The network is down, unreachable, or has been reset.

66 means that the connection was closed by the peer (TCP stack). Pulling the cable is not the same as a "close".

Share this post


Link to post
Share on other sites
What error, if any, does it return? the error might be something like

59 The network is down, unreachable, or has been reset.

66 means that the connection was closed by the peer (TCP stack). Pulling the cable is not the same as a "close".

We reset the VME backplane and our XP machine returns that the network connection was lost but the test program continues to report a "56". (We placed a conditional probe to pause for any error greater than "56" and it never stopped.) We then opened the box and yanked the ethernet cable and it took about 10 seconds for the test program to report the "66".

It seems the problem is hardware. (Geez I love saying that!) The reset does not necessarily close/destroy the network connection and in the meantime it continues to report the "56". Got to figure out what the difference is between a hardware reset and yanking the ethernet cable.

Share this post


Link to post
Share on other sites

We reset the VME backplane and our XP machine returns that the network connection was lost but the test program continues to report a "56". (We placed a conditional probe to pause for any error greater than "56" and it never stopped.) We then opened the box and yanked the ethernet cable and it took about 10 seconds for the test program to report the "66".

It seems the problem is hardware. (Geez I love saying that!) The reset does not necessarily close/destroy the network connection and in the meantime it continues to report the "56". Got to figure out what the difference is between a hardware reset and yanking the ethernet cable.

That is not how TCP/IP works. TCP/IP is a state controlled protocol and in order for an error 66 to be reported the TCP/IP stack must go trough the FIN state which is initiated with a FIN, FIN ACK handshaking. Since the connection simply went away there is not something like this.

For the local stack the connection is still in an active state although all packet sends and requests timeout, and that is what you get, error 56 timeout. You will have to rethink your aproach but TCP/IP in itself does not guarantee detection of line breaks, only detection and reporting of successful transmission.

I think there is some configurable timeout clearing for the TCP/IP stack, where the connection is put into the FIN state automatically after a certain amount of packet requests timeout continously.

Rolf Kalbermatter

Share this post


Link to post
Share on other sites

Error 56 sounds logical. It only means that there was no data received in time. This has nothing to do with the TCP timeout (which I think you cannot set from within LabVIEW). If you only read and don't receive anything the connection is not considered lost at all. The other side just didn't send anything. It is only after some data is tried to be send and no acknowledge is received from the other side that the TCP layer will say that the connection is lost. But that is usually only after a considereable time (at least half a minute but possibly a few minutes). This is why it is often good to have some form of keep-alive built into your app, a packet that is sent from both sides at regular intervals. At least then you detect when the connection is lost.

Joris

Share this post


Link to post
Share on other sites
It is only after some data is tried to be send and no acknowledge is received from the other side that the TCP layer will say that the connection is lost. But that is usually only after a considereable time (at least half a minute but possibly a few minutes). This is why it is often good to have some form of keep-alive built into your app, a packet that is sent from both sides at regular intervals.

I think you can access the lower layers of the IP stack to enable/disable Keep alive packets as well as setting the period of the Keep alive packets.

We had a problem with delays when transferring small pieces of data, the solution was to disable the Nagle algorithm (buffering of small packets until an efficient size is gathered). To do this we used the code in the folling link as an example:

http://digital.ni.com/public.nsf/websearch...39?OpenDocument

As I remember, we also tweaked other network parameters (enabling/disabling KEEP_ALIVE messages etc.) using a similar approach (GetRawSocketFromConnectionID).

In VISA-TCP/IP you can also set some of these parameters through property nodes.

/J

Share this post


Link to post
Share on other sites
A co-worker found some code on the NI forums site that helps with the problem...

Linkup / Linkdown detection; Network cable plugged or unplugged

The LLB that is referenced (iptools.llb) ties into a DLL that gives an immediate response to the connection status.

Hmm I know them as I wrote that library :-)

But the status they return is completely independant of TCP/IP or any other network protocol. They return the link status of the network connection (in fact the detection of the carrier on the network cable when it is connected).

However be aware that that may not always work, although today that may not be as bad anymore. It can both depend on the network card used and its drivers as well as on the remote side connected. For instance having a hub will always see link status connected eventhough that hub may not be connected to anything else but the power line. In the past some hubs with auto detection/negotiation of the speed and/or crossover or not connection, did have troubles to properly detect certain network cards resulting in a carrier on the network link but no real connection possible.

So don't just blindly expect this library to give you everything. This status only tells you that there is a powered network interface attached to your interface and nothing more. If network traffic is possible or not can be and often is a completely different issue.

Rolf Kalbermatter

Share this post


Link to post
Share on other sites

Thank you Rolf....both for the library and giving me a heads up on the info returned!

David

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0