Beruflich Dokumente
Kultur Dokumente
Abstract
Support of end-to-end Quality-of-Service (QoS) and
appropriate high-level programming abstractions are two
crucial factors for the development of future telecommunication services and distributed multimedia systems.
Todays middleware systems, like the Common Object
Request Broker Architecture (CORBA), support high-level
programming abstractions, but they do not appropriately
support the demands from soft realtime and multimedia
applications. We develop a flexible and adaptable middleware that supports a broad range of QoS requirements of
distributed multimedia applications. In this paper, we
present design, implementation, and preliminary performance evaluation of our first prototype. We have extended
the object and message layer of the CORBA implementation COOL with QoS support by (1) enabling QoS specifications for method invocations, (2) integrating bilateral
QoS negotiation between client and server, and (3) implementing a simple unilateral QoS negotiation between message layer and transport layer in the Object Request
Broker (ORB). In the transport layer of COOL, we have
integrated Da CaPo to flexibly support the various QoS
requirements. Our work demonstrates that it is possible to
support QoS with minor changes in GIOP and the use of a
QoS supporting transport protocol.
On a first glance, it seems that the necessary technology is already commercially available. Asynchronous
Transfer Mode (ATM) networks offer high bandwidth and
(guaranteed) QoS to higher layer protocols. Furthermore,
implementations of the distributed object-oriented middleware standard Common Object Request Broker Architecture (CORBA) from the Object Management Group
(OMG) provide high-level programming abstractions.
However, nearly all CORBA implementations (e.g.,
IONAs Orbix and Inprises VisiBroker) are based on the
communication protocols TCP/IP. It is well known that
these transport and network layer protocols do not support
QoS. To make things worse, CORBA does not support
QoS at the object level, and multimedia streams are not
integrated in the Object Request Broker (ORB).
In the MULTE (Multimedia Middleware for LowLatency High-Throughput Environments) project, we contribute to the solutions of these problems by designing,
implementing, and evaluating flexible and adaptable middleware systems that support a broad range of QoS
requirements, e.g., low latency, high throughput, and controlled delay jitter. We use IPv4 and IPv6 over traditional
155 Mbit/s ATM and 2.4 Gigabit/s ATM technology developed at the Washington University St. Louis, and the next
generation internet protocols IPv6 and RSVP (Resource
Reservation Protocol) to provide network QoS. Above the
network layer, a flexible (re)configurable protocol system
replaces the traditional protocols, e.g., TCP and GIOP
(General Inter-ORB protocol), and represents the core element in the MULTE middleware. A flexible protocol system allows dynamic selection, configuration and
reconfiguration of protocol modules to dynamically shape
the functionality of a protocol to satisfy specific application requirements and/or adapt to changing service properties of the underlying network. The basic idea of flexible
end-to-end protocols is that they are configured to include
only the necessary functionality required to satsify the
Object
Impl.
Client
Stubs
Skeletons
Object Adapter
GIOP,
COOL Protocol
Notification
Generic Transport Protocol Layer
TCP/IP,
Chorus IPC
Related Work
There are several research activities in the area of endto-end QoS support in distributed multimedia systems. We
concentrate our discussion of related work on OMG activities and QoS support in middleware.
OMG has defined an architecture for multimedia
streams called OMG A/V Streams [16] based on CORBA,
with a similar approach to IMA MSS [12][13]. The data
flow takes place over separate channels outside the ORB
core/computational model. OMG A/V Streams only define
a limited set of interfaces, especially the control and management interfaces for streams. The Real-Time CORBA
specification (RT-CORBA) [17] addresses how the ORB
ensures end-to-end predictability with respect to priority
propagation, threading schemes, explicit binding, and protocol policies and configurations. Explicit binding is used
according to the CORBA Messaging specification [18].
Protocol policies guide in RT-CORBA the selection of
protocols, and the configuration of the protocol is depending on the flexibility and nature of the protocol. The configurable properties for TCP in RT-CORBA include send
and receive buffer sizes, keep alive, and do not route.
There is no way to reconfigure protocols after binding
time in RT-CORBA.
There is a considerable amount of research on end-toend QoS support. Main concern in most of these
approaches is appropriate resource management. A survey
of these so-called QoS architectures can be found in [1]. In
contrast, flexible protocol approaches put main emphasis
on the adaptation of protocol functionality to support the
requested QoS and to increase protocol performance by
4.1
QoS Specification
Traditionally, QoS is related to a particular type of service, namely associations, like transport connections or
virtual circuits in ATM. A certain QoS is specified and
negotiated for an association and the negotiated QoS is
valid for the lifetime of the association, if not re-negotiated. In the context of object-oriented middleware, there is
no directly corresponding notion of such a service.
Objects, bindings, method invocations, and even parame-
QoS per method invocation: each method invocation is marshaled in a single Request message
and the result is returned in a single Reply message. These messages are transported over one
transport connection and can easily be associated
with QoS. However, subsequent method invocations with different QoS require renegotiation of
the transport connection. Furthermore, all parameters in a method will have the same QoS.
Never call setQoSParameter: no QoS support is required and standard GIOP can be used.
Call setQoSParameter: each method invocation will be supported (if possible) according to
the QoS requested in the last setQoSParameter call. By calling setQoSParameter only
once in the beginning of a binding, a per binding
QoS will be supported, and setting QoS before
each method invocation results in QoS per
method.
In order to allow QoS specification for method invocations, we have modified the COOL IDL compiler, called
Chic, because it is necessary to generate stubs that handle
the QoS specification. Chic uses template files to generate
stub source files during compilation of the IDL definitions. These template files are modified by adding the
method setQoSParameter(struct QoSParameter** qp) in the stub. The client uses this method to
specify QoS requirements in an array of QoSParameter
structures (see Figure 2-ii) and communicates it to the stub
by calling the method. The stub handles the propagation of
these QoS requirements to the message and transport layers in the ORB.
Calling the setQosParameter method transforms
the implicit binding between the client and the object
implementation on the server side to a explicit binding.
This explicit binding is controlled by the client application
when specifying requirements.
4.2
Extensions in GIOP
char magic[4];
Version GIOP_version;
boolean byte_order;
Client
Client
Server
GIOP Request
with QoS parameters
Server
GIOP Request
with QoS parameters
octet message_type;
unsigned long message_size;
GIOP Reply
NACK
};
enum MsgType { // GIOP messages
Request,
(i)
(ii)
Reply,
CancelRequest,
LocateRequest,
LocateReply,
CloseConnection,
MessageError
};
Client
IDL stub
GIOP
send
message
transport
receive
unmarshal QoS
messsage and method
string operation;
sequence<QoSParameter> qos_params;
// only field added
1
handle
request
marshal results
Principal requesting_principal;
};
send
message
Object
Impl.
1
establish
connection
IDL
skeleton
request
connection
with QoS
marshal QoS
and method
IOP::ServiceContextList service_context;
boolean response_expected;
GIOP
setQoSPar.
inv. method
};
struct RequestHeader {
// the only GIOP message modified
Transport
Layer
unmarshal
results
method call
returns
receive
messsage
transport
4.3
5.1
Da CaPo Overview
Layer C
Application
Configuration
management
Connection
management
Resource
management
Modules
Module
Graph
Management
Runtime
Environment
Layer T
Transport Infrastructure
Management
Shared
memory
Message queue
with pointers to
packets
Module with thread
Message queues
Module with thread
Network
_ChorusComChannel
COOL_InputCallback
_TcpComChannel
_dlink
_TcpBuffer
_DacapoComChannel
_ChorusComManager
COOL
Protocol
Chorus
IPC
Da CaPo
(ii)
Da CaPo
(i)
_ComManager
_TcpComManager
_dlist
_DacapoComManager
implemented
in
notify: asynchronous replies is handled by calling notify, which calls a registered procedure
to receive the reply.
cancel: to terminate the waiting for an asynchronous reply, cancel is called with the appropriate request message as parameter.
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
Acknowledgements
We thank Ragnvald Blindheim for his work on design
and implementation of the object and message layer extensions.
References
[1] Aurrecoechea, C. Campbell, A., Hauw, L.: A Survey of
Quality of Service Architectures, Technical Report, Lancaster University, MPG-95-18, 1995
[2] Blindheim, R.T.: Extending the Object Request Broker
COOL with flexible Quality of Service Support, Master
Thesis, University of Oslo, Center for Technology at Kjeller
(UniK), Oslo, Norway, February 1999
[3] Chorus Systems: Requirements for a Real-Time ORB,
ReTINA, Technical report RT/TR-96-8, May 1996.
[4] Chorus Systems: CHORUS/COOL-ORB r3 Runtime
Class Description, CSI/TR-96-36.1, August 1996
[5] Chorus Systems: COOL Internet Inter-ORB Protocol,
CS/TR-96-161.2, January 1996
[6] Coulson, G.: A Configurable Multimedia Middleware Platform, IEEE Multimedia, Vol. 6, No. 1, January-March
1999, pp. 62-76
[7] DIMMA Team: DIMMA Design and Implementation,
ANSA Phase III, Technical Report APM.2063.01, September 1997
[8] Dumant, B., Dang Tran, F., Horn, F., Stefani, J.-B.:
Jonathan: an Open Distributed Procesing Environment in
Java, Proceedings of Middleware98: IFIP International
Conference on Distributed Systems Platforms and Open
[17]
[18]
[19]
[20]
[21]
[22]
[23]