US20110029688A1 - Logical routing system - Google Patents

Logical routing system Download PDF

Info

Publication number
US20110029688A1
US20110029688A1 US12/898,657 US89865710A US2011029688A1 US 20110029688 A1 US20110029688 A1 US 20110029688A1 US 89865710 A US89865710 A US 89865710A US 2011029688 A1 US2011029688 A1 US 2011029688A1
Authority
US
United States
Prior art keywords
logical
identifier
node
function
physical
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US12/898,657
Other versions
US8819273B2 (en
Inventor
Edward Jung
Holly Knight
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Open Design Inc
Original Assignee
Open Design Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Open Design Inc filed Critical Open Design Inc
Priority to US12/898,657 priority Critical patent/US8819273B2/en
Publication of US20110029688A1 publication Critical patent/US20110029688A1/en
Application granted granted Critical
Publication of US8819273B2 publication Critical patent/US8819273B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4505Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/302Route determination based on requested QoS
    • H04L45/306Route determination based on the nature of the carried application
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/30Managing network names, e.g. use of aliases or nicknames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4555Directories for electronic mail or instant messaging
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1008Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/101Server selection for load balancing based on network conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/30Types of network names
    • H04L2101/365Application layer names, e.g. buddy names, unstructured names chosen by a user or home appliance name
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers

Definitions

  • the described technology generally relates to mapping of logical identifiers to physical identifiers.
  • URI Uniform Resource Identifier
  • a URI is either a Uniform Resource Locator (“URL”) or Uniform Resource Name (“URN”), or any other formatted string that identifies a network resource.
  • URLs are discussed in detail in T. Berners-Lee et al., Uniform Resource Locators (URL), RVC 1738, CERN, Xerox PARC, Univ. of Minn., December 1994. Each URL contains a domain name identifying where the resource is located.
  • the URL “http://www.odi.com/home.htm” indicates that the resource named “home.htm” is located at the domain of “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 in the URL.
  • the TCP/IP protocol identifies computers using IP addresses (e.g., “128.32.0.6”) rather than domain names.
  • IP addresses e.g., “128.32.0.6”
  • IP addresses e.g., “128.32.0.6”
  • DNS domain name service
  • ISP IP Security
  • the local domain name server may be identified in a configuration file of the client computer executing the browser.
  • the local domain name server checks a local cache to determine whether it has a mapping of that domain name to IP address. If so, it returns the IP address to the application. If not, it forwards the resolution request to a root domain name server.
  • the root domain name server contains a mapping of each top-level domain name (e.g., “com”) to its name server(s).
  • 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 the resolution request to the top-level domain name server and receives (and may cache) the name of the domain name server for the second-level domain name (e.g., “odi.com”).
  • 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 an IP address associated with the second-level domain name.
  • the local domain name server may repeat the process for each level of domain name.
  • the local domain name server sends an IP address of the domain name to the computer executing the application. e.g.
  • FIG. 1 is a block diagram for illustrating the logical routing system in one embodiment.
  • FIG. 2 is a flow diagram illustrating the processing when a client program sends a message to an application.
  • FIG. 3 is a block diagram for illustrating the logical routing system where instances of the application are executing at multiple nodes.
  • FIG. 4 is a block diagram illustrating use of the node identification function to effect load balancing for an application.
  • FIG. 5 is a block diagram illustrating the architecture of the application layer 510 , the logical routing layer 520 and the physical routing layer 530 used by the logical routing system.
  • FIG. 6 is a block diagram illustrating connections at the physical routing layer between various nodes.
  • FIG. 7 illustrates a data structure used by the logical routing layer in one embodiment.
  • FIG. 8 illustrates data structures used by the physical routing layer in one embodiment.
  • FIG. 9 is a flow diagram illustrating the processing of the send message function of the physical routing layer in one embodiment.
  • FIG. 10 is a flow diagram illustrating the processing of the “search for route to node” function in one embodiment.
  • FIG. 11 is a flow diagram illustrating the processing of the lookup node function in one embodiment.
  • FIG. 12 is a flow diagram illustrating the processing of the establish peer connection function in one embodiment.
  • FIG. 13 is a flow diagram illustrating the processing of the receive message function of the physical routing layer in one embodiment.
  • FIG. 14 is a flow diagram illustrating the processing of the forward message function of the physical routing layer in one embodiment.
  • FIG. 15 is a flow diagram illustrating the processing of the process node search function in one embodiment.
  • FIG. 16 is a flow diagram illustrating the processing of the send logical message function of the logical routing layer in one embodiment.
  • FIG. 17 is a flow diagram illustrating the processing of the resolve logical destination function of the logical routing layer in one embodiment.
  • FIG. 18 is a flow diagram illustrating the processing of the search logical destination function of the logical routing layer in one embodiment.
  • FIG. 19 is a flow diagram illustrating the processing of the get response function of the logical routing layer in one embodiment.
  • FIG. 20 is a flow diagram illustrating the processing of the process logical destination update function of the logical routing layer in one embodiment.
  • FIG. 21 is a flow diagram illustrating the processing of the user information function of the logical routing layer in one embodiment.
  • FIG. 22 is a flow diagram illustrating the processing of the receive logical message function of the logical routing layer in one embodiment.
  • FIG. 23 is a flow diagram illustrating the processing of the register logical name function of the logical routing layer in one embodiment.
  • FIG. 24 is a flow diagram illustrating the processing of the generate logical destination update function of the logical routing layer in one embodiment.
  • FIG. 25 is a flow diagram illustrating the processing of the process logical name search function of the logical routing layer in one embodiment.
  • FIG. 26 is a flow diagram illustrating the processing of an application initialization function in one embodiment.
  • FIG. 27 is a flow diagram illustrating the processing of a function of an application that receives a message from the logical routing layer.
  • a logical routing system allows each application or entity (e.g., user of an application) to register its logical identifier to physical identifier mapping when the application starts executing on a computer.
  • a client program uses the registered mapping to identify the physical identifier of the computer. If an application later starts executing on a different computer, then the application can register a different mapping.
  • the logical routing system allows an application to register a function that is used to generate the physical identifier for the logical identifier associated with the application.
  • the use of a function allows the mapping to physical identifier to vary based on various criteria, such as location of a client computer or workload balancing goals.
  • the logical routing system also allows a logical identifier to map to multiple physical identifiers. With such a mapping, a client program would send a message to each of the computers identified by the multiple physical identifiers.
  • FIG. 1 is a block diagram for illustrating the logical routing system in one embodiment.
  • the logical routing system is used to send messages between client computer systems 101 (“client nodes”) and application computer systems 103 (“application nodes”).
  • the computer systems are interconnected through a communications mechanism 104 , such as the Internet.
  • Applications executing at application nodes provide services to client programs executing at client nodes.
  • the logical routing system provides a logical naming mechanism that allows client nodes to send messages to (e.g., requesting services of) applications by identifying the application by a logical identifier (also referred to as a “logical destination”), rather than a physical identifier (also referred to as a “node identifier”).
  • a logical identifier of an application may be “address book,” whereas a physical identifier may be a globally unique identifier that uniquely identifies the node where the application is executing.
  • An address book application maintains a mapping of names (e.g., John Smith) of people to electronic mail addresses (e.g., JohnSmith@company.com).
  • the address book application receives messages from client programs requesting an electronic mail address for a person and sends a response message to the client program that includes the electronic mail address.)
  • a client node or more precisely, a computer program executing at the client node
  • wants to send a message to an application it provides the message to a logical routing system along with the logical identifier of the application.
  • the logical routing system identifies the appropriate physical identifier of the node where the application is executing and sends the message to that node.
  • an application starts its execution at an application node, it registers with the logical routing system.
  • the logical routing system may maintain a mapping from logical identifiers of applications to physical identifiers of the application nodes where the applications are executing.
  • a client node may identify the physical identifiers of an application from the logical identifier using this mapping.
  • a logical identifier may map to multiple physical identifiers of different application nodes. For example, multiple copies of the address book application may be executing at different application nodes to accommodate the demands of the client program.
  • the logical identifier of the retrieve address function might map to only one physical identifier.
  • the logical identifier of the insert address function might map to the physical identifiers of all the nodes where the application is executing.
  • the logical routing system thus provides a mechanism that allows client programs to be developed using logical identifiers of applications and allows the logical identifiers to be resolved to physical identifiers during execution of the client programs.
  • a program executing at a node can be both an application and a client program in that it may respond to requests for services from client programs and request services from other applications.
  • the logical routing system may maintain a logical routing map of these registrations.
  • the logical routing system can implement the logical routing map across the application nodes and client nodes in a distributed manner, can implement the logical routing map as a central system, or can implement the logical routing map by a combination of distributed and centralized systems.
  • a register message may be sent to a logical destination that identifies the logical routing map (e.g., “logical routing map”).
  • the logical routing system may send a message to the same logical destination to retrieve the physical identifiers of the application.
  • the logical routing map may be considered to be an “application” that is not only used by the logical routing system, but is also accessible through the logical routing system itself.
  • the logical routing map has a node identification function for each logical name that returns the node identifier of the node associated with that logical name.
  • the application associated with a logical name registers with the logical routing system, the application provides its node identification function to the logical routing system.
  • the node identification function may input parameters or criteria (e.g., the message to be sent) and returns the appropriate node identifier for those parameters or criteria.
  • applications associated with a logical name may be executing at nodes physically located on each continent.
  • the node identification function may input the country where the sending node is located and return the node identifier for the node located on the continent in which the country is located.
  • the logical routing system allows mappings between logical identifiers and physical identifiers to be dynamically changed.
  • the mappings can be dynamically changed in various ways. For example, an application can dynamically change its mappings by registering a new node identification function, which may be sent to a node executing a client program in response to a request for service by the client program. The node receiving the new node identification function can replace the old node identification function for that application.
  • the logical routing system may use an existing network to transmit the mappings.
  • the existing network may be the IP network and DNS of the Internet.
  • the logical identifier may be mapped to a DNS name (i.e., a physical identifier) by the logical routing system and ultimately mapped to an IP address (i.e., a network address) by a transport system of the existing network.
  • DNS name i.e., a physical identifier
  • IP address i.e., a network address
  • the dynamic changing of the mappings allows the servicing of requests to dynamically meet demand. For example, as the demand on the address book application increases, the application can be launched on additional nodes. The new identification function, which is sent to a node executing a client program, can distribute some of the requests to the additional nodes. Similarly, as the demand decreases, the number of nodes executing the address book application can also decrease.
  • the logical routing system uses various criteria for routing messages.
  • the logical routing system may allow the criteria to be supplied by the client program or the application that provides the service.
  • the client program may specify a priority associated with a request, and the node identification function would identify a node that can service a request of that priority.
  • the application may specify that clients in a certain country have all their requests sent to a certain node.
  • the logical routing system allows criteria-based routing to one of multiple copies of an application using the same logical name. For example, to improve communications speed, the node identification function of an application may select a physical identifier for a node that is geographically close to the node of the client program.
  • the logical routing system also allows the services of an application to be distributed over multiple nodes. For example, an address book application may execute on multiple nodes that each service address requests relating to different parts of the alphabet. One node may service requests for names starting with A-M, and another node may service requests for names starting with N-Z.
  • the logical routing system may use a distributed model for maintaining the mappings of logical identifiers to physical identifiers (e.g., node identification functions).
  • each node maintains the mappings for the applications executing on the node.
  • the other node can cache the mapping.
  • the logical routing system may search for the mapping by sending a search request to the nodes to which it is connected.
  • Each node that receives a search request checks its local cache to see if it has the mapping. If so, it sends the mapping to the requesting node.
  • Each node that receives the mapping on its way to the requesting node may cache the mapping. (This searching automatically discovers the topology of the network.)
  • a node executing a client program may discover that an application is no longer available when the client program sends a message to that application. Upon such a discovery, the logical routing system may remove the mapping from its cache.
  • the search message is an example of the logical routing system supporting node-level messages. Thus, the logical routing system supports both node-level and application-level messages.
  • the logical routing system may use a combination of a distributed and a centralized model for maintaining the mappings.
  • the logical routing system may have a server node that stores all mappings.
  • Each application registers its logical identifier with the logical routing system.
  • the logical routing system may cache a mapping of the logical identifier to physical identifier locally at the node and send the mapping to the server node.
  • the logical routing system may first checks a local cache of mappings. If the logical identifier is not in the local cache, the logical routing system may request the mapping from the server node. If the server node is not available, then the logical routing system may search for the mapping in the same way as with the distributed model.
  • a logical identifier may identify a user.
  • a user logs on to an application or node, that user can be registered with the logical routing system using a logical identifier, such as the user's name.
  • the 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 it transmits messages to client programs. Indeed, the logical routing system may send the message to a client program that is responsible for displaying the message to the user.
  • the logical routing system maps from a logical identifier to a physical identifier and a transport system maps from the physical identifier to the network address.
  • the physical identifier might be the ultimate identifier used by the transport system. (For example, the physical identifier might be a network address.)
  • the transport system would not perform any mapping and would route messages to the nodes identified by physical identifier.
  • the functions of the logical routing system can be integrated into a transport system and may even be considered part of a physical layer.
  • FIG. 2 is a flow diagram illustrating the processing when a client program sends a message to an application.
  • an application when it starts execution registers its logical identifier and the physical identifier of the node at which it is currently executing with the logical routing system. (Client programs register in a similar way.)
  • a node identification function is registered. Whenever the physical identifier is needed, the node identification function is invoked, passing the message to be sent, and returns one or more physical identifiers.
  • the address book application may register a node identification function that maps the last name of a person to the physical identifier of the node that is executing the instance of the application that is responsible for servicing requests with that last name.
  • the logical routing system stores the mapping of logical identifier to node identification function for the application.
  • the client program invokes the logical routing system to send a message to an application identified by a logical identifier.
  • 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 an instance of application.
  • the logical routing system sends the message to the node addressed by that physical identifier.
  • the logical routing system at the application node upon receiving the message, may determine whether the message should be forwarded to another node or processed by this node.
  • the logical routing system at the application node may use a node identification function to identify the node that is to process the message.
  • the application processes the message.
  • the application sends a response to the client node using the logical routing system.
  • the logical routing system may 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 passes the response to the client program and uses the updated node identification function when sending subsequent messages to the logical identifier.
  • the updated node identification function may reflect the changing architecture of how the application is distributed across multiple application nodes.
  • FIG. 3 is a block diagram for illustrating the logical routing system where instances of the application are executing at multiple nodes.
  • the application is executing at application nodes 303 , 305 and 306 .
  • the application was initially executing only one instance at application node 303 .
  • application nodes 305 and 306 were brought online and started executing instances of the application.
  • the application node 303 services requests for names beginning with the letters A-J
  • application node 305 services requests for names beginning with the letters K-S
  • application node 306 services requests for names beginning with the letters T-Z.
  • the logical routing system uses the node identification function for the logical identifier of “address book,” which identifies application node 303 .
  • the logical routing system sends the request to application node 303 .
  • the logical routing system at application node 303 uses its node identification function to identify application node 305 .
  • 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.
  • the instance of the application executing at application node 305 retrieves the electronic mail address and sends the address to the client node.
  • the logical routing system of application node 305 may also send to the client node an updated node identification function that maps names beginning with the letters A-J to application node 303 , names beginning with the letters K-S to application node 305 and names beginning with the letters T-Z to application node 306 .
  • an updated node identification function that maps names beginning with the letters A-J to application node 303 , names beginning with the letters K-S to application node 305 and names beginning with the letters T-Z to application node 306 .
  • the logical routing system of the client node next uses the updated node identification function, it will identify the appropriate application node that is responsible for servicing the request and send the request directly to the identified application node.
  • application node 305 does not send an updated node identification function, then subsequent requests will be routed through application node 303 .
  • the node identification function may select the physical identifier of an instance randomly, may select the physical identifier based on geographic proximity to the client node, and so on.
  • FIG. 4 is a block diagram illustrating use of the node identification function to effect load balancing for an application.
  • the client nodes 401 use a node identification function that maps to one of the load balancing nodes 402 .
  • the node identification function may randomly select one of the load balancing nodes.
  • the node identification function used by the client nodes may be provided by the load balancing nodes.
  • FIG. 5 is a block diagram illustrating the architecture of the application layer 510 , the logical routing layer 520 and the physical routing layer 530 used by the logical routing system in one embodiment.
  • 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 a message to a node identified by a node identifier. Each node in the network maybe 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 messages using the send message component and receives messages via the receive message component.
  • the send message component is passed a message and a destination node identifier (e.g., “www.odi.com”) and locates the network address (e.g., IP address and port) for that destination node identifier.
  • the send message component then invokes the underlying transport layer, such as TCP/IP, to deliver the message to the network address.
  • the send message component may request a physical routing map to provide the network address for the destination node identifier or may request other nodes to which it is connected (i.e., peer nodes) if they know of the network address for the destination node.
  • the send message component may cache the network address in a physical routing table for use when sending subsequent messages to that destination node. The send message component then sends the message to that network address.
  • the message may be sent by establishing a direct connection between the originating node and the destination node, by forwarding the message to the destination node via a peer node of the originating node, or by sending a message to a physical routing server for forwarding to the destination node.
  • the send message component uses a “search for route to node” component 533 , a lookup node component 534 and establish peer connection component 535 , as described below in more detail.
  • the receive message component processes messages that are received for a destination node. If this node (i.e., the node where a component is executing) is not the destination node, then the receive message component attempts to forward the message to the destination node.
  • the receive message component passes the message to the logical routing layer by invoking the receive logical message component 522 or the process logical name search component 529 A.
  • the logical routing layer provides a send logical message component 521 , a receive logical message component 522 , a register logical name component 523 , a process logical name search component 529 A, and a generate logical destination update function 529 .
  • the application layer sends messages to a logical destination, which may be an application or a user, using the send logical message component and receives response messages from the logical destination via the receive logical message component.
  • the send logical message component is passed a logical identifier and a message, identifies the destination node identifier for the logical identifier, and uses the send message component of the physical routing layer to send the message to the destination node.
  • the send logical message component may identify the destination node identifier using a node identification function provided by a central server, by a search of peer nodes, or by the logical destination itself.
  • the send logical message component may cache the mapping of the logical identifier to the node identification function.
  • the send logical message component uses a resolve logical destination component 524 , a user information component 525 , a logical destination search component 526 , a get response component 527 , and a process logical destination update component 528 that are described below in detail.
  • the receive logical message component is invoked by the receive message component of the physical routing layer to pass the message to the logical routing layer.
  • the receive logical message component processes the message and provides the message to the application layer.
  • the process logical name search function and the generate logical destination update function are described below in detail.
  • the register logical name component is used by the application layer to register a logical identifier with the logical routing layer.
  • the generate logical destination update component is invoked by the process logical name search component.
  • the application layer may provide an application initialization component 511 and an application receive component 512 .
  • the application initialization component may register the application's logical identifier with the logical routing layer.
  • the application receive component is invoked by the receive logical message component to effect the passing of the message from the logical routing layer to the application layer.
  • the application layer also invokes the send logical message to send messages to a logical destination.
  • the logical routing system may execute on computer systems that include main memory, a central processing unit, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices) and a hard drive.
  • the main memory and hard drive are computer-readable media that may contain instructions that implement the logical routing system.
  • the computer systems may be interconnected via various communication channels that include the Internet, a wide area network, a point-to-point dial-up connection, or a local area network.
  • FIG. 6 is a block diagram illustrating connections at the physical routing layer between various nodes.
  • client node 602 is connected to client node 603
  • client node 603 is connected to application node 604 .
  • the send message component may attempt to establish a direct connection with the application node.
  • the send message component of client node 602 determines whether the application node is accessible through any of its peer nodes. In this case, application node 604 is accessible to client node 602 via client node 603 .
  • the 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.
  • the logical name table 701 (also referred to as a logical routing table) contains an entry for each logical name associated with an application executing at the node.
  • a logical name is a logical identifier that identifies an application.
  • a 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 identification function.
  • the fully qualified logical identifier uniquely identifies the logical name associated with the application.
  • the class identifies a message class of the logical destination.
  • the class may be database, application or user.
  • a logical identifier is unique within a class.
  • the node identification function is used by client nodes to identify the node identifier to which a message for the logical name should be sent.
  • Each entry may also include a function name that identifies a function supported by the application. For example, a function name of an address book application for inserting a new entity may be “insert address.”
  • the logical name table contains an entry for each logical destination known to this node.
  • the logical name table may also contain a mapping of user names to user identifiers.
  • the user name is the logical name.
  • the fully qualified logical name is the user identifier that uniquely identifies the user. There may be more than one user name (e.g., aliases) associated with a user identifier.
  • the logical routing table includes a key function, criteria declaration, and route table. The criteria defines the data to be passed to the key function to generate a key. The key is then used to locate the node identifier from the route table.
  • FIG. 8 illustrates data structures used by the physical routing layer in one embodiment.
  • the data structures of the physical routing layer include a physical routing table 801 and a peer table 802 .
  • the physical routing table contains an entry for each node identifier known to this node. Each entry maps the node identifier to the peer node identifier through which the node identifier is accessible.
  • the peer table contains an entry for each peer node of this node. Each entry maps the node identifier to the network address of the peer node.
  • FIGS. 9-27 are flow diagrams of functions of the logical routing system in one embodiment.
  • FIGS. 9-15 are flow diagrams illustrating the processing of the physical routing layer in one embodiment.
  • FIGS. 9-12 illustrate the send processing of the physical routing layer.
  • FIG. 9 is a flow diagram illustrating the processing of the send message function of the physical routing layer in one embodiment. The function is passed a destination node (i.e., component) identifier and a message and sends the message to the identified destination node. This function is invoked by the logical routing layer.
  • a destination node i.e., component
  • decision block 901 if an entry for the destination node identifier is in the physical routing table, then a route to the destination node has previously been identified and the function retrieves that entry and continues at block 902 , else the function continues at block 905 .
  • the function adds to the header of the message route information that includes the node identifier of this node.
  • the receiving node can update its physical routing table to indicate that the nodes on that path are accessible.
  • the function retrieves the node identifier of the peer node from the entry and then retrieves the network address (e.g., the IP address and port number) for that peer node from the peer table. The function then sends the message to the retrieved network address.
  • decision block 904 if sending the message was successful, then the function returns an indication of success, else the function returns an indication of error.
  • Blocks 905 - 914 are performed when an entry for the passed node identifier is not in the physical routing table. These blocks attempt to find a route through which the message can be sent to the destination node.
  • the function invokes the “search for route to node” function, which searches for a peer node through which the destination node is accessible.
  • the invoked function finds such a peer node, then it adds an entry to the physical routing table and returns an indication of success.
  • decision block 906 if a route was found, then the function continues at block 907 , else the function continues at block 908 .
  • the function retrieves the entry for the destination node from the physical routing table and continues at block 902 to send the message to the destination node.
  • decision block 908 if the policy for this node allows for a new peer connection to be created, then the function continues at block 909 , else the function continues at block 913 .
  • An example policy may limit the number of connections to peer nodes to four. If this node already has four peer nodes, then the policy prevents connection to a fifth peer node.
  • the function invokes the lookup node function, which identifies the network address for the destination node and adds it to the peer table.
  • the invoked function may send a message to a server node to see if the destination node has registered with the server node.
  • the invoked function also adds an entry to the peer table to store the node identifier and network address for the destination node.
  • decision block 910 if the destination node was found, then the function continues at block 911 , else the function continues at block 914 .
  • the function invokes the establish peer connection function to establish a peer connection with the destination node and to update the physical routing table.
  • decision block 912 if a connection is established to the destination node, then the function continues at block 907 to send the message directly to the destination node, else the function continues at block 913 .
  • decision block 913 if the policy of this node allows for server node forwarding, then the function continues at block 903 to forward the message to the server node, else the function returns an indication of error.
  • server node forwarding is allowed, this node sends the message to the server node so that the server node can forward the message to the destination node either now if the destination node is online or later when the destination node comes online.
  • decision block 914 if the message should be dropped, then the function returns an indication of error, else the function continues in block 913 .
  • FIG. 10 is a flow diagram illustrating the processing of the “search for route to node” function in one embodiment.
  • the function is passed the node identifier of the destination node.
  • the function is invoked to identify a path from a peer node of this node to the destination node.
  • the function sends a message to each peer node of this node indicating that this node is searching for a path to the destination node.
  • a peer node responds to the message when it has identified a path through the peer node to the destination node.
  • searching techniques may be used.
  • the messages may be sent to the peer nodes so that each peer node can attempt to identify a path before a message is sent to the next peer node, rather than initially sending a message to each peer node.
  • decision block 1001 if this node has any peer nodes, then the function continues at block 1002 , else the function returns an indication of error.
  • the function creates a node search message that includes the identifier of this node and the destination node.
  • the function sends a copy of the node search message to each peer node of this node.
  • the function sets a timer to limit the time that this node waits for a response from a peer node.
  • the function waits for a response from a peer node or for a timeout.
  • decision block 1006 if a response was received, then the function continues at block 1007 , else the timeout occurred and the function returns an indication of error.
  • the function updates the physical routing table by adding an entry to indicate that the destination node is accessible through the peer node that sent the response. The function cancels the timer and then returns an indication of success.
  • FIG. 11 is a flow diagram illustrating the processing of the lookup node function in one embodiment.
  • This function is passed the node identifier of the destination node.
  • the function contacts the server node to retrieve the network address for the destination node and adds an entry to the peer table if the server node responds with the network address of the destination node.
  • decision block 1101 if the appropriate connection to the server node is available, then the function continues at block 1101 , else the function returns an indication of error.
  • the function creates a lookup node message that includes the destination node identifier.
  • the function sends the lookup node message to the server node.
  • the function sets a timer.
  • the function waits for a response from the server node or a timeout.
  • decision block 1106 if a response is received from the server node, then the function continues at block 1107 , else a timeout has occurred and the function returns an indication of error.
  • the function adds an entry to the peer table that indicates the network address of the destination node, which was returned in the message. The function cancels the timer and then returns an indication of success.
  • this node may request its peer nodes to contact the server node on its behalf or may check locally cached information relating to the network address of various nodes.
  • FIG. 12 is a flow diagram illustrating the processing of the establish peer connection 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.
  • the function looks up the destination node identifier in the peer table.
  • decision block 1202 if the network address of the destination node is in the peer table, then the function continues at block 1203 , else a connection cannot be established and the function returns an indication of error.
  • the function creates a peer connect request message that identifies this node.
  • the function sends the peer connect request message to the network address for the destination node.
  • the function To send the message, the function establishes a transport level connection to the network address and then sends the message. If a connection cannot be established, then the function returns an indication of error. In block 1205 , the function sets a timer. In block 1206 , the function waits for a response from the destination node or a timeout. In decision block 1207 , if a response is received from the destination node, then the function continues at block 1208 , else a timeout occurred and the function returns an indication of error. In block 1208 , the function cancels the timer.
  • the function continues at block 1210 , else the destination node is not willing to connect to this node and the function returns an indication of error.
  • the function authenticates the destination node. Various well-known authentication techniques can be used, such as use of public/private key pairs in which the destination node sends a message encrypted with its private key and this node decrypts the message using the public key. If the destination node cannot be authenticated, then the function returns an indication of error.
  • the function updates the physical routing table to indicate that the destination node is accessible as a peer node (i.e., connected at the physical routing layer) and then returns an indication of success.
  • FIGS. 13-15 are flow diagrams illustrating the processing of a received message of the physical routing layer.
  • FIG. 13 is a flow diagram illustrating the processing of the receive message function of the physical routing layer in one embodiment.
  • the function is passed a message that has been received from a peer node.
  • the function determines whether the message is intended for this node or another node. If the message is intended for this node, then the function forwards the message to the logical routing layer.
  • 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 originating node to this node.
  • the function updates the physical routing table to add any of the nodes identified in the message header that are not already in the physical routing table. The updates indicate that the identified nodes are accessible through the peer node that sent the message.
  • decision block 1303 if the destination node is this node, then the function continues at block 1304 , else the function continues at block 1305 .
  • decision block 1304 if the message is a response to a message previously sent, then the function continues at block 1304 A, else the function continues at block 1304 B.
  • the function notifies the logical routing layer that a response has been received by invoking the get response function of the logical routing layer and then returns.
  • the function invokes the receive logical message function of the logical routing layer passing the received message to pass the message to the logical routing layer and then returns.
  • decision block 1305 if the message is a node search request, then the function continues at block 1306 , else the function continues at block 1306 A.
  • the function invokes the process node search function passing the identifier of the destination node and the message and then returns. The invoked function checks the physical routing table of this node to determine whether the destination node is accessible through this node. If not, it sends the search request to its peer nodes.
  • decision block 1306 A if the message is a logical name search request, then the function continues at block 1306 A, else the function continues at block 1307 .
  • the function invokes the process logical name search function of the logical routing layer.
  • the function invokes the forward message function to forward the message onto the next route (i.e., a peer node of this node) in the path to the destination node and then returns.
  • FIG. 14 is a flow diagram illustrating the processing of the forward message function of the physical routing layer in one embodiment.
  • the function is passed a destination node identifier and a message to be forwarded. This function sends the message to a peer node that is in the path to the destination node.
  • the function updates the message to add the information about this node into the message header.
  • the function decrements the hop count in the message header. Each hop corresponds to a node along the path to the destination node. The hop count indicates the maximum number of hops that a message can travel on its way to the destination node. The node that originates the message can set the hop count.
  • the message header may contain an indication of the number of hops that the message has traveled.
  • Each node can decide, based on that number, whether to continue forwarding the message.
  • decision block 1403 if the hop count is zero, then the function continues at block 1407 , else the function continues at block 1404 .
  • decision block 1404 if the destination node identifier is in the physical routing table, then the destination node is accessible through this node and the function continues at block 1405 , else the function continues at block 1407 .
  • the function sends the message to a peer node through which the destination node is accessible.
  • decision block 1406 if sending the message was successful, then the function reports an indication of success and returns, else the function reports an indication of error and returns.
  • decision block 1407 if the policy of this node allows for forwarding to the server node, then the function continues at block 1408 , else the function reports an indication of error and returns.
  • decision block 1408 if a server node connection is available, then the function continues at block 1408 to forward the message to the server node, else the function reports an indication of error and returns. The server node can then forward the message to the destination node now if it is online or later when the destination node comes online.
  • FIG. 15 is a flow diagram illustrating the processing of the process node search function in one embodiment.
  • the 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. If this node has already processed this message when the message was received from a different peer node, then the function may return without further processing.
  • decision block 1501 if the destination node identifier is in the physical routing table, then the destination node is accessible through this node and the function continues at block 1502 , else the function continues at block 1504 .
  • the function sends the message to the next peer node in the path as indicated in the physical routing table.
  • the function sends a message to each of those peer nodes.
  • decision block 1503 if sending the message to at least one peer node was successful, then the function returns, else the function reports an indication of error and returns.
  • blocks 1504 - 1509 the function forwards the search message to the peer nodes of this node.
  • the function decrements the hop count.
  • decision block 1505 if the hop count is equal to zero, then the function discards the message and returns, else the function continues at block 1506 .
  • the function identifies the next peer node to forward the search message based on a search algorithm.
  • the search algorithm described here is one that exhaustively searches all peer nodes to locate a destination node.
  • Alternative search algorithms may select a single peer node for search message forwarding.
  • the search algorithms may be optimized to best suit node topologies, hop counts, geographic location, and application requirements.
  • decision block 1507 if a next peer node was identified, then the function continues at block 1508 , else the function continues at block 1510 .
  • the function updates the message to add the information relating to this node to the message header.
  • the function creates a copy of the message for each peer node to which the message is to be sent and continues at block 1502 to send the message to each identified peer node.
  • the function discards the message and returns.
  • FIGS. 16-25 are flow diagrams illustrating the processing of the logical routing layer in one embodiment.
  • FIGS. 16-21 are flow diagrams, illustrating the processing of a send message of the logical routing layer.
  • FIG. 16 is a flow diagram illustrating the processing of the send logical message function of the logical routing layer in one embodiment.
  • the send logical message function is passed a logical destination and a message.
  • the logical destination indicates where the message is to be sent.
  • the logical destination may be identified by a user name, a logical name (.e.g., “address book”) or a fully qualified logical name (e.g., “addressbook.node.opendesign.com”).
  • the function determines the identifier of the destination node corresponding to that logical destination and sends the message to that node by invoking the send message function of the physical routing layer.
  • the function invokes the resolve logical destination function.
  • the invoked function updates the logical routing table to add an entry for the logical destination if such an entry is not already in the table.
  • decision block 1602 if the logical destination was successfully resolved, then the function retrieves the entry from the logical routing table and continues at block 1604 , else the function returns an indication of error.
  • the function computes the destination node identifier by invoking the node identification function of the retrieved entry passing the message.
  • the function invokes the send message function of the physical routing layer to send the message to the destination node and then returns the indication of success or error that is returned by the invoked send message function.
  • the node identification function may use a criteria, a key function and a routing table. The key function is invoked passing the criteria to generate a key. The key is then used to search the routing table to identify the node identifier.
  • the criteria for the address book application may be the last name, and the key function may return the first letter of the last name.
  • the routing table may be a tree that maps letters to node identifiers.
  • FIG. 17 is a flow diagram illustrating the processing of the resolve logical destination function of the logical routing layer in one embodiment.
  • This function is passed an indication of a logical destination and returns a fully qualified logical name.
  • decision block 1701 if the logical destination is a user name, then the function continues at block 1710 , else the function continues at block 1702 .
  • decision block 1702 if the logical name of the logical destination is local to this node, then the function continues at block 1703 , else the function continues at block 1705 .
  • the function retrieves the entry for the logical name from the logical routing table. The entry includes the fully qualified logical name.
  • decision block 1704 if an entry for the logical name is found, then the function continues at block 1705 , else the function returns an indication of error.
  • the function retrieves an entry for the fully qualified logical name from the logical routing table.
  • decision block 1706 if the entry for the fully qualified logical name was retrieved, then the function sets the logical destination to the fully qualified logical name and returns an indication of success, else the function continues at block 1707 .
  • the function invokes the search logical destination function to search for the logical destination globally. The invoked function may search at a server node or through peer nodes to find the fully qualified logical name.
  • decision block 1708 if a fully qualified logical name was found while searching, then the function returns an indication of success, else the function returns an indication of error.
  • the function invokes the user information function to find the user identifier for the user name. The invoked function may add an entry to the logical routing table to map the user identifier to the node identifier. The function then returns an indication of success.
  • FIG. 18 is a flow diagram illustrating the processing of the search logical destination function of the logical routing 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 (if not already added) to map the fully qualified logical name to a node identifier.
  • the node identifier can be extracted from the fully qualified name.
  • the node identifier is retrieved by sending a message to a logical destination of the logical routing map. In this described embodiment, however, the node identifier is either retrieved from a server node or by searching peer nodes. This function sends a message to a server node that stores global logical destination information.
  • the function sends a search message to its peer nodes, which it propagated throughout the network.
  • the function looks up the passed logical destination in the logical routing table.
  • decision block 1802 if an entry for the logical destination was found, then the function returns an indication of success, else the function continues at block 1803 .
  • the function creates a logical name lookup message of class SN. The message indicates that the sending node is requesting information for mapping the logical name to a node identifier.
  • the function invokes the send logical message function passing the created message and the node identifier logical destination of the server node.
  • decision block 1805 if the message was sent successfully, then the function continues at block 1806 , else the function returns an indication of error.
  • the function invokes the get response function to wait for a response to be received.
  • decision block 1807 if a response was received, then the function continues at block 1808 , else the function continues at block 1809 .
  • the function invokes the process logical destination update function to update the logical routing table and then returns an indication of success.
  • the function creates a logical name lookup message of class SEARCH.
  • the SEARCH class indicates that message is sent from a peer node to search for a node identifier.
  • the function invokes the send message function of the physical routing layer to send the created message.
  • the search message is sent to peer nodes that respond when the logical destination can be accessed through them.
  • decision block 1811 if the send message indication was successful, then the function continues at block 1812 , else the function returns an indication of error.
  • the function invokes the get response function to wait for a message or a timeout.
  • decision block 1813 if a response was received, then the function continues at block 1814 , else the function returns an indication of error.
  • the function invokes the process logical destination update function to update the logical routing table and then returns an indication of success.
  • FIG. 19 is a flow diagram illustrating the processing of the get response function of the logical routing layer in one embodiment.
  • This function is a low-level function that is used to set a timer and wait for either a response to a message or a time out.
  • the function sets a timer.
  • decision block 1902 if a response was received, then the function continues at block 1903 , else a timeout occurred and the function returns an indication of error.
  • the function cancels the timer and returns an indication of success.
  • FIG. 20 is a flow diagram illustrating the processing of the process logical destination update function of the logical routing layer in one embodiment.
  • This function is passed information for a logical destination and updates an existing entry in, or adds a new entry to, the logical routing table for that logical destination.
  • the function looks up the passed logical destination in the logical routing table.
  • decision block 2002 if the logical destination was found, then the function continues at block 2004 , else the function continues at block 2003 .
  • the function adds a new entry for the logical destination to the logical routing table.
  • the function updates the entry in the logical routing table with the class and node identification function. The function then returns an indication of success.
  • FIG. 21 is a flow diagram illustrating the processing of the user information function of the logical routing layer in one embodiment.
  • This function is passed a user name, updates the logical routing table as appropriate to map the user identifier for the user name to a node identifier and returns the user identifier as the logical destination.
  • the function looks up the user name in the logical routing table.
  • decision block 2102 if the lookup was successful, then the function returns the user identifier as the logical destination along with an indication of success, else the function continues at block 2103 .
  • the function creates a get user identifier message of class SN. The message is a request to retrieve a user identifier associated with a user name.
  • the function invokes the send logical message function to send the created message to a logical destination that maps user names to user identifiers.
  • decision block 2105 if the message was successfully sent, then the function continues at block 2106 , else the function returns an indication of error.
  • the function invokes the get response function.
  • decision block 2107 if a response was successfully received, then the function continues at block 2108 , else the function returns an indication of error.
  • 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.
  • the function creates a node user message of class SN.
  • the function invokes the send logical message function to send the created message to the logical destination of the logical routing map to find out the node(s) of the user identifier.
  • the function if the message was successfully sent, then the function continues at block 2112 , else the function returns an indication of error.
  • the function invokes the get response function.
  • decision block 2113 if a response was successfully received, then the function continues at block 2114 , else the function returns an indication of error.
  • the function updates the logical routing table to add an entry for the user identifier and node identifier provided in the response and then returns the user identifier as the logical destination along with an indication of success.
  • FIG. 22 is a flow diagram illustrating the processing of the receive logical message function of the logical routing layer in one embodiment.
  • This function is passed the received message. If the logical function and specified instance of the message are known to this node, then the function computes the node identifier. If the identified node is this node, then the function passes the message to the application for processing. Otherwise, the function sends the message to the identified node.
  • the function retrieves the logical destination from the message header along with the function and instance specified in the message header.
  • the message header includes a logical destination (“Iname”), a class (“class”), and a criteria (“crit”).
  • decision block 2202 if the class is supported by this node as indicated by the logical routing table, then the function continues at block 2203 , else the function reports an indication of error and returns.
  • decision block 2203 if the logical destination is known to this node as indicated by the logical routing table, then the function continues at block 2204 , else the function reports an indication of error and returns.
  • the function computes the destination node identifier based on the node identification function for the logical destination and the criteria.
  • decision block 2205 if the destination node identifier was successfully computed, then the function continues at block 2206 , else the function reports an indication of error and returns.
  • decision block 2206 if the computed node identifier identifies this node, then the function continues at block 2207 , else the function continues at block 2208 .
  • the function consumes the message and returns.
  • the function invokes the send message function of the physical routing layer to send the message to the computed node identifier and then returns.
  • FIG. 23 is a flow diagram illustrating the processing of the register logical name function of the logical routing layer in one embodiment.
  • This function is invoked by application programs to register their logical name both locally and globally.
  • This function is passed the logical name and name class.
  • decision block 2301 if the combination of logical name and class is not in the logical routing table, then the function continues at block 2302 , else the function returns an indication of error.
  • the function creates a fully qualified logical name from the passed logical name. For example, the function may append the identifier of this node along with a registered domain name to the logical name to generate the fully qualified logical name (e.g., “logicalname” to “logicalname.nodeID.company.com”).
  • the function adds an entry to the logical routing table for the logical name. This entry includes the node identification function.
  • the function creates a message to register the logical name globally.
  • the function invokes the send logical message function of the logical routing layer to send the registration message for registration with the logical routing map.
  • decision block 2306 if the message was sent successfully, then the function returns an indication of success, else the function continues at block 2307 .
  • the function sets a timer for retrying the sending of the registration message and then returns an indication of error.
  • FIG. 24 is a flow diagram illustrating the processing of the generate logical destination update function of the logical routing layer in one embodiment.
  • This function is invoked when this node is to respond to a search message for a logical destination or when this node detects that the node identification function of a client node (i.e., a node using the services of an application of this node) is not current.
  • This function is passed a logical name.
  • the function retrieves the entry for the logical name in the logical routing table.
  • decision block 2402 if an entry was found, then the function continues at block 2403 , else the function returns an indication of error.
  • the function creates a message that contains the node identification function and returns an indication of success.
  • FIG. 25 is a flow diagram illustrating the processing of the process logical name search function of the logical routing layer in one embodiment.
  • the function is passed a logical name and a message. This function is invoked when the physical routing layer receives a logical name search request.
  • decision block 2501 if the logical name is in the logical routing table, then the function continues at block 2502 , else the function continues at block 2506 .
  • the function invokes the generate logical destination update function to retrieve and prepare the information (e.g., node identification function) for the passed logical name.
  • the function creates a logical route search response that includes the node identification function.
  • the function sends the response to a peer node to be sent back to the originating node.
  • decision block 2505 if the response was sent successfully, then the function returns, else the function reports error and then returns.
  • the function decrements the hop count.
  • decision block 2507 if the hop count is zero, then the function continues at block 2512 , else the function continues at block 2508 .
  • the function determines the next peer node based on a search algorithm.
  • decision block 2509 if a peer node was identified, then the function continues at block 2510 , else the function continues at block 2512 .
  • the function updates the message to add the node identifier of this node.
  • the function creates the copies of the message for each peer node to which the message is to be sent and continues at block 2504 to send a message to each peer node.
  • the function discards the message and then returns.
  • FIG. 26 is a flow diagram illustrating the processing of an application initialization function in one embodiment.
  • This function illustrates the use of the logical routing layer by an application.
  • the function authenticates the application with the server node.
  • decision block 2602 if the authentication is successful, then the function continues at block 2603 , else the function reports an indication of error and completes.
  • the function invokes the register logical names function to register the logical routing map associated with this application. The function also adds entries to the logical routine table for this application.
  • the function creates a request message to be sent to a logical destination. This reflects the actual processing that may be done by the application.
  • the function invokes the send logical message function of the logical routing layer to send a message to the logical destination.
  • decision block 2606 if the message was successfully sent, then the function completes, else the function reports an error and completes.
  • FIG. 27 is a flow diagram illustrating the processing of a function of an application that receives a message from the logical routing layer.
  • the function authenticates the message.
  • decision block 2703 if the message is authenticated, then the function continues at block 2704 , else the function reports an error and then completes.
  • the function consumes the message.
  • decision block 2705 if a response is to be sent, then the function continues at block 2706 , else the function completes.
  • the function creates a response.
  • the function invokes the send logical message function of the logical routing layer to send the response.
  • decision block 2708 if the sending of the logical message was successful, then the function completes, else the function reports an error and then completes.

