KR20120104341A - Method and apparatus for locating services within peer-to-peer networks - Google Patents

Abstract

Like code networks or other peer-to-peer network (P2P) networks, the ability to support service locating capabilities in P2P networks is provided. In one embodiment, a method is provided for locating a service within a P2P network. The P2P network includes a plurality of nodes, including a target node that executes a method for locating the service within the P2P network. The target node includes a lookup table that includes a plurality of entries that identify each of the plurality of nodes of the P2P network. The method includes searching for a request to search for the service within the P2P network and initiating a service search request towards at least one of the nodes in the search table. The service search request is a request for identifying at least one node of the P2P network supporting the service. The service search request includes information indicating the service and a search range for use by a node receiving the service search request.

Description

METHOD AND APPARATUS FOR LOCATING SERVICES WITHIN PEER-TO-PEER NETWORKS

Cross-Reference to Related Applications

The present application is directed to a method and apparatus for disassembling a peer-to-peer network and using a disassembled peer-to-peer network, the entirety of which is incorporated herein by reference. AND USING A DECOMPOSED PEER-TO-PEER NETWORK, US Patent Application No. 12 / 640,049 filed December 17, 2009, entitled Representative Document No. ALU / 805520].

FIELD OF THE INVENTION The present invention relates to peer-to-peer (P2P) networks and, more particularly, to locating services within P2P networks.

File sharing has been the focus of intensive research and grass roots usage for some time. File sharing has been made possible in particular by file sharing schemes designed for this purpose and implemented as different file sharing systems with associated file sharing protocols. Many different file sharing systems start with Napster and then many different file sharing systems, such as gnutella, kazaa, donkey, ewinny, and bittorrent. It has been implemented through the creation of them. In addition to these file sharing systems, new systems such as Share and Perfect Dark have also been developed. Collectively, these file systems and associated protocols are called peer-to-peer (P2P) file sharing systems / protocols or simply P2P file sharing applications. Moreover, besides P2P file sharing applications, a new class of P2P applications, namely P2P televisions (P2PTVs), which are architecturally different from the P2P file sharing applications, are emerging.

The popularity of P2P file sharing is evident in recent traffic studies. For example, a recent traffic study by Ellacoya Networks, with millions of broadband users in the United States, indicates that the impairments of major traffic types in volume are: Web (HTTP)-46%; Peer-to-peer (P2P)-37%; Non-HTTP streaming video-3%; Games-2%; Voice-over-IP (VoIP)-1%; Other-1%. The main cause for large amounts of HTTP traffic is embedded video streaming traffic, such as traffic from YouTube, which accounts for 9.8% of the total traffic in the above mentioned studies). However, P2P file sharing is still responsible for a large percentage of the traffic, and with the appearance of P2PTV, the amount of traffic is expected to increase rapidly.

The majority of existing P2P applications involve file sharing, but many of the existing P2P applications that involve file sharing were not, at least initially, fully peer-to-peer. Rather, most existing P2P applications initially used a central server to coordinate activity among members of the P2P network. For example, in BitTorrent, while the downloading of different branches of information is peer-to-peer, a centralized server called as a tracker in BitTorrent is used to coordinate the activity of the BitTorrent application. . Similarly, many other P2P applications that involve file sharing, for example, also have similar characteristics, such as Napster and Donkey. However, the use of a central server also makes existing P2P applications vulnerable to congestion and failures and also makes existing P2P applications an attractive target for security threats.

Disadvantageously, however, existing P2P applications support file sharing, while existing P2P applications do not support the ability to search for services.

In one embodiment, a method is provided for locating a service within a P2P network. The P2P network includes a plurality of nodes, including a target node that executes a method for locating the service within the P2P network. The target node includes a lookup table that includes a plurality of entries that identify each of the plurality of nodes of the P2P network. The method includes detecting a request to search for the service within the P2P network and initiating a service search request towards at least one of the nodes in the search table. The service search request is a request for identifying at least one node of the P2P network supporting the service. The service search request includes information indicative of the service and a service range for use by the node receiving the service search request.

The teachings herein can be readily understood by considering the following detailed description in conjunction with the accompanying drawings.

Various drawbacks of the prior art are addressed by embodiments that support service locating capability in a P2P network, such as a code network or other suitable peer-to-peer (P2P) network.

1 illustrates an exemplary code network.
FIG. 2 illustrates service discovery request messages initiated within the exemplary code network of FIG. 1 in response to service location discovery initiated by one of the nodes of the exemplary code network of FIG.
3 illustrates an embodiment of a method for generating a service search request message at a node initiating a service location search request.
4 illustrates an embodiment of a method for processing a service search request message at an intermediate node.
5 illustrates one embodiment of a method for processing service search response messages at an intermediate node.
FIG. 6 illustrates an exemplary code network illustrating an example of performing a gradual service location search for a service in an exemplary code network. FIG.
FIG. 7 illustrates an exemplary search range for performing a gradual service location search for a service in the exemplary code network of FIG.
8 illustrates one embodiment of a method for generating service search request messages at a node initiating a service location search request using aligned incremental service location search.
9A-9D illustrate a service location search initiated by one of the nodes of the representative code network of FIG. 1, illustrating an example of performing an ordered incremental service location search for a service in the representative code network of FIG. 1. Diagrams responsive to service discovery request messages initiated within the representative code network of FIG.
10 is a high-level block diagram of a general purpose computer suitable for use in carrying out the functions described herein.

To facilitate understanding, the same reference numerals are used to designate the same elements that are common to the figures, where possible.

Service locating capability is provided for use in locating a service within a peer-to-peer (P2P) network.

The service locating capability according to an embodiment may enable a target node in a P2P network to search for a location of a particular service in the P2P network, for example, to search for one or more other nodes of the P2P network supporting the service. do. The service location finding capability reuses existing search tables of nodes of the P2P network to perform service location search. The service location search initiated by a target node is performed for all nodes of the search table in a row until service search requests are made simultaneously for all nodes in the search table, until the location of the service is found or the search table is exhausted. Simultaneously for a subset of nodes in the table, and subsequently for any remaining nodes in the search table, and / or using any other suitable techniques until the location of the service or the search table is exhausted To be initiated. In the service location search, each service search request sent to a node includes information indicative of the requested service, a search range for use by the node receiving the service request, and optionally service specific information. The service search request may include other types of information. The service location search initiated by a node will generate at most M search messages so that each node receives at most M response messages (where M is the size of the bits of the key space of the P2P network), therefore The search across the entire P2P network will be distributed such that no single load of the P2P network is overloaded by search request and / or response messages. The service location search capability may be used to determine an object in the second P2P network by using the service location search capability to identify nodes in the first P2P network that are also nodes in the first P2P network. Make it searchable. The foregoing descriptions are merely general descriptions of specific embodiments of the service locating capability provided to introduce the service locating capability, and thus embodiments of the service locating capability are limited by the foregoing description. It will be understood that it is not intended.

The service locating capability is primarily depicted and described within the context of certain types of P2P networks, namely code networks. In a code network, a lookup table maintained at a node of the code network is called a finger table, and each entry in the finger table is called a finger, respectively. The principles of the service locating capability can be applied to other types of P2P networks, so that references to finger tables and associated fingers are more generally read as references to search tables and associated entries identifying nodes. It will be understood that it can.

1 depicts a high-level block diagram of an exemplary code network. As depicted in FIG. 1, the code network 100 includes a plurality of nodes 110 logically arranged in a ring configuration. Each of the nodes 110 stores files that can be shared among the nodes 110. The nodes 110 may also be host services that may be made available to other nodes 110. The nodes 110 include any nodes capable of, for example, a code network. For example, the nodes 110 may include computers, telephones, and the like. The nodes 110 are each configured to provide various functions of the service location capability.

The operation of the code network 100 when providing the service location capability can be better understood by first considering the general operation of the code networks in conjunction with the representative code network of FIG.

In Chord, the nodes of the code network have network connectivity through a packet-based network (eg, an IP network or any other suitable network), and the code places an overlay network over the underlying packet-based network. Form. Nodes of the code network are logically arranged in a circle in the order of the node IDs of the nodes. The node IDs of the nodes are assigned using a hash function.

In the code, the code network, for example, the number of nodes that can be based on the size of the key space (address space) of the code network. In general, the key space is M bits, where M can be any suitable number. For example, a typical key space used for code networks is provided using a 160 bit implementation that makes the size of the key space equal to 2 ¹⁶⁰ or ˜1.45 * 10 ⁴⁸ . A consistent hash function is used to map inputs to 160-bit values (ie, map inputs to the key space). Outputs from the hash function are mapped uniformly into the key space. It will be appreciated that any suitable hash function may be used, such as Secure Hash Algorithm (SHA-1), Message-Digest Algorithm 5 (MD5), and the like. When mapped to the key space, the outputs of the hash function provide a set of node IDs used to logically arrange the nodes in the code network.

In the code, active nodes (existing nodes participating in the code network) and inactive nodes (potential nodes that can participate in the code network) are logically arranged in a circle in the order of the node IDs of the nodes. The code has a wraparound in a circle and orders in the direction of increasing node ID values. In the code network, connectivity between active nodes of the code network is logical connectivity between adjacent ones of the active nodes in the circles (since inactive nodes are not connected to the code network, therefore the code only as active nodes) Potential nodes that can participate in the network). In this way, from the perspective of the target active node in the code network, the next active node on the circle in a clockwise direction is a successor of the target active node and the next active node on the circle in a counterclockwise direction is the Predecessor of the target active node.

In FIG. 1, the active nodes and the inactive nodes are displayed for clarity. In Figure 1, the key space of the code network is 6 bits (or 64 nodes numbered consecutively, in a clockwise manner from node ID 0 to node ID 63). In Fig. 1, nodes 0, 2-3, 5-7, 9, 12-13, 16-24, 26, 29-30, 32, 34-35, 37, 41, 43, 45, 49, 51 , 53-54, 56-58, and 62) are active and the remaining nodes are inactive. In FIG. 1, the logical connectivity between the active nodes of the code network 100 has a node 62 connected to node 0 to complete the circle, where node 0 is connected to node 2 and Node 2 is connected to node 3, node 3 is connected to node 6, and so on. Node 2 is called as a successor of node 0, and node 62 is a predecessor of node 0, because the code has wraparound and uses clockwise incrementing values to order the circle. Node 3 is called as successor of node 2 and node 0 is called as predecessor of node 2.

As described herein, the code network supports file sharing, where each file to be shared is stored on one or more of the active nodes of the code network. In code, the file name of the file is hashed to the same key space used to identify the nodes of the code network, using the same hash function used to identify the nodes of the code network. The hashed output from hashing the file name is a file identifier for the file. Thus, for example, for a code network with a key space of 160 bits, the code network could potentially accommodate 1.45 * 10 ⁴⁸ files. In code, the file is stored in a node with a node ID that matches the file ID of the file if the node is active, and if the node is inactive, the file is stored in a first active node with a node ID greater than the file ID. .

In Fig. 1, the code network 100 can accommodate a total of 64 files to be stored as follows: node 0 stores files 0 and 63; Node 2 stores files 1 and 2; Node 3 stores file 3; Node 5 stores files 4 and 5; Node 6 stores file 6; Node 7 stores file 7; Node 9 stores files 8 and 9; Node 12 stores files 10, 11, 12; Node 13 stores file 13, node 16 stores files 14, 15, and 16; Node 17 stores file 17; Node 18 stores file 18; Node 19 stores file 19; Node 20 stores file 20; Node 21 stores file 21; Node 22 stores file 22; Node 23 stores file 23; Node 24 stores file 24; Node 26 stores files 25 and 26; Node 29 stores files 27 28 and 29; Node 30 stores file 30; Node 32 stores files 31 and 32; Node 34 stores files 33 and 34; Node 35 stores file 35; Node 37 stores files 36 and 37; Node 41 stores files 38. 39, 40, 41; Node 43 stores files 42 and 43; Node 45 stores files 44 and 45; Node 49 stores files 46, 47, 48, 49; Node 51 stores files 50 and 51; Node 53 stores files 52 and 53; Node 54 stores file 54; Node 56 stores files 55 and 56; Node 57 stores file 57; Node 58 stores file 58; Node 62 stores files 59, 60, 61, 62.

In the most basic implementation, only one copy of a given file is stored in the code network, but different methods may be used to store multiple copies of one file within the code network (eg, node For resilience in cases of failures, load-disruption, etc.).

In one embodiment, for example, multiple versions of a file may be stored in the code network by assigned slightly different file names for multiple copies of the file using an agreed naming convention. For example, if the name of the file is "abc", an extension such as "-n" may be added to the file name indicating the same file. In this example, multiple copies of the file may be stored under the names ("abc", "abc-1", "abc-2", etc.). In this way, because multiple file names for the "abc" file are not the same, hashing of different file names will result in different hash outputs and hence different file IDs, whereby multiple copies of the file Will be stored in different nodes of the code network.

In one embodiment, for example, multiple independent versions of multiple files of the file are generated to generate multiple file IDs for the file using the file name (rather than the implementation described above where a single consistent hash function is used). By using hash functions can be stored in the code network. In this embodiment, a node seeding a file with the code network determines each of the possible file IDs of the file using the hash functions and uses the file IDs to retrieve the multiple copies of the file. Insert into code network. In this embodiment, a node searching for a file in the code network will determine all of the possible file IDs of the file (by hashing the file name using each of the hash functions) and subsequently successively determine the determined file IDs. The file may be searched by using or simultaneously.

With regard to the storage of multiple versions of a file in the code network, it will be understood that multiple versions of a file may be stored in the code network in any other suitable manner.

As described herein, the code allows nodes to share a file. In order to allow nodes of the code network to share files, each node of the code network is required to be able to navigate and ultimately determine the location of the desired file to obtain the desired file.

In the code, each node maintains a lookup table. For a code network with M-bit key space, each node N will maintain a lookup table with M entries, where the entries in the lookup table are called "fingers". In the search table for node N, the i th finger represents the circular first node that is at least 2 ^i-1 away from N. In general, unless otherwise indicated, the term "i th finger" will be used to denote a node represented by the i th entry of the search table. For example, in the code network 100, the third finger of node 0 is node 5.

Collectively, the search tables of the nodes provide an efficient global search algorithm in which the location (s) of the objects in the code network can be determined.

In Figure 1, the key space is 6 bits, so each node has six fingers in its search table. In FIG. 1, the lookup table for node 0 may be expressed as shown in Table 1 as follows.

In code, the network is dynamic. Since new nodes connect to the code network and existing nodes leave the code network, lookup tables at active nodes of the code network can be enforced. As such, in the code, each active node K will periodically update its associated search table. The active node K may update its search table in any suitable way. For example, the active node K may update its search table by searching for node K + 2 ^i-1 , which results from performing this search on the i th finger of the search table. It will be a value. It will be appreciated that active nodes of the code network may update their search tables in any suitable manner.

In code, in addition to the lookup table, each node also stores the identities of its successors and its predecessors in the ring. This information is used for ring maintenance, such as when new nodes connect to the network and existing nodes leave the network, as well as when nodes recover from failure. In some code networks, a node may store the identity of its N successors and its N predecessors in the ring, in order to be alert to the situation where there are multiple concurrent node failures.

In code, nodes of the code network may search for and obtain files from other nodes of the code network. The code network supports a search algorithm that allows nodes to search for files available from other nodes in the code network. The operation of the code search algorithm may be illustrated by way of example using the code network 100 of FIG. 1. In this example, assume that node 2 wants to search for file 0 in code network 100 of FIG. Node 2 will access its lookup table to select one of the other nodes to send the file request. From the point of view of node 2, the file ID of the target file (i.e. file 0) is greater than the value of the largest finger of node 2 (i.e. node 34) due to wraparound and the node ( 2) will send a file request to node 34 requesting node 34 to search for file 0. Node 34 receives the file request from node 2. Since it does not store file 0, node 34 will access its lookup table to select one of the other nodes to forward the file request. At node 34, the lookup table includes six fingers, representing nodes 35, 37, 40, 43, 51, and 2. Since the object ID of file 0 is between the fifth and sixth fingers (node 51 and node 2, respectively), node 34 sends the search request to the fifth finger (node 51). Forward to the node identified by). Node 51 receives the file request from node 34. Node 51 will access the lookup table to select one of the other nodes to send the file request since it does not store file 0. At node 51, the lookup table includes six fingers representing nodes 53, 53, 56, 62, 3, and 19. Since the object ID of file 0 is between the fourth and fifth fingers (node 62 and node 3, respectively), node 51 sends the search request to the fourth finger (node 62). Forward to the node identified by)). Node 62 receives the file request from node 51. Since node 62 does not store file 0, it will access its lookup table to select one of the other nodes to send the file request. At node 62, the lookup table includes six fingers, representing nodes 0, 0, 2, 6, 16, and 30. Since the object ID of file 0 is represented at both the first and second fingers (node 0), node 62 indicates that node 0 is active and forwards the search request to node 0. I know that. In response to receiving the search request, node 0 is directly or intermediate nodes having a file 0 (ie, node 62, node 51, node 34, and then node (). Reply to node 2). The node 2 can then obtain the file 0 directly from the node 0. Thus, from this example, it is clear that in the code, all of the nodes in the code network cooperate to support the code search algorithm.

In code, the code network is dynamic because nodes can connect to the code network at any time and leave the code network. As nodes connect and leave the code network, files are transferred between nodes. For example, a connecting node assumes responsibility for storing a file (and potentially also other files) having at least the same file ID as the connecting node's node ID, while the leaving node is responsible for storing one or more files. Responsibility can be passed on to another node. The procedures associated with joining and leaving the code network are described in further detail below.

In a code join procedure, when a node wants to join a code network, the joining node determines its node ID. The connecting node determines its node ID by hashing its name with a key value. For example, if the name of the node is node-xyx@company-abc.com, the node ID would be the output of SHA-1 (node-xyx@company-abc.com), where for simplicity we will Assume the hash function is SHA-1 (although any suitable hashing function can be used). In this example, let K be the node ID for this node, as determined from the hashing operation.

In the code connection procedure, the connection node K then contacts an active node (denoted as an initialization node) of the code network. Initially, such an initialization node may appear to be a centralized server, but this is not the case: (a) The initialization node may be any node currently active in the code network (eg, node ( If K1) and node K2 want to connect to the code network at the same time, they may use and are likely to use different active nodes as their respective initiating nodes for connecting to the network) and (b) The initiating node need not provide any special capability other than the basic capabilities (ie it can only act like any other node in the code network). The node K may obtain a list of potential candidate initialization nodes in any suitable manner (eg, from one or more lookup tables, successor lists and / or processor lists for the connecting node K). , From administratively configured information within the connecting node K, from a web site, etc.). In this example, let L be the node ID of the initialization node.

In the code concatenation procedure, the connection node K then sends a request for the initialization node L to search for the connection node K (ie, search for an object with ID = K). At this point, two events can occur:

(A) Node L responds to connection node K with a value of N. Node N will be a node with a node ID greater than K associated with connecting node K, among all active nodes. Thus, if connection node K is for connecting the code network, node N should be a successor node to connection node K. Node K then contacts node N and requests node N for the identity of the predecessor node of node N. In this example, the predecessor of node N is denoted as node N-. The node N provides the connection node K with a value of N−. Based on this information, it is known that node K must then insert itself into the code network between node N and node N-.

(B) Node L has a value of K and responds to connection node K. This means that there is another node in the code network with a node ID of K already active. This case is very unlikely in most code networks (eg, in code network 100, which is a 160 bit key space, the probability of this occurrence is 1.45 * 10 ⁴⁸ to 1) is possible. This situation has the connection node K slightly changed its own name (e.g. adding a timestamp, adding a number, etc.) to generate a different node ID (denoted as K '). Can be resolved by using a name. The connection node K 'may restart the process by sending a new discovery request to the initialization node L (i.e., the request that the initialization node L searches for the connection node K').

In the code connection procedure, following the determination of the insert for the connection node K, a process is executed to insert a node, for example in the code network. The connecting node K is inserted between node K− (the candidate predecessor of K) and node K + (the candidate predecessor of K), where at this time, before node K connects to the network, Node K + is the successor of node K-. The connecting node K contacts the successor node K + indicating that it wishes to connect to the code network. The successor node K + then (1) informs the connecting node K that its predecessor is node K-, and (2) any files that node K should be responsible for (i.e., (K-) + files with file IDs from 1 to K), and (3) its predecessor that connection node (K) is in the process of connecting to the code network. Notifies node K-. After the file transfer is completed, the connecting node K establishes a connection with the predecessor node K-. After the connection between the connection node K and the predecessor node K− is established, the connection node K informs the successor node K + that it has successfully connected to the code network. The successor node K + then disconnects from the predecessor node K-, and both the successor node K + and the predecessor node K- update their predecessor and successor lists.

In the Chord leave procedure, processing is performed to enable the rib node K to leave the chord network in a controlled manner. The leaving node K has a predecessor node (denoted as node K-) and a subsequent node associated with it (denoted node K +). The rib node K contacts both the predecessor node K− and the successor node K + and informs both that it is about to leave the code network and informs the identity of another of both nodes. To provide. The rib node K then has all of the IDs between (K −) + 1 and K, including K, that is currently being stored on behalf of the code network by the rib node K. All files) to the successor node (K +). After the transfer of the files is completed, the connecting node leaves the code network by disconnecting from the predecessor node K- and the successor node K +. Nodes K- and K + then establish, for example, between them (which can be initiated by one of them). Nodes K- and K + also update their predecessor and successor lists.

In addition to using the dynamic code concatenation procedure and the code rib procedure to enable dynamic changes to the code network, the code also supports a code recovery procedure to enable recovery from node failures (ie, the Code rib and code attach procedures are not used to recover from node failures). Nodes of the code network periodically send heartbeat messages to each of their predecessor and successor nodes, thereby enabling nodes of the code network to quickly detect node failures. In general, the heartbeat message from a node will contain the identities of the predecessor and successor nodes of the node from which the heartbeat message originates. In this way, when a node receives a heartbeat message from its successor node, it knows the identity of the successor node of its successor node, so when the node's successor fails, the node does not The connection to the successor node of the successor node of may be initiated and the code ring is maintained. As discussed above, in some code networks, nodes maintain lists of k predecessors and k successors. In this case, the code network can recover from the failures of k-1 consecutive nodes. In this case, even for the value of k, the probability of failure of k consecutive nodes is very small. In some such code networks, the value for k may be determined as 2 * log ₂ (L), where L is the average number of active nodes in the network (i.e., code that normally goes 100,000 active nodes, k) Will be ~ 34).

The code recovery procedure described above allows the code network to be repaired in case of node failures, but files stored on the failed nodes are lost. This problem can be solved in at least two of the above described in various ways. Additionally, in another embodiment, this problem is solved by having the nodes that have obtained the files voluntarily become seed nodes for the files. One description of one such embodiment follows. The file is originally introduced into the code network by a member of the code network (where the member node is called as the seed node of the file). The seed node obtains a hashed value of the file name (ie, the file ID) and searches for a node having a node ID equal to the file ID. The seed node will locate the first active node in the code network with a node ID equal to or greater than the file ID. The seed node sends the file to the node that finds the location. Thereafter, other nodes of the code network that later acquire the file may voluntarily become seed nodes for the file. The seed node for the file will periodically search for the file in the code network, and if the seed node fails to find the file, it will send the file to the appropriate node as described above. In this way, "lost" files are recovered in the code network.

As described herein, in addition to storing and sharing files, the code network may also support services. If existing code networks only supported file sharing services, code networks may increasingly support one or more other services in addition to file sharing services. The service may be available from all nodes or a subset of nodes, and may only be available from a small subset of nodes. Service may be mandatory for all or some of the nodes, or may be supported by the nodes at will. The node (s) supporting the service may transition between active and inactive. Each of these features associated with supporting services in code networks may vary based on one or more of the type of supporting service, the implementation of the code network, similar factors. In view of the possibility of supporting services in code networks, the service locating capability allows each of the nodes in the code network to search for and match a node providing a particular service.

The service locating capability is advantageous for at least the following reasons when used to find the location of a node supporting a particular service: (1) it uses existing lookup tables maintained on the nodes of the code network ( That is, no new lookup table is required for the nodes); (2) the search is distributed (eg, when searching for a service, the initiating node initiating the service search will initiate at most M messages (where M is the length of the key space of the code network) ) Thus at most the M response messages will be received such that the initiating node is not congested by an overwhelming number of responses; and (3) the service search can be executed in stages, step by step, where each step Can be configured to have a large probability of success such that the number of messages exchanged in the code network is minimized The service locating capability also has the benefit of enabling efficient broadcasting (useful in many applications).

The services that can be located in the code network include any services suitable to be supported by the code network.

The first service that may be supported by nodes of a code network is a "cross-ring searching" service, which allows a node to search for files across multiple linked code networks. In general, a code network represents an interesting community in which files of interest to a community are stored and shared. A node can belong to multiple code networks. This is evident from the understanding that individual users associated with possible code networks, for example, may have different interests, and therefore at least some nodes are likely to belong to multiple sets of code networks. When a node searches for a file in the code network, the search node may: (a) the file is never stored in the network (eg, the file is newly created and none of the nodes in the code network are yet; Did not obtain the file); (b) the file may not be of interest to the community and is therefore not stored in the code network; (c) due to the fact that each node in the code network has a practical limit on the number of files it can store on behalf of the code network (eg, in rare cases, between a node and its predecessor). The gap is too large and thus the node cannot store all of the files; for example, the policy of the code network is typically that older and / or less popular files cannot be stored, and thus within the code network It will not be available); And (d) failures of nodes can cause some files to be unavailable in the code network; And (5) the location of the file within the code network may fail for any number of reasons, such as for any other reasons that may cause files not to be available in the code network. If a node of the code network searching for belongs to multiple code networks, the node may search for the file in each of the code networks to which it belongs. If a node of a code network cannot find the location of the file in the code network (s) to which the node belongs, then the node may then wish to search for the file in one or more other code networks. In this case, the node may wish to discover other nodes in the code network that are connected to one or more other code networks (other than the code network (s) already discovered). This extension of the search for the file to one or more additional code networks is cross-located for use by nodes of the code network belonging to other code networks to search the file across multiple code networks. It is implemented using the ring search service.

The second service that can be supported by the nodes of the code network is a "translation" service. The translation service may be for translating documents between languages. For example, a node of the code network may want a document translated from English to German, and some of the nodes in the code network may have this capability. Similarly, a node of the code network may want a document translated from Italian to French, and some of the nodes in the code network may have this capability. For this type of service, the node is not just nodes that do not support translation services, more specifically the specific translation services required by the search node (ie translation from one language to another). You can try to find the location of nodes that support.

The representative services described above demonstrate that in addition to file sharing, there are many different services that can be supported by code networks. Thus, although specific examples of services that may be provided in code networks are described herein for clarity when describing the service location capability, the service location capability is limited to use with any particular service. Will be understood.

The service locating capability provides an algorithm that allows a node on a code network to locate one or more other nodes on the code network that support or provide a particular service.

As described herein, existing code networks allow nodes on code networks to search for other nodes on the code network or to search files stored in the code network. The service location locating capability described and described herein allows a code network to search for a new type of search within the code network, ie a node on the code network can locate a particular service on the code network. (I.e., to search for one or more other nodes on the code network that support a particular service, as specified in a service search request).

To simplify the description of the service location locating capability, the term “search” will be used in the following paragraphs to indicate service location search unless specifically indicated or described otherwise; Since the service locating capability uses existing lookup tables on the nodes of the code network, the term "lookup tables" used in the following paragraphs is still the code "finger held at nodes of the code network." "Tables.

The service locating capability is described using an example and then more generally using method diagrams showing processing performed at different nodes of the code network participating in providing the service locating capability within the code network. Expressed in terms.

As described in FIG. 1 and described above, the code network 100 has six bit key spaces (ie supporting 64 addresses), and 36 of the 64 nodes are active (ie Nodes (0, 2, 3, 5, 6, 7, 9, 12, 13, 16, 17, 18, 19, 20, 21, 22, 23, 24, 26, 29, 30, 32, 34, 35 41, 43, 45, 49, 51, 53, 54, 56, 57, 58, 62. As further described in Figure 1, the subset of the active nodes (ie, nodes 7, 19, 30, and 51 support a service denoted as service A (descriptively, each of the active nodes supporting service A is used with active nodes that do not support service A). Are displayed using darker shading than is used).

As an example, with reference to FIG. 1, assume that node 0 wants to find the location of one of the nodes of code network 100 supporting service A. FIG. To simplify the description of the example, we assume that the node initiating the search is node 0 (that is, by the same process only subtracting the value of N from the node IDs of all of the nodes in the code network). As can be done, it will be understood that there is no loss of generality since the same discussion can be made if the node initiating the search is node N). As indicated above in Table 1 (it is repeated below), at node 0 the search table has six entries containing the following information:

TABLE 1

In this example, node 0 initiates a search for locating service A within code network 100. Based on this search table maintained at node 0, node 0 transmits the M search request messages to the M nodes each identified by the M fingers of the search table, thereby providing the search location service ( A) is started. The search request message for the i-th finger contains the following information: (1) an indication of the service to be located; And (2) a service range, that is, a range of nodes that the i-th finger should search for.

The indication of the service to be located may be specified using any suitable criteria for specifying the service (eg, a service identifier, one or more parameters that may be used to describe the service, etc., as well as it). Like various combinations of).

The search range that identifies the range of nodes that the i-th finger should search for may be specified in any suitable manner. For clarity in describing the search range, the notation [m, n) to be used is used to denote a range from m to n, where m is included but n is excluded.

In one embodiment, for the i th finger, the search range will be [i th finger, i + 1 finger). In our example, node 0 will send discovery messages to node 2, node 5, node 9, node 16, and node 32, each of the discovery messages [2, 5), [5, 9), [9, 16), [16, 32), and [32, 0).

In another embodiment, for the i th finger, the search range may be further reduced from [i th finger, i + 1 finger) to [i th finger, 2 ⁱ ). In our example, for the third finger of node 5, the search range would be [5, 8) instead of [5, 9), where the (i + 1) finger is greater than 2 ⁱ This is because it is the same first node (ie there are no active nodes between the second ⁱ and the i + 1 finger). This embodiment provides a reduced range, but the reduced range means that a new node in the range of [2 ⁱ , i + 1 finger] may take the network example before node 0 updates its lookup table. For example, we will not describe the rare cases that can be done. This potential problem can be understood by considering the third finger of node 0, which means that node 8 has a code network 100, e.g., before node 0 updates its search table. Represents an event.

From the descriptions of these search range embodiments, all of the embodiments actually work, but an embodiment based on the (i-finger, i + 1 finger) search range is in the (i-finger, 2 ⁱ ) search range. It is evident that it is more powerful than the based embodiment.

As described above, node 0 performs a search for locating service A within code network 100 by sending service search request messages to nodes 2, 5, 9, 16, and 32, respectively. It starts. The service search request messages received by nodes 2, 5, 9, 16, and 32, respectively, are processed to continue the service location search.

Upon receiving the service search request message from node 0, each of the nodes 2, 5, 9, 16, and 32 first determines whether the requested service is locally supported. If any of the nodes 2, 5, 9, 16, and 32 that receive the service search request message from node 0 determine that the service is locally supported, then the node determines that it is the service. Respond to node 0 with a service search response message indicating that it supports. For each of the nodes 2, 5, 9, 16, and 32 that receive the service search request message from node 0 that determines that the service is not locally supported, the node is a node. Initiate processing to determine whether to initiate one or more search messages to one or more other nodes for locating the service requested by (0). The node that received the service search request message (where the service is not locally supported) is the finger or fingers (if any) in its local search table that fall within the search range specified in the received service search request message. Will initiate a service search request message.

In this example, since none of the nodes 2, 5, 9, 16, and 32 that receive a service search request message from node 0 support service A, the nodes 2, Each of 5, 9, 16, and 32 determines whether to initiate one or more search messages for one or more other nodes to find the location of service A requested by node 0.

The processing executed at the node receiving the service search request message from node 0 is performed by one of the nodes receiving the service search request message from node 0 (ie, nodes 2, 5, 9, 16, And 32) may be better understood by considering the processing performed by one of 32).

In this example, consider the processing executed at node 16 when receiving the service search request message from node 0. Node 16 has a range of [16, 32] and receives a search request from node (0). As indicated above, node 16 first determines whether it supports the requested service. In this example, node 16 does not support service A. Node 16 then determines whether to initiate the service search request message (s) to another node (s) of code network 100. Node 16 uses the search range [16, 32] included in the service search request message received from node 0 and uses its local search table to add another node (s) of code network 100. Determine whether to initiate the service search request message (s). The lookup table of node 16 is shown in Table 2 as follows.

In this example, based on the search range of [16, 32) and the specified search table included in the service search request message received from node 0, node 16 is responsible for nodes 17, 18, 20. Will generate service discovery request messages for. As initiated by node 0, the service search request messages initiated by node 16 may include (1) an indication of the service to be located; And (2) the range of coverage, i. E., The range of nodes that the i-th finger must seek. In this example, each of the service search request messages initiated for nodes 17, 18, 20, 24 specifies a service A, and also each of the search ranges [17, 18, 20]. ), (20, 24), (23, 32)). Node 16 does not initiate service discovery request messages for node 32 (fifth finger) and node 48 (sixth finger), which are the service discovery requests for which these nodes were received from node 0. This is because it is outside the search scope specified in the message.

2 depicts service discovery request messages initiated within the representative code network 100 of FIG. 1 in response to service location discovery initiated by node 0 of the representative code network 100 of FIG.

As depicted in FIG. 2, service search request messages are sent within the code network 100 as follows: node 0 sends messages to nodes 2, 5, 9, 16, 32; Node 2 sends a message to node 3; Node 5 sends messages to nodes 6 and 7; Node 9 sends messages to nodes 12 and 13; Node 16 sends messages to nodes 17, 18, 20, and 24; Node 18 sends a message to node 19; Node 20 sends messages to nodes 21 and 22; Node 22 sends a message to node 23; Node 24 sends messages to nodes 26 and 29; Node 29 sends a message to node 30; Node 32 sends messages to nodes 34, 37, 41, and 49; Node 32 sends a message to node 33; Node 40 sends messages to nodes 42 and 45; Node 49 sends messages to nodes 51, 53 and 56; Node 53 sends a message to node 54; Node 56 sends messages to nodes 57, 58, 62.

In this way, a service locator request for service A initiated by node 0 may respond with each node of code network 100 having an indication as to whether it supports the requested service. So that node 0 can thus be aware of the identity of any nodes that support service A).

As described above, each service search request message initiated within the code network to locate a service results in the initiation of a corresponding service search response message. The service search response messages propagate towards the node from which the service location search originates. In this way, the node from which the service location search originates knows the node (s) of the code network supporting the requested service.

For propagation of service search response messages, propagation of positive response messages and negative response messages is handled differently.

At a given downstream node receiving a service search request message from an upstream node, a positive response message is immediately propagated from the given downstream towards the upstream node. For example, this may be in response to a determination by the given downstream node that it locally supports the requested service, or a node further down the downstream node (ie, the given downstream node is serviced). Reply to the given downstream node receiving a positive response message from the downstream node initiating the search request message.

At a given downstream node receiving a service search request message from an upstream node, a negative response message waits for response messages from each downstream node (s) at which the given downstream node initiates a service search request message (s). Only after it has propagated from the given downstream toward the upstream node. In this way, the given downstream node may incorporate a response from its downstream node (s) into a single response message to which the upstream node is sent.

The propagation of service search response messages can be better understood by considering the exemplary code network of FIGS. 1 and 2.

In this example, when node 19 receives a service search request message from node 18, node 19 immediately responds to node 18 indicating that it supports service A, and node 18 Will in turn forward this response to node 16, which in turn will forward the response back to node 0.

In this example, when node 9 receives a service search request message from node 0, node 9 sends two service search request messages to nodes 12 and 13, respectively, which is the node ( 9) because it does not support service (A) itself. Here, assuming that node 9 receives a negative response from node 12 before receiving a negative response from node 13, node 9 waits for a response from node 13, 12) will store the negative response. Then, upon receiving the negative response from node 13, node 9 will merge the two negative responses from nodes 12 and 13 into a single negative response and Will be sent to node (0).

In the service location finding capability described and described herein, references to messages (and, more specifically, response messages) are generally references to application level messages. The need for this distinction is that when node N sends a message to node J, node J usually responds with a validation check to node N to indicate to node N that it has received the message. It will be understood by considering. If node N has not received the acknowledgment after some time, node N will resend the message (eg, up to a maximum number of attempts). In the service locator capability described and described herein, this acknowledgment process is assumed to be a background process, and is ignored here to simplify the description of the service locator capability. In other words, the service search response messages referenced herein are not acknowledgments of the background process that may or may not run in the code network.

In order to provide a good understanding of embodiments of the service locating capability, the processing performed by the originating node and intermediate nodes when providing the service locating capability is depicted and described with respect to FIGS. do.

3 depicts one embodiment of a method for generating a service search request message at an originating node.

At step 302, method 300 begins.

In step 304, the originating node detects a service location search request. The service location lookup request may be configured to identify a location (s) of the service within a P2P network (eg, to identify one or more nodes of the P2P network supporting the service), and to identify a service within the P2P network. Request to search.

The service location search request identifies the service required or desired at the originating node. The service location search request may be detected in any suitable manner, which may depend on how the service location search request is initiated at the originating node. The service location request may be initiated manually (eg by the user of the originating node) or automatically (eg by the originating node in response to detecting a trigger condition).

In step 306, the originating node initiates a service location search for the service. The service location search is a process for searching for a service within the P2P network to identify the location (s) of the service within the P2P network.

The service location search may be initiated using a search table maintained at the originating node. The service location search may be initiated by initiating a service search request with one or more nodes of the search table maintained on the originating node. The originating node may initiate the service search request by propagating one or more service search request messages toward one or more of the nodes in the search table.

The service search request message generated and propagated by the originating node is adapted to be used by the originating node to locate the location of at least one node of the P2P network supporting the requested service.

The service search request message includes a node ID of the originating node for use by nodes receiving the service search request message to respond to the service search request message.

The service search request message includes a node receiving the service search request message for matching request messages and response messages of the same service location search and a message ID of the service search request message for use by the originating node. do.

The service search request message includes service identification information adapted for use in identifying the requested service. For example, the service identification information may include a service ID identifying the service, service description information (eg, one or more parameters, attributes, adapted for use in identifying the service and / or describing the service, And / or criteria), and the like.

The service search request message includes a search range specified by the originating node for use by the node from which the service search request message is initiated. The search range is indicated as (K1, K2), where K2 is the largest value of the search range and K1 is the smallest value of the search range. The search range of the service search request message may depend on the type of service location search initiated by the originating node (eg, full network search, phased network search, progressive network search, etc.).

It will be appreciated that the information included in the service search request message may be different (eg, less information may be included, more information may be included, different information may be included, etc.).

The manner in which the originating node initiates the service location search (ie, the number of service search request messages initiated by the originating node, and the timing of the service search request messages) is the type of service location search that is executed (eg, total Network discovery, phased network discovery, incremental network discovery, etc.).

In one embodiment where a full network search is initiated by the originating node, service search request messages are propagated simultaneously from the originating node towards each of the fingers in the finger table.

In one embodiment where staged network discovery is initiated by the originating node, service discovery request messages are sequentially propagated from the originating node toward one or more fingers in the finger table. The use of phased network search can be better understood by reference to FIGS. 6 and 7 in conjunction with the other figures depicted and described herein.

In one embodiment, where progressive network discovery is initiated by the originating node, service search request messages are simultaneously directed from the originating node toward a subset of the fingers in the finger table as the initial discovery and as one or more subsequent searches. It propagates continuously toward one or more subsequent fingers in the table. The use of progressive network search may be better understood by reference to FIGS. 8 and 9 in conjunction with the other figures depicted and described herein.

At step 308, method 300 ends.

Although depicted and described as termination, following the initiation of the service location search by the originating node, the originating node is then moved by the originating node in response to the one or more service search request messages initiated by the originating node. Initiating processing to process the received one or more service search response messages may support and continue processing the service location search.

Although depicted and described herein primarily as being executed in succession, at least some of the steps of the method 300 may be executed concurrently or in a different order than that depicted and described with respect to FIG. 3. Although primarily depicted and described herein with respect to a particular implementation of process logic for executing service search request message generation at an intermediate node, process logic for executing service search request message generation at an intermediate node is described and described herein. It will be appreciated that it can be implemented in a variety of different ways while still supporting the service locating capability.

4 depicts one embodiment of a method for processing a service search request message at an intermediate node.

At step 402, method 400 begins.

In step 404, the intermediate node (denoted as node J) receives a service discovery request message from an upstream node (denoted as node N), which may be the initiator or upstream intermediate node of the service location discovery. have.

The service search request message includes any information suitable for searching for the requested service.

The service search request message includes the node ID of the originator (ie, upstream node N) of the service search request message.

The service search request message includes a message ID of the service search request message.

The service search request message includes service identification information adapted for use in identifying the requested service. For example, the service identification information may include a service ID identifying the service, service description information (eg, one or more parameters, attributes, adapted for describing the service and / or for use in identifying the service, And / or criteria), and the like.

The service search request message includes a search range specified by the upstream node N for the intermediate node J. The search range is indicated as (K1, K2), where K2 is the largest value of the search range and K1 is the smallest value of the search range.

It will be appreciated that different information may be included in the service discovery request message.

In step 406, a determination is made whether the intermediate node J supports the requested service. This determination may be performed in any suitable manner (eg, by comparing at least a portion of the service identification information to information available at intermediate node J).

If the intermediate node J supports the requested service, the method 400 proceeds to step 408 (in which point the intermediate node J responds with a positive service search response to the upstream node N). Start a message).

If the intermediate node J does not support the requested service, the method 400 proceeds to step 410 (at this point, the intermediate node J is said to be within the search range of the service search request message). Initiate additional processing to determine whether to extend the service location search to other nodes in the network).

In step 408, the intermediate node J sends a positive service search response message for the upstream node N. The service search response message is any suitable for use to inform the originating node that the requested service is supported by the intermediate node J and allows the originating node to request the service from the intermediate node J. Information may include For example, the service search response message is an identifier of the intermediate node J, an indication that the message is a response to a service search request message from an upstream node N (eg, a message ID of the service search request message). ), An indication that intermediate node J supports the requested service, network contact information for intermediate node J for use by the originating node to request service from intermediate node J (eg, IP Address, port number, etc.). It will be appreciated that the service search response message may include different information. From step 408, the method 400 proceeds to step 434, where the method 400 ends.

In step 410, the intermediate node J identifies the first finger of its search table.

As depicted in FIG. 4, in conjunction with step 410 or at any other suitable time, the intermediate node J may also additionally determine whether to extend the service location search to other nodes in the network. You can execute initialization functions to use to perform the processing. For example, the intermediate node j may initialize the finger counter i equal to 1, and set the first finger variable F1 equal to the first finger of the intermediate node j (ie, F1 = first finger), the second finger variable F2 is set equal to NULL, and the search list is set equal to NULL (where the search list is defined by intermediate node J from upstream node N). A list of nodes that transmit a service search request message on behalf of the service search request message received, which may be used to manage responses to any service search request messages initiated by intermediate node J) . It will be appreciated that fewer, more, and / or different variables, lists, and / or similar parameters may be used and / or initialized in any other suitable manner.

In step 412, a determination is made as to whether the largest value K2 of the search range is greater than the first finger F1 of the intermediate node J. The intermediate node J checks whether its first finger is outside the search range. If K2 is not greater than F1, the method 400 proceeds to step 414. If K2 is greater than F1, the method 400 proceeds to step 416.

In step 414, the intermediate node J sends a negative service discovery response message to the upstream node N. [ In this case, no service search request message is generated by the intermediate node J. The service search response message may include any information suitable for use to inform upstream node N that there are no nodes in the range of [F1, F2) supporting service A. From step 412, method 400 proceeds to step 434, where method 400 ends.

In step 416, the intermediate node J identifies the (i + 1) finger of its search table. In the first pass through method 400, this is the second finger of the search table of intermediate node J.

In step 418, a determination is made as to whether the largest value K2 of the search range is greater than the (i + 1) th finger F2 of the intermediate node J. The intermediate node J checks whether its (i + 1) finger is outside the search range.

If K2 is greater than F2, the method 400 proceeds to step 428 (ie, the search range of the message is reduced to (F1, K2) and the resulting service search generated by the intermediate node J). The request message is the last to be generated by intermediate node J in response to the service search request message received from upstream node N).

If K2 is not greater than F2, method 400 proceeds to step 420 (ie, the resulting service search request message generated by intermediate node J is a service search request message received from upstream node N). In response to the last service discovery request message generated by intermediate node J).

In step 420, intermediate node J sends a service search request message to node F1 having a search range of (F1, F2). In this respect, both F1 and F2 are smaller than K2, so the search range (F1, F2) is within the search range (K1, K2). The service search request message typically includes the information contained in the service search request message, as described herein.

In step 422, the intermediate node J is a node in the search list for use by the intermediate node J to manage responses to any service search request messages initiated by the intermediate node J. (F1) is added.

In step 424, the intermediate node J updates the first finger variable F1 to be equal to the second finger variable F2 and increments the finger counter (i = i + 1).

In step 426, a determination is made as to whether the finger counter i is greater than or equal to M (where 2 ^M is the size of the key space and M is the size of the finger table on the intermediate node J).

The finger counter i is not greater than or equal to M and the method 400 returns to step 416.

If the finger counter i is greater than or equal to M, the method 400 proceeds to step 428 (ie, F1 is the last finger and the resulting service search request message generated by the intermediate node J). Is the last generated by intermediate node J in response to the service search request message received from upstream node N).

In step 428, intermediate node J sends a service search request message to node F1 having a search range of [F1, F2]. The service search request message includes information typically included in the service search request message, as described herein.

In step 430, intermediate node J is a node in the search list for use by intermediate node J to manage responses to any service search request messages initiated by intermediate node J. (F1) is added.

In step 432, intermediate node J starts time and one or more service search response messages to be received by intermediate node J in response to one or more service search request messages initiated by intermediate node J. Wait to hear

At step 434, method 400 ends.

Although the execution of the method 400 is depicted and described as termination, resulting in the initiation of one or more service search request messages by the intermediate node J, the intermediate node J is one or more services initiated by the intermediate node J. By initiating processing to process one or more service search response messages received by the intermediate node J in response to the search request messages (eg, by executing the method 500 depicted and described with respect to FIG. 5). The service location finding request initiated by the originating node may be supported to continue processing.

Although depicted and described herein primarily as being executed in succession, at least some of the steps of the method 400 may be executed concurrently or in a different order than that depicted and described with respect to FIG. 3. Although mainly depicted and described herein with respect to a particular implementation of process logic for executing service discovery request message generation in an intermediate node, process logic for executing service discovery request message generation in an intermediate node is described and described herein. It will be appreciated that it can be implemented in a variety of different ways while still supporting the ability to locate.

5 depicts one embodiment of a method for processing service search response messages at an intermediate node (represented as node J). The intermediate node J services the upstream node received by the intermediate node J a service discovery request message that triggered the intermediate node J to send one or more additional service discovery request messages to the one or more downstream nodes. Implement a method for processing service search response messages to provide a search response message.

At step 502, method 500 begins.

In step 504, intermediate node J waits for one or more service search response messages. The service search response by the intermediate node J (eg, by executing the method 400 depicted and described with respect to FIG. 4) in response to one or more service search request messages initiated by the intermediate node J. Message (s) are expected.

In step 506, the intermediate node J determines whether a service search response message has been received from the downstream node.

If a service search response message is received from the downstream node, the method 500 proceeds to step 510 (at which point processing of the service search response message begins).

If a service search response message is not received from downstream, the method 500 proceeds to step 508.

In step 508, a determination is made whether the timer has expired. The timer may be set by the intermediate node J in any suitable manner (eg, as part of the execution of the method 400, as in the initialization phase of the execution of the method 500, or in any other suitable manner. to). The timer can be set to any suitable length of time.

If the timer has not expired, the method 500 returns to step 504 and in step 504 step 506 (ie, the intermediate node J responds with one or more service discovery responses from one or more downstream nodes). To the waiting state for messages).

If the timer has expired, the method 500 proceeds to step 522 (at this point, intermediate node J initiates a negative service search response message for the upstream node, which is intermediate node J). Does not receive all service discovery response messages that have not yet been processed from downstream nodes within the allotted time length).

With respect to steps 504, 506, 508, it will be understood that this functionality may be implemented in other ways. For example, explicit steps that determine whether a service search response message has been received (step 506) and whether the timer has expired (step 508) are performed rather than executed within the method 500. , Much less is executed within method 500 in a particular sequence, and until method 500 detects that a service search response message has been received (in which point method 500 proceeds to step 510), or It will be appreciated that until it detects that the timer has expired (in which point method 500 proceeds to step 522), it may still remain in a waiting state (ie, step 504). For example, rather than monitoring the timer as an explicit step within the method 400, regardless of the point in the method 500 in which processing is performed, by the intermediate node J, the timer expires. Detection may be performed as a background process (eg, directly or smoothly) to cause the method 500 to proceed to step 522. It will be appreciated that this functionality may be implemented in other ways.

In step 510, a determination is made whether the received service search response message is legitimate. The validity of the received service search response message may be determined in any suitable manner. For example, in one embodiment, the validity of the received service search response message is provided to verify that the service search response message is provided in response to a service search request message from an intermediate node J. This is determined by checking the request ID included in the message.

If the service search response message is not valid, the method 500 proceeds to step 512.

If the service search response message is valid, the method 500 proceeds to step 514.

In step 512, the intermediate node J ignores the received service search response message. From step 512, the method 500 returns to step 504 (ie, intermediate node J continues to wait for one or more service search response messages).

In step 514, the received service discovery response message is found to be positive (i.e., the location of the node supporting the requested service was found) or negative (i.e., the location of the node supporting the requested service is found). Decision is made.

If the service search response message is affirmative, the method 500 proceeds to step 516.

If the service search response message is negative, the method 500 proceeds to step 518.

In step 516, intermediate node J sends a positive service search response message to the upstream node.

The service search response message may include any information suitable for use in providing an upstream node with an indication of the node identified as supporting the requested service. For example, the service search response message may be an identifier of the intermediate node J, an indication that the message is a response to a service search request message from the upstream node (eg, the message ID of the service search request message), and An indication of a node supporting the requested service, network contact information (eg, IP) for the node supporting the requested service for use by the originating node when requesting the service from a node supporting the requested service; Address, port number, etc.), and the like. It will be appreciated that the service search response message may include different information. From step 516, the method 500 proceeds to step 524, where the method 500 ends.

In step 518, intermediate node J removes the source node from the search list. The source node is the source of the service search response message received by intermediate node J. The search list is used by intermediate node J to manage responses to any service search request message initiated by intermediate node J, as described with respect to method 400. A list of one or more nodes for which to expect a service discovery response message.

In step 520, a determination is made whether the search list is NULL. This is a determination as to whether or not all of the service search response messages expected to be received by intermediate node J have actually been received (an associated service search response message can be sent from intermediate node J to the upstream node). So that).

If the search list is NULL (ie, all predicted service search response messages have been received), the method 500 proceeds to step 522.

If the search list is not NULL (ie, not all expected service search response messages have been received), the method 500 returns to step 504 and from step 504 to step 506 (ie, the Intermediate node J proceeds to a waiting state, still waiting for one or more service search response messages from one or more downstream nodes).

In step 522, intermediate node J sends a negative service search response message to the upstream node.

The service search response message indicates that intermediate node J does not support the requested service, and none of the downstream nodes contacted by intermediate node J on behalf of the upstream node do not support the requested service. It may include any information suitable for use in providing an indication to the upstream node. From step 522, the method 500 proceeds to step 524, where the method 500 ends.

At step 524, method 500 ends.

Although primarily depicted and described herein as being executed in succession, at least some of the steps of the method 500 may be executed concurrently or in a different order than that depicted and described with respect to FIG. 5. Although mainly depicted and described herein with respect to a particular implementation of process logic for performing service discovery response message processing at an intermediate node, the process logic for processing service discovery response message at an intermediate node is the service location capability described and described herein. It will be appreciated that it can be implemented in a variety of different ways while still supporting.

As indicated here, FIG. 5 is primarily directed towards processing service search response messages executed at intermediate nodes. However, FIG. 5 may also be adapted to specify service search response message processing executed at an originating node, i.e., a node initiating the service location search request for the service. For the originating node, the method 500 is adapted by eliminating steps 516 and 522. For steps 516 and 522, these steps are unnecessary for the originating node since the originating node is the source of the service location search request (ie, the originating node does not need to send a response). For the removal of step 516, from step 514, the method 500 may proceed to step 524 (eg, once the originating node identifies one of the nodes supporting the requested service). The originating node does not care whether there are any other nodes supporting the requested service) or if there is still an unresolved (eg, the originating node of the network supporting the requested service). You can continue to monitor for additional service search response messages (which may want a list of all nodes). For removal of step 522 from step 508 (the timer expires) and step 520 (the navigation list is NULL), the method 500 proceeds to step 524.

In the service location search as described above: (1) if the key space of the code network is M bits, then the source of the service location search sends at most M service search request messages and at most M service search response messages. Will receive, the intermediate nodes send far fewer request messages and receive much less response messages, and ensure that none of the nodes in the code network are overloaded with messages, and (2) downstream nodes from the upstream node. The service search request message sent to may cause one or more additional service search request messages to be generated at the downstream node such that a service location search for the service may be performed up to M-1 steps or stages. Distribution across one or more steps or stages Navigation can be to generate a sequence of. From this, in the service location search as described above, if there are K active nodes in the code network in the service location search request, the service location search request is eventually terminated (the service location search request). It will generate K-1 messages in the code network because it passes one service discovery request message to each node of the code network (excluding source). These messages are distributed across all of the nodes such that none of the nodes are overloaded by the messages, but in general, K is a large number, and thus, of messages generated in the code network to locate a service. It would be desirable to reduce the number.

