I'm working on a multi-server (sbRIO-9612's), multi-client (Windows PCs) application which uses the STM 2.0 libraries and LV2009 SP1. The server listens on a UDP port for the client to send a message - once sent, the server opens the TCP connection to the client and all is well . . .
. . . until I added a "hearbeat" message to monitor for down connections. Once the TCP connection has been extablished, the client PC sends a TCP message (a request for the number of clients connected) to the server sbRIO-9612 every 5 seconds - both the client and server are coded to close the connection if a message is not received within 10 seconds. The client-side app works fine - if the TCP message is not returned in 10 seconds, the connection is closed and a new UDP message is sent to re-establish it.
The server-side is the problem - if no message is received in 10 seconds, the TCP connection is closed o.k. (no errors), but the server will no longer allow new TCP connections to be established unless it's rebooted. It seems to work fine if I leave the non-communicating TCP connections open on the server-side, but I can see this leading to problems after several clients have disconnected without notifying the server properly.
Interestingly, if the client closes the TCP connection properly (via TCP Close in LV), the server detects it fine and there is no problem.
I'm allowing the operating system on both sides to select the TCP port to use.
Any help is greatly appriciated - thank you!
How are you configuring new TCP connections? The TCP Listen VI should be able to catch new connections even after you've closed out existing connections. It might be a matter of the logic/dataflow in setting up new connections and closing out older connections. Can you post up the TCP code you're using in a simple/stripped down example?
I apologize for the delayed response - your suggestion to post a simplified version of the code prompted me to create very simple versions of both the client and server VIs, which did NOT behave the same as the original complete versions. So there was no need to post them . . .
After sever attempts to diagnose the problem, I installed the latest version of LV (2010 SP1) - which seems to have fixed the problem completely.
Thanks for your suggestion to simplify the code - it demonstrated that the problem was not what I initially thought it was.
Thanks for the update -- I'm glad that you were able to find that the issue wasn't actually with the TCP VIs, and moreover that LabVIEW 2010 SP1 seems to have resolved the issue. I would still recommend combing through the code on the RT end to ensure that the LabVIEW 2010 SP1 upgrade really did 'fix' the underlying issue. It's somewhat strange that a version upgrade resolved TCP communication issues that you were having. I just want to be sure that the solution is a truly stable one.
I agree, it doesn't seem right that a LV upgrade would fix the problem - although the sbRIO software modules were upgraded at the same time. Could one of them have caused the initial problem in the way the TCP connection was being closed/opened?
I went back and closely reviewed the RT code and didn't see anything out of the ordinary. I've also been stress testing the application on both the client and server side in the same (and different) conditions that caused the original problem and haven't generated a single failure.
Thanks again for your support on this!
An update to the sbRIO software modules might explain the resolution to the problem you were initially facing. I just wanted to make sure that the solution wasn't a fluke. I'm happy to hear that you have a stable solution, as you are unable to replicate the problem through stress testing the application. Best of luck going forward!