Peer-to-Peer Protocol (P2PP)

Application-layer protocol that can be used to form and maintain an overlay among participant nodes. Provides mechanisms for nodes to join, leave, publish, or search for a resource-object in the overlay. Maintaining information about nodes in routing table. Because of potentially large content, node's routing table only contains a subset of these nodes. If node can't accomplish the request, it searches for one, who can by performing nextHop() operation to a destination from routing table (recursive-routing).

Basic functions of the protocol are

* Resource publishing and lookup.
* 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. Can be either request or a response. The response header contains a response code (see codes). They cannot 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 (Request Failure), response data which indicates that the request has failed.

Request / Response Rules

Requests cannot 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 : (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; the requesting peer has control over peers the 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 request sent over UDP and response extends MTU, 413 Message Too Large, returned.

Sources

[http://www.p2psip.org/drafts/draft-baset-p2psip-p2pcommon-01.html]
[http://www.tools.ietf.org/html/draft-baset-p2psip-p2pp-01]
[http://www.voip-info.org/wiki-SIP+response+codes]