In one embodiment, the number of messages generated in the code network to locate a service is a portion of the circle, rather than the searches for the service initiating searches for the service simultaneously for all parts of the circle. Can be reduced by performing a gradual search that is initiated step by step in succession. This type of service location search is referred to herein as progressive service location search.

The incremental service location search is better by first considering that one way to reduce the number of messages generated in the code network to locate the service is to search only a portion of the circle, instead of the entire circle, in the initial search. Can be understood. In this case, because the entire circle is not searched, this search cannot find the location of the node providing the requested service. In such a case, the probability that a search for a portion of the circle is successful may be balanced against the number of messages initiated to locate the service (ie, relative to the size of the search range within the circle). In this case, the size of the search range can be determined as follows.

The manner in which the size of the search range can be determined to ensure a small search failure rate can be better understood by considering an example. In this example, let us assume that the key space is ^2M , and on average, there are usually ^2K active nodes in the network providing the service. Based on these assumptions, the probability that there is an active node providing a service for a particular node-ID is α = 2 ^K / 2 ^M = 2 ^{-− (MK)} . In this example, further assume that node 0 searches for service A within the initial search range of [1, L). The probability that no node in the range ([1, L)) will provide service A is (1-α) ^L-1 . In this example, the desired search failure rate is, for example, less than 2% (although any desired search failure rate may be used), which results in the formula ((1-α) ^L-1 <1/50). do. Using this equation and taking the logarithm of both sides of the equation (base e), the enemies: (L-1) * In (1-α) <-In (50), where In (1-α) = such as ^{α 4/4 - -α - α} 2/2 - α 3/3. In general, α is a very small number, so higher order terms are not algebraic and can be ignored. Thus, the equation can be approximated as:-(L-1) * α <-In (50), or L> (3.91) * 1 / α + 1, more simply, L> (3.91) * 1 / α (ignore 1).

The manner in which the size of the search range can be determined to ensure a small search failure rate can also be better understood by considering more illustrative examples. In this example, consider a code network with a key space of 160 bits. On average, assume that there are 100,000 active nodes in the network where there are usually 2 ¹⁰ (or 1024) nodes among the active nodes providing service A (ie ~ 1% of the active nodes). . In this case α = ²⁻¹⁵⁰ and L is selected to be larger than (3.91) * 2 ¹⁵⁰ . Let L = 4 * 2 ¹⁵⁰ = 2 ¹⁵² . Have the choice of these L, the initial search is ^2152/2160 = ⁸ 1/2 of the one-part will cover the 1/256. Thus, in this example, the initial search will have a 98% chance of success, while the number of messages exchanged in the network to locate the service is reduced by a factor of 256 (ie, the initial on average). The number of nodes in the service range is approximately 400, so the initial search produces only about 400 search messages, rather than 100,000 search messages to be generated if the initial search spans the entire code network.

As mentioned above, it is unlikely that the initial search will simply fail to locate the node that supports the service. If the initial search fails to locate a node that supports the service, the source of the service location search may then initiate a second search for the second portion of the circle (eg, the example above). Node 0 will have a range ([L, 2L) and initiate a second service location search). If the second search fails to locate a node that supports the service, then the source of the service location search may then initiate a third search for the third portion of the circle (eg, in the example above). Node 0 will have a range ([2L, 3L) and initiate a third service location search). Thus, the source node may continue to search each of the plurality of portions of the circle of the code network until the location of the node supporting the service is found or the entire circle is searched without finding the location of the node supporting the service. Thereby providing a progressive service location search that can significantly reduce the number of messages exchanged within the code network to locate the node supporting the service.

In the progressive service location search embodiment described above, the endpoints of the search arcs (and thus search ranges) are L, 2L, 3L, 4L, and the like. This is depicted in FIG. 6.

6 depicts an exemplary code network, illustrating an example of performing a gradual service location search for a service in an exemplary code network. In the code network 600, the key space is 6 bits (ie 64 IDs) and the size of the search range for each stage of the progressive service location search is 8 nodes.

In the gradual service location search embodiment described above, the endpoints of the search arcs are L, 2L, 3L, 4L, etc., which is not compatible with the search table maintained at the source node initiating the service location request. , They are not fingers of the search table maintained at the source node). As a result, when performing a search across one of the arcs (eg, over [n * L, (n + 1) * L)), multiple service location search messages may need to be generated. This is depicted in FIG.

FIG. 7 depicts an exemplary search range for performing a gradual service location search for a service in the exemplary code network of FIG. 6. As depicted in FIG. 7, the (k + 1) fingers belong to the search range (ie, n * L <(k + 1) fingers <(N + 1) * L) and the kth finger And the (k + 2) fingers are both outside the search range. In this case, to perform a service location search across the arc, the source node will generate two service search request messages as follows: (a) One search request is (n * L, (k) +1) finger) and is sent to k-th finger, and (b) one search request has a search range of ((k + 1) finger, (N + 1) * L) k + 1) is sent to the finger.

In one embodiment, the progressive service location search may be modified such that the progressive service location search is in line with the search table of the source node, thereby avoiding a situation where a search through an arc requires multiple service search request messages. .

A representative embodiment of aligned progressive service location search is depicted and described with respect to FIGS. 8 and 9.

8 depicts one embodiment of a method for generating a service search request message at a node initiating a service location search request using aligned incremental service location search.

At step 802, method 800 begins.

In step 804, the node determines an estimated average number of active nodes (denoted as L) that support the service.

The estimated average number of active nodes supporting the service can be determined from any suitable source of such information (eg, from the local memory of the node, from a web server, etc.).

The average number of active nodes supporting the service can be estimated in any suitable manner. In one embodiment, the average number of active nodes supporting a service may be estimated using a modified version of the service location search algorithm depicted and described with respect to FIGS. In the service location search algorithm described with respect to FIGS. 1-6, the intermediate node forwards a positive response message to the upstream node as soon as it is received from the downstream node. In one embodiment, the service location search algorithm depicted and described with respect to FIGS. 1 to 6 is positive to the upstream node upon receipt of a first positive response from one of the downstream nodes that initiated service search request messages. Rather than forwarding the response immediately, each intermediate node waits for all response messages from all downstream nodes from which it initiated service search request messages and then integrated response (the total number of the downstream nodes supporting the service). And a node ID and IP address of at least one of these nodes) may be changed to forward to the upstream node. The intermediate nodes may be instructed to execute this modified process in any suitable manner. In one embodiment, for example, a new indicator may be added to the service search request messages to inform the intermediate nodes as to whether to perform a process for estimating an average number of active nodes supporting a service. . In one such embodiment, the new indicator may be set to TRUE for at least some first searches for a particular service, so that the source node is the average number of active nodes for which the node supports the service. Receive at least some estimates of the number of active nodes supporting the service so that an estimate can be determined therefrom. The new indicator may then be set to FALSE so that the intermediate nodes are not required to perform modified processing for all requests for the service. In a further embodiment, an estimate of the average number of active nodes supporting the service is a service location search for the service using the service location search algorithm described with respect to FIGS. 1-6 with a new indicator set to true. Can be updated periodically by executing. After determining an estimate of the average number of active nodes supporting a service, the node then uses the progressive service location search capabilities to estimate an average number of active nodes supporting a service to perform subsequent searches for the service. It is available. Moreover, in addition to the above-described embodiments, many variations of the above-described embodiments may be used. For example, search messages from the originating node to part of the network may set the indicator to true while the indicator is set to false for the rest. In this example, responses from the search messages with the indicator set to true can be used to estimate the average number of active nodes supporting the service, but with less accuracy, the indicator set to false Since the search messages that are held do not wait for positive responses, they will generate a faster response. It will be appreciated that many other methods are also possible. In general, the differences between the different methods include trade-offs between the accuracy of the estimate, the complexity of the algorithm, the response time, and the number of messages generated.

In step 806, the node determines (indicated as K) the number of fingers for the initial search for the service. The number of fingers for the initial discovery is determined using the average number of active nodes supporting the service. The number of fingers for the initial search is determined by solving for L from the equation ((L-1) * In (1-a) <In (1 / b)), where (i) a is The node ID is the probability of having an active node supporting the service, (ii) b is the probability that the search is negative, and (iii) L is the search range.

In step 808, the node sends service search request messages to the first K fingers of the search table maintained at the node. The service search request message includes any information suitable for use in searching for the requested service, such as the ID of the service search request message, service identification information adapted for use in identifying the requested service, search range, and the like. do. The search range for the i th finger is [i th finger, (i + 1) finger), where i = 1, ..., K. It will be appreciated that different information may be included in the service discovery request message.

In step 810, a determination is made as to whether a node supporting the service has been identified (ie, based on initial service search request messages from step 808, and optionally from step 816). One or more subsequent service discovery request messages). If a node supporting the service has been identified, the method 800 proceeds to step 818, at which point the method 800 ends. If a node supporting the service has not been identified, the method 800 proceeds to step 812.

In step 812, a determination is made as to whether the last finger in the lookup table has been selected (ie, K = M). If the last finger in the search table has been selected, the method 800 proceeds to step 818, at which point the method 800 ends. If the last finger in the lookup table has not been selected, the method 800 proceeds to step 814.

In step 814, the value of K is incremented. In step 816, the node sends a service search request message to the Kth finger of the search table maintained at the node. From step 816, the method 800 returns to step 810, where a determination is made as to whether a node supporting the service has been identified during the current stage of the progressive search.

At step 816, the method 800 ends when a node supporting the service is identified or entered when no node supporting the service is identified after all the fingers of the search table have been processed.

8, in one embodiment, if the (i + 1) finger is the same as the i th finger, the service search request message is not sent for the (i + 1) finger (recalling duplicate messages in the initial search). To avoid sending to the fingers) thereby preventing multiple service search request messages from being sent to the same node.

Although depicted and described herein primarily as being executed in succession, at least some of the steps of the method 800 may be executed concurrently or in a different order than that depicted and described with respect to FIG. 8. Although primarily depicted and described herein with respect to a particular implementation of process logic for executing service search request message generation at an intermediate node, the process logic for executing service search request message generation at an intermediate node is still described and described above. It will be appreciated that it can be implemented in a variety of different ways while supporting the service location capability.

9A-9D illustrate a service location search initiated by one of the nodes of the representative code network of FIG. 1, illustrating an example of performing an ordered incremental service location search for a service in the exemplary code network of FIG. 1. In response, depict service discovery request messages initiated within the representative code network of FIG.

In the example of FIGS. 9A-9D, node 0 initiates a service location search request. The estimated average number of active nodes supporting the requested service is equal to 8 (L = 2 ³ = 8), so that the initial search for the service is the first three fingers of node 0's search table, i.e. Nodes 2, 2, and 5, respectively. Thus, service search request messages are sent to nodes 2 and 5 with search ranges of [2, 5) and [5, 9), respectively (node 9 is the fourth finger). The initial search by node 0 is shown in FIG. 9A, where the service search request messages are sent to nodes 2, 5 and node 2 sends a service search request message to node 3, and the node (5) sends service search request messages to the nodes (6, 7). In this example, node 7 is the active node supporting the requested service, so node 0 will find the location of the node supporting the requested service in the initial search, and the aligned incremental service location. The search will complete.

