JP4426183B2 - Logical routing control system - Google Patents

Description

  The described techniques generally relate to the mapping of logical identifiers to physical identifiers.

  An application program such as a Web browser accesses a resource (resource) using the HTTP protocol. The HTTP protocol uses a Uniform Resource Identifier (“URI”) to identify resources to be accessed. The URI is a Uniform Resource Locator (“URL”) or Uniform Resource Name (“URN”), or any other formatted string that identifies a network resource. It is. A URL as an example of a URI is described in detail in (Non-Patent Document 1). Each URL includes a domain name that identifies where the resource is located. For example, the URL “http://www.odi.com/home.html” indicates that the resource named “home.htm” is located in the domain “odi.com”. The HTTP protocol uses an underlying transport layer, such as TCP / IP, to route messages to the computer associated with the domain name identified by the URL. However, the TCP / IP protocol identifies a computer using an IP address (eg, “128.32.0.6”) instead of a domain name. Various computer technologies have been developed to map high level identifiers such as domain names to low level identifiers such as IP addresses.

  One such technique is implemented by the Domain Name Service (“DNS”) provided as part of the TCP / IP protocol suite used by the Internet. DNS is a name service that maps domain names to IP addresses. When an application sends a message to a domain name using the HTTP protocol, it issues a resolution request that specifies the domain name to a local domain name server (eg, provided by an ISP) that is part of DNS. hand in. The local domain name server can be identified in the configuration file of the client computer running the browser. The local domain name server consults the local cache to determine whether it has a mapping of that domain name to an IP address. If so, the local domain name server returns its IP address to the application. If not, the local domain name server forwards the resolution request to the root domain name server. The root domain name server contains a mapping of each top level domain name (eg, “com”) to its name server. The root domain name server responds to the resolution request by providing the name of the top level domain name server to the local domain name server. The local domain name server caches the name of the top level domain name server. The local domain name server then sends a resolution request to the top level domain name server, and the name of the domain name server with respect to the second level domain name (eg, “odi.com”). (Also can be cached). The local domain name server forwards the resolution request to the domain name server for the second level domain name. The domain name server returns the IP address associated with the second level domain name. Alternatively, the domain name server returns the name of the domain name server for the third level domain name (eg, “www.odi.com”), and the local domain name server It is possible to repeat the process for each level of domain name. Finally, the local domain name server sends the IP address of the domain name to, for example, a computer that executes the application.

T. Berners-Lee et al., Uniform Resource Locators (URL), RVC 1738, CERN, Xerox PARC, Univ. Of Minn., December 1994

