rendezvous-server icon indicating copy to clipboard operation
rendezvous-server copied to clipboard

src/transport.rs: Consider using `V1Lazy`

Open mxinden opened this issue 4 years ago • 2 comments

Unsolicited feedback. Feel free to ignore.

Given that you are supporting a single authentication protocol only, you might want to consider using Version::V1Lazy instead of V1, potentially saving you one round trip. See V1Lazy docs for details.

https://github.com/comit-network/rendezvous-server/blob/b87efa36121a2a4c917d98cfd30916891f4419d2/src/transport.rs#L11-L39

mxinden avatar Jul 05 '21 09:07 mxinden

Given that you are supporting a single authentication protocol only, you might want to consider using Version::V1Lazy instead of V1, potentially saving you one round trip. See V1Lazy docs for details.

In the docs it says V1Lazy only applies to the dialer. Since the rendezvous point never dials anyone, I don't think it is needed here?

This strategy is only applicable for the node with the role of “dialer” in the negotiation and only if the dialer supports just a single application protocol. In that case the dialer immedidately “settles” on that protocol, buffering the negotiation messages to be sent with the first round of application protocol data (or an attempt is made to read from the Negotiated I/O stream).

rishflab avatar Jul 08 '21 04:07 rishflab

In the docs it says V1Lazy only applies to the dialer. Since the rendezvous point never dials anyone, I don't think it is needed here?

My bad. Yes you are right. I didn't think about this being a rendezvous-only binary.

You could consider setting Swarm::substream_upgrade_protocol_override to Version::V1Lazy to speed up e.g. libp2p-ping substream negotiations, might not be worth the performance gain in the case of libp2p-ping though. Also obviously not worth it in case you decide to remote libp2p-ping.

mxinden avatar Jul 08 '21 09:07 mxinden