Browse Prior Art Database

Buffer System APIs and Implementation for Quality of Service Communications Connections

IP.com Disclosure Number: IPCOM000105530D
Original Publication Date: 1993-Aug-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 4 page(s) / 183K

Publishing Venue

IBM

Related People

Baugher, M: AUTHOR [+3]

Abstract

Certain multimedia application (e.g., those with sound and video) will use computer communications connections which have quality of service (QoS) guarantees; such applications will require a computer memory buffer system which minimizes copying of media packets, offers constant path length for buffer allocation and deallocation, permits system deallocation of user buffers on send operations, and permits user deallocation of system buffers on receive operations. The buffer system described in this article has these properties.

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

Buffer System APIs and Implementation for Quality of Service Communications Connections

      Certain multimedia application (e.g., those with sound and
video) will use computer communications connections which have
quality of service (QoS) guarantees; such applications will require a
computer memory buffer system which minimizes copying of media
packets, offers constant path length for buffer allocation and
deallocation, permits system deallocation of user buffers on send
operations, and permits user deallocation of system buffers on
receive operations.  The buffer system described in this article has
these properties.

      Many communications system interfaces such as Netbios, APPC,
and Sockets, employ a "user buffering style" where the transport
application must supply a buffer for receive as well as for send
operations.

      In "Netbios style" buffering, the transport application
supplies the buffer into which a communication packet is directly
received; there is no additional copy from system (kernel or ring 0)
space to application (user or ring 3) space, but the application and
system share the buffer.  This sharing obviates the need to copy
between user and system buffers but, the interface between user and
system layers is crossed twice for receive operations.

      The "Sockets style" also requires a user buffer for receive
flows, but the incoming packet is initially placed into a system
buffer, and then it is copied into an application-supplied buffer.
"Netbios style" buffering avoids this copy, but has longer path
length since the application must be notified that one or more
buffers are needed, and hundreds of instructions must be executed to
provide the buffer(s) to the receiving communications adapter.
"Sockets style" buffering permits the communications system to
allocate the buffer as soon as the communications adapter indicates
that a receive is in progress.  But "Sockets style" buffering
achieves this reduced path length at the cost of copying the packet
into an application buffer.

      "System style" buffering is optimal for receiving packets:  The
system allocates a buffer immediately following the receive
indication from the communications adapter.  The system adjusts the
buffer appropriately to remove packet header information and returns
the buffer directly to the application (many communications adapters
permit the header to be placed in a separate buffer - this is called
"scatter" capability).  For send flows, the application can use
system-style buffering to get a buffer which the system can
deallocate when the send completes; this saves hundreds of computer
instructions which are expended to notify the application of each
send completion.

      Copying by the buffer system, and long path length are problems
for multimedia applications requiring tight bounds on packet delay
and guaranteed packet throughput.  Copying of packets is prohibitive
for applications such as video commu...