Showing results for 
Search instead for 
Did you mean: 

Port opened with TCP continues to accept TCP Open calls after closed

I've enclosed modfied versions of the Data Server Client and Server (TCP and Multiple Connections Client and Server (TCP Create/Wait on's)
Both Servers have a Wait Delay Loop after the TCP Close Connection (Data Server vi's) or TCP Close Listener (Multiple Connections vi's)
If you run through the instructions, you'll see how the port opened with TCP continues to accept TCP Open calls after closed, but the port opened with TCP Create Connection does not.
Looking at this post:
I'm guessing that the TCP creates a "phantom listener" that persists after the TCP connection is closed. 
This is undesirable behavior for my VI. Fortunately there is a work-around available by using the TCP Create/Wait on Listeners vi's instead and I'll just limit the number of connections to one. 
Is this a bug in LabVIEW, a "feature", or am I missing something?
0 Kudos
Message 1 of 20
Forgot to mention that I'm running on a PC, Windows XP Pro, LabVIEW 7.1
0 Kudos
Message 2 of 20
Hi, Jeffh4.

Thank you for that well-documented segment of code; it's refreshing to see code that's so easy to read! Unfortunately, however, I didn't see the behavior you described when I ran it. You say your server is accepting connections even after the listener has been closed, correct? That does sound undesirable; I would expect the client connection to fail once the inner loop is stopped. But that's exactly what happened (and what your instructions seem to predict -- contrary to your above post). I suspect i'm misunderstanding you -- could you please clarify a bit?


Sarah K.
Search PME
National Instruments
Message 3 of 20


Thanks for the response. 

I didn't have the instructions exactly right.  The Date Client works with the Date Server and the Multiple Client works with the Multiple Server.  The instructions are correct in the attached pic.  The pic shows what the client screens should show after following the instructions for the Multiple Server and Date Server runs.

You'll see that the second run for the Multiple Client fails on the TCP Open Connection call.  That is what I would expect to happen because the listener and the connection have both been closed.

For the Date Client, the second run for the Date Client succeeds the TCP Open Connection call (Post Open error out) even though the TCP connection has been closed and the server VI is in the Delay Loop.  There was only one TCP connection and it was closed, so how can that port still accept connections?  snoop/ethereal verifies that LabVIEW did accept the connection on the port and the subsequent read fails, which we see in the Post Close error out.

LMK if you see the same thing on your runs.

0 Kudos
Message 4 of 20
Hit the wrong reply.   Please see my response earlier in the thread.  Thanks,
0 Kudos
Message 5 of 20
Hi, Jeff.

I'm afraid I'm still confused -- the instructions in the picture match those on the file I initially downloaded from you, and my initial comments still stand. If the VIs you sent work correctly -- as you said in your last post -- I'm not sure what I'm supposed to see by running them myself.

Let me know! What you're talking about sounds very interesting, so I hope I'm able to figure it out. 😃

Have a nice evening.
Sarah K.
Search PME
National Instruments
0 Kudos
Message 6 of 20

Thanks for sticking with this Sarah.

When following the instructions, do you get a screenshot that matches the one I included? 

If so, then you'll see that after a TCP Listener is closed by the Mulitiple Connections mod server, then next Client Open attempt FAILS (as shown by Post Open error out in the Multiple Connections - front panel).  This is what I would expect. The server is NOT trying to accept a connection, so the Client cannot connect.

Also, after a TCP Listen is closed by the Data Server mod server, the next Client Open attemp SUCCEEDS (as shown by Post Open error out in the Data Server front panel). The server code is not running any code at that point that would accept a connection.  So why can the Client connect? It should not be able to.'


0 Kudos
Message 7 of 20
Hi, Jeff.

Okay, I've figured it out. It took a good bit of tracing and debugging, but the TCP protocol is not behaving incorrectly (or unexpectedly) -- the problem is an error in your code. In the Data Server mod, you stop the inner loop and then seem to see a connection despite the fact that TCP Close Connection was called. The error is that TCP Close Connection is not called. It's called when I close my client VI, but when I press "Stop inner while loop," it's not executed. (I was able to determine this by putting a breakpoint just in front of it.)

And since the connection is not closed, the next client connection connects as expected (and the only error occurs when the client's Read times out).

Incidentally, my confusion from before stemmed from a misnomer in the instructions combined with my not understanding that you were only including the multiple connections VIs to serve as a comparison for how TCP should be behaving.

I hope my explanation was clear -- if you're still confused, let me know. Have a nice evening!

Message Edited by sarahk on 06-26-2006 09:42 PM

Sarah K.
Search PME
National Instruments
0 Kudos
Message 8 of 20
Thanks for the input, but I'm afraid that wasn't it.  The "Not a Number/Path/Refnum?" control just prevents the TCP Close being called if the reference number coming in is zero.  Removing the case structure or adding a TCP Close to the TRUE case does not fix the problem but does have following side effect.
When the Data Server is later stopped by clicking Stop Outer Loop, Stop Wait Delay Loop, then Stop Inner Loop, the General Error Handler creates a popup stating "Error 1 occurred at TCP Close Connection in Data Server" 
The question still remains. Why does the Data Server accept the Client Open connection after the TCP Close is called?  For a demonstration of this, put a Probe Data selection on the connection ID entering the TCP Close.  Then run the Server. Then run the client.  Then hit the Stop Inner Loop button.  The probe popup shows the tcp connection ID going into the TCP Close.  Now run the Client again.  The TCP Open is successful as shown by the good status in the Post Open error out indicator even though the Server successfully closed it's connection.
LMK what you think.
0 Kudos
Message 9 of 20
Hi, Jeff.

Okay, I took another look at your code, and I saw the error 1 behavior when I removed the case structure. After working with that for a few minutes, I came to the conclusion that that code is too complex for us to easily narrow down the issue. So I created my own very simple mods of the data client/server examples that demonstrate TCP/IP working correctly. Unfortunately (for me!), in creating them I determined that you are in fact correct -- the listener remains listening (and accepting connections) after a Close Connection has executed. Incidentally, however, further testing showed that despite the second connection, no data may be transmitted using the read and write VIs. (So that's a saving grace at least!)

But it does seem to be a bug. I'll file a report on this to R&D to see what they say about it. That's a tricky thing to spot -- kudos to you. Thanks for taking the time to point it out!

Have a nice evening. If I find out something interesting on the subject from R&D, I'll post back here and let you know.
Sarah K.
Search PME
National Instruments
0 Kudos
Message 10 of 20