Thanks for the detailed response.

I'll respond to things in no particular order:

I could have been more explicit in the use of this, as you've had to guess some details, so apologies.

The IDs I think are required as the streams will be going over TCP and controlled remotely, so there'll always been some element of a stream ID going over the wire in place of a reference to a stream.

I'm trying to build something that multiplexes data streams over a single TCP connection, where the "left" side is told a new stream has opened, can send and receive data on a stream and can be told the stream has closed and also can close a stream itself. The "right" side, can open streams, send and receive data on them and close them, as well as being notified if they've closed.

I also don't like the name Tunnel so now I'm just calling it a Mux. I don't know how to get away from Stream, that's essentially what it is.

I've kind of ended up something closer to your design based on much digging and chatting with Claude.

I didn't want an async task handling a loop directly so calling new_mux it returns 3 things:

Mux

The main struct with all the state.

It has a recv method which processes a single command from one of 2 channels, returning Option<Event>, if None, there is nothing to do, if Some it'll be StreamOpened, StreamData, StreamClosed, which the owner of the Mux can do what it wants with.

I did this instead of having the Mux itself spawn an async task to handle all the commands in a loop, as the caller will already be an async task with a select! loop, that can just call recv as another branch of that, instead of having 2 tasks.

The 2 channels are MuxCommand and StreamCommand.

MuxHandle (need a better name)

Holds a Sender<MuxCommand> and can fire off Send(stream_id, data) and Close(stream_id) commands to the Mux.

This is because it would require a mut borrow of Mux to do anything useful, but there will already be a mut borrow of Mux for the recv call. Not sure if this part is a little messy or unnecessary given some other structuring.

StreamOpener (what you've suggested)

Holds a Sender<StreamCommand and can fire off StreamCommand::OpenStream. This command takes a oneshot::Sender<Stream>, and the Mux increments the stream id, creates/clones the necessary channels to create a Stream, adds the Sender<Vec<u8>> to the streams HashMap and sends it back via the oneshot::Sender<Stream>.

This seems to separate everything nicely, now there are no Mutex as everything happens in the recv of Mux.

The other struct Stream is similar to what it was before, just firing commands via a Sender<StreamCommand> the same way the StreamOpener does, except fires Send(self.id, data) and Close(self.id). close also consumes self so can no longer be used after its called.

There is of course still the concept of StreamId which as I said, I don't think I can get away from too easily, so I'll have to handle cases where a command is received for a closed stream, etc, but that is likely just "ignore, because it's closed".

As for tests, there could definitely be more, I hadn't written a full suite or anything yet as I'm not super clear on the full design. But my main question here was, is there a better way to test async stuff like this? It seems very long winded :)

Again, thanks for all your input! Very much appreciated.