D ATA P ROTOCOL

In peer-to-peer network, how to decide the data you want to download and how to manage the data you downloaded are important. As a result, we attempt to design a data protocol that fits our system. [Figure 3.10] shows the flow chart of our data protocol. Next, we describe this protocol at root side and server side.

)

Figure 3-10 The data protocol

Root:

The data protocol in root is intuitive. The job of root is keeping encoding the data and sending the encoded data to its downstream nodes. At first, we need to keep obtaining original frame from the webcam or file. And we save these frames into the queue. Next, there is a thread keeping encoding the original frame from the queue (A) by VCM9 codec. After encoding a frame, it puts the encoded frame into queue (B). When the queue (B) accumulates enough size for channel coding, it will send a notification to channel encoder. Finally, we have a sending buffer storing the encoded data. The size of a sending buffer represents the maximal number of section you can keep. This buffer is also a circular buffer. When root puts the encoded data into the corresponding position which is filled with old data, the newer data will cover the older one. When the downstream nodes ask the section of data root has, root

starts to send data from the sending buffer according to their allocated bandwidth. We explain how to allocate the bandwidth of children later.

Server:

The data protocol in server is much complicated than root. There are two buffers in each server. One is the sending buffer which is same as root. The other is playback buffer storing the decoded data. First of all, after choosing parents, server needs to decide the initial section index among the parents. We will discuss how to decide the index in the next part. When we finish picking the initial index, it is time to allocate the requested bandwidth from parents. We believe that the parents with higher scores are more suitable for us. As a result, we allocate the bandwidth according to their scores [equation 5]. The next step is waiting for the completion of this section. However, we can’t keep on waiting for infinite time. If the time we wait exceeds the expected time or no more streaming data can be played, we start with the timeout mechanism. The expected time is the total bits of a section divided by the target bit rate.

Because real time streaming data is time-dependent, we hope to have a stable throughput. The timeout mechanism helps us to detect the condition of our streaming service. If we decode this session within our expected time, we put the decoded data into playback buffer.

Furthermore, we re-encode the decoded session by channel encoder and put it into the sending buffer. This action increases the data diversity of whole system. When the peer receives data from upstream nodes, the chance of receiving repeat data (encoded block) is much lower.

(5)

After choosing our parents, we need to decide which section of data to download. In the same time, our parents have to reply the section of data they download now. Therefore, we discuss the issue on the two sides.

First of all, we have to choose the section replying to the children according to our sending buffer. [Figure 3.11] shows a peer’s condition of the sending buffer. The playback index is the section index of the data peer watches. And the decoding index is the section index of the data peer receives. We can see the difference between playback index and

decoding index is D. At the beginning of playing the video stream data, D should be the same as the initial buffer size.A peer's initial buffer size is the amount of data prepared for playing.

We set the value to be two sections. Nevertheless, with the change of peer’s downloading ability, D will vary over time. If the throughput of the peer drops off, D will be smaller. If we send the decoding index to our children, we may not be able to transmit the section of data to them. Because of this condition, we send the decoding index minus one to our child. If D is the same as initial buffer size or bigger, the throughput of the peer might increase or keeps stable. It means we have high probability to decode the section we receive successfully. As a result, we reply the decoding index to our child.

After obtaining each parent’s decoding index, we have to decide the initial section index. The strategy we use is to choose the newest and maximum section index the parents have. We want the newest data and get help from more parents. We think it is the best way for our system.

Figure 3-11 The condition of the sending buffer

3.4.2 How to allocate the bandwidth of children and

parents

How to manage the download and upload bandwidth in peer-to-peer network is

important. Because we discussed how to allocate download bandwidth, now we describe how to allocate children’s bandwidth. The strategy we take is to allocate bandwidth fairly for all the children [figure 3.12]. At first, we need to find out the smallest upload bandwidth for all children. The spirit of strategy is that we attempt to satisfy each child with the smallest upload bandwidth. If we still have uploading bandwidth left, we keep satisfying the remaining

children with the smallest amount of bandwidth until the total bandwidth is allocated.

400 kb 200 kb 230 kb

Upload bandwidth 40 kb

400 kb 200 kb 230 kb

Upload bandwidth 0 kb

400 kb 200 kb 230 kb

Upload bandwidth 640 kb

Figure 3-12 The process of allocating children’s bandwidth

3.4.3 Communication Protocol

In the real world, it is hard to let every computer obtain a public IP. It means there are a lot of peers under the NAT environment. We use the user datagram protocol (UDP) to solve NAT traversal problem. [Figure 3.13] shows how our system passes the NAT environment by UDP. We open two ports for our system. The one (info port) is for sending the communication packets. The other (data port) is for sending the data packets. When we ask peer list from patch server, we need to send the request packet through the two ports. The patch server records every new coming peer’s public IP and ports. Before we ask the data packet from parents, we need to send the test packet to parent’s data port. That is because we want to create the mapping from our internal IP and ports to the parents’ external IP and ports in the router. Therefore, the data packets from parents can be transferred to us by the mapping in the router.

Figure 3-13 The process of passing the NAT environment

3.4.4 Packet Protection

Because UDP is a message based connectionless protocol, the packet may be lost in the process of transmission. Therefore, we provide the data protection for our system. We use different level of protection according to the importance of packets. At first, we use ACK mechanism for the regular communication packets (for example: the packets for asking peer list, joining request, leaving notification …etc). If a peer receives this kind of packets, it needs to reply an ACK packet for notifying the sender [Figure 3.14]. If the sender does not receive the ACK packet after a limited time and the number of resending times for the parent is smaller than the MAX, we will resend the packet. The MAX is the threshold of resending times. If the number of sending times is bigger than MAX, we suppose that the peer leaves this system and remove this peer from peer list.

Figure 3-14 Data protection for regular communication packets

When peer decodes the section of data successfully, it needs to request the next section of data from its parents. If a peer sends this kind of communication packet, it will send the same communication packet twice [Figure 3.15]. The reason is if the receivers lose this communication packet, we will receive a bunch of overdue data packets. To prevent this situation, we send this communication packet twice.

For the data packet, we do not provide any protection mechanism. That is because we use the rateless code to encode our data. The encoded packets in the same section are

time-independent. For the receiver, as long as it receives enough packets, it has the ability to retrieve the original data. Even if we lose a few packets, the decoding will be affected slightly.

Figure 3-15 Data protection for important communication packets