Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

connections/simopen: Prefix fake protocol ID with a '/' #321

Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 27 additions & 27 deletions connections/simopen.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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}
Expand All @@ -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.