How to architect a P2P application
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 pretty open-ended for SO 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).
No comments:
Post a Comment