Port opened with TCP Listen.vi continues to accept TCP Open Connection.vi calls after closed

Port opened with TCP Listen.vi continues to accept TCP Open Connection.vi calls after closed

Post by Jeffh » Wed, 21 Jun 2006 08:40:08


I've enclosed modfied versions of the Data Server Client and Server (TCP Listen.vi) and Multiple Connections Client and Server (TCP Create/Wait on Listener.vi'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 Listen.vi continues to accept TCP Open Connection.vi calls after closed, but the port opened with TCP Create Connection does not.
 
Looking at this post:
 
<a href=" http://www.yqcomputer.com/ ;message.id=38579&requireLogin=False" target="_blank"> http://www.yqcomputer.com/ ;message.id=38579&requireLogin=False</a>
 
I'm guessing that the TCP Listen.vi 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?


tcp_close.llb:
http://www.yqcomputer.com/
 
 
 

Port opened with TCP Listen.vi continues to accept TCP Open Connection.vi calls after closed

Post by Jeffh » Fri, 23 Jun 2006 02:40:09

Sarah,
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.


vierr1.GIF:
http://www.yqcomputer.com/

 
 
 

Port opened with TCP Listen.vi continues to accept TCP Open Connection.vi calls after closed

Post by Jeffh » Fri, 23 Jun 2006 06:40:10

Hit the wrong reply.   Please see my response earlier in the thread.  Thanks,
 
<a href=" http://www.yqcomputer.com/ ;message.id=190742&jump=true" target="_blank"> http://www.yqcomputer.com/ ;message.id=190742&jump=true</a>
 
 
 

Port opened with TCP Listen.vi continues to accept TCP Open Connection.vi calls after closed

Post by Jeffh » Thu, 29 Jun 2006 00:40:09

Sarah,
 
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 mod.vi." 
 
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.
 
 
 

Port opened with TCP Listen.vi continues to accept TCP Open Connection.vi calls after closed

Post by Jeffh » Sat, 01 Jul 2006 20:41:43

Sarah,
 
Thanks!  I've coded a TCP Listener based solution for my application to get around the problem, so it won't be holding me back.  Just thought NI would like to know.
 
 
 

Port opened with TCP Listen.vi continues to accept TCP Open Connection.vi calls after closed

Post by Jeffh » Sun, 02 Jul 2006 01:10:09

Sally,
 
Here's an example of a workaround TCP Server that only accepts one connection (using the TCP Listener insead of TCP Listen).
 
 


one_tcp_connecton_only.llb:
http://www.yqcomputer.com/
 
 
 

Port opened with TCP Listen.vi continues to accept TCP Open Connection.vi calls after closed

Post by Jeffh » Sat, 07 Jul 2007 08:10:08

Sarah,
 
Did R&D find a fix for this problem?  Does a later version of LabVIEW fix this issue?
 
Thanks,
 
 
 
 
 

Port opened with TCP Listen.vi continues to accept TCP Open Connection.vi calls after closed

Post by Elizabeth » Mon, 09 Jul 2007 06:11:19

Hi JeffH4,
 
This issue has been reported and is under investigation by R&D.  I'm sorry for any inconvenience but I do not have further information at this time.
 
Regards,
Elizabeth S.
Applications Engineer
National Instruments
 
 
 

Port opened with TCP Listen.vi continues to accept TCP Open Connection.vi calls after closed

Post by Elizabeth » Fri, 13 Jul 2007 09:10:05

Hi FMonkey,

 

Thank you for your simple instructions.  I was able to reproduce this error and filed a report to R&D (# 4BAHL189) for investigation.  Thank you for the feedback. 

 

Regards,

Elizabeth S.

Application Engineer

National Instruments 
 
 
 

Port opened with TCP Listen.vi continues to accept TCP Open Connection.vi calls after closed

Post by Elizabeth » Fri, 13 Jul 2007 11:10:11

Hi JeffH4,

 

This issue has been fixed in LabVIEW 8.2 as I was unable to reproduce the same problem.  Typically, the report number is posted in a discussion forum when a bug in reported to R&D.  Unfortunately that was not the case in this instance so it has proven more difficult to track down the issue.  Again, I?m sorry for any inconvenience. 

 

Regards,

Elizabeth S.

Application Engineer

National Instruments