Patent Application
20050050227
1. Field of the Invention
The present invention relates to methods and systems for maintaining and tracking computer system network addresses and, in particular, to methods and systems for providing peer-to-peer directory services without an intermediary server.
2. Background Information
One of the hurdles in designing and running “peer-to-peer” applications on computer systems is obtaining the current network addresses of the other computer systems with which the peer-to-peer applications desire to communicate. Peer-to-peer applications are applications that communicate with and exchange data between two or more computer systems using peer-to-peer technology. For example, using peer-to-peer technology, data is transferred directly from one computer system to another using, without requiring an intervening server. Peer-to-peer technology and background information on peer-to-peer computing is described further in Oram, Andy, Peer to Peer: Harnessing the Benefits of a Disruptive Technology, O'Reilly and Assocs., Inc., 2001, which is incorporated herein by reference in its entirety.
In such environments, network addresses are often dynamic, and peer computer systems are not always available, because they may, for example, be intermittently connected to the network or be otherwise off-line. In particular, home computer systems commonly do not have a consistent Internet address (known as an IP address). For example, with dial-up Internet access, a computer is assigned a different IP address each time it connects (each time it dials up) typically from a pool of IP addresses. Even with “always on” connections such as DSL, ADSL, and cable, the computer system doesn't “own” its IP address—an address is assigned and periodically changed by the ISP (Internet Service Provider) that provides connection service to the Internet. Thus, even though an address for a computer system may be known at one instant, it may no longer be usable the next time an application attempts to communicate with that computer system.
The issue of discerning a network address for a peer computer system is rarely confronted outside of the home (or home-like) environment, since computer systems outside the home typically have “static” IP addresses that do not change. Such systems typically invoke a well-known “name service,” such as through a DNS server on the network, to translate friendly domain names such as “yahoo.com” and “msn.com” into usable IP addresses. DNS servers are part of a Domain Name System (typically itself a network within the Internet) that implements name to network address mappings for networks such as the Internet. For example, when a user enters an address such as “msn.com” into a browser, the user's computer system contacts a DNS server with a known (and static) IP address to retrieve “msn.com's” corresponding IP address. The DNS server may contact other DNS servers as needed until the IP address that corresponds to “msn.com” is determined. The computer system is thereafter able to directly contact the “msn.com” server using the retrieved IP address.
Servers like “yahoo.com” or “msn.com” do occasionally change their IP addresses (they have many of them corresponding to different parts of the services they offer) or may add new ones. When address changes occur, the server is responsible for notifying the DNS system of its address change, after which, a day or so is required before the changes are propagated throughout all of the (related) DNS servers in the world.
In some cases, it makes sense for computer systems in home-like environments that connect to the Internet to obtain static IP addresses with user friendly names that are maintained with the Internet DNS system to avoid the problems associated with dynamic addresses. However, in many cases such a solution is cost-prohibitive. Each such computer system needs to have a domain name, which is maintained with the Internet DNS system so that other computer systems can locate it, and a static IP address, both of which add expense.
In other cases, computer systems with dynamic IP addresses that desire to communicate with each other have incorporated approaches that require more involvement by the user of the computer system or the system itself. These systems also utilize an independent “directory service” or “directory server” to store and serve network addresses. In this case though, the independent directory server is a network-accessible server, with a known (and static) address, that is invoked by an application to record its own network address for access by others and to retrieve the network addresses of other computer systems. Thus, the directory server acts as an intermediary between computer systems that use it.
Such intermediary directory servers can exist in different forms. In one form, a centralized computer system(s) operates to maintain the addresses of its members/subscribers. The central directory service acts as a kind of current “phone book,” and each computer system must notify the directory service of its current address every time the user comes “on-line” with the application (e.g., the system comes on-line and registers with the application) or otherwise potentially changes its address. Napster and the Instant Messaging (IM) services such as AOL and MSN, as well as other services, use such an approach. Each service/application maintains an established central server, with a static IP address served by the DNS, which intermediates between subscriber computer systems. So when a subscriber of the application comes on-line, the subscriber's computer system (or in some cases the subscriber) is responsible for connecting to the central directory server (the directory server's address is available through the DNS), to notify the directory server of its currently assigned IP address. When two users or computer systems want to communicate directly with each other (such as through an application), each must first contact the directory server to determine the other's current IP address, after which the two computer systems can communicate directly. Essentially, the directory server acts as a surrogate for a DNS system for its own particular application/system—maintaining a translation system from “friendly names” known within the application to current IP addresses. Because network addresses can change, a peer-to-peer application typically needs to determine or check the validity of a computer system's network address typically at the start of each communication session, re-retrieving it from the directory service as needed. And, when a computer system's network address does change (e.g., it's assigned a new IP address), the application needs to again notify the directory service.
A second form of intermediary directory servers offers a de-centralized approach, known as “fluid” directory servers. Fluid directory servers have static IP addresses, but there are typically one or more of them, and they may dynamically join or leave the application network (for example, as they make themselves available to provide directory service for a particular application or then cease to do so). Each directory server that is present on the network at a particular time can intermediate between the computer systems “connected” to it, and each computer system may connect to any one or more of the directory servers. Thus, one particular computer system cannot count on a second particular computer system being connected to the same directory server at a particular point in time to locate or communicate specifically with the second computer system. Therefore, this form of directory server isn't generally useful for peer-to-peer applications that need to connect particular users to each other such as IM applications. Rather, applications in which the respective computer systems are “fungible” (not valued for their uniqueness, but rather for a common characteristic) are best suited for such an approach. File sharing services, such as Gnutella and Kazaa, use this form of the intermediary directory server approach. These services connect together different computer systems to offer a desired commodity such as copies of a particular song. Which computer supplies the copy is not important—just that the copy is available.
One problem with most centralized and fluid directory services is that they are application specific—they support their own applications and are not available to third party applications. The expense of maintaining large centralized banks of server machines contributes substantially to this unavailability. Directory services provided by AOL and MSN are subsidized by advertising revenue. Other directory services charge directly for their use, for example through subscription fees. “Jabber.com” is one central directory service that is available to third party applications and is not application-specific; however, there is an expense associated with its use. Another problem with such solutions is privacy—many users are reticent to share information with centralized services because they cannot control the dissemination of the information once it is shared.
Another approach to supporting communication between computer systems with dynamic IP addresses involves the explicit exchange of network addresses, for example, by manual entry of an IP address when needed by an application. Applications that use this approach typically utilize a user interface (UI) for entering another user's (computer system's) IP address. The IP addresses can be exchanged “offline,” such as by a telephone call or through email. Because of the tedium involved in entering this data, potential for making errors, and lack of understanding of IP addresses by non-technical users, this approach works only in limited situations. In addition, when network addresses change, the application needs to be notified by the user. Thus, the manual method is onerous to the user and unreliable, because it may be difficult for a user to keep track of what or who needs to be notified.
Embodiments of the present invention provide computer-and network-based methods and systems for providing directory services for peer-to-peer systems and applications. Example embodiments provide a Peer-to-Peer Directory System (“PPDS”), which enables applications, especially those using peer-to-peer technology that desire to communicate directly with one another on different peer computer systems, to discover working (current) network addresses for each other in an automated fashion even when the network addresses of their respective computer systems change dynamically. The PPDS provides a community-based tracking system, a portion of which is implemented on each computer system that is a member of the community, to mutually track and store the network addresses of the other computer systems to which it has an associated relationship. The PPDS also provides a query mechanism that takes advantage of the relationship paths between the various computer systems to search for a current network address of a designated computer system. The PPDS can provide directory services in conjunction with or without the use of an intermediary server with a known network address.
In one example embodiment, the Peer-to-Peer Directory Service comprises one or more functional components/modules that work together to provide correspondent tracking and location. The PPDS comprises a plurality of PPDS portions executed by each member computer system of a community. For example, a PPDS portion may comprise a tracking and location service, which includes a tracking agent and a location service; a correspondent information data repository; a user interface; and an application interface. The tracking agent forwards changes to the computer system's network address, and potentially network address information for a tracked number of levels of correspondents to its correspondents via a network, and receives similar messages from its correspondents via the network. The tracking agent stores received network addresses and network address information in the correspondent information data repository. The location service uses the network and network addresses retrieved from the data repository to contact correspondent computer systems to automatically determine a network address for a target correspondent computer system.
According to one approach, a network address for a target correspondent is automatically determined by receiving and storing network address information for a plurality of computer systems, at least one of which has a dynamically changing address, designating a target correspondent, and contacting another correspondent to retrieve the current network address of the designated target correspondent. In some embodiments, member computer systems in the community are queried based upon correspondent information stored locally to locate the current network address of the designated target correspondent. In other embodiments, member computer systems in the community are searched recursively to allow the PPDS to locate the current address for the target correspondent by querying correspondents down relationship paths. In some embodiments, the determining of a network address for a target correspondent occurs periodically and in other embodiments a target correspondent is designated by receiving a request for a target correspondent's address. In some instances, the network addresses that are tracked are public network addresses, in others they are private addresses, and yet in others they are a combination of both. The network addresses may be heterogeneous or homogeneous.
According to another approach, a network address for a member correspondent is forwarded to other member computer systems after the network address for the member correspondent has been updated. This provides a mechanism for the member computer systems to be informed on a periodic basis of updates to network addresses. In some embodiments, the member's updated network address is forwarded to direct and indirect correspondents of the member computer system. In other embodiments, the member's updated network address is forwarded to the direct correspondents of the member computer system, which are then responsible for propagating the updated network address. In some embodiments, network address information that relates to the direct correspondents of the direct correspondent is also forwarded. In some embodiments, it is not. In some embodiments, network address information that relates to the indirect correspondents of the direct correspondent is also forwarded. In some embodiments, the information (whether for direct or indirect correspondents) is propagated from direct correspondent to direct correspondent. In some situations, network address information for other correspondents may be sent together with the updated network address. In other situations, they may be forwarded separately or portions not forwarded at all.
According to yet another approach, a network address for a direct correspondent along with network address information for its direct and indirect correspondents is forwarded to a new direct correspondent. In some situations, the information is forwarded when the direct correspondent is notified that it is to track the new direct correspondent. In some embodiments, the network address for the direct correspondent along with the network address information for its direct and indirect correspondents is forwarded on a periodic basis.
In some scenarios, indirect correspondents are tracked to a number of levels of indirection. In some approaches, the tracking level is user settable and may be specific to a computer system. In other approaches, an agreed upon community tracking level is maintained.
According to one approach, the tracking of a particular correspondent or its elimination from community tracking is specifiable by a user or by an application.
Embodiments of the present invention provide computer- and network-based methods and systems for providing directory services for peer-to-peer systems and applications. Example embodiments provide a Peer-to-Peer Directory System (“PPDS”), which enables applications, especially those using peer-to-peer technology that desire to communicate directly with one another on different peer computer systems, to discover working (current) network addresses for each other in an automated fashion even when the network addresses of their respective computer systems change dynamically. The PPDS can provide directory services in conjunction with or without the use of an intermediary server with a known network address. The PPDS takes advantage of the phenomenon that individuals and applications have communities of correspondents of which they are a part, and uses those correspondents and the inherent relationships between them to help track and locate the current network address each individual's computer system. The computer systems that belong to such a community will be generally referred to as “peer” computer systems, because they typically utilize peer-to-peer technologies to communicate and interact with each other, and because the PPDS technologies are particularly useful in such environments. However, one skilled in the art will recognize and understand that the PPDS is also useful in communities with computer systems that run more traditional client-server applications, or a mixture of client-server and peer-to-peer applications, as well.
In an PPDS environment that involves computer systems with dynamically changing addresses, changes to network addresses are broadcast to other computer systems that are within a sphere of computer systems that interact. It is likely that one or more of these other computer systems does not receive the network address update because it is not on-line or otherwise connected to the network at the time the update is broadcast. Thus, when the other computer system comes back on-line, it will need to somehow obtain the updated network address.
The PPDS provides a community-based tracking system, a portion of which is implemented on each computer system that is a member of the community, to mutually track and store the network addresses of the other computer systems to which it has an associated relationship. The PPDS also provides a query mechanism that takes advantage of the relationship paths between the various computer systems to search for a current network address of a designated computer system. Through the tracking system and query mechanism, the PPDS provides an automated method for discovering a current network address for the designated computer system, without user involvement, once the designated computer system is known to some member of the community of computer systems, by determining from other related member computer systems the current network address of the designated computer system. Thus, by distributing the responsibility for tracking network addresses to member computer systems in a community formed by the natural relationships inherent in application and user communication, the PPDS avoids the expense and management involved in utilizing the intermediary directory services and servers of traditional techniques.
Each member computer system is responsible for transmitting network address information to the other member computer systems of the community with which it has an associated relationship and for collecting and storing network address information it receives. Each computer system typically transmits its own network address and an effective date and time typically whenever its address changes; the addresses of other computer systems with which it maintains relationships; and the addresses received from these other computer systems, which typically includes addresses of other member computer systems with which they maintain a relationship, up to a settable (or predetermined) number of levels. The transmission of network address information may take place at different times or at other times, such as on a periodic basis or triggered by some event. In addition, the addresses of the other computer systems may be transmitted at different times or at the same time as when the computer systems transmits its own address.
In one embodiment of the PPDS, alternative mechanisms for finding a current network address can be additionally employed as a backup or secondary mechanism to the community-based tracking and locating services described. Such mechanisms are indicated as optionally invoked in step 207. For example, although not likely to yield an immediate response, the application can optionally choose to use email to send the correspondent computer system its resident computer system's address and request a network message back that contains the correspondent computer system's current network address. This mechanism is described further with respect to
Each member computer system in a PPDS community typically communicates with one or more of the other member computer systems over one or more networks, either through applications or users of the computer systems. The relationships (associations, contacts, affiliations, or connections, etc.) between the computer system applications or users may be “direct” or may be “indirect.” Within a community of peer computer systems, there may be many direct and indirect relationships between the various systems and therefore many direct and indirect correspondents.
For example, two computer systems may have a direct relationship, either through an application running on a first computer system that communicates (or is otherwise directly associated) with an application running on a second computer system or through the users of both computer systems. In this case, each of the computer systems (or an application executing on them or their users) is referred to as a “direct correspondent” of the other computer system. For example, two peer-to-peer applications that send one or more messages between themselves over a network are direct correspondents.
On the other hand, two computer systems may have an indirect relationship, if they do not directly communicate (or otherwise directly associate) with each other, but both communicate with (or are otherwise associated with) a third computer system that communicates with both the first and second computer system. Because of the direct communication, the second and third computer systems are direct correspondents, as are the first and third computer systems. However, the relationship between the first computer system and the second computer system is indirect through a relationship path via the third computer system. The first and second computer systems (or an application executing on them or their users) are referred to as an “indirect correspondents” relative to each other.
According to an example PPDS, indirect correspondents are tracked by each member computer system to a user-settable (or predetermined) level. For example, if the tracking level for computer system A is set to three, then computer system A will track network address information for (1) its own direct correspondents (first level correspondents); (2) direct correspondents of computer system A's direct correspondents, which are computer system A's second level correspondents (related through one level of indirection); and (3) first level indirect correspondents of computer system A's direct correspondents, which are computer system A's third level correspondents (related through two levels of indirection).
Each computer system has its own tracking level, and is responsible for collecting and forwarding network address information as appropriate by level. (Each computer system typically forwards to one level less than it collects.) In one embodiment, tracking entails collecting network address information up through the tracking level number of correspondents; forwarding as appropriate received updates for these correspondents or information on new correspondents to one's own direct correspondents; and forwarding as appropriate updates regarding one's own network address to one's own correspondents. Typically, an effective date and time, or other indication of time period, is forwarded with each new or updated network address so that a receiving computer system can determine whether the address is more recent than one that is already stored.
In one embodiment, the PPDS presents a user interface to allow a user of the member computer system to change the default tracking level for that system. Thus, it is possible that different member computer systems are tracking to different levels of correspondents. Therefore, a member computer system may receive more or less network address information than it is set up to track, and it will simply ignore any excess information. The effective number of levels that the overall PPDS community operates with may thus be less than that chosen by a particular user. One skilled in the art will recognize that a default may be set to any number or for each system or for the community, and that the number of tracking levels could also be predetermined or arranged by users in advance.
In the example PPDS community 100 shown in
For the purposes of the PPDS, 104 and 103 are indirect correspondents of computer system 101, even though computer system 101 may have no a priori knowledge of either system. Potentially unbeknownst to the users and applications of computer system 101, the PPDS portion 111 that executes on computer system 101 becomes “knowledgeable” of computer systems 103 and 104 through running the PPDS. Specifically, according to the techniques described herein, at some point the PPDS tracking and location service 112 on computer system 102 informs the PPDS tracking and location service 111 of the networking addresses of systems 103 and 104 as correspondents of computer system 102. (Alternatively, computer system 101 may learn of these computer systems through other means, such as through a different direct correspondent.) The PPDS tracking and location service 111 running on computer system 101 uses the respective PPDS tracking and location services 113 and 114 on computer systems 103 and 104 (computer system 101's indirect correspondents) to find a current network address of computer system 102 when computer system 102 becomes “unavailable” from the perspective of computer system 101. This scenario might occur if, for example, computer system 102 is off-line, and then comes on-line with a new address during a time when computer system 101 is off-line, so that computer system 102 cannot contact 101 with its new address. Later when computer system 101 comes on-line perhaps with its own new address, the address that computer system 101 has stored for computer system 102 is no longer valid (because computer system 102's address has changed) and if computer system 101's address has also changed, then computer system 102 no longer has the correct address for computer system 101, so neither system has a current (working) address of the other. To obtain computer system 102's current address, the PPDS tracking and location service 111 running on computer system 101 uses stored network address information to contact computer systems 103 and 104 as needed to request a current address for computer system 102. As long as at least one of computer systems 103 and 104 was on-line when computer system 102 obtained its new address (or, in another embodiment, computer 104 was on-line and forwarded it to its correspondents), then the address of computer system 102 will be discoverable by the PPDS.
In general, to find a target correspondent's current network address when the target correspondent cannot be contacted, the PPDS tracking and location service of a resident member computer system queries its other correspondents, which include a target correspondent's correspondents, for the target's current address. Several techniques can be used to query the other correspondents for the target correspondent's current address. One technique focuses on contacting correspondents based upon current tracking information stored in the resident computer system's data repository. Direct and indirect correspondents are queried until a working address is found. A second technique focuses on spreading the location task between correspondents. According to this technique, the resident computer system queries its direct correspondents, and, if these other correspondents cannot be contacted, then the PPDS tracking and location service on the resident computer system contacts their correspondents in turn in an effort to find the other direct correspondents' current network addresses, and then querying them for the target correspondent's address, and so on. This process is repeated as necessary for as many levels of correspondent information that are maintained by the PPDS tracking and location service, until one such sequence of correspondents is able to return a current network address for the target correspondent or until all correspondents have been exhausted. Other techniques, or variations of these techniques are also possible. Once the target correspondent's current network address has been determined using any of these techniques, then the resident computer system may send the target correspondent its own network address information to ensure that further communication can easily occur.
Although the techniques of automatic peer-to-peer tracking and locating and the PPDS are generally applicable to any type of network address, the phrase “address,” “url,” “network address,” etc., is used generally to imply any type of location identifier of another system. In addition, one skilled in the art will recognize that the network addresses are really “black boxes” to the Peer-to-Peer Directory System, the content of which need not be understood—just stored, retrieved, and forwarded by the PPDS portions. Thus, the techniques described herein can be applied to a heterogeneous mixture of wide area network addresses and private local area network addresses as well as to systems with homogeneous addresses. In the case of multiple machines sharing a single public address (as often occurs with networked home computers), the address information stored and transmitted may include additional fields to identify a particular computer on a private network.
Also, although the examples described herein often refer to peer-to-peer applications, one skilled in the art will recognize that the techniques of the present invention can also be used by systems that employ traditional applications that communicate by means of an intermediary system or using a client-server model exclusively or in addition to peer-to-peer applications. In such a scenario, the PPDS doesn't change the flow of normal application communication, although it utilizes peer-to-peer techniques to locate the other systems involved in the communications. Essentially, the concepts and techniques described are applicable to any group of computer systems that desires to share addressing whether or not they utilize peer-to-peer applications at all, in-part, or in whole.
Also, although certain terms are used primarily herein, one skilled in the art will recognize that other terms could be used interchangeably to yield equivalent embodiments and examples. For example, it is well-known that equivalent terms could be substituted for such terms as “community,” “correspondent,” “member,” etc. Specifically, the term “community” can be used interchangeably with “group,” “set,” “plurality of,” etc. Likewise, the term “correspondent” can be used interchangeably with the terms “communication recipient,” etc. Also, the terms broadcast and forward are not intended to imply a particular implementation of any underlying communications primitives. In addition, terms may have alternate spellings which may or may not be explicitly mentioned, and one skilled in the art will recognize that all such variations of terms are intended to be included.
Example embodiments described herein provide applications, tools, data structures and other support to implement a Peer-to-Peer Directory System to be used for automatically tracking and locating correspondent computer systems. In the following description, numerous specific details are set forth, such as data formats and code sequences, etc., in order to provide a thorough understanding of the techniques of the methods and systems of the present invention. One skilled in the art will recognize, however, that the present invention also can be practiced without some of the specific details described herein, or with other specific details, such as changes with respect to the ordering of the code flow.
In the embodiment shown, computer system 700 comprises a computer memory (“memory”) 701, a display 702, a Central Processing Unit (“CPU”) 703, Input/Output devices 704, and network devices 705. The components of the Peer-to-Peer Directory System portion 710 are shown residing in memory 701. (The memory 701 includes any type of computer memory including RAM, ROM, and persistent storage such as disk drives.) The components of the PPDS portion 710 preferably execute on CPU 703 and perform tracking and locating functions, as described in previous figures. Other downloaded code 730 and potentially other data repositories, such as repository 720, also reside in the memory 701, and preferably execute on one or more CPU's 703. In a typical embodiment, the PPDS portion 710 includes a tracking and location service 711, the correspondent information data repository 712, the application interface 714 and the user interface 713. One skilled in the art will recognize that many different arrangements of the components of the PPDS portion 710 are possible.
In an example embodiment, components of the PPDS portion 710 are implemented using standard programming techniques. One skilled in the art will recognize that various object-oriented and distributed methodologies may be used. However, any of the PPDS portion components 711-714 may be implemented using more monolithic programming techniques as well. In addition, programming interfaces to the data stored in the correspondent information data repository 712 or the functions of the tracking and location service 711 can be made available by standard means such as through C, C++, C#, and Java API and through scripting or tag-based languages such as JavaScript or XML, or through web servers supporting such. The correspondent information data repository 712 that is used to store network address information is preferably implemented for scalability reasons as one or more databases rather than as a text files. However, any method for storing such information may be used. In addition, portions of the tracking and location service 711 may be implemented as stored procedures, or methods attached to stored “objects,” although other techniques are equally effective.
One skilled in the art will recognize that the PPDS including the PPDS portions 710 may be implemented in a distributed environment that is comprised of multiple, even heterogeneous, computer systems and networks. For example, in one embodiment, the PPDS tracking and location service 711, the correspondent information data repository 712, the user interface 713, and the application interface 714 are all located in physically different computer systems. In another embodiment, various components of the PPDS portion 710 are hosted each on a separate server machine and may be remotely located from the correspondent network address information which is stored in the correspondent information data repository 712. Different configurations and locations of programs and data are contemplated for use with techniques of the present invention. In example embodiments, these components may execute concurrently and asynchronously; thus the components may communicate using well-known message passing techniques. One skilled in the art will recognize that equivalent synchronous embodiments are also supported by an PPDS implementation. Also, other steps could be implemented for each routine, and in different orders, and in different routines, yet still achieve the functions of the PPDS.
As mentioned, in order for the PPDS to provide automated tracking and locating of correspondents, each member computer system of a community is responsible for storing network address information associated with each of its correspondents, up to the designated tracking level for that computer system.
Specifically, each entry includes several fields that provide tracking data for a particular direct or indirect correspondent. Field 801 is an indication of its tracking level relative to the member computer system. Field 802 is a representation of the name of the correspondent and its relationship path relative to the member computer system. It includes a representation of the correspondent's relationship path starting from the direct correspondent that is associated with the member computer system when the correspondent is an indirect correspondent. Each component of the path is an indicator of a member computer system; thus, two components in sequence indicates a direct correspondent relationship between them. The relationship path stored in field 802 allows the PPDS location service to contact the appropriate indirect correspondents when the PPDS is attempting to determine a network address for an associated direct correspondent. For convenience, a relationship path between computer systems A and C (though B) is designated as “A→B→C” or “A:B:C,” where A, B, and C are indicators of their respective computer systems. One skilled in the art will recognize that any nomenclature that can be used to describe the direct and indirect relationships can be used with and incorporated into the techniques of the present invention and that many different indicators of computer systems can be used. Field 803 is a representation of an associated (the last known) network address 803 of the correspondent named in field 802. Field 804 is an indication of the effective date and time of the address stored as associated network address 803. One skilled in the art will recognize that many alternative representations of the network information are possible and that other information may be stored in the data repository.
Although the information stored in the correspondent information data repository is updated on a periodic basis by each member computer system based upon receiving updated address information, initial correspondent information is needed to bootstrap the entire tracking and locating process. Specifically, in one embodiment when a PPDS portion is first installed (and executed) on a member computer system, it creates and initializes the correspondent information data repository with initial network addresses values for at least some of the direct correspondents of the member computer system. (In other embodiments, the data repository may not be created or initialized until a first use is attempted, or at some other time.) In one embodiment, the PPDS locates potential direct correspondents, which may be approved or disapproved by a user prior to entry into the data repository. These initial direct correspondents are “new” to the system and will trigger the automatic update process as if information for a new direct correspondent information was just received by an application running on the member computer system. A new direct correspondent can also be added (upon PPDS initialization or at other times) by an application invoking a routine (of the application interface) to track a new direct correspondent. A routine for handling network address information updates for a new direct correspondent is described below with reference to
There are several ways that correspondent information can be entered initially into the PPDS data repository of a resident member computer system. In any one embodiment, one or more of these methods may be used. One method is for the PPDS upon installation to examine correspondent information that may be stored, for example, in system registries, buddy lists, email address books, etc., for existing peer-to-peer applications and other communication facilities to create a list of potential correspondents. The user may be offered an opportunity to accept or reject any found potential correspondents and enter or verify corresponding network addresses. Another method is for the PPDS to present its own user interface to allow the user to add additional direct correspondents (and their network information) as desired. This method may be invoked, for example, upon installation of the PPDS and explicitly by the user anytime the user desires to add a direct correspondent. A third method is for an application to invoke an application programming interface (“API”) of the PPDS to track a new direct correspondent.
When a direct correspondent is added to the data repository (automatically by the PPDS upon initialization or by a user or by an application) if an associated network address is not known, then several techniques can be employed to determine a current network address. First, the PPDS can examine entries in the correspondent information data repository to determine whether the direct correspondent is already present in the data repository as an indirect correspondent, and, if so, an initial network address is retrieved from the determined entry. While there is not necessarily an engineered reason why this scenario would exist, in practice, correspondents will come from communities with a lot of overlap among correspondents and so a new correspondent for one user may very well already be a correspondent of one of that user's existing other correspondents. Second, if a correspondent's email is known, but an associated network address is not, then the PPDS can send an email message to the potential correspondent that includes the member computer system's current network address and requests a return network message with a current network address. When the new address is received, it is then entered into the correspondent information data repository.
When the PPDS portion itself or an application indicates that a new direct correspondent is to be tracked, as part of initializing the PPDS portion or thereafter, the PPDS portion invokes a routine to broadcast the network address and potential correspondent information for the new direct correspondent to its other direct correspondents. In addition, in some embodiments, the routine may send to each new direct correspondent, the resident system's own network address and its correspondent network address information. In other embodiments, this information may be sent to the new direct correspondent through another routine or message, or at some other time.
Other events in the PPDS portion may also cause a member computer system's network address or correspondent information to be forwarded or broadcasted. One such event occurs each time a member computer system is given its own new network address (an updated address). In one embodiment, each time a member computer system receives a new network address, it broadcasts the new network address to its direct and indirect correspondents, for which there are entries in its data repository. These entries are typically set up when correspondents were added for tracking as described above. In this embodiment, there is no need to propagate the updates, because the broadcast will result in informing those correspondent computer systems that are on-line and available. In another embodiment, each time a member computer system is given its own new network address, it broadcasts the new network address to its direct correspondents, which then propagate the network address to their direct correspondents, and so on, for the tracked number of levels. Another event that potentially causes a network address or correspondent information to be forwarded or broadcasted occurs whenever the PPDS portion or an application receives a request to end tracking of a direct correspondent. An indication of the direct correspondent to be eliminated from tracking is propagated throughout paths of direct correspondents so that the direct correspondent and its correspondent information can be eliminated from each member system.
The figures that follow address the various routines and messages that may occur in response to such events. One skilled in the art will understand that, although particular messages and message names are referred to for convenience in many of the routines that follow, other messages, ordering of messages, functions etc., may be equivalently incorporated into the techniques described herein. In addition, although the routines and message handlers operate to track and store direct and indirect correspondent information, embodiments of the PPDS are envisioned that only track direct correspondent information or indirect correspondents to a single level of indirection. (For example, computer A adds a new direct correspondent to track, computer X, and informs its other direct correspondents of computer X, but the information is not propagated further.)
Specifically, in step 1001, the routine determines whether an address has been designated as a parameter, and, if so, continues in step 1002, else continues in step 1009. In step 1002, the routine prepares the address of the resident computer system (and an effective date and time) into a packet for broadcasting to the named direct correspondent. In step 1003, the routine retrieves the resident computer system's correspondent information from the correspondent information data repository and adds the retrieved information into the broadcast packet. In step 1004, the routine sends a PPDS_Update_With_CInfo message with the prepared information stored in the broadcast packet to the designated direct correspondent. Note that although the routine is described as transmitting both the resident computer network address and the network address information of its correspondents all at one time (in one packet), one skilled in the art will recognize that some or all of this information may be transmitted at any one time or in multiple packets at different times or at the same time, or not at all etc. In step 1005, the routine updates an existing entry or adds a new entry into the data repository that corresponds to the designated direct correspondent and its address, along with an effective date and time. In step 1006, the routine prepares address information for the designated direct correspondent including the effective date and time and any correspondent information for the designated direct correspondent into a (freshly initialized or new) broadcast packet. In a typical embodiment, the preparation step involves prepending (appending to the beginning) an indication of the resident computer system to each relationship path of each correspondent that is passed in the broadcast packet. For example, before computer system A sends information on a new correspondent computer system X, it prepends an “A” to each relationship path. What was previously a path designated “X→C” now becomes “A→X→C” before being sent to computer system A's other direct correspondents, so that the receiving correspondent knows that contact to computer system X is through computer system A. One skilled in the art will recognize that other mechanisms for prepending an indication of the resident computer system to a relationship path are available, including letting a message recipient computer system prepend an indicator of the source correspondent of a received message to a path before using it. In step 1007, the routine determines a list of other direct correspondents from the data repository. In step 1008, the routine sends a “PPDS_Update_With_CInfo” message to each of the other direct correspondents with the broadcast packet containing the new direct correspondent's information, and then returns.
In step 1009, if no address has been designated, then before steps 1002-1008 can be executed, the routine needs to determine whether it has or can obtain a working address by some other means. For example, in step 1009, the routine searches the data repository to determine whether the designated direct correspondent is already in the data repository either as a direct correspondent already or as an indirect correspondent of some other direct correspondent as described earlier. If so, then in step 1010, the routine retrieves the determined address and sets the designated address to the retrieved address, and then continues with steps 1002-1008. Otherwise, then the routine needs to invoke a more manual means if one is available. For example, in some embodiments as described above, in step 1011 the routine prompts a user to enter an address for the designated correspondent, and then determines in step 1012 if an address is received. If so, the routine continues in steps 1002-1008, otherwise the routine returns a failure code. In other embodiments, in step 1011, the routine uses an email message to send the direct correspondent the address of the resident system and requests a return network message to the resident address with the address of the designated direct correspondent. This technique was described with respect to
Note that even though one (user or application of a) computer system specifies another (user or application of a) computer system as a direct correspondent, the relationship may not be reciprocal. That is, the second computer system may not consider the first a direct correspondent. This is not a harmful situation and in fact the first computer system may still get updated information for the second, providing that the computer systems have other member computer systems of the community in common. In addition, as mentioned previously there may be some overlap between correspondents. Even if a member computer system receives updates for a correspondent more than once, no harm is done providing the member computer system checks before updating the data repository to make sure that a received address is newer than one already stored before updating the stored address.
Although not necessarily a typical embodiment, it is possible that the PPDS_Update_With_CInfo message could also be invoked by an application running on a different computer system to track a new correspondent. Optional steps 1103-1106 may be thus included to process the new direct correspondent similar to how it would be handled if the request had come from the resident system (and called the routine that is described in
In the embodiment shown, a message packet, which may include more than one entry of correspondent network address information, is designated as an input parameter. The message handler of the receiving system processes each entry in the message packet, and then propagates the entries (prepending the relationship paths with an indication of the receiving computer system) to all of its other direct correspondents. This process will trigger PPDS_Update_With_CInfo messages to be sent to each set of direct correspondents until the address of the newly tracked relationship is fully propagated through the tracking level. (Also, each receiving system will ignore received addresses that are not more recent than those already stored in its data repository.)
Specifically, in step 1101, the message handler for a PPDS_Update_With_CInfo retrieves the first entry of the message packet. Assuming that the handler is coded to be able to receive a request message to track a new direct correspondent as described above, then in step 1102, the handler determines whether the retrieve first entry specifies a new direct correspondent, and, if so, continues in step 1103, else continues in step 1107. In an embodiment that doesn't handle new direct correspondents in this fashion, steps 1102-1106 would be non-existent. In step 1103, the handler initializes a message packet for broadcasting. In step 1104, the handler prepares network address information of the resident computer system, including an effective date and time, and adds it to the message packet. In step 1105, the handler retrieves and prepares correspondent information for the resident computer system and adds it to the message packet. In step 1106, the handler sends a PPDS_Update_With_CInfo message to the designated direct correspondent passing the prepared message packet and continues in step 1107.
In step 1107, consistent with normal use of this routine in sequence with the Track New Correspondent routine of
In general,
As another example, there are other times that it may be beneficial to send an update of a resident computer system's correspondent information (not just the resident computer system's network address). The steps to perform such an update are described with reference to
As mentioned, as an alternative to broadcasting a resident computer system's updated network address to all of its correspondents, another technique may be used which broadcasts the updated network address to its direct correspondents and then lets them propagate the new address appropriate to the level of tracking of each system.
Note that it is possible in
A user or an application of a resident computer system can also designate that a particular correspondent computer system cease to be tracked by the PPDS, for example, via a user interface of a PPDS portion of an application. In such case, the PPDS of the resident computer system effectively removes network address knowledge of the designated computer system from its data repository and contacts its direct correspondents (sends a message) for them to do the same.
As mentioned, when a direct correspondent is designated as one for which tracking by the PPDS is to cease, a message to each computer system's direct correspondents is propagated.
In addition to explicitly requesting that a particular correspondent cease to be tracked by the community, it may be desirable to have each PPDS portion periodically delete entries in its data repository that have not been referenced over some period of time. Many forms of referencing entries may be tracked, including, for example, network address updates for a correspondent, queries for a correspondent's current address, queries originating from a correspondent for others, etc. One skilled in the art will recognize that there are many other aspects that can conceivably be tracked to determine whether an entry is sufficiently referenced over some designated period of time, and that time may be indicated in many ways, such as periods of time, discrete events, etc.
As described in
There are many reasons why a user's computer system may be unreachable over a network, including that the user's computer system is no longer using the network address that was recorded for it. For example, a network message may have been returned indicating that the network address is not in use or that someone else (another computer system) has been assigned that address. Alternatively, the user's computer system may be off-line and therefore does not respond. When a computer system does not respond there is no way to tell if it has retained the same network address or if it has been assigned to another system. In addition, when a computer system does not respond, there is no way to tell whether the correspondent system is off-line or on-line with a new network address. Thus, when a correspondent computer system is unreachable, it makes sense for an application to seek an updated network address in any case, because the cause may not be knowable. Thus, when a correspondent is unreachable, the application uses the PPDS to try find an updated network address. Because of the possibility that a different user may be now using a correspondent's old network address, once an address is returned, the application (or underlying communications software) may want to employ authentication measures to ensure that the actual respondent is the correspondent expected.
Specifically, in step 2001, the routine initializes the ordering variable (here the current level). In step 2002, the routine increments the ordering variable, for example, increments the current level. In step 2003, the routine determines whether the current level is within the threshold number of levels that are tracked in this repository, and, if so, continues in step 2004, otherwise returns a failed status. In step 2004, the routine retrieves the correspondent entries at the current level from the data repository, and sets the current query list to the retrieved entries. In some embodiments, various heuristics can be used to filter or reorder this list as necessary, including that, in step 2005, the routine filters out an entry that corresponds to the designated target system if one is present in the query list. In step 2006, the routine sets the current correspondent entry to the next entry in the current query list starting with the first entry. In step 2007, the routine determines whether it has reached the end of the current query list, and, if so, continues back to the beginning of the loop to prepare a query list at the next level at step 2002, otherwise continues in step 2008. In step 2008, the routine sets a current address to a retrieved last known address for the current correspondent. In step 2009, the routine retrieves a current path for the current correspondent and prepares a new path to be able to direct the correspondent to the correct target. Specifically, in one embodiment the retrieved path is reversed, an indicator to the resident system is appended to the reversed path, and then an indicator to the designated target system is appended to the path created thus far. This allows the path to appear to the current correspondent when the path is received as the path to the target would be stored in that correspondent's data repository. Since names of systems are not necessarily unique, passing the path allows the receiving correspondent to properly make sure it knows which target is being requested. In step 2010, the routine invokes a Query_For_Target routine to attempt to contact the current correspondent using the retrieved address for the current correspondent and designating the prepared path as the target. The Query_For_Target routine is described below with respect to
Specifically, in step 1601, a local target correspondent variable is set to the designated correspondent. In step 1602, a query list (list of correspondents to be potentially queried further) is set to the direct correspondents of the target correspondent by querying the data repository. In step 1603, the routine retrieves the next correspondent from the query list starting with the first as the current query correspondent. In step 1604, the routine determines whether there are more potential correspondents to query, and, if so, continues in step 1605, else continues in step 1610. In step 1605, the routine retrieves from the data repository the last known address associated with the current query correspondent. In step 1606, the routine calls another routine to attempt to contact the current query correspondent using the retrieved address. This Query_For_Target routine is described below with respect to
In step 1610, when the current query list has been exhausted for this invocation of the routine, the routine determines whether there are any non-answering correspondents to continue to query, and if so continues in step 1611, else returns a failure status (the target address of the current correspondent cannot be found at this time). Then, in steps 1611-1617, the routine executes a loop to recursively search the list of non-answering correspondents for a direct correspondent that knows a working address of a non-answering correspondent. Specifically, in step 1611, the routine determines whether the level of the non-answering correspondent is less than the number of tracking levels stored in the data repository (otherwise it won't have its own direct correspondents to query for its address), and, if so, continues in step 1612, else returns a failure status. One skilled in the art will recognize that this test of whether to go another level deep in the recursion could be performed at other times. In step 1612, the routine retrieves the next correspondent from the list of non-answering correspondents starting with the first as the current query correspondent. In step 1613, the routine determines whether there are more potential non-answering correspondents to query, and, if so, continues in step 1614, else returns a failure status. In step 1614, the routine recursively invokes itself to search for a target address of the current query correspondent. In step 1615, the return status is examined, and if an address is returned, then the routine continues in step 1616, else it continues to loop to the next correspondent on the list of non-answering correspondents in step 1612. In step 1616, the routine invokes another routine to attempt to contact the current query correspondent using the returned address for the current query correspondent. This Query_For_Target routine is described below with respect to
If the Find_New_Network_Address routine is not successful at locating an updated network address for the target correspondent, then the peer-to-peer application or other software that invoked the routine is notified and the application can choose a different course of action dependent upon its goals. For example, the application can retry the PPDS operation at a later time. This tactic eventually will be successful if the target correspondent was simply off-line. Or, for example, the PPDS may offer an alternative mechanism to the community-based approach that sends email to request an updated network address (as described with reference to
Several enhancements can be made to the automated location service provided by a PPDS. One skilled in the art will recognize how such enhancements can be integrated in the routines described with reference to
All of the above U.S. patents, U.S. patent application publications, U.S. patent applications, foreign patents, foreign patent applications and non-patent publications referred to in this specification and/or listed in the Application Data Sheet, including but not limited to U.S. Provisional Patent Application No. 60/484,803, entitled “PEER-TO-PEER DIRECTORY SYSTEM,” filed Jul. 3, 2003; and U.S. patent application Ser. No. 10/838,293, entitled METHOD AND SYSTEM FOR RECIPROCAL DATA BACKUP, filed May 4, 2004, are incorporated herein by reference, in their entirety.
From the foregoing it will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. For example, one skilled in the art will recognize that the methods and systems for performing directory services discussed herein are applicable to other architectures other than purely peer-to-peer architecture. For example, the PPDS facilities may be offered in conjunction in a community with a computer system that has a static IP address. Also, portions of the PPDS may be offered for fee. For example, member systems with static IP addresses may charge for locating addresses of correspondents. One skilled in the art will also recognize that the methods and systems discussed herein are also applicable to differing protocols, communication media (optical, wireless, cable, etc.) and devices (such as wireless handsets, electronic organizers, personal digital assistants, portable email machines, game machines, pagers, navigation devices such as GPS receivers, etc.).
| Number | Date | Country | |
|---|---|---|---|
| 60484803 | Jul 2003 | US |
