We consider the base stream recovery first. Suppose client is
disrupted by a failure. Due to the tree structure, all clients
belonging to the subtree rooted
at this client are affected by the failure.
For the sake of
simplicity and to prevent the server from receiving a large number of
recovery requests, P2Cast only allows client
to contact the
server and perform recovery. The recovery process is identical to that of
a new client joining process except that here only the base stream is
required.
If the recovery attempt succeeds, the entire subtree is
recovered. If it fails, client
is rejected.
The children of client
will then contact the server and start the recovery process representing their
own subtrees. This process continues recursively.
In patch recovery, assume
client seeks a new patch server. It contacts the server and begins the
recursive recovery process identical to the server
selection process for a new client. Note that here only the clients that
arrived earlier than client
can be candidate patch servers.
If a patch server is successfully selected, the recovery
succeeds. Otherwise, client
has to be rejected, and the
clients that receive a patch or the base stream from client
will initiate the recovery
processes.
We present the signaling protocol used in P2Cast for clients to do the failure recovery in [11]. It consists of the network failure recovery protocol and the client departure recovery protocol, to deal with network failure and client departure, respectively. P2Cast clients constantly monitor the incoming traffic, both the base stream and patch stream. If the incoming traffic's quality degrades to a certain degree, the recovery process is triggered.
In Section 4 we will further investigate how to provide continuous playback even in the face of disruptions . Below we first present the Best Fit algorithm for the base tree construction and the patch server selection.