Real-Time CORBA

Last Update October 4, 2000

This documents keeps track of the TAO's Real-Time CORBA Development Status , and a description of the Release Notes for our implementation. For any comment or question on a specific aspect of RT CORBA you can contact the responsible as listed in the Real-Time CORBA Development Status, or you can contact one of us: Marina Spivak, Irfan Pyrali, Angelo Corsaro.

RT Corba Development Status

The scope of this brief document is to keep track of the progress of the RT-CORBA implementation, and to let the user understand what is already in place what will be soon available and what will not be supported. Table 1 contains a detailed list of the features that are described by the RT-CORBA spec. and their status respect to our implementation. Table 2 contains features that are not described in the  RT-CORBA spec. but that are needed to "enable" our RT-CORBA implementation, and at last Table 3 contains a list of issues that should be addressed soon.

Table 1 - Status of the feature described in the RT CORBA Spec.

Real-Time ORB - Extension to the CORBA::ORB interface that provides operations to create and destroy other constituents of a RT ORB.

Real Time POA - RT extension of the traditional POA that provides additional operation to support object level priority and "understand" the RT Policies defined in ptc/99-05-03. This interface is derived from the POA interface so it support all the semantics prescribed for a non RT-POA.

CORBA Priority & Priority Mappings - RT-CORBA Priority have the intent of shielding the user from the different priority scheme that a RTOS might use, providing a uniform representation system wide. RT-CORBA Priority Mappings take care of mapping RTCORBA::Priority into native priorities. Right now to scheme are implemented and respectively the Linear and Direct.

Real-Time Current - The RTCORBA::Current interface is derived from CORBA::Current, and provide access to the CORBA Priority of the current thread. Real Time CORBA Priority can be associated with the current thread by using this interface.

Real-Time CORBA Priority Models - Real-Time CORBA supports two models for the coordination of priorities across a system, that let set the priority at which a servant executes. This two different model are Client Propagated Priority Model and Server Declared Priority Model.

Priority Transforms - Priority Transforms allow the application designer to implement RT-CORBA system using priority models different from either the Client Propagated or Server Declared. Priority Transforms are user provided functions that map one RTCORBA::Priority value to another RTCORBA::Priority value.

Mutex Interface - Real-Time CORBA defines a Mutex interface, and two operation in the RTORB interface for creating and destroying such  mutex. This mutex should have the same priority inheritance scheme used by the ORB.

Thread Pools - Real-Time CORBA define an interface for creating Thread Pools, with or without lanes, and for creating Thread Pools Priorities. Lanes are just sub-sets of threads at assigned different RTCORBA::Priority values. The only feature that won't be supported is the Request Buffering (see sec. 4.10.3).

Implicit & Explicit Binding - Provide control on when a binding is made on a object reference. In particular a call to validate_connection force the binding to an object reference to be made as explicit binding.

 Priority Banded Connections - Real-Time CORBA defines priority bands that are in turn used to serve request depending on the priority model used by the target object.

Private Connection Policy - This policy allows a client to obtain a private transport connection which will not be shared with other client-server connections.

Protocol Configuration - Enables the selection and configuration of the protocols on the client and server side of the ORB.

Table 2 - Feature needed to Enable RT-CORBA

Collocation - A new collocation scheme has been designed and is in its last stage of development. The collocation scheme has been changed because the selection of the right proxy to use to perform a call, now has to be taken on a call-per-call basis, to avoid interference between thread priorities. In designing the new scheme we tried to reduce the memory footprint and the overhead that the new scheme needs to introduce.

Policy Streaming - Different policies defined by the RT-CORBA Spec. need to be exposed to the client by  embeddeding those  into the IOR. This facilities were added to those policies.

Invocation Timeout - Allows the setting of timeout that expire if an invocation doesn't complete in a given amount of time.

Table 3 - Issue to be shortly addressed

Factoring of TAO's Protocol Policies -

Profile Management - The Profile management is right now quite nasty. The class interface are pretty counter-intuitive, and the code that deal with profile needs to be redesigned and re-implemented.

RT CORBA Example Test - Examples and Tests need to be written to show how to use  RT CORBA's features, and to massively test the behavior of the new stuff.

Performance - Performance tests needs to performed on TAO to see the impact of the changes and to early individuate critical path and bottlenecks.

Release Notes

We are currently working on implementing RT CORBA 1.0 specification in TAO. Our design is an extension of the endpoint-per-priority architecture mentioned in the Recently Completed Work section below. In this design, codenamed reactor-per-lane, each threadpool lane owns a set of I/O resources, i.e., Reactor, Acceptor, and Connector_Registry. Each request is serviced by a single thread without context switches, i.e., the same thread performs I/O and runs the servant code.

Below there is a list of feature recently added to TAO, and in also a brief description of the main feature that characterize certain feature related to our implementation of RT-CORBA.

• Client Protocol Policy.

• Priority Banded Connections.

• TAO's RTCORBA Documentation web pages.

• POA Threadpools & SERVER_DECLARED Priority Model.

• CLIENT_PROPAGATED Priority Model.

• Server Protocol Policy.

• RTORB, RTCurrent and ProrityMappingManger interfaces.

• Support for client-exposed policies.

• All RTCORBA, Policy and POA interfaces converted to local.

• Collocation-related classes are restructured to support RTCORBA.

• Implemented Policy framework (defined in the Messaging specification, used in RT CORBA).

• Added support for Real-time CORBA Priority and implemented two Priority Mappings: Linear and Direct.

• Added support for end-to-end CORBA request priority preservation. This is achieved through multiple listening endpoint architecture, a.k.a. endpoint-per-priority, on the server and a Client Priority Policy on the client. Following is a brief description of how this is implemented.

  Server ORB uses multiple transport endpoints to accept connections from clients. Each transport endpoint has a priority, which is the priority of the thread(s) servicing the endpoint as well as all connections it accepts. When a server ORB creates an IOR for one of its objects, it embeds all of the server's listening endpoints along with their priorities into the object's IOR. Then, a client ORB selects the priority that best matches client's need (as specified by the Client Priority Policy) from those offered by the server, and uses the corresponding transport endpoint specified by the server to obtain the desired level of service.

  For more details and performance results for endpoint-per-priority architecture, see this paper. See TAO/tao/TAO.pidl for Client Priority Policy interface definition, and TAO/tests/Endpoint_Per_Priority for example of using priority preservation in TAO.

   

• Implemented reliable one-way requests, i.e., SyncScope Policy from the Messaging specification. This is relevant to RT CORBA because of the following feature: setting SyncScope Policy to SYNC_NONE enables buffering of one-way requests in the client ORB. Request buffering can be used to optimize message throughput, possibly at the expense of latency. ORB buffering behavior is controlled by the Buffering Constraint Policy, which is described next.

• Added support for buffered one-way and asynchronous requests in the client ORB. Buffering Constraint Policy gives users control over queueing and flushing of requests in the ORB. A combination of the following conditions for initiating buffer flush can be specified using this policy:

  • Timeout value expires.

  • Max byte count is exceeded.

  • Explicit flush by the user.

  • Max message count is exceeded, or

  • ORB shutdown.

  Also supported are out-of-band requests, i.e., requests that bypass buffers and are delivered to the server immediately.

  Buffering Constraint Policy is a TAO-specific feature. See TAO/tao/TAO.pidl for policy interface definition and TAO/examples/Buffered_Oneways and TAO/examples/Buffered_AMI directories for its use. For motivation and performance of buffered one-ways see this paper.

Known issues:

• Location forwarding does not work properly with endpoint-per-priority model.

Future work:

• Provide server-side RT CORBA implementation using a queue-per-lane approach. In this approach each threadpool lane owns a queue, while I/O resources are being shared among all the threadpool lanes of the same priority within the server. Strategize TAO to use either queue-per-lane or reactor-per-lane implementation, and compare the two.