In the example of FIGS. 9A-9D, however, for illustrative purposes, assume that node 7 does not support the service and therefore that the initial search has failed. Upon determining that the initial search has failed, node 0 then initiates a subsequent search for the service with the next finger in its search table, namely node 9. Thus, the service search request message is sent to node 9 with a search range of [9, 16). This subsequent search by node 0 is shown in FIG. 9B, where the service search request message is sent to node 9 and node 9 sends service search request messages to nodes 12 and 13. In this example, there are no active nodes in the range ([9, 16) supporting the requested service, so the aligned progressive service location search will continue.

In the example of FIGS. 9A-9D, upon determining that the first subsequent search has failed, node 0 then moves to the next finger in its search table, namely node 16, the second subsequent for the service. Start the search. Thus, the service search request message is sent to node 16 with a range of [16, 32]. This subsequent search by node 0 is shown in FIG. 9C, where the service search request message is sent to node 16, and node 16 sends service search request messages to nodes 17, 18, 20, 24. (As well as these nodes propagate additional service search request messages). In this example, node 19 is the active node supporting the requested service, so node 0 will find the location of the node supporting the requested service in the initial search, and the aligned incremental service location. The search can be completed.

In the example of FIGS. 9A-9D, however, for illustrative purposes, assume that node 19 does not support the service and therefore the second subsequent search has failed. Upon determining that the second subsequent search has failed, node 0 then initiates a third subsequent search for the service with the next finger in its search table, namely node 32. Thus, the service search request message has a search range of [32, 0) and is sent to node 32. This subsequent search by node 0 is shown in FIG. 9D, where the service search request message is sent to node 32 and node 32 sends service search request messages to nodes 34, 37, 40, 49. (As well as these nodes propagate additional service search request messages), in this example, node 51 is the active node supporting the requested service, so node 0 is in the initial search. The location of the node supporting the requested service will be found, and the aligned incremental service location search will be completed.

In the aligned incremental service location search, multiple service search request messages are sent by the originating node in the initial stage, but a single service search request message is sent by the originating node in each of the subsequent stages. This is evident from the exemplary method of FIG. 8 and the examples of FIGS. 9A-9D. In general, the search ranges for the first two searches each cover L node IDs, and then the search range of the subsequent searches is doubled in every step (eg, the third search is approximately 2 * L Cover node IDs, and the fourth search covers approximately 4 * L node-IDs).

As described herein, progressive service location search is one suitable method for reducing the number of messages exchanged within the code network to find the location of a node that supports the requested service.

In one embodiment, the number of messages exchanged within the code network to locate the node supporting the requested service is one or more nodes previously identified as nodes supporting the requested service at the nodes of the network. Can be reduced by caching the node IDs of the nodes. In this embodiment, from the perspective of the source node of the node, node IDs of one or more nodes previously identified by the source node as nodes supporting the requested service may be cached as the source node. In this embodiment, when searching for the service, the search message may be set to indicate that the source node is willing to accept cached information, so when the node receives such a search request, the node It can then respond with the node ID (s) from its cache. In this way, the number of search messages is reduced and the response time is faster, but there is a risk of the cached information becoming old. In one embodiment, to avoid stale information, only node IDs cached within the last X amount of time will be included in the response, where the amount of time of X may be configured as needed or desired (eg, the last 30 Last 4 hours, last day, etc.).

In one embodiment, the number of messages exchanged within the code network to locate the node supporting the requested service is exchanged between the nodes of the code network to exchange information about which services are supported by which nodes. It can be reduced by piggybacking the heartbeat messages that are made. As described herein, a node in the code network periodically sends heartbeat messages to its predecessor and successor nodes. The heartbeat messages sent by the node to its predecessor include the node ID (s) of the successor (or K successors) of the node, and similarly, its subsequent by the node. The heartbeat message sent to the child contains the node ID (s) of the predecessor (or K predecessors) of the node. In this embodiment, in addition to the predecessor / successor information, the heartbeat message sent by the node will include information indicative of any messages supported by the node, whereby each of the nodes is associated with its neighbors. Know your service capabilities. In this way, the number of messages that need to be exchanged to locate the service in the code network is reduced.

As described above, one service that can be supported by the code network is a cross-ring search service. The cross-ring search service enables a target node to initiate a request to search for an object on one or more other code networks for which the target node is not a member.

In general, members of a code network form a community that likes to share files related to some common interest (s), such as certain types of music, certain types of videos, research topics, and the like. A user can have many interests, so his or her node can join multiple code networks at the same time. If a node searching for a file fails to locate the file in the code network (s) to which it belongs, the node may wish to extend the search for the file to one or more additional code networks, It can be achieved using a cross-ring search service.

Using the cross-ring search service, the originating node searching the file will search the code network (s) that is a member to find the location of any node (s) belonging to one or more other code networks. . The originating node initiates a search request. In the search request, the originating node specifies that the service is a cross-ring search service. The search request may include additional service specific information.

The additional service specific information may comprise a non-search list, which is a list of code network IDs of code networks for which the originating node has already searched the file. In this case, when responding to such a request, these code networks should be ignored (i.e., the node receiving the search request must be configured with a code network other than the code network (s) the node has indicated in the non-browsing list). If you are a member of s) you will only send a positive response).

The additional service specific information may comprise a specific-search list, which is a list of code network IDs of code networks for which the originating node wishes to search the file. In this case, when responding to this request, all code networks other than these code networks should be ignored (i.e., the node receiving the search request is simply the code networks whose node is indicated in the specific-search list). If you are a member of either, you will send a positive response).

When using the cross-ring search service, the originating node searching for the file will receive search responses in response to the search request. In this case, any positive search response includes the code network ID (s) of the code network (s) that triggered the positive search response. Upon receiving a positive search response, the originating node may attempt to obtain the file from the identified code network (s) in any suitable manner.

In one embodiment, upon receiving a positive search response, the originating node may attempt to obtain a file from the identified code network (s) by connecting to the identified code network (s). In this case, upon connecting to the code network (s), the originating node may then initiate a search for the file within the connected code network (s).

In one embodiment, upon receiving a positive search response, the originating node initiates a search for the file within the identified code network (s) on behalf of the originating node by a node that is answered with the positive search response. You can ask. This means that if the originating node does not have permission to access the identified code network (s), the originating node does not have or dedicates the resources required to access and leave the identified code network (s). (I.e. when the node connects to the code network, the implied assumption is that the node will store multiple files instead of the code network, and accessing and leaving the code network takes time and network resources such as files Between the originating node is technically unable to connect to the identified code network (eg, the originating node is an IPv4-only node and the identified code network (s) is an IPv6 code network). Or the originating node is an IPv6-only node and the identified code network (s) May be useful if the originating node, such as (in the case of an IPv4 network), is unable or unwilling to connect to the identified code network (s). The originating node is configured to transmit the search request message to the node that is answered with the positive search response and to the node that is responded with the positive search response to the node within the identified code network (s) instead of the originating node. You can request to initiate a search for a file. In this case, the search request message sent by the originating node includes the full name of the file searched by the originating node, which may cause the identified code network (s) to have a different key space and And / or use a hash function that is different from the code network of the originating node. If the file cannot find a location within the identified code network (s), the originating node receives a negative search response. If the file is found in the identified code network (s), the node storing the file forwards the file to the originating node. The file may or may not be stored in the code network of the originating node.

Although primarily described and described herein with respect to embodiments in which the service locating capability is implemented within a particular type of P2P network, i.e., a code network, the P2P service locating capability is any suitable for supporting the service searching capability. It may be implemented within other types of P2P networks.

In one embodiment, the service location locating capability may be adapted such that the service location locating capability is generally suitable for use in DHT-based P2P networks. In one such embodiment, the P2P network to which the service matching capability is provided has a well-configured geometry (eg, for code, the geometry is circular), and the concept of "area" is derived from this geometry. (Eg, for code, the "region" is the arc of the circle). When a source node of the DHT-based P2P network initiates a service location search, the source node sends a service search request to the nodes in its routing table, and each service search request sent to the node is the search. A description of the area to be restricted to the node receiving the service search request. When an intermediary receives a service search request, the intermediate nodes determine whether it locally recognizes a node that supports the requested service (eg, it is itself, its predecessor, its successor). One or more nodes from cached information available at the intermediate node, etc., as well as combinations thereof). If the intermediate node locally identifies a node that supports the requested service, the intermediate node responds with a positive response. If the intermediate node cannot locally identify a node that supports the requested service, the intermediate node propagates the service search request based on its own routing table. Propagation of the service search request by the intermediate node has a range limited by information included in the service search request received by the intermediate node and information from the routing table of the intermediate node. Search ranges of service search requests used to match a service may be adapted to minimize the overlap between search ranges to improve the efficiency of the search, but in certain cases if the overlap simplifies the search range description requirements At least some overlap may be desirable. In this generalized implementation of service locating capability, many other capabilities described and described herein for code networks may also be used (eg, the probability of successful search when the search is limited to one area). To estimate, to perform gradual searches, etc., as well as combinations thereof).

Although described and described herein with respect to embodiments in which service location capabilities are provided, the service location capabilities described and described herein may be adapted to provide information distribution capabilities for distributing information within P2P networks. Will be understood. In such embodiments, the service search request messages described herein within the context of the service location search capability may be adapted for use as information distribution messages in the information distribution capability. In such embodiments, the information distribution capability may include not only all nodes of the P2P network, one or more ranges of nodes of the P2P network, one or more nodes of the P2P network that meet one or more criteria, etc. It can be implemented to be distributed in various combinations thereof.

10 depicts a high-level block diagram of a computer suitable for use in carrying out the functions described herein. As depicted in FIG. 10, computer 1000 may include processor element 1002 (eg, a central processing unit (CPU) or other suitable processor (s)), memory 1004 (eg, random access memory (RAM), or the like. ), Read-only memory (ROM), etc.), service location search module / process 1005, and various input / output devices 1006 (eg, user input devices (such as keyboards, keypads, mice, etc.), user outputs). Devices (such as displays, speakers, etc.), input ports, output ports, receivers, transmitters, and storage devices (eg, tape drives, floppy drives, hard disk drives, compact disk drives, etc.).

The functions depicted and described herein may be implemented in software and / or in a combination of software and hardware, eg, using a general purpose computer, one or more application specific integrated circuits (ASICs), and / or any other hardware equivalents. It should be noted that it can. In one embodiment, service location search process 1005 may be loaded into memory 1004 and executed by processor 1002 to implement the functions as discussed above. As such, the service location search process 1005 (including associated data structures) may be stored in a computer readable storage medium or carrier, such as a RAM memory, magnetic or optical drive or diskette, and the like.

Some of the functions discussed herein, implemented as software, are provided in any suitable manner (eg, provided during the manufacture of the nodes, administratively loaded into the node, downloaded from a web server or other suitable source, etc.). As well as its various combinations) may be configured on nodes of a peer-to-peer network. It is contemplated that some of the steps discussed herein as software methods may be implemented in hardware, such as, for example, circuitry that cooperates with the processor to execute various method steps. When some of the functions / elements described herein are processed by a computer, they may be implemented as a computer program product that adapts the operation of the computer such that the methods and / or techniques described herein are invoked or otherwise provided. Can be.

Aspects of the invention are specified in the claims. These and other aspects of the invention are specified in the following numbered clauses.

1. A method for discovering a service within a peer-to-peer (P2P) network comprising a plurality of nodes is:

Detecting, at a target node of the P2P network, a request to search for a service within the P2P2 network, the target node comprising a search table comprising a plurality of entries identifying each of the plurality of nodes of the P2P network; Including, the detecting step; And

Initiating a service search request towards at least one of the nodes identified in the search table, wherein the service search request is a request to identify at least one node of the P2P network supporting the service; The search request includes the initiating step, which includes information indicative of the service and a search range for use by the node from which the service search request is initiated.

2. In the method of clause 1, the service search request is initiated simultaneously towards all of the nodes of the search table.

3. The method of clause 1, wherein the service search request is selected in the search table until at least one node supporting the service is identified or a determination is made that none of the nodes in the P2P network support the service. It is initiated in sequence towards the nodes.

4. In the method of clause 3, a service search request is initiated towards the (i + 1) node of the search table in response to receiving a negative search response from the i th node of the search table.

5. In the method of clause 1, the service search request is initiated simultaneously towards the subset of the nodes of the search table, the subset of nodes in the search table including the nodes identified in the first K entries of the search table. .

6. The method of clause 5,

If a positive search response is received from at least one of the nodes of the subset of nodes of the search table, initiating a request for the service; And

If a positive search response is not received from at least one of the nodes of the subset of nodes of the search table:

Initiating a subsequent service search request to locate the service within the P2P network towards the next node associated with a next entry of the search table that is not in the subset of nodes of the search table.

7. The method of Clause 5 is:

Identifying a subset of the nodes of the lookup table using the estimated average number of nodes of the P2P network supporting the service.

8. In the method of clause 7, the subset of nodes in the lookup table is identified by solving for the L, by the equation ((L-1) * In (1-a) <In (1 / b), and (i) a is the probability that the node ID will have active nodes supporting the service, (ii) b is the probability that the search is negative, and (iii) L is the search range.

9. In the method of clause 7, the estimated average number of nodes of the P2P network supporting the service is determined from the node's local memory or from a web server.

10. The method of clause 7 wherein the estimated average number of nodes of the P2P network supporting the service are:

Initiating each service discovery request message configured to enable identification by each target node of the nodes of the P2P supporting the service towards each of the nodes of the discovery table; And

A node of the P2P network identified by the node as being nodes supporting the service or information adapted for use in deriving from each of the nodes of the search table the number of nodes of the P2P network supporting the service Receiving each service search response message comprising an indication of the number of times; And

Processing the service search response messages to calculate an estimated number of nodes of the P2P network supporting the service, wherein the estimated number of nodes of the P2P network supporting the service support the service. Estimated by the method comprising the processing step, adapted for use in determining the estimated average number of nodes of the P2P network.

11. The method of Clause 1 is:

Receive a search response from each of at least one of the nodes of the search table from which the service search request is initiated, indicating whether the node supports the service or has another identified node supporting the service. It further comprises the step of.

12. The method of clause 1 is:

When the target node receives a positive search response indicating that a node supporting the service is located, initiating a request for the service from the target node towards the node supporting the service. .

13. The method of clause 12, wherein the positive search response includes a node identifier of the node supporting the service and an IP address of the node supporting the service.

14. The method of clause 1, wherein the service is a cross-ring discovery service for identifying at least one other node of the P2P network that is a member of an additional P2P network.

15. The method of clause 14 is:

When the target node receives a positive search response indicating that a location of a node that is a member of an additional P2P network is found,

Initiating a process for the target node from the target node to connect to the additional P2P network; And

Initiating a request from the target node toward the node that is a member of the additional P2P network, for a node that is a member of the additional P2P network to initiate a search for an object within the additional P2P network. Further comprising executing at least one.

16. An apparatus for discovering a service within a peer-to-peer (P2P) network including a plurality of nodes:

A memory for storing a lookup table comprising a plurality of entries identifying each of a plurality of nodes of the P2P network; And

As a processor,

Detect a request to search for a service within the P2P network,

Initiating a service search request towards at least one of the nodes identified in the search table, wherein the service search request is a request to identify at least one node of the P2P network supporting the service; The request includes the processor, configured to initiate the service search request, including information indicating the service and a search range for use by the node from which the service search request is initiated.

17. A method for locating a service within a peer-to-peer (P2P) network including a plurality of nodes is:

Receiving, at a target node of the P2P network, a service search request, the service search request including information indicating the service requested and a search range for the target node;

Determining whether the target node supports the service using at least some of the information indicative of the requested service;

When a determination is made that the target node supports the service, initiating a service search response message from the target node indicating that the service is supported by the target node; And

When a determination is made that the target node does not support the service, determining whether to initiate a service search request from the target node toward at least one other node of the P2P network.

18. In the method of clause 17, when no determination is made to initiate a service search request from the target node towards at least one other node of the P2P network, the method further comprises:

Initiating a negative response message from the target node indicating that a node supporting the service cannot find a location by the target node using the search range.

19. In the method of clause 17, when the determination is made to initiate a service search request towards at least one other node of the P2P network, the method includes:

Determining a search range for a new service search request to be initiated by the target node, wherein the search range is the search range included in the service search request received at the target node and the search range stored on the target node. The determination step, determined using; And

Initiating a new service search request from the target node, wherein the new service search request further includes the initiating step, including information indicative of the requested service and the search range determined for the new service search request. do.

20. In the method of clause 17, determining whether to initiate a service search request towards at least one other node of the P2P network:

Determining whether any entries in the search table of the target node identify nodes that fall within the search range of the service search request received at the target node; And

If the entries in the search table of the target node do not identify nodes that belong to the search range of the service search request, determining that the target node does not need to initiate any service search requests; And

If at least one entry in the search table of the target node identifies at least one node belonging to a search range of the service search request, at least one of the search table of the target node belonging to the search range of the service search request from the target node Initiating at least one service search request towards each at least one node of the entry of the.

21. In the method of clause 17, when the determination is made to initiate a service search request towards at least one other node of the P2P network, the method includes:

Receiving a service search response associated with a service search request initiated by the target node towards another node of the P2P network;

If the service search response is not a valid response, ignoring the service search response and continuously waiting for at least one additional service search response;

If the service search response is a legitimate response, determining whether the service search response is a positive response or a negative response;

If the service search response is a positive response, initiating a positive service search response toward the node from which the service search request was received from the target node;

If the service search response is a negative response, determining whether all expected service search response messages have been received by the target node;

If all of the expected service search response messages have not been received by the target node, continuing to wait for at least one additional service search response; And

If all of the expected service search response messages have been received by the target node, further comprising initiating a negative service search response from the target node towards the node from which the service search request is received.

22. An apparatus for locating a service within a peer-to-peer (P2P) network including a plurality of nodes includes:

Means for receiving a service search request at a target node of the P2P network, the service search request comprising one or more criteria indicative of the service and a search range for the target node;

Means for determining whether the target node supports the service using at least some of the one or more service search criteria;

Means for initiating a service search response message from the target node indicating that the service is supported by the target node when a determination is made that the target node supports the service; And

Means for determining whether to initiate a service search request from the target node towards at least one other node of the P2P network when a determination is made that the target node does not support the service.

Although various embodiments, including the teachings of the present invention, are shown and described in detail herein, those skilled in the art can readily devise many other modified embodiments that continue to incorporate these teachings.

100: code network 110: a plurality of nodes
1000: computer 1002: processor element
1004: memory 1006: input / output devices
1005: service location navigation module / process

Claims (10)

A method for discovering a service within a peer-to-peer (P2P) network comprising a plurality of nodes, comprising:
Detecting, at a target node of the P2P network, a request to search for a service within the P2P network, the target node comprising a search table comprising a plurality of entries identifying each of a plurality of nodes of the P2P network; Including, the detecting step; And
Initiating a service search request towards at least one of the nodes identified in the search table, wherein the service search request is a request to identify at least one node of the P2P network supporting the service; The search request includes the initiating step, including information indicative of the service and a search range for use by the node from which the service search request is initiated. The method of claim 1,
And the service search request is initiated simultaneously towards all of the nodes of the search table. The method of claim 1,
The service search request is initiated continuously toward the nodes of the search table until at least one node supporting the service is identified or a determination is made that none of the nodes of the P2P network support the service, How to navigate the service. The method of claim 1,
Wherein the service search request is initiated simultaneously towards the subset of the nodes of the search table, wherein the subset of nodes of the search table includes the nodes identified in the first K entries of the search table. The method of claim 4, wherein
If a positive search response is received from at least one of the nodes of the subset of nodes of the search table, initiating a request for the service; And
If a positive search response is not received from at least one of the nodes of the subset of nodes of the search table:
Initiating a subsequent service search request for locating the service within the P2P network towards a next node associated with a next entry of the search table that is not in the subset of nodes of the search table. . The method of claim 4, wherein
And identifying a subset of the nodes in the lookup table using the estimated average number of nodes in the P2P network supporting the service. The method of claim 1,
Receiving from each of at least one of the nodes of the search table from which the service search request is initiated a search response indicating whether the node supports the service or has another identified node supporting the service. Including, service discovery method. The method of claim 1,
When the target node receives a positive search response indicating that a node supporting the service is located, initiating a request for the service from the target node towards the node supporting the service. How to navigate the service. An apparatus for discovering a service within a peer-to-peer (P2P) network comprising a plurality of nodes, comprising:
A memory for storing a lookup table comprising a plurality of entries identifying each of a plurality of nodes of the P2P network; And
As a processor,
Detect a request to search for a service within the P2P network,
The processor, configured to initiate a service search request towards at least one of the nodes identified in the search table,
The service search request is a request for identifying at least one node of the P2P network supporting the service, and the service search request is for use by information indicative of the service and by the node from which the service search request is initiated. A service navigation device comprising a search range. A method for locating a service in a peer-to-peer (P2P) network comprising a plurality of nodes, comprising:
Receiving, at a target node of the P2P network, a service search request, the service search request including information indicating the service requested and a search range for the target node;
Determining whether the target node supports the service using at least some of the information indicative of the requested service;
When a determination is made that the target node supports the service, initiating a service search response message from the target node indicating that the service is supported by the target node; And
When a determination is made that the target node does not support the service, determining whether to initiate a service search request from the target node toward at least one other node of the P2P network.

Images