Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Transport Application Programming Interface Extension for Multimedia

IP.com Disclosure Number: IPCOM000111266D
Original Publication Date: 1994-Feb-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 4 page(s) / 128K

Publishing Venue

IBM

Related People

Baugher, M: AUTHOR [+3]

Abstract

Multimedia communications require that many new features be added to our communications transport products, such as IBM NetBios. The established practice in transport Application Programming Interfaces (APIs) is to have a seperate operation for each feature. When applied to multimedia, this practice could result in a dozen new API operations. This article discloses a method whereby only a single new API operation would be a sufficient extension to a transport programming interface for multimedia.

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

Transport Application Programming Interface Extension for Multimedia

      Multimedia communications require that many new features be
added to our communications transport products, such as IBM NetBios.
The established practice in transport Application Programming
Interfaces (APIs) is to have a seperate operation for each feature.
When applied to multimedia, this practice could result in a dozen new
API operations.  This article discloses a method whereby only a
single new API operation would be a sufficient extension to a
transport programming interface for multimedia.

      Many new features are needed in communications transports to
support multimedia.  New connection or session types are needed for
higher performance data transfers, such as unacknowledged
connection-oriented or sequenced connectionless service.  The
connection or session may have a range of quality of service
parameters for throughput and delay guarantees.  Connection or
session quality of service, moreover, may need to change as more or
less bandwidth is needed by the application.  Some APIs require new
buffering alternatives for multimedia.

      A common approach in communications transport APIs is to invent
a new operation for each feature.  In Berkeley sockets, for example,
there are separate connect, listen, send and receive operations for
connection-oriented and connectionless service.  New multimedia
connections include variations on connection-oriented and
connectionless services such as "unacknowledged connection-oriented"
service or its equivalent "sequenced datagram" service.  Thus, we
would need three more operations to accommodate such an extension
using the conventional approach.

      Multimedia connections and sessions often must manage high
volume, time-sensitive transfers.  Many, older transports and their
APIs were not originally designed with the buffer and notification
features that are needed today.  TCP/IP, for example, uses double
buffering in which all sends and receives are copied between user and
system buffers.  For time-sensitive multimedia transfers, it is
probably desirable for the user to use system buffers or for the
system to use user buffers.  Removing this inefficiency will require
yet another option to be associated with the connect operation.

      Multimedia transfers also require Quality of Service (QoS)
guarantees, so provision must be made to pass QoS information across
some API to the transport.  QoS will not necessarily require new
operations since it could be passed in the connection or session
establishment API.  But if the application needs to alter its quality
of service during the session, a new operation would be required to
spare the application of the need to destroy and reestablish the
connection or session.

      It is clear that the existing convention of creating a new
operation whenever there is a new connection or session feature will
prove infeasible for communicatins...