background image
Bionic Buffalo Tech Note #103: Introduction to Pegasus Client Support
In other words, the client application manipulates remote stream objects on the server.
DSM-CC User-Network. Bionic Buffalo implemented U-N by first defining the U-N services
interfaces in IDL. In a conventional CORBA system, an application communicates with local and
remote service objects by way of the ORB. In Bionic Buffalo's U-N system, the application
communicates with service objects which implement the U-N protocols. The client normally doesn't
see U-N server objects directly, or vice versa. Instead, the remote objects are seen only through the
services of local objects. Thus, Bionic Buffalo's implementation of U-N is similar to that of U-U
implementations which use proxy objects:
application - local U-N object - (U-N protocol) - remote U-N server
(Note: Normally, the application talks to local objects, but because the objects are implemented using
CORBA it is also possible with Bionic Buffalo's product to communicate directly with remote objects.
In other words, it is possible to have application - local ORB - remote ORB - remote U-N object - U-N
protocol - differently-remote U-N server
. This feature isn't expected to find normal use, but rather
value in support and development situations.)
Pegaus Session Setup Protocol. The Pegasus specifications (at least, the SSP and LSCP ones
considered here) define the over-the-wire interaction, but don't define an API for applications. They
define protocols, not objects. To implement SSP and LSCP, Bionic Buffalo uses local and proxy
For SSP, the Pegasus protocol is in fact a dialect of the DSM-CC U-N Session protocol. The model is
the same as used for basic U-N:
application - local object - U-N protocol (SSP dialect) - U-N server
The local objects have been modified slightly from standard DSM-CC objects, to allow for the SSP
dialect. (A modification wasn't, strictly speaking, necessary. However, it makes the API easier to use.)
The same objects, with the same API, can be used for basic U-N, as for the SSP dialect.
Pegasus Lightweight Stream Control Protocol. As with the 
 class, LSCP envisions a
playback engine on the server. Instead of regarding it as an object, however, the LSCP specification
defines a client-server protocol. The playback engine embodies the same state machine as does a
 object, and the messages controlling the playback operation have the same semantics
as those of the corresponding IIOP messages. (However, the Pegasus playback engine lacks some
operations not directly related to playback and the state machine, such as those for access control,
security, and event management. Where Pegasus has equivalent functionality, these are handled in
different ways.) The data formats, such as the one used for time and the time base, are a little different
between Pegasus and DSM-CC. Altogether, the differences are slight enough that the API representing
 interface can be used to control a Pegasus playback engine.
Usually, modification of a Pegasus server is infeasible, so Bionic Buffalo's software uses a client proxy
object to implement LSCP. The model is
Page 7 of 11