Browse Prior Art Database

Object-Oriented Remote Dispatch for a Client/Server Implementation

IP.com Disclosure Number: IPCOM000118321D
Original Publication Date: 1996-Dec-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 4 page(s) / 162K

Publishing Venue

IBM

Related People

Tulkoff, MC: AUTHOR [+2]

Abstract

Disclosed is a design for an asynchronous, remote dispatcher. The components of the system consist of individual objects and may be customized. The implementation is in two parts: a client part, which is bound to an application process, and a server part, which handles command processing, as well as individual task execution. This is known as a client/server implementation. The application sends commands to what appears to be a local object. This design makes use of a user configuration file to switch the local object at runtime to a proxy object with the same interface as the original object. This new proxy object will then dispatch the applications commands to the server. The proxy object will also handle any data transfers as well.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 33% of the total text.

Object-Oriented Remote Dispatch for a Client/Server Implementation

      Disclosed is a design for an asynchronous, remote
dispatcher.  The components of the system consist of individual
objects and may be customized.  The implementation is in two parts: a
client part, which is bound to an application process, and a server
part, which  handles command processing, as well as individual task
execution. This  is known as a client/server implementation.  The
application sends commands to what appears to be a local object.
This design makes use of a user configuration file to switch the
local object at runtime to a proxy object with the same interface as
the original object.  This new proxy object will then dispatch the
applications commands to the server.  The proxy object will also
handle any data transfers as well.

      Disclosed is a method for the management of independent clients
sending real-time audio data to a server.  The server is used for
resource sharing, arbitration, and special tasks such as audio
mixing.  To accommodate the requirements that the solution remain
transparent to the applications and that the audio Application
Processor Interface (API) remains standardized, a modified remote
dispatch model is used in this solution.  This remote dispatch model
is asynchronous, persistent, and maintains a session layer.  The
model is ideal for the distribution and processing of real-time audio
data.  This solution is designed to run in an AIX* (or UNIX**)
environment where the server is implemented as a UNIX daemon process
and the clients communicate with the server via UNIX domain sockets
in the case of multiple processes on a single machine or Transmission
Control Protocol/Internet Protocol (TCP/IP) domain sockets in the
case of a network.

      The client/server system is made of of separate building blocks
called objects.  There is a class definition of a server, a device
client, and of the communications layer of the system.  These class
definitions have implementations as well that may be used to form
unique applications.  IBM has so far implemented an audio mixer using
these standard objects.  The class definitions are also available for
users to inherit from and create different or more powerful
implementations for applications.  In other words, the solution is
modular and any of the main modules may be replaced.

      The first object is the device client object.  This code is
meant to be bound with the audio application.  The application
expects to interface with an audio device object and knows nothing
about the distributed scheme.  Therefore, the client device object
inherits its interface from the audio device class that is defined in
the multimedia  framework being used.  In the current implementation
of this design, the framework is IBM's Ultimedia Services for AIX*
(UMS).

      Now that the audio interface is consistent, there must be a
scheme to attach this implementation t...