You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Whilst working on #4789, I had an epiphany. So far, I was of the opinion that we will remove the UpgradeInfo trait together with the {In,Out}boundUpgrade traits.
Doing this always left a somewhat bad taste because the associated types on UpgradeInfo is what allows the entire SelectUpgrade machinery to work:
In other words, building a tree of ConnectionHandlers, getting their protocols and dispatching back to the correct handler only works because of the associated type of UpgradeInfo::Info.
To remove some of the complexity of ConnectionHandlers but still retaining this property, we can simply keep the UpgradeInfo trait and just remove the upgrade step. I made a PoC for this in 310311a. It works actually quite well. I've only adjusted the "ping" protocol here:
In essence, this now always received a Stream and the protocol is the one that was negotiated. If a user uses ReadyUpgrade, that will always be an instance of StreamProtocol.
The text was updated successfully, but these errors were encountered:
Whilst working on #4789, I had an epiphany. So far, I was of the opinion that we will remove the
UpgradeInfo
trait together with the{In,Out}boundUpgrade
traits.Doing this always left a somewhat bad taste because the associated types on
UpgradeInfo
is what allows the entireSelectUpgrade
machinery to work:rust-libp2p/core/src/upgrade/select.rs
Lines 43 to 68 in d05d836
In other words, building a tree of
ConnectionHandler
s, getting their protocols and dispatching back to the correct handler only works because of the associated type ofUpgradeInfo::Info
.To remove some of the complexity of
ConnectionHandler
s but still retaining this property, we can simply keep theUpgradeInfo
trait and just remove the upgrade step. I made a PoC for this in 310311a. It works actually quite well. I've only adjusted the "ping" protocol here:rust-libp2p/protocols/ping/src/handler.rs
Lines 330 to 366 in 310311a
In essence, this now always received a
Stream
and theprotocol
is the one that was negotiated. If a user usesReadyUpgrade
, that will always be an instance ofStreamProtocol
.The text was updated successfully, but these errors were encountered: