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 . 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.