Academia.eduAcademia.edu

A distributed object platform for multimedia applications

1999, Proceedings IEEE International Conference on Multimedia Computing and Systems

Abstract

Although distributed object computing has developed rapidly over the past decade, and is now becoming commercially important, there remain key application areas inadequately supported by current standards and implementations. This paper describes research aimed at support for one of these areas: distributed soft real-time/ multimedia applications. The approach is to provide a low level platform which offers generic middleware services useful for the implementation of a range of multimedia capable distributed object systems. The design of the platform is influenced on the one hand by the real-time/ multimedia-oriented computational model of the RM-ODP and on the other hand by recent research results in the efficient engineering of communications systems and operating systems. The platform provides support for quality of service (QoS) and application specific protocols as required by multimedia capable distributed object systems. A novel scheme for flexible QoS specification and management is described. A performance evaluation of the platform is given and a sample application program is presented to illustrate the platform's API. Keywords: distributed object computing, distributed multimedia, CORBA, quality of service.

Key takeaways

  • In GOPI, individual ASPs are responsible for defining a schema for QoS specification and for mapping QoS specifications expressed using this schema into low level GOPI resources (primarily threads, buffers and transport service access points or TSAPs).
  • As explained above, the representation of QoS is transparent to GOPI and is viewed and mapped only within individual ASPs.
  • The ASP's connection management calls are able to make decisions as to resource availability by mapping the given ASP specific QoS parameters to primitive resource interfaces (i.e. threads, buffers and TSAPs) provided by the lower level modules of GOPI.
  • • the order in which the threads doing the recv() system call get to run is determined by the deadline of the thread as determined by the QoS of its associated binding; thus GOPI is able to avoid processing low urgency messages when high urgency messages are available;
  • It would be possible to adapt GOPI to use IO notification on a selectable, per TSAP, basis (presumably selected by a QoS parameter defined by ASPs for which rapid response to events was an issue) to take advantage of the benefits of IO notification without paying the overall performance penalty.