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
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
|
<html>
<!-- $Id$ -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>TAO Real-Time CORBA Features Documentation</title>
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
</head>
<body>
<h2 align="center">Features Documentation</h2>
<p>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
<CODE>$TAO/tests/RTCORBA/</CODE>. We hope to have tutorial-style examples available in
the near future. </p>
<h3>
<a name="enabling">Enabling Real-Time CORBA features</a> </h3>
<p>In order to use features from the Real-Time CORBA 1.0 specification in TAO,
it must be compiled with both <CODE>TAO_HAS_RT_CORBA</CODE> and <CODE>TAO_HAS_CORBA_MESSAGING</CODE> set to <CODE>1</CODE>. These macros are defined in
<CODE>$TAO/tao/orbconf.h</CODE> </p>
<p>By default, both Real-Time CORBA and Messaging are enabled in TAO unless Minimum CORBA support is turned on,
<i>i.e.</i>, <CODE>TAO_HAS_MINIMUM_CORBA</CODE>
is set to <CODE>1</CODE>. </p>
<h3>Migrating from <a name="deprecated"><i>TAO::Client_Priority_Policy</i></a></h3>
<p><i>TAO::Client_Priority_Policy</i> is a proprietary policy that was introduced
before support for Real-Time CORBA 1.0 was available in TAO.
Since standard RTCORBA policies provide equivalent functionality and more, <i>
TAO::Client_Priority_Policy</i> is currently deprecated, and will be completely
removed from TAO before the next minor release. It is disabled by default,
but can be enabled manually, although at the expense of making the functionality
of standard RTCORBA policies not available. <i>TAO::Client_Priority_Policy</i> users should migrate to
standard RTCORBA policies and mechanisms as follows: </p>
<ul>
<li><CODE>TAO::USE_THREAD_PRIORITY</CODE> users should switch to threadpool with lanes
plus <CODE>RTCORBA::CLIENT_PROPAGATED</CODE> priority model.</li>
<li><CODE>TAO::USE_PRIORITY_RANGE</CODE> users should switch to threadpool with
lanes plus <CODE>RTCORBA::CLIENT_PROPAGATED</CODE> priority model plus <i>RTCORBA::PriorityBandedConnectionPolicy</i>.</li>
</ul>
<p>See <a href="#threadpools"> Threadpools</a> and <a href="#valid_configurations">Priority
Policies</a> sections of this document for more information on RTCORBA policies
and mechanisms mentioned above. </p>
<h3><a name="mappings">Priority Mappings </a></h3>
<p>TAO provides two Priority Mappings, Direct and Linear, described below: </p>
<dl>
<dt><b>Direct</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>
<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 <CODE>$TAO/tao/Strategies/Linear_Priority_Mapping.cpp
</CODE>for more details.</dd>
</dl>
<p>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>
<p>By default TAO uses Direct priority mapping and <CODE>SCHED_OTHER</CODE> scheduling
policy. There are two ways for an application to override these settings:
</p>
<ol>
<li><CODE>svc.conf</CODE> 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:<br>
<CODE><br>
static Resource_Factory "-ORBPriorityMapping <em>mapping_type</em>
-ORBSchedPolicy <i> sched_policy</i>"<br>
<br>
</CODE>where valid values for <i> mapping_type</i> are <CODE>linear</CODE>
and <CODE>direct,</CODE> and <em> </em>valid
values for <i> sched_policy</i> are <CODE>SCHED_OTHER</CODE>, <CODE>SCHED_FIFO</CODE> and <CODE>SCHED_RR</CODE>. <br>
</li>
<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.<br>
<br>
Obtaining Priority Mapping Manager:
<br>
<CODE>object = <br>
</CODE>
<CODE>orb->resolve_initial_references ("PriorityMappingManager",
ACE_TRY_ENV);<br>
ACE_TRY_CHECK;<br>
TAO::PriorityMappingManager_var mapping_manager = <br>
TAO::PriorityMappingManager::_narrow (object.in (),
ACE_TRY_ENV);<br>
ACE_TRY_CHECK;<br>
</CODE>
<br>
Overriding priority mapping/policy in effect with another ORB-defined
mapping/policy combination:
<br>
<CODE>#include "tao/Strategies/Linear_Priority_Mapping.h"<br>
#include "tao/Strategies/Direct_Priority_Mapping.h"<br>
...<br>
RTCORBA::PriorityMapping pm = <br>
new TAO_Linear_Priority_Mapping (policy);<br>
</CODE>or
<CODE><br>
new TAO_Direct_Priority_Mapping (policy); <br>
mapping_manager->mapping (pm);<br>
...</CODE><br>
where policy is <CODE>SCHED_OTHER, SCHED_FIFO</CODE> or <CODE>SCHED_RR.</CODE> Priority Mapping
Manager takes the ownership of the priority mapping object. <CODE> <br>
</CODE>
<br>
Overriding the default with user-defined priority mapping:
<br>
<CODE>My_Mapping *foo = new My_Mapping;<br>
mapping_manager->mapping (foo);</CODE>
<br>
where <i>My_Mapping</i> must inherit from <i> RTCORBA::PriorityMapping</i> (a typedef for
<i>
TAO_Priority_Mapping</i> class) located in <CODE>$TAO/tao/Priority_Mapping.h<br>
<br>
</CODE>Obtaining a pointer to the priority mapping object being used by the
ORB:<br>
<CODE>RTCORBA::PriorityMapping *pm =<br>
mapping_manager->mapping ();</CODE>
<br>
Mapping manager retains the ownership of the priority mapping object.</li>
</ol>
<h3>
<a name="defaults">ORB Default Policies</a>
</h3>
<p>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. </p>
<table border="1" width="100%" cellpadding="7">
<tr>
<td width="31%" align="center"><b>Policy</b></td>
<td width="69%" align="center"><b>Default</b></td>
</tr>
<tr>
<td width="31%"><i>ServerProtocolPolicy</i></td>
<td width="69%">All loaded protocols, 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%">Currently none, but will be added once <a href="#threadpools"> Threadpools</a> are
fully supported. </td>
</tr>
<tr>
<td width="31%"><i>PriorityModelPolicy</i></td>
<td width="69%">Currently none, but will be added once <a href="#threadpools"> Threadpools</a> are fully
supported.</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 <CODE>SCHED_OTHER</CODE> scheduling
policy. See <a href="#mappings"> Priority
Mappings</a> section for more details.</td>
</tr>
</table>
<h3><a name="threadpools">Threadpools</a></h3>
<ul>
<li>Initial support for ThreadPools is now available in TAO. Users
can use the standard RT-CORBA APIs to create thread pools. See
<code>$TAO_ROOT/tests/RTCORBA/Thread_Pool</code> for an example.
However, a lot more work needs to go into partitioning ORB resources
among the thread pool lanes before the feature is completely
supported. <p>
<li> Until it is fully supported, follow these steps to obtain
<i>threadpool with lane</i> functionality in TAO:</p>
<ol>
<li>Include <CODE>"tao/Pool_Per_Endpoint.h"</CODE> into the server's
driver, and substitute the traditional <br>
<CODE>orb->run (ACE_TRY_ENV);</CODE> <br>
with <br>
<CODE>TAO_Pool_Per_Endpoint pool (orb.in
(), <i>policy</i>, <i>lane_size</i>, <i>flags</i>);<br>
pool.run (ACE_TRY_ENV);</CODE> <br>
where <i> policy</i> is <CODE>SCHED_OTHER</CODE>, <CODE>SCHED_FIFO</CODE> or <CODE>SCHED_RR,
</CODE><i>lane_size</i> is the number of threads in each lane, and <i> flags</i>
are flags used for thread creation. </li>
<li>Specify the following in the server's <CODE>svc.conf</CODE>: <br>
<CODE>static Advanced_Resource_Factory "-ORBReactorType tp -ORBReactorRegistry per-priority"</CODE></li>
<li>Specify endpoint for each lane using the <CODE>-ORBendpoint</CODE> command-line
option. For example, for a threadpool with three lanes with priorities 40, 50
and 60, you would specify:<br>
<CODE>-ORBendpoint iiop:///priority=40 -ORBendpoint iiop:///priority=50
-ORBendpoint iiop:///priority=60</CODE></li>
<li>Do not use <i>RTCORBA::ThreadpoolPolicy</i></li>
</ol>
<p>For an example of following the steps above, see
<CODE>$TAO/tests/RTCORBA/Server_Declared</CODE>. The limitation
of this method is that the threadpool is global, <i>i.e.</i>,
available to all POAs in the ORB. There is no way to create
additional threadpools and associate them with selected POAs.
<i>Threadpool without lanes</i> functionality is not yet
available.</p>
<p>Threadpool threads are the ones doing all the work in the ORB: no
additional internal threads are created by the ORB for such tasks as
I/O. </p>
<p>More documentation will be available here once threadpools are
fully supported. Also, see <a
href="#valid_configurations">Priority Policies</a> section, which
contains information on how threadpools interact with <i>
PriorityBandedConnectionPolicy</i> and <i>PriorityModelPolicy</i>.</p>
</ul>
<h3><a name="valid_configurations">Priority Policies</a></h3>
<p>The table below lists all possible configurations of policies involving priorities,
and summarizes the semantics of each configuration.</p>
<table border="1" width="100%" cellpadding="4">
<tr>
<td width="33%" align="center"><b>Configuration</b></td>
<td width="33%" align="center"><b>Valid values</b></td>
<td width="34%" align="center"><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%">Once threadpools are fully supported, there will be an ORB default for
<i>PriorityModelPolicy</i>,<i> i.e.</i>, this configuration will not
exist.</td>
</tr>
<tr>
<td width="33%">Threadpool with lanes +<br>
<CODE>SERVER_DECLARED</CODE> 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%">Each object is serviced at its declared priority for the
full duration of request,<i> i.e.</i>, including I/O and demultiplexing.</td>
</tr>
<tr>
<td width="33%">Threadpool with lanes + <CODE>CLIENT_PROPAGATED</CODE> 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%">Each object is serviced at client-propagated priority
for the full duration of request, <i>i.e.</i>, including I/O and demultiplexing.</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%">Once threadpools are fully supported, there will be an ORB default for
<i>PriorityModelPolicy</i>,<i> i.e.</i>, this configuration will not
exist. </td>
</tr>
<tr>
<td width="33%">Threadpool with lanes +<br>
<CODE>SERVER_DECLARED</CODE> 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). In addition, each of the priority bands
must cover at least one of the threadpool lane priorities. </td>
<td width="34%">Each object is serviced at the priority that falls into the
same priority band range as the object's declared priority, for the full
duration of request.</td>
</tr>
<tr>
<td width="33%">Threadpool with lanes +<br>
<CODE>CLIENT_PROPAGATED</CODE> 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%">Application request processing takes place at the client-propagated priority. I/O processing for a request takes place at the
priority that falls into the same priority band range as the
client-propagated priority.</td>
</tr>
<tr>
<td width="33%">Threadpool without lanes,<br>
no <i>PriorityModelPolicy</i>,<br>
no <i> PriorityBandedConnectionPolicy</i></td>
<td width="33%">Invalid</td>
<td width="34%">Once threadpools are fully supported, there will be an ORB default for
<i>PriorityModelPolicy</i>,<i> i.e.</i>, this configuration will not
exist.</td>
</tr>
<tr>
<td width="33%">Threadpool without lanes +<br>
<CODE>SERVER_DECLARED</CODE> model,<br>
no <i> PriorityBandedConnectionPolicy</i></td>
<td width="33%">All valid CORBA priorities.<br>
(Threadpools without lanes are not yet supported.)</td>
<td width="34%">Request I/O and demultiplexing happen at threadpool
priority. Application level processing is done at declared object
priority.</td>
</tr>
<tr>
<td width="33%">Threadpool without lanes + <CODE>CLIENT_PROPAGATED</CODE> model, <br>
no <i> PriorityBandedConnectionPolicy</i></td>
<td width="33%">All valid CORBA
priorities. <br>
(Threadpools without lanes are not yet supported.)</td>
<td width="34%">Request I/O and demultiplexing happen at threadpool
priority. Application level processing is done at 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%">Once threadpools are fully supported, there will be an ORB default for
<i>PriorityModelPolicy</i>, <i>i.e.</i>, this configuration will not
exist.</td>
</tr>
<tr>
<td width="33%">Threadpool without lanes +<br>
<CODE>SERVER_DECLARED</CODE> 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).<br>
(Threadpools without lanes not yet supported.) </td>
<td width="34%">Request I/O and demultiplexing happen at threadpool
priority. Application level processing is done at server-declared object
priority. The only purpose of the <i> PriorityBandedConnectionPolicy</i> is
to restrict allowed server-declared priority values.</td>
</tr>
<tr>
<td width="33%">Threadpool without lanes +<br>
<CODE>CLIENT_PROPAGATED</CODE> model +<br>
<i>
PriorityBandedConnectionPolicy</i></td>
<td width="33%">Priority of the invoking client thread must fall into one of the priority
bands. <br>
(Threadpools without lanes not yet supported.)</td>
<td width="34%">Request I/O and demultiplexing happen at threadpool
priority. Application level processing is done at client-propagated
priority. The sole purpose of the <i> PriorityBandedConnectionPolicy</i> in
this configuration is to restrict allowed client-propagated priority
values.</td>
</tr>
</table>
<h3><a name="explicit_bind">Explicit Binding</a></h3>
<p><CODE>Object::_validate_connection ()</CODE> 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 <CODE>_validate_connection
()</CODE> for <b>all</b> <i>thread/ priority/ object</i> combinations that will
be used.</p>
<h3><a name="protocols">Protocol Policies</a></h3>
<p>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.</p>
<ul>
<li><b>IIOP<br>
</b>
Protocol <i> ProfileId</i>: 0<br>
Transport properties interface name: <i> RTCORBA::TCPProtocolProperties</i> (standard)<br>
Implementation class name: <i> TAO_TCP_Properties</i><br>
<table border="1" height="150" cellpadding="4">
<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 height="19" align="left"><CODE>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</CODE></td>
</tr>
<tr>
<td height="19">long <i> recv_buffer_size</i></td>
<td height="19" align="left"><CODE>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</CODE></td>
</tr>
<tr>
<td height="19">boolean <i> keep_alive</i> (not yet supported)</td>
<td height="19" align="left"><CODE>1</CODE> </td>
</tr>
<tr>
<td height="19">boolean <i> dont_route</i> (not yet supported)</td>
<td height="19" align="left"><CODE>0</CODE> </td>
</tr>
<tr>
<td height="19">boolean <i> no_delay</i></td>
<td height="19" align="left"><CODE>1</CODE></td>
</tr>
</table> <br>
</li>
<li><b> UIOP</b><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> <br>
<table border="1" 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><CODE>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</CODE></td>
</tr>
<tr>
<td> long <i> recv_buffer_size</i></td>
<td><CODE>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</CODE></td>
</tr>
</table><br>
</li>
<li><b>SHMIOP</b><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><br>
<table border="1" 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>
</li>
</ul>
<br><p>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>:<br>
<CODE><br>
class TAO_Protocol_Properties_Factory<br>
{<br>
public:
<br>
<br>
static RTCORBA::ProtocolProperties* <br>
create_transport_protocol_property
(IOP::ProfileId id);<br>
<br>
static RTCORBA::ProtocolProperties* <br>
create_orb_protocol_property (IOP::ProfileId id);<br>
};</CODE>
</p>
<p>Alternatively, concrete <i> ProtocolProperties</i> implementation classes can be
instantiated directly as needed. </p>
<p>The table below summarizes how protocol policies overrides affect protocol
selection and configuration in TAO.</p>
<table border="1" 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: <CODE>-ORBSndSock</CODE> and <CODE>-ORBRcvSock</CODE> ORB options
have no effect when RTCORBA is enabled.</p>
<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.</p>
<hr>
<p><i>Last Modified: </i>
<i>
$Date$ </i></p>
</body>
</html>
|
