TCP connection problem

[hspec]

I have an application which communuicates via TCP with an avionics box we are developing. The code running on the box is the client, and my app is the server. We have developed a crude software watchdog timer between the client code on the UUT and my app. The client code listens for a heartbeat (in the form of a simple IDN query) and will close the connection if the heartbeat is lost for 10 seconds. It then creates a new connection and repeats this forever or until my code reconnects. This works well for a relink after the link between the two softwares is physically disconnected. The problem I have is that when the power is left on the UUT (client) and my LV software is either stopped or locks, the client continues to spawn new connections. These connections switch to CLOSE_WAIT (I use NETSTAT cmd to view connection status) and a large number of them can be opened. They eventually disappear as windows decides they are not needed. When my software is re-started it trys to link with the lowest available port connection number (which is in the CLOSE_WAIT state) and communication is not possible.

I would like to know if there is any way for me to "quickly" determine what state the connection is in, so that I can get to the latest "ESTABLISHED" connection and restart communications with the box.

Thanks,

Howard Spec

CMC Electronics

Canada 

[altenbach]

A few things you say don't quite make a lot of sense.

TCP is a connection based protocol and the connection is setup with a threeway handshake and closed mutually. If the state is "close_wait", it means that one side sent a FIN packet and considers the connections closed.

Do a google search for "TCPstate diagram" and you should get a better understanding. There is no way to go back to data transfer once the connection is in close-wait state.

For a crude watchdog, you might cosider a connectionless protcol such as UDP.

---

hspec wrote:

When my software is re-started it trys to link with the lowest available port connection number (which is in the CLOSE_WAIT state) and communication is not possible.

---

Are you talking about the server "software" (LabVIEW) or the client software? The server should reside on a fixed port number and should just reply to the ephemeral source port of whatever a new incoming connection is.

Can you provide a bit more detail on how you are trying to communicate?

Do you run any firewall software? Make sure that the server responds with a RST whenever the service is not running (default). Some personal firewall programs make the server stealth, preventing a RST response and thus causing a built-up of half-open connections.

Message Edited by altenbach on 02-19-2008 12:14 PM

[hspec]

The client software which resides on the UUT is closing the connection which puts the connection into the "close_wait" state. The client then creates a new connection (on the server fixed port) and waits 10 seconds before closing it and trying again. Therefore when my labview application is started again there can be many close_wait connections as well as one "established" connection.  My problem is that my LV app (the server) tries to link with the lowest connection port number which is in "closed_wait" state. It can take a very long time before we sync back up, because windows does not dispose of the close_wait connections very quickly, and it seems to take labview 4 or 5 seconds to get a connection ID when linking. I would like a method to determine the state of the connection so that I can quickly get to the "established" connection.

I guess another good question would be "why does labview attempt to link with connections that are in close_wait state"

If this is still not clear, let me know and I will try again.  The code is way to big for me to send....

Thanks,

Howard

[altenbach]

---

hspec wrote:
I guess another good question would be "why does labview attempt to link with connections that are in close_wait state"

---

How do you define "link with" and how do you tell?

A server is listening on a port, it does not actively link with anything, but just waits for the next connection attempt.

What is your LabVIEW version?

[hspec]

Labview 7.1.1

Sorry, I don't have a huge amount of Ethernet experience and my terminology is probably a little off.

OK, the LV server "TCP wait on listener vi" tries to connect to a port which is in the "close_wait" state. I know this because I monitor the remote port number reported by the listener vi, and compare it to what is reported by the "netstat" command issued from the command prompt. The TCP wait on listener vi takes about 4-5 seconds to execute, and produces a good connection ID and no error.

[altenbach]

Can you show us some code? How do yo create the listener? How do you close the connection when the program exits?

Are there uninitialized shift register? Any unwired output tunnels that use default?

I don't think LabVIEW has much control about lowlevel TCP/IP details, it just calls system services. Something just does not sound right.

[hspec]

The code is part of a large state machine application so it would be difficult to send.

During initialization I use Create Listener.vi to get the listener ID. I then use TCP Wait on Listener.vi to get the connection ID. When I turn off power to the uUT I use TCP Close Connection.vi to close the connection ID I got from TCP Wait on Listener.vi.  I then re-use the same listener ID when the power is turned back on.

This problem has nothing to do with uninitialized shift registers. The solution is probably to change the way the UUT (client) works so that it does not create and then close so many connections when my application is not running.

I was really hoping that there would be some trick to determining the status of a TCP connection. If there is no way to do this, then I will have to change the way the client and server work to prevent the problem. 

Thanks for your help,

Howard

[altenbach]

---

hspec wrote:

I then re-use the same listener ID when the power is turned back on.

---

This might be the problem. I would no re-use any IDs between runs.

[Matthew_Kelton]

How about a couple of screen captures then?

I am confused by some of your statements.  You say the client is connecting, then closing the connection if you server is locked up or not running.  How does the client even establish a connection to the PC if your code is not running or is locked up?

You should be able to reuse the Listener ID (as per Multiple Connections - Server.vi Example).  Can you reproduce the problem using this example.  From what I understand, if you ran this example, the UUT should connect to it, although it will time out.

[hspec]

Matthew,

The client is C code running on an Avionics box we are developing. I'm not sure how it creates or closes the connection, but I can certainly see what it is doing via the dos "netstat" command.

Yes, the TCP communications between my server and the UUT client are working perfectly under normal conditions. I am able to re-use the Listerner ID. The problem occurs when my code (server) is not running, and the power is on to the Avionics box (client). The client opens, then closes new connections every ten seconds if it does not get the "heartbeat" from the server. The heartbeat is in the form of a simple IDN? query from my code.  Windows does not dispose of the closed connections very quickly, so when my code is re-started, there can be many existing connections in the "close_wait" state. My labview code then tries to connect to each of the connections that are in the "close_wait" state, instead of finding the one connection that is "established". This can prevent the client and server from ever re-synchronizing. 

My reason for submitting this post was to find out if there is any way to quickly determine the state of the connection, so that I could get to the established connection quickly and re-establish communications. It seems strange that the "TCP Wait on Listener.vi" provides a good connection ID to a port connection that is in the close_wait state. I have checked, and there is no error or warning coming from this vi either.

You mentioned that the example (which is what I originally based my code on) would connect but time out. I just checked my code, and I currently masking the timeout error. I will have a look at this and check if a timeout error is occuring.  

Thanks

Howard