Proceedings of 2012 IEEE 19th International Packet Video Workshop May 10-11, 2012, Munich, Germany

RapidStream: P2P Streaming on Android

Philipp M. Eittenberger, Matthias Herbst, Udo R. Krieger
Faculty of Information Systems and Applied Computer Science
Otto-Friedrich University
Bamberg, Germany
Email: {philipp.eittenberger, udo.krieger}@uni-bamberg.de

Abstract—In this paper we present the architecture of the currently holds, the peers exchange their buffer maps, also
first mobile P2P streaming prototype for the operating system called chunk maps. Mainly two different service types can
Android. At first, we discuss the application of P2P streaming in be distinguished within P2P streaming: A video on demand
the scenario of mobile networking. Then, the system and software
architecture of our prototypical implementation is elaborated. In (VoD) system provides users with VCR functionality, e.g.
addition, an initial field test to evaluate the feasibility of the stop, rewind or fast forward of the video. In contrast, by live
proposed approach is presented. Finally, we report our insights streaming the users have a more TV-like experience, where all
arising from the practical experience with Android. users view the same playback time within a certain range of
delay. Regarding the system architecture and, in particular,
I. I NTRODUCTION
the implementation of the data dissemination, the systems
Mobile video traffic is growing rapidly with yearly growth can be coarsely divided into two main groups: Mesh-pull
rates of more than 90 % according to [2]. The rapid deploy- systems build an unstructured overlay, hence "mesh", and each
ment of new multimedia services including video streaming peer requests, i.e. "pulls", the data from other peers. Tree-
as well as many new video portals, like PPLive, PPStream push systems explicitly construct a dissemination overlay and
or SopCast, indicates the evolutionary path towards the next "push" the data along the constructed "trees".
generation of mobile networks. Hence, one important aspect P2P streaming applications have attracted a lot of atten-
that needs to be investigated is given by the optimal dis- tion in recent years. Numerous scientific studies investigated
semination of video data in the next generation of wireless their properties, large research projects have been founded
networks. One viable possibility to distribute the traffic load to develop prototypes (e.g. NapaWine[12] or PPNext[13]),
more evenly in the network and thereby, provide lower costs but more important, real systems have also been deployed
and higher scalability is given by the usage of peer-to-peer successfully. These P2P streaming applications are able to
(P2P) technology. However, current P2P applications are not serve simultaneously up to hundreds of thousands of users
tailored for these new requirements; quite the opposite, P2P nowadays. It is therefore just a matter of time when these
streaming applications tend to use the network resources very applications also pervade mobile networks. The goal of our
aggressively and at least P2P streaming applications have no work is to investigate these necessary adaptations of P2P
or little preference to exchange data among nearby peers [3]. techniques for the mobile, wireless dissemination of video
This is not surprising, because current P2P video streaming content. For this purpose, we have developed the prototypical
applications have been specifically developed for a “wired” P2P streaming application RapidStream. In this paper we will
scenario, where users run the application at their PC, which present its current architecture and report our insights of using
is connected via the customer premises network to the ISP. Android as a client platform for P2P applications.
However, with the advent of ubiquitous computing users
want to use their accustomed applications wherever they are. II. R ELATED W ORK
Thereby, new requirements arise that need to be addressed by Despite the fact that there is a large amount of scientific
P2P applications in order to provide a sufficient quality of studies investigating P2P video streaming, there is relatively
experience. little work regarding the usage of P2P streaming applications
Let us first clarify the terminology of the P2P domain: on mobile devices. The first studies introducing P2P video
Users, so called peers, are connected with each other in overlay streaming applications that are able to operate on mobile
networks to share resources, in this case, to disseminate video devices are presented by Venot and Yan [14], who introduce
data. The main difference to the client/server paradigm is given a JXTA based P2P video streamer. Yet, their implementation
by the fact that each peer can be at the same time client and was not able to stream the video content progressively if it
server. A common approach to disseminate video data via was operating on a mobile device, i.e. it could only display
P2P is to split up the data in smaller units, called chunks. the video file when it was completely downloaded. Also Zhang
They are then distributed between the peers of a swarm. A et al. [15] presented a Symbian based P2P video streamer, but
source node, in this domain called seed, provides the initial the study did solely evaluate the energy consumption of the
upload of the data; subsequently, the downloaders distribute proposed system on the mobile devices. Furthermore, Diaz et
the data further to other peers. To indicate the chunks a peer al. [6] conducted a measurement study on a Symbian based

