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

Divulge non-local addresses #246

Closed
jbenet opened this issue Oct 31, 2014 · 4 comments
Closed

Divulge non-local addresses #246

jbenet opened this issue Oct 31, 2014 · 4 comments
Milestone

Comments

@jbenet
Copy link
Member

jbenet commented Oct 31, 2014

Right now we can end up connecting to ourselves (which rightly triggers a panic currently) because we currently advertise our own listening address (e.g. /ip4/0.0.0.0/tcp/4001). This is the reverse of the previous dht-addr-listing problem (listing addrs we've dialed from). What we need is to generate a list of possible addresses, both by inspecting our machine's interfaces, and by asking other peers what our external address seems to be (ICE-style).

I propose:

  • in the handshake we inform each other what address we see them coming from.
  • use this to populate list of "potential" local addresses
  • transmit those when asked (node id / handshake)
  • transmit those to our directly connected peers.

i'm not sure we want to store everyone's addresses along with provider records. While this does certainly speed up lookups (avoiding additional lookup for the node), it will be pretty space inefficient to include it as part of the record. We should relax this constraint, making provider-records (in the dht) merely store identities (node.IDs) of providers. Nodes who store a particular provider record should also store the providers' addresses and return those when sending provider info. (sounds the same, but note that since it's not stored in the record, there's space savings when a node has the same node in multiple provider records)


https://gist.github.com/jbenet/9b6c1ca8bb2c76443dea

03:57 <jbenet> ah!!! found the problem
03:57 <jbenet> we don't _mean_ to connect to ourselves.
03:57 <jbenet> we're just at the same addr: [Peer Qmcrp1uV8Na1] dialing [Peer Qmb1PXdLf9fc] /ip4/0.0.0.0/tcp/4001 dial.go:35
03:57 <jbenet> we need to figure out our real ip addrs before listing them.
03:57 <jbenet> ah the reverse of the other address problem in the dht.
03:58 <jbenet> we need a "what's my IP" / stun type of thing
@jbenet
Copy link
Member Author

jbenet commented Nov 3, 2014

This will be improved in #253

@jbenet
Copy link
Member Author

jbenet commented Nov 3, 2014

For future ref:

@whyrusleeping whyrusleeping added this to the α milestone Nov 5, 2014
@whyrusleeping
Copy link
Member

Is this resolved? 253 has been merged

@whyrusleeping
Copy link
Member

@jbenet i think this one can be closed, we do this now

@aschmahmann aschmahmann mentioned this issue Dec 1, 2021
80 tasks
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