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

Per-connection protocol list #2693

Open
Stebalien opened this issue Jan 26, 2024 · 2 comments
Open

Per-connection protocol list #2693

Stebalien opened this issue Jan 26, 2024 · 2 comments
Labels
kind/enhancement A net-new feature or improvement to an existing feature

Comments

@Stebalien
Copy link
Member

Currently, identify operates at a peer level. However, this doesn't match up with reality. In practice, there are some protocols we only want to speak over connections with specific properties. Mostly with respect to transient connections, but we may end up having, e.g., network, interface, or even IP-based restrictions.

To solve this, we should:

  1. Run identify on all connections (we already do this).
  2. Associate the protocol list with the connection itself (see Proposal: a radically simpler Peerstore #2355).
  3. When creating a new stream, find the best connection that supports the given protocol.
  4. Whenever a connection is created/destroyed, emit a "protocol change" event describing the connection-specific protocols lost/gained.
  5. Provide a way to set a protocol handler with some set of constraints. Ideally an arbitrary function that's called on each new connection (during identify) and on a stream's connection before the handler is invoked. That shouldn't be that slow and it's really flexible.

Why? Bitswap, for example only wants non-transient connections and it doesn't even want to hear about peers with transient-only connections. Honestly, this applies to pretty much all of our protocols except the DHT and hole-punching protocols.

@sukunrt sukunrt added the kind/enhancement A net-new feature or improvement to an existing feature label Feb 22, 2024
@MarcoPolo
Copy link
Contributor

Is there any other property besides limited (née transient) connections that we care about today?

We currently do a happy eyeballs type thing for dialing a peer given a list of addresses, so for most cases we'll end up with a single connection.

Perhaps unrelated, but it might make sense to have peers be able to exchange which protocols they support over a limited connection.

@Stebalien
Copy link
Member Author

Nothing else that I can think of today. The only other reason to do this right now is to remove the protocol list from the peer store. See number two above. But this probably isn't a priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or improvement to an existing feature
Projects
None yet
Development

No branches or pull requests

3 participants