From 26774a2e31d125a1fc0e13bac884ed5cf8b50fb2 Mon Sep 17 00:00:00 2001 From: Max Inden Date: Tue, 27 Apr 2021 19:10:45 +0200 Subject: [PATCH] connections/simopen: Prefix fake protocol ID with a '/' In order to be backwards compatible with vanilla multistream-select the simultaneous open extension disguises its identifier as a protocol ID. According to the protocol negotiation specification protocol IDs can use any string, though by convention they are prefixed with a '/'. > Each protocol supported by a peer is identified using a unique string called a protocol id. While any string can be used, the conventional format is a path-like structure containing a short name and a version number, separated by / characters. For example: /mplex/1.0.0 identifies version 1.0.0 of the mplex stream multiplexing protocol. multistream-select itself has a protocol id of /multistream/1.0.0. https://github.com/libp2p/specs/tree/master/connections#protocol-negotiation This commit replace the `iamclient` identifier with `/libp2p/simultaneous-connect` to comply with the convention. --- connections/simopen.md | 54 +++++++++++++++++++++--------------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/connections/simopen.md b/connections/simopen.md index 8dbfe820a..587d4da42 100644 --- a/connections/simopen.md +++ b/connections/simopen.md @@ -32,21 +32,21 @@ acting as such. ## The Protocol -When a peer acting as the initiator enters protocol negotiation, it -sends the string `iamclient` as first protocol selector. If the other -peers is a responder or doesn't support the extension, then it -responds with `na` and protocol negotiation continues as normal. +When a peer acting as the initiator enters protocol negotiation, it sends the +string `/libp2p/simultaneous-connect` as first protocol selector. If the other +peers is a responder or doesn't support the extension, then it responds with +`na` and protocol negotiation continues as normal. If both peers believe they are the initiator, then they both send -`iamclient`. If this is the case, they enter an initiator selection -phase, where one of the peers is selected to act as the initiator. In -order to do so, they both generate a random 256-bit integer and send -it as response to the `iamclient` directive, prefixed with the -`select:` string. The integer is in big-endian format, encoded in base64. -The peer with the highest integer is selected to act -as the initator and sends an `initiator` message. The peer with the -lowest integer responds with `responder` message and both peers -transition to protocol negotiation with a distinct initiator. +`/libp2p/simultaneous-connect`. If this is the case, they enter an initiator +selection phase, where one of the peers is selected to act as the initiator. In +order to do so, they both generate a random 256-bit integer and send it as +response to the `/libp2p/simultaneous-connect` directive, prefixed with the +`select:` string. The integer is in big-endian format, encoded in base64. The +peer with the highest integer is selected to act as the initator and sends an +`initiator` message. The peer with the lowest integer responds with `responder` +message and both peers transition to protocol negotiation with a distinct +initiator. Note the importance of the prefix in the random integer, as it allows peers to match the selection token and ignore potentially pipelined @@ -56,8 +56,8 @@ The following schematic illustrates, for the case where A's integer is higher than B's integer: ``` -A ---> B: iamclient -B ---> A: iamclient +A ---> B: /libp2p/simultaneous-connect +B ---> A: /libp2p/simultaneous-connect A: generate random integer IA B: generate random integer IB A ---> B: select:{IA} @@ -73,17 +73,17 @@ indicative of a bug and both peers should abort the connection. ## Implementation Considerations -The protocol is simple to implement and is backwards compatible with -vanilla multistream-select. An important consideration is avoiding RTT -overhead in the common case of a single initiator. In this case, the -initiator pipelines the security protocol negotiation together with the -selection, sending `multistream,iamclient,secproto`. If the receiving -peer is a responder, then it replies with `multistream,na,secproto`, -negotiating the security protocol without any overhead. +The protocol is simple to implement and is backwards compatible with vanilla +multistream-select. An important consideration is avoiding RTT overhead in the +common case of a single initiator. In this case, the initiator pipelines the +security protocol negotiation together with the selection, sending +`multistream,/libp2p/simultaneous-connect,secproto`. If the receiving peer is a +responder, then it replies with `multistream,na,secproto`, negotiating the +security protocol without any overhead. If the peer is also a client, then it also sends -`multistream,iamclient,secproto`. On seeing the `iamclient` message, -both peers enter the initiator selection protocol and ignore the -`secproto` in the original packet. They can do so because the random -integer is prefixed with the `select:` string, allowing peers to match -the selection and ignore pipelined protocols. +`multistream,/libp2p/simultaneous-connect,secproto`. On seeing the +`/libp2p/simultaneous-connect` message, both peers enter the initiator selection +protocol and ignore the `secproto` in the original packet. They can do so +because the random integer is prefixed with the `select:` string, allowing peers +to match the selection and ignore pipelined protocols.