Abstract

A method and system for mapping logical identifiers to physical identifiers is provided. In one embodiment, a logical routing system allows each application, or more generally entity (e.g., user of an application), to register its logical identifier to physical identifier mapping when the application starts executing on a computer. To send a message to an application identified by a logical identifier, a client program uses the registered mapping to identify the physical identifier of the computer. If an application later starts executing on a different computer, then the application can register a different mapping.

Description

    CROSS-REFERENCE TO RELATED APPLICATION(S)
  • This application is a continuation of U.S. patent application Ser. No. 10/076,214 entitled “LOGICAL ROUTING SYSTEM” filed Feb. 12, 2002, which application claims the benefits of U.S. application Ser. No. 10/021,265 entitled “APPLICATION PLATFORM” filed Nov. 16, 2001 and U.S. Provisional Application No. 60/268,386 entitled “LOGICAL ROUTING” filed Feb. 12, 2001, all of which are hereby incorporated by reference.
  • BACKGROUND
  • The described technology generally relates to mapping of logical identifiers to physical identifiers.
  • Application programs such as a Web browser access resources using the HTTP protocol. The HTTP protocol uses a Uniform Resource Identifier (“URI”) to identify a resource to be accessed. A URI is either a Uniform Resource Locator (“URL”) or Uniform Resource Name (“URN”), or any other formatted string that identifies a network resource. URLs, as an example of URIs, are discussed in detail in T. Berners-Lee et al., Uniform Resource Locators (URL), RVC 1738, CERN, Xerox PARC, Univ. of Minn., December 1994. Each URL contains a domain name identifying where the resource is located. For example, the URL “http://www.odi.com/home.htm” indicates that the resource named “home.htm” is located at the domain of “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 in the URL. The TCP/IP protocol, however, identifies computers using IP addresses (e.g., “128.32.0.6”) rather than domain names. Various computer techniques 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”) that is 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 uses the HTTP protocol to send a message to a domain name, it submits a resolution request that specifies the domain name to a local domain name server (e.g., provided by an ISP) that is part of the DNS. The local domain name server may be identified in a configuration file of the client computer executing the browser. The local domain name server checks a local cache to determine whether it has a mapping of that domain name to IP address. If so, it returns the IP address to the application. If not, it forwards the resolution request to a root domain name server. The root domain name server contains a mapping of each top-level domain name (e.g., “com”) to its name server(s). 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 the resolution request to the top-level domain name server and receives (and may cache) the name of the domain name server for the second-level domain name (e.g., “odi.com”). 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 an IP address associated with the second-level domain name. Alternatively, it may return the name of the domain name server for the third-level domain name (e.g., “www.odi.com”), and the local domain name server may repeat the process for each level of domain name. Eventually, the local domain name server sends an IP address of the domain name to the computer executing the application. e.g.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram for illustrating the logical routing system in one embodiment.
  • FIG. 2 is a flow diagram illustrating the processing when a client program sends a message to an application.
  • FIG. 3 is a block diagram for illustrating the logical routing system where instances of the application are executing at multiple nodes.
  • FIG. 4 is a block diagram illustrating use of the node identification function to effect load balancing for an application.
  • FIG. 5 is a block diagram illustrating the architecture of the application layer 510, the logical routing layer 520 and the physical routing layer 530 used by the logical routing system.
  • FIG. 6 is a block diagram illustrating connections at the physical routing layer between various nodes.
  • FIG. 7 illustrates a data structure used by the logical routing layer in one embodiment.
  • FIG. 8 illustrates data structures used by the physical routing layer in one embodiment.
  • FIG. 9 is a flow diagram illustrating the processing of the send message function of the physical routing layer in one embodiment.
  • FIG. 10 is a flow diagram illustrating the processing of the “search for route to node” function in one embodiment.
  • FIG. 11 is a flow diagram illustrating the processing of the lookup node function in one embodiment.
  • FIG. 12 is a flow diagram illustrating the processing of the establish peer connection function in one embodiment.
  • FIG. 13 is a flow diagram illustrating the processing of the receive message function of the physical routing layer in one embodiment.
  • FIG. 14 is a flow diagram illustrating the processing of the forward message function of the physical routing layer in one embodiment.
  • FIG. 15 is a flow diagram illustrating the processing of the process node search function in one embodiment.
  • FIG. 16 is a flow diagram illustrating the processing of the send logical message function of the logical routing layer in one embodiment.
  • FIG. 17 is a flow diagram illustrating the processing of the resolve logical destination function of the logical routing layer in one embodiment.
  • FIG. 18 is a flow diagram illustrating the processing of the search logical destination function of the logical routing layer in one embodiment.
  • FIG. 19 is a flow diagram illustrating the processing of the get response function of the logical routing layer in one embodiment.
  • FIG. 20 is a flow diagram illustrating the processing of the process logical destination update function of the logical routing layer in one embodiment.
  • FIG. 21 is a flow diagram illustrating the processing of the user information function of the logical routing layer in one embodiment.
  • FIG. 22 is a flow diagram illustrating the processing of the receive logical message function of the logical routing layer in one embodiment.
  • FIG. 23 is a flow diagram illustrating the processing of the register logical name function of the logical routing layer in one embodiment.
  • FIG. 24 is a flow diagram illustrating the processing of the generate logical destination update function of the logical routing layer in one embodiment.
  • FIG. 25 is a flow diagram illustrating the processing of the process logical name search function of the logical routing layer in one embodiment.
  • FIG. 26 is a flow diagram illustrating the processing of an application initialization function in one embodiment.
  • FIG. 27 is a flow diagram illustrating the processing of a function of an application that receives a message from the logical routing layer.
  • DETAILED DESCRIPTION
  • A method and system for mapping logical identifiers to physical identifiers is provided. In one embodiment, a logical routing system allows each application or entity (e.g., user of an application) to register its logical identifier to physical identifier mapping when the application starts executing on a computer. To send a message to an application identified by a logical identifier, a client program uses the registered mapping to identify the physical identifier of the computer. If an application later starts executing on a different computer, then the application can register a different mapping. In one embodiment, the logical routing system allows an application to register a function that is used to generate the physical identifier for the logical identifier associated with the application. The use of a function allows the mapping to physical identifier to vary based on various criteria, such as location of a client computer or workload balancing goals. The logical routing system also allows a logical identifier to map to multiple physical identifiers. With such a mapping, a client program would send a message to each of the computers identified by the multiple physical identifiers.
  • FIG. 1 is a block diagram for illustrating the logical routing system in one embodiment. The logical routing system is used to send messages between client computer systems 101 (“client nodes”) and application computer systems 103 (“application nodes”). The computer systems are interconnected through a communications mechanism 104, such as the Internet. Applications executing at application nodes provide services to client programs executing at client nodes. The logical routing system provides a logical naming mechanism that allows client nodes to send messages to (e.g., requesting services of) applications by identifying the application by a logical identifier (also referred to as a “logical destination”), rather than a physical identifier (also referred to as a “node identifier”). For example, a logical identifier of an application may be “address book,” whereas a physical identifier may be a globally unique identifier that uniquely identifies the node where the application is executing. (This description uses an “address book” as an example application. An address book application maintains a mapping of names (e.g., John Smith) of people to electronic mail addresses (e.g., JohnSmith@company.com). The address book application receives messages from client programs requesting an electronic mail address for a person and sends a response message to the client program that includes the electronic mail address.) When a client node (or more precisely, a computer program executing at the client node) wants to send a message to an application, it provides the message to a logical routing system along with the logical identifier of the application. The logical routing system identifies the appropriate physical identifier of the node where the application is executing and sends the message to that node. When an application starts its execution at an application node, it registers with the logical routing system. The logical routing system may maintain a mapping from logical identifiers of applications to physical identifiers of the application nodes where the applications are executing. A client node may identify the physical identifiers of an application from the logical identifier using this mapping. A logical identifier may map to multiple physical identifiers of different application nodes. For example, multiple copies of the address book application may be executing at different application nodes to accommodate the demands of the client program. When a client program wants to retrieve an address, then the logical identifier of the retrieve address function might map to only one physical identifier. In contrast, when a client program wants to insert an address, then the logical identifier of the insert address function might map to the physical identifiers of all the nodes where the application is executing. The logical routing system thus provides a mechanism that allows client programs to be developed using logical identifiers of applications and allows the logical identifiers to be resolved to physical identifiers during execution of the client programs. One skilled in the art would appreciate that a program executing at a node can be both an application and a client program in that it may respond to requests for services from client programs and request services from other applications.
  • Applications register themselves with the logical routing system to map their logical identifiers to physical node identifiers. The logical routing system may maintain a logical routing map of these registrations. The logical routing system can implement the logical routing map across the application nodes and client nodes in a distributed manner, can implement the logical routing map as a central system, or can implement the logical routing map by a combination of distributed and centralized systems. When an application registers with the logical routing system, a register message may be sent to a logical destination that identifies the logical routing map (e.g., “logical routing map”). Similarly, when a client program sends a message to an application, the logical routing system may send a message to the same logical destination to retrieve the physical identifiers of the application. More generally, the logical routing map may be considered to be an “application” that is not only used by the logical routing system, but is also accessible through the logical routing system itself.
  • In one embodiment, the logical routing map has a node identification function for each logical name that returns the node identifier of the node associated with that logical name. When the application associated with a logical name registers with the logical routing system, the application provides its node identification function to the logical routing system. The node identification function may input parameters or criteria (e.g., the message to be sent) and returns the appropriate node identifier for those parameters or criteria. For example, applications associated with a logical name may be executing at nodes physically located on each continent. The node identification function may input the country where the sending node is located and return the node identifier for the node located on the continent in which the country is located.
  • The logical routing system allows mappings between logical identifiers and physical identifiers to be dynamically changed. The mappings can be dynamically changed in various ways. For example, an application can dynamically change its mappings by registering a new node identification function, which may be sent to a node executing a client program in response to a request for service by the client program. The node receiving the new node identification function can replace the old node identification function for that application. The logical routing system may use an existing network to transmit the mappings. For example, the existing network may be the IP network and DNS of the Internet. In such a case, the logical identifier may be mapped to a DNS name (i.e., a physical identifier) by the logical routing system and ultimately mapped to an IP address (i.e., a network address) by a transport system of the existing network. The dynamic changing of the mappings allows the servicing of requests to dynamically meet demand. For example, as the demand on the address book application increases, the application can be launched on additional nodes. The new identification function, which is sent to a node executing a client program, can distribute some of the requests to the additional nodes. Similarly, as the demand decreases, the number of nodes executing the address book application can also decrease.
  • The logical routing system uses various criteria for routing messages. The logical routing system may allow the criteria to be supplied by the client program or the application that provides the service. For example, the client program may specify a priority associated with a request, and the node identification function would identify a node that can service a request of that priority. The application may specify that clients in a certain country have all their requests sent to a certain node. The logical routing system allows criteria-based routing to one of multiple copies of an application using the same logical name. For example, to improve communications speed, the node identification function of an application may select a physical identifier for a node that is geographically close to the node of the client program. The logical routing system also allows the services of an application to be distributed over multiple nodes. For example, an address book application may execute on multiple nodes that each service address requests relating to different parts of the alphabet. One node may service requests for names starting with A-M, and another node may service requests for names starting with N-Z.
  • In one embodiment, the logical routing system may use a distributed model for maintaining the mappings of logical identifiers to physical identifiers (e.g., node identification functions). In such a distributed model, each node maintains the mappings for the applications executing on the node. When another node receives a mapping (e.g., because a client program of that other node is sending a message to an application) the other node can cache the mapping. The logical routing system may search for the mapping by sending a search request to the nodes to which it is connected. Each node that receives a search request checks its local cache to see if it has the mapping. If so, it sends the mapping to the requesting node. If not, it forwards the search request to the nodes to which it is connected. Each node that receives the mapping on its way to the requesting node may cache the mapping. (This searching automatically discovers the topology of the network.) A node executing a client program may discover that an application is no longer available when the client program sends a message to that application. Upon such a discovery, the logical routing system may remove the mapping from its cache. The search message is an example of the logical routing system supporting node-level messages. Thus, the logical routing system supports both node-level and application-level messages.
  • In another embodiment, the logical routing system may use a combination of a distributed and a centralized model for maintaining the mappings. In addition to maintaining the mappings at each node, the logical routing system may have a server node that stores all mappings. Each application registers its logical identifier with the logical routing system. The logical routing system may cache a mapping of the logical identifier to physical identifier locally at the node and send the mapping to the server node. When a client program sends a message to the logical identifier, the logical routing system may first checks a local cache of mappings. If the logical identifier is not in the local cache, the logical routing system may request the mapping from the server node. If the server node is not available, then the logical routing system may search for the mapping in the same way as with the distributed model.
  • A logical identifier may identify a user. When a user logs on to an application or node, that user can be registered with the logical routing system using a logical identifier, such as the user's name. When another user wants to send a message to the user, the 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 it transmits messages to client programs. Indeed, the logical routing system may send the message to a client program that is responsible for displaying the message to the user.
  • In one embodiment, the logical routing system maps from a logical identifier to a physical identifier and a transport system maps from the physical identifier to the network address. One skilled in the art, however, will appreciate that the physical identifier might be the ultimate identifier used by the transport system. (For example, the physical identifier might be a network address.) In such a case, the transport system would not perform any mapping and would route messages to the nodes identified by physical identifier. One skilled in the art would also appreciate that the functions of the logical routing system can be integrated into a transport system and may even be considered part of a physical layer.
  • FIG. 2 is a flow diagram illustrating the processing when a client program sends a message to an application. In block 201, an application when it starts execution registers its logical identifier and the physical identifier of the node at which it is currently executing with the logical routing system. (Client programs register in a similar way.) In one embodiment, rather than registering the actual physical identifier, a node identification function is registered. Whenever the physical identifier is needed, the node identification function is invoked, passing the message to be sent, and returns one or more physical identifiers. For example, the address book application may register a node identification function that maps the last name of a person to the physical identifier of the node that is executing the instance of the application that is responsible for servicing requests with that last name. In block 202, the logical routing system stores the mapping of logical identifier to node identification function for the application. In block 203, the client program invokes the logical routing system to send a message to an application identified by a logical identifier. In 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 an instance of application. The logical routing system sends the message to the node addressed by that physical identifier. The logical routing system at the application node, upon receiving the message, may determine whether the message should be forwarded to another node or processed by this node. The logical routing system at the application node may use a node identification function to identify the node that is to process the message. In block 206, assuming that the message is to be processed at this node, the application processes the message. In block 207, the application sends a response to the client node using the logical routing system. The logical routing system may 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 passes the response to the client program and uses the updated node identification function when sending subsequent messages to the logical identifier. The updated node identification function may reflect the changing architecture of how the application is distributed across multiple application nodes.
  • FIG. 3 is a block diagram for illustrating the logical routing system where instances of the application are executing at multiple nodes. The application is executing at application nodes 303, 305 and 306. The application was initially executing only one instance at application node 303. As the demand for the address book services increased, application nodes 305 and 306 were brought online and started executing instances of the application. The application node 303 services requests for names beginning with the letters A-J, application node 305 services requests for names beginning with the letters K-S, and application node 306 services requests for names beginning with the letters T-Z. Continuing with the example of FIG. 2, when the client program wants to request an address for “John Smith,” the logical routing system uses the node identification function for the logical identifier of “address book,” which identifies application node 303. The logical routing system sends the request to application node 303. When the logical routing system at application node 303 receives the request, it uses its node identification function to identify application node 305. 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. The instance of the application executing at application node 305 retrieves the electronic mail address and sends the address to the client node. The logical routing system of application node 305 may also send to the client node an updated node identification function that maps names beginning with the letters A-J to application node 303, names beginning with the letters K-S to application node 305 and names beginning with the letters T-Z to application node 306. In this way, when the logical routing system of the client node next uses the updated node identification function, it will identify the appropriate application node that is responsible for servicing the request and send the request directly to the identified application node. Alternatively, if application node 305 does not send an updated node identification function, then subsequent requests will be routed through application node 303. If multiple instances of an application provide the same capabilities, then the node identification function may select the physical identifier of an instance randomly, may select the physical identifier based on geographic proximity to the client node, and so on.
  • FIG. 4 is a block diagram illustrating use of the node identification function to effect load balancing for an application. The client nodes 401 use a node identification function that maps to one of the load balancing nodes 402. For example, the node identification function may randomly select one of the load balancing nodes. The node identification function used by the client nodes may be provided by the load balancing nodes. When a load balancing node receives a request from a client node, it uses a different node identification function provided by the application to identify the application node 403 that is to service the request. For example, there may be multiple instances of the address book application that services requests for names beginning with the letters A-J. Each load balancing node can decide in which of those instances to send a request.
  • FIG. 5 is a block diagram illustrating the architecture of the application layer 510, the logical routing layer 520 and the physical routing layer 530 used by the logical routing system in one embodiment. One skilled in the art will appreciate that the function and data structures of the 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 a message to a node identified by a node identifier. Each node in the network maybe 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 messages using the send message component and receives messages via the receive message component. The send message component is passed a message and a destination node identifier (e.g., “www.odi.com”) and locates the network address (e.g., IP address and port) for that destination node identifier. The send message component then invokes the underlying transport layer, such as TCP/IP, to deliver the message to the network address. The send message component may request a physical routing map to provide the network address for the destination node identifier or may request other nodes to which it is connected (i.e., peer nodes) if they know of the network address for the destination node. The send message component may cache the network address in a physical routing table for use when sending subsequent messages to that destination node. The send message component then sends the message to that network address. The message may be sent by establishing a direct connection between the originating node and the destination node, by forwarding the message to the destination node via a peer node of the originating node, or by sending a message to a physical routing server for forwarding to the destination node. The send message component uses a “search for route to node” component 533, a lookup node component 534 and establish peer connection component 535, as described below in more detail. The receive message component processes messages that are received for a destination node. If this node (i.e., the node where a component is executing) is not the destination node, then the receive message component attempts to forward the message to the destination node. If the message indicates that an originating node is searching for a path to a destination node, then this node either responds to the search request, if it knows a path to the destination node, or forwards the search request to its peer nodes. If the message is intended for processing at this node, then the receive message component passes the message to the logical routing layer by invoking the receive logical message component 522 or the process logical name search component 529A.
  • The logical routing layer provides a send logical message component 521, a receive logical message component 522, a register logical name component 523, a process logical name search component 529A, and a generate logical destination update function 529. The application layer sends messages to a logical destination, which may be an application or a user, using the send logical message component and receives response messages from the logical destination via the receive logical message component. The send logical message component is passed a logical identifier and a message, identifies the destination node identifier for the logical identifier, and uses the send message component of the physical routing layer to send the message to the destination node. The send logical message component may identify the destination node identifier using a node identification function provided by a central server, by a search of peer nodes, or by the logical destination itself. The send logical message component may cache the mapping of the logical identifier to the node identification function. The send logical message component uses a resolve logical destination component 524, a user information component 525, a logical destination search component 526, a get response component 527, and a process logical destination update component 528 that are described below in detail. The receive logical message component is invoked by the receive message component of the physical routing layer to pass the message to the logical routing layer. The receive logical message component processes the message and provides the message to the application layer. The process logical name search function and the generate logical destination update function are described below in detail. The register logical name component is used by the application layer to register a logical identifier with the logical routing layer. The generate logical destination update component is invoked by the process logical name search component. The application layer may provide an application initialization component 511 and an application receive component 512. The application initialization component may register the application's logical identifier with the logical routing layer. The application receive component is invoked by the receive logical message component to effect the passing of the message from the logical routing layer to the application layer. The application layer also invokes the send logical message to send messages to a logical destination.
  • The logical routing system may execute on computer systems that include main memory, a central processing unit, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices) and a hard drive. The main memory and hard drive are computer-readable media that may contain instructions that implement the logical routing system. The computer systems may be interconnected via various communication channels that include the Internet, a wide area network, a point-to-point dial-up connection, or a local area network.
  • FIG. 6 is a block diagram illustrating connections at the physical routing layer between various nodes. 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 client node 602 is to send a message to application node 604, which is identified by a destination node identifier, the send message component may attempt to establish a direct connection with the application node. However, if a connection cannot be established, then the send message component of client node 602 determines whether the application node is accessible through any of its peer nodes. In this case, application node 604 is accessible to client node 602 via client node 603. Thus, the 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. The logical name table 701 (also referred to as a logical routing table) contains an entry for each logical name associated with an application executing at the node. A logical name is a logical identifier that identifies an application. A 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 identification function. The fully qualified logical identifier uniquely identifies the logical name associated with the application. The class identifies a message class of the logical destination. For example, the class may be database, application or user. A logical identifier is unique within a class. The node identification function is used by client nodes to identify the node identifier to which a message for the logical name should be sent. Each entry may also include a function name that identifies a function supported by the application. For example, a function name of an address book application for inserting a new entity may be “insert address.” The logical name table contains an entry for each logical destination known to this node. The logical name table may also contain a mapping of user names to user identifiers. The user name is the logical name. The fully qualified logical name is the user identifier that uniquely identifies the user. There may be more than one user name (e.g., aliases) associated with a user identifier. In an alternate embodiment (described below), the logical routing table includes a key function, criteria declaration, and route table. The criteria defines the data to be passed to the key function to generate a key. The key is then used to locate the node identifier from the route table.
  • FIG. 8 illustrates data structures used by the physical routing layer in one embodiment. The data structures of the physical routing layer include a physical routing table 801 and a peer table 802. The physical routing table contains an entry for each node identifier known to this node. Each entry maps the node identifier to the peer node identifier through which the node identifier is accessible. The peer table contains an entry for each peer node of this node. Each entry maps the node identifier to the network address of the peer node.
  • FIGS. 9-27 are flow diagrams of functions of the logical routing system in one embodiment. One skilled in the art will appreciate that the functions described herein may implement only a subset of the described functionality, may reorder the described functionality, or may implement additional functionality. FIGS. 9-15 are flow diagrams illustrating the processing of the physical routing layer in one embodiment. FIGS. 9-12 illustrate the send processing of the physical routing layer. FIG. 9 is a flow diagram illustrating the processing of the send message function of the physical routing layer in one embodiment. The function is passed a destination node (i.e., component) identifier and a message and sends the message to the identified destination node. This function is invoked by the logical routing layer. In decision block 901, if an entry for the destination node identifier is in the physical routing table, then a route to the destination node has previously been identified and the function retrieves that entry and continues at block 902, else the function continues at block 905. In block 902, the function adds to the header of the message route information that includes the node identifier of this node. When a message is received by a node, it will have a history of the nodes on the path traveled so far. The receiving node can update its physical routing table to indicate that the nodes on that 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 (e.g., the IP address and port number) for that peer node from the peer table. The function then sends the message to the retrieved network address. In decision block 904, if sending the message was successful, then the function returns an indication of success, else the function returns an indication of error. Blocks 905-914 are performed when an entry for the passed node identifier is not in the physical routing table. These blocks attempt to find a route through which the message can be sent to the destination node. In block 905, the function invokes the “search for route to node” function, which searches for a peer node through which the destination node is accessible. If the invoked function finds such a peer node, then it adds an entry to the physical routing table and returns an indication of success. In decision block 906, if a route was found, then the function continues at block 907, else the function continues at block 908. In block 907, the function retrieves the entry for the destination node from the physical routing table and continues at block 902 to send the message to the destination node. In decision block 908, if the policy for this node allows for a new peer connection to be created, then the function continues at block 909, else the function continues at block 913. An example policy may limit the number of connections to peer nodes to four. If this node already has four peer nodes, then the policy prevents connection to a fifth peer node. In block 909, the function invokes the lookup node function, which identifies the network address for the destination node and adds it to the peer table. The invoked function may send a message to a server node to see if the destination node has registered with the server node. The invoked function also adds an entry to the peer table to store the node identifier and network address for the destination node. In decision block 910, if the destination node was found, then the function continues at block 911, else the function continues at block 914. In block 911, the function invokes the establish peer connection function to establish a peer connection with the destination node and to update the physical routing table. In decision block 912, if a connection is established to the destination node, then the function continues at block 907 to send the message directly to the destination node, else the function continues at block 913. In decision block 913, if the policy of this node allows for server node forwarding, then the function continues at block 903 to forward the message to the server node, else the function returns an indication of error. When server node forwarding is allowed, this node sends the message to the server node so that the server node can forward the message to the destination node either now if the destination node is online or later when the destination node comes online. In decision block 914, if the message should be dropped, then the function returns an indication of error, else the function continues in block 913.
  • FIG. 10 is a flow diagram illustrating the processing of the “search for route to node” function in one embodiment. The function is passed the node identifier of the destination node. The function is invoked to identify a path from a peer node of this node to the destination node. The function sends a message to each peer node of this node indicating that this node is searching for a path to the destination node. A peer node responds to the message when it has identified a path through the peer node to the destination node. One skilled in the art will appreciate that different searching techniques may be used. For example, the messages may be sent to the peer nodes so that each peer node can attempt to identify a path before a message is sent to the next peer node, rather than initially sending a message to each peer node. In decision block 1001, if this node has any peer nodes, then the function continues at block 1002, else the function returns an indication of error. In block 1002, the function creates a node search message that includes the identifier of this node and the destination node. In block 1003, the function sends a copy of the node search message to each peer node of this node. In block 1004, the function sets a timer to limit the time that this node waits for a response from a peer node. In block 1005, the function waits for a response from a peer node or for a timeout. In decision block 1006, if a response was received, then the function continues at block 1007, else the timeout occurred and the function returns an indication of error. In block 1007, the function updates the physical routing table by adding an entry to indicate that the destination node is accessible through the peer node that sent the response. The function cancels the timer and then returns an indication of success.
  • FIG. 11 is a flow diagram illustrating the processing of the lookup node function in one embodiment. This function is passed the node identifier of the destination node. The function contacts the server node to retrieve the network address for the destination node and adds an entry to the peer table if the server node responds with the network address of the destination node. In decision block 1101, if the appropriate connection to the server node is available, then the function continues at block 1101, else the function returns an indication of error. In block 1102, the function creates a lookup node message that includes the destination node identifier. In block 1103, the function sends the lookup node message to the server node. In block 1104, the function sets a timer. In block 1105, the function waits for a response from the server node or a timeout. In decision block 1106, if a response is received from the server node, then the function continues at block 1107, else a timeout has occurred and the function returns an indication of error. In block 1107, the function adds an entry to the peer table that indicates the network address of the destination node, which was returned in the message. The function cancels the timer and then returns an indication of success. In an alternate embodiment, if the server node is not available through this node, then this node may request its peer nodes to contact the server node on its behalf or may check locally cached information relating to the network address of various nodes.
  • FIG. 12 is a flow diagram illustrating the processing of the establish peer connection 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 identifier in the peer table. In decision block 1202, if the network address of the destination node is in the peer table, then the function continues at block 1203, else a connection cannot be established and the function returns an indication of error. In block 1203, the function creates a peer connect request message that identifies this node. In block 1204, the function sends the peer connect request message to the network address for the destination node. To send the message, the function establishes a transport level connection to the network address and then sends the message. If a connection cannot be established, then the function returns an indication of error. In block 1205, the function sets a timer. In block 1206, the function waits for a response from the destination node or a timeout. In decision block 1207, if a response is received from the destination node, then the function continues at block 1208, else a timeout occurred and the function returns an indication of error. In block 1208, the function cancels the timer. In decision block 1209, if the response indicates that a connection can be established, then the function continues at block 1210, else the destination node is not willing to connect to this node and the function returns an indication of error. In block 1210, the function authenticates the destination node. Various well-known authentication techniques can be used, such as use of public/private key pairs in which the destination node sends a message encrypted with its private key and this node decrypts the message using the public key. If the destination node cannot be authenticated, then the function returns an indication of error. In block 1211, the function updates the physical routing table to indicate that the destination node is accessible as a peer node (i.e., connected at the physical routing layer) and then returns an indication of success.
  • FIGS. 13-15 are flow diagrams illustrating the processing of a received message of the physical routing layer. FIG. 13 is a flow diagram illustrating the processing of the receive message function of the physical routing layer in one embodiment. The function is passed a message that has been received from a peer node. The function determines whether the message is intended for this node or another node. If the message is intended for this node, then 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 originating node to this node. In block 1302, the function updates the physical routing table to add any of the nodes identified in the message header that are not already in the physical routing table. The updates indicate that the identified nodes are accessible through the peer node that sent the message. In decision block 1303, if the destination node is this node, then the function continues at block 1304, else the function continues at block 1305. In decision block 1304, if the message is a response to a message previously sent, then the function continues at block 1304A, else the function continues at block 1304B. In block 1304A, the function notifies the logical routing layer that a response has been received by invoking the get response function of the logical routing layer and then returns. In block 1304B, the function invokes the receive logical message function of the logical routing layer passing the received message to pass the message to the logical routing layer and then returns. In decision block 1305, if the message is a node search request, then the function continues at block 1306, else the function continues at block 1306A. In block 1306, the function invokes the process node search function passing the identifier of the destination node and the message and then returns. The invoked function checks the physical routing table of this node to determine whether the destination node is accessible through this node. If not, it sends the search request to its peer nodes. In decision block 1306A, if the message is a logical name search request, then the function continues at block 1306A, else the function continues at block 1307. In block 1306B, the function invokes the process logical name search function of the logical routing layer. In block 1307, the function invokes the forward message function to forward the message onto the next route (i.e., a peer node of this node) in the path to the destination node and then returns.
  • FIG. 14 is a flow diagram illustrating the processing of the forward message function of the physical routing layer in one embodiment. The function is passed a destination node identifier and a message to be forwarded. This function sends the message to a peer node that is in the path to the destination node. In block 1401, the function updates the message to add the information about this node into the message header. In block 1402, the function decrements the hop count in the message header. Each hop corresponds to a node along the path to the destination node. The hop count indicates the maximum number of hops that a message can travel on its way to the destination node. The node that originates the message can set the hop count. Alternatively, the message header may contain an indication of the number of hops that the message has traveled. Each node can decide, based on that number, whether to continue forwarding the message. In decision block 1403, if the hop count is zero, then the function continues at block 1407, else the function continues at block 1404. In decision block 1404, if the destination node identifier is in the physical routing table, then the destination node is accessible through this node and the function continues at block 1405, else the function continues at block 1407. In block 1405, the function sends the message to a peer node through which the destination node is accessible. In decision block 1406, if sending the message was successful, then the function reports an indication of success and returns, else the function reports an indication of error and returns. In decision block 1407, if the policy of this node allows for forwarding to the server node, then the function continues at block 1408, else the function reports an indication of error and returns. In decision block 1408, if a server node connection is available, then the function continues at block 1408 to forward the message to the server node, else the function reports an indication of error and returns. The server node can then forward the message to the destination node now if it is online or later when the destination node comes online.
  • FIG. 15 is a flow diagram illustrating the processing of the process node search function in one embodiment. The 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. If this node has already processed this message when the message was received from a different peer node, then the function may return without further processing. In decision block 1501, if the destination node identifier is in the physical routing table, then the destination node is accessible through this node and the function continues at block 1502, else the function continues at block 1504. In block 1502, the function sends the message to the next peer node in the path as indicated in the physical routing table. If the destination node is accessible through more than one peer node, then the function sends a message to each of those peer nodes. In decision block 1503, if sending the message to at least one peer node was successful, then the function returns, else the function reports an indication of error and returns. In blocks 1504-1509, the function forwards the search message to the peer nodes of this node. In block 1504, the function decrements the hop count. In decision block 1505, if the hop count is equal to zero, then the function discards the message and returns, else the function continues at block 1506. In block 1506, the function identifies the next peer node to forward the search message based on a search algorithm. The search algorithm described here is one that exhaustively searches all peer nodes to locate a destination node. Alternative search algorithms may select a single peer node for search message forwarding. One skilled in the art will appreciate that the search algorithms may be optimized to best suit node topologies, hop counts, geographic location, and application requirements. In decision block 1507, if a next peer node was identified, then the function continues at block 1508, else the function continues at block 1510. In block 1508, the function updates the message to add the information relating to this node to the message header. In block 1509, the function creates a copy of the message for each peer node to which the message is to be sent and continues at block 1502 to send the message to each identified peer node. In block 1510, the function discards the message and returns.
  • FIGS. 16-25 are flow diagrams illustrating the processing of the logical routing layer in one embodiment. FIGS. 16-21 are flow diagrams, illustrating the processing of a send message of the logical routing layer. FIG. 16 is a flow diagram illustrating the processing of the send logical message function of the logical routing layer in one embodiment. The send logical message function is passed a logical destination and a message. The logical destination indicates where the message is to be sent. For example, the logical destination may be identified by a user name, a logical name (.e.g., “address book”) or a fully qualified logical name (e.g., “addressbook.node.opendesign.com”). The function determines the identifier of the destination node corresponding to that logical destination and sends the message to that node by invoking the send message function of the physical routing layer. In block 1601, the function invokes the resolve logical destination function. The invoked function updates the logical routing table to add an entry for the logical destination if such an entry is not already in the table. In decision block 1602, if the logical destination was successfully resolved, then the function retrieves the entry from the logical routing table and continues at block 1604, else the function returns an indication of error. In block 1604, the function computes the destination node identifier by invoking the node identification function of the retrieved entry passing the message. In decision block 1605, if the destination node identifier was successfully computed, then the function continues at block 1606, else the function returns an indication of error. In block 1606, the function invokes the send message function of the physical routing layer to send the message to the destination node and then returns the indication of success or error that is returned by the invoked send message function. In one embodiment, the node identification function may use a criteria, a key function and a routing table. The key function is invoked passing the criteria to generate a 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 may be the last name, and the key function may return the first letter of the last name. The routing table may be a tree that maps letters to node identifiers.
  • FIG. 17 is a flow diagram illustrating the processing of the resolve logical destination function of the logical routing layer in one embodiment. This function is passed an indication of a logical destination and returns a fully qualified logical name. In decision block 1701, if the logical destination is a user name, then the function continues at block 1710, else the function continues at block 1702. In decision block 1702, if the logical name of the logical destination is local to this node, then the function continues at block 1703, else the function continues at block 1705. In block 1703, the function retrieves the entry for the logical name from the logical routing table. The entry includes the fully qualified logical name. In decision block 1704, if an entry for the logical name is found, then the function continues at block 1705, else the function returns an indication of error. In block 1705, the function retrieves an entry for the fully qualified logical name from the logical routing table. In decision block 1706, if the entry for the fully qualified logical name was retrieved, then the function sets the logical destination to the fully qualified logical name and returns an indication of success, else the function continues at block 1707. In block 1707, the function invokes the search logical destination function to search for the logical destination globally. The invoked function may search at a server node or through peer nodes to find the fully qualified logical name. In decision block 1708, if a fully qualified logical name was found while searching, then the function returns an indication of success, else the function returns an indication of error. In block 1709, the function invokes the user information function to find the user identifier for the user name. The invoked function may add an entry to the logical routing table to map the user identifier to the node identifier. The function then returns an indication of success.
  • FIG. 18 is a flow diagram illustrating the processing of the search logical destination function of the logical routing 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 (if not already added) to map the fully qualified logical name to a node identifier. In one embodiment, the node identifier can be extracted from the fully qualified name. In another embodiment, the node identifier is retrieved by sending a message to a logical destination of the logical routing map. In this described embodiment, however, the node identifier is either retrieved from a server node or by searching peer nodes. This function sends a message to a server node that stores global logical destination information. If the information for the entry is not received from the server node, then the function sends a search message to its peer nodes, which it propagated throughout the network. In block 1801, the function looks up the passed logical destination in the logical routing table. In decision block 1802, if an entry for the logical destination was found, then the function returns an indication of success, else the function continues at block 1803. In block 1803, the function creates a logical name lookup message of class SN. The message indicates that the sending node is requesting information for mapping the logical name to a node identifier. In block 1804, the function invokes the send logical message function passing the created message and the node identifier logical destination of the server node. In decision block 1805, if the message was sent successfully, then the function continues at block 1806, else the function returns an indication of error. In block 1806, the function invokes the get response function to wait for a response to be received. In decision block 1807, if a response was received, then the function continues at block 1808, else the function continues at block 1809. In block 1808, the function invokes the process logical destination update function to update the logical routing table and then returns an indication of success. In block 1809, the function creates a logical name lookup message of class SEARCH. The SEARCH class indicates that message is sent from a peer node to search for a node identifier. In block 1810, the function invokes the send message function of the physical routing layer to send the created message. The search message is sent to peer nodes that respond when the logical destination can be accessed through them. In decision block 1811, if the send message indication was successful, then the function continues at block 1812, else the function returns an indication of error. In block 1812, the function invokes the get response function to wait for a message or a timeout. In decision block 1813, if a response was received, then the function continues at block 1814, else the function returns an indication of error. In decision block 1814, the function invokes the process logical destination update function to update the logical routing table and then returns an indication of success.
  • FIG. 19 is a flow diagram illustrating the processing of the get response function of the logical routing layer in one embodiment. This function is a low-level function that is used to set a timer and wait for either a response to a message or a time out. In block 1901, the function sets a timer. In decision block 1902, if a response was received, then the function continues at block 1903, else a timeout occurred and the function returns an indication of error. In block 1903, the function cancels the timer and returns an indication of success.
  • FIG. 20 is a flow diagram illustrating the processing of the process logical destination update function of the logical routing layer in one embodiment. This function is passed information for a logical destination and updates an existing entry in, or adds a new entry to, the logical routing table for that logical destination. In block 2001, the function looks up the passed logical destination in the logical routing table. In decision block 2002, if the logical destination was found, then the function continues at block 2004, else the function continues at 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 an indication of success.
  • FIG. 21 is a flow diagram illustrating the processing of the user information function of the logical routing layer in one embodiment. This function is passed a user name, updates the logical routing table as appropriate to map the user identifier for the user name to a node identifier and returns the user identifier as the logical destination. In block 2101, the function looks up the user name in the logical routing table. In decision block 2102, if the lookup was successful, then the function returns the user identifier as the logical destination along with an indication of success, else the function continues at block 2103. In block 2103, the function creates a get user identifier message of class SN. The message is a request to retrieve a user identifier associated with a user name. In block 2104, the function invokes the send logical message function to send the created message to a logical destination that maps user names to user identifiers. In decision block 2105, if the message was successfully sent, then the function continues at block 2106, else the function returns an indication of error. In block 2106, the function invokes the get response function. In decision block 2107, if a response was successfully received, then the function continues at block 2108, else the function returns an indication of error. In 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. In block 2109, the function creates a node user message of class SN. In block 2110, the function invokes the send logical message function to send the created message to the logical destination of the logical routing map to find out the node(s) of the user identifier. In block 2111, if the message was successfully sent, then the function continues at block 2112, else the function returns an indication of error. In block 2112, the function invokes the get response function. In decision block 2113, if a response was successfully received, then the function continues at block 2114, else the function returns an indication of error. In block 2114, the function updates the logical routing table to add an entry for the user identifier and node identifier provided in the response and then returns the user identifier as the logical destination along with an indication of success.
  • FIG. 22 is a flow diagram illustrating the processing of the receive logical message function of the logical routing layer in one embodiment. This function is passed the received message. If the logical function and specified instance of the message are known to this node, then the function computes the node identifier. If the identified node is this node, then the function passes the message to the application for processing. Otherwise, the function sends the message to the identified node. In 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 (“Iname”), a class (“class”), and a criteria (“crit”). In decision block 2202, if the class is supported by this node as indicated by the logical routing table, then the function continues at block 2203, else the function reports an indication of error and returns. In decision block 2203, if the logical destination is known to this node as indicated by the logical routing table, then the function continues at block 2204, else the function reports an indication of error and returns. In block 2204, the function computes the destination node identifier based on the node identification function for the logical destination and the criteria. In decision block 2205, if the destination node identifier was successfully computed, then the function continues at block 2206, else the function reports an indication of error and returns. In decision block 2206, if the computed node identifier identifies this node, then the function continues at block 2207, else the function continues at block 2208. In block 2207, the function consumes the message and returns. In block 2208, the function invokes the send message function of the physical routing layer to send the message to the computed node identifier and then returns.
  • FIG. 23 is a flow diagram illustrating the processing of the register logical name function of the logical routing layer in one embodiment. This function is invoked by application programs to register their logical name both locally and globally. This function is passed the logical name and name class. In decision block 2301, if the combination of logical name and class is not in the logical routing table, then the function continues at block 2302, else the function returns an indication of error. In block 2302, the function creates a fully qualified logical name from the passed logical name. For example, the function may append the identifier of this node along with a registered domain name to the logical name to generate the fully qualified logical name (e.g., “logicalname” to “logicalname.nodeID.company.com”). In block 2303, the function adds an entry to the logical routing table for the logical name. This entry includes the node identification function. In block 2304, the function creates a message to register the logical name globally. In block 2305, the function invokes the send logical message function of the logical routing layer to send the registration message for registration with the logical routing map. In decision block 2306, if the message was sent successfully, then the function returns an indication of success, else the function continues at block 2307. In block 2307, the function sets a timer for retrying the sending of the registration message and then returns an indication of error.
  • FIG. 24 is a flow diagram illustrating the processing of the generate logical destination update function of the logical routing layer in one embodiment. This function is invoked when this node is to respond to a search message for a logical destination or when this node detects that the node identification function of a client node (i.e., a node using the services of an application of this node) is not current. This function is passed a logical name. In block 2401, the function retrieves the entry for the logical name in the logical routing table. In decision block 2402, if an entry was found, then the function continues at block 2403, else the function returns an indication of error. In block 2403, the function creates a message that contains the node identification function and returns an indication of success.
  • FIG. 25 is a flow diagram illustrating the processing of the process logical name search function of the logical routing layer in one embodiment. The function is passed a logical name and a message. This function is invoked when the physical routing layer receives a logical name search request. In decision block 2501, if the logical name is in the logical routing table, then the function continues at block 2502, else the function continues at block 2506. In block 2502, the function invokes the generate logical destination update function to retrieve and prepare the information (e.g., node identification function) for the passed logical name. In block 2503, the function creates a logical route search response that includes the node identification function. In block 2504, the function sends the response to a peer node to be sent back to the originating node. In decision block 2505, if the response was sent successfully, then the function returns, else the function reports error and then returns. In block 2506, the function decrements the hop count. In decision block 2507, if the hop count is zero, then the function continues at block 2512, else the function continues at block 2508. In block 2508, the function determines the next peer node based on a search algorithm. In decision block 2509, if a peer node was identified, then the function continues at block 2510, else the function continues at block 2512. In block 2510, the function updates the message to add the node identifier of this node. In block 2511, the function creates the copies of the message for each peer node to which the message is to be sent and continues at block 2504 to send a message to each peer node. In block 2512, the function discards the message and then returns.
  • FIG. 26 is a flow diagram illustrating the processing of an application initialization function in one embodiment. This function illustrates the use of the logical routing layer by an application. In block 2601, the function authenticates the application with the server node. In decision block 2602, if the authentication is successful, then the function continues at block 2603, else the function reports an indication of error and completes. In block 2603, the function invokes the register logical names function to register the logical routing map associated with this application. The function also adds entries to the logical routine table for this application. In block 2604, the function creates a request message to be sent to a logical destination. This reflects the actual processing that may be done by the application. In block 2605, the function invokes the send logical message function of the logical routing layer to send a message to the logical destination. In decision block 2606, if the message was successfully sent, then the function completes, else the function reports an error and completes.
  • FIG. 27 is a flow diagram illustrating the processing of a function of an application that receives a message from the logical routing layer. In block 2702, the function authenticates the message. In decision block 2703, if the message is authenticated, then the function continues at block 2704, else the function reports an error and then completes. In block 2704, the function consumes the message. In decision block 2705, if a response is to be sent, then the function continues at block 2706, else the function completes. In block 2706, the function creates a response. In block 2707, the function invokes the send logical message function of the logical routing layer to send the response. In decision block 2708, if the sending of the logical message was successful, then the function completes, else the function reports an error and then completes.
  • From the above description, it will be appreciated that although specific embodiments of the technology have been described for purposes of illustration, various modifications may be made without deviating from the scope of the invention. Accordingly, the invention is not limited except by the appended claims.

