The work done by O'Malley and Peterson [16] is the closest to BAST that we could find. They extended the x-Kernel with the
notion of microprotocol graph, and they described a methodology for
organizing network software into a complex graph, where each microprotocol
encapsulates a single function. In contrast, conventional ISO and TCP/IP
protocol stacks have much simpler protocol graphs, with each layer
encapsulating several related protocol functions. They argue that such a
fine-grain decomposition allows to better tailor communication protocols to
application needs; our conclusion concurs theirs perfectly on that point.
In their paper, O'Malley and Peterson mainly apply their approach to RPC
communications (with only one very short discussion on a what they call a
fault-tolerant multicast). Compared to BAST, their approach
is very close to what we have done and is based on the same basic
assumption: composing (micro-)protocols is essential when it comes to
customize complex distributed applications (and fault-tolerance implies
such a complexity). In their terminology, what we call
problem 
is referred to as metaprotocol .
There are also some important differences, however. They do not provide ready-to-use protocol classes to application programmers who are not skilled at understanding and/or building complex protocol graphs, whereas this is one of the main goals of BAST [7]. Moreover, their approach does not rely on design patterns. Similarly to CONDUIT+, they go one step further in their decomposition of protocol algorithms, by defining the notion of virtual protocols. The latter ``are not truly protocols in the traditional sense'' [16, page 131,] : virtual protocols are actually used to remove IF-statements and to place them in the microprotocol graph instead. All those differences can be best understood by looking at the background domains of the BAST library and the x-Kernel respectively. The latter aims at helping system programmers to customize any communication protocol usually found in modern operating systems, while the former aims at providing ready-to-use protocol classes, in order to help any programmer to build fault-tolerant applications, and at allowing skilled programmers to build news fault-tolerant protocols easily.