WO2005006649A1

WO2005006649A1 - Multi-node network having common routing table

Info

Publication number: WO2005006649A1
Application number: PCT/US2003/018469
Authority: WO
Inventors: Lan Ngoc Vu
Original assignee: Web Office, Inc.
Priority date: 2003-06-11
Filing date: 2003-06-11
Publication date: 2005-01-20
Also published as: AU2003243512A1

Abstract

System and method for operating, via the Internet, a multi-node network (12) having a common routing table (32). A local copy of the common routing table (12) is maintained in each of the network (12), both servers (14,22) and their respective clients (16,18,20,24,26,28). In the event that any node discovers that another node is no longer online, the discovering node takes appropriate steps to assure that all of the other nodes are made aware of the system change and can make appropriate updates to their local copies of the common routing table (32). Preferably, the common routing table (32) contains recent workload information sufficient to allow dynamic distribution of workload among the several servers.

Description

MULTI-NODE NETWORK HAVING COMMON ROUTING TABLE CROSS-REFERENCE TO RELATED APPLICATIONS The present invention is related to the following co-pending applications for patents (the "Related Applications"): "System and Method for Facilitating Business-to-Business Business", U.S. Application Serial Number 09/597,359, filed 19 June 2000 and assigned to the assignee hereof ("First Application"); "System and Method for Dynamic Local Caching of Web Content", U.S. Application Serial Number 09/699,093, filed 28 October 2000 and assigned to the assignee hereof ("Second Application"); "System and Method for Multi-Tier Multi-Casting Over the Internet", U.S.

Application Serial Number 09/917,412, filed 28 July 2001 and assigned to the assignee hereof ("Third Application"); and "System and Method for Secure Communication Over the Internet", U.S. Application Serial Number 10/039,792, filed 24 October 2001 and assigned to the assignee hereof ("Fourth Application"). BACKGROUND OF THE INVENTION

1. TECHNICAL FIELD. Our invention relates generally to a method and apparatus for operating a multi-node network over the Internet. 2. BACKGROUND ART. In general, in the descriptions that follow, we will italicize the first occurrence of each special term of art which should be familiar to those skilled in the art of network communication systems. In addition, when we first introduce a term that we believe to be new or that we will use in a context that we believe to be new, we will bold the term and provide the definition that we intend to apply to that term. In addition, throughout this description, we may use the terms assert and negate when referring to the rendering of a signal signal flag, status bit, or similar apparatus into its logically true or logically false state, respectively. In our Related Applications, we related, among other things, the following: While the number of single entity intra-nets continually increases, most multi-site entities utilize -public networks for inter-site transactions. Since the Internet is the best known of the public networks, we will tend to refer to it hereafter (or to its alter ego, the World Wide Web ("WWW")or just Web) for purposes of example. However, numerous Internet service providers or ISPs have set up their privately-owned networks so as to be semi-autonomous from the remainder of the Internet, thereby allowing their subscribers to exploit the many advantages inherent in such intra-ISP communication facilities. For our purposes, therefore, we intend the term "public network" to include any network to which a member of the public, in our case any business entity, can obtain access by payment of a periodic service fee. Thus, we distinguish such intra-ISP- networks from truly private networks that are owned and operated by single organizations, such as large corporations, and to which access is limited to only members (e.g., employees) of that organization (these we will refer to as "iNets"). For purposes of this application, we shall refer hereinafter to an employee connected to an iNet as if she were a client of the business systems that have been fully and completely disclosed in the First, Second, Third and Fourth Applications. A virtual private network ("VPN") is a private data network that makes use of the public telecommunication infrastructure, maintaining privacy through the use of a tunneling protocol and security procedures. A VPN can be contrasted with a system of owned or leased lines that can only be used by one company. The idea of the VPN is to give the company the same capabilities at much lower cost by using the shared public infrastructure rather than a private one. In theory, a VPN facilitates sharing of public resources for the secure exchange of private data. One major use of VPN is to enable secure communications between client servers connected to different, remotely located segments of a distributed iNet. For convenience of reference, we refer to the set of commonly owned client servers connected to a single, corporate-wide iNet as siblings. Using a VPN involves encrypting data before sending it through the public network and decrypting it at the receiving end. An additional level of security involves encrypting not only the data but also the originating and receiving network addresses. VPN software is typically installed as part of a company's firewall server. The Point-to-Point Tunneling Protocol 'PPTP") is one protocol that has been proposed to create a VPN using tunnels through the Internet. Each tunnel is the particular path that a given company message or file might travel through the Internet. Using PPTP, which is an extension of the Internet's Point-to-Point Protocol ("PPP"), any employee having a PC with PPP client support will be able to use any ISP to connect securely to the employer's server. This means that companies will no longer need their own leased lines for wide-area communication but could securely use the public networks. One primary function of a firewall is to render invisible from the Internet side all client servers that may be connected to the iNet side. We refer to think of such client servers as being cloaked by the firewall. One consequence of being cloaked is that a VPN can be initiated only by a cloaked client server. Accordingly, special procedures are required before a sibling client server connected to a remotely located segment of that iNet (or perhaps a mobile client server that is connected to the Internet via a temporary public connection) will be allowed to initiate a VPN with a cloaked client server. This problem is further exacerbated if the sibling client server is itself cloaked by a second firewall. What is needed is a general solution to secure communications between cloaked, sibling client servers and their respective clients. In general, chatting is talking to other people who are simultaneously using the Internet. In a typical chat session, messages entered at one site (using an input device such as a keyboard) are deposited into a message repository at a chat site, and then relayed to a group of users who take part from anywhere on the Internet. If desired, a private chat can be arranged between two parties.

Chat sites open to members of the public are often established by popular ISP's. Internet Relay Chat ("IRC") is a preferred protocol for performing various essential chat-related functions, such as establishing a chat group or channel or discovering existing chat groups and their members. The IRC protocol uses TCP, usually on port 6667. While current chat technology is sufficient to facilitate informal communication between chat users, it, by itself, is not sufficient to provide secure communication between users. Now, since the filing of our Related Applications, we have come to realize that, in addition to the deficiencies and problems related above, the following deficiencies and problems are present in currently-available Internet communication systems: In a typical iNet comprising multiple client servers organized into multiple tiers, a selected one of the servers, located at the logical root of the tree-like structure, is tasked with mamtairύng a master routing table ("RT") that must be constantly updated to reflect the status of each node in the structure. In such an arrangement all intra-net traffic must be routed by the root server. As a result, the entire system to vulnerable to catastrophic failure in the event the root server goes down. For reasons of system reliability, it would be preferable to provide a more distributed mechanism for maintaining the RT. In a typical multi-partition iNet, in which the iNet is partitioned into a plurality of interconnected sub-nets, each partition is managed by a respective partition server. Depending upon the size of the iNet, one or more higher levels of multi-partition servers may be provided to manage increasing larger combinations of sub-nets. At each level, one or more respective partition servers maintain the respective RTs for their sub-nets. In such an arrangement, the loss of one of the partition servers results in the effective loss of the entire sub-net until some higher lever partition server finally succeeds in reestabHshing communication with the surviving nodes of that sub-net. To minimize system recovery time, it would be preferable to provide a mechanism whereby a single master RT is coherently maintained within each server, thereby facilitating, in the event of loss of any one or more of the partition servers, rapid reconstruction of the balance of the iNet by the remaining partition servers. In the typical multi-tiered iNet wherein a plurality of servers are each responsible for managing a respective portion of the system RT, the workload on each server just to manage the RT increases rapidly as the total number of nodes in the structure varies over time (e.g., due to new machines coming on-line while others go off-line). This workload will be further increased if, in addition to reflecting simply node membership, the RT maintains node operating history information. For reasons of system workload management, it would be preferable to provide a more efficient mechanism for sharing the burden of maintaining the RT. BRIEF SUMMARY OF THE INVENTION In accordance with a preferred embodiment of our invention, we provide a method for operating, via the Internet, a network comprised of n nodes. According to our method, we first determine an address on the Internet of each of the nodes. We then create a routing table having, for each of the nodes, an entry comprising a first field that stores the IP address of the node. Once created, we store a copy of said routing table at each of said nodes. Thereafter, we can route all accesses by a first of the nodes to a second of the nodes using the copy of the routing table stored locally at the first node, thereby eliminating the requirement to provide centralized routing services. In accordance with another embodiment of our invention, we provide, in an n-node network, operated via the Internet, a distributed routing method.

