LIBSWIFT P2P PROTOCOL: AN ANALYSIS AND EXTENSION

Transcription

1 Master Thesis - TRITA-ICT-EX LIBSWIFT P2P PROTOCOL: AN ANALYSIS AND EXTENSION Fu Tang Design and Implementation of ICT products and systems Royal Institute of Technology (KTH) fut@kth.se October 30th, 2012

2 Supervisor: Flutra Osmani Examiner: Björn Knutsson Department: ICT School, NSLab Royal Institute of Technology (KTH) 1

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

4 Contents I Background 7 1 Introduction Basic Introduction of Libswift Problem Description Motivation Hypothesis Goal Tasks Structure Background and Related Work Peer-to-Peer networks Peer-to-Peer protocols BitTorrent protocol Peer tracking and piece picking Libswift protocol Basic operations in libswift Related work Experimental Evaluation Extensions for libswift Software resources and tools Overview and Analysis Peer discovery basics

5 3.2 Peer exchange and selection Analysis of multiple-channel download Congestion control II Design and Implementation 44 4 Protocol Extensions PEX REQ design Design of the adapter Interaction between components Implementation Libswift modifications Implementation of the adapter module Integration with PeerSelector Experimental Evaluation PEX modifications Adapter extension Experimental results Comparison of policies Side effects of PeerSelector III Discussion and Conclusions 71 7 Discussion Libswift Extensions Conclusions 76 A Appendix 78 2

6 List of Figures 2.1 P2P network Centralized network Metainfo with tracker Metainfo, trackerless Data request and response Channels and file transfer Chunk addressing in libswift A libswift datagram The process of connection The process of exchanging data The flow of PEX messages State machine of the leecher State machine of the seeder Message flow I Message flow II Piece picking algorithm Three peers in the same swarm The setting for three groups Group 1, trial Group 1, trial Group 1, trial Group 1, trial Group 2, trial

7 3.14 Group 2, trial Group 2, trial Group 2, trial Group 3, trial Group 3, trial Group 3, trial Group 3, trial Seeder s HAVE and sent DATA messages Congestion window size Overall view Detailed view Sender side Receiver side Design overview The interaction between components Adapter and libswift core Adapter and PeerSelector API used by PeerSelector API used by libswift Test case Test case Download performance for Score Score, trial Score, trial Download performance for AS-hops AS-hops, trial AS-hops, trial Download performance for RTT RTT, Trial RTT, Trial

8 6.12 Download performance for Random Random, Trial Random, Trial

9 List of Tables 6.1 PlanetLab machine properties Score-selected peers AS-hops-selected peers RTT-selected peers Comparison of policy-based performances

10 Part I Background 7

11 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 BitTorrent 1, 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. 1 BitTorrent(software) available at (software) 8

12 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, more specifically, how do such properties affect libswift s download speed, data transfer rate and latency. 9

13 1.4 Hypothesis We argue that peer management directly impacts the efficiency and performance of libswift protocol. No previous thorough analysis or solution on peer management for libswift has been provided. Identifying and developing a suitable peer management mechanism for libswift can be used to reduce its download time and resource utilization. 1.5 Goal 1. Characterize libswift behavior in scenarios where libswift downloads from multiple peers, and assess the protocol in terms of its correctness. 2. Identify and devise a peer management mechanism that reduces both download time and resource utilization Tasks To achieve our goal we will understand and analyze the internal peer discovery mechanism and peer management policy. In P2P systems, the process of selecting peers affects download performance. We will also analyze congestion control and how it affects the behavior of libswift. Generally, congestion control affects data transfer rate. In addition, we will investigate piece picking algorithm and profile libswift behavior for multiple-channel download scenarios. In a P2P protocol, piece (chunk) picking affects the efficiency of data transfer. We will design and implement a module to help libswift manage its peers better. This module should act as an interface (adapter) between libswift and a third-party peer selection mechanism. The interface should be integrated with libswift but the peer selection mechanism should be independent of libswift and should not require any major modifications inside libswift s implementation. 10

14 To verify the functionality of our module, we will integrate libswift with an example peer selection engine. Finally, we will define and carry out an experimental evaluation to verify whether libswift s download speed has improved. 1.6 Structure Chapter 2 introduces background and related work, as well as, necessary information needed to understand our thesis and the topic. Chapter 3 provides and overview and analysis of libswift, while Chapter 4 introduces the overall design and design considerations for the extensions. Chapter 5 outlines implementation details, and Chapter 6 presents an experimental evaluation of the extension and describes experimental results. We discuss preliminary results and lessons learned in Chapter 7 and conclude in Chapter 8. 11

15 Chapter 2 Background and Related Work In this chapter, we explain basic concepts of peer-to-peer networks and protocols, introduce related work, and describe relevant background information necessary to understand the work in this thesis. 2.1 Peer-to-Peer networks In a centralized network, computers connect to a central server where files are commonly located. When users want to download a file, they will connect to that server, as depicted in Figure 2.2. Napster is the first prominent centralized P2P system [29]. Figure 2.1: P2P network Figure 2.2: Centralized network 12

16 A peer-to-peer (P2P) network is a network architecture which organizes computers as peers of an equivalent role [24]. Figure 2.1 illustrates a peerto-peer network where computers are connected to each other and files are distributed across such machines. When a user wants to obtain a file, he may connect to any computer of that network. Unlike in the centralized network, there is no obvious server in a distributed network. Instead, every computer acts as the rest of computers, and they call each other a peer. Gnutella is a typical decentralized peer-to-peer network [6]. 2.2 Peer-to-Peer protocols A peer-to-peer protocol is used by users to exchange content or other information in a P2P network. Since late 90s, such protocols were widely used for file-sharing and distributed computing [29, 23, 26]. Terms we commonly encounter in P2P protocols are described in the following: Peer a computer participating in a P2P network and is usually identified by its IP address and port number. Content a live transmission, a pre-recorded multimedia asset, or a file [15]. Swarm a group of peers that are distributing the same content. Chunk (piece) a unit of content, usually measured in kilobytes. Leecher a peer that is downloading content, sometimes called a receiver. Seeder a peer that is serving the content, often called a sender. Tracker a device that keeps track of a group of peers that have a given content. Peers searching for content commonly contact the tracker in order to get other peers addresses. 13

17 2.3 BitTorrent protocol In recent years, BitTorrent has been widely used to share music, videos and other files in the Internet. Using BitTorrent to distribute content consists of mainly two phases: Publishing content BitTorrent generates a metainfo (.torrent) file which contains a unique key named infohash. This key contains subkeys describing chunks within the content [6]. A file is split into small fixed-size pieces, where the default size is 256K. Every piece is hashed and a corresponding 20 bytes string is generated to uniquely identify the piece. All such 20 byte strings are stored in the metainfo file, as pieces. Thus, the length of the pieces value is always a multiple of 20. Figure 2.3: Metainfo with tracker Figure 2.4: Metainfo, trackerless By default, there should be an announce key that contains tracker s address inside metainfo (see Fig. 2.3). In a trackerless version, BitTorrent uses Distributed Dash Tables (DHT) to get peer s contact information [16]. In this case, a key named nodes replaces the announce key inside metainfo, and the value of the nodes field becomes a list of IP addresses and port numbers (see Fig. 2.4). 14

18 Transferring data Once a BitTorrent client obtains the metainfo file from a torrent indexing website, it reads tracker s contact information from it and then connects to that tracker to get peers who currently are sharing the requested file. If this is a trackerless torrent, the client reads the nodes from metainfo and then contacts such nodes for peers that have the content. In the latter case, each node works as a tracker. Figure 2.5: Data request and response As soon as the client gets peer addresses, it sends them request messages for pieces of content. A request message contains: an integer index, begin, and length [16]. The queried peer may return a message whose payload contains a piece index. Once the client receives a piece, it can check its correctness against the hash value stored inside the metainfo file. Figure 2.5 illustrates the data transfer process where index represents the piece index that peer A wants to retrieve, begin is the byte offset within the piece, and length is the requested length Peer tracking and piece picking Two peer tracking mechanisms exist in BitTorrent. Commonly, BitTorrent relies on a tracker to find peers, as trackers maintain a list of peers for a 15

19 given infohash. When a new peer queries the tracker for a list of peers for a certain file, the tracker returns the list of peers but also adds the querying peer to the overall peer list for that infohash. Finally, whenever a peer wants additional peers, it has to contact the tracker again. Distributed Hash Tables (DHT) is an alternative, decentralized mechanism for peer discovery in BitTorrent [16]. In DHT, each peer maintains (is responsible) contact information for a list of peers. Using DHT, a client searches for k closest nodes to the given infohash, where the definition of closeness is specific to the DHT protocol variant and its implementation, as well as, the parameter k. Once it finds closest nodes, it queries them for the list of peers associated with the infohash. While nodes serve only as pointers to the list of peers, the peers possess the actual content. BitTorrent uses rarest chunk first heuristics to retrieve pieces that are rare in the swarm, and optimistic unchoking to enable random peers bootstrap themselves into the swarm [7]. 2.4 Libswift protocol Libswift is a recently developed multiparty transport protocol that supports three usecases: file download, on-demand and live streaming. Unlike Bit- Torrent, libswift runs over UDP and TCP, however, current implementation of the protocol is UDP-based [13, 15]. In this section, we will describe some of the main libswift components. File transfer Libswift introduces file transfer a means to distinguish between different file transfers in the client. More specifically, file transfer is used to read or save content that is being sent or received by a libswift client. Every file in libswift has a corresponding file transfer. Though protocol specification does not limit the number of concurrent file transfers, the current implementation enforces a default of 8. 16

20 Channels When two peers are connected, a channel is established between these two peers. A channel is used to transfer the content of a file between connected peers. One file transfer can employ more than one channel to transfer the same file, but every channel can only work for one file transfer. Figure 2.6 illustrates the relationship between file transfers and channels. Figure 2.6: Channels and file transfer Congestion control In order to control data transfer rate between the receiver and sender, libswift uses a third-party congestion control method called Low Extra Delay Background Transport (LEDBAT) [17]. LEDBAT is designed to utilize all available bandwidth. As soon as there is bottleneck in the link, it decreases the size of congestion window using the detected queuing delay. In practice, libswift uses LEDBAT to manage its congestion window size; libswift increases or decreases its data transfer rate according to the change of congestion window size. LEBDAT uses the following elements for its decision making: 17

21 TARGET if a delay is bigger than this value, the sender should reduce the size of congestion window. GAIN measures the increase and decrease ratio of the current congestion window size. Chunk addressing and chunk integration check Like BitTorrent, libswift splits the file into small pieces during data transfer. The recommended chunk size is 1 kilobyte. Figure 2.7: Chunk addressing in libswift Figure 2.7 illustrates the chunk addressing tree of a 4 kilobytes file. Each leaf of the tree corresponds to a chunk. In turn, each chunk has an index and a corresponding bin number. For example, bin number 0 stands for the first 1 kb of the file, bin 2 stands for the second 1 kb, bin 4 stands for the third 1kb, and so on. When a peer starts serving this file to other peers, it calculates a SHA1 hash for every chunk. Then, it recursively calculates the upper layer SHA1 hashes according to the hashes of lower layers. Finally, the top level s hash value is the root hash (roothash) of the file. The roothash uniquely identifies the file. A peer requests content using the roothash. With the first chunk received, the peer also gets the necessary hashes to check the integrity of that chunk. For example, to check the first chunk of the above file, the sender will send the hash of bin 2 and bin 5. First, when the receiver gets the hash of bin 2, it calculates the hash for bin 1 according to bin 0 and 18

22 bin 2. Then, it obtains a hash by calculating bin 1 and bin 5. Finally, it compares the hash which he got in step two with the roothash. If these two hashes match, the integrity of the first chunk has been checked. Otherwise, this chunk will be dropped. Libswift messages Libswift uses the following messages: HANDSHAKE when a peer wants to connect to another peer, it starts by sending a handshake message. HAV E a peer uses this message to inform other peers what content it has available. HINT a peer uses this message to inform the sender what content it wants. DAT A contains pieces of the file, usually, it carries 1 kb of content. HASH this message is sent together with the DATA message. The payload of this message contains the necessary hashes to verify the integrity of transferred content. ACK the receiver uses this message to acknowledge that it got the content and successfully verified it. P EX REQ peer uses this message to query for new peers from its communicating peer. P EX RSP sender uses this message to send back a list of peers to the peer that requested them. Peer exchange Usually, a peer-to-peer network introduces a centralized tracker to keep track of a group of computer addresses. When a peer wants to discover new peers, 19

23 it contacts this centralized tracker and the tracker gives back a subset of peers. When a new peer joins the swarm, the tracker adds this new peer s address to the list of peers associated with certain content. In addition, libswift supports trackerless peer discovery using the gossiping algorithm called PEX (peer exchange). There are two types of PEX messages: P EX REQ and P EX RES. When a peer A wants some peers, it has to send a P EX REQ to a connected peer B who is transferring data with the former. Then peer B may respond with a P EX RES message containing its peers. The peers sent back to peer A are peers who were actively exchanging information with peer B in the last 60 seconds Basic operations in libswift In libswift, the basic operation unit is a message and the basic transferring unit is a datagram which may contain one or more messages. Figure 2.8: A libswift datagram Figure 2.8 illustrates a datagram which contains a DATA and an INTEGRITY message. The DATA message carries a piece of content and the INTEGRITY message carries the hashes to verify integrity of the content. Joining a swarm When a peer wants to download some specific content, it begins from requesting a list of peers from the tracker. It knows that these peers reside in the same swarm where peers are exchanging the same file. Then, the peer starts to connect to one of such peers by sending a HANDSHAKE message; the other side will send back a HANDSHAKE message, indicating that the connection has been established. In the same datagram returned by the connected peer there may be some HAVE messages to show the current 20

24 Figure 2.9: The process of connection content that is available at its side. Details of this process are depicted in Figure 2.9. Exchanging chunks Figure 2.10: The process of exchanging data After the connection has been established, the leecher (requester) starts to request data from the connected peers. The leecher sends HINT 21

