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
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
|
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.03 [en] (X11; I; Linux 2.0.30_SMP i686) [Netscape]">
<TITLE>TAO Release Information and TODO List</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF">
<!-- $Id$ -->
<CENTER>
<HR>
<H3>
Release Information for The ACE ORB (TAO)</H3></CENTER>
Information is available on the following topics related to the <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/VERSION">current release</A> of
<A HREF="TAO.html">TAO</A>:
<UL>
<LI>
<A HREF="orbcore.html">ORB & ORB Core</A></LI>
<LI>
<A HREF="#idl">IDL Compiler</A></LI>
<LI>
<A HREF="#eventchannel">Event Channel</A></LI>
<LI>
<A HREF="#apps">Test & Example Applications</A></LI>
<LI>
<A HREF="#poa">Portable Object Adapter</A></LI>
<LI>
<A HREF="#nservices">CORBA Naming Service</A></LI>
<LI>
<A HREF="#tservices">CORBA Trader Service</A></LI>
<LI>
<A HREF="#ace">ORB-related ACE Changes</A></LI>
</UL>
<!--#include virtual="/~schmidt/ACE_wrappers/TAO/docs/releasenotes/orbcore.html" -->
<HR>
<H3><A NAME="idl"></A>IDL Compiler</H3>
Point of contact: <A HREF="mailto:gokhale@cs.wustl.edu">Andy Gokhale</A>
<P> Current status:
<UL>
<LI> Many IDL constructs supported including primitive types,
typedefs, sequences, structures, and unions. </LI>
<LI> Generated code closely follows the C++ Mapping specified in
the POA Specification (ORBOS/97-05-15). </LI>
<LI> Generates C++ stubs and skeletons that use TAO's <A
HREF="http://www.cs.wustl.edu/~schmidt/HICSS-97.ps.gz">interpretive IIOP protocol
engine</A>. </LI>
</UL>
<P> Known bugs:
<UL>
<LI>Works for <I>most</I> IDL constructs. Some of the known
bugs/incomplete tasks are:
<UL>
<LI>
Sequences of strings and object references may still
pose problems </LI>
<LI>
TypeCode generation for multidimensional arrays and
indirected typecodes is still a problem. </LI>
<LI>
Exceptions are not well-supported. TAO does not use
C++ Exceptions. Instead we use the alternative
mapping that uses CORBA::Environment. </LI>
<LI>
Some problems noticed when IDL files are included
and definitions from included files are used.</LI>
</UL>
</LI>
</UL>
Future work:
<UL>
<LI>Improve IDL compiler to support complete IDL-to-C++ mapping.</LI>
<LI>Fix bugs in the SunSoft IDL front-end we've
uncovered. These primarily include support for Unions.</LI>
<LI>Add command line options to TAO IDL. These options will
decide what strategy to use for operation name
demultiplexing. Another option may decide whether to use
the interpretive IIOP engine or generate compiled
stubs/skeletons. </LI>
<LI>Use <A
HREF="http://www.cs.utah.edu/projects/flux/flick/">Flick</A>
(from the University of Utah) to generate compiled stubs.</LI>
<LI>Goal is to measure the code size of the interpretive stubs
generated by TAO IDL compiler <I>vs</I> code size of compiled
stubs. Then compare the performance of each. We want to prove
the thesis that TAO IDL compiler generated interpretive stubs
have a small code size, yet are comparable in performance (or
slightly less) than compiled stubs. Hence, it will be useful
for small distributed equipment such as handsets, PDAs,
etc.</LI>
<LI>In doing the above, improvements to the IIOP protocol
engine in terms of size/performance/determinism will be
made.</LI>
</UL>
<HR>
<H3>
<A NAME="eventchannel"></A>Real-time Event Channel</H3>
Point of contact: <A HREF="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</A>
<P>Current status:
<UL>
<LI>
The current Event Channel is running under Orbix, fully distributed, the
main test has three processes, one runs the EC itself, one a Supplier and
yet another a Consumer.</LI>
<LI>
The configuration runs can be done even on the distributed scenario, using
the Real-time "Scheduling Service", which now has an IDL interface.</LI>
<LI>
At run-time (no config runs) there is no need to use the Real-time Scheduling
Service, a faster, collocated implementation for the service is available.
Obviously the information is generated on the config runs and linked into
the program.</LI>
<LI>
We are using an implementation of the standard <A HREF="#naming">Naming
Service</A> for Orbix.</LI>
</UL>
Future work:
<UL>
<LI>
Port to TAO (once IDL compiler is available and stable).</LI>
<LI>
The Scheduling Service is completely independant of the EC and the configuration
of suppliers or consumers. I think it would be convenient to have a library
and binaries for it, including a tool to dump the results in a C++ compilable
form.</LI>
</UL>
<HR>
<H3>
<A NAME="apps"></A>Test & Example Applications</H3>
Point of contact: <A HREF="mailto:sumedh@cs.wustl.edu">Sumedh Mungee</A>
<P>Current status:
<P>The TAO test application is meant to serve as a starting point for real-time
tests on the TAO system. It comprises the following parts:
<UL>
<LI>
<I>Server.</I> The server creates multiple CORBA objects (servants),
each with different real-time priorities. This priority is implemented
by using real-time thread support provided by the operating
system. Thus, requests sent to a high-priority servant are handled by
a high-priority real-time thread, and those sent to a lower priority
servant are handled by correspondingly lower priority threads. <P>
<LI>
<I>Client.</I> The client component binds to the servants, and sends a
stream of CORBA requests to the servants. It measures the response time,
i.e. the time taken for the request to complete successfully. In particular,
it measures the time taken for requests sent to the high priority servant
to complete. The volume of lower priority requests is configurable. The
client is thus able to measure the performance of the high-priority servant
in the presence of competition from several lower-priority servants.</LI>
</UL>
Clearly, if the ORB endsystem handles the priorities of the various requests
correctly, increasing the volume of lower priority requests should not
affect the performance seen by the higher priority requests. The application
thus serves as a tool to measure and confirm this behavior.
<P>Future work:
<UL>
<LI>
Study the impacts of scheduling & concurrency strategies on performance.</LI>
<LI>
Evolve into a testbed for discovering sources of performance non-determinism
& priority inversion.</LI>
</UL>
<HR>
<H3>
<A NAME="poa"></A>Portable Object Adapter</H3>
Point of contact: <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyarali</A>
<P>Current Status:
<UL>
<LI>
The POA is not integrated into this release, though we've begun migrating
TAO's OA to use POA method names.</LI>
</UL>
Critical work:
<UL>
<LI>
Re-generate win32 project files with new file names.</LI>
<LI>
Add resolve_initial_references() to resolve the "RootPOA" entry.</LI>
</UL>
Future work:
<UL>
<LI>
Mostly compliant with the <A HREF="http://siesta.cs.wustl.edu/~cleeland/tao/POA.pdf">ORB
Portability Specifications [orbos/97-05-15]</A> published by OMG.</LI>
<LI>
Provide extensions of the specification to ensure real-time delivery of
messages.</LI>
</UL>
<HR>
<H3>
<A NAME="nservices"></A>CORBA Naming Service</H3>
Point of contact: <A HREF="mailto:sergio@cs.wustl.edu">Sergio
Flores-Gaitan</A> and <A HREF="mailto:marina@cs.wustl.edu">Marina
Spivak</A><P>
<P>Current status:
<UL>
<LI>
This implementation works on ORBIX 2.0.</LI>
</UL>
Future work:
<UL>
<LI>
Testing the implementation ported to TAO. There is a bug in the sequence
marshalling of Name. After that is fixed, it should run ok.
</LI>
</UL>
<!--#include virtual="/~schmidt/ACE_wrappers/TAO/docs/releasenotes/trader.html" -->
<HR>
<H3>
<A NAME="ace"></A>ORB-related ACE Changes</H3>
Points of contact: <A HREF="mailto:cleeland@cs.wustl.edu">Chris Cleeland</A> and <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyrarli</A>
<P>Future work:
<ul>
<li>The current caching connector does not behave properly in
the face of a non-blocking connect request. The "fix" is
simply to not support non-blocking connects through the cache.
When the <code>connect()</code> fails with
<code>EWOULDBLOCK</code>, morph the error to -1 and clean up
the request.</li>
<li>Service handlers obtained from the caching connector are
not cleaned up. The application needs to be able to signal
that it's not using it any longer, and, when the application
encounters an error, needs to effectively close down that
connection for good so that a new connection can be initiated.
We're still working through the details on how to accomplish
this.</li>
</ul>
</BODY>
<hr><P>
<!--#include virtual="/~schmidt/cgi-sig.html" -->
</HTML>
|
