Although IO has thus far been solely described as a point-to-point IPC mechanism, it is quite possible to use IO for multi-casting.
Of course, the operating system has to know about it. And the simplest way to add appropriate OS support is to generalize the concept of system servers into a system groups of servers. In other words, the OS should allow one to define a single name for a group of servers, and to add this name to the file/device/server name space.
When a prospective client opens an I/O port to a group of servers, the ``request to become a client'' message is sent to every server in the group, as are all subsequent messages sent via the port. In other words, the client automatically multi-casts to the server groups. Of course, the multiple replies received by the client present something of a problem.
One solution is to discard all but one of the replies (treating the others as though they are duplicates introduced by the network). For many multi-casting applications, this may be perfectly acceptable, and one would expect the OS to allow this approach, particularly since it makes multi-casting transparent to the client.
However, it should also be possible to use multi-casting in applications where the client needs to receive and process all the replies. This can be made possible, simply by adding an option to IO that would allow the client to set up a list of receive buffers when making the request. The client would then use multiple calls to Complete-IO or Try-to-complete-IO in order to receive the multiple replies.
Note that the semantics outlined here for the purpose of multi-casting can also be used to implement streaming (non-handshaked) protocols on top of IO: Several messages can be sent from a port without needing a ``handshake'' reply for each, and several messages can be received at a port without needing a ``handshake'' request for each. ``Handshaked'' request-reply interaction is merely the natural way of using IO, not the only way.
Prof Herman Venter