-
Notifications
You must be signed in to change notification settings - Fork 6
Conversation
Thanks for opening this, it looks good. Can you add some tests please? I wonder if there's any value in the handshake when there's only one protocol we want to speak? We could just send the protocol and immediately start sending data, then the remote would close the stream if it doesn't support the protocol. |
That's urh, exactly what this does...unless I'm misunderstanding what you mean. Lazy select does this: sequenceDiagram
participant initiator
participant receiver
initiator->>receiver: /multistream/1.0.0 /bitswap/1.2.0 DATA
receiver->>initiator: /multistream/1.0.0 /bitswap/1.2.0
VS regular select: sequenceDiagram
participant initiator
participant receiver
initiator->>receiver: /multistream/1.0.0 /bitswap/1.2.0
receiver->>initiator: /multistream/1.0.0 /bitswap/1.2.0
initiator->>receiver: DATA
In lazy select the receiver will respond with In my fork I expose this to users via a |
Yeah, I just mean you have to explicitly select to be lazy - it looks like lazy is better since there are fewer round-trips involved, so why not default to that instead of doing the whole handshake dance. |
I'm just thinking out loud, not a requirement for merging this PR! |
Ah ok, because you have to know in advance that |
|
🎉 This PR is included in version 3.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Implements lazy select as seen in go-multistream (https://github.com/multiformats/go-multistream/blob/master/lazyClient.go) and rust libp2p (libp2p/rust-libp2p#1855)
Can be used to avoid a round trip when the dialer has only a single protocol to select from.