1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
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>
<h2><a name="top">Known Issues and TO-DO Items</a></h2>
<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://ace.cs.wustl.edu/bugzilla/query.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::keep_alive</i> and <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>
|
