Implementing P2P Protocol

The fundamental elements of a structured P2P protocol consist in defining overall network structure, basic P2P operations, and fail-over mechanisms. The following table lists the tasks for implementing P2P protocol using our framework.

Task Remarks

define id space

Create corresponding Id and PeerId class, which define the distance function. Implement IdFactory and PeerIdFactory for creating identifier.

define topology Implement Peer interface with routing table information.

Determine the neighbor set and replication set.

peer initialization

Define externalized parameter name and type for environment configuration. Implement PeerFactory for creating peers.

join operation

Define message format of join request and response.

Implement associated action in joinImpl method and provide corresponding message handling procedures in handleMessage method. Change peer status after join operation finished.

lookup operation

Define message format of lookup request and response.

Implement route and localLookup method for determine routing path. Implement associated action in handleMessage method. Define request time out mechanism to prevent thread locking.

leave operation Define leave request format, carrying the information of topology correction.

stabilization

Managing periodical probing task using scheduleMessage method, scheduleTask method and CancellableTask class. Should be tolerated on every possible exception.

Table 5-1 – Task Descriptions of Developing P2P Protocols

Here we present two reference implementations that show how to implement a P2P protocol. First, we implement Ring Protocol, which is a simplified version of Chord. Like Chord, Ring Protocol maps both peers and resources in to an m-bits, ordered identifier circle. Each peer in Ring Protocol maintains the link to its predecessor, successor, and K random peers on the network.

The details of Ring Protocol are described in Appendix A.

RingIdFactory and RingPeerIdFactory are created using MD5/SHA-1 hash algorithm to produce corresponding RingId and RingPeerId. Because both type of identifier mapping to the same id space, RingPeerId is simply a subclass of the RingId class. A NeighborTable is introduced to manage the information of random neighbor table, which provides corresponding methods to refresh/retrieve the neighbors’ status.

Figure 5-1 – Relationships between Ring Protocol implementation and P2P Protocol Layer

In order to implement the join operation, we directly send out a join request to boot peer that search for the successor. When the lookup response is arrived, the joining peer can setup successor and predecessor. The random neighbor table can also be filled up according to the response message. While peer leaving, the predecessor is notified with successor correction information. The predecessor of leaving peer can then inform its new successor for further topology repairing.

The lookup operation is implemented in recursive way. The lookup request is forward to the closest neighbor until the successor of current peer is the possible handler for the certain id. The entire message flow involves lookup, route, localLookup, and handleMessage method. The localLookup method determines the closest neighbor with the information about current neighborhoods.

The route method compacts lookup request and routing information into a

RouteMessage, delegate the message transmission to communication manager. In handleMessage method, the lookup request is examined if the request is reach the correct destination. A lookup response will be sent to the requester, or a fail occurs while the request is time out.

The stabilization process is established by using scheduleTask methods.

A periodical message sending task is registered that send notification to its successor (if existing), and the successor reports its predecessor as response. Any inconsistency of ring topology will be correct during the request-response cycle.

The neighbor table updating task also utilizes message scheduling to ping each peer, the table entry is removed if exception occurred in message transmission.

The second protocol we used is the Viceroy DHT (details present in Appendix B) with topology stabilization enhanced. In the design of Viceroy DHT, both peers and resources are mapping to the interval of real numbers between the interval of [0, 1). The ViceroyId class represents a valid identifier and defines the distance function. A ViceroyPeer maintains additional peer status, such as level, seven out-bound links and all remote links. By defining the ViceroyIdFactory and ViceroyPeerFactory, developers can adapt their application to Viceroy DHT.

Figure 5-2 – Relationship between Viceroy DHT implementation and P2P Protocol Layer

Within the handleMessage method, each arriving message is delegated to individual processing functions. The join operation sends a JoinMessage out to find the correct joining position on the P2P network through the boot peer. Once the join operation fails to complete within the timeout, peer will start a new network and join as the first peer in this network. Peers send a LeaveMessage to its successor to notify the change of topology.

The route method implements the greedy routing algorithm via the localLookup method determing the next hop. The lookup operation involves two messages, LookupMessage and LookupAckMessage, to discover the handle peer and notify the result. By using the lookup operation, each Viceroy peer can then forward the LevelLookupMessage to complete the level lookup operation. If these two lookup operation do not finish before timeout, the lookup method will be interrupted and will throw an exception.

By using sheduleTask method, the periodical stabilization and probing tasks are implemented. If the peer status is incorrect, a series of actions for topology reconstruction will be triggered. For determing the correctness of inbound connections, a random remote peer will be chosen and a InboundValidateMessage will be sent to see if the remote peer still holds the link.