Patch server selection

A patch server serves the patch to a new client. Except for the first client in a session that receives the entire video (base stream) from the server, all other clients will miss the initial part of the video and will require a patch. A new client needs to select a patch server that can unicast the patch to it.

Since the server stores the entire video, it can always be a patch server as long as it has sufficient bandwidth. A peer client that arrives earlier and has sufficient bandwidth can also be a patch server. Fig. 2 illustrates an example. Assume the session starts at time 0. At time $t_1$, client 1 arrives. It joins the base tree and receives the base stream starting at point $t_1$. We assume that client 1 obtains the patch stream from the server directly. At time $t_2$, client 2 arrives. Client 2 joins the base tree and receives the base stream from the base tree. Since client 1 has already cached part of the patch required by client 2 at time $t_2$ (the shaded part is the content already cached in client 1); and client 1 continues to receive its own patch and base stream, it can serve as the patch server for client 2.

The patch server selection process for a new client is identical to a new client's base tree joining process. In fact, all existing clients in a session arrive earlier than the new client, and thus can be its patch server if there is sufficient bandwidth. In Section 5, however, we will consider patch recovery, where the arrival time of a candidate patch server needs to be compared with the arrival time of the requesting client.

Figure 2: The earlier arriving client (client 1) is eligible to be the patch server of the later arriving client (client 2) in P2Cast.