diff options
| author | William R. Otte <wotte@dre.vanderbilt.edu> | 2006-07-24 15:50:21 +0000 |
|---|---|---|
| committer | William R. Otte <wotte@dre.vanderbilt.edu> | 2006-07-24 15:50:21 +0000 |
| commit | 3aff90f4a822fcf5d902bbfbcc9fa931d6191a8c (patch) | |
| tree | 197c810e5f5bce17b1233a7cb8d7b50c0bcd25e2 /TAO/docs/rtcorba | |
| parent | 6b846cf03c0bcbd8c276cb0af61a181e5f98eaae (diff) | |
| download | ATCD-3aff90f4a822fcf5d902bbfbcc9fa931d6191a8c.tar.gz | |
Repo restructuring
Diffstat (limited to 'TAO/docs/rtcorba')
| -rw-r--r-- | TAO/docs/rtcorba/architecture.html | 117 | ||||
| -rw-r--r-- | TAO/docs/rtcorba/content.html | 44 | ||||
| -rw-r--r-- | TAO/docs/rtcorba/faq.html | 40 | ||||
| -rw-r--r-- | TAO/docs/rtcorba/features.html | 843 | ||||
| -rw-r--r-- | TAO/docs/rtcorba/index.html | 23 | ||||
| -rw-r--r-- | TAO/docs/rtcorba/issues.html | 231 | ||||
| -rw-r--r-- | TAO/docs/rtcorba/omg_issues.html | 103 | ||||
| -rw-r--r-- | TAO/docs/rtcorba/queue-per-lane.gif | bin | 0 -> 44463 bytes | |||
| -rw-r--r-- | TAO/docs/rtcorba/reactor-per-lane.gif | bin | 0 -> 47879 bytes | |||
| -rw-r--r-- | TAO/docs/rtcorba/status.html | 131 |
10 files changed, 1532 insertions, 0 deletions
diff --git a/TAO/docs/rtcorba/architecture.html b/TAO/docs/rtcorba/architecture.html new file mode 100644 index 00000000000..b06460a079d --- /dev/null +++ b/TAO/docs/rtcorba/architecture.html @@ -0,0 +1,117 @@ +<html> + +<!-- $Id$ --> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> +<title>TAO Real-Time Architecture</title> +<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> +</head> + +<body> + +<h3 align="center">TAO Real-Time Architecture </h3> +<p>This page describes and compares the two main ORB designs we considered for +supporting Real-Time CORBA 1.0 in TAO. The first design, codenamed <i>reactor-per-lane</i> +and shown in Figure 1, was chosen for our initial implementation. The +second design, <i>queue-per-lane</i>, might also get implemented in the future, +as a part of a project evaluating alternative ORB architectures for Real-Time +CORBA. </p> +<h3 align="center">Design I: Reactor-per-Lane</h3> +In this design, each Threadpool Lane has its own reactor, acceptor, connector +and connection cache. Both I/O and application-level processing for a +request happen in the same threadpool thread: there are no context switches, and +the ORB does not create any internal threads. Objects registered with any +Real-Time POA that does not have the <i>ThreadpoolPolicy</i> are serviced by <i>default +threadpool</i>, which is a set of of all the application threads that invoked +<CODE>orb->run ()</CODE>. +<p align="center"><img border="0" src="reactor-per-lane.gif" width="407" height="333"></p> +<p align="center">Figure 1: Reactor-per-lane</p> +<p>When a Real-Time POA is creating an IOR, it includes one or more of its +threadpool's acceptor endpoints into that IOR according to the following +rules. If the POA's priority model is <i>server declared</i>, we use the +acceptor from the lane whose priority is equal to the priority of the target +object. If the +priority model is <i> client propagated,</i> all endpoints from the POA's +threadpool are included into the IOR. Finally, if the <i>PriorityBandedConnectionPolicy</i> +is set, then endpoints from the threadpool lanes with priorities falling into one of the specified +priority bands are selected. The endpoints, selected according to the +rules above, and their corresponding priorities are stored in IORs using a special +<i>TaggedComponent </i><CODE>TAO_TAG_ENDPOINTS</CODE>. During each +invocation, to obtain a connection to the server, the client-side ORB selects +one of these endpoints based on the effective policies. For example, if the object has +<i> client propagated</i> priority +model, the ORB selects the endpoint whose priority is equal to the priority of the client thread making the +invocation. If on the client-side, during invocation, or on the +server-side, during IOR creation, an endpoint of the right priority is not available, it +means the system has not been configured properly, and the ORB throws an exception. +The design and rules described above ensure that when a threadpool with lanes is +used, client requests are processed by the thread of desired priority from very +beginning, and priority inversions are minimized.</p> +<p>Some applications need less rigid, more dynamic environment. They do +not have the advanced knowledge or cannot afford the cost of configuring all of the +resources ahead of time, and have a greater tolerance for priority +inversions. For such applications, threadpools <i> without</i> lanes are a way to go. +In TAO, threadpools without lanes have different semantics that their <i>with-lanes</i> +counterparts. Pools without lanes have a single acceptor endpoint used in +all IORs, and their threads change priorities on the fly, as necessary, to +service all types of requests.</p> +<h3 align="center">Design II: Queue-per-Lane</h3> +In this design, each threadpool lane has its own request queue. There is a separate +I/O layer, which is shared by all lanes in all threadpools. The I/O layer has one +set of resources - reactor, connector, connection cache, and I/O thread(s) - for each priority +level used in the threadpools. I/O layer threads perform I/O processing +and demultiplexing, and threadpool threads are used for application-level request +processing. +<p align="center"><img border="0" src="queue-per-lane.gif" width="387" height="384"></p> +<p align="center">Figure 2: Queue-per-lane</p> +<p>Global acceptor is listening for connections from clients. Once a +connection is established, it is moved to the appropriate reactor during the +first request, once its priority is known. Threads in each lane are blocked on +condition variable, waiting for requests to show up in their queue. I/O +threads read incoming requests, determine their target POA and its threadpool, +and deposit the requests into the right queue for processing. </p> +<h3 align="center">Design Comparison</h3> +<i>Reactor-per-lane</i> advantages: +<ul> + <li><b>Better performance</b><br> + Unlike in <i>queue-per-lane</i>, since each request is serviced in one + thread, there are no context switches, and there are opportunities for stack and TSS optimizations.</li> + <li><b>No priority inversions during connection establishment</b><i><br> + </i>In <i>reactor-per-lane</i>, threads accepting connections are the same + threads that will be servicing the requests coming in on those connections, <i>i.e.</i>, + priority of the accepting thread is equal to the priority of requests on the + connection. In <i>queue-per-lane</i>, + however, because of a global acceptor, there is no differentiation between + high priority and low priority clients until the first request.</li> + <li><b>Control over all threads with standard threadpool API<br> + </b>In <i>reactor-per-lane,</i> the ORB does not create any threads of its + own, so application programmer has full control over the number and + properties of all the threads with the Real-Time CORBA Threadpool + APIs. <i>Queue-per-lane</i>, on the other hand, has I/O layer threads, + so either a proprietary API has to be added or application programmer will + not have full control over all the thread resources..</li> +</ul> +<p> +<i>Queue-per-lane</i> advantages:</p> +<ul> + <li><b>Better feature support and adaptability</b><br> + <i>Queue-per-lane</i> supports ORB-level request buffering, while <i>reactor-per-lane</i> + can only provide buffering in the transport. With its two-layer + structure, <i>queue-per-lane</i> is a more decoupled design than <i>reactor-per-lane</i>, + making it easier to add new features or introduce changes </li> + <li><b>Better scalability</b> <br> + Reactor, connector and connection cache are <i>per-priority</i> resources in + <i>queue-per-lane</i>, and <i>per-lane</i> in <i>reactor-per-lane</i>. + If a server is configured with many threadpools that have similar lane + priorities, <i>queue-per-lane</i> might require significantly fewer of the + above-mentioned resources. It also uses fewer acceptors, and its IORs + are a bit smaller.</li> + <li><b>Easier piece-by-piece integration into the ORB<br> + </b>Ease of implementation and integration are important practical + considerations in any project. Because of its two-layer structure, <i>queue-per-lane</i> + is an easier design to implement, integrate and test piece-by-piece.</li> +</ul> +<hr> +<p><i>Last modified: $Date$</i></p> +</body> +</html> diff --git a/TAO/docs/rtcorba/content.html b/TAO/docs/rtcorba/content.html new file mode 100644 index 00000000000..0e0f6b68f89 --- /dev/null +++ b/TAO/docs/rtcorba/content.html @@ -0,0 +1,44 @@ +<html> + +<!-- $Id$ --> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> +<title>TAO Real-Time CORBA Documentation Table of Content</title> +<base target="main"> +</head> + +<body> + +<h3 align="center">TAO Real-Time CORBA Documentation </h3> + +<ol> + <li><a href="status.html#intro">Intro</a></li> + <ul> + <li><a href="status.html#supported">Supported Features</a></li> + <li><a href="status.html#unsupported">Unsupported Features</a></li> + <li><a href="status.html#future">Future Work</a></li> + </ul> + </li> + <li><a href="omg_issues.html">Issues with the Real-Time CORBA 1.0 Specification</a></li> + <li><a href="architecture.html">TAO Real-Time Architecture</a></li> + <li><a href="features.html">Real-Time Features Documentation</a><ul> + <li><a href="features.html#enabling">Enabling Real-Time features</a></li> + <li><a href="features.html#deprecated">Migrating from + TAO::Client_Priority_Policy</a> </li> + <li><a href="features.html#mappings">Priority Mappings</a></li> + <li><a href="features.html#defaults">ORB Default Policies</a></li> + <li><a href="features.html#threadpools"> Threadpools</a></li> + <li><a href="features.html#valid_configurations">Priority Policies</a> </li> + <li><a href="features.html#explicit_bind">Explicit Binding</a></li> + <li><a href="features.html#protocols">Protocol Policies</a></li> + <li><a href="features.html#diffserv">Diffserv Support</a></li> + </ul> + </li> + <li><a href="issues.html">Known Bugs and Issues</a></li> + <li><A + HREF="http://www.cs.wustl.edu/~schmidt/corba-research-realtime.html">Performance and Papers</A></li> + <li><a href="faq.html">FAQ</a> </li> +</ol> + +</body> +</html> diff --git a/TAO/docs/rtcorba/faq.html b/TAO/docs/rtcorba/faq.html new file mode 100644 index 00000000000..ab446b2620b --- /dev/null +++ b/TAO/docs/rtcorba/faq.html @@ -0,0 +1,40 @@ +<html> + +<!-- $Id$ --> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> +<title>TAO Real-Time CORBA Frequently Asked Questions</title> +<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> +</head> + +<body> + +<h3><a name="top">Frequently Asked Questions</a></h3> + +<p><strong><a href="#Q1">1. Question</a><br> +<a href="#Q2">2. Question</a></strong></p> + +<hr> + +<p><a name="Q1">Q1</a>.</p> + +<p>A1.</p> + +<p><a href="#top">[back]</a></p> + +<hr> + +<p><a name="Q2">Q2</a>.</p> + +<p>A2.</p> + +<p><a href="#top">[back]</a></p> + +<hr> +<i> + +<p>Last modified: $Date$ </i></p> + +<p> </p> +</body> +</html> diff --git a/TAO/docs/rtcorba/features.html b/TAO/docs/rtcorba/features.html new file mode 100644 index 00000000000..d360ee31c2d --- /dev/null +++ b/TAO/docs/rtcorba/features.html @@ -0,0 +1,843 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.77 [en] (Windows NT 5.0; U) [Netscape]"> + <title>TAO Real-Time CORBA Features Documentation</title> +<!-- $Id$ --> +</head> +<body> + +<center> +<h3> +Features Documentation</h3></center> +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 +<tt>$TAO/tests/RTCORBA/</tt>. +We hope to have tutorial-style examples available in the near future. +<h3> +<a NAME="enabling"></a>Enabling Real-Time CORBA features</h3> +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 +RTPortableServer libraries. Since some features in RT-CORBA depend on the +messaging specification, all code must be compiled with <tt>TAO_HAS_CORBA_MESSAGING</tt> +set to +<tt>1</tt>. This macros are defined in +<tt>$TAO/tao/orbconf.h</tt> +<p>By default, both Real-Time CORBA and Messaging are enabled in TAO unless +Minimum CORBA support is turned on, <i>i.e.</i>, +<tt>TAO_HAS_MINIMUM_CORBA</tt> +is set to <tt>1</tt>. +<h3> +<a NAME="mappings"></a>Priority Mappings</h3> +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. +<dl> +<dt> +<b>Direct</b></dt> + +<dd> +Maps CORBA priorities directly to native priorities.</dd> + +<dt> +<b>Linear</b></dt> + +<dd> +Maps each individual native priority to a contiguous range of CORBA priorities, +so that the complete CORBA priority range is used up for the mapping. See +<tt>$TAO_ROOT/tao/RTCORBA/Linear_Priority_Mapping.cpp +</tt>for +more details.</dd> + +<dt> +<b>Continuous</b></dt> + +<dd> +Maps the first <i>n</i> CORBA priorities to the range of native priorities, +where <i>n</i> is the number of native priorities. The lowest native priority +is mapped to CORBA priority 0, next higher native priority is mapped to +CORBA priority 1, and so on. Since in all the operating systems where TAO +is supported the native priority set contains less than 32767 priorities, +part of the CORBA priority range is left unused. Consider NT Direct priority +mapping as an example. NT native priorities -15 -2 -1 0 1 2 15 are mapped +to CORBA priorities 0 1 2 3 4 5 6, respectively, and the rest of the CORBA +priority range is not used.</dd> +</dl> +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. +<p>By default TAO uses Direct priority mapping and +<tt>SCHED_OTHER</tt> +scheduling policy. There are two ways for an application to override these +settings: +<ol> +<li> +<tt>svc.conf</tt> 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:</li> + +<br> +<p> +<br> +<br> +<p><tt>static RT_ORB_Loader "-ORBPriorityMapping +<i>mapping_type</i> -ORBSchedPolicy +<i>sched_policy</i>"</tt> +<p>where valid values for <i>mapping_type</i> are <tt>continuous</tt>, <tt>linear</tt> and <tt>direct,</tt> +and<i> </i>valid values for <i>sched_policy</i> are <tt>SCHED_OTHER</tt>, +<tt>SCHED_FIFO</tt> +and <tt>SCHED_RR</tt>. +<li> +<i>TAO::PriorityMappingManager</i> can be used to 1) override the default +priority mapping and scheduling policy with another ORB-defined mapping/scheduling +policy combination, 2) install a user-defined priority mapping, 3) obtain +a reference to the priority mapping object used by the ORB. Code excerpts +below demonstrate how to perform each of these tasks.</li> + +<br> +<p> +<br> +<br> +<p>Obtaining Priority Mapping Manager: +<br><tt>object = orb->resolve_initial_references ("PriorityMappingManager");</tt> +<br><tt>TAO::PriorityMappingManager_var mapping_manager =</tt> +<br><tt>TAO::PriorityMappingManager::_narrow (object.in ());</tt> +<p>Overriding priority mapping/policy in effect with another ORB-defined +mapping/policy combination: +<br><tt>#include "tao/RTCORBA/Continuous_Priority_Mapping.h"</tt> +<br><tt>#include "tao/RTCORBA/Linear_Priority_Mapping.h"</tt> +<br><tt>#include "tao/RTCORBA/Direct_Priority_Mapping.h"</tt> +<br><tt>...</tt> +<p><tt>RTCORBA::PriorityMapping *pm =</tt> +<br><tt>new TAO_Continuous_Priority_Mapping (policy);</tt> +<br>or +<br><tt>new TAO_Linear_Priority_Mapping (policy);</tt> +<br>or +<br><tt>new TAO_Direct_Priority_Mapping (policy);</tt> +<br><tt>mapping_manager->mapping (pm);</tt> +<br><tt>...</tt> +<br>where policy is <tt>SCHED_OTHER, SCHED_FIFO</tt> or +<tt>SCHED_RR.</tt> +Priority Mapping Manager takes the ownership of the priority mapping object. +<p>Overriding the default with user-defined priority mapping: +<br><tt>My_Mapping *foo = new My_Mapping;</tt> +<br><tt>mapping_manager->mapping (foo);</tt> +<br>where <i>My_Mapping</i> must inherit from <i>RTCORBA::PriorityMapping</i> +(a typedef for <i>TAO_Priority_Mapping</i> class) located in +<tt>$TAO/tao/Priority_Mapping.h</tt> +<p>Obtaining a pointer to the priority mapping object being used by the +ORB: +<br><tt>RTCORBA::PriorityMapping *pm =</tt> +<br><tt>mapping_manager->mapping ();</tt> +<br>Mapping manager retains the ownership of the priority mapping object.</ol> + +<h3> +<a NAME="defaults"></a>ORB Default Policies</h3> +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. +<br> +<table BORDER CELLPADDING=7 WIDTH="100%" > +<tr> +<td ALIGN=CENTER WIDTH="31%"><b>Policy</b></td> + +<td ALIGN=CENTER WIDTH="69%"><b>Default</b></td> +</tr> + +<tr> +<td WIDTH="31%"><i>ServerProtocolPolicy</i></td> + +<td WIDTH="69%">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 <a href="#protocols">Protocol +Policies</a> section for more details.</td> +</tr> + +<tr> +<td WIDTH="31%"><i>ClientProtocolPolicy</i></td> + +<td WIDTH="69%">None</td> +</tr> + +<tr> +<td WIDTH="31%"><i>ThreadpoolPolicy</i></td> + +<td WIDTH="69%">None. If no ThreadpoolPolicy policy is specified during +POA creation, the default thread-pool will be used for that POA.</td> +</tr> + +<tr> +<td WIDTH="31%"><i>PriorityModelPolicy</i></td> + +<td WIDTH="69%">None</td> +</tr> + +<tr> +<td WIDTH="31%"><i>PriorityBandedConnectionPolicy</i></td> + +<td WIDTH="69%">None</td> +</tr> + +<tr> +<td WIDTH="31%"><i>PrivateConnectionPolicy</i></td> + +<td WIDTH="69%">None</td> +</tr> + +<tr> +<td WIDTH="31%">Priority Mapping</td> + +<td WIDTH="69%">Direct mapping with <tt>SCHED_OTHER</tt> scheduling policy. +See <a href="#mappings">Priority Mappings</a> section for more details.</td> +</tr> +</table> + +<h3> +<a NAME="threadpools"></a>Threadpools</h3> + +<ul> +<li> +ThreadPools are now fully supported. Endpoint priorities are no longer +supported.</li> +<li> +By default dynamic RTCorba threads live forever after they are created. +When using the <code>RTORBDynamicThreadIdleTimeout</code> from the +<code>RT_ORB_Loader</code> it +can be specified that the dynamic threads should end after a given +idle time. Timeout must be specified in microseconds, 0 means the threads +will stay alive forever. +</ul> + +<h3> +<a NAME="valid_configurations"></a>Priority Policies</h3> +The table below lists all possible configurations of policies involving +priorities, and summarizes the semantics of each configuration. +<br> +<table BORDER CELLPADDING=4 WIDTH="100%" > +<tr> +<td ALIGN=CENTER WIDTH="33%"><b>Configuration</b></td> + +<td ALIGN=CENTER WIDTH="33%"><b>Valid values</b></td> + +<td ALIGN=CENTER WIDTH="34%"><b>Semantics</b></td> +</tr> + +<tr> +<td WIDTH="33%">Threadpool with lanes, +<br>no <i>PriorityModelPolicy</i>, +<br>no <i>PriorityBandedConnectionPolicy</i></td> + +<td WIDTH="33%">Invalid.</td> + +<td WIDTH="34%">None.</td> +</tr> + +<tr> +<td WIDTH="33%">Threadpool with lanes + +<br><tt>SERVER_DECLARED</tt> model, +<br>no <i>PriorityBandedConnectionPolicy</i></td> + +<td WIDTH="33%"><i>Server_priority</i> attribute of the <i>PriorityModelPolicy</i> +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).</td> + +<td WIDTH="34%">All processing is done at the servant's priority.</td> +</tr> + +<tr> +<td WIDTH="33%">Threadpool with lanes + +<br><tt>CLIENT_PROPAGATED</tt> model, +<br>no <i>PriorityBandedConnectionPolicy</i></td> + +<td WIDTH="33%">Priority of the invoking client thread must be equal to +the priority of one of the threadpool lanes.</td> + +<td WIDTH="34%">All processing is done at the client-propagated priority.</td> +</tr> + +<tr> +<td WIDTH="33%">Threadpool with lanes + +<br><i>PriorityBandedConnectionPolicy</i>, +<br>no <i>PriorityModelPolicy</i></td> + +<td WIDTH="33%">Invalid.</td> + +<td WIDTH="34%">None.</td> +</tr> + +<tr> +<td WIDTH="33%">Threadpool with lanes + +<br><tt>SERVER_DECLARED</tt> model + +<br><i>PriorityBandedConnectionPolicy</i></td> + +<td WIDTH="33%"><i>Server_priority</i> attribute of the <i>PriorityModelPolicy</i> +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.</td> + +<td WIDTH="34%">All processing is done at the servant's priority.</td> +</tr> + +<tr> +<td WIDTH="33%">Threadpool with lanes + +<br><tt>CLIENT_PROPAGATED</tt> model + +<br><i>PriorityBandedConnectionPolicy</i></td> + +<td WIDTH="33%">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.</td> + +<td WIDTH="34%">All processing is done at the threadpool lane priority +which matches the priority band used by the client.</td> +</tr> + +<tr> +<td WIDTH="33%">Threadpool without lanes, +<br>no <i>PriorityModelPolicy</i>, +<br>no <i>PriorityBandedConnectionPolicy</i></td> + +<td WIDTH="33%">All valid CORBA priorities.</td> + +<td WIDTH="34%">All processing is done at the threadpool's default priority.</td> +</tr> + +<tr> +<td WIDTH="33%">Threadpool without lanes + +<br><tt>SERVER_DECLARED</tt> model, +<br>no <i>PriorityBandedConnectionPolicy</i></td> + +<td WIDTH="33%">All valid CORBA priorities.</td> + +<td WIDTH="34%">Request I/O and demultiplexing processing is done at the +threadpool's default priority. Application level processing is done at +the servant's priority.</td> +</tr> + +<tr> +<td WIDTH="33%">Threadpool without lanes + <tt>CLIENT_PROPAGATED</tt> model, +<br>no <i>PriorityBandedConnectionPolicy</i></td> + +<td WIDTH="33%">All valid CORBA priorities.</td> + +<td WIDTH="34%">Request I/O and demultiplexing processing is done at the +threadpool's default priority. Application level processing is done at +the client-propagated priority.</td> +</tr> + +<tr> +<td WIDTH="33%">Threadpool without lanes + +<br><i>PriorityBandedConnectionPolicy</i>, +<br>no <i>PriorityModelPolicy</i></td> + +<td WIDTH="33%">Invalid.</td> + +<td WIDTH="34%">None.</td> +</tr> + +<tr> +<td WIDTH="33%">Threadpool without lanes + +<br><tt>SERVER_DECLARED</tt> model + +<br><i>PriorityBandedConnectionPolicy</i></td> + +<td WIDTH="33%"><i>Server_priority</i> attribute of the <i>PriorityModelPolicy</i> +must fall into one of the priority bands. (Same goes for priorities of +all the objects registered with the target POA).</td> + +<td WIDTH="34%">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, <i>PriorityBandedConnectionPolicy</i> +is used to restrict the allowed priority values for the servant.</td> +</tr> + +<tr> +<td WIDTH="33%">Threadpool without lanes + +<br><tt>CLIENT_PROPAGATED</tt> model + +<br><i>PriorityBandedConnectionPolicy</i></td> + +<td WIDTH="33%">Priority of the invoking client thread must fall into one +of the priority bands.</td> + +<td WIDTH="34%">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, <i>PriorityBandedConnectionPolicy</i> +is used to restrict the allowed priority values for the client.</td> +</tr> +</table> + +<h3> +<a NAME="explicit_bind"></a>Explicit Binding</h3> +<tt>Object::_validate_connection ()</tt> method establishes a connection, +if one doesn't already exist, and verifies policy overrides for the <i>invoking +thread/ its priority/ target object</i> combination. To establish all connections +ahead of time, application must call <tt>_validate_connection ()</tt> for +<b>all</b><i>thread/ +priority/ object</i> combinations that will be used. +<h3> +<a NAME="protocols"></a>Protocol Policies</h3> +In addition to <i>TCPProtocolProperties</i> 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. +<ul> +<li> +<b>IIOP</b></li> + +<br>Protocol <i>ProfileId</i>: 0 +<br>Transport properties interface name: <i>RTCORBA::TCPProtocolProperties</i> +(standard) +<br>Implementation class name: <i>TAO_TCP_Properties</i> +<table BORDER CELLPADDING=4 HEIGHT="150" > +<tr> +<td ALIGN=CENTER HEIGHT="19"><b>Protocol Properties Attribute</b></td> + +<td ALIGN=CENTER HEIGHT="19"><b>Default Value</b></td> +</tr> + +<tr> +<td HEIGHT="19">long <i>send_buffer_size</i></td> + +<td ALIGN=LEFT HEIGHT="19"><tt>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</tt></td> +</tr> + +<tr> +<td HEIGHT="19">long <i>recv_buffer_size</i></td> + +<td ALIGN=LEFT HEIGHT="19"><tt>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</tt></td> +</tr> + +<tr> +<td HEIGHT="19">boolean <i>keep_alive</i> (not yet supported)</td> + +<td ALIGN=LEFT HEIGHT="19"><tt>1</tt></td> +</tr> + +<tr> +<td HEIGHT="19">boolean <i>dont_route</i> (not yet supported)</td> + +<td ALIGN=LEFT HEIGHT="19"><tt>0</tt></td> +</tr> + +<tr> +<td HEIGHT="19">boolean <i>no_delay</i></td> + +<td ALIGN=LEFT HEIGHT="19"><tt>1</tt></td> +</tr> +</table> + +<li> +<b>UIOP</b></li> + +<br>Protocol <i>ProfileId</i>: 0x54414f00U +<br>Transport properties interface name: <i>RTCORBA::UnixDomainProtocolProperties</i> +(TAO-specific) +<br>Implementation class name: <i>TAO_Unix_Domain_Properties</i> +<table BORDER CELLPADDING=4 > +<tr> +<td ALIGN=CENTER><b>Protocol Properties Attribute</b></td> + +<td ALIGN=CENTER><b>Default Value</b></td> +</tr> + +<tr> +<td>long <i>send_buffer_size</i></td> + +<td><tt>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</tt></td> +</tr> + +<tr> +<td>long <i>recv_buffer_size</i></td> + +<td><tt>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</tt></td> +</tr> +</table> + +<li> +<b>SHMIOP</b></li> + +<br>Protocol <i>ProfileId</i>: 0x54414f02U +<br>Transport properties interface name: <i>RTCORBA::SharedMemoryProtocolProperties</i> +(TAO-specific) +<br>Implementation class name: <i>TAO_SMEM_Properties</i> +<table BORDER CELLPADDING=4 > +<tr> +<td ALIGN=CENTER><b>Protocol Properties Attribute</b></td> + +<td ALIGN=CENTER><b>Default Value</b></td> +</tr> + +<tr> +<td>long <i>preallocate_buffer_size</i></td> + +<td>not yet supported</td> +</tr> + +<tr> +<td>string <i>mmap_filename</i></td> + +<td>not yet supported</td> +</tr> + +<tr> +<td>string <i>mmap_lockname</i></td> + +<td>not yet supported</td> +</tr> +</table> +</ul> +Real-Time CORBA 1.0 does not define how protocol properties are created. +<i>TAO_Protocol_Factory</i> +class can be used to create default <i>ProtocolProperties</i> for a particular +protocol given its <i>ProfileId</i>: +<p><tt>class TAO_Protocol_Properties_Factory</tt> +<br><tt>{</tt> +<br><tt>public:</tt> +<p><tt>static RTCORBA::ProtocolProperties*</tt> +<br><tt>create_transport_protocol_property (IOP::ProfileId id);</tt> +<p><tt>static RTCORBA::ProtocolProperties*</tt> +<br><tt>create_orb_protocol_property (IOP::ProfileId id);</tt> +<br><tt>};</tt> +<p>Alternatively, concrete <i>ProtocolProperties</i> implementation classes +can be instantiated directly as needed. +<p>The table below summarizes how protocol policies overrides affect protocol +selection and configuration in TAO. +<br> +<table BORDER CELLPADDING=4 > +<tr> +<td ALIGN=CENTER><b>Policy</b></td> + +<td ALIGN=CENTER><b>ORB default</b></td> + +<td ALIGN=CENTER><b>Override levels that have impact on protocol selection</b></td> + +<td ALIGN=CENTER><b>Override levels that have impact on protocol configuration</b></td> +</tr> + +<tr> +<td><i>ServerProtocolPolicy</i></td> + +<td>All protocols loaded into the ORB, in the order they were loaded.</td> + +<td>ORB +<br>POA</td> + +<td>ORB +<br>(If no protocol properties are specified at the ORB level, default +protocol configurations are used.)</td> +</tr> + +<tr> +<td><i>ClientProtocolPolicy</i></td> + +<td>None</td> + +<td>ORB +<br>Current +<br>Object</td> + +<td>ORB +<br>(If no protocol properties are specified at the ORB level, default +protocol configurations are used.)</td> +</tr> +</table> + +<p>NOTE: <tt>-ORBSndSock</tt> and <tt>-ORBRcvSock</tt> ORB options have +no effect when RTCORBA is enabled. +<p>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. +<br> +<hr> +<h3> +<a NAME="diffserv"></a>Diffserv Support</h3> + +<p>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. +<dl> +<dt> +<b>Modifications to RTCORBA.pidl</b></dt> + +<br> +<ul> +<li> +<b>TCP Protocol Properties extension</b></li> + +<br> +<dd> +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.</dd> + +<p><tt>local interface TCPProtocolProperties : ProtocolProperties</tt> +<br><tt>{</tt> +<br><tt>attribute long send_buffer_size;</tt> +<br><tt>attribute long recv_buffer_size;</tt> +<br><tt>attribute boolean keep_alive;</tt> +<br><tt>attribute boolean dont_route;</tt> +<br><tt>attribute boolean no_delay;</tt> +<br><tt>attribute boolean enable_network_priority;</tt> +<br><tt>};</tt> +<br> +<li> +<b>Network Priority Mapping Interfaces</b></li> + +<dd> +<p>Support was added for mapping RTCORBA priority to Network Priority. It +is similar to the RTCORBA to native thread priority mapping.</dd> + +<p><tt>typedef long NetworkPriority;</tt> +<br><tt>native NetworkPriorityMapping;</tt></ul><br> + +<dt> +<b>Usage</b></dt> + +<br> +<ul> +<li> +<b>Client - Setting DSCP on the GIOP Requests</b></li> + +<br><br> +<dd> +1. <i>Create TCP protocol properties</i> - The enable_network_priority +flag implies the setting/unsetting of the network priority.</dd> + +<p><tt>RTCORBA::TCPProtocolProperties_var tcp_properties =</tt> +<br><tt> rt_orb->create_tcp_protocol_properties (send_buffer_size,</tt> +<br><tt> +recv_buffer_size,</tt> +<br><tt> +1, //keep alive</tt> +<br><tt> +0, //don't route</tt> +<br><tt> +1, //no delay</tt> +<br><tt> +enable_network_priority);</tt> +<p>2. <i>Create TCP Protocol Properties Policy</i> +<p><tt>RTCORBA::ProtocolList protocols;</tt> +<br><tt>protocols.length (1);</tt> +<br><tt>protocols[0].protocol_type = 0; //IIOP</tt> +<br><tt>protocols[0].transport_protocol_properties =</tt> +<br><tt> RTCORBA::ProtocolProperties::_duplicate (tcp_properties.in +());</tt> +<br><tt>protocols[0].orb_protocol_properties =</tt> +<br><tt> RTCORBA::ProtocolProperties::_nil ();</tt> +<p><tt>CORBA::PolicyList policy_list;</tt> +<br><tt>policy_list.length (1);</tt> +<br><tt>policy_list[0] =</tt> +<br><tt> rt_orb->create_client_protocol_policy (protocols);</tt> +<p>3.<i> Set TCP Protocol Properties Policy</i> +<p><b>ORB Level</b> - This implies that the tcp protocol properties set +will apply to every invocation made with this ORB. +<p><tt>CORBA::Object_var object =</tt> +<br><tt>orb->resolve_initial_references ("ORBPolicyManager");</tt> +<br><tt>CORBA::PolicyManager_var policy_manager =</tt> +<br><tt> CORBA::PolicyManager::_narrow (object.in ());</tt> +<br><tt>policy_manager->set_policy_overrides (policy_list,</tt> +<br><tt> +CORBA::SET_OVERRIDE);</tt> +<p><b>THREAD Level</b> - 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. +<p>orb->orb_core ()->policy_current ().set_policy_overrides (policy_list, +<br> +CORBA::SET_OVERRIDE); +<p><b>OBJECT Level</b> - This implies that the tcp protocol properties +set will apply to the invocations made on the corresponding object only. +<p><tt>CORBA::Object_var object = server->_set_policy_overrides (policy_list,</tt> +<br><tt> +CORBA::SET_OVERRIDE);</tt> +<p><tt>server = Test::_narrow (object.in ()); //server is the CORBA Object</tt> +<p>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. +<br> +<li> +<b>Server - Setting DSCP on the GIOP Replies</b></li> + +<br> +<dd> +1. <i>Create the TCP protocol properties</i> - The enable_network_priority +flag implies the setting/unsetting of the network priority.</dd> + +<p><tt>RTCORBA::TCPProtocolProperties_var tcp_properties =</tt> +<br><tt> rt_orb->create_tcp_protocol_properties (send_buffer_size,</tt> +<br><tt> +recv_buffer_size,</tt> +<br><tt> +1, //keep alive</tt> +<br><tt> +0, //don't route</tt> +<br><tt> +1, //no delay</tt> +<br><tt> +enable_network_priority);</tt> +<p>2. <i>Create TCP Protocol Properties Policy</i> +<p><tt>RTCORBA::ProtocolList protocols;</tt> +<br><tt>protocols.length (1);</tt> +<br><tt>protocols[0].protocol_type = 0; //IIOP</tt> +<br><tt>protocols[0].transport_protocol_properties =</tt> +<br><tt> RTCORBA::ProtocolProperties::_duplicate (tcp_properties.in +());</tt> +<br><tt>protocols[0].orb_protocol_properties =</tt> +<br><tt> RTCORBA::ProtocolProperties::_nil ();</tt> +<br> +<p><tt>CORBA::PolicyList policy_list;</tt> +<br><tt>policy_list.length (1);</tt> +<br><tt>policy_list[0] =</tt> +<br><tt> rt_orb->create_server_protocol_policy (protocols);</tt> +<p>3. <i>Create POA with Diffserv enabled</i> +<p><tt>CORBA::PolicyList poa_policy_list;</tt> +<br><tt>poa_policy_list.length (1);</tt> +<br><tt>poa_policy_list [0] =</tt> +<br><tt> rt_orb->create_server_protocol_policy (protocols);</tt> +<p><tt>PortableServer::POA_var poa_with_ds =</tt> +<br><tt>root_poa->create_POA ("POA_WITH_DS",</tt> +<br><tt> +poa_manager.in (),</tt> +<br><tt> +poa_policy_list );</tt> +<p>All the servants that want network priority set on their replies should +register with this POA. +<p>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. +<br> </ul> + +<dt> +<b>Network Priority Mapping</b></dt> + +<br> +<ul> +<li> +<b>NetworkPriorityMapping interface</b></li> + +<br> +<dd> +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: + +<p><tt>typedef TAO_Network_Priority_Mapping +NetworkPriorityMapping;</tt></dd> + +<p><tt>Where TAO_Network_Priority_Mapping is defined as:</tt> +<p><tt>class TAO_Network_Priority_Mapping</tt> +<br><tt>{</tt> +<br><tt>public:</tt> +<br><tt> virtual CORBA::Boolean to_network (RTCORBA::Priority +corba_priority,</tt> +<br><tt> +RTCORBA::NetworkPriority &network_priority) = 0;</tt> +<br><tt> virtual CORBA::Boolean to_CORBA (RTCORBA::NetworkPriority +network_priority,</tt> +<br><tt> +RTCORBA::Priority &corba_priority) = 0;</tt> +<br><tt>};</tt> +<p>The methods to_network (…) and to_corba (…) can be implemented differently +for different mapping algorithms that can be defined by the application. +<br> +<li> +<b>Default Network Priority Mappings</b></li> + +<br> +<dd> +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:</dd> + +<p>static RT_ORB_Loader "-ORBSchedPolicy SCHED_FIFO -ORBScopePolicy PROCESS +-ORBPriorityMapping direct <i>-ORBNetworkPriorityMapping Linear</i>" +<br> +<li> +<b>Network Priority Mapping Manager</b></li> + +<br> +<dd> +A NetworkPriorityMappingManager is defined in TAO to manage the Network +Priority Mapping.</dd> + +<p><tt>typedef TAO_Network_Priority_Mapping_Manager NetworkPriorityMappingManager;</tt> +<p><tt>Where TAO_Network_Priority_Mapping_Manager is:</tt> +<p><tt>class TAO_RTCORBA_Export TAO_Network_Priority_Mapping_Manager :</tt> +<br><tt>{</tt> +<br><tt>public:</tt> +<br><tt> TAO_Network_Priority_Mapping_Manager (RTCORBA::NetworkPriorityMapping +* mapping);</tt> +<br><tt> void mapping (RTCORBA::NetworkPriorityMapping +* mapping);</tt> +<br><tt> RTCORBA::NetworkPriority_Mapping *mapping (void);</tt><tt></tt> +<p><tt>private:</tt> +<br><tt> TAO_Network_Priority_Mapping *mapping_;</tt> +<br><tt>};</tt> +<p>The application developer can add his custom network priority mappings +as described in section 2.3.3 using the NetworkPriorityMappingManager. +<br> +<li> +<b>Custom Network Priority Mapping</b></li> + +<br> +<dd> +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:</dd> + +<p><tt>class TAO_Custom_Network_Priority_Mapping :</tt> +<br><tt>public TAO_Network_Priority_Mapping</tt> +<br><tt>{</tt> +<br><tt> virtual CORBA::Boolean to_network (RTCORBA::Priority +corba_priority,</tt> +<br><tt> +RTCORBA::NetworkPriority &network_priority);</tt> +<br><tt> virtual CORBA::Boolean to_CORBA (RTCORBA::NetworkPriority +network_priority,</tt> +<br><tt> +RTCORBA::Priority &corba_priority);</tt> +<br><tt>};</tt> +<p>This custom Network Priority Mapping can then be loaded into the Network +Priority Mapping Manager as follows: +<p><tt># Resolve the Network priority Mapping Manager</tt> +<br><tt>CORBA::Object_var object = orb->resolve_initial_references ("NetworkPriorityMappingManager");</tt> +<br><tt>RTCORBA::NetworkPriorityMappingManager_var mapping_manager = RTCORBA::NetworkPriorityMappingManager::_narrow +(object.in ());</tt> +<p><tt># Initialize the custom priority mapping</tt> +<br><tt>TAO_Custom_Network_Priority_Mapping *cnpm = 0;</tt> +<br><tt>ACE_NEW (cnpm,</tt> +<br><tt> TAO_Custom_Network_Priority_Mapping);</tt> +<p><tt>#Load the custom network priority mapping object in the network +priority</tt> +<br><tt>#mapping manager. The user can thus add his own priority mapping.</tt> +<br><tt>mapping_manager->mapping (cnpm);</tt> +<p>This ensures that the Custom Network Priority Mapping will be used to +map the RTCORBA priority to the network priority. +</ul> +<br> +<i>Last Modified: $Date$</i></dl> + +</body> +</html> diff --git a/TAO/docs/rtcorba/index.html b/TAO/docs/rtcorba/index.html new file mode 100644 index 00000000000..994b5dd6398 --- /dev/null +++ b/TAO/docs/rtcorba/index.html @@ -0,0 +1,23 @@ +<html> +<!-- $Id$ --> + +<head> +<meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> +<title>TAO Real-Time CORBA Documentation</title> +<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> +<meta name="ProgId" content="FrontPage.Editor.Document"> +</head> + +<frameset cols="300,*"> + <frame name="contents" target="main" src="content.html" scrolling="auto"> + <frame name="main" src="status.html"> + <noframes> + <body> + + <p>This page uses frames, but your browser doesn't support them.</p> + + </body> + </noframes> +</frameset> + +</html> diff --git a/TAO/docs/rtcorba/issues.html b/TAO/docs/rtcorba/issues.html new file mode 100644 index 00000000000..43c3e1979b0 --- /dev/null +++ b/TAO/docs/rtcorba/issues.html @@ -0,0 +1,231 @@ +<html> + +<!-- $Id$ --> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> +<title>Implementation Issues and Known Bugs</title> +<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> +</head> + +<body> + +<h3><a name="top">Known Issues and TO-DO Items</a></h3> +<p>This page contains a list of known RTCORBA-related issues and to-do +items. The list does not include any of the reports from the bug tracking +system, so be sureto <a href="http://deuce.doc.wustl.edu/bugzilla/index.cgi">query +Bugzilla</a> for RTCORBA entries. </p> +<ol> + <li><a href="#7">Integrating protocol policies with the Pluggable Protocols framework</a></li> + <li><a href="#10">Integrating Implementation Repository with RTCORBA and PP</a></li> + <li><a href="#12">Priority Banded Connections interoperability issues</a></li> + <li><a href="#2">Removing dependencies on ORB debug output from RTCORBA tests</a></li> + <li><a href="#14">Adding RTCORBA examples</a></li> + <li><a href="#5">Improving management of Private Connections</a></li> + <li><a href="#6">Redesigning profile management to satisfy new requirements + and to provide full + support for location forwarding</a></li> + <li><a href="#11">Location forwarding with client-exposed policies</a></li> + <li><a href="#8">Moving FT endpoint selection into the endpoint selectors framework</a></li> + <li><a href="#3">Introducing guidelines for debug output in TAO</a><br> + </li> +</ol> +<hr> +<h4><a name="7">Integrating protocol policies with the Pluggable Protocols +framework</a></h4> +<p><i>RTCORBA::ServerProtocolPolicy</i> and <i>RTCORBA::ClientProtocolPolicy</i> +allow +application developers to select and configure ORB communication protocols, and +to specify preferred order of their use. This functionality has been implemented +in TAO, but is only available with RTCORBA. Since protocol management +is of interest to a large chunk of TAO users (many of whom do not need RTCORBA +otherwise), +we should make protocol policies available even when RTCORBA is not used, better +integrate them with the Pluggable Protocols framework, and provide a number of +other enhancements.</p> +<ol> + <li>Integrate protocol policies with PP framework. Make concrete <i> Protocol_Factories</i> +responsible for creating corresponding <i>ProtocolProperties</i> with default and user-specified +values (rather than having the knowledge about concrete <i>ProtocolProperties </i>embedded in the ORB). + This will enable the protocol policies to be used to +configure any pluggable protocols without having to modify the ORB code for +each protocol.<br> + </li> + <li>Make protocol policies available even when RTCORBA is not used. Once +this is done, remove (or deprecate) <i>-ORBSndSock</i>, <i>-ORBRcvSock</i>, +and <i>-ORBNodelay</i> ORB options.<br> + </li> + <li>Add support for <i>TCPProtocolProperties::dont_route</i> + in IIOP.<br> </li> + <li>Add support for protocol properties configuration in SHMIOP. (SHMIOP + properties are defined in <i>RTCORBA::SharedMemoryProtocolProperties</i>, but + are currently not supported in the protocol implementation.)</li> +</ol> + +<p><a href="#top">[back]</a></p> + +<hr> +<h4><a name="10">Integrating Implementation Repository with RTCORBA and PP</a></h4> +<p>Current version of Implementation Repository does not work properly with +RTCORBA or Pluggable Protocols because it does not handle multiple endpoints for +one server. Once RTCORBA implementation is complete, we should look into +redesign of Implementation Repository.</p> + +<p><a href="#top">[back]</a></p> + +<hr> +<h4><a name="12">Priority Banded Connections interoperability issues</a></h4> +<p> + +Section 4.12.2 (Binding of Priority Banded Connection) of the RT-CORBA +spec talks about the <CODE>_bind_priority_band</CODE> implicit +operation. Clearly, this operation is not completely defined and +neither is the reply to this implicit operation. Therefore, it is +almost impossible to get interoperability between RT-ORBs with respect +to this operation. <p> + +Even if we make assumptions about the <CODE>_bind_priority_band</CODE> +implicit operation and its reply, it leads to an architecture where +there is unnecessary jitter and unpredictability because the +connection needs to be moved from the Reactor associated with the +Acceptor to the Reactor associated with correct priority. This is +either done with the <CODE>_bind_priority_band</CODE> method or with +the first request. <p> + +Because of the above mentioned issues, TAO does not use +<CODE>_bind_priority_band</CODE> operation and <CODE> +RTCorbaPriorityRange</CODE> service context during band +establishment. Instead, the server embeds a proprietary <CODE> +TAO_TAG_ENDPOINTS</CODE> tagged component into an object's IOR to let +the clients know about available priorities and corresponding +endpoints. To establish a banded connection, the client simply uses +the endpoint corresponding to the priority of interest. (See <a +href="architecture.html">TAO Real-Time Architecture</a> section for +more details.)<p> + +Once the semantics of the <CODE>_bind_priority_band</CODE> operation +have been fully described by the specification or if the application +can deal with the unpredictability of the first request, and TAO can +be redesigned to handle the additional complexity of connection +movement between the Reactors, we can change the behavior of Priority +Banded Connections by: + +<ol> + + <li>modifying client to use <CODE>bind_priority_band</CODE> + operation and <CODE> RTCorbaPriorityRange </CODE> service context + during <CODE>Object::_validate_connection()</CODE> </li> + + <li>modifying server to move a connection to the appropriate reactor + once it receives <CODE> bind_priority_band </CODE>request and/or + <CODE> RTCorbaPriorityRange </CODE> service context</li> + + <li>modifying client to store and look up connections based on + address + priority range rather than just based on address + alone</li> </ol> + +<p><a href="#top">[back]</a></p> + +<hr> + +<h4><a name="2">Removing dependencies on ORB +debug output from RTCORBA tests</a></h4> +<p>Some of the RTCORBA tests rely on ORB debugging output for checking whether +something works. This is <i> very</i> <i> brittle</i> since ORB developers frequently +add/remove/modify debugging messages, causing tests to 'break', and increasing +amount of maintenance effort required. Yet, we somehow need to verify that <i>internally</i> the ORB behaves as we expect, <i>e.g.</i>, a particular transport protocol +is used to carry out an invocation. It may be possible to achieve this without +depending on ORB debug messages by using Portable Interceptors or some other +similar mechanism. For example, we could write several interceptors, which would +obtain and print information of interest for the test. We +should look into this.</p> + +<p><a href="#top">[back]</a></p> + +<hr> +<h4><a name="14">Adding RTCORBA examples</a></h4> +<p>We do have tests for RTCORBA features, but what we also need are some +examples. Use case-driven examples illustrating how certain features help +satisfy various requirements. Examples that would help users understand +when to use various features.</p> + +<p><a href="#top">[back]</a></p> + +<hr> +<h4><a name="5">Improving management of Private Connections</a></h4> +<p>Currently, when the object that has private connections is destroyed, its +connections remain in the cache. We need to implement cleanup of private +connections on object destruction. If such cleanup is expensive, we may +want to have it controlled by an option.</p> + +<p><a href="#top">[back]</a></p> + +<hr> +<h4><a name="6">Redesigning profile management to satisfy new requirements and +to provide full +support for location forwarding</a></h4> +<p>Current client profile management code needs to change for the +following reasons:</p> +<ol> + <li>Original design assumed that all threads using the same object reference + would want to use the same profile for making an invocation. Hence, certain + state, <i>i.e.</i>, <CODE>profile_in_use, profile_sucess and forward_profiles, + </CODE> + is stored per <i>Stub</i>. This assumption no longer holds true, <i>e.g.</i>, + different threads may have different policies set, and would want to use + different profiles based on those policies. This is at least the case with + RTCORBA, where different threads may, for example, want to use different + protocols. It may also be the case in other scenarios. So, we should not keep + the state per <i>Stub</i>.</li> + <li>Current design does not properly support location forwarding more than one + level deep. And with certain policy configurations, location + forwarding is not supported at all.</li> + <li>Current interfaces are very polluted: many tiny functions with similar + names calling into each other, comments in <i> .h</i> files outdated, comments in + <i> .cpp</i> files mostly absent.</li> + <li>Lack of thorough test suite.</li> +</ol> +<p>Also, redesign of profile management is a good time to add support for +<CODE>TAG_ALTERNATE_IIOP</CODE> (multiple endpoints per profile).</p> +<p>Bala is familiar with profile management code, and has agreed to act as a +consultant/guide when somebody tackles this item.</p> + +<p><a href="#top">[back]</a></p> + +<hr> +<h4><a name="11">Location forwarding with client-exposed policies</a></h4> +<p>When an object is forwarded, a new set of profiles is received, and they can +potentially include different client-exposed policies. Currently, we don't handle this case, +<i>i.e.</i>, the set of client-exposed policies from the object's original IOR is +used for its complete lifetime. This item is related to the <a href="#6">profile +management</a> issue.</p> + +<p><a href="#top">[back]</a></p> + +<hr> +<h4><a name="8">Moving FT endpoint selection into the endpoint selector +framework</a></h4> +<p>Selection of endpoints for invocations in TAO is strategized, with strategies for +different policy combinations located in <i>Invocation_Endpoint_Selectors.*</i> +Bala +may want to make FT-based endpoint selection one of the available strategies. +(Currently it's not part of the endpoint selectors framework.)</p> + +<p><a href="#top">[back]</a></p> + +<hr> +<h4><a name="3">Introducing guidelines for debug output in TAO</a></h4> +<p>Speaking of ORB debug output, there is not much consistency about it in TAO: +not in the use of ORB debug levels, not in the style and detail of debug messages. It is probably a good idea to come up with a short list of +guidelines for debugging messages - this would make the output more useful (if +the guidelines are followed, of course ;-) )</p> + +<p><a href="#top">[back]</a></p> + +<hr> + +<i> + +<p>Last modified: $Date$ </i></p> +<p></p> +</body> +</html> diff --git a/TAO/docs/rtcorba/omg_issues.html b/TAO/docs/rtcorba/omg_issues.html new file mode 100644 index 00000000000..bb49722b205 --- /dev/null +++ b/TAO/docs/rtcorba/omg_issues.html @@ -0,0 +1,103 @@ +<html> + +<!-- $Id$ --> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> +<title>Issues with OMG Real-Time CORBA 1.0 Specification</title> +<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> +</head> + +<body> + +<h3>Issues with Real-Time CORBA 1.0 Specification</h3> + +This document lists what we believe to be the shortcomings of the +Real-Time CORBA 1.0 specification, which we uncovered while implementing it in TAO. +All items on this page refer to <a href="http://cgi.omg.org/cgi-bin/doc?ptc/99-05-03">ptc/99-05-03</a>, which was +the basis for our implementation. This material will be submitted to the +OMG. +<h3> + +Unnecessary <i>ClientProtocolPolicy</i> complexity</h3> +<p> + +<i>ClientProtocolPolicy</i> can be set on either client or server. Section 4.8.5 +in CORBA 2.4 cautions against defining policies that can be set +in both places: +<blockquote><br> + If the <b><font FACE="Arial" SIZE="2">Policy </font></b> can be +used with <b><font FACE="Arial" SIZE="2">POA </font></b>creation +to tune <b><font FACE="Arial" SIZE="2">IOR </font></b>contents +and can also be specified (overridden) in the client, specify how to reconcile the policy's +presence from both the client and server. It is strongly recommended to avoid this +case! As an exercise in completeness, most <b><font FACE="Arial" SIZE="2">POA </font></b>policies +can probably be extended to have +some meaning in the client and vice versa, but this does not help make usable +systems, it just makes them more complicated without adding really useful +features. +There are very few cases where a policy is really appropriate to specify in +both places, and for these policies the interaction between the two must be +described. </blockquote> +<p>While the specification does describe what happens if <i>ClientProtocolPolicy</i> +is set on both client and server, it is not clear that being able to set the +policy on the server-side adds any useful functionality. With <i>ServerProtocolPolicy, +</i>the server already has the ability to specify which protocols and in what +order can be used by clients for invocations. So, <i>ClientProtocolPolicy</i> +should be made a pure client policy, to reduce the complexity of the +system. A related issue, which becomes moot if the policy is made pure +client, is whether <CODE>nil</CODE> <i>ProtocolProperties</i> are allowed in <i>ClientProtocolPolicy</i>, +and, if so, how are they encoded into a <i>TaggedComponent</i> if the policy is +set on the server-side.</p> +<h3>Lack of standard APIs for managing Priority Mappings and Priority Transforms</h3> +<p>The specification does not define APIs for setting and getting Priority Mappings and Priority Transforms, +leaving it up to ORB implementations. These APIs should be standardized in +order for application code to be portable. +</p> +<h3> +Policy configurations ambiguities</h3> +<p>The specification defines a number of policies involving priorities, and +describes some of their interaction. However, it does not completely +specify the validity and semantics of <i>all</i> possible combinations of those +policies. For example, does the combination of Server Declared Priority +Model with server-set Priority Banded Connections make sense? For all values? +If the purpose of Priority Banded Connections is to avoid priority inversions, +then why would we ever want to use <i>PriorityModelPolicy</i> without <i>PriorityBandedConnectionPolicy</i>? +And, if we would <i>always</i> want to use Priority Banded Connections, why does +there need to be a policy, why can't banded connections be a mechanism the ORB +uses internally as needed, transparent to the user? </p> +<p>What is clear from the spec is the availability of certain policies, what is +not clear is what exactly using each one of those policies achieves - in other +words, when and why different combinations of them are appropriate. </p> +<h3>Lack of thread resources model</h3> +<p> Section 4.12.2 of the specification says the following about server ORB and +priority band establishment: <cite>"if the priority band +is inconsistent with the ORB's priority configuration then the ORB shall raise a +INV_POLICY system exception". </cite>However, the specification +never defines what is meant by <i>the ORB's priority configuration,</i> leaving +it up to implementations. One implementation, for example, might use +Threadpool threads for servicing banded connections, and <i>consistency with the +ORB's configuration</i> would mean availability of a threadpool lane with +priority matching band's priority range. Another implementation might be +spawning separate threads for servicing banded connections, and <i>consistency +with the ORB's configuration</i> would be automatic. With these two +implementations, a band that will cause exception in the first implementation +will work just fine in the second. The specification does not provide a +model of ORB thread resources: it provides APIs for creating Threadpools, but +does not describe how the threadpool threads are used. I/O threads are +never even mentioned. On one hand, this lack of a resource model is +beneficial: it allows greater freedom and variety of implementations. But, +on the other hand, it hurts portability, since a configuration might work with +one real-time ORB implementation but not another. Also, bounding priority inversions +is a quality of implementation: there is no explicit requirement for I/O threads to run at the same priority as request processing threads.</p> + +<p>In summary, we believe that Real-Time CORBA 1.0 specification is a good +start, but needs some work, especially in regards to resolving +ambiguities. Currently, applications must depend on many implementation details. +For example, a policy combination providing certain semantics in one ORB can +provide different semantics or be invalid when used in another ORB, with both +ORBs being compliant with the specification. </p> + +<hr> +<p><i>Last Modified: $Date$</i></p> +</body> +</html> diff --git a/TAO/docs/rtcorba/queue-per-lane.gif b/TAO/docs/rtcorba/queue-per-lane.gif Binary files differnew file mode 100644 index 00000000000..cff639fc568 --- /dev/null +++ b/TAO/docs/rtcorba/queue-per-lane.gif diff --git a/TAO/docs/rtcorba/reactor-per-lane.gif b/TAO/docs/rtcorba/reactor-per-lane.gif Binary files differnew file mode 100644 index 00000000000..37f2195acdb --- /dev/null +++ b/TAO/docs/rtcorba/reactor-per-lane.gif diff --git a/TAO/docs/rtcorba/status.html b/TAO/docs/rtcorba/status.html new file mode 100644 index 00000000000..781617616b7 --- /dev/null +++ b/TAO/docs/rtcorba/status.html @@ -0,0 +1,131 @@ +<html> +<!-- $Id$ --> + +<head> +<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> +<title>Status of Real-Time CORBA Support in TAO</title> +<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> +</head> + +<body> + +<h3><a name="intro">Real-Time CORBA Support in TAO</a> </h3> +<a name="status"> + +<p>Support for <a href="http://www.omg.org">OMG</a> <a +href="http://cgi.omg.org/cgi-bin/doc?ptc/99-05-03">Real-Time CORBA 1.0 +specification</a> has been added to TAO. For an overview of Real-time +CORBA features, please see the <A +HREF="http://www.cs.wustl.edu/~schmidt/report-doc.html#rt">C/C++ Users +Journal columns</A> written by <A +HREF="http://www.cs.wustl.edu/~schmidt/">Douglas Schmidt</A> and <A +HREF="http://www.iona.com/hyplan/vinoski/">Steve Vinoski</a>. For a +detailed design discussions and results of empirical performance +analyzes of TAO's Real-time CORBA implementation, please see the <A +HREF="http://www.cs.wustl.edu/~schmidt/doc-group.html">DOC group's</a> +<A +HREF="http://www.cs.wustl.edu/~schmidt/corba-research-realtime.html">Real-time +CORBA research page</A>. + +<p>As usual, questions, comments, and contributions should be posted +to the <a href="news:comp.soft-sys.ace">comp.soft-sys.ace</a> +newsgroup, and bug reports can be submitted either through our +web-based <a +href="http://ace.cs.wustl.edu/bugzilla/index.cgi">bug-tracking +system</a> (best) or by filling out the <A +HREF="../../PROBLEM-REPORT-FORM">TAO_ROOT/PROBLEM-REPORT-FORM</A> +and posting it to the newsgroup. Please indicate "RTCORBA" +in the component field when submitting a bug report. </p> + +<p>Points of contact for the project are: + +<ul> + <li><a href="mailto:corsaro@cs.wustl.edu">Angelo Corsaro</a> - collocation and policy + encoding into ior</li> + <li><a href="mailto:irfan@cs.wustl.edu">Irfan Pyarali</a> - POA threadpools and RT POA</li> + <li><a href="mailto:marina@cs.wustl.edu">Marina Spivak</a> - all other features and online + documentation </li> + <li><a href="mailto:yamuna@oomworks.com">Yamuna Krishnamurthy</a> - Diffserv support in RTCORBA </li> +</ul> + +<h3><a name="supported">Supported Features</a></h3> + +<p>Following is the complete list of features from the Real-Time CORBA 1.0 specification +that are currently supported in TAO. (These do not include <a href="#in progress">work +in progress</a>). + +<ul> + <li>Real-Time ORB</li> + <li>Real-Time POA</li> + <li>Real-Time Current</li> + <li>Priority Mappings</li> + <li>Client_Propagated Priority Model</li> + <li>Server_Declared Priority Model</li> + <li>Server Protocol Policy</li> + <li>Client Protocol Policy</li> + <li>Priority Banded Connections</li> + <li>Explicit Binding</li> + <li>Private Connections</li> + <li>Invocation Timeout</li> + <li>RT Mutex</li> + <li>POA Threadpools</li> +</ul> + +<h3><a name="unsupported">Unsupported Features</a></h3> + +<p>The following features are not currently supported, and there are no immediate plans +for their implementation: + +<ul> + <li>POA Threadpool request buffering</li> + <li>POA Threadpool thread borrowing </li> + <li>Priority Transforms</li> + <li>ORBinit command-line option</li> +</ul> + +<h3><a name="future">Future Work</a></h3> + +<ol> + + <li>Currently, persistent objects are not supported for RT POAs. We + need to add this feature.</li> + + <li>Currently, purging of connection only happens for the lane of + the thread that runs out of connection. We need to change this + such that we allow system wide purging.</li> + + <li>Currently, all user-created threads are part of the default + thread pool. There is nothing done to separate out these threads + into different (implicit) lanes based on their priorities. We may + need to add this separation to get better/predictable behavior + with respect to sharing of resources across threads of different + priorities.</li> + + <li>Currently, some CDR memory pools are global. We should + reevaluate them to see which of them can be made a per-lane + resource.</li> + + <li>Improve current RT CORBA implementation through benchmarking and + optimizations, resolving known bugs and issues, adding examples, + and other enhancements.</li> + + <li>Implement an alternative real-time orb architecture using a + <em>queue-per-lane</em> approach, as described in the <a + href="architecture.html">TAO Real-Time Architecture</a> + section. 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 a server. Strategize TAO to use + either <em>queue-per-lane</em> or <em>reactor-per-lane</em> + implementation, and compare the two.</li> + + <li>As both real-time and fault tolerance implementations mature + separately, explore issues in combining them, and, ultimately, + enable TAO to provide applications with both real-time and fault + tolerance support at the same time. </li> </ol> + +<hr> +<i> + +<p>Last modified: $Date$</i></p> +</body> +</html> |
