search

gawen / WireHub

🌍 Decentralized, peer-to-peer and secure overlay networks
Apache License 2.0
498 stars 32 forks source link

Node names issues with large wirehub networks ? #3

Open johnr14 opened 5 years ago

johnr14 commented 5 years ago

Is there a possibility to have host names collisions if a hub becomes too large or if you connect to multiple hubs ?

I would suggest implementing GNU Name System or pave the way for future implementation ? That system seems to fit well with wirehub. The extention .wh could be reserved for addressing wirehub nodes.

I didn't look in the code, but how well does it scale ? I mean if there where to be a hub of more than 10k peers, would it keep connections open to all, or drop connections to unused hosts and reconnect on demand ?

Keep the good work, this is quite promising ! Also featured on phoronix.com

gawen commented 5 years ago

Hey @johnr14!

Is there a possibility to have host names collisions if a hub becomes too large or if you connect to multiple hubs ?

No. The mapping {hostname: pubkey} is statically stored in the configuration file. The configuration file will be rejected as invalid if two peers have the same host name.

The mapping {h: k} might also be resolved dynamically by ns objects, which forbid collisions too. A provided example built upon Keybase resolves namespace-d host names like <sub domain>.<keybase username>.keybase.wh.

I would suggest implementing GNU Name System or pave the way for future implementation ? That system seems to fit well with wirehub. The extention .wh could be reserved for addressing wirehub nodes.

I agree. nss-mdns looks like good material to implement it.

The current implementation inserts the host names in the file /etc/hosts if the environment variable EXPERIMENTAL_MODIFY_HOSTS is set.

I didn't look in the code, but how well does it scale ? I mean if there where to be a hub of more than 10k peers, would it keep connections open to all, or drop connections to unused hosts and reconnect on demand ?

I plan to have empirical data on this. Current efforts is to build a test bed and run benchmarks.

One peer keeps track of (1) DHT neighbors peers (cap to a certain amount) and (2) trusted peers with active application traffic. If it is behind a NAT, keep-alive packets are sent every ~25s to keep the UDP NAT mapping.