In this text we will focus on key elements one general purpose peer-to-peer system must have.
Main thing about peer-to-peer world is certainly communication channel between two hosts (peers), but to get to that point there must be some way those two can find each other.

Or in some cases peer X may be interesting to peer Y for connection establishment only if he can provide certain relevance to peer Y so there also must be option to publish some meta data about peer that others can lookup.

Peer X may want to refuse connection to peer Y for some reason so there also must be some sort of negotiation before tunnel is made.

Also Peer X and Peer Y may want to communicate in totally secure and private manner so data encryption and secure key exchange may come very handy in those cases.
So we need to provide these required abstract functionalities:

- NAT traversal for direct tunnel creation. Also is some small number of cases (~ 2 - 3%) nat traversal may fail so there must be relay service that will handle situations like this. Relay is most expensive part of system so designing good NAT traversal routing is key factor of quality peer-to-peer system.

- Instant messaging for negotiation and other control or short data messages

- Peer lookup by unique identification and/or published metadata

- Peer status notification for all other peers in relation  

Add-on functionalities most app will find use:

- Secure key exchange and data encryption

- Virtual user/networks/membership service that is closely aware of states of peers

  This system should give ability to permanently store metadata abut users, networks and other need abstract objects. This meta-data should be searchable and editable.
So let us now think what services we would need to provide to be able to support all this features.

- We need some service to which peers will report their presence and status. This service must be able provide peer with all necessary information it needs, so this service must be equipped with instant messaging system that is able to instantly notify peer about some changes on network relevant to him or to carry instant messages form one peer and deliver them instantly to other peer. Since this is place where information about active peers is available this system also should provide peer lookup by unique identifier or some searchable metadata. We will call this service "CHECKPOINT" in further text.
Technically communication between peer and CHECKPOINT should be UDP based and here is why:

- CHECKPOINT is expected to receive and send massive number of short messages to/from peers

- Each peer must be always accessible and able to receive notification, so with UDP this is easily achieved. When peer sends packet first time to CHECKPOINT thru his NAT device, CHECKPOINT may have around XXs lasting permission from NAT device to send some message back. If both peer and CHECKPOINT would be inactive for more than X sec NAT would close gate and notification messages arriving from CHECKPOINT would be thrown as unsolicited. So peer should send keep-alive each ~ X/2 sec in order of maintaining NAT table so CHECKPOINT can send message to peer anytime. Achieving this using TCP would be much less convenient and would make unnecessary data transfer. Also servers usually have limitation on number of concurrent TCP connections so that would also produce much faster performance degrade.   


- When two peers decide to establish direct communication channel NAT traversal operation should be invoked. NAT traversal is complex operation involving multiple steps where each new step depends on result of previous ones. So we introduce new service we will call "HANDSHAKE" in further texts. Handshake purpose is to synchronies NAT traversal operation steps between two peers. When they want to create tunnel CHECKPOINT will direct them to one of all available HANDSHAKE services to manage Nat traversal operation. HANDSHAKE procedure uses STUN technology to decide which methods are best to be applied in order of tunnel opening. So we need pair of STUN services to be available for HS. In some rear situations 2%, especially if one peer if behind some tight security corporate network tunnel opening will fail using NAT traversal in such cases we can turn to relaying that will always work. Relay is most expensive resource in system so it's crucial that HS does it procedure well so we minimize rely usage. To be able to guarantee 100% connectivity relay service must be part of system so it could handle 2% of tunnels Nat traversal was unable to create. Common standardized technology that was intended for relaying was TURN and you will find it in most or readings on internet and as RFC standard. Systems like quickP2P does not use TURN instead it uses raw relay mostly because resulting object of operation is common socket you will use as using socket in any other case also some networks deliberately detect and refuse TURN packets. TURN brings much overhead because of packet info data that is some times larger that actual "real" data so all for this reasons raw relay was picked by quickP2P engineers to handle 2% of tunnels that Nat traversal was unable to create.

So until now we described all components that would be needed for basic peer-to-peer NAT-traversal system : CHECKPOINT, HANDSAKE, STUN and RELAY service. Commonly every modern application requires storage of some permanent data like user profiles, user groups with thier metadata, device data etc... So if you would wnat to develop some application that has user accounts and does some sort of data exchange between users you would certanly need this. You could provide web services of your own on other hand imagine you have ability to store metadata permanetly and that system that does storage is more closly aware about availability of peers. That would certany be more convinient so we introduce INDEX servce. Index purphose is to do storage operations for permanent metadata that will be available no matter if peer is online or not.

Having all this we would be ready to create out-of-box peer-to-peer application with no need for additional web services.