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
|
<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, a RT-CORBA client application must link with the RTCORBA
library; a RT-CORBA server application must link with the RTCORBA
library and the RTPortbaleServer libraries. Since some features in
RT-CORBA depend on the messaging specification, all code must be
compiled with <CODE>TAO_HAS_CORBA_MESSAGING</CODE> set to
<CODE>1</CODE>. This 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><a name="mappings">Priority Mappings </a></h3>
<p>TAO provides three Priority Mappings: Direct, Linear, and
Continuous. If no mapping is specified, Direct Priority Mappings will
be used. Note that Continuous was previously referred to as
Direct.</p>
<dl>
<dt><b>Direct</b></dt>
<dd>Maps CORBA priorities directly to native priorities.</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_ROOT/tao/Strategies/Linear_Priority_Mapping.cpp </CODE>for
more details.</dd>
<dt><b>Continuous</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>
</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 RT_ORB_Loader "-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 = orb->resolve_initial_references ("PriorityMappingManager");<br>
TAO::PriorityMappingManager_var mapping_manager = <br>
TAO::PriorityMappingManager::_narrow (object.in ());<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>
<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. <br>
<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 protocols that are loaded by the ORB by
default (e.g., IIOP) and any explicitly specified by the user
(e.g., SHMIOP), 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%">None. If no ThreadpoolPolicy policy is specified
during POA creation, the default thread-pool will be used for that
POA.</td>
</tr>
<tr>
<td width="31%"><i>PriorityModelPolicy</i></td>
<td width="69%">None</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>ThreadPools are now fully supported. Endpoint priorities are no
longer supported.</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%">None.</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%">All processing is done at the servant's priority.</td>
</tr>
<tr>
<td width="33%">Threadpool with lanes +<br>
<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%">All processing is done at the client-propagated priority.</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%">None.</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 be equal to the
priority of one of the threadpool lanes. (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%">All processing is done at the servant's priority.</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%">All processing is done at the threadpool lane
priority which matches the priority band used by the
client.</td>
</tr>
<tr>
<td width="33%">Threadpool without lanes,<br>
no <i>PriorityModelPolicy</i>,<br>
no <i> PriorityBandedConnectionPolicy</i></td>
<td width="33%">All valid CORBA priorities.</td>
<td width="34%">All processing is done at the threadpool's default
priority.</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.</td>
<td width="34%">Request I/O and demultiplexing processing is done
at the threadpool's default priority. Application level
processing is done at the servant's 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.</td>
<td width="34%">Request I/O and demultiplexing processing is done
at the threadpool's default priority. Application level
processing is done at the 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%">None.</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).</td>
<td width="34%">Request I/O and demultiplexing processing is done
at the threadpool's default priority. Application level
processing is done at the servant's priority. In this case,
<i>PriorityBandedConnectionPolicy</i> is used to restrict the
allowed priority values for the servant.</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.</td>
<td width="34%">Request I/O and demultiplexing processing is done
at the threadpool's default priority. Application level
processing is done at the client-propagated priority. In this
case, <i>PriorityBandedConnectionPolicy</i> is used to restrict
the allowed priority values for the client.</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>
|
