feat: add lazy select

[alanshaw]

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.

[achingbrain]

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.

[alanshaw]

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

Loading

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

Loading

In lazy select the receiver will respond with na if not supported and then the stream will be closed by the initiator. The receiver may receive some data but 🤷‍♂️.

In my fork I expose this to users via a lazy option so you can do libp2p.dialProtocol('/bitswap', ma, { lazy: true }) but things have changed around a bit so I think the upgrader would do that logic now...

https://github.com/web3-storage/js-libp2p-multistream-select/blob/15ac7f3f632df9dadf71b975857cc18bc9dc57a6/src/index.ts#L43-L45

[achingbrain]

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.

[achingbrain]

I'm just thinking out loud, not a requirement for merging this PR!

[alanshaw]

Ah ok, because you have to know in advance that DATA doesn't begin with a valid multistream message like /bitswap/2.0.0. In the case where the receiver responds na, DATA could be misconstrued as a continuation of the multistream negotiation.

[alanshaw]

The remaining theoretical pitfall whereby application data gets misinterpreted as another protocol proposal by a listener remains, however unlikely.
libp2p/rust-libp2p#1855

[github-actions]

🎉 This PR is included in version 3.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