Check out the new USENIX Web site. next up previous
Next: Reliable Multicast: an Example Up: Protocol Algorithms as Strategies Previous: Strategy/Context Interactions.


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 tex2html_wrap_inline777 Algotex2html_wrap_inline851 can replace default tex2html_wrap_inline777 Algo in protocol class tex2html_wrap_inline777 Object if and only if tex2html_wrap_inline777 Algotex2html_wrap_inline851 requires a subset of the services featured by tex2html_wrap_inline777 Object.

This approach also helps protocol programmers to clearly specify, for each protocol tex2html_wrap_inline777, 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 tex2html_wrap_inline865, whereas a reliable multicast communication usually takes more than 100 ms when three or more protocol objects are involvedgif (without even considering failures). The gain in flexibility clearly overtakes the local overhead caused by the use of the Strategy pattern.

Wed May 14 17:28:46 MET DST 1997