search

hyperboria / bugs

Peer-to-peer IPv6 networking, secure and near-zero-conf.
153 stars 17 forks source link

Anycast #3

Open ghost opened 9 years ago

ghost commented 9 years ago

Was https://github.com/cjdelisle/cjdns/issues/629

@mildred commented on 14 Aug 2014

Hi,

I'm opening this issue to discuss anycast. if and how it could be implemented. The main use case I'm thinking about is for advertising a P2P service. To bootstrap a P2P network that would run on top of cjdns, new nodes could find seeds by contacting a well-known anycast address.

A cjdns client could have multiple IP addresses. (this could be implemented using two cjdns instances chained together). Anycast address would be address which private key has been made public. Multiple nodes could register it on the cjdns network at the same time, and packets should arrive to one (or more) of these addresses.

@kpcyrd commented on 14 Aug 2014

I propose we aggree on special use addresses, that are discarded if they are accidentally generated.

Next, we can brute addresses in fc00:c457::/32 for dht peers. Those peers are for bootstrapping P2P networks and it's assumed they run a bootstrapping server. You can discover bootstrapping addresses by dumping the routing table.

@mildred commented on 14 Aug 2014

Do we really need special addresses? Why couldn't it work for any address?

@kpcyrd commented on 14 Aug 2014

It would work for any address, but it'd be easier to probe only those addresses that match a special pattern. They'd "announce" this torrent-tracker-like service using their address. It's not really anycast, but it'd allow to bootstrap P2P networks without any central systems.

I think public private keys would defeat the friend-to-friend trust system :)

I'm not sure what happens if multiple peers try to join the network using the same address. I doubt this works, but I've never tried it.

@cjdelisle commented on 21 Aug 2014

I'm not sure what happens if multiple peers try to join the network using the same address. I doubt this works, but I've never tried it.

I'm not 100% sure how this behaves (in the real world) but the desired behavior if a private key is installed on multiple machines is to have working anycast.

@Arceliar commented on 2 Sep 2014

I'm not 100% sure how this behaves (in the real world), but the desired behavior if a private key is installed on multiple machines is to not break the network.

Because the NodeStore identifies nodes based on IPv6, it would probably get horribly confused about who is a child of which node.

Suppose we're node A, we have node N with peer P in our store, and we discover a new node N' (same key/ipv6) with peer Q behind the same director as P. We can't distinguish N from N' (afaik), so we would be unable to correctly determine which N/N' to route through if we wanted to contact node P/Q.

@mildred commented on 2 Sep 2014

What is sure is that anycast nodes (nodes sharing the same key pair) can't participate in routing as they cannot be identified uniquely. A good practice for such nodes would be to restrict their peers to 1 only. Perhaps we should test this on the network...

@Arceliar commented on 5 Sep 2014

I think the anycast nodes would still be required to forward traffic (because of the DHT), so limiting them to 1 peer probably wouldn't fix the problem (but it may make the problem less severe).

I think the "right" solution would be to identify peers in the nodestore by something other than the key used to generate the IP address. Then you can have unique nodes, which happen to have the same IP, without breaking the node store. Maybe generate a second key, who'se only purpose is to distinghish between different anycast nodes.

mildred commented 9 years ago

I tried to set up two nodes using my own private key twice, and got the following results: When both nodes are online, I can ping the IP address with no problems. However, when a node from the two sharing the same key disconnects, it seems that I can't necessarily ping the IP address any more.

I believe that when the node disappears, the routing table doesn't contain the IP address anymore, The node still online is no longer reachable.

@cjdelisle Would you accept PR to make this use case work? Or do you think this would complexify the code too much for a marginal use case?

cjdelisle commented 9 years ago

If it can be made to work without butchering the codebase I'm ok with it, however I think it's complicated and multicast with a non-guaranteed-transport is difficult to make use of.