TCP/IP feature or bug?

Question

I have been using the basic TCP VIs (Data Communication palette) to implement multiple independent TCP streams with a real-time system.  In doing some tests, I found a strange behavior that I think may be a "bug".
To form a connection, you need to both run both TCP Listen and TCP Open Connection with the same Service Name.  I assumed that when you closed these two TCP IDs (TCP Close Connection), a subsequent Listen alone, or Open Connection alone, would fail (because both need to be present).  However, I found that while I could not open the Listener a second time without it timing out, I could open the "Open Connection" (without re-opening the Listener) and no error would result.  This should not work (because you could, for example, "Send" via the "Open Connection" stream but not have any process "listening", and capable of receiving, the data).
I've attached a VI that runs the following 6 tests:  1, open/close ("run") server; 2, run client; 3, run server + client; 4, run server+client, then run server+client again; 5, run server+client, then run just server again; 6, run server+client, then run just client again.  According to the principle that both a server and client need to be running at the same time, only tests 3 and 4 should succeed without error (the server is configured with a 2 second timeout, which generates an error if there's no client), but test 6 also succeeds!
Note that the "Is a RefNum" VI on the Boolean palette correctly indicates "Not a RefNum" after the Close Connection VI runs.
P.S. -- this VI was run and tested on LabVIEW 8.5.1.  I just ran it on LabVIEW 8.6, and it behaves the same way (tests 3, 4, and 6 run without error).
Bob Schor
Attachments:
TEST TCP Open and Close.vi ‏46 KB

Answer 1

I don't know all the internal TCP details (e.g. SYN and ACK) and who's supposed to send what and when. I'm assuming that the LabVIEW primitives follow it correctly.
I should also point out that my claim earlier about the listen VI creating multiple listeners was wrong. I simply hadn't looked inside the IA VI, although I have done it in the past. Looking at it shows clearly that it has its own buffer for the listener references and only holds one for each port (makes sense, since you can't have two connections on the same port). Assuming that the primitives work correctly (which they probably do, or there would probably be a single primitive for listening instead of two), then I guess that NI does need to output the listener ref as you suggested, so that the user can disable the listener if they so choose.
By the way, this was simply a pet annoyance of mine, since I was asked to debug a piece of code which was affected by this issue and it was annoying. Essentially, the system had a single client with multiple servers and each server would only allow one connection. The server code looked something like this:
The client code had a similar timer for handling the errors, but it had a much shorter timeout, so what was happening was that if the user closed the client and reopened it while the server was still in the right loop, they would get stuck in a situation where the client opened the connection successfully but didn't get a response so it kept opening more connections. The server, on the other hand, got a connection each time (since the listener was always active) and a single message which was very stale. Then, it had to count all the errors again.
Of course, once I realized this was the issue, the fix was simple. I created and destroyed the listener myself and that solved that. I could also probably have used an infinite timeout instead of the loop, but fixing it was enough. I didn't need to make it any better.
Try to take over the world!
Attachments:
TCP Listen Example.png ‏5 KB