GPMS design

At the beginning, a peer joins the P2P network, and it maintains its neighborhood overlay via exchanging signaling messages with other peers until leaving P2P network. The lifecycle of peer represents the self-organization of overlay, and the finite state machine is driven via such messages to design for the lifecycle and behaviors. As Figure 3.6 illustrated, every peer should go through the states: start, wait, connect, maintain, and leave. Every current state should deal with the exact messages to avoid errors, which may crash the overlay.

Based on Figure 3.6, we give a normal example as in Figure 3.7, in which peer A plays the role in such example. Peer A is a newly joined peer in the P2P network, the joining process and querying process are described as the follows:

(1) First, because peer A knows neither any peer nor the overlay, it broadcasts Arrival Message to search the neighbors. The Arrival Message has the source address and routing trace.

Next header = 17 Extension length Routing type = 0 Segments left Version = 6 Traffic class Flow Label

Routing address [1]

Routing address [2]

...

Service ID Packet ID

Figure 3.5: The pseudo packet structure of GPMS.

(2) If an intermediate node receives an Arrival Message, it doesn't know such message and rebroadcasts to search some peers. When a peer receives an Arrival Message, it sends Welcome Message to peer A via the source address and routing trace, and it stops rebroadcasting. The Welcome Message has the destination address and routing trace.

(3) After receiving the Welcome Message, peer A unicasts a Join Message to select its

Figure 3.6: The normal message flow of GPMS.

Start

Figure 3.7: The finite state machine or lifecycle of a peer.

(4) After receiving a Join Accept Message, peer A becomes one member in P2P network and can use P2P service.

(5) Peer A creates a download task when querying a file sharing or live streaming. If Peer A needs multiple services, it creates multiple download tasks.

(6) For example, peer A may anycast a Query Message for a specific document.

(7) When receiving the Query Message, the peer creates an upload task for a query.

(8) Reply Message with the result of the query (i.e. yes or no) is sent to peer A. The query result is sent to user.

(9) Peer A unicasts Request Message for the available document depending on the query result.

(10) After receiving Response Message, peer A can download the queried document.

(11) The data is delivered upon the download task finished.

(12) Peer A leaves the P2P network via Leave Message. However, GPMS process isn't always

create upload task

Figure 3.8: The abnormal message flow of GPMS.

normal during the overlay construction or data distribution. Therefore, we give an abnormal example based on Figure 3.7, it is shown in Figure 3.8.

(13) When peer A chooses the neighbor, peer B, as its member, it sends a Join Message to peer B and expects to receive Join Accept Message. If Join Message or Join Accept Message is lost, the timeout of new joining process avoids the endless waiting and Join Message will be sent again.

(14) When receiving the Reply Message with NO as the query result, peer A gives up the query.

(15) After peer B leaves, peer A searches other uploaders if peer B is the only one uploader.

Therefore, the download and upload task must have the finite state machine to proceed the process.

As Figure 3.9 illustrated, GPMS creates a download task when a demand query arrives. The download task starts a timer when sending Query Message, and stops it upon receiving Reply Message. The file or stream is shared via Request Message depending on Reply Message, and a

Create

Figure 3.9: The finite state machine or lifecycle of download task.

timer is switched to perform the download process. When the download efficiency is low or the up-loader is gone, GPMS executes the peer reselection to search other appropriate up-loaders and waits for new a Reply Message. The download task is completed in a normal case, but it will be aborted when pending the reply, or cancelled when creating the query.

The download task should go through the states: create, pending, query, download, and finish. The upload task is operating in coordination with the download task. Therefore, the upload task is created when receiving a Reply Message and finished when receiving a Complete Message. As Figure 3.10 illustrated, the upload task should go through the states:

create, reply, upload, and finish. Since the upload process is coordinated with the download process, we don't describe the superfluous details here.

The relation between peers is many-to-many, and the relation between upload and download tasks is many-to-many, too. Therefore, the message flow of GPMS should combine the finite state machine of peer behaviors and upload/ download operations as Figure 3.11 illustrated. In the scenario, peer A and D are new joining peers, and they download the same video stream from peer B and C individually. During the period of live streaming delivery, peer C leaves, and peer D requests another member, i.e. peer B, for continuous streaming recovery.

Create

Figure 3.10: The finite state machine or lifecycle of upload task.

When peer A stops the streaming delivery, it sends a Complete Message to peer B to terminate the upload task. The upload/ download operations of file sharing application are the same as the ones of live streaming application.

When a peer moves or leaves, the overlay must be adjusted to avoid non-optimized end-to-end path and service interruption. We give an example to explain the overlay maintenance and recovery of GPMS as Figure 3.12 illustrated.

(1) As Figure 3.12 (a) illustrated, the path A^C^E is connected, and all nodes (A, B, C, D, E) broadcast a Hello Message to keep alive periodically on ad hoc protocols.

(2) As Figure 3.12 (b) illustrated, after peer C moves, the number of received Hello Messages from peer C to A decreases.

(3) When peer A considers that peer C moves far away, it sends a Maintain Message to all peers on the path (only peer E in the example).

Start Connect Connect Start

Figure 3.11: The message flow of GPMS.

(4) Peer C is still routable via node D, so both peers A and E update the path information. One path becomes two paths AC and AE. Peer E returns a Remain Message to avoid the interruption.

(5) If peer C cannot receive the Hello Message from peers A and E, it sends a Rejoin Message to peer A. If peer C receive data from peer A (via node D) before sending the Rejoin Message, the step will be ignored.

(6) Because peer A can route to peer C, it returns a Join Accept Message, and then peer C recovers the overlay. If step (5) is ignored, step (6) is ignored, too.

(7) When peer C receives Hello Message from peers E, it updates the path information because peer E has been known.

(8) Peer C sends a Maintain Message to peer A for the modification of path A^C, and so does peer C to peer E for path ACE.

Figure 3.12: The overlay maintenance and recovery of GPMS.

(9) Both peers A and E update the path information for path A^E^C and return a Remain Message to peer C for the modification.

(10) As Figure 3.12 (c) illustrated, peer E sends a Leave Message to all peers on the path before leaving the P2P network. Peers A and C update the path information for path AC as that illustrated in Figures 3.7 and 3.8.

GPMS can manage P2P overlay on MANET to provide file sharing or live streaming service due to the cross-layer scheme and FPRT design. Recall that in Figure 3.3, even if the peers move or leave, FPRT is updated via the path information and service cache to keep the continuous data. The algorithms of GPMS extend the P2P service, reduce the signaling overhead, and improve the recovery efficiency.