TAO/docs/rtcorba/issues.html

   1 <html>
   2
   3 <!--  -->
   4 <head>
   5 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   6 <title>Implementation Issues and Known Bugs</title>
   7 <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
   8 </head>
   9
  10 <body>
  11
  12 <h3><a name="top">Known Issues and TO-DO Items</a></h3>
  13 <p>This page contains a list of known RTCORBA-related issues and to-do
  14 items. The list does not include any of the reports from the bug tracking
  15 system, so be sureto <a href="http://bugzilla.dre.vanderbilt.edu/index.cgi">query
  16 Bugzilla</a> for RTCORBA entries. </p>
  17 <ol>
  18   <li><a href="#7">Integrating protocol policies with the Pluggable Protocols framework</a></li>
  19   <li><a href="#10">Integrating Implementation Repository with RTCORBA and PP</a></li>
  20   <li><a href="#12">Priority Banded Connections interoperability issues</a></li>
  21   <li><a href="#2">Removing dependencies on ORB debug output from RTCORBA tests</a></li>
  22   <li><a href="#14">Adding RTCORBA examples</a></li>
  23   <li><a href="#5">Improving management of Private Connections</a></li>
  24   <li><a href="#6">Redesigning profile management to satisfy new requirements
  25     and to provide full
  26     support for location forwarding</a></li>
  27   <li><a href="#11">Location forwarding with client-exposed policies</a></li>
  28   <li><a href="#8">Moving FT endpoint selection into the endpoint selectors framework</a></li>
  29   <li><a href="#3">Introducing guidelines for debug output in TAO</a><br>
  30   </li>
  31 </ol>
  32 <hr>
  33 <h4><a name="7">Integrating protocol policies with the Pluggable Protocols
  34 framework</a></h4>
  35 <p><i>RTCORBA::ServerProtocolPolicy</i> and <i>RTCORBA::ClientProtocolPolicy</i>
  36 allow
  37 application developers to select and configure ORB communication protocols, and
  38 to specify preferred order of their use. This functionality has been implemented
  39 in TAO, but is only available with RTCORBA. Since protocol management
  40 is of interest to a large chunk of TAO users (many of whom do not need RTCORBA
  41 otherwise),
  42 we should make protocol policies available even when RTCORBA is not used, better
  43 integrate them with the Pluggable Protocols framework, and provide a number of
  44 other enhancements.</p>
  45 <ol>
  46   <li>Integrate protocol policies with PP framework. Make concrete <i> Protocol_Factories</i>
  47 responsible for creating corresponding <i>ProtocolProperties</i> with default and user-specified
  48 values (rather than having the knowledge about concrete <i>ProtocolProperties </i>embedded in the ORB).
  49     This will enable the protocol policies to be used to
  50 configure any pluggable protocols without having to modify the ORB code for
  51 each protocol.<br>
  52   </li>
  53   <li>Make protocol policies available even when RTCORBA is not used. Once
  54 this is done, remove (or deprecate) <i>-ORBSndSock</i>, <i>-ORBRcvSock</i>,
  55 and <i>-ORBNodelay</i> ORB options.<br>
  56   </li>
  57   <li>Add support for <i>TCPProtocolProperties::dont_route</i>
  58     in IIOP.<br> </li>
  59   <li>Add support for protocol properties configuration in SHMIOP. (SHMIOP
  60     properties are defined in <i>RTCORBA::SharedMemoryProtocolProperties</i>, but
  61     are currently not supported in the protocol implementation.)</li>
  62 </ol>
  63
  64 <p><a href="#top">[back]</a></p>
  65
  66 <hr>
  67 <h4><a name="10">Integrating Implementation Repository with RTCORBA and PP</a></h4>
  68 <p>Current version of Implementation Repository does not work properly with
  69 RTCORBA or Pluggable Protocols because it does not handle multiple endpoints for
  70 one server. Once RTCORBA implementation is complete, we should look into
  71 redesign of Implementation Repository.</p>
  72
  73 <p><a href="#top">[back]</a></p>
  74
  75 <hr>
  76 <h4><a name="12">Priority Banded Connections interoperability issues</a></h4>
  77 <p>
  78
  79 Section 4.12.2 (Binding of Priority Banded Connection) of the RT-CORBA
  80 spec talks about the <CODE>_bind_priority_band</CODE> implicit
  81 operation.  Clearly, this operation is not completely defined and
  82 neither is the reply to this implicit operation.  Therefore, it is
  83 almost impossible to get interoperability between RT-ORBs with respect
  84 to this operation.  <p>
  85
  86 Even if we make assumptions about the <CODE>_bind_priority_band</CODE>
  87 implicit operation and its reply, it leads to an architecture where
  88 there is unnecessary jitter and unpredictability because the
  89 connection needs to be moved from the Reactor associated with the
  90 Acceptor to the Reactor associated with correct priority.  This is
  91 either done with the <CODE>_bind_priority_band</CODE> method or with
  92 the first request. <p>
  93
  94 Because of the above mentioned issues, TAO does not use
  95 <CODE>_bind_priority_band</CODE> operation and <CODE>
  96 RTCorbaPriorityRange</CODE> service context during band
  97 establishment. Instead, the server embeds a proprietary <CODE>
  98 TAO_TAG_ENDPOINTS</CODE> tagged component into an object's IOR to let
  99 the clients know about available priorities and corresponding
 100 endpoints. To establish a banded connection, the client simply uses
 101 the endpoint corresponding to the priority of interest. (See <a
 102 href="architecture.html">TAO Real-Time Architecture</a> section for
 103 more details.)<p>
 104
 105 Once the semantics of the <CODE>_bind_priority_band</CODE> operation
 106 have been fully described by the specification or if the application
 107 can deal with the unpredictability of the first request, and TAO can
 108 be redesigned to handle the additional complexity of connection
 109 movement between the Reactors, we can change the behavior of Priority
 110 Banded Connections by:
 111
 112 <ol>
 113
 114   <li>modifying client to use <CODE>bind_priority_band</CODE>
 115   operation and <CODE> RTCorbaPriorityRange </CODE> service context
 116   during <CODE>Object::_validate_connection()</CODE> </li>
 117
 118   <li>modifying server to move a connection to the appropriate reactor
 119   once it receives <CODE> bind_priority_band </CODE>request and/or
 120   <CODE> RTCorbaPriorityRange </CODE> service context</li>
 121
 122   <li>modifying client to store and look up connections based on
 123   address + priority range rather than just based on address
 124   alone</li> </ol>
 125
 126 <p><a href="#top">[back]</a></p>
 127
 128 <hr>
 129
 130 <h4><a name="2">Removing dependencies on ORB
 131 debug output from RTCORBA tests</a></h4>
 132 <p>Some of the RTCORBA tests rely on ORB debugging output for checking whether
 133 something works. This is <i> very</i> <i> brittle</i> since ORB developers frequently
 134 add/remove/modify debugging messages, causing tests to 'break', and increasing
 135 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
 136 is used to carry out an invocation. It may be possible to achieve this without
 137 depending on ORB debug messages by using Portable Interceptors or some other
 138 similar mechanism. For example, we could write several interceptors, which would
 139 obtain and print information of interest for the test. We
 140 should look into this.</p>
 141
 142 <p><a href="#top">[back]</a></p>
 143
 144 <hr>
 145 <h4><a name="14">Adding RTCORBA examples</a></h4>
 146 <p>We do have tests for RTCORBA features, but what we also need are some
 147 examples. Use case-driven examples illustrating how certain features help
 148 satisfy various requirements. Examples that would help users understand
 149 when to use various features.</p>
 150
 151 <p><a href="#top">[back]</a></p>
 152
 153 <hr>
 154 <h4><a name="5">Improving management of Private Connections</a></h4>
 155 <p>Currently, when the object that has private connections is destroyed, its
 156 connections remain in the cache. We need to implement cleanup of private
 157 connections on object destruction. If such cleanup is expensive, we may
 158 want to have it controlled by an option.</p>
 159
 160 <p><a href="#top">[back]</a></p>
 161
 162 <hr>
 163 <h4><a name="6">Redesigning profile management to satisfy new requirements and
 164 to provide full
 165 support for location forwarding</a></h4>
 166 <p>Current client profile management code needs to change for the
 167 following reasons:</p>
 168 <ol>
 169   <li>Original design assumed that all threads using the same object reference
 170     would want to use the same profile for making an invocation. Hence, certain
 171     state, <i>i.e.</i>, <CODE>profile_in_use, profile_sucess and forward_profiles,
 172     </CODE>
 173     is stored per <i>Stub</i>. This assumption no longer holds true, <i>e.g.</i>,
 174     different threads may have different policies set, and would want to use
 175     different profiles based on those policies. This is at least the case with
 176     RTCORBA, where different threads may, for example, want to use different
 177     protocols. It may also be the case in other scenarios. So, we should not keep
 178     the state per <i>Stub</i>.</li>
 179   <li>Current design does not properly support location forwarding more than one
 180     level deep. And with certain policy configurations, location
 181     forwarding is not supported at all.</li>
 182   <li>Current interfaces are very polluted: many tiny functions with similar
 183     names calling into each other, comments in <i> .h</i> files outdated, comments in
 184     <i> .cpp</i> files mostly absent.</li>
 185   <li>Lack of thorough test suite.</li>
 186 </ol>
 187 <p>Also, redesign of profile management is a good time to add support for
 188 <CODE>TAG_ALTERNATE_IIOP</CODE> (multiple endpoints per profile).</p>
 189 <p>Bala is familiar with profile management code, and has agreed to act as a
 190 consultant/guide when somebody tackles this item.</p>
 191
 192 <p><a href="#top">[back]</a></p>
 193
 194 <hr>
 195 <h4><a name="11">Location forwarding with client-exposed policies</a></h4>
 196 <p>When an object is forwarded, a new set of profiles is received, and they can
 197 potentially include different client-exposed policies. Currently, we don't handle this case,
 198 <i>i.e.</i>, the set of client-exposed policies from the object's original IOR is
 199 used for its complete lifetime. This item is related to the <a href="#6">profile
 200 management</a> issue.</p>
 201
 202 <p><a href="#top">[back]</a></p>
 203
 204 <hr>
 205 <h4><a name="8">Moving FT endpoint selection into the endpoint selector
 206 framework</a></h4>
 207 <p>Selection of endpoints for invocations in TAO is strategized, with strategies for
 208 different policy combinations located in <i>Invocation_Endpoint_Selectors.*</i>
 209 Bala
 210 may want to make FT-based endpoint selection one of the available strategies.
 211 (Currently it's not part of the endpoint selectors framework.)</p>
 212
 213 <p><a href="#top">[back]</a></p>
 214
 215 <hr>
 216 <h4><a name="3">Introducing guidelines for debug output in TAO</a></h4>
 217 <p>Speaking of ORB debug output, there is not much consistency about it in TAO:
 218 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
 219 guidelines for debugging messages - this would make the output more useful (if
 220 the guidelines are followed, of course ;-) )</p>
 221
 222 <p><a href="#top">[back]</a></p>
 223
 224 <hr>
 225
 226 <i>
 227
 228 </p>
 229 <p></p>
 230 </body>
 231 </html>