US20060209819A1 - Method and apparatus for efficiently expanding a P2P network - Google Patents
Method and apparatus for efficiently expanding a P2P network Download PDFInfo
- Publication number
- US20060209819A1 US20060209819A1 US11/084,971 US8497105A US2006209819A1 US 20060209819 A1 US20060209819 A1 US 20060209819A1 US 8497105 A US8497105 A US 8497105A US 2006209819 A1 US2006209819 A1 US 2006209819A1
- Authority
- US
- United States
- Prior art keywords
- node
- response message
- data
- network
- search request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
- H04L67/1068—Discovery involving direct consultation or announcement among potential requesting and potential source peers
- H04L67/107—Discovery involving direct consultation or announcement among potential requesting and potential source peers with limitation or expansion of the discovery scope
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
Definitions
- the present invention relates generally to computing networks and relates more particularly to the expansion of peer-to-peer data transfer networks.
- FIG. 1 is a schematic diagram of a network 100 of nodes (e.g., computing devices) interacting in a peer-to-peer (P2P) manner.
- a requesting node 101 sends a search message 105 (e.g., containing keywords relating to data that the requesting node 101 wishes to locate) to at least one intermediate node 111 in communication with the requesting node 101 via a peer connection.
- the intermediate node 111 receives the search message 105 and forwards the search message 105 to at least one additional node 111 .
- the search message 105 reaches at least one responding node 103 having the requested data (in some cases, the first intermediate node 111 to which the search message 105 is forwarded will also be a responding node 103 ). At least one responding node 103 then sends a response message 107 back to the requesting node 101 , e.g., via the intermediate nodes 111 .
- the requesting node 101 requests the relevant data from a responding node 103 by connecting directly to the responding node 103 , e.g., via direct connection 109 .
- messages including the search message 105 and the response message 107 have a limited time to live or hop count. That is, a message will expire once it has been forwarded to a predefined maximum number of nodes 101 , 103 or 111 .
- the requesting node 101 generates a second search message having a time to live of four, and a node at which the requested data resides (e.g., node 113 ) is more than four “hops” away from the requesting node 101 , the second search message will expire before the requested data is obtained.
- This problem can be reduced by increasing the search message's time to live or by increasing a number of peer connections per node; however, either will cause an increase in network traffic (the former increase being exponential due to the fan out nature of the network 100 ).
- One embodiment of the present method and apparatus for efficiently expanding a P2P network includes receiving a search request message from a requesting node and sending a response message to the requesting node on behalf of a node that has the requested data, where the response message originates at an intermediate node.
- the intermediate node may respond on behalf of the “responding” node, for example, in cases where the responding node is too far away from the requesting node to receive the search request message.
- FIG. 1 is a schematic diagram of a network of nodes interacting in a peer-to-peer manner
- FIG. 2 is a flow diagram illustrating one embodiment of a method for efficiently expanding a P2P network, such as the network illustrated in FIG. 1 ;
- FIG. 3 is a high level block diagram of the network expansion method that is implemented using a general purpose computing device.
- the present invention is a method and apparatus for efficiently expanding a P2P network.
- Embodiments of the present invention make it possible for a requesting node on a P2P network to receive data from nodes that would normally be outside of the requesting node's “range” by enabling intermediate nodes to respond “by proxy” for the out-of-range nodes.
- FIG. 2 is a flow diagram illustrating one embodiment of a method 200 for efficiently expanding a P2P network, such as the network 100 illustrated in FIG. 1 .
- the method 200 may be implemented at, for example, any node (e.g., 101 , 103 , 111 or 113 ) on the P2P network 100 .
- the method 200 is initialized at step 202 and proceeds to step 204 , where the method 200 receives a search request message, e.g., from a peer (connected) node.
- the method 200 then proceeds to step 206 , where the method 200 examines the search request message and determines whether the receiver (e.g., the node at which the search request message was received in step 204 ) has the requested data. If the receiver has the requested data, the method 200 proceeds to step 208 and sends a response message over the network 100 back to the requesting node, e.g., in accordance with conventional P2P protocols. The method then proceeds to step 212 and checks a local database for other data potentially matching the search request message, as described in further detail below.
- the receiver e.g., the node at which the search request message was received in step 204
- the method 200 proceeds to step 208 and sends a response message over the network 100 back to the requesting node, e.g., in accordance with conventional P2P protocols.
- the method then proceeds to step 212 and checks a local database for other data potentially matching the search request message, as described in further detail below.
- step 212 checks a local database residing at the receiver.
- the database that is checked in step 212 comprises at least one entry containing information about a previous data transfer executed on the network 100 (e.g., in which data was transferred from a responding node to a requesting node).
- this information includes at least one of a transferred data name, a description of the contents of the transferred data, the size of the transferred data, the type of data (e.g., an image file, and audio file, etc.), the time of the data transfer, a source of the transferred data (e.g., the network ID, address, port number or other form of identification for the responding node for the transfer), a number of hops separating the receiver from the responding node, or other meta data related to the response message sent prior to the actual transfer of data.
- a transferred data name e.g., a description of the contents of the transferred data, the size of the transferred data, the type of data (e.g., an image file, and audio file, etc.), the time of the data transfer, a source of the transferred data (e.g., the network ID, address, port number or other form of identification for the responding node for the transfer), a number of hops separating the receiver from the responding node, or other meta data related to the response message sent prior to the actual transfer of
- the receiver saves the information about the previous data transfers from incoming response messages sent prior to the actual transfers of data.
- the receiver saves as much information from the response messages as is necessary to reconstruct the response messages as proxy responses, as described in further detail below.
- all data contained in the response messages is saved.
- the information saved in the database for a particular previous data transfer could be the entire response message corresponding to the data transfer.
- the method 200 determines whether there is an entry (e.g., a response message) in the database that matches or corresponds to the data requested in the search request message. Specifically, the method 200 determines whether the database includes an entry that indicates at least one node in the network 100 that has the requested data (e.g., the node may have responded to a previous request for the same data that is presently being requested). If no such database entry exists, the method 200 proceeds to step 218 and either forwards the search request message to the next node (e.g., if the search request message's time to live field has not yet expired), or discards the search request message (e.g., if the time to live field expired upon transmission to the receiver in step 204 ).
- the next node e.g., if the search request message's time to live field has not yet expired
- discards the search request message e.g., if the time to live field expired upon transmission to the receiver in step 204 ).
- the method 200 determines in step 212 that the database does contain an entry that corresponds to the data requested in the search request message, the method 200 proceeds to step 214 and further determines whether the search request message will reach the source of the corresponding database entry (e.g., the node that presumably has the requested data).
- the method 200 examines the search request message's time to live field (which specifies how many more hops the search request message can make) or hop count field (which specifies how many hops have been made so far) and determines how far into the network the search request message will travel (e.g., what is the furthest node that the search request message will reach?).
- the method 200 assumes that the search request message will not reach the source of the corresponding database entry.
- step 214 If the method 200 determines in step 214 that the search request message will not reach the source of the corresponding database entry, the method 200 proceeds to step 220 and responds on behalf of the source of the corresponding database entry, e.g., as a proxy. In one embodiment, the method 200 responds on behalf of the source of the corresponding database entry by sending a response message from the receiver to the requesting node. The response message indicates that the source of the corresponding database entry has the data for which the requesting node is searching.
- the method 200 may do one of two things. In one embodiment, the method 200 simply forwards the search request message to the next node, e.g., in accordance with conventional P2P protocols.
- the method 200 may, in step 216 , respond to the search request message on behalf of the source of the corresponding database entry even though the search request message will likely still reach source of the corresponding database entry.
- the method 200 may also discard the search request message (i.e., not forward the search request message further through the network) once the method 200 has responded to the requesting node.
- Responding on behalf of the source of the corresponding database entry in this case may be desirable to achieve faster responses to search request messages (e.g., a response is generated at an earlier node in the transmission path) or to reduce network traffic (e.g., by preventing the search request message from traveling further in the network once the source of the corresponding database entry has been identified).
- These benefits may be especially desirable in cases where a single, finite response is all that is needed to respond to a request for data (e.g., such as a query for a stock price).
- the method 200 terminates in step 222 .
- the method 200 may actually execute in its entirety at the requesting node. That is, if the requesting node maintains its own database of previous response messages, the requesting node may, in fact, be able to identify a node that has the requested data simply by searching its own database in accordance with steps 210 - 222 .
- the method 200 as described above enables efficient expansion of P2P networks while only minimally increasing network traffic.
- the search space for a data request is effectively increased without actually sending the data request to additional nodes.
- the method 200 actually conserves traffic while at the same time “expanding” the network.
- a node's database for storing information related to previous data transfers may be built according to a variety of criteria. For example, in one embodiment, a node may automatically save information every time a response message is received. In other embodiment, parameters such as available memory or storage, network bandwidth speed, network bandwidth utilization or a length of time for which the responding node has been active in the network may dictate whether a corresponding entry will be saved in the database. In further embodiments, the node may compare the received response message to existing database entries and create an entry for the received response message only if an entry does not already exist for the data to which the response message relates. Alternatively, if a database entry already exists for the relevant data, the received response message may be used to update information for the data (e.g., by creating a list of nodes that have the data or file).
- a database may be maintained based on a variety of criteria.
- a node may specify that database entries will be kept according to a sliding time window (e.g., where information relating to only a fixed number of the most recent search responses is saved), a fixed number of the most or least popular data searches, or a length of time in which a responding node has been active in the network (e.g., a node may keep a subset of search response information for a number of responding nodes that have been active for the longest period of time).
- a node may periodically query other nodes whose response messages have been entered in the database, e.g., to ensure that the nodes still have the relevant data.
- a responding node can assist in the management of database entries by adding a field to the response message that indicates for how long the search results will be valid (e.g., “This section of the live video stream will only be available for one day.”), or that indicates for how long the responding node has been active in the network.
- a requesting node may specify that it does not wish to receive proxy responses on behalf of out-of-range nodes (e.g., by stating so in the search request message). For example, the requesting node may expect to have its search satisfied by a nearby node (e.g., within a certain range). Alternatively, a requesting node may specify a hop count past which proxy responses are allowed (e.g., “No proxy responses until the n th hop.”), so that the closest peer nodes do not send proxy responses. Furthermore, the requesting node may set an age limit for proxy responses (e.g., “No proxy responses referring to database entries that are older than n days.”), in order to ensure the validity of proxy responses.
- an age limit for proxy responses e.g., “No proxy responses referring to database entries that are older than n days.”
- a responding node may specify that it does not wish to have information concerning its response message saved (e.g., by stating so in the response message). For example, the responding node may want to limit its communication to only nearby nodes. Alternatively, the responding node may specify given points along the response message path at which information concerning the response message can be saved (e.g., “No saving past the n th hop.”), so that the only nodes within a certain range can save information concerning the response message.
- FIG. 3 is a high level block diagram of the network expansion method that is implemented using a general purpose computing device 300 .
- a general purpose computing device 300 comprises a processor 302 , a memory 304 , a data transfer module 305 and various input/output (I/O) devices 306 such as a display, a keyboard, a mouse, a modem, and the like.
- I/O devices 306 such as a display, a keyboard, a mouse, a modem, and the like.
- at least one I/O device is a storage device (e.g., a disk drive, an optical disk drive, a floppy disk drive).
- the data transfer module 305 can be implemented as a physical device or subsystem that is coupled to a processor through a communication channel.
- the data transfer module 305 can be represented by one or more software applications (or even a combination of software and hardware, e.g., using Application Specific Integrated Circuits (ASIC)), where the software is loaded from a storage medium (e.g., I/O devices 306 ) and operated by the processor 302 in the memory 304 of the general purpose computing device 300 .
- ASIC Application Specific Integrated Circuits
- the data transfer module 305 for efficiently expanding a P2P network described herein with reference to the preceding Figures can be stored on a computer readable medium or carrier (e.g., RAM, magnetic or optical drive or diskette, and the like).
- the present invention represents a significant advancement in the field of data transfer networks.
- a method and apparatus are provided that make it possible for a requesting node on a P2P network to receive data from nodes that would normally be outside of the requesting node's range by enabling intermediate nodes to respond by proxy for the out-of-range nodes.
- the method and apparatus of the present invention actually conserve network traffic while effectively expanding the search space for data requests.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
One embodiment of the present method and apparatus for efficiently expanding a P2P network includes receiving a search request message from a requesting node and sending a response message to the requesting node on behalf of a node that has the requested data, where the response message originates at an intermediate node. The intermediate node may respond on behalf of the “responding” node, for example, in cases where the responding node is too far away from the requesting node to receive the search request message.
Description
- The present invention relates generally to computing networks and relates more particularly to the expansion of peer-to-peer data transfer networks.
-
FIG. 1 is a schematic diagram of anetwork 100 of nodes (e.g., computing devices) interacting in a peer-to-peer (P2P) manner. Generally, a requestingnode 101 sends a search message 105 (e.g., containing keywords relating to data that the requestingnode 101 wishes to locate) to at least oneintermediate node 111 in communication with the requestingnode 101 via a peer connection. Theintermediate node 111 receives thesearch message 105 and forwards thesearch message 105 to at least oneadditional node 111. Eventually, thesearch message 105 reaches at least one respondingnode 103 having the requested data (in some cases, the firstintermediate node 111 to which thesearch message 105 is forwarded will also be a responding node 103). At least one respondingnode 103 then sends aresponse message 107 back to the requestingnode 101, e.g., via theintermediate nodes 111. The requestingnode 101 then requests the relevant data from a respondingnode 103 by connecting directly to the respondingnode 103, e.g., viadirect connection 109. - In conventional P2P systems, messages including the
search message 105 and theresponse message 107 have a limited time to live or hop count. That is, a message will expire once it has been forwarded to a predefined maximum number ofnodes node 101 generates a second search message having a time to live of four, and a node at which the requested data resides (e.g., node 113) is more than four “hops” away from the requestingnode 101, the second search message will expire before the requested data is obtained. This problem can be reduced by increasing the search message's time to live or by increasing a number of peer connections per node; however, either will cause an increase in network traffic (the former increase being exponential due to the fan out nature of the network 100). - Thus, there is a need in the art for a method and apparatus for efficiently expanding a P2P network.
- One embodiment of the present method and apparatus for efficiently expanding a P2P network includes receiving a search request message from a requesting node and sending a response message to the requesting node on behalf of a node that has the requested data, where the response message originates at an intermediate node. The intermediate node may respond on behalf of the “responding” node, for example, in cases where the responding node is too far away from the requesting node to receive the search request message.
- So that the manner in which the above recited embodiments of the invention are attained and can be understood in detail, a more particular description of the invention, briefly summarized above, may be obtained by reference to the embodiments thereof which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
-
FIG. 1 is a schematic diagram of a network of nodes interacting in a peer-to-peer manner; -
FIG. 2 is a flow diagram illustrating one embodiment of a method for efficiently expanding a P2P network, such as the network illustrated inFIG. 1 ; and -
FIG. 3 is a high level block diagram of the network expansion method that is implemented using a general purpose computing device. - To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.
- In one embodiment, the present invention is a method and apparatus for efficiently expanding a P2P network. Embodiments of the present invention make it possible for a requesting node on a P2P network to receive data from nodes that would normally be outside of the requesting node's “range” by enabling intermediate nodes to respond “by proxy” for the out-of-range nodes.
-
FIG. 2 is a flow diagram illustrating one embodiment of a method 200 for efficiently expanding a P2P network, such as thenetwork 100 illustrated inFIG. 1 . The method 200 may be implemented at, for example, any node (e.g., 101, 103, 111 or 113) on theP2P network 100. The method 200 is initialized atstep 202 and proceeds tostep 204, where the method 200 receives a search request message, e.g., from a peer (connected) node. - The method 200 then proceeds to
step 206, where the method 200 examines the search request message and determines whether the receiver (e.g., the node at which the search request message was received in step 204) has the requested data. If the receiver has the requested data, the method 200 proceeds to step 208 and sends a response message over thenetwork 100 back to the requesting node, e.g., in accordance with conventional P2P protocols. The method then proceeds to step 212 and checks a local database for other data potentially matching the search request message, as described in further detail below. - Alternatively, if the method 200 determines in
step 206 that the receiver does not have the requested data, the method 200 proceeds directly tostep 212 and checks a local database residing at the receiver. The database that is checked instep 212 comprises at least one entry containing information about a previous data transfer executed on the network 100 (e.g., in which data was transferred from a responding node to a requesting node). In one embodiment, this information includes at least one of a transferred data name, a description of the contents of the transferred data, the size of the transferred data, the type of data (e.g., an image file, and audio file, etc.), the time of the data transfer, a source of the transferred data (e.g., the network ID, address, port number or other form of identification for the responding node for the transfer), a number of hops separating the receiver from the responding node, or other meta data related to the response message sent prior to the actual transfer of data. - In one embodiment, the receiver saves the information about the previous data transfers from incoming response messages sent prior to the actual transfers of data. In particular, the receiver saves as much information from the response messages as is necessary to reconstruct the response messages as proxy responses, as described in further detail below. In some embodiments, all data contained in the response messages is saved. In this embodiment, the information saved in the database for a particular previous data transfer could be the entire response message corresponding to the data transfer.
- In particular, in
step 212, the method 200 determines whether there is an entry (e.g., a response message) in the database that matches or corresponds to the data requested in the search request message. Specifically, the method 200 determines whether the database includes an entry that indicates at least one node in thenetwork 100 that has the requested data (e.g., the node may have responded to a previous request for the same data that is presently being requested). If no such database entry exists, the method 200 proceeds tostep 218 and either forwards the search request message to the next node (e.g., if the search request message's time to live field has not yet expired), or discards the search request message (e.g., if the time to live field expired upon transmission to the receiver in step 204). - Alternatively, if the method 200 determines in
step 212 that the database does contain an entry that corresponds to the data requested in the search request message, the method 200 proceeds tostep 214 and further determines whether the search request message will reach the source of the corresponding database entry (e.g., the node that presumably has the requested data). In one embodiment, the method 200 examines the search request message's time to live field (which specifies how many more hops the search request message can make) or hop count field (which specifies how many hops have been made so far) and determines how far into the network the search request message will travel (e.g., what is the furthest node that the search request message will reach?). Thus, if the search request message can make x more hops, and if the source of the corresponding database entry is at least x+1 more hops from the receiver, the method 200 assumes that the search request message will not reach the source of the corresponding database entry. - If the method 200 determines in
step 214 that the search request message will not reach the source of the corresponding database entry, the method 200 proceeds tostep 220 and responds on behalf of the source of the corresponding database entry, e.g., as a proxy. In one embodiment, the method 200 responds on behalf of the source of the corresponding database entry by sending a response message from the receiver to the requesting node. The response message indicates that the source of the corresponding database entry has the data for which the requesting node is searching. - Alternatively, if the method 200 determines in
step 214 that the search request message will reach the source of the corresponding database entry, the method 200 may do one of two things. In one embodiment, the method 200 simply forwards the search request message to the next node, e.g., in accordance with conventional P2P protocols. - In another embodiment, the method 200 may, in
step 216, respond to the search request message on behalf of the source of the corresponding database entry even though the search request message will likely still reach source of the corresponding database entry. In this case, the method 200 may also discard the search request message (i.e., not forward the search request message further through the network) once the method 200 has responded to the requesting node. Responding on behalf of the source of the corresponding database entry in this case may be desirable to achieve faster responses to search request messages (e.g., a response is generated at an earlier node in the transmission path) or to reduce network traffic (e.g., by preventing the search request message from traveling further in the network once the source of the corresponding database entry has been identified). These benefits may be especially desirable in cases where a single, finite response is all that is needed to respond to a request for data (e.g., such as a query for a stock price). - The method 200 terminates in
step 222. Those skilled in the art will appreciate that in some embodiments, the method 200 may actually execute in its entirety at the requesting node. That is, if the requesting node maintains its own database of previous response messages, the requesting node may, in fact, be able to identify a node that has the requested data simply by searching its own database in accordance with steps 210-222. - The method 200 as described above enables efficient expansion of P2P networks while only minimally increasing network traffic. By enabling one or more nodes in a P2P network to respond “by proxy” for other nodes in the network, the search space for a data request is effectively increased without actually sending the data request to additional nodes. Thus, unlike conventional P2P expansion methods that tend to result in a sometimes exponential increase in network traffic (e.g., by increasing either a search request message's time to live or a node's number of peer connections), the method 200 actually conserves traffic while at the same time “expanding” the network.
- Those skilled in the art will appreciate that a node's database for storing information related to previous data transfers may be built according to a variety of criteria. For example, in one embodiment, a node may automatically save information every time a response message is received. In other embodiment, parameters such as available memory or storage, network bandwidth speed, network bandwidth utilization or a length of time for which the responding node has been active in the network may dictate whether a corresponding entry will be saved in the database. In further embodiments, the node may compare the received response message to existing database entries and create an entry for the received response message only if an entry does not already exist for the data to which the response message relates. Alternatively, if a database entry already exists for the relevant data, the received response message may be used to update information for the data (e.g., by creating a list of nodes that have the data or file).
- Moreover, a database may be maintained based on a variety of criteria. For example, a node may specify that database entries will be kept according to a sliding time window (e.g., where information relating to only a fixed number of the most recent search responses is saved), a fixed number of the most or least popular data searches, or a length of time in which a responding node has been active in the network (e.g., a node may keep a subset of search response information for a number of responding nodes that have been active for the longest period of time).
- In order to ensure the continued validity of database entries, a node may periodically query other nodes whose response messages have been entered in the database, e.g., to ensure that the nodes still have the relevant data. Alternatively, a responding node can assist in the management of database entries by adding a field to the response message that indicates for how long the search results will be valid (e.g., “This section of the live video stream will only be available for one day.”), or that indicates for how long the responding node has been active in the network.
- In some embodiments, a requesting node may specify that it does not wish to receive proxy responses on behalf of out-of-range nodes (e.g., by stating so in the search request message). For example, the requesting node may expect to have its search satisfied by a nearby node (e.g., within a certain range). Alternatively, a requesting node may specify a hop count past which proxy responses are allowed (e.g., “No proxy responses until the nth hop.”), so that the closest peer nodes do not send proxy responses. Furthermore, the requesting node may set an age limit for proxy responses (e.g., “No proxy responses referring to database entries that are older than n days.”), in order to ensure the validity of proxy responses.
- Conversely, a responding node may specify that it does not wish to have information concerning its response message saved (e.g., by stating so in the response message). For example, the responding node may want to limit its communication to only nearby nodes. Alternatively, the responding node may specify given points along the response message path at which information concerning the response message can be saved (e.g., “No saving past the nth hop.”), so that the only nodes within a certain range can save information concerning the response message.
-
FIG. 3 is a high level block diagram of the network expansion method that is implemented using a generalpurpose computing device 300. In one embodiment, a generalpurpose computing device 300 comprises aprocessor 302, amemory 304, adata transfer module 305 and various input/output (I/O)devices 306 such as a display, a keyboard, a mouse, a modem, and the like. In one embodiment, at least one I/O device is a storage device (e.g., a disk drive, an optical disk drive, a floppy disk drive). It should be understood that thedata transfer module 305 can be implemented as a physical device or subsystem that is coupled to a processor through a communication channel. - Alternatively, the
data transfer module 305 can be represented by one or more software applications (or even a combination of software and hardware, e.g., using Application Specific Integrated Circuits (ASIC)), where the software is loaded from a storage medium (e.g., I/O devices 306) and operated by theprocessor 302 in thememory 304 of the generalpurpose computing device 300. Thus, in one embodiment, thedata transfer module 305 for efficiently expanding a P2P network described herein with reference to the preceding Figures can be stored on a computer readable medium or carrier (e.g., RAM, magnetic or optical drive or diskette, and the like). - Thus, the present invention represents a significant advancement in the field of data transfer networks. A method and apparatus are provided that make it possible for a requesting node on a P2P network to receive data from nodes that would normally be outside of the requesting node's range by enabling intermediate nodes to respond by proxy for the out-of-range nodes. Moreover, unlike conventional methods for expanding P2P networks, the method and apparatus of the present invention actually conserve network traffic while effectively expanding the search space for data requests.
- While foregoing is directed to the preferred embodiment of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.
Claims (29)
1. A method for transferring data from a first node to a second node in a network, said method comprising the steps of:
receiving a search request message from said second node, said search request message requesting data; and
sending by a third node a response message to said second node on behalf of said first node, said response message indicating that said first node has the requested data.
2. The method of claim 1 , wherein said third node is an intermediate node located between said first node and second node.
3. The method of claim 1 , wherein said third node sends said response message on behalf of said first node if said third node determines that said search request message will not reach said first node.
4. The method of claim 3 , further comprising the step of:
examining a time to live field or a hop count field of said search request message to determine how far in said network said search request message will travel.
5. The method of claim 1 , wherein said sending step comprises:
locating information related to said requested data in a database associated with said third node, where said database includes at least one entry related to at least one previous data transfer executed on said network; and
sending said response message to said second node in accordance with said located information.
6. The method of claim 5 , wherein a time period for keeping said at least one entry in said database is dictated by at least one of: a fixed number of most recent data transfers, a fixed number of most popular responses, a fixed number of least popular data responses, and a length of time for which a transferring node has been active in said network.
7. The method of claim 5 , further comprising:
periodically querying at least one source of said requested data to confirm a validity of said at least one entry.
8. The method of claim 5 , wherein said at least one entry comprises information taken from at least one response message previously received by said third node in connection with said at least one previous data transfer.
9. The method of claim 8 , where said at least one entry comprises information taken from at least one response message previously sent by said first node in connection with said at least one previous data transfer.
10. The method of claim 8 , wherein said information comprises at least one of: a name of data transferred in said at least one previous data transfer, a description of content of data transferred in said at least one previous data transfer, a size of data transferred in said at least one previous data transfer, a type of data transferred in said at least one previous data transfer, a time of said at least one previous data transfer, a number of hops separating said third node from said first node, meta data related to said at least one response message, a source of data transferred in said at least one previous data transfer, and said at least one response message itself.
11. The method of claim 8 , wherein said information is automatically saved in said database for every response message received by said third node.
12. The method of claim 8 , wherein said information is saved based on at least one of: available database memory, available database storage, network bandwidth speed, network bandwidth utilization and a length of time for which a source of said at least one response message has been active on said network.
13. The method of claim 8 , wherein said at least one response message indicates a length of time for which data contained therein will be valid.
14. The method of claim 1 , wherein said method is executed at said second node.
15. A computer readable medium containing an executable program for transferring data from a first node to a second node in a network, where the program performs the steps of:
receiving a search request message from said second node, said search request message requesting data; and
sending by a third node a response message to said second node on behalf of said first node, said response message indicating that said first node has the requested data.
16. The computer readable medium of claim 15 , wherein said third node is an intermediate node located between said first node and second node.
17. The computer readable medium of claim 15 , wherein said third node sends said response message on behalf of said first node if said third node determines that said search request message will not reach said first node.
18. The computer readable medium of claim 17 , further comprising the step of:
examining a time to live field or a hop count field of said search request message to determine how far in said network said search request message will travel.
19. The computer readable medium of claim 15 , wherein said sending step comprises:
locating information related to said requested data in a database associated with said third node, where said database includes at least one entry related to at least one previous data transfer executed on said network; and
sending said response message to said second node in accordance with said located information.
20. The computer readable medium of claim 19 , wherein a time period for keeping said at least one entry in said database is dictated by at least one of: a fixed number of most recent data transfers, a fixed number of most popular responses, a fixed number of least popular data responses, and a length of time for which a transferring node has been active in said network.
21. The computer readable medium of claim 19 , further comprising:
periodically querying at least one source of said requested data to confirm a validity of said at least one entry.
22. The computer readable medium of claim 19 , wherein said at least one entry comprises information taken from at least one response message previously received by said third node in connection with said at least one previous data transfer.
23. The computer readable medium of claim 22 , where said at least one entry comprises information taken from at least one response message previously sent by said first node in connection with said at least one previous data transfer.
24. The computer readable medium of claim 22 , wherein said information comprises at least one of: a name of data transferred in said at least one previous data transfer, a description of content of data transferred in said at least one previous data transfer, a size of data transferred in said at least one previous data transfer, a type of data transferred in said at least one previous data transfer, a time of said at least one previous data transfer, a number of hops separating said third node from said first node, meta data related to said at least one response message, a source of data transferred in said at least one previous data transfer, and said at least one response message itself.
25. The computer readable medium of claim 22 , wherein said information is automatically saved in said database for every response message received by said third node.
26. The computer readable medium of claim 22 , wherein said information is saved based on at least one of: available database memory, available database storage, network bandwidth speed, network bandwidth utilization and a length of time for which a source of said at least one response message has been active on said network.
27. The computer readable medium of claim 22 , wherein said at least one response message indicates a length of time for which data contained therein will be valid.
28. The computer readable medium of claim 15 , wherein said program is executed at said second node.
29. Apparatus comprising:
means for receiving a search request message from said second node, said search request message requesting data; and
means for sending a response message to said second node on behalf of said first node, said response message indicating that said first node has the requested data and originating at a third node on the network.
Priority Applications (9)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/084,971 US20060209819A1 (en) | 2005-03-21 | 2005-03-21 | Method and apparatus for efficiently expanding a P2P network |
CA002602483A CA2602483A1 (en) | 2005-03-21 | 2006-03-09 | Method and apparatus for efficiently expanding a p2p network |
JP2008502375A JP4755683B2 (en) | 2005-03-21 | 2006-03-09 | Method, apparatus, and program for efficiently extending a peer-to-peer (P2P) network |
AT06725006T ATE547889T1 (en) | 2005-03-21 | 2006-03-09 | METHOD AND DEVICE FOR EFFICIENTLY EXPANDING A P2P NETWORK |
PCT/EP2006/060605 WO2006100185A1 (en) | 2005-03-21 | 2006-03-09 | Method and apparatus for efficiently expanding a p2p network |
CN2006800089733A CN101147380B (en) | 2005-03-21 | 2006-03-09 | Method and apparatus for efficient expansion of P2P networks |
EP06725006A EP1867137B1 (en) | 2005-03-21 | 2006-03-09 | Method and apparatus for efficiently expanding a p2p network |
TW095109247A TWI392285B (en) | 2005-03-21 | 2006-03-17 | Method and apparatus for efficiently expanding a p2p network |
US12/164,979 US8788573B2 (en) | 2005-03-21 | 2008-06-30 | Method and apparatus for efficiently expanding a P2P network |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/084,971 US20060209819A1 (en) | 2005-03-21 | 2005-03-21 | Method and apparatus for efficiently expanding a P2P network |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/164,979 Continuation US8788573B2 (en) | 2005-03-21 | 2008-06-30 | Method and apparatus for efficiently expanding a P2P network |
Publications (1)
Publication Number | Publication Date |
---|---|
US20060209819A1 true US20060209819A1 (en) | 2006-09-21 |
Family
ID=36609477
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/084,971 Abandoned US20060209819A1 (en) | 2005-03-21 | 2005-03-21 | Method and apparatus for efficiently expanding a P2P network |
US12/164,979 Expired - Fee Related US8788573B2 (en) | 2005-03-21 | 2008-06-30 | Method and apparatus for efficiently expanding a P2P network |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/164,979 Expired - Fee Related US8788573B2 (en) | 2005-03-21 | 2008-06-30 | Method and apparatus for efficiently expanding a P2P network |
Country Status (8)
Country | Link |
---|---|
US (2) | US20060209819A1 (en) |
EP (1) | EP1867137B1 (en) |
JP (1) | JP4755683B2 (en) |
CN (1) | CN101147380B (en) |
AT (1) | ATE547889T1 (en) |
CA (1) | CA2602483A1 (en) |
TW (1) | TWI392285B (en) |
WO (1) | WO2006100185A1 (en) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050163133A1 (en) * | 2004-01-23 | 2005-07-28 | Hopkins Samuel P. | Method for optimally utilizing a peer to peer network |
WO2007031981A3 (en) * | 2005-09-15 | 2007-09-13 | One Fone Ltd | Incorporating a mobile device into a peer-to-peer network |
WO2008057509A2 (en) | 2006-11-07 | 2008-05-15 | Tiversa, Inc. | System and method for enhanced experience with a peer to peer network |
WO2009000181A1 (en) * | 2007-06-27 | 2008-12-31 | Huawei Technologies Co., Ltd. | Method for acquiring traversal resource, peer to peer node and peer to peer system |
WO2008004207A3 (en) * | 2006-07-07 | 2009-05-07 | Fringland Ltd | Identifying network entities in a peer-to-peer network |
JP2009524293A (en) * | 2006-01-13 | 2009-06-25 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Method and apparatus for establishing peer-to-peer karma and trust |
US20100002694A1 (en) * | 2007-03-16 | 2010-01-07 | Fujitsu Limited | Route data collection technique in network |
US8156175B2 (en) | 2004-01-23 | 2012-04-10 | Tiversa Inc. | System and method for searching for specific types of people or information on a peer-to-peer network |
US8909664B2 (en) | 2007-04-12 | 2014-12-09 | Tiversa Ip, Inc. | System and method for creating a list of shared information on a peer-to-peer network |
US9922330B2 (en) | 2007-04-12 | 2018-03-20 | Kroll Information Assurance, Llc | System and method for advertising on a peer-to-peer network |
CN111046065A (en) * | 2019-10-28 | 2020-04-21 | 北京大学 | Extensible high-performance distributed query processing method and device |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5272731B2 (en) * | 2006-11-09 | 2013-08-28 | 日本電気株式会社 | P2P data distribution system, P2P data distribution method, and P2P data distribution program |
US20090323555A1 (en) * | 2008-06-27 | 2009-12-31 | Affinegy, Inc. | System and Method for Controlling and Configuring a Router |
US9129263B2 (en) * | 2009-12-01 | 2015-09-08 | Yahoo! Inc. | System and method for automatically building up topic-specific messaging identities |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5115433A (en) * | 1989-07-18 | 1992-05-19 | Metricom, Inc. | Method and system for routing packets in a packet communication network |
US6205481B1 (en) * | 1998-03-17 | 2001-03-20 | Infolibria, Inc. | Protocol for distributing fresh content among networked cache servers |
US20030041141A1 (en) * | 2001-01-22 | 2003-02-27 | Abdelaziz Mohamed M. | Peer-to-peer presence detection |
US20040246975A1 (en) * | 2003-06-06 | 2004-12-09 | Meshnetworks, Inc. | System and method to improve the overall performance of a wireless communication network |
US20050021725A1 (en) * | 2003-06-30 | 2005-01-27 | Johannes Lobbert | Distance-aware service discovery mechanism for determining the availability of remote services in wireless personal area networks |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5222242A (en) * | 1990-09-28 | 1993-06-22 | International Business Machines Corp. | System for locating a node containing a requested resource and for selectively verifying the presence of the resource at the node |
US7327683B2 (en) * | 2000-03-16 | 2008-02-05 | Sri International | Method and apparatus for disseminating topology information and for discovering new neighboring nodes |
WO2002057917A2 (en) * | 2001-01-22 | 2002-07-25 | Sun Microsystems, Inc. | Peer-to-peer network computing platform |
US20020150099A1 (en) * | 2001-04-13 | 2002-10-17 | Pung Hung Keng | Multicast routing method satisfying quality of service constraints, software and devices |
JP3602070B2 (en) * | 2001-06-05 | 2004-12-15 | エヌイーシーコンピュータテクノ株式会社 | MPOA system, shortcut communication control method thereof, and shortcut communication control program |
US20030009586A1 (en) * | 2001-07-06 | 2003-01-09 | Intel Corporation | Method and apparatus for peer-to-peer services |
US7054867B2 (en) * | 2001-09-18 | 2006-05-30 | Skyris Networks, Inc. | Systems, methods and programming for routing and indexing globally addressable objects and associated business models |
US20030114787A1 (en) * | 2001-12-13 | 2003-06-19 | Victor Gura | Wearable peritoneal dialysis system |
US7571251B2 (en) * | 2002-05-06 | 2009-08-04 | Sandvine Incorporated Ulc | Path optimizer for peer to peer networks |
JP2004021770A (en) * | 2002-06-19 | 2004-01-22 | Ariel Networks Co Ltd | Network system and program |
JP3890061B2 (en) * | 2002-07-31 | 2007-03-07 | ケイティーフリーテル カンパニー リミテッド | Method and apparatus for explicit multicast receiveability and reachability testing |
US8090798B2 (en) * | 2002-08-12 | 2012-01-03 | Morganstein | System and methods for direct targeted media advertising over peer-to-peer networks |
US7263560B2 (en) * | 2002-08-30 | 2007-08-28 | Sun Microsystems, Inc. | Decentralized peer-to-peer advertisement |
US7822810B2 (en) * | 2002-09-17 | 2010-10-26 | Hewlett-Packard Development Company, L.P. | Method and system for peer to peer common channel collaboration |
JP2004246522A (en) * | 2003-02-13 | 2004-09-02 | Hitachi Ltd | Distributed community system and distributed community terminal |
JP3835410B2 (en) | 2003-02-13 | 2006-10-18 | 日本電気株式会社 | Computer system, memory allocation guarantee value dynamic changing method and program |
US8095500B2 (en) * | 2003-06-13 | 2012-01-10 | Brilliant Digital Entertainment, Inc. | Methods and systems for searching content in distributed computing networks |
US7720006B1 (en) * | 2003-08-06 | 2010-05-18 | Cisco Technology, Inc. | System for determining reachablity of a neighboring node in a network |
US20050080846A1 (en) * | 2003-09-27 | 2005-04-14 | Webhound, Inc. | Method and system for updating digital content over a network |
US7668146B2 (en) * | 2004-12-20 | 2010-02-23 | Connectivities Llc | Internet-oriented ad-hoc network |
-
2005
- 2005-03-21 US US11/084,971 patent/US20060209819A1/en not_active Abandoned
-
2006
- 2006-03-09 EP EP06725006A patent/EP1867137B1/en active Active
- 2006-03-09 CA CA002602483A patent/CA2602483A1/en not_active Abandoned
- 2006-03-09 JP JP2008502375A patent/JP4755683B2/en not_active Expired - Fee Related
- 2006-03-09 WO PCT/EP2006/060605 patent/WO2006100185A1/en not_active Application Discontinuation
- 2006-03-09 CN CN2006800089733A patent/CN101147380B/en not_active Expired - Fee Related
- 2006-03-09 AT AT06725006T patent/ATE547889T1/en active
- 2006-03-17 TW TW095109247A patent/TWI392285B/en not_active IP Right Cessation
-
2008
- 2008-06-30 US US12/164,979 patent/US8788573B2/en not_active Expired - Fee Related
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5115433A (en) * | 1989-07-18 | 1992-05-19 | Metricom, Inc. | Method and system for routing packets in a packet communication network |
US6205481B1 (en) * | 1998-03-17 | 2001-03-20 | Infolibria, Inc. | Protocol for distributing fresh content among networked cache servers |
US20030041141A1 (en) * | 2001-01-22 | 2003-02-27 | Abdelaziz Mohamed M. | Peer-to-peer presence detection |
US20040246975A1 (en) * | 2003-06-06 | 2004-12-09 | Meshnetworks, Inc. | System and method to improve the overall performance of a wireless communication network |
US20050021725A1 (en) * | 2003-06-30 | 2005-01-27 | Johannes Lobbert | Distance-aware service discovery mechanism for determining the availability of remote services in wireless personal area networks |
Cited By (41)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050163133A1 (en) * | 2004-01-23 | 2005-07-28 | Hopkins Samuel P. | Method for optimally utilizing a peer to peer network |
US20050163050A1 (en) * | 2004-01-23 | 2005-07-28 | Hopkins Samuel P. | Method for monitoring and providing information over a peer to peer network |
US8468250B2 (en) | 2004-01-23 | 2013-06-18 | Tiversa Ip, Inc. | Method for monitoring and providing information over a peer to peer network |
US20070153710A1 (en) * | 2004-01-23 | 2007-07-05 | Tiversa, Inc. | Method for monitoring and providing information over a peer to peer network |
US8122133B2 (en) | 2004-01-23 | 2012-02-21 | Tiversa, Inc. | Method for monitoring and providing information over a peer to peer network |
US9300534B2 (en) | 2004-01-23 | 2016-03-29 | Tiversa Ip, Inc. | Method for optimally utilizing a peer to peer network |
US8972585B2 (en) | 2004-01-23 | 2015-03-03 | Tiversa Ip, Inc. | Method for splitting a load of monitoring a peer to peer network |
US8037176B2 (en) | 2004-01-23 | 2011-10-11 | Tiversa, Inc. | Method for monitoring and providing information over a peer to peer network |
US7583682B2 (en) | 2004-01-23 | 2009-09-01 | Tiversa, Inc. | Method for improving peer to peer network communication |
US8798016B2 (en) | 2004-01-23 | 2014-08-05 | Tiversa Ip, Inc. | Method for improving peer to peer network communication |
US8095614B2 (en) | 2004-01-23 | 2012-01-10 | Tiversa, Inc. | Method for optimally utilizing a peer to peer network |
US20050163135A1 (en) * | 2004-01-23 | 2005-07-28 | Hopkins Samuel P. | Method for improving peer to peer network communication |
US8819237B2 (en) | 2004-01-23 | 2014-08-26 | Tiversa Ip, Inc. | Method for monitoring and providing information over a peer to peer network |
US8386613B2 (en) | 2004-01-23 | 2013-02-26 | Tiversa Ip, Inc. | Method for monitoring and providing information over a peer to peer network |
US8358641B2 (en) | 2004-01-23 | 2013-01-22 | Tiversa Ip, Inc. | Method for improving peer to peer network communication |
US8312080B2 (en) | 2004-01-23 | 2012-11-13 | Tiversa Ip, Inc. | System and method for searching for specific types of people or information on a peer to-peer network |
US7761569B2 (en) | 2004-01-23 | 2010-07-20 | Tiversa, Inc. | Method for monitoring and providing information over a peer to peer network |
US7783749B2 (en) | 2004-01-23 | 2010-08-24 | Tiversa, Inc. | Method for monitoring and providing information over a peer to peer network |
US20110029660A1 (en) * | 2004-01-23 | 2011-02-03 | Tiversa, Inc. | Method for monitoring and providing information over a peer to peer network |
US8156175B2 (en) | 2004-01-23 | 2012-04-10 | Tiversa Inc. | System and method for searching for specific types of people or information on a peer-to-peer network |
US8825907B2 (en) | 2005-09-15 | 2014-09-02 | Gendband US LLC | Incorporating a mobile device into a peer-to-peer network |
WO2007031981A3 (en) * | 2005-09-15 | 2007-09-13 | One Fone Ltd | Incorporating a mobile device into a peer-to-peer network |
JP2009524293A (en) * | 2006-01-13 | 2009-06-25 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Method and apparatus for establishing peer-to-peer karma and trust |
WO2008004207A3 (en) * | 2006-07-07 | 2009-05-07 | Fringland Ltd | Identifying network entities in a peer-to-peer network |
US20100049873A1 (en) * | 2006-07-07 | 2010-02-25 | Alex Nerst | Identifying network entities in a peer-to-peer network |
US9712667B2 (en) | 2006-07-07 | 2017-07-18 | Genband Us Llc | Identifying network entities in a peer-to-peer network |
US20080140780A1 (en) * | 2006-11-07 | 2008-06-12 | Tiversa, Inc. | System and method for enhanced experience with a peer to peer network |
EP2082326A4 (en) * | 2006-11-07 | 2012-02-15 | Tiversa Inc | System and method for enhanced experience with a peer to peer network |
WO2008057509A3 (en) * | 2006-11-07 | 2008-07-10 | Tiversa Inc | System and method for enhanced experience with a peer to peer network |
AU2007317889B2 (en) * | 2006-11-07 | 2011-05-12 | Kroll Information Assurance, Llc | System and method for enhanced experience with a peer to peer network |
EP2082326A2 (en) * | 2006-11-07 | 2009-07-29 | Tiversa Inc. | System and method for enhanced experience with a peer to peer network |
WO2008057509A2 (en) | 2006-11-07 | 2008-05-15 | Tiversa, Inc. | System and method for enhanced experience with a peer to peer network |
US9021026B2 (en) | 2006-11-07 | 2015-04-28 | Tiversa Ip, Inc. | System and method for enhanced experience with a peer to peer network |
US20100002694A1 (en) * | 2007-03-16 | 2010-01-07 | Fujitsu Limited | Route data collection technique in network |
US8345567B2 (en) * | 2007-03-16 | 2013-01-01 | Fujitsu Limited | Route data collection technique in network |
US8909664B2 (en) | 2007-04-12 | 2014-12-09 | Tiversa Ip, Inc. | System and method for creating a list of shared information on a peer-to-peer network |
US9922330B2 (en) | 2007-04-12 | 2018-03-20 | Kroll Information Assurance, Llc | System and method for advertising on a peer-to-peer network |
US20100100630A1 (en) * | 2007-06-27 | 2010-04-22 | Huawei Technologies Co., Ltd. | Method for acquiring traversal resource, peer to peer node and peer to peer system |
US8601140B2 (en) | 2007-06-27 | 2013-12-03 | Huawei Technologies Co., Ltd. | Method for acquiring traversal resource, peer to peer node and peer to peer system |
WO2009000181A1 (en) * | 2007-06-27 | 2008-12-31 | Huawei Technologies Co., Ltd. | Method for acquiring traversal resource, peer to peer node and peer to peer system |
CN111046065A (en) * | 2019-10-28 | 2020-04-21 | 北京大学 | Extensible high-performance distributed query processing method and device |
Also Published As
Publication number | Publication date |
---|---|
US8788573B2 (en) | 2014-07-22 |
JP4755683B2 (en) | 2011-08-24 |
CA2602483A1 (en) | 2006-09-28 |
EP1867137A1 (en) | 2007-12-19 |
WO2006100185A1 (en) | 2006-09-28 |
TWI392285B (en) | 2013-04-01 |
CN101147380B (en) | 2010-12-15 |
JP2008537619A (en) | 2008-09-18 |
TW200644525A (en) | 2006-12-16 |
US20080270539A1 (en) | 2008-10-30 |
CN101147380A (en) | 2008-03-19 |
ATE547889T1 (en) | 2012-03-15 |
EP1867137B1 (en) | 2012-02-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8788573B2 (en) | Method and apparatus for efficiently expanding a P2P network | |
US8280970B2 (en) | Method and apparatus for improving data transfers in peer-to-peer networks | |
US7558854B2 (en) | Access relaying apparatus | |
US7580971B1 (en) | Method and apparatus for efficient SQL processing in an n-tier architecture | |
US7836016B2 (en) | Method and apparatus for disseminating new content notifications in peer-to-peer networks | |
US20050138173A1 (en) | Ontology-based service discovery system and method for ad hoc networks | |
US20040059722A1 (en) | Method and apparatus for discovery of dynamic network services | |
US10225201B2 (en) | Scalable multicast for notification-driven content delivery in information centric networks | |
US20060179137A1 (en) | Method and apparatus for reducing spam on a peer-to-peer network | |
US20030187931A1 (en) | Facilitating resource access using prioritized multicast responses to a discovery request | |
CN112333169B (en) | Message processing method, device, electronic equipment and computer readable medium | |
KR20030047856A (en) | Data processing system, data processing method, information processing device, and computer program | |
JP2018536356A (en) | System and method for supporting context-aware content requests in an information-oriented network | |
US20130275464A1 (en) | Terminal device based on content name, and method for routing based on content name | |
CN115883659B (en) | Method and device for supporting batch refreshing of CDN caches | |
JP2002525749A (en) | Internet caching system, method and system configuration | |
RU2483457C2 (en) | Message routing platform | |
US8862095B2 (en) | Managing mobile nodes in a lawful intercept architecture | |
US10887412B2 (en) | Directory assisted routing of content in an information-centric network | |
CN111639944B (en) | Transaction broadcasting method, apparatus and storage medium | |
JP2004258994A (en) | Dynamic file retrieval method for p2p network, terminal, program, and recording medium | |
JP2004127074A (en) | File retrieval method in p2p network, terminal, program, and recording medium | |
WO2024152803A1 (en) | Communication method and apparatus | |
CN116756214A (en) | Data processing method, device, electronic equipment and storage medium | |
CN117119054A (en) | Method, device, computer equipment and storage medium for accelerating domain name query |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:JENNINGS, III, RAYMOND B.;LAVOIE, JASON D.;REEL/FRAME:016347/0454 Effective date: 20050725 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |