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
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
|
<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>
<LI>
<a href="#vc">How to add IDL files into your Visual C++ projects</a>
</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">Aniruddha Gokhale</A>
<P> Current status: (As of Dec 31st, 1997.)
<UL>
<LI> Param_Test example is able to test string sequences, fixed
structs, variable sized structs and nested structs </LI>
<LI> Param_Test test suite can now test fixed structs and string
sequences.This needed bug fixes to TAO ORB core. </LI>
<LI> A new test to test all the parameter passing modes for a
number of data types has been added. At this point in time,
it tests primitive types and strings. Other tests will be
added. Bugs discovered thru these tests have been
fixed. </LI>
<LI> Very preliminary support for arrays. Not working yet. </LI>
<LI> Many bugs associated with stub generation fixed. This
included support for return values that are variable sized
IDL types. Unions improved. </LI>
<LI> Support for sequences of strings and object references
added. However, it is not tested yet so there may be some
bugs. We should have these fixed in a day or so. </LI>
<LI> Support for handling exceptions added. TAO does not use
direct C++ exceptions. Instead it uses the
CORBA::Environment based approach. </LI>
<LI> Sequences as out parameters have been
tested in the IDL_Cubit example. A test suite is currently
being built to test all the parameter passing modes on a
variety of IDL data types. </LI>
<LI> Support for attributes completed. Not tested yet. </LI>
<LI> The problem of incorrect code generation for typedefs
defined in an imported file is resolved.
<LI>
Problems when interfaces use single
or multiple inheritance solved. The problem was with the demultiplexing
code, the generated operation tables, and the dispatching
mechanism. We are currently testing this with the Event
Channel code. </LI>
<LI> The problems arising due to public virtual inheritance when
casting from an interface class to CORBA::Object_ptr has
been solved. We do this casting inside the stubs/skeletons
rather than first converting an interface class pointer to a
void*, storing it in an Any, and casting it to
CORBA::Object_ptr in the encode/decode methods. The casting
inside the stubs/skeletons work because the compiler has
knowledge of both types. </LI>
<LI> The compiler
generates correct code for COSS Naming service and it
runs properly. Correct code also gets generated for the
Event Channel program </LI>
<LI> Include files are handled properly. So are the definitions
used inside the include files that are used in the currently
parsed files. </LI>
<LI> IN, INOUT, and OUT object reference parameters are now
supported properly. We think the same approach should work
for sequences, structs, and unions. </LI>
<LI> Many IDL constructs supported including primitive types,
typedefs, sequences, structures, and unions. </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>
<LI> Generated code closely follows the C++ Mapping specified in
the POA Specification (ORBOS/97-05-15). </LI>
</UL>
<P> Known bugs/unimplemented constructs:
<UL>
<LI> Some of the known bugs/incomplete tasks are:
<UL>
<LI> Generation of Managed types must somehow be moved
to the ORB Core </LI>
<LI>
We need support for ``TIEs'' (i.e., the object form
of the Adapter pattern). </LI>
<LI>
TypeCode generation for multidimensional arrays and
indirected typecodes is still a problem. </LI>
<LI> Unions with default cases yet to be handled </LI>
<LI> The <<= and >>= operators for user-defined types
are not generated yet. </LI>
<LI> Deal with names in the IDL definition that are C++
keywords. </LI>
<LI> IDL is case-insensitive. However, it looks like our
front-end is case-sensitive. Thanks to Anil Gopinath
(anil@ittc.ukans.edu) for pointing this out. </LI>
<LI> tao_idl generates code for a *.idl file only inside
the directory where the *.idl resides. However, it
may be required to generate code elsewhere i.e., in
the directory where the compiler was invoked. Thanks
to Tom Richards (tomr@MCMEnterprise.com) for this
suggestion. </LI>
</UL>
</LI>
</UL>
Future work:
<UL>
<LI>Improve IDL compiler to generate compiled form of stubs/skeletons.</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 working on TAO,
the Scheduling Service still has some problems,
apparently related to the IDL compiler.</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. Unfortunately the schedule information cannot be
downloaded from the service right now.</LI>
<LI>
TAO <A HREF="#nservices">Naming Service</A> is used to locate the various
services: the Event Channel itself, the Scheduling Service, etc.</LI>
</UL>
Future work:
<UL>
<LI>
When several suppliers are consumers are distributed over the network
it could be nice to exploit locality and have a separate Event
Channel on each process (or host).
Only when an event is required by some remote consumer we need to send
it through the network.
The basic architecture to achieve this seems very simple,
each Event Channel connects as another supplier to its peers,
providing a "merge" of its (local) suppliers QoS as its own QoS
specification,
the channel also registers as a consumer,
using an analogous QoS, this time looking at its consumers.
It is not clear how to avoid event looping and how to propagate the
QoS yet,
we plan to build some experiments on this scenario,
hand crafting the QoS if necessary and evolve from there.</LI>
<LI>
We should be able to download the schedule to the interested parties,
without need for a separate link phase. This will simplify and
speed up the developing cycle,
but requires a (small) amount of dynamic memory allocation.
It could be interesting to "save" the schedule computation in some
persistent form, so startup cost are lower too.</LI>
</UL>
<P>For general documentation on the Event Service please read
<A HREF="http://www.cs.wustl.edu/~schmidt/oopsla.ps.gz">
The Design and Performance of a Real-time CORBA Event Service</A>.
The current distribution has just one test program for the Event
Service, below are the basic instructions to run it:</P>
<OL>
<LI> Compile everything under <CODE>$TAO_ROOT/orbsvcs</CODE>, this
needs, obviously, <CODE>$TAO_ROOT/tao</CODE> and
the IDL compiler in <CODE>$TAO_ROOT/TAO_IDL</CODE>.</LI>
<LI> Run the naming service, the scheduling service, the event service
and the test in
<CODE>$TAO_ROOT/TAO/orbsvcs/tests/Event_Latency</CODE>;
remember to give a different port to each one,
using the <CODE>-ORBport</CODE> option.</LI>
<LI> If you want real-time behavior on Solaris you may need to run
these programs as root; on the other hand, this particular
example really has no priority inversion, since only one
thread runs at a time.</LI>
</OL>
<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 implementation is almost complete. The next step is the ORB
Core / POA / IDL compiler integration. Estimated deadline for this is
December 22, 1997.
</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 (as of Dec 10th):
<UL>
<LI>
The Naming Service implementation is complete.</LI>
</UL>
<P>Known problems:
<UL>
<LI>
The bind_new_context() call is not working correctly. This is getting looked at and will be resolved soon.
</LI>
</UL>
<P>Future work:
<UL>
<LI>
Currently the bindings are stored as a table in memory. Future work will include a persistent database to store the bindings.</LI>
</UL>
<P>For general documentation on the Naming Service please read
<A HREF="ftp://www.omg.org/pub/docs/formal/97-07-12.pdf">
The Naming Service Specification</A>.
<!--#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>Recently Completed Work:
<UL>
<li>Added special declaration to OS.h for <code>inet_ntoa</code>
and other functions because VxWorks doesn't provide full
argument prototypes for these library functions.</li>
<li>The current caching connector behaves 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
now 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. <br>
Added the ability for a Svc_Handler to
recycle itself. idle() can be called when the Svc_Handler is
done serving a particular connection and can how be recycled.
The Svc_Handler now also has a pointer to a recycler that is
responsible for managing the connections. The recycler is
usually a Cached_Connector. <br>
Added new class ACE_Recycling_Strategy.
It defines the interface (and default implementation) for
specifying a recycling strategy for a Svc_Handler. This
strategy acts as a consular to the Svc_Handler, preparing it for
the tough times ahead when the Svc_Handler will be recycled. <br>
Added new class ACE_NOOP_Concurrency_Strategy. It implements
a no-op activation strategy in order to avoid calling open on
a recycled svc_handler multiple times. <br>
ACE_Cached_Connect_Strategy now
implements the ACE_Connection_Recycling_Strategy interface.
This allows Svc_Handlers to cache themselves with
ACE_Cached_Connect_Strategy when they become idle. It also
allows them to purge themselves from the connection cache when
the Svc_Handlers close down. <br>
Also added ~ACE_Cached_Connect_Strategy that will cleanup up the
connection cache. </li>
</UL>
<P>Future work:
<blockquote>
<em>None currently scheduled.</em>
</blockquote>
<H3>
<A NAME="#VC"></A>How to add IDL files into your Visual C++ projects</H3>
Point of contact: <a href="mailto:nw1@cs.wustl.edu">Nanbor Wang</a>.
<p>Each IDL file generates .h, .i and .cpp files. Here is an
example of adding an IDL file named foobar.idl into a VC project.
<ol>
<li>Create/open the workspace. Create server project and client
project if you haven't had them ready. Add the IDL file
<foobar.idl> and other non-IDL generated files into
both client and server projects.
<li>Added foobarC.h, foobarC.i, foobarC.cpp, foobarS.h, foobarS.i,
and foobarS.cpp into the server project and foobarC.h,
foobarC.i, and foobarC.cpp into the client project.
<li>Now open the project setting window (Project ->
Setting... or just press Alt-F7.) Select the IDL files in
both client and server projects. Choose to set the setting
for "All Configuration." Make sure the "Exclude from build"
under the "General" tab is unchecked.
<li>Click on the "Custom Build" tab. Add this entry as the
build command for IDL files:
<pre>..\..\..\TAO_IDL\tao_idl $(InputName).idl</pre> Notice
that your absolute path to TAO_IDL may vary.
<li>Now add the following entries as "Output file(s)." <pre>
$(InputName)S.h
$(InputName)S.i
$(InputName)S.cpp
$(InputName)C.h
$(InputName)C.i
$(InputName)C.cpp</pre>
Add only one entry in each line.
<li>We are all set. Click OK.
<li>Add foobarC.cpp to client project and foobarC.cpp and
foobarS.cpp to server project.
</ol>
Notice that these procedures only setup the IDL compiler to
perform correctly.<p>
p.s. If anyone knows how to set a default setting in VC so we
don't need to perform these procedures every time a new project
gets set up, please let us know. Thanks.
</BODY>
<hr><P>
Back to the TAO <A HREF="../index.html">documentation index</A>.
<!--#include virtual="/~schmidt/cgi-sig.html" -->
</HTML>
|
