| blob | febadd5e653b1731dc8148e38af0467e62926dfa |
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 simultaniously 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,
1016 OpenVMS, AIX, and Solaris.
1018 If this option is used then -ORBForwardOnTransientLimit should
1019 also be used to avoid a TRANSIENT exception being thrown.
1020 </td>
1021 </tr>
1022 <tr>
1024 <td>Defines the number of milliseconds to delay while
1025 cycling through profiles when the first base profile
1028 </tr>
1029 </tbody>
1030 </table>
1031 </p>
1032 </blockquote>
1036 Options in this category don't control the behavior of the ORB in
1037 terms of resouces or strategies. Instead, they are helper options
1038 provided for specific application requirements.
1039 <blockquote>
1040 <p>
1042 <tbody>
1043 <tr>
1046 </tr>
1047 <tr>
1052 coexisting ORBs (when there is more than one ORB).</td>
1053 </tr>
1054 <tr>
1059 </tr>
1060 <tr>
1063 run as a background process. Note, that this changes the working directory to
1064 be the root directory "/". This especially affects relative paths specified at the command line.
1065 This option is only meaningful on OS platforms that support daemonization.</td>
1066 </tr>
1067 <tr>
1071 which means the request is not forwarded upon OBJECT_NOT_EXIST exception.
1072 </td>
1073 </tr>
1074 <tr>
1077 receives OBJECT_NOT_EXIST exception reply. If it receives one of the exceptions
1078 (OBJECT_NOT_EXIST, COMM_FAILURE, TRANSIENT, INV_OBJREF) during forwarding,
1079 the request is not forwarded again and exception is propagated to the client
1081 is not forwarded upon OBJECT_NOT_EXIST exception.
1082 </td>
1083 </tr>
1084 <tr>
1087 receives COMM_FAILURE exception reply. If it receives one of the exceptions
1088 (OBJECT_NOT_EXIST, COMM_FAILURE, TRANSIENT, INV_OBJREF) during forwarding,
1089 the request is not forwarded again and exception is propagated to the client
1091 COMM_FAILURE exception.
1092 </td>
1093 </tr>
1094 <tr>
1097 receives TRANSIENT exception reply. If it receives one of the exceptions
1098 (OBJECT_NOT_EXIST, COMM_FAILURE, TRANSIENT, INV_OBJREF) during forwarding,
1099 the request is not forwarded again and exception is propagated to the client
1101 is not forwarded upon TRANSIENT exception.
1102 </td>
1103 </tr>
1104 <tr>
1107 receives INV_OBJREF exception reply. If it receives one of the exceptions
1108 (OBJECT_NOT_EXIST, COMM_FAILURE, TRANSIENT, INV_OBJREF) during forwarding,
1109 the request is not forwarded again and exception is propagated to the client
1111 is not forwarded upon INV_OBJREF exception.
1112 </td>
1113 </tr>
1114 </tbody>
1115 </table>
1116 </p>
1117 </blockquote>
1118 <p></p>
1121 Internally, TAO uses the <a
1123 Configurator framework</a> to allow applications to configure the ORB
1125 with options that configure appropriate strategies in to the ORB. The
1126 options enable developers to control the behavior of the factories,
1127 strategies, and resources that the ORB uses. By default, TAO provides
1128 the following set of factories:
1129 <p></p>
1130 <ol>
1132 This factory controls the creation of configurable resources used by
1133 TAO's ORB core. The resource factory is responsible for constructing
1134 and providing access to various resources used by the ORB irrespective
1135 of whether they perform client or server roles. ORB resources include
1136 reactors, protocol factories, message flushing strategies, connection
1137 purging strategies and different IOR parsers.
1138 <p> </p>
1139 </li>
1141 creates various strategies of special utility to the ORB that is useful
1142 for controlling the behavior of servers. This factory is responsible
1143 for creating strategies useful for server objects like the concurrency
1144 strategy and the request demultiplexing strategies used by the POA.
1145 <p> </p>
1146 </li>
1148 creates various strategies of special utility to the ORB, useful for
1149 controlling the behavior of clients. This factory is responsible for
1150 creating strategies useful for clients such as request multiplexing
1151 strategies, wait strategies, connect strategies etc.
1152 <p></p>
1153 </li>
1155 responsible for controlling the behavior of clients and servers that
1156 use UDP sockets.
1157 <p></p>
1158 </li>
1160 responsible for controlling the behavior of clients and servers that
1161 use MIOP protocol.
1162 <p></p>
1163 </li>
1165 manages the TIME_POLICY strategy used by the ORB for timers and
1166 countdowns.
1167 <p></p>
1168 </li>
1169 </ol>
1171 either the components provided by TAO (including the
1175 developed by the users. The service configurator file
1177 to be loaded with the required strategies for each component.
1179 run
1180 TAO applications since TAO provides a set of default values for
1182 default values are set for all options. When a TAO application calls
1185 directives in the file; if not found, the default value for the
1186 default components will be used.</p>
1189 Many of TAO's ORB Core resources are fixed, including the allocators
1190 for
1191 the incoming and outgoing data paths, and data structures for the
1192 various
1193 maps and lists maintained by the ORB. There is some flexibility,
1194 however, in the choice of a reactor, the selection of transport
1195 protocols, choice of data flushing strategy, various forms of
1196 connection resource management strategies and possibility of using
1197 different IOR parsers. The resource factories supported by TAO
1200 factories, as well as the specialized resource factories described
1201 below:
1202 <blockquote>
1203 <p>
1205 <tbody>
1206 <tr>
1209 </tr>
1210 <tr>
1212 <td>Unless configured otherwise, this is the default resource
1213 factory used by the ORB.The resource factory is responsible for
1214 creating and providing access to various resources used by the server
1215 and client ORBs. The resources managed by this factory include creation
1216 of acceptor and connector registries, choice of data flushing strategy,
1217 limits for connection resource management, types of CDR buffers used
1218 for marshalling and demarshalling data, and different IOR parsers. </td>
1219 </tr>
1220 <tr>
1222 <td>This factory provides more advanced configuration options
1223 in the addition to all the features of the default resource factory.<br>
1224 <br>
1225 The advanced resource factory gives more control than the default
1226 resource factory over the type of resources used and how those
1227 resources are accessed. In addition to the options provided by the
1228 default resource factory, the advanced resource factory provides
1229 options that allow selecting different reactors, choosing different
1230 transport mechanisms and selecting the right connection purging
1231 strategy to maintain limits on resources used. The advanced resource
1232 factory was created to allow more advanced options while keeping the
1233 footprint of the default resource factory small.<br>
1234 <br>
1235 The advanced resource factory inherits from the default resource
1236 factory and accepts all of its options in addition to its own. </td>
1237 </tr>
1238 <tr>
1240 <td>This is a specialized resource factory providing the means
1241 for integrating with the Qt GUI toolkit from Trolltech. </td>
1242 </tr>
1243 <tr>
1245 <td>This is a specialized resource factory providing the means
1246 for integrating with the X Window System's Xt Intrinsics toolkit. </td>
1247 </tr>
1248 </tbody>
1249 </table>
1250 </p>
1251 </blockquote>
1252 <p></p>
1254 Typically, the above options are exercised via the service
1255 configurator (svc.conf) file. The following line in the
1257 <p> <code>static
1259 <p>will load the default
1260 resource factory with the options listed within the double quotes. The
1261 following table shows the list of possible options that can be
1262 specified within the double quotes in the above directive. There is an <a
1265 <p></p>
1266 <blockquote>
1267 <p>
1269 <tbody>
1270 <tr>
1273 </tr>
1274 <tr>
1277 lock to be used by the Connection Cache. Possible values for lock type
1280 specifies that no locking be performed. The default is thread. </td>
1281 </tr>
1282 <tr>
1285 will grow to a maximum of the specified limit. The default is system
1286 dependent, but can be overridden at compile-time by defining the
1288 </tr>
1289 <tr>
1292 transport cache is purged, the specified percentage (20 by default) of
1293 the total number of connections cached will be closed. </td>
1294 </tr>
1295 <tr>
1298 connections are added to the transport cache so they can be reused.
1299 If a process continues to run and these connections are not reused,
1300 however, the cache will continue to grow. Before each new connection,
1301 therefore, the cache is checked and purged if it has reached the limit
1303 system default if that option was not used. The possible values for
1308 connections are purged) and are contained within the TAO Strategies
1309 library. </td>
1310 </tr>
1311 <tr>
1314 make the ORB wait for replies to show up even if the ORB is
1315 shutdown. The default is to drop replies. For example, clients
1316 comunicating with misbehaved servers will continue to hang if
1317 replies don't show up and even if the client ORB is shutdown
1318 from another thread. This strategy helps the ORB decide to
1319 wait for the replies or drop replies. Some clients may not
1320 want to drop replies, and may want all their requests to be
1321 processed until ORB::destroy () is called. Setting the value
1323 </tr>
1324 <tr>
1328 strategy uses the Reactor and non-blocking I/O to send the outgoing
1329 messages, this strategy participates in the Leader/Followers protocol
1331 strategy uses the Reactor but does not take part in the
1332 Leader/Followers protocol, thus it is better used only in single
1334 flushes the queue as soon as it becomes "full", and blocks the thread
1335 until all the data is sent.
1336 </td>
1337 </tr>
1338 <tr>
1346 </tr>
1347 <tr>
1350 allows only specified number of connections-per-QoS property to be
1351 added to connection cache. Threads not getting the connections will
1352 wait for the connections to be released. This option is more useful for
1353 transports using a muxed connection strategy and want control over the
1354 number of connections that are created by the active threads. </td>
1355 </tr>
1356 <tr>
1360 will be used.
1361 </td>
1362 </tr>
1363 <tr>
1366 protocol factory to load. By default, only the factory for the IIOP
1370 available, then it could be loaded into TAO by specifying <code>-ORBProtocolFactory
1372 pluggable protocol would then be available for use. </p>
1373 </td>
1374 </tr>
1375 <tr>
1377 <td>ACE select reactors mask signals during upcalls to the
1378 event handlers. This is only useful if the application is going to trap
1379 those signals and handle them in any special way. Disabling the mask
1380 can improve performance by reducing the number of kernel level locks. </td>
1381 </tr>
1382 <tr>
1385 protocol, which at this moment the only option is sendfile.
1386 If your platform does support sendfile but you don't want
1387 that TAO uses it you can disable
1389 to your config.h file.
1390 </td>
1391 </tr>
1392 </tbody>
1393 </table>
1394 </p>
1395 </blockquote>
1398 accepts the options below as well as those described above in the
1400 using a service configurator directive of the form (all on one line):
1401 <p><code>dynamic Advanced_Resource_Factory Service_Object
1402 *</code><br>
1403 <code>TAO_Strategies:_make_TAO_Advanced_Resource_Factory
1406 <p></p>
1407 <ul>
1413 </ul>
1414 You can
1419 warnings telling you so). The following table lists the options that
1420 can be provided in double quotes. An <a
1422 is available that shows how to specify this option in the svc.conf file.</p>
1423 <p></p>
1424 <blockquote>
1425 <p>
1427 <tbody>
1428 <tr>
1431 </tr>
1432 <tr>
1437 </tr>
1438 <tr>
1443 </tr>
1444 <tr>
1451 sequences will not work in all cases when the allocator does not have
1452 locks (for example if the octet sequences are part of a return
1453 value). Using locked allocators also allows the users to take
1454 advantage of the TAO octet sequence extensions to preserve the buffer
1455 after the upcall. </td>
1456 </tr>
1457 <tr>
1460 supported. The Advanced Resource Factory will emit an error if you
1461 attempt its use. </td>
1462 </tr>
1463 <tr>
1470 waiting threads are selected to run by the
1472 </tr>
1473 <tr>
1476 the ORB uses. The default reactor is the ACE_TP_Reactor.
1478 <tbody>
1479 <tr>
1482 </tr>
1483 <tr>
1486 </tr>
1487 <tr>
1490 </tr>
1491 <tr>
1494 </tr>
1495 <tr>
1498 </tr>
1499 <tr>
1502 thread-pool reactor which is the default.</td>
1503 </tr>
1504 <tr>
1508 based thread-pool reactor. It is intended to be a
1509 highly scalable replacement for the
1511 ACE_Dev_Poll_Reactor is currently only supported on
1512 HP-UX, Solaris and Linux. Be aware that dev_poll
1513 support is experimental!</td>
1514 </tr>
1515 </tbody>
1516 </table>
1517 </td>
1518 </tr>
1519 </tbody>
1520 </table>
1521 </p>
1522 </blockquote>
1524 Certain elements of the ORB relate only to a TAO server. In this
1525 context, the server is any application that passively accepts
1526 connection from other processes and receives requests from those other
1527 connections. The server strategy factory is responsible for supporting
1528 features of TAO that are specific to servers. In particular, these
1529 include the following strategies:
1530 <ul>
1532 flags and other concurrency related behaviors.
1533 <p></p>
1534 </li>
1536 to locate servants inside the POA that are responsible for handling
1537 requests.
1538 <p></p>
1539 </li>
1540 </ul>
1541 TAO provides a default server strategy factory called
1543 <p>Typically, the following options are set via the service
1544 configurator
1545 (svc.conf) file. The following line in the svc.conf file (all in one
1546 line)</p>
1551 is available
1553 file. </p>
1554 <p></p>
1555 <blockquote>
1556 <p>
1558 <tbody>
1559 <tr>
1562 </tr>
1563 <tr>
1565 in ids</em></td>
1566 <td>Specify whether an active hint should be added to ids. With
1567 active hints, ids can be found quickly. However, they lead to larger
1568 IORs. Note that this option is disregarded <code>if
1572 </td>
1573 </tr>
1574 <tr>
1576 hint in poa names</em></td>
1577 <td>Specify whether an active hint should be added to POA
1578 names. With active hints, POA names can be found quickly. However, they
1581 </tr>
1582 <tr>
1584 size</em></td>
1585 <td>Specify the size of the active object map. If not
1587 </tr>
1588 <tr>
1590 reactivation of system ids</em></td>
1591 <td>Specify whether system ids can be reactivated, i.e., once
1592 an id that was generated by the system has been deactivated, will the
1593 user reactivate a new servant using the old id. If the user is not
1594 going to use this feature, the IORs can be shortened, an extra
1595 comparison in the critical upcall path removed, and some memory on the
1598 </td>
1599 </tr>
1600 <tr>
1602 <td>Specify which concurrency strategy to use. Range of values
1605 thread to service each connection. The default is reactive. </td>
1606 </tr>
1607 <tr>
1609 id policy based demultiplexing strategy</em></td>
1610 <td>Specify the demultiplexing lookup strategy to be used with
1614 </tr>
1615 <tr>
1617 <td>Specify the size of the POA map. If not specified, the
1619 </tr>
1620 <tr>
1622 policy based demultiplexing strategy</em></td>
1623 <td>Specify the demultiplexing lookup strategy to be used with
1626 This option defaults to use the <code>dynamic</code> strategy when <code>-ORBAllowReactivationOfSystemids</code>
1627 is true, and to <code>active</code> strategy when <code>-ORBAllowReactivationOfSystemids</code>
1628 is false. </td>
1629 </tr>
1630 <tr>
1632 <td>Specify the flags used for thread creation. Flags can be
1636 </tr>
1637 <tr>
1640 <td>In many platforms it is impossible to interrupt the server
1644 threads periodically poll the ORB to find out if they should shutdown.
1645 This option controls the period of the polling, expressed in
1646 milliseconds. Applications that do not shutdown, or that can otherwise
1647 ensure that no server threads will be running at shutdown (for example
1648 if all the clients terminate before the server) can disable the
1650 <p>If the option is not provided then the ORB uses the
1652 this flag also expresses the time in milliseconds (as a string
1654 disable polling entirely. This yields a slight performance improvement
1656 </td>
1657 </tr>
1658 <tr>
1660 id policy based demultiplexing strategy</em></td>
1661 <td>Specify the demultiplexing lookup strategy to be used with
1665 </tr>
1666 <tr>
1668 id policy based reverse demultiplexing strategy</em></td>
1669 <td>Specify the reverse demultiplexing lookup strategy to be
1673 </tr>
1674 <tr>
1676 policy based demultiplexing strategy</em></td>
1677 <td>Specify the demultiplexing lookup strategy to be used with
1681 </tr>
1682 </tbody>
1683 </table>
1684 </p>
1685 </blockquote>
1687 Similar to the
1688 server strategy factory, the client strategy factory supports those
1689 elements of TAO that are specific to the behavior of clients, which
1690 are any CORBA applications that actively establish connections, submit
1691 requests, and perhap receive responses. The client strategy factory
1692 provides control over several resources used by clients. TAO provides
1693 a default client strategy factory called
1695 <p>Typically, the following options are set via the service
1696 configurator
1703 file.</p>
1704 <p></p>
1705 <blockquote>
1706 <p>
1708 <tbody>
1709 <tr>
1712 </tr>
1713 <tr>
1715 / MT_NOUPCALL</em><br>
1717 </em>
1718 </td>
1719 <td><em>Please note that these two options are synonymous and can be used interchangeably.</em>
1721 use the single-threaded client connection handler, i.e., the leader
1723 nested upcalls and handling of new requests while waiting for the reply
1724 from a server.
1726 handler which uses the leader follower model. This model allows the use
1727 of multiple threads with a single Reactor. </p>
1730 instead of waiting in the Reactor using the Leader/Followers
1732 does not have to worry about new request showing up when waiting for a
1733 response. Further, this strategy cannot be used with BiDIR GIOP.
1734 Note that applications that require nested upcalls are not compatible
1735 with this strategy. Also note that this strategy will only affect synchronous
1736 two way calls, since there is no waiting for one way calls or AMI requests
1737 (at least not in the same sense as for synchronous two way calls).
1738 This strategy can also be used in an application that
1739 is both a client and a server where the server side is handled by a
1740 separate thread and the client threads are "pure" clients.
1741 Use in single threaded applications with both client and server roles is
1742 also possible but in these cases special care has to be taken to avoid
1743 deadlocks because of nested synchronous calls. Mixing in AMI requests and/or
1744 other asynchronous reactor (timer/notification) events might help solve
1745 such issues.
1746 When this strategy is set to RW, then also the -ORBFlushingStrategy
1748 <p>
1750 participates in the leader-follower model like MT, but, like
1751 RW, does not allow handling of nested CORBA upcalls within the
1752 waiting thread. It does allow handling of other non CORBA (ACE reactor events)
1753 like timers and ACE notification queue events. Note that with
1754 this strategy it is possible
1755 to "run out of threads" in a thread pool, and that TAO doesn't
1756 grow thread pools. Unlike RW, this does not require <a
1758 </p>
1760 </td>
1761 </tr>
1763 <tr>
1765 </td>
1768 handlers setup for sending messages need to be cleaned up
1769 when errors occur. This option has an effect only for
1772 automatically set up for cleaning the connection
1774 effect of registering and unregistering the connection
1775 handlers with the Reactor for every invocation, which has a
1777 </em> prevents this performance impact but leads to problems
1778 outlined
1779 <A
1783 here</A>
1785 </td>
1786 </tr>
1788 <tr>
1792 strategy uses the Reactor and non-blocking connects to connect and this
1793 strategy participates in the Leader/Followers protocol to synchronize
1795 for non-blocking connects but does not take part in the
1796 Leader/Followers protocol, thus it is better used only in single
1798 name implies, blocks the thread until connection is complete. Some of
1800 strategy.
1801 </td>
1802 </tr>
1803 <tr>
1806 the ORB to use when a Messaging Sync Scope policy is not used. When not
1807 supplied, the default sync scope is SYNC_WITH_TRANSPORT.
1808 </td>
1809 </tr>
1810 <tr>
1813 means that the Transport does not multiplex requests on a connection.
1814 At a time, there can be only one request pending on a connection.
1816 one request at the same time on a connection. This option is often used
1817 in conjunction with AMI, because multiple requests can be sent "in
1820 </td>
1821 </tr>
1822 <tr>
1824 <td>Options of the same names as the command-line options
1826 can also be applied client strategy factory service. Any
1827 option provided on the command line will override the
1828 corresponding option in the service configurator
1829 file.
1830 </td>
1831 </tr>
1832 </tbody>
1833 </table>
1834 </p>
1835 </blockquote>
1838 is used with the DIOP and MIOP protocols managing the UDP connectionless
1839 sockets (normally one-way calls only) instead of the standard IIOP TCP/IP
1840 two-way connection based sockets. It accepts the options shown below.
1841 (Any options required should be given
1842 to the TAO_UIPMC_Protocol_Factory between the two double-quotes at the end
1843 of the line as a space separated list; however none are required as all
1844 options take default values if not specified.) This factory can be loaded
1845 dynamically using service configurator directives of the form (all on one line):
1846 <p><code>dynamic UIPMC_Factory Service_Object *
1848 <p>Normally however in order to set up the TAO_UIPMC_Protocol_Factory correctly,
1849 the application will have to use other service configurator directives as well;
1850 for example:</p>
1851 <code>dynamic UIPMC_Factory Service_Object *
1853 static Resource_Factory "‑ORBProtocolFactory IIOP_Factory
1855 dynamic PortableGroup_Loader Service_Object *
1857 <blockquote>
1858 <p></p>
1860 <tbody>
1861 <tr>
1864 </tr>
1865 <tr>
1866 <td ALIGN="left"><code>‑ORBListenerInterfaces</code> <em>targetNetwork=localNetwork[,...] | CopyPreferredInterfaces</em></td>
1868 which network/interface(s) are to be used to listen for communications from the multicast addressed
1869 remote client(s). If this option is unspecified (or if none of the given
1871 the attempted listener) then the default listener will be set-up as specified or defaulted with the
1874 address(es), it will use the local ip address(es) matching the <em>localNetwork</em> string. Simple
1875 wildcards can be used for both parameters, and multiple paired <em>targetNetwork=localNetwork</em>
1876 strings can be specified using comma separators (no embedded spaces allowed) or via additional
1878 and/or multiple interfaces at the same time for each listener established via such
1880 <p>
1881 For example, for a machine with two network cards identified by the ip addresses
1883 <code>‑ORBListenerInterfaces 239.255.*=*10,224.255.*=*20</code> or the pair of directives
1884 <code>‑ORBListenerInterfaces 239.255.*=*10 ‑ORBListenerInterfaces 224.255.*=*20</code>
1885 to establish the link to listen for <em>239.255.*</em> multicast addresses on the first interface, and
1887 <em>targetNetwork</em> can use any string, but must typically match the value writen into the IOR and so
1888 will usually be a dotted decimal multicast address in the administrative "site local" range,
1889 (<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>).
1890 <p><em>localNetwork</em> must use a local dotted decimal address, because it will be matched with
1891 the local ip interfaces.</p>
1892 The same client-side (sender) assignments as specified by the ORB_init supplied command line option(s)
1894 <em>CopyPreferredInterfaces</em> parameter as in <code>‑ORBListenerInterfaces CopyPreferredInterfaces</code>
1895 (which may be prefixed and/or postfixed by other <code>‑ORBListenerInterfaces <em>targetNetwork=localNetwork</em></code>
1896 options as required).
1897 </tr>
1898 <tr>
1902 directives (if any, see below) match the actual multicast address being set-up.
1903 <p>If disabled (<em>0</em>) the multicast address will be listened for only on the default multicast
1905 local interface on the system), the loopback interface is normally excluded.</p>
1907 interface(s) which are multicast enabled (again the loopback interface is normally excluded).
1908 </td>
1909 </tr>
1910 </tbody>
1911 </table>
1912 </blockquote>
1916 manage its UDP sockets, you should also look at that factories configuration
1917 options. The MIOP factory accepts it own options detailed below which
1918 should be specified between the two double-quotes shown here as a space
1919 separated list; however none are required as all options take default
1920 values if not specified. This factory can be loaded dynamically using a
1921 service configurator directive of the form (all on one line):
1922 <p><code>dynamic MIOP_Resource_Factory Service_Object *
1924 You would normally have to use other service configurator
1925 directives as well; for example:
1926 <p><code>dynamic UIPMC_Factory Service_Object *
1928 static Resource_Factory "‑ORBProtocolFactory IIOP_Factory
1930 dynamic PortableGroup_Loader Service_Object *
1932 dynamic MIOP_Resource_Factory Service_Object *
1934 Since MIOP uses UDP sockets (which is not a "reliable" transport unlike tcp/ip)
1935 it is easy to configure MIOP in such a way that messages will not actually
1936 reach the servant. The options below are intended to maximize MIOP reliability
1937 but they must be used with care; users of MIOP must understand that large
1938 messages are sent in fragments and they have to be reassembled by the server in
1939 their entirety to be usable by the servant. If even a single data
1940 fragment/packet is lost, the whole message cannot be reconstructed and will be
1941 unusable. There is no way for the servant to even know it has missed such a
1942 MIOP message, and being a one-way protocol, neither will the client be aware
1943 that the message has been lost. Fragments can be lost due to a variety of
1944 reasons:
1945 <p></p>
1946 <ul>
1947 <li>
1948 The client sends too large a message fragment, or sends messages too fast,
1949 overwhelming the client socket's transmission buffer. (In which case the
1950 client-side (sender) OS simply ignores the excess send requests and some of the
1951 fragments are not actually sent on the wire.)
1952 <li>
1953 The server socket's receive buffer became too full to acquire the fragments off
1954 the wire. (In this case the client is again sending messages too fast, but this
1955 time it is the servant that is too slow to process the messages it has already
1956 received.)
1957 <li>
1958 Something happend to the network or routing and the packet was lost between the
1959 client and the server, or the server OS failed to react to the hardware network
1960 device in a timely manor so that network packets were lost.</li></ul>
1961 <p></p>
1963 the client adapting/throttling its sending rate so as to not overflow the
1964 capacity of the client's operating system sending buffer and the receiving
1965 buffer of the server socket. If there are multiple clients all sending to the
1966 same server, all of these clients must be configured to slow down their sending
1967 rate (as a software system design descision) as otherwise the server's receive
1968 buffer will become swamped and some messages will be lost.</p>
1969 <blockquote>
1970 <p>
1972 <tbody>
1973 <tr>
1974 <th>
1975 Option</th>
1976 <th>
1977 Description</th>
1978 </tr>
1979 <tr>
1982 although this default can be overriden when the TAO libraries are built in the <CODE>
1983 ace/config.h</CODE>, by specifying the new default such as <CODE>#define TAO_DEFAULT_MIOP_EAGER_DEQUEUEING false</CODE>
1984 which in this case would turn this off by default, unless specified in the
1985 service file. If disabled (0) each thread servicing the MIOP listener will only
1986 dequeue enough MIOP message fragments from the socket receive buffer to
1987 complete a single full MIOP message which it will then process. This action
1988 reduces the amount of user memory consumed by the server process, but it also
1989 increases the likelihood of the OS sockets receive buffer overflowing (as
1990 whilst processing each message, the thread cannot dequeue other incomming
1991 message fragments). If enabled (1) it specifies that each server thread will
1992 attempt to dequeue all available MIOP messages from the receiver's socket and
1993 queue these up in a user memory FIFO queue, before attempting to process a
1994 single MIOP message from the head of this FIFO queue. This action attempts to
1995 speed up the dequeueing of MIOP messages from the OS socket receive buffer
1996 (with a corresponding increase in the amount of user memory consumed by the
1997 server process) so as to limit the number of MIOP messages that the server may
1998 miss due to the OS sockets receive buffer becoming full.
1999 </td>
2000 </tr>
2001 <tr>
2004 <P>This client-side (sender) option (if enabled, see <code>‑ORBSendThrottling</code> below)
2005 specifies a non-zero, positive amount of time (in
2006 uSec, i.e. microseconds) that it takes to transmit and process an individual
2008 option above. (This is the total of the
2010 network transmission delay.) The client attempts to keep the rate at which it
2011 sends messages down to this speed by purposly delaying sending message
2012 fragments, if it would exceeding this capacity (but also see the <code>‑ORBSendHighWaterMark</code>
2013 option below). The default is same value as specified, or is defaulted by, the <code>
2015 microseconds not bytes. (This default delay value is approximatly the time
2017 values will throttle back the clients transmittion rate, smaller values will
2020 to be altered if the size is changed.
2021 </P>
2022 </td>
2023 </tr>
2024 <tr>
2027 fragments that a client can break the outgoing message up into. The limit must
2028 be a positive number or zero (indicating an unlimited number). The default is
2032 which in this case would turn off fragmentation by default (as only a single
2033 fragment would be allowed), unless a new limit is specified in the service
2034 file. Any messages that are too large and require more fragments than allowed
2035 by this setting are simply not transmitted by the client (the message is
2036 effectly lost without any error indication, other than possibly a debug
2037 message). This setting can be used as a safety setting to stop swamping the
2038 network and servants with abnormally large messages, or during testing to
2039 "lose" large messages for whatever reason.
2040 </td>
2041 </tr>
2042 <tr>
2044 | MEMORY</em></td>
2047 fragments that cannot be reassembled after a certain delay should be removed
2048 from the waiting queue (i.e. considered lost messages). The other options are <em>
2050 messages in the waiting queue will be limited, or the whole memory comsumed by
2051 the incomplete messages in the waiting queue will be limited.
2052 </td>
2053 </tr>
2054 <tr>
2056 <td ALIGN="left">This option specifies the numerical limit for the server's <code>‑ORBFragmentsCleanupStrategy</code>
2061 the limit indicates the number of bytes reserved for the whole queue (with the
2062 default being 3000000 bytes).
2063 </td>
2064 </tr>
2065 <tr>
2068 each individual MIOP fragment, which must be between <em>272</em> and <em><code>ACE_MAX_UDP_PACKET_SIZE</code>
2070 values decrease) the number of fragments required to send the actual payload
2071 data. Each fragment requires the overhead of a new MIOP header (32 bytes)
2072 prefixing the actual data being sent, with the header reducing the actual
2073 usable payload data inside each fragment. Roughly this value can be considered
2074 as the MTU (Maximum Transmission Unit) set for the specific connection. The
2078 when the TAO libraries are built. <b>Note: most gateways and routing networks
2082 below. Note also if this value is changed (during development) and the <code>‑ORBMaxFragmentRate</code>
2083 option below is also specified, you should change that value by the same
2084 factor, otherwise the speed of transmission will be effected as these two
2085 options specify a working ratio.
2086 </td>
2087 </tr>
2088 <tr>
2091 message buffer, i.e., how much data can be received directly off the wire by the
2092 server and queued for processing by the servant whilst it is busy. If specified
2093 in the service configuration file, this value will override (for MIOP only) the
2094 value specified by the corresponding ORB_init parameter. If NOT specified in
2095 either place, the default value for the system itself will be used. Again for a
2097 whatever value is actually specified it is normally doubled internally to take
2098 account of the control structures required to track the messages themselves and
2099 so it is not a hard limit. Specifying as large a value as possible (i.e.
2101 option is advisable to maximize the available socket's receive buffer space, but
2102 obviously this is a trade off between available memory and other OS non-paged
2103 memory uses.
2104 </td>
2105 </tr>
2106 <tr>
2108 <td ALIGN="left">This client-side (sender) option (if enabled, see <code>‑ORBSendThrottling</code> below)
2109 is the usable size of the message
2110 buffer, i.e how much data can be sent without introducing delays into the
2112 option above). <b>Its default value is the size of the buffer maintained by the
2113 Operating System for the sending socket at the client side (see the <code>‑ORBSndSock</code>
2114 option below) and although it should ideally be based on the server's receive
2115 socket buffer size, that information is not available to the client, and the
2116 two values normally default to the same size anyway.</b> If in doubt specify
2119 broadcasting to the same server, when each client should only use a fraction of
2120 the full buffer size based upon the number of clients actually in use).
2121 </td>
2122 </tr>
2123 <tr>
2126 although this default can be overriden when the TAO libraries are built in the <CODE>
2127 ace/config.h</CODE>, by specifying the new default such as <CODE>#define TAO_DEFAULT_MIOP_SEND_THROTTLING false</CODE>
2128 which in this case would turn off throttling by default, unless specified in
2129 the service file. If disabled (0) the client will always attempt to transmit
2130 all MIOP message fragments without any delay. If enabled (1) the client will
2131 attempt to automatically restrict the speed of sending individual MIOP messages
2132 to maintain an average of <code>‑ORBMaxFragmentSize</code> bytes per <code>‑ORBMaxFragmentRate</code>
2134 of data are currently being transmitted or are in progress via each individual transport
2135 (i.e. each individual client-side (sender) connection to the server).
2136 </td>
2137 </tr>
2138 <tr>
2141 message buffer. If specified in the service configuration file, this value will
2142 override (for MIOP only) the value specified by the corresponding ORB_init
2143 parameter. If NOT specified in either place, the default value for the system
2145 limits the maximum size of an individual message fragment, larger fragments can
2146 be simply ignored (i.e. packet loss) by the client's socket without any error
2148 set with care. For a Linux type OS, the system's SndSock is usually defaulted to
2150 normally doubled internally to take account of the control structures required
2151 to track the messages themselves and so it is not a hard limit.
2152 </td>
2153 </tr>
2154 </tbody>
2155 </table>
2156 </p>
2157 </blockquote>
2159 The TIME_POLICY manager controls the actual TIME_POLICY strategy used for
2160 ORB timers and countdowns. TAO provides a default strategy manager called
2162 <p>Typically, the following options is set via the service
2163 configurator
2166 <p><code>static
2171 file.</p>
2172 <p></p>
2173 <blockquote>
2174 <p>
2176 <tbody>
2177 <tr>
2180 </tr>
2181 <tr>
2184 defines the TIME_POLICY strategy to load. TAO provides two
2185 standard TIME_POLICY strategies:</p>
2187 equivalent of <code>gettimeofday</code> to return a current time value. This is the default for
2191 <code>TAO_USE_HR_TIME_POLICY_STRATEGY</code> has been defined this becomes the default for TAO).</p>
2192 <p>Any other value is assumed to denote the exact name of a dynamically loadable
2194 test provides an example of this functionality.</p>
2195 </td>
2196 </tr>
2197 </tbody>
2198 </table>
2199 </p>
2200 </blockquote>
2201 <hr>
2202 <p>Back to the TAO <a href="components.html">component options and tuning documentation</a>.<!--#include virtual="/~schmidt/cgi-sig.html" -->
2203 </body>
2204 </html>