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

sim open #2099

Closed
wants to merge 8 commits into from
Closed

sim open #2099

wants to merge 8 commits into from

Conversation

dvc94ch
Copy link
Contributor

@dvc94ch dvc94ch commented Jun 9, 2021

This fixes the failing test case in #2066

mxinden and others added 8 commits May 5, 2021 16:46
From the multistream-select 1.0 simultaneous open protocol extension
specification:

> 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.

See libp2p/specs#196 for details.

This commit implements the above specification, available via
`Version::V1SimOpen`.
@@ -238,7 +290,7 @@ impl<R> MessageIO<R> {
MessageReader { inner: self.inner.into_reader() }
}

/// Drops the [`MessageIO`] resource, yielding the underlying I/O stream.
/// Draops the [`MessageIO`] resource, yielding the underlying I/O stream.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops

@dvc94ch
Copy link
Contributor Author

dvc94ch commented Jun 23, 2021

@mxinden do you have a timeline for when you expect this feature to be merged?

@mxinden
Copy link
Member

mxinden commented Jun 24, 2021

@mxinden do you have a timeline for when you expect this feature to be merged?

I am not sure what you are referring to with "this feature". In case you are referring to the solution suggested in this pull request: I don't think we should merge it as (a) it is adding more complexity in general and (b) it is polluting the function signature for stream upgrades which will never need this functionality. In case you are referring to support for multistream-select simultaneous open in general: I don't know, especially as it depends on so many other efforts (e.g. circuit relay v2, direct connection upgrade through relay, ...).

See #2066 (comment) for details.

@dvc94ch dvc94ch closed this Jul 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants