Deprecate mplex #661
Deprecate mplex #661
Conversation
| [source](https://github.com/libp2p/rust-libp2p/blob/1c9b3ca355aecffa0bcf83d2495cd4cc1019425b/muxers/mplex/src/config.rs#L130) | ||
| - Block up to a certain amount of time, then reset the stream. | ||
| [source](https://github.com/libp2p/go-mplex/blob/ad9bfb922974b5875cc48c6e7492c4987c0cb94a/multiplex.go#L35-L37) | ||
| - Head of line blocking between streams |
There was a problem hiding this comment.
As long as you use TCP, there is no way to resolve this, right? So I think it's a good idea to note that only using QUIC will resolve this and yamux won't.
There was a problem hiding this comment.
You're right, you can only really solve head of line blocking of packets with QUIC. However, there's another head of line blocking issue that I'm referencing here, that Yamux can avoid due to stream flow control.
Say you have two streams, and one of them writes a 10 MB payload, and the other one then writes a 1 KB message.
In Yamux, you would send the first 256KB of the first stream, then the next 1KB of the other message. You would not send any more data on the first stream until you receive a window update message.
In mplex, you would try to send the full 10MB payload before you make any progress on the 1KB payload.
We've talked a lot about deprecated mplex for many reasons, but I don't think we've done a good job of documenting the reasons. A lot of the reasons are spread out in various issues, repos, and docs. My goal here is to summarize the reasoning and document why we want to deprecate mplex.
Related to #553