Many software applications use connection-oriented transport protocols to provide communication and networking services to client devices. For example, Hypertext Transfer Protocol (HTTP) is an application-level protocol commonly used to transport web pages and related data to client web browsers. HTTP can operate, either directly or indirectly, on top of the Transport Connection Protocol (TCP). TCP is a connection-oriented protocol which provides a service to ensure proper delivery of a data stream of packets sent from one network device to another without duplication or loss of data. Since packet transfer is generally not reliable, TCP utilizes a technique known as positive acknowledgment with retransmission to guarantee reliability of packet transfers. This technique requires the receiving device to respond with an acknowledgment message as it receives the data. The sending device keeps a record of each packet it sends, and waits for acknowledgment before sending the next packet. The sending device also keeps a timer starting from when the packet was sent, and retransmits a packet if the timer expires. The timer is needed in case a packet gets lost or corrupted. Another example of a connection-oriented protocol is Stream Control Transmission Protocol (SCTP), which can be used by clients to transport Session Initiation Protocol (SIP) signaling messages for telephony or other media sessions.
Increasingly, users rely upon or expect better availability and stability of communication and networking services. Therefore, many applications have been specifically designed to handle faults at the transport layer by instantiating a new transport connection. For example, if a TCP connection is broken, a typical web browser might fail an ongoing request but will establish a new TCP connection for a retry or a new request. Similarly, a SIP Voice Over IP (VOIP) client might fail an ongoing call attempt if the TCP connection terminates but will try a new call on a different TCP connection.
Despite the ability to service future requests after a transport failure, these transport failures are not transparent to the client device. Recovery from the transport failures frequently requires action on the part of the client device and, sometimes, the user. This requirement of action by the client device or the user affects both usability of the client device and related software applications and customer perceptions of service quality. Various schemes have been attempted to provide for the transparent recovery and continuation of a transport connection after a failure. However, these attempts have required customization of the hardware, firmware, and/or networking protocol stack contained in the operating system of the device. Unfortunately, since many service providers use off-the-shelf operating system software, it is inefficient, costly, or impossible to directly modify the networking protocol stacks to provide transparent recovery and continuation.
A need therefore exists for improved methods and apparatuses for transparent recovery of transport connections.