How to Architect a P2P Application in .NET

It's the easiest if you have a "mothership". Nowadays it doesn't have to be a single server, a SPOF, there are tons of cheap CDN (content delivery network) and cloud solutions.

Otherwise, borrow an idea from a software that is the most successful: bittorrent. Distributed hash tables (DHT) are simply beautiful. And if I'm not mistaken, you can piggyback your own software on the DHT network. DHT doesn't have to be bittorrent-specific, but there are millions of hosts in the bittorrent DHT network already, so why not use it for anything that you like? It's a huge free resource, the protocol is trivial, but there are already lots of libraries for it, it's like a gold mine.

Of course, DHT needs to be bootstrapped as well, but it's an already solved problem. You can collect a big list of known DHT hosts, or just probe randombly, it is so huge that either can work.

Bittorrent's DHT is simple: every torrent has a hash, and the DHT network stores a peer list for each hash. All you have to do is make up a fake, fixed hash for your needs and store that in the DHT. You can help bootstrapping if you create a few DHT nodes yourself that are close to your fixed hash, but it won't be necessary.

Well, it's actually not a completely free resource, if you participate in the DHT network, then you should also participate in the storage of other hashes, and other peers will use your peers as a service.

I'd be worried about the overhead in transmitting the whole list of peers each time. If you have N users, and during each 'discovery loop' each peer connects to the rest of the N peers and downloads a list of N peers, then the bandwidth dedicated to synchronizing the peers list grows like O(N^3)! By using some tricks to only transmit the peers that differ between the two you can get it down to O(N^2 log N) or O(N^2), but that's still pretty steep.

I heard some time ago of a synchronization model designed to avoid this problem. I don't remember the name so I'll call it "rumor mill synchronization."

Your client maintains three lists of peers:

• Known good peers.

• Recently changed peers. Each peer in this list is associated with a boolean 'added/removed' flag and a (local) time.

• Possibly changed peers. Each peer is this list also has the 'added/removed' flag, and also has an associated counter.

You also choose a length of time for changes to be considered 'new,' and a required number of 'votes' before you commit a change (K). I would suggest that the former is fixed (based on your testing) and the latter is user-configurable (so they can set how trusting they are of the network). Here is the procedure:

1. You start off with the addresses of a few peers that you think are good; these might be your servers' addresses preloaded into the app, or a set of peers that the user chooses. Query a number of them, asking to download their entire list of known good peers. Check them against each other so that an attacker will have a more difficult time adding malicious addresses. (This takes O(KN) bandwidth.)

   Assuming that you trust most of the peers you just talked to, you can add peers that are in a majority of their lists to your list of known good peers. Now we start the discovery loop.

2. Each cycle, you connect to a new peer from your known good list, and ask for their recently changed list. (If the network is relatively static, this list should be less than O(N).) If the network is large you can choose a random peer for this step, otherwise you should loop through the (randomly ordered) list. The goal is to talk to as many different peers as possible without biasing towards a certain subset.

   • If they don't respond, remove them from your known good list and add them to your recently changed list as 'removed' (overwriting an 'added' entry for that peer if it exists; don't forget to update the time too).

   • Otherwise, go through the received peers one by one.

     • If they're in your known good list, there's nothing to do.

     • If they're in your possible changes list, increment their counter; otherwise, add them to the list with their counter at one.

3. Check the list of possible changes to see if any have surpassed K votes; if so, add them to your list of recently changed, and add or remove them from your known good list as appropriate.

4. Check the list of recent changes to see if any changes on this list are 'stale,' i.e. older than your time threshold. If so, remove them.

5. Wait for a little, then go back to step 2. You should also repeat step 1 occasionally with random peers from your 'known good' list; treat this like step 2 but download their list of known good peers, not recently changed peers.

6. If you receive a connection from an unknown peer, treat this as in step 3, adding them to your recently changed and known good peers.

Note that this approach only works if the network is relatively static, otherwise the list of recent changes will encompass almost all the clients.

The implementation details might be a bit off (it was a long time ago that I read about this) but the idea is there; basically you ring up as many peers as you can and ask, 'hear about any new people?'