Methods and systems for mapping logical identifiers to physical identifiers are provided. In one embodiment, the logical routing system is configured so that each application or each entity (eg, a user of the application) has its own logical identifier to the physical identifier when the application starts running on the computer. Allows you to register mappings. In order to send a message to the application identified by the logical identifier, the client program uses the registered mapping to identify the physical identifier of the computer. If the application then starts running on a different computer, the application can register another mapping. In one embodiment, the logical routing system allows an application to register a function that is used to generate a physical identifier for the logical identifier associated with the application. The use of functions allows the mapping to physical identifiers to change based on various criteria such as the location of the client computer or the workload balancing goal. The logical path control system also allows logical identifiers to be mapped to multiple physical identifiers. Using such a mapping, the client program will send a message to each of the computers identified by the plurality of physical identifiers.

  FIG. 1 is a block diagram for illustrating a logical path control system according to an embodiment. This logical routing system is used to send messages between a client computer system 101 (“client node”) and an application computer system 103 (“application node”). The computer systems are connected to each other via a communication mechanism 104 such as the Internet. An application running on the application node provides a service to a client program running on the client node. A logical routing system allows a client node to send a message to an application (eg, request an application service) by a logical identifier (also referred to as “node identifier”) rather than a physical identifier (also referred to as “node identifier”). By providing a logical naming mechanism that allows transmission. For example, the logical identifier of the application can be an “address book”, while the physical identifier can be a globally unique identifier that uniquely identifies the node on which the application is running. is there. (This description uses “address book” as an exemplary application. The address book application maps a person's name (eg, John Smith) to an email address (eg, JohnSmith@company.com). The address book application receives a message from a client program requesting an individual's email address and sends a response message containing the email address to the client program.) Client node (or More precisely, when a computer program (running on a client node) wants to send a message to an application, the message is logically routed with the logical identifier of the application To provide to your system. The logical routing system identifies the appropriate physical identifier of the node where the application is running and sends a message to that node. An application registers with the logical routing system when it starts executing at an application node. The logical routing system can maintain a mapping from the logical identifier of the application to the physical identifier of the application node on which the application is running. The client node can use this mapping to identify the physical identifier of the application from the logical identifier. Logical identifiers can be mapped to multiple physical identifiers for individual application nodes. For example, multiple copies of the address book application can be running on different application nodes to handle multiple requests of the client program. If the client program wants to retrieve an address, the logical identifier of the address retrieval function can map to only one physical identifier. In contrast, if the client program wishes to insert an address, the logical identifier of the address insertion function can be mapped to the physical identifier of all nodes on which the application is running. Thus, the logical routing system allows a client program to be developed using the application's logical identifier, and allows the logical identifier to be resolved to a physical identifier during execution of the client program. Provide a mechanism to A program executed on a node can respond to a request for service from a client program and can request a service from another application, and can be both an application and a client program. It will be recognized by engineers in the field.

The application registers itself with the logical routing system and maps its logical identifier to a physical node identifier. The logical routing system can maintain these registered logical routing maps. A logical routing system implements a logical routing map across multiple application nodes and multiple client nodes in a distributed manner, implements a logical routing map as a central system, or Logical routing maps can be implemented with a combination of distributed and centralized systems. When an application registers with a logical routing control system, it can send a registration message to a logical destination that identifies the logical routing control map (eg, a “logical routing map”). Similarly, when a client program sends a message to an application, the logical routing system can send the message to the same logical destination to retrieve the physical identifier for that application. More generally, a logical routing map can be considered an “application” that is not only used by the logical routing system, but also accessible through the logical routing system itself.

  In one embodiment, the logical routing map has, for each logical name, a node identification function that returns the node identifier of the node associated with that logical name. When the application associated with the logical name is registered in the logical routing system, it provides its own node identification function to the logical routing system. The node identification function can input parameters or criteria (eg, a message to be sent) and returns an appropriate node identifier that meets the parameters or criteria. For example, an application associated with a logical name can be running at a node physically located on each continent. The node identification function can enter the country where the sending node is located and return a node identifier for the node located on the continent where the country is located.

The logical routing system allows the mapping between logical identifiers and physical identifiers to be changed dynamically. The mapping can be changed dynamically in various ways. For example, an application can dynamically change its mapping by registering a new node identification function, and the new node function can send a client program to a node that executes a client program in response to a service request. It can be sent by a program. A node that receives a new node identification function can replace the old node identification function for that application. The logical routing system can transmit the mapping using an existing network. For example, the existing network can be an Internet IP network and DNS . In such a case, the logical identifier is mapped to a DNS name (ie, physical identifier) by the logical routing system, and finally to an IP address (ie, network address) by the existing network transport system. Is possible. The dynamic change of the mapping makes it possible to meet the demand to meet the demand dynamically. For example, as demand for an address book application increases, the application can be launched at additional nodes. A new identification function sent to the node executing the client program can distribute some of the requests to additional nodes. Similarly, as demand decreases, the number of nodes running the address book application can be reduced.

  Logical routing systems use various criteria to route messages. The logical routing system may allow criteria to be provided by a client program or by an application that provides a service. For example, a client program can specify a priority associated with a request, and a node identification function identifies a node that can service the request of that priority. This application can specify that a client in a country has all requests sent to a node. The logical routing system allows for criteria-based routing to one of multiple copies of an application that uses the same logical name. For example, to improve communication speed, the application's node identification function can select a physical identifier for a node that is geographically close to the client program's node. The logical routing system also allows application services to be distributed across multiple nodes. For example, an address book application can be run on multiple nodes, each serving address requests associated with different parts of the alphabet. It is possible for one node to service requests for names starting with A-M and another node to service requests for names starting with N-Z.

  In one embodiment, the logical routing system may use a distributed model to maintain a mapping of logical identifiers to physical identifiers (eg, node identification function). In such a distributed model, each node maintains a mapping for the application that runs on that node. When another node receives the mapping (eg, because the client program of this other node is sending a message to the application), that other node can cache the mapping. The logical routing system can search for a mapping by sending a search request to the connected node. Each node that receives the search request checks its local cache for the mapping. If so, the node sends the mapping to the requesting node. If not, the node forwards the search request to the node group to which it is connected. Each node that receives a mapping on its way to the requesting node can cache the mapping. (This search automatically finds the topology of the network.) A node executing a client program may discover that the application is no longer available when the client program sends a message to the application. is there. Once such a discovery is made, the logical routing system can remove the mapping from its cache. This search message is an example of a logical routing system that supports node level messages. Thus, the logical routing system supports both node level messages and application level messages.

  In another embodiment, the logical routing system can use a combination of distributed and centralized models to maintain the mapping. In addition to maintaining the mapping at each node, the logical routing system can have a server node that stores all mappings. Each application registers its own logical identifier in the logical path control system. The logical routing system can cache the mapping of the logical identifier to the physical identifier locally at the node and send the mapping to the server node. When a client program sends a message to a logical identifier, the logical routing system can first examine the mapping's local cache. If the logical identifier does not exist in the local cache, the logical routing system can request the mapping from the server node. If the server node is not available, the logical routing system can search the mapping in the same way as the distributed model.

  The logical identifier can identify the user. When a user logs on to an application or node, the user can be registered with the logical routing system using a logical identifier such as the user's name. If another user wants to send a message to that user, that other user uses the logical identifier to identify the user to the logical routing system. The logical routing system transmits the message to the user in the same way as it transmits the message to the client program. In practice, the logical routing system can send a message to a client program that is responsible for displaying the message to the user.

In one embodiment, the logical routing system performs mapping from logical identifiers to physical identifiers, and the transport system performs mapping from physical identifiers to network addresses. However, those skilled in the art will appreciate that this physical identifier may be the final identifier used by the transport system. (For example, this physical identifier may be a network address.) In such a case, the transport system does not perform any mapping and routes the message to the node identified by that physical identifier. It will also be appreciated by those skilled in the art that the functions of the logical routing system can be integrated into the transport system, or even considered part of the physical layer.

  FIG. 2 is a flowchart showing processing when a client program transmits a message to an application. At block 201, when an application starts execution, it registers its logical identifier and the physical identifier of the node on which the application is currently executing in the logical routing system. (The client program also registers in a similar manner.) In one embodiment, instead of registering the actual physical identifier, a node identification function is registered. Whenever a physical identifier is required, the node identification function is called, passing the message to be sent, and one or more physical identifiers are returned. For example, an address book application has as its node identification function a node that maps a person's last name to the physical identifier of the node running the instance of the application that is responsible for responding to requests with that last name. It is possible to register an identification function. At block 202, the logical routing system stores a mapping of logical identifiers to node identification functions for the application. At block 203, the client program calls the logical routing system to send a message to the application identified by the logical identifier. At block 204, the logical routing system identifies the physical identifier using the logical routing mapping. The logical routing system at the client node invokes the node identification function passing the message. The node identification function returns the physical identifier associated with the application instance. The logical routing system sends a message to the node addressed by its physical identifier. When the logical routing system at the application node receives the message, it can determine whether the message should be forwarded to another node or processed at that node. The logical routing system at the application node can use the node identification function to identify the node that should process the message. At block 206, assuming that the message is to be processed at that node, the application processes the message. At block 207, the application sends a response to the client node using the logical routing system. The logical routing system can also send an updated node identification function to the client node. The client node receives the response and the updated node identification function. The logical routing system at the client node uses the updated node identification function in passing the response to the client program and sending subsequent messages to the logical identifier. The updated node identification function can reflect architectural changes in how applications are distributed across multiple application nodes.

  FIG. 3 is a block diagram illustrating a logical path control system in which an instance of an application is executed in a plurality of nodes. The application is running on application nodes 303, 305, and 306. The application was initially running only one instance at application node 303. As the demand for the address book service increases, application nodes 305 and 306 are brought online and start running instances of the application. Application node 303 serves requests for names starting with the letters A through J, application node 305 services requests for names beginning with the letters K through S, and application node 306 with letters TZ. Serves requests for names that begin. Continuing the example of FIG. 2, if the client program wishes to request an address for “John Smith”, the logical routing system uses a node identification function for the logical identifier for “address book”, thereby Application node 303 is identified. The logical routing system sends the request to the application node 303. When the logical routing system in application node 303 receives the request, it identifies application node 305 using its node identification function. The logical routing system of application node 303 forwards the request to application node 305 where the logical routing system provides the message to the application. An instance of an application running on application node 305 retrieves the email address and sends the address to the client node. The logical routing system of application node 305 maps names that begin with letters A through J to application node 303, maps names that begin with letters K through S into application node 305, and names that begin with letters T through Z An updated node identification function that maps to the application node 306 can also be sent to the client node. In this way, the client node logical routing system identifies the appropriate application node responsible for servicing the request the next time it uses the updated node identification function, and identifies the application that identified the request.・ Send directly to the node. Alternatively, if application node 305 does not send an updated node identification function, subsequent requests are routed through application node 303. If multiple instances of an application provide the same functionality, the node identification function can randomly select a physical identifier for the instance, select a physical identifier based on the geographical proximity of the client node, etc. .

  FIG. 4 is a block diagram illustrating the use of a node identification function that provides load balancing for an application. The client node 401 uses a node identification function that maps to one of the load balancing nodes 402. For example, the node identification function can randomly select one of the load balancing nodes. The node identification function used by the client node can be provided by the load balancing node. When a load balancing node receives a request from a client node, it uses different node identification functions provided by the application to identify the application node 403 that should service the request. For example, there can be multiple instances of an address book application that service requests for names that begin with AJ. Each load balancing node can decide to which of these instances the request is sent.

  FIG. 5 illustrates the architecture of an application layer 510, a logical routing layer 520, and a physical routing layer 530 used by the logical routing system in one embodiment. It is a block diagram. Those skilled in the art will recognize that the functions and data structures of these layers can be tailored to the requirements of any particular implementation of the logical routing system. The logical routing system corresponds to the functionality provided by the logical routing layer in one embodiment. The physical routing layer is responsible for sending messages to the node identified by the node identifier. Each node in the network can be assigned a unique node identifier. The physical routing layer provides a send message component 531 and a receive message component 532. The logical routing layer sends a message using the message sending component and receives the message via the message receiving component. The message sending component is passed a message and a destination node identifier (eg, “www.odi.com”) to find the network address (eg, IP address and port) for that destination node identifier. The message sending component then calls an underlying transport layer, such as TCP / IP, to deliver the message to that network address. The message sending component requests the physical routing map to provide a network address for the destination node identifier, or other nodes (ie, peer nodes) to which the message sending component is connected If you know the network address for the destination node, you can make requests to those other nodes. The message sending component can cache the network address in the physical routing table for use in sending subsequent messages to its destination node. The message sending component then sends the message to its network address. A message is sent by establishing a direct connection between the source node and the destination node, sent by forwarding the message to the destination node through the source node's peer node, or to the destination node Or can be sent by sending a message to the physical routing server for forwarding. The send message component includes a “search for route to node” component 533, a node lookup node component 534, and a peer connection, as described in more detail below. An established peer connection component 535 is used. The message receiving component processes messages received for the destination node. If the node in question (ie, the node on which the component is executing) is not the destination node, the message receiving component will attempt to forward the message to the destination node. If the message indicates that the source node is searching for a path to the destination node, this node responds to the search request when it knows the path to the destination node, or To other peer nodes. If the message is to be processed at the node in question, the message receiving component is either a receive logical message component 522 or a process logical name search component 529A. Pass the message to the logical routing layer by calling.

  The logical path control layer includes a logical message transmission component (send logical message component) 521, a logical message reception component (receive logical message component) 522, a logical name registration component (register logical name component) 523, and a logical name search processing configuration. An element (process logical name search component) 529A and a generate logical destination update function 529 are provided. The application layer uses a logical message send component to send a message to a logical destination that may be an application or a user, and receives a response message from the logical destination via the logical message receive component. The logical message sending component is passed the logical identifier and the message, identifies the destination node identifier for the logical identifier, and sends the message to the destination node using the physical routing layer message sending component. The logical message sending component uses the node identification function provided by the central server to identify the destination node identifier, to identify the destination node identifier by searching for peer nodes, or to the destination node identifier by the logical destination itself. Can be identified. The logical message sending component can cache a mapping of logical identifiers to node identification functions. The logical message transmission component includes a resolve logical destination component 524, a user information component 525, a logical destination search component 526, described in more detail below. A get response component 527 and a logical destination update component 528 are used. The logical message receiving component is called by the physical routing layer message receiving component to pass the message to the logical routing layer. The logical message receiving component processes the message and provides the message to the application layer. The logical name search processing function and logical destination update generation function will be described in more detail below. The logical name registration component is used by the application layer to register a logical identifier with the logical routing layer. The logical destination update generation component is called by the logical name search processing component. The application layer can provide an application initialization component 511 and an application receive component 512. The application initialization component can register the logical identifier of the application in the logical routing layer. The application receiving component is invoked by the logical message receiving component to perform the passing of messages from the logical routing layer to the application layer. The application layer also sends a message to a logical destination by calling a logical message transmission.

  The logical routing system runs on a computer system that includes a main memory, a central processing unit, input devices (eg, keyboards and pointing devices), output devices (eg, display devices), and a hard drive. It is possible. Main memory and the hard drive are computer-readable media that may contain instructions that implement the logical routing system. Computer systems can be connected to each other via various communication channels including the Internet, wide area networks, point-to-point dial-up connections, or local area networks.

  FIG. 6 is a block diagram illustrating connections between various nodes in the physical routing layer. In this example, client node 602 is connected to client node 603 and client node 603 is connected to application node 604. When the physical routing layer of the client node 602 sends a message to the application node 604 identified by the destination node identifier, the message sending component can attempt to establish a direct connection with that application node. It is. However, if a connection cannot be established, the message sending component of client node 602 determines whether the application node is accessible through any of node 602's own peer nodes. To do. In this case, the client node 602 can access the application node 604 via the client node 603. Thus, client node 602 forwards the message to client node 603, which in turn forwards the message to application node 604.

  FIG. 7 illustrates a data structure used by the logical routing layer in one embodiment. A logical name table 701 (also referred to as a logical path control table) includes an entry for each logical name associated with an application running on the node. The logical name is a logical identifier that identifies an application. The logical identifier may also identify a user or some other logical destination. Each entry includes a logical identifier, a fully qualified logical identifier, a class, and a node ID (identification) function. A sufficiently limited logical identifier uniquely identifies the logical name associated with the application. The class identifies the message class of the logical destination. For example, a class can be a database, application, or user. A logical identifier is unique within a class. The node identification function is used by the client node to identify the node identifier to which messages directed to the logical name should be sent. Each entry may also include a function name that identifies the function supported by the application. For example, the function name for inserting a new entity in the address book application can be “insert address”. The logical name table includes an entry for each logical destination known to that node. The logical name table can also include a mapping of user names to user identifiers. The user name is a logical name. A sufficiently limited logical name is a user identifier that uniquely identifies the user. There can be multiple user names (eg, aliases) associated with a user identifier. In an alternative embodiment (described below), the logical routing table includes a key function, a criteria declaration, and a routing table. The criteria define the data that is passed to the key function to generate the key. The key is then used to find the node identifier from the route table.

  FIG. 8 illustrates a data structure used by the physical routing layer in one embodiment. The data structure of the physical routing layer includes a physical routing table 801 and a peer table 802. The physical routing control table includes an entry for each node identifier known to the node. Each entry maps a node identifier to a peer node identifier through which the node identifier can be accessed. The peer table contains an entry for each peer node of that node. Each entry maps a node identifier to a peer node's network address.

  9-27 are flow diagrams of functions of a logical path control system in one embodiment. It is known in the art that the functions described herein can perform only a subset of the functions described, rearrange the functions described, or implement additional functions. It will be recognized by the person. 9-15 are flowcharts illustrating the processing of the physical routing layer in one embodiment. 9 to 12 show the transmission processing of the physical route control layer. FIG. 9 is a flow diagram that illustrates the processing of the physical routing layer send message function in one embodiment. This function is passed a destination node (ie, component) identifier and message and sends the message to the identified destination node. This function is called by the logical routing layer. If, at decision block 901, an entry for the destination node ID (identifier) exists in the physical routing table, the route to that destination node has been previously revealed, and the function retrieves the entry and block 902 Proceed to If not, the function proceeds to block 905. In block 902, the function adds path information including the node identifier of the node in question to the message header. When a message is received by a node, it has a history of the node on the path it has gone through. The receiving node can update its physical route control table to indicate that the nodes on the path are accessible. In block 903, the function retrieves the node identifier of the peer node from the entry, and then retrieves the network address (eg, IP address and port number) for that peer node from the peer table. The function then sends a message to the retrieved network address. At decision block 904, if the message was successful, the function returns an indication of success; otherwise, the function returns an error indication. Blocks 905-914 are performed when there is no entry in the physical routing table for the passed node identifier. These blocks attempt to find a path through which the message can be sent to the destination node. In block 905, the function calls a “find route to node” function that searches for peer nodes through which it can access the destination node. If the called function finds such a peer node, it adds an entry to the physical routing table and returns a success indication. If at decision block 906 a route is found, the function proceeds to block 907; otherwise, the function proceeds to block 908. In block 907, the function retrieves the entry for the destination node from the physical routing table and proceeds to block 902 to send the message to the destination node. If at decision block 908, the policy for the node allows the creation of a new peer connection, the function proceeds to block 909, otherwise, the function proceeds to block 913. An example policy may limit the number of connections to a peer node to four. If the node already has four peer nodes, this policy prevents connection to the fifth peer node. In block 909, the function invokes the node lookup function, which identifies the network address for the destination node and adds the network address to the peer table. The called function can send a message to the server node to check if the destination node is registered with the server node. The called function also adds an entry to the peer table to store the node identifier and network address for the destination node. If, at decision block 910, the destination node is found, the function proceeds to block 911, otherwise, the function proceeds to block 914. In block 911, the function calls a peer connection establishment function to establish a peer connection with the destination node and updates the physical routing table. If at decision block 912, a connection to the destination node is established, the function proceeds to block 907 and sends the message directly to the destination node; otherwise, the function proceeds to block 913. At decision block 913, if the node's policy allows server node forwarding, the function proceeds to block 903 to forward the message to the server node; otherwise, the function returns an error indication. . If server node forwarding is allowed, the node sends a message to the server node and either immediately when the destination node is online or at a point after the destination node is online. Allows the message to be forwarded to the destination node. At decision block 914, if the message is to be dropped (removed), the function returns an error indication; if not, the function proceeds to block 913.

  FIG. 10 is a flowchart illustrating processing of a “search for a route to a node” function according to an embodiment. This function is passed the node identifier of the destination node. The function is called to identify the path from the peer node of the node in question to the destination node. The function sends a message to each peer node of the node indicating that the node is searching for a path to the destination node. If the peer node identifies a path through the peer node to the destination node, it responds to the message. Those skilled in the art will recognize that different search techniques may be used. For example, instead of sending a message to each peer node first, so that each peer node can attempt to identify a path before the message is sent to the next peer node, A message may be sent to the peer node. In decision block 1001, if the node has a peer node, the function proceeds to block 1002, otherwise the function returns an error indication. In block 1002, the function generates a node search message that includes the identifier of the node and the destination node. In block 1003, the function sends a copy of the node search message to each peer node of that node. In block 1004, the function sets a timer to limit the amount of time that the node waits for a response from the peer node. In block 1005, the function waits for a response from the peer node or a timeout. If, at decision block 1006, a response is received, the function proceeds to block 1007, otherwise, a timeout occurs and the function returns an error indication. In block 1007, the function updates the physical routing table by adding an entry indicating that the destination node is accessible via the peer node that sent the response. After canceling the timer, the function returns a success indication.

  FIG. 11 is a flow diagram that illustrates the processing of the node lookup function in one embodiment. This function is passed the node identifier of the destination node. The function contacts the server node and if the server node responds with the destination node's network address, it retrieves the network address for the destination node and adds an entry to the peer table. If at decision block 1101 an appropriate connection to the server node (SN) is available, the function proceeds to block 1101 and if not, the function returns an error indication. In block 1102, the function generates a node lookup message that includes the destination node identifier. In block 1103, the function sends the node lookup message to the server node. At block 1104, the function sets a timer. In block 1105, the function waits for a response from the server node or a timeout. If a response is received from the server node at decision block 1106, the function proceeds to block 1107, otherwise, a timeout occurs and the function returns an error indication. At block 1107, the function adds an entry to the peer table indicating the network address of the destination node returned in the message. After canceling the timer, the function returns a success indication. In an alternative embodiment, if a server node is not available through the node, the node may request its peer node to contact the server node on behalf of, or Information related to network addresses can be used to examine locally cached information.

  FIG. 12 is a flow diagram that illustrates the processing of the peer connection establishment function in one embodiment. This function is passed the identifier of the destination node. The function establishes a connection with the destination node and updates the physical routing table. In block 1201, the function looks up the destination node ID (identifier) in the peer table. If at decision block 1202, the network address of the destination node exists in the peer table, the function proceeds to block 1203, otherwise the connection cannot be established and the function gives an indication of the error. return. In block 1203, the function generates a peer connection request message that identifies the node. In block 1204, the function sends the peer connection request message to the network address of the destination node. To send the message, the function establishes a transport level connection to the network address before sending the message. If the connection cannot be established, the function returns an error indication. At block 1205, the function sets a timer. In block 1206, the function waits for a response from the destination node or a timeout. If, at decision block 1207, a response is received from the destination node, the function proceeds to block 1208, otherwise a timeout occurs and the function returns an error indication. At block 1208, the function cancels the timer. If, at decision block 1209, the response indicates that a connection can be established, the function proceeds to block 1210, otherwise, the destination node has no intention to connect to the node, and the function indicates an error indication. return. At block 1210, the function authenticates the destination node. The destination node sends a message encrypted with its own private key, and the relevant node uses various public authentication techniques such as the use of a public / private key pair that decrypts the message using the public key. Can be used. If the destination node cannot be authenticated, the function returns an error indication. At block 1211, the function updates the physical routing table to indicate that the destination node is accessible as a peer node (ie, connected at the physical routing layer), and then indicates a success indication. return.

  FIGS. 13-15 are flow diagrams illustrating the processing of received messages in the physical routing layer. FIG. 13 is a flowchart illustrating processing of the message reception function of the physical routing control layer in one embodiment. This function is passed a message received from the peer node. The function determines whether the message is directed to the node in question or to another node. If the message is directed to that node, the function forwards the message to the logical routing layer. In block 1301, the function scans the message header for a new destination node. The message header identifies the destination node and each node in the path from the source node to the node. In block 1302, the function updates the physical routing table to add a non-existing node in the physical routing table with the node identified in the message header. The update indicates that the identified node is accessible via the peer node that sent the message. In decision block 1303, if the destination node is the node in question, the function proceeds to block 1304, otherwise the function proceeds to block 1305. At decision block 1304, if the message is a response to a previously sent message, the function proceeds to block 1304A, otherwise the function proceeds to block 1304B. In block 1304A, the function informs the logical path control layer that a response has been received by calling the logical route control layer's get response function and then returns. In block 1304B, the function passes the received message to call the logical routing layer logical message receive function, passes the message to the logical routing layer, and then returns. At decision block 1305, if the message is a node search request, the function proceeds to block 1306; otherwise, the function proceeds to block 1306A. In block 1306, the function returns after calling the node search processing function passing the identifier of the destination node and the message. The called function checks the physical path control table of the relevant node to determine whether the destination node is accessible via the relevant node. If it is not accessible, the node sends its search request to its peer node. At decision block 1306A, if the message is a logical name search request, the function proceeds to block 1306B, otherwise the function proceeds to block 1307. In block 1306B, the function calls the logical name search processing function of the logical path control layer. In block 1307, the function calls the message transfer function to transfer the message to the next path in the path to the destination node (ie, the peer node of that node) and then return.

  FIG. 14 is a flowchart illustrating the processing of the message transfer function of the physical routing layer in one embodiment. This function is passed the destination node identifier and the message to be transferred. This function sends a message to a peer node that exists on the path to the destination node. In block 1401, the function updates the message to add information about the node in question to the message header. At block 1402, the function decrements the hop count in the message header. Each hop corresponds to a node on the path to the destination node. The hop count indicates the maximum number of hops that the message can pass on the way to the destination node. The node that originates the message can set the hop count. Alternatively, the message header can include an indication of the number of hops that the message has passed. Each node can decide whether to continue forwarding messages based on that number. If at decision block 1403, the hop count is zero, the function proceeds to block 1407, otherwise, the function proceeds to block 1404. In decision block 1404, if the destination node ID (identifier) is present in the physical routing table, the destination node is accessible via the node, and the function proceeds to block 1405, and if not, The function proceeds to block 1407. In block 1405, the function sends a message to the peer node through which the destination node is accessible. At decision block 1406, if the message was successful, the function reports a success indication and returns, otherwise, the function reports an error indication and returns. If at decision block 1407, the node's policy allows forwarding to the server node (SN), the function proceeds to block 1408; otherwise, the function reports an error indication and returns. . If, at decision block 1408, a server node (SN) connection is available, the function proceeds to block 1408 and forwards the message to the server node; otherwise, the function reports an error indication and returns. The server node can then forward the message to the destination node immediately when the destination node is online or at a time after the destination node is online.

Figure 15 is a flow diagram that illustrates the processing nodes search processing function in one embodiment. This function is passed a destination node identifier and a message. The function forwards the message to the next node in the path to the destination node. When a message is received from a different peer node, if the node has already processed the message, the function can return without further processing. In decision block 1501, if the destination node identifier is present in the physical routing table, the destination node is accessible via the node, and the function proceeds to block 1502, otherwise the function is Proceed to block 1504. At block 1502, the function sends a message to the next peer node in the path indicated in the physical routing table. If the destination node is accessible through multiple peer nodes, the function sends a message to each of the peer nodes. If at decision block 1503 the transmission of the message to at least one peer node was successful, the function returns; otherwise, the function reports an error indication and returns. In blocks 1504-1509, the function forwards the search message to the peer node of that node. At block 1504, the function decrements the hop count. If at decision block 1505, the hop count is equal to zero, the function discards the message and returns, otherwise, the function proceeds to block 1506. At block 1506, the function identifies the next peer node to which the search message should be forwarded based on the search algorithm. The search algorithm described herein is an algorithm that exhaustively searches all peer nodes to find a destination node. An alternative search algorithm can select a single peer node for search message forwarding. Those skilled in the art will recognize that the search algorithm can be optimized to best fit the node topology, hop count, geographic location, and application requirements. If at decision block 1507, the next peer node is identified, the function proceeds to block 1508; otherwise, the function proceeds to block 1510. At block 1508, the function updates the message to add information related to the node in question to the message header. At block 1509, the function generates a copy of the message for each peer node to which the message is to be sent and proceeds to block 1502 to send the message to each identified peer node. At block 1510, the function discards the message and returns.

FIGS. 16-25 are flowcharts illustrating the processing of the logical routing control layer in one embodiment. 16 to 21 are flowcharts showing message transmission processing of the logical routing control layer. FIG. 16 is a flowchart illustrating the processing of the logical message transmission function of the logical routing control layer in one embodiment. The logical message send function is passed a logical destination and a message. The logical destination indicates where the message should be sent. For example, a logical destination can be identified by a user name, a logical name (eg, “address book”), or a fully qualified name (eg, “addressbook.node.opendesign.com”). The function determines the identifier of the destination node corresponding to the logical destination and sends a message to that node by calling the message transmission function of the physical routing layer. At block 1601, the function calls a logical destination resolution function. The called function updates the logical path control table to add an entry for the logical destination if such an entry does not already exist in the table. If at decision block 1602, the logical destination is successfully resolved, the function retrieves the entry from the logical routing table and proceeds to block 1604, and if not successfully resolved, the function provides an indication of the error. return. At block 1604, the function calculates the destination node identifier (compute; determines using a computer) by calling the node identification function of the retrieved entry passing the message. In decision block 1605, if the destination node identifier is calculated successfully, the function proceeds to block 1606, if it has not been calculated successfully, the function returns an indication of error. In block 1606, the function calls the physical routing layer send message function to send the message to the destination node and then returns a success or error indication returned by the called send message function. In one embodiment, the node identification function can use criteria, key functions, and routing tables. The key function is called by passing the criteria for generating the key. The key is then used to search the routing table to identify the node identifier. For example, the criteria for the address book application is the last name, and the key function can return the first character of the last name. The routing table can be a tree that maps characters to node identifiers.

  FIG. 17 is a flow diagram illustrating the processing of the logical destination resolution function of the logical routing control layer in one embodiment. This function is passed a logical destination indication and returns a fully qualified logical name. At decision block 1701, if the logical destination is a username, the function proceeds to block 1710; otherwise, the function proceeds to block 1702. At decision block 1702, if the logical name of the logical destination is local to the node, the function proceeds to block 1703, otherwise the function proceeds to block 1705. At block 1703, the function retrieves an entry for the logical name from the logical path control table. This entry contains a sufficiently limited logical name. If at decision block 1704 an entry for the logical name is found, the function proceeds to block 1705; otherwise, the function returns an error indication. At block 1705, the function retrieves a well-defined logical name entry from the logical routing table. If at decision block 1706 an entry for a well-defined logical name is retrieved, the function sets the logical destination to that fully-qualified logical name, returns a success indication, and if not retrieved, The function proceeds to block 1707. At block 1707, the function calls a logical destination search function to globally search for logical destinations. The called function can search in the server node or through the peer node to find a sufficiently limited logical name. If at decision block 1708, a sufficiently limited logical name is found during the search, the function returns an indication of success, otherwise, the function returns an indication of an error. At block 1709, the function calls the user information function to find the user identifier for the username. The called function can add an entry to the logical routing table to map the user identifier to the node identifier. The function then returns a success indication.

  FIG. 18 is a flowchart illustrating the processing of the logical destination search function of the logical route control layer in one embodiment. This function is passed a logical destination that is a fully qualified logical name and adds an entry to the logical routing table to map the fully qualified logical name to a node identifier (if not already added) ). In one embodiment, the node identifier can be extracted from a well-defined name. In another embodiment, the node identifier can be retrieved by sending a message to the logical destination of the logical routing map. However, in the described embodiment, the node identifier is retrieved from the server node or by searching for peer nodes. This function sends a message to a server node that stores global logical destination information. If information about the entry is not received from the server node, the function sends a search message to its peer node, and the search message is propagated throughout the network. In block 1801, the function looks up the logical destination passed in the logical routing table. If at decision block 1802 an entry for the logical destination is found, the function returns a success indication; otherwise, the function proceeds to block 1803. At block 1803, the function generates a logical name lookup message of class SN. This message indicates that the sending node is requesting information to map a logical name to a node identifier. In block 1804, the function calls the send logical message function passing the generated message and the node identifier logical destination of the server node. At decision block 1805, if the message was successfully sent, the function proceeds to block 1806, and if not, the function returns an error indication. At block 1806, the function calls a get response function and waits for a response to be received. If, at decision block 1807, a response is received, the function proceeds to block 1808; otherwise, the function proceeds to block 1809. In block 1808, the function calls the logical destination update processing function to update the logical path control table and then returns a success indication. At block 1809, the function generates a logical name lookup message of class SEARCH. The SEARCH class indicates that the message was sent from a peer node to search for a node identifier. In block 1810, the function sends a message generated by calling a physical routing layer send message function. The search message is sent to the peer node and the peer node responds if it can access the logical destination through that peer node. If at decision block 1811 the message send indication is successful, the function proceeds to block 1812; otherwise, the function returns an error indication. At block 1812, the function calls a get response function to wait for a message or timeout. If at decision block 1813 a response is received, the function proceeds to block 1814; otherwise, the function returns an error indication. At decision block 1814, the function calls the logical destination update processing function to update the logical path control table and then returns a success indication.

  FIG. 19 is a flowchart illustrating the processing of the response acquisition function of the logical route control layer in one embodiment. This function is a low-level function used to set a timer and wait for a response to a message or timeout. In block 1901, the function sets a timer. If a response is received at decision block 1902, the function proceeds to block 1903, otherwise a timeout occurs and the function returns an error indication. At block 1903, the function cancels the timer and returns a success indication.

  FIG. 20 is a flowchart showing the processing of the logical destination update processing function of the logical route control layer in one embodiment. This function is passed information about the logical destination and updates an existing entry for the logical destination in the logical routing table or adds a new entry for the logical destination. In block 2001, the function looks up the passed logical destination in the logical routing table. If at decision block 2002, a logical destination is found, the function proceeds to block 2004; otherwise, the function proceeds to block 2003. In block 2003, the function adds a new entry for the logical destination to the logical routing table. In block 2004, the function updates the entry in the logical routing table with the class and node identification function. The function then returns a success indication.

  FIG. 21 is a flowchart showing the processing of the user information function of the logical route control layer in one embodiment. This function is passed a user name, updates the logical path control table as appropriate to map the user identifier for that user name to a node identifier, and returns that user identifier as a logical destination. In block 2101, the function looks up the user name in the logical routing table. At decision block 2102, if the lookup was successful, the function returns the user identifier as a logical destination with a success indication, otherwise the function proceeds to block 2103. At block 2103, the function generates a class SN user identifier acquisition message. This message is a request to retrieve the identifier associated with the user name. At block 2104, the function calls a send logical message function to send the generated message that maps the user name to the user identifier to the logical destination. If at decision block 2105, the message was successfully transmitted, the function proceeds to block 2106; otherwise, the function returns an error indication. At block 2106, the function invokes a get response function. If, at decision block 2107, the response is successfully retrieved, the function proceeds to block 2108, and if not, the function returns an error indication. At block 2108, the function adds an entry to the logical routing table that maps the user name to the user identifier provided in the response by the server node. At block 2109, the function generates a node user message of class SN. At block 2110, the function invokes the send logical message function to send the generated message to the logical destination in the logical routing map to find the user identifier node. If at block 2111, the message was successfully sent, the function proceeds to block 2112; if not successfully sent, the function returns an error indication. At block 2112, the function calls a response acquisition function. If, at decision block 2113, a response is successfully received, the function proceeds to block 2114, and if not successfully received, the function returns an error indication. In block 2114, the function updates the logical routing table to add entries for the user identifier and node identifier provided in the response and then returns the user identifier as a logical destination with an indication of success.

FIG. 22 is a flowchart illustrating the processing of the logical message reception function of the logical routing control layer in one embodiment. This function is passed the received message. If the logical function and the specified instance of the message are known to the node in question, the function calculates a node identifier. If the identified node is that node, the function passes the message to the application for processing. If not, the function sends a message to the identified node. At block 2201, the function retrieves the logical destination from the message header along with the function and instance specified in the message header. In one embodiment, the message header includes a logical destination (“lname”), a class (“class”), and a criterion (“crit”). At decision block 2202, if the class is supported by the node as indicated by the logical routing table, the function proceeds to block 2203, otherwise, the function reports an error indication and returns. At decision block 2203, as indicated by the logical routing table, if the logical destination is known to the node in question, the function proceeds to block 2204, otherwise the function reports an error indication and returns. . At block 2204, the function calculates a destination node identifier based on the node identification function and criteria for that logical destination. In decision block 2205, if the destination node identifier is calculated successfully, the function proceeds to block 2206, if it has not been calculated successfully, the function returns to report an indication of error. If, at decision block 2206, the calculated node identifier identifies the node, the function proceeds to block 2207; otherwise, the function proceeds to block 2208. At block 2207, the function consumes the message and returns. In block 2208, the function calls the physical routing layer send message function to send the message to the calculated node identifier and then returns.

  FIG. 23 is a flowchart showing the processing of the logical name registration function of the logical path control layer in one embodiment. This function is called by the application program to register both the logical name of the application program locally and globally. This function is passed a logical name and a name class. In decision block 2301, if the logical name and class combination does not exist in the logical routing table, the function proceeds to block 2302 and returns an error indication if it exists. At block 2302, the function generates a fully qualified logical name from the passed logical name. For example, the function generates a sufficiently limited logical name by adding the identifier of the node together with the registered domain name to the logical name (for example, “logicalname” is changed to “logicalname.nodeID.company.com”). can do. In block 2303, the function adds an entry for the logical name to the logical routing table. This entry includes a node identification function. At block 2304, the function generates a message that registers its logical name globally. In block 2305, the function calls the logical route control layer's logical message send function to send a registration message for registration in the logical route control map. If at decision block 2306 the message was successfully transmitted, the function returns an indication of success; otherwise, the function proceeds to block 2307. In block 2307, the function returns an error indication after setting a timer to attempt to send the registration message again.

  FIG. 24 is a flowchart showing the processing of the logical destination update generation function of the logical route control layer in one embodiment. This function is used when the node responds to a search message for a logical destination, or the node identification function of the client node (ie, the node using the application service of the node) is not up-to-date. Called when a node is detected. This function is passed a logical name. At block 2401, the function retrieves an entry for that logical name in the logical routing table. If, at decision block 2402, an entry is found, the function proceeds to block 2403, otherwise, the function returns an error indication. At block 2403, the function generates a message containing the node identification function and returns a success indication.

  FIG. 25 is a flowchart showing the processing of the logical name search processing function of the logical path control layer in one embodiment. This function is passed a logical name and a message. This function is called when the physical routing layer receives a logical name search request. In decision block 2501, if the logical name exists in the logical path control table, the function proceeds to block 2502, otherwise the function proceeds to block 2506. In block 2502, the function calls the logical destination update generation function to retrieve and prepare information (eg, node identification function) regarding the passed logical name. At block 2503, the function generates a logical path search response that includes the node identification function. At block 2504, the function sends the response to the peer node to be sent back to the originating node. At decision block 2505, if the response was successfully sent, the function returns; if not, the function reports an error and then returns. At block 2506, the function decrements the hop count. If at decision block 2507, the hop count is zero, the function proceeds to block 2512; otherwise, the function proceeds to block 2508. At block 2508, the function identifies the next peer node based on the search algorithm. If at decision block 2509 a peer node is identified, the function proceeds to block 2510, otherwise, the function proceeds to block 2512. At block 2510, the function updates the message to add the node identifier for the node in question. In block 2511, the function generates a copy of the message for each peer node to which the message is to be sent and proceeds to block 2504 to send the message to each peer node. In block 2512, the function discards the message and then returns.

  FIG. 26 is a flowchart showing the processing of the application initial setting function in one embodiment. This function illustrates the use of a logical routing layer by an application. In block 2601, the function authenticates the application to the server node. If at decision block 2602 authentication is successful, the function proceeds to block 2603; otherwise, the function reports an error indication and completes. At block 2603, the function calls the register logical name function to register with the logical path control map associated with the application. This function also adds an entry to the logical path control table for the application. At block 2604, the function generates a request message to be sent to the logical destination. This reflects the actual processing that can be performed by the application. In block 2605, the function sends a message to the logical destination by calling the logical message send function of the logical routing layer. At decision block 2606, if the message was successfully sent, the function is complete, otherwise, the function reports and reports an error.

  FIG. 27 is a flowchart showing processing of a function of an application that receives a message from the logical routing control layer. At block 2702, the function performs message authentication. If at decision block 2703 the message is authenticated, the function proceeds to block 2704; otherwise, the function completes after reporting an error. At block 2704, the function consumes the message. If at decision block 2705 a response is to be sent, the function proceeds to block 2706, otherwise, the function is complete. At block 2706, the function generates a response. In block 2707, the function invokes the logical routing layer logical message send function and sends the response. At decision block 2708, if the transmission of the logical message is successful, the function is complete; otherwise, the function completes after reporting an error.

  From the foregoing description, specific embodiments of the present technology have been described for purposes of illustration, but it will be appreciated that various modifications can be made without departing from the scope of the invention. Accordingly, the invention is not limited except as by the appended claims.

It is a block diagram for showing a logical route control system in one embodiment. It is a flowchart which shows the process at the time of a client program transmitting a message to an application. It is a block diagram for showing a logical routing system in which an instance of an application is executed in a plurality of nodes. FIG. 3 is a block diagram illustrating load balancing for an application using a node identification function. FIG. 3 is a block diagram illustrating the architecture of an application layer 510, a logical routing layer 520, and a physical routing layer 530 used by the logical routing system. It is a block diagram which shows the connection in the physical routing control layer between various nodes. FIG. 4 illustrates a data structure used by a logical routing layer in one embodiment. FIG. 3 illustrates a data structure used by a physical routing layer in one embodiment. It is a flowchart which shows the process of the message transmission function of the physical routing control layer in one Embodiment. It is a flowchart which shows the process of the function "search for the route to a node" in one embodiment. 3 is a flow diagram that illustrates the processing of a node lookup function in one embodiment. It is a flowchart which shows the process of the peer connection establishment function in one Embodiment. It is a flowchart which shows the process of the message reception function of the physical routing control layer in one Embodiment. It is a flowchart which shows the process of the message transfer function of the physical routing control layer in one Embodiment. It is a flowchart which shows the process of the node search processing function in one Embodiment. It is a flowchart which shows the process of the logical message transmission function of the logical routing control layer in one Embodiment. 6 is a flowchart illustrating processing of a logical destination resolution function of a logical routing control layer in an embodiment. It is a flowchart which shows the process of the logical destination search function of the logical route control layer in one Embodiment. It is a flowchart which shows the process of the response acquisition function of the logic route control layer in one Embodiment. It is a flowchart which shows the process of the logical destination update process function of the logical route control layer in one Embodiment. It is a flowchart which shows the process of the user information function of the logical routing control layer in one Embodiment. It is a flowchart which shows the process of the logical message reception function of the logical routing control layer in one Embodiment. It is a flowchart which shows the process of the logical name registration function of the logical route control layer in one Embodiment. It is a flowchart which shows the process of the logical destination update generation function of the logical route control layer in one Embodiment. It is a flowchart which shows the process of the logical name search process function of the logical route control layer in one Embodiment. It is a flowchart which shows the process of the application initialization function in one Embodiment. 6 is a flowchart illustrating processing of a function of an application that receives a message from a logical routing control layer.

Claims (51)

A method at said client node for sending a message to an application node corresponding to a logical identifier known to the client node, comprising:
Maintaining a mapping from the application node to a plurality of physical identifiers corresponding to the logical identifier by receiving a mapping of the logical identifier of the node to a plurality of physical identifiers and registering the mapping in the logical routing control table ;
The message having a logical identifier at the client node is passed to a node identification function for the logical identifier that calculates a physical identifier for the logical identifier, and the physical identifier for the logical identifier and the application to which the message is to be transmitted Selecting one or more physical identifiers of a node from the logical routing table and determining, and sending the message to an application node identified by the determined physical identifier identification function retrieves the key from the message with the logical identifier according to the criteria included in the predetermined reference or said message, on the basis of the key taken out, one or more physical identifiers Method characterized by having a function of selecting from the logical routing control table.   The client node includes receiving an update to the node identification function, and a message to be transmitted after receiving the update is transmitted to an application node identified by the updated node identification function The method according to claim 1.   The application node of claim 1 when receiving the message, examines using a node identification function to determine whether the message should be forwarded to another application node. The method described. The method of claim 1, wherein the node identification function is common to a plurality of logical identifiers.   The method of claim 1, wherein a client node receives the node identification function from the application node.   The method of claim 1, wherein the mapping of logical identifiers to node identification functions is maintained at a server node.   The method of claim 1, wherein the mapping of logical identifiers to node identification functions is maintained at server nodes and distributed among the nodes.   The method of claim 1, wherein the mapping of logical identifiers to node identification functions is distributed among the nodes. A physical routing layer having a message sending component and a message receiving component;
A logical routing system comprising a logical routing layer having a logical message sending component and a logical message receiving component,
The logical message transmission component of the logical routing layer of the source node receives the logical destination and message from the client of the application and identifies the node identifier of the destination node associated with the logical destination, and then the node identifier And providing the message to the message sending component of the physical routing layer;
The message sending component of the physical routing layer of the source node identifies the provided node identifier of the destination node and a path from the source node to the destination node upon receipt of the message; Sending the message to the destination node;
The message receiving component of the physical routing layer of the destination node receives the message transmitted from the source node and passes the received message to the logical message receiving component of the logical routing layer. Offer to,
The logical message receiving component of the logical routing layer of the destination node receives the provided message and provides the message to the application;
The logical message transmission component, using the node identification function to identify the node identifier, the node identification function, according to the criteria included in the predetermined reference or the message, the message with the logical destination And a function of selecting one or a plurality of node identifiers from a logical routing table in which mappings to a plurality of node identifiers corresponding to logical destinations are already registered based on the extracted keys. A logical route control system characterized by that. The logical path control system according to claim 9 , wherein the node identification function is provided by the destination node. The logical path control system according to claim 9 , wherein the node identification function is updated by the destination node. The logical message sending component of the logical routing layer sends a search message to a peer node to determine whether the peer node can provide the node identifier, thereby determining the node of the destination node The logical path control system according to claim 9 , wherein the identifier is identified. Wherein said logical message transmission components of the logical path control layer by sending the destination node identifier to a server node that provides the node identifier, claim 9, wherein identifying a node identifier of the destination node The logical route control system described in 1. The logical routing system of claim 9 , wherein the message sending component of the physical routing layer sends the message to the server node for forwarding to the destination node. 15. The logical routing system of claim 14 , wherein the server node stores the message until the destination node is online.   The logical routing system of claim 9, wherein the logical message receiving component of the logical routing layer determines whether the message should be forwarded to another node. The logical routing system of claim 16 , wherein the determination of whether the message should be forwarded to another node is based on a node identification function that calculates a node identifier. The logical path control system according to claim 16 , wherein the destination node and the transmission source node are operated by a plurality of different organizations. The logical path control system according to claim 16 , wherein the destination node and the another node are managed by different organizations. The message transmission component of the physical routing layer to claim 9, characterized in that using the mapping of node identifiers to network address to send the message to a network address associated with the destination node The logical routing control system described. The logical route control system according to claim 20 , wherein the network address includes an IP address. 10. The logical routing system of claim 9 , wherein the message sending component of the physical routing layer sends the message using a TCP / IP protocol. Receiving a logical destination and message from a client of the application, identifying a node identifier of a destination node associated with the logical destination, and sending the message to a node identified by the node identifier using a physical routing layer A logical message transmission component of the source node, wherein the node identifier is identified using the logical message transmission component and transmits the message to the logical destination; and ,
A logical message receiving component of the destination node that receives the message provided by the physical routing layer and provides the message to the application;
The logical message transmission component, using the node identification function to identify the node identifier, the node identification function, according to the criteria included in the predetermined reference or the message, the message with the logical destination And a function for selecting one or a plurality of node identifiers from a logical route control table in which mappings to a plurality of node identifiers corresponding to logical destinations are already registered based on the extracted keys. logical routing control system according to claim to Rukoto. The logical path control system according to claim 23 , wherein the node identification function is provided by the destination node. The logical path control system according to claim 23 , wherein the node identification function is updated by the destination node. 24. The logical path control system of claim 23 , wherein the mapping from the logical destination to the corresponding node identifier is centralized in a server node. 24. The logical routing system of claim 23 , wherein the mapping of node identifiers corresponding to the logical destination is distributed across a plurality of server nodes. 24. The logical routing system of claim 23 , wherein the physical routing layer sends the message to a server node for transfer to the destination node. 29. The logical routing system of claim 28 , wherein the server node stores the message until the destination node is online. 24. The logical routing system of claim 23 , wherein the logical message receiving component determines whether the message should be forwarded to another node. The logical routing system of claim 30 , wherein the determination of whether the message should be forwarded to another node is based on a node identification function that calculates a node identifier. The logical path control system according to claim 23 , wherein the destination node and the another node are operated by different organizations. The logical path control system according to claim 23 , wherein the destination node and the transmission source node are under the management of different organizations. 24. The logical path control system of claim 23 , wherein the mapping from the logical destination to the corresponding node identifier is stored at a server node. The logical path control system according to claim 23 , wherein the mapping from the logical destination to the corresponding node identifier is distributed among the nodes. A node identification function, by providing a message containing the logical address comprises transmitting it to identify a plurality of node identifiers corresponding to the logical address, and a message to the node identified by the node identifier,
The node identification function retrieves a key from the message having the logical destination according to a predetermined criterion or a criterion included in the message, and, based on the retrieved key, one or more node identifiers as a logical destination from the logical routing control table mapping to a plurality of node identifiers corresponding has already been registered, the control computer system to send the message to the logical destination by how to characterized in that it has a function to select A computer- readable recording medium characterized by containing an instruction code to be recorded . 37. The computer readable record of claim 36 , when a node receives the message, it uses a node identification function to determine whether the message should be forwarded to another node. Medium. 38. The computer- readable medium of claim 37 , wherein the node that forwards the message performs a load balancing function for the logical destination. The node identification function is common to a plurality of logical destinations each having a criterion, a key function, and a mapping data structure, and the node identification function generates a key using the criterion and the key function The computer- readable medium of claim 36 , wherein the generated key is used to identify a node identifier from the mapping data structure. The computer- readable medium of claim 36 , wherein the mapping of logical destinations to node identifiers is stored in a centralized system. The computer- readable medium of claim 36 , wherein the mapping of logical destinations to node identifiers is stored at a distributed location. A node identification function, according to the criteria included in the predetermined reference or message, retrieve the key from the message with a logical address, based on the key taken out, one or more physical identifiers, the logic A means for registering the node identification function , which is selected from a logical route control table in which mappings to a plurality of node identifiers corresponding to the destination are already registered, and a message including the logical destination are passed to the node identification function and the logical destination Means for identifying a destination node identifier corresponding to
Means for transmitting a message to a node identified by the destination node identifier. 43. The logical routing system of claim 42 , wherein a logical destination is associated with an application, and the application registers a node identification function for the associated logical destination. The logical path control system according to claim 42 , wherein the node identification function is registered by the destination node. The logical path control system according to claim 42 , wherein the node identification function is updated by the destination node. 43. The logical routing system of claim 42 , wherein the mapping from logical destinations to corresponding node identifiers is centralized at a server node. 43. The logical routing system of claim 42 , wherein the means for identifying a destination node identifier includes a mapping of logical destinations to destination node identifiers distributed across a plurality of server nodes. The logical path control system according to claim 45 , wherein the destination node and the node that transmits the message are operated by different organizations. 43. The logical route control system according to claim 42 , wherein the destination node and a node that sends a message are under the management of different organizations. The logical routing system of claim 42 , wherein the mapping of logical destinations to node identifiers is stored at a central location. 43. The logical routing system of claim 42 , wherein the mapping of logical destinations to node identifiers is stored at distributed locations.

Images