Many applications have a requirement for multidestination delivery.
This has implications for naming and access mechanisms:
-
The targets for multidestination are groups of servers. They may be
providing identical services, or replicated services, or they may be
providing choices of differing but similar services.
-
Some way of choosing which of the group (all or some or one) is needed
at compile and at run time.
-
The groups may be slowly changing (static) or rapidly changing
(dynamic). A Group management scheme is needed.
In an language integrated RPC system, some mechanism for
collecting replies is needed and either mapping them into an array of
results, or providing hooks for voting/selecting a reply. The
different models are illustrated in #fnmsgpat#503>.
Group communications for applications are not well understood. It
would appear that multicast protocols provide a simple packet/message
optimisation, but that they do not simplify real group communications
problems except for the ;SPM_quot;which of;SPM_quot; type query. Many
systems use one to one communication and model groups inside the
application[#birman##1#]. Chapter 3 shows how replicated servers
are built in this way.
#figure505#
Figure: Message Patterns and IPC
In the most gerneral case, you have
both client and server groups. If a server (group) is invoked by a
client group then you also need to have mechanisms for collecting
invocations and determining which invocations belong to which groups
(naming activities).