Peer-to-Peer network has attracted tremendous attention from both academy and industry.
Nodes communicate directly with each other for the sharing and exchanging of data as well as other resources. In this chapter, we give the overview of the P2P system and our motivation
1.1 Overview
Since the Internet was started early in 1970s, many services and applications have been deployed, these include WWW, E-mail, File Transfer Protocol (FTP) and BBS. These services are all based on Client-Server model, on which the server is placed somewhere on Internet and waiting for client’s request. The server starts to provide its service to client upon receiving client’s request.
Client-Server model is easy for implementation. However, when the system population grows up, the server always becomes the bottleneck because of the limitation in centralized resources. So far, it is still hard for a single server to provide service to a large number of clients at the same time.
In the past decade, the so-called Peer-to-Peer (P2P) network architecture emerged. In this architecture, every peer acts as both server and client. A peer provides and receives the resource from/to other peers. This is the main difference between P2P architecture and Client-Server architecture, there are many advantages on P2P architecture, and it can resolve the server bottleneck and efficiently make a good use for every link.
The early application on P2P architecture is file-sharing. Every peer can share its own file among peers. Applications of Peer-to-Peer have been the focus point in recent years with the widely use of Napster [1], which is a file sharing system for sharing music files. To improve the file sharing performance on P2P architecture, BitTorrent (BT) [2] was developed
in 2002 by Bram Cohen which is a new architecture based on P2P file-sharing. To share a file through BitTorrent, a torrent file is first created. The torrent file contains the information of a so-called tracker that coordinates the file distribution and the metadata of the shared content.
The file content is divided into many fixed-size chunks so that a peer can download a file from different peers for different chunks simultaneously. This can improve the download rate much faster. The concept of “chunk” causes great effect not only on file-sharing but also on many applications.
In addition to file-sharing, there were many applications deployed based on P2P architecture, such as VoIP(Voice over Internet Protocol). Skype [3] is probably the most well known VoIP service. It runs under proprietary protocol and relies on the Skype P2P network for user directory and firewall/NAT(network address translator) traversal. As a result, Skype can bypass the costly infrastructure associated with the deployment of VoIP, and can easily scale to a very large size.
Another popular application is P2P streaming. More than dozen companies are actively working in this area. Some example companies are PPLive [4] , PPStream [5], etc. The main reason that the IPTV runs on P2P architecture is scalability and provisioning cost, it can utilize every peer’s upload bandwidth to provide contents to other peers. Thus it can reduce the workload in centralized server.
The source of video content is always divided into chunks in P2P systems. Peers receive chunks from source and share it with other peers. To achieve efficient and robust P2P content delivery, we need to work on two primary functions: P2P overlay construction and P2P scheduling. There are two major P2P overlays: Tree overlay and Mesh overlay. Every peer is a node in the tree overlay and it received video stream from parent and delivered contents to its children. Peer receives and delivers chunks from/to uncertain peers in mesh overlay. The mesh overlay is more robust compared to the tree overlay and it can accommodate much more peers than tree overlay. However, its latency is much longer than that for tree overlay.
Although there are many P2P IPTV system developed in recent years, most of them are proprietary systems. They do not release their protocol and algorithm in their systems. Many researchers are still curious about the internal design of these systems. Works have been done by tracing their packets [6] in the system and we can have deep view into these systems.
1.2 Motivation and Purpose
The P2P scheduling concerns the method for delivering the data from the source to its destinations under a given overlay. Depending on whether the sender and/or the receiver take the initiative in requesting the blocks, three modes may be used in the P2P delivery. In the push mode, the sender takes the initiative. In the pull mode, the receiver takes the initiative. In hybrid mode, both of them may take the initiative. In either push or pull mode, the peer needs to decide upon a delivery strategy, in the other word, which block to push/pull, and from/to which peer that the block is pushed and pulled. We call this the block selection and the peer selection [7].
Nowadays, many researchers focus on block selection, and proposed many block selection schemes, such as rarest, random etc. However only few of them focus on peer selection, they just randomly choose the peer who has the block, and receive the block from it.
Because every link has a different bandwidth, it may result a longer download time if we choose the worse one.
To efficiently utilize the bandwidth resource available in the P2P network, we propose a new approach to choose the best peer among the current partners. It can cope with any other block selection schemes and achieve much better stability. We focus on mesh-based system due to its good scalability and ease in implementation. Our goal is to shorten the download time of the chunks in P2P streaming system so that user can have a better quality-of-experience (QoE) for using streaming services.
1.3 Organization of the Thesis
The rest of this thesis is organized as follows. We introduce P2P streaming systems in more detail and address some related works about our peer selection algorithm in Chapter 2.
In Chapter 3, we discuss our proposed scheme in detail. We evaluate our scheme through OMNet++ simulation in Chapter 4. Finally, conclusions are stated in Chapter 5.