Patent Application
20110202652
The present invention relates to peer-to-peer networks generally and, in particular, to a method and apparatus for monitoring the performance of a peer-to-peer network with minimal impact on the overlay topology and performance of the monitored peer-to-peer network.
As used herein, “/” denotes alternative names for the same or similar components or structures. That is, a “/” can be taken as meaning “or” as used herein. A Kad network is a specific type of peer-to-peer (P2P) network. Kad is related to Kademlia. A Kad-type network is considered a third generation P2P network. First generation P2P networks relied on a central repository to coordinate lookups on the P2P network including lookups for peer locations and lookups for content location. Second generation P2P networks did not rely on a central unit/node or repository to perform lookups but rather flooded the P2P network in search of content. Third generation P2P networks such a Kad and Kademlia use distributed hash tables to locate content in the P2P network. It is, of course, extremely desirable to locate content quickly.
Given that as background, one might wish to monitor the performance of such a network. There are many reasons for this desire. One is to locate illegal file/content downloading in order to prevent piracy. Another reason is to target advertising. Yet another reason is to understand and model Kad network performance and behavior in order to determine if such a network could be used in another application.
One approach for capturing Kad traffic is to randomly place a few instrumented peers within the network. Each instrumented peer passively monitors and logs traffic. While this approach may provide insight into a median peer's experience, the small sample size sheds little light on the typical Kad traffic pattern.
An alternative approach is to insert a large number of instrumented peers to monitor traffic at many points within the Kad network. Unfortunately, adding a large number of monitoring peers is impractical due to the requirement on computational resources. Even if it was possible, such a brute force approach artificially increases the number of peers in a Kad network, disturbing and changing the existing system, i.e., altering the traffic pattern of underlying network that the monitoring system was designed to monitor.
Mistral, developed by Steiner et al., is the closest known monitoring tool to the present invention, which is called Montra herein. The basic idea of crawling the network and using protocol features to add monitors to routing tables of actual peers is the same between the two techniques. However, the technique of the present invention introduces the concept of a monitor with least visibility (MLV). MLVs allow the Kad network to be monitored without disrupting the network. MLVs gracefully cope with churn and give a fairly accurate measure of traffic. Mistral, on the other hand, can disrupt the system.
Through the present invention, a technique has been developed to capture Distributed Hash Table (DHT) traffic without affecting/disturbing the underlying system. The present invention monitors the destination traffic of peers whose IDs fall into a range of a continuous ID space. One instrumented Kad peer is deployed per peer to monitor its traffic. The visibility of monitors is limited so as to minimize the disruption caused by the large number of monitors.
A method and apparatus are described including determining if a received message is from a monitored peer, forwarding said received message to a coordinator responsive to said determination, determining if the received message is a request message, opening a port for the peer responsive to the second determination, forwarding the request message to a monitored peer via the opened port and forwarding a response message to the monitored peer responsive to the second determination. Also described are a method and apparatus including determining if a received message is from a peer locator, clearing peers from a database responsive to the determination, generating a request message for each monitored peer in the received message responsive to the determination, forwarding the generated request messages to each monitoring peer, determining if the received message is a response message, marking a monitored peer responsive to the second determination, logging the received message, determining if the received message is a heartbeat message, determining if the heartbeat message is from a monitored peer responsive to the third determination, generating a response message responsive to the fourth determination and forwarding the response message to the monitoring peer. Further described are a method and apparatus including retrieving records from a file and searching for and matching records of the file based on a requested content identifier and an identification of a destination peer.
The present invention is best understood from the following detailed description when read in conjunctions with the accompanying drawings. The drawings include the following figures described below:
A naive approach for capturing DHT traffic is to deploy a few instrumented Kad nodes, namely monitors, randomly across a Kad network. These instrumented Kad nodes passively monitor and log observed traffic. The problem with this approach is how to determine proper number of monitors. A small number of monitors will not be able to capture enough traffic samples to draw reliable conclusions. On the other hand, a large number of instrumented Kad peers/clients/nodes will change the underlying system itself. Thus, the measurement result is influenced/changed by the monitoring tool. To address the above issue, the present invention classifies Kad traffic into two categories:
Routing traffic is a direct consequence of the destination traffic coupled with the Kad routing protocol. Since the structure of the Kad P2P network is well understood in theory and can be measured efficiently using a crawler, it is sufficient to measure the destination traffic and derive the properties of a Kad system. In addition, it turns out that measuring the destination traffic alone is much more tractable.
The present invention captures the Kad destination traffic observed by a single peer, called target peer Pt, by placing a monitor (Pm) adjacent to Pt in the ID space such that no other peer lies between Pm and Pt. In this scenario, whenever Pt receives a destination request, it always informs the request originator Pr about the existence of Pm, even if Pt itself is the closest peer to the requested ID (content). Pt behaves this way because, in Kad, global decisions about finding the closest possible node to a requested ID are made at Pr. Pt is only responsible for making a local decision to find n closest possible peers to the requested ID based on its own routing table. As a result, Pt always selects Pm along with other peers, for all the destination requests because according to Pt's routing table, Pm is the closest peer to the requested ID. Once Pr learns about Pm then Pr sends the same request to Pm, which achieves a goal of the present invention. This process is shown in
1. Pr sends a request for a given ID to Pt.
2. Pt sends a response to Pr, which contains the contacts of next hop nodes. If Pt is the closest node to the requested ID then Pt includes the ID of Pm in its response.
3. Since Pr wants to find n closest nodes to the requested ID, it sends the same request to Pm even though the closest node to the request has been found.
This strategy allows traffic from a single node in Kad to be captured. However, traffic from multiple points in the network must be observed in order to capture the representative traffic. A large number of samples must be collected without affecting the peer population. This is accomplished by keeping the monitors minimally visible. The basic idea is to make the monitor visible to the target node however not to other nodes in the network. This enables a monitor to receive all the destination traffic observed by a target node, without affecting any other nodes in the network. A target node learns about the existence of a monitor when the monitor is added to its routing table. Based on the routing table of a target node, a monitor is always the closest peer for a destination request because the target node does not add itself to its own routing table. Thus, whenever a target node observes a destination request, it always informs the query originator (requester, Pr) about the presence of the monitor. As a result, the query originator sends a request to the monitor, which allows the monitor to observe the destination traffic without affecting the Kad network and its function. The monitor remains minimally visible by only responding to heart beat (HELLO REQUEST) messages from the target node. All the other messages from any other node in the network are logged but are not responded to. As a result, every other node in the network considers the monitor to be a dead node. But the target node considers the monitor to be alive because it receives responses to heart beat messages.
How a monitor identifies the destination traffic of the monitored node, i.e., how a given monitor distinguishes routing traffic from destination traffic and filters out the routing traffic is now described.
This present invention solves this problem by monitoring a continuous zone of Kad ID space. The idea is to monitor all the nodes that share the same n high order bits. The n high order bits are the zone prefix. For example, if n=8 and zone prefix is 0xa4, the zone includes all nodes whose high order 8 bits match 0xa4. The high order bits are the most significant bits. That is, the address is big-endian.
Any request that matches the zone prefix and enters the monitored zone is bound to have a destination in that zone. As a result, all the requests, which are captured by the monitor, must be destination requests. Some intermediate monitors may observe these requests as routing requests and one monitor finally observes the request as destination request. The monitors log all the observed requests. In the off-line post measurement processing, all the logs are compared. The Kad node that is the closest to a given request is considered to be the actual destination node, while the requests observed by other monitors are discarded as routing requests. The available computational power and network bandwidth limit the size of monitored zone. 6 bit zones on a Core 2 Duo—2.2 GHz machine with 1 GB RAM have been successfully been monitored, dropping a very small fraction of packets.
While the above mentioned approach is extremely lightweight and causes minimal disruption, only the following information can be extracted from the observed traffic:
Based only on the above SEARCH/PUBLISH requests, Keywords and Files cannot be distinguished. Hence nothing can be learned about different characteristics of files that are being searched or published. To address these limitations, the present invention can be extended at the cost of introducing minimal disruption to the system. Any SEARCH or PUBLISH request from a Kad client progresses in two phases. When a monitor receives a request from the first phase, it sends a response. The response does not carry any next hop contacts but it informs the request originator (Pr) that the monitor is alive and can receive a request during the second phase. As a result, the monitors of the present invention receive SEARCH/PUBLISH requests, which carry additional information about files and keywords being searched/published.
This extension/enhancement causes minimal disruption to regular operation of the system. As a result of this addition, when content is published, instead of being published at 10 closest possible nodes, it is published at 9 nodes. The monitors of the present invention log the published information but do not maintain it as this is an additional overhead. Also, when SEARCH requests are sent to 300 closest possible nodes then 299 nodes will respond to the query. Since the monitors of the present invention do not maintain published information, it is not possible to send responses to SEARCH requests. Also, responding to the request messages results in more visible monitors which lead to system disruption as well.
To avoid these shortcomings of the extension, requests for a given content ID are responded to only once. When an actual SEARCH/PUBLISH request for a given content ID is received, the following information about that ID is extracted and stored into the database:
This extension to the present invention is shown in
Optional message exchanges are as follows:
The Lightweight Kad monitor tool is described below. A python-based Kad client was modified and used as a virtual node. Instead of running one separate monitor to monitor a Kad node, one virtual node is executed that simulates the presence of multiple peers. This is possible by monitoring the traffic of different nodes using different ports. For example, if the client is monitoring a population of 4000 peers, the virtual node opens 4000 ports, and listens for the messages related to individual monitored nodes. In addition, the virtual node makes it possible to share monitoring state information, including content ID, keyword ID, node IDs in the monitored zone, etc. This information is essential in identifying destination traffic as well as the type of destination traffic.
A Kad crawler is known in the art and is used to locate all the peers in a monitored zone. The Master selects a zone to be monitored. A zone is a specific small section of the Kad network typically on the order of 1/64 of the network. The Master advises the crawler which zone to monitor. The crawler starts with a few known contacts in a given zone and downloads their routing tables. In order to download a routing table from a single peer, the crawler generates targeted query IDs based on the target peer ID. The crawler then sends request messages for the generated query IDs to the target peer. The peer responds to those queries with response messages, containing contacts, as it would respond to any request message, thus informing the crawler about a part of its routing table. By sending such queries, the crawler can download the entire routing table of the target peer. The crawler then repeats the same process with every discovered contact in the zone and thus incrementally learns about all the peers in a given zone. The crawler runs on a six node cluster.
While crawling, the crawler must avoid peers behind network address translation (NAT) boxes. Such peers do not participate in routing and, as a result, cannot be monitored. These peers are registered with the Kad network because, just like any other peer, they respond to all HELLO REQ messages. However, every message sent by a peer behind a NAT box is sent from a different port, which is open only for a short period of time. As a result, all routing messages sent towards a peer behind a NAT box are not delivered.
Given the continuously changing peer population of a P2P system, crawling a given zone only once is not adequate. Since the present invention needs to monitor all nodes in a given zone, the arrival of new peers in the zone must be detected quickly. This is achieved by performing back-to-back crawls, i.e. a new crawl starts as soon as the current crawl ends. Back-to-back crawls also help the present invention to learn about missed contacts. Since Kad uses user datagram protocol (UDP) for almost all the communication except for file transfer, it is possible that some UDP packets are lost during a crawl and these contacts are left undiscovered. This is because UDP does not guarantee reliability or ordering.
The present invention works accurately without detecting departure of individual peers. When a target node leaves the network, the monitor for that particular node will stop receiving the traffic because of its limited visibility. However, in order to save memory and recycle port numbers, the present invention still detects peer departure by comparing back-to-back crawls. The data collected for the departed peers is discarded using the heuristic that if a given peer does not respond for m consecutive crawls then it is considered dead. In experiments m was set to 4. A departed node/peer is no longer “live”. That is, the departed node/peer is no longer a member of the Kad network.
In order to add a monitor to the routing table of a target node Kad's HELLO REQUEST and HELLO RESPONSE messages are used. The HELLO REQUEST messages are normally used by a Kad client to determine if a new or existing peer is alive. A HELLO RESPONSE message is sent by peer in response to a HELLO REQUEST message to confirm its liveliness. A combination of HELLO REQUEST and HELLO RES messages are used, depending on the eMule version used by the target nodes, to add the monitors of the present invention to the routing tables. Monitors are added to clients with versions between 0.45a (when eMule started supporting Kad) and 0.47a by sending a single HELLO RESPONSE. For versions between 0.47b and 0.48a, 2 HELLO REQUEST messages are sent to each client. This activity is performed by the virtual node. The virtual node detects the software version by using the information embedded in the HELLO REQUEST and HELLO RESPONSE messages and then adapts the sequence of registration messages accordingly.
The implementation of the Listener of the presentation was kept as lightweight as possible so that the Listener can receive a maximum number of packets without dropping them. Thus, the Listener's only responsibility is to efficiently send and receive messages. The Listener does not maintain any information about target peers, analyze requests, log requests or generate responses. In order to optimize the Listener's performance, another component called the Master has been added. The Master acts as a coordinator between the Listeners and the crawler. A Listener establishes a TCP connection with the Master and sends every received packet to the Master. The Master logs all the packets, generates responses based on peer information and sends the generated response back to the Listener, which sends the packet (generated response) back to the request originator. The crawler also establishes a TCP connection with the Master and informs the Master about all newly discovered contacts (new Pms). The Master maintains this information and informs the Listener to monitor new contacts. The Master also keeps track of those peers which have departed the system. When a peer departs the system, the Master informs the Listener to stop monitoring that particular peer.
The complete topology of Montra (the present invention) is depicted in
Specifically, at 405 a test is performed to determine if the received message is from a monitored peer/node (Pt). It should be noted that a test could determine if the message is from the Master as easily. The message has to be from either the Master or a monitored node/peer (Pt) or there is an error so if it is determined that the message did not come from a monitoring node/peer (Pt) then no further test is performed to confirm that the message came from the Master although such a test could be provided/performed. At 410 the message received from the monitored peer/node (Pt) is forwarded to the Master. Processing continues at 405. At 415 a test is performed to determine if the message received from the Master is a HELLO REQUEST. Similar logic should be understood here. A message received from the Master must be either a HELLO REQUEST or a HELLO RESPONSE or there is an error. A test could be performed for either of these messages assuming if it was not the message tested for then it must be the other message or there was an error. A test to confirm that the message was the other message could be provided/performed. At 420 the Listener opens a new port for this new monitored node/peer (Pt). AT 425 the Listener forwards/relays the HELLO REQUEST message to the target peer from the newly opened port. Processing continues at 405. If the message was not a HELLO REQUEST then the message must have been a HELLO RESPONSE so at 430 the message is forwarded/relayed to the corresponding peer.
Specifically, at 505 a test is performed to determine if the received message is from the crawler. It should be noted that a test could determine if the message is from the Listener as easily. The message has to be from either the Listener or the crawler or there is an error so if it is determined that the message did not come from the crawler then no further test is performed to confirm that the message came from the Listener although such a test could be provided/performed. If the message is from the crawler then at 510, the Master cleans up/clears peers that have not been marked as “live” for more then m rounds. Peers/nodes that have not been marked as “live” for more than in rounds have departed the network. At 515 the Master constructs a HELLO REQUEST message from each peer in the peer list provided by the crawler. At 520 the Master sends/forwards/relays the HELLO REQUEST messages to the Listener. Processing continues at 505. At 525 a test is performed to determine if the received message is a HELLO RESPONSE message. If the received message is a HELLO RESPONSE message then the corresponding peer/node is marked as “live” for m rounds at 530. That is, the corresponding peer/node has not departed the network. At 535 the message is logged into the database for later analysis.
If the received message is not a HELLO RESPONSE message then at 540 a test is performed to determine if the received message is a HELLO message. If the message is not a HELLO message then processing continues at 535. If the received message is a HELLO message then at 545 a test is performed to determine if the received message is from a monitored peer/node. If the received message is not from a monitored peer/node then processing continues at 535. If the received message is from a monitored peer/node then a corresponding HELLO RESPONSE message is constructed at 550. The HELLO RESPONSE message is sent/forwarded/relayed to the Listener at 555. Processing continues at 535.
It is to be understood that the present invention may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. Preferably, the present invention is implemented as a combination of hardware and software. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage device. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (CPU), a random access memory (RAM), and input/output (I/O) interface(s). The computer platform also includes an operating system and microinstruction code. The various processes and functions described herein may either be part of the microinstruction code or part of the application program (or a combination thereof), which is executed via the operating system. In addition, various other peripheral devices may be connected to the computer platform such as an additional data storage device and a printing device.
It is to be further understood that, because some of the constituent system components and method steps depicted in the accompanying figures are preferably implemented in software, the actual connections between the system components (or the process steps) may differ depending upon the manner in which the present invention is programmed. Given the teachings herein, one of ordinary skill in the related art will be able to contemplate these and similar implementations or configurations of the present invention.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/US2008/012288 | 10/30/2008 | WO | 00 | 4/13/2011 |