According to our method we first determine an address on the Internet of each of the nodes. We then create a routing table having, for each of the nodes, an entry comprising a first field that stores the IP address of the node. Once created, we store a copy of said routing table at each of said nodes. Thereafter, we can route all accesses by a first of the nodes to a second of the nodes using the copy of the routing table stored locally at the first node, thereby eliminating the requirement to provide centralized routing services. In accordance with yet another embodiment of our invention, we provide a network, operated via the Internet, comprising n nodes, each including a common routing table. In accordance with our invention, each, copy of the common routing table comprises n entries, each entry corresponding to a respective one of the nodes. Preferably, each of the entries comprises a first field that stores an address on the Internet of the respective one of the nodes. Accordingly, we can route all accesses by a first of the nodes to a second of the nodes using the copy of the routing table stored locally at the first node, thus eliminating the requirement to provide centralized routing services. BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS Our invention may be more fully understood by a description of certain preferred embodiments in conjunction with the attached drawings in which: Figure 1 illustrates in block diagram form a business system adapted to provide a virtual VPN (" WPN") as set forth in our Related Applications; Figure 2 illustrates in block diagram form an iNet configured as a ring of stars ("RoS") which is managed using a common routing table ("CRT); Figure 3 illustrates in diagrammatic form one possible instantaneous • topology of the RoS shown in Figure 2; Figure 4 illustrates in time flow diagram form the manner in which the RoS shown in Figure 2 responds to a first abnormal operation ("Case 1"); Figure 5 illustrates in time flow diagram form the manner in which the RoS shown in Figure 2 responds to a second abnormal operation ("Case 2"); Figure 6 illustrates in time flow diagram form the manner in which the RoS shown in Figure 2 responds to a third abnormal operation ("Case 3"); Figure 7 illustrates in time flow diagram form the manner in which the RoS shown in Figure 2 responds to a fourth abnormal operation ("Case 4"); Figure 8 illustrates in time flow diagram form the manner in which the RoS shown in Figure 2 responds to a fifth abnormal operation ("Case 5"); Figure 9 illustrates an RoS comprising four (4) servers and fifteen (15) clients, prior to performing a load balancing operation; and Figure 10 illustrates an RoS comprising four (4) servers and fifteen (15) clients, subsequent to performing the load balancing operation. DETAILED DESCRIPTION OF THE INVENTION Shown in Figure 1 is a business system 2 having a server 4 that can be accessed electronically via the Internet 6 by a plurality of businesses, including for example a first client 8, and a second client 10. Each member business may subscribe for any of the several services available from our server 4. A number of such services are described in our First, Second and Third Applications. One additional service, described in our Fourth Application, is the creation and maintenance of WPNs to facilitate secure communication between clients, at least some of which are behind local firewalls. However, as the number of clients increases and the set of available services expands, the workload that is placed on the server 4 will eventually exceed its ability to provide timely service to all clients. At some point, additional server capacity must be added to the system 2. Balancing the workload among the available servers then becomes an problem that must be resolved. Shown in Figure 2 is a multi-node iNet configured as a ring of stars that we shall refer to as RoS 12. In RoS 12, a first server, S₁ 14, provides, at a minimum, VVPN services to three (3) clients, C_α 16, C₂ 18 and C₃ 20, and a second server, S₂ 22, provides, at a minimum, VVPN services to three (3) clients, C₄ 24, C₅ 26 and C₆ 28. In contrast to the de minimus RoS 12, we have shown in Figure 9 a larger, more complex RoS 30. In general, we prefer to classify our RoS iNets according to the numbers of servers vis-a-vis clients: using such a taxonomy, for example, RoS 12 would be classified as a "2-server x 6-client RoS", or simply as a "2x6 RoS", whereas RoS 30 is a 4:ci5 RoS. We will defer for now further discussion of RoS 30. In accordance with the preferred embodiment of our invention, the management of the set of all connections among the several nodes comprising RoS 12 is accomplished using a single, iNet-specific routing table, iRT 32 (see, Figure 2) that contains the pertinent information relating to each node-to-node connection. In contrast to existing iNet implementations, each of the nodes in RoS 12, including both the servers and the clients, maintains a local copy of the iRT 32. We shall discuss below, on a case-by-case basis, our preferred mechanism for assuring coherency among the several copies. By way of example, we have shown in Figure 3 one possible topology of RoS 12, wherein, at the illustrated instant: 16 is having a session with C₄ 24 over a fully open connection; C₂ 18 is having a session with C₅ 26 with the assistance of S₂ 22, wherein the connection between C₂ 18 and S₂ 22 is open but the connection from S₂ 22 to C₅ 26 is a closed VVPN connection; S₁ 14 is having a session with C₃ 20 over a WPN connection; and C₆ 28 is on-line but is not currently in session.

Since all nodes of RoS 12 maintain local copies of the iRT, any node can, in general, contact any other node without relying on the services of a router. The only exception is if the desired node has gone off-line since the last update of the iRT 32. Note that those nodes which are behind firewalls are, at least from the perspective of any other node of RoS 12, still directly accessible simply by using the IP address of the respective VVPN server stored in the local copy of the iRT 32. In accordance with the invention disclosed in our Fourth Application, direct access to a client that is located behind a firewall can only be made via a VVPN that has been established, and thereafter maintained, by a respective ser er. At the ins nf- iUiistrated Figure 2, S, 14 is providing VVPN services to only one of its clients, namely C₃ 20, while S₂ 22 is providing WPN services to only one of its clients, namely C₅ 26. To distinguish in the drawings between normal open connections and VVPN connections we have depicted the former using solid lines and the latter using dashed lines. To distinguish in the iRT 32 between normal open connections and VVPN connections we tag the former with the letter "O" in the connections ("C") column and the latter using the letter "V". (See, e.g., Figure 2.) The remaining fields of the iRT 32 consist, at a minimum, of: the logical name ("ID") of the respective node; the current static IP address of the node; and, finally, the ID of the node ("Server") which has been assigned the task of providing services, such as WPN, to the respective node. Preferably, the responsibility for maintaining a client entry in the iRT 32 is assigned to that client's Server; similarly, responsibility for maintaining the entry for each server is assigned to a designated one of the other servers. Since a coherent copy of the iRT 32 is maintained within every node of the RoS 12, any client which may find itself isolated because of the failure of its Server, can immediately reestablish contact with the Server assigned to the now-lost Server (a process we call "walking the iRT"). Similarly, if a server, say S_x 14, should discover that the other server, S₂22, is off-line, it can immediately initiate recovery procedures to reestablish the connections to those clients who were being serviced by S₂ 22. Let us now show, on a case-by-case basis, how this recovery mechanism works. Case 1: In Case 1, illustrated in Figure 4, C_α 16 is initially having a normal dialog with C₂ 18 over an open connection. Suddenly, C₂ 18 fails to timely respond to a request from 16. Consulting its local copy of the iRT 32, 16 finds that the Server for C₂ 18 is S_x 14. C_α 16 then issues a corresponding fault report to S_x 14. Upon receiving this fault report, S_α 14 will initiate a procedure designed to verify that C₂ 18 is indeed no longer on-line. Such a procedure will be implementation dependent, but, in general, will consist of one or more attempts to contact C₂ 18. If, at the completion of the verification procedure, S₁ 14 is unable to reestablish contact with C₂ 18, S₁ 14 will update in the local copy of the iRT 32 the entry for C₂ 18. As soon as possible thereafter, S_x 14 will distribute that update fiist to S₂ 22, and then, in a predetermined order, to its other clients, namely C_t 16 and C₃ 20. (Remember that C₂ 18 is off-line and thus can not be contacted.) Upon receiving the update from S_t 14, S₂ 22 will immediately update its local copy of the iRT 32, and then distribute that update to its clients, namely C₄ 24, C₅ 26 and C₆ 28. Upon receiving the update, each of the clients will immediately update its local copy of the iRT 32. Thus, the update to the iRT 32 is quickly and efficiently distributed throughout the RoS 12. As a result of the updates, RoS 12 is now a 2x5 RoS. Note that 16, the reporting client, changes its local cop}⁷ of the iRT 32 only as result of receiving a proper update request from its server. Thus, if the problem was transient in nature and S_t 14 found no problem in the link to C₂ 18, there would have been no unnecessary changes anywhere in the RoS 12. In such a case, it would be desirable for S_x 14 to so notify C- 16 so that the latter can retry the earlier-faulted transaction with C, 18. Case 2: In Case 2, illustrated in Figure 5, C_x 16 is initially having a normal dialog with C₄ 24 over an open connection. Suddenly, C₄ 24 fails to timely respond to a request from <Z_X 16. Consulting its local copy of the iRT 32, C_α 16 finds that the Server for C₄ 24 is S₂ 22. 16 then issues a corresponding fault report to S₂ 22, preferably without going through S 14. Upon receiving this fault report, S₂ 22 will initiate a procedure designed to verify that C₄ 24 is indeed no longer on-line. Such a procedure will be implementation dependent, but, in general, will consist of one or more attempts to contact C₄ 24. If, at the completion of the verification procedure, S₂ 22 is unable to reestablish contact with C₄ 24, S₂ 22 will update in the local copy of the iRT 32 the entry for C₄24. As soon as possible thereafter, S₂ 22 will distribute that update first to S_t 14, and then, in a predetermined order, to its other clients, namely C₅ 26 and C₆ 28. (Remember that C₄24 is down and thus can not be contacted.) Upon receiving the update from S₂ 22, S_α 14 will immediately update its local copy of the iRT 32, and then distribute that update to its clients, namely C_x 16, C₂ 18, and C₃ 20. Upon receiving the update, each of the clients will immediately update its local copy of the iRT 32. Thus, as in Case 1, the update to the iRT 32 is quickly and efficiently distributed throughout the RoS 12. As a result of these updates, RoS 12 is now also a 2:3 RoS, but it has a different topology than in Case 1. Case 3: In Case 3, illustrated in Figure 6, S_j 14 is initially having a normal dialog with C₍ 16 over an open connection. Suddenly, C_j 16 fails to timely respond to a request from S_α 14. Consulting its local copy of the iRT 32, S_α 14 finds that it itself is the Server for 16. Accordingly, S₁ 14 will immediately initiate a procedure designed to verify that C_α 16 is indeed no longer on-line. Such a procedure will be implementation dependent, but, in general, will consist of one or more attempts to contact C_α 16. If, at the completion of the verification procedure, S_x 14 is unable to reestablish contact with C_t 16, S_t 14 will update in the local copy of the iRT 32 the entry for 16. As soon as possible thereafter, S_j 14 will distribute that update first to S₂ 22, and then, in a predetermined order, to its other clients, namely C₂ 18 and C₃ 20. (Remember that C_α 16 is down and thus can not be contacted.) Upon receiving the update from S₁ 14, S₂22 will immediately update its local copy of the iRT 32, and then distribute that update to its clients, namely C₄ 24, C₅ 26 and C₆ 28. Upon receiving the update, each of the clients will immediately update its local copy of the iRT 32. Thus, the update to the iRT 32 is quickly and efficiently distributed throughout the RoS 12. As a result of these updates, RoS 12 is yet another 2x5 RoS, but it has a different topology than in either Case 1 or Case 2. Case 4: In Case 4, illustrated in Figure 7, 16 is initially having a normal dialog with S_α 14 over an open connection. Suddenly, S_α 14 fails to timely respond to a request from 16. Walking its local copy of the iRT 32, 16 finds that the Server for S_α 14 is S₂ 22. 16 then issues a corresponding fault report directly to S₂ 22. Upon receiving this fault report, S₂22 will initiate a procedure designed to verify that S₁ 14 is indeed no longer on-line. Such a procedure will be implementation dependent, but, in general, will consist of one or more attempts to contact S₁ 14. If, at the completion of the verification procedure, S₂ 22 is unable to reestablish contact with S₁ 14, S₂ 22 will update in the local copy of the iRT 32 the entry for S_α 14. In addition, however, S₂ 22 will update the entries in the iRT 32 for all of the current clients of S_x 14, namely 16, 18 and C₃ 20, to indicate that thereafter S₂ 22 will be their Server. As soon as possible thereafter, S₂ 22 will distribute all of these updates, in a predetermined order, to all of its client , namely C_x 16, C₂ 1G, C, 20, 24, C₅ 26 and C₆ 2G. Upon receiving the updates, each of the clients will immediately update its local copy of the iRT 32. Thus, as in Case 1, Case 2 and Case 3, the update to the iRT 32 is quickly and efficiently distributed throughout the RoS 12. As a result of these updates, RoS 12 is now a 1x6 RoS. Case 5: In Case 5, illustrated in Figure 8, S_α 14 is initially having a normal dialog with S₂ 22 over an open connection. Suddenly, S₂ 22 fails to timely respond to a request from S_α 14. Consulting its local copy of the iRT 32, S_α 14 finds that the Server for S₂ 22 is itself. S_λ 14 then initiates a procedure designed to verify that S₂ 22 is indeed no longer on-line. Such a procedure will be implementation dependent, but, in general, will consist of one or more attempts to contact S₂ 22. If, at the completion of the verification procedure, S_x 14 is unable to reestablish contact with S₂ 22, S_α 14 will update in the local copy of the iRT 32 the entry for S₂ 22. In addition, however, S_α 14 will update in the local copy of the iRT 32 the entries for all of the current clients of S₂ 22, namely C₄24, C₅ 26 and C₆ 28, to indicate that thereafter S₁ 14 will be their Server. As soon as possible thereafter, S_t 14 will distribute all of these updates, in a predetermined order, to all of its clients, namely 16, C₂ 18, C₃ 20, C₄ 24, C₅ 26 and C₆ 28. Upon receiving the updates, each of the clients will immediately update its local copy of the iRT 32. Thus, as in Case 1, Case 2, Case 3 and Case 4, the update to the iRT 32 is quickly and efficiently distributed throughout the RoS 12. As a result of these updates, RoS 12 is now also a 1x6 RoS, but it has a different topology than in Case 4. As mentioned briefly above, shown in Figure 9 is the 4x15 RoS 30 and the associated iRT 34. As can be seen in both the topographic diagram and the iRT 34: a first server, S 36, provides, at a minimum., VVPN and update services to four (4) clients, namely 38, C₂ 40, C₃ 42 and C₄ 44; a second server, S₂ 46, provides, at a minimum, VVPN and update services to four (4) clients, namely C₅ 48, 50, C₇ 52 and C₈ 54; a third server, S₃ 56, provides, at a minimum., VVPN and update services to three (3) client, namely C, 58, C_{I (J} 60 and C_n 62; i i a fourth server, S_i 64, provides, at a minimum, VVP and update services to four (4) clients, namely C₁₂ 66, C_rj 68, C_u 70 and C₁₅ 72. At the illustrated instant: S_α 36 is providing VVPN services to both C₂ 40 and C₃ 42; 5₂ 46 is providing VVPN services to only 50; 5₃ 56 is providing WPN services to none of its clients; and 5₄ 64 is providing WPN services to only C₁₄ 70. Since it requires significant resources of a server to maintain a WPN connection, let us assume that, as a result of having to simultaneously maintain two (2) VVPN connections, S_t 36 has just determined that its response time to its clients has fallen below a predetermined minimum response time. In response, S_j 36 sends to its Server, namely S₂46, a request to transfer responsibility for servicing, for example, C₄ 44. Upon receiving the transfer request, S₂46 determines if it has sufficient available resources to assume responsibility for an additional normal (i.e., non- VVPN) client. Preferably, this determination would take into account both the current workload of S₂ 46 and the anticipated load imposed by such a client.

Both numbers can be determined either statically, using best estimates (e.g., the number of clients), or dynamically, by continuously monitoring the actual loading patterns of each of the nodes of the RoS 30. In this regard, such information can be conveniently maintained for each node in respective, additional columns of the iRT 34 (not shown). Let us assume, for this example, that S₂46 decides that, because of the load imposed by the WPN connection it is maintaining with 50, assuming responsibility for C₄ 44 would unreasonably jeopardize its ability to timely service its existing clients. Instead, S₂ 46 forwards the transfer request to its Server, namely S₃ 56. Upon receiving the transfer request, S₃ 56 determines if it has sufficient available resources to assume responsibility for C₄44. For this example, we will now assume that S, 56 decides that, because it has only three (3) normal clients to service, it is indeed in a position to assume responsibility for C₄ 44 and stall provide timely services to all four (4) clients. Consulting its local copy of the iRT 34, it retrieves the ID of the Server for 44, namely S, 36. S₃ 56 then sends a transfer approval to S_α 36. In response to receiving the transfer approval from S₃ 56, S_x 36 will send a transfer notice to C₄44 indicating that it should contact S₃ 56 for further services. Upon successfully establishing contact with C₄44, S₃ 56 will then update the entry in the iRT 34 for C₄ 44 to show that it is now the Server for C₄ 44. Using the ' update distribution mechanism described above, S₃ 56 will then distribute the update to the other nodes of RoS 30. The resulting topology and associated iRT are shown in Figure 10. In addition to being effective in dynamically balancing workload to relieve local over-loading, the same mechanism can be used equally effectively to dynamically assign to an appropriate server a node that desires to join an established RoS. Similarly, when a node drops out for any reason, the same general mechanism can be advantageously employed in reverse to transfer workload from a relatively loaded server to a now-under-loaded server. If, as we described above, the iRT 34 is expanded to accommodate recent workload history for servers as well as clients, such workload balancing decisions can be made quite efficiently. Those skilled in the art will recognize that modifications and variations can be made without departing from the spirit of our invention. Therefore, we intend that our invention encompass all such variations and modifications as fall within the scope of the appended claims.

Claims

CLAIMS What we claim is:

1. A method for operating, via the Internet, a network comprised of n nodes, the method comprising: determining an address on the Internet of each of said nodes; creating a routing table having, for each of said nodes, an entry comprising: a first field that stores said address of said node; storing a copy of said routing table at each of said nodes; and routing all accesses by a first of said nodes to a second of said nodes using said copy of said routing table stored at said first node.

2. The method of claim 1, wherein: upon creating said routing table, a unique identifier is assigned to each of said nodes; and wherein each entry in said routing table further includes: a second field that stores said identifier of said node.

3. The method of claim 2 wherein: said first node provides a first selected service to said second node.

4. The method of claim 3 wherein each entry in said routing table includes: a third field that stores the address on the internet of a selected one of said nodes other than the node corresponding to said entry; and wherein: said third field of said entry for said second node stores the address o£ said first node; whereby, using the copy of the routing table stored in the second node, the second node can request the first selected service from the first node via the address stored in the third field of the entry for the second node.

5. The method of claim 4 wherein, as said first selected service, said first node creates, and thereafter selectively destroys, a virtual private network (VPN) connection over the Internet for said second node.

6. The method of claim 5, wherein: upon creating said VPN connection, said first node stores in said first field of said entry for said second node said address of said first node; and upon destroying said VPN connection, said first node stores in said first field of said entry for said second node said address of said second node.

7. The method of claim 6, wherein said routing table further includes: a fourth field that stores an indicator indicating that said node is connected to the Internet via an open connection; and wherein: upon creating said VPN connection, said first node stores in said fourth field of said entry for said second node an indicator indicating that said second node is connected to the Internet via a VPN connection; and upon destroying said VPN connection, said first node stores in said fourth field of said entry for said second node an indicator indicating that said second node is connected to the Internet via an open connection.

8. The method of claim 7, wherein: a third node provides a second selected service to said first node.

9. The method of claim 8, wherein: said third field of said entry for said first node stores the address of said third node; whereby, using the copy of the routing table stored in the first node, the first node can request the second selected service from the third node via the address stored in the third field of the entry for the third node.

10. The method of claim 9 wherein, as second selected service, said third node provides said first selected service to said second node if said first node is unavailable to provide said first selected service; whereby, if the first node is unavailable to provide the first selected service to the second node, then, using the copy of the routing table stored in the second node, the second node can request the first selected service from the third node via the address stored in the third field of the entry for the third node.

11. In an n-node network, operated via the Internet, a distributed routing method comprising: determining an address on the Internet of each of said nodes; creating a routing table having, for each of said nodes, an entry comprising: a first field that stores said address of said node; storing a copy of said routing table at each of said nodes; and routing all accesses by a first of said nodes to a second of said nodes using said copy of said routing table stored at said first node.

12. The method of claim 11, wherein: upon creating said routing table, a unique identifier is assigned to each of said nodes; and wherein each entry in said routing table further includes: a second field that stores said identifier of said node.

13. The method of claim 12 wherein: said first node provides a first selected service to said second node.

14. The metliod of claim 13 wherein each entry in said routing table includes: a third field that stores the address on the Internet of a selected one of said nodes other than the node corresponding to said entry; and wherein: said third field of said entry for said second node stores the address of said first node; whereby, using the copy of the routing table stored in the second node, the second node can request the first selected service from the first node via the address stored in the third field of the entry for the second node.

15. The method of claim 14 wherein, as said first selected service, said first node creates, and thereafter selectively destroys, a virtual private network

(VPN) connection over the Internet for said second node.

16. The method of claim 15, wherein: upon creating said VPN connection, said first node stores in said first field of said entry for said second node said address of said first node; and upon destroying said VPN connection, said first node stores in said first field of said entry for said second node said address of said second node.

17. The method of claim 16, wherein said routing table further includes: a fourth field that stores an indicator indicating that said node is connected to the Internet via an open connection; and wherein: upon creating said VPN connection, said first node stores in said fourth field of said entry for said second node an indicator indicating that said second node is connected to the Internet via a VPN connection; and upon destroying said VPN connection, said first node stores in said fourth field of said entry for said second node an indicator indicating that said second node is connected to the Internet via an open connection.

18. The method of claim 17, wherein: a third node provides a second selected service to said first node.

19. The method of claim 18, wherein: said third field of said entry for said first node stores the address of said third node; whereby, using the copy of the routing table stored in the first node, the first node can request the second selected service from the third node via the address stored in the third field of the entry for the third node.

20. The method of claim 19 wherein, as second selected service, said third node provides said first selected service to said second node if said first node is unavailable to provide said first selected service; whereby, if the first node is unavailable to provide the first selected service to the second node, then, using the copy of the routing table stored in the second node, the second node can request the first selected service from the third node via the address stored in the third field of the entry for the third node.

21. A network, operated via the Internet, comprising: n nodes, each including a common routing table, said common routing table comprising n entries, each entry corresponding to a respective one of said nodes, each of said entries comprising: a first field that stores an address on the Internet of said respective one of said nodes; whereby all accesses by a first of said nodes to a second of said nodes may be routed using said copy of said routing table stored at said first node.

22. The network of claim 21 wherein each of said entries further comprises: a second field that stores a unique identifier assigned to said respective one of said nodes.

23. The network of claim 22 wherein: said first node provides a first selected service to said second node.

24. The network of claim 23 wherein each of said entries further comprises: a third field that stores the address on the Internet of a selected one of said nodes other than said respective node; whereby, using the copy of the routing table stored in the second node, the second node can request the first selected service from the first node via the address stored in the third field of the entry for the second node.

25. The network of claim 24 wherein, as said first selected service, said first node creates, and thereafter selectively destroys, a virtual private network

(VPN) connection over the Internet for said second node.

26. The network of claim 25, wherein: upon creating said VPN connection, said first node stores in said first field of said entry for said second node said address of said first node; and upon destroying said VPN connection, said first node stores in said first field of said entry for said second node said address of said second node.

27. The network of claim 26, wherein said each of said entries further includes: a fourth field that stores an indicator indicating that said respective node is connected to the Internet via an open connection; and wherein: upon creating said VPN connection, said first node stores in said fourth field of said entry for said second node an indicator indicating that said second node is connected to the Internet via a VPN connection; and upon destroying said VPN connection, said first node stores in said fourth field of said entry for said second node an indicator indicating that said second node is connected to the Internet via an open connection.

28. The network of claim 27, wherein: a third node provides a second selected service to said first node.

29. The network of claim 28, wherein: said third field of said entry for said first node stores the address of said third node; whereby, using the copy of the routing table stored in the first node, the first node can request the second selected service from the third node via the address stored in the third field of the entry for the third node.

30. The network of claim 29 wherein, as second selected service, said third node provides said first selected service to said second node if said first node is unavailable to provide said first selected service; whereby, if the first node is unavailable to provide the first selected service to the second node, then, using the copy of the routing table stored in the second node, the second node can request the first selected service from the third node via the address stored in the third field of the entry for the third node.