Claims (21)

1-86. (canceled)
87. A method for a client node to request services of an application identified by a logical identifier, the application executing at an application node that is identified by a physical identifier, the method comprising:
receiving at the client node from a logical routing layer mappings of logical identifiers to physical identifiers, each mapping being registered with the logical routing layer for an application identified by the logical identifier of the mapping and for an application node identified by the physical identifier of the mapping;
identifying at the client node the logical identifier of an application to which the client node is to send a request for service;
identifying at the client node the physical identifier corresponding to the identified logical identifier using the received mappings; and
sending by the client node to a physical routing layer the request for service, the request being addressed to the identified physical identifier wherein the physical routing layer determines a network identifier for the addressed physical identifier and routes the request for service to the network identifier.
88. The method of claim 87 wherein at least one of the mappings maps a logical identifier to multiple physical identifiers.
89. The method of claim 88 wherein multiple requests for service are sent, each addressed to one of the multiple physical identifiers.
90. The method of claim 88 wherein the request for service is addressed to one of the multiple physical identifiers.
91. The method of claim 87 wherein the receiving of mappings includes receiving a node identification function for a logical identifier that, when invoked, identifies a physical identifier corresponding to the logical identifier.
92. The method of claim 91 wherein the identifying of the physical identifier includes invoking the node identification function passing a parameter so that the physical identifier that is identified is based on the passed parameter.
93. The method of claim 92 wherein the parameter is a priority.
94. The method of claim 87 including sending from the client node to nodes to which the client node is connected a search request for a mapping of a logical identifier to a physical identifier wherein the search request is forwarded to other nodes until a mapping of the logical identifier to a physical identifier is located.
95. The method of claim 87 wherein a logical identifier is a user name that identifies a user and a mapping maps that logical identifier to a physical identifier of a node through which the user is registered with the logical routing layer.
96. The method of claim 87 including receiving a mapping of a logical identifier to a physical identifier to replace a previously received mapping of that logical identifier to a physical identifier.
97. A routing system for routing messages from client nodes to application nodes, comprising:
a logical routing layer that:
receives a mapping of a logical identifier of an application to a physical identifier of an application node associated with the application;
receives a message addressed to the logical identifier of the application;
identifies from the received mapping the physical identifier corresponding to the logical identifier; and
sends to a physical routing layer the message addressed to physical identifiers; and
a physical routing layer that:
receives the message addressed to a physical identifier;
identifies a network address corresponding to the physical identifier; and
sends to a transport layer the message addressed to the network address.
98. The routing system of claim 97 wherein the mapping maps the logical identifier to multiple physical identifiers.
99. The routing system of claim 98 wherein multiple messages are sent to the physical routing layer, each addressed to one of the multiple physical identifiers.
100. The routing system of claim 97 wherein the mapping is represented as a node identification function for the logical identifier that, when invoked, identifies the physical identifier corresponding to the logical identifier.
101. The routing system of claim 100 wherein the identifying of the physical identifier includes invoking the node identification function passing a parameter so that the physical identifier that is identified is based on the passed parameter.
102. The routing system of claim 97 wherein the logical routing layer receives a mapping of a logical identifier to a physical identifier to replace a previously received mapping of that logical identifier to a physical identifier.
103. A computer-readable medium containing computer-executable instructions for controlling an application executing at an application node to receive messages, the application identified by a logical identifier and the application node identified by a physical identifier, by a method comprising:
registering with a logical routing layer a mapping of the logical identifier to the physical identifier; and
receiving from a client node via a transport layer a message, the message being sent from the client node to the logical routing layer and being addressed to the logical identifier,
wherein the logical routing layer identifies the physical identifier based on the registered mapping and sends the message to a physical routing layer addressed to the identified physical identifier, and
wherein the physical routing layer identifies a network address corresponding to the physical address and sends the message to the application node via a transport layer by addressing the message to the network address.
104. The computer-readable medium of claim 103 wherein the registering of the mapping includes registering a node identification function for the logical identifier that, when invoked, identifies the physical identifier corresponding to the logical identifier.
105. The computer-readable medium of claim 104 wherein the logical routing layer invokes the node identification function passing a parameter so that the physical identifier that is identified is based on the passed parameter.
106. The computer-readable medium of claim 103 including registering a new mapping of the logical identifier to a physical identifier to replace a previously registered mapping of the logical identifier to a physical identifier.
US12/898,657 2001-02-12 2010-10-05 Logical routing system Expired - Fee Related US8819273B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/898,657 US8819273B2 (en) 2001-02-12 2010-10-05 Logical routing system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US26838601P 2001-02-12 2001-02-12
US7621402A 2002-02-12 2002-02-12
US10/278,761 US7809854B2 (en) 2002-02-12 2002-10-21 Logical routing system
US12/898,657 US8819273B2 (en) 2001-02-12 2010-10-05 Logical routing system

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/278,761 Continuation US7809854B2 (en) 2001-02-12 2002-10-21 Logical routing system

Publications (2)

Publication Number Publication Date
US20110029688A1 true US20110029688A1 (en) 2011-02-03
US8819273B2 US8819273B2 (en) 2014-08-26

Family

ID=29581926

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/278,761 Expired - Fee Related US7809854B2 (en) 2001-02-12 2002-10-21 Logical routing system
US12/898,657 Expired - Fee Related US8819273B2 (en) 2001-02-12 2010-10-05 Logical routing system

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/278,761 Expired - Fee Related US7809854B2 (en) 2001-02-12 2002-10-21 Logical routing system

Country Status (1)

Country Link
US (2) US7809854B2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140201323A1 (en) * 2013-01-15 2014-07-17 Qualcomm Incorporated Supporting transport diversity and time-shifted buffers for media streaming over a network
WO2015053850A1 (en) * 2013-10-10 2015-04-16 AdaptiveApps, Inc. Adaptive overlay networking
US9432810B2 (en) 2013-10-29 2016-08-30 Whooley, Inc. Opt-in and time limited bi-directional real-time location sharing

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8583745B2 (en) 2000-11-16 2013-11-12 Opendesign, Inc. Application platform
US7809854B2 (en) * 2002-02-12 2010-10-05 Open Design, Inc. Logical routing system
JP2004102373A (en) * 2002-09-05 2004-04-02 Hitachi Ltd Access management server, method and program
US20040054808A1 (en) * 2002-09-13 2004-03-18 Sun Microsystems, Inc. Method and apparatus for bi-directional translation of naming service data
US7725826B2 (en) 2004-03-26 2010-05-25 Harman International Industries, Incorporated Audio-related system node instantiation
US7430592B2 (en) * 2004-04-21 2008-09-30 Dell Products L.P. Method for heterogeneous system configuration
US7924826B1 (en) * 2004-05-03 2011-04-12 Cisco Technology, Inc. Method and apparatus for device pinout mapping
JP4725955B2 (en) * 2005-06-30 2011-07-13 株式会社リコー Information processing apparatus, message management method, program, and storage medium
US20070282880A1 (en) * 2006-05-31 2007-12-06 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Partial role or task allocation responsive to data-transformative attributes
GB2440759A (en) * 2006-08-11 2008-02-13 Cachelogic Ltd Selecting a download cache for digital data
US8627402B2 (en) 2006-09-19 2014-01-07 The Invention Science Fund I, Llc Evaluation systems and methods for coordinating software agents
US8055797B2 (en) * 2006-09-19 2011-11-08 The Invention Science Fund I, Llc Transmitting aggregated information arising from appnet information
US8601530B2 (en) 2006-09-19 2013-12-03 The Invention Science Fund I, Llc Evaluation systems and methods for coordinating software agents
US9306975B2 (en) 2006-09-19 2016-04-05 The Invention Science Fund I, Llc Transmitting aggregated information arising from appnet information
US8601104B2 (en) 2006-09-19 2013-12-03 The Invention Science Fund I, Llc Using network access port linkages for data structure update decisions
US7752255B2 (en) * 2006-09-19 2010-07-06 The Invention Science Fund I, Inc Configuring software agent security remotely
US8607336B2 (en) 2006-09-19 2013-12-10 The Invention Science Fund I, Llc Evaluation systems and methods for coordinating software agents
US8224930B2 (en) * 2006-09-19 2012-07-17 The Invention Science Fund I, Llc Signaling partial service configuration changes in appnets
US8984579B2 (en) * 2006-09-19 2015-03-17 The Innovation Science Fund I, LLC Evaluation systems and methods for coordinating software agents
US20080250121A1 (en) * 2007-04-09 2008-10-09 Oracle International Corporation Facilitating configuration of multiple instances of an application on a server cluster
US9800926B2 (en) * 2008-08-13 2017-10-24 At&T Intellectual Property I, L.P. Peer-to-peer video data sharing
WO2010038142A1 (en) * 2008-09-30 2010-04-08 Nokia Corporation Method and apparatus for address book contact management
US10419374B1 (en) 2010-07-09 2019-09-17 Gummarus, Llc Methods, systems, and computer program products for processing a request for a resource in a communication
US10171392B1 (en) 2010-07-09 2019-01-01 Gummarus LLC Methods, systems, and computer program products for processing a request for a resource in a communication
US10015122B1 (en) 2012-10-18 2018-07-03 Sitting Man, Llc Methods and computer program products for processing a search
US10158590B1 (en) 2010-07-09 2018-12-18 Gummarus LLC Methods, systems, and computer program products for processing a request for a resource in a communication
US10212112B1 (en) 2010-07-09 2019-02-19 Gummarus LLC Methods, systems, and computer program products for processing a request for a resource in a communication
US20140172998A1 (en) * 2012-12-16 2014-06-19 Deep River Ventures, Llc Methods, Systems, and Computer Program Products for Browsing Via a Communications Agent
US20120178480A1 (en) * 2010-09-03 2012-07-12 Sabse Technologies, Inc. Messaging systems and methods
US9348712B1 (en) * 2010-12-22 2016-05-24 Netapp, Inc. Policy-based volume caching in a clustered storage system
US8990913B2 (en) * 2012-04-17 2015-03-24 At&T Mobility Ii Llc Peer applications trust center
US10013158B1 (en) 2012-09-22 2018-07-03 Sitting Man, Llc Methods, systems, and computer program products for sharing a data object in a data store via a communication
US10021052B1 (en) 2012-09-22 2018-07-10 Sitting Man, Llc Methods, systems, and computer program products for processing a data object identification request in a communication
US10033672B1 (en) 2012-10-18 2018-07-24 Sitting Man, Llc Methods and computer program products for browsing using a communicant identifier
US10019135B1 (en) 2012-10-18 2018-07-10 Sitting Man, Llc Methods, and computer program products for constraining a communication exchange
CN106487864B (en) * 2015-09-02 2019-09-27 华为终端有限公司 Method for building up, server-side and the mobile terminal of data connection
US10534791B1 (en) 2016-01-31 2020-01-14 Splunk Inc. Analysis of tokenized HTTP event collector
US11093476B1 (en) * 2016-09-26 2021-08-17 Splunk Inc. HTTP events with custom fields
CN108323232B (en) * 2017-05-16 2020-01-24 北京大学深圳研究生院 Method for maintaining index and chain topological structure between multi-level block chain systems
GB2612665B (en) * 2017-09-27 2023-10-11 Aclara Tech Llc Enhanced meter reading schema to improve functionality in a utility's communications system
US10680804B2 (en) * 2017-09-27 2020-06-09 Salesforce.Com, Inc. Distributed key caching for encrypted keys
US10725941B2 (en) * 2018-06-30 2020-07-28 Western Digital Technologies, Inc. Multi-device storage system with hosted services on peer storage devices
US11277372B2 (en) 2019-10-29 2022-03-15 Microsoft Technology Licensing, Llc Name server management of domain name systems using virtual name servers

Citations (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5721904A (en) * 1993-12-20 1998-02-24 Hitachi, Ltd. Database access system and method of controlling access management to a database access system for a plurality of heterogeneous database servers using SQL
US5751914A (en) * 1995-10-10 1998-05-12 International Business Machines Corporation Method and system for correlating a plurality of events within a data processing system
US5870747A (en) * 1996-07-09 1999-02-09 Informix Software, Inc. Generalized key indexes
US5878218A (en) * 1997-03-17 1999-03-02 International Business Machines Corporation Method and system for creating and utilizing common caches for internetworks
US5946679A (en) * 1997-07-31 1999-08-31 Torrent Networking Technologies, Corp. System and method for locating a route in a route table using hashing and compressed radix tree searching
US5978568A (en) * 1997-03-11 1999-11-02 Sequel Technology Corporation Method and apparatus for resolving network users to network computers
US6003083A (en) * 1998-02-19 1999-12-14 International Business Machines Corporation Workload management amongst server objects in a client/server network with distributed objects
US6021113A (en) * 1997-10-29 2000-02-01 Lucent Technologies Inc. Distributed precomputation of network signal paths with table-based link capacity control
US6098108A (en) * 1997-07-02 2000-08-01 Sitara Networks, Inc. Distributed directory for enhanced network communication
US6154777A (en) * 1996-07-01 2000-11-28 Sun Microsystems, Inc. System for context-dependent name resolution
US6167449A (en) * 1997-11-19 2000-12-26 Apple Computer, Inc. System and method for identifying and locating services on multiple heterogeneous networks using a query by type
US6192394B1 (en) * 1998-07-14 2001-02-20 Compaq Computer Corporation Inter-program synchronous communications using a collaboration software system
US6260148B1 (en) * 1997-04-04 2001-07-10 Microsoft Corporation Methods and systems for message forwarding and property notifications using electronic subscriptions
US6314469B1 (en) * 1999-02-26 2001-11-06 I-Dns.Net International Pte Ltd Multi-language domain name service
US6360256B1 (en) * 1996-07-01 2002-03-19 Sun Microsystems, Inc. Name service for a redundant array of internet servers
US20020059452A1 (en) * 2000-09-14 2002-05-16 Kddi Corporation Method and system for transferring data in mobile IP
US20020069238A1 (en) * 2000-12-05 2002-06-06 Eard Douglas F. Technique to transfer data over a network
US20020073409A1 (en) * 2000-12-13 2002-06-13 Arne Lundback Telecommunications platform with processor cluster and method of operation thereof
US20020178227A1 (en) * 2001-05-25 2002-11-28 International Business Machines Corporation Routing instant messages using configurable, pluggable delivery managers
US6510450B1 (en) * 1999-02-04 2003-01-21 Novell, Inc. Multiple storage class distributed nametags for locating items in a distributed computing system
US6513061B1 (en) * 1997-10-07 2003-01-28 Hitachi, Ltd. Proxy server selecting server and proxy server
US6650631B1 (en) * 1997-03-11 2003-11-18 Verizon Services Corp. Public IP transport network
US6728748B1 (en) * 1998-12-01 2004-04-27 Network Appliance, Inc. Method and apparatus for policy based class of service and adaptive service level management within the context of an internet and intranet
US6760775B1 (en) * 1999-03-05 2004-07-06 At&T Corp. System, method and apparatus for network service load and reliability management
US6826559B1 (en) * 1999-03-31 2004-11-30 Verizon Laboratories Inc. Hybrid category mapping for on-line query tool
US7389322B1 (en) * 1999-10-25 2008-06-17 Fujitsu Limited Electric mail system
US20090077260A1 (en) * 2000-11-16 2009-03-19 Rob Bearman Application platform
US7809854B2 (en) * 2002-02-12 2010-10-05 Open Design, Inc. Logical routing system

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10240687A (en) 1997-02-28 1998-09-11 Tec Corp Network system
EP0889418A3 (en) 1997-06-30 1999-08-18 Sun Microsystems, Inc. Abstract URL resolution via relocation service
JPH11265402A (en) 1997-12-22 1999-09-28 Toshiba Corp Data processing system and recording medium recorded with control program of the system
JPH11205338A (en) 1998-01-19 1999-07-30 Nec Corp Multimedia bus exchange and method

Patent Citations (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5721904A (en) * 1993-12-20 1998-02-24 Hitachi, Ltd. Database access system and method of controlling access management to a database access system for a plurality of heterogeneous database servers using SQL
US5751914A (en) * 1995-10-10 1998-05-12 International Business Machines Corporation Method and system for correlating a plurality of events within a data processing system
US6154777A (en) * 1996-07-01 2000-11-28 Sun Microsystems, Inc. System for context-dependent name resolution
US6360256B1 (en) * 1996-07-01 2002-03-19 Sun Microsystems, Inc. Name service for a redundant array of internet servers
US5870747A (en) * 1996-07-09 1999-02-09 Informix Software, Inc. Generalized key indexes
US6650631B1 (en) * 1997-03-11 2003-11-18 Verizon Services Corp. Public IP transport network
US5978568A (en) * 1997-03-11 1999-11-02 Sequel Technology Corporation Method and apparatus for resolving network users to network computers
US5878218A (en) * 1997-03-17 1999-03-02 International Business Machines Corporation Method and system for creating and utilizing common caches for internetworks
US6260148B1 (en) * 1997-04-04 2001-07-10 Microsoft Corporation Methods and systems for message forwarding and property notifications using electronic subscriptions
US6098108A (en) * 1997-07-02 2000-08-01 Sitara Networks, Inc. Distributed directory for enhanced network communication
US5946679A (en) * 1997-07-31 1999-08-31 Torrent Networking Technologies, Corp. System and method for locating a route in a route table using hashing and compressed radix tree searching
US6513061B1 (en) * 1997-10-07 2003-01-28 Hitachi, Ltd. Proxy server selecting server and proxy server
US6021113A (en) * 1997-10-29 2000-02-01 Lucent Technologies Inc. Distributed precomputation of network signal paths with table-based link capacity control
US6167449A (en) * 1997-11-19 2000-12-26 Apple Computer, Inc. System and method for identifying and locating services on multiple heterogeneous networks using a query by type
US6003083A (en) * 1998-02-19 1999-12-14 International Business Machines Corporation Workload management amongst server objects in a client/server network with distributed objects
US6192394B1 (en) * 1998-07-14 2001-02-20 Compaq Computer Corporation Inter-program synchronous communications using a collaboration software system
US6728748B1 (en) * 1998-12-01 2004-04-27 Network Appliance, Inc. Method and apparatus for policy based class of service and adaptive service level management within the context of an internet and intranet
US6510450B1 (en) * 1999-02-04 2003-01-21 Novell, Inc. Multiple storage class distributed nametags for locating items in a distributed computing system
US6314469B1 (en) * 1999-02-26 2001-11-06 I-Dns.Net International Pte Ltd Multi-language domain name service
US6760775B1 (en) * 1999-03-05 2004-07-06 At&T Corp. System, method and apparatus for network service load and reliability management
US6826559B1 (en) * 1999-03-31 2004-11-30 Verizon Laboratories Inc. Hybrid category mapping for on-line query tool
US7389322B1 (en) * 1999-10-25 2008-06-17 Fujitsu Limited Electric mail system
US20020059452A1 (en) * 2000-09-14 2002-05-16 Kddi Corporation Method and system for transferring data in mobile IP
US20090077260A1 (en) * 2000-11-16 2009-03-19 Rob Bearman Application platform
US20020069238A1 (en) * 2000-12-05 2002-06-06 Eard Douglas F. Technique to transfer data over a network
US20020073409A1 (en) * 2000-12-13 2002-06-13 Arne Lundback Telecommunications platform with processor cluster and method of operation thereof
US20020178227A1 (en) * 2001-05-25 2002-11-28 International Business Machines Corporation Routing instant messages using configurable, pluggable delivery managers
US7809854B2 (en) * 2002-02-12 2010-10-05 Open Design, Inc. Logical routing system

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140201323A1 (en) * 2013-01-15 2014-07-17 Qualcomm Incorporated Supporting transport diversity and time-shifted buffers for media streaming over a network
US10015437B2 (en) * 2013-01-15 2018-07-03 Qualcomm Incorporated Supporting transport diversity and time-shifted buffers for media streaming over a network
WO2015053850A1 (en) * 2013-10-10 2015-04-16 AdaptiveApps, Inc. Adaptive overlay networking
US10075413B2 (en) 2013-10-10 2018-09-11 Cloudistics, Inc. Adaptive overlay networking
US9432810B2 (en) 2013-10-29 2016-08-30 Whooley, Inc. Opt-in and time limited bi-directional real-time location sharing

Also Published As

Publication number Publication date
US8819273B2 (en) 2014-08-26
US20030225924A1 (en) 2003-12-04
US7809854B2 (en) 2010-10-05

Similar Documents

Publication Publication Date Title
US8819273B2 (en) Logical routing system
US8583745B2 (en) Application platform
US11909639B2 (en) Request routing based on class
US11115500B2 (en) Request routing utilizing client location information
US8275826B2 (en) Organizing resources into collections to facilitate more efficient and reliable resource access
US9021127B2 (en) Updating routing information based on client location
JP4592184B2 (en) Method and apparatus for accessing device with static identifier and intermittently connected to network
US7970765B1 (en) Network device for providing integrated DNS caching services
US9264358B2 (en) Alias resource record sets
JP2001103092A (en) Dns inquiry device, dns inquiry method and recording medium
US9154571B2 (en) Publish/subscribe networks
Hauswirth et al. Handling identity in peer-to-peer systems
CA2438203C (en) Logical routing system
KR20050003598A (en) Domain name service provide system and method using dual domain name server
Garcia-Luna-Aceves System and Method for Discovering Information Objects and Information Object Repositories in Computer Networks

Legal Events

Date Code Title Description
STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551)

Year of fee payment: 4

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20220826