The model in the current Tubes spec is that when you close the stream tube you were offering, it's because you want to stop offering the service at all. The use case we were thinking of was something like:

* you're in a chatroom with Alice, Bob and Chris
* you offer your desktop over VNC so they can help you with something
* Alice and Bob connect
* when they've helped you with whatever it was you wanted, you close the stream tube
* Alice and Bob automatically get disconnected
* You open confidential files that Alice and Bob shouldn't see, but that's OK because you know they've been disconnected

However, with normal TCP sockets, it's also possible to close() the listening socket while keeping Alice and Bob's connections open. For instance, you might have a two-player game that only wants to listen() until a second player joins, then give ECONNREFUSED to anyone who tries to join thereafter, while keeping a TCP stream going between the two players.

I think we should keep the current CloseTube() semantics, for least astonishment, but we should consider adding a StopOfferingTube() method that stops accepting new connections but leaves existing connections as they are.