TCPServer does not seem to release its port

Hey there,

Using latest VL.IO.TCP available (0.4.1-alpha), and tried with both gamma 5.2 and latest preview (5.3-192)

I’m spinning a TCP server in vvvv gamma and make Châtaigne talk to it. All is good until I delete the TCPServer node : it looks like it’s still running somewhere in the background since Châtaigne marks it as Connected, even after the node gets deleted.

Here are some repro steps and a capture :

  • Create a TCP server in vvvv, leave the default settings
  • In Châtaigne, create a TCP Client module, point it to vvvv’s port
  • You can see the Is Connected bool turning true in Châtaigne. Is Connected is true in vvvv as well, all good
  • Using Châtaigne’s Command Tester, send a string to vvvv, it works just fine
  • In vvvv delete the TCPServer : Châtaigne will lose the connection (Is Connected goes false) and then turn true again
  • CTRL + Z in vvvv, the TCP Server shows up again. But even if sending something from Châtaigne, vvvv does not receive anything
  • Now change the port to 4445 both in Châtaigne in vvvv, it works again until you re-delete the TCPServer in vvvv
  • Delete everything in vvvv and change the port back to 4444 in Châtaigne, it will pretend it’s connected even though there’s nothing running in vvvv
  • Quit vvvv, Châtaigne will indeed indicate Is Connected is false

What makes me believe that it has something to do with vvvv is the fact that when quitting the process, Châtaigne reports it’s disconnected.

Any idea?


i found TCPView from sysinternals very helpful to debug these kinds of situations.
if the server is not released properly you should be able to see it in there…

1 Like

Thanks for the suggestion @motzi, will double-check tomorrow :-)


TCPView indeed gives similar results. See the following capture : TCPServer never releases its ports. Later in the video I’m comparing with OSCServer that disposes when changing the port or deleting the node.

This is not shown in the capture but when quitting vvvv, the entries are gone from TCPView.

Very nice tool by the way :)

1 Like

The server is not stopped / disposed on Dispose. If you add the following it works as expected:

1 Like

thanks for bringing this up. it is fixed in VL.IO.TCP 0.4.2-alpha

This should be fixed at the Cache region, the “Dispose Cached Outputs” is set to true, so the region should dispose the server instance at its output on stop.


the reason we’re not using “Dispose Cached Outputs” here is that disposing the server is not enough. we also need to call Stop() on it before to fix the above mentioned issue. therefore here we’re using a SerialDispose as you can see in the patch.