The classical example of object-oriented methodology is a window system. Starting with a basic window, one can construct extended windows with concepts like a border, a title bar, or a scroll bar. These form new objects that inherit the basic interface from the basic window object. The basic window with its interface and semantics forms a class, and each specialization or extension a subclass. The concept is generalized by building a tree of classes, the class hierarchy.
Protocols also match this model. We can start out with a basic protocol class that supports best-effort byte delivery over ATM or the Internet. With this protocol, messages may be delayed, lost, or garbled. As we layer other protocols over such a layer, its properties can be enhanced. A simple protocol that adds a (large enough) checksum to each message could be used to reduce the garbling problem to a statistically insignificant rate. Such a protocol has functionality on both the sending side, where it adds the checksum, and on the receive side, where it drops the message if the checksum does not match the contents of the message. More interestingly, the checksum could be made cryptographic (i.e., dependent on a secret key), making it impossible for an malignant intruder to impersonate a member process of the application. The corresponding protocol model forms a subclass of simple communication protocols.
Next in the class hierarchy could be a protocol that deals with message loss and reordering. By adding a sequence number to each message, a receiver can detect that messages have been reordered or lost. It can then request a retransmission by returning a negative acknowledgement message. This requires the sender to remember each message it sent until it knows that the message has arrived. To give some idea of what other protocols may be needed in a complex distributed system, we provide a list of many of the protocol types used in Horus (see Figure 1).
Figure: Protocol layers can be stacked at run-time like
LEGO.9extm blocks. The table on the bottom contains a list of
common protocol types.
A communication system, such as the Horus embedding of virtually synchronous process-groups into UNIX sockets, is built by stacking a set of protocol modules. The top-most module is the only one to deviate from the Horus interface standard: it converts the Horus protocol abstraction into one matching the needs and expectations of a user. Thus, when Horus is used through its socket interface, the top-most module converts socket sendto and recvfrom operations into the Horus paradigm.