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

Support explicit addresses for dialing purposes send_request #5634

Open
nazar-pc opened this issue Oct 14, 2024 · 6 comments
Open

Support explicit addresses for dialing purposes send_request #5634

nazar-pc opened this issue Oct 14, 2024 · 6 comments

Comments

@nazar-pc
Copy link
Contributor

Right now send_request is dialing peer ID unconditionally. It is destined to fail if none of the behaviors know the address of the peer, as documented in the method itself.

However I am getting addresses in a response to another request and don't really want to persist it in any of the behaviors due to how annoying it is to write and manage them.

The simplest change that would work for me is to add an optional list of addresses to send_request, such that it can still succeed even if behaviors know nothing about this peer.

Not sure if this is the desired approach though. Initially I tried to initiate explicit dial right before calling send_request, but it didn't work because send_request's dial quickly fails and aborts the whole request, so I'll need to do more elaborate workaround, which is unfortunate and unnecessary.

@jxs
Copy link
Member

jxs commented Oct 15, 2024

Hi Nazar, you are referring to request_response::Behaviour::send_request right?
If so,

The simplest change that would work for me is to add an optional list of addresses to send_request, such that it can still succeed even if behaviors know nothing about this peer.

how would this work if request_response saves the peers into connected: HashMap<PeerId, SmallVec<[Connection; 2]>>,

@nazar-pc
Copy link
Contributor Author

Hi Nazar, you are referring to request_response::Behaviour::send_request right?

Yes, what I meant is that for this to include addresses:

self.pending_events.push_back(ToSwarm::Dial {
opts: DialOpts::peer_id(*peer).build(),
});

Like this:

self.pending_events.push_back(ToSwarm::Dial { 
    opts: DialOpts::peer_id(*peer).addresses(addresses).build(),
});

@jxs
Copy link
Member

jxs commented Oct 15, 2024

I am curious, where do those multiaddresses come from? And can't you dial them as soon as you get them?

@nazar-pc
Copy link
Contributor Author

Not sure what you mean by that exactly

@jxs
Copy link
Member

jxs commented Oct 16, 2024

Sorry Nazar, I misread, reformulated the question

@nazar-pc
Copy link
Contributor Author

I have a custom request-response protocol, then as described in #5626 if responder doesn't have the data they respond with addresses of closest peers via local Kademlia query. After this application aggregates results and if needed makes requests to some of the newly discovered peers, which swarm may not be aware of at all.

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

No branches or pull requests

2 participants