2009 Tenth International Conference on Mobile Data Management: Systems, Services and Middleware
Improving Mobile Peer-to-Peer Streaming Service with BitTorrent-like Redundant Tracker Pin-Chuan Liu1,2, Tsun-Chieh Chiang1, Yi-Fan Chien2, Wei-Kuan Shih2, 1 2 Industrial Technology Dept. of Computer Science Research Institute National Tsing Hua University Hsinchu, Taiwan, R.O.C. Hsinchu, Taiwan, R.O.C. {horatio,wshih}@rtlab.cs.nthu.edu.tw {flash,tcchiang}@itri.org.tw
Abstract
Chih-Lin Hu3 Dept. of Comm. Engineering National Central University Taoyuan, Taiwan, R.O.C.
[email protected]
connecting with broadband fixed networks. However, it is still not the case in wireless and mobile network environments, while the advance of wireless and mobile communication technologies can offer high data transmission capability and ubiquitous access connectivity, especially in the coming 4G networks, for convergence of fixed, wireless and mobile network systems. Thus, it is desirable that the P2P networks and services will be expanded to the wireless and mobile networks in the coming future. Notwithstanding, before their success, the development and deployment of mobile P2P networks suffer from many challenging issues, including terminal mobility, unreliable network connection, high frequency of disconnections and retransmission, power/energy saving and so on, due to characteristics and conditional restrictions in such network environments, but yet to be resolved. Therefore, our work in this paper primarily takes account of peer mobility in mobile P2P. Accordingly, we propose a redundant BT-like tracker mechanism which is able to enhance the performance in mobile P2P networks. Particularly, randomly intervening peers with arbitrary entrance in and leave out the mobile P2P networks, can result in high performance variance. This circumstance especially impacts multimedia streaming services, which require high and timely priority to produce playback data. Specifically, a peer must receive the complete video segment before playback. As streaming, a consecutive segment must follow the preceding segment seamlessly in order to avoid any intermittent delay and playback interrupt. In practice playback buffer or pre-fetching can be used to tolerate possible network transmission variance. However, mobile peer outage or unavailability is still not avoided due to unpredictable mobility, the event which greatly degrades quality of service/experience (QoS/E). To remedy it, several major P2P media streaming services (ppstream [4], pplive [5], tvants [6])
Entering and leaving of random peers will result in great variance of data availability in P2P networks, especially when multimedia streams require high priority to the immediate playback data. All peers must be able to receive the complete video segment before that playback. This requirement becomes more critical in mobile and wireless network environments where mobile peers have high frequency to leave and join the P2P network. Therefore, the provision of the tracker in the P2P networks is to accurately track the status of each peer and so to maintain high data availability being considered functionally. Our work deliberates the redundant mechanism of BitTorrent Tracker and designs a BT-like redundant tracker mechanism that is configured to this purpose, and presents the relative performance measure. The result shows that the proposed redundant tracker does not increase overheads and is able to upgrade stability to the playback operations in mobile P2P streaming networks.
1. Introduction While P2P networks conserve server computing power and bandwidth in a great large-scale peer community, P2P data flows currently take up the majority of Internet traffic [1]. In contrast to the traditional centralized client-server paradigm, the P2P functions the distributed sharing service that is proven to effectively reduce the calculation resources and network bandwidth [2]. At present, in addition to many common P2P applications, including file, media and resource sharing, there are several upcoming services, that target for VoIP, instant messaging, as well as multimedia streaming services, that are all based on the P2P technology. At present, in this context, the P2P service is so popular in the present Internet where the user can acquire this service by stationary PC 978-0-7695-3650-7/09 $25.00 © 2009 IEEE DOI 10.1109/MDM.2009.110
3
643
all have required a peer tracker to increase peer-lookup speed for end users. In addition to providing the resource sharing services, the tracker can also accurately track up/downloading rate and status of peers to further improve the P2P network performance. Therefore, for the purpose of providing reliability, stability and QoS in mobile P2P services, the deployment of a reliable tracker is of importance critically. While the single tracker will run the risk of single point of failure, the redundant tracker scheme is more reliable and can be established by means of existing High Availability (HA) middleware to support management and redundancy functionalities. In this paper, we exploit the tracker technique adopted in the popular BitTorrent P2P service and demonstrate the performance of proposed highly reliable redundant tracker mechanism. The highly reliable redundant tracker can support frequent and large update of the status of mobile nodes without overhead. The rest of this paper is organized as below. In Section 2, we will briefly explain the principles behind the BitTorrent P2P technology and its tracker functionality. In Section 3, we will describe the High Availability (HA) middleware and demonstration of the redundant tracker mechanism as proof of concept in Section 4. Section 5 will present performance results and analysis of the redundant tracker server. The concluding remarks are given in Section 6.
the torrent file, and then perform exchanging interested pieces. The tracker is to track the statuses of peers, socalled swarm with identical torrent. Peers provide relevant statistics data to the tracker and periodically query the tracker for the latest update of peer list. The tracker manages participant peers and contains a peer database which includes peer statuses, e.g., all downloading blocks, completed blocks, connection time, registered users, connection IPs, and IP connection counts (for NAT) , etc. It has been observed that the failure of tracker can significantly reduce the available amount of downloads [7][8]. In [8], some comparative results showed that a single tracker system provides better performance than multiple trackers and DHT methods. The amount of average nodes in a swarm will be lower for multiple trackers or DHT methods than from a single tracker and single peer database. Each tracker can be seen as an independent database, and the matter of round-robin polling to obtain multiple sets of peer lists will not much improve the P2P performance.
3. High Availability Tracker As mentioned above, the tracker plays an important role in the availability of BitTorrent network, especially for the P2P multimedia streaming applications where the DHT algorithm will not be able to satisfy the real-time constraint. The single tracker will run the risk of single point of failure, and therefore redundant tracker mechanism may be the best solution to increase both availability and reliability. The Service Availability (SA) Forum formed by many leaders in the communication and computer industry bodies proposed an open architecture high availability middleware specification. The Application Interface Specification (AIS) [10] has been defined in between the High Availability (HA) Middleware and application software, acting as the interface for telecom and Internet communication systems, and also supporting the uninterrupted service requirements [13]. The redundant tracker mechanism can be established on the base of the existing HA middleware to support the management and redundancy functionalities. As in the AIS specification, the system that requires high availability is represented with a standard abstract model inside which application interface functions are specified. These AIS Functions can be invoked to monitor and control the application software and middleware to detect and handle system failures. The AIS software will backup and maintain the statuses of the application to synchronize with the backend copies. As long as the active component runs to failure, the
2. BitTorrent Protocol and Tracker BitTorrent is mostly popular P2P file sharing software [3]. Compared with other earlier P2P file transfer applications, BitTorrent splits large file into various smaller pieces. Peers have ability of sharing pieces comprising the complete file instead of waiting a whole file downloaded from a single file server. The popularity of BitTorrent has resulted in many compatible software modules being developed. Particularly, the BitTorrent protocol is defined to improve the compatibility among different BT clients [9]. The BitTorrent protocol is built upon the TCP/IP protocol. A torrent file is introduced by metadata of sharing files. In addition, the torrent file records the URL of the tracker. Peers interested in a file must firstly download and open the torrent file in the BT client. During the download process, the BT client will resolve the torrent file to obtain the tracker’s URL and then connect to the tracker server through the HTTP protocol. The tracker will respond to the request of the downloading peer with other peers’ IP addresses and TCP/UDP port numbers. The downloader will connect to other peers for comparing each other’s available pieces, based on
644
4. High Available BT Tracker
system will immediately perform the failover and switch to the redundant backup. Accordingly, the AIS can provide the availability management and cluster management functions, in addition to providing commonly used service mechanisms in the HA application, such as data synchronization, high reliable distributed data message services and etc. The following describes three major service categories used in our work.
In a BitTorrent network, the tracker keeps the massive peer data to maintain communication within the P2P group. Once the tracker fails, these peer data will be lost, and thus the P2P network may be disrupted without further available updates. BNBT [12], an open source BT tracker, is rewritten in C++ from the original Python-based BT tracker to achieve better speed and efficiency. In our design, the redundant tracker mechanism is established through the OpenAIS [11] middleware by using the AMF, CLM and CKPT services to support the tracker management and redundancy functionalities.
(1) Availability Management Framework (AMF) AMF is the core of the entire HA Middleware. It provides the management interface of the cluster-wide services, including registration management, health monitoring, availability management, error report, and etc. The main tasks consist of: Selection and designation of Active/Standby role. Multiple Redundancy Mode supports N+1 and N+M redundancy modes, and supports scalable number of nodes. Health monitoring of software components and relevant resources, as well as handling the task of fail-over/switch-over to provide the uninterrupted service. (2) Cluster Membership Service (CLM) CLM provides the management service for the entire cluster members, monitoring and reporting of member status, and in addition providing real-time tracking interface of members. The main functions include:
Figure 1. System architecture of HA Tracker. As in Figure 1, the integration of BNBT and OpenAIS creates a High Availability tracker group, where the active tracker sends data to multiple standby members within the group simultaneously. Furthermore, the Membership protocol provided by OpenAIS can identify the current members and manage the group memberships. The Membership protocol can ensure consistency in each member's configuration, thereby handling the message relay for modifications to the membership or configuration status. The pseudo-code below describes the main thread of the algorithm. We initialize AMF service with the standard procedures and create twelve check point sections. At the end of the thread, we do an infinite while-loop process to prevent the service disabled.
Failure detection between nodes through the heartbeat method. The point of failure can be quickly detected, and of which the cause can be determined within 50ms recovery time as specified by telecom class standards. Lookup and discovery of cluster members with continuous tracking. When members are added or disconnected, all cluster nodes will be immediately notified. (3) Checkpoint Service (CKPT) CKPT provides interface for copying and backup of critical data to the redundant notes. The active component needs to copy and synchronize data through the Checkpoint API to create the Check Point Replica. During every update (write), the HA service middleware/daemon will automatically copy and update to each standby node to complete the data synchronization.
Pseudo-code of Main Thread Create_checkpoint() { saCkptInitialize( &ckptHandle, …);
645
saCkptCheckpointOpen( ckptHandle, ckpt_name, &checkpointHandle );
}
}
//create 12 check point sections saCkptSectionCreate(checkpointHandle, saCkptSectionCreationAttributesT* attr, …); … saCkptSectionCreate( checkpointHandle, SaCkptSectionCreationAttributesT* attr, …);
ckpt.push_back( EncodeDicti(*m_pIPs) ); ckpt.push_back( EncodeDicti(*m_pFastCache) );
These critical data in BNBT are stored in the structure of link lists. We use the Bencoding method from BitTorrent to encode these members into simple text strings, and write these strings to the checkpoint sections. After the standby trackers receive these data, the member contents can be decoded and recovered as shown by the following pseudo-code.
//initialize AMF saAmfInitialize( &handle, …); saAmfSelectionObjectGet(&handle, &fd); FD_SET(fd, &read_fd); saAmfComponentRegister(handle, comp_name, …); Create_checkpoint(); While(1) { seletc(, &read_fd, …); saAmfDispatch(&handle, …); }
Section Recovery in Standby Tracker standby_restore( ) { m_pAllowed m_pState m_pDFile m_pCompleted m_pTimeDicti m_pCached m_pComments m_pTags m_pUsers m_pIPs m_pFastCache }
Within the same timeframe, only a single tracker will remain active, and all other trackers will be in the standby state. The active tracker will be the only server to external peers and will periodically write the database information, such as peer list and other backup data, to the checkpoint. All other standby trackers will keep a copy of the backup data. Then if the active tracker fails to leave the group, the standby trackers will immediately restore the backed up data and enter the active state to provide continuous services. In BNBT, peer database is stored in the structure of eleven link lists. We create eleven checkpoint sections to these data and plus one checkpoint section to check the status of previous task. The pseudo-code below describes the basic cycle of pushing data into checkpoint sections in the active tracker.
= DecodeDicti( ckpt [0] ); = DecodeDicti( ckpt [1] ); = DecodeDicti( ckpt [2] ); = DecodeDicti( ckpt [3] ); = DecodeDicti( ckpt [4] ); = DecodeDicti( ckpt [5] ); = DecodeDicti( ckpt [6] ); = DecodeDicti( ckpt [7] ); = DecodeDicti( ckpt [8] ); = DecodeDicti( ckpt[9] ); = DecodeDicti( ckpt[10] );
Eleven Checkpoint Sections in Active Tracker active_backup( ) { ckpt.push_back( EncodeDicti(*m_pAllowed) ); ckpt.push_back( EncodeDicti(*m_pState) ); ckpt.push_back( EncodeDicti(*m_pDFile) ); ckpt.push_back( EncodeDicti(*m_pCompleted) ); ckpt.push_back( EncodeDicti(*m_pTimeDicti)); ckpt.push_back( EncodeDicti(*m_pCached) ); ckpt.push_back( EncodeDicti(*m_pComments) ); ckpt.push_back( EncodeDicti(*m_pTags) ); ckpt.push_back( EncodeDicti(*m_pUsers) );
Figure 2. The procedural flow in HA Tracker. All trackers will be connected through the network interface as indicated in Figure 2. The trackers in the group will call GetState after an interval to check if the state has changed, or if T seconds have elapsed. If the answer is negative, the normal tracker operation will
646
should be a contribution somehow to inspire the development and deployment of BT-like redundant tracker mechanism. Accordingly, in the mobile P2P environments, the peer list will be updated rapidly. Bencoding and compressing peer database by an appropriate algorithm can effectively improve the backup process. Peers using the same IP subnet and TCP port number can also increase the compression ratio of the peer list. Therefore, the redundant tracker mechanism is an economically effective method that is very applicable towards upcoming P2P streaming applications. Our redundant tracker design is a first step towards constructing a wireless and mobile P2P streaming system.
resume. If YES, the active tracker will enter the backup process, and subsequently encode, compress and write the peer list to the checkpoint service. The standby trackers will access the latest peer list from the checkpoint service and save to the local database after decompression and decoding.
5. Measurement Results and Analysis In the laboratory environment, we used the VMware multiple platform software on a single PC to emulate two trackers for timing analysis and implementation of synchronization requirements. The OpenAIS works on the eth0 interface, and only a single tracker will be in the active state among the two trackers. The active tracker uses eth0:1 as the IP address which is also the registered tracker IP in the .torrent file serving external peers. When the current active tracker fails, the standby tracker will enter active state and add the identical network interface as eth0:1. Therefore, to the external peers, the location of the tracker does not change and is transparent to the different tracker machines in service. We used another PC to randomly generate large amounts of peer data to measure the backup and recovery time. Two redundant trackers were setup in VMware on a PC equipped with Intel E6300 1.86GHz and 1G DDR2-667 RAM. We measured the backup time in active tracker and restoration time in standby tracker under different number of peers to verify the overhead of our design. As illustrated in Figure 3, the recovery time is proportional to the number of peers with linear growth. With 2000 peers, the backup and recovery can be completed within 0.24 seconds. Another PC running the BitTorrent client was used to measure the response time of the request peer list inquiry. As shown in Figure 4, backup time T, set to 5 seconds, 10 seconds and non-backup, has no significant correlation between the response time and number of peers. When T is set to 1 second, the response time will possibly increase with the number of peers. From the two test results, backup and data recovery time needs approximately 0.24 seconds, and if the time T is set to 1 second then the system will have to continuously backup and recover the data, thereby impacting the overall response time of the tracker.
Backup/restoration time
250000
backup restoration
time (us)
200000
150000
100000
50000
0 0
500
1000
1500
2000
peer number
Figure 3. HA Tracker performance. Avg. Response time
480000
1 5 10 no ckpt service
Response time (us)
460000
440000
420000
400000
380000 250
500
750
1000
1250
1500
1750
peer number
Figure 4. HA Tracker response time.
6. Conclusion and Future Research In this paper, we have presented our design reference of the High Availability BitTorrent Tracker methodology. We believe that this proposed design
647
2000
References [1] Morganstanley report, on-line available via http://www.morganstanley.com/institutional/techre search/webtwopto2006.html [2] Dongyu, Qiu, and R. Srikant, “Modeling and performance analysis of BitTorrent-like peer-topeer networks,” in Proceedings of the 2004 conference on Applications, technologies, architectures, and protocols for computer communications, Portland, Oregon, USA, 2004. [3] Cohen, B., “Incentives build robustness in BitTorrent,” in Proceedings of the 1st Workshop on the Economics of Peer-to-Peer Systems, Berkeley, 2003. [4] ppstream, website at http://www.ppstream.com/ [5] pplive, website at http://www.pplive.com/ [6] tvants, website at http://www.tvants.com/ [7] J. Pouwelse, P. Garbacki, D. Epema, and H. Sips, “The bittorrent p2p file-sharing system: Measurements and analysis,” in Proceedings of the 4th International Workshop on Peer-to-Peer Systems (IPTPS’05), February 2005. [8] G. Neglia, G. Reina, H. Zhang, D. Towsley, A. Venkataramani and J. Danaher, “Availability in BitTorrent Systems,” in Proceedings of the 26th IEEE International Conference on Computer Communications(INFOCOM 2007), 2007. [9] BT Specification, on-line available via http://wiki.theory.org/BitTorrentSpecification/. [10] Service Availability Forum, “Service Availability Forum Application Interface Specification”, SAIAIS-B.01.01, 2004. [11] OpenAIS, website at http://developer.osdl.org/dev/openais/. [12] BNBT, website at http://sourceforge.net/projects/bnbt/. [13] R. Manfred, “Delivery of the SA Forum Application Interface Specification,” in Proceedings of the Workshop on Dependable Embedded Systems (SRDS 2003), Fujitsu Siemens Computers, 2003.
648
