This paper develops analytical models that characterize the behavior of on-demand stored media content delivery using Bit Torrent-like protocols. The models capture the effects of different piece selection policies, including Rarest-First, In-Order, and two probabilistic policies (Portion and Zipf).

1. Guide: Presented by:
Mr. Jayakumar S. , M.E. Shonit Kichloo - 1030920061
Assistant Professor(O.G.) Sovan Kundu - 1030920063
Sumit Kumar - 1030920065
Vighnesh Krishnan - 1030920070

2. …..Introduction
 This paper develops analytical models that characterize
the behavior of on-demand stored media content delivery
using Bit Torrent-like protocols.
 The models capture the effects of different piece
selection policies, including Rarest-First, In-Order, and
two probabilistic policies (Portion and Zipf).

3. …..Explanation
 Streaming media is video or audio content sent in
compressed form over the Internet and played
immediately, rather than being saved to the hard drive .
 With streaming media, a user does not have to wait to
download a file to play it. Because the media is sent in a
continuous stream of data it can play as it arrives. Users
can pause, rewind or fast-forward, just as they could with
a downloaded file, unless the content is being streamed
live.

4. …..Abstract
 Our models provide insight into system behaviour and help explain the
sluggishness of the system with In-Order streaming.
 We use the models to compare different retrieval policies across a wide
range of system parameters, including peer arrival rate,
upload/download bandwidth, and seed residence time.
 We also provide quantitative results on the startup delays and retrieval
times for streaming media delivery. Our results provide insights into the
design tradeoffs for on-demand media streaming in peer-to-peer
networks.
 Finally, the models are validated using simulations.

5. …..Terminologies
 On-demand streaming: Streaming media content that
is transmitted to the client upon request.
 Peer-to-peer communication: A model in which each
party has the same capabilities and either party can
initiate a communication session.
 BitTorrent : A peer-to-peer (p2p) file sharing protocol
designed to reduce the bandwidth required to transfer
files.

6. …..Existing System
 P2P networks are autonomous systems with the
advantages of self-organization and self-adaptation.
 On-demand streaming of stored media files differs in
subtle but important ways from live media streaming.
 First, live streaming typically involves only a single
streaming source, whereas stored media streaming can
involve many providers of content.

7. …..Existing System
 Second, the stored media case involves retrieving the
entire media object, while the live streaming case allows
peers to join at any time (i.e., mid-stream), without
retrieving earlier portions of the stream.
 Third, the peers in a live streaming scenario have a
shared temporal content focus, while the stored media
case has greater temporal diversity of requests.

8. …..Disadvantages
 The issue of “startup delay” differs in the two scenarios
(i.e., joining an existing stream versus starting a new
stream).
 The stored media case is general: The retrieval rate could
be slower than, faster than, or the same as the media
playback rate, or even vary with time

9. …..Proposed System
 We develop detailed analytical models that explicitly
consider piece selection policies.
 The models accurately predict the transition rate of
downloader’s to seeds, as well as the steady-state swarm
population size and mix.
 The models provide important insights into the efficiency
of on-demand media streaming in P2P networks.

10. …..Proposed System
 The models explicitly consider the number of upload and
download connections, rather than just the total network
bandwidth.
 This formulation provides the flexibility to model
concurrent connections and consider the effect of
network asymmetry on the system performance.

11. …..Advantages
The advantage of our models capture performance
differences between various policies and configuration
details (e.g., piece selection policies, upload bandwidth)
and allow us to answer questions related to the efficiency
and user-perceived performance of BitTorrent-like on-
demand streaming protocols.

12. …..Architecture Diagram

13. ….System Requirements
 Hardware:
Intel/AMD processors
RAM - 128 MB or higher
Video Card – 128 MB or higher
Internet connectivity
 Software:
OS – Windows 2000 or higher
Media Player – WMP/ Video LAN Player
Streaming Protocols – BitTorrent

14. …..Modules
 1ST PHASE
DOWNLOAD PROGRESS
 MODEL ASSUMPTIONS
 SYSTEM EFFICIENCY
 BASELINE MODEL: RAREST-FIRST
 IN-ORDER PIECE SELECTION (FCFS)
 2ND PHASE
