8

[Moved here at the suggestion of SO users (10k SO+)]

I'd like to develop a peer-to-peer application. While I have a lot of experience in LOB apps, I'm new to the P2P arena.

I've got a rough idea of how things should work but need some more details to fill out my understanding.

What I know (believe) I need to do:

  • A significant proportion of clients need to enable inbound connections (ala uPnP/NAT rules)
  • Nodes should share other known nodes to provide resiliency if any particular node goes down
  • Some form of synchronisation/route finding is required for sending data between arbitrary clients
  • Possibly some resource sniffing to differentiate between "dumb" clients and and more powerful "super nodes" to handle sync/sharing of node lists and maybe relay messages
  • Clients without inbound support should hold open an outbound connection through which they can receive info of nodes to connect to

In short, I'm hoping to offer (at first) a chat/messenger service which doesn't rely on a connection to any particular central server. While I imagine I'll need to supply a number of centralised "supernodes" to get things started (or after significant upgrades), these should be optional once a functional P2P network has been established.

I can see a slew of problems and don't know how to address them. Mainly how to...

  • Authenticate users to other nodes without a central authority to verify
  • Co-ordinate which nodes know about which other nodes (min-max number/by latency/???)
  • Allow a given user to determine if another user (or node) is online
  • Deal with a situation where 2 groups of nodes are physically disconnected (airgapped) and how to resync on reconnection of the groups
  • Etc etc

I know this is a pretty open-ended question, so while high-level design patterns would be appreciated, what I'm really looking for is a decent guide to how others have handled these problems (and the ones I haven't considered yet).

Community
  • 1
Basic
  • 234
  • 2
  • 10
  • Is the web-application tag intentional? If so, what, in your mind, constitutes a p2p *web app*? – svidgen Aug 13 '13 at 23:45
  • @svidgen: It's not unreasonable, that the swarm could be a clustered web host. – Steven Evers Aug 14 '13 at 01:29
  • @svidgen Good catch, I was going to make the question a little bigger but changed my mind so I should remove that tag. Thanks – Basic Aug 14 '13 at 10:09
  • 1
    Take a look at BitTorrent and DHT and the principles and technologies they use. With tens of years of experience, both have tackled most of the problems you'd like to address. This really is too broad. – CodeCaster Aug 14 '13 at 10:23
  • @CodeCaster I'm starting to think you're stalking me ;) – Basic Aug 14 '13 at 11:19
  • @Basic whenever I'm waiting for my machine, I browse SO. I recently found programmers.se. ;-) – CodeCaster Aug 14 '13 at 11:28

1 Answers1

6
  1. Designing a protocol and building an application on it is a huge project. Take as much as possible from existing protocols.
  2. Most relevant protocols (beyond skype, which is a peer-to-peer messaging, but it's protocol is secret) are those that provide resources over peer-to-peer network which means especially the part of TOR providing the .onion domain and freenet.
  3. Most things you list in "need to do" are handled by freenet and many of them in TOR too.
  4. Identity of users has to be cryptographic. Associating real-word identities with the cryptographic keys requires some form of web-of-trust like in PGP/GPG.
  5. Important reason for using peer-to-peer messaging is privacy. Off-the-record messaging is basically mandatory (specifies how the authentication must work).
  6. Presence has to be off-the-record too, basically a special kind of message.
  7. Disconnects are no special problem beyond general fault tolerance. For each side it looks like the other nodes failing and joining again.
  8. You may want to use the protocol as signalling for some streaming protocol, probably sRTP. That protocol handles NAT traversal, so you can clone the mechanism for the p2p protocol itself.
Jan Hudec
  • 18,250
  • 1
  • 39
  • 62