search

libp2p / specs

Technical specifications for the libp2p networking stack
https://libp2p.io
1.56k stars 273 forks source link

roadmap: rewrite the section about efficient handshakes #461

Closed marten-seemann closed 1 year ago

marten-seemann commented 2 years ago

Over the last couple of weeks, we've broken the early muxer negotiation into its own project (#446), and found an arguably nicer solution than proposed in the Protocol Select spec (#349). The change to move the security address into the multiaddr is already split out into a separate PR: #354.

With these two changes having been separated from Protocol Select, we save 2 RTTs during a TCP handshake, reducing the total latency to the bare minimum consumed by the components used (TCP: 1 RTT, security handshake: 1 RTT).

Implementing the rest of the Protocol Select spec now appears less pressing. The main additional benefits would be:

  1. Slightly shorter protocol names, since the protocol string would be wrapped in a protobuf instead of being prefixed with /multistream/1.0.0. This saving of ~10 bytes on a new stream is likely negligible in almost all situations.
  2. The ability to propose multiple protocols on a stream at the same time, instead of sequentially. In theory, this saves roundtrips, but in practice, one can just open multiple streams, one for each of the protocols (and then even send application data right away, if desired).
  3. The Protocol Select protobuf is as a basis for future extensions to the protocol, e.g. an extension that abbreviates protocol IDs with an integer, saving another ~10 bytes per stream.

(1) and (2) probably don't justify a high priority for Protocol Select. (3) is a valid point, but it would be preferable if the project was driving by a concrete use case that in itself would justify a high priority, rather than by the wish to create an extensible platform.

MarcoPolo commented 2 years ago

With the caveat that I'm not as familiar with protocol select as others. I agree with these points.

On point 3, couldn't users already define an integer that represents their protocol? Is there anything that says it has to be a human readable string?

Even if not, we could imagine a small change to multistream-select that allows them to pass multicodecs instead of protocol ids with a similar extensions protobuf. This could be /multistream/1.1.0 that gracefully falls back to the old method if it gets a /multistream/1.0.0 response (we'd have to support semver matching in multistream code).

marten-seemann commented 2 years ago

On point 3, couldn't users already define an integer that represents their protocol? Is there anything that says it has to be a human readable string?

They could, but without a place to coordinate the small values, this will probably run into interoperability issues rather quickly.

I’m not convinced this is a problem worth solving in the first place. Even if you have a crazily chatty protocol that opens a stream in every single packet you send, the overhead of multistream will still just be 20 bytes (compared to a Protobuf with a protocol name compression extension). For reference, 20 bytes is the overhead of IPv6 vs IPv4, or 1.5% of the packet payload.