Peer-to-Peer Protocol (P2PP)
Peer-to-Peer Protocol is an application layer peer-to-peer networking protocol that can be used to form and maintain an overlay network among participant nodes. It was defined in an Internet Draft submitted to the IETF by the P2PSIP Working Group. It provides mechanisms for nodes to join, leave, publish, or search for a resource-object in the overlay. It maintains information about nodes in a routing table. Because of potentially large content, a node's routing table only contains a subset of these nodes. If a node can't accomplish the request, it searches for one which can, by performing a nextHop() operation to a destination from the routing table (recursive-routing).
Basic functions of the protocol
- Resource publishing and look-up.
- P2P network maintenance.
- Heterogeneous connectivity.
- P2PP is a request–response protocol
Messages
A message is a P2PP protocol message that performs a certain function. It begins with a header followed by a sequence of type-length-value (TLV) objects. It can be either a request or a response. The response header contains a response code (see codes). They can not be combined in one message if an unreliable transport is used, due to limitations of UDP MTU.
Type-length-value objects
Peer-Info: a variable length TLV object, can include Uptime, Neighbour/resource-utilization, and NAT and firewall TLV objects, Peer-ID (variable): fixed-length output of the hash function negotiated at join, Additional Fields: their inclusion is left to the overlay implementer.
Additional information fields
Unhashed ID of this peer. This is only included in a DHT-based overlay.
Uptime (32 bits)
Resource-Info: Number of Neighbors (16 bits), CPU Utilization (8 bits), CPU Utilization of this peer on a scale of 1 to 100, bandwidth Utilization (8 bits), on a scale of 1 to 100, Peer Bandwidth (32 bits), kilo bits per second.
Response codes
(same as used in SIP)
1xx (Provisional), response data which provides an update on the progress of the request. These responses are only sent when request is sent over an unreliable transport in a recursive manner.
2xx (Success), response data which indicates that the request has been processed successfully in some sense.
3xx (Redirect), response data which indicates that the request should be redirected.
4xx (Client Failure), response data which indicates that the request has failed.
Request and response rules
Requests can not be combined. If the request was received over TCP, it SHOULD be forwarded over TCP. A peer issuing the request MAY request to receive a copy of the routing and neighbour tables of recipient. 480 Alternative Service response, demands resending request over TCP directly to the peer which generated this response. The request SHOULD be sent over TCP if its size exceeds UDP MTU. The response is matched to the appropriate request transaction by the transaction-ID.
Routing
Recursive routing : the request traverses the peers until it reaches the peer responsible for the resource-object if it exists; the peer issuing has no control over peers the request traverses.
Iterative routing : (Note: can be sent to multiple peers at the same time) The peer sends a request to another peer, which replies with the network address of the peer to which the request should be forwarded. Thus, the requesting peer has control over which peers a request is forwarded. UDP can send messages limited by MTU. TCP needs a connection establishing with each requested node (what takes time due to three-way handshake). It is preferred to use UDP for lookups (by sending only resource-ID), and TCP to send whole resource-object once, when node responsible for it has been found. TCP used to maintain routing tables causes increasing of necessary connections up to 320. If the request is sent over UDP and the response extends 1 MTU, the following is returned: 413 Message Too Large.