Wrapping server-side TCP to mask connection failures

Alvisi, Lorenzo; Bressoud, Thomas; El-Khashab, A.M.; Marzullo, Keith; Zagorodnov, Dmitrii

doi:10.1109/infcom.2001.916715

Cited by 72 publications

(56 citation statements)

References 3 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…These components are the Encapsulation Node (EN) and the Decapsulation Node (DN) 1 . The EN typically runs on a client device, such as a smartphone or a laptop, and initiates a connection to the DN.…”

Section: Traditional Encapsulation Systemsmentioning

confidence: 99%

“…This solution, named Fault-Tolerant Transmission Control Protocol (FT-TCP) [1] [31], combines traditional IP failover protocols with a new component that sits both above and below the existing TCP stack to intercept all packets being send and received using TCP. It logs all packets to a data store that is shared amongst all the hosts in the cluster.…”

Section: Traditional Encapsulation Failovermentioning

confidence: 99%

See 1 more Smart Citation

An Architecture for Reliable Encapsulation Endpoints Using Commodity Hardware

Robinson

Ward

2011

2011 IEEE 30th International Symposium on Reliable Distributed Systems

View full text Add to dashboard Cite

Customized hardware is expensive and making software reliable is difficult to achieve as complexity increases. Recent trends towards computing in the cloud have highlighted the importance of being able to operate continuously in the presence of unreliable hardware and, as services continue to grow in complexity, it is necessary to build systems that are able to operate not only in the presence of unreliable hardware but also failure-vulnerable software. This thesis describes a newly developed approach for building networking software that exposes a reliable encapsulation service to clients and runs on unreliable, commodity hardware without substantially increasing the implementation complexity. The proposal was implemented in an existing encapsulation system, and experimental analysis has shown that packets are lost for between 200 ms and 1 second during a failover, and that a failover adds less than 5 seconds to the total download time of several sizes of files. The approach described in this thesis demonstrates the viability of building high availability systems using commodity components and failure-vulnerable server software.

show abstract

Section: Traditional Encapsulation Systemsmentioning

confidence: 99%

Section: Traditional Encapsulation Failovermentioning

confidence: 99%

An Architecture for Reliable Encapsulation Endpoints Using Commodity Hardware

Robinson

Ward

2011

2011 IEEE 30th International Symposium on Reliable Distributed Systems

View full text Add to dashboard Cite

show abstract

“…Specifically, request packets are acknowledged only after they are stored redundantly (logged) so that they can be obtained even after a failure of a server host (Aghdaie and Tamir, 2001;Aghdaie and Tamir, 2002;Alvisi et al, 2001). Since the server may be non-deterministic, none of the packets of a reply can be sent to the client unless the entire reply is safely stored (logged) so that its transmission can proceed despite a failure of a server host (Aghdaie and Tamir, 2001;Aghdaie and Tamir, 2002).…”

Section: Coral Architecturementioning

confidence: 99%

“…Since the server may be non-deterministic, none of the packets of a reply can be sent to the client unless the entire reply is safely stored (logged) so that its transmission can proceed despite a failure of a server host (Aghdaie and Tamir, 2001;Aghdaie and Tamir, 2002). The logging of requests can be done at the level of TCP packets (Alvisi et al, 2001) or at the level of HTTP requests (Aghdaie and Tamir, 2001;Aghdaie and Tamir, 2002). If request logging is done at the level of HTTP requests, the requests can be matched with logged replies so that a request will never be reprocessed following failure if the reply has already been logged (Aghdaie and Tamir, 2001;Aghdaie and Tamir, 2002).…”

Section: Coral Architecturementioning

confidence: 99%

“…This is critical in order to ensure that for each request only one reply will reach the client. If request logging is done strictly at the level of TCP packets (Alvisi et al, 2001), it is possible for a request to be replayed to a spare server following failure despite the fact that a reply has already been sent to the client. Since the spare server may generate a different reply, two different replies for the same request may reach the client, violating the requirement for transparent fault tolerance.…”

Section: Coral Architecturementioning

confidence: 99%

See 1 more Smart Citation

CoRAL: A transparent fault-tolerant web service

Aghdaie¹,

Tamir²

2009

Journal of Systems and Software

View full text Add to dashboard Cite

The Web is increasingly used for critical applications and services. We present a client-transparent mechanism, called CoRAL, that provides high reliability and availability for Web service. CoRAL provides fault tolerance even for requests being processed at the time of server failure. The scheme does not require deterministic servers and can thus handle dynamic content. CoRAL actively replicates the TCP connection state while maintaining logs of HTTP requests and replies. In the event of a primary server failure, active client connections fail over to a spare, where their processing continues seamlessly.We describe key aspects of the design and implementation as well as several performance optimizations.Measurements of system overhead, failover performance, and preliminary validation using fault injection are presented.

show abstract