A Multicast Datagram Network Service in Wide Area Networks
is a relatively new technique based on forming host groups
and enhancing routers to form special purpose forwarding
information bases to these groups. This is mainly so that
the number of copies of packets sent to replicated services
may be reduced to near optimum in the same manner as on
networks with a physical broadcast technology (e.g.
Satellite and Ethernets). [#mospf##1#] [#dvmrp##1#]
Multi-media conferencing is an application that often
involves more than two end systems, and could take advantage
of a multicast network service. However, multimedia systems
often employ application level distribution. For instance,
the voice portion of a conference is often sent by each
participant to a central mixing service, which then sends
the mixed portion to each member. To be optimally placed for
each client, the mixing server may well be pessimally placed
to use multicast to redistribute the mixed voice, compared
with a forest of multicast trees rooted at each sender, or
rooted at each destination group.
With the video portion of
a conference, it is often quad multiplexed by CODECs (video COder DECoder), in a
similar manner to audio mixing, or else bandwidth
requirements preclude anyone but the floor holder of a
conference being visible.
Clients of Replicated Databases distribute the same updates
and retrieve the same records from more than one copy of the
service and could also make use of a multicast network
service. However, many transaction systems involve 2 or 3
phase commit protocols with each server in the replicated
system for writing (although for reading, a majority read
may suffice - however we need to know what the majority is).
In this note we examine the snares and delusions that must
be avoided when a multicast application uses a multicast
network service. In particular, we distinguish between the
savings of using a multicast system for data packet
replication and the overheads in establishing and
maintaining group membership and group reachability.
In this case, there are two modes that could make use of
In the CAR experimental platform, shared
applications can be either collaboration transparent
Conference discovery can either use multicast to
construct a conference finding service, or can use
that as an optimisation between a real directory system
and the application. All conference instance will be
stored in the directory and local ones cache at the
conference finding deamon. Conference finding request
will always be sent out on a local multicast address.
Local conference will then return using the cache result
at the conference finding deamon. Non local conference
then lookup the real directory using DAP (Directory Access Protocol).
In the next section, we briefly examine a centralised architecture
for multimedia collaboration. Then we study in turn the use
of multicast support for shared windows, audio, video and
A multicast ;SPM_quot;rwho;SPM_quot; that the conference service cache the result.
We can also use this to find out the people we can conference
Do a multicast to find out about the user when needed.
Stations that has multimedia conference capabilities can
then join the multicast group. Alternatively, only users
that wants to be found will join the multicast group.