-
Notifications
You must be signed in to change notification settings - Fork 273
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
The relay protocol could be split in two #105
Comments
I agree. We wouldn't even need a CAN_HOP in this case. Thoughts @vyzo? |
I think this was discussed during the spec development and rejected as an idea? |
Well, we can always support both so we don't need to break anything. However, as you said, this may be a pain to implement/deploy. Really, my motivation is that this would allow us to split the implementation into a separate transport and relay. |
Based on discussions in libp2p/go-libp2p-circuit#67, I think the core problem is that the relay protocol doesn't model allocations. So when a client connects to a relay, the relay has no idea if this is a NAT'ted client wishing to allocate a slot in the relay, or if it's a node wanting to connect to establish a channel to a relayed peer. We can draw inspiration from the TURN spec (RFC5766), which models "allocations" explicitly. I think the hop/stop separation doesn't get to the root of the issue. IMO a more correct design would be:
See libp2p/go-libp2p-circuit#67 (review) for related discussion. |
Has any thought been given to how a relay should respond if it doesn't want to relay data to the requested peer? (For example, no allocation has been (or will be) made to the requested peer, due to whatever policies the relay uses.)
|
This has been incorporated in the circuit relay v2 protocol (#325), thus I am closing here. Thanks for raising it @tomaka. In my eyes this is a great improvement to the v1 specification.
This is handled in the circuit relay v2 protocol via Reservations.
For now this is modeled via the |
This is mostly a suggestion/idea.
The relay protocol currently has two modes: HOP and STOP.
Instead of negotiating
/libp2p/relay/circuit/0.1.0
then requesting a mode, it could be a good idea to have two different protocols instead. For example/libp2p/relay/circuit/0.1.0/hop
and/libp2p/relay/circuit/0.1.0/stop
.The advantage is that most nodes would accept acting as a destination, but not all accept relaying. By splitting them we would know earlier on whether a node accepts relaying.
The text was updated successfully, but these errors were encountered: