You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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
The text was updated successfully, but these errors were encountered:
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:
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
The text was updated successfully, but these errors were encountered: