So, the multi-stream select protocol helps negotiate the Security(secio etc) & Multiplexing protocol(mplex etc) when we create a Connection over a raw Transport(Tcp etc).
However, once I have an upgraded connection to a peer & send a message over Stream X(Dht etc), who helps negotiate that stream with & find the handler on the remote peer ? Is it multi-stream select or Mplex/Yamux ? Basically, I am trying to understand the difference between the multi-stream-select protocol & the stream multiplexers in terms of their use-case.
Once we have a full fledged QUIC transport, does the QUIC handshake replace both the security & multiplexer negotiation & therefore the transport upgrader ? If yes, what role does multi-stream select play now & who takes care of the application level protocol(Dht, Identity etc) negotiation & handling ?
Multistream select handles the routing. The muxers are solely responsible for the management of internal streams on the connection, they don’t really care about the data/protocols being used. Anytime a new stream is created it will be run through multistream select in order to route the stream to the appropriate protocol handler. ‘Multistream’ is a bit of a misnomer, which is why the version 2 spec is trying to move to being called multiselect.
QUIC does have security and multiplexing built in. I’m not super familiar with the go code, but QUIC should in theory return a CapableConnection (no upgrader needed). multiselect (multistream) doesn’t really change. As soon as a new stream has been decrypted we immediately need to determine where to route that data to internally, so it’s handed off to multiselect to handle that routing.