* Remove `id` field from `Unregister` message
All connections in libp2p are authenticated. As such, we don't have
to include the PeerId in the `Unregister` message. We only allow
peers to unregister themselves and therefore, this `id` would always
be equal to the one we are learn from the authentication layer. Having
to compare those and ensure they are equal is an unnecessary error
path.
To be backwards-compatible with existing deployments of the rendezvous
protocol, the field is only commented out. If this record ever gets
extended, the next field should use id `3`.
* Clarify absence of `UNREGISTER` response
Specifies the Kademlia Distributed Hash Table (DHT) subsystem in libp2p.
Co-authored-by: John Hiesey <john@hiesey.com>
Co-authored-by: Steven Allen <steven@stebalien.com>
Co-authored-by: Max Inden <mail@max-inden.de>
* Specify the Circuit Relay v2 protocol.
* Move README.md specifying the Circuit Relay v1 protocol to circuit-v1.md
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: raulk <raul@protocol.ai>
To be meaningful, TTL has to be a positive integer hence the use of
an signed integer does not bring any value and only introduces
unnecessary error handling.
Limiting the number of responses makes only sense if it is a positive
integer.
Extend connections specification with a document describing the long
term vision of hole punching in libp2p across transport protocols,
platforms and implementations.
Co-authored-by: Steve Loeppky <stvn@loeppky.com>
Co-authored-by: Marcin Rataj <lidel@lidel.org>
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
* identify: Document identify behavior for asymetrical protocols
> Note on asymmetrical protocols: Assume an asymmetrical
request-response style protocol `foo` where some clients only support
initiating requests while some servers (only) support responding to
requests. To prevent clients from initiating requests to other clients,
which given them being clients they fail to respond, clients should not
list `foo` in their `protocols` list.
Question emerged in https://github.com/libp2p/specs/issues/324.
* identify/README: Reword to inbound substreams
* identify: Document identify behavior for asymetrical protocols
> Note on asymmetrical protocols: Assume an asymmetrical
request-response style protocol `foo` where some clients only support
initiating requests while some servers (only) support responding to
requests. To prevent clients from initiating requests to other clients,
which given them being clients they fail to respond, clients should not
list `foo` in their `protocols` list.
Question emerged in https://github.com/libp2p/specs/issues/324.
* identify/README: Reword to inbound substreams
* identify: Document identify behavior for asymetrical protocols
> Note on asymmetrical protocols: Assume an asymmetrical
request-response style protocol `foo` where some clients only support
initiating requests while some servers (only) support responding to
requests. To prevent clients from initiating requests to other clients,
which given them being clients they fail to respond, clients should not
list `foo` in their `protocols` list.
Question emerged in https://github.com/libp2p/specs/issues/324.
* identify/README: Reword to inbound substreams
> In order to support direct connections through NATs with hole punching, we
> need to account for simultaneous open. In such cases, there is no single
> initiator and responder, but instead both peers act as initiators. This breaks
> protocol negotiation in multistream-select, which assumes a single initator.
>
> This draft proposes a simple extension to the multistream protocol negotiation
> in order to select a single initator when both peers are acting as such.
Co-authored-by: Jacob Heun <jacobheun@gmail.com>
Co-authored-by: bigs <cole@protocol.ai>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Steven Allen <steven@stebalien.com>
This commit adds recommendations to the rendezvous spec regarding how a rendezvous
point should be configured. These were based on the discussions on the go
implementation PR and current code.
Co-authored-by: Max Inden <mail@max-inden.de>
