Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1998-12-31
2003-04-15
Vanderpuye, Ken (Department: 2661)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C709S245000
Reexamination Certificate
active
06549538
ABSTRACT:
BACKGROUND OF THE INVENTION
Generally speaking, computer systems typically include one or more central processor nodes, referred to simply as “processor nodes” or “nodes”. Each of those processor nodes includes one or more network interface modules, connected to a computer network, for communicating with other processor nodes. Each network interface module has an associated network layer address or IP address to which packets of information can be directed. The network layer address allows processor nodes to communicate with one another by sending those packets of information across the computer network. Each packet includes a header that contains the network layer addresses of the originating, or source, processor node and of the destination processor node. Groups of processor nodes can be connected in an arrangement referred to as a “cluster”. Generally, processor nodes within a cluster are more tightly coupled than in a general network environment and act in concert with one another. For example, all of the processor nodes within a cluster can share a common file system such that they are able to access the same files. Also, each of the processor nodes within the cluster can use the same security domain files such that common user names and passwords may be utilized to log on to any of the processor nodes.
A cluster should appear as a single processor node to clients accessing that cluster. In other words, a cluster should present a common set of software services that can be executed by any of the associated processor nodes. Therefore, regardless of which processor node is accessed by a client, the same services will be provided. Because of that configuration, processor nodes can be seamlessly added to the cluster to increase the capacity of those services without the cluster looking any different to the client.
To make a cluster appear to be a single processor node, it should have a single network layer address. Such a network layer address is referred to as a “cluster alias address”. That cluster alias address should not be tied to one specific node within the cluster but rather should be collectively associated with all the processor nodes. To that end, the cluster's network layer address must be accessible regardless of what the current membership of the cluster is. The current membership of a cluster is defined by the nodes that are “up” and capable of running the software services required by any client accessing the cluster. Accordingly, a client accessing the cluster over a network does not need to know which nodes within the cluster are currently up and running in order to access the software services that the cluster provides.
In order to direct incoming data packets, each processor node within the cluster has the ability to distribute those packets to the appropriate processor node for servicing. The processor node receiving the data packet from the network will hereinafter be referred to as the “receiving processor node” for that transaction. When a data packet is received by the cluster, the receiving processor node determines what type of data packet it is. For example, most data packets correspond to the TCP/IP or UDP network protocols. Data packets that are associated with a connection correspond to the TCP/IP protocol. Data packets using the UDP/IP protocol are all treated similar to new connection requests for the purposes of this invention, since the UDP protocol is connectionless. The receiving processor node further determines whether the data packet is associated with an existing connection to an application running on one of the processor nodes within the cluster or whether a new connection should be established. Generally, when a connection is established, it means that an application running on one of the processor nodes of the cluster is dedicated to servicing data packets sent by an associated client application. Also, data can be returned to the client application via the connection.
If the data packet is associated with an existing connection to an application running on a processor node within the cluster, the receiving processor node performs an operation for determining the identity of that processor node. To that end, data packets typically include a header portion that contains information about the existing connection to which it is associated. That header portion includes the network layer address of the processor node from which it was sent, the TCP port number of the application from which it was sent, the network layer address of the destination processor node, the TCP port number of the application running on the destination processor node and the protocol type to which the data packet conforms. The receiving processor node maintains a look-up table of that information for each existing connection within the cluster. That look-up table is referred to as the “connection registration database” or CRD. Each time a new connection is established, the details of that connection are registered in the connection registration database. Typically, the details of a connection stored in the connection registration database are indexed according to a combination of the network layer address of the source processor node and the TCP port number of the source application that is running on that processor node. The index also includes the destination network layer address and the TCP port number of the destination application.
The cluster alias address associated with the source processor node can be identified as the source address in the header portion of a data packet. Such a practice is typically used to simplify the authentication process at the destination processor node when an application running in the cluster is acting as a client to a service on some other node in the network. When the cluster alias address is used as the source address, the authentication table maintained by the destination node needs to include only a single entry for each cluster, as opposed to a single entry for each processor node within that cluster.
When the cluster alias address is identified as the source address, the destination processor can accurately reference the associated connection information in the connection registration database only when the source TCP port number is not being used by any other application running on a processor node within the source cluster. If the same source TCP port number is being used with the cluster alias by another application accessing the same destination node and port number, the index into the connection registration database will not be unique. Accordingly, the information for the associated connections will occupy the same location in the connection registration database and the two connections will look the same to the destination processor node. In that situation, competent passing of data packets between the source cluster and destination node is prevented.
SUMMARY OF THE INVENTION
The foregoing problems of indexing into a connection registration database are overcome by the present invention. In accordance with the invention, a method is provided for managing TCP port numbers used by applications running on a cluster. Using that method, ranges of TCP port numbers are locked by a processor node of a cluster. An application running on one of those processor nodes uses a locked TCP port number when issuing a data packet that includes the cluster alias address as the source address. With such an invention, applications-running on each processor node within a cluster will use unique TCP port numbers. Therefore, connections between a source and destination application can be uniquely registered at the destination processor node using an index that includes a combination of the source address and the TCP port number.
More specifically, the method for managing port numbers includes a lock application that locks, or effectively reserves, a range of port numbers for use by an associated processor node. The port numbers are locked through registration in a lookaside list such that information regarding those locked port
Beck Paul R.
Cohen Larry
Compaq Information Technologies Group L.P.
Vanderpuye Ken
LandOfFree
Computer method and apparatus for managing network ports... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Computer method and apparatus for managing network ports..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Computer method and apparatus for managing network ports... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3112396