| blob | 09552d66d6d61378f3228a12ee1cd5d324c7defb |
2 <html>
3 <head>
4 <!-- -->
6 </head>
8 <hr>
9 <p></p>
12 <ul>
16 <ul>
19 <ol>
21 </li>
25 Selection </a> </li>
28 </ol>
29 </li>
31 <ol>
33 <ol>
36 </ol>
37 </li>
43 </ol>
44 </li>
45 </ul>
46 </li>
47 </ul>
48 <hr>
50 TAO is a highly flexible ORB that contains a wide range of ORB
51 configuration options. One or more of these options can be combined
52 to meet various application requirements, such as low-latency,
53 predictable real-time behavior, or small memory footprint. TAO's ORB
54 configuration options are managed by an object-oriented framework
55 within the ORB Core that contains the following types of entities:
56 <ul>
58 differing from their default settings. Examples include setting the
59 size of a Portable Object Adapter (POA)'s active object map or
60 configuring the ORB to print debugging information as it processes
61 requests. A few of these are run-time options, while a majority of
62 them are compile-time options.
63 <p></p>
64 </li>
68 used to regulate access to certain parts of the ORB.
69 <p></p>
70 </li>
72 entities to perform various ORB tasks, such as connection management,
73 concurrency, and demultiplexing.
74 <p></p>
75 </li>
77 many resources and strategies into a manageable number of factories
78 that can be (re)configured into the ORB conveniently and consistently
79 by ORB and application developers.
80 <p></p>
81 </li>
82 </ul>
83 The set of TAO ORB configuration options that are represented by the
84 settings, resources, strategies, and factories can be specified via
87 <ul>
89 interoperable object reference (IOR) and port number of TAO's Naming
90 Service, Trading Service and Implementation Repository. They are
91 limited in flexibility and don't provide the most important
92 configuration hooks necessary to configure TAO for real-time and
93 high-performance applications.
94 <p></p>
95 </li>
97 initialization
101 through
102 environment variables can also be manipulated through command-line
103 options. Command-line options override the environment variable
104 settings if both are enabled.
105 <p></p>
106 </li>
108 to statically and dynamically configure components into middleware and
109 applications. The information comprising the names of these
110 components and their corresponding options are specified in a service
111 configurator file, whose default file name is
114 configurator processing is done after all the command-line options
115 have been parsed.
116 </li>
117 </ul>
118 <p></p>
120 <p></p>
122 TAO's command-line options are useful when there's a fixed set of
123 configuration options, each of which has a predefined list of
124 alternative values. Conversely, TAO's service configurator file is
125 useful for configuring a broader range of resources, strategies, and
126 factories. Generally speaking, the service configurator file allows
127 the user to <br>
128 <ul>
130 strategies and factories) based on the predefined list of alternatives
131 that TAO provides or
132 <p> </p>
133 </li>
134 <li>extend the existing factories by providing user-defined
135 components and dynamically load them through the service configurator
136 mechanism. </li>
137 </ul>
138 Additionally, the service configurator mechanism allows an
139 application to control the behavior of the ORB using extensible
140 configuration information. In general, the command-line configuration
141 options are provided in TAO
142 in order to leverage preexisting configuration settings that are
143 compiled within the TAO ORB. Users are not allowed to change these
144 settings. In contrast, those options that require more flexible
145 manipulation of resources, strategies, and factories must be
147 result, the command-line options and the service configurator options
148 cannot be used interchangeably.
149 <p></p>
150 <hr>
152 This section provides a detailed overview of how to configure TAO's
153 options using environment variables, command-line options, and service
154 configuration files.
155 <p></p>
158 As mentioned earlier, environment variables have a limited use in TAO
159 ORB configuration. The currently supported environment variables are
160 listed below. They are used to specify the IOR and port numbers for
161 three of TAO's ORB services.
162 <blockquote>
163 <p>
165 <tbody>
166 <tr>
169 </tr>
170 <tr>
172 <td>Specifies which port the Naming Service is listening on for
173 multicast requests. </td>
174 </tr>
175 <tr>
177 <td>Specifies which port the Trading Service is listening on
178 for multicast requests. </td>
179 </tr>
180 <tr>
182 <td>Specifies which port the Implementation Repository is
183 listening on for multicast requests. </td>
184 </tr>
185 </tbody>
186 </table>
187 </p>
188 </blockquote>
189 In addition to being able to define the port where these known services
190 are listening for multicast requests, as above, it is possible to set
191 an environment variable that specifies the IOR of any named service.
194 will have a similar effect to defining an -ORBInitRef value on the
195 command line (see below). Any value set as a command line -ORBInitRef
196 option will override any value set as an environment variable for the
197 same service name.<br>
198 <br>
199 In general, setting environment variables is not particularly portable
200 or convenient, which is why users can also set these options via
201 command-line options. The example shown below demonstrates a
202 deployment scenario where the client and Naming Service run on the
203 same host:
204 <p><code>
205 % NameService.exe -ORBEndpoint iiop://localhost:12345
206 </code></p>
207 <p><code>
208 % client.exe -ORBInitRef NameService=corbaloc:iiop:localhost:12345/NameService
209 </code></p>
211 <p></p>
214 TAO's run-time behavior can also be controlled by passing options via
216 initialization options are commonly passed into the program from the
219 <p>Command-line options can be classified into the following groups
220 according to their purposes:</p>
221 <ol>
227 </li>
228 </ol>
229 We describe each of these five groups of options below.
230 <p></p>
232 The options described below influence the behavior of the ORB's <a
234 the command-line options
235 have been parsed. </a>
236 <p></p>
240 <tbody>
241 <tr>
244 </tr>
245 <tr>
247 <td>Specifies the name of the file used to read service
248 configuration directives via the Service Configurator framework. By
249 default, a service configurator-based application will look for a file
251 </tr>
252 <tr>
254 <td>Specifies a service configuration directive, which is
255 passed to the Service Configurator. You can pass multiple of these
256 options on the same command-line. </td>
257 </tr>
258 <tr>
262 service configurator class.
263 </td>
264 </tr>
265 <tr>
268 side-effect of not initializing the ACE Service Configurator
269 framework or registering the SIGHUP signal.
270 </td>
271 </tr>
272 <tr>
277 </td>
278 </tr>
279 <tr>
282 context. By default, all ORBs share a common configuration context. This
283 is defined by a Service Repository that contains service objects, such
284 as the resource factory. In some cases multiple ORBs may be dynamically
285 loaded and as such may wish to have distinct configurations. Passing the
287 ORB with a local configuration context will be used by that ORB in place
288 of any default service object. The final variation is that of shared
290 the ORB to share the local configuration of another ORB as identified with
292 </td>
293 </tr>
294 </tbody>
295 </table>
296 </p>
297 </blockquote>
299 During application development and testing, it is often necessary to
300 control the amount and type of debugging information output by the
301 ORB. The following options enable TAO to provide debugging
302 information at several levels of granularity.
303 <p></p>
304 <blockquote>
305 <p>
307 <tbody>
308 <tr>
311 </tr>
312 <tr>
314 <td>Instructs the ORB to print debugging messages from the
315 service configurator framework. This option does not have a value but
316 is used as a toggle to enable or disable debugging messages.</td>
317 </tr>
318 <tr>
320 <td>Control the level of debugging in the ORB. Higher numbers
322 </tr>
323 <tr>
325 <td>Controls the amount of status data printed on each line of
326 the debug log. Higher numbers generate more output.
328 </tr>
329 <tr>
333 </tr>
334 <tr>
337 <td>Causes use of ORB reactor for dispatching timer events to
338 ACE_Logging_Strategy configured as a dynamic service with name
340 rotation. </td>
341 </tr>
342 <tr>
345 style (default) is the conventional CORBA object reference, whereas the
347 </td>
348 </tr>
349 </tbody>
350 </table>
351 </p>
352 </blockquote>
355 throughput and reduce latency</a> by optimizing certain stages of
356 request processing in the ORB. The following command-line options
357 control various optimizations during request processing.
358 <p></p>
359 <blockquote>
360 <p>
362 <tbody>
363 <tr>
366 </tr>
367 <tr>
370 tradeoff between copy vs. no copy marshaling of octet sequences. If an
373 current message block contains enough space for it -- the octet
374 sequence is copied instead of appended to the CDR stream. </td>
375 </tr>
376 <tr>
379 outgoing GIOP request/reply. The request or reply
380 being sent will be fragmented, if necessary.</td>
381 </tr>
382 <tr>
386 (default), objects in the same process will be treated as collocated.
389 treated as collocated. </td>
390 </tr>
391 <tr>
393 </td>
394 <td>Specifies what type of collocated object to use. If not specified
395 the TAO_DEFAULT_COLLOCATION_STRATEGY default (default on thru_poa) is used.
397 implementation that respects POA's current state and policies. When
399 collocated objects become direct calls to servant without checking
401 strategy, your interfaces must be compiled with the <code><a
404 TAO tries to perform the best possible collocation, first <code>direct</code> collocation if possible,
406 </tr>
407 <tr>
409 </td>
410 <td>Specifies what happens when making collocated AMI invocations.
411 When 1 (default) an AMI call will be done on a collocated
412 servant and the client thread will be used to invoke the
413 servant, when 0 the collocated call will be converted
414 to a remote call so that a different thread could be used
415 to execute the servant.</td>
416 </tr>
417 <tr>
421 enabled.</td>
422 </tr>
423 <tr>
426 receive buffer as a positive, non-zero integer. If not specified, the <code>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</code>
427 default is used.</td>
428 </tr>
429 <tr>
432 send buffer as a positive, non-zero integer. If not specified, the <code>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</code>
433 default is used.</td>
434 </tr>
435 <tr>
438 the ORB does not generate the OMG standardized profile components, such
439 as the ORB type and code sets. Notice that the presence of this
440 components is optional in GIOP 1.1 The default value is controlled by a
442 </tr>
443 <tr>
446 does not include the codeset negotiation subsystem, TAO_Codeset. This yields
447 a somewhat smaller runtime footprint as well as a smaller IOR. However this
448 also removes the ability to interoperate with ORBs on systems using
449 alternative character or wide charater encodings. The default value may be set
453 TAO statically and get the codeset negotiation feature, two additional steps
454 are needed to ensure the TAO_Codeset library is linked in and initalized. Add the MPC feature "negotiate_codesets=1" to the default.features file and regenerate your makefiles, and add <CODE>#include "tao/Codeset/Codeset.h"</CODE> somewhere in your application source, such as the cpp file containing your main.</td>
455 </tr>
456 <tr>
459 controls whether TAO's ``single read optimization'' is used when
461 ORB will do two reads to read a request: one reads the request header
464 read the entire request. If more than one request is read they will be
465 queued up for processing later.
467 provide better performance. In the case of Real-time CORBA, however, this
470 request is queued, and (3) the ORB uses its Reactor's notification
471 mechanism to wake up the follower threads. If at the same time,
472 however, new requests arrive on others sockets of higher priority the
473 lower priority queued message will be processed before the newly
474 arrived higher priority request since Reactor notifications are given
475 preferences over normal I/O, thereby causing priority inversion.</p>
476 </td>
477 </tr>
478 <tr>
479 <td><code>-ORBDisableRTCollocation</code> <em>boolean (0|1)</em></td> <td><a name="-ORBDisableRTCollocation"></a>This
480 option controls whether the application wants to use or discard
481 RT collocation decisions made by the RT ORB. A value of
483 collocation decisions implemented in the default ORB, which is
484 useful for applications using the RT ORB and doesn't want
485 to use the RT collocation decisions but fallback on the default
486 decisions for better performance. The default value is
488 </tr>
489 <tr>
492 to satisfy some of its needs for heap storage, as it is often more
493 efficient than using the platform's default memory allocator. The local
494 pool will always grow as large as necessary to satisfy memory allocations,
495 but it will never shrink. This means that sometimes a process can retain
496 memory that it no longer needs. If the default allocator is used then
497 TAO gives memory back as soon as it is not needed which allows for better
498 resource sharing at the expense of memory deallocation time.
500 default allocator for the platform.</p>
502 local memory pool.</p>
503 <p> This option defaults to the compile-time option specified by
505 </td>
506 </tr>
507 </tbody>
508 </table>
509 </p>
510 </blockquote>
512 TAO can send and receive requests and replies using various <a
515 The following options manage connections and control protocol
516 selection within a TAO application.
517 <p></p>
518 <blockquote>
519 <p>
521 <tbody>
522 <tr>
525 </tr>
526 <tr>
529 amount of time to wait before attempting to accept new
530 connections in the event that a transient error occurs (such as
531 running out of file handles). A delay of zero indicates that
532 accepting should not be attempted again after the transient error
533 and the handler will be removed from the reactor.
534 </td>
535 </tr>
536 <tr>
539 resolution of initial references not explicitly specified with
541 ('|' for the UIOP pluggable protocol) and a simple object key, forms a
542 new URL to identify an initial object reference. The URL prefix format
543 currently supported is based on the standard <code><A href="INS.html#corbaloc">corbaloc</A></code>
545 Service. </a></td>
546 </tr>
547 <tr>
550 decimal notation for addresses. This option can be used to workaround
551 broken DNS implementations and may also reduce the time spent resolving
553 Windows since DNS is often misconfigured there. On other platforms
555 more flexible address notations for IORs.</td>
556 </tr>
557 <tr>
563 selected port is used. If there are no available ports in the range, the ORB
564 will throw a TRANSIENT exception. </td>
565 </tr>
566 <tr>
573 </tr>
574 <tr>
577 prevent the ORB from looking up the peer's hostname when accepting an incoming
580 </tr>
581 <tr>
586 deprecated in later versions on TAO since the CORBA
588 option instead. </font> </td>
589 </tr>
590 <tr>
594 clients running on a multihomed host to pick a local
595 network/interface to communicate with a remote target.
596 When TAO attempts to establish a connection with a host
597 matching targetNetwork, then it will use the local ip address
598 matching localNetwork. Simple wildcards can be used for both
599 parameters, and multiple preferred interfaces can be specified
600 using comma separators (no embedded spaces allowed) or additional ‑ORBPreferredInterfaces directives.
601 For example, for a machine with two network cards
605 Or to force all communication to first try to
608 with the value read from an IOR.
610 will be matched with the local ip interfaces.
611 </tr>
612 <tr>
619 cannot be made using a preferred interface, TAO will
621 Note: If none of the preferred interfaces apply to an outgoing connection
622 then they will not be enforced. For this option to have
623 any effect, therefore, the connection through a legal preferred interface must fail.
624 </tr>
625 <tr>
628 that the SO_KEEPALIVE option is set on TCP sockets used by IIOP.
630 </td>
631 </tr>
632 <tr>
635 that the SO_DONTROUTE option is set on TCP sockets used by IIOP.
637 </td>
638 </tr>
639 <tr>
642 set the linger timeout on a TCP socket before closing it. Hence,
643 this option is only useful when using IIOP. The
645 maximum signed integer value for the particular platform on which
646 TAO is running.
647 </td>
648 </tr>
649 <tr>
652 specify the TTL (IPv4) or hop limit (IPv6) value used when datagrams are
653 sent over a socket. The default is the one selected by the Operating System.
655 maximum signed integer value for the particular platform on which
656 TAO is running. Currently this feature works in IIOP, DIOP, SCIOP, and MIOP.
657 </td>
658 </tr>
659 <tr>
662 specify that the IP_MULTICAST_LOOP / IPV6_MULTICAST_LOOP option is set on
664 </td>
665 </tr>
666 <tr>
669 introduced with the CORBA <a
671 Reference Template</A> (ORT) specification. It instructs a
672 server ORB to listen for requests on the interface specified
674 specifies the endpoints that the default thread pool listens
675 to. TAO endpoints are specified using a URL style format. An
676 endpoint has the form:
677 <blockquote><code>protocol://V.v@addr1,...,W.w@addrN
680 address. An example of an IIOP endpoint is:
682 </code></blockquote>
684 Sets of endpoints may be specified using multiple
686 endpoints with a semi-colon (;). For example,
688 -ORBListenEndpoints uiop:///tmp/mylocalsock
690 equivalent to: <blockquote><code>-ORBListenEndpoints
692 </code></blockquote> Notice the single quotes (') in the
693 latter option specification. Single quotes are needed to
694 prevent the shell from interpreting text after the semi-colon
695 as another command to run. <p>If an endpoint is specified
697 <blockquote><code>-ORBListenEndpoints uiop://
698 -ORBListenEndpoints shmiop:// </code></blockquote> then a
699 default endpoint will be created for the specified
700 protocol. <p>
703 how to specify endpoints.
704 </td>
705 </tr>
706 <tr>
709 <a
712 deprecated in later versions on TAO.</font>
713 </td>
714 </tr>
715 <tr>
719 user to specify endpoints for thread pools and lanes. This
720 option is only meaningful when used with Real-time CORBA and
721 only makes sense when the thread pools and lanes are created in the
722 same order across server incarnations. See <a
724 option on how to specify endpoints. An example is:
728 specifies the third lane of that thread pool. Note that
735 <p>Sets of endpoints may be specified using multiple
737 endpoints with a semi-colon (;). For example,
744 </code></blockquote> Notice the single quotes (') in the
745 latter option specification. Single quotes are needed to
746 prevent the shell from interpreting text after the semi-colon
747 as another command to run. <p>If an endpoint is specified
751 then a default endpoint will be created for the specified
752 protocol.
753 </td>
754 </tr>
755 <tr>
757 <td>Specifies which port the Implementation Repository is
758 listening on for multicast requests. By default, the <code>TAO_DEFAULT_IMPLREPO_SERVER_REQUEST_PORT</code>
760 </tr>
761 <tr>
764 arbitrary object reference for an initial service. The IOR could be in
770 The mappings specified through this argument override the ORB
773 any of the above formats. </td>
774 </tr>
775 <tr>
779 is of the form <code>ip-number:port-number</code> (<em>e.g.</em>, <code>"tango.cs.wustl.edu:1234"</code>
781 in the end_point it is assumed to be a port number, with the IP address
783 </tr>
784 <tr>
786 <td>Specifies which port the Naming Service is listening on for
789 </tr>
790 <tr>
793 <td> Specifies
794 to which port the Trading Service is listening on for multicast
797 </tr>
798 <tr>
802 should be used for notification of startup and shutdown and object
803 references should be changed to use the Implementation Repository also (N.B.
805 </tr>
806 <tr>
811 is set. The default is true. </td>
812 </tr>
813 <tr>
816 specify the ORB attempt to connect simultaneously to all endpoints
817 listed in profiles, rather than stepping through individual endpoints,
818 trying and possibly failing, before moving on to the next. For this
819 feature to work, the server must be using shared profiles.
821 </td>
822 </tr>
823 <tr>
826 This option allows multiple implicit or explicit endpoints to be
827 combined into a single profile for a given protocol rather than using
828 multiple profiles. For IIOP in non RTCORBA environments, the CORBA
830 used to encode the combined endpoints. Processses using RTCORBA and
831 priority banded connections will continue to generate Profiles with
833 This options is disabled by default.
834 </td>
835 </tr>
836 <tr>
839 connection attempts, this option defines the number of milliseconds to
840 delay when polling previously started connection attempts. If a server
841 is likely to be busy, this client side option will help avoid creating
842 redundant connections that must be accepted, only to be closed a moment
843 later. However, if the first reachable endpoint is far down the list,
844 this option will increase the delay before that endpoint is reached.
846 </td>
847 </tr>
848 <tr>
852 endpoint selector for client connections to first attempt to
853 connect any IIOP endpoints from a provided IOR specifying
854 IPv6 interfaces. Only when none of these can be found or sucessfully connected IPv4
856 <p>
858 </td>
859 </tr>
860 <tr>
866 <li>prevent (depending on availability of IPV6_V6ONLY socket option)
867 or block IPv6 to IPv4 connections</li>
868 <p>
869 This option directs the default endpoint selector for client connections
870 to only attempt to connect any IIOP endpoints from a provided IOR specifying
871 IPv6 interfaces. Any available IPv4 interfaces will be
873 <p>
874 This option is only available for IPv6 enabled builds of TAO (ACE_HAS_IPV6).
875 </td>
876 </tr>
877 <tr>
881 connections on IPv6 link local addresses.
883 <p>
884 This option is only available for IPv6 enabled builds of TAO (ACE_HAS_IPV6).
885 </td>
886 </tr>
887 <tr>
890 (true) it directs a client ORB to use any client-side (sender) configured ZIOP compression
891 without having seen any server-side (listener) ZIOP available compressor's list policies.
892 The CORBA Compressed GIOP (ZIOP) V1.0 specification states that the Server publishes
893 its available (i.e. allowable) compressors in the IOR of each server object. This
894 option allows ZIOP to be used with MIOP and/or CORBALOCs that have no such
895 compression list policies embedded. The client simply has to trust that the server is
896 configured to allow its highest priority compressor to be used. Any servers
897 that cannot decompress the client's used ZIOP compressor will reject the
898 request as they simply cannot decode or handle it (client-side (sender) comms will simply
899 timeout or lock-up for any such incorrect two-way requests, or be oblivious
900 to the failure for any such incorrect one-way requests). The default
902 and conform to the ZIOP specification; but this can be changed by adding
903 <CODE>#define TAO_ALLOW_ZIOP_NO_SERVER_POLICIES_DEFAULT true</CODE> to TAO's <CODE>config.h</CODE>
904 </td>
905 </tr>
906 </tbody>
907 </table>
908 </p>
909 </blockquote>
911 In cases such as connection timing issues or a load balancing server
912 is temporarily not able to handle requests, it may be desirable to have
913 the ORB transparently retry an invocation a maximum number of times
914 until a successful invocation is made. To support this, a set of
915 parameters can be used to cycle over base and location forwarded
916 profiles until an invocation is successful. When cycling over
917 profiles and the first base profile is to be used, a user-defined
918 delay is made before retrying.
919 <p></p>
920 These parameters are used in the following situations:
921 <p></p>
922 <ul>
923 <li>Initial connection: If the connection to a server would result
924 in a TRANSIENT exception being thrown, cycle over profiles no more than the value of
925 the -ORBForwardOnTransientLimit option before throwing the exception.
926 <p></p>
927 </li>
928 <li>Waiting for a reply from the server: When using the IIOP protocol,
929 on many platforms if zero bytes is read as the server's reply, this could
930 indicate that the server may have had a disorderly shutdown or the
931 connection to the server was abruptly terminated. In this case
932 cycling through the profiles to retry the request will not exceeding the
933 value of -ORBForwardOnReplyClosedLimit. If for example the Implementation
934 Repository and Activator are used to start the server then this cycling could be
935 used to give the server enough time to re-launch. When this option is
936 used the -ORBForwardOnTransientLimit option should also be used to
937 avoid exceptions being thrown when trying to reestablish a connection.
938 <b>Note that because it is not known if the request was sent, this
939 could result in the request being processed more than one by the
940 server. Therefore this option should be used with care.</b>
941 This is why, although a COMM_FAILURE exception is normally thrown in this case,
942 this option is kept distinct from -ORBForwardOnCommFailureLimit
943 discussed below.
944 <p></p>
945 <li>Server sends an exception as a reply: A reply is received
946 and it is checked if it is an exception. If the exception is
947 of type COMM_FAILURE with completion status of COMPLETED_NO, then
948 the profiles will be cycled no more than the value of option
949 -ORBForwardOnCommFailureLimit until a successful reply is
950 received. Similar retries can be applied to TRANSIENT exceptions
951 (-ORBForwardOnTransientLimit), OBJECT_NOT_EXIST exceptions
952 (-ORBForwardOnObjectNotExistLimit), and INV_OBJREF exceptions
953 (-ORBForwardOnInvObjrefLimit).
954 <p></p>
955 </li>
956 </ul>
958 The retry options are given in the table below. Note that for
959 backward compatibility, the -ORBForward* options described in the
961 However, if any option in this section is used, then any
962 -ORBForward* option given in the Miscellaneous Options
963 section is ignored.
964 <p></p>
966 These options can also be used in the list of
968 in the service configurator file.
969 Using the service configurator file can help insure these
970 options are uniformly applied across multiple clients by
971 having them use the same configurator file.
973 <blockquote>
974 <p>
976 <tbody>
977 <tr>
980 </tr>
981 <tr>
983 <td>Use this option to cycle through profiles when
984 establishing a connection with a server or when a
985 server replies to a request with a TRANSIENT
986 exception.
988 </tr>
989 <tr>
991 <td>Use this option to cycle through profiles when a
992 server replies to a request with a COMM_FAILURE
993 exception.
995 </tr>
996 <tr>
998 <td>Use this option to cycle through profiles when a
999 server replies to a request with a OBJECT_NOT_EXIST
1000 exception.
1002 </tr>
1003 <tr>
1005 <td>Use this option to cycle through profiles when a
1006 server replies to a request with a INV_OBJREF
1007 exception.
1009 </tr>
1010 <tr>
1012 <td>Use this option to cycle through profiles when it has
1013 been detected that a connection is closed when reading a server reply
1014 and having the server possibly process the reqest more than once
1015 is acceptable. This option currently does not work under FreeBSD.
1017 If this option is used then -ORBForwardOnTransientLimit should
1018 also be used to avoid a TRANSIENT exception being thrown.
1019 </td>
1020 </tr>
1021 <tr>
1023 <td>Defines the number of milliseconds to delay while
1024 cycling through profiles when the first base profile
1027 </tr>
1028 </tbody>
1029 </table>
1030 </p>
1031 </blockquote>
1035 Options in this category don't control the behavior of the ORB in
1036 terms of resouces or strategies. Instead, they are helper options
1037 provided for specific application requirements.
1038 <blockquote>
1039 <p>
1041 <tbody>
1042 <tr>
1045 </tr>
1046 <tr>
1051 coexisting ORBs (when there is more than one ORB).</td>
1052 </tr>
1053 <tr>
1058 </tr>
1059 <tr>
1062 run as a background process. Note, that this changes the working directory to
1063 be the root directory "/". This especially affects relative paths specified at the command line.
1064 This option is only meaningful on OS platforms that support daemonization.</td>
1065 </tr>
1066 <tr>
1070 which means the request is not forwarded upon OBJECT_NOT_EXIST exception.
1071 </td>
1072 </tr>
1073 <tr>
1076 receives OBJECT_NOT_EXIST exception reply. If it receives one of the exceptions
1077 (OBJECT_NOT_EXIST, COMM_FAILURE, TRANSIENT, INV_OBJREF) during forwarding,
1078 the request is not forwarded again and exception is propagated to the client
1080 is not forwarded upon OBJECT_NOT_EXIST exception.
1081 </td>
1082 </tr>
1083 <tr>
1086 receives COMM_FAILURE exception reply. If it receives one of the exceptions
1087 (OBJECT_NOT_EXIST, COMM_FAILURE, TRANSIENT, INV_OBJREF) during forwarding,
1088 the request is not forwarded again and exception is propagated to the client
1090 COMM_FAILURE exception.
1091 </td>
1092 </tr>
1093 <tr>
1096 receives TRANSIENT exception reply. If it receives one of the exceptions
1097 (OBJECT_NOT_EXIST, COMM_FAILURE, TRANSIENT, INV_OBJREF) during forwarding,
1098 the request is not forwarded again and exception is propagated to the client
1100 is not forwarded upon TRANSIENT exception.
1101 </td>
1102 </tr>
1103 <tr>
1106 receives INV_OBJREF exception reply. If it receives one of the exceptions
1107 (OBJECT_NOT_EXIST, COMM_FAILURE, TRANSIENT, INV_OBJREF) during forwarding,
1108 the request is not forwarded again and exception is propagated to the client
1110 is not forwarded upon INV_OBJREF exception.
1111 </td>
1112 </tr>
1113 </tbody>
1114 </table>
1115 </p>
1116 </blockquote>
1117 <p></p>
1120 Internally, TAO uses the <a
1122 Configurator framework</a> to allow applications to configure the ORB
1124 with options that configure appropriate strategies in to the ORB. The
1125 options enable developers to control the behavior of the factories,
1126 strategies, and resources that the ORB uses. By default, TAO provides
1127 the following set of factories:
1128 <p></p>
1129 <ol>
1131 This factory controls the creation of configurable resources used by
1132 TAO's ORB core. The resource factory is responsible for constructing
1133 and providing access to various resources used by the ORB irrespective
1134 of whether they perform client or server roles. ORB resources include
1135 reactors, protocol factories, message flushing strategies, connection
1136 purging strategies and different IOR parsers.
1137 <p> </p>
1138 </li>
1140 creates various strategies of special utility to the ORB that is useful
1141 for controlling the behavior of servers. This factory is responsible
1142 for creating strategies useful for server objects like the concurrency
1143 strategy and the request demultiplexing strategies used by the POA.
1144 <p> </p>
1145 </li>
1147 creates various strategies of special utility to the ORB, useful for
1148 controlling the behavior of clients. This factory is responsible for
1149 creating strategies useful for clients such as request multiplexing
1150 strategies, wait strategies, connect strategies etc.
1151 <p></p>
1152 </li>
1154 responsible for controlling the behavior of clients and servers that
1155 use UDP sockets.
1156 <p></p>
1157 </li>
1159 responsible for controlling the behavior of clients and servers that
1160 use MIOP protocol.
1161 <p></p>
1162 </li>
1164 manages the TIME_POLICY strategy used by the ORB for timers and
1165 countdowns.
1166 <p></p>
1167 </li>
1168 </ol>
1170 either the components provided by TAO (including the
1174 developed by the users. The service configurator file
1176 to be loaded with the required strategies for each component.
1178 run
1179 TAO applications since TAO provides a set of default values for
1181 default values are set for all options. When a TAO application calls
1184 directives in the file; if not found, the default value for the
1185 default components will be used.</p>
1188 Many of TAO's ORB Core resources are fixed, including the allocators
1189 for
1190 the incoming and outgoing data paths, and data structures for the
1191 various
1192 maps and lists maintained by the ORB. There is some flexibility,
1193 however, in the choice of a reactor, the selection of transport
1194 protocols, choice of data flushing strategy, various forms of
1195 connection resource management strategies and possibility of using
1196 different IOR parsers. The resource factories supported by TAO
1199 factories, as well as the specialized resource factories described
1200 below:
1201 <blockquote>
1202 <p>
1204 <tbody>
1205 <tr>
1208 </tr>
1209 <tr>
1211 <td>Unless configured otherwise, this is the default resource
1212 factory used by the ORB.The resource factory is responsible for
1213 creating and providing access to various resources used by the server
1214 and client ORBs. The resources managed by this factory include creation
1215 of acceptor and connector registries, choice of data flushing strategy,
1216 limits for connection resource management, types of CDR buffers used
1217 for marshalling and demarshalling data, and different IOR parsers. </td>
1218 </tr>
1219 <tr>
1221 <td>This factory provides more advanced configuration options
1222 in the addition to all the features of the default resource factory.<br>
1223 <br>
1224 The advanced resource factory gives more control than the default
1225 resource factory over the type of resources used and how those
1226 resources are accessed. In addition to the options provided by the
1227 default resource factory, the advanced resource factory provides
1228 options that allow selecting different reactors, choosing different
1229 transport mechanisms and selecting the right connection purging
1230 strategy to maintain limits on resources used. The advanced resource
1231 factory was created to allow more advanced options while keeping the
1232 footprint of the default resource factory small.<br>
1233 <br>
1234 The advanced resource factory inherits from the default resource
1235 factory and accepts all of its options in addition to its own. </td>
1236 </tr>
1237 <tr>
1239 <td>This is a specialized resource factory providing the means
1240 for integrating with the Qt GUI toolkit from Trolltech. </td>
1241 </tr>
1242 <tr>
1244 <td>This is a specialized resource factory providing the means
1245 for integrating with the X Window System's Xt Intrinsics toolkit. </td>
1246 </tr>
1247 </tbody>
1248 </table>
1249 </p>
1250 </blockquote>
1251 <p></p>
1253 Typically, the above options are exercised via the service
1254 configurator (svc.conf) file. The following line in the
1256 <p> <code>static
1258 <p>will load the default
1259 resource factory with the options listed within the double quotes. The
1260 following table shows the list of possible options that can be
1261 specified within the double quotes in the above directive. There is an <a
1264 <p></p>
1265 <blockquote>
1266 <p>
1268 <tbody>
1269 <tr>
1272 </tr>
1273 <tr>
1276 lock to be used by the Connection Cache. Possible values for lock type
1279 specifies that no locking be performed. The default is thread. </td>
1280 </tr>
1281 <tr>
1284 will grow to a maximum of the specified limit. The default is system
1285 dependent, but can be overridden at compile-time by defining the
1287 </tr>
1288 <tr>
1291 transport cache is purged, the specified percentage (20 by default) of
1292 the total number of connections cached will be closed. </td>
1293 </tr>
1294 <tr>
1297 connections are added to the transport cache so they can be reused.
1298 If a process continues to run and these connections are not reused,
1299 however, the cache will continue to grow. Before each new connection,
1300 therefore, the cache is checked and purged if it has reached the limit
1302 system default if that option was not used. The possible values for
1307 connections are purged) and are contained within the TAO Strategies
1308 library. </td>
1309 </tr>
1310 <tr>
1313 make the ORB wait for replies to show up even if the ORB is
1314 shutdown. The default is to drop replies. For example, clients
1315 comunicating with misbehaved servers will continue to hang if
1316 replies don't show up and even if the client ORB is shutdown
1317 from another thread. This strategy helps the ORB decide to
1318 wait for the replies or drop replies. Some clients may not
1319 want to drop replies, and may want all their requests to be
1320 processed until ORB::destroy () is called. Setting the value
1322 </tr>
1323 <tr>
1327 strategy uses the Reactor and non-blocking I/O to send the outgoing
1328 messages, this strategy participates in the Leader/Followers protocol
1330 strategy uses the Reactor but does not take part in the
1331 Leader/Followers protocol, thus it is better used only in single
1333 flushes the queue as soon as it becomes "full", and blocks the thread
1334 until all the data is sent.
1335 </td>
1336 </tr>
1337 <tr>
1345 </tr>
1346 <tr>
1349 allows only specified number of connections-per-QoS property to be
1350 added to connection cache. Threads not getting the connections will
1351 wait for the connections to be released. This option is more useful for
1352 transports using a muxed connection strategy and want control over the
1353 number of connections that are created by the active threads. </td>
1354 </tr>
1355 <tr>
1359 will be used.
1360 </td>
1361 </tr>
1362 <tr>
1365 protocol factory to load. By default, only the factory for the IIOP
1369 available, then it could be loaded into TAO by specifying <code>-ORBProtocolFactory
1371 pluggable protocol would then be available for use. </p>
1372 </td>
1373 </tr>
1374 <tr>
1376 <td>ACE select reactors mask signals during upcalls to the
1377 event handlers. This is only useful if the application is going to trap
1378 those signals and handle them in any special way. Disabling the mask
1379 can improve performance by reducing the number of kernel level locks. </td>
1380 </tr>
1381 <tr>
1384 protocol, which at this moment the only option is sendfile.
1385 If your platform does support sendfile but you don't want
1386 that TAO uses it you can disable
1388 to your config.h file.
1389 </td>
1390 </tr>
1391 </tbody>
1392 </table>
1393 </p>
1394 </blockquote>
1397 accepts the options below as well as those described above in the
1399 using a service configurator directive of the form (all on one line):
1400 <p><code>dynamic Advanced_Resource_Factory Service_Object
1401 *</code><br>
1402 <code>TAO_Strategies:_make_TAO_Advanced_Resource_Factory
1405 <p></p>
1406 <ul>
1412 </ul>
1413 You can
1418 warnings telling you so). The following table lists the options that
1419 can be provided in double quotes. An <a
1421 is available that shows how to specify this option in the svc.conf file.</p>
1422 <p></p>
1423 <blockquote>
1424 <p>
1426 <tbody>
1427 <tr>
1430 </tr>
1431 <tr>
1436 </tr>
1437 <tr>
1442 </tr>
1443 <tr>
1450 sequences will not work in all cases when the allocator does not have
1451 locks (for example if the octet sequences are part of a return
1452 value). Using locked allocators also allows the users to take
1453 advantage of the TAO octet sequence extensions to preserve the buffer
1454 after the upcall. </td>
1455 </tr>
1456 <tr>
1459 supported. The Advanced Resource Factory will emit an error if you
1460 attempt its use. </td>
1461 </tr>
1462 <tr>
1469 waiting threads are selected to run by the
1471 </tr>
1472 <tr>
1475 the ORB uses. The default reactor is the ACE_TP_Reactor.
1477 <tbody>
1478 <tr>
1481 </tr>
1482 <tr>
1485 </tr>
1486 <tr>
1489 </tr>
1490 <tr>
1493 </tr>
1494 <tr>
1497 </tr>
1498 <tr>
1501 thread-pool reactor which is the default.</td>
1502 </tr>
1503 <tr>
1507 based thread-pool reactor. It is intended to be a
1508 highly scalable replacement for the
1510 ACE_Dev_Poll_Reactor is currently only supported on
1511 Linux. Be aware that dev_poll
1512 support is experimental!</td>
1513 </tr>
1514 </tbody>
1515 </table>
1516 </td>
1517 </tr>
1518 </tbody>
1519 </table>
1520 </p>
1521 </blockquote>
1523 Certain elements of the ORB relate only to a TAO server. In this
1524 context, the server is any application that passively accepts
1525 connection from other processes and receives requests from those other
1526 connections. The server strategy factory is responsible for supporting
1527 features of TAO that are specific to servers. In particular, these
1528 include the following strategies:
1529 <ul>
1531 flags and other concurrency related behaviors.
1532 <p></p>
1533 </li>
1535 to locate servants inside the POA that are responsible for handling
1536 requests.
1537 <p></p>
1538 </li>
1539 </ul>
1540 TAO provides a default server strategy factory called
1542 <p>Typically, the following options are set via the service
1543 configurator
1544 (svc.conf) file. The following line in the svc.conf file (all in one
1545 line)</p>
1550 is available
1552 file. </p>
1553 <p></p>
1554 <blockquote>
1555 <p>
1557 <tbody>
1558 <tr>
1561 </tr>
1562 <tr>
1564 in ids</em></td>
1565 <td>Specify whether an active hint should be added to ids. With
1566 active hints, ids can be found quickly. However, they lead to larger
1567 IORs. Note that this option is disregarded <code>if
1571 </td>
1572 </tr>
1573 <tr>
1575 hint in poa names</em></td>
1576 <td>Specify whether an active hint should be added to POA
1577 names. With active hints, POA names can be found quickly. However, they
1580 </tr>
1581 <tr>
1583 size</em></td>
1584 <td>Specify the size of the active object map. If not
1586 </tr>
1587 <tr>
1589 reactivation of system ids</em></td>
1590 <td>Specify whether system ids can be reactivated, i.e., once
1591 an id that was generated by the system has been deactivated, will the
1592 user reactivate a new servant using the old id. If the user is not
1593 going to use this feature, the IORs can be shortened, an extra
1594 comparison in the critical upcall path removed, and some memory on the
1597 </td>
1598 </tr>
1599 <tr>
1601 <td>Specify which concurrency strategy to use. Range of values
1604 thread to service each connection. The default is reactive. </td>
1605 </tr>
1606 <tr>
1608 id policy based demultiplexing strategy</em></td>
1609 <td>Specify the demultiplexing lookup strategy to be used with
1613 </tr>
1614 <tr>
1616 <td>Specify the size of the POA map. If not specified, the
1618 </tr>
1619 <tr>
1621 policy based demultiplexing strategy</em></td>
1622 <td>Specify the demultiplexing lookup strategy to be used with
1625 This option defaults to use the <code>dynamic</code> strategy when <code>-ORBAllowReactivationOfSystemids</code>
1626 is true, and to <code>active</code> strategy when <code>-ORBAllowReactivationOfSystemids</code>
1627 is false. </td>
1628 </tr>
1629 <tr>
1631 <td>Specify the flags used for thread creation. Flags can be
1635 </tr>
1636 <tr>
1639 <td>In many platforms it is impossible to interrupt the server
1643 threads periodically poll the ORB to find out if they should shutdown.
1644 This option controls the period of the polling, expressed in
1645 milliseconds. Applications that do not shutdown, or that can otherwise
1646 ensure that no server threads will be running at shutdown (for example
1647 if all the clients terminate before the server) can disable the
1649 <p>If the option is not provided then the ORB uses the
1651 this flag also expresses the time in milliseconds (as a string
1653 disable polling entirely. This yields a slight performance improvement
1655 </td>
1656 </tr>
1657 <tr>
1659 id policy based demultiplexing strategy</em></td>
1660 <td>Specify the demultiplexing lookup strategy to be used with
1664 </tr>
1665 <tr>
1667 id policy based reverse demultiplexing strategy</em></td>
1668 <td>Specify the reverse demultiplexing lookup strategy to be
1672 </tr>
1673 <tr>
1675 policy based demultiplexing strategy</em></td>
1676 <td>Specify the demultiplexing lookup strategy to be used with
1680 </tr>
1681 </tbody>
1682 </table>
1683 </p>
1684 </blockquote>
1686 Similar to the
1687 server strategy factory, the client strategy factory supports those
1688 elements of TAO that are specific to the behavior of clients, which
1689 are any CORBA applications that actively establish connections, submit
1690 requests, and perhap receive responses. The client strategy factory
1691 provides control over several resources used by clients. TAO provides
1692 a default client strategy factory called
1694 <p>Typically, the following options are set via the service
1695 configurator
1702 file.</p>
1703 <p></p>
1704 <blockquote>
1705 <p>
1707 <tbody>
1708 <tr>
1711 </tr>
1712 <tr>
1714 / MT_NOUPCALL</em><br>
1716 </em>
1717 </td>
1718 <td><em>Please note that these two options are synonymous and can be used interchangeably.</em>
1720 use the single-threaded client connection handler, i.e., the leader
1722 nested upcalls and handling of new requests while waiting for the reply
1723 from a server.
1725 handler which uses the leader follower model. This model allows the use
1726 of multiple threads with a single Reactor. </p>
1729 instead of waiting in the Reactor using the Leader/Followers
1731 does not have to worry about new request showing up when waiting for a
1732 response. Further, this strategy cannot be used with BiDIR GIOP.
1733 Note that applications that require nested upcalls are not compatible
1734 with this strategy. Also note that this strategy will only affect synchronous
1735 two way calls, since there is no waiting for one way calls or AMI requests
1736 (at least not in the same sense as for synchronous two way calls).
1737 This strategy can also be used in an application that
1738 is both a client and a server where the server side is handled by a
1739 separate thread and the client threads are "pure" clients.
1740 Use in single threaded applications with both client and server roles is
1741 also possible but in these cases special care has to be taken to avoid
1742 deadlocks because of nested synchronous calls. Mixing in AMI requests and/or
1743 other asynchronous reactor (timer/notification) events might help solve
1744 such issues.
1745 When this strategy is set to RW, then also the -ORBFlushingStrategy
1747 <p>
1749 participates in the leader-follower model like MT, but, like
1750 RW, does not allow handling of nested CORBA upcalls within the
1751 waiting thread. It does allow handling of other non CORBA (ACE reactor events)
1752 like timers and ACE notification queue events. Note that with
1753 this strategy it is possible
1754 to "run out of threads" in a thread pool, and that TAO doesn't
1755 grow thread pools. Unlike RW, this does not require <a
1757 </p>
1759 </td>
1760 </tr>
1762 <tr>
1764 </td>
1767 handlers setup for sending messages need to be cleaned up
1768 when errors occur. This option has an effect only for
1771 automatically set up for cleaning the connection
1773 effect of registering and unregistering the connection
1774 handlers with the Reactor for every invocation, which has a
1776 </em> prevents this performance impact but leads to problems
1777 outlined
1778 <A
1782 here</A>
1784 </td>
1785 </tr>
1787 <tr>
1791 strategy uses the Reactor and non-blocking connects to connect and this
1792 strategy participates in the Leader/Followers protocol to synchronize
1794 for non-blocking connects but does not take part in the
1795 Leader/Followers protocol, thus it is better used only in single
1797 name implies, blocks the thread until connection is complete. Some of
1799 strategy.
1800 </td>
1801 </tr>
1802 <tr>
1805 the ORB to use when a Messaging Sync Scope policy is not used. When not
1806 supplied, the default sync scope is SYNC_WITH_TRANSPORT.
1807 </td>
1808 </tr>
1809 <tr>
1812 means that the Transport does not multiplex requests on a connection.
1813 At a time, there can be only one request pending on a connection.
1815 one request at the same time on a connection. This option is often used
1816 in conjunction with AMI, because multiple requests can be sent "in
1819 </td>
1820 </tr>
1821 <tr>
1823 <td>Options of the same names as the command-line options
1825 can also be applied client strategy factory service. Any
1826 option provided on the command line will override the
1827 corresponding option in the service configurator
1828 file.
1829 </td>
1830 </tr>
1831 </tbody>
1832 </table>
1833 </p>
1834 </blockquote>
1837 implements the MIOP protocol. It uses the
1839 shared with the TAO_DIOP_Protocol_Factory. It accepts its own un-shared
1840 options shown below. (Any options required should be given
1841 to the TAO_UIPMC_Protocol_Factory between the two double-quotes at the end
1842 of the line as a space separated list; however none are required as all
1843 options take default values if not specified.) This factory can be loaded
1844 dynamically using service configurator directives of the form (all on one line):
1845 <p><code>dynamic UIPMC_Factory Service_Object *
1847 <p>Normally however in order to set up the TAO_UIPMC_Protocol_Factory correctly,
1848 the application will have to use other service configurator directives as well;
1849 for example:</p>
1850 <code>dynamic UIPMC_Factory Service_Object *
1852 static Resource_Factory "‑ORBProtocolFactory IIOP_Factory
1854 dynamic PortableGroup_Loader Service_Object *
1856 <blockquote>
1857 <p></p>
1859 <tbody>
1860 <tr>
1863 </tr>
1864 <tr>
1865 <td ALIGN="left"><code>‑ORBListenerInterfaces</code> <em>targetNetwork=localNetwork[,...] | CopyPreferredInterfaces</em></td>
1867 which network/interface(s) are to be used to listen for communications from the multicast addressed
1868 remote client(s). If this option is unspecified (or if none of the given
1870 the attempted listener) then the default listener will be set-up as specified or defaulted with the
1873 address(es), it will use the local ip address(es) matching the <em>localNetwork</em> string. Simple
1874 wildcards can be used for both parameters, and multiple paired <em>targetNetwork=localNetwork</em>
1875 strings can be specified using comma separators (no embedded spaces allowed) or via additional
1877 and/or multiple interfaces at the same time for each listener established via such
1879 <p>
1880 For example, for a machine with two network cards identified by the ip addresses
1882 <code>‑ORBListenerInterfaces 239.255.*=*10,224.255.*=*20</code> or the pair of directives
1883 <code>‑ORBListenerInterfaces 239.255.*=*10 ‑ORBListenerInterfaces 224.255.*=*20</code>
1884 to establish the link to listen for <em>239.255.*</em> multicast addresses on the first interface, and
1886 <em>targetNetwork</em> can use any string, but must typically match the value writen into the IOR and so
1887 will usually be a dotted decimal multicast address in the administrative "site local" range,
1888 (<em>224.255.0.0</em> to <em>238.255.255.255</em>) or (<em>239.255.0.0</em> to <em>239.255.255.255</em>).
1889 <p><em>localNetwork</em> must use a local dotted decimal address, because it will be matched with
1890 the local ip interfaces.</p>
1891 The same client-side (sender) assignments as specified by the ORB_init supplied command line option(s)
1893 <em>CopyPreferredInterfaces</em> parameter as in <code>‑ORBListenerInterfaces CopyPreferredInterfaces</code>
1894 (which may be prefixed and/or postfixed by other <code>‑ORBListenerInterfaces <em>targetNetwork=localNetwork</em></code>
1895 options as required).
1896 </tr>
1897 <tr>
1901 directives (if any, see below) match the actual multicast address being set-up.
1902 <p>If disabled (<em>0</em>) the multicast address will be listened for only on the default multicast
1904 local interface on the system), the loopback interface is normally excluded.</p>
1906 interface(s) which are multicast enabled (again the loopback interface is normally excluded).
1907 </td>
1908 </tr>
1909 </tbody>
1910 </table>
1911 </blockquote>
1914 manages UDP connection options shared between the TAO_DIOP_Protocol_Factory
1916 accepts the options detailed below, which should be specified between the
1917 two double-quotes shown here as a space-separated list; however none are
1918 required as all options take default values if not specified. This factory
1919 can be loaded dynamically using a service configurator directive of the
1920 form (all on one line):
1921 <p><code>dynamic MIOP_Resource_Factory Service_Object *
1923 You would normally have to use other service configurator
1924 directives as well; for example:
1925 <p><code>dynamic UIPMC_Factory Service_Object *
1927 static Resource_Factory "‑ORBProtocolFactory IIOP_Factory
1929 dynamic PortableGroup_Loader Service_Object *
1931 dynamic MIOP_Resource_Factory Service_Object *
1933 Since DIOP and MIOP use UDP sockets (which is not a "reliable" transport unlike
1934 TCP/IP), it is easy to configure them in such a way that messages will not
1935 actually reach the servant. The options below are intended to maximize DIOP and
1936 MIOP reliability, but they must be used with care; users of DIOP and MIOP must
1937 understand that large messages are sent in fragments and they have to be
1938 reassembled by the server in their entirety to be usable by the servant. If
1939 even a single data fragment/packet is lost, the whole message cannot be
1940 reconstructed and will be unusable. There is no way for the servant to even
1941 know it has missed such a DIOP or MIOP message, and being a one-way protocol,
1942 neither will the client be aware that the message has been lost. Fragments
1943 can be lost due to a variety of reasons:
1944 <p></p>
1945 <ul>
1946 <li>
1947 The client sends too large a message fragment, or sends messages too fast,
1948 overwhelming the client socket's transmission buffer. (In which case the
1949 client-side (sender) OS simply ignores the excess send requests and some of the
1950 fragments are not actually sent on the wire.)
1951 <li>
1952 The server socket's receive buffer became too full to acquire the fragments off
1953 the wire. (In this case the client is again sending messages too fast, but this
1954 time it is the servant that is too slow to process the messages it has already
1955 received.)
1956 <li>
1957 Something happend to the network or routing and the packet was lost between the
1958 client and the server, or the server OS failed to react to the hardware network
1959 device in a timely manor so that network packets were lost.</li></ul>
1960 <p></p>
1962 the client adapting/throttling its sending rate so as to not overflow the
1963 capacity of the client's operating system sending buffer and the receiving
1964 buffer of the server socket. If there are multiple clients all sending to the
1965 same server, all of these clients must be configured to slow down their sending
1966 rate (as a software system design descision) as otherwise the server's receive
1967 buffer will become swamped and some messages will be lost.</p>
1968 <blockquote>
1969 <p>
1971 <tbody>
1972 <tr>
1973 <th>
1974 Option</th>
1975 <th>
1976 Description</th>
1977 </tr>
1978 <tr>
1981 although this default can be overriden when the TAO libraries are built in the <CODE>
1982 ace/config.h</CODE>, by specifying the new default such as <CODE>#define TAO_DEFAULT_MIOP_EAGER_DEQUEUEING false</CODE>
1983 which in this case would turn this off by default, unless specified in the
1984 service file. If disabled (0) each thread servicing the MIOP listener will only
1985 dequeue enough MIOP message fragments from the socket receive buffer to
1986 complete a single full MIOP message which it will then process. This action
1987 reduces the amount of user memory consumed by the server process, but it also
1988 increases the likelihood of the OS sockets receive buffer overflowing (as
1989 whilst processing each message, the thread cannot dequeue other incomming
1990 message fragments). If enabled (1) it specifies that each server thread will
1991 attempt to dequeue all available MIOP messages from the receiver's socket and
1992 queue these up in a user memory FIFO queue, before attempting to process a
1993 single MIOP message from the head of this FIFO queue. This action attempts to
1994 speed up the dequeueing of MIOP messages from the OS socket receive buffer
1995 (with a corresponding increase in the amount of user memory consumed by the
1996 server process) so as to limit the number of MIOP messages that the server may
1997 miss due to the OS sockets receive buffer becoming full.
1998 </td>
1999 </tr>
2000 <tr>
2003 <P>This client-side (sender) option (if enabled, see <code>‑ORBSendThrottling</code> below)
2004 specifies a non-zero, positive amount of time (in
2005 uSec, i.e. microseconds) that it takes to transmit and process an individual
2007 option above. (This is the total of the
2009 network transmission delay.) The client attempts to keep the rate at which it
2010 sends messages down to this speed by purposly delaying sending message
2011 fragments, if it would exceeding this capacity (but also see the <code>‑ORBSendHighWaterMark</code>
2012 option below). The default is same value as specified, or is defaulted by, the <code>
2014 microseconds not bytes. (This default delay value is approximatly the time
2016 values will throttle back the clients transmittion rate, smaller values will
2019 to be altered if the size is changed.
2020 </P>
2021 </td>
2022 </tr>
2023 <tr>
2026 fragments that a client can break the outgoing message up into. The limit must
2027 be a positive number or zero (indicating an unlimited number). The default is
2031 which in this case would turn off fragmentation by default (as only a single
2032 fragment would be allowed), unless a new limit is specified in the service
2033 file. Any messages that are too large and require more fragments than allowed
2034 by this setting are simply not transmitted by the client (the message is
2035 effectly lost without any error indication, other than possibly a debug
2036 message). This setting can be used as a safety setting to stop swamping the
2037 network and servants with abnormally large messages, or during testing to
2038 "lose" large messages for whatever reason.
2039 </td>
2040 </tr>
2041 <tr>
2043 | MEMORY</em></td>
2046 fragments that cannot be reassembled after a certain delay should be removed
2047 from the waiting queue (i.e. considered lost messages). The other options are <em>
2049 messages in the waiting queue will be limited, or the whole memory comsumed by
2050 the incomplete messages in the waiting queue will be limited.
2051 </td>
2052 </tr>
2053 <tr>
2055 <td ALIGN="left">This option specifies the numerical limit for the server's <code>‑ORBFragmentsCleanupStrategy</code>
2060 the limit indicates the number of bytes reserved for the whole queue (with the
2061 default being 3000000 bytes).
2062 </td>
2063 </tr>
2064 <tr>
2067 each individual MIOP fragment, which must be between <em>272</em> and <em><code>ACE_MAX_UDP_PACKET_SIZE</code>
2069 values decrease) the number of fragments required to send the actual payload
2070 data. Each fragment requires the overhead of a new MIOP header (32 bytes)
2071 prefixing the actual data being sent, with the header reducing the actual
2072 usable payload data inside each fragment. Roughly this value can be considered
2073 as the MTU (Maximum Transmission Unit) set for the specific connection. The
2077 when the TAO libraries are built. <b>Note: most gateways and routing networks
2081 below. Note also if this value is changed (during development) and the <code>‑ORBMaxFragmentRate</code>
2082 option below is also specified, you should change that value by the same
2083 factor, otherwise the speed of transmission will be effected as these two
2084 options specify a working ratio.
2085 </td>
2086 </tr>
2087 <tr>
2090 message buffer, i.e., how much data can be received directly off the wire by the
2091 server and queued for processing by the servant whilst it is busy. If specified
2092 in the service configuration file, this value will override (for MIOP only) the
2093 value specified by the corresponding ORB_init parameter. If NOT specified in
2094 either place, the default value for the system itself will be used. Again for a
2096 whatever value is actually specified it is normally doubled internally to take
2097 account of the control structures required to track the messages themselves and
2098 so it is not a hard limit. Specifying as large a value as possible (i.e.
2100 option is advisable to maximize the available socket's receive buffer space, but
2101 obviously this is a trade off between available memory and other OS non-paged
2102 memory uses.
2103 </td>
2104 </tr>
2105 <tr>
2107 <td ALIGN="left">This client-side (sender) option (if enabled, see <code>‑ORBSendThrottling</code> below)
2108 is the usable size of the message
2109 buffer, i.e how much data can be sent without introducing delays into the
2111 option above). <b>Its default value is the size of the buffer maintained by the
2112 Operating System for the sending socket at the client side (see the <code>‑ORBSndSock</code>
2113 option below) and although it should ideally be based on the server's receive
2114 socket buffer size, that information is not available to the client, and the
2115 two values normally default to the same size anyway.</b> If in doubt specify
2118 broadcasting to the same server, when each client should only use a fraction of
2119 the full buffer size based upon the number of clients actually in use).
2120 </td>
2121 </tr>
2122 <tr>
2125 although this default can be overriden when the TAO libraries are built in the <CODE>
2126 ace/config.h</CODE>, by specifying the new default such as <CODE>#define TAO_DEFAULT_MIOP_SEND_THROTTLING false</CODE>
2127 which in this case would turn off throttling by default, unless specified in
2128 the service file. If disabled (0) the client will always attempt to transmit
2129 all MIOP message fragments without any delay. If enabled (1) the client will
2130 attempt to automatically restrict the speed of sending individual MIOP messages
2131 to maintain an average of <code>‑ORBMaxFragmentSize</code> bytes per <code>‑ORBMaxFragmentRate</code>
2133 of data are currently being transmitted or are in progress via each individual transport
2134 (i.e. each individual client-side (sender) connection to the server).
2135 </td>
2136 </tr>
2137 <tr>
2140 message buffer. If specified in the service configuration file, this value will
2141 override (for MIOP only) the value specified by the corresponding ORB_init
2142 parameter. If NOT specified in either place, the default value for the system
2144 limits the maximum size of an individual message fragment, larger fragments can
2145 be simply ignored (i.e. packet loss) by the client's socket without any error
2147 set with care. For a Linux type OS, the system's SndSock is usually defaulted to
2149 normally doubled internally to take account of the control structures required
2150 to track the messages themselves and so it is not a hard limit.
2151 </td>
2152 </tr>
2153 </tbody>
2154 </table>
2155 </p>
2156 </blockquote>
2158 The TIME_POLICY manager controls the actual TIME_POLICY strategy used for
2159 ORB timers and countdowns. TAO provides a default strategy manager called
2161 <p>Typically, the following options is set via the service
2162 configurator
2165 <p><code>static
2170 file.</p>
2171 <p></p>
2172 <blockquote>
2173 <p>
2175 <tbody>
2176 <tr>
2179 </tr>
2180 <tr>
2183 defines the TIME_POLICY strategy to load. TAO provides two
2184 standard TIME_POLICY strategies:</p>
2186 equivalent of <code>gettimeofday</code> to return a current time value. This is the default for
2190 <code>TAO_USE_HR_TIME_POLICY_STRATEGY</code> has been defined this becomes the default for TAO).</p>
2191 <p>Any other value is assumed to denote the exact name of a dynamically loadable
2193 test provides an example of this functionality.</p>
2194 </td>
2195 </tr>
2196 </tbody>
2197 </table>
2198 </p>
2199 </blockquote>
2200 <hr>
2201 <p>Back to the TAO <a href="components.html">component options and tuning documentation</a>.<!--#include virtual="/~schmidt/cgi-sig.html" -->
2202 </body>
2203 </html>