Documente Academic
Documente Profesional
Documente Cultură
David D. Clark*
Massachusetts Institute of Technology
Laboratory for Computer Science
Cambridge, MA. 02139
(Originally published in Proc. SIGCOMM ‘88, Computer Communication Review Vol. 18, No. 4,
August 1988, pp. 106–114)
There are two important advantages to fate-sharing over The first example of a service outside the range of TCP
replication. First, fate-sharing protects against any was support for XNET12, the cross-Internet debugger.
number of intermediate failures, whereas replication can TCP did not seem a suitable transport for XNET for
only protect against a certain number (less than the several reasons. First, a debugger protocol should not
number of replicated copies). Second, fate-sharing is be reliable. This conclusion may seem odd, but under
much easier to engineer than replication. conditions of stress or failure (which may be exactly
when a debugger is needed) asking for reliable
There are two consequences to the fate-sharing communications may prevent any communications at
approach to survivability. First, the intermediate packet all. It is much better to build a service which can deal
switching nodes, or gateways, must not have any with whatever gets through, rather than insisting that
essential state information about on-going connections. every byte sent be delivered in order. Second, if TCP is
Instead, they are stateless packet switches, a class of general enough to deal with a broad range of clients, it
network design sometimes called a "datagram" network. is presumably somewhat complex. Again, it seemed
Secondly, rather more trust is placed in the host wrong to expect support for this complexity in a
machine than in an architecture where the network debugging environment, which may lack even basic
ensures the reliable delivery of data. If the host resident