DOCSLIB.ORG

Replication Strategies for Streaming Media

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Replication Strategies for Streaming Media “replication-strategies” — 2007/4/24 — 10:56 — page 1 — #1 Research Report No. 2007:03 Replication Strategies for Streaming Media David Erman Department of Telecommunication Systems, School of Engineering, Blekinge Institute of Technology, S–371 79 Karlskrona, Sweden “replication-strategies” — 2007/4/24 — 10:56 — page 2 — #2 °c 2007 by David Erman. All rights reserved. Blekinge Institute of Technology Research Report No. 2007:03 ISSN 1103-1581 Published 2007. Printed by Kaserntryckeriet AB. Karlskrona 2007, Sweden. This publication was typeset using LATEX. “replication-strategies” — 2007/4/24 — 10:56 — page i — #3 Abstract Large-scale, real-time multimedia distribution over the Internet has been the subject of research for a substantial amount of time. A large number of mechanisms, policies, methods and schemes have been proposed for media coding, scheduling and distribution. Internet Protocol (IP) multicast was expected to be the primary transport mechanism for this, though it was never deployed to the expected extent. Recent developments in overlay networks has reactualized the research on multicast, with the consequence that many of the previous mechanisms and schemes are being re-evaluated. This report provides a brief overview of several important techniques for media broad- casting and stream merging, as well as a discussion of traditional IP multicast and overlay multicast. Additionally, we present a proposal for a new distribution system, based on the broadcast and stream merging algorithms in the BitTorrent distribution and repli- cation system. “replication-strategies” — 2007/4/24 — 10:56 — page ii — #4 ii “replication-strategies” — 2007/4/24 — 10:56 — page iii — #5 CONTENTS Contents 1 Introduction 1 1.1 Motivation . 2 1.2 Outline . 3 2 Multicast 5 2.1 IP Multicast . 5 2.2 Application Layer Multicast . 13 2.3 Summary . 17 3 Broadcasting Strategies 19 3.1 Terminology . 19 3.2 Conventional Broadcasting . 20 3.3 Staggered Broadcasting . 20 3.4 Pyramid Schemes . 20 3.5 Staircase Schemes . 22 3.6 Harmonic Schemes . 22 3.7 Hybrid Schemes . 23 3.8 Summary . 23 4 Stream Merging Strategies 25 4.1 Batching . 25 4.2 Piggybacking . 26 4.3 Patching . 28 4.4 Chaining . 30 4.5 Hierarchical and Hybrid Merging . 31 4.6 Summary . 32 5 Caching Strategies 33 5.1 Replacement Policies . 34 5.2 Segment-based Caching . 36 5.3 Smoothing and Pre-fetching . 37 5.4 Summary . 37 iii “replication-strategies” — 2007/4/24 — 10:56 — page iv — #6 CONTENTS 6 BitTorrent Streaming 39 6.1 BitTorrent . 39 6.2 State of the Art . 41 6.3 Streaming Extensions for BitTorrent . 42 6.4 Summary . 45 7 Summary and Future Work 47 7.1 Future Work . 47 iv “replication-strategies” — 2007/4/24 — 10:56 — page v — #7 LIST OF FIGURES List of Figures 2.1 Group Communication. 5 2.2 Multicast architectures. 15 3.1 Stream parameters. 20 4.1 Batching methods for a single video object. 26 4.2 Piggybacking system state . 27 4.3 Chaining . 31 v “replication-strategies” — 2007/4/24 — 10:56 — page vi — #8 LIST OF FIGURES vi “replication-strategies” — 2007/4/24 — 10:56 — page vii — #9 LIST OF TABLES List of Tables 2.1 Group communication types. 7 3.1 Pagoda segment-to-channel mapping . 23 vii “replication-strategies” — 2007/4/24 — 10:56 — page viii — #10 LIST OF TABLES viii “replication-strategies” — 2007/4/24 — 10:56 — page 1 — #11 Chapter 1 Introduction One of the applications expected to become the next “killer application” on the Internet is large-scale multimedia distribution. One indicator of this is the development of the Internet Multimedia Subsystem (IMS). The IMS is a result of work of the 3rd Generation Partnership Project (3GPP), and was first published as part of release 5 of the Univer- sal Mobile Telecommunications System (UMTS) in March 2003 [1]. Multimedia is thus considered as being an integral part of the next generation telecommunication networks, and the Internet as the primary distribution channel for this media. The IMS is not the first proposed media-related killer application for the Internet. A multitude of media applications were suggested in connection with the appearance of Internet Protocol Multicast (IPMC) [2–4]. IPMC provided a method to send IP datagrams to several recipients without increasing the amount of bandwidth needed to do this. In effect, IPMC provided a service similar to that of the television broadcasting service, where clients choose to subscribe to a specific TV or multicast channel. Though IPMC was a promising technical solution, it also posed new and difficult problems that did not need to be considered in traditional unicast IP. For instance, there is no notion of a receiver group in unicast communication, and new mechanisms and protocols were needed to address issues of group management, such as the latency of joining and leaving a group, how to construct multicast trees, etc. Additionally, the acknowledge-based congestion control algorithm used in unicast Transport Control Protocol (TCP) could not be used for multicast without modifications, as it would result in an overload of incoming acknowledgements to the source, effectively performing a distributed denial- of-service attack. As IPMC was not natively implemented in most IP routers at the time, the Multicast Backbone (MBone) [5] was put forth as an interim solution until router manufacturers got around to implementing IPMC in their hardware. The MBone provides an overlay network, which connects IPMC capable parts of the Internet via unicast links. However, connecting to the MBone requires administrative support, and not all Internet Service Providers (ISPs) allow access through their firewalls to provide MBone tunneling. Thus, IPMC is still not deployed to a significant extent in the Internet. Additionally, as there were no real killer applications making use of IPMC, ISPs have been reluctant to increase their 1 “replication-strategies” — 2007/4/24 — 10:56 — page 2 — #12 CHAPTER 1. INTRODUCTION administrative burden for providing a service which is not requested by their customers. An additional issue with IPMC is that it lacks native buffering capabilities. This becomes a significant problem when providing streaming services, and many solutions have been proposed to solve this problem. Patching (Section 4.3) [6] and Chaining (Section 4.4) are examples of solutions using both application layer caching for buffering and IPMC for transmission. Another way is to move the functionality of the network layer to the application layer, thus forming overlay networks that can take into account more diverse parameters and provide more complex services, while at the same time simplify deployment and remove the dependence on the underlying infrastructure. One specific type of overlay network that has been gaining attention during the last few years are the Peer-to-Peer (P2P) networks. Systems such as Napster [7], Gnutella [8], eDonkey [9] and BitTorrent [10] have been used for searching for or distributing files by millions of users. Additionally, much research is being done on implementing multicast as an overlay service, i. e., Overlay Multicast (OLMC). Systems such as End-System Multicast (ESM) [11] and PeerCast [12] are being used to stream video and audio to large subscriber groups. Furthermore, approaches such as Distributed Prefetching Protocol for Asynchronous Multicast (dPAM) [13] and oStream [14] provide intelligent application layer multicast routing and caching services. Overlay systems based on Distributed Hash Tables (DHTs) have also been used to provide multicast services, e. g., Bayeux [15], Scribe [16] and Application Level Multicast Infrastructure (ALMI) [17]. BitTorrent is currently one of the most popular P2P applications [18], and proposals for adapting it to provide streaming services have been put forth. While the original BitTorrent distribution model was designed for distributing large files in an efficient way, researchers have designed adaptations to the BitTorrent protocols and mechanisms so as to be able to use them as foundations for streaming systems [19, 20]. 1.1 Motivation This research report has been written as part of the Routing in Overlay Networks (ROVER) project, partially funded by the Swedish Foundation for Internet Infrastructure (IIS). The main research area of ROVER is on multimedia distribution in overlay net- works, with particular focus on streaming and on-demand delivery services. While there are several surveys of broadcasting mechanisms and stream merging mechanisms, e. g., [21–23], and a large amount of publications on Application Layer Multicast (ALM) and P2P systems intended for Video-on-Demand (VoD), there is little information on applying the ideas and mechanisms from the former to the latter. In this report, we provide an overview of four related topics: multicast systems, broadcasting strategies, stream merging strategies and caching mechanisms. These form a foundation for a further discussion on using them in a BitTorrent-based system for VoD. We discuss multicast, as this is the technology that best fits large-scale media distribution. Broadcasting strategies are considered because of the scheduling aspects of multimedia transmissions. Stream merging strategies are discussed because of their bandwidth-conserving capability and relation to both broadcasting and caching. We 2 “replication-strategies” — 2007/4/24 — 10:56 — page 3 — #13 1.2. OUTLINE also consider caching strategies, as these are important for decreasing bandwidth con- sumption, as well as for ALM to perform well in comparison with IPMC. In short: • Multicast systems (both IPMC and ALM) provide the group transmission capabili- ties (e. g., addressing and forwarding) necessary for media distribution to multiple clients. • Broadcast strategies concern mechanisms for the segmentation of media objects and scheduling of media streams. • Stream merging strategies concern mechanisms for the reduction of bandwidth consumption, typically by caching stream data in application for later redistribu- tion. • Caching strategies concern mechanisms for the buffering of media streams at in- termediary nodes. In the BitTorrent discussion provided in Chapter 6, we consider these mechanisms in relation to the BitTorrent algorithms.
Load more

Recommended publications
  • A Remote Lecturing System Using Multicast Addressing
    MTEACH: A REMOTE LECTURING SYSTEM USING MULTICAST ADDRESSING A Thesis Submitted to the Faculty of Purdue University by Vladimir Kljaji In Partial Fulfillment of the Requirements for the Degree of Master of Science in Electrical Engineering August 1997 - ii - For my family, friends and May. Thank you for your support, help and your love. - iii - ACKNOWLEDGMENTS I would like to express my gratitude to Professor Edward Delp for being my major advisor, for his guidance throughout the course of this work and especially for his time. This work could not have been done without his support. I would also like to thank Pro- fessor Edward Coyle and Professor Michael Zoltowski for their time and for being on my advisory committee. - iv - TABLE OF CONTENTS Page LIST OF TABLES .......................................................................................................viii LIST OF FIGURES........................................................................................................ix LIST OF ABBREVIATIONS.........................................................................................xi ABSTRACT.................................................................................................................xiii 1. INTRODUCTION...................................................................................................1 1.1 Review of Teleconferencing and Remote Lecturing Systems ...............................1 1.2 Motivation ...........................................................................................................2
    [Show full text]
  • SIP Architecture
    383_NTRL_VoIP_08.qxd 7/31/06 4:34 PM Page 345 Chapter 8 SIP Architecture Solutions in this chapter: ■ Understanding SIP ■ SIP Functions and Features ■ SIP Architecture ■ Instant Messaging and SIMPLE Summary Solutions Fast Track Frequently Asked Questions 345 383_NTRL_VoIP_08.qxd 7/31/06 4:34 PM Page 346 346 Chapter 8 • SIP Architecture Introduction As the Internet became more popular in the 1990s, network programs that allowed communication with other Internet users also became more common. Over the years, a need was seen for a standard protocol that could allow participants in a chat, videoconference, interactive gaming, or other media to initiate user sessions with one another. In other words, a standard set of rules and services was needed that defined how computers would connect to one another so that they could share media and communicate.The Session Initiation Protocol (SIP) was developed to set up, maintain, and tear down these sessions between computers. By working in conjunction with a variety of other protocols and special- ized servers, SIP provides a number of important functions that are necessary in allowing communications between participants. SIP provides methods of sharing the location and availability of users and explains the capabilities of the software or device being used. SIP then makes it possible to set up and manage the session between the parties. Without these tasks being performed, communication over a large network like the Internet would be impossible. It would be like a message in a bottle being thrown in the ocean; you would have no way of knowing how to reach someone directly or whether the person even could receive the message.
    [Show full text]
  • Bittorrent Files Hace Stopped Downloading
    bittorrent files hace stopped downloading Why Some Torrents Don’t Download? A torrent that doesn’t start downloading or one that suddenly stops can be very frustrating. You check your Internet connection, the cables, and everything looks good. So what can be the reasons for those torrents that don’t seem to work? Some Torrents Don’t Download. The main reason behind a torrent file that doesn’t even start downloading is the lack of seeders and peers. In other words, there is no one seeding that file, meaning there’s no place where you can download it from. That’s why it’s very important that you have a look at the number of seeders and peers every time you start a new download. Seeders are the users who already finished downloading and are only sharing. The peers are the ones like you, the ones who are downloading and uploading at the same time. Some Files Suddenly Stop Downloading. This is another common scenario. We’ve all been there when a torrent stops at some moment, such as 99%. That usually happens when there are only peers, but no seeders . If you think about it, it makes total sense. The peers have many parts of the torrent in common, and they will share those between them. But because there are zero seeders, no one has the entire file , and everyone will share the same parts and stop in the same percentage point. A Dead Torrent. Both of the situations we just saw are what users in the community call a “dead torrent”.
    [Show full text]
  • Improving Fairness in Peer-To-Peer Networks by Separating the Role of Seeders in Network Infrastructures
    Turkish Journal of Electrical Engineering & Computer Sciences Turk J Elec Eng & Comp Sci (2016) 24: 2255 { 2266 http://journals.tubitak.gov.tr/elektrik/ ⃝c TUB¨ ITAK_ Research Article doi:10.3906/elk-1402-304 Improving fairness in peer-to-peer networks by separating the role of seeders in network infrastructures Alireza NAGHIZADEH∗, Reza EBRAHIMI ATANI Department of Computer Engineering, Faculty of Engineering, University of Guilan, Rasht, Iran Received: 27.02.2014 • Accepted/Published Online: 08.07.2014 • Final Version: 15.04.2016 Abstract:Fairness is one of the most important challenges that should be considered as a priority when designing a P2P file-sharing network. An unfair P2P network may attract free-riders, frustrate the majority of users, and consequently shorten the longevity of files. When BitTorrent protocol was first introduced, by suggesting new algorithms like tit-for- tat or rarest-first and combining them with methods like choking and unchoking, it pushed fairness one step forward. However, BitTorrent did not bring a plenary solution and has its own shortcomings. For instance, neither this protocol nor other P2P protocols that we are aware of precisely indicate how seeders should be treated in their networks. Most of the time they dictate that seeders upload as much as possible. With this approach, seeders can easily be abused by free-riders. It gets even worse when we realize that for lack of a good infrastructure a lawful user may become a free-rider unknowingly. The purpose of this paper is to address this problem by suggesting a novel and universal method that can be implemented in current P2P networks.
    [Show full text]
  • The Dos and Don'ts of Videoconferencing in Higher
    The Dos and Don’ts of Videoconferencing in Higher Education HUSAT Research Institute Loughborough University of Technology Lindsey Butters Anne Clarke Tim Hewson Sue Pomfrett Contents Acknowledgements .................................................................................................................1 Introduction .............................................................................................................................3 How to use this report ..............................................................................................................3 Chapter 1 Videoconferencing in Higher Education — How to get it right ...................................5 Structure of this chapter ...............................................................................................5 Part 1 — Subject sections ............................................................................................6 Uses of videoconferencing, videoconferencing systems, the environment, funding, management Part 2 — Where are you now? ......................................................................................17 Guidance to individual users or service providers Chapter 2 Videoconferencing Services — What is Available .....................................................30 Structure of this chapter ...............................................................................................30 Overview of currently available services .......................................................................30 Broadcasting
    [Show full text]
  • Mbone Provides Audio and Video Across the Internet
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Calhoun, Institutional Archive of the Naval Postgraduate School Calhoun: The NPS Institutional Archive Faculty and Researcher Publications Faculty and Researcher Publications 1994-04 MBone Provides Audio and Video Across the Internet Macedonia, Michael R. http://hdl.handle.net/10945/40136 MBone Provides Audio and Video Across the Internet Michael R. Macedonia and Donald P. Brutzman Naval Postgraduate School he joy of science is in the discovery. In March 1993, our group at the Naval Postgraduate School heard that the Jason Project, an underwater explo­ ration and educational program supported by Woods Hole Oceanographic IIInstitution in Massachusetts, was showing live video over the Internet from an under­ water robot in waters off Baja, Mexico. We worked furiously to figure out how to re­ ceive that video signal, laboring diligently to gather the right equipment, contact the appropriate network managers, and obtain hardware permissions from local bu­ reaucrats. After several days of effort, we learned that a satellite antenna uplink ca­ ble on the Jason support ship had become flooded with seawater a few hours before we became operational. Despite this disappointment, we remained enthusiastic because, during our ef­ forts, we discovered how to use the Internet's most unique network, MBone. Short for Multicast Backbone, 1 MBone is a virtual network that has been in existence since early 1992. It was named by Steve Casner1 of the University of Southern California Information Sciences Institute and originated from an effort to multicast audio and video from meetings of the Internet Engineering Task Force.
    [Show full text]
  • P2P File Sharing P2P File Sharing
    P2P File Sharing P2P file sharing Alice chooses one of the peers, Bob. File is copied from Bob’s PC to Example Alice’s notebook: HTTP Alice runs P2P client While Alice downloads, other application on her notebook users uploading from Alice. computer Alice’s peer is both a Web client Intermittently connects to and a transient Web server. Internet; gets new IP address All peers are servers = highly for each connection scalable! Asks for “Hey Jude” Application displays other peers that have copy of Hey Jude. P2P: centralized directory (Napster’s Approach) Bob centralized directory server original “Napster” design 1 1) when peer connects, it peers 1 informs central server: IP address 1 3 content 2 1 2) Alice queries for “Hey Jude” 3) Alice requests file from Alice Bob P2P: problems with centralized directory file transfer is Single point of failure decentralized, but locating content is Performance highly decentralized bottleneck Copyright infringement Query flooding: Gnutella overlay network: graph edge between peer X fully distributed and Y if there’s a TCP no central server connection public domain all active peers and protocol edges is overlay net many Gnutella clients Edge is not a physical implementing protocol link Given peer will typically be connected with < 10 overlay neighbors Gnutella: protocol Ì File transfer: Query message HTTP sent over existing TCP connections Query Ì peers forward QueryHit Query message Ì QueryHit sent over reverse Query path QueryHit Scalability: limited scope flooding Gnutella: Peer joining 1. Joining peer X must find some other peer in Gnutella network: use list of candidate peers 2.
    [Show full text]
  • Compsci 514: Computer Networks Lecture 21-2: from Bittorrent to Bittyrant Problem Statement
    CompSci 514: Computer Networks Lecture 21-2: From BitTorrent to BitTyrant Problem Statement ... Server • One-to-many content distribution – Millions of clients downloading from the same server Evolving Solutions • Observation: duplicate copies of data are sent • Solutions – IP multicast – End system multicast – Content distribution networks e.g. Akamai – P2P cooperative content distribution • Bittorrent etc. IP multicast • End systems join a multicast group • Routers set up a multicast tree • Packets are duplicated and forwarded to multiple next hops at routers • Multicast pros and cons End system multicast • End systems rather than routers organize into a tree, forward and duplicate packets • Pros and cons Content distribution networks • Akamai – Works well but expensive, requires infrastructure support Peer-to-Peer Cooperative Content Distribution u Use the client’s uplink bandwidth u New problem: incentives for cooperation or how to motivate clients to upload The Gnutella approach u All nodes are true peers u A peer is the publisher, the uploader and the downloader. u No single point of failure. u Efficiency and scalability issue: u File searches span across a large number of nodes generating lots of traffic. u Integrity, i.e.content pollution issue: u Anyone can claim that he publishes valid content u No guarantee of quality of objects u Incentive issue: u No incentives for cooperation (free-riding in Gnutella) Outline u Problem of Content Distribution u The BitTorrent approach u BitTyrant BitTorrent overview Tracker 1 2 3 Leecher A Seeder Leecher C Leecher B u File is divided into chunks (e.g. 256KB) uShA1 hashes of all the pieces are included in the .torrent file for integrity check uA chunk is divided into sub-pieces to improve efficiency u Seeders have all chunks of the file u Leechers have some or no chunks of the file BitTorrent overview Tracker 1 2 3 Leecher A Seeder Leecher C Leecher B u File is divided into chunks (e.g.
    [Show full text]
  • Exploiting Bittorrent for Fun (But Not Profit)
    Exploiting BitTorrent For Fun (But Not Profit) Nikitas Liogkas, Robert Nelson, Eddie Kohler, and Lixia Zhang University of California, Los Angeles fnikitas, rlnelson, kohler, [email protected] ABSTRACT the file can be downloaded from different peers. A meta- This paper assesses BitTorrent’s robustness against selfish peers, data file is associated with every download. This file con- who try to download more than their fair share by abusing existing tains information necessary for the download process, in- protocol mechanisms. We design and implement three selfish-peer cluding the number of pieces and hashes for all the pieces; exploits and evaluate their effectiveness on public and private tor- the hashes are used by peers to verify that a piece has been rents. In practice, BitTorrent appears quite robust against this kind received correctly. This metadata file is typically created by of exploit: selfish peers can sometimes obtain more bandwidth, and the content provider, who must also launch at least one client honest peers’ download rates suffer slightly in consequence, but we offering the entire file for download. In order to join the observe no considerable degradation of the system’s quality of ser- download process, a client retrieves the metadata file out of vice. We identify private-torrent scenarios in which a selfish peer band, usually either from a well-known website or by email. could benefit more significantly at the expense of honest peers, and It then contacts the tracker, a centralized component that discuss the BitTorrent protocol mechanisms that lead to robustness by rendering these scenarios infeasible. keeps track of all the peers participating in the download.
    [Show full text]
  • Peer-To-Peer Networking
    Peer-to-Peer Networking Case Study: BitTorrent Lecture Content BitTorrent (protocol version 1.0) File transfer protocol Novel techniques for distributing content P2P system studied further The original design Later enchantments are not discussed here BitTorrent (BT) BT is a file transfer protocol for content distribution Protocol specifications v1.0 studied here A centralised P2P system (compare to Napster) A tracker server managing users© downloads BitTorrent concentrates on efficient file transfer Searching content is not provided by the protocol specification, but out-of-band methods Addresses the free riding problem in P2P file sharing BT Terminology (1/3) Torrent Set of peers cooperating to download the same content using BT protocol Tracker Centralised server keeping track of current participants. Does not involve to data transfers, but collect statistics Pieces and blocks File is cut into fixed size pieces (typically 256 KB) and pieces are further cut into blocks (transfer unit, 16 KB) BT Terminology (2/3) Metainfo file, or .torrent file Contains information about the file, its length, name and the address and port of the tracker Hashes for pieces of files for verification Interested and Choked A is marked as interested in peer B when B has pieces that A wants, and vice versa. Also, A is choked, when B decides not to upload data when A is interested. When B is willing to upload again, A is unchoked. BT Terminology (3/3) Peer set or a swarm The group of machines that are collectively connected for a particular file, i.e. a list of open TCP connections Leecher and seed Leecher is a peer that is still downloading the pieces.
    [Show full text]
  • Peer-To-Peer Networks – Protocols, Cooperation and Competition
    Peer-to-Peer Networks – Protocols, Cooperation and Competition Hyunggon Park Signal Processing Laboratory (LTS4), Institute of Electrical Engineering, Swiss Federal Institute of Technology (EPFL), Lausanne, Switzerland Rafit Izhak Ratzin Computer Science Department, University of California, Los Angeles (UCLA), Los Angeles, USA Mihaela van der Schaar Multimedia Communications and Systems Laboratory, Electrical Engineering Department, University of California, Los Angeles (UCLA), Los Angeles, USA 1. INTRODUCTION Peer-to-peer (P2P) networks connect many end-hosts (also referred to as peers) in an ad-hoc manner. P2P networks have been typically used for file sharing applications, which enable peers to share digitized content such as general documents, audio, video, electronic books, etc. Recently, more advanced applications such as real-time conferences, online gaming, and media streaming have also been deployed over such networks. Unlike traditional client-server networks, where servers only provide content, and clients only consume content, in P2P networks, each peer is both a client and a server. It has been observed that P2P file sharing applications dominate Internet traffic usage. In fact, a wide range of measurements, which were performed in 8 different geographic regions during the years of 2008-2009, show that P2P networks generated most of the traffic in all monitored regions, ranging from 43% in Northern Africa to 70% in Eastern Europe (http://www.ipoque.com/). The same study also identified that BitTorrent (Cohen, 2003) is the most popular protocol on the Internet, generating most of the traffic in 7 out of 8 regions ranging from 32% in South Africa to 57% in Eastern Europe. The details of the BitTorrent protocol will be discussed in Section 3.
    [Show full text]
  • Libswift P2p Protocol: an Analysis and Extension
    Master Thesis - TRITA-ICT-EX-2012-262 LIBSWIFT P2P PROTOCOL: AN ANALYSIS AND EXTENSION Fu Tang Design and Implementation of ICT products and systems Royal Institute of Technology (KTH) [email protected] October 30th, 2012 Supervisor: Flutra Osmani Examiner: Bj¨ornKnutsson Department: ICT School, NSLab Royal Institute of Technology (KTH) 1 Abstract More and more end-users are using P2P protocols for content sharing, on-demand and live streaming, contributing considerably to overall Internet traffic. A novel P2P streaming protocol named libswift was developed to enable people experience a better service by consuming less resources and transferring less unnecessary functions and metadata. This master thesis studies the inner functioning of libswift and analyzes some of the vulnerabilities that directly impact performance of the protocol, namely download speed and response delay. By investigating the behavior of libswift in scenarios with multiple peers, we found that the lack of a peer selection mechanism inside the protocol affects download efficiency and response time. We also discovered that libswift's internal piece picking algorithm raises competition among peers, thus not fully utilizing connected peers. In addition, we found that current libswift implementation does not follow the specification for PEX peer discovery, thus we modified PEX algorithm to support another message that is used to proactively request new peers from the currently connected. Having made these observations, we designed and implemented a peer selection extension interface that allows for third-party peer selection mechanisms to be used with libswift protocol. Apropos, we tested the interface (or adapter) with an example peer selection mechanism that groups peers according to properties such as latency and locality.
    [Show full text]