This page is not a tutorial on Real-Time CORBA, but is
rather a supplement to the specification, covering all
implementation-specific details. Sample code exercising
RTCORBA features can be found in
$TAO/tests/RTCORBA/
. We hope to have
tutorial-style examples available in the near future.
In order to use features from the Real-Time CORBA 1.0
specification in TAO, a RT-CORBA client application must link
with the RTCORBA library; a RT-CORBA server application must
link with the RTCORBA library and the RTPortbaleServer
libraries. Since some features in RT-CORBA depend on the
messaging specification, all code must be compiled with
TAO_HAS_CORBA_MESSAGING
set to 1
. This
macros are defined in $TAO/tao/orbconf.h
By default, both Real-Time CORBA and Messaging are enabled
in TAO unless Minimum CORBA support is turned on,
i.e., TAO_HAS_MINIMUM_CORBA
is set to
1
.
TAO provides three Priority Mappings: Direct, Linear, and Continuous. If no mapping is specified, Direct Priority Mappings will be used. Note that Continuous was previously referred to as Direct.
$TAO_ROOT/tao/RTCORBA/Linear_Priority_Mapping.cpp
for more details.Priority mappings implement the rules for mapping CORBA priority range (from 0 to 32767) into the native OS priority range and vice versa. However, in some operating systems, the the native OS priority range depends on the scheduling policy being used. That's why when specifying a priority mapping, scheduling policy must be specified as well. Below, we describe how to configure TAO to use a particular priority mapping and scheduling policy. Note, in some operating systems super user privileges are required for use of some of the scheduling policies.
By default TAO uses Direct priority mapping and
SCHED_OTHER
scheduling policy. There are two ways
for an application to override these settings:
svc.conf
file can be used to select a mapping
and a scheduling policy the ORB will use. (This method
does not allow the specification of user-defined
mappings.) Config file should contain the following
options:
static RT_ORB_Loader "-ORBPriorityMapping
mapping_type -ORBSchedPolicy
sched_policy"
where valid values for mapping_type are
linear
and direct,
and valid values
for sched_policy are SCHED_OTHER
,
SCHED_FIFO
and SCHED_RR
.
Obtaining Priority Mapping Manager:
object = orb->resolve_initial_references
("PriorityMappingManager");
TAO::PriorityMappingManager_var mapping_manager
=
TAO::PriorityMappingManager::_narrow (object.in
());
Overriding priority mapping/policy in effect with another ORB-defined mapping/policy combination:
#include
"tao/RTCORBA/Linear_Priority_Mapping.h"
#include
"tao/RTCORBA/Direct_Priority_Mapping.h"
...
RTCORBA::PriorityMapping *pm =
new TAO_Linear_Priority_Mapping (policy);
or
new TAO_Direct_Priority_Mapping (policy);
mapping_manager->mapping (pm);
...
where policy is SCHED_OTHER, SCHED_FIFO
or
SCHED_RR.
Priority Mapping Manager takes the
ownership of the priority mapping object.
Overriding the default with user-defined priority mapping:
My_Mapping *foo = new My_Mapping;
mapping_manager->mapping (foo);
where My_Mapping must inherit from
RTCORBA::PriorityMapping (a typedef for
TAO_Priority_Mapping class) located in
$TAO/tao/Priority_Mapping.h
Obtaining a pointer to the priority mapping object being used by the ORB:
RTCORBA::PriorityMapping *pm =
mapping_manager->mapping ();
Mapping manager retains the ownership of the priority
mapping object.
Real-Time CORBA 1.0 does not specify ORB defaults for the policies it defines, leaving it up to implementations. Below is a summary TAO defaults.
Policy | Default |
---|---|
ServerProtocolPolicy | All protocols that are loaded by the ORB by default (e.g., IIOP) and any explicitly specified by the user (e.g., SHMIOP), in the order they were loaded, with their default properties. See Protocol Policies section for more details. |
ClientProtocolPolicy | None |
ThreadpoolPolicy | None. If no ThreadpoolPolicy policy is specified during POA creation, the default thread-pool will be used for that POA. |
PriorityModelPolicy | None |
PriorityBandedConnectionPolicy | None |
PrivateConnectionPolicy | None |
Priority Mapping |
Direct mapping with SCHED_OTHER scheduling
policy. See Priority
Mappings section for more details.
|
The table below lists all possible configurations of policies involving priorities, and summarizes the semantics of each configuration.
Configuration | Valid values | Semantics |
---|---|---|
Threadpool with lanes, no PriorityModelPolicy, no PriorityBandedConnectionPolicy |
Invalid. | None. |
Threadpool with lanes +SERVER_DECLARED model,no PriorityBandedConnectionPolicy |
Server_priority attribute of the PriorityModelPolicy must be equal to the priority of one of the threadpool lanes. (Same goes for priorities of all the objects registered with the target POA). | All processing is done at the servant's priority. |
Threadpool with lanes +CLIENT_PROPAGATED model,no PriorityBandedConnectionPolicy |
Priority of the invoking client thread must be equal to the priority of one of the threadpool lanes. | All processing is done at the client-propagated priority. |
Threadpool with lanes + PriorityBandedConnectionPolicy, no PriorityModelPolicy |
Invalid. | None. |
Threadpool with lanes +SERVER_DECLARED model +PriorityBandedConnectionPolicy |
Server_priority attribute of the PriorityModelPolicy must be equal to the priority of one of the threadpool lanes. (Same goes for priorities of all the objects registered with the target POA). In addition, each of the priority bands must cover at least one of the threadpool lane priorities. | All processing is done at the servant's priority. |
Threadpool with lanes +CLIENT_PROPAGATED model +PriorityBandedConnectionPolicy |
Priority of the invoking client thread must fall into one of the priority bands. In addition, each of the priority bands must cover at least one of the threadpool lane priorities. | All processing is done at the threadpool lane priority which matches the priority band used by the client. |
Threadpool without lanes, no PriorityModelPolicy, no PriorityBandedConnectionPolicy |
All valid CORBA priorities. | All processing is done at the threadpool's default priority. |
Threadpool without lanes +SERVER_DECLARED model,no PriorityBandedConnectionPolicy |
All valid CORBA priorities. | Request I/O and demultiplexing processing is done at the threadpool's default priority. Application level processing is done at the servant's priority. |
Threadpool without lanes + CLIENT_PROPAGATED
model,no PriorityBandedConnectionPolicy |
All valid CORBA priorities. | Request I/O and demultiplexing processing is done at the threadpool's default priority. Application level processing is done at the client-propagated priority. |
Threadpool without lanes + PriorityBandedConnectionPolicy, no PriorityModelPolicy |
Invalid. | None. |
Threadpool without lanes +SERVER_DECLARED model +PriorityBandedConnectionPolicy |
Server_priority attribute of the PriorityModelPolicy must fall into one of the priority bands. (Same goes for priorities of all the objects registered with the target POA). | Request I/O and demultiplexing processing is done at the threadpool's default priority. Application level processing is done at the servant's priority. In this case, PriorityBandedConnectionPolicy is used to restrict the allowed priority values for the servant. |
Threadpool without lanes +CLIENT_PROPAGATED model +PriorityBandedConnectionPolicy |
Priority of the invoking client thread must fall into one of the priority bands. | Request I/O and demultiplexing processing is done at the threadpool's default priority. Application level processing is done at the client-propagated priority. In this case, PriorityBandedConnectionPolicy is used to restrict the allowed priority values for the client. |
Object::_validate_connection ()
method establishes a
connection, if one doesn't already exist, and verifies policy
overrides for the invoking thread/ its priority/ target
object combination. To establish all connections ahead of
time, application must call _validate_connection ()
for allthread/ priority/ object combinations
that will be used.
In addition to TCPProtocolProperties defined by the Real-Time CORBA specification, TAO provides configurable properties for each protocol it supports. Below is a summary of all protocol properties available in TAO.
Protocol ProfileId: 0
Transport properties interface name:
RTCORBA::TCPProtocolProperties (standard)
Implementation class name: TAO_TCP_Properties
Protocol Properties Attribute | Default Value |
---|---|
long send_buffer_size |
ACE_DEFAULT_MAX_SOCKET_BUFSIZ
|
long recv_buffer_size |
ACE_DEFAULT_MAX_SOCKET_BUFSIZ
|
boolean keep_alive (not yet supported) |
1
|
boolean dont_route (not yet supported) |
0
|
boolean no_delay |
1
|
Protocol ProfileId: 0x54414f00U
Transport properties interface name:
RTCORBA::UnixDomainProtocolProperties
(TAO-specific)
Implementation class name:
TAO_Unix_Domain_Properties
Protocol Properties Attribute | Default Value |
---|---|
long send_buffer_size |
ACE_DEFAULT_MAX_SOCKET_BUFSIZ
|
long recv_buffer_size |
ACE_DEFAULT_MAX_SOCKET_BUFSIZ
|
Protocol ProfileId: 0x54414f02U
Transport properties interface name:
RTCORBA::SharedMemoryProtocolProperties
(TAO-specific)
Implementation class name: TAO_SMEM_Properties
Protocol Properties Attribute | Default Value |
---|---|
long preallocate_buffer_size | not yet supported |
string mmap_filename | not yet supported |
string mmap_lockname | not yet supported |
Real-Time CORBA 1.0 does not define how protocol properties are created. TAO_Protocol_Factory class can be used to create default ProtocolProperties for a particular protocol given its ProfileId:
class TAO_Protocol_Properties_Factory
{
public:
static RTCORBA::ProtocolProperties*
create_transport_protocol_property (IOP::ProfileId
id);
static RTCORBA::ProtocolProperties*
create_orb_protocol_property (IOP::ProfileId
id);
};
Alternatively, concrete ProtocolProperties implementation classes can be instantiated directly as needed.
The table below summarizes how protocol policies overrides affect protocol selection and configuration in TAO.
Policy | ORB default | Override levels that have impact on protocol selection | Override levels that have impact on protocol configuration |
---|---|---|---|
ServerProtocolPolicy | All protocols loaded into the ORB, in the order they were loaded. |
ORB POA |
ORB (If no protocol properties are specified at the ORB level, default protocol configurations are used.) |
ClientProtocolPolicy | None |
ORB Current Object |
ORB (If no protocol properties are specified at the ORB level, default protocol configurations are used.) |
NOTE: -ORBSndSock
and -ORBRcvSock
ORB
options have no effect when RTCORBA is enabled.
Protocol policies do not depend on any other Real-Time CORBA features and can be used alone. In fact, we plan to make protocol policies available outside RTCORBA, and better integrate them with the Pluggable Protocols framework in the near future.
Though the RT-CORBA specification details the real-time ORB, thread priorities, and application scheduling requirements, it is less explicit about the communication transport and the underlying network priorities. Our research involved using Differentiated Services technology to prioritize the RT-CORBA traffic in the network. This effort required two essential enhancements to the TAO ORB. First, we provided an efficient and flexible way of setting the DSCP codepoints in the data packets, which is done by extending the ORB protocol properties. DSCP codepoints can dynamically change, based on many factors like QoS feedback received from external QoS monitoring resources or even a change in the application policy. Second, we provide a mechanism to map the RT-CORBA priorities to the Diff-Serv network priorities. The detials of the implementation follows.
The TCP protocol properties interface was extended to add a flag, enable_network_priority. When this flag is set to 1 the RTCORBA priority is mapped to network priority (diffserv codepoint - DSCP) and this priority is set on the GIOP requests and replies. When the flag is not set no network priorities are set on the GIOP requests and replies and are hence best effort.
local interface TCPProtocolProperties :
ProtocolProperties
{
attribute long send_buffer_size;
attribute long recv_buffer_size;
attribute boolean keep_alive;
attribute boolean dont_route;
attribute boolean no_delay;
attribute boolean
enable_network_priority;
};
Support was added for mapping RTCORBA priority to Network Priority. It is similar to the RTCORBA to native thread priority mapping.
typedef long NetworkPriority;
native NetworkPriorityMapping;
RTCORBA::TCPProtocolProperties_var
tcp_properties =
rt_orb->create_tcp_protocol_properties
(send_buffer_size,
recv_buffer_size,
1, //keep alive
0, //don't route
1, //no delay
enable_network_priority);
RTCORBA::ProtocolList protocols;
protocols.length (1);
protocols[0].protocol_type = 0;
//IIOP
protocols[0].transport_protocol_properties
=
RTCORBA::ProtocolProperties::_duplicate
(tcp_properties.in ());
protocols[0].orb_protocol_properties
=
RTCORBA::ProtocolProperties::_nil
();
CORBA::PolicyList policy_list;
policy_list.length (1);
policy_list[0] =
rt_orb->create_client_protocol_policy
(protocols);
ORB Level - This implies that the tcp protocol properties set will apply to every invocation made with this ORB.
CORBA::Object_var object =
orb->resolve_initial_references
("ORBPolicyManager");
CORBA::PolicyManager_var policy_manager
=
CORBA::PolicyManager::_narrow
(object.in ());
policy_manager->set_policy_overrides
(policy_list,
CORBA::SET_OVERRIDE);
THREAD Level - This implies that the tcp protocol properties set will apply to all the invocations made in the corresponding thread only. All other invocations will have the TCP protocol properties set at the ORB level.
orb->orb_core ()->policy_current
().set_policy_overrides (policy_list,
CORBA::SET_OVERRIDE);
OBJECT Level - This implies that the tcp protocol properties set will apply to the invocations made on the corresponding object only.
CORBA::Object_var object =
server->_set_policy_overrides
(policy_list,
CORBA::SET_OVERRIDE);
server = Test::_narrow (object.in ());
//server is the CORBA Object
The above steps can be applied repeatedly to create and set TCP protocol properties on the client to enable/disable network priority on the GIOP requests. Since the TCP protocol properties are updated per invocation the most recently set policy will apply.
RTCORBA::TCPProtocolProperties_var
tcp_properties =
rt_orb->create_tcp_protocol_properties
(send_buffer_size,
recv_buffer_size,
1, //keep alive
0, //don't route
1, //no delay
enable_network_priority);
RTCORBA::ProtocolList protocols;
protocols.length (1);
protocols[0].protocol_type = 0;
//IIOP
protocols[0].transport_protocol_properties
=
RTCORBA::ProtocolProperties::_duplicate
(tcp_properties.in ());
protocols[0].orb_protocol_properties
=
RTCORBA::ProtocolProperties::_nil
();
CORBA::PolicyList policy_list;
policy_list.length (1);
policy_list[0] =
rt_orb->create_server_protocol_policy
(protocols);
CORBA::PolicyList poa_policy_list;
poa_policy_list.length (1);
poa_policy_list [0] =
rt_orb->create_server_protocol_policy
(protocols);
PortableServer::POA_var poa_with_ds
=
root_poa->create_POA
("POA_WITH_DS",
poa_manager.in
(),
poa_policy_list
);
All the servants that want network priority set on their replies should register with this POA.
NOTE - The POA policy can be set only once.
This implies that all replies sent from the POA
that has the network priority set will have the
DSCP set on them. In order to unset the network
priority one has to use a different POA without
the network priority set on it.
The RTCORBA to network priority mapping framework is similar to the RTCORBA to native thread priority mapping framework. As mentioned in section 2.1.2 this is implemented by providing the native interface NetworkPriorityMapping. The native interface is implemented in the RTCORBAC.h as:
typedef TAO_Network_Priority_Mapping
NetworkPriorityMapping;
Where TAO_Network_Priority_Mapping is
defined as:
class TAO_Network_Priority_Mapping
{
public:
virtual CORBA::Boolean to_network
(RTCORBA::Priority corba_priority,
RTCORBA::NetworkPriority &network_priority)
= 0;
virtual CORBA::Boolean to_CORBA
(RTCORBA::NetworkPriority
network_priority,
RTCORBA::Priority &corba_priority) =
0;
};
The methods to_network (…) and to_corba (…) can be implemented differently for different mapping algorithms that can be defined by the application.
TAO implements the default Linear Mapping from RTCORBA to Diffserv Codepoint mapping. Further mappings may be added to TAO. The application can choose these TAO supported mappings through the Service Configurator (svc.conf) files with the following entry:
static RT_ORB_Loader "-ORBSchedPolicy SCHED_FIFO -ORBScopePolicy PROCESS -ORBPriorityMapping direct -ORBNetworkPriorityMapping Linear"
A NetworkPriorityMappingManager is defined in TAO to manage the Network Priority Mapping.
typedef
TAO_Network_Priority_Mapping_Manager
NetworkPriorityMappingManager;
Where TAO_Network_Priority_Mapping_Manager
is:
class TAO_RTCORBA_Export
TAO_Network_Priority_Mapping_Manager :
{
public:
TAO_Network_Priority_Mapping_Manager
(RTCORBA::NetworkPriorityMapping *
mapping);
void mapping
(RTCORBA::NetworkPriorityMapping *
mapping);
RTCORBA::NetworkPriority_Mapping
*mapping (void);
private:
TAO_Network_Priority_Mapping
*mapping_;
};
The application developer can add his custom network priority mappings as described in section 2.3.3 using the NetworkPriorityMappingManager.
In order to implement a custom network priority mapping the application developer should implement the methods of the TAO_Network_Priority_Mapping class. E.g:
class TAO_Custom_Network_Priority_Mapping
:
public
TAO_Network_Priority_Mapping
{
virtual CORBA::Boolean to_network
(RTCORBA::Priority corba_priority,
RTCORBA::NetworkPriority
&network_priority);
virtual CORBA::Boolean to_CORBA
(RTCORBA::NetworkPriority
network_priority,
RTCORBA::Priority
&corba_priority);
};
This custom Network Priority Mapping can then be loaded into the Network Priority Mapping Manager as follows:
# Resolve the Network priority Mapping
Manager
CORBA::Object_var object =
orb->resolve_initial_references
("NetworkPriorityMappingManager");
RTCORBA::NetworkPriorityMappingManager_var
mapping_manager =
RTCORBA::NetworkPriorityMappingManager::_narrow
(object.in ());
# Initialize the custom priority
mapping
TAO_Custom_Network_Priority_Mapping *cnpm =
0;
ACE_NEW (cnpm,
TAO_Custom_Network_Priority_Mapping);
#Load the custom network priority mapping
object in the network priority
#mapping manager. The user can thus add his
own priority mapping.
mapping_manager->mapping (cnpm);
This ensures that the Custom Network Priority Mapping will be used to map the RTCORBA priority to the network priority.