Abstract: Recently the Portable Applications Standards Committee of the IEEE Computer Society has published for review a proposed Realtime Distributed Systems Communication Application Program Interface (API) standard designated P1003.21 LIS/V1.0. The objective of this standard is to develop a language-independent specification (LIS) and Ada language binding for interprocess message communication in the realtime distributed systems domain. The standard is specified independently of a specific protocol but includes mappings to existing protocols.
The P1003.21 standard has been specified to meet specific requirements that are considered essential for real time distributed communication. These requirements include support for:
The complete requirements for this standard are published as a separate IEEE report. In addition, a formal definition of the standard has been developed using the Z language and is included as an annex to the standard. Finally, to ensure that the language-independent specification is implementable, prototypes in both Ada and C have been written. These prototypes are available through ftp from the SEI.
The following paragraphs briefly summarize the principal interfaces of the proposed standard in terms of its objects, communication models, and services.
Endpoints are used by applications to send and receive messages and by implementations to identify the source and destination of messages. The scope of a source endpoint is local to its creating process and may be shared among the different threads comprising the process to send/receive messages. In contrast, a destination endpoint is obtained by an application through either a logical name or a protocol-dependent address. Once a destination endpoint has been obtained it can be used as the destination to which messages may be sent.
Messages are the unit of data transfer between one source endpoint and one or more destination endpoints. A message is represented as a sequence of octets and its contents are specified by the application. Associated with each message is a header that is used by the implementation to specify message attributes such as message priority. A label may also be associated with a message by the application; the meaning of such a label is determined by the application.
Logical names are used to identify one or more endpoints. An application may associate a logical name with an endpoint that it has created. This logical name may then be used to obtain an identifier to represent a destination endpoint.
Multicast groups represent sets of endpoints. Associated with each multicast group is a logical name through which an identifier is obtained for use as the destination for sending messages. Applications create and delete multicast groups and manage the joining of endpoints to a group and the leaving of endpoints from a group.
Buffers represent storage areas through which an implementation may provide improved application performance by reducing the frequency with which data is copied in sending and receiving messages. The standard provides for application-controlled buffers and implementation-controlled buffers.
The standard supports four communication models for applications to exchange messages; these are unicast, broadcast, multicast, and message labels. In addition, it allows for a mixture of communication models.
Unicast communication provides for a message to be sent from one endpoint to another endpoint. The sending endpoint must specify the receiving endpoint to which the message is destined using a destination identifier.
Broadcast communication provides for a message to be sent from one endpoint to all endpoints that have registered to receive broadcast messages. The sending endpoint is unaware of the destinations for the message and message delivery status cannot be determined. Applications may register and deregister endpoints to receive broadcast messages. However, the standard does not define the timing conditions that govern the delivery of messages to different endpoints.
Multicast communication provides for a message to be sent from one endpoint to a multicast group. The message is received by all endpoints that have joined the multicast group. The sending endpoint may or may not be aware of the destinations for message delivery depending upon how the application manages its multicast groups. Services are provided by the standard to manage groups and to notify applications when endpoints join or leave a group.
Labeled communication provides for a labeled message to be sent from one endpoint to all endpoints that have registered to receive messages with that label. Similar to multicast communication, the sending endpoint may or may not be aware of the destinations for message delivery depending upon how the application manages labeled messages.
Mixed communication provides for labeled communication to be combined with other communication models. To use mixed communication, endpoints are established for all the desired models by defining the appropriate logical names and groups. A labeled message may then be sent specifying both a destination identifier and a label. In this case the destination identifier is used to select the receiving endpoints and the label is used to filter delivery of the message to those endpoints that have registered to receive messages with that label.
The standard supports a variety of communication services to facilitate the use of the provided communication models.
Directory services allow applications to reference destination endpoints to which messages may be sent using both location-independent and location dependent identifiers. The location-independent identifiers are provided through services that provide for logical names to be associated with endpoints. A minimal interface is specified in the standard to associate an endpoint with a logical name to obtain a destination identifier for a logical name, and to get the logical names associated with an endpoint. The location-dependent identifiers are protocol address references and are supported in the standard by an interface to bind an endpoint to a protocol address, to get the protocol address for an endpoint, and to obtain a destination identifier based upon a protocol address.
Attribute services allow applications to specify the attributes that are to be associated with endpoints and messages. Endpoint attributes are defined through endpoint control blocks and include the following attributes: the transmission mode of an endpoint (i.e., sending, receiving, or sending/receiving); the queueing policy for messages received at an endpoint; the use of buffers to send and receive messages; the reliability of message transfer; and the maximum size of a message that can be sent/received using an endpoint. Message attributes are defined through send control blocks and include the following attributes: the destination identifier; the message length; the message label; the message priority; and the reliability of message delivery.
Asynchronous services allow applications to specify that operations are to be performed asynchronously using an activity control block. An activity control block specifies a timeout for the operation and the form of notification to be performed when the operation completes. For each asynchronous operation, an identifier is returned that allows an application to monitor the progress of the corresponding operation. In addition, an application may use the identifier to wait for the operation to complete or to cancel the operation.
Event services allow applications to be notified of various conditions using an endpoint event queue. Endpoint conditions that cause events to be placed in the queue are: discarding a message when the receive queue is full; losing a connection with a destination endpoint; and changing the composition of a multicast group. Events are queued in fifo order and it is the responsibility of the application to detect and remove an event from the queue.
Protocol services allow applications to gain access and manipulate the attributes of the communication protocols underlying the implementation. In this way endpoints may be bound to protocol-dependent addresses using directory services. The standard provides interfaces to the IP, TCP, and UDP protocols.
Connection services allow applications to establish protocol-dependent connection-oriented data transfer between a sending and receiving endpoint. The services provided include: openning a connection; listening on a connection; accepting a connection; rejecting a connection; closing a connection; and getting the status of a connection.
In addition to the operations provided to support the Communication Services, the standard provides operations for sending and receiving messages.
The standard specifies a separately defined send operation for each communication model. However, each operation follows a consistent form and may be called either synchronously or asynchronously. The parameters to each operation must specify the endpoint from which to send the message, the message length, and the address of the data comprising the message. Two variations of each operation allow the application to provide a send control block either directly or by using a handle to a previously created send control block. The latter variation offers an opportunity for the implementation to optimize sending similarly constructed messages. In addition, an application may use buffers to improve performance, in which case the address of the message data is the address of the buffer where the message data is located. Finally, the different forms of send operations are used to interpret the message destination in the send control block. Namely, the unicast, broadcast, and multicast sends interpret the destination in the send control block as a destination endpoint, constant, and mutlicast group respectively.
The standard specifies a common receive operation for each communication model. Receive operations do not depend upon the form of send operation; they only depend upon the availability of a message to the application at one or more endpoints local to the application. If no message is available at the endpoints, then the receive operation waits until a message is available unless the operation is to be performed asynchronously. Receive operations must specify an endpoint from which to receive a message, an address to locate the message data, and the maximum length of a message. Similar to send operations, receive operations may specify the use of a buffer to locate message data. If a message may be received from multiple endpoints, the endpoint from which the message is received is made available to the application.
The standard provides several simple examples to explain the use of the proposed interface. The following subparagraphs summarize the examples.
This example sends/receives a message to/from the logical name alpha using buffers. The sequence of sending/receiving operations (sn/rn) is as follows:
r1: create an endpoint;
r2: allocate a buffer to locate the inbound messages;
r3: associate the logical name alpha with the endpoint;
r4: wait to receive a message on this endpoint.s1: create an endpoint;
s2: allocate a buffer for outbound messages;
s3: construct the message data in the allocated buffer;
s4: determine a destination identifier for the name alpha;
s5: send the message from the endpoint using the buffer to the destination identifier.
This example sends/receives a message using broadcasting. The sequence of sending/receiving operations (sn/rn) is as follows:
r1: create an endpoint;
r2: register the endpoint to receive broadcast messages;
r3: wait to receive a message in application storage on this endpoint.s1: create an endpoint;
s2: construct the message in application storage area;
s3: send the message using broadcast.
This example sends/receives a message to/from the multicast group beta using buffers. The sequence of sending/receiving operations (sn/rn) is as follows:
s1: create an endpoint;
s2: allocate a buffer for outbound messages;
s3: construct the message data in the allocated buffer;
s4: determine a destination identifier for the multicast group beta; s5: send the message from the endpoint using the buffer to the destination identifier.r1: create an endpoint;
r2: allocate a buffer to locate the inbound messages;
r3: determine a local identifier for the multicast group beta;
r4: join the endpoint to the group using the local identifier
r5: wait to receive a message on this endpoint.
Several important areas have not been addressed in the proposed standard. These include: support for request/response communication such as remote procedure call; support for heterogeneous data transfer so that messages may be exchanged among applications executing on heterogeneous distributed systems; and support for collecting performance data.
The first ballot for this standard was completed on November 15, 1996. The P1003.21 working group is scheduled to meet in January 1997 to resolve any outstanding ballot issues. Currently, it is unknown whether or not the standard will be recirculated for another ballot.
Additional information on the P1003.21 working group may be obtained from the Chairperson Dr. Craig Meyers (bcm@sei.cmu.edu).
Back to the TSC page.