Engineering fault-tolerant TCP/IP servers using FT-TCP

Zagorodnov, Dmitrii; Marzullo, Keith; Alvisi, Lorenzo; Bressoud, Thomas

doi:10.1109/dsn.2003.1209950

Cited by 33 publications

(17 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Our architecture is most related to FT-TCP [2,18], ST-TCP, Backdoors [4,17] and other similar systems. Some differences between our architecture and FT-TCP…”

Section: Related Workmentioning

confidence: 99%

Enhanced server fault-tolerance for improved user experience

Marwah

Mishra

Fetzer

2008

2008 IEEE International Conference on Dependable Systems and Networks With FTCS and DCC (DSN)

View full text Add to dashboard Cite

show abstract

“…Our architecture is most related to FT-TCP [2,18], ST-TCP, Backdoors [4,17] and other similar systems. Some differences between our architecture and FT-TCP…”

Section: Related Workmentioning

confidence: 99%

Enhanced server fault-tolerance for improved user experience

Marwah

Mishra

Fetzer

2008

2008 IEEE International Conference on Dependable Systems and Networks With FTCS and DCC (DSN)

View full text Add to dashboard Cite

show abstract

“…Second, either servers are required to be deterministic (Marwah et al, 2003;Shenoy et al, 2000), or frequent synchronization between servers is required (Burton-Krahn, 2002;Zagorodnov et al, 2003). Otherwise, the backup may not have an identical copy of a reply and thus it can not always continue the transmission of a reply should the primary fail in the midst of sending a reply.…”

Section: Coral Architecturementioning

confidence: 99%

“…There is significant on-going research on reliability enhancements on top of Web protocols FT-TCP (Alvisi et al, 2001;Zagorodnov et al, 2003) uses the log and replay approach. It is implemented as a kernel-level TCP wrapper that transparently masks server failures from clients.…”

Section: Related Workmentioning

confidence: 99%

“…To achieve the fault tolerance goals, active replication of the servers may be used, where every client request is processed by two (or more) server replicas (Burton-Krahn, 2002;Marwah et al, 2003;Shenoy et al, 2000;Zagorodnov et al, 2003). During fault-free operation, the reply from only one of the servers is sent to the client.…”

Section: Coral Architecturementioning

confidence: 99%

“…A protocol similar to that of our kernel module is used to achieve client transparency. An improved version of the scheme (Zagorodnov et al, 2003) uses a backup host instead of the logger, handles non-determinism, and allows for system operation in either cold (logging) or hot (active replication) modes. Nondeterministic execution is handled by synchronizing the system call results of the primary and backup hosts.…”

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

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

Kernel support for zero‐loss Internet service restart

Chang

Tsai

et al. 2006

Softw Pract Exp

View full text Add to dashboard Cite

Owing to long serving time and huge numbers of clients, Internet services can easily suffer from transient faults. Although restarting a service can solve this problem, information of the on-line requests will be lost owing to the service restart, which is unacceptable for many commercial or transaction-based services. In this paper, we propose an approach to achieve the goal of zero-loss restart for Internet services. Under this approach, a kernel subsystem is responsible for detecting the transient faults, retaining the I/O channels of the service, and managing the service restart flow. In addition, some straightforward modifications to the service should be made to take advantage of the kernel support. To demonstrate the feasibility of our approach, we implemented the subsystem in the Linux kernel. Moreover, we modified a Web server and a CGI program to take advantage of the kernel support. According to the experimental results, our approach incurs little runtime overhead (i.e. less than 3.2%). When the service crashes, it can be restarted quickly (i.e. within 210 µs) with no information loss. Furthermore, the performance impact due to the service crash is small. These results show that the approach can efficiently achieve the goal of zero-loss restart for Internet services. Copyright KERNEL SUPPORT FOR ZERO-LOSS INTERNET SERVICE RESTART 835 RELATED WORKIn this section, we describe the previous works that were used or can be used for building fault-tolerant Internet service systems.Checkpointing [11] is one of the most well-known approaches for system recovery. It checkpoints the software state into a stable storage. When a fault occurs, the system can be recovered from the last checkpointed state. This approach can be applied on different levels, such as user library level [12,13], compiler level [14-16], operating system level [17,18], and hardware level [19]. Although this approach can recover a system from transient faults, it is not suitable for service applications that contain hard-to-be-detected bugs, which cause them to crash after a long time of execution. This is because the recovered state is aged, instead of fresh, and thus the service may crash again immediately after the recovery. In this situation, to restart a fresh copy of the service is a more suitable approach. In addition, many checkpoint techniques incur large overheads owing to the large amount of the checkpointed state and the access to the stable storage. Since our approach does not address server node failures but only service faults, we use memory for state storage. Moreover, we can reduce the amount of state that needs to be saved through application-kernel cooperation.The concept of developing recovery-oriented software for dealing with errors was proposed by the Recovery-Oriented Computing (ROC) project [20], which is a joint effort of University College Berkeley and Stanford University. Different from the previous research, which usually addressed the Mean Time to Failure (MTTF), ROC offered high availability by reducing the Mean...

show abstract

Engineering fault-tolerant TCP/IP servers using FT-TCP

Abstract: In a recent paper [2] we have proposed FT-TCP: an

Cited by 33 publications

References 11 publications

Enhanced server fault-tolerance for improved user experience

Enhanced server fault-tolerance for improved user experience

CoRAL: A transparent fault-tolerant web service

Kernel support for zero‐loss Internet service restart

Contact Info

Product

Resources

About