Debugging TCP connections

[Reisbicks]

Hello,

I have two programs that run perfectly together about 90% of the time.  Here is the general idea of what they are doing:

1) Start the server

2) Start the Client

3) Press Run on the server, 

4) It will tell the client that it has started and the client will do tcp read for an incoming 1 byte signal

5) server will run through its loop, then tcp write a 1 byte signal to client

6) client will receive signal and begin to do its loop 

7) server will do tcp read for a 1 byte signal

😎 when client loop is done it will send a 1 byte signal

9) server will start its loop, client will stop.

When I run these two programs, I can get them to do the loop anywhere from 1-40 times before they just fall out of sync without throwing an error.  If it will help I can upload the VI for the tcp regions, but you won't be able to run it because it requires sub Vi's to connect to other equipment in the first place.  I also have all the timeouts set to -1.  I also have noticed that using the probe, the server computer will send the signal, but the client will remain in a listening state.  When this happens, I kill the server, then the signal goes through and the client loop begins to run as it is supposed to and then crashes after it finished because the server is now closed.  Additionally, the sending and receiving loops are the exact same on the client and server but the issue happens on the client end always.  I am new to LabView, so I don't know any of the troubleshooting methods other than the probe, but if there is a way to identify why the packet doesn't get read sometimes that would be very helpful.

Thanks!

[wiebe@CARYA]

First thing is to wire all the errors through all the nodes, and to implement decent error handling\notification.

Changes are, somewhere something gives an error, and that would be the start of the search.

If the applications are on different computers (maybe even if they are not), note that the client connection to the server stays open\valid even when the server is closed. Opening a connection will give an error, but once it is opened, it won't get killed\closed if the server is closed. This gives a very confusing situation, where you have a valid connection, and you can even try to read data. Reading data will give a time out error, but no connection closed error. The time out error could however be something that the application 'expects'. This is tricky to handle properly.

[Bob_Schor]

---

wiebe@CARYA wrote:

First thing is to wire all the errors through all the nodes, and to implement decent error handling\notification.

---

I would have said "First thing is to attach your VI so we can see what you are doing and not have to "guess" that perhaps you failed to implement any error handling.  Of course, you'd need to attach both the Client and Server VIs.  There are other "variations" on Network Protocols that might be easier to use -- I happen to like Network Streams, others have mentioned the Simple Messaging Something-or-other.

Bob Schor

[crossrulz]

---

@Bob_Schor wrote:  others have mentioned the Simple Messaging Something-or-other.

---

STM - Simple TCP Messaging.  And, yes, I really like this library.

But back to the OP....

How often are these messages being sent back and forth?  Windows does not like to see connections that are not being used and will force them to disconnect after so much time with no traffic.  So you may need to implement a keep-alive protocol to keep this from happening.