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

feat(iroh): allow custom protocols with optional manual accept #2284

Closed
wants to merge 2 commits into from

Conversation

Frando
Copy link
Member

@Frando Frando commented May 13, 2024

Description

allow to manually accept connections and use custom protocols together with iroh core

see the included example which uses both a custom protocol and core iroh protocols.

Breaking Changes

Notes & open questions

Change checklist

  • Self-review.
  • Documentation updates if relevant.
  • Tests if relevant.
  • All breaking changes documented.

///
/// The default is [`AcceptMode::Auto`], which accepts all iroh protocol automatically and does
/// not allow to use custom protocols.
pub fn accept_mode(mut self, accept_mode: AcceptMode) -> Self {
Copy link
Contributor

Choose a reason for hiding this comment

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

I like passing the mode instead of having accept_manual().

///
/// This method will panic unless [`Builder::accept_mode`] was called with
/// [`AcceptMode::Manual`]
pub async fn accept_connection(&self) -> Option<Connecting> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need this at all? Can we just let people call accept on the endpoint?

https://docs.rs/iroh/latest/iroh/node/struct.Node.html#method.magic_endpoint

Copy link
Contributor

@rklaehn rklaehn left a comment

Choose a reason for hiding this comment

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

I like this approach better than some elaborate scheme with ALPN handlers. I think the complexity is acceptable for advanced use cases, and having some handler trait scheme will break down in many cases.

One thing I was wondering: you can already get the endpoint from the node. So what would happen if somebody would just grab an endpoint and then call accept on it, in the current code? Who wins? Is it round robin?

https://docs.rs/iroh/latest/iroh/node/struct.Node.html#method.magic_endpoint

@Frando Frando changed the title feat(iroh): allow to manually accept connections and use custom protocols together with iroh core feat(iroh): optionally accept connections manually and allow custom protocols May 13, 2024
@Frando Frando changed the title feat(iroh): optionally accept connections manually and allow custom protocols feat(iroh): allow custom protocols with optional manual accept May 13, 2024
@Frando Frando marked this pull request as draft May 13, 2024 11:23
@Frando Frando marked this pull request as draft May 13, 2024 11:23
@Frando
Copy link
Member Author

Frando commented May 13, 2024

One thing I was wondering: you can already get the endpoint from the node. So what would happen if somebody would just grab an endpoint and then call accept on it, in the current code? Who wins? Is it round robin?

Yes, it would be round-robin I think, same as quinn::Endpoint::accept.

You could already do this now by the way - the endpoint is already exposed (as you linked). You really shouldn't though because behavior would be unpredictable.

We could remove Node::accept in the PR, it would be identical to calling node.magic_endpoint().accept.

@rklaehn
Copy link
Contributor

rklaehn commented May 13, 2024

We could remove Node::accept in the PR, it would be identical to calling node.magic_endpoint().accept.

Yeah, with some of these APIs we really assume people know what they are doing, so we might as well let them do endpoint().accept(), then it becomes clearer that this is not some special stuff but just a good old incoming connection handler.

@Frando Frando mentioned this pull request Jun 11, 2024
4 tasks
@Frando
Copy link
Member Author

Frando commented Jun 11, 2024

Closing in favor of #2357

@Frando Frando closed this Jun 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants