Patent Document

FIELD OF THE INVENTION 
     The present invention relates to providing a peer to peer path optimizer (PPO) to examine peer to peer networking messages and dynamically and transparently redirect them to a cost efficient path. 
     BACKGROUND OF THE INVENTION 
     Peer to peer (P2P) networking has emerged as a popular form of exchanging data such as movies or music among individuals using the Internet. In a P2P network each computer in the network has the same responsibilities as each of the others, i.e. it is a “peer”. Many variations of P2P networks have been created, at the time of writing the most prevalent being: Napster, Kazaa and Gnutella. The use of P2P for transferring large amounts of multimedia data such as movies or music has significantly increased the amount of information transmitted on the Internet. 
     P2P has led to increased financial pressure for network service providers. A network service provider is an entity that maintains a group of computers or nodes that form a network. Examples of networks include but are not limited to: a network controlled by an Internet Service Provider (ISP), a corporate network or a university network. 
     A network service provider typically must pay a fee for the traffic to and from their network. 
     Given the popularity of P2P networking, it is difficult for any network service provider to block P2P traffic. The network service provider is left with few choices, namely:
     a) tiered bandwidth services, and the hope that users will pay for additional bandwidth, or   b) capping the amount of bandwidth available to P2P applications, which could cause dissatisfaction among the user base.   

     Thus, there is a need for an alternative approach, which allows a network service provider to cost effectively constrain P2P traffic through their network, while maintaining or improving existing performance to the user. The present invention addresses this need. 
     SUMMARY OF THE INVENTION 
     The present invention is directed to a peer to peer optimizer, the optimizer examining peer to peer messages between nodes within networks connected to the optimizer, for the purpose of optimizing behavior on each of said networks. 
     The present invention is also directed to a peer to peer optimizer, the optimizer examining peer to peer messages between nodes within networks connected to the optimizer, for the purpose of determining a cost efficient path for each peer to peer message. 
     The present invention is also directed to a process for managing peer to peer messages between and within networks, the process comprising the step of determining a cost efficient path for each of the peer to peer messages. 
     The present invention is also directed to a computer readable medium containing instructions for managing peer to peer messages between nodes in networks, the medium comprising instructions for optimizing behavior on the networks. 
     The present invention is further directed to a system for optimizing peer to peer messages between nodes within networks, the system comprising a peer to peer optimizer, the system utilizing the optimizer to examine messages between the nodes for the purpose of optimizing behavior on each of the networks. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       For a better understanding of the present invention, and to show more clearly how it can be carried into effect, reference will now be made, by way of example only, to the accompanying drawings in which: 
         FIG. 1  is a block diagram of networks connected to the present invention; 
         FIG. 2  is a block diagram of a plurality of nodes connected to a PPO; 
         FIG. 3  is a block diagram of an ISP system; 
         FIG. 4  is a block diagram of a centralized server network; 
         FIG. 5  is a block diagram of a centralized server network utilizing a PPO; 
         FIG. 6  is a block diagram of a decentralized server network; 
         FIG. 7  is a block diagram of a decentralized P2P network utilizing a PPO; 
         FIG. 8  is a block diagram of a hybrid P2P network; 
         FIG. 9  is a block diagram of a hybrid P2P network utilizing a PPO; 
         FIG. 10  is a block diagram of a PPO; 
         FIG. 11  is a logical flow diagram illustrating the processing of a ping message; 
         FIG. 12  is a logical flow diagram illustrating the processing of a pong message; 
         FIG. 13  is a logical flow diagram illustrating the processing of a query message; 
         FIG. 14  is a logical flow diagram illustrating the processing of a queryhit message; and 
         FIG. 15  is a logical flow diagram illustrating the processing of a connect request; and 
         FIG. 16  is a chart illustrating how PPO  10  may be used to examine and redirect P 2 P traffic between networks. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       FIG. 1  is a block diagram of networks connected to the present invention. Peer to Peer optimizer (PPO)  10  monitors all P2P traffic between a plurality of networks  12 . Examples of networks  12  include but are not restricted to; a network controlled by an ISP, a corporate network, or a University network. Networks  12  would typically be connected to PPO  10  via the Internet, but that is not a requirement of the present invention. Any network  12  that is capable of providing or requesting P2P traffic may make use of PPO  10 . 
     To minimize the cost of P2P traffic, network  12  utilizes PPO  10  to determine a cost efficient path for exchanging P2P data between nodes  14 . A node  14  is any computer that is capable of receiving or transmitting P2P data. 
     Referring now to  FIG. 2 , a block diagram of a plurality of nodes connected to a PPO  10  is shown. Each network  12   a  and  12   b  contains a plurality of nodes  14 . For each node  14  that it is aware of, PPO  10  maintains a cost class. Table 1 illustrates the cost class for each node of  FIG. 2 . 
     
       
         
               
               
               
             
               
               
               
             
           
               
                   
                 TABLE 1 
               
               
                   
                   
               
               
                   
                 Node 
                 Cost Class 
               
               
                   
                   
               
             
             
               
                   
               
             
          
           
               
                   
                 14a 
                 5 
               
               
                   
                 14b 
                 5 
               
               
                   
                 14c 
                 10 
               
               
                   
                 14d 
                 250 
               
               
                   
                 14e 
                 150 
               
               
                   
                 14f 
                 50 
               
               
                   
                 14g 
                 250 
               
               
                   
                   
               
             
          
         
       
     
     Assuming that a P2P request can be serviced within a single network such as  12   a , then typically the most cost efficient paths for P2P transfer will be within network  12   a . Examples would be connections to nodes  14   a  and  14   b . However, this may not always be the case. For example a request to node  14   d  may be very expensive if node  14   d  which contains the data, resides halfway around the world within a corporate intranet. In such a scenario, node  14   f , within network  12   b , which contains the required data, would be a more cost efficient choice. 
     In determining a cost efficient path for the delivery or reception of P2P data, PPO  10  combines the cost class of each node on the end of a potential exchange of data. This combination results in a path cost value. For example, a request from node  14   e  for a file on node  14   a  may result in a path cost of  155 . This example is one of simple addition to the cost class of two nodes to determine a path cost. The inventor does not intend to restrict the present invention to any specific algorithm to obtain a path cost. For example, a weighting factor may be applied to nodes with a high cost class to exclude them from consideration in calculating a path cost. 
     In  FIG. 3 , a block diagram of an ISP system is shown.  FIG. 3  illustrates how an Internet Service Provider (ISP) may make use of the present invention. Network  12   a  is the network maintained by an ISP. Network  12   a  is connected to a plurality of networks  12   b  to  12   n  via links  30   b  to  30   n . Typically networks  12   b  to  12   n  would be accessible via the Internet, but they may be any form of network which contains files for P2P exchange. Network  12   a  comprises a plurality of nodes  14 . P2P data is exchanged between nodes  14  within network  12   a  and nodes within networks  12   b  to  12   n . A node  14  may be the computer of a home user, a business computer or a corporate server connected to any of networks  12   a  to  12   n . Returning to the present ISP example of  FIG. 3 , each node  14  within network  12   a  is connected to a communications module  20 , which allows node  14  to communicate with network  12   a . Communications module  20  may be Digital Subscriber Line Access Multiplexer (DSLAM) which is used for phone line connections. Communications module  20  may also be a Cable Modem Termination System (CMTS) which is used for cable connections. Communications module  20  may also be a module that accepts dialup connections, wireless connections or fiber optic connections. The point here being that communications module  20  connects a node  14  to network  12   a . An aggregator  22  collects the data to and from communications modules  20  and is connected to distribution router  24  for this purpose. Distribution router  24  determines where a request for information should be routed within network  12   a . Distribution router  24  is connected to core router  26 , one or more cache servers  28  and one or more P2P Path Optimizers (PPO)  10 . Core router  26  is connected to networks  12   b  to  12   n  most typically by InterXchange Carrier (IXC) links  30   b  to  30   n . An IXC is a telecommunications company such as AT&amp;T. A cache server  28  is a repository of information obtained from networks  12   b  to  12   n  that may be frequently accessed by nodes  14 . To avoid the expense of continually requesting data from networks  12   b  to  12   n  network  12   a  may store frequently accessed information in one or more caches  28 . Most commonly this would be current versions of popular websites, but may include all forms of data. Cache  28  may also commonly be referred to as a “cache cluster” or a “cache server”. 
     PPO  10  is where the present invention resides. PPO  10  serves to provide three main functions:
         1) Reorganize networks connected to PPO  10 . This is achieved by intercepting all P2P messages and attempting to have nodes connect to other nodes in the same cost class. This allows the networks to reorganize in two ways:
           a) they become flatter as nodes connect to nodes under the control of a PPO  10  thus a tree of connections between nodes would have at most a depth of one; and   b) PPO  10  attempts to connect nodes to other nodes within a network, where without the use of a PPO  10 , connections would be random and a tree of connections between nodes may have an unlimited depth.   
           2) Reduce network traffic. This is done by not broadcasting messages but instead sending them where they need to go, or dropping them if there is no need to send them on.   3) Redirecting traffic to a cost efficient path.
 
Each of these functions is discussed in more detail below.
       

     Although the example of  FIG. 3  applies to the network of an ISP, it is not the intent for the inventors to restrict the use of the present invention to an ISP network. Any network for which an entity wishes to control P2P traffic in a cost efficient manner may make use of the present invention. As discussed above examples would be a corporate network or a University network or any commercial use of a large network, such as the hotel industry. 
     Before describing in detail the structure of PPO  10 , we will refer first to how it may be utilized in a variety of P2P models. 
     Referring now to  FIG. 4 , a block diagram of a centralized server network is shown generally as  40 . Network  40  is an example of a first generation P2P network, such as Napster. Napster is an Internet service that was originally designed to permit users to exchange MP3 music files. In network  40 , a central server  42  connects a plurality of nodes  14  via connections  44 . Connections  44  would typically be connections via the Internet. A node  14  sends a request for a file to central server  42  via a connection  44 . Central server  42  provides a reply via connection  44  indicating on which node  14  the requested file resides. In essence central server  42  contains a directory of all files available for access on all nodes  14 . In acting on the reply, the requesting node  14  establishes a connection with its peer node  14  that contains the file and requests a copy of the file, as is shown in transfer link  46 . 
     To explain how  FIG. 4  may make use of the present invention we refer now to  FIG. 5  where a block diagram of a centralized server network utilizing a PPO is shown generally as  50 . In network  50 , PPO  10  examines search requests sent to central server  42 . If PPO  10  is aware of the requested file, it will provide the requester with a cost efficient path to the file. If PPO  10  is not aware of the file it will utilize alternatives to direct the requestor to the file. These alternatives are discussed in detail later. In determining which node  14  to direct the request to, PPO  10  makes use of cost class information. Cost class information for a node would typically be determined by metrics such as the speed of the connection to the node (e.g. bandwidth and distance) and the monetary cost of using a connection to the node. Cost class information would typically reflect a monetary cost to obtain a file from a specific node  14 . An administrator of the present invention may set their own cost class to a node  14  or PPO  10  may set them by default or determine them dynamically. Whatever the method of establishing the cost class for a node, the point is that each node has a cost associated with it and PPO  10  utilizes this information to provide a cost efficient path for exchanging P2P data. 
     Referring to  FIG. 6 , a block diagram of a decentralized server network is shown generally as  60 . Network  60  utilizes a distributed model where each node  14  is equal and there is no central server  42  as with network  40  ( FIG. 4 ). Network  60  may be considered to be a second generation P2P network, an example of which would be Gnutella. Gnutella provides a file sharing service for many types of information and is not directed solely to the exchange of multimedia files. Each node  14  tries to maintain some number of connections  44  to other nodes  14  at all times. Requests for information are sent with a Time to Live (TTL) field that is decremented and then forwarded by each node  14  to all other nodes  14  to which it is connected. When the TTL value reaches zero, the request is dropped. This type of network has been shown to have significant scaling issues, as requests for information will degrade network performance. As with network  40  when a requested file is located a direct connection is made between two nodes to transfer the requested data as shown by transfer link  46 . 
     In the present invention the topology of network  60  is reconfigured as shown in  FIG. 7 .  FIG. 7  is a block diagram of a decentralized P2P network utilizing PPO  10  and is shown generally as  70 . In network  70  when P2P communication is sent between networks  12   a  and  12   b  PPO  10  examines it. PPO  10  then determines a cost efficient manner to deal with the communication. It is not the intent of the inventor to restrict the use of the present invention to only two networks  12   a  and  12   b  as shown in  FIG. 7 . 
     Referring now to  FIG. 8  a block diagram of a hybrid P2P network is shown generally as  80 . This network topology may be referred to as third generation P2P where some nodes are elected as “supernodes” or “ultra peers” and serve as the traffic coordinator for the other nodes. In  FIG. 8 , supernodes are designated with the feature number  82  and are connected to each other. This model is utilized by P2P services such as Fasttrack, Kazaa, Morpheus and Grokster. The supernodes  82  change dynamically as bandwidth and network topology change. Any node  14  may be a supernode  82 . 
     Referring now to  FIG. 9 , a block diagram of a hybrid P2P network utilizing PPO  10  is shown generally as  90 . In network  90 , PPO  10  acts as a supernode between networks  12   a  and  12   b . All nodes within network  12   a  will see PPO  10  as their supernode and thus as their path to network  12   b . Nodes  14  within network  12   a  may also be supernodes within network  12   a  (not shown). 
     With regard to the topologies of the networks shown in  FIGS. 4 to 9 , it is the intent of the inventor to simply illustrate how the present invention may be utilized in existing P2P networks. It is not the intent of the inventor to restrict the present invention to the networks shown, but rather to provide examples of the diversity of the present invention. 
     Referring now to  FIG. 10  a block diagram of a PPO is shown generally as  10 . As one skilled in the art can appreciate, PPO  10  may be implemented in many different ways. The structure of PPO  10  as shown in  FIG. 10  serves only as an example of one implementation that may be used to examine and manage P2P communications. We will now describe the components of PPO  10  as illustrated in  FIG. 10  in more detail. 
     Licensing module  102  is responsible for enforcing the maximum number of concurrent users of PPO  10  for which the customer (i.e. the owner of a PPO  10 ) has paid a license fee. Configuration module  104  maintains the configuration of PPO  10 , such as the sub-networks and IP addresses of the nodes that reside within a network  12 . Statistics module  106  maintains the statistics for PPO  10 , such as the number of files redirected and the number of concurrent users. Logging module  108  is responsible for logging functions, such as when PPO  10  was started up or shut down and when the number of licenses was exceeded. Load balancer feedback module  110  provides a negative feedback loop to an external load balancer so that multiple PPO&#39;s under the control of a customer will receive equal traffic. WCCP module  112  operates with the Cisco Web Cache Communication Protocol (WCCP) to ensure that a router, such as distribution router  24  of  FIG. 3  sends only P2P communications to one or more PPO&#39;s  10 . As one skilled in the art can appreciate, a number of methods may be used to direct P2P traffic to a PPO  10 , such as recognizing specific port addresses or context sensitive scanning of packets. WCCP serves only as one example. GUID generator  114  generates a globally unique identifier for each sender of a P2P packet to avoid the possibility of looping back to the original sender of the packet and to also uniquely identify messages that have been received. 
     P2P application  116  acts as the control program for PPO  10 . Application  116  comprises: route/path cost module  118 , query module  120 , ping/pong network training module  122 , connection manager module  124  and transfer manager module  126 . Route/path cost module  118  assigns a path cost to each proposed connection based upon the cost class of each node in the connection. 
     Query module  120  comprises: string edit distance module  128 , search amalgamation module  130 , query routing logic module  132 , QoS modification module  134  and content index module  136 . String edit distance module  128  determines the similarity between the name of a requested file and the filenames known to PPO  10 . Search amalgamation module  130  utilizes string edit distance module  128  to map the name of a requested file to the known files available, regardless of cost class. Query routing logic module  132  routes queries for a file to the nodes that are likely to contain the requested file. Module  132  maintains a list of all messages to and from a network  12 . By maintaining such a list, module  132  may quickly drop spurious messages, such as requests for data that have not been acknowledged. QoS modification module  134  rewrites the routing information of module  132  to select a cost efficient path determined by route/path cost module  118 . Routing information includes QoS parameters such as stated bandwidth and uptime. The purpose of rewriting routing information is to provide the requestor with a path to a file or files that make the most efficient use of network resources. By doing so a message may be redirected. Content index  136  maintains an index of content available for access in nodes  14  within networks  12 . Content index  136  also contains the cost class for each node in which the content resides. Typically such content will be a file but may also include forms of data such as streaming media. It is not the intent of the inventor to restrict the use of the term “file” to any form of P2P data that may be examined by or transmitted through PPO  10 . 
     Ping/Pong network training module  122  serves to fill host cache  138  with IP addresses of nodes  14  based upon the Ping messages received by PPO  10  from nodes  14 . Ping/Pong network training module  122  sends a plurality of Pong messages in response to a Ping message in an attempt to train a network sending a Ping message. Pong messages are sent by PPO  10  for each node  14  that is in the same cost class as the sender of the Ping that PPO  10  is aware of. This use of multiple Pong messages serves to train the network that sent the Ping. This training provides the sending network with nodes other than those for which PPO  10  wishes to restrict traffic. 
     When a connection is established between a node  14  and PPO  10 , connection manager  124  maintains the connection until the node  14  drops the connection. Index fetch module  142  is responsible for obtaining content names and adding them to content index  136 . 
     Transfer manager  126  is in essence a proxy that handles the exchange of P2P data. Manager  126  utilizes fetch redirection module  144  to redirect a request for content to a node with a lower path cost. A node  14  may make a request for a specific file on another node  14 . If that file is available via a more cost efficient path, fetch redirection module  144  will silently direct the request to another node having a more cost efficient path. 
     A plurality of P2P protocol specific handlers  146  are responsible for maintaining a specific P2P protocol, for example Gnutella or Fasttrack. Transmission Control Protocol (TCP) handler  148  ensures the maintenance of correct TCP behavior. Similarly, Internet Protocol (IP) handler  150  serves the same purpose for IP. It is not the intent of the inventor to restrict the present invention to the use of TCP and IP. These serve only as an example. As one skilled in the art can appreciate any number of communication protocols may be used, including, but not restricted to: ATM, UDP, and wireless. 
     Differentiated Services Code Point (DSCP) marking module  152 , utilizes Differentiated Services (DiffServ or DS) to specify IP packets by class so that certain types of packets get precedence over others. For example a limit may be imposed on the number of P2P packets allowed to enter or leave a network  12 . Such a feature is optional but may be used by networks that find P2P data is consuming too much of their bandwidth. As one skilled in the art can appreciate any number of schemes such as packet snooping or recognizing specific port addresses may be utilized to identify P2P traffic. It is not the intent of the inventor to restrict the ability to limit P2P traffic to the DSCP solution. 
     PPO  10  optimizes behavior between and within the networks  12  to which it is connected. Behavior is the ability to create, destroy, modify or ignore messages. Behavior optimizes future behavior of each network  12 , not just the current message. An example of creating a message is a false pong. An example of destroying a message is deleting a message that has already been answered or in the case of Gnutella, a message whose TTL has expired. Modification is not limited to QoS modification module  134 . For example, search amalgamation module  130  may modify messages to reflect the closest filename as determined by string edit distance module  128 . In the case of a specific protocol, for example Gnutella, modification may include overwriting the TTL portion of the message when forwarding the message. Similarly the GUID for a message may be changed if needed. In essence, depending upon the protocol, PPO  10  may modify messages as required to optimize network behavior. An example of ignoring a message is to ignore a query request to a node in a network, as traffic from that network has been restricted. 
     In order for PPO  10  to examine and act upon P2P requests, it must be aware of a variety of P2P protocols. This functionality is handled by P2P protocol specific handlers  146 . 
     By way of example we refer next to how a P2P protocol specific handler  146  may interface with the Gnutella protocol. It is not the intent of the inventor to restrict the present invention to work simply with the Gnutella protocol, but rather to provide a practical example of how the present invention may deal with P2P requests. 
     The Gnutella protocol has five message types, namely: ping, pong, query, queryhit and push. How a handler  146  handles each of these messages is shown  FIG. 16 . In  FIG. 16 , the term “internal node” refers to a node  14  within network  12   a  of the ISP example of  FIG. 3 . The term “external node” refers to a node  14  within a network  12   b  to  12   n  of  FIG. 3 . By the use of the terms “internal node” and “external node” the inventor means to show how PPO  10  may be used to examine and redirect P2P traffic between nodes in an “internal” network such as an ISP and nodes in an “external” network such as a plurality of sites on the Internet. 
       FIG. 16  illustrates how PPO  10  may be used to examine and redirect P2P traffic between network. In the following description of  FIG. 16 , we advise the reader refer to  FIGS. 3 and 10  as well as  FIG. 16 . 
     A ping message is used to determine if a node  14  is active, and helps to establish a database of active nodes in host cache  138  of  FIG. 10 . PPO  10  responds to a ping message with a pong message. To avoid identifying a node  14  within network  12   a , PPO  10  would typically provide a forged pong message. The forged pong message would indicate the number of files shared and the amount of data shared within network  12   a  containing the pinged node  14 , as well as the IP address and port of the pinged node. Similarly in this example, PPO  10  does not forward pong messages, however it does receive them and adds them to the list of nodes in host cache  138  from which it may obtain data. 
     A query message is a search message containing a fragment of a filename, in other words, a request for data. In the present example, incoming query messages from an external node are dropped, thus appearing to be a query miss and thereby avoiding servicing a P2P request from a network  12   b  to  12   n . It is not the intent of the inventor to require that query messages be dropped, it is simply one method that may be used to restrict unwanted P2P traffic into network  12   a . Implementations utilizing PPO  10  may choose to allow free flow of all messages or to provide a limited amount of traffic. Query messages from a node  14  within network  12   a  are forwarded first to the nodes  14  containing the requested file that have a cost efficient path. Typically these would be nodes  14  within network  12   a , but that may not always be the case. The nodes  14  having the requested data will then respond with queryhit messages. If there are no matches for the request for data, or if no queryhit message is returned, then the query message is sent to a random set of nodes  14  within network  12   a . One method of determining the random set of nodes  14  to receive the query message would be to use a weighted probabilistic function such as a round robin method based upon the number of files available from each node  14 . In this way, the query does not always go to the node  14  having the largest number of files. If there is still no match, the query is forwarded to nodes  14  having the lowest path cost in networks  12   b  to  12   n.    
     A queryhit message is a response to a query message. Incoming queryhit messages from nodes in networks  12   b  to  12   n  are forwarded to the appropriate node  14  within network  12   a . Incoming queryhit messages from nodes  14  within network  12   a  are forwarded back to the requesting node within network  12   a  and not sent out to networks  12   b  to  12   n.    
     A push message is used when the transmitting node has a firewall and the receiving node does not. The receiving node sends a push message, which causes the transmitting node to open a connection directly to the receiving node. Incoming push requests may be optionally dropped by PPO  10  and are propagated unchanged on the way out of network  12   a.    
     By way of example on how the present invention may be utilized to provide support for the Gnutella protocol, we will now refer to logical flow diagrams  11  to  15 . As with the previous discussion with regard to Chart 1, we will be referring to the components of  FIG. 3  by way of example. 
     Referring now to  FIG. 11 , a logical flow diagram illustrating the processing of a ping message is shown generally as  160 . Beginning at step  162 , a ping message is received. At step  164  the ping message is optionally dropped and if dropped, is not propagated within network  12   a . At step  166  a forged Pong message is created. The forged pong response may contain the number of files available for P2P exchange within network  12   a . The forged pong message may be sent to each node to connected to PPO  10  in order to train a network as described earlier with reference to ping/pong training module  122  of  FIG. 10 . 
     Referring now to  FIG. 12 , a logical flow diagram illustrating the processing of a pong message is shown generally as  190 . Process  190  begins at step  192  with the receipt of a pong message. At step  194  a test is made to determine if the message is from a node  14  within network  12   a . If the message is from a node  14  within network  12   a  the message may be optionally dropped at step  196 . If the message is from a node  14  in a network  12   b  to  12   n , processing moves to step  198  where the TTL for the message is decremented. Processing then moves to step  200  where a test is made to determine the current value of the TTL. If the TTL has expired, the message is dropped at step  202 . If the TTL has not expired, processing moves to step  204  where a test is made to determine if a ping message to match the pong message has been received. PPO  10  stores messages it receives under the control of query routing logic module  132  ( FIG. 10 ). Typically a message is not stored for long as most P2P requests for information are resolved within less than a minute. If no matching ping message is found, the pong message is dropped at step  202 . If a matching ping message has been seen, then the pong message is forwarded to the source of the original ping message at step  206 . 
     In the above description of  FIG. 12 , the inventor makes reference to Time To Life (TTL). TTL information is utilized by the Gnutella protocol, but not by all other protocols. For other protocols not recognizing TTL, the logic if  FIG. 11  would be modified to remove steps  198 , and  200 . Thus control would flow from step  194  in the negative case directly to step  204 . 
     Referring now to  FIG. 13 , a logical flow diagram illustrating the processing of a query message is shown generally as  210 . Process  210  begins at step  212  where a query message is received. At step  214  a test is made to determine if the query message came from a node  14  within network  12   a . If this is the case processing moves to step  216  where a test is made to determine if the requested file is contained within network  12   a  as indicated by content index  136  ( FIG. 10 ). If the file is contained within network  12   a  then processing moves to step  218  where the query message is forwarded to nodes  14  having the lowest cost class within network  12   a . If the file is not found within network  12   a  then processing moves to step  220  where the query message is forwarded to a select weighted list of nodes  14  within network  12   a . The intent here being that content index  136  may not be current and the requested file may reside within network  12   a . One method of determining the set of nodes  14  to send the query message to would be to use a weighted probabilistic function such as a round robin method based upon the number of files available from each node  14  within network  12   a . In this way, the query does not always go to a node  14  having the largest number of files. 
     A test is next made at step  222  to determine if the file has been located on a node  14  within network  12   a . If the file has been located the location information is forwarded to the originator of the query message at step  224 . If at step  222  the file has not been located, the query message is forwarded to a weighted subset of connected nodes having the lowest cost class in networks  12   b  to  12   n  at step  226 . As mentioned before, a weighted round robin scheme may be utilized to select the nodes  14  in networks  12   b  to  12   n  to receive the query. A connected node is one that has established a communication path with PPO  10 , for example via TCP/IP. Returning to step  214  if the query message is not from a node  14  within network  12   a , processing moves to step  228  where the TTL value of the message is decremented. A test is then made at step  230  to determine if the TTL value for the message is greater than zero. If it is not, then the message is dropped at step  232  and processing ends. If the TTL value is less than or equal to zero then processing moves to step  226  where the query message is forwarded to all connected nodes in networks  12   b  to  12   n . Optionally, if the query is from a node in networks  12   b  to  12   n , the query may simply be dropped or returned to the requesting node at step  226 , thus not requiring PPO  10  to forward the query to connected nodes. 
     As discussed above with reference to  FIG. 12 , if the communication protocol does not make use of TTL, then steps  228 ,  230  and  232  would be deleted. The negative case from step  214  would then flow to step  226 . 
     Referring now to  FIG. 14 , a logical flow diagram illustrating the processing of a queryhit message is shown generally as  240 . Process  240  begins at step  242  where a queryhit message is received by PPO  10 . Processing moves to step  244  where the TTL for the queryhit message is decremented. At step  246  if the TTL is less than or equal to zero than the message is dropped at step  248 . If the TTL is greater than zero, processing moves to step  250  where a test is performed to determine if a matching query message had been received for the queryhit message. PPO  10  stores messages it receives under the control of query routing logic module  132  ( FIG. 10 ). Typically a message is not stored for long as most P2P requests for information are resolved within less than a minute. If no matching query message was received, processing moves to step  248  where the message is dropped. If a matching query message was received, processing moves to step  252  where a test is made to determine if the queryhit message was from a node  14  within network  12   a . If not, the queryhit message is then optionally forwarded to the node that made the original query at step  254 . If at step  252  the queryhit message is determined to have come from a node  14  within network  12   a , then processing moves to step  256 . At step  256  a test is made to determine if the original query message corresponding to the queryhit message was from a node  14  within network  12   a . If so, processing moves to step  254  where the message is forwarded to the node that made the original query. If not, processing moves to step  248  where the message is dropped. 
     Referring now to  FIG. 15  a logical flow diagram illustrating the processing of a connect request is shown generally as  260 . Any node  14  may request a connection with any other node  14  at step  262 . At step  264  a test is made to determine if the request is from a node  14  within network  12   a . If so, connection manager  124  (see  FIG. 10 ) attempts to service the query through query module  120  (see  FIG. 10 ) to determine a cost efficient path within network  12   a , at step  266 . If at step  264  it is determined that the connect request is not from a node  14  within network  12   a , processing moves to step  268 . At step  268  a ping message is sent to connected nodes  14  within networks  12   b  to  12   n . At step  270  one or more pongs are received and a decision is made at step  272  which connection to a specific external node  14  should be utilized. Step  272  may utilize a variety of methods to determine which connections to keep and which to drop. Typically, step  272  would maintain connections based upon the amount of data, cost class, and the total number of connections that may be maintained. If at step  272  a node  14  is found to be no better than an existing connection, it is dropped at step  274 . If at step  272  a better connection is found, it is added to content index  136  at step  276 . 
     Although this disclosure and the claims appended hereto make use of the terms query, queryhit, ping, pong, push and connect, it is not the intent of the inventor for these terms to be specifically associated with the Gnutella protocol. To the inventor the term query is analogous to a request for data and queryhit to a reply to a query, indicating that the data has been located. A ping is a standard computer communications term and is short for Packet Internet Groper; in essence it is a message to determine whether a specific computer in a network is accessible. A pong is a response to a ping. A push is a message sent directly to a node that is protected by a firewall. A push is used to request a direct connection between the node behind the firewall and the node sending the push message so that the node behind the firewall can “push” data to the requesting node. A connect is a connection between two nodes. 
     Although the disclosure refers to a PPO within an ISP by way of example, it is not the intent of the inventor to restrict the invention to such a configuration. For example a PPO may be used within any network, including networks utilized by corporations to exchange data with their employees or customers. Further, multiple PPO&#39;s may be utilized to provide redundancy in case one PPO fails and also to provide load balancing. In the case of a network  12  utilizing a single PPO, if the PPO failed, network  12  would revert to the status quo without the PPO; i.e. all P2P messages are exchanged with no decision made on who should service the request. 
     Although the invention has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art without departing from the spirit and scope of the invention as outlined in the claims appended hereto.

Technology Category: h