[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 downSome form of synchronisation/route finding is required for sending data between arbitrary clientsPossibly some resource sniffing to differentiate between dumb clients and and more powerful super nodes to handle sync/sharing of node lists and maybe relay messagesClients without inbound support should hold open an outbound connection through which they can receive info of nodes to connect toIn 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 verifyCo-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 onlineDeal with a situation where 2 groups of nodes are physically disconnected (airgapped) and how to resync on reconnection of the groupsEtc etcI 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).
How to architect a P2P application
.net;architecture;client;p2p