25 (REQUEST) messages to its peers whereas the peers respond back with DATA, HAVE and INTEGRITY messages. Next, the leecher will check and save the received chunks and send acknowledgment messages back. In the same datagram a new HINT message may be included. Figure 2.10 illustrates the data exchange process. Leaving a swarm Once the initial peer downloads all desired content, it can leave the swarm by explicitly sending a leave message or by stopping to respond to peers. 2.5 Related work Many efforts have been made to improve the performance of P2P applications, and they can be mainly categorized into three areas: thirdparty assisted approaches, end-user based approaches, and approaches using congestion control. The first two categories focus on optimal peer selection mechanisms, while the third category focuses on optimizing data transfer. Third-party assisted approaches Aggarwal et al [4] proposed a mechanism to help users find peers with good performance. Authors propose an oracle service, provided by the ISP, to P2P users. A P2P user provides a list of peers to the oracle, and this oracle ranks peers according to different criteria including: peer s distance to edge of the AS, the bandwidth between users, or other. Given a sorted list of peers, the user can then contact peers with better ranking. As the ISP has more information about network s topology, the calculated rank of peers can be more accurate. Thus, a P2P user may benefit from this method. On the other hand, ISPs may also benefit by ranking peers who are in their own network in a higher place, keeping Internet traffic internal. This solution seems like a win-win game, where both P2P users and ISPs benefit. However, some questions remain. First, in a P2P network, peers 22

26 frequently join a swarm and leave it. This means that, in order to get the latest peer rankings, a user must contact ISP s oracle continuously. As a result, new overhead is introduced at the user side. Secondly, given that this approach requires the ISPs to deploy servers for the oracle service, it is not clear whether ISPs are willing to incur additional costs by adding such infrastructure. Finally, this proposal heavily relies on the ISP s participation and honesty. Eugene et al [11] proposed a method to predict network distance between two computers. The fundamental component of this method is Global Network Positioning (GNP) which computes the coordinates of a computer by seeing the whole network as a geometric space. First, it sets some computers as landmarks and initiates these computers coordinates in the geometric space. Then, a computer calculates its coordinates based on the predefined landmarks. Given that the authors select a spherical surface as their modeling geometric space, if a computer knows the coordinate of its peer, it can compute its distance to the peer. Authors reported that the correction between calculated GNP distance and measured distance is Predicting the distance of two P2P peers helps a P2P user choose a nearby peer to download data from and thus potentially reduce data delay. However, to set up landmarks whose coordinates affect the accuracy of the whole GNP system is a challenge for a P2P network. The reason is that, in a P2P network, it is difficult to find such peers who are always online to work as landmarks. Moreover, the current P2P protocol must be modified or extended to support peers that discover such landmarks. Though we don t integrate this approach in this master thesis, the proposal motivates our choices and informs us that distance prediction can help in choosing nearby peers. Another solution given by Francis et al [12] shows a different way of predicting distance between two computers. They built a system called IDMaps to provide a service to other computers to check their distances as 23

27 well as a HOPS server, employed to provide the service. Given a computer A who wants to know the distance to B, IDMaps calculates the distance from A to its nearest Tracer C, and the distance from B to its nearest Tracer D. Then, by calculating the distance from C and D, the sum of A-C, B-D and C-D is the distance between A and B. Any computer can visit its HOPS server to get its distance to others. Results of their research show that the more tracers are in the system the more accurate is the calculated distance. Both GNP and IDMaps services are focused on the distance prediction of network users. Other studies and projects try to provide more information, including bandwidth and AS-hops to applications to use. Haiyong Xie et al [31] suggested a P4P service for both ISPs and P2P users. In P4P, a network provider runs an itracker which maintains network information such as network backbone information and preferred inter-domain links of the provider. A tracker or peer can contact the itracker to obtain the information and select its peers based on the information. Authors show that if ISPs and P2P users know more information about each other, the traffic caused by P2P applications can be reduced. According to their results, the bottleneck link traffic was reduced up to 69%. The IETF ALTO Working Group [28, 27] and the NAPA-WINE project [5, 25] are trying to build more powerful services to provide more network layer information to P2P applications. ALTO aims to provide information such as bandwidth, cross-domain traffic and cost to the user. To date, ALTO working group is still working on this project [10]. NAPA- WINE does similar things to ALTO, moreover, it allows P2P applications to query their own network status, including link congestion and preferred routing. NAPA-WINE project claims that 50% traffic can be reduced on long-haul links. End-user based approaches The above research efforts show that third-party entities have the ability to make P2P applications more friendly to ISPs and achieve better 24

28 performance. From the P2P application point of view, the benefits are not always obvious. Cramer et al introduced a method to reduce the bootstrapping delay of P2P applications [8]. Every peer hashes k-bit of its IP address prefix and saves these hash values under a key in the DHT. When a peer comes to this DHT, it tries to check the hash values of the IP prefix. If a peer s prefix hash matches its address, it is likely that they are in the same location in terms of network topology. And, the longer the prefix match, the higher the locality accuracy. If there are sufficient peers matching reasonable bits of prefix, the peer can find enough peers. Otherwise, it tries to get the ones matching shorter prefix bits. This approach provides a quick way to filter peers who most likely are not within the same location. Especially, in a very big DHT, peers can use this method as the first filter to select potential peers. And based on the results of prefix matching, a peer can further filter peers. Lucia D Acunto et al [9] focus on improving the QoS of the P2P system. In their proposal, authors suggest that a peer who already has good QoS should increase its allocated bandwidth for random peers. First, good QoS of a peer means that its sequential progress is faster than the video playback rate; in this case, this peer should increase its optimistic unchoke slots. Then, by setting a higher priority for the new coming peers, the bootstrap delay of these peers will be reduced. Their simulation results show that average bootstrap delay is reduced by 48%, at the same time, there is no negative impact on other peers performance. Congestion Control Most P2P clients are implemented in the application layer and use TCP as their transport carrier. Applications such as PPLive, PPstream, Xunlei, and BitTorrent open too many concurrent connections to other peers. Data shows that PPLive can open up to 256 connections. In this case, when a P2P client is running, other applications and users suffer bottleneck. For 25

29 example, imagine a usecase where a user has a 10MB Internet bandwidth and a normal non-p2p application A that needs 1MB bandwidth to run. In this case, if the user runs a P2P client who sets up more than 10 connections to its peers, then each of the connections only has up to 1MB/11. In this case, application A lacks enough bandwidth and cannot run correctly. Yaning Liu et al [21] presented a way to detect congestion and a way to raise or decrease the number of TCP connections. Their friendlyp2p solution calculates the throughput of every P2P connection. By comparing the current throughput with the previous recorded throughput, it knows the change of a connection. If throughput of half of the connections is decreased, it means that congestion was detected and P2P clients can reduce the number of connections. TCP is designed to fairly share the bottleneck with all connections [22] thus a P2P application should consider the fairness with other applications to make P2P more friendly to the network. Our decisions Most of the above approaches show us that involving third-party entities requires upfront costs in order to support such peer recommendation services for P2P applications. On the other hand, most studies also highlight the importance of locality and keeping traffic within local ISPs. From a P2P application s point of view, using cheap and simple strategies to select right peers to communicate with influences its overall performance. When it comes to libswift, we consider it should be able to select peers with the following properties: low latency (RTT), be as close as possible (geographically), or be in the nearby ASes. We mentioned that libswift prefers to run on top of UDP, and UDP suggests that congestion control should be made in application layer. Thus, libswift has more potentials to be more friendly to non-p2p applications than other P2P applications who are running over TCP. In this thesis, we ll investigate libswift s congestion control to see whether it is more friendly to 26

30 other non-p2p applications. 2.6 Experimental Evaluation This section describes the procedure to analyze libswift and set up the experimental environment. Later, we explain the tests we devised to test libswift extensions and the software we used. Procedure and testbed In order to analyze and find vulnerabilities in libswift protocol, we investigated: peer exchange procedure, piece picking algorithm and congestion control. First step is to study libswift s source code [14] and verify if the implementation functions according to protocol specification. This study mainly focuses on: how peers exchange addresses with each other, how these peers are used or managed, how libswift chooses which chunks of content will be downloaded next, and what kind of congestion control is used. We want to do our test in an environment where libswift can run close to a real Internet setting. These tests require computers located in different countries to run our code, since, in real world, P2P users are located in different regions and we want our experimental setting to work in a similar way. At the same time, our tests may cause lots of traffic and some unknown results, thus we cannot interfere with the real Internet infrastructure. Therefore, we have chosen PlanetLab as our platform to do the tests. It currently consists of 1129 nodes [3] and these computers are located in different countries. In particular, we investigate the following issues more thoroughly: Peer exchange behavior we construct a small size swarm to study how a peer queries for news peers from the peers it already is connected with. In particular, we want to investigate how PEX messages are handled by libswift. Also, we want to analyze the download behavior which peer contributed more content to the local peer. 27

31 Peer selection method we construct a small size swarm with peers that have different properties RTT, location and AS-number. Specifically, we selected sixteen computers that are located in different countries and are diverse enough to be good candidates for the local peer. Congestion control LEDBAT congestion window size is highly correlated with RTT. In this thesis, we observe how the size of congestion window (CWND) increases and under what circumstances CWND size decreases. We also analyze how an initial CWND size affects data transfer rate at the beginning of the connection. Finally, in order to know whether a bigger CWND size can improve performance, we changed CWND size manually Extensions for libswift After we investigated libswift s peer exchange mechanism and peer selection policy, we found that libswift does not employ any specific peer selection policy. Moreover, libswift does not support P EX REQ message which is necessary when using PEX protocol to exchange peers. Therefore, we modified libswift s source code to add support for P EX REQ message and we decided to design an extension which we call peer selector adapter for libswift to help the protocol manage and select its peers. To test our new adapter (interchangeably, middleware or interface) we integrated it with a peer selection mechanism PeerSelector which was developed by another master thesis project [18]. Testing extensions and modifications We configured two scenarios to verify the function of P EX REQ. First, a new coming peer interacts with peers without sending a P EX REQ message. Second, a new coming peer interacts with peers and sends a P EX REQ message. The local peer should not receive peers in the first 28

32 case, even if it is in a swarm with more than a peer. However, it can receive peers in the second case. Since the functions of peer selector adapter can be verified together with PeerSelector, we did not run any independent test case for the adapter. PeerSelector employs four types of peer selection policies: geo-location, RTT, AS-hops, and random. We tested each policy at least twice to exclude Internet random variables and we run all the tests in the same swarm to maintain the consistency of results. For each policy, we want to study if the selection of peers based on a given property or metric influences libswift s download performance. We then compare the results of the first three policies with the random policy. Aside from evaluating how libswift s download speed changes under different policies, we also verified which peers were selected by PeerSelector and whether such peers worked as expected Software resources and tools We use MaxMind s GeoIP [2] library to get the peers geographic location. GeoIP is not only a free library but also provides an API to the user to check city, country and continent for an IP address. An mp4 file of approximately 40 megabytes was used as the target content when we did the tests. This is a 14 minutes long video file. Usually, a music video is just a half of this length. The download time of this video is enough for us to observe libswift s behavior. To analyze download speed and draw graphs, we use gnuplot [1]. It is a command-line driven graphing utility and it is free. 29

33 Chapter 3 Overview and Analysis In this chapter, we provide an overview of libswift and discuss in greater detail the internal functioning of the protocol. Mainly, we will focus our discussion on three issues outlined in the previous chapter: peer discovery peer exchange and selection, and congestion control. 3.1 Peer discovery basics When retrieving content, there are at least two participants. One is the peer trying to obtain the content and thus it initiates the whole process, and the other peer is responding back with data. We call the first peer a leecher and the latter a seeder who also acts as a tracker. According to protocol specification, when a peer A wants new peer addresses, it should follow the procedure illustrated in Figure 3.1. In step 1, A explicitly sends a P EX REQ message to its connected peer B. In step 2, peer B may respond with a P EX RSP message, which includes a peer C. In step 3, peer A initiates a connection to C by sending a HANDSHAKE message. In case peer A wants more peers, it sends P EX REQ messages to both connected peers B and C, where peer C may reply with a message containing a peer D. At this point, peer A repeats step 3. 30

34 Figure 3.1: The flow of PEX messages Leecher s angle Figure 3.2 illustrates the internal state of a leecher. When libswift runs as a leecher, it starts by opening a new channel. First, it initiates itself and creates a datagram containing a HAN DSHAKE message, channel ID and the roothash of the desired content. Then, it jumps into running state and sends the datagram to the destination peer address. Finally, it waits for a response from the destination peer. The length of waiting time is determined by congestion control. After this waiting time is decided, the leecher jumps to the waiting state. Figure 3.2: State machine of the leecher The destination peer may respond back with a datagram which contains a HANDSHAKE and a HAV E message. While the first message informs 31

35 the leecher that the connection has been set up, the latter message informs the leecher which content the destination has available. Next, the leecher sends a HIN T message to the destination, specifying the content it wants. Again, it has to wait for the response, so the leecher jumps back to the waiting state. Whenever it receives a datagram, it comes back to its running state. If the received datagram contains a DAT A message, the leecher responds to the destination with an ACK message. If in the meantime, the leecher is transferring data with other peers, it will update them about its currently available content by sending them HAV E messages. Seeder s angle When libswift runs as a seeder, it means that this peer possesses content it can send to other peers. In this case, libswift initializes itself and starts listening on a certain port number. Then, it goes to waiting state. When it receives a new datagram with a HAN DSHAKE message, the seeder will respond back with a HANDSHAKE message and its channel ID. In the same datagram, there may be included HAV E messages to inform the leecher of its currently available content. Now that the connection between the seeder and leecher is established, the seeder goes to the waiting state once more. This process is illustrated in Figure 3.3. Figure 3.3: State machine of the seeder 32

36 3.2 Peer exchange and selection To understand peer exchange behavior in libswift, we configured a small swarm with fourteen peers. In addition, we set up an initial seeder A who, at the same time, acts as a tracker. In this setting, our local peer will start downloading data from seeder A. To understand the inner process of peer exchange, we will use logs generated by libswift. Keywords such as +hash, +hs, +hint, -have, -pex correspond to libswift messages such as HASH, HANDSHAKE, HINT, HAV E and P EX ADD. PEX messages Figure 3.4 depicts the messages exchanged between the leecher and seeder A. In line 3, leecher sends the first datagram to seeder A. The datagram includes two messages: +hash informing seeder A that the leecher wants to download the indicated content (the string carried by this meesage is the roothash of the file), and +hs a HANDSHAKE message. From line 6 to 15, the leecher receives HANDSHAKE and HAVE messages from seeder A. On lines 16 and 17, leecher sends a HINT message to seeder A. From line 18 and onwards, leecher receives a new datagram from seeder A, containing P EX ADD (P EX RSP ) messages that inform the leecher about peers seeder A has. Finally, we can see from Figure 3.4 how the leecher does not send P EX REQ messages to the seeder, however, it receives peers from the seeder. This behavior is not compatible (goes against) with the protocol specification which states that A peer that wants to retrieve some peer addresses MUST send a P EX REQ message. Peer selection As we ve seen from the logs in the previous section, the leecher gets a subset of peers from seeder A. Figure 3.5 further shows how the leecher tries to 33

37 Figure 3.4: Message flow I Figure 3.5: Message flow II establish connections with the received peers, following the same sequence of peers as it received them from seeder A. This implies that the current implementation of libswift does not employ any peer selection strategy. Piece picking algorithm As previously explained, libswift downloads data by sending a HIN T message to the seeder. The seeder then sends DAT A messages back to the leecher, according to the HIN T message which specifies the bin number. The bin number represents the chunk that leecher wants to download, and it is commonly determined (or picked) by the piece picking algorithm. This means that, if we record the chunk index of a DAT A message when the leecher receives one, we can understand how libswift picks next pieces. Figure 3.6 reveals that the current piece picking is linear, as most of the chunks are downloaded sequentially. Roughly, we can observe that the first received chunk has index 1, the second received chunk has index 2, and so on; the last received chunk has the largest chunk index. When data transfer is sequential, there are two or more concurrent channels which will be competing with each other. This may often be the case why data is dropped. Appendix A shows that the leecher already 34

38 Figure 3.6: Piece picking algorithm received chunks 4256, 4257, 4258, and so on from peer 193.xxx.xxx.250, but peer 192.xxx.xxx.11 still sends these chunks to the leecher. As a result, the leecher drops data coming from 192.xxx.xxx.11. If libswift were to use random piece picking algorithm to download pieces from these two peers, the chances of chunks being dropped would have been lower. 3.3 Analysis of multiple-channel download Properties of peers can affect libswift s download performance. In this section, we want to figure out how a peer property such as RTT affects download speed. To study this issue, we set up three different groups of test cases (see Fig. 3.8). The leecher is connected to two seeders, as shown in Figure 3.7. As shown in Figure 3.8, in every group, there are three peers. One peer works as a leecher who downloads content from the other two seeders. The first seeder also acts as the initial seeder and tracker, which means that, the 35

39 Figure 3.7: Three peers in the same swarm leecher learns from this seeder about the second seeder s address. Figure 3.8: The setting for three groups In the first group, the two seeders run on the same virtual machine, so they have the same RTT. In the second group, each seeder runs on a different computer in PlanetLab, however, they are located in the same AS and running in the same laboratory, thus they have very similar RTT value. In the last group, we run one seeder on the local virtual machine and the other runs on PlannetLab. In this group, the two seeders are very different: the first seeder has a very small RTT, compared to the RTT of the second one. Finally, all tests for each group were run at least four times. Observed behaviors In the first group, two seeders have the same properties except their port number. Results show that each of the two seeders provide half of the content, moreover, download speed from two seeders is almost equal. Figures show four trials carried out for group one. Figures show the test results for the second group. From the first two trials we can see that the content provided by two seeders is disproportionate. Seeder one provides more content than seeder two and 36

40 Figure 3.9: Group 1, trial 1 Figure 3.10: Group 1, trial 2 Figure 3.11: Group 1, trial 3 Figure 3.12: Group 1, trial 4 the ratio is about 7 to 3. The last two trials show that the ratio becomes more even, approximately 55 to 45. We should emphasize that the RTT of the first seeder is smaller than that of the second seeder. The last group shows very different results from the previous two. All test cases show that the seeder running on the local virtual machine provides much more content. Specifically, more than 90% of the content is downloaded from seeder one, as shown in Figures Analysis Let s say that the leecher, seeder one, and seeder two are A, B, and C respectively. A has two channels to B and C. A seeder typically has to 37

41 Figure 3.13: Group 2, trial 1 Figure 3.14: Group 2, trial 2 Figure 3.15: Group 2, trial 3 Figure 3.16: Group 2, trial 4 handle HAV E messages and send DAT A messages. This process is further illustrated in Figure 3.21 and detailed in the following: Step 1: records that the leecher already has (N-1) chunk, in order to make sure this chunk is not sent again Step 2: waits to send the next datagram Step 3: creates a new datagram which contains DAT A and INT EGRIT Y messages Assume that A just got a chunk of content from B or C and this chunk of content is N-1. A then notifies both B and C with a HAV E message 38

42 Figure 3.17: Group 3, trial 1 Figure 3.18: Group 3, trial 2 Figure 3.19: Group 3, trial 3 Figure 3.20: Group 3, trial 4 (at time t 0 ), confirming that A already got chunk N-1. B and C receive this confirmation after half the RTT time, and they now are aware that A needs its next chunk N. The time B and C spend on processing is γ B and γ C respectively. Both B and C wait for τ B and τ C before sending the next datagram; this timer is determined by congestion control. Once this timer expires, B and C start preparing their datagrams with the next chunk during time δ B and δ C respectively, and then send it to A. After half the RTT time, A receives data from B and C. The data from B arrives at A at: 39

43 Figure 3.21: Seeder s HAVE and sent DATA messages t 0 + RT T B 2 + γ B + τ B + δ B + RT T B 2 And data from C arrives at A at: t 0 + RT T C 2 + γ C + τ C + δ C + RT T C 2 If: (t 0 + RT T B 2 + γ B + τ B + δ B + RT T B ) < (t 0 + RT T C γ C + τ C + δ C + RT T C ) 2 then A will accept data from B, otherwise, A will accept data from C. Because the RTT is always much larger than the time spent preparing datagrams or waiting, RTT plays a more important role in our tests. In the first group, RTT values are equal, thus two seeders provide the same amount of content. But in the second group, RTT of the first seeder is a little bit smaller than that of the second seeder. Consequently, the first seeder contributes more content. Although the ratio becomes smaller in the third and fourth trials, we still observe that the first seeder contributed more content. In the last group, the first seeder has a much more smaller RTT, so the data coming from it always arrives first at leecher compared to the data coming from the second seeder. For example, if A receives chunk 40

44 N from B, it sends HAV E messages to B and C, saying I got the chunk with bin number N. Then B waits to send the next chunk. Whereas, if C has not sent chunk N to A, C will cancel sending chunk N. However, if C receives the HAVE notification after sending the chunk to A, A still can receive the chunk and this chunk will be dropped by A. Therefore, we can say the peers who have smaller RTT contribute more content and have a faster data transfer rate. 3.4 Congestion control Libswift uses LEDBAT at the sender side to control data transfer rate, whereas the receiver side does not use any congestion control. According to LEDBAT specification, a conservative implementation may skip slow-start by setting an initial window size for LEDBAT. The purpose of slow-start is to make a connection have a larger CWND (congestion window) as soon as possible. In particular, there are two phases: slow-start CWND increases exponentially, and second phase congestion control changes to LEDBAT, after CWND has increased beyond a predefined threshold. According to libswift protocol specification, libswift employs slow-start. However, during our tests we found that as soon as the seeder gets the first ACK message from the leecher, libswift changes from slow-start to LEDBAT. This means that libswift changes to LEDBAT too early. Because slow-start increases CWND much faster than LEDBAT, if libswift transitions to LEDBAT too early, it means that libswift does not have a big CWND. Often, this causes the data transfer rate to be very low at the beginning of a new connection. Figure 3.22 shows how CWND size changes with received ACK messages. Red color shows libswift s initial window size of 1, whereas green color illustrates the window size when manually changed to 70. A small ratio of window size decrease means the current RTT increased; a very big ratio of decrease is caused by the timeout of ACK messages. The red line shows that libswift s CWND size increased slowly. If the initial window size 41

45 Figure 3.22: Congestion window size is set to a reasonable value, peers can get the first chunks faster. The green line, representing a bigger window size, shows that our manually changed larger window size exhibits better data transfer rate. Figure 3.23: Overall view Figure 3.24: Detailed view Figure 3.24 shows that if we set a bigger CWND size, we get faster rate at the beginning. Although the overall download performance has not improved, as can be seen in Figure 3.23, the time spend on downloading the first few hundred chunks has decreased, as shown in Figure It should noted that the CWND of 200 in these illustrations is also a test number, 42

46 showing that if we have a larger CWND, download speed can be improved. LEDBAT specification suggests that TARGET should be 100 milliseconds [17], however, libswift uses a value of 25 milliseconds. If libswift were to run on a mobile phone, the current TARGET value is too big. In addition, LEDBAT recommends a GAIN value of 1, whereas libswift implements a much smaller value 1/ To summarize, congestion control in libswift needs further investigation and experimentation to find suitable values for the initial window size, TARGET, and GAIN. 43

47 Part II Design and Implementation 44

48 Chapter 4 Protocol Extensions As previously explained, current libswift implementation does not support P EX REQ message. In this situation, the leecher will always receive peers from seeders and there is no way to stop seeders from sending peers to the leecher. Thus, we will complement the existing implementation to fulfill protocol specification A peer that wants to retrieve some peer addresses MUST send a PEX REQ message. Now, if the leecher does not need additional peers, seeders will stop sending peers back. Secondly, we know that some of the peers in the same swarm have better performance. However, libswift does not have the ability to find which peer is better to use. To manage peers better, we will extend libswift and devise an interface module that enables a more efficient peer rotation mechanism inside libswift and simply call it an adapter. The rest of this chapter will be mainly divided into two sections: explaining P EX modifications and the adapter extension. 4.1 PEX REQ design We do not need a new component to support this functionality. Instead, we employ a true-false switch into libswift. When a peer (sender) sends a datagram to its connected peers, it checks the true-false switch. If the value of the switch is true, it sends a P EX REQ, otherwise, it does not send 45

49 a P EX REQ. The switch is controlled by the adapter and the default is true, but it can also be controlled by an external peer selection mechanism. Whenever a peer (receiver) receives a P EX REQ, it sets the true-false state to true in its corresponding channel. Before it sends the next datagram, it checks the state. If the state is true, it adds the P EX RSP message to the datagram, including current peers. After this, it switches the true-false state to false. Figure 4.1 shows the process of adding a P EX REQ message. Figure 4.2 shows the process of responding to a P EX REQ. Figure 4.1: Sender side Figure 4.2: Receiver side Two functions were added to instruct the channel to send and receive P EX REQ: AddPexReq is used to check the value of the switch. Then, libswift adds P EX REQ message to the datagram that will be sent to the receiver. If the switch s value is false, it just sends the datagram without including P EX REQ message OnPexReq when a P EX REQ message is received, libswift uses this function to set the flag to true to indicate that the sender wants peers. Flag will be changed to false when current peers are added to the datagram. Libswift checks the flag to decide whether it should send its peers to the receiver 46

50 4.2 Design of the adapter We designed and developed an interface module which acts as a middleware between the existing libswift core and an external peer selection mechanism (see Fig. 4.3). Therefore, we call it a peer selector adapter or shortly adapter. Figure 4.3: Design overview Libswift core This module is responsible for interacting with other peers. It transfers content, verifies content, constructs datagrams, sends datagrams to other peers and receives them. When libswift discovers new peers, it relays them to adapter. Similarly, when libswift wants to open channels for communication with new peers, it calls the adapter. Adapter The adapter is located between libswift and peer selection mechanism, as shown in Figure 4.4. Adapter is highly coupled with libswift s implementation and provides the interface to third-party peer selection mechanisms. As soon as an external peer selection mechanism implements adapter s interface, these three components can work together. The advantage of this design is that libswift is decoupled from external mechanisms, enabling us to plug in (integrate) different mechanisms for peer selection. Otherwise, the adapter saves peers addresses to a queue. When 47

51 libswift requests peers, the adapter returns peers from the queue, without ranking them. Figure 4.4: The interaction between components Peer selection mechanism The peer selection mechanism we tested with libswift is an externally developed module called PeerSelector [18]. Once the adapter relays peers to PeerSelector, the latter saves them to a database and then ranks them according to the following peer ranking policies: RTT policy the peer who has the smallest RTT value is placed first, the peer who has the second smallest RTT is placed second, and so on. RTT value is determined by probing the given peer (pinging). AS-hop count policy ranks peers by calculating their AS-hop count. For every peer it gets from the adapter, it calculates its AShop count to the local peer using public BGP records. 48

52 Geo-location policy ranks peers by calculating their geographical distance to the local peer. Geographical closeness is determined using a third-party GeoIP database and API [2]. Random policy peers are returned randomly, no ranking applied. PeerSelector provides three functions to us: Interaction between components Adapter and libswift Figure 4.5: Adapter and libswift core Libswift interacts with adapter in several cases. First, it asks the adapter if it needs more peers. Also, it calls the adapter when libswift discovers new 49

53 peers and needs to store them locally. Furthermore, it calls the adapter when libswift needs certain ranked or not peers. Figure 4.5 illustrates this process. IsNeedPeer is called to check whether libswift needs to discover new peers, by issuing P EX REQ messages. If new peers are discovered (through P EX RSP ), libswift calls AddPeer to store such peers. Finally, when libswift establishes a new channel, it calls GetBestPeer to obtain the the best peer and connect to it. Adapter and PeerSelector Figure 4.6: Adapter and PeerSelector Adapter relays discovered peers to PeerSelector. Figure 4.6 illustrates their interaction. When libswift sets up a new channel, adapter will call PeerSelector to get the best ranked peer. Otherwise, PeerSelector uses handles such as Needpeer to request or not new peers. Designed APIs Two types of API were defined to facilitate the interaction between components. 50

54 Figure 4.7: API used by PeerSelector Figure 4.8: API used by libswift 51

55 Chapter 5 Implementation Implementation work on this master thesis consists of modifications done to add support for P EX REQ, implementation of the adapter module to add support for a peer rotate mechanism, and integration of PeerSelector with libswift source code. 5.1 Libswift modifications Three files: swif t.h, transf er.cpp and sendrecv.cpp were modified. Message P EX REQ was added to swift.h and variables were added to transfer.cpp (file transfer). Two functions AddP exreq and OnP exreq were also added to support PEX functionality: typedef enum {... SWIFT PEX REQ = 11 //make s w i f t support PEX REQ } m e s s a g e i d t ; class F i l e T r a n s f e r {... //We added some members to t h e s w i f t F i l e T r a n s f e r p r i v a t e s e c t i o n. private : S e l e c t o r p e e r S e l e c t o r ; // peer s e l e c t o r adapter p o i n t e r FILE p F i l e ; // f i l e p o i n t e r to save l o g information 52

56 int maxpeernum ; //how many p e e r s t h e s w i f t want to use int r o l e ; // to i d e n t i f y s w i f t. 0 i s seeder, 1 i s l e e c h e r int s o r t ; // t h e s o r t p o l i c y used by s w i f t 0 score, 1 r t t, 2 as hops, 3 //random i n t 6 4 t s t a r t t p ; // timestamp o f f i r s t r e q u e s t s e n t by s w i f t... } ; class Channel {... public :... void AddPexReq ( Datagram& dgram ) ; // add t h e PEX REQ t o datagram void OnPexReq( Datagram& dgram ) ; // r e c e i v e d a PEX REQ protected :... bool p e e r r e q r v d ; // whether r e c e i v e r r e c e i v e d PEX REQ } ; Source Code 5.1: swift.h Module transf er.cpp was modified to add support for the adapter. When libswift discovers (receives) new peers, we use the adapter to save them locally: F i l e T r a n s f e r : : F i l e T r a n s f e r ( const char filename, const Sha1Hash& r o o t h a s h ) : f i l e ( filename, r o o t h a s h ), h s i n o f f s e t ( 0 ), c b i n s t a l l e d ( 0 ) { // In t h e c o n s t r u c t i o n f u n c t i o n o f F i l e T r a n s f e r... p e e r S e l e c t o r = new S e l e c t o r ( ) ; // i n i t i a l t h e s e l e c t o r adapter }... void F i l e T r a n s f e r : : OnPexIn ( const Address& addr ) {... i f (1 == r o l e ) { 53

57 p e e r S e l e c t o r >AddPeer ( addr, hash ) ; //We c a l l t h e adapter to save p e e r s. std : : vector <Address> p e e r s = p e e r S e l e c t o r >GetPeers ( sort, this >r o o t h a s h ( ) ) ; // g e t p e e r s back. int counter = p e e r s. s i z e ( ) ; i f ( counter >= SWARM SIZE) { for ( int i = 0 ; i < maxpeernum ; i ++) { //And i f t h e open channels i f s m a l l e r than t h e maxpeernum Address addrtemp = ( Address ) p e e r s [ i ] ; bool connected = f a l s e ; // judge whether connected to t h e peer for ( u i n t j = 0 ; j < h s i n. s i z e ( ) ; j++) { Channel c = Channel : : channel ( h s i n [ j ] ) ; i f ( c && c >t r a n s f e r ( ). fd ( ) == this >fd ( ) && c >peer ( ) == addrtemp ) connected = true ; // a l r e a d y connected } i f (! connected ) { //we s e t up new channel new Channel ( this, Datagram : : d e f a u l t s o c k e t ( ), addrtemp ) ; } } }... } Source Code 5.2: transfer.cpp Module sendrecv.cpp was extended with two functions AddP exreq and OnP exreq: b i n 6 4 t Channel : : OnData ( Datagram& dgram ) { // l o g g i n g peer address, c o n t e n t l e n g t h and t h e r e c e i v e d time o f t h i s p i e c e o f data. f p r i n t f ( t r a n s f e r ( ). pfile, f i r s t r e q u e s t time=%l l d r e c e i v e d data from %s data l e n g t h=%d time=%l l d \n, this >t r a n s f e r ( ). 54

58 s t a r t t p, addr. s t r ( ), length,now) ; }... void Channel : : Reschedule ( ) {... // Before d e l e t e t h e channel we d e l e t e t h e peer in t h e peer s e l e c t o r. t r a n s f e r ( ). p e e r S e l e c t o r >DelPeer ( this >peer ( ), t r a n s f e r ( ). r o o t h a s h ( ) ) ;... }... void Channel : : AddPexReq ( Datagram& dgram ) { // Check i f we need send PEX REQ. i f (! t r a n s f e r ( ). p e e r S e l e c t o r >IsNeedPeer ( ) ) return ; // Yes, put PEX REQ message t o datagram. dgram. Push8 (SWIFT PEX REQ) ; d p r i n t f ( %s #%u +pex req \n, t i n t s t r ( ), i d ) ; } void Channel : : OnPexReq( Datagram& dgram ) { //we r e c e i v e d a PEX REQ message, record i t. p e e r r e q r v d = true ; d p r i n t f ( %s #%u pex req \n, t i n t s t r ( ), i d ) ; } void Channel : : AddPex( Datagram& dgram ) { // check whether we need send peer to t h e o t h e r s i d e i f (! p e e r r e q r v d ) return ; // i f f a l s e, j u s t r e t u r n.... }... Source Code 5.3: sendrecv.cpp 5.2 Implementation of the adapter module Two modules selector.h and selector.cpp were designed, implementing class Selector. Functions used by libswift and PeerSelector are public. Functions 55

59 AddP eer, DelP eer, GetP eers, and IsNeedP eer are used by libswift, while NeedP eer is used by PeerSelector. In the private section, we have three variables: need peer the switch we designed to indicate whether libswift needs to send a P EX REQ message, inpeers queue used to save peers when there is a peer selection mechanism, and p Btselector pointer to PeerSelector instance. class S e l e c t o r { public : S e l e c t o r ( ) ; // add a peer to database void AddPeer ( const Address& addr, const Sha1Hash& r o o t ) ; // d e l e t e a peer from d atabase void DelPeer ( const Address& addr, const Sha1Hash& r o o t ) ; // do not p r o v i d e t h i s peer back in h a l f an hour void SuspendPeer ( const Address& addr, const Sha1Hash& r o o t ) ; // whether peer s e l e c t o r wants more p e e r s void NeedPeer ( bool need ) ; // used by s w i f t core to judge whether need send PEX REQ. bool IsNeedPeer ( ) {return need peer ; } // g e t p e e r s from database. t y p e : 0 score, 1 r t t, 2 as hops and 3 random std : : vector <Address> GetPeers ( int type, const Sha1Hash& f o r r o o t ) ; // f u t u r e use Address GetBestPeer ( ) ; private : bool need peer ; // a l l p e e r s r e c e i v e d by s w i f t, t h e queue t h a t mentioned in s e c t i o n deque<address> i n p e e r s ; #i f d e f BITswift // t h e t h i r d p a r t peer s e l e c t o r B i t s w i f t S e l e c t o r p B t s e l e c t o r ; #endif 56

60 } ; Source Code 5.4: selector.h Module selector.cpp implements adapter functions. We initialize PeerSelector and set the switch to true (default behavior) in the construction function. Function AddP eer first checks whether PeerSelector is null; if null, it saves peers to the inpeers queue. Similarly, function GetP eers checks if PeerSelector is null; if null, it returns peers stored in the queue. S e l e c t o r : : S e l e c t o r ( ) { #i f d e f BITswift // i n i t a i l peer s e l e c t o r p B t s e l e c t o r = new B i t s w i f t S e l e c t o r ( ) ; #endif // by d e f a u l t, s w i f t needs p e e r s NeedPeer ( true ) ; } void S e l e c t o r : : AddPeer ( const Address& addr, const Sha1Hash& r o o t ) { // i f t h e r e i s no peer s e l e c t o r, we j u s t save i t in a queue. i f ( p B t s e l e c t o r == NULL) i n p e e r s. push back ( addr ) ; // F i r s t we change t h e address o f peer and r o o t hash // to t h e s t y l e t h a t can be used by peer s e l e c t o r. u i n t 3 2 t ipv4 = ntohl ( addr. addr. s i n a d d r. s addr ) ; char r s [ 2 0 ] = { 0 } ; s p r i n t f ( rs, %i.% i.% i.% i, ipv4 >> 24, ( ipv4 >> 16) & 0 x f f, ( ipv4 >> 8) & 0 x f f, ipv4 & 0 x f f ) ; s t r i n g i p S t r i n g ( r s ) ; // then we c a l l addpeer to save i t to peer s e l e c t o r. p B t s e l e c t o r >addpeer ( i p S t r i n g, addr. port ( ), r o o t. hex ( ) ) ; } void S e l e c t o r : : DelPeer ( const Address& addr, const Sha1Hash& r o o t ) { // i f t h e r e i s no peer s e l e c t o r, we d e l e t e t h e peer in 57

61 t h e queue i f ( p B t s e l e c t o r == NULL) { for ( int i = 1 ; i < i n p e e r s. s i z e ( ) ; i ++) { i f ( i n p e e r s [ i ] == addr ) i n p e e r s. e r a s e ( i n p e e r s. begin ( ) + i ) ; } } u i n t 3 2 t ipv4 = ntohl ( addr. addr. s i n a d d r. s addr ) ; char r s [ 2 0 ] = { 0 } ; s p r i n t f ( rs, %i.% i.% i.% i, ipv4 >> 24, ( ipv4 >> 16) & 0 x f f, ( ipv4 >> 8) & 0 x f f, ipv4 & 0 x f f ) ; s t r i n g i p S t r i n g ( r s ) ; // then c a l l d e l e t e p e e r to d e l e t e i t from peer s e l e c t o r p B t s e l e c t o r >d e l e t e p e e r ( i p S t r i n g, addr. port ( ), r o o t. hex ( ) ) ; } std : : vector <Address> S e l e c t o r : : GetPeers ( int type, const Sha1Hash& f o r r o o t ) { std : : vector <i p P o r t s > i p p o r t l i s t ; std : : vector <Address> p e e r s ; std : : vector <Address> p e e r s ; // i f t h e r e i s no peer s e l e c t o r, we g e t peer from our queue. i f ( p B t s e l e c t o r == NULL) { std : : copy ( i n p e e r s. begin ( ), i n p e e r s. end ( ), std : : b a c k i n s e r t e r ( p e e r s ) ) ; return p e e r s ; } //Then, c a l l t h e f u n c t i o n g e t p e e r o f peer s e l e c t o r p B t s e l e c t o r >g e t p e e r ( f o r r o o t. hex ( ), type, i p p o r t l i s t, 2 0 ) ; //Then we change t h e data t y p e t h a t w i l l be used by s w i f t core. for ( std : : vector <i p P o r t s >:: c o n s t i t e r a t o r j = i p p o r t l i s t. begin ( ) ; j!= i p p o r t l i s t. end ( ) ; ++j ) { Address addr ( j >ipaddress. c s t r ( ), j >port ) ; p e e r s. push back ( addr ) ; } 58

62 return p e e r s ; } void S e l e c t o r : : SuspendPeer ( const Address& addr, const Sha1Hash& r o o t ) { // f u t u r e use, need peer s e l e c t o r support, w i l l not a f f e c t our experiment. } void S e l e c t o r : : NeedPeer ( bool need ) { need peer = need ; } Address S e l e c t o r : : GetBestPeer ( ) { // f u t u r e use, need peer s e l e c t o r support w i l l not a f f e c t our experiment. } Source Code 5.5: selector.cpp 5.3 Integration with PeerSelector PeerSelector implements BitSwif tselector class in order to save peers to the local database, and request ranked peers from the database. We use this class, BitSwif tselector.h and BitSwif tselector.cpp respectively, to access the functions of PeerSelector. class B i t S w i f t S e l e c t o r { public : void addpeer ( s t r i n g ip, int port, s t r i n g hash ) ; void d e l e t e p e e r ( s t r i n g ip, int port, s t r i n g hash, int type = 100) ; void g e t p e e r ( s t r i n g hash, int type, std : : vector <i p P o r t s > & i p p o r t, int count = 0) ;... } ; Source Code 5.6: bitswiftselector.cpp 59

63 Chapter 6 Experimental Evaluation We conducted experiments to test the functions of our implemented modules, as well as, make sure P EX REQ message modifications work as expected. These experiments also evaluate if PeerSelector works according to its design, as well as, observe if libswift s download performance improves. To summarize, first experiments test P EX REQ, the rest of experiments evaluate adapter extension. 6.1 PEX modifications Setup We configured a swarm with three seeders running on the same computer under different ports, and a leecher running on a separate machine. The leecher connects to the initial seeder in two test cases. In the first test case, the leecher calls N eedp eer(f alse) in adapter s construction function. This means that the leecher does not need peers and it should not send P EX REQ to the initial seeder. In the second test case, the leecher calls NeedP eer(true) in adapter s construction function. This means that leecher needs peers and it will send P EX REQ to the initial seeder. 60

64 Results Figure 6.1 shows that if the leecher does not send a P EX REQ message to the initial seeder, it can not receive peers. Figure 6.2 shows that if the leecher sends a P EX REQ message to the initial seeder, it receives peers as a result. Therefore our design and implementation work as expected. Figure 6.1: Test case 1 Figure 6.2: Test case Adapter extension Testbed environment To set up a simulation swarm, we have chosen sixteen nodes in PlanetLab and they are running Fedora Linux 2.6, 32 bit OS. In the swarm, one computer acts as leecher and all the other computers act as seeders. Table 6.1 lists the properties of these computers. In geographic score, a smaller value means closer to the leecher. And a smaller RTT means data delay is lower. AS-hop and RTT values are relative to the leecher. To run our implementation, we installed GNU Make 3.81 and gcc version on PlanetLab machines. To be able to run PeerSelector, we 61