-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Rework network/src/protocol.rs to use libp2p's multiplexing #1517
Comments
Tentatively turned this into a "meta" issue, since it sounds like it could be broken-up into smaller issues, and made an attempt a formulating one at #1541. On the broader issue, I just wanted to add that having protocol use a "HTTP1-like scheme" might be a good thing, in the sense that it just handles one event from libp2p at the time(and communicates back one message at a time) and perhaps doesn't need to be aware of the underlying streaming structure. On the other hand, it sounds like the way to take advantage of of libp2p's "HTTP3-like" capabilities is to move logic out of protocol entirely, the peer timeout being perhaps a good example. |
Also, I think it's important to be clear about the difference between the "network" and "network-libp2p" crate, and when @tomaka you mentioned the "Substrate-specific protocol" I assume you mean "network-libp2p" as opposed to For clarity, I meant:
|
There's no plan in changing that. This is orthogonal to what this issue is about. |
We can continue talking about this change in details, but I find that a bit ridiculous because it's not a very large change in the end. I'm just waiting for #1340 to finally be merged in order to do it. |
Although this change would probably remove half of #1340 unfortunately, as the channel would be handled by libp2p. |
There needs to be a transition period so that we don't break the networking entirely. My plan for this is to introduce a new protocol name. If we notice that the remote accepts the version with |
Behaviour right nowWhen two nodes connect, the dialing side opens a Substrate substream. Once done, we report at the API layer that we are connected. The substream is then used by both sides for all communications. If the substream or the connection is closed by either side, we report to the API layer that we are disconnected. If either node starts denying the other node, it does so by closing the unique substream. If the node is again accepting the other node, it reopens the substream. New behaviour (backwards-compatible)When two nodes connect, the dialing side opens a substream. Once done, we report at the API layer that we are connected. If it uses the old protocol name, then operate as previously. If it uses the new protocol name, then both sides are now free to open as many substreams as they want. If we ever fail to open a substream, we report to the API layer that we are disconnected and immediately shut down all the other substreams without taking their response into account (this is to ensure state consistency, otherwise could report messages after we've reported disconnection). If a node starts denying the other node, it does so by refusing new incoming substreams. If a node is again accepting the other node again, it forcefully opens a substream. This last sentence is a bit of a hack, but is necessary before #1702 is done. |
Right now what happens on the networking layer is:
network
crate. The network crate can send back messages using a method on theNetworkService
.The ping, identify and Kademlia protocols of libp2p use an HTTP3-like scheme, where each request opens a new substream. More precisely: we open a substream, send the request, optionally wait the response, then close the substream.
However, the Substrate-specific protocol is an HTTP1-like scheme, where all the requests get pipelined into a single substream.
Moving this to a more HTTP3-like scheme would simplify the code, as libp2p's multiplexing would handle many details (like timeouts, or interleaving messages).
The text was updated successfully, but these errors were encountered: