(IJCNS) International Journal of Computer and Network Security, 79

Vol. 2, No. 9, September 2010

Performance Evaluation of Peer–to-Peer system in

Video on Demand with Load Sharing Scheduling
Algorithm
S.Nagaprasad1*, A.VinayaBabu2, K.Madhukar3, D.Marlene G Verghese4, V.Mallaiah1and A.Sreelatha5
1
Research Scholar, Dept. of CSE,
Aacharya Nagarjuna University, Guntur,
1
*nagkanna80@gmail.com
2
Professor, Dept. of CSE,
JNTU College of Engineering, Hyderabad,
avb1222@gmail.com
3
Professor, Nizam College, Osmania University, Hyderabad
mkatakam@osmania.ac.in
4
Associate Professor
Bhimavaram Institute of Engineering & Technology
Pennada, West Godavari
marlenedegala@yahoo.co.in
5
Student, Dept. of CSE,
JITS College of Engineering, Karimnagar,
sreelathu_alugoju@yahoo.com

Abstract: Peer-to-Peer (P2P) networks have been shown to be
a promising approach to provide large-scale Video on Demand
(VoD) services over Internet for its potential high scalability.
However, for a normal peer, how to efficiently schedule media
data to multiple asynchronous peers for VoD services in such
networks remains a major challenge. These systems
dramatically reduce the server loading, and provide a platform
for scalable content distribution, as long as there is interest for
the content. The main challenges reside in ensuring that users
can start watching a movie at any point in time, with small start-
up times and sustainable playback rates. In this work, we
address the challenges underlying the problem of near Video-
on-Demand (nVoD) using P2P systems, and provide evidence
that high-quality nVoD is feasible. In particular, we investigate
the scheduling problem of efficiently disseminating the blocks of
a video file in a P2P mesh-based system, and show scheduling
algorithm can provide significant benefits and the experimental
results will show that load sharing scheduling performs
significantly better than other dynamic algorithm, network
coding.
Keywords: Networks, VoD, nVoD, P2P.
1. Introduction
Video-on-demand (VoD) systems provide multimedia
services offering more flexibility and convenience to users
by allowing them to watch any kind of video at any point in
time. Such systems are capable of delivering the requested
information and responsible for providing continuous
multimedia visualization [5].
Currently, the traffic generated by P2P systems accounts
for a major fraction of the Internet traffic today, and is
bound to increase. The increasingly large volume of P2P
traffic highlights the importance of caching such traffic to
reduce the cost incurred by Internet Services Providers
(ISPs) and alleviate the load on the Internet backbone.
We are faced with a problem of delivering quality video
to a single receiver computer. In the streaming scenarios,
the entire video is not always available at every peer
machine and/or it would not be feasible to transmit the
entire video from a single peer ,for example, that would
overload a particular peer. The beauty of streaming is
obviously the fact that we don’t need to have the entire video
downloaded before the play out begins [6][10]. We can
simply split the video file, identify the peers that have the
segments of interest available, request these segments from
the peers, receive them and play them out.
An important requirement of a VoD service is scalability,
i.e., to be able to support a large number of users, as a
typical video stream imposes a heavy burden both on the
network and the system resources e.g. disk I/O of the server.
The multicasting paradigm has been proposed to address the
scalability issues. However, these systems require a
multicast-enabled infrastructure, which unfortunately has
never materialized. Peer-to-Peer networks promise to
provide scalable distribution solutions without infrastructure
support.
80
The difficulty lies in the fact that users need to receive
blocks “sequentially” in order to watch the movie while
downloading, and, unlike streaming systems, the users may
be interested in different parts of the movie, and may
compete for system resources. In other words, we assume
linear viewing, but we allow the users to join at arbitrary
times. The resources especially network bandwidth of the
server are limited, and hence users contribute their own
resources to the system. Users organize themselves in an
unstructured overlay mesh which resembles a random
graph. The goal then is to design a P2P system which meets
the VoD requirements, while maintaining a high utilization
of the system resources [10].
We study algorithms that provide the users with a high-
quality VoD service while ensuring a high utilization of the
system resources. We evaluate our algorithm such as
segment scheduling using both extensive simulations and
real experiments under different user arrival/departure
patterns. The results will show that load sharing scheduling
algorithm will be able to improve throughput for bulk data
transfer and scheduling that results in high system
throughput while delivering content “pseudo sequentially”,
to provide efficient VoD with small setup delays as
compared to other dynamic algorithms such as Segment
Scheduling and Network Coding[1][2][6].
In this paper we are implementing Scheduling which
takes Segment Scheduling in which the entire video is
divided into segments once the play out begins. It takes
video in the form of segments, define the segments, identify
the peers that have segments of interest available, request
these segments from the peers , receive them and play them
out. Load sharing Scheduling algorithm will improve
performance by increasing sender’s bandwidth, dividing
segments based on loads and the number of segments and
decreasing number of missed segments. Section 2 describes
Architecture of the peer to peer system with load sharing
scheduling algorithm. Section 3 describes brief description
of algorithm. Section 4 describes the implementation of the
whole algorithm, Section 5 describes simulations and
Section 6 presents our conclusion.
2. Architecture and Environment
P2P-VoD system has the following major components:
(a)A set of servers as the source of content (e.g., movies);
(b)A set of trackers to help peers connect to other peers to
share the same content;
(c) A bootstrap server to help peers to find a suitable tracker
(e.g. based on which geographical region the peer is
located), and to perform other bootstrapping functions;
(IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 9, September 2010
(d)Other servers such as log servers for logging significant
events for data measurement, and transit servers for helping
peers in the system [11].
We assume a large number of users interested in some
video content, which initially exists on a special peer that
we call the server. Users arrive at random points in time,
and want to watch the video sequentially from the beginning
of the server are limited, and hence, users should contribute
their own resources to the system. The upload and download
capacities of the users are also limited and typically
asymmetric. A client joins the system by contacting a central
tracker. This tracker gives the client a small subset of active
nodes .The client then contacts each of these nodes and joins
the network. At any point in time, a node is connected to a
small subset of the active nodes, and can exchange content
and control messages only with them. We call this subset
the neighborhood of the node.The neighborhood changes as
a result of node arrivals and departures, and because nodes
periodically try to find new neighbors to increase their
download rates. We assume cooperative nodes. The file is
divided into a number of segments, which are further
divided into blocks. The system is media codec agnostic,
hence, nodes need to download all blocks; if a block is not
available when needed, the video pauses and this is
undesirable. Clients have enough storage to keep all the
blocks they have downloaded.
Our system divides the constant stream of data into
stripes to improve performance and robustness. In a peer-to-
peer system, the stream of data is dis-rupted whenever a
client leaves the system either due to a failure or a regular
disconnects. Since clients receive pieces of the content from
different senders, they can continue to receive some data
even if one of the senders disconnects. To further hide
disruption from the user, a client keeps a buffer of several
seconds of data. When a client reconnects after being cut off
from a sender, the buffer allows the video to play smoothly
as the client catches up on the data that was missed during
the disconnection. In a one-directional live video streaming
system, it is allowable for the video to be viewed a few
seconds after its creation.
Figure 1. System Architecture of Video on demand
 (IJCNS) International Journal of Computer and Network Security, 81
The goals of our system include the following:
• To ensure low set up time and a high sustainable
playback rate for all users, regardless of their
arrival time.
• We are also interested in increasing the total number
of blocks exchanged per round, which we call
throughput, and the total server bandwidth.
3. Related Work
The overall throughput improves if all the nodes seek to
improve the diversity of segments in the network. If the
segment policy is to upload a block from a lesser represented
segment whenever possible throughput improves
significantly for both existing and new nodes [15] [19].
We are faced with a problem of delivering quality video
to a single receiver computer. In the streaming scenarios,
the entire video is not always available at every peer
machine and/or it would not be feasible to transmit the
entire video from a single peer.
It is important that we provide a continuous supply of the
video segments once the play out begins. If only a few
segments are missing once in a while, the video quality will
still be acceptable by most standards. If too many segments
are missing the video and the audio quality will suffer and
the media will not be useful. A missing segment does not
always indicate network failure (due to congestion or
other problems). It may simply mean that the segment was
not available at the receiver’s media player at the time it was
supposed to be rendered, i.e. the segment deadline was
missed. The main problem that we are solving is creating a
schedule that minimizes the number of video segments
missing their deadlines [14][15][18][19].
Load Sharing Scheduling Algorithm provides track of
every sender’s estimated load. Before we can sort the list of
suppliers for segments, where segment has n potential
suppliers, we create a look-ahead estimated load, i.e. what
would be the load of each one of those potential suppliers if
segment s was to be assigned to them. Once we have these
look-ahead estimated loads, we can sort the list of potential
suppliers in the increasing order of the estimated load. Since
we do not have a guarantee that the supplier with the
smallest estimated load is suitable to deliver segments, we
iterate over the list of potential suppliers. Algorithm
minimizes the number of missed segments and the easiest
way to do this is to compare it against a couple of other
known scheduling algorithms and the results show that that
load sharing scheduling improves the throughput of the
system and decrease missed segments[20].
4. Load Sharing Scheduling Algorithm
Vol. 2, No. 9, September 2010
Our algorithm hinges on having a good estimate of how
well-represented a segment is. This estimate should include
nodes that have the complete segment, and those that have
partially downloaded the segment. In our implementation,
the tracker monitors the rarity of segments in the network.
Clients in our system report the fraction of blocks they have
received from each segment. Those fractions are used to
estimate the popularity of the segments; for example, a
segment is considered under-represented if the vast majority
of nodes have very few blocks from that segment [14] [15].
The primary objective of the scheduling algorithm is to
create a schedule such that all requested video segments are
delivered to the receiver before their respective deadlines. If
that is impossible to achieve given insufficient resources,
etc., we want to minimize the number of segments missed.
We also have two secondary objectives. We want to make
efficient use of the bandwidth and avoid transmitting
segments before they are required because there is no
guarantee that they will even be used. Finally, since we do
not want to overload any of the senders, we make sure that
the peers are load balanced. The sender for a particular
segment is selected based on the estimated load of each
sender. The estimated load of a sender is the amount of
work time spent transmitting segments that the sender has
assigned by the schedule at a particular instance of time.
The time it takes a particular sender to transmit a segment
depends on the segment size and the sender bandwidth. We
predict the load of each sender by temporarily assigning the
next scheduled segment to each sender. We select the sender
with the smallest predicted estimated load. This ensures that
the load is shared among all the senders. The proper
segment transmission start time is also most essential for a
successful schedule. We schedule each segment to arrive at
the receiver a fixed amount of time before its deadline thus
fixing the client buffer. This ensures the least amount of
bandwidth wasted on unsolicited video segments.
In situations where senders do not have all segments
available, we must make sure that we do not commit a
sender who is the only one that can deliver particular
segments to do work delivering other segments that could be
delivered by other senders. When determining the
appropriate peer to deliver a segment, we must therefore
examine the number of potential senders that have the
segment available. It is usually more difficult to meet the
deadline of a segment that has fewer potential suppliers [4]
[10] [14] [15]. For this reason, the algorithm first calculates
the number of potential suppliers for each segment and the
segments with least potential suppliers are scheduled first.
That is, the segments with one potential supplier are
scheduled first, then segments with two potential suppliers,
82 (IJCNS) International Journal of Computer and Network Security,
then three and so on. This is a potential area of improving
the algorithm in the future because it is not always necessary
to schedule the segments with the least potential suppliers
first. It is still possible to change segment scheduling order
from the order of the number of potential suppliers and still
create an efficient schedule where all segment deadlines are
met. The proper segment transmission start time is also
most essential for a successful schedule. We schedule each
segment to arrive at the receiver a fixed amount of time
before its deadline thus fixing the client buffer. This ensures
the least amount of bandwidth wasted on unsolicited video
segments [16] [18].
In the most general form we are given a set of n video
segments, S = {S1, S2, . . . , Sn}, with an associated set of
segment lengths, L = {L1, L2, . . . , Ln}, and a set of
segment deadlines, D = {D1, D2, . . . , Dn}. We also have a
set of m peers, P = {P1, P2, . . . , Pm} with an associated set
of peer bandwidths, B = {B1, B2, . . . , Bm}[20]. Finally, we
are given the set of segment ranges available at each peer.
Since typically peers hold contiguous ranges of segments,
we assume that the segment range at each peer is simply
given by the highest segment number available. We assume
that all segments with lower segment numbers are also
available at that peer. The set of available segments is given
by A = {A1, A2, . . . , Am}. We need to create a schedule J
where each segment has an assigned peer and transmission
start time such that the segment will be transmitted to the
receiver before its deadline. Since this may not always be
possible and missed segments must be taken into
consideration, we want to minimize the number of segments
that miss their deadlines. We have the additional constraint
that the schedule cannot exceed the incoming receiver
bandwidth.
Consider an instance of the segment scheduling problem
where we are given a set of n segments.
S = {S1, S2,..., Sn} and a set of m peers
P = {P1, P2,..., Pm}. We apply two restrictions:
1) There is only one sender peer available, i.e. m = 1.
2) The sender peer has all the segments available.
The segment transmissions are the tasks that need to be
scheduled. The release time of each segment transmission is
0. Since we only have one sender, clearly only one segment
can be transmitted at a time.
The execution length of each task is the segment
transmission time, which can be calculated from the
Segment length and the sender’s bandwidth. Every segment
still has a deadline. At this point, it should be obvious that
we have an instance of sequencing the Sender’s problem to
be solved by our Efficient Scheduling algorithm.
Increasing the average sender bandwidth has very little
effect on the execution time but a higher average sender
Vol. 2, No. 9, September 2010
bandwidth decreases the number of missed segments which
solves the problem of missing segments. It’s possible that
we will have any number of segments with n potential
suppliers; we must iterate over the list of segments with n
potential suppliers. If we have large-scale video, we can
simply split the video file into well defined segments,
identify the peers that have the segments of interest
available, request these segments from the peers receive
them and play them out. In situations where senders do not
have all segments available, we must make sure that we do
not commit a sender who is the only one that can deliver
particular segments to do work delivering other segments
that could be delivered by other senders.
The first task is to create the segment supplier table. The
reason for creating this table is to enable actual schedule
creation code to iterate the segments in the increasing order
of the number of segment suppliers. The Segment table
should fetch data in such a way that it can be easy to
retrieve. For every potential sender p for segment s, we must
confirm that the sender p is suitable to deliver segment s.
This means that sender p must be able to deliver segment s
before its deadline and it cannot overload the receiver, i.e.
the resulting bandwidth at the receiver must be ≤ maximum
Bandwidth. Secondly, we create schedule that minimizes the
number of video segments missing their deadlines.
Increasing the average sender bandwidth has very little
effect on the execution time but a higher average sender
bandwidth decreases the number of missed segments which
solves the problem of missing segments. It’s possible that
we will have any number of segments with n potential
suppliers; we must iterate over the list of segments with n
potential suppliers. This data is readily available from the
segment supplier table. For every segment with n potential
suppliers, we need to determine its sender and transmission
start time. Since we want to schedule the segments with
least potential suppliers first, we must iterate over the
collection of segment supplier table indices in the increasing
table index order. It’s possible that we will have any number
of segments with n potential suppliers; we must iterate over
the list of segments with n potential suppliers. This data is
readily available from the segment supplier table. For every
segment with n potential suppliers, we need to determine its
sender and transmission start time.
Here, schedule creation iterates the segments in the
increasing order of the number of segment suppliers. The
data is arranged in such a way that it is easy to retrieve. For
every potential sender p for segment s, we must confirm that
the sender p is suitable to deliver segment s. Then, the
segments are transferred from senders to the receivers with
the least segment first. The step 5-10 iterates the loop for
loading peers. The segments are then loaded at the client
 (IJCNS) International Journal of Computer and Network Security, 83
side with the increased bandwidth at the server side. The
bandwidth of client should not exceed the maximum
available bandwidth at Server side. Finally, the scheduled
peers are returned.
For every potential sender p for segment s, we must
confirm that the sender p is suitable to deliver segment s.
This means that sender p must be able to deliver segment s
before its deadline and it cannot overload the receiver, i.e.
the resulting bandwidth at the receiver must be ≤ maximum
bandwidth. As the initial guess, we set the start time to be
such that segment s will arrive at the receiver right before its
deadline and before we confirm this transmission slot for
segment s we must make sure that it doesn’t violate the
maximum bandwidth constraint.
Figure 2. Load Sharing Scheduling Algorithm Replication
Strategy of Segments
Assuming each peer contributes with some amount of hard
disc storage, a P2P storage system is formed by the entire
viewer population, each of them containing segments. Once
all the segments are available locally, the segment is
advertised to other Peers. The aim of replication strategy is
to make segments available to every user in the shortest time
possible in order to meet with viewing demands. Design
issues regarding replication strategies contemplate:
(i) Allowing multiple movies to be cached if there is room
on the hard disc. This is referred as multiple movie cache
(MVC); and lets a peer watching a movie upload a different
movie at the same time.
Vol. 2, No. 9, September 2010
(ii) To pre-fetch or not to pre-fetch;
while pre-fetching could improve performance, it could also
waste uplink bandwidth resources of the peer.
(iii) Selecting which segment or movie to remove when the
disc cache is full; preferred choices for many caching
algorithms are least recently used (LRU) or least frequent
used (LFU).
Content Discovery:
Together with a good replication strategy, peers must also be
able to learn who is holding the content they need without
introducing too much overhead into the system. P2P systems
depend on the following methods for content discovery:
(i) A tracker; to keep track of which peers are replicating
what part of the movie;
(ii) DHT; used to assign movies to trackers for load
balancing purposes.
Congestion Control
• Rate Control-Match the rate of the video stream to the
maximum available bandwidth thus reducing congestion
and segment loss. Without rate control segments which
would exceed the maximum bandwidth would be discarded.
This approach focuses on the transport concept.
• Rate-adaptive video encoding -Use compression to make
video feeds more practical and bandwidth efficient. This
approach focuses on the compression concept.
• Rate Shaping -This approach is a combination of the
previous two. The video feed is being re-coded with rate-
adaptive video encoding and rate control makes sure there is
no loss in segments.
5. Performance Evaluation
In this section we evaluate the performance of both
segment scheduling and load sharing scheduling algorithm.
Initially, we will present data that compares the segment
rate of both the algorithms. Then Load sharing Scheduling
algorithm will be compared with another dynamic
algorithm. And then the results will clearly show that load
sharing scheduling algorithm is better than segment
scheduling especially under the missed segments.
5.1. Simulation Set Up:
Matlab Software was used for all simulations. Along with
load sharing scheduling algorithm network coding and
segment scheduling will also be simulated for benchmark
comparison purposes. In general, the behavior of the
algorithms is rather intuitive. For all 3 algorithms,
increasing the number of senders has very little effect on
the execution time but having more senders’ decreases the
number of missed segments. Similarly, increasing the
average sender bandwidth has very little effect on the
execution time but a higher average sender bandwidth
84 (IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 9, September 2010

decreases the number of missed segments. Finally, simulated scheduling algorithm with increased bandwidth
increasing the bit rate has similar effects, i.e. it has little on server side systems used in our experiments.
effect on the execution time but increasing the bit rate
increases the number of missed segments[11][13]. Table 1: System Parameters.
The parameters that we should vary include:
Parameters. Values
• Average segment size, i.e. video quality (bit rate) Segments 10
• Segment count (shorter vs. longer videos) Potential Suppliers 4
• Number of senders Bandwidth 100kbps
• Bandwidth of senders bandwidth1 80kbps
Deadline 60 seconds
• Receiver’s bandwidth
Size 250kbs
For each scenario, we should compare the results of each Available 2
algorithm according to the following criteria:
• Number of missed segments 5.2 Impact of missed Segments:
• Running time The Graph here shows the segment loss is less in load
In the current evaluation, the maximum receiver bandwidth sharing scheduling algorithm as compared to other dynamic
constraint has been ignored for all test cases. Since we are algorithms. Measuring the available bandwidth is of great
most interested in the effects of the bit rate on the number of importance for predicting the end-to-end performance of
missed segments and the algorithm execution time, most applications, for dynamic path selection and traffic
results provide an execution time or number of missed engineering, and for selecting between a numbers of
segments vs. bit rate graphs. More specifically, we plot the differentiated classes of service. The available bandwidth is
following result graphs: an important metric for several applications, such as grid,
a. Execution time/missed segments vs. time for varying video and voice streaming, overlay routing, p2p file
number of segments transfers, server selection, and inter domain path
b. Execution time/missed segments vs. time for varying monitoring. The overall throughput improves if all the
number of senders nodes seek to improve the diversity of segments in the
c. Execution time/missed segments vs. time for a varying network.
average sender bandwidth.
d. Missed segment and execution time algorithm
comparison graph.
On the other hand, increasing the number of segments
(video length) has little effect on the number of missed
segments or at least little effect on the bit rate at which the
number of missed segments starts to increases but in the
case of the segment scheduling algorithm, longer videos
take more time to schedule. This could possibly be caused by
the fact that those 2 algorithms are much faster than the
Load Sharing Scheduling algorithm and the inputs provided Graph1. Bit Rate v/s Time.
in the tests do not stress the algorithms enough to product From the above graph we can conclude that as the
trends in the execution time graphs. transmission time increases for the senders the amount of
When comparing the algorithms, the general trends data that can be sent through the sender of a particular
exhibited by all 3 of them are very similar. When comparing segment, the data rate of the segment decreases.
actual values, it becomes evident that the Load Sharing
Scheduling algorithm is superior to the other 2 when it
comes to minimizing the number of missed segments but in
most cases, this algorithm takes a lot to compute the results.
This table-1 summarizes various system parameters
which are included in the simulation calculation and the
system used for our experiments. Before presenting
empirical results, we present the simulation model as
follows. Table 1 summarizes the configuration parameters of
Graph 2. Time v/s Bit rate for varying Segments
 (IJCNS) International Journal of Computer and Network Security, 85
From the above graph we can conclude that as transmission
time increases for the senders the number of segments that it
can handle in any given time reduces and hence the bit rate
decreases.
5.3 Scalability:
Generally speaking, scalability can be defined as the
adaptability to changes in the peer-to-peer system size, load
extent and nature of the load. That is, the network load
should be distributed evenly among the peers, which means
that every peer should be aware of approximately the same
number of other peers. From the data it can be concluded
that our algorithm is more scalable than other dynamic
algorithm such as segment scheduling and network coding.
The second approach to deal with the scalability issue of
video streaming systems is to use P2P load sharing. “P2P
networking architectures receive a lot of attention nowadays,
as they enable a variety of new applications that can take
advantage of the distributed storage and increased
computing resources offered by such networks”. Their
advantage resides in their ability for self organization,
bandwidth scalability, and network path redundancy, which
are all very attractive features for effective delivery of media
streams over networks .Also the space is saved for the peers
as the replicas will be deleted.
6. Conclusion
The success of the peer-to-peer paradigm in both file
distribution and live streaming application derived in the
adoption of this technology for the delivery of video-on-
demand content. Fast response time is a technology factor
that end-users demand. Considerable research has been
performed to find better ways to arrange data such that fast
response time can be achieved by increasing throughput and
maximum bandwidth with low startup delay. Load sharing
scheduling is better for improving the performance of peer-
to-peer systems. Though further work is required towards a
better understanding of the efficacy of our algorithms in
more realistic scenarios, we believe that the guidelines
proposed in this paper can be used to build high-
performance P2P VoD systems. Thus, high quality VoD is
feasible with high playback rates.
Our system was designed to guarantee that the video
starts playing shortly after the beginning of the download,
and progresses without interruptions until the end of the
movie. While we have made an implicit assumption that
users watch the entire video linearly, we believe that the
same principles used in our system could be extended to
support non-linear viewing, i.e., where users would be able
to start watching from arbitrary points in the video and
perform fast forward and rewind operations. However, if the
user desires to watch a part of the video that is not available
Vol. 2, No. 9, September 2010
locally, then the user will suffer a (moderate) waiting time
as the system searches for segments of peers to download the
desired content from.
References
[1] Gnutella, “http://gnutella.wego.com/”.
[2] Y.-H. Chu, S. G. Rao, and H. Zhang, “A case for end
system multicast,” in Measurement and Modeling of
Computer Systems, 2000.
[3] B. Cohen, “Incentives Build Robustness in BitTorrent,”
in Workshop on Economics of Peer-to-Peer Systems,
2003.
[4] V. Agarwal and R. Rejaie. Adaptive Multi-source
Streaming in Heterogeneous Peer-to-Peer Networks In
MMCN, 2005.
[5] Y. Huang, Tom Z.J. Fu, Dah-Ming Chiu, J.C.S. Lui, and
C. Huang, “Challenges, design and analysis of a large-
scale p2p-vod system,” Proc ACM SIGCOMM 2008, pp.
375-388, 2008.
[6] X. Zhang, G. Neglia, J. Kurose, and D. Towsley. On the
benefits of random linear coding for unicast applications
in disruption tolerant networks. Second Workshop on
Network Coding,Theory, and Applications (NETCOD),
2006.
[7] Wikipedia, P2P http://en.wikipedia.org/wiki/P2P,
accessed 20/11/2006.
[8] M. R. Garey and D. J. Johnson, Computers and
intractability: a guide to the theory of NP-completeness.
New York: W.H. Freeman, 1979.
[9] C. Gkantsidis, J. Miller, and P. Rodriguez,
“Comprehensive view of a live network coding P2P
system”, in Proc. ACM SIGCOMM/USENIX IMC’06,
Brasil, October 2006.
[10] S. Deering and D. Cheriton, “Multicast routing in
datagram internetworks and extended LANs”, ACM
Transaction on Computer Systems, vo. 8, no. 2, pp. 85-
110, May 1990.
[11] S. Banerjee, B. Bhattacharjee, and C. Kommareddy,
“Scalable application layer multicast”, in Proc. ACM
SIGCOMM’02, Pittsburgh, PA, August 2002.
[12] M. Castro, P. Druschel, A.-M. Kermarrec, A. Nandi,
A. Rowstron and A. Singh, “SplitStream: High-
bandwidth multicast in cooperative environments”, in
Proc. ACM SOSP’03, New York, USA, October 2003.
[13] S. Acendanski, S. Deb, M. Medard, and R. Koetter,
“How good is random linear coding based distributed
networked storage?,” in NetCod, 2005.
[14] PPLive internet site. http://www.pplive.com.
[15] Xiaojun Hei, Chao Liang, Jian Liang, Yong Liu and
Keith Ross, "Insight into PPLive: A Measurement Study
86 (IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 9, September 2010

of a Large-Scale P2P IPTV System", Proc of WWW

2006 workshop of IPTV services over World Wide Web.
[16] “PeerSim P2P Simulator,” 2005, accessed 01-May-
2006. [Online]. Available:
http://peersim.sourceforge.net/.
[17] [Agr02] R. Agrawal and V. Subramanian, “Optimality
of Certain Channel Aware Scheduling Policies,” Proc. of
2002 Allerton Conference on Communication,Control
and Computing, Oct. 2002.
[18] J.A. Pouwelse, J.R. Taal, R.L. Langendijk, D.H.J.
Epema,, “Real-time Video Delivery using Peer-to-Peer
Barterin Networks and Multiple
DescriptionCoding”http://ishare.ewi.tudelft.nl/public/Po
uwelseTaal_SMC2 004.pdf.
[19] R. Ahlswede, N. Cai, S.-Y. R. Li, and R. W. Yeung,
“Network information flow,”
[20]H. Kopetz. Real-time systems-design principles for
distributed embedded applications. Kluwer Academic
Publishers, 1997.

Authors Profile

S.Nagaprasad Sri. Received the Bacholar

of Computer Applications (B.C.A.) From
Osmania University, Hyderabad, in 2001,
M.Sc (I.T.) From Sikkim Manipal
University, Manipal in 2003 and M.Tech
(C.S.) From Allahabad Agricultural
University, Allahabad in 2005. Presently
Pursing Ph.D in Computer Science &
Engineering from Aacharya Nagarjuna University, Guntur.

Prof. A.Vinay Babu obtained his

Bachelors degree in Electronics &
Communication Engineering from Osmania
University. Has duel Masters degree, one in
Computer Science & Engg and the other
one is in ECE from JNTU. He obtained his
PhD from JNTU, Hyderabad. His research
area is Data Mining and Image processing.

Prof. K.Madhukar received his Masters

in Engineering Physics and Instrumentation
from Osmania University in 1980 and PhD
from Osmania University in 1989.
Presently he is Professor and Head Dept of
Physics and Electronics, Nizam College,
Osmania University, Hyderabad. He
worked as ICT4D programme specialist in
United Nations Development Programme
(UNDP) for more than four years. His research area is Data
mining, Knowledge Discovery and Networks. Eight students
working for their doctorial degree under his supervision.