Remote invocation of stream controls

Stream control requires the receiver to send a message to the media server, asking it to perform some action. There may or may not be some response. This paradigm of request/response over a network has been well-known for many years, and has been formulated as a remote procedure call or rpc.

In a remote procedure call, the remote server offers a selection of procedures that the local machine can call. These calls are labelled in a unique fashion across the server. When the local machine wishes to make a call, the calling program constructs a packet which references the label on the remote server, adds any arguments to the call encoded in a machine independent format, and sends the packet to the server. The server receives the packet, routes the request to the appropriate bit of code and unpacks the arguments so that they can be understood and executes the request. If there are any return values, or any error responses, these are packed into a packet and sent back to the sender. The strength of rpc mechanisms lay in the fact that the code to construct the packets at the local machine, and demultiplex and deconstruct the arguments at the server can be automatically generated from descriptions of the procedures that are similar to programming languages with which progrmamers are already familiar, such as C. The canonical reference for rpc is the work by Birrell and Nelson from Xerox PARC in [#!birrell84:_implem_remot_proced_calls!#]. The most widely used rpc system has probably been the sun rpc system, whilst every vendor with an interest in providing network solutions has some variation upon rpc, such as DCOM from Microsoft, the Java RMI system and the DCE rpc system.

Most projects which have designed networked multimedia systems have used an rpc system to build the stream controls. An influential project was Pandora out of Cambridge. This work pioneered the use of ATM type systems to deliver real-time media such as audio and video, but also used RPC mechanisms to implement the network controls.

Rpc systems make life very simple for the application programmer, and for the conceptually simple controls for a media stream, they would seem to provide an ideal solution. However, as ever, there are a few problems.

Rpc mechanisms are intended to support the networking of heterogeneous machines, but there is no widespread rpc system available across all platforms. CORBA provides a generic object-oriented technology for integrating operating systems, and is seen by many to be the key integrating technology. Currently, CORBA technology is costly, but increasing use should see its use by more than major corporations.

Using rpc mechanisms makes defining the control interfaces easy. However there remain some subtleties in interpreting the precedence of control requests. What happens if a number of play requests are sent - should they be queued? How then should the streams be interrupted if the requests are queued? How should the server track the current state of the stream? There is the need for a small stateful protocol at the server to deal with the ordering of play and pause requests Inherent in controlling streams of data remotely is the necessity to keep state at the server about the requests that have been made. Requests must have an associated sequence number, so that the server can service the incoming requests in the correct order, despite any re-ordering that may occur.

If a client requests the transmission of a stream, the server has to return some identifier to the client so that this stream can be distinguished from others. The mapping between this identifier and the stream is held both on the server and on the client and can be the source of major difficulties in designing a complete solution. The problem comes in deciding what happens when the state is lost at either the client or the server. If the state is lost at the server, then the server can no longer associate control requests with the outgoing stream. If the client loses state, then it will not be able to generate control requests for the stream. If the stream consumes many resources, then this may be disastrous, since a long lived stream which no one is using, and which is uncontrolled is just a resource hog, and may block other legitimate uses.

Solutions to the problem rely on either being able to recreate the state (discussed elsewhere as the ``soft-state'' approach WHERE IS THIS DISCUSSED), or in ensuring that the protocol is fail-safe, whereby unless control is continuously asserted, the stream stops.