There are situations where an application’s message protocol may change while the application is running. First we’ll examine the ways in which a message protocol can vary during runtime, then we’ll see how our message-passing facility would need to be modified to support these adaptable message protocols.
The most common situation encountered in message passing is a message whose argument list varies in length. Some arguments are actually lists of values, whose size is not known by the receiver beforehand. A multiuser server may provide a way to ask for its current list of users, for example. Optional arguments are another cause for variable-length argument lists. Continuing with the multiuser server example, a request for its list of current users may be a message with some optional arguments that control how much data is returned. A “verbose” argument may indicate that the caller wants all available information on the current users. When this argument is not present, a more condensed set of data is returned.
These possibilities imply that the recipient of a message may require
information on the number of arguments to expect. In our previous
examples, the message objects handling incoming messages were
hardwired to expect a given number of messages, with each argument
always having the same meaning. The
MoveMessage in Example 6.7 reads in the expected argument list, then waits for the end-of-message string. ...