One of the requirements of distributed multimedia applications is to support group communication, and to effectively fulfil this condition the framework should also support multicast connections. Not only does this allow more efficient distribution of broadcast-style continuous metadata through lower duplication, it also increases the flexibility with which the framework can direct and combine flows from one node to others, simplifying the mechanism for richer functionality in filter chains.
4.4.1
Sources, Flows, and Presentation Points
While the media and metadata sources themselves remain largely unchanged, when the data they produce is output into the framework it is transmited using multicast flows. A source will send a particular media or metadata flow to any number of filter nodes or presentation points simultaneously, where all the nodes recieving the flow are members of a multicast group. In a live broadcast or group presentation environment all the nodes receiving a flow require the same (media or meta) data at the same point in time, so the use of multicast simplifies the management of the data transfer and makes more efficient use of the network. If a node wishes to start receiving a flow it can join the relevant multicast group - there is no need to allocate and set up a new point-to-point unicast flow. Since metadata must be delivered with a high degree of reliability (section 4.1), the framework now has a requirement for some form of reliable multicast (section 2.2.3).
In the case of a single presentation point requesting a flow there is no inherent advantage in using a multicast connection rather than point-to-point, although even in this scenario communication between filter nodes may be better served by multicast, since several secondary processing nodes could receive the multicast
output of a single filter earlier in the chain.
4.4.2
Filters
To receive a metadata flow from another filter or source, a filter node only has to join the multicast group that flow is being sent to. In turn the filter can easily transmit its output to many other filters or presentation points using the same mechanism. This use of multicast can create a much more sophisticated web of interrelated filter chains available to presentation points; it is much simpler for a node to join or branch a filter chain without duplicating the resources before it. Multicasting filters also increases the scalability of the processing service offered by each node. For example, in a live video broadcast a hypermedia server may identify relevant sections of the picture using image processing techniques. It would be an inefficient use of both the hypermedia server and network resources for the many clients who receive the video stream to query the server
individually; using the framework the hypermedia server only processes the video once, then the results are multicast through a metadata flow to as many
presentation points as requested.
4.4.3
Control
In many ways expanding the distribution of framework flows (from one-to-one to one-to-many) is simplified through the use of multicast. To receive a flow (from a source or filter) a presentation point or filter can just join the multicast group the flow is being transmitted on; this is a much more elegant solution than maintaining state about multiple point-to-point links both for the whole framework, and for individual nodes.
Other facets of control inevitably become more complex with the introduction of group communication. A single source or filter can be expected to control the flow of media or metadata to many other nodes, and any control messages to or
from these nodes regarding stalling, restarting, and jumping to new points in a flow must be dealt with.
Since a flow is inherently temporal, with a limited period of validity, a node might request a timing re-alignment of continuous metadata which cannot be accomodated by the current instanciation of the filter chain - the flow is time shifted beyond what can be compensated for by buffering. If this offset is not required by all the nodes being fed data from a filter or source, it will need to branch the flow: the original stream will continue, but a new additional flow must be initiated in alignment with the requested epoch.
A forked flow of continuous metadata, while derivative and processed by an identical function (at any one filter node), is independently transmitted through the framework and should be considered a new and separate flow. When a subsequent filter chain is constructed branched metadata should be available for inclusion in the same way as for any other flows.
Considering again the two control dissemination mechanisms (section 4.3.4, above):
1. Control messages sent directly to the source can easily and efficiently be propagated to later nodes in the chain using multicast, in parallel with the flow of continuous metadata. This is particularly effective if the control signal has common relevance to all filters and presentation points, for example a video clip being replayed to a distributed class or meeting. However, if the message is only intended to modify the flow received by a small number nodes at the end of a chain, the mechanism must allow leading nodes to ignore the directive whilst forwarding it on.
2. Control messages sent from a presentation point or filter to the
immediately preceeding node are more suitable if the result of the request is a fork in the chain by way of initiating a new flow (because of larger than buffer size difference). How a node contstructs this flow will be application and implementation dependent, which will determine whether control
message are propagated upstream.