 |
Claims  |
|
|
What is claimed is:
1. A computer-implemented message passing method for a computer system
having a processing trait and a memory wherein a plurality of client
tasks, a plurality of server tasks and a message passing unit reside, each
client task comprising a sequence of program instructions that require a
service, each server task comprising a sequence of program instructions
capable of providing a service, the message passing unit comprising a
sequence of program instructions that manages the transfer of messages
between client tasks and server tasks, each client task, each server task,
and the message passing unit executable by the processing unit, the
message passing method comprising the steps of:
creating a plurality of message object data structures with the message
passing unit, each message object data structure corresponding to a type
of service provided by at least one server task within the plurality of
server tasks, each message object data structure serving as a message
destination from the perspective of a client task within the plurality of
client tasks and to which a client task within the plurality of client
tasks issues a send message request for the purpose of requesting a
particular type of service be performed upon a message;
creating a port object data structure with the message passing unit, the
port object data structure associated with the plurality of message data
structures, the port object data structure corresponding to a receptacle
for messages directed to each message object data structure within the
plurality of message object data structures and to which each server task
within the plurality of server tasks issues a receive message request for
the purpose of polling for a message;
issuing a send message request with a first client task within the
plurality of client tasks, the send message request including a reference
to a first message and a reference to a message object data structure
within the plurality of message object data structures;
receiving the send message request with the message passing unit;
transferring the first message to the port object data structure with the
message passing unit;
polling the port object data structure with a first server task within the
plurality of server tasks; and
transferring the first message to the first server task with the message
passing unit.
2. The method of claim 1, wherein the step of transferring the first
message to the port object comprises the steps of:
generating a unique message identification signal with the message passing
unit;
creating a send message control block with the message passing unit, the
send message control block corresponding to the message identification
signal, the send message control block storing the reference to the first
message; and
storing a reference to the send message control block in a data field of
the port object with the message passing unit.
3. The method of claim 2, further comprising the steps of:
determining with the message passing unit whether the send message request
specifies that execution of the first client task by the processing unit
is to be temporarily prevented; and
preventing execution of the first client task with the message passing unit
until the first server task has issued a reply corresponding to the
message identification signal.
4. The method of claim 2, wherein the step of transferring the first
message to the first server task comprises the steps of:
determining with the message passing unit whether the first server task has
issued a receive message request that matches the send message control
block; and
issuing a signal to the first server task with the message passing unit to
initiate a service corresponding to the send message request in the event
that the receive message request matches the send message control block.
5. The method of claim 4, further comprising the steps of:
creating a receive message control block associated with the receive
message request with the message passing unit if the receive message
request does not match the send message control block; and
storing a reference to the receive message control block in a data field of
the port object with the message passing unit.
6. The method of claim 5, further comprising the steps of:
determining with the message passing unit whether the receive message
request specifies that execution of the first server task by the
processing unit is to be temporarily prevented; and
preventing execution of the first sever task with the message passing unit
until a send message control block that matches the receive message
request has been created.
7. The method of claim 4, further comprising the step of transferring reply
information to the first client task with the message passing unit in
response to the first server task issuing a reply corresponding to the
message identification signal.
8. The method of claim 2, further comprising the steps of:
storing a reference to an acceptance function in a data field of the port
object with the message passing unit, the acceptance function comprising a
sequence of program instructions capable of providing a service within a
memory address space associated with at least one client task within the
plurality of client tasks;
determining with the message passing unit whether the send message control
block matches the acceptance function; and
if the send message control block matches the acceptance function, issuing
a signal to the acceptance function with the message passing unit to
initiate a service corresponding to the send message request.
9. A computer-implemented means for passing messages between a plurality of
server tasks and a plurality of client tasks within a computer system
having a processing unit and a memory, the means for passing messages
comprising:
means for creating a plurality of message object data structures, each
message object data structure corresponding to a type of service provided
by at least one server task within the plurality of server tasks, each
message object data structure serving as a unique message destination from
the perspective of a client task within the plurality of client tasks and
to which a client task within the plurality of client tasks issues a send
message request for the purpose of requesting a particular type of service
be performed upon a message;
means for creating a port object data structure associated with the
plurality of message data structures, the port object data structure
corresponding to a receptacle for messages directed to each of its
associated message object data structures and to which each server task
within the plurality of server tasks issues a receive message request for
the purpose of polling for a message;
means for transferring a first message associated with a first client task
within the plurality of client tasks to the port object data structure;
and
means for transferring the first message from the port object data
structure to a first server task within the plurality of server tasks.
10. The system of claim 9, further comprising:
means for generating a unique message identification signal in response to
the generation of a send message request by the first client task;
means for creating a send message control block corresponding to the
message identification signal, the send message control block storing a
reference to the first message;
means for determining whether a receive message request generated by the
first server task matches the send message control block; and
means for issuing a signal to the first server task to initiate a service
corresponding to the send message request.
11. The system of claim 9, further comprising a means for issuing a signal
to an acceptance function associated with the port object to initiate the
performance of a service within a memory address space associated with the
first client task.
12. The system of claim 9, further comprising a means for transferring
reply information to the first client task in response to a reply issued
by the first server task.
13. An object oriented message passing system for passing messages between
a plurality of client tasks and a plurality of server tasks, the object
oriented message passing system comprising:
a memory having an input and an output for storing data and commands, the
memory including an object management unit for creating a port object data
structure and a plurality of message object data structures associated
with the port object data structure, the port object data structure
corresponding to a message receptacle to which a sever task within the
plurality of server tasks issues a receive message request for the purpose
of polling for a message, each message object data structure corresponding
to a type of service provided by the server task, each message object data
structure serving as a message destination from the perspective of a
client task within the plurality of client tasks and to which a client
task within the plurality of client tasks issues a send message request
for the purpose of requesting a particular type of service be performed
upon a message, the memory additionally including an object database for
storing the port object data structure and each message object data
structure, and a message transaction unit for matching a send message
request issued by a client task within the plurality of client tasks with
a receive message request issued by a server task within the plurality of
server tasks, each of the object management unit and the message
transaction unit comprising program instructions that form a portion of a
computer operating system; and
a processing unit having an input and an output, for processing data and
executing commands under control of program instructions stored in the
memory, the input of the processing unit coupled to the output of the
memory, and the output of the processing unit coupled to the input of the
memory.
14. The method of claim 1, wherein the object oriented message passing unit
forms a portion of a microkernel operating system.
15. A computer-readable medium storing program instructions for performing
the steps of:
creating a plurality of message object data structures with a message
passing unit, each message object data structure corresponding to a type
of service provided by at least one server task within a plurality of
server tasks, each message object data structure serving as a message
destination from the perspective of a client task within the plurality of
client tasks and to which a client task within a plurality of client tasks
issues a send message request for the purpose of requesting a particular
service be performed upon a message;
creating a port object data structure with the message passing unit, the
port object data structure associated with the plurality of message data
structures, the port object data structure corresponding to a receptacle
for messages directed to each message object data structure within the
plurality of message object data structures and to which each server task
within the plurality of server tasks issues a receive message request for
the purpose of polling for a message;
receiving a send message request issued by a first client task, the send
message request including a reference to a first message and a reference
to a message object data structure within the plurality of message object
data structures;
transferring the first message to the port object data structure with the
message passing unit; and
transferring the first message to a first server task with the message
passing unit in response to the first server task polling the port object
data structure. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to systems and methods for
intra-computer communication, and more particularly to systems and methods
for message-based client-server communication. Still more particularly,
the present invention is an object oriented message passing system and
method.
2. Description of the Background Art
In intra-computer communications, a client task requires a service provided
by a server task. For example, a client task may require window creation
or file deletion services. The particular service that the client task
requires is performed by an appropriate server task, such as a window
manager or a file system. A message is the unit of communication
interchange between a client and a server. Thus, in order to inform a
server that a particular service is required, the client task sends or
issues an appropriate message. Upon receiving an issued message, the
server task performs the required actions. Message passing systems and
methods determine the manner in which a message that has been issued by a
client task is delivered to a server task.
In the prior art, message passing systems and methods have relied upon a
task-based message passing model, a port-based message passing model, or a
port-set-based message passing model. Referring now to FIG. 1, a block
diagram of a task-based message passing model is shown. In the task-based
message passing model, when a client task requires a particular service,
the client task sends a message directly to a server task that performs
types of services related to the particular service required. Because
multiple client tasks may require a service provided by the same server
task, each server task present must support message queuing and message
dispatch, both of which introduce an undesirable level of server task
complexity. Moreover, because server tasks must support message queuing
and message dispatch, memory beyond that required to implement a set of
services must be available to each server task. An additional drawback
associated with the task-based message passing model is that a client task
and a corresponding server task are bound together in an inflexible
manner, with each server task being dedicated to only one type of service.
The inflexible binding found in the task-based message passing model also
introduces an undesirable level of complexity when the behavior of the
client task or the server task is to be modified or evolved.
Referring now to FIG. 2A, a block diagram of a port-based message passing
model is shown. In the port-based message passing model, a message port
represents a type of service available to a client task. Client tasks send
messages to message ports rather than directly to server tasks. Messages
sent to a given message port are queued within the message port by the
operating system. Thus, to a server task, each message port represents a
message queue. Multiple server tasks can compete to receive and process
messages from any message port, thereby decoupling client tasks from
server tasks. Client tasks commonly require many different types of
services; hence, multiple message ports are required. Each message port
requires a significant amount of memory to implement. Some prior art
operating systems require that a unique port be present for each client
task present.
Within a computer system, a message passing system generally resides within
an operating system, which in turn resides within the computer system's
memory. The total amount of memory available in the computer system is
limited, and the memory must therefore be treated as a shared resource. It
is thus highly desirable to have an operating system that occupies as
little memory as possible. Message passing systems and methods that are
based upon the port-based message passing model are undesirable because
the memory required to implement each port significantly adds to the
operating system's memory requirements. In personal computer systems, less
memory is typically available than in other computer systems. Hence,
message passing systems and methods that rely upon the port-based message
passing model are particularly undesirable in personal computer systems.
Commonly, client tasks and server tasks function in different address
spaces. In prior art message passing systems and methods that rely upon
the port-based message passing model, when a client task and a server task
operate in different address spaces, the message passing system or method
must perform a mapping between address spaces prior to transferring a
message from the client task to the server task. After the mapping between
address spaces has been performed, the server task performs the required
service. Often, particular services, such as input/output (I/O)
operations, must be performed as rapidly as possible. The mapping between
address spaces performed by prior art message passing systems and methods
that rely upon the port-based message passing model undesirably increases
the amount of time required to complete the service. Thus, prior art
systems and methods that rely upon the port-based message passing model
are undesirable in time-critical situations when client tasks and server
tasks function in different address spaces.
Referring now to FIG. 2B, a block diagram of a port-set-based message
passing model is shown. The port-set-based message passing model is a
variant of the port-based message passing model described above. In the
port-set-based message passing model, one or more message ports are
associated to form a common port set. Each port set represents a
particular type of service, and each individual message port represents a
particular resource that can utilize the service associated with the port
set to which it belongs. Client tasks therefore view individual message
ports as resources to which messages can be sent. The additional level of
structural granularity provided by the port-set-based message passing
model significantly simplifies message decoding and message prioritization
operations that must be performed by server tasks. As in the case of the
port-based message passing model, however, each message port requires a
significant amount of memory to implement. Therefore, message passing
systems and methods that rely upon the port-set-based message passing
model require even more memory than those that rely upon the port-based
message passing model. Prior art message passing systems and methods that
rely upon the port-set-based message passing model also suffer from the
address space translation drawbacks described above in relation to the
port-based message passing model.
What is needed is a means for message passing that provides a high level of
structural granularity, that minimizes memory requirements, and that can
reduce the time required to perform time-critical operations when client
tasks and server tasks function in different address spaces.
SUMMARY OF THE INVENTION
The present invention is an object oriented message passing system and
method. The system of the present invention comprises an object oriented
message passing unit. The object oriented message passing unit creates and
maintains a set of message objects and one or more port objects. Each
message object is associated with a particular port object, and each
message object represents a resource that corresponds to a service
provided by a server task. Each port object represents a message
receptacle from which a server task can receive messages. Message objects
require significantly less memory to implement than port objects. Through
the use of message objects and port objects, the present invention
provides an object-oriented message passing model that exhibits a high
level of structural granularity and that requires significantly less
memory than any message passing model supported in the prior art.
The object oriented message passing unit associates an acceptance function
with a port object upon request, where the acceptance function provides a
means for performing one or more services within the context and address
space of the client task. Acceptance functions significantly reduce the
amount of time required to complete time-critical services by eliminating
the need for mapping between address spaces and context switching.
A client task sends a message to a message object by issuing a send message
request that includes a reference to a message object, a reference to a
message, and a message type. The message referenced in the send message
request itself indicates a required service. A server task receives a
message from a port object by issuing a receive message request that
includes a reference to a port object and a message type. In response to a
send message request, the object oriented message passing unit creates a
corresponding send message control block (MCB), where the send MCB
includes the reference to the message. After creating the send MCB, the
object oriented message passing unit first attempts to match the send
message request with an acceptance function. If a matching acceptance
function is present, the object oriented message passing unit ensures that
the message referenced in the send MCB is transferred to the acceptance
function. The acceptance function then performs the required service
within the context and address space of the client task. If no matching
acceptance function is present, the object oriented message passing unit
matches the send message request to a receive message request. The object
oriented message passing unit ensures that the message referenced in the
send MCB is transferred to the server task that issued the receive message
request, and provides any required mapping between address spaces. After
the server task has received the message, the server task performs the
required service.
Once an acceptance function or a server task has performed a required
service, the acceptance function or the server task, respectively,
preferably issues a reply to the message. The issuance of a send message
request, followed by the matching of a send message request to an
acceptance function or to a receive message request, followed by the
issuance of a reply is referred to herein as a message transaction. In
response to a reply, the object oriented message passing unit performs
reply operations that deliver status information and possibly data to the
client task that initiated the message transaction.
The object oriented message passing unit locks and unlocks message objects
upon request. After a message object is locked, send message requests
directed to the message object are not eligible to be matched to an
acceptance function or to a receive message request until the message
object is unlocked. Message object locking and unlocking provide a means
to guarantee that a parameter value associated with a given message object
remains unchanged while a message transaction is in progress.
The method of the present invention comprises the steps of: creating a port
object; creating a message object associated with the port object;
optionally associating an acceptance function with the port object;
matching a send message request directed to the message object with the
acceptance function or with a matching receive message request; matching a
receive message request directed to the port object with a send message
request; and performing reply operations following a server task's reply
to a message.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a task-based message passing model of the
prior art;
FIG. 2A is a block diagram of a port-based message passing model of the
prior art;
FIG. 2B is a block diagram of a port-set-based message passing model of the
prior art;
FIG. 3 is a block diagram of a preferred embodiment of the object oriented
message passing system constructed in accordance with the present
invention;
FIG. 4 is a block diagram of a preferred embodiment of an object oriented
message passing unit in the system of the present invention;
FIG. 5 is a block diagram of an object oriented message passing model
provided by the system of the present invention;
FIG. 6 is a block diagram of a preferred embodiment of a message object;
FIG. 7 is a block diagram of a preferred embodiment of a port object;
FIG. 8A is a block diagram of a synchronous send message control block in
the present invention;
FIG. 8B is a block diagram of an asynchronous send message control block in
the present invention;
FIG. 9A is a block diagram of a synchronous receive message control block
in the present invention;
FIG. 9B is a block diagram of an asynchronous receive message control block
in the present invention;
FIG. 10 is a block diagram of a delivery message control block in the
present invention;
FIGS. 11A and 11B are a flowchart of a preferred object oriented message
passing method in accordance with the present invention;
FIGS. 12A, 12B, and 12C are a flowchart of a preferred method for
responding to a send message request in the present invention;
FIGS. 13A and 13B are a flowchart of a preferred method for responding to a
receive message request in the present invention;
FIG. 14 is a flowchart of a preferred reply method in the present
invention;
FIG. 15 is a flowchart of a preferred method for responding to a lock
request in the present invention; and
FIG. 16 is a flowchart of a preferred method for responding to an unlock
request in the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Referring now to FIG. 3, a block diagram of a preferred embodiment of an
object oriented message passing system 10 constructed in accordance with
the present invention is shown. The system 10 comprises a processing unit
12, an input device 14, an output device 16, an external storage device
18, and a memory 20 wherein an operating system 30, a client task 32, and
a server task 34 reside. In the preferred embodiment, the operating system
30 is a microkernel operating system 30 capable of maintaining multiple
address spaces. An object oriented message passing unit 40 resides within
the operating system 30. Each element of the system 10 has an input and an
output coupled to a common system bus 29. In an exemplary embodiment, the
system 10 of the present invention is an Apple Macintosh computer system
made by Apple Computer, Inc., of Cupertino, Calif., and having a Motorola
MC68030 microprocessor and 8 Mbytes of Random Access Memory (RAM) wherein
a microkernel operating system 30 that includes the object oriented
message passing unit 40 resides.
In the present invention, a client task 32 is preferably a set of program
instructions that requires a given service, for example, the creation of a
window or the deletion of a file. The provider of a required service is
referred to herein as a server task 34. Preferably, each server task 34 is
also a set of program instructions. In the preferred embodiment, a given
server task 34 can function as a client task 32 when the given server task
34 itself requires a particular service that is performed by another
server task 34. The microkernel operating system 30 preferably maintains a
task context for each client task 32 and each server task 34 in a
conventional manner, where the task context is a set of data structures
and information specific to the client or server task 34, 34 with which it
is associated. The microkernel operating system 30 also preferably
associates with each client task 32 and with each server task 34 an
address space specifying a set of memory addresses accessible to the
client task 32 and server task 34, respectively. Each address space
preferably includes a microkernel-accessible address area that is common
to all address spaces. A complete description of an exemplary microkernel
operating system 30 and the functionality provided by the present
invention is given in Appendix A.
The object oriented message passing unit 40 facilitates communication
between client tasks 32 and server tasks 34. Referring now to FIG. 4, a
block diagram of a preferred embodiment of the object oriented message
passing unit 40 of the present invention is shown. The object oriented
message passing unit 40 comprises an object management unit 42, a message
transaction unit 44, a locking unit 46, and an object database 48. Each
element of the object oriented message passing unit 40 has an input and an
output coupled to the common system bus 29. In the preferred embodiment,
the object oriented message passing unit 40 comprises computer program
steps that are selectively executed by the processing unit 12.
The object management unit 42 creates and maintains data structures in the
object database 48 that provide a client task communication interface
between client tasks 32 and the object oriented message passing unit 40,
and that provide a server task communication interface between server
tasks 34 and the object oriented message passing unit 40. Through the
client task communication interface and the server task communication
interface, the object management unit 42 provides an object oriented
message passing model 50. Referring now to FIG. 5, a block diagram of a
preferred object oriented message passing model 50 provided by the present
invention is shown. In the preferred object oriented message passing model
50, one or more message objects 52 form the client task communication
interface, and one or more port objects 54 form the server task
communication interface. Each message object 52 is associated with at
least one client task 32. The set of client tasks 32 associated with a
given message object 52 are referred to herein as a client team 33. Each
message object 52 represents the behavior of a resource that is under the
control of a given server task 34, and preferably reflects how client
tasks 32 use a particular service provided by the server task 34. To
invoke the behavior associated with a given message object 52, a client
task 32 sends a message to the message object 52 by issuing a send message
request, where each send message request specifies a message and a message
type. The send message requests will be described in more detail below.
In the preferred object-oriented message passing model 50, each port object
54 serves as a receptacle for messages directed from client tasks 32 to
message objects 52 that are associated with the port object 54. Server
tasks 34 receive messages from a port object 54 by issuing receive message
requests as will be described in more detail below. After receiving a
given message, a server task 34 implements the behavior associated with
the message object 52 to which the message was sent, according to details
supplied in the message itself. The server task 34 then issues a reply to
the given message that the client task 32 sent, where the reply provides
the client task 32 with status information and possibly data. Herein, the
sending of a given message by a client task, followed by a server task's
receipt of the given message, followed by the server task's reply to the
given message is referred to as a message transaction.
Referring now to FIG. 6, a block diagram of a preferred embodiment of a
message object 52 is shown. The object management unit 42 creates a
message object 52 and generates a unique message object identification
(ID) in response to a server task's issuance of a message object creation
request. The message object creation request preferably includes a
reference constant specifying an initial state of the message object 52; a
reference to a given port object 54 with which the message object 52 is to
be associated; and a client team ID specifying a set of client tasks 32
with which the message object 52 is to be associated. Within each message
object 52, a first data field stores the message object ID generated by
the object management unit 42 that uniquely identifies the message object
52; a second data field stores the reference constant supplied by the
server task, where the reference constant corresponds to the initial state
of the message object 52; a third data field references the given port
object 54 indicated in the message object creation request; a fourth data
field specifies the client team ID included in the message object creation
request; and a fifth data field references a next message object 52
associated with the given port object 54. The object management unit 42
does not assign a value to the fifth data field until a next message
object 52 has been created.
Referring now to FIG. 7, a block diagram of a preferred embodiment of a
port object 54 is shown. The object management unit 42 creates a port
object 54 and generates a unique port object ID in response to a port
object creation request from a server task 34. In the port object 54, a
first data field specifies a next port object and a previous port object.
The object management unit 42 therefore links port objects 52 together via
their respective first data fields. A second data field in the port object
54 provides a list of those message objects 52 that are associated with
the port object 54. When the object management unit 42 creates a new
message object 52, the object management unit 42 adds the corresponding
new message object ID to the list in the second data field of the port
object 54 with which the newly created message object 52 is associated. A
third data field in the port object 54 provides a list of each associated
message object 52 that has been "locked" in response to a lock request.
When a given message object 52 is locked, any send message requests issued
by client tasks 32 and directed to the given message object 52 are not
available to be received by a server task 34 until unlocking operations
have been performed. Message object locking and unlocking operations are
performed by the locking unit 46 and will be described in detail below.
In the port object 54, a fourth data field is used to store a pending send
message list that specifies those message that client tasks 32 have sent
to a message object 52 associated with the port object 54, but that have
not yet been received by a server task 34. A fifth data field in the port
object 54 is used to store a pending receive message list that specifies
those receive message requests that have been issued to the port object 54
by server tasks 34, but that have not yet been matched to a corresponding
message sent by a client task 32. A sixth data field in the port object 54
is used to store a pending reply message list that specifies each message
that server tasks 34 have received but for which a reply has not yet been
issued. When the object management unit 42 creates the port object 54, the
fourth, fifth, and sixth data fields are empty. As will be described
below, the lists stored in the fourth, fifth, and sixth data fields are
maintained by the message transaction unit 44.
A seventh data field in the port object 54 optionally specifies an
acceptance function. The acceptance function comprises a set of
instructions that directly implements a subset of services provided by a
server task 34 within the task context of a client task 32. The acceptance
function uses the microkernel-accessible address area that is common to
the address space of the client task 32, and therefore effectively
functions within the address space of the client task 32. Acceptance
functions thus eliminate the need for context switching and mapping
between address spaces. Performance of a given service via an acceptance
function therefore requires much less computational time than performance
of the same service via a server task 34. Acceptance functions provide a
means for minimizing the amount of time required to perform time-critical
operations. The seventh data field in the port object 54 also specifies a
set of message types for which the acceptance function is capable of
providing a service. Preferably, the seventh data field is empty when the
object management unit 42 first creates the port object 54. The object
management unit 42 stores or registers a reference to an acceptance
function and the set of message types in response to a server task
registration request that identifies a particular acceptance function and
the set of message types.
In an exemplary situation in which acceptance functions might be used
beneficially, disk input/output (I/O) operations may require services
provided by a first server task 34 associated with a file system. The
first server task 34 may selectively require particular services provided
by a second server task 34 associated with a disk driver, which may in
turn selectively require particular services provided by a third server
task 34 associated with a small computer systems interface (SCSI) manager.
If the second server task 34 and the third server task 34 issue
appropriate registration requests, the object management unit 42 will
register an acceptance function for the second server task 34 and an
acceptance function for the third server task 34, respectively. Those disk
I/O operations that require the particular services corresponding to the
acceptance functions registered will occur within the task context and
within the address space of the first server task 34, eliminating the need
for mapping between address spaces and context switching. This in turn
will greatly reduce the time required to perform these disk I/O
operations.
In the preferred embodiment, client tasks 32 can send messages
synchronously or asynchronously. In a like manner, server tasks can issue
message receive requests synchronously or asynchronously. Synchronous and
asynchronous operations will be described in more detail below. An eighth
data field in the port object 54 specifies an amount of storage available
for messages sent asynchronously, and a ninth data field in the port
object 54 specifies an amount of storage available for asynchr | | |
