san26141 Posted January 19, 2007 Report Share Posted January 19, 2007 Description : See attached VI. While in the Quote Link to comment
LAVA 1.0 Content Posted January 19, 2007 Report Share Posted January 19, 2007 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". Quote Link to comment
san26141 Posted January 19, 2007 Author Report Share Posted January 19, 2007 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. Quote Link to comment
Rolf Kalbermatter Posted January 22, 2007 Report Share Posted January 22, 2007 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 Quote Link to comment
robijn Posted January 23, 2007 Report Share Posted January 23, 2007 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 Quote Link to comment
Mellroth Posted January 23, 2007 Report Share Posted January 23, 2007 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 Quote Link to comment
san26141 Posted January 23, 2007 Author Report Share Posted January 23, 2007 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. Quote Link to comment
Rolf Kalbermatter Posted January 24, 2007 Report Share Posted January 24, 2007 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 Quote Link to comment
san26141 Posted January 24, 2007 Author Report Share Posted January 24, 2007 Thank you Rolf....both for the library and giving me a heads up on the info returned! David Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.