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

identify: Update local node listen addresses #191

Closed
1 task done
Tracked by #140
lexnv opened this issue Jul 31, 2024 · 1 comment · Fixed by #212
Closed
1 task done
Tracked by #140

identify: Update local node listen addresses #191

lexnv opened this issue Jul 31, 2024 · 1 comment · Fixed by #212
Assignees
Labels
enhancement New feature or request

Comments

@lexnv
Copy link
Collaborator

lexnv commented Jul 31, 2024

The identify protocol provides as response a listen_addresses field.
The remote peer uses this field to insert self reported addresses into the Kademlia DHT.

Substrate makes use of the listen addresses here.

The problem is that the identify protocol starts with a static set of addresses, which may expire or become invalid:

listen_addrs: self
.listen_addresses
.iter()
.map(|address| address.to_vec())
.collect::<Vec<_>>(),

This might be one of the reasons why we've seen low connectivity with peers over the long term (~90 days).

The Identify protocol can be extended to receive verified addresses for healthier listen addresses.
For the Substrate perspective, when we deem a "remote address" as valid (after 2 encounters), that address needs to be reported back to the Identify protocol.
Libp2p already has a similar mechanism of discovery via the ExternalAddressDiscovered and confirming addresses.

Tasks

  1. enhancement
    lexnv
@dmitry-markin
Copy link
Collaborator

Yeah, it shouldn't be like this. With libp2p backend Identify "listen addresses" field actually contains discovered external addresses, no matter when they were discovered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants