Transparent TCP connection failover

Methods of transparent connection failover allowing a remote computer (i.e., a client), to continue to use a network connection to communicate with one of at least two or more other computers (i.e., the backup servers) over a network, when one of the other computers (i.e., the primary server) fails. With the mechanisms of this invention, there is no need for the client to establish a new connection to a backup server when the primary server fails. The failover is preferably executed within a bridge layer between the TCP layer and the IP layer of the server's TCP/IP stack. No modifications are required to the network infrastructure, the client's TCP/IP stack, the client application or the server application. The methods support active or semi-active replication of the server application, and do not require rollback of the application during failover. The invention also provides mechanisms for bringing up new backup servers.

NOTICE OF MATERIAL SUBJECT TO COPYRIGHT PROTECTION

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention pertains generally to communication over a network between computers in the presence of faults in those computers, and more particularly to the execution of connection-oriented communication protocols.

2. Description of Related Art

Computers use communication protocols executed by communication routines for exchanging information between them. An important class of communication protocols is the class of connection-oriented communication protocols that operate over an underlying network communication protocol. The most-widely used communication protocols in this class today comprise the Transmission Control Protocol (TCP) operating on top of the Internet Protocol (IP).

Connection-oriented communication protocols require one computer (i.e., the client) to initiate a connection to another computer (i.e., the server). Once the connection is established, the client and the server can exchange data. The connection remains established until both client and server endpoints terminate the connection, or one endpoint fails.

To achieve fault tolerance of the server, the server is replicated with a primary server replica and one or more backup server replicas, so the client continues to receive service, despite the failure of a server. If the primary server fails, a backup server takes over the role of the failed primary server and the client establishes a new connection to the backup server. The operations involved in the backup server taking over the role of the failed primary are referred to as a failover operation. There are several approaches that allow the client to use the same server address to connect to the backup server and, thus, mask the fact that the client is communicating with a different server. The masking of the failover operation without the client having to establish a new connection to the backup server and, without any modification to the client computer's software or hardware, is the subject of this invention and is referred to as transparent connection failover.

Systems have been proposed that allow the client to maintain an established connection with the server even if the server fails. However, they often require modifications to the network infrastructure, the client application or the client computer's protocol stack. Those systems suffer from the drawback that the network and the client computers often belong to organizations that are different from that of the server and, therefore, the client's computer software or hardware cannot be easily modified.

U.S. Patent Publication No. 20010056492 describes a system in which client-server TCP/IP communication is intercepted and logged at a backup computer. When the server fails, the server application is restarted and all TCP/IP stack activity is replayed. The backup computer performs an IP takeover, in which it takes over the role of the server computer for the remaining lifetime of the connection. No modifications to the client's TCP/IP protocol stack, the client application or the server application are required. To operate properly, the backup computer must be operational before the connection between the client and the server is established. Although the failover happens transparently to the client, the failover time can be significant because the entire history of the connection must be replayed.

TCP splicing (O. Spatscheck, J. S. Hansen, J. H. Hartman and L. L. Peterson, Optimizing TCP forwarder performance, IEEE/ACM Transactions on Networking, vol. 8, no. 2, April 2000, pp.146-157) is a technique that is used to improve performance and scalability of application-level gateways. Clients establish TCP connections to a dispatcher application. The dispatcher chooses an appropriate server to handle a client connection, and then modifies the TCP/IP stack of the dispatcher computer to forward all TCP packets of the connection directly to the selected server. No further involvement of the dispatcher is required until the connection is terminated. TCP splicing requires all traffic to flow through the dispatcher.

TCP handoff (M. Aron, D. Sanders, P. Druschel and W. Zwaenepoel, Scalable content-aware request distribution in cluster-based network servers, Proceedings of the USENIX 2000 Annual Technical Conference, San Diego, Calif., June 2000, pp. 323-336) removes the dispatcher by letting the client connect directly to one of the servers. If the initial server decides that another server is better suited to handle the connection, it transfers the TCP connection state to an alternate server. TCP handoff requires a special front-end layer-4 switch that routes the packets to the appropriate server.

TCP migration (A. C. Snoeren, D. G. Andersen and H. Balakrishnan, Fine-grained failover using connection migration, Proceedings of the USENIX Conference on Internet Techniques and Systems, San Francisco, Calif., March 2001, pp.221-232) is a technique that is transparent to the client application but requires modifications to both the client and server TCP/IP stacks. Modifications to the network infrastructure (e.g., Internet routers, underlying protocols) are not required. The client or any of the servers can initiate migration of the connection. At any point in time, only one server is connected to the client. Multicasting or forwarding of the client's message is not possible.

Other researchers (F. Sultan, K. Srinivasan, D. Iyer and L. Iftode, Migratory TCP: Connection migration for service continuity in the Internet, Proceedings of the IEEE International Conference on Distributed Computing Systems, Vienna, Austria, July 2002, pp. 469-470) propose a TCP connection migration scheme that requires the cooperation of both the client and server TCP/IP stacks. The client initiates the migration. During the migration process, both servers must be operational, which renders this approach appropriate for load balancing but not useful for fault tolerance.

The Hydranet system (G. Shenoy, S. K. Satapati and R. Beftati, HydraNet-FT: Network support for dependable services, Proceedings of the IEEE International Conference on Distributed Computing Systems, Taipei, Taiwan, April 2000, pp. 699-706) replaces a single server with a group of server replicas. It does not require any modification of the client's TCP/IP stack. Instead, all IP packets sent by the client to a certain IP address and port number are multicast to the group of server replicas. For this scheme to work, all traffic must go through a special redirector, which resides on an Internet router. To maintain consistency between the server replicas, the system employs an atomic multicast protocol. The forwarding service is not restricted to TCP, but can accommodate any transport protocol that is based on IP.

The SwiFT system (H. Y. Huang and C. Kintala, Software implemented fault tolerance, Proceedings of the IEEE Fault Tolerant Computing Symposium, Toulouse, France, June 1993, pp. 2-10) provides fault tolerance for user applications. SwiFT consists of modules for error detection and recovery, checkpointing, event logging and replay, communication error recovery and IP packet rerouting. The latter is achieved by providing a single IP image for a cluster of server computers. Addressing within the cluster is done by Media Access Control (MAC) addresses. All traffic from the clients is sent to a dispatcher, which forwards the packets to one of the server computers. A client must run the SwiFT client software to reestablish the TCP connection if the server fails.

Rerouting of IP packets (A. Bhide, E. N. Elnozahy and S. P. Morgan, A highly available network file server, Proceedings of the 1991 USENIX Winter Conference, Dallas, Tex., January 1991, pp. 199-205) is proposed in a scheme that reroutes IP packets from a primary server to a backup server. If the primary server fails, the backup server changes its IP address to the address of the primary server. The backup server then sends a gratuitous Address Resolution Protocol (ARP) request to announce that it can now be found at the primary's address. From then on, all IP packets that are addressed to the primary server are sent to the backup server.

Replication of Web services (N. Aghdaie and Y. Tamir, Client-transparent fault-tolerant Web service, Proceedings of the IEEE International Conference on Performance, Computing and Communications, Phoenix, Ariz., April 2001, pp. 209-216) is used in a system that allows a client to continue to use a TCP connection transparently when the primary server fails. This approach does not require changes to the hardware or software infrastructure but, rather, uses two proxies at each server that are implemented in user space to avoid changes to the operating system of the server computer. The server application is passively replicated, and the backup proxy logs client requests and server replies. The drawback of their approach is the degraded performance that results from the context switches and protocol stack traversals that are needed for an implementation in user space.

Therefore, a need exists for a method of maintaining a network connection between a client and a replicated server without the need for the client to establish a new connection if one of the servers fails and without the need for any modifications to the application code, communication routines or other hardware or software infrastructure at the client, so that the connection failover is transparent to the client. The present invention satisfies those needs, as well as others, and overcomes the deficiencies of previously developed methods for providing network connection failover.

BRIEF SUMMARY OF THE INVENTION

To achieve transparent connection failover, the present invention requires two networked computers (i.e., the servers) that belong to the same subnet. One of the servers acts as the primary server, and the other acts as the backup server. Any one of the two servers can fail while connections to at least one other computer (i.e., the clients) are established, or are in the process of being established, or are in the process of being terminated. As long as at least one of the servers remains operational, the failure of a server remains transparent to a client and, in particular, a client does not need to establish a new connection to the backup server. The client and server roles as described herein are provided by way of example, and it should be appreciated that the roles of the client and the server may be reversed or temporarily assumed in either direction in relation to specific applications and/or connections being established over the network, without departing from the teachings herein.

The invention achieves transparent connection failover by utilizing a form of connection endpoint migration. The invention inserts a bridge sublayer between a connection-oriented communication protocol layer and an underlying network communication protocol layer. By way of example, the connection-oriented communication protocol layer is the Transmission Control Protocol (TCP) layer, and the underlying network communication protocol layer is the Internet Protocol (IP) layer. Although the present invention is described in the context of TCP operating over IP, it should be appreciated that the principles of the invention apply to other protocols as well.

Routines for maintaining a connection are preferably implemented in a bridge sublayer between the TCP layer and the IP layer of the server's TCP/IP stack. The invention does not require any modification to the network infrastructure, the server application, the client application or the client's TCP/IP stack.

In the standard TCP/IP protocol stack, the TCP layer resides above the IP layer. TCP accepts messages from the user application and divides the messages into TCP segments. The TCP segments are passed to the IP layer, where they are packed into IP datagrams. The routers that reside between a client computer and the server computers work at the IP layer and, therefore, have no knowledge of TCP. In TCP connection establishment, the server listens for incoming connection requests, and the client connects to the server.

In the present invention, the server application process is replicated on both computers, using active or semi-active replication. With active or semi-active replication, the server application runs on both primary and backup server computers. Both server processes accept connections, handle requests and generate replies. Server processes must exhibit the same deterministic behavior, which means that they generate identical replies on all connections. If the primary server process generates a reply, the backup server process must generate an identical reply. Because both servers undergo the identical state transitions and because the bridge synchronizes the state of the TCP layer of the primary and backup servers, state transfer of the application state and of the communication infrastructure state is not required to support transparent connection failover. However, bringing up a new backup server replica, or returning a failed and repaired server replica to the system, requires a state transfer to the new backup server replica of not only the application state but also the communication infrastructure state.

To failover a TCP connection endpoint from a primary server to a backup server in a manner that is transparent to the client, the IP datagrams that the client sends to the primary server must be redirected to the backup server, and the TCP protocol must be respected. The following are directed to that end:

(a) The backup server must have a copy of all TCP segments, sent by the client, that the primary server has acknowledged. The primary server must not acknowledge a client's TCP segment until it has received an acknowledgment of that segment from the backup server.

(b) The backup server must have a copy of all TCP segments, sent by the primary server, that the client has not acknowledged. If the client acknowledges a server's TCP segment, the primary server and each backup server must receive the acknowledgment and remove the TCP segment from its buffers.

(c) The backup server must synchronize its TCP sequence numbers with the TCP sequence numbers used by the primary server. The sequence number order must not be violated when a failover takes place. If a client detects a violation in the sequence number order, the client will disconnect and reinitiate the connection.

(d) The backup server must respect the Maximum Segment Size (MSS) and the maximum window size that were negotiated between the primary server and the client when the connection was established.

The present invention enables a TCP connection to continue to be utilized when the primary server has failed, and does not require changes to the client application, the client TCP/IP stack or other software or hardware at the client. The invention operates at the level of the TCP/IP stack of the server, and for a request/reply or a message/acknowledgment, requires preferably k+1 messages and at most 2k messages, where k is the number of server replicas.

The present invention provides transparent connection failover for a connection-oriented communication protocol where a client is connected to a replicated server over a network. In one embodiment, transparent connection failover is achieved by program code that executes within the communication code for: (a) communicating client requests to at least one backup server; and (b) migrating the connection endpoint from the primary server to the backup server when the primary server fails, in response to which the backup server receives and responds to the client requests while the client is still addressing the primary server and is unaware of the server failure or of the connection failover.

In another embodiment, an apparatus for transparent connection failover comprises (a) at least two server computers that execute routines for communicating with a client computer over a network; and (b) a means for modifying the address of a backup server computer within the communication routines of the backup server computer in response to the failure of the primary server computer, in order that the backup server computer can act as the endpoint of the connection and the new primary server. The means of modifying the address of the backup server is preferably performed within a bridge sublayer between the connection-oriented communication protocol layer and the underlying network communication protocol layer.

In a further embodiment, an apparatus for transparent connection failover comprises: (a) a server computer configured for executing a communication protocol with client computers over a network; and (b) program code within the server computer for executing the communication protocol for (i) communicating client requests to a primary server, (ii) communicating client requests to at least one backup server, (iii) communicating responses from the primary server to the client, and (iv) migrating the connection endpoint from the primary server to the backup server when the primary server fails, (v) wherein the backup server receives and responds to the client requests while the client is still addressing the primary server.

Another embodiment of the invention is a method of providing transparent connection failover for two or more computers that communicate with a remote computer over a network, comprising: (a) executing the same computations on two or more computers in response to communication from a remote computer using the Transmission Control Protocol (TCP) over the Internet Protocol (IP), and (b) migrating the connection endpoint upon the failure of one computer wherein the other of the computers continues to communicate with the remote computer.

In another embodiment, a method of ensuring transparent connection failover is described comprising: (a) executing communication routines on computers connected Within the network so that computations can be executed on a first computer in response to communication with a remote computer; (b) maintaining synchronization of at least a second computer with the first computer, within the communication routines, wherein the server application on the second computer executes the same computations as the server application on the first computer; and (c) migrating the connection endpoint, within the communication routines, from the first computer to the second computer if the first computer fails, providing transparent connection failover so that the remote computer still addresses the first computer but communicates with the second computer.

It should be appreciated that the preceding embodiments are provided by way of example and not of limitation, and that the inventive teachings and associated aspects of the invention may be described in a number of alternative embodiments.

An aspect of the invention is a method of providing transparent connection failover by using connection endpoint migration.

Another aspect of the invention is a transparent connection failover mechanism from a primary server to a backup server wherein the client does not need to establish a new connection with the backup server when the primary server fails.

Another aspect of the invention is a transparent connection failover mechanism that supports active or semi-active replication of the server application.

Another aspect of the invention is a transparent connection failover mechanism that does not require rollback of the application during failover.

Another aspect of the invention is a transparent connection failover mechanism in which the backup servers are synchronized with the primary server.

Another aspect of the invention is a transparent connection failover mechanism that is executed by routines in a bridge sublayer between a connection-oriented communication protocol layer and a network communication protocol layer.

Another aspect of the invention is a transparent connection failover mechanism in which the bridge routines replace the original (primary) destination address of incoming segments with that of another (backup) server.

Another aspect of the invention is a transparent connection failover mechanism in which the client is not cognizant of the failover, such as requiring it to establish a new connection with a backup server that has a different destination address from the primary server.

Another aspect of the invention is a failover mechanism that utilizes the Transmission Control Protocol (TCP) as the connection-oriented communication protocol and the Internet Protocol (IP) as the network protocol.

Another aspect of the invention is a bridge sublayer implemented between the TCP layer and the IP layer of the TCP/IP stack at the servers.

Another aspect of the invention is a transparent connection failover mechanism in which between k+1 and 2k messages are required for a request/reply or a message/acknowledgment, wherein k represents the number of server replicas.

Another aspect of the invention is a transparent connection failover mechanism that does not require proxies at each server and that is not implemented in user space.

Another aspect of the invention is a transparent connection failover mechanism that does not require replaying the connection history of the connection prior to performing the failover to another server.

Another aspect of the invention is a transparent connection failover mechanism that does not require traffic to be routed through a dispatcher.

A still further aspect of the invention is a transparent connection failover mechanism that requires no modification of the software running on remote or client computers, or to the TCP/IP protocol stacks on the remote or client computers.

DETAILED DESCRIPTION OF THE INVENTION

It should be noted that the present invention is generally described in terms of a single client and two server replicas, a primary server and a backup server. However, the invention is easily generalized to multiple clients and k server replicas, where there is one primary server replica and k−1 backup server replicas, where k≧2.

A connection established by means of the present invention between a client and the servers is referred to as a fault-tolerant connection or FT connection. The 4-tuple (client IP address, client TCP port number, primary server IP address, primary server TCP port number) uniquely identifies a FT connection between a client and the servers.

The TCP connection failover mechanisms of this invention preferably reside between the TCP layer and the IP layer of the TCP/IP protocol stack of the primary and backup servers. This sublayer is referred to, as introduced by this invention, as the bridge, and comprises bridge routines. Although each server must be able to operate as a primary server or a backup server, the functionality of the bridge is different in the two cases, as described below.

The primary server bridge contains the core, which comprises two queues: the primary server output queue and the backup server output queue. The primary server output queue contains payload bytes that the primary server's TCP layer generates. The backup server output queue contains payload bytes that the backup server's TCP layer generates. The primary server bridge maintains a primary server output queue and backup server output queue for each FT connection between a client and the servers. The primary server bridge adjusts the sequence numbers of all outgoing TCP segments that it receives from the TCP layer, and all acknowledgment sequence numbers of incoming TCP segments that it receives from the IP layer.

The backup server bridge does not contain the core. However, it replaces the original destination (client) address of an outgoing TCP segment with the address of the primary server and puts the client address in the TCP options field. Correspondingly, the backup server bridge replaces the original (primary server) destination address of an incoming TCP segment with the address of the backup server. In the description of the inventive embodiment below, the backup server bridge does not adjust the sequence numbers of outgoing TCP segments or the acknowledgment sequence numbers of incoming TCP segments. However, it should be appreciated that the invention may be implemented to require the backup server bridge to make such adjustments.

2. Description of a Preferred Embodiment.

The connection failover mechanisms of this invention are described for a single TCP connection between a single client and a replicated server, where there are two server replicas, although the mechanisms are easily extended to multiple clients and more than two replicas of the server. The behavior of the system is considered in the fault-free case, and then its behavior is examined when the primary server or the backup servers fail, after which connection establishment and disestablishment procedures are described. The process of starting up a new backup replica is also described.

2.1. Maintaining the State of a TCP Connection in the Fault-Free Case.

A client computer C is considered that runs a client application, and a primary server computer P and a backup server computer B that each run the same server application.

In the standard TCP/IP protocol stack, when the client application issues a request to the server application, it passes a request message to the TCP layer of the client computer. The TCP layer packs the data of the request message into TCP segments, and passes the TCP segments to the IP layer. Each TCP segment has a unique sequence number. The IP layer packs the TCP segments into an IP datagram. The IP datagram header contains the IP address of the sender (source) computer and the IP address of the receiving (destination) computer.

In the present invention, the source address is the IP address of client computer C, which is denoted herein by Ac, and the destination address is the IP address of primary server computer P, which is denoted herein by Ap. When primary server computer P receives a datagram from client computer C, the IP layer of primary server computer P delivers the payload of the datagram to the TCP layer, which then extracts the client's request and passes it to the server application.

The IP layer of backup server B, whose network interface runs in promiscuous mode, also receives all datagrams from client computer C. The backup server bridge discards the payload of any datagram that does not contain a TCP segment or that is not addressed to primary server P. For the payload of any other datagram, it replaces the original destination field with the address AB of backup server B in the TCP segment header and passes the TCP segment to the TCP layer of backup server B. When it processes the TCP segment, the TCP layer assumes that client C sent this segment directly to backup server B.

After the server applications have processed the client's request, they generate a reply. Assuming that the server applications behave deterministically, both replies are identical. The TCP layers of the primary server and the backup server pack the replies into TCP segments. Note that, although the application replies are identical, the TCP layers might not generate identical sets of TCP segments. For example, due to flow control, the TCP layer of one of the servers might split the reply into multiple TCP segments, while the TCP layer of the other server might pack the entire reply into a single segment.

When the primary server bridge obtains TCP segments from the TCP layer, it puts the payload data in the primary server output queue and waits until it receives corresponding data from backup server B. The primary server bridge must not send any data to the client until it has received the data from both backup server B and its own TCP layer.

The TCP layer of backup server B passes TCP segments to the backup server bridge. If the backup server bridge receives a segment that is addressed to client C, it replaces the destination address field of the segment with the address of primary server P. Thus, all TCP segments intended for the client are diverted to primary server P. The backup server bridge includes the original destination address of the segment in the segment as a TCP header option.

When the primary server bridge receives the TCP segment that backup server B sent, it matches the segment's payload data against the data in the primary server output queue. The primary server bridge builds a new segment that contains the matching payload bytes. The remaining bytes of the original segment are queued in the backup server output queue. The new segment carries the address of primary server P in the source field and the address of client C in the destination field.

The acknowledgment field contains the smaller of the two acknowledgment sequence numbers of the last segments that the primary server bridge received from primary server P and backup server B. Choosing the smaller of the two acknowledgment sequence numbers guarantees that both servers have received all of the client's data up to that sequence number.

Similarly, the window size field contains the smaller of the two window sizes of the last segments that the primary server bridge received from primary server P and backup server B. Choosing the smaller of the two window sizes adapts the client's send rates to the slower of the two servers and, thus, reduces the risk of segment loss.

The primary server bridge maintains a variable Δseq, which is the offset in the sequence numbers that the TCP layers of primary server P and backup server B assign to segments that they send to client C. When they establish a new connection to client C, primary server P and backup server B choose initial sequence numbers seqP, initand seqB, init. The primary server bridge calculates the sequence number offset Δseqas the difference of those initial sequence numbers: Δseq=seqP, init−seqB, init. Subsequently, to compare the sequence numbers of TCP segments sent by P and B, the primary server bridge subtracts Δseqfrom the sequence numbers of each segment that it receives from the primary server's TCP layer.

FIG. 1throughFIG. 3depict the bridge within the present invention.FIG. 1represents the bridge within a primary server, whileFIG. 2depicts the bridge within a backup server. The method described above is reflected inFIG. 3. The left side of the figure shows the primary server bridge receiving a segment from the primary server TCP layer.FIG. 4AandFIG. 4Billustrate an example in which the primary server bridge is modifying the sequence numbers of the payload bytes.

If a bridge receives a TCP segment from a server but cannot build a TCP segment because the other server's queue does not contain any matching payload, it compares the minimum of P's and S's most recent acknowledgments with the acknowledgment of the previous TCP segment that it built. If the former is greater than the latter, the bridge constructs a TCP segment with no payload to acknowledge the client's segment. This prevents a deadlock in the case that the server application does not send any data to the client.

In standard TCP, acknowledgments of segments are piggybacked onto segments that are sent in the opposite direction. If no data are sent in the opposite direction, TCP creates a TCP segment that carries no user data, which is referred to as a delayed acknowledgment.

In this embodiment of the present invention, if the bridge receives such a delayed acknowledgment, it updates the ACK and WinSize fields of the segment header and compares the new ACK value with the ACK value of the last segment that it sent to the client. If the former is greater than the lafter, the bridge constructs a TCP segment with no payload.

2.2. Loss of Messages.

In standard TCP, dropping a TCP segment m has several effects at the intended destination. First, the destination will not acknowledge m or any later segments that the source of m sends. When the source's retransmission timer expires, the source retransmits m. Second, the destination will not receive the acknowledgment ackkthat the source attached to m and that acknowledges the destination's segment k. If the source does not send additional TCP segments that acknowledge the destination segment k, the destination retransmission timer expires, and the destination retransmits segment k.

The present invention handles such loss of segments, which can occur at several places, as follows:

(a) The primary server P does not receive the client's segment m, but the backup server receives it. In this case, the TCP layer of primary server P does not acknowledge m. Consequently, the primary server bridge does not acknowledge m. Client C retransmits m after its retransmission timer expires. Segment m might carry an acknowledgment ackkfor a segment k that the servers sent. Because the primary server does not receive ackk, it retransmits k. By comparing the sequence number of segment k with the sequence number of the last segment that it sent, the primary server bridge recognizes that segment k is a retransmission and that it has already received a copy of segment k from the backup server. Therefore, the primary server bridge does not queue segment k, waiting for a copy of segment k from the backup server; rather, it transmits segment k immediately.

(b) The backup server does not receive the client's segment m, but the primary server receives it. This case is similar to case (a) in that the backup server retransmits segment k and the primary server bridge transmits segment k, without waiting to receive a retransmission of segment k from the TCP layer of primary server P, because it has already received segment k from the TCP layer of primary server P.

(c) The client transmits segment m containing the acknowledgment ackk, but neither primary server P nor backup server B receives segment m and, thus, neither receives ackk. In this case, the TCP layers of both primary and backup servers retransmit segment k. When the primary server bridge receives either of those retransmissions, it immediately transmits segment k to the client, for the reasons described above in cases (a) and (b) above.

(d) The primary server bridge does receive segment k that backup server B sent and, thus, will not send any more segments to client C until it has received the segment k. Consequently, client C will not acknowledge the segment k, and both servers will retransmit k. If the primary server bridge receives the retransmission of segment k from backup server B before it receives the retransmission of k from the primary server's TCP layer, the bridge recognizes that it has already received the transmission of k from the primary server's TCP layer and, thus, it immediately transmits k to the client. If the primary server bridge receives the retransmission of k from the primary server's TCP layer before it receives the retransmission of k from backup server B, it finds segment k in the primary server queue and discards the second copy of k that it received from the primary server's TCP layer.

(e) Client C does not receive the segment k transmitted by the primary server bridge to the client. Consequently, client C will not acknowledge segment k. The TCP layers in both primary server P and backup server B will retransmit k. The handling of these retransmissions is essentially equivalent to that described in case (c) above where the acknowledgment transmitted by the client was not received by either server. Consequently, the primary server bridge will retransmit k twice.

2.3. Failure of the Primary Server.

Primary server P and backup server B must exchange heartbeat messages on a regular basis. If backup server B determines that it is not receiving heartbeats from primary server P, it performs a reconfiguration procedure generally comprising the following steps:

(a) Disable the sending of heartbeats by backup server B.

(b) Request the backup server bridge to stop sending TCP segments, that are addressed to client C, to the IP layer.

(c) Disable the promiscuous receive mode of the network interface of backup server B.

(d) Disable the AP-to-ABaddress translation of the destination field for incoming TCP segments of FT connections.

(e) Disable the AC-to-APaddress translation of the destination field for outgoing TCP segments of FT connections.

(f) Change the IP address of backup server B to the address of primary server P and send a gratuitous ARP request packet.

(g) When the change of the IP address is completed, resume sending TCP segments by the backup server bridge.

After the reconfiguration of the backup server bridge, backup server B sends its TCP segments directly to client C, and behaves like any standard TCP server.

Note that, during the reconfiguration of the backup server bridge, neither the sequence number nor the ACK sequence number nor the window size needs to be changed.

2.4. Failure of the Backup Server.

If primary server P determines that it is not receiving heartbeats from backup server B, it performs a reconfiguration procedure generally comprising the following steps:

(a) Remove all payload data from the primary server output queue, place the data into a newly created TCP segment (or multiple TCP segments, if necessary), and send the TCP segment to client C.

(b) Disable the demultiplexer for incoming IP datagrams. Route all incoming TCP segments directly to the TCP layer.

(c) Disable the delay of TCP segments that primary server P created. Do not modify the acknowledgment field or the window size of those segments. But, continue to subtract the offset Δseqfrom the sequence number field of all outgoing TCP segments that are addressed to client C.

After the completion of the recovery from the failure of the backup server B, all TCP segments that primary server P sent to client C contain the acknowledgment and the window size that the TCP layer of primary server P chose.

During normal operation, all segments that the primary server bridge sends to client C carry sequence numbers that the TCP layer of backup server B assigned. The primary server bridge adjusts all of the sequence numbers that the TCP layer of primary server P assigned by subtracting Δseq.

If backup server B fails, the primary server bridge does not discontinue subtracting the offset because the TCP layer of client C is synchronized to the sequence numbers that backup server B generated.

The establishment of a standard TCP connection is a three-way handshake. First, the client sends a TCP segment to the server that has the synchronization flag (SYN segment) set. The SYN segment specifies a server port and contains the client's initial sequence number. Second, if the server accepts the connection, it sends back a SYN that acknowledges the client's SYN. The server's segment contains the server's initial sequence number and an acknowledgment of the client's SYN segment. Third, the client acknowledges the server's SYN segment. The connection is then established, and either side can send TCP segments.

The present invention establishes a FT connection as follows:

(a) The backup server bridge performs the address translation of the destination address of the outgoing SYN segments. It then decrements the Maximum Segment Size (MSS) field of the segment by 8 bytes for IPv4 (where 4 bytes are used to mark the option and 4 bytes are used for the client address in the TCP options field) and 20 bytes for IPv6 (where 4 bytes are used to mark the option and 16 bytes are used for the client address in the TCP options field). The primary server bridge receives the initial SYN segment from the client and passes the SYN segment to the TCP layer.

(b) When the TCP layer of primary server P accepts the connection request, it sends a SYN segment to the primary server bridge.

(c) On receiving this segment from the TCP layer, the primary server bridge creates the primary and backup server output queues, and then queues the segment. The primary server bridge stores the sequence number seqP,initof that segment to be able to perform the sequence number offset calculation.

(d) The backup server bridge receives the initial SYN segment from client C, does the address translation of the destination address of the segment, and passes the SYN segment to the TCP layer.

(e) When the TCP layer of backup server B accepts the connection request, it passes a SYN segment to the backup server bridge.

(f) The backup server bridge then passes the segment to the IP layer.

(g) When the primary server bridge receives the SYN segment that the TCP layer of backup server S sent, it calculates the sequence number offset Δseqby subtracting the sequence number seqB,initof the SYN segment from seqP,init.

(h) The primary server bridge now builds the SYN segment that is to be sent to the client. It sets the MSS field of that segment to the minimum of the MSS fields contained in the SYN segments created by the TCP layers of primary server P and backup server B.

(i) The primary server bridge passes the segment to the IP layer.

(j) The TCP layer of client C receives the SYN segment from primary server P and responds by sending an acknowledgment.

(k) The primary server bridge and backup server bridge handle the acknowledgment segment in the same way as future incoming segments.

Primary server P and backup server B initiate the establishment of a TCP connection to a third-tier back-end server by sending a SYN segment. The TCP layers of the primary server and the backup server both generate a SYN segment. When it receives the first SYN segment, the primary server bridge creates the primary and backup server output queues and queues the TCP segment. When a server's bridge receives the other server's SYN segment, it calculates the sequence number offset, creates a SYN segment and sends it to the third-tier back-end server.

When the TCP layer of the third-tier back-end server accepts the connection request, it sends a SYN segment in return. Both the primary server bridge and the backup server bridge handle the acknowledgment segment in the same way as future incoming segments. The servers complete the three-way handshake by sending an acknowledgment for the client's SYN segment.

The termination of a standard TCP connection is a four-way handshake. Either side can initiate the connection termination process. Each direction of the connection is shut down independently of the other. To terminate one direction of a TCP connection, the sending endpoint sends a TCP segment that has the FIN flag set. The other endpoint acknowledges the FIN segment. The connection is now in a half-closed state, in which the endpoint that has not sent the FIN is still allowed to send data. The other endpoint must acknowledge all incoming segments, but is not allowed to send data. The half-closed state prevails until the side that remained active sends a FIN. As soon as the other side acknowledges the FIN, the connection is closed.

In the present invention, if client C initiates the connection termination, the FT connection is terminated as follows:

(a) The primary server bridge receives a FIN segment from client C. It marks the TCP client-to-server direction of the connection as closed, and then passes the FIN segment to the TCP layer.

(b) When the primary server bridge has received a FIN segment from the TCP layer of primary server P and backup server B, it marks the connection as closed and then sends the FIN segment to client C.

(c) When the primary server bridge receives the client's acknowledgment of the servers'FIN segment, it deletes all internal data structures that were allocated for that connection and passes the acknowledgment to the TCP layer.

(d) If backup server B does not receive the client's acknowledgment for the FIN segment within a timeout, B retransmits the FIN segment. When the primary server bridge receives a FIN that B sent after it deleted all internal data structures associated with the connection, it creates an acknowledgment on behalf of the client and sends the acknowledgment to B.

In the present invention, if the servers initiate the connection termination, the FT connection is terminated as follows:

(a) The primary server bridge receives a FIN segment from the TCP layer of primary server P and backup server B. The bridge marks the server-to-client direction of the connection as closed, and then sends the FIN segment to the client.

(b) When the primary server bridge receives the FIN segment sent by client C, it marks the connection as closed and passes the FIN segment to the TCP layer.

(c) When the primary server bridge receives the acknowledgment of the client's FIN from the TCP layer of the primary server and the backup server, the primary server bridge deletes all internal data structures that were allocated for that connection and sends the acknowledgment to the client.

(d) If client C does not receive the servers' acknowledgment, it retransmits the FIN segment. When the primary server bridge receives a FIN segment sent by client C after the primary server bridge has removed all internal data structures associated with the connection, it creates an acknowledgment and sends it back to client C.

2.8. Starting a New Backup Server.

The process of starting a new backup server involves the following steps. The primary server checkpoints its state by performing the following operations:

(a) Capture the state of the server application.

(b) Capture the state of the TCP connections that the server application currently uses, including the socket buffer state.

(c) Save the sequence number offset of all TCP failover connections.

(d) Prepare the primary server bridge to collaborate with the backup server by creating the backup server output queue and initializing the data structures and variables.

(e) Change the primary server bridge mode from BACKUP_SERVER_DOWN to BACKUP_SERVER_UP.

(f) Communicate the state to the backup server.

Operations (a) through (e) must be executed atomically. After they are executed, the bridge sends TCP segments to the client only if it has received the corresponding segments from the primary server TCP layer and the backup server.

To start a new backup server, the following operations are performed at the new backup server:

(g) Receive the state from the primary server.

(h) Start the server application and upload the application state.

(i) Create the ongoing TCP connections by uploading the state of the TCP layer for those connections.

(j) Modify the sequence number counter of the TCP layer (subtract seqOffset) so that all outgoing TCP segments transmitted by the backup server have the sequence numbers expected by the client and thus require no modification in the primary server bridge. The sequence numbers of segments, pending transmission or acknowledgment, must also be modified.

(k) Modify the Maximum Message Size (MSS) for all established connections that the server applications maintain. This ensures that the segments provide enough space to attach the original client address to the TCP header.

(m) Put the backup server into promiscuous receive mode.

Operations (h) though (m) must be executed atomically. With the exception of the sequence number offset, it is not necessary to transfer the rest of the bridge state. Operations (c) and (j) are necessary because the primary server's TCP layer uses different sequence numbers than the client uses. In the embodiment described earlier, the backup server does not modify sequence numbers. Therefore, the TCP layer state is modified, so that the sequence numbers of all outgoing segments conform to the client's sequence numbers and, similarly, for the acknowledgment sequence numbers of all incoming segments.

The method described above can be modified in several ways, a few of which are described below by way of example.

3.1. Modification 1: No IP Failover of Backup Server.

As described previously, the backup server takes over the IP address of the primary server when the primary server fails. Modification 1 does not require the backup server to take over the primary server's IP address. If the primary server fails, the backup server remains in promiscuous mode, and the backup server bridge continues to modify the destination address of incoming TCP segments and the source address of outgoing TCP segments.

As described previously, the backup server obtains the client's segments by putting its network interface in promiscuous mode. Modification 2 does not require the use of promiscuous receive mode. The primary server bridge copies the TCP segment it received from the client and sends it to the backup server. The client's IP address is stored in the TCP options field of the segment.

Modification 1 and modification 2 are incompatible. If the backup server does not receive the client segments through an interface that operates in promiscuous mode, it must take over the primary server's IP address when the primary server fails.

3.3. Modification 3: Adjustment of Sequence Numbers and Acknowledgment Sequence Numbers.

In the method described above, only the primary server bridge adjusts the sequence numbers and the acknowledgment sequence numbers. Alternatively, both the primary server bridge and the backup server bridge could perform the adjustments of the sequence numbers and acknowledgment of sequence numbers.

If the backup server adjusts the sequence numbers and acknowledgment sequence numbers then, when a new backup server is brought up, the TCP layer state for the sequence numbers and acknowledgment sequence numbers does not need to be modified.

3.4. Modification 4: Sending and Comparing Payload Bytes.

In the method described above, the backup server bridge sends the TCP segment, including the payload data that it received from its TCP layer, to the primary server. The primary server bridge compares the payload data bytes that it received in the TCP segment from the backup server bridge with the corresponding payload data bytes in the TCP segment that it received from its own TCP layer.

Alternatively, the backup server bridge does not send the payload data bytes of the TCP segment that it received from its TCP layer, to the primary server bridge. Instead, the backup server bridge sends a TCP segment containing the following fields from the TCP segment header: the address of the client, the TCP sequence number, the length of the payload data, the acknowledgment sequence number, the Maximum Segment Size and the window size.

When the primary server bridge receives the TCP segment without the payload data bytes, from the backup server, the primary server bridge matches the sequence number and data length contained in that segment against the sequence numbers of the data in the primary server output queue. The primary server bridge builds a new segment that contains the data bytes from the primary server output queue whose sequence number match the sequence numbers that it received from the backup server bridge. Any unmatched sequence numbers that it received from the backup server are stored in the backup server output queue. The new TCP segment carries the address of the primary server in the source field and the address of the client in the destination field.

3.5. Modification 5: Adjustments of Sequence Numbers in Captured State.

Section 2.8 above describes how the state of the TCP connections can be checkpointed to start a new backup server. It is possible to modify the sequence numbers by modifying the state captured in operation (b) of Section 2.8. The parts of the captured state that correspond to sequence numbers are modified. This modification eliminates the need to perform operation (k) of Section 2.8. The modification of the captured state can be performed in either the primary server or the backup server. If the modification of the captured state is performed in the primary server, the sequence number offset, determined in operation (c) of Section 2.8 above, does not need to be communicated to the backup server.

4. Detailed Descriptions of Figures.

FIG. 1illustrates an example of functional blocks within a primary server computer2. The primary server computer hosts one or more applications4, which communicate with a TCP layer of that computer6. A primary server bridge8resides between the TCP layer and the IP layer.

Outgoing TCP segments are passed to a demultiplexer10. TCP segments that do not belong to a FT connection are passed12directly to IP layer26. TCP segments that belong to a FT connection are passed to a core16of the primary server bridge.

Incoming TCP segments that are delivered by IP layer26of the primary server computer are passed30to the primary server bridge. A demultiplexer24separates the incoming segments by their source addresses. Segments from a computer other than the backup server are passed directly20to the TCP layer. Segments from the backup server are passed22to the core of the primary server bridge.

If the core has received bytes14with identical sequence numbers from the primary server's TCP layer6and bytes22from the backup server, it generates TCP segments that contain those bytes, addresses the segments to the client, and passes18those bytes to IP layer26. IP layer26packs the TCP segments into an IP datagram and passes it to the network driver28, which sends the datagram to the client.

FIG. 2illustrates an example of functional blocks within a backup server50, which hosts one or more server applications52. The applications are identical to those running on primary server4. The applications communicate with a TCP layer54. A backup server bridge56resides between TCP layer54and an IP layer64.

Outgoing TCP segments are passed to a demultiplexer58. TCP segments that do not belong to a FT connection are passed60directly to IP layer64. The backup server bridge replaces62the original destination (client) address of each TCP segment that belongs to a FT connection with that of the primary server and places the client address in the TCP options field of the TCP segment, and then passes the TCP segment to IP layer64. IP layer64packs the TCP segment into an IP datagram and passes it to a network driver66, which sends the datagram to the primary server.

Incoming TCP segments are passed to the backup server bridge only if they are addressed to the primary server or the backup server. A demultiplexer in the backup server bridge separates the incoming segments by their destination address68. Segments that are addressed to the backup server are passed directly70to the TCP layer. Segments that are addressed to the primary server are passed to a second demultiplexer72. If a segment does not belong to a FT connection, the backup server bridge drops the TCP segment74. If a segment belongs to a FT connection, the backup server bridge replaces the original (primary server) destination address with the address of the backup server B76, and then passes the segment to the TCP layer54.

FIG. 3shows the core of the primary server bridge. The core accepts a TCP segment that the primary server's TCP layer generated80. The core adjusts the sequence number of the TCP segment82. The core saves the value in the TCP segment's ACK field in the variable AP84and the values in the TCP segment's window size field in the variable WP86.

If the payload in a TCP segment matches any payload in the backup server output queue106, the core creates one or more TCP segments94. It dequeues from the backup server output queue90matching payload bytes, and queues in the primary server output queue88all payload bytes that are not contained in the backup server output queue.

The core writes the minimum of the values of the variables APand ASinto the acknowledgment field of a new TCP segment108. The core writes the minimum of the values of the variables WPand WBinto the window size field of the new TCP segment92. Once the TCP segment is complete, the core passes96the segment to the IP layer of the primary server.

If the core receives a TCP segment that the backup server generated100, the core saves the value of the TCP segment's ACK field in a variable AB102, and it saves the value of the TCP segment's window size field in a variable WB104.

If the payload of a TCP segment matches any payload in the primary server output queue88, the core creates one or more TCP segments94. It dequeues from primary server output queue90all matching payload bytes, and it queues in backup server output queue106all payload bytes that are not contained in the primary server output queue.

The core writes the minimum of the values of the variables APand ASinto the acknowledgment field of a new TCP segment108. The core writes the minimum of the values of the variables WPand WBinto the window size field of new TCP segment92. Once the TCP segment is complete, the core passes96the segment to the IP layer of the primary server.

FIG. 4AandFIG. 4Billustrate an example in which the primary server bridge is modifying the sequence numbers of the payload bytes. The segment that the primary server bridge just received contains the payload bytes with sequence numbers51to54as shown at block110inFIG. 4A, Δseqequals 30 as shown at block112, and the primary server bridge had previously received a segment containing the payload bytes with sequence numbers21and22as shown at block124ofFIG. 4Bfrom the backup server. After the primary server bridge subtracts Δseqfrom the sequence numbers of the bytes it just received from the primary server TCP layer, it queues those bytes, which now have sequence numbers21to24as shown at block114ofFIG. 4A, in the primary server output queue. Referring toFIG. 4B, the primary server bridge then receives a segment, sent by the backup server, that carries the payload bytes with sequence numbers23to26as shown at block120. The primary server bridge finds and removes the matching bytes with sequence numbers23and24as shown at block124in the primary server output queue, dequeues the matching payload as shown at block126, and creates a new TCP segment as shown at block128with those bytes in its payload130which it then passes to the IP layer. It queues the remaining bytes with sequence numbers25and26as shown at block122in the backup server output queue.

FIG. 5considered without block162and with a direct arrow from block152to block150, illustrates the operation of the IP layer of a standard TCP/IP protocol stack. On sending a TCP segment, TCP passes the segment at block140to the IP layer together with the source address and the destination address of the segment. The IP layer encapsulates the segment into an IP datagram as per block142, and then passes the datagram to the network interface driver as shown at block144.

On receiving a message from the network, the network interface driver passes each IP datagram to the IP layer at block146. The IP layer checks at block148for bit errors to see if the datagram is correct. If the datagram is corrupted, it discards the datagram at block158and terminates at block160. The IP layer then compares at block152the destination address of the datagram with the IP addresses assigned to its computer. If the destination address does not match any of those IP addresses, the IP layer checks whether it has a route for the address and can forward the datagram as shown by block150. If the IP layer has a route for the address, the IP layer passes the datagram back to the network interface driver; otherwise, it discards the datagram at block158and terminates at block160. If the destination address matches one of those IP addresses, the IP layer extracts the TCP segment from the datagram at block154and delivers it to the TCP layer at block156.

FIG. 5, with block162and the existing arrows, shows the IP layer of a TCP/IP protocol stack that implements TCP connection failover. The check in block162ensures that the backup server does not forward or discard IP datagrams addressed to the primary server. Instead, the backup server handles those datagrams just like datagrams that are addressed to the backup server. Otherwise, the steps are the same as those described above forFIG. 5and a standard TCP/IP protocol stack.

FIG. 6is a diagram that shows the primary server bridge receiving at block170a TCP segment from the IP layer of the primary server. The bridge checks at block172whether the backup server sent the segment. If the backup server sent the segment, the bridge processes the SYN flag at block174with processing continuing inFIG. 12. If the backup server did not send the segment, the bridge checks at block176whether the ACK flag in the TCP header is set. If the ACK flag in the TCP header is not set, it sets ACK equal to the sum of ACK and Δseqat block178. In either case, it then delivers the segment to the TCP layer at block180.

FIG. 7is a diagram that shows the primary server bridge receiving at block190a TCP segment from the TCP layer of the primary server. The bridge processes the SYN flag and FIN flag at block192, processing details are respectively described by the flowcharts ofFIG. 11andFIG. 13, and checks whether at block194the segment belongs to a FT connection. If the segment does not belong to a FT connection, the bridge passes the segment to the IP layer at block196, which sends it to the client. If the segment belongs to a FT connection, the bridge delivers the segment to the core of the primary server bridge at block198which is shown continuing inFIG. 10.

FIG. 8is a diagram that shows the core of the primary server bridge on receiving a TCP segment. If the core receives a TCP segment from the primary server's TCP layer at block200, it matches the segment's payload against the data in the backup server output queue at block202. The bridge creates at block204new TCP segments that contain the matching payload bytes using the adjusted sequence numbers from block304inFIG. 11. The bridge queues the remaining bytes of the original segment in the primary server output queue as represented by block206and deletes the original segment at block208.

The new segments carry the address of the primary server in the source field and the address of the client in the destination field. The acknowledgment field is set at block210to the smaller of the acknowledgment sequence numbers of the last segment that the bridge received from the TCP layer of the primary server or the backup server. The same procedure is used to fill the window size field of the new segments at block212. The segments are then passed to the IP layer at block214, which sends them to the client.

If the core receives a TCP segment from the backup server as represented by block220, it matches the segment's payload data against the data in the primary server output queue at block222. The bridge creates new TCP segments at block224that contain the matching payload bytes. It queues the remaining bytes of the original segment in the backup server output queue at block226and deletes the original segment at block228. The remainder of the procedure comprises steps represented by blocks210,212and214, as described above.

FIG. 9is a diagram that shows the backup server bridge receiving an incoming TCP segment from the IP layer at block240. First, it checks at block242whether the primary server is operational. If the primary server is not operational, the bridge delivers the incoming segment to the IP layer at block250. If the primary server is operational, the bridge checks whether the incoming TCP segment is addressed to the backup server at block244. If the incoming TCP segment is addressed to the backup server, the bridge passes the segment as per block250to the TCP layer. If the incoming TCP segment is not addressed to the backup server, the bridge checks whether the segment belongs to a FT connection at block246. If the segment belongs to a FT connection, the bridge overwrites the destination address of the segment with the address of the backup server at block248, and then passes at block250the segment to the TCP layer. If the segment does not belong to a FT connection, the bridge drops the segment252.

FIG. 10is a diagram that shows the backup server bridge receiving at block260an outgoing TCP segment from the TCP layer. First, the bridge checks at block262whether the segment belongs to a FT connection. If the segment does not belong to a FT connection, the bridge passes the segment to the IP layer at block270. If the segment belongs to a FT connection, the bridge checks at block264whether the primary server is operational. If the primary server is not operational, the bridge passes the segment to the IP layer at block270. If the primary server is operational, the bridge writes the client address into the TCP options field of the segment at block266and overwrites the client address in the destination field of the segment with the address of the primary server at block268. The bridge then passes the segment to the IP layer at block270, which sends the segment to the primary server.

FIG. 11is a diagram that illustrates the primary server bridge processing the SYN flags of segments that the bridge receives from the TCP layer as per block300. The bridge checks whether the SYN flag is set at block302. If the SYN flag is not set, the bridge subtracts the value of the variable seqOffset from the sequence number of the segment at block304and continues to process the TCP segment at block306. If the SYN flag is set, the bridge sets the value of the variable primarySynSeq equal to the sequence number of the TCP segment at block308.

If the variable backupSynSeq does not contain a valid sequence number at block310, the bridge drops the segment at block312and terminates at block322. Otherwise, the bridge calculates the value of the variable seqOffset at block314. It then creates at block316a new SYN segment without any payload and with a sequence number equal to that of the original SYN segment minus seqOffset, and passes the new SYN segment to the IP layer at block316, which sends the new SYN segment to the client.

The bridge then checks at block318whether the original SYN segment contains any payload. If the original SYN segment contains payload, the bridge clears the SYN flag of the segment at block320. In either case, the bridge then subtracts at block304seqOffset from segment.seq and continues processing at block306as if the segment were a regular segment sent by the primary server's TCP layer.

FIG. 12is a diagram illustrating primary bridge processing of the SYN flag of a TCP segment that the bridge received from the backup server as represented by block350. The bridge checks whether the SYN flag is set at block352. If the SYN flag is not set, the bridge continues to process the segment at block356. If the SYN flag is set, the bridge sets the value of the variable backupSynSeq, at block358, to the sequence number carried by the segment.

If the variable primarySynSeq does not contain a valid sequence number360, the bridge then checks whether the original SYN segment contains any payload at block368, and if the segment contains a payload the bridge clears the SYN flag of the original segment at block370and continues to process the segment at block356. Otherwise, the bridge calculates the value of the variable seqOffset364. It then creates a SYN segment, without any payload and with a sequence number equal to the sequence number of the original SYN segment minus seqOffset, and passes it to the IP layer at block366. The IP layer sends the SYN segment to the client.

The bridge then checks whether the original SYN segment contains any payload at block368. If the original SYN segment contains payload, the bridge clears the SYN flag of the segment at block370. In either case, the bridge then handles the segment like a regular segment sent by the primary server's TCP layer as represented by block356.

FIG. 13is a diagram that illustrates the primary server bridge processing a TCP FIN flag of a segment that it received from the TCP layer of the primary server at block400. The bridge checks at block402whether the FIN flag is set. If the FIN flag is not set, the bridge continues to process the segment inFIG. 8like a regular segment sent by the primary server's TCP layer as represented by block404. If the FIN flag is set, the bridge sets the value of the variable primaryFinSeq at block406to the sequence number of the last byte of the TCP segment.

The primary server bridge then checks at block408whether the value of the variable backupFinSeq is equal to the value of the variable primaryFinSeq. If the value of backupFinSeq is not equal to the value of primaryFinSeq, the bridge checks whether the original FIN segment contains payload at block412. If the original FIN segment contains payload, the bridge clears the FIN flag of the segment at block414. In either case, the bridge continues processing the segment as represented by block404.

If the value of backupFinSeq is equal to the value of primaryFinSeq, the bridge creates a FIN segment, without any payload and with sequence number equal to primaryFinSeq, and passes the new FIN segment to the IP layer at block410, which sends the FIN segment to the client. The primary server bridge then checks at block412whether the original FIN segment contains any payload. If the original FIN segment contains payload, the bridge clears the FIN flag of the segment at block414. In either case, the bridge then continues processing the segment like a regular segment sent by the primary server's TCP layer as represented by block404.

FIG. 14is a diagram that shows the primary server bridge processing a TCP FIN flag of a segment that it received from the backup server as represented by block420. The bridge checks whether the FIN flag is set at block422. If the FIN flag is not set, the bridge continues to process the segment as represented by block424. If the FIN flag is set, the bridge sets the value of the variable backupFinSeq at block426to the sequence number of the last byte of the TCP segment.

The backup server bridge then checks whether the value of the variable backupFinSeq is equal to the value of the variable primaryFinSeq at block428. If the value of backupFinSeq is not equal to the value of primaryFinSeq, it checks whether the original FIN segment contains any payload at block432. If the original FIN segment contains payload, the bridge clears the FIN flag of the segment at block434. In either case, it then continues to process the segment as represented by block424.

If the value of backupFinSeq is equal to the value of primaryFinSeq, the bridge creates a FIN segment, without any payload and with sequence number equal to primaryFinSeq, and passes at block430the new FIN segment to the IP layer, which sends the FIN segment to the client. The backup server bridge then checks at block432whether the original FIN segment contains any payload. If the original FIN segment contains payload, the bridge clears the FIN flag of the segment at block434. In either case, the bridge then continues processing the segment like a regular segment sent by the primary server's TCP layer as represented by block424.

FIG. 15is a diagram that shows the steps taken by the primary server bridge when the primary server detects at block500that the backup server has failed. The primary server bridge sends at block502all payload data that are in the primary server output queue. It then deletes the primary server output queue and the backup server output queue at block504and changes the primary server bridge mode from BACKUP_SERVER_UP to BACKUP_SERVER_DOWN at block506, and the process terminates at block508.

FIG. 16is a diagram that shows the steps taken by the backup server bridge when the backup server detects that the primary server has failed as represented by block520. The backup server takes over the IP address of the primary server at block522, disables the promiscuous receive mode at block524and then changes the backup server bridge mode from BACKUP_SERVER to PRIMARY_SERVER at block526, and the process terminates at block528.

FIG. 17is a diagram that shows the steps taken at the primary server to bring up a new backup server. The primary server checkpoints its state at block550by performing the following operations. The primary server captures the state of the server application at block552and the state of the fault-tolerant connections that the server application currently uses, including the socket buffer state at block554. It saves the sequence number offset of all fault-tolerant connections at block556. The primary server prepares the primary server bridge to collaborate with the backup server by creating the backup server output queue and initializing the data structures and variables at block558. The above operations must be executed atomically. The primary server then changes the primary server bridge mode from BACKUP_SERVER_DOWN to BACKUP_SERVER_UP at block560, and communicates state to the backup server at block562, and the process terminates at block564. Subsequently, the primary server bridge sends TCP segments to the client only if it has received the corresponding segments from the primary server TCP layer and the backup server.

FIG. 18is a diagram that shows the steps that are taken at a new backup server to start the new backup server as represented by block580. The backup server receives state from the primary server at block582. The backup server starts the server application and uploads the server application state at block584. It creates the ongoing fault-tolerant connections by uploading at block586the state of the TCP layer for those connections, including the socket buffers. It modifies the sequence number of all outgoing TCP segments (subtracts seqOffset) at block588. It modifies the Maximum Message Size (MSS) for all established connections that the server applications maintain, which ensures that the segments provide enough space to attach the original client address to the TCP header at block590. It enables address translation at block592, and enables promiscuous receive mode at block594, and the process terminates at block596. The above operations at the backup server must be executed atomically.

Accordingly, it will be seen that this invention of a method and system for maintaining a connection and providing transparent connection failover can be implemented with numerous variations obvious to those skilled in the art. It should be appreciated that the bridge routines, and other routines and elements described herein may be implemented with variations as to structure, order, sequence and optional aspects, without departing from the teachings of the present invention. It should also be appreciated that described aspects of the invention need not be implemented in each application which follows the teachings herein, while heretofore undescribed options may be implemented along with the teachings herein without departing from those teachings.