• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Insights on On-demand Media Streaming Progress
 

Insights on On-demand Media Streaming Progress

on

  • 413 views

This paper develops analytical models that characterize the behavior of on-demand stored media content delivery using Bit Torrent-like protocols. ...

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).

Statistics

Views

Total Views
413
Views on SlideShare
413
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Insights on On-demand Media Streaming Progress Insights on On-demand Media Streaming Progress Presentation Transcript

    • Guide: Presented by: Mr. Jayakumar S. , M.E. Shonit Kichloo - 1030920061 Assistant Professor(O.G.) Sovan Kundu - 1030920063 Sumit Kumar - 1030920065 Vighnesh Krishnan - 1030920070
    • …..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).
    • …..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.
    • …..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.
    • …..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.
    • …..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.
    • …..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.
    • …..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
    • …..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.
    • …..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.
    • …..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.
    • …..Architecture Diagram
    • ….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
    • …..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
    • …..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).
    • …..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.
    • …..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).
    • …..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.
    • …..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
    • …..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:
    • …..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
    • …..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); }
    • …..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 { } }
    • …..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;
    • …..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; } } }
    • …..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; }
    • …..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.
    • …..Results
    • …..Snapshots
    • …..Snapshots
    • …..Snapshots
    • …..Snapshots
    • …..Snapshots
    • …..Snapshots
    • …..Snapshots
    • …..Snapshots
    • …..Snapshots
    • …..Snapshots
    • …..Snapshots
    • …..Snapshots
    • …..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.
    • …..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.
    • …..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.