Abstract. 1. Introduction

Transcription

1 Supporting s in Gnutella File Sharing Network with Agents Tim Hsin-ting Hu, Binh Thai, Aruna Seneviratne School of Electrical Engineering and Telecommunications University of New South Wales, Sydney, Australia timhu@mobqos.ee.unsw.edu.au, binh@ee.unsw.edu.au, a.seneviratne@unsw.edu.au Abstract The use of peer to peer file sharing networks such as Gnutella is proliferating on the Internet, but its use is bandwidth consuming due to the broadcast nature of some peer to peer protocols. This is undesirable for mobile devices due to their bandwidth and power constraints. This paper proposes an architecture that uses mobile agents to participate in the Gnutella network on behalf of mobile devices in order to reduce the amount of traffic for the mobile device, as well as providing support for device mobility. Using real Gnutella traffic characteristics, analysis on the viability of the architecture is presented. 1. Introduction Since the introduction of Napster [9] in 1999, file sharing using peer to peer (P2P) networks is increasing in popularity among the Internet community. Despite the death of Napster in recent years, alternative P2P networks have emerged to replace Napster, such as Gnutella [5] and Fasttrack [4], and the number of users is ever increasing. devices and wireless networks are also becoming popular in recent years. Users now have the ability to gain access to the Internet via portable devices such as a PDA or a cellular phone via different types of wireless access networks such as GRPS and IEEE wireless LAN. However, although mobile devices and wireless networks provide users the convenience of accessing the Internet from anywhere, they have various limitations. For mobile devices, the limitations include small screen size, limited battery life, CPU and memory. Wireless networks are also more prone to errors since it uses air as its transmission medium. Hence they provide lower bandwidth, higher delay, and less reliability compared to fixed wired networks. Due to these limitations, there are various Internet services, including P2P file sharing, that are not suitable to run on mobile devices over wireless network. s join and maintain membership in current file sharing P2P networks such as Gnutella by sending heartbeat messages to its peers. This can result in devices transmitting and receiving large amounts of network traffic, confirmed by Portmann et al [11] and from our traffic measurements of Gnutella. This causes the following problems for mobile devices, especially ones that access the Internet via any type of wireless network: The periodic sending and receiving of these heartbeat messages to and from its peers require the network interface of the mobile device to be on at all times. Constant usage of the CPU is also required to process these messages. This can easily drain the power and reduce the operation time of the device. The bandwidth available for wireless networks is limited, and the high volume of network traffic generated by P2P protocols will not only cause congestion on the network, but also result in high costs to the user. The unpredictability of wireless networks can cause a mobile device to be suddenly disconnected. Intermittent disconnections will be taxing on the mobile device as it constantly spends overhead rejoining the network. It is also taxing on the network as a whole, as nodes need to re-establish connections with transient mobile device nodes. devices can easily migrate between different networks. This migration can lead to a mobile device changing its IP address. When the mobile device s IP address changes due to migration, its peers do not have the capability to detect that change, as the current P2P protocols are not mobility aware. With regards to the problem of high volume of traffic, the situation has improved with the new versions of the P2P protocols, such as Gnutella version 0.6. The protocol now designates nodes that have more resources to act as ultrapeers or supernodes. Ultrapeers shield network traffic from nodes that have fewer resources, termed the leaf nodes. However, P2P file sharing is still not suitable for mobile devices, as P2P protocols do not support mobility, making it difficult for mobile devices to remain persistent on a P2P network if migration is frequent. This persistency problem is compounded if nodes participate in the P2P network by wireless access. We believe that it will be possible to overcome the above-mentioned problems by using a mobile agent. agents have the characteristics of being mobile, autonomous and persistent [10]. Instead of the mobile device attaching to the P2P network, a mobile agent can connect to the P2P network and act on behalf of the mobile device. A lightweight protocol is used to reduce the amount of traffic on the network between the mobile agent and mobile device. In this paper we present an

2 architecture of such a system with analysis of traffic measurements to evaluate its viability, with particular focus on the Gnutella P2P protocol. The paper is organised as follows: Section 2 describes the specification of the Gnutella P2P protocol and Section 3 presents work which address similar issues. Section 4 describes our mobile agent system that achieves the objectives. Section 5 presents the results and analysis of the traffic measurements, and finally section 6 presents the conclusions and describes our future work. 2. Review of Gnutella P2P Protocol 2.1. Gnutella Protocol Version 0.4 The original Gnutella protocol, known as protocol version 0.4, allows nodes on the Internet to form an overlay network with each other. Each node termed a servent or a peer on this network, and each peer maintains connections to several other peers. Peers on the Gnutella network co-operate to share files, and they are given equal responsibilities in the network, including the sharing of files, performing searches and routing of information. A new node first joins the Gnutella network by making a TCP connection to any existing peer on the network. Once a peer discovers other peers whilst participating in the network, it can choose to connect to them in similar fashion. Ping messages are transmitted by peers to discover other potential peers and act as heartbeat messages to already connected peers. The frequency of Ping transmissions varies between different servent developers. When a Ping is received by a peer, the Ping is broadcasted with a decremented time-to-live (TTL) to all its other peers; it may also reply with a Pong message to indicate its existence. The Pong message contains information such as the peer s IP address and the amount of data it shares, which the requesting peer may then use to connect to the responding peer. The Pong message, with a TTL equal to the hops travelled by the original Ping, is returned on the same connection that the Ping originated from. The Pong traverses the same path as the Ping in the reverse direction, passing through the same intermediate peers, back to the pinging peer. Peers drop any Pongs that do not correspond to any previously seen Pings. When a peer searches for a file, it broadcasts a Query message to all its connected peers. The broadcast mechanism of Query is the same for Ping. If a peer finds files matching the criteria of the search, it will reply with a QueryHit message, which contains the necessary information to download the file. QueryHit messages are returned on the same paths as the Query back to the requesting peer, in the same fashion as Pong messages. Once a peer receives a QueryHit message answering a search, the peer may use the information contained within the QueryHit message to initiate the direct download (via HTTP) from the peer owning the file(s) described in the QueryHit. If the requesting peer receives a QueryHit message from a responding peer that cannot support incoming connections, commonly due to firewall restrictions, the requesting peer may then use a Push message to initiate the download. The responding peer uses the address information in the Push to upload the file to the requesting peer Gnutella Protocol Version 0.6 Many vendors of clone Gnutella clients had made independent changes to the original protocol since its release. Although the core operations described in section 2.1 remained, over time, disparate protocol differences resulted in segmented overlay networks, each network comprising of a few compatible or the same client types. Version 0.6 was in part an informal standardisation of the Gnutella protocol changes [13], thus achieving interoperability amongst the major vendors. Version 0.6 makes several extensions and enhancements to the Gnutella network; the features that address similar issues to this paper are described below. Interested readers may refer to [5] for full details: Pong Caching Pong caching refers to schemes which reduce the amount of traffic on the network by reducing the number of Pings and Pongs. Peers regularly cache Pong information from neighbours and when a Ping is received, multiple Pong s are returned from the cache and the Ping is not propagated further by broadcast, thus conserving bandwidth [5]. Multiplexing many incoming Pings into a single outgoing Ping and conversely demultiplexing incoming Pong to multiple outgoing Pongs is also employed to reduce traffic [8] Ultrapeer A hierarchical Gnutella network is built by classifying peers as either ultrapeers or leaf nodes. The scheme creates a two level hierarchy where more capable peers with better network and faster CPU (ultra) act as proxy for the slower, less capable peers (leaf). The ultrapeers shield leaf nodes from excessive traffic, and thus conserves bandwidth by reducing the overall amount of traffic on the network. Leaf nodes maintain single connections to ultrapeers, and the ultrapeers shield the leaf nodes from all incoming Ping traffic. This means that the leaf nodes will not have to respond with Pong messages. Ultrapeers also shield leaf nodes from Query messages by the following schemes:

3 Reflector Indexing: Ultrapeers periodically polls its leaf nodes with an indexing Query. Leaf nodes then respond with QueryHit of all shared files. Ultrapeers cache the index of its leaves content and responds to Query messages on behalf of the leaf nodes. This scheme shields the leaf nodes from all query traffic. Query Routing Protocol (QRP) [12]: Leaf nodes submit hashed descriptions of the files to its ultrapeers. The hashed descriptions cannot represent the shared files exactly. The ultrapeers filter any Query messages and only forward them to leaf nodes that will most likely have a match. This is the preferred method in most Gnutella clients. 3. Related Work The JXTA for J2ME Project [6] is perhaps the closest work to our proposed architecture. It is an initiative spawned from JXTA in providing a programming environment aimed at creating peer-to-peer applications that are suitable for the constraints limiting mobile wireless devices, but still maintaining interoperability with the rest of the JXTA framework. To achieve this, JXTA Relays are introduced to perform resourceintensive tasks on behalf of mobile devices. devices connect to the JXTA Relays, which act as proxies for the devices. The Relays perform discovery and registration of peers and peer groups, searching, peer communication on behalf of the mobile devices, as well as filtering and compression of JXTA traffic. Much like the rest of the JXTA initiative, the details and implementation of this project is still a working progress. 4. The Agent P2P Architecture Gnutella protocol Figure 1 The Agent P2P Architecture light weight communicaiton protocol Given the properties of mobile agents described in [7], the Agent P2P architecture is shown in Figure 1. The architecture consists of a number of hosts on the network that contain execution environments for mobile agents. The execution environment not only provides a place for mobile agents to execute their program code, but also serve as a resource and security control for the host. The mobile agent that represents its mobile device executes the Gnutella file sharing protocol, joins the existing P2P network and communicates with other P2P hosts in one of these execution environments. Finally, the mobile device and the mobile agent communicate via a lightweight communication protocol, which will be explained later in this section Operations of the P2P Architecture The following operations are needed to support mobile devices on a Gnutella file sharing network Joining a Gnutella Network As illustrated in Figure 2, the operation for a mobile device to join a Gnutella network is as follows: When the user wishes to join the Gnutella network, s/he will launch a file sharing application on the mobile device. The application then creates a mobile agent (1) which gathers information about the device, such as its IP address, CPU and network capabilities, and a list of files that the user wants to share. The mobile agent then migrates to a host that contains an execution environment (2). Upon arrival, the mobile agent reports its location back to the mobile device (3) and joins the Gnutella network (4) Figure 2 joining the Gnutella Network Notice that the mobile agent only carries with it a list of files that the user is willing to share on his/her mobile device, not the files themselves. We believe that it is impractical for the mobile agents to carry the files, as this will incur a very heavy and unjustifiable migration cost Searching for a File When the user wants to perform a file search on the Gnutella network, the required parameters is entered into the file sharing application running on his/her mobile device. The application communicates the search criteria to the mobile agent using the lightweight communication protocol. The mobile agent then translates this message into a Gnutella Query and broadcasts it to its peers. When the search results are returned, the mobile agent gathers and sorts them in order of reliability of the replying peers. The sorted results are then sent back to the mobile device. Based on the network capacity of the mobile device, the mobile agent may choose not to send back the entire set of results it may only send back the ones which are at the top of the list, since those peers have the highest reliability. If the query yielded no

4 results, the mobile agent will signal this back to the mobile device. The mobile agent is also expected to receive search queries from other peers on the network. It can determine whether a match exists by searching the list of files from the mobile device, and reply to searches accordingly. While the user is running the file sharing application, the files that s/he wants to share may change at anytime. With this variability, the mobile agent needs to ensure its file sharing list is consistent with the files that are actually been shard by the mobile device. This is achieved by the mobile device sending update information to the mobile agent whenever there is a change in the file sharing status, for example, a new file is added to the file sharing directory or an existing file is removed from sharing File Upload/Download Since the mobile agent only maintains a list of the files which the user is willing to share, a download request (in the form of HTTP) from other peers to the mobile agent must be forwarded to the mobile device. This function is similarly to a HTTP proxy. If the mobile device is offline or in an area that has no network connectivity, then the mobile agent will reject the request. There are two options when the user wants to download a file from other peers: From the results of the search, the user knows the address of the peers that contain the files for download. Hence the file sharing application can send the download request directly to that peer, bypassing the mobile agent. (Figure 3a). (a) HTTP Request Request for file download HTTP Request Figure 3 Options for Download Operation (b) If the mobile device is in the area where network connectivity is unstable, or the user may wish to disconnect from the network for a period of time, the mobile agent can download the file on behalf of the mobile device. The file sharing application on the mobile device would send a download request to the mobile agent using the lightweight communication protocol, specifying the file and the location of the file, obtained from the returned search results. The mobile agent then sends a download request to the peer and initiates the download. The downloaded file can be stored at the host of which the mobile agent is currently executing, or some well-known storage servers on the Internet (Figure 3b) Mobility Support In our architecture, the mobility support is twofold, since both the mobile device and mobile agent have the ability to change its location. The operation of supporting terminal mobility is as follows: When the mobile device migrates from one network to another, there is a possibility that its IP address may change. As illustrated in Figure 4, if the IP address of the mobile device has changed (1), the file sharing application will communicate with the mobile agent to notify this change (2) Figure 4 Mobility Support 5 4 With the migration of the mobile device, the mobile agent may choose to migrate to another execution environment so that is can operate as close to the mobile device as possible. This can improve the performance of the lightweight communication protocol between the mobile device and the mobile agent, as wireless transport layer protocol such as Berkeley s TCP Snoop [1] is designed to operate close to the mobile device. There might be other circumstances where the mobile agent might need to migrate, for example, when its current execution environment is running out of resources. The method of discovering other suitable executing environments shall be addressed in future research, with the possibility of using the peer to peer network itself to discover new surrogate hosts. Also illustrated in Figure 4, if the mobile agent migrates, it does so by firstly suspending any download operations. The mobile agent then keeps a record of its current peers before it disconnects itself from the network, since a mobile agent cannot migrate along with opened socket states (3). Once the mobile agent successfully migrates to the new execution environment, it notifies the mobile device of its new location (4), then rejoins the Gnutella network and resumes any pervious file downloads (5) Lightweight Communication Protocol The lightweight communication protocol between the mobile device and mobile agent was designed to ensure that the traffic between the two entities is kept at a

5 minimum, while maintaining the basic functionalities of the typical Gnutella file sharing application. The reliability of the messages is guaranteed with the use of TCP as the transport layer protocol, and the performance of the protocol can be improved using TCP snoop. Similar to HTTP, our lightweight communication protocol is text based, and it is of a request/response nature. Six different types of messages are used between the mobile device (MD) and the mobile agent (): Location Update: Used by either the MD or to update the other of its new IP whenever one has changed its location. Query: Used by the MD to submit search criteria to the, and the will perform the search on behalf of the MD. will reply with the list of results if the search is successful. Download: Used by the MD to tell the to download a file on its behalf. The message contains the name and the location of the file. Download Status: Used by the MD to query the download status of a particular file. Download Complete: Used by the to notify the MD when download operation is complete. The message contains the location where the MD can retrieve the file. Bye: Used by the MD to inform the that the user no longer wants to participate in the network. The will terminate all connections to its peers, cease any download operations and destroy itself. 5. Initial Analysis and Traffic Measurement The viability of our scheme is dependent on a number of factors: 1) the size of the mobile agent, 2) rates at which the Gnutella messages are generated/received and 3) the length of time which the session runs. Given the size of the mobile agent is fixed (as it is simply execution code), our scheme can produce significant savings if the message generation/receive rates are high and/or the length of the session is long Traffic Measurement In order to determine the amount of traffic generated with an existing Gnutella client, packet data was captured over continuous periods to monitor the bytes received and the proportions of the different Gnutella message types. During the monitoring process, there was no search initiated from our client. The files shared were purposely selected to generate no hits from searches, yet large enough not to be treated as a free-loader. Both of these measures ensure that we do not contribute any traffic to the network, allowing passive monitor of the network, thus giving an indication of the minimum traffic required to participate as a Gnutella peer. BearShare [3] is the Gnutella client of choice for monitoring, as it gives the user the choice of operating as one of the three Gnutella entities: Leaf, Peer or Ultrapeer. The results, expressed as percentage of different message types, are presented in Table 1. It can be seen that the dominant component of the traffic is the Query messages. It is also interesting to note that when BearShare acts as a Leaf node, Ping and Pong messages are more symmetric, and together with Query messages accounts for almost all of the traffic. As a Peer node, 95% of the traffic is Query. Finally, as an Ultrapeer, the proportion of Query messages to the other message types is less compared to other node types, yet the proportion of QueryHit messages increases. Table 1 Distribution of Bytes Node Configuration Ping Pong Query QueryHit Push Leaf Peer Ultrapeer The fact that Pings and Pongs account only for a small percentage of the traffic is in stark contrast to previous measurements of Gnutella traffic in [11] where Ping messages dominated more than half of the traffic. It is clear that the current Gnutella network has evolved since, and the difference in traffic proportions resultant from the architectural change towards a more hierarchical structure, as well as efforts to reduce Ping and Pong messages as outlined in Section 2. Traffic (MB) Leaf Peer UltraPeer Time (hr) Figure 5 Accumulative Traffic w/ Different Node Configuration We also plotted the cumulative traffic against time for the three Gnutella node configurations, and they are illustrated in Figure 5. It can be observed that the amount of traffic generated by the Gnutella client accumulates very quickly, especially if it is configured as a Peer or Ultrapeer. As suggested in Table 1, a large amount of this traffic originates from Query and QueryHit messages. With the use of a mobile agent, the large volume of traffic will be shielded from the mobile device. In determining at which point our scheme can provide any bandwidth savings, we estimated our mobile agent to

6 have an upper bound of 3MB in size, based on the current Java mobile agent technology and implementations of the Gnutella client Limewire, which is also written in Java. The initial mobile agent overhead cost is compensated by the amount of traffic it shields for the mobile device. This is expressed as the duration in which the mobile agent has to exist in the network in order to recuperate the initial mobile agent migration cost. Using the accumulative traffic results the average bandwidth usage of each Gnutella node configuration was determined, and the running time required to recuperate the initial mobile agent cost is illustrated in Table 2. Table 2 Time required to recuperate initial Agent cost Node Configuration Bandwidth Usage Time (min) Leaf 1.21kb/s min Peer kb/s 3.62min Ultrapeer kb/s 2.15min Since the mobile agent will respond to Query messages on behalf of the mobile device, it must contain the complete file descriptions in order to perform the searches. This is in contrast to the Query Routing Protocol operating between leaf nodes and ultrapeers, where the file descriptions maintained by the ultrapeer are simply hash values, resulting in Query forwarding with certain inaccuracy. Assuming that searching is performed on the name of the files, and that each file name is 35 bytes long 1, 3500 bytes need to be transferred to the mobile agent for 100 songs. Again, this cost is expressed in terms of the mobile agent uptime in shielding the amount of Query messages for the mobile device, given in Table 3 Table 3 Time required to recuperate the file description cost Node Configuration Bandwidth Usage Time Leaf 1.09kb/s 24.97s Peer 93.01kb/s 0.29s Ultrapeer kb/s 0.25s It can be seen from our results that when a Gnutella client is configured as Peer or Ultrapeer, our scheme can provide significant savings. However, most Gnutella clients would not run as a Peer or an Ultrapeer but as a Leaf, due to low bandwidth access networks (eg. Modem access). From our results, it appears that our scheme does not provide any savings when compared to nodes configured as Leaf; rather it generates a significant overhead from the migration of the mobile agent. However, one must take into account that our estimate for the size of the mobile agent is generous. We believe that with careful implementation, the size of the mobile agent can be reduce significantly, thus making it more attractive even if the client decides to operate as a Leaf. 1 The value is estimated using the average length of the artists and names of the top 100 favorite songs of all time in the UK. [2] 6. Conclusion and Future Work It can be seen from this paper that a node on the Gnutella network will handle a high volume of traffic. Hence file sharing through a P2P network is not suitable for mobile devices, which have limited battery life and potentially limited bandwidth due to the use of wireless access networks. Also, the protocol does not support mobility, making it difficult for mobile devices to be persistent on a P2P network if migrations are frequent and intermittent connection due to wireless access occurs. To address these issues, we introduced an architecture that uses mobile agents to support mobile devices in a P2P network. A mobile agent attaches itself to the P2P network and acts on behalf of the mobile device, communicating with the mobile device using a lightweight communication protocol. The mobile agent provides the advantages of reducing unnecessary traffic to the mobile device, greater support for mobility, and enabling the participation on the P2P network with fewer interruptions. The architecture proposed can produce significant savings if the message rates are high and/or the length of the session is long, as confirmed by our traffic measurements. Being a concept in its early stages, there are still a number of issues we need to address. These include optimisation of our lightweight communication protocol and the effects of frequent migration on the architecture. 7. References [1] Balakrishnan H, Seshan S and Katz R, Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks, ACM Wireless Networks, Volume 1, Issue 4, December [2] BBC News: The top 100 #1 singles, /1/hi/entertainment/music/ stm [3] Bearshare Homepage, [4] Fasttrack Homepage, [5] Gnutella 0.6, Development/GnutellaProtocol-v draft.txt [6] JXTA for J2ME, [7] Lange D, Mitsuru O, Programming and Deploying Java Agents with Aglets, Addison-Wesley, Massachusetts, [8] Limewire Ping Pong Scheme, [9] Napster Homepage, [10] Pham V, Karmouch A, Software Agents: An Overview, IEEE Communication Magazine, July 1998, p [11] Portmann M et al, The Cost of Peer Discovery and Searching in the Gnutella Peer-to-Peer File Sharing Protocol, In Proc. Of IEEE International Conference on Networks (ICON), October, [12] Query Routing Protocol, the_gdf/files/proposals/qrp/ [13] The Gnutella Development Forum,