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>
