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

Handling of asymmetrical protocols #568

Closed
jm-clius opened this issue May 5, 2021 · 2 comments
Closed

Handling of asymmetrical protocols #568

jm-clius opened this issue May 5, 2021 · 2 comments
Labels
question Further information is requested

Comments

@jm-clius
Copy link
Contributor

jm-clius commented May 5, 2021

Following from @D4nte's question in libp2p, it appears libp2p best practice provisions for asymmetrical protocols where peers participating in the same protocol, but in different roles, may choose to differentiate between their roles by:

  1. Sending differentiated protocol IDs in the identify protocol list, or
  2. Excluding that protocol from the identify protocol list

See this comment for examples of the above

Is this something supported by nim-libp2p? In other words, is it possible to mount a protocol but choose not to include that in the identify protocol list?

@jm-clius jm-clius added the question Further information is requested label May 5, 2021
@dryajov
Copy link
Contributor

dryajov commented May 5, 2021

Is this something supported by nim-libp2p? In other words, is it possible to mount a protocol but choose not to include that in the identify protocol list?

Yes, both are supported. If a protocol shouldn't be advertised it is simply not mounted. I would use this two techniques in different situations however.

  • If a protocol has a pure client/server mode and the client shouldn't handle requests, then don't mount the protocol for the client
  • if a protocol a node can assume explicit modes of operation, as it is the case of the hop/stop parts in the relay, then I would use the second technique with different protocol strings

Fun fact, the changes suggested for relay v2 was what got originally proposed but rejected with the argument that "libp2p protocol strings aren't REST endpoints" 🤔 - glad to see it come full circle ;-)

@Menduist
Copy link
Contributor

Menduist commented Jan 4, 2022

Closing, feel free to re-open if needed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants