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

[Jeffh4]

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://forums.ni.com/ni/board/message?board.id=170&amp;message.id=38579&amp;requireLogin=False" target="_blank">http://forums.ni.com/ni/board/message?board.id=170&amp;message.id=38579&amp;requireLogin=False</a>
&nbsp;
I'm guessing that the TCP Listen.vi creates a "phantom listener" that persists after the TCP connection is closed.&nbsp;
&nbsp;
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.&nbsp;
&nbsp;
Is this a bug in LabVIEW, a "feature", or am I missing something?


tcp_close.llb:
http://forums.ni.com/attachments/ni/170/190742/1/tcp_close.llb

[Jeffh4]

Sarah,
Thanks for the response.&nbsp;
I didn't have the instructions exactly right.&nbsp; The Date Client works with the Date Server and the Multiple Client works with the Multiple Server.&nbsp; The instructions are correct in the attached pic.&nbsp; 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.&nbsp; 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&nbsp;call (Post Open error out) even though the TCP connection has been closed and the server VI is in the Delay Loop.&nbsp; There was only one TCP connection and it was closed, so how can that port still accept connections?&nbsp; 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:
Loading Image...

[Jeffh4]

This post might be inappropriate. Click to display it.

[Jeffh4]

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

[Jeffh4]

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


one_tcp_connecton_only.llb:
http://forums.ni.com/attachments/ni/170/193071/1/one_tcp_connecton_only.llb

[Jeffh4]

Hit the wrong reply.&nbsp;&nbsp; Please see my response earlier in the thread.&nbsp; Thanks,
&nbsp;
<a href="http://forums.ni.com/ni/board/message?board.id=170&amp;message.id=190742&amp;jump=true" target="_blank">http://forums.ni.com/ni/board/message?board.id=170&amp;message.id=190742&amp;jump=true</a>

[Jeffh4]

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

[Elizabeth S]

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

[Elizabeth S]

Hi FMonkey,

&nbsp;

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

&nbsp;

Regards,

Elizabeth S.

Application Engineer

National Instruments&nbsp;

[Elizabeth S]

Hi JeffH4,

&nbsp;

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

&nbsp;

Regards,

Elizabeth S.

Application Engineer

National Instruments