SEQUENTIAL PROGRESS
 RANDOM PIECE SELECTION
 PORTION PIECE SELECTION
 ZIPF PIECE SELECTION
REPLICATION

15. …..Download Progress
MODEL ASSUMPTIONS :
In this module we construct a peer system; it acts as a both client and server process. We
consider a single swarm (file) in a BitTorrent-like system with seeds and down loaders. Without
loss of generality, we assume that this file is of fixed (unit) size. The target file is divided into
number of pieces or packets or chunk and is encoded for playback at rate. Each peer is allowed
concurrent upload connections and concurrent download connections.
BASELINE MODEL: RAREST-FIRST :
It gives good scalability by trying to propagate the chunks of a file to as many peers as quickly
as possible. The expected rarest chunk is the latest chunk distributed by the server that is
missing from all the local peers’ buffer. The main point is that the search for missing chunks
starts from the latest chunk. We characterize the system behavior when downloader uses the
Rarest-First piece selection policy (the default in Bit Torrent).

16. …..Download Progress
SYSTEM EFFICIENCY :
In this model we derive the system efficiency (also called file sharing effectiveness) for the
Rarest-First piece selection policy. Each peer knows which pieces are available at other peers in
the system, and peers try to download the pieces they need. When a peer connects with other
peers, it tries to download a needed piece that is rarest among the pool of pieces available
from its neighboring peers.
IN-ORDER PIECE SELECTION (FCFS) :
The model presented here assumes that the uploading peers do not purge the unfulfilled
requests after each round. Rather, the pending requests at a providing peer are queued until
they are serviced. The request queues are serviced using First-Come–First-Serve (FCFS). In the
purging model, each downloader issues download requests per round; in the queue-based
model, downloader operate in a closed-loop fashion, with at most download outstanding
requests at any time.

17. …..Sequential Progress
RANDOM PIECE SELECTION :
In this module we have to implement the random piece selection policy. The analysis of
sequential progress for the Random piece selection policy proceeds as follows. Assume that the
file of interest has M pieces, numbered from 1 to M. The downloader retrieves one piece per
unit time using a Bit Torrent-like protocol, with the pieces chosen uniformly at random. It
ignores the numerical ordering of the pieces.
PORTION PIECE SELECTION :
This module used to get the portion of the missing packet or file or chunk at the receiver end.
Our analysis considers the sequential progresses achieved after k out of M pieces have been
retrieved. More specifically, we are interested in the expected sequential progress E [j|k],
where is the number of useful pieces (at the start of the file).

18. …..Sequential Progress
ZIPF PIECE SELECTION :
In this module we have to implement the Zipf piece selection policy. We again assume that the
missing pieces (except the first missing piece) are uniformly distributed. This module used to
get the portion of the missing packet or file or chunk at the receiver end.
REPLICATION :
This replication process is automatically sending the acknowledgement request to other Peer
forget new file and also other Peer automatically responds to the requested Peer. The responds
Peer listen the entire request from the neighbor Peers and responds to all Peers with in a
second. This process automatically shares the files only the trusted Peer’s in the network.

19. …..Activity Diagram
Send the packet to requested peer
Send File request
Receive the packet and Packet Schedule
Check the Missing Packet
If the Packet are Missing
Send Request corresponding Neighbour Peer
Send Response to requested peer
Merge overall packets
View The File
Yes
Receive the file request from requested peer
Send the packet schedule to requested peer
Generate the packet schedule
Receive the missing packet from neighbor node
NO
Check the Missing Packet If the Packet are missing
Portion selection Process
Yes
NO
Zipf selection Process
Yes
Neighbour Peer If Neighbor peer is ON
Yes Activate Sub ServerNO

20. …..Dataflow Diagram
Peer (Client)
(1….n)
File Downloading
using Sequential
process and
Download process
Server
Peer
(Client)
Send File
Request
Peer
(Server)
Select
Requested
Peers
Maintain All
Peers Info
In DB
Split the
added file into
multiple
packet
Generate
Packet
Schedule
Send the
packet to all
requested
Peers
Maintain
Packet
Schedule
Send packet
Schedule
Information
Receive
the packet
And schedule
information
View File
Level 0:
Level 1:

21. …..Dataflow Diagram
Level 2:
Peer
(Client)
Send File
Request
Peer
(Server)
Select
Requested
Peers
Maintain All
Peers Info
In DB
Split the
added file into
multiple
packet
Generate
Packet
Schedule
Send the
packet to all
requested
Peers
Maintain
Packet
Schedule
Send
packet
Schedule
Information to
all Requested
peer
Receive
the packet
And schedule
information
View File
Check the
missing
packet
Send
missing packet
request to
corresponding
neighbor peer
Validate
Missing
Neighbours
Peer
Send
response to
requested
peer
Not Missing
Peer node off
No
Yes
Send the
Acknowledge
ment to
Subserver
Receive the
acknowledge
ment from
neighbor peer
Sub server
Merge the
over all file
Apply Portion
Piece
selection
Process
Apply Zipf
piece
selection
Process
Added a new
file
Send the file
to its sub
server
Activate the
sub server

22. …..Sample Coding
private void btnBrowseFile_Click(object sender, EventArgs e)
{OpenFileDialog op = new OpenFileDialog();
DialogResult dr = op.ShowDialog();
if (dr == DialogResult.OK)
{
op.OpenFile();
}
if (op.FileName != "")
{
txtSourceFile.Text = op.FileName;
txt_FileName.Text = op.SafeFileName;
FileStream fstream = new FileStream(op.FileName, FileMode.Open, FileAccess.Read);
txt_Size.Text = fstream.Length.ToString();
} }
private void btn_Add_Click(object sender, EventArgs e)
{
CreateFileDirectory();
File.Copy(txtSourceFile.Text,Application.StartupPath + "Files" + pName + "" +
txt_FileName.Text,true);
int myCount = SplitCount(int.Parse(txt_Size.Text.ToString()));
OriginalFileCount = myCount;
SplitFile(txtSourceFile.Text, Application.StartupPath + "Split Files" + pName + "" +
txt_FileName.Text + "", myCount);
}

23. …..Sample Coding
private void CreateFileDirectory()
{
// Specify the directory you want to manipulate.
// string path = @"c:MyDir";
path1 = Application.StartupPath + "Files" + pName + "";
try
{
// Determine whether the directory exists.
if (Directory.Exists(path1))
{
Console.WriteLine("That path exists already.");
return;
}
// Try to create the directory.
DirectoryInfo di = Directory.CreateDirectory(path1);
Console.WriteLine("The directory was created successfully at {0}.", Directory.GetCreationTime(path1));
}
catch (Exception e)
{
Console.WriteLine("The process failed: {0}", e.ToString());
}
finally { }
}

24. …..Sample Coding
Private void SplitFile(string FileInputPath, string FolderOutputPath, int OutputFiles)
{
// Store the file in a byte array
Byte[] byteSource = System.IO.File.ReadAllBytes(FileInputPath);
// Get file info
FileInfo fiSource = new FileInfo(txtSourceFile.Text);
// Calculate the size of each part
int partSize = (int)Math.Ceiling((double)(fiSource.Length / OutputFiles));
// The offset at which to start reading from the source file
int fileOffset = 0;
// Stores the name of each file part
string currPartPath;
// The file stream that will hold each file part
FileStream fsPart;
// Stores the remaining byte length to write to other files
int sizeRemaining = (int)fiSource.Length;

25. …..Sample Coding
// Loop through as many times we need to create the partial files
for (int i = 0; i < OutputFiles; i++)
{
// Store the path of the new part
currPartPath = FolderOutputPath + "" + fiSource.Name + "." + String.Format(@"{0:D4}", i)
+ ".part";
// A filestream for the path
if (!File.Exists(currPartPath))
{
fsPart = new FileStream(currPartPath, FileMode.CreateNew);
sizeRemaining = (int)fiSource.Length - (i * partSize);
if (sizeRemaining < partSize)
{
partSize = sizeRemaining;
}
fsPart.Write(byteSource, fileOffset, partSize);
fsPart.Close();
fileOffset += partSize;
}
}
}

