The context/strategy separation enables to overcome the limitations of
inheritance, as far as protocol composition goes. One could for example
optimize the reliable multicast algorithm and use it in some protocol
classes, while leaving it unchanged in others. Protocol algorithms could
even be dynamically edited and/or chosen, according to criteria computed at
runtime; this feature is analogous to the dynamic interpositioning of
objects. There is a minor compatibility constraint among different
protocol algorithms in order to make them interchangeable: new algorithm
class 
Algo
can replace default Algo in protocol
class Object if and only if Algo requires
a subset of the services featured by Object.
This approach also helps protocol programmers to clearly specify, for each
protocol , what are its dependencies with other protocols. One
drawback of the Strategy pattern is the overhead due to local interactions
between strategies and contexts. In distributed systems however, this
overhead is small compared to communication delays, especially when
failures and/or complex protocols are involved. More specifically, the
time for a local Smalltalk invocation is normally under 100 
,
whereas a reliable multicast communication usually takes more than 100 ms
when three or more protocol objects are involved
(without even considering
failures). The gain in flexibility clearly overtakes the local overhead
caused by the use of the Strategy pattern.