Open dominictarr opened 11 years ago
Yes yes yes :) Sounds like a really good way of doing this. Two important things for me are:
And on my long term wish-list:
Thanks again for all your work on this.
+10000 to a binary version of mux-demux. it would be a way better solution than msgpack
with the leveldb stuff this is a rising priority.
I have been looking at this today.
A lot has changed since I first wrote mux-deumx. the next version will be a complete rewrite.
here are the aims
I'm not sure what the QoS system should look like. pause/resume messages are probably not suitable because of latency. If the roundtrip takes too long, then the pipe can get congested before a pause gets through.
Instead, it will probably need to be more like tcp, which sends a certain amount, and then waits for an ACK. If it gets a NAK, it slows down. of course, since it's already over tcp, there won't be any dropped packets, but could measure latency and throughput, and then slow things down to allow that much through! this is also complicated because the multiplexed streams may want to use their own backpressure...
Probably, I'll just make a basic mux-demux and then QoS will plug into it. This will be useful for other things that need QoS, like post-message streams to webworkers and iframes.
okay, so @owenb needs a tighter protocol for socket-stream.
ideas:
I think that should get the protocol down pretty small, without changing the semantics.