Multiselect Peer Id and Rounds

Implementers and Contributors
1

Hello again.

According to docs, the Multiselect protocol sends messages with protocols with a prepended PeerId (if I understand correctly, that is “Qm…”). Also, it has only one round, during which a protocol is selected.

But, after some implementation, I came across to that issue. So, now there are always two rounds and no peer ids are sent along with the protocol messages? Also, is there an updated version of docs yet?

Thanks.

2

Hi,

Unfortunately I haven’t had a chance to update the multiselect docs yet; I’ll up the priority on that since it’s causing confusion (not just with you, btw!).

It’s correct that in-practice, we don’t send the peer ids as part of protocol negotiation; in fact, I’m pretty sure if you were to try doing so, protocol negotiation would fail, since the inclusion of a peer id would cause the match logic to fail to find a match.

For exchanging peer ids, we use the identify protocol, which sends the peer id along with some useful addressing info.

Thanks for being patient while we get our docs in order.

1 Like
3

And what about two rounds, one for encryption protocol and the other for the protocol, which is going to be used while communicating? Is this schema correct and approved? So, our implementation should always process two rounds?

Thanks for answers!

4

Sorry for the delay :slight_smile:

There are actually three rounds for most initial libp2p connections:

  1. negotiate encryption
  2. negotiate stream multiplexer (could be mplex, yamux, etc)
  3. negotiate protocol for initial stream

It’s technically possible to only do the first two steps, in which case you’d have an open connection but no agreement on how to use it going forward. That might actually be useful in some limited cases, for example if you just want to add yourself to another peer’s routing tables. In most cases though, you’re looking at three round trips for setup.

We’re thinking of ways to make this much more efficient over here, if you want to join us: https://github.com/libp2p/specs/pull/95

5

Okay then, we are going to implement the current version /multistream-select/1.0.0 with three rounds, as the specification for the second version is not ready yet, and when it’s finished and merged, we update the protocol. Thank you!