26. …..Sample Coding
private int SplitCount(long FileSize)
{
int splitFileSize = 0;
int FileCount = 0;
int OriginalFileSize = int.Parse(FileSize.ToString());
if (FileSize < 1000000)
{ splitFileSize = 150000;
FileCount = OriginalFileSize / splitFileSize;
}
else if (FileSize > 1000000 && FileSize < 5000000)
{ splitFileSize = 500000;
FileCount = OriginalFileSize / splitFileSize;
}
else if (FileSize > 5000000 && FileSize < 10000000)
{
splitFileSize = 650000;
FileCount = OriginalFileSize / splitFileSize;
}
else if (FileSize > 10000000)
{
splitFileSize = 2000000;
FileCount = OriginalFileSize / splitFileSize;
}
return FileCount;
}

27. …..Results
Fluid model validation results [analytic results use lines; simulation results use points, with
“+” for Rarest-First, circles for In-Order (Naive), and squares
for In-Order (FCFS)]. Top row: Swarm population. Bottom row: Download latency (a), (d)
Effect of arrival rate. (b), (e) Effect of seed residence time. (c), (f) Effect
of upload bandwidth.

28. …..Results

29. …..Snapshots

30. …..Snapshots

31. …..Snapshots

32. …..Snapshots

33. …..Snapshots

34. …..Snapshots

35. …..Snapshots

36. …..Snapshots

37. …..Snapshots

38. …..Snapshots

39. …..Snapshots

40. …..Snapshots

41. …..Future Enhancement
Replication is one of the new concept we implement in this paper. Replication is the
process of sharing information so as to ensure consistency between redundant
resources, such as software or hardware components, to improve reliability, fault-
tolerance, or accessibility. It could be data replication if the same data is stored on
multiple storage devices or computation replication if the same computing task is
executed many times. A computational task is typically replicated in space, i.e. executed
on separate devices, or it could be replicated in time, if it is executed repeatedly on a
single device. This replication process is automatically sending the acknowledgement
request to other Peer forget new file and also other Peer automatically responds to the
requested Peer.

42. …..Conclusion
We developed detailed analytical models to characterize the behavior of BitTorrent-like
protocols for on-demand stored media streaming. Our analysis was made possible by the
fundamental insight that media streaming progress (i.e., the rate at which useful pieces are
obtained by a peer for media playback) is essentially the product of download progress (i.e.,
the rate at which pieces are successfully obtained from the P2P network) and sequential
progress (i.e., the usefulness of the obtained pieces for media playback). Our models explicitly
capture the effects of different piece selection policies, including Rarest-First, two variants of
In-Order, andtwo probabilistic policies. Our models provide insights into the behavior of a P2P
network used for on-demand streaming.

43. …..References
[1] S. Annapu Reddy, C. Gkantsidis, and P. Rodriguez, “Providing video-on-demand using peer-to-
peer networks,” in Proc. IPTV, Edinburgh,Scotland, May 2006, pp. 238–247.
[2] Y. Choe, D. Schuff, J. Dyaberi, and V. Pai, “Improving VoD server efficiencywith
BitTorrent,” in Proc. ACM Multimedia, Augsburg, Germany,Sep. 2007, pp. 117–126.
[3] N. Carlsson and D. Eager, “Peer-assisted on-demand streaming of stored media using
BitTorrent-like protocols,” in Proc. IFIP/TC6Netw., Atlanta, GA, May 2007, pp. 570–581.
[4] N. Carlsson and D. Eager, “Modeling priority-based incentive policies for peer-assisted content
delivery systems,” in Proc. IFIP/TC6 Netw.,Singapore, May 2008, pp. 421–432.
[5] N. Carlsson, D. Eager, and A. Mahanti, “Peer-assisted on-demand video streaming with selfish
peers,” in Proc. IFIP/TC6 Netw., Aachen,Germany, May 2009, pp. 586–599.