978-1-4673-0301-9/12/$31.00 ©2012 IEEE 125 PV 2012

 Figure 2. UML Packet Diagram of the Framework
Figure 1. Mobile P2P Streaming Architecture

to a maximum of 32 MB. Only with root access on the

P2P video streaming application over cellular networks. All device we could increase the heap space to the “hard wired”
of these first presented P2P video streaming prototypes for maximum of 48 MB. As a consequence, this implies that
mobile devices suffered from the limited resource capacities the video buffer must be kept quite small and that it is
of mobile devices given at that time (2007). Only recently by crucial to hold not too many open connections in parallel.
the appearance of much more powerful mobile devices this In addition, to enable the P2P video data dissemination on
approach has become feasible in practice. In 2010, Peltotalo Android, the protocol of the P2P application should be as
et al. [11] presented a fully working RTSP based P2P video lean as possible, to avoid too much signaling traffic and in
streaming application for Nokia smart phones. Other work that general, to keep the communication overhead at a minimum.
investigates certain aspects of this approach consists of Noh et Therefore, an important development objective of mobile P2P
al. [10], who proposed a transcoding scheme to enable video video streaming applications must be the sustainable usage
streaming to mobile peers. Cycon et al. [5] introduced a H.264 of the network resources, i.e. to be as energy and resource
video encoder that operates in real-time on mobile phones for efficient as possible.
P2P video conferencing. Finally, Leung and Chan [9] proposed
As a platform for our prototype we have chosen Android,
a protocol for the P2P dissemination of multimedia content to
which is a partly open source, Linux based OS mainly tailored
mobile devices.
for mobile devices. User programs written for Android are
III. R APID S TREAM - P2P S TREAMING ON M OBILE executed in the Dalvik Virtual Machine (DVM), which is based
D EVICES upon the Java Virtual Machine (JVM). We found that there
The migration of P2P video streaming applications to a is generally a good fit between both, but in some cases the
mobile environment requires certain adoptions, since mo- Android’s Java implementation provides only stubs and no
bile devices are battery powered and have in general less implementations for some classes of the Java API.
computing power compared to standard PCs. In addition,
P2P applications running in a mobile environment encounter A. System Architecture
different network dynamics compared to a “wired” scenario. For the prototypical implementation we have chosen to
Although next generation mobile networks, like LTE, strive to build a mesh-pull based live streaming network. Regarding the
provide broadband-like downstream capacity, hand-overs and system design we went for a hybrid P2P overlay maintenance
the fluctuating link quality negatively affect the transmission design, i.e. the system is not fully decentralized, since there is
performance of P2P applications [7]. Moreover, the protocols a dedicated, centralized infrastructure to retain control of the
of such P2P applications even increase the rate of control P2P network and to relieve the load of the peers. The central
messages due to connection disruptions, and thereby, produce infrastructure consists of a tracker server, a video server and a
more signaling overhead. Apart from these network induced rendezvous server. In the simplest case, only a single instance
conditions, there are also new requirements caused by the used of each component exists in the system. Of course, to increase
hardware platforms. As already mentioned, mobile devices the reliability and the performance of the system, one could
provide less computing resources, i.e. primarily less memory always use more, redundant instances of each component.
and CPU speed. For instance, on current Android versions The video server needs to register his content at the tracker
the heap space of a Java application is limited per default server to be able to stream video content. In the proposed

