The “medium” over which a libp2p protocol transpires is a bi-directional binary stream with the following properties:
- Data is read in the same order as it was written
Does this mean that libp2p protocols all suffer from head-of-line blocking, like TCP, even if TCP isn’t the underlying transport?
This isn’t necessarily a dealbreaker for circulex, but circulex is oriented around messages, rather than streams, and some of those messages are more important and urgent than others, so if they’ve been received, it would be a shame to delay processing them until earlier less important messages have also been received.
I like what I’ve seen written about SCTP, including its message-oriented nature, and its avoidance of head-of-line blocking, so it’s currently specified in the unfinished draft circulex specification. Has SCTP (or any of its design features) been considered by the libp2p community?