In this text we will focus on key elements one general purpose peer-to-peer system must have.
Mhe 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. That only if he can provide certain relevance to peer Y so there also must be an option to publish some meta-data about peer that others can look up.

Peer X may want to refuse connection to peer Y for some reason so there also must be some sort of negotiation before the 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. The relay is most expensive part of the system so designing good NAT traversal routing is the key factor of the 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 a use:

- Secure key exchange and data encryption

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

  This system should give the ability to permanently store meta-data about 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 these features.

- We need some service to which peers will report their presence and status. This service must be able to provide peer with all necessary information it needs. This service must be equipped with an instant messaging system that is able to instantly notify peer about some changes on network relevant to him or to carry instant messages from one peer and deliver them instantly to another peer. Since this is the place where information about active peers is available, this system also should provide peer lookup by the unique identifier or some searchable meta-data. 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 a 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 the peer sends packet first time to CHECKPOINT trough 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 a message to peer anytime. Achieving this using TCP would be much less convenient and would make unnecessary data transfer. Also, servers usually have a limitation on a 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 a complex operation involving many steps where each new step depends on the result of previous ones. So we introduce new service that we will call "HANDSHAKE" in further texts. Handshake purpose is to synchronize 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 a pair of STUN services to be available for HS. In some rear situations 2%, especially if one peer is 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. The relay is a most expensive resource in the system so it's crucial that HS does it procedure well so we minimize relay usage. To be able to guarantee 100% connectivity relay service must be a part of the system so it could handle 2% of tunnels that 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 the internet and as RFC standard. Systems like quickP2P do not use TURN. Instead it uses raw relay. It is because the resulting object of operation is common socket that you will use as using a 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 sometimes larger than actual "real" data. 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 the basic peer-to-peer NAT-traversal system: CHECKPOINT, HANDSHAKE, STUN and RELAY service. Commonly every modern application requires storage of some permanent data like user profiles, user groups with their meta-data, device data etc... So if you would want to develop some application that has user accounts and does some sort of data exchange between users, you would certainly need this. You could provide web services of your own. On other hand, imagine you have the ability to store meta-data permanently and the system that does storage is more closely aware of the availability of peers. That would certainly be more convenient so we introduce INDEX service. Index purpose is to do storage operations for permanent meta-data that will be available no matter if the peer is online or not.

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