LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP/IP feature or bug?

Destroying the listener internally is a possible approach but it has a couple problems beyond backward compatibility:

 

The default behavior when creating a listener on a particular port is to not set it to be reusable. This means that when the listener is closed it is necessary to wait for the OS networking stack to clean up the listener before you can create another on the same port. This can take a couple of minutes.

 

Another problem is that it is relatively expensive to set up the listener in the first place. It is much more efficient to wait on an already created listener than to constantly recreate it. It seems to me like it is a more common use case for a server to be listening for connections in a loop. Closing the listener automatically after each connection would be very expensive.

 

We could instead of returning the listener id, add an input whether the listener should be closed and setting the default value to false. This would have the benefit of keeping the listener id abstracted away but the disadvantage that the developer would have to know before listening that they want to close the listener when they're done.

 

Nathan

0 Kudos
Message 11 of 13
(1,116 Views)

You're right. I forgot about the OS not freeing the port immediately after you close the connection.

 

You might also wish to get the documentation team to expand the documentation on this (e.g. to explain what a listener is and when it's actually active, since I believe that doesn't appear in the current documentation). This applies to the primitives as well as the listen VI.


___________________
Try to take over the world!
0 Kudos
Message 12 of 13
(1,108 Views)

I agree that whatever else we do the docs need to cover this.

 

The possible solutions in this thread are:

1) Do nothing and document it. If you need to close the listener then use the Create and Wait instead.

2) Return the listener id so it can be closed if necessary.

3) Add an input to close the listener automatically.

 

I feel like the current behavior would be adequate except I'm sure that some users will get confused about the lifetime of the listener even if we add it to the documentation. I'm leaning toward adding the close input. Even if the user doesn't need the input, seeing it there may make it clear that the listener will stay active.

0 Kudos
Message 13 of 13
(1,099 Views)