DOCSLIB.ORG

Libswift P2p Protocol: an Analysis and Extension

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

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. Preliminary experimental data shows that using our extension with an external peer selection mechanism enables libswift to select peers based on various metrics and thus enhances its download speed. We argue that libswift is a good protocol for next generation content delivery systems and it can get faster data transfer rates and lower latency by integrating efficient peer selection mechanisms. Contents I Background 7 1 Introduction 8 1.1 Basic Introduction of Libswift . .8 1.2 Problem Description . .9 1.3 Motivation . .9 1.4 Hypothesis . 10 1.5 Goal . 10 1.5.1 Tasks . 10 1.6 Structure . 11 2 Background and Related Work 12 2.1 Peer-to-Peer networks . 12 2.2 Peer-to-Peer protocols . 13 2.3 BitTorrent protocol . 14 2.3.1 Peer tracking and piece picking . 15 2.4 Libswift protocol . 16 2.4.1 Basic operations in libswift . 20 2.5 Related work . 22 2.6 Experimental Evaluation . 27 2.6.1 Extensions for libswift . 28 2.6.2 Software resources and tools . 29 3 Overview and Analysis 30 3.1 Peer discovery basics . 30 1 3.2 Peer exchange and selection . 33 3.3 Analysis of multiple-channel download . 35 3.4 Congestion control . 41 II Design and Implementation 44 4 Protocol Extensions 45 4.1 PEX REQ design . 45 4.2 Design of the adapter . 47 4.2.1 Interaction between components . 49 5 Implementation 52 5.1 Libswift modifications . 52 5.2 Implementation of the adapter module . 55 5.3 Integration with PeerSelector . 59 6 Experimental Evaluation 60 6.1 PEX modifications . 60 6.2 Adapter extension . 61 6.2.1 Experimental results . 63 6.3 Comparison of policies . 68 6.3.1 Side effects of PeerSelector . 70 III Discussion and Conclusions 71 7 Discussion 72 7.1 Libswift . 73 7.2 Extensions . 74 8 Conclusions 76 A Appendix 78 2 List of Figures 2.1 P2P network ........................... 12 2.2 Centralized network ....................... 12 2.3 Metainfo with tracker ...................... 14 2.4 Metainfo, trackerless ...................... 14 2.5 Data request and response ................... 15 2.6 Channels and file transfer ................... 17 2.7 Chunk addressing in libswift .................. 18 2.8 A libswift datagram ....................... 20 2.9 The process of connection ................... 21 2.10 The process of exchanging data ................ 21 3.1 The flow of PEX messages ................... 31 3.2 State machine of the leecher .................. 31 3.3 State machine of the seeder .................. 32 3.4 Message flow I .......................... 34 3.5 Message flow II ......................... 34 3.6 Piece picking algorithm ..................... 35 3.7 Three peers in the same swarm ................ 36 3.8 The setting for three groups .................. 36 3.9 Group 1, trial 1 ......................... 37 3.10 Group 1, trial 2 ......................... 37 3.11 Group 1, trial 3 ......................... 37 3.12 Group 1, trial 4 ......................... 37 3.13 Group 2, trial 1 ......................... 38 3 3.14 Group 2, trial 2 ......................... 38 3.15 Group 2, trial 3 ......................... 38 3.16 Group 2, trial 4 ......................... 38 3.17 Group 3, trial 1 ......................... 39 3.18 Group 3, trial 2 ......................... 39 3.19 Group 3, trial 3 ......................... 39 3.20 Group 3, trial 4 ......................... 39 3.21 Seeder's HAVE and sent DATA messages .......... 40 3.22 Congestion window size ..................... 42 3.23 Overall view ........................... 42 3.24 Detailed view ........................... 42 4.1 Sender side ............................ 46 4.2 Receiver side ........................... 46 4.3 Design overview ......................... 47 4.4 The interaction between components ............. 48 4.5 Adapter and libswift core ................... 49 4.6 Adapter and PeerSelector ................... 50 4.7 API used by PeerSelector ................... 51 4.8 API used by libswift ...................... 51 6.1 Test case 1 ............................ 61 6.2 Test case 2 ............................ 61 6.3 Download performance for Score ............... 64 6.4 Score, trial 1 ........................... 64 6.5 Score, trial 2 ........................... 64 6.6 Download performance for AS-hops ............. 65 6.7 AS-hops, trial 1 ......................... 66 6.8 AS-hops, trial 2 ......................... 66 6.9 Download performance for RTT ................ 67 6.10 RTT, Trial 1 ........................... 67 6.11 RTT, Trial 2 ........................... 67 4 6.12 Download performance for Random ............. 68 6.13 Random, Trial 1 ......................... 69 6.14 Random, Trial 2 ......................... 69 5 List of Tables 6.1 PlanetLab machine properties ................. 62 6.2 Score-selected peers ....................... 63 6.3 AS-hops-selected peers ..................... 65 6.4 RTT-selected peers ....................... 66 6.5 Comparison of policy-based performances .......... 69 6 Part I Background 7 Chapter 1 Introduction During recent years Internet grew rapidly, with many protocols and architectures developed to allow people to get information from the Internet. Apropos, P2P networks and protocols play a very important role to help the end-user retrieve and consume content. 1.1 Basic Introduction of Libswift Libswift is a recently developed P2P protocol that may be understood as BitTorrent at the transport layer [13]. Its mission is to disseminate content among a group of devices. In its current form, it is not only a file-sharing protocol, but it can also be used for streaming on-demand and live video [15]. Using libswift, a group of computers share and download the same file with each other, where each computer is a peer to other computers. These computers and the file together form a swarm. Like BitTorrent1, libswift divides the file into small pieces which can be located among a group of computers. As a result, the files and computers may be located in different countries or cities. This is why we call libswift network a content distributed network. When a user wants to retrieve pieces or the whole content, libswift is responsible to transfer that content back to the user. 1BitTorrent(software) available at http://en.wikipedia.org/wiki/BitTorrent (software) 8 1.2 Problem Description Naturally, users want to get their wanted content or some parts of it as soon as possible [20]. Libswift and other P2P protocols try to retrieve content from several computers at the same time. Just as explained above, several devices may be serving the same content, meaning that the user can download the corresponding content from any computer of the given swarm. If swarm size is, say, five or six then libswift would be requesting pieces from all five or six computers and, as a result, download speed would increase proportionally with swarm size. However, if swarm size were to be around five thousand[19], we should not allow libswift to retrieve pieces from all of the computers as resources of a local PC or a mobile device are limited, including CPU speed, memory, or traffic bandwidth. Each request to another peer would consume some of such resources. If thousands of requests were to be sent concurrently, the local device would exhaust its memory and other resources. In this thesis, we want to improve download performance by limiting the number of simultaneous requests to certain | more wisely chosen | peers only. 1.3 Motivation When we download data from different computers or any other device, we may get different download speeds from each. In a P2P network, there are many factors that may affect the performance of each peer. These factors or properties include, among others, a peer's location [20] and peer's Autonomous System (AS) [30]. Our initial motivation is to study how these properties affect the behavior of libswift and,
Recommended publications
  • The Pirate Bay Liability

    The Pirate Bay Liability

    THE PIRATE BAY LIABILITY University of Oslo Faculty of Law Candidate name: Angela Sobolciakova Supervisor: Jon Bing Deadline for submission: 12/01/2011 Number of words: 16,613 10.12.2011 Abstract The thesis discuses about peer-to-peer technology and easy availability of an Internet access which are prerequisites to a rapid growth of sharing data online. File sharing activities are managing without the copyright holder‟s permission and so there is a great opportunity of infringing exclusive rights. The popular pee-to-peer website which is enabling immediate file sharing is for example www.thepiratebay.org – the object of this thesis. The copyright law is obviously breaching by end users who are committing these acts. However, on the following pages we are dealing with the third party liability – liability of online intermediaries for unlawful acts committed by their users. A file sharing through the pee-to-peer networks brings benefits for the Internet users. They need no special knowledge in order to learn how to use the technology. The service of www.thepiratebay.org website is offering simultaneously users an access to a broad spectrum of legal content and a copyright protected works. The service is mainly free of charge and the users can find a data they are interested in quickly and in a users‟ friendly format. The aim of the thesis is to compare the actual jurisprudential status of liability of intermediary information society service providers for the file sharing activities on www.thepiratebay.org. 2 Acknowledgement I would like to thank Professor Jon Bing, I am grateful to him for supervising the thesis.
  • Characterizing Peer-Level Performance of Bittorrent

    Characterizing Peer-Level Performance of Bittorrent

    Characterizing Peer-level Performance of BitTorrent DRP Report Amir H. Rasti ABSTRACT 1. INTRODUCTION BitTorrent is one of the most popular Peer-to-Peer During the past few years, peer-to-peer appli- (P2P) content distribution applications over the cations have become very popular on the In- Internet that significantly contributes in network ternet. BitTorrent in one of the most popu- traffic. lar peer-to-peer applications providing scalable peer-to-peer content distribution over the In- In BitTorrent, a file is divided into segments ternet. Some recent studies [8] have shown that and participating peers contribute their outgoing BitTorrent is accountable for approximately bandwidth by providing their available segments 35% of the Internet traffic. BitTorrent is a to other peers while obtaining their missing peers scalable peer-to-peer content distribution sys- from others. Characterization of BitTorrent is use- tem that enables one-to-many distribution of ful in determining its performance bottlenecks as large files without requiring a large access link well as its impact on the network. bandwidth at the source. Similar to other peer- In this study, we try to address the following two to-peer systems, it uses resources of participat- key questions through measurement: (i) What are ing peers to increase the capacity of the system. the main factors that affect observed performance The main shared resource in BitTorrent is the by individual peers in BitTorrent?, and (ii) What up-link bandwidth of individual peers. The file are the contributions of these factors on the per- being distributed is divided into a large number formance of individual peers? To address these of segments.
  • A Study of Peer-To-Peer Systems

    A Study of Peer-To-Peer Systems

    A Study of Peer-to-Peer Systems JIA, Lu A Thesis Submitted in Partial Fulfilment of the Requirements for the Degree of Master of Philosophy in Information Engineering The Chinese University of Hong Kong August 2009 Abstract of thesis entitled: A Study of Peer-to-Peer Systems Submitted by JIA, Lu for the degree of Master of Philosophy at The Chinese University of Hong Kong in June 2009 Peer-to-peer (P2P) systems have evolved rapidly and become immensely popular in Internet. Users in P2P systems can share resources with each other and in this way the server loading is reduced. P2P systems' good performance and scalability attract a lot of interest in the research community as well as in industry. Yet, P2P systems are very complicated systems. Building a P2P system requires carefully and repeatedly thinking and ex- amining architectural design issues. Instead of setting foot in all aspects of designing a P2P system, this thesis focuses on two things: analyzing reliability and performance of different tracker designs and studying a large-scale P2P file sharing system, Xun- lei. The "tracker" of a P2P system is used to lookup which peers hold (or partially hold) a given object. There are various designs for the tracker function, from a single-server tracker, to DHT- based (distributed hash table) serverless systems. In the first part of this thesis, we classify the different tracker designs, dis- cuss the different considerations for these designs, and provide simple models to evaluate the reliability of these designs. Xunlei is a new proprietary P2P file sharing protocol that has become very popular in China.
  • Replication Strategies for Streaming Media

    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 .
  • Bittorrent Files Hace Stopped Downloading

    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”.
  • Improving Fairness in Peer-To-Peer Networks by Separating the Role of Seeders in Network Infrastructures

    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.
  • Torrent Crawler: a Tool for Collecting Information from Bittorrent Networks

    Torrent Crawler: a Tool for Collecting Information from Bittorrent Networks

    Torrent Crawler: a tool for collecting information from BitTorrent networks Yeounoh Chung 1. Abstract structure and the unpredictability of the clients can cause problems in the network, making errors BitTorrent is a free peer-to-peer (P2P) difficult to detect and diagnosis. The reliance of a content-sharing application with a complex and node on node local views to maintain the overlay dynamic overlay structure due to loose coupling, high structure further compounds the problem. Defects or churn rate, and varying responsiveness of nodes. The anomalies such as partitioning in the overlay or load complexity and the dynamic nature of the overlay imbalance due to biased peer selection are structure can mask the problems in the network, undetectable without partial global information and a making errors difficult to detect and diagnosis in a good understanding of the various characteristics and timely manner. Furthermore, the heavy reliance of dynamic behaviors of the network. However, such an clients on the node local views compounds the understanding was often times missing or incorrectly problems such as partitioning in the network or load obtained from non-representative measurement imbalance due to biased peer selection. studies, in which a few instrumented clients were In an effort to provide the network with used to capture the desired properties. partial global information to resolve the network Collecting representative global information problems, this project looks into introducing a tool such as peer’s download rate, known neighboring that efficiently collects global information from peers, and the network’s churn rate, from the BitTorrent network. The tool, called Torrent Crawler complex and dynamic BitTorrent network is not (TC) uses a number of techniques to efficiently find simple.
  • A Week in the Life of the Most Popular Bittorrent Swarms

    A Week in the Life of the Most Popular Bittorrent Swarms

    A Week in the Life of the Most Popular BitTorrent Swarms Mark Scanlon, Alan Hannaway and Mohand-Tahar Kechadi 1 UCD Centre for Cybercrime Investigation, School of Computer Science & Informatics, University College Dublin, Belfield, Dublin 4, Ireland {mark.scanlon, alan.hannaway, tahar.kechadi}@ucd.ie AbstractThe popularity of peer-to-peer (P2P) file distribution is c material, which typically commences with a single source sharing large sized files to many downloaders. networks lend themselves well to the unauthorised distribution of To commence the download of the content in a particular copyrighted material due to their ease of use, the abundance of - material available and the apparent anonymity awarded to the downloaders. This paper presents the results of an investigation loaded from an indexing website. This file is then opened conducted on the top 100 most popular BitTorrent swarms over using a BitTorrent client, which proceeds to connect to several the course of one week. The purpose of this investigation is to members of the swarm and download the content. Each quantify the scale of unauthorised distribution of copyrighted BitTorrent swarm is built around a particular piece of content material through the use of the BitTorrent protocol. Each IP which is determined through a unique identifier based on a address, which was discovered over the period of the weeklong SHA-1 hash of the file information contained in this UTF- 8 investigation, is mapped through the use of a geolocation encoded metadata file, e.g., name, piece length, piece hash database, which results in the ability to determine where the values, length and path.
  • P2P File Sharing P2P File Sharing

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

    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.
  • Exploiting Bittorrent for Fun (But Not Profit)

    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.
  • Peer-To-Peer Networking

    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.