126
system, each video results in an own dissemination swarm,
i.e. only the peers watching the same video exchange video
data. In future extensions more advanced techniques could
also be considered to increase the dissemination performance.
The process of joining of a swarm, i.e. watching and re-
distributing a chosen video, can be described as follows: Upon
registration at the tracker server, each peer receives a unique
identifier (PeerID). In addition, the tracker server returns a list
of the currently broad-casted channels in combination with the
connection information of the video servers. If the peer has
chosen a video channel, it informs the tracker server of joining
the particular swarm. The tracker server supplies the peer with
an initial peer list in the bootstrap process. The implementation
of the tracker protocol follows closely the standard proposal
given in the PPSP Tracker Protocol [4] and it is probably
one of the first working implementations. With the help of
the rendezvous server, the peer is able to communicate with
other peers, even if they or itself are behind a NAT. Right
now, only UDP hole punching is implemented, as it yields
the highest success rate. However, in future releases we will
include TCP hole punching as well to increase the chance
of a successful NAT traversal. Upon successful connection Figure 3. Architecture of RapidStream’s Android P2P VideoStreamer
setup, the peers exchange their buffer maps and they request
missing chunks from each other. The exchange of the buffer
maps and the chunk transfer are conducted iteratively as executable program. The central Framework-API provides the
long as the peer is watching the video. Due to the structure most common data objects, which are shared between all the
of the proposed system, every communication relationship modules and which are used for the inter-module communi-
needs a particular type of connection. Figure 1 sketches the cation. After the completion of the framework, the next step
system architecture of RapidStream and illustrates the usage included porting the peer module to Android. The architecture
of the transport protocols for the different scenarios. For the of the Android P2P streaming application is illustrated in Fig-
communication with or between the servers, HTTP is a well ure 3. Porting the application was relatively straightforward;
suited protocol (as described in [4]), as it is the protocol that the main difference is that there is no Swing on Android.
is the more likely to work in any case. The communication Therefore, a few GUI classes, in the Android terminology
with the rendezvous server is performed by TCP. The video called activities, had to be added to the presentation layer of
data dissemination requires a more efficient transport protocol, the P2P videostreamer: The Connection Screen is used to enter
thus, the connectionless UDP is used. However, to ensure the contact information of the different servers, the Video List
the successful transmission of signaling and control messages activity displays the obtained list of available videos and upon
between the peers, the framework can use TCP respectively reception of enough video data, the Video Player shows the
RUDP [1] for this kind of communication too. To ease the particular video. The brain of the application is the Controller,
performance analysis and the gathering of measurement data, which manages in coordination with the Streaming Compo-
we have also included a statistics server, which receives nent all the connections through the incoming and outgoing
periodically measurement data from all network participants. communication modules. The Streaming Component is also
Since this server is not a vital part of the P2P network, it is responsible for the internal video buffer and for advancing the
not depicted in the system architecture (cf. Figure 1). time line of the chunk buffer.

B. Software Architecture C. Interaction Pattern of a Peer

We have developed a general P2P streaming framework, Figure 4 depicts an UML sequence diagram that illustrates
which is based upon a modular software architecture. The the initial operations of a peer without explicit error han-
framework is purely Java based and can be executed on every dling considerations. At first, the device running RapidStream
Java-capable device. Figure 2 depicts the UML package dia- connects to the tracker server receiving its PeerID. With the
gram of the framework. The hierarchical structure illustrates PeerID and its connection information it registers itself at the
the dependency between the packages. Every package can rendezvous server and requests the list of video servers from
be easily replaced as long as its dependency is considered. the tracker server. Then, the peer may contact a particular
This modular design enables the combination of existing video server and request the list of videos/channels. The
components, it allows for instance the bundling of the tracker connection establishment might be enabled by the rendezvous
server, the video server and the rendezvous server into one server, if the video server is behind a NAT. Upon choosing

127
a particular video or channel, the video server provides the
necessary meta data of the video. This procedure is further
explained in Section III-D. Subsequently, the peer requests
the buffer map of the video server and sets its initial buffer
map accordingly. In addition, the peer informs the tracker
server of joining the dissemination swarm of the video and
requests a bootstrap list of other peers participating in the
same swarm. The following interactions may be conducted
iteratively as long as the peer is a member of the video
swarm: The peer contacts the video server to update its peer
list, then, it choses a particular chunk to request and a peer
and subsequently, tries to establish a connection to the chosen
peer. Again, the connection establishment might be enabled
by the rendezvous server. After a successful connection, the
peer is requesting the buffer map of the second peer and a
particular chunk, if the contacted peer possesses a missing
chunk. When the peer has successfully downloaded the first
chunk, it may itself serve chunk requests of other peers too.
One can observe that we have “outsourced“ as much of the
overlay maintenance functionality as possible to the dedicated
network infrastructure. RapidStream even avoids the standard
keep-alive message exchanges between the peers to keep the
signaling overhead small. The scarce resources of the mobile
devices are mainly used for the dissemination of video data.
From the perspective of requiring a lean and sustainable P2P
streaming protocol, large chunk sizes are also necessary to
yield a small overhead rate. Otherwise, if the chunks are too
small, there is a lot of signaling overhead due to the continu-
ous connection establishments and the necessary negotiations
among the peers. However, if the chunk size is chosen too
large, the receiver will have to wait longer for the reception
of a chunk leading to an increased play back delay. In the
presented version of RapidStream we have opted for chunk
sizes of up to 2 MB to reduce signaling traffic and the energy
consumption by limiting the transmission phases of the air
interface (compare with the stepwise increase of the received
traffic in 7). As each peer receives data from a multitude of Figure 4. UML Sequence Diagram of the P2P streaming player
peers, the optimal number of concurrent data transmissions
is an important parameter to reduce the resource usage too.
Currently, each peer downloads from at most 5 peers in the MediaPlayer instances with regard to different smartphone
parallel. All of these parameters were chosen according to manufacturers. In order to get the certification "Android com-
our experimental investigations, but for the best possible video patible" for a particular device, it must be tested by Google’s
experience they need to be validated analytically. However, we Android Compatibility Program. Only in this case, it may
leave this open for future work. participate in the Android ecosystem, e.g. have access to the
Android market. Despite this certification process by Google,
D. Pitfalls on Android we encountered serious problems with Samsung devices. The
Android provides a multimedia framework that includes state diagram of Android’s MediaPlayer has been specified
codecs for the most common audio and video formats. We by Google (compare [8]). Yet, for reasons that have to be
use the MediaPlayer of this API for the play back of the clarified, the method call of prepare() may lead in some cases
received video data in order to avoid writing our own video directly to the state Playback Completed on Samsung devices.
player. As one might expect from such a smartphone platform, According to the state diagram in [8] this transition should
like Android, the Java implementation of the MediaPlayer not be possible, respectively, it is not allowed. To circumvent
should be the same on all the particular devices. However, this error, our current implementation loops over the prepare()
since the MediaPlayer is relying on native implementations of method until the state Prepare is finally entered. We did not
the video codecs, i.e. C/C++ code provided by the particular encounter this nuisance on devices of any other manufacturer.
device manufacturer, we encountered a different behavior of To be completely independent of such limitations, we would

128
 Table I
H ARDWARE BASE IN THE TEST RUN
ID Vendor Model
1 Samsung Galaxy Gio (1)
HTC Desire
2 Samsung Galaxy S (1) Samsung Galaxy Tab
LG Optimus 2X
3 Samsung Galaxy Gio (2) Sony Ericsson MT15i
all other Samsung
4 Samsung Galaxy S (2)

0 200 400 600 800 1000

5 Samsung Galaxy Ace

Throughput (KByte/s)

Chunk Nr.
6 HTC Desire
7 Sony Ericsson MT15i 25
8 LG Optimus 2X 20
9 Samsung Galaxy Tab 15
10
5
0

need to provide our own implementation of a media player

with the related codecs. As such a task was not the focus of our
work, we will await for a porting of other media players, like Figure 5. Download Throughput (Test Run)
the VLC player, to the Android platform in future versions.
Android (up to version 3) supports the two container for-
mats 3GPP and MPEG-4 (Part 12) for video codecs. The cation on as many different devices as possible to ensure its
provided MediaPlayer is even capable to support streaming functionality.
with RTP/RTSP. Therefore, the general suitability for live
streaming in the P2P context is, in principle, given. Such an IV. M EASUREMENT R ESULTS OF AN I NITIAL F IELD T EST
approach would need an implementation of a RTSP server Since we are especially interested in the performance that
on every terminal device. This RTSP server would be used can be achieved in practice, we have evaluated the performance
to “feed” the MediaPlayer with the reassembled video data. of RapidStream in the following experiment. To judge the
However, we could not find a publicly available Java based general feasibility of the proposed system, we have conducted
implementation of the RTP/RTSP stack. Therefore, we decided a small scale test run. Due to the fact that we have only a
not to implement the needed RTSP functionality, as this was very limited number of Android devices, we recruited nine
not the focus of our work either. Yet, we decided to use the persons, who posses Android smartphones, to participate in
MediaPlayer after all, as one can rely on the fact that this the test run1 . The resulting hardware base is depicted in Table
player is available by default on every Android compatible I. Unfortunately, most of the participating devices were from
device. To make the MediaPlayer capable of progressive Samsung. This fact is responsible for the relatively long start-
streaming, the video server needs to manipulate the container up delays depicted in Figure 6 (a). The start-up delay is the
format. Most encoders write the meta data of the MPEG-4 time between the initial request of the video data and the
container, called moov atom, at the end of the video file and time the video playback starts. As already mentioned, our
therefore, downloading the entire file is required in order for implementation had to loop over the prepare() method until the
the MediaPlayer to be able to read the meta data of the video state Prepared was finally reached on Samsung devices. This
and start the play back. When the moov atom is relocated to circumstance had a negative effect on the start-up delays. Yet,
the front of the file and its offsets are adjusted accordingly, half of the peers could start watching the video in less than 20
the MediaPlayer is able to start playing the video, even if the seconds. On the HTC Desire smartphone we even measured
whole file is not yet available. For this reason, the video server start-up delays of less than 10 seconds, which is a really
extracts the moov atom and provides it together with other promising result. To start our experiment, the participants
meta information (the top-level ftyp atom) to the peers. Upon had to download and install RapidStream from a web server.
joining a particular swarm, the peer downloads at first the Subsequently, they could enter the P2P network and join
video meta data from the video server and creates a temporary the test swarm. One initial video server provided the open
file to buffer the video data as it is downloaded from the peers. content film "Big Buck Bunny"2 . This video was encoded
The initial temporary file is empty apart from the meta data by H.264, a resolution of 320x180 pixels and 24 frames per
at the beginning. But it will be continuously filled with the second. The movie length is 9.56 min and it has a total
received chunks, which have to be stored at the right position data volume of 61.7 MB. Thus, to watch the video without
of the file. If a certain threshold of received video data is disruptions, a device needs at least a download throughput of
reached, the video play back starts. 105.94 KByte/s respectively 847,5 KBit/s. Figure 5 depicts
Android is a standardized platform for mobile devices, the achieved download throughput in the test run. It can be
therefore, one might anticipate that this fact makes the life observed that nearly all the devices are capable to reach the
of a developer much simpler. Quite to the contrary, due to the 1 A short video of the test run is provided at:
broad, heterogeneous hardware base of Android compatible http://www.ktr.uni-bamberg.de/project/rapidstream.html
devices, we found that the developer needs to test his appli- 2 http://www.bigbuckbunny.org/

129
 70
●
●
●●

60
●●●
●●●●
0.8

●
●
●● ●
●
● Cum. Download

95

Received Data (MByte)

●
●●●
●●
●●● Playback Rate

Neighborhood Size

50
●
● ●
●

6
0.6

Battery Level
●
●●● ●
●
●
1 − F(x)

40
●●
●●●●
●
●
●●
●●

90
●●●
●
●●
●●
●

30
0.4

●
●●
●
●●●
●●
● ●
●

20
●
●
●●

2
●
● ●
0.2

85
Mobile Peers ●●
●●

10
●●
●
●●●
●●
●●
●
Normal Peers ●●
●●
●●
●

0
●
●
●●

0
10 20 30 40 1 2 3 4 5 6 7 8 9 0 10 20 30 40 50 60 0 100 200 300 400 500
Peer ID Time (min) Time (s)
Start−up Delay (s)

(a) Start-up Delay (b) Peer Neighborhood Distribution (a) Battery level (b) Cumulative Download Traffic

Figure 6. Test Run Results Figure 7. Test Run Results (continued)

necessary throughput rate. The different starting points of the transmission in cellular networks. We will address the shown
particular graphs result from different swarm joining times, pitfalls and investigate more sophisticated data dissemination
since some participants needed more time to download and patterns specifically focused on mobile networks in future
install RapidStream on their device. To provide a more realistic versions of RapidStream.
scenario, we have setup some additional PCs running the peer ACKNOWLEDGMENTS
application too. Figure 6 (b) illustrates the distribution of
the peer neighborhood of the mobile devices. A normal peer The authors are thankful to Marcel Großmann for his
represents a peer application running on a desktop machine. assistance with the measurements.
Since the PCs were started before the mobile devices did join R EFERENCES
the P2P network, they were able to serve successfully most
[1] T. Bova and T. Krivoruchka. Internet-draft - reliable udp protocol. 1999.
of the chunk requests of the mobile peers. Figure 7 illustrates [2] Cisco Systems. Visual networking index cisco visual networking index:
more measurement results taken on the Samsung Galaxy Tab. Forecast and methodology, 2010-2015. White Paper, 2011.
Figure 7 (a) displays the drainage of the battery during the test [3] D. Ciullo, M. Garcia, A. Horvath, E. Leonardi, M. Mellia, D. Rossi,
M. Telek, and P. Veglia. Network awareness of p2p live streaming
run. If one extrapolates the battery usage, one can see that the applications: A measurement study. IEEE Transactions on Multimedia,
battery of this device is able to provide roughly 4 hours of 12(1):54 –63, 2010.
video display with RapidStream. Figure 7 (b) illustrates the [4] R. S. Cruz, M. S. Nunes, Y. Gu, J. Xia, D. A. Bryan, J. P. Taveira, and
D. Lingli. Internet-draft - ppsp tracker protocol. 2011.
received download traffic and the playback rate of the video [5] H. Cycon, T. Schmidt, G. Hege, M. Wahlisch, D. Marpe, and M. Palkow.
for the first 10 minutes of the test. As already mentioned, the Peer-to-peer videoconferencing with h.264 software codec for mobiles.
stepwise increase of the cumulated down-link traffic is due In International Symposium on a World of Wireless, Mobile and Multi-
media Networks. (WoWMoM ’08), pages 1–6, 2008.
to the large chunk sizes and the hereby induced on-off traffic [6] A. Diaz, P. Merino, L. Panizo, and A. M. Recio. Experimental analysis
pattern to reduce the energy consumption of the air interface of peer-to-peer streaming in cellular networks. In 21st International
as much as possible. Conference on Advanced Information Networking and Applications.
(AINA ’07), pages 784–791, 2007.
V. C ONCLUSION [7] P. M. Eittenberger, S. Kim, and U. R. Krieger. Damming the torrent:
Adjusting bittorrent-like peer-to-peer networks to mobile and wireless
To the best of our knowledge, this work presents the environments. Advances in Electronics and Telecommunications, 2(3):14
first academical P2P application operating on Android. In – 22, 2011.
[8] http://developer.android.com/reference/android/media/MediaPlayer.html.
summary, we have introduced the general architecture of State diagram of android’s mediaplayer. 2011.
RapidStream, a proof-of-concept implementation of a P2P [9] M. Leung and S. G. Chan. Broadcast-based peer-to-peer collaborative
video streaming application for Android compatible devices. video streaming among mobiles. IEEE Transactions on Broadcasting,
53(1):350–361, 2007.
Furthermore, the paper presents a preliminary field test to [10] J. Noh, M. Makar, and B. Girod. Streaming to mobile users in a
evaluate the general feasibility of the proposed approach. peer-to-peer network. In Proceedings of the 5th International ICST
Our first insights regarding the feasibility of P2P streaming Mobile Multimedia Communications Conference (MOBIMEDIA ’09),
pages 24:1–24:7, 2009.
in the domain of mobile devices and the results of our [11] J. Peltotalo, J. Harju, L. Väätämöinen, I. Bouazizi, and I. D. D. Curcio.
experiments are promising. Despite the fact that our test run Rtsp-based mobile peer-to-peer streaming system. International Journal
was performed on a rather small scale, we were able to identify of Digital Multimedia Broadcasting, 2010.
[12] http://napa-wine.eu. Napa Wine.
that Android devices are in principle capable to support the [13] http://www.p2p-next.org/. P2P-Next.
necessary streaming rates. In addition, we could identify the [14] S. Venot and L. Yan. On-demand mobile peer-to-peer streaming over
main challenges that need to be addressed in future work. the jxta overlay. In International Conference on Mobile Ubiquitous
Computing, Systems, Services and Technologies. (UBICOMM ’07).,
The most important challenge for mobile P2P is given by pages 131 –136, 2007.
the reduction of the energy consumption on battery powered [15] J. Zhang, J. Niu, R. He, J. Hu, and S. Limin. P2p-leveraged mobile
devices. Thus, the goal is to be as energy efficient as possible. live streaming. In Proceedings of the 21st International Conference on
Advanced Information Networking and Applications Workshops. (AINAW
Further requirements that need to be addressed in future work ’07)., pages 195–200, 2007.
consist of the optimal peer selection and the efficient data

130