Browse Prior Art Database

Automatic Interface Re-Activation

IP.com Disclosure Number: IPCOM000104703D
Original Publication Date: 1993-May-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 2 page(s) / 76K

Publishing Venue

IBM

Related People

Edel, TR: AUTHOR [+3]

Abstract

This paper discusses the specification of an interface that remains in effect until it is overridden by its re-specification or cancellation. This is especially useful in a data transfer/data communication environment where the overhead in re-activating an interface is of significance and also where the retransmission of data occurs in a high traffic situation because there is no outstanding receive for the transmitted data.

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

Automatic Interface Re-Activation

      This paper discusses the specification of an interface that
remains in effect until it is overridden by its re-specification or
cancellation.  This is especially useful in a data transfer/data
communication environment where the overhead in re-activating an
interface is of significance and also where the retransmission of
data occurs in a high traffic situation because there is no
outstanding receive for the transmitted data.

      Application signalling and data transfer between end points in
a data communication environment is initiated by informing the
communication system of a desire to accept or transmit information
from/to specified partner(s).  This is accomplished by utilizing an
interface  provided by the communication system.  For Receive type
operations, the parameters of the communication interface are very
often constant between successive invocations.  The  following
categories of communication exhibit characteristics for invarient
parameters:

o   An interface to a Listen function indicates to the communication
    subsystem that the requester is willing to monitor/accept
    connection requests from anyone that wishes to communicate with
    the application that requested the Listen function.

o   The corollary of the Listen function is the Receive Connection
    which is a confirmation for the Connect request that satisfied
    the outstanding Listen.

o   An interface to a Receive Data function that indicates to the
    communication subsystem that the requester is willing to accept
    data transfer requests from partners that wish to communicate
    with the application invoking the Receive Data function.  For
    stream or message mode connections, the size of the  data
    transfer  usually remains the same between repeated data transfer
    iterations.

o   An interface to a Receive Data Transmission Error function that
    indicates to the communication subsystem that the requester is
    willing to accept error information associated with previously
    sent connectionless data units.  The solution for Receive type
    functions that are constant between success...