diff options
| author | venkita <venkita@ae88bc3d-4319-0410-8dbf-d08b4c9d3795> | 2003-10-19 22:17:59 +0000 |
|---|---|---|
| committer | venkita <venkita@ae88bc3d-4319-0410-8dbf-d08b4c9d3795> | 2003-10-19 22:17:59 +0000 |
| commit | 6517518d3805dc5e512218d5e7f257feb4ec6328 (patch) | |
| tree | 6c432b166dc690f99ce8d44d574fca02998bf743 | |
| parent | 5721863770e6ba35d61b72c2ccd8b532906c3393 (diff) | |
| download | ATCD-6517518d3805dc5e512218d5e7f257feb4ec6328.tar.gz | |
ChangeLogTag: Sun Oct 19 17:11:21 2003 Venkita Subramonian <venkita@cs.wustl.edu>
| -rw-r--r-- | TAO/ChangeLog | 10 | ||||
| -rw-r--r-- | TAO/docs/releasenotes/ftrt_ec.html | 231 | ||||
| -rw-r--r-- | TAO/docs/releasenotes/index.html | 2745 | ||||
| -rw-r--r-- | TAO/docs/releasenotes/rtc10_sched.html | 293 | ||||
| -rw-r--r-- | TAO/orbsvcs/FTRT_Event_Service/Readme | 192 | ||||
| -rw-r--r-- | TAO/orbsvcs/orbsvcs/RTCosScheduling/README | 301 |
6 files changed, 1849 insertions, 1923 deletions
diff --git a/TAO/ChangeLog b/TAO/ChangeLog index 1e0cd7b2e69..a7e95e7ab1f 100644 --- a/TAO/ChangeLog +++ b/TAO/ChangeLog @@ -1,3 +1,13 @@ +Sun Oct 19 17:11:21 2003 Venkita Subramonian <venkita@cs.wustl.edu> + + * orbsvcs/FTRT_Event_Service/Readme: + * orbsvcs/orbsvcs/RTCosScheduling/README: Deleted these files and + moved them as part of release notes. See below. + + * docs/releasenotes/index.html: + * docs/releasenotes/rtc10_sched.html: + * docs/releasenotes/ftrt_ec.html: Added these to release notes. + Sun Oct 19 15:46:42 2003 Huang-Ming Huang <hh1@cse.wustl.edu> * orbsvcs/orbsvcs/RTCosScheduling_Static.dsp: diff --git a/TAO/docs/releasenotes/ftrt_ec.html b/TAO/docs/releasenotes/ftrt_ec.html new file mode 100644 index 00000000000..e43008e4084 --- /dev/null +++ b/TAO/docs/releasenotes/ftrt_ec.html @@ -0,0 +1,231 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<!-- $Id$ --> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="Author" content="Venkita Subramonian"> + <meta name="GENERATOR" content="Mozilla/4.79 [en] (Windows NT 5.0; U) [Netscape]"> + <title>Fault Tolerant Real-Time Event Service</title> +</head> +<body> + +<center> +<h2> +Fault Tolerant Real-time Event Service</h2></center> + +<h3> +Introduction</h3> +The Fault Tolerant Real-time Event Service provides the fault tolerant +capability to the TAO Real-time Event Service. Essentially, it allows you +to start several event services in different machines. These event services +form an object group which can be treated as a logical event service by +clients. The clients only communicate with the primary (leader) of the +object group. The rest event channels in the object group are called backups. +Once the primary dies, one of the backups will assume the reponsibility +of primary and this process is transparent to the clients. +<p>The key to provide fault tolerance to event channels is to replicate +the states of primary to its backups. There are two kinds of states in +the event channels, transient and persistent. A transient state in the +event channels is the events which are yet to be delivered to the consumers. +Those events are hard to replicate because the time scale is too small. +They might be delivered late or out of scope if we tried to replicate the +events. However, the subscription information occurs at a suitable +<br>time scale for replication, and is in fact more essential for the delivery +of events since it establishes a kind of connectivity from suppliers to +consumers. Therefore, we only replicate the subscriptions +<p>Once the primary receives the subscription requests from the clients, +it will replicate the requests to the backup event channels.In order to +provide time bounds on replication, we introduce the concept of transaction +depth. If we say the transaction depth is n, that means a subscription +method invocation has to be blocked until the first n replicas complete +the subscription operation, illustrated by the assured-replicate arc in +the figure. Other replicas can get the state change via a so called soft-replicate +which conceptually means the replication is not assured to complete before +the subscription operation returns. So, if the soft-replicate fails +due to loss of the primary, we will have only the assured depth of replication. +The clients are allowed to configure the transaction depth to tradeoff +reliability and responsiveness. Furthermore, it is necessary to roll back +an operation in some replicas if the transaction depth can not be met. +In addition, we can use either two-way or AMI calls for assured-replication +and one-way operations for soft-replication. +<p><b><font color="#FF6666">Important Note</font> :</b> In current stage, +the Fault Tolerant Event Service can only be made under MPC build. The +conventional makefiles are yet to be supported. +<br> +<h3> +Programs</h3> +This directory contains the following programs: +<p>ftrt_eventservice : Implements the functionality of fault tolerant event +channel. It can be started directly or be started by the ft_factory. +<p>ftrtec_factory_service : A program used to spawn the ftrt_eventservice +process. The process it create can be controled through "test.cfg" whose +contents should begin with the repository id of EventChannel followed by +the executable path of ftrt_eventservice. +<p>ftrtec_gateway_service : An intermediator program between the ftrt_eventservice +and the clients which do not support FT CORBA. +<p>consumer : A shell script to start the consumer test program. The actual +consumer pragram is in orbsvcs/tests/FtRtEvent. +<p>supplier : A shell script to start the supplier test program. The actual +supplier pragram is in orbsvcs/tests/FtRtEvent. +<p>ftec : a shell script to start ftrt_eventservice. +<br> +<h3> +Quick start:</h3> + Run the applications as follows: +<br> +<p> 1. Start Naming_Service +<br> $ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -m 1 +<br> or you can use the shell script NameService +in this directory to start it. +<p> 2. Start the ftrt_eventservice. Use the "-p" option to start +it as a primary and +<br> use the "-j" option to start it as a backup. +<p> $ ./ftec -p +<br> $ ./ftec -j +<br> $ ./ftec -j +<br> +<p> 3. Start the consumer and supplier. +<br> $ ./consumer +<br> $ ./supplier +<br> +<h3> +How do we add a new FTRTEC to the system?</h3> + Just use +<p> ./ftec -j +<p> The newly created process will contact to the naming service +and then join to +<br> the existing object group. +<br> +<h3> +Is there any adjustable options for FTRTEC?</h3> + Here is the list of options for the ftec script +<p> -sciop +Use SCIOP for CORBA communication +<br> -sctp +Use SCTP for fault detection +<br> -hb n +Specify the heart beat interval in sec +<br> +for SCTP connection, this option also activate sctp option. +<br> -ami +Use AMI call for replication messages (The default is +<br> +two-way CORBA call for replication) +<br> -p +activate as a primary replica. +<br> -j +activate as a backup replica. +<br> +<p> Below are some options that are used for the consumer and supplier +<br> test scripts. +<p> -sciop +Use SCIOP for CORBA communication. This requires that the Naming +<br> +Service and ftec are also started using SCIOP transport protocol. +<p> -d n +Specify the transaction depth. The transaction depth indicates the +<br> +number of replicas that must complete the subscription request before +<br> +the request can return. +<p> -t f.f +For supplier only. Specify the time interval between event sending +<br> +in seconds, this value should be a float point. +<p> If you the naming service are not running at the same machine +with above programs, you can always set the environmental variables NameServiceIOR +before starting the ftec, consumer or supplier. +<br> +<h3> +How do I start the FTRTEC using ftrtec_factory_service?</h3> +The ftrtec_factory_service is a small program that can instaniate a ftrt_eventservice +on demand. It exports the FT::GenericFactory interface to its client. There +are two ways that you can get the IOR for the factory object. 1) +specify the name you want the factory register to the naming service +and then get the IOR from the naming service by the name. 2) output the +IOR to a file when the factory starts. Here are the options +<p> ftrtec_factory_service : +<p> -i id_string +The id field of the name that is used to register to the naming service +<br> -k kind_string +The kind field of the name that is used to register to the naming service +<br> -o output_filename +The output file name for the factory IOR. +<p>Once you get the IOR for the factory, you can use create_object to intantiate +the ftrt_eventservice. +<br>Here are the parameters in create_object() to control how ftrt_eventservice +is created. +<p> type_id : this value should be "IDL:FtRtecEventChannelAdmin/EventChannel:1.0" +<br> the_criteria : the_criteria is a sequence of Property +which in term consists of "nam" and "value". Below a a list of possible +nam and values. +<br> +<br> +<table BORDER COLS=2 WIDTH="100%" > +<tr> +<td>nam</td> + +<td>value</td> +</tr> + +<tr> +<td>FTEC_MEMBERSHIP</td> + +<td>PRIMARY +<br>BACKUP +<br>NONE</td> +</tr> + +<tr> +<td>FTEC_DETECTOR_TRANSPORT_PROTOCL</td> + +<td>TCP +<br>SCTP</td> +</tr> + +<tr> +<td>FTEC_HEART_BEAT</td> + +<td>the heart beat value in sec. (Note, you have to specify it using string, +i.e. the_criteria[0].value <<= "5");</td> +</tr> + +<tr> +<td>FTEC_REPLICATION_STRATEGY</td> + +<td>AMI +<br>(If not specified, the ftrt_eventservice use default two-way call for +replication) +<br> </td> +</tr> + +<tr> +<td>NameServieIOR</td> + +<td>the corbaloc representation for the naming service +<br> </td> +</tr> +</table> + +<p> Any nam string started with "-" will be used as a command line +option to start ftrt_eventservice. For example, if you specfiy the name +as "-ORBEndpoint" and value as "sciop://" then the ftrt_eventservice can +be started using sciop. +<br> +<h3> +How do I use the ftrtec_gateway_service program ?</h3> +The FTRTEC uses some features in FT CORBA that requires every client to +use FT ORB to work. If your client is written based other ORBs other +than TAO. You cannot get the desired fault tolerance feature. In this case +you can have the ftec_gateway as an intermediator between the FTRTEC and +you client program. +<br>For example, if you have an existing client called my_supplier. +<p> # setting up the event channel group as previously +stated. +<p> $ftrtec_gateway_service -o gateway.ior +## start the gateway and output the IOR of the gateway to a file +<br> $my_supplier -i file://gateway.ior ## start +the supplier using the gateway +<br> +</body> +</html> diff --git a/TAO/docs/releasenotes/index.html b/TAO/docs/releasenotes/index.html index 5b55192a2c8..b7c1dca3a6f 100644 --- a/TAO/docs/releasenotes/index.html +++ b/TAO/docs/releasenotes/index.html @@ -1,7 +1,8 @@ <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <head> - + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.79 [en] (Windows NT 5.0; U) [Netscape]"> <title>TAO Release Information and TODO List</title> </head> <body text="#000000" bgcolor="#FFFFFF"> @@ -9,16 +10,15 @@ <center> <hr></center> -<center> <h3> - -Release Information for The ACE ORB (TAO)</h3></center> This document -contains information on the following topics related to the <a -href="../../VERSION">current release</a> of <a -href="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</a>: - -<TABLE cellpadding=10 cellspacing=0 border=0> - -<TD valign="top"> +<center> +<h3> +Release Information for The ACE ORB (TAO)</h3></center> +This document contains information on the following topics related to the +<a href="../../VERSION">current +release</a> of <a href="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</a>: +<table BORDER=0 CELLSPACING=0 CELLPADDING=10 > +<tr> +<td VALIGN=TOP> <ul> <li> <a href="#ace">ACE Wrappers</a></li> @@ -39,13 +39,13 @@ href="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</a>: <a href="#poa">Portable Object Adapter (POA)</a></li> <li> -<a HREF="../poa_migration.html">POA Migration Notes</a></li> +<a href="../poa_migration.html">POA Migration Notes</a></li> <li> <a href="#ami">Asynchronous Method Invocation (AMI)</a></li> <li> -<a href="./amh.html">Asynchronous Method Handling (AMH)</a></li> +<a href="amh.html">Asynchronous Method Handling (AMH)</a></li> <li> <a href="#interceptor">Portable Interceptors</a></li> @@ -67,14 +67,13 @@ href="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</a>: <li> <a href="PSS.html">Persistent State Service</a></li> +</ul> +</td> -</UL> -</TD> -<TD valign="top"> -<UL> - +<td VALIGN=TOP> +<ul> <li> -<a href="#nservices">Naming Service </a> +<a href="#nservices">Naming Service </a></li> <li> <a href="#tservices">Trading Service</a></li> @@ -109,29 +108,37 @@ href="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</a>: <li> <a href="#miop">Multicast InterORB Protocol (MIOP)</a></li> -<li><a href="#loadbalancer">Load Balancer</a></li> +<li> +<a href="#loadbalancer">Load Balancer</a></li> <li> <a href="ec.html">TAO's Real-time Event Service</a></li> <li> +<a href="ftrt_ec.html">TAO's Fault Tolerant Event Service</a></li> + +<li> <a href="#scheduling">TAO's Scheduling Service</a></li> <li> -<a href="#logging">TAO's Logging Service</a></li> +<a href="rtc10_sched.html">RTCORBA 1.0 Scheduling Service</a></li> -</UL> -</TD> -<TD valign="top"> -<UL> +<li> +<a href="#logging">TAO's Logging Service</a></li> +</ul> +</td> -<li><!-- <a href="../../CIAO/docs/releasenotes.html"> --> - <a href="http://www.cs.wustl.edu/~nanbor/projects/CIAO-src/docs/releasenotes.html">CORBA Component Model (CIAO) </a> +<td VALIGN=TOP> +<ul> +<li> +<!-- <a href="../../CIAO/docs/releasenotes.html"> --><a href="http://www.cs.wustl.edu/~nanbor/projects/CIAO-src/docs/releasenotes.html">CORBA +Component Model (CIAO) </a></li> -<li><a href="#CORBA-conformance">CORBA Standards Conformance</a></li> +<li> +<a href="#CORBA-conformance">CORBA Standards Conformance</a></li> <li> -<a href="#fault_tolerance">TAO's support for FT services </a></li> +<a href="#fault_tolerance">TAO's support for FT services </a></li> <li> <a href="#apps">Regression Tests</a></li> @@ -151,97 +158,87 @@ href="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</a>: <li> <a href="#locate">Locate requests</a></li> -<li><a href="#localobject">Local Interfaces</a></li> +<li> +<a href="#localobject">Local Interfaces</a></li> <li> <a href="TODO.html">Our TODO list</a></li> - -</TABLE> - +</ul> +</td> +</tr> +</table> A complete list of all modifications to TAO is available in the <a href="../../ChangeLog">ChangeLog</a>. <p> <hr> - <h3> <a NAME="ace"></a>ACE Wrappers</h3> -<p>Current status: (As of July 07, 2003.) +Current status: (As of July 07, 2003.) <ul> <li> - -The following changes are related to improving memory management of -Event Handlers when they interact with Reactors (and Timer Queues). -When a handler is registered with the Reactor, the Reactor increments -the reference count on the handler. The Reactor also increments this -reference count when making upcalls on the handler. The reference -count is decremented when an upcall completes or when the handler is -removed from the Reactor. <p> - -This mechanism is similar to what happens between POAs and Servants -and it allows for the safe deletion of handlers. This mechanism is -particularly need for multi-threaded applications that can have -multiple threads executing upcalls on a handler that needs to be -shutdown in a safe manner. The following illustrates an example of -how this mechanism works: <p> - +The following changes are related to improving memory management of Event +Handlers when they interact with Reactors (and Timer Queues). When a handler +is registered with the Reactor, the Reactor increments the reference count +on the handler. The Reactor also increments this reference count when making +upcalls on the handler. The reference count is decremented when an upcall +completes or when the handler is removed from the Reactor.</li> + +<br> +<p> +<p>This mechanism is similar to what happens between POAs and Servants +and it allows for the safe deletion of handlers. This mechanism is particularly +need for multi-threaded applications that can have multiple threads executing +upcalls on a handler that needs to be shutdown in a safe manner. The following +illustrates an example of how this mechanism works: <ul> -<li> When a handler is created, it reference count is one. - -<li> After the handler is registered with the Reactor, it reference -count becomes two. - -<li> At this point, the handler creator can let go of the handler -reference, bringing down the reference count to one. +<li> +When a handler is created, it reference count is one.</li> -<li> For each thread executing upcalls on the handler, the Reactor -increments the reference count by one. So if three threads were -simultaneously making upcalls on a handler, the reference count would -be four. +<li> +After the handler is registered with the Reactor, it reference count becomes +two.</li> -<li> Assuming an external event (and thread) decides to close the -handler. It simply removes the handler from the Reactor. This -decreases the reference count to three. +<li> +At this point, the handler creator can let go of the handler reference, +bringing down the reference count to one.</li> -<li> As each thread completes their upcall, the reference reduces. +<li> +For each thread executing upcalls on the handler, the Reactor increments +the reference count by one. So if three threads were simultaneously making +upcalls on a handler, the reference count would be four.</li> -<li> Once the final thread exits the upcall, the reference reaches -zero, and the handler is finally deleted. +<li> +Assuming an external event (and thread) decides to close the handler. It +simply removes the handler from the Reactor. This decreases the reference +count to three.</li> -</ul> <p> +<li> +As each thread completes their upcall, the reference reduces.</li> +<li> +Once the final thread exits the upcall, the reference reaches zero, and +the handler is finally deleted.</li> +</ul> This mechanism ensures that the handler is not deleted until the final -upcall thread exits the handler. <p> - -Reference counting on handlers is optional and is disabled by default. -To enable reference counting on a handler, reset its reference -counting policy to "ENABLED". <p> - -To facilitate reference counting of handlers, an ACE_Event_Handler_var -class was added. This class is akin to the -PortableServer::ServantBase_var class. <p> - -Similar reference counting related changes were made to the Timer -Queues so that handlers can be used in a thread safe manner with the -queues. <p> - -The Connector implementation was completely revised to utilize the new -memory management mechanisms and remove existing concurrency bugs. <p> +upcall thread exits the handler. +<p>Reference counting on handlers is optional and is disabled by default. +To enable reference counting on a handler, reset its reference counting +policy to "ENABLED". +<p>To facilitate reference counting of handlers, an ACE_Event_Handler_var +class was added. This class is akin to the PortableServer::ServantBase_var +class. +<p>Similar reference counting related changes were made to the Timer Queues +so that handlers can be used in a thread safe manner with the queues. +<p>The Connector implementation was completely revised to utilize the new +memory management mechanisms and remove existing concurrency bugs. +<p>Several new examples/tests were added: Reference_Counted_Event_Handler_Test, +MT_Reference_Counted_Event_Handler_Test, MT_Reference_Counted_Notify_Test, +Timer_Queue_Reference_Counting_Test, NonBlocking_Conn_Test, Reactor_Registration_Test, +WFMO_Reactor_Test, Timer_Cancellation_Test</ul> -Several new examples/tests were added: -Reference_Counted_Event_Handler_Test, -MT_Reference_Counted_Event_Handler_Test, -MT_Reference_Counted_Notify_Test, Timer_Queue_Reference_Counting_Test, -NonBlocking_Conn_Test, Reactor_Registration_Test, WFMO_Reactor_Test, -Timer_Cancellation_Test - -</li> -</ul> <hr> -</ul> - <h3> <a NAME="idl"></a>IDL Compiler</h3> -Point of contact: <a href="mailto:j.parsons@vanderbilt.edu"> -Jeff Parsons</a> +Point of contact: <a href="mailto:j.parsons@vanderbilt.edu">Jeff Parsons</a> <p>Current status: (As of October 1, 2002.) <ul> <li> @@ -249,25 +246,21 @@ Generated code closely follows the C++ Mapping specified in the latest C++ mapping for CORBA 2.3 (Document ptc/98-09-03).</li> <li> -IDL compiler is now able to generate code that support native C++ -exceptions on the stubs and skeletons. With this strict mapping, the -CORBA::Environment parameter is no longer generated. -The default behavior is to generate code without the extra parameter - on plaforms with native exceptions and with the extra - parameter in platforms without native exceptions. - Use the -Ge flag to override the defaults. -</li> +IDL compiler is now able to generate code that support native C++ exceptions +on the stubs and skeletons. With this strict mapping, the CORBA::Environment +parameter is no longer generated. The default behavior is to generate code +without the extra parameter on plaforms with native exceptions and with +the extra parameter in platforms without native exceptions. Use the -Ge +flag to override the defaults.</li> <li> -We are now able to handle shared case labels and default label in -unions. In addition, whenever appropriate, we are also able to -generate the "default ()" operation. -</li> +We are now able to handle shared case labels and default label in unions. +In addition, whenever appropriate, we are also able to generate the "default +()" operation.</li> <li> -We are now able to handle recursive types. We are also able to -generate optimized typecodes. -</li> +We are now able to handle recursive types. We are also able to generate +optimized typecodes.</li> <li> Struct members of type strings and arrays of strings now use the managed @@ -313,27 +306,26 @@ Verified support for the "long long" and "unsigned long long" datatypes. On platforms that do not support 64 bit longs we provided <i>partial</i> emulation through ACE_U_LongLong.</li> -<li> Perfect Hashed Operation Lookup Strategy has been added to the -IDL Compiler. -P flag to <code>tao_idl</code> enables the perfect -hased lookup strategy. This strategy uses <a -href="http://www.cs.wustl.edu/~schmidt/gperf.ps.gz">GPERF</a>, the -GNU's Perfect Hash Function Generator written by Dr.Douglas -C. Schmidt. Right now, GPERF works only on Solaris. Any work on -porting GPERF to other platforms will be highly -appreciated.</L1></li> +<li> +Perfect Hashed Operation Lookup Strategy has been added to the IDL Compiler. +-P flag to <tt>tao_idl</tt> enables the perfect hased lookup strategy. +This strategy uses <a href="http://www.cs.wustl.edu/~schmidt/gperf.ps.gz">GPERF</a>, +the GNU's Perfect Hash Function Generator written by Dr.Douglas C. Schmidt. +Right now, GPERF works only on Solaris. Any work on porting GPERF to other +platforms will be highly appreciated.</L1></li> <li> The <<= and >>= operators for user-defined types are now generated.</li> -<li> Completely redesigned the IDL compiler using the Visitor -patterns. Many incomplete issues have been resolved. These include -support for "sequence of typecodes", passing object references as in, -inout, and out parameters. Code generation for sequences is also -properly handled i.e., for a named sequence such as <CODE>typedef -sequence<char>CharSeq;</CODE>, we now generate a new class (and -hence a type) called "class CharSeq". Arrays are still being worked -out and will be done soon. An important difference in the generated -code is that the skeletons now use a table driven approach very +<li> +Completely redesigned the IDL compiler using the Visitor patterns. Many +incomplete issues have been resolved. These include support for "sequence +of typecodes", passing object references as in, inout, and out parameters. +Code generation for sequences is also properly handled i.e., for a named +sequence such as <tt>typedef sequence<char>CharSeq;</tt>, we now generate +a new class (and hence a type) called "class CharSeq". Arrays are still +being worked out and will be done soon. An important difference in the +generated code is that the skeletons now use a table driven approach very similar to the stubs.</li> <li> @@ -387,271 +379,309 @@ are -GI [ h | s | b | e | c ]</li> <li> The IDL compiler generates source code for the management and (de)marshaling -of wide characters and wide strings, enabling the sending and receiving of -Unicode over the wire. However, wide character and wide string literals are -not yet portable to Unix platforms (see entry under Future Work below).</li> +of wide characters and wide strings, enabling the sending and receiving +of Unicode over the wire. However, wide character and wide string literals +are not yet portable to Unix platforms (see entry under Future Work below).</li> <li> Since the CORBA spec requires that all enums be 32 bits, and some compilers will try to use less space if the enum values are small enough, the IDL -compiler now appends <enum name>_TAO_ENUM_32BIT_ENFORCER = 0xFFFFFFFF to -every enum. This appended enum value is not part of the IDL compiler's -internal representation of the enum, so unions that use the enum as a -discriminator will not have incorrect _default() code generated for them.</li> +compiler now appends <enum name>_TAO_ENUM_32BIT_ENFORCER = 0xFFFFFFFF +to every enum. This appended enum value is not part of the IDL compiler's +internal representation of the enum, so unions that use the enum as a discriminator +will not have incorrect _default() code generated for them.</li> <li> The IDL compiler generates a C++ ostream operator for IDL exceptions. So -far only the repository ID is output, but this may be enhanced when -requirements and/or desires become clearer.</li> +far only the repository ID is output, but this may be enhanced when requirements +and/or desires become clearer.</li> <li> The IDL compiler now has limited support for valuetypes (see release notes -for valuetypes for details). If the TAO library is built with -TAO_HAS_VALUETYPE defined, and IDL_HAS_VALUETYPE is also defined, then -the IDL compiler will enable OBV support with the command line option --Gv, and disable it with the option -Sv (the default).</li> +for valuetypes for details). If the TAO library is built with TAO_HAS_VALUETYPE +defined, and IDL_HAS_VALUETYPE is also defined, then the IDL compiler will +enable OBV support with the command line option -Gv, and disable it with +the option -Sv (the default).</li> <li> -As part of the implementation of interceptors, the TAO IDL compiler -now generates interception points in the client and server, as well -as the prepare_header method in the stubs.</li> +As part of the implementation of interceptors, the TAO IDL compiler now +generates interception points in the client and server, as well as the +prepare_header method in the stubs.</li> <li> -Scoping and name resolution rules have changed in CORBA with version -2.3. The IDL compiler now conforms to these new rules. </li> +Scoping and name resolution rules have changed in CORBA with version 2.3. +The IDL compiler now conforms to these new rules.</li> <li> IDL compiler now supports the CORBA AMI callback model, generating code -for reply handlers and reply stubs if the -GC command line option is -used. The TAO library must be compiled with TAO_HAS_CORBA_MESSAGING = 1. -If this is done, TAO_HAS_AMI_CALLBACK will automatically be defined to -1 as well. IDL_HAS_VALUETYPE is defined to 1 by default. </li> +for reply handlers and reply stubs if the -GC command line option is used. +The TAO library must be compiled with TAO_HAS_CORBA_MESSAGING = 1. If this +is done, TAO_HAS_AMI_CALLBACK will automatically be defined to 1 as well. +IDL_HAS_VALUETYPE is defined to 1 by default.</li> <li> -New command line option -So added to suppress generation of ostream -operators for exceptions. </li> +New command line option -So added to suppress generation of ostream operators +for exceptions.</li> <li> New command line option -Sc added to suppress generation of tie classes -and *S_T.* files. The default is still to generate them. </li> +and *S_T.* files. The default is still to generate them.</li> <li> IDL compiler now handles escaped identifiers (CORBA 2.3.1). An identifier -appearing in an IDL file with a leading underscore will appear in -generated code without the underscore. This enables the use of identifiers -in generated code identical to IDL keywords, as specified in CORBA 2.3.1. -If the resulting identifier matches a C++ keyword, "_cxx_" -will be prepended in generated code as before. </li> +appearing in an IDL file with a leading underscore will appear in generated +code without the underscore. This enables the use of identifiers in generated +code identical to IDL keywords, as specified in CORBA 2.3.1. If the resulting +identifier matches a C++ keyword, "_cxx_" will be prepended in generated +code as before.</li> <li> -The -St option to suppress generation of typecodes now also suppresses the -generation of the Any insertion and extraction operators. The extraction +The -St option to suppress generation of typecodes now also suppresses +the generation of the Any insertion and extraction operators. The extraction operators require the associated typecode, so the generated code for those -operators would not compile when the -St option was used. </li> +operators would not compile when the -St option was used.</li> <li> Option -Ge 2 added which generates 'throw' instead of ACE_THROW_SPEC, ACE_THROW, and ACE_RETHROW. Since the expansion of ACE_THROW_RETURN is platform-dependent, -it was left as is. Same for TAO_INTERCEPTOR_THROW, since it sometimes -expands to ACE_THROW_RETURN. Of course ACE_HAS_EXCEPTIONS must be defined for -this option to work.</li> +it was left as is. Same for TAO_INTERCEPTOR_THROW, since it sometimes expands +to ACE_THROW_RETURN. Of course ACE_HAS_EXCEPTIONS must be defined for this +option to work.</li> <li> -Removed generation of ostream operators for user exceptions, along with the -command line option to suppress this generation. The ostream operator -defined in the base class CORBA::Exception works fine and produces the same -output.</li> +Removed generation of ostream operators for user exceptions, along with +the command line option to suppress this generation. The ostream operator +defined in the base class CORBA::Exception works fine and produces the +same output.</li> <li> The TAO IDL compiler is no longer monolithic. It is composed of a top-level executable, a front end library and a back end library. This will enable -different back ends to be plugged in for code generation in different -languages, and for IfR administration. Different back ends may require -a few changes to the executable (described below), but the front end -library can remain unchanged. The chain of dependencies is as follows: -<blockquote> -FE : ACE<br> -BE : FE<br> -EXE : FE, BE<br> -</blockquote> +different back ends to be plugged in for code generation in different languages, +and for IfR administration. Different back ends may require a few changes +to the executable (described below), but the front end library can remain +unchanged. The chain of dependencies is as follows:</li> + +<blockquote>FE : ACE +<br>BE : FE +<br>EXE : FE, BE</blockquote> Executing the Makefile (or the TAO_IDL Compiler project in the MSVC 'tao_idl' workspace) will build whatever is required in the proper order, as before. -Back end files, classes and functions required by the executable are as follows: -<blockquote> -be.h - file containing #includes of the major BE file headers.<br> -TAO_Codegen - class, holds output stream references for the various generated files.<br> -TAO_CODEGEN - ACE_Singleton typedef of the above class.<br> -tao_cg - pointer to instance of TAO_CODEGEN.<br> -be_generator - class, inherits from AST_Generator in FE and generates AST nodes.<br> -void BE_produce (void) - global function, starts AST traversal for code generation.<br> -BE_GlobalData - class, holds default/command line arg settings specific to BE.<br> -be_global - pointer to instance of above class.<br> -</blockquote> -All the code in the executable that may need to be modified for different back -ends in contained in the file drv_args.cpp. Code in this file processes the -command line arguments, outputs a usage message, and performs other miscellaneous -BE initialization.</li> - +Back end files, classes and functions required by the executable are as +follows: +<blockquote>be.h - file containing #includes of the major BE file headers. +<br>TAO_Codegen - class, holds output stream references for the various +generated files. +<br>TAO_CODEGEN - ACE_Singleton typedef of the above class. +<br>tao_cg - pointer to instance of TAO_CODEGEN. +<br>be_generator - class, inherits from AST_Generator in FE and generates +AST nodes. +<br>void BE_produce (void) - global function, starts AST traversal for +code generation. +<br>BE_GlobalData - class, holds default/command line arg settings specific +to BE. +<br>be_global - pointer to instance of above class.</blockquote> +All the code in the executable that may need to be modified for different +back ends in contained in the file drv_args.cpp. Code in this file processes +the command line arguments, outputs a usage message, and performs other +miscellaneous BE initialization. <li> The IDL compiler can how handle interfaces forward declared in one IDL -file and defined in another. It will handle interfaces that are -mutually dependent across two IDL files, as long as code generated from both IDL -files is included in the same C++ build. </li> +file and defined in another. It will handle interfaces that are mutually +dependent across two IDL files, as long as code generated from both IDL +files is included in the same C++ build.</li> <li> -Generation of template tie class declarations has been moved from the *S.h file to the -*S_T.h file. The new SunCC 5.2 compiler does not require that template source code -be included in the header file, but it does require that template declarations and -implementations be in the same 'compilation unit' that is, the same header/source -file combination. Generated ifdef guards prevent the compilation of tie class -code if the target platform does not support namespaces. For such platforms, TAO -maps the IDL 'module' keyword to a class instead of to 'namespace', and C++ does -not allow template class declarations to occur inside another class. </li> +Generation of template tie class declarations has been moved from the *S.h +file to the *S_T.h file. The new SunCC 5.2 compiler does not require that +template source code be included in the header file, but it does require +that template declarations and implementations be in the same 'compilation +unit' that is, the same header/source file combination. Generated ifdef +guards prevent the compilation of tie class code if the target platform +does not support namespaces. For such platforms, TAO maps the IDL 'module' +keyword to a class instead of to 'namespace', and C++ does not allow template +class declarations to occur inside another class.</li> <li> IDL compiler can now process multiple IDL files per execution, on all platforms. -A separate process is spawned for each file. IDL files and command line options -may appear in any order on the command line. Any option not starting with '-' will -be treated as a filename.</li> +A separate process is spawned for each file. IDL files and command line +options may appear in any order on the command line. Any option not starting +with '-' will be treated as a filename.</li> <li> -Support for value types has been expanded to include forward declared value types, -sequences of value types, and factory methods. Also, work to support Anys and type -codes for value types is in progress.</li> +Support for value types has been expanded to include forward declared value +types, sequences of value types, and factory methods. Also, work to support +Anys and type codes for value types is in progress.</li> <li> Support for #pragma prefix has been revamped and improved to be compliant -(the prefix is now cleared when leaving the scope or the included IDL file where it -was defined), and support for #pragma version and #pragma ID has been added.</li> +(the prefix is now cleared when leaving the scope or the included IDL file +where it was defined), and support for #pragma version and #pragma ID has +been added.</li> <li> -Support for forward declared structs and unions has been added. In compliance with -CORBA 2.6, such forward declarations must be fully defined in the same compilation -unit, and may be used only in sequence declarations, which in turn may be used in -the declaration of recursive structs and unions. Use of a forward declared struct -or union as an aggregate type member or as an operation parameter will generat -an error message.</li> +Support for forward declared structs and unions has been added. In compliance +with CORBA 2.6, such forward declarations must be fully defined in the +same compilation unit, and may be used only in sequence declarations, which +in turn may be used in the declaration of recursive structs and unions. +Use of a forward declared struct or union as an aggregate type member or +as an operation parameter will generat an error message.</li> <li> Support for enum constants has been added.</li> <li> -The IDL compiler can now handle concatenation of string literals, for example<br> -<blockquote> -const string foo = "hel" "lo " "the" "re";<br> -</blockquote> -</li> +The IDL compiler can now handle concatenation of string literals, for example</li> + +<blockquote>const string foo = "hel" "lo " "the" "re";</blockquote> <li> Support for abstract interfaces has been added.</li> <li> -Support for valuetypes has been expanded.<br> -<ul> -<li>Forward declared valuetypes not defined in the same compilation unit</li> -<li>Type codes for valuetypes</li> -<li>Generation of Any insertion/extraction operators</li> -<li>Abstract valuetypes</li> -<li>Valuetype members of all IDL aggregate types</li> -<li>Interface supports list</li> -</ul> -</li> - -<li>Support for the CCM extensions to IDL, which first appeared in CORBA 3.0 is -complete, with the exception of support for the 'import' keyword. -</li> - -</ul> +Support for valuetypes has been expanded.</li> -<p><h4>Known Issues:</h4> <ul> +<li> +Forward declared valuetypes not defined in the same compilation unit</li> <li> -With Microsoft Visual C++, verison 6.0 and earlier, a problem has been discovered -when the IDL compiler is built using the Release version of the MSVC project. For -the Release version, the Optimizations box in the C/C++ tab has 'Maximize Speed' -selected. This setting turned out to cause a problem when<br><br> +Type codes for valuetypes</li> -const char *foo = ......<br><br> +<li> +Generation of Any insertion/extraction operators</li> -occurs in the source code. The variable foo is sometimes not allocated or assigned -properly, and if foo is part of generated code, it will then display as garbage or -as an empty string (or substring). Two workarounds have been found. One is to -change the declaration of foo to be<br><br> +<li> +Abstract valuetypes</li> -static const char *foo = ....<br><br> +<li> +Valuetype members of all IDL aggregate types</li> -and this has been done in all cases we could find in the IDL compiler source code. -Another way to avoid the problem is to change the Release project Optimization -setting to 'Minimize Size'. Reportedly the problem has been fixed in MSVC version -7.0. -</li> +<li> +Interface supports list</li> </ul> -<p><h4>Future work:</h4> +<li> +Support for the CCM extensions to IDL, which first appeared in CORBA 3.0 +is complete, with the exception of support for the 'import' keyword.</li> +</ul> + +<h4> +Known Issues:</h4> + <ul> +<li> +With Microsoft Visual C++, verison 6.0 and earlier, a problem has been +discovered when the IDL compiler is built using the Release version of +the MSVC project. For the Release version, the Optimizations box in the +C/C++ tab has 'Maximize Speed' selected. This setting turned out to cause +a problem when</li> + +<br> +<p> +<p>const char *foo = ...... +<p>occurs in the source code. The variable foo is sometimes not allocated +or assigned properly, and if foo is part of generated code, it will then +display as garbage or as an empty string (or substring). Two workarounds +have been found. One is to change the declaration of foo to be +<p>static const char *foo = .... +<p>and this has been done in all cases we could find in the IDL compiler +source code. Another way to avoid the problem is to change the Release +project Optimization setting to 'Minimize Size'. Reportedly the problem +has been fixed in MSVC version 7.0.</ul> +<h4> +Future work:</h4> + +<ul> <li> -Implement the complete <A HREF="../ReleaseNotes/OBV.html">Object-by-Value</A> +Implement the complete <a href="../ReleaseNotes/OBV.html">Object-by-Value</a> specification. Originally implemented solely for use in holding exceptions -raised in <A HREF="../../../PDFs/ami1.pdf">asynchronous</A> invocations, +raised in <a href="../../../PDFs/ami1.pdf">asynchronous</a> invocations, work is now ongoing to extend TAO's OBV implementation until it includes the complete CORBA value type specification. Some of the items yet to be -implemented include:<p> +implemented include:</li> +<br> +<p> +<br> +<br> <ul> <li> -Boxed value types<p> +Boxed value types</li> + +<br> +<p> +<br> +<br> <li> -Custom marshaling<p> +Custom marshaling</li> + +<br> +<p> +<br> +<br> <li> -Truncation<p> +Truncation</li> + +<br> +<p> +<br> +<br> <li> -Marshaling of complex state (graphs with cycles)<p> -</ul> +Marshaling of complex state (graphs with cycles)</li> +<br> +<p> +<br> +<br> </ul> For a complete description of value type semantics, see chapter 5 in the -CORBA specification.<p> - - +CORBA specification. +<br> +<br> <li> The generated sequence classes should not be generated per sequence, but per type and parent scope. Which means, that the overhead of having the source code generated serveral times should be reduced. To do this, an -extra pass over the internal representation of the IDL file has to be done.<p> - -<li> -Updated and portable support for wide characters and wide strings. The original -implementation supports Unicode only. At the time, the CORBA specification required -wide characters, whether standalone or in a wide string, to be marshaled -as 16-bit quantities. This is the same size as the native wchar_t type on -Win32 platforms. However, the wchar_t type on UNIX and related platforms -is 32 bits in size. In addition, the General Inter-ORB Protocol (GIOP) version 1.2 -has changed the CDR transfer syntax for wide characters. In the new version, -a wide character is marshaled as a single byte indicating the size of the -wide character representation, followed by the specified nunber of bytes. The -IDL compiler's handling of wide characters needs to be updated, both to -handle the GIOP 1.2 CDR transfer syntax, and to be portable under previous -versions of GIOP. For more information about GIOP CDR transfer syntax, see -section 15.3 in the CORBA specification. and for information about the -marshaling of IDL character types specifically, see section 15.3.1.6.<p> - -</ul> - - - -<br><!--#include virtual="orbcore.html" --> +extra pass over the internal representation of the IDL file has to be done.</li> + +<br> +<p> +<br> +<br> +<li> +Updated and portable support for wide characters and wide strings. The +original implementation supports Unicode only. At the time, the CORBA specification +required wide characters, whether standalone or in a wide string, to be +marshaled as 16-bit quantities. This is the same size as the native wchar_t +type on Win32 platforms. However, the wchar_t type on UNIX and related +platforms is 32 bits in size. In addition, the General Inter-ORB Protocol +(GIOP) version 1.2 has changed the CDR transfer syntax for wide characters. +In the new version, a wide character is marshaled as a single byte indicating +the size of the wide character representation, followed by the specified +nunber of bytes. The IDL compiler's handling of wide characters needs to +be updated, both to handle the GIOP 1.2 CDR transfer syntax, and to be +portable under previous versions of GIOP. For more information about GIOP +CDR transfer syntax, see section 15.3 in the CORBA specification. and for +information about the marshaling of IDL character types specifically, see +section 15.3.1.6.</li> + +<br> +<p> +<br> +<br> </ul> + +<p><br><!--#include virtual="orbcore.html" --> <hr> - <h3> <a NAME="pp"></a>Pluggable Protocols</h3> Point of contact: <a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</a> <p>The goal of the pluggable protocol effort is to (1) identify logical communication layers in the ORB, (2) abstract out common features, (3) -define general interfaces, and (4) provide necessary mechanisms for -implementing different concrete ORB and transport protocols. TAO's pluggable -protocol framework will allow disparate communication mechanisms to be -supported transparently, each with its own set of requirements and strategies. +define general interfaces, and (4) provide necessary mechanisms for implementing +different concrete ORB and transport protocols. TAO's pluggable protocol +framework will allow disparate communication mechanisms to be supported +transparently, each with its own set of requirements and strategies. <p>For example, if the ORB is communicating over a system bus, such as PCI or VME, and not all the features of GIOP/IIOP are necessary and a simpler, optimized ORB and transport protocol can be defined and implemented. Similarly, @@ -659,23 +689,24 @@ it should be straightforward to add support for new transport protocols that use native ATM or shared memory as the underlying communication mechanism. In all cases the ORB's interface to the application will remain compliant with the OMG CORBA standard. -<p>There will be several stages of the development process: (1) basic -pluggable transport protocols framework, (2) support for multiple profiles, -(4) add example transport protocols, such as ATM and VME, and refine/optimize -the transport protocols framework, and (4) add support for pluggable ORB -protocols, e.g., replacements for GIOP. Each of these steps is outlined -below: -<ul> -<li> -<b>Basic pluggable transport protocols framework</b>: We have added -several Bridge classes that decouple the transport-specific details from -the rest of TAO's ORB Core. This allows us to isolate the details of how -messages are communicated at the transport layer in a few classes. This -design resulted in the restructuring of the ORB Core and how requests are -handled. For instance, there is now the concept of communication layers: -Objects (e.g., references, method invocations, etc.), ORB Messaging, Transport, -and Network. The Object layer is just the usual stubs and skeletons.</li> - +<p>There will be several stages of the development process: (1) basic pluggable +transport protocols framework, (2) support for multiple profiles, (4) add +example transport protocols, such as ATM and VME, and refine/optimize the +transport protocols framework, and (4) add support for pluggable ORB protocols, +e.g., replacements for GIOP. Each of these steps is outlined below: +<ul> +<li> +<b>Basic pluggable transport protocols framework</b>: We have added several +Bridge classes that decouple the transport-specific details from the rest +of TAO's ORB Core. This allows us to isolate the details of how messages +are communicated at the transport layer in a few classes. This design resulted +in the restructuring of the ORB Core and how requests are handled. For +instance, there is now the concept of communication layers: Objects (e.g., +references, method invocations, etc.), ORB Messaging, Transport, and Network. +The Object layer is just the usual stubs and skeletons.</li> + +<br> +<p> <p>The common interfaces have been defined in the new abstract classes that form the core of TAO's pluggable protocol framework, e.g., <tt>TAO_Connector</tt>, @@ -686,33 +717,41 @@ transport protocols are the <tt>TAO_Connector_Registry</tt> and <tt>TAO_Acceptor_Registry</tt>, which are essentially Abstract Factories that produce the right types of -connector, acceptors, and transports. <p> +connector, acceptors, and transports. <li> <b>Multiple Profile</b> - Support for more than one profile per object. This is important since there may be several different ways to access an object. Each profile for an object may encode information pertaining to -QoS, network and transport protocols, addresses or routes.<p> +QoS, network and transport protocols, addresses or routes.</li> +<br> +<p> +<br> +<br> <li> -<b>Example Transport protocols</b> - Aside from IIOP, five additional -transport protocols are distributed with TAO: +<b>Example Transport protocols</b> - Aside from IIOP, five additional transport +protocols are distributed with TAO:</li> + <ol> -<P><li>UIOP: GIOP over local IPC (UNIX domain sockets)</li> -<P><li>SHMIOP: GIOP over shared memory</li> -<P><li>SSLIOP: IIOP over SSL (Secure Socket Layer)</li> -<P><li>DIOP: GIOP over UDP/IP</li> -<P><li>MIOP: GIOP over unreliable multicast</li> -</ol> +<li> +UIOP: GIOP over local IPC (UNIX domain sockets)</li> -<P> -Other interesting transport protocols could be for ATM, Buses (VME or -PCI), TP4, and GSMP. TAO users have also created their own -pluggable transport protocols, such as a ScramNet pluggable protocol. +<li> +SHMIOP: GIOP over shared memory</li> -</li> +<li> +SSLIOP: IIOP over SSL (Secure Socket Layer)</li> +<li> +DIOP: GIOP over UDP/IP</li> -<P><li> +<li> +MIOP: GIOP over unreliable multicast</li> +</ol> +Other interesting transport protocols could be for ATM, Buses (VME or PCI), +TP4, and GSMP. TAO users have also created their own pluggable transport +protocols, such as a ScramNet pluggable protocol. +<li> <b>Pluggable ORB protocols</b> - This step will add support for ORB protocols besides GIOP. In particular, we will explore lightweight protocols using shared memory and system buses like PCI or VME.</li> @@ -720,552 +759,484 @@ shared memory and system buses like PCI or VME.</li> Current Status: <ul> <li> +The basic framework to support pluggable transport protocols has been completed. +The standard TAO regression tests <tt>Latency</tt>, +<tt>MT_Cubit</tt>, +<tt>Multiple_Inheritance</tt>, +<tt>CDR</tt> and +<tt>EC_Throughput</tt> can be used to verify performance +using the new framework.</li> + +<li> +Multiple endpoint support in the ORB has been added. A list of TAO_Acceptors +is kept in the Acceptor Registry. When the ORB needs to create an IOR it +iterates over all the acceptors to do so. Using either multiple <tt><a href="../ORBEndpoint.html">-ORBEndpoint</a></tt> +options or several endpoints separated by semi-colons ';', the user can +specify what addresses the ORB should use. Each endpoint is specified in +URL format (ex: <tt>iiop://foo.bar.com:0</tt>), this format can be extended +to support different protocols.</li> + +<li> +If the user does not specify a list of endpoints then the ORB creates a +default endpoint for each protocol configured, unless the pluggable protocol +explicitly prevents that in an effort to prevent resource leaks.</li> + +<li> +Added support for multiple Connectors in the ORB, the ORB finds the correct +connector based on the tag for the profile.</li> + +<li> +Added support for multiple profiles in the IORs, when the ORB demarshals +an IOR it queries the Connector Registry to create the right kind of profile +for the known protocols. If one of the protocols is unknown we create a +special profile class that can only be used for marshaling and demarshaling, +not communication.</li> + +<li> +Enabled the UIOP protocol. This protocol uses local IPC (aka UNIX domain +sockets) as the transport mechanism. The protocol is loaded by default.</li> + +<li> +Enabled the SHMIOP protocol. This protocol uses shared memory as the transport +mechanism. The protocol is loaded by default.</li> + +<li> +An IIOP over SSL pluggable protocol called "SSLIOP" has been implemented. +It provides secure communication between hosts that support IIOP over SSL, +and is meant to be a drop-in replacement for the IIOP pluggable protocol. +TAO's SSLIOP pluggable protocol implementation supports both the standard +IIOP transport protocol and the secure IIOP over SSL transport protocol.</li> + +<br> +<p> +<p>No changes were made to the core TAO sources to provide to this SSL +support, nor does TAO contain any security related hooks. TAO's SSLIOP +implementation is completely self-contained. This ensures that the core +TAO sources remains free of export restrictions. +<li> +Protocols can be dynamically loaded into the ORB: The default resource +factory reads the protocol "names" from its list of arguments. These protocol +names are used to load an abstract factory via the service configurator. +This factory can create acceptors or connectors on demand. By default only +IIOP is loaded.</li> + +<li> +The service configurator is now used to load protocol factories.</li> + +<li> +Support for the <tt>-ORBHost</tt> and <tt>-ORBPort</tt> has been removed. +The new <tt><a href="../ORBEndpoint.html">-ORBEndpoint</a></tt> option +supersedes them, and provides the same functionality in a protocol-neutral +way. If the deprecated options are used, the ORB exits with a <tt>CORBA::BAD_PARAM</tt> +exception, indicating an unknown <tt>-ORB</tt> option.</li> + +<li> +The <tt>-ORBPreconnect</tt> ORB option has been deprecated in favor of +the standard <tt>validate_connection</tt> run-time feature. Support for +this option will be removed from future releases.</li> + +<li> +The URL style object reference format has been updated to conform with +the format that <tt>corbaloc</tt> uses. The BNF specification for <tt>corbaloc</tt> +is:</li> + +<blockquote><tt><corbaloc> = "corbaloc:/"[<obj_addr_list>]["/"<key_string>]</tt> +<br><tt><obj_addr_list>= [<obj_addr> ","]* <obj_addr></tt> +<br><tt><obj_addr>= <prot_addr> | <future_prot_addr></tt> +<br><tt><prot_addr>= <rir_prot_addr> | <iiop_prot_addr></tt> +<br><tt><rir_prot_addr>= <rir_prot_token>":"</tt> +<br><tt><iiop_prot_addr>= <iiop_id><iiop_addr></tt> +<br><tt><iiop_id>= ":" | <iiop_prot_token>":"</tt> +<br><tt><iiop_prot_token> = "iiop"</tt> +<br><tt><iiop_add> = [<version> <host> [":" <port>]]</tt> +<br><tt><host> = DNS-style Host Name | ip_address</tt> +<br><tt><version> = <major> "." <minor> "@" | empty_string</tt> +<br><tt><port> = number</tt> +<br><tt><major> = number</tt> +<br><tt><minor> = number</tt> +<br><tt><future_prot_addr> = <future_prot_id><future_prot_addr> +<future_prot_id> = <future_prot_token>":" <future_prot_token> += possible examples: "atm" | "dce" <future_prot_addr> = protocol specific +address <key_string> = <string> | empty_string</tt></blockquote> +The <tt>uiop</tt> URL style object references syntax is: +<blockquote><tt><uioploc> = "uioploc://"[<addr_list>]["|"<key_string>]</tt> +<br><tt><addr_list>= [<address> ","]* <address></tt> +<br><tt><address> = [<version> <rendezvous point>]</tt> +<br><tt><rendezvous point> = Valid Filesystem Path</tt> +<br><tt><version> = <major> "." <minor> "@" | empty_string</tt> +<br><tt><major> = number</tt> +<br><tt><minor> = number</tt> +<br><tt><key_string> = <string> | empty_string</tt></blockquote> +Note that the key string delimiter for <b><tt>uiop</tt></b> is a vertical +bar `<b><tt>|</tt></b>' (the command line "pipe" symbol) not a forward +slash `<tt>/</tt>'. A delimiter other than a forward slash is needed to +prevent ambiguities of where the rendezvous point ends and where the key +string begins since both may contain forward slashes in them. The new <tt>corbaloc:uiop</tt> +URL format may also be used. +<p>It should be noted that these formats have been superseded by the new +<tt>corbaloc</tt> +<a href="../INS.html">Interoperable Naming Service</a> support. +<li> +The <i>rendezvous point</i> for <tt>uiop</tt> is any valid path and filename +that the ORB has permission to read and write to. However, UIOP rendezvous +points have the same restrictions that local IPC has. The following are +some guidelines that will help ensure successful use TAO's UIOP pluggable +transport protocol:</li> -The basic framework to support pluggable transport protocols has been -completed. The standard TAO regression tests <tt>Latency</tt>, -<tt>MT_Cubit</tt>, <tt>Multiple_Inheritance</tt>, <tt>CDR</tt> and -<tt>EC_Throughput</tt> can be used to verify performance using the new -framework.</li> - -<P><li> - Multiple endpoint support in the ORB has been added. A - list of TAO_Acceptors is kept in the Acceptor - Registry. When the ORB needs to create an IOR it iterates - over all the acceptors to do so. Using either multiple - <a href="../ORBEndpoint.html"><code>-ORBEndpoint</code></a> - options or several endpoints separated by semi-colons ';', - the user can specify what addresses the ORB should use. - Each endpoint is specified in URL format (ex: - <code>iiop://foo.bar.com:0</code>), this format can be - extended to support different protocols. -</li> - -<P><li> - If the user does not specify a list of endpoints then the - ORB creates a default endpoint for each protocol - configured, unless the pluggable protocol explicitly - prevents that in an effort to prevent resource leaks. -</li> - -<P><li> - Added support for multiple Connectors in the ORB, the ORB - finds the correct connector based on the tag for the - profile. -</li> - -<P><li> - Added support for multiple profiles in the IORs, when the - ORB demarshals an IOR it queries the Connector Registry to - create the right kind of profile for the known protocols. - If one of the protocols is unknown we create a special - profile class that can only be used for marshaling and - demarshaling, not communication. -</li> - -<P><li> - Enabled the UIOP protocol. This protocol uses local IPC - (aka UNIX domain sockets) as the transport mechanism. The - protocol is loaded by default. - -</li> - -<P><li> - Enabled the SHMIOP protocol. This protocol uses shared - memory as the transport mechanism. The protocol is loaded - by default. -</li> - -<P><li> - An IIOP over SSL pluggable protocol called "SSLIOP" has - been implemented. It provides secure communication - between hosts that support IIOP over SSL, and is meant to - be a drop-in replacement for the IIOP pluggable protocol. - TAO's SSLIOP pluggable protocol implementation supports - both the standard IIOP transport protocol and the secure - IIOP over SSL transport protocol. - - <P> - No changes were made to the core TAO sources to provide - to this SSL support, nor does TAO contain any security - related hooks. TAO's SSLIOP implementation is - completely self-contained. This ensures that the core - TAO sources remains free of export restrictions. -</li> - -<P><li> - Protocols can be dynamically loaded into the ORB: The - default resource factory reads the protocol "names" from - its list of arguments. These protocol names are used to - load an abstract factory via the service configurator. - This factory can create acceptors or connectors on demand. - By default only IIOP is loaded. -</li> - -<P><li> - -The service configurator is now used to load protocol factories. - -</li> - -<P><li> - Support for the <code>-ORBHost</code> and - <code>-ORBPort</code> has been removed. The new - <a href="../ORBEndpoint.html"><code>-ORBEndpoint</code></a> - option supersedes them, and provides the same - functionality in a protocol-neutral way. If the - deprecated options are used, the ORB exits with a - <code>CORBA::BAD_PARAM</code> exception, indicating an - unknown <code>-ORB</code> option. -</li> - -<P><li> - The <code>-ORBPreconnect</code> ORB option has been - deprecated in favor of the standard - <code>validate_connection</code> run-time feature. - Support for this option will be removed from future - releases. -</li> - -<P><li> - The URL style object reference format has been updated to - conform with the format that <code>corbaloc</code> - uses. The BNF specification for <code>corbaloc</code> is: - -<blockquote><code> - -<corbaloc> = "corbaloc:/"[<obj_addr_list>]["/"<key_string>]<br> -<obj_addr_list>= [<obj_addr> ","]* <obj_addr><br> -<obj_addr>= <prot_addr> | <future_prot_addr><br> -<prot_addr>= <rir_prot_addr> | <iiop_prot_addr><br> -<rir_prot_addr>= <rir_prot_token>":"<br> -<iiop_prot_addr>= <iiop_id><iiop_addr><br> -<iiop_id>= ":" | <iiop_prot_token>":"<br> -<iiop_prot_token> = "iiop"<br> -<iiop_add> = [<version> <host> [":" <port>]]<br> -<host> = DNS-style Host Name | ip_address<br> -<version> = <major> "." <minor> "@" | empty_string<br> -<port> = number<br> -<major> = number<br> -<minor> = number<br> -<future_prot_addr> = <future_prot_id><future_prot_addr> -<future_prot_id> = <future_prot_token>":" -<future_prot_token> = possible examples: "atm" | "dce" -<future_prot_addr> = protocol specific address -<key_string> = <string> | empty_string<br> -</code></blockquote> - - The <code>uiop</code> URL style object references syntax - is: - -<blockquote><code> -<uioploc> = "uioploc://"[<addr_list>]["|"<key_string>]<br> -<addr_list>= [<address> ","]* <address><br> -<address> = [<version> <rendezvous point>]<br> -<rendezvous point> = Valid Filesystem Path<br> -<version> = <major> "." <minor> "@" | - empty_string<br> -<major> = number<br> -<minor> = number<br> -<key_string> = <string> | empty_string<br> -</code></blockquote> - - Note that the key string delimiter for <b><code>uiop</code></b> - is a vertical bar `<b><code>|</code></b>' (the command line - "pipe" symbol) not a forward slash - `<code>/</code>'. A delimiter other than a - forward slash is needed to prevent ambiguities of - where the rendezvous point ends and where the key - string begins since both may contain forward - slashes in them. The new <code>corbaloc:uiop</code> URL - format may also be used. - <p> - It should be noted that these formats have been superseded - by the new <code>corbaloc</code> - <a href="../INS.html">Interoperable Naming Service</a> - support. -</li> - -<P><li> - The <i>rendezvous point</i> for <code>uiop</code> is - any valid path and filename that the ORB has permission to - read and write to. However, UIOP rendezvous points have - the same restrictions that local IPC has. The following - are some guidelines that will help ensure successful use - TAO's UIOP pluggable transport protocol: - <blockquote><li> - To guarantee portability, local IPC rendezvous - points (including the path and filename) should not - be longer than 99 characters long. Some platforms - may support longer rendezvous points, usually 108 - characters including the null terminator, but - Posix.1g only requires that local IPC rendezvous - point arrays contain a maximum of <b>at least</b> - 100 characters, including the null terminator.<P> - - If an endpoint is longer than what the platform - supports then it will be truncated so that it fits, - and a warning will be issued. - </li> - <P><li> - Avoid using <em>relative</em> paths in your UIOP endpoints. - If possible, use <b><em>absolute</em></b> paths - instead. Imagine that the server is given an - endpoint to create using <code>-ORBEndpoint - uiop://foobar</code>. A local IPC rendezvous - point called <code>foobar</code> will be created - in the current working directory. If the client - is not started in the directory where the - <code>foobar</code> rendezvous point exists then - the client will not be able to communicate with - the server since its point of communication, the - rendezvous point, was not found. On the other - hand, if an absolute path was used, the client - would know exactly where to find the rendezvous - point. - <P> - It is up to the user to make sure that a given UIOP - endpoint is accessible by both the server and - the client. - </li> - <P><li> - It is important to be consistent in the use of - absolute paths and relative paths for rendezvous - points. The two types of paths should not be used - for the same endpoint. For example, if - <code>uiop:///tmp/foo</code> is specified as the - server endpoint and <code>uiop://foo</code> as a - preconnect for a client in <code>/tmp</code>, then - the preconnection may be established but it is - likely it won't be used since the endpoint and - preconnect are interpreted as different strings, - i.e. <code>/tmp/foo</code> and <code>foo</code> are - not the same, lexicographically. On the other - hand, if both the endpoint and the preconnect are - the same string then a preconnection will be - established and used successfully.<P> - </li></blockquote> - - The <a href="../ORBEndpoint.html"><code>-ORBEndpoint</code></a> - option uses a syntax similar to that of the URL style - object reference shown above. The only difference is that - the object key delimiter and the object key string are not - specified. -</li> - -<P><li> - Added documentation that describes how to implement - pluggable transport protocols for TAO. The document is - available - <A HREF="../pluggable_protocols/index.html">here</A>. -</li> - -<P><li> - TAO's IIOP pluggable protocol now supports automatic - creation of profiles for endpoints created on a host with - multiple network interfaces. It should no longer be - necessary to manually specify an endpoint for each network - interface. - <P> - This means that server IORs will contain profiles for - all of the default endpoints created on each network - interface the server is listening on, if no explicit - endpoints were specified. -</li> - -</ul> - -<P> +<blockquote> +<li> +To guarantee portability, local IPC rendezvous points (including the path +and filename) should not be longer than 99 characters long. Some platforms +may support longer rendezvous points, usually 108 characters including +the null terminator, but Posix.1g only requires that local IPC rendezvous +point arrays contain a maximum of <b>at least</b> 100 characters, including +the null terminator.</li> + +<br> +<p> +<p> If an endpoint is longer than what the platform supports then +it will be truncated so that it fits, and a warning will be issued. +<li> +Avoid using <i>relative</i> paths in your UIOP endpoints. If possible, +use <b><i>absolute</i></b> paths instead. Imagine that the server is given +an endpoint to create using <tt>-ORBEndpoint uiop://foobar</tt>. A local +IPC rendezvous point called <tt>foobar</tt> will be created in the current +working directory. If the client is not started in the directory where +the <tt>foobar</tt> rendezvous point exists then the client will not be +able to communicate with the server since its point of communication, the +rendezvous point, was not found. On the other hand, if an absolute path +was used, the client would know exactly where to find the rendezvous point.</li> + +<br> +<p> +<p>It is up to the user to make sure that a given UIOP endpoint is accessible +by both the server and the client. +<li> +It is important to be consistent in the use of absolute paths and relative +paths for rendezvous points. The two types of paths should not be used +for the same endpoint. For example, if <tt>uiop:///tmp/foo</tt> is specified +as the server endpoint and <tt>uiop://foo</tt> as a preconnect for a client +in <tt>/tmp</tt>, then the preconnection may be established but it is likely +it won't be used since the endpoint and preconnect are interpreted as different +strings, i.e. <tt>/tmp/foo</tt> and <tt>foo</tt> are not the same, lexicographically. +On the other hand, if both the endpoint and the preconnect are the same +string then a preconnection will be established and used successfully.</li> + +<br> +<p> +<br> +<br> </blockquote> +The <tt><a href="../ORBEndpoint.html">-ORBEndpoint</a></tt> option uses +a syntax similar to that of the URL style object reference shown above. +The only difference is that the object key delimiter and the object key +string are not specified. +<li> +Added documentation that describes how to implement pluggable transport +protocols for TAO. The document is available <a href="../pluggable_protocols/index.html">here</a>.</li> + +<li> +TAO's IIOP pluggable protocol now supports automatic creation of profiles +for endpoints created on a host with multiple network interfaces. It should +no longer be necessary to manually specify an endpoint for each network +interface.</li> + +<br> +<p> +<p>This means that server IORs will contain profiles for all of the default +endpoints created on each network interface the server is listening on, +if no explicit endpoints were specified.</ul> Known Issues: - <ul> <li> +</li> </ul> Critical Work: - <ul> <li> -None. -</li> +None.</li> -<p><p> -</ul> +<br> +<p> +<br> +<br> </ul> Future Work: <ul> <li> -Complete support for multiple ORB messaging protocols. +Complete support for multiple ORB messaging protocols.</li> <li> Long term work will include adding support for pluggable ORB protocols, as well as transport protocols. This way we can develop optimal messaging and transport protocols for a given platform.</li> - </ul> -<p> <hr> - - <h3> <a NAME="poa"></a>Portable Object Adapter (POA)</h3> Point of contact: <a href="mailto:irfan@cs.wustl.edu">Irfan Pyarali</a> -<P> -The POA associates servants with the ORB and demultiplexes incoming -requests to servants. <P> - +<p>The POA associates servants with the ORB and demultiplexes incoming +requests to servants. <p>Current Status: <ul> <li> TAO supports the POA spec. This section will carry updates as available.</li> </ul> Known issues: - -<ul> - -</UL> - -Future work: +<br>Future work: +<br>Recently completed work: +<br> +<br> <ul> +<li> +ORB::shutdown now properly deactives all the POA Managers.</li> -</ul> +<li> +POA Managers in TAO were previously ignored in the request processing path +on the server. This is now fixed such that their state is checked before +dispatching the client request to the servant. Only if the state is <tt>ACTIVE</tt>, +is the request dispatched to the servant. Otherwise, the request is rejected. +Since POA Managers start off in <tt>HOLDING</tt> state, make sure to +<tt>activate()</tt> +them before falling into the event loop.</li> -Recently completed work:<P> +<li> +TAO's POA now properly supports both the threading policies: SINGLE_THREAD_MODEL +and ORB_CTRL_MODEL.</li> -<ul> +<li> +The synchronization in the POA is now very optimal. For example, the locks +are not held across the invocation on the servant. The locks are also not +held across the invocation on the AdapterActivator and ServantManagers. +This allows us to use regular locks instead of recursive locks inside the +POA. This also allows multiple threads to dispatch requests on the same +POA simultaneous.</li> -<li> ORB::shutdown now properly deactives all the POA -Managers. </li><P> +<li> +TAO now supports reference counting between POA and servants, including +the new RefCountServantBase and ServantBase_var classes. RefCountServantBase +is a reference counted base class that was added to the CORBA specification +to avoid race conditions for servant deletion in threaded servers. <a href="ftp://ftp.omg.org/pub/docs/orbos/98-07-12.pdf">ftp://ftp.omg.org/pub/docs/orbos/98-07-12.pdf</a> +contains the relevant text. Check <a href="../poa_migration.html#Reference counting Servants">here</a> +on some hints to avoid trouble.</li> <li> +The POA now supports active demultiplexing of servants in the SYSTEM_ID +and the USER_ID policy. This should make the POA faster and more predictable +since there is no hashing involved and the index of the slot where the +servant is registered is in the Object Key.</li> -POA Managers in TAO were previously ignored in the request processing -path on the server. This is now fixed such that their state is checked -before dispatching the client request to the servant. Only if the -state is <CODE>ACTIVE</CODE>, is the request dispatched to the -servant. Otherwise, the request is rejected. Since POA Managers start -off in <CODE>HOLDING</CODE> state, make sure to -<CODE>activate()</CODE> them before falling into the event loop. +<li> +Previously, the complete POA name was used as the POA identity. This scheme +was inefficient in many ways including: (a) the complete POA name can be +significantly large in size, and therefore, ineffient to pass with every +method call from the client to the server; (b) it is varible in size, and +therefore, does not lend itself to smart and effective parsing; (c) the +searching based on the complete POA name is very ineffient.</li> -</li><P> +<br> +<p> +<p>The new solution is to use an active demux table, and flatten the POA +hierarchy. This will help in the searching since active demuxing is fast +and predictable. This will also help in the parsing since the demux key +will be fixed size. +<p>Note that for persistent ids, we have to pass the complete POA name +in addition to the demux key in order to handle POA creation on demand. +<br> +<br> +<li> +There were some POA objects in a typical server that are not freed up properly, +resulting in a memory leak. This has now been fixed.</li> -<li> TAO's POA now properly supports both the threading policies: -SINGLE_THREAD_MODEL and ORB_CTRL_MODEL. </li><P> +<li> +Timestamps in persistent IORs were not required and have been removed.</li> -<li>The synchronization in the POA is now very optimal. For example, -the locks are not held across the invocation on the servant. The locks -are also not held across the invocation on the AdapterActivator and -ServantManagers. This allows us to use regular locks instead of -recursive locks inside the POA. This also allows multiple threads to -dispatch requests on the same POA simultaneous.</li><P> +<li> +POA exceptions are not not system exceptions and have been removed from +the list of system exceptions.</li> -<li>TAO now supports reference counting between POA and servants, -including the new RefCountServantBase and ServantBase_var -classes. RefCountServantBase is a reference counted base class that -was added to the CORBA specification to avoid race conditions for -servant deletion in threaded servers. <a -href="ftp://ftp.omg.org/pub/docs/orbos/98-07-12.pdf">ftp://ftp.omg.org/pub/docs/orbos/98-07-12.pdf</a> -contains the relevant text. Check <a -href="../poa_migration.html#Reference counting Servants">here</a> on -some hints to avoid trouble.</li><P> +<li> +Vastly improved the ability of the POA to deal with user exceptions, memory +allocation failures, and constructor failures.</li> -<li> The POA now supports active demultiplexing of servants in the -SYSTEM_ID and the USER_ID policy. This should make the POA faster and -more predictable since there is no hashing involved and the index of -the slot where the servant is registered is in the Object Key.</li> -<P> +<li> +We now support a minimum POA for the minimum CORBA specification. Recently, +this feature was enchanced such that the minimum CORBA footprint was further +reduced. In addition, minimum POA can be enabled/disable irrespective of +the minimum CORBA setting.</li> -<li> Previously, the complete POA name was used as the POA -identity. This scheme was inefficient in many ways including: (a) the -complete POA name can be significantly large in size, and therefore, -ineffient to pass with every method call from the client to the -server; (b) it is varible in size, and therefore, does not lend itself -to smart and effective parsing; (c) the searching based on the -complete POA name is very ineffient.</li> +<li> +We have decided not to support active demuxing for method name lookup. +The benefit of this optimization was questionable since the current perfect +hashing scheme provide very good and predictable behavior.</li> -<p> The new solution is to use an active demux table, and flatten the -POA hierarchy. This will help in the searching since active demuxing -is fast and predictable. This will also help in the parsing since the -demux key will be fixed size. +<br> +<p> +<p>Also, note that this optimization will require many changes. We would +have to use the help of the IDL compiler to modify the object key that +is passed for every method call differently. Note that this scheme doesn't +work in the case of multiple inheritance or when the client stubs are not +TAO. +<br> +<br> +<li> +Improved the parsing of object keys belonging to the RootPOA. Since this +is the default POA and is commonly used, we have given it a reserved byte +in the object key in order to quickly identify it. With the reserved bit, +the active demux key for the RootPOA is not used, and no map lookups are +required.</li> -<p> Note that for persistent ids, we have to pass the complete POA -name in addition to the demux key in order to handle POA creation on -demand.<P> +<li> +POA name separator was changed from '/' to '\0'. Since POA names are strings, +this makes a better choice since there is no chance of a conflict with +the string specified by the user.</li> -<li> There were some POA objects in a typical server that are not -freed up properly, resulting in a memory leak. This has now been -fixed.</li> <P> +<li> +We have support for reactivating servants with system generated ids.</li> -<li> Timestamps in persistent IORs were not required and have been -removed.</li> <P> +<li> +The TAO specific synchronization POA policy has been removed.</li> -<li> POA exceptions are not not system exceptions and have been -removed from the list of system exceptions.</li> <P> +<li> +New examples have been added to show how servants can be dynamically loaded +from DLLs on demand.</li> -<li> Vastly improved the ability of the POA to deal with user -exceptions, memory allocation failures, and constructor failures.</li> -<P> +<li> +Support for collocation should be much better now because the POA can tell +if we created the object reference.</li> -<li> We now support a minimum POA for the minimum CORBA specification. -Recently, this feature was enchanced such that the minimum CORBA -footprint was further reduced. In addition, minimum POA can be -enabled/disable irrespective of the minimum CORBA setting.</li> <P> +<li> +After Nanbor's recent changes for collocation, we support the full semantics +of remote objects on a collocated object. The spec mandates that collocated +object should behave <i>exactly</i> like remote objects, which includes +going through the POA, running the Servant Managers, running the interceptors, +and expecting the reference counting behavior provided by the POA. Note +that the old scheme of direct call through to the servant is also still +available.</li> -<li> We have decided not to support active demuxing for method name -lookup. The benefit of this optimization was questionable since the -current perfect hashing scheme provide very good and predictable -behavior.</li> <P> +<br> +<p> +<br> +<br> </ul> -Also, note that this optimization will require many changes. We would -have to use the help of the IDL compiler to modify the object key that -is passed for every method call differently. Note that this scheme -doesn't work in the case of multiple inheritance or when the client -stubs are not TAO.<P> - -<li> Improved the parsing of object keys belonging to the -RootPOA. Since this is the default POA and is commonly used, we have -given it a reserved byte in the object key in order to quickly -identify it. With the reserved bit, the active demux key for the -RootPOA is not used, and no map lookups are required.</li> <P> - -<li> POA name separator was changed from '/' to '\0'. Since POA names -are strings, this makes a better choice since there is no chance of a -conflict with the string specified by the user. </li> <P> - -<li> We have support for reactivating servants with system generated -ids. </li> <P> - -<li> The TAO specific synchronization POA policy has been -removed. </li> <P> - -<li> New examples have been added to show how servants can be -dynamically loaded from DLLs on demand. </li> <P> - -<li> Support for collocation should be much better now because the POA -can tell if we created the object reference.</li><P> - -<li> After Nanbor's recent changes for collocation, we support the -full semantics of remote objects on a collocated object. The spec -mandates that collocated object should behave <i>exactly</i> like -remote objects, which includes going through the POA, running the -Servant Managers, running the interceptors, and expecting the -reference counting behavior provided by the POA. Note that the old -scheme of direct call through to the servant is also still -available. </li><P> - -</UL> <hr> - <br><!--#include virtual="OBV.html" --> - <h3> <a NAME="nservices"></a>CORBA Naming Service and Interoperable Naming Service</h3> -Points of contact: <a href="mailto:marina@cs.wustl.edu">Marina -Spivak</a> and <a href="mailto:vishal@cs.wustl.edu">Vishal Kachroo</a> -<p> - -OMG defined CORBA Naming Service (spec <a -href="ftp://ftp.omg.org/pub/docs/formal/97-07-12.pdf">here</a>) to -provide a basic service location mechanism for CORBA systems. -CosNaming manages a hierarchy of name-to-object-reference mappings. -Anything, but typically the server process hosting an object, may bind -an object reference with a name in the Naming Service by providing the -name and object reference. Interested parties (typically clients) can -then use the Naming Service to resolve a name to an object reference. -<p> - -More recently, CORBA Naming Service was subsumed/extended by the CORBA -Interoperable Naming Service, a.k.a. INS (spec <A -HREF="ftp://ftp.omg.org/pub/docs/orbos/98-10-11.pdf">here</A>). INS -inherits all the functionality from the original Naming Service -specification in addition to addressing some its shortcomings. In -particular, INS defines a standard way for clients and servers to -locate the Naming Service itself. It also allows the ORB to be -administratively configured for bootstrapping to services not set up -with the orb at install time. <a href="../INS.html">This page</a> -provides a brief description of additional features INS provides, and -how they are implemented in TAO. <P> - +Points of contact: <a href="mailto:marina@cs.wustl.edu">Marina Spivak</a> +and <a href="mailto:vishal@cs.wustl.edu">Vishal Kachroo</a> +<p>OMG defined CORBA Naming Service (spec <a href="ftp://ftp.omg.org/pub/docs/formal/97-07-12.pdf">here</a>) +to provide a basic service location mechanism for CORBA systems. CosNaming +manages a hierarchy of name-to-object-reference mappings. Anything, but +typically the server process hosting an object, may bind an object reference +with a name in the Naming Service by providing the name and object reference. +Interested parties (typically clients) can then use the Naming Service +to resolve a name to an object reference. +<p>More recently, CORBA Naming Service was subsumed/extended by the CORBA +Interoperable Naming Service, a.k.a. INS (spec <a href="ftp://ftp.omg.org/pub/docs/orbos/98-10-11.pdf">here</a>). +INS inherits all the functionality from the original Naming Service specification +in addition to addressing some its shortcomings. In particular, INS defines +a standard way for clients and servers to locate the Naming Service itself. +It also allows the ORB to be administratively configured for bootstrapping +to services not set up with the orb at install time. <a href="../INS.html">This +page</a> provides a brief description of additional features INS provides, +and how they are implemented in TAO. <p>Current status (as of 18 May 2001): <ul> -<li>The Naming Service now <em>does not</em> do listen for multicast -discovery as the default. Use <code>-m1</code> option to turn it on. +<li> +The Naming Service now <i>does not</i> do listen for multicast discovery +as the default. Use <tt>-m1</tt> option to turn it on.</li> </ul> Recent work: <ul> -<li>Changed default for multicast discovery to +<li> +Changed default for multicast discovery to</li> </ul> Features: <ul> <li> -Added support for Persistence (using memory-mapped files). Persistence +Added support for Persistence (using memory-mapped files). Persistence feature is optional, and is controlled by the command line argument.</li> -<li>Updated the implementation of the Naming Service to use new ACE -exception macros.</li> <li> -Added support for the InterOperable Naming Service, which enables the -ORB to support IORs in user-friendly <CODE>corbaloc</CODE> format. -These features allow the ORB to be configured to return arbitrary object -references from <CODE>CORBA::ORB::resolve_initial_references</CODE> -for non-locality-constrained objects. Two options -ORBInitRef and --ORBDefaultInitRef have been added to the orb for bootstrapping to -arbitrary services. -</li> +Updated the implementation of the Naming Service to use new ACE exception +macros.</li> -<li>Added support for the Naming service to act like an agent: to -understand IIOP request messages from clients and respond with reply -messages with a <code>LOCATION_FORWARD/OBJECT_NOT_EXIST</code> -status. The Naming Service can be configured through ORB options to -register arbitrary services given the URL-format IOR for the -service. The <code>resolve_initial_references ()</code> resolves a service in the -following order : <ol><li><code>-ORBInitRef</code><li><code>-ORBDefaultInitRef</code> -<li>Multicast discovery</ol> -</li> <li> -Added a test for the InterOperable Naming Service that works in -conjunction with the current TAO examples. -</li> +Added support for the InterOperable Naming Service, which enables the ORB +to support IORs in user-friendly <tt>corbaloc</tt> format. These features +allow the ORB to be configured to return arbitrary object references from +<tt>CORBA::ORB::resolve_initial_references</tt> +for non-locality-constrained objects. Two options -ORBInitRef and -ORBDefaultInitRef +have been added to the orb for bootstrapping to arbitrary services.</li> + <li> -Implementation of the CORBA INS spec is completed. The -following features are now supported: - <ul> - <li> corbaname format </li> - <li> NamingServiceExt interface</li> - </ul> -</li> +Added support for the Naming service to act like an agent: to understand +IIOP request messages from clients and respond with reply messages with +a <tt>LOCATION_FORWARD/OBJECT_NOT_EXIST</tt> status. The Naming Service +can be configured through ORB options to register arbitrary services given +the URL-format IOR for the service. The <tt>resolve_initial_references +()</tt> resolves a service in the following order :</li> -</ul> +<ol> +<li> +<tt>-ORBInitRef</tt></li> + +<li> +<tt>-ORBDefaultInitRef</tt></li> +<li> +Multicast discovery</li> +</ol> + +<li> +Added a test for the InterOperable Naming Service that works in conjunction +with the current TAO examples.</li> + +<li> +Implementation of the CORBA INS spec is completed. The following features +are now supported:</li> + +<ul> +<li> +corbaname format</li> + +<li> +NamingServiceExt interface</li> +</ul> +</ul> Future work: <ul> <li> -Support for a load balancing feature similar to the one present in -ORBIX. It will be possible to bind a group of objects under a single -name, and when a client attempts to resolve the name in question, a -preset policy (e.g., random, round robin, etc.) will determine which -one of the object references from the group will be returned. -</li> +Support for a load balancing feature similar to the one present in ORBIX. +It will be possible to bind a group of objects under a single name, and +when a client attempts to resolve the name in question, a preset policy +(e.g., random, round robin, etc.) will determine which one of the object +references from the group will be returned.</li> + <li> -Support for the Naming Service to handle the IIOP LocateRequest -messages and respond with LocateReply messages with a -<code>LOCATION_FORWARD/OBJECT_NOT_EXIST</code> status. -</li> +Support for the Naming Service to handle the IIOP LocateRequest messages +and respond with LocateReply messages with a +<tt>LOCATION_FORWARD/OBJECT_NOT_EXIST</tt> +status.</li> </ul> -<p> <hr> - <h3> <a NAME="tservices"></a>CORBA Trading Service</h3> Point of contact: <a href="mailto:sbw1@cs.wustl.edu">Seth Widoff</a> - -<p>The <a -href="http://www.omg.org/technology/documents/formal/trading_object_service.htm">Trading -Service</a> is an implementation of the COS Trading Service -speficiation that meets the Linked Trader conformance criteria --- it -implements the <tt>Lookup</tt>, <tt>Register</tt>, <tt>Admin</tt>, and -<tt>Link</tt> interfaces, but not the <tt>Proxy</tt> -interface. Notably, the TAO trader supports the following features:<P> -<ul> <li> Multithreaded operation;</li> +<p>The <a href="http://www.omg.org/technology/documents/formal/trading_object_service.htm">Trading +Service</a> is an implementation of the COS Trading Service speficiation +that meets the Linked Trader conformance criteria --- it implements the +<tt>Lookup</tt>, +<tt>Register</tt>, <tt>Admin</tt>, and +<tt>Link</tt> interfaces, but not +the <tt>Proxy</tt> interface. Notably, the TAO trader supports the following +features: +<br> +<br> +<ul> +<li> +Multithreaded operation;</li> <li> Trader federations and distributed queries;</li> @@ -1294,49 +1265,37 @@ The Proxy Interface.</li> <li> Persistent storage of service types and offers.</li> </ul> -<p> -<hr> +<hr> <h3> <a NAME="pservices"></a>CORBA Property Service</h3> -Point of contact: <a href="mailto:alex@cs.wustl.edu">Alexander Babu -Arulanthu</a> - -<p>Current status (as of Mar 9th, 1999): All the interfaces of this -service have been implemented. Please go through the test examples at -$TAO/orbsvcs/tests/CosPropertyService. Property Service is has been -used by the TAO's <a href="#av">Audio Video Streaming -Service</a>developed for TAO. For general documentation of the -Property Service, please read <a -href="http://www.omg.org/technology/documents/formal/property_service.htm">The +Point of contact: <a href="mailto:alex@cs.wustl.edu">Alexander Babu Arulanthu</a> +<p>Current status (as of Mar 9th, 1999): All the interfaces of this service +have been implemented. Please go through the test examples at $TAO/orbsvcs/tests/CosPropertyService. +Property Service is has been used by the TAO's <a href="#av">Audio Video +Streaming Service</a>developed for TAO. For general documentation of the +Property Service, please read <a href="http://www.omg.org/technology/documents/formal/property_service.htm">The Property Service Specification.</a> - -<P>Recent Work: +<p>Recent Work: <ul> - <li> - Changed the PropertyException from Exception to struct, according - to the OMG's changes. - </li> - <li> - Changed the implementation to allocate storage for the Sequence - out parameters, eventhough their length is 0. This is according - to the CORBA specification. - </li> +<li> +Changed the PropertyException from Exception to struct, according to the +OMG's changes.</li> + +<li> +Changed the implementation to allocate storage for the Sequence out parameters, +eventhough their length is 0. This is according to the CORBA specification.</li> </ul> -<p> <hr> - <h3> <a NAME="cservices"></a>CORBA Concurrency Service</h3> Point of contact: <a href="mailto:tworm@cs.wustl.edu">Torben Worm</a> -<p>Current status (as of May 3rd): - -The <a -href="http://www.omg.org/technology/documents/formal/concurrency_service.htm">Concurrency -Service</a> provides a mechanism that allows clients to acquire and -release various types of locks in a distributed system.<P> - +<p>Current status (as of May 3rd): The <a href="http://www.omg.org/technology/documents/formal/concurrency_service.htm">Concurrency +Service</a> provides a mechanism that allows clients to acquire and release +various types of locks in a distributed system. +<br> +<br> <ul> <li> A simple version of the Concurrency Service has been implemented, i.e. @@ -1346,66 +1305,62 @@ Future Work: <ul> <li> Implementation of the Concurrency Service with transactions</li> -</ul><P> +</ul> + <hr WIDTH="100%"> -<h3><a NAME="av"></a>CORBA Audio/Video Streaming Service</h3> +<h3> +<a NAME="av"></a>CORBA Audio/Video Streaming Service</h3> Point of contact: <a href="mailto:yamuna@oomworks.com">Yamuna Krishnamurthy</a> -<p>This is an implementation of the OMG spec addressing the <a -href="http://www.omg.org/technology/documents/formal/audio.htm">Control -and Management of Audio/Video Streams</a>. For more documentation on -TAO's A/V Service please have a look <A HREF="http://www.cs.wustl.edu/~schmidt/av.html">here</A>. +<p>This is an implementation of the OMG spec addressing the <a href="http://www.omg.org/technology/documents/formal/audio.htm">Control +and Management of Audio/Video Streams</a>. For more documentation on TAO's +A/V Service please have a look <a href="http://www.cs.wustl.edu/~schmidt/av.html">here</a>. +<h4> +Current Status:</h4> +(as of July 30 2002) +<ul> +<li> +The audio/video streaming service has been implemented in the full profile. +The current implementation support all the flow related components like +flowEndpoint,FDev,FlowConnection,..,etc.</li> -<p><h4>Current Status:</h4> (as of July 30 2002) -<p> +<li> +Point-to_Point and Point-to-MultiPoint streams have been implemented.</li> + +<li> +A Pluggable protocols framework has been implemented to flexibly add new +flow protocols like SFP, RTP and new transports like ATM. The current implementation +has protoocol implementations for SFP, RTP over UDP and Multicast UDP. +Please look at <tt><a href="../../orbsvcs/orbsvcs/AV/AV_Pluggable_Framework.html">orbsvcs/orbsvcs/AV/AV_Pluggable_Framework.html</a></tt>for +more documentation about the implementation.</li> + +<li> +QoS_UDP pluggable protocol added which implements RSVP QoS support for +UDP streams.</li> + +<li> +Diffserv support added to the UDP pluggable protocol by <a href="mailto:crodrigu@bbn.com">Craig +Rodrigues</a>.</li> + +<li> +RTP/UDP support enhancements and RTCP control protocol support added by +<a href="mailto:rruff@scires.com">Rob +Ruff</a>.</li> +</ul> +Work in progress: <ul> - <li> - The audio/video streaming service has been implemented in the full - profile. The current implementation support all the flow related - components like flowEndpoint,FDev,FlowConnection,..,etc. - </li> - <li> - Point-to_Point and Point-to-MultiPoint streams have been - implemented. - </li> - <li> - A Pluggable protocols framework has been implemented to flexibly - add new flow protocols like SFP, RTP and new transports like - ATM. The current implementation has protoocol implementations - for SFP, RTP over UDP and Multicast UDP. Please look at <A - HREF="../../orbsvcs/orbsvcs/AV/AV_Pluggable_Framework.html"><CODE>orbsvcs/orbsvcs/AV/AV_Pluggable_Framework.html</CODE> - </A> for more documentation about the implementation. - </li> - <li> - QoS_UDP pluggable protocol added which implements RSVP QoS support - for UDP streams. - </li> - <li> - Diffserv support added to the UDP pluggable protocol by <a href="mailto:crodrigu@bbn.com">Craig Rodrigues</a>. - </li> - <li> - RTP/UDP support enhancements and RTCP control protocol support added by - <a href="mailto:rruff@scires.com">Rob Ruff</a>. - </li> -</ul> -<p>Work in progress: -<ul> - <li> - Integration with <a href="http://www.dist-systems.bbn.com/projects/AIRES/UAV/">BBN UAV software.</a> - </li> +<li> +Integration with <a href="http://www.dist-systems.bbn.com/projects/AIRES/UAV/">BBN +UAV software.</a></li> </ul> <hr> - <p><a NAME="ts"></a><b>CORBA Time Service</b> <p>Point of contact: <a href="mailto:vishal@cs.wustl.edu">Vishal Kachroo</a> - -<p> The <a href="ftp://ftp.omg.org/pub/docs/formal/97-02-22.pdf">Time Service</a> - allows clients to connect to Time Service Clerks and obtain globally -synchronized time. This time is calculated from the time obtained from -one or more Time Servers running on multiple machines in the -network. The service uses the TAO Implementation Repository to -activate the time servers on demand. - +<p>The <a href="ftp://ftp.omg.org/pub/docs/formal/97-02-22.pdf">Time Service</a> +allows clients to connect to Time Service Clerks and obtain globally synchronized +time. This time is calculated from the time obtained from one or more Time +Servers running on multiple machines in the network. The service uses the +TAO Implementation Repository to activate the time servers on demand. <p>Current status (as of 10th Jan 1999): <ul> <li> @@ -1421,14 +1376,13 @@ algorithm can be used in the future.</li> <li> Implementation of the Timer Event Service.</li> </ul> -<p> <hr WIDTH="100%"> <h3> <a NAME="ec"></a>CORBA Event Service</h3> <h4> -Last updated: Fri Mar 5 20:38:26 CST 1999</h4> +Last updated: Fri Mar 5 20:38:26 CST 1999</h4> Point of contact: <a href="mailto:pradeep@cs.wustl.edu">Pradeep Gore</a> <p>The COS compliant Event Service implements the Event Service Specification: <a href="ftp://ftp.omg.org/pub/docs/formal/97-12-11.pdf">(.pdf)</a>, @@ -1437,32 +1391,14 @@ Point of contact: <a href="mailto:pradeep@cs.wustl.edu">Pradeep Gore</a> <h3> Features in this release:</h3> -<ul> - <li><P>There is a new implementation of the COS Event Service - available. - This new implementation supports both the Push and Pull - styles for event communication, and it does not require the - Real-time Event Service to work. - </P> - </LI> - - <LI><P>A new testsuite for the COS Event Service has been - started, they are available at: - <CODE>$TAO_ROOT/orbsvcs/tests/CosEvent/</CODE> - </P> - </LI> - - <LI><P>A new example for the COS Event Service is provided in - <CODE>$TAO_ROOT/orbsvcs/examples/CosEC/Simple/</CODE> - </P> - </LI> - - <LI><P>A new binary to run the native COS Event Service was - added, it is compiled in: - <CODE>$TAO_ROOT/orbsvcs/CosEvent_Service/CosEvent_Service_Native</CODE> - </P> - </LI> - +<ul>There is a new implementation of the COS Event Service available. This +new implementation supports both the Push and Pull styles for event communication, +and it does not require the Real-time Event Service to work. +<p>A new testsuite for the COS Event Service has been started, they are +available at: <tt>$TAO_ROOT/orbsvcs/tests/CosEvent/</tt> +<p>A new example for the COS Event Service is provided in <tt>$TAO_ROOT/orbsvcs/examples/CosEC/Simple/</tt> +<p>A new binary to run the native COS Event Service was added, it is compiled +in: <tt>$TAO_ROOT/orbsvcs/CosEvent_Service/CosEvent_Service_Native</tt> <li> A simple test (<tt>$TAO_ROOT/orbsvcs/tests/CosEC_Basic</tt>) demonstrates how to create and use the event channel.</li> @@ -1473,379 +1409,308 @@ creates a COS compliant event channel and registers it with the naming service with the default name "CosEventChannel".</li> <br>Please read the associated README for more details. - <li> -CosEC_Multiple: <tt>($TAO_ROOT/orbsvcs/tests/CosEC_Multiple)</tt>: -This test demonstrates how multiple CosEC's connect to one RtEC and how -multiple consumers and producers exchange events in this configuration.</li> +CosEC_Multiple: <tt>($TAO_ROOT/orbsvcs/tests/CosEC_Multiple)</tt>: This +test demonstrates how multiple CosEC's connect to one RtEC and how multiple +consumers and producers exchange events in this configuration.</li> </ul> + <h3> Known bugs:</h3> + <ul> <li> -CosEC_Multiple: <tt>($TAO_ROOT/orbsvcs/tests/CosEC_Multiple)</tt>: -Once the tests are done, the control doesn't return to the shell, -you have to say CTRL-C to get back to the prompt. -</li> +CosEC_Multiple: <tt>($TAO_ROOT/orbsvcs/tests/CosEC_Multiple)</tt>: Once +the tests are done, the control doesn't return to the shell, you have to +say CTRL-C to get back to the prompt.</li> </ul> <hr WIDTH="100%"> -<h3><a NAME="log"></a>CORBA Telecom Log Service </h3> +<h3> +<a NAME="log"></a>CORBA Telecom Log Service</h3> -<h4> Last updated: Mon Oct 14 13:03:21 CDT 2002 </h4> +<h4> +Last updated: Mon Oct 14 13:03:21 CDT 2002</h4> Point of contact: <a href="mailto:d.hanvey@qub.ac.uk">D A Hanvey</a> -<p>The CORBA <a -href="http://www.omg.org/cgi-bin/doc?telecom/99-05-01"> Telecom Log -Service </a> prototype was updated in TAO 1.3. -<br> -<h3> Features supported in the current version:</h3> - -<ul> - <li> - The Log Service implementation under <tt>$TAO_ROOT/orbsvcs/orbsvcs/Log</tt> - implements the <tt>DsLogAdmin </tt>module. - <br> - </li> - <li> - Support for the <tt>DsEventLogAdmin </tt> module, which uses - the <a href= "#ec">COS Event Service</a> has been added. - <br> - </li> - <li> - Support for the <tt>DsNotifyLogAdmin </tt> module, which uses - the <a href= "#notify">Notification Service</a> has been added. - <br> - </li> - <li> - Support for the <tt>RTEventLog </tt> module, which uses - the <a href= "ec.html">RTEvent Service</a> has been added. - <br> - </li> - <li> - Support for the <tt>DsLogNotification </tt> module for log- - generated events has been added. - <br> - </li> - - <li> - The Logging_Service (<tt>$TAO_ROOT/orbsvcs/Logging_Service</tt>) contains 4 - separate services - <ul> - <li>Basic_Logging_Service <tt>$TAO_ROOT/orbsvcs/Logging_Service/Basic_Logging_Service</tt></li> - <li>Event_Logging_Service <tt>$TAO_ROOT/orbsvcs/Logging_Service/Event_Logging_Service</tt></li> - <li>Notify_Logging_Service <tt>$TAO_ROOT/orbsvcs/Logging_Service/Notify_Logging_Service</tt></li> - <li>RTEvent_Logging_Service <tt>$TAO_ROOT/orbsvcs/Logging_Service/RTEvent_Logging_Service</tt></li> - </ul> - Each service registers with the Naming Service as "BasicLogFactory", - "EventLogFactory", "NotifyLogFactory" and "RTEventLogFactory" respectively. - <br> - </li> - <li> - There are now examples that demonstrate simple usage of the Log Services. - These are found in <tt>$TAO_ROOT/orbsvcs/examples/Log</tt> and the - relevant sub-directories. - <br> - A thorough test <tt>$TAO_ROOT/orbsvcs/tests/Log/Basic_Log_Test</tt> tests - most of the features of the basic logging service. - </li> - <li> - The Query Language supported at present is "ETCL". - The Log record id and Log record time are treated as properties - of the log and can be referenced in a query as "id" and "time" - respectively. - <br> - </li> -</ul> - -<h3> Future work and enhancements: </h3> -<ul> - - <li> - Currently all Log records are stored in memory, later we could add - support for persistant storage. - <br> - </li> - <li> - Use Red-Black trees to optimize lookup on frequently used query keys - - namely record id's and time. - <br> - </li> -</ul> - - -<hr WIDTH="100%"> -<h3><a NAME="notify"></a>Notification Service </h3> - -<h4> Last updated:Thu Nov 21 18:41:11 2002 </h4> -Point of contact: <a href="mailto:pradeep@oomworks.com">Pradeep Gore</a> -<p> +<p>The CORBA <a href="http://www.omg.org/cgi-bin/doc?telecom/99-05-01">Telecom +Log Service </a>prototype was updated in TAO 1.3. +<h3> +Features supported in the current version:</h3> -TAO's CORBA <a href="ftp://ftp.omg.org/pub/docs/telecom/99-07-01.pdf"> -Notification Service </a> implementation consists of the following -(see the associated README's for more information): <ul> - <li> - The implementation of the interfaces in the Notification Service - spec is in <tt><a href = "../../orbsvcs/orbsvcs/Notify"> $TAO_ROOT/orbsvcs/orbsvcs/Notify </a></tt>. - </li> - - <li> - The service driver is implemented in - <tt><a href = "../../orbsvcs/Notify_Service">$TAO_ROOT/orbsvcs/Notify_Service</a></tt>. <br> -The various options of the Notify_Service are described <a href="notify.html#notify_Service">here </a>. - </li> - - <li> - The example in <tt><a href = "../../orbsvcs/examples/Notify/Filter"> $TAO_ROOT/orbsvcs/examples/Notify/Filter</a></tt> - shows a basic example of using filters. - </li> - - <li> - The example in <tt><a href= "../../orbsvcs/examples/Notify/Subscribe"> $TAO_ROOT/orbsvcs/examples/Notify/Subscribe</a> - </tt> shows a basic example of how to use subscriptions. - </li> +<li> +The Log Service implementation under <tt>$TAO_ROOT/orbsvcs/orbsvcs/Log</tt> +implements the <tt>DsLogAdmin </tt>module.</li> - <li> - Feature unit tests are under <tt><a href="../../orbsvcs/tests/Notify"> $TAO_ROOT/orbsvcs/tests/Notify </a></tt> - </li> +<li> +Support for the <tt>DsEventLogAdmin </tt>module, which uses the <a href="#ec">COS +Event Service</a> has been added.</li> - <li> - The <a href="notify.html#feature_matrix" >Notification feature matrix </a>lists the features implemented. - </li> -</ul> +<li> +Support for the <tt>DsNotifyLogAdmin </tt>module, which uses the <a href="#notify">Notification +Service</a> has been added.</li> -<i>Note that this implementation does not support Pull interfaces and -Typed Event style communication.</i> -<p> +<li> +Support for the <tt>RTEventLog </tt>module, which uses the <a href="ec.html">RTEvent +Service</a> has been added.</li> -<hr WIDTH="100%"> -<h3><a NAME="rt_notify"></a>Real-Time Notification Service </h3> +<li> +Support for the <tt>DsLogNotification </tt>module for log- generated events +has been added.</li> -<h4> Last updated:Thu Jul 24 11:57:53 2003 </h4> -Point of contact: <a href="mailto:pradeep@oomworks.com">Pradeep Gore</a> -<p> +<li> +The Logging_Service (<tt>$TAO_ROOT/orbsvcs/Logging_Service</tt>) contains +4 separate services</li> -This is an extension to TAO's CORBA Notification Service with Real-Time CORBA support. -<p> -<b>IDL Extensions:</b> <ul> +<li> +Basic_Logging_Service <tt>$TAO_ROOT/orbsvcs/Logging_Service/Basic_Logging_Service</tt></li> <li> +Event_Logging_Service <tt>$TAO_ROOT/orbsvcs/Logging_Service/Event_Logging_Service</tt></li> -<b>Interface Extensions:</b> -The <a href ="../../orbsvcs/orbsvcs/NotifyExt.idl"> $TAO_ROOT/orbsvcs/orbsvcs/NotifyExt.idl</a> extends the ConsumerAdmin -and SupplierAdmin interfaces. The <tt>obtain_notification_push_supplier_with_qos</tt> and <tt>obtain_notification_push_consumer_with_qos</tt> methods can be used to specify QoS parameters. +<li> +Notify_Logging_Service <tt>$TAO_ROOT/orbsvcs/Logging_Service/Notify_Logging_Service</tt></li> -</li> +<li> +RTEvent_Logging_Service <tt>$TAO_ROOT/orbsvcs/Logging_Service/RTEvent_Logging_Service</tt></li> +</ul> +Each service registers with the Naming Service as "BasicLogFactory", "EventLogFactory", +"NotifyLogFactory" and "RTEventLogFactory" respectively. +<li> +There are now examples that demonstrate simple usage of the Log Services. +These are found in <tt>$TAO_ROOT/orbsvcs/examples/Log</tt> and the relevant +sub-directories.</li> +<br>A thorough test <tt>$TAO_ROOT/orbsvcs/tests/Log/Basic_Log_Test</tt> +tests most of the features of the basic logging service. <li> +The Query Language supported at present is "ETCL". The Log record id and +Log record time are treated as properties of the log and can be referenced +in a query as "id" and "time" respectively.</li> +</ul> -<b>QoS Definitions:</b> +<h3> +Future work and enhancements:</h3> <ul> +<li> +Currently all Log records are stored in memory, later we could add support +for persistant storage.</li> -<li>ThreadPoolParams: This specifies the parameters for creating a -threadpool in an RT POA. -</li> - -<li>ThreadPoolLanesParams: This specifies the parameters for creating a -threadpool with lanes in an RT POA. -</li> - -</ul> - -</li> - +<li> +Use Red-Black trees to optimize lookup on frequently used query keys - +namely record id's and time.</li> </ul> -<b>Tests and Examples:</b> +<hr WIDTH="100%"> +<h3> +<a NAME="notify"></a>Notification Service</h3> +<h4> +Last updated:Thu Nov 21 18:41:11 2002</h4> +Point of contact: <a href="mailto:pradeep@oomworks.com">Pradeep Gore</a> +<p>TAO's CORBA <a href="ftp://ftp.omg.org/pub/docs/telecom/99-07-01.pdf">Notification +Service </a>implementation consists of the following (see the associated +README's for more information): <ul> - <li> +The implementation of the interfaces in the Notification Service spec is +in <tt><a href="../../orbsvcs/orbsvcs/Notify">$TAO_ROOT/orbsvcs/orbsvcs/Notify +</a></tt>.</li> -The <a href = "../../orbsvcs/examples/Notify/Lanes" > <tt>$TAO_ROOT/orbsvcs/examples/Notify/Lanes </tt></a> example shows how to use RTCORBA -Lanes in RT Notification. - -</li> +<li> +The service driver is implemented in <tt><a href="../../orbsvcs/Notify_Service">$TAO_ROOT/orbsvcs/Notify_Service</a></tt>.</li> +<br>The various options of the Notify_Service are described <a href="notify.html#notify_Service">here +</a>. <li> +The example in <tt><a href="../../orbsvcs/examples/Notify/Filter">$TAO_ROOT/orbsvcs/examples/Notify/Filter</a></tt> +shows a basic example of using filters.</li> -The <a href ="../../orbsvcs/examples/Notify/ThreadPool"> <tt>$TAO_ROOT/orbsvcs/examples/Notify/ThreadPool</a></tt> example shows how to -use RTCORBA ThreadPools in RT Notification. +<li> +The example in <tt><a href="../../orbsvcs/examples/Notify/Subscribe">$TAO_ROOT/orbsvcs/examples/Notify/Subscribe</a></tt>shows +a basic example of how to use subscriptions.</li> -</li> +<li> +Feature unit tests are under <tt><a href="../../orbsvcs/tests/Notify">$TAO_ROOT/orbsvcs/tests/Notify</a></tt></li> +<li> +The <a href="notify.html#feature_matrix">Notification feature matrix </a>lists +the features implemented.</li> </ul> +<i>Note that this implementation does not support Pull interfaces and Typed +Event style communication.</i> +<p> +<hr WIDTH="100%"> +<h3> +<a NAME="rt_notify"></a>Real-Time Notification Service</h3> -The performance tests for RT Notification measure the throughput, -latency and jitter for various test configurations using Periodic Suppliers: - +<h4> +Last updated:Thu Jul 24 11:57:53 2003</h4> +Point of contact: <a href="mailto:pradeep@oomworks.com">Pradeep Gore</a> +<p>This is an extension to TAO's CORBA Notification Service with Real-Time +CORBA support. +<p><b>IDL Extensions:</b> <ul> +<li> +<b>Interface Extensions:</b> The <a href="../../orbsvcs/orbsvcs/NotifyExt.idl">$TAO_ROOT/orbsvcs/orbsvcs/NotifyExt.idl</a> +extends the ConsumerAdmin and SupplierAdmin interfaces. The <tt>obtain_notification_push_supplier_with_qos</tt> +and <tt>obtain_notification_push_consumer_with_qos</tt> methods can be +used to specify QoS parameters.</li> <li> -<a href = "../../orbsvcs/tests/Notify/performance-tests/scripts/1_Path_Period_0_Lanes" ><tt>$TAO_ROOT/tests/Notify/performance-tests/scripts/1_Path_Period_0_Lanes</tt></a> <br> -This configuration measures performance for a single data path when -the load is increased. The Supplier sends events in a single burst. +<b>QoS Definitions:</b></li> -</li> +<ul> +<li> +ThreadPoolParams: This specifies the parameters for creating a threadpool +in an RT POA.</li> <li> +ThreadPoolLanesParams: This specifies the parameters for creating a threadpool +with lanes in an RT POA.</li> +</ul> +</ul> +<b>Tests and Examples:</b> +<ul> +<li> +The <tt><a href="../../orbsvcs/examples/Notify/Lanes">$TAO_ROOT/orbsvcs/examples/Notify/Lanes +</a></tt>example +shows how to use RTCORBA Lanes in RT Notification.</li> -<a href = "../../orbsvcs/tests/Notify/performance-tests/scripts/3_Path_Period_10ms_Lanes" ><tt>$TAO_ROOT/tests/Notify/performance-tests/scripts/3_Path_Period_10ms_Lanes</tt></a> <br> -This configuration measures performance for 3 data paths of high, -,medium and low priorities when the Load is increased. The Suppliers send events at 100Hz. +<li> +The <tt><a href="../../orbsvcs/examples/Notify/ThreadPool">$TAO_ROOT/orbsvcs/examples/Notify/ThreadPool</a></tt> +example shows how to use RTCORBA ThreadPools in RT Notification.</li> +</ul> +The performance tests for RT Notification measure the throughput, latency +and jitter for various test configurations using Periodic Suppliers: +<ul> +<li> +<tt><a href="../../orbsvcs/tests/Notify/performance-tests/scripts/1_Path_Period_0_Lanes">$TAO_ROOT/tests/Notify/performance-tests/scripts/1_Path_Period_0_Lanes</a></tt></li> - </li> +<br>This configuration measures performance for a single data path when +the load is increased. The Supplier sends events in a single burst. +<li> +<tt><a href="../../orbsvcs/tests/Notify/performance-tests/scripts/3_Path_Period_10ms_Lanes">$TAO_ROOT/tests/Notify/performance-tests/scripts/3_Path_Period_10ms_Lanes</a></tt></li> +<br>This configuration measures performance for 3 data paths of high, ,medium +and low priorities when the Load is increased. The Suppliers send events +at 100Hz. <li> +<tt><a href="../../orbsvcs/tests/Notify/performance-tests/scripts/Paths_vs_Throughput">$TAO_ROOT/tests/Notify/performance-tests/scripts/Paths_vs_Throughput</a></tt></li> -<a href = "../../orbsvcs/tests/Notify/performance-tests/scripts/Paths_vs_Throughput"> <tt>$TAO_ROOT/tests/Notify/performance-tests/scripts/Paths_vs_Throughput </tt></a><br> -This configuration has 1 high priority path ans several low priority -paths. we measure the performance of the high priority path as a -function of the number of low priority paths. +<br>This configuration has 1 high priority path ans several low priority +paths. we measure the performance of the high priority path as a function +of the number of low priority paths. +<li> +<tt><a href="../../orbsvcs/tests/Notify/performance-tests/scripts/Max_Throughput">$TAO_ROOT/tests/Notify/performance-tests/scripts/Max_Throughput</a></tt></li> -</li> +<br>This Configuration measures the performance obtained for a data path +using a Structured Event payload: +<ul> +<li> +directly between a Supplier and Consumer in seperate processes.</li> <li> +directly between a colocated Supplier and Consumer.</li> -<a href = "../../orbsvcs/tests/Notify/performance-tests/scripts/Max_Throughput"> <tt>$TAO_ROOT/tests/Notify/performance-tests/scripts/Max_Throughput</tt></a> <br> -This Configuration measures the performance obtained for a data path using a Structured Event payload: +<li> +between a Supplier and Consumer with a "Relay Consumer" as an intermidiary.</li> -<ul> -<li>directly between a Supplier and Consumer in seperate processes.</li> -<li>directly between a colocated Supplier and Consumer.</li> -<li>between a Supplier and Consumer with a "Relay Consumer" as an -intermidiary.</li> -<li>between a a Supplier and Consumer using the Notification Service.</li> +<li> +between a a Supplier and Consumer using the Notification Service.</li> </ul> - -</li> - </ul> +<b>Test Framework:</b> +<br>The <tt><a href="../../orbsvcs/tests/Notify/lib">$TAO_ROOT/orbsvcs/tests/Notify/lib</a></tt> +contains a scripting based test framework which can be used to quickly +create test cases. The framemork and its options are described <a href="notify.html#test_framework">here. </a><!-- BEGIN: CORBA Security Service Release Notes --> +<hr WIDTH="100%"> +<h3> +<a NAME="security"></a>CORBA Security Service</h3> +Point of contact: <a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</a> +<p>Additional information is available +<a href="http://doc.ece.uci.edu/TAO/Security/">here</a>. +<p>Implemented Features: +<ul>IIOP over SSL integration via TAO's <a href="http://doc.ece.uci.edu/TAO/Security/SSLIOP.html">SSLIOP +pluggable protocol</a>. +<ul> +<li> +Added an <tt>SSLIOP::Current</tt> implementation that can be used to obtain +the SSL session state for the current execution context. This is useful +for obtaining the SSL peer certificate chain associated with the current +request, for example.</li> -<b>Test Framework:</b><br> +<li> +TAO's SSLIOP pluggable protocol now registers a secure invocation server +request interceptor. It enforces secure invocation by rejecting requests +coming in on the insecure port if the server is configured to do so (default +behavior).</li> -The <a href = "../../orbsvcs/tests/Notify/lib"><tt>$TAO_ROOT/orbsvcs/tests/Notify/lib</a></tt> contains a scripting based test -framework which can be used to quickly create test cases. -The framemork and its options are described <a href="notify.html#test_framework">here. </a> +<li> +Implemented <tt>SecurityLevel1</tt> for the SSLIOP security mechanism.</li> -<!-- BEGIN: CORBA Security Service Release Notes --> -<HR WIDTH="100%"> -<H3><A NAME="security"></A>CORBA Security Service </H3> -Point of contact: <A HREF="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</A> +<li> +The <tt>SecurityLevel2::QOPPolicy</tt> policy has been implemented. This +policy is used to set the desired invocation Quality-of-Protection (QoP). +It can be created using <tt>ORB::create_policy()</tt>, and used in conjunction +with the standard policy manipulation CORBA features (e.g. <tt>PolicyManager</tt>, +<tt>PolicyCurrent</tt>), +meaning that this policy can be set on a per-ORB, per-thread or per-object +basis.</li> -<P> -Additional information is available -<A HREF="http://doc.ece.uci.edu/TAO/Security/">here</A>. +<br> +<p> +<p>This policy makes it possible to, for example, make both secure and +insecure invocations within the same client process. +<li> +TAO's SSLIOP pluggable protocol implementation is now thread-safe.</li> -<P> -Implemented Features: -<UL> - <LI> - <P> - IIOP over SSL integration via TAO's - <A HREF="http://doc.ece.uci.edu/TAO/Security/SSLIOP.html">SSLIOP pluggable protocol</A>. - <UL> - <P> - <LI> - Added an <CODE>SSLIOP::Current</CODE> implementation that can - be used to obtain the SSL session state for the current - execution context. This is useful for obtaining the SSL peer - certificate chain associated with the current request, for - example. - </LI> - <LI> - TAO's SSLIOP pluggable protocol now registers a secure - invocation server request interceptor. It enforces secure - invocation by rejecting requests coming in on the insecure - port if the server is configured to do so (default behavior). - </LI> - <LI> - Implemented <CODE>SecurityLevel1</CODE> for the SSLIOP - security mechanism. - </LI> - <LI> - The <CODE>SecurityLevel2::QOPPolicy</CODE> policy has been - implemented. This policy is used to set the desired - invocation Quality-of-Protection (QoP). It can be created - using <CODE>ORB::create_policy()</CODE>, and used in - conjunction with the standard policy manipulation CORBA - features (e.g. <CODE>PolicyManager</CODE>, - <CODE>PolicyCurrent</CODE>), meaning that this policy can - be set on a per-ORB, per-thread or per-object basis. - <P> - This policy makes it possible to, for example, make both secure - and insecure invocations within the same client process. - </LI> - <LI> - TAO's SSLIOP pluggable protocol implementation is now - thread-safe. - </LI> - <LI> - The <CODE>SecurityLevel2::EstablishTrustPolicy</CODE> - policy has been implemented. This policy is used to set - the desired - invocation level of establishment of trust. It can be created - using <CODE>ORB::create_policy()</CODE>, and used in - conjunction with the standard policy manipulation CORBA - features (e.g. <CODE>PolicyManager</CODE>, - <CODE>PolicyCurrent</CODE>), meaning that this policy can - be set on a per-ORB, per-thread or per-object basis. - <P> - This policy makes it possible to, for example, make - authenticated and non-authenticated invocations within - the same client process. - </LI> +<li> +The <tt>SecurityLevel2::EstablishTrustPolicy</tt> policy has been implemented. +This policy is used to set the desired invocation level of establishment +of trust. It can be created using <tt>ORB::create_policy()</tt>, and used +in conjunction with the standard policy manipulation CORBA features (e.g. +<tt>PolicyManager</tt>, +<tt>PolicyCurrent</tt>), meaning that this policy can be set on a per-ORB, +per-thread or per-object basis.</li> - </LI> - <LI> - Implemented - <CODE>SecurityLevel2::PrincipalAuthenticator</CODE> support - for SSLIOP. In particular, a SSLIOP-specific - <CODE>SecurityReplaceable::Vault</CODE> implementation is now - available. - </LI> - <LI> - Initial SSLIOP-specific <CODE>Credentials</CODE> - implementation is complete. - </LI> - </UL> - </LI> -</UL> +<br> +<p> +<p>This policy makes it possible to, for example, make authenticated and +non-authenticated invocations within the same client process. +<li> +Implemented <tt>SecurityLevel2::PrincipalAuthenticator</tt> support for +SSLIOP. In particular, a SSLIOP-specific <tt>SecurityReplaceable::Vault</tt> +implementation is now available.</li> +<li> +Initial SSLIOP-specific <tt>Credentials</tt> implementation is complete.</li> +</ul> +</ul> Current Status: -<UL> - <LI> - Core <CODE>SecurityLevel2</CODE> interfaces such as - <CODE>Credentials</CODE>, <CODE>SecurityManager</CODE>, and - <CODE>PrincipalAuthenticator</CODE> are currently under - development. - </LI> - <LI> - Began implementation of the interfaces in the - <CODE>SecurityReplaceable</CODE> IDL module. They provide the - ability to replace key security components in the ORB with - another implementation with ease. Thus, the security - components in the ORB become highly extensible. - </LI> - -</UL> +<ul> +<li> +Core <tt>SecurityLevel2</tt> interfaces such as <tt>Credentials</tt>, <tt>SecurityManager</tt>, +and <tt>PrincipalAuthenticator</tt> are currently under development.</li> +<li> +Began implementation of the interfaces in the <tt>SecurityReplaceable</tt> +IDL module. They provide the ability to replace key security components +in the ORB with another implementation with ease. Thus, the security components +in the ORB become highly extensible.</li> +</ul> Schedule: -<UL> - - <LI> - <FONT COLOR=BLUE>October 2002</FONT><BR> - <UL> - <LI> - Begin implementation of the Common Secure Interoperability - version 2 (CSIv2) protocol/specification. Needed for more - advanced features, such as delegation. - </LI> - </UL> - </LI> +<ul> +<li> +<font color="#0000FF">October 2002</font></li> +<ul> +<li> +Begin implementation of the Common Secure Interoperability version 2 (CSIv2) +protocol/specification. Needed for more advanced features, such as delegation.</li> +</ul> <!-- <LI> <FONT COLOR=BLUE>November 2002</FONT> @@ -1876,61 +1741,49 @@ Schedule: </UL </LI> --> +<li> +<font color="#0000FF">November 2002</font></li> - <LI> - <FONT COLOR=BLUE>November 2002</FONT><BR> - <UL> - <LI> - Begin implementation of the <I>Authentication Token Layer - Attribute Service (ATLAS)</I> specification for TAO. - </LI> - </UL> - </LI> - - <LI> - <FONT COLOR=BLUE>December 2002</FONT><BR> - <UL> - <LI> - Begin implementation of the <I>Resource Access Decision (RAD) - Facility</I> specification for TAO. - </LI> - </UL> - </LI> - +<ul> +<li> +Begin implementation of the <i>Authentication Token Layer Attribute Service +(ATLAS)</i> specification for TAO.</li> +</ul> - <LI> - <FONT COLOR=BLUE>February 2003</FONT><BR> - <UL> - <LI> - Begin implementation of the <I>Security Domain Membership - Management (SDMM)</I> specification for TAO. - It is needed to support security domains. - </LI> - </UL> - </LI> +<li> +<font color="#0000FF">December 2002</font></li> - <LI> - <FONT COLOR=BLUE>April 2003</FONT><BR> - <UL> - <LI> - SSLIOP and SECIOP performance enhancements. - </LI> - </UL> - </LI> +<ul> +<li> +Begin implementation of the <i>Resource Access Decision (RAD) Facility</i> +specification for TAO.</li> +</ul> +<li> +<font color="#0000FF">February 2003</font></li> -</UL> +<ul> +<li> +Begin implementation of the <i>Security Domain Membership Management (SDMM)</i> +specification for TAO. It is needed to support security domains.</li> +</ul> -<!-- END: CORBA Security Service Release Notes --> +<li> +<font color="#0000FF">April 2003</font></li> -<!--#include virtual="ec.html" --> +<ul> +<li> +SSLIOP and SECIOP performance enhancements.</li> +</ul> +</ul> +<!-- END: CORBA Security Service Release Notes --><!--#include virtual="ec.html" --> <p> <hr> - <h3> <a NAME="scheduling"></a>TAO's Scheduling Service</h3> -Point of contact: <a href="mailto:cdgill@cs.wustl.edu">Chris Gill</a> -and <a href="mailto:levine@cs.wustl.edu">David Levine</a> +Point of contact: <a href="mailto:cdgill@cs.wustl.edu">Chris Gill</a> and +<a href="mailto:levine@cs.wustl.edu">David +Levine</a> <p>Currently Implemented Features: <ul> <li> @@ -1961,23 +1814,23 @@ Future work: Implement heap-based dispatching queues.</li> <li> -Add support for additional configurability, especially in the type -of dispatching strategy (list vs. heap) that will be used to dispatch operations -at a given static priority level.</li> +Add support for additional configurability, especially in the type of dispatching +strategy (list vs. heap) that will be used to dispatch operations at a +given static priority level.</li> <li> -Benchmark the various alternative strategies to obtain performance -profiles across different operation loads and OS platforms.</li> +Benchmark the various alternative strategies to obtain performance profiles +across different operation loads and OS platforms.</li> <li> Add increased functionality. Requests and suggestions are welcome.</li> </ul> <hr> - <h3> <a NAME="logging"></a>TAO's Logging Service</h3> -Point of contact: <a href="mailto:krish@cs.wustl.edu">Krishnakumar Elakkara Pathayapura</a> +Point of contact: <a href="mailto:krish@cs.wustl.edu">Krishnakumar Elakkara +Pathayapura</a> <p>Current status (Jan 23 2000): <ul> <li> @@ -1991,121 +1844,156 @@ Add persistence and then to add event notification</li> </ul> <hr> +<h3> +<a NAME="fault_tolerance"></a>TAO's support for FT services</h3> +Point of contact: <a href="mailto:bala@dre.vanderbilt.edu">Balachandran +Natarajan</a> +<h4> +Current Status:</h4> +TAO supports the ORB level requirements to achieve Fault Tolerance for +CORBA Objects. The details of the ORB level support is described in the +FT chapter of the +<a href="http://www.omg.org/cgi-bin/doc?formal/02-06-01">CORBA +3.0 specification</a>. Specifically TAO implements the sections 23.2.2, +23.2.3, 23.2.6 thru 23.2.8 of the document. +<h4> +Future Work:</h4> -<h3><a NAME="fault_tolerance"></a>TAO's support for FT services</h3> - -<p> -Point of contact: <a href="mailto:bala@dre.vanderbilt.edu">Balachandran Natarajan</a> - -<h4>Current Status:</h4> -<p>TAO supports the ORB level requirements to achieve Fault Tolerance -for CORBA Objects. The details of the ORB level support is described -in the FT chapter of the -<a href="http://www.omg.org/cgi-bin/doc?formal/02-06-01"> -CORBA 3.0 specification</a>. Specifically TAO implements the sections -23.2.2, 23.2.3, 23.2.6 thru 23.2.8 of the document. - -<h4>Future Work:</h4> <ul> -<li> Implement 23.2.9 of the document.</li> +<li> +Implement 23.2.9 of the document.</li> </ul> -<hr> - -<h3><a NAME="loadbalancer"></a>Load Balancer</h3> -<p> +<hr> +<h3> +<a NAME="loadbalancer"></a>Load Balancer</h3> Point of contact: <a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</a> - -<h4>Current Status:</h4> -<p>TAO's -<A HREF="http://www.cs.wustl.edu/~schmidt/PDF/load_balancing.pdf"> -Load Balancer</a> currently implements the latest revision of the -OMG <I>Load Balancing and Monitoring</I> proposed specification. -<p> -It provides many features and advantages over the previous prototype. +<h4> +Current Status:</h4> +TAO's +<a href="http://www.cs.wustl.edu/~schmidt/PDF/load_balancing.pdf">Load +Balancer</a> currently implements the latest revision of the OMG <i>Load +Balancing and Monitoring</i> proposed specification. +<p>It provides many features and advantages over the previous prototype. Those features and advantages include: <ul> - <li>Multiple object group support</li> - <li>Extensible load balancing strategies through IDL interfaces</li> - <li>Extensible load monitoring</li> - <li>Both "push" and "pull" style monitoring are supported</li> - <li>Support for infrastructure and application controlled object - group membership</li> - <li>Improved server-side transparency</li> -</ul> +<li> +Multiple object group support</li> + +<li> +Extensible load balancing strategies through IDL interfaces</li> -The current proposed <I>Load Balancing and Monitoring</I> -specification defines three built-in load balancing strategies. They -are: +<li> +Extensible load monitoring</li> + +<li> +Both "push" and "pull" style monitoring are supported</li> + +<li> +Support for infrastructure and application controlled object group membership</li> + +<li> +Improved server-side transparency</li> +</ul> +The current proposed <i>Load Balancing and Monitoring</i> specification +defines three built-in load balancing strategies. They are: <ol> - <li><CODE>RoundRobin</CODE> <FONT COLOR=BLUE>(non-adaptive)</FONT></li> - <li><CODE>Random</CODE> <FONT COLOR=BLUE>(non-adaptive)</FONT></li> - <li><CODE>LeastLoaded</CODE> <FONT COLOR=BLUE>(adaptive)</FONT></li> -</ol> +<li> +<tt>RoundRobin</tt> <font color="#0000FF">(non-adaptive)</font></li> +<li> +<tt>Random</tt> <font color="#0000FF">(non-adaptive)</font></li> + +<li> +<tt>LeastLoaded</tt> <font color="#0000FF">(adaptive)</font></li> +</ol> TAO implements all of these load balancing strategies. +<h4> +Known Issues:</h4> -<h4>Known Issues:</h4> <ul> -<li><em>Adaptive</em> load balancing is currently not working. In - particular, the load shedding mechanism needs work. -</li> +<li> +<i>Adaptive</i> load balancing is currently not working. In particular, +the load shedding mechanism needs work.</li> </ul> -<h4>Recent Work:</h4> +<h4> +Recent Work:</h4> + <ul> -<li>Implemented <CODE>RoundRobin</CODE> load balancing strategy.</li> -<li>Implemented <CODE>LeastLoaded</CODE> load balancing strategy.</li> -<li>Implemented preliminary infrastructure-controlled membership - support.<li> +<li> +Implemented <tt>RoundRobin</tt> load balancing strategy.</li> + +<li> +Implemented <tt>LeastLoaded</tt> load balancing strategy.</li> + +<li> +Implemented preliminary infrastructure-controlled membership support.</li> + +<li> +</li> </ul> -<h4>Future Work:</h4> +<h4> +Future Work:</h4> + <ul> -<li>Implement cooperative (distributed) load balancing support</li> -<li>Integrate multicast support</li> +<li> +Implement cooperative (distributed) load balancing support</li> + +<li> +Integrate multicast support</li> </ul> <hr> - -<h3><a NAME="miop"></a>Multicast InterORB Protocol (MIOP)</h3> - -<p> +<h3> +<a NAME="miop"></a>Multicast InterORB Protocol (MIOP)</h3> Point of contact: <a href="mailto:fhunleth@cs.wustl.edu">Frank Hunleth</a> +<h4> +Current Status:</h4> +The final <a href="http://www.omg.org/cgi-bin/doc?ptc/2001-11-08">MIOP +specification</a> has recently been adopted by the OMG. TAO's MIOP support +(located in $TAO_ROOT/orbsvcs/orbsvcs/PortableGroup) enables servants to +receive requests sent to multicast addresses. This is performed by creating +a GroupId that identifies the multicast group and associating it with one +or more servants. Additionally, the Unreliable IP Multicast (UIPMC) pluggable +protocol is used to send and receive multicast requests. Multicast endpoints +can be created dynamically at runtime. +<h4> +Known Issues:</h4> -<h4>Current Status:</h4> <p> The final <A -HREF="http://www.omg.org/cgi-bin/doc?ptc/2001-11-08"> MIOP -specification</A> has recently been adopted by the OMG. TAO's MIOP -support (located in $TAO_ROOT/orbsvcs/orbsvcs/PortableGroup) enables -servants to receive requests sent to multicast addresses. This is -performed by creating a GroupId that identifies the multicast group -and associating it with one or more servants. Additionally, the -Unreliable IP Multicast (UIPMC) pluggable protocol is used to send and -receive multicast requests. Multicast endpoints can be created -dynamically at runtime. - -<h4>Known Issues:</h4> <ul> -<li>MIOP packet reassembly is not performed yet, so the maximum - request size is limited to about 5-6kb depending on the platform.</li> +<li> +MIOP packet reassembly is not performed yet, so the maximum request size +is limited to about 5-6kb depending on the platform.</li> </ul> -<h4>Recent Work:</h4> +<h4> +Recent Work:</h4> + <ul> -<li>Initial check in of MIOP implementation.</li> +<li> +Initial check in of MIOP implementation.</li> </ul> -<h4>Future Work:</h4> +<h4> +Future Work:</h4> + <ul> -<li>Allow group references to be disassociated when no longer needed.</li> -<li>Implement MIOP packet reassembly.</li> -<li>Implement a Multicast Group Manager (MGM).</li> -<li>Implement a Multicast Gateway (MG).</li> -</ul> +<li> +Allow group references to be disassociated when no longer needed.</li> -<hr> +<li> +Implement MIOP packet reassembly.</li> +<li> +Implement a Multicast Group Manager (MGM).</li> +<li> +Implement a Multicast Gateway (MG).</li> +</ul> + +<hr> <h3> <a NAME="apps"></a>Test & Performance Tests</h3> Point of contact: <a href="mailto:naga@cs.wustl.edu">Nagarajan Surendran</a> @@ -2150,23 +2038,22 @@ Study the impacts of scheduling & concurrency strategies on performance.</li Evolve into a testbed for discovering sources of performance non-determinism & priority inversion.</li> </ul> - -<p>Pluggable: +Pluggable: <p>Current status: <p>The TAO Pluggable test utilizes ACE Timeprobes to time the latency at various points in the ORB, especially that incurred by the Pluggable Protocols -implementation. Comparisons can be made not only between different layers of the -ORB, but also between different protocols as they become available. +implementation. Comparisons can be made not only between different layers +of the ORB, but also between different protocols as they become available. <p>Future work: <ul> <li> Add options to redirect the output to a file.</li> + <li> Script or otherwise automate the piping of the output to a spreadsheet.</li> </ul> <hr> - <h3> <a NAME="ace"></a>ORB-related ACE Changes</h3> Points of contact: <a href="mailto:nanbor@cs.wustl.edu">Nanbor Wang</a> @@ -2268,9 +2155,9 @@ Enhancing MIB functionality</li> <li> Monitoring the AV Streaming Service</li> </ul> -For more information on the DOVE demo, please refer to: $TAO_ROOT/orbsvcs/tests/Simulator/README.<P> +For more information on the DOVE demo, please refer to: $TAO_ROOT/orbsvcs/tests/Simulator/README. +<p> <hr> - <h3> <a NAME="forwarding"></a>Location Forwarding</h3> Point of contact: <a href="mailto:irfan@cs.wustl.edu">Irfan Pyarali</a>, @@ -2279,7 +2166,6 @@ Kircher</a>. <p>For more information see <a href="../forwarding.html">Location forwarding</a> <p> <hr> - <h3> <a NAME="leader"></a>Global Resources and Leader-Follower Model</h3> Point of contact: <a href="mailto:irfan@cs.wustl.edu">Irfan Pyarali</a>, @@ -2289,7 +2175,6 @@ Kircher</a>. model</a> <p> <hr> - <h3> <a NAME="locate"></a>Implementation of locate request</h3> Point of contact: <a href="mailto:irfan@cs.wustl.edu">Irfan Pyarali</a>, @@ -2298,117 +2183,117 @@ Kircher</a>. <p>For more information see <a href="../locate_request.html">Locate request</a> <p> <hr> - <h3> <a NAME="ami"></a>Asynchronous Method Invocation</h3> Points of contact: <a href="mailto:alex@cs.wustl.edu">Alexander Arulanthu</a> -, <a href="mailto:Michael.Kircher@mchp.siemens.de">Michael Kircher</a> and +, <a href="mailto:Michael.Kircher@mchp.siemens.de">Michael Kircher</a> +and <a href="mailto:coryan@uci.edu">Carlos O'Ryan</a> <p>Status: +<ul>We've implemented the callback model of the +<a href="http://www.omg.org/cgi-bin/doc?formal/01-12-60">CORBA +Messaging specification</a>. To activate the AMI for TAO and the TAO IDL +compiler define <tt>TAO_HAS_CORBA_MESSAGING</tt>>, +<tt>TAO_HAS_AMI_CALLBACK</tt> +in your config.h file. The TAO IDL compiler can generate the AMI "callback" +stubs, ReplyHandler und reply stubs using the <tt>-GC</tt> switch. +<p>For an example see <tt>$TAO_ROOT/tests/AMI</tt> and <tt>$TAO_ROOT/examples/AMI</tt>.</ul> +Finished work: <ul> +<li> +Redesign of the IDL compiler to make an addtional pass over the AbstractSyntaxTree +and generate the implied-IDL code in memory. This reduced the amount of +AMI specific IDL compiler code dramatically.</li> -We've implemented the callback model of the -<A HREF="http://www.omg.org/cgi-bin/doc?formal/01-12-60">CORBA Messaging -specification</a>. To activate the AMI for TAO and the TAO IDL -compiler define <CODE>TAO_HAS_CORBA_MESSAGING</CODE>>, -<tt>TAO_HAS_AMI_CALLBACK</tt> in your config.h file. The TAO IDL -compiler can generate the AMI "callback" stubs, ReplyHandler und reply -stubs using the <CODE>-GC</CODE> switch. -<p> -For an example see <tt>$TAO_ROOT/tests/AMI</tt> and <tt>$TAO_ROOT/examples/AMI</tt>. +<li> +Support for exceptions</li> -</ul> +<li> +Support for attributes</li> -<p> Finished work: -<ul> -<li> Redesign of the IDL compiler to make an addtional pass over -the AbstractSyntaxTree and generate the implied-IDL code in memory. -This reduced the amount of AMI specific IDL compiler code dramatically.</li> -<li>Support for exceptions</li> -<li>Support for attributes</li> -<li>Support for buffering and batching AMI calls. See <a -href="../../examples/Buffered_AMI">Buffered AMI</a> example for -details.</li> -<li>Support for deferred synchronous invocations. -<a href="mailto:j.parsons@vanderbilt.edu">Jeff Parsons</a></li> -<li>Support for timeouts in combination with AMI calls, response handler gets +<li> +Support for buffering and batching AMI calls. See <a href="../../examples/Buffered_AMI">Buffered +AMI</a> example for details.</li> + +<li> +Support for deferred synchronous invocations. +<a href="mailto:j.parsons@vanderbilt.edu">Jeff +Parsons</a></li> + +<li> +Support for timeouts in combination with AMI calls, response handler gets CORBA::TIMEOUT exception on timeout</li> </ul> -<p> Future Work: +Future Work: <ul> -<li>Implementation of the poller model.</li> +<li> +Implementation of the poller model.</li> </ul> -<p> -<hr> -<h3> <a NAME="interceptor"></a>Portable Interceptors</h3> +<hr> +<h3> +<a NAME="interceptor"></a>Portable Interceptors</h3> Point of contact: <a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</a>. -<p>For more information see <a href="../interceptors.html">Portable -Interceptors</a> -</p> +<p>For more information see <a href="../interceptors.html">Portable Interceptors</a> +<br> <hr> - -<h3><a name="localobject"></a>Local Interfaces</h3> - -<p>Point of contact: <a href="mailto:nanbor@cs.wustl.edu">Nanbor -Wang</a>.</p> - -<p>Local interfaces are first defined in the CORBA Component Model -specification. For more information on using the local interfaces, -please refers to Section 11.1.1 to 11.1.4 of the -<a href="http://www.omg.org/cgi-bin/doc?orbos/99-07-01/">spec</a> and -our short <a href="../LocalObject.html">guideline</a> on implementing -local objects.</p> - -<HR><P> -<h3><a NAME="CORBA-conformance">CORBA Standards Conformance</a></h3> - -Here is a summary of TAO's conformance issues with CORBA latest CORBA -specifications (updated 9 August 2000):<br> - -2.3.1 and 2.3 differ in very little, if at all, check:<br> -<a href="ftp://ftp.omg.org/pub/docs/formal/99-10-07.pdf">ftp://ftp.omg.org/pub/docs/formal/99-10-07.pdf</a><br> - and search for the change bars, meanwhile this can help: +<h3> +<a NAME="localobject"></a>Local Interfaces</h3> +Point of contact: <a href="mailto:nanbor@cs.wustl.edu">Nanbor Wang</a>. +<p>Local interfaces are first defined in the CORBA Component Model specification. +For more information on using the local interfaces, please refers to Section +11.1.1 to 11.1.4 of the +<a href="http://www.omg.org/cgi-bin/doc?orbos/99-07-01/">spec</a> +and our short <a href="../LocalObject.html">guideline</a> on implementing +local objects. +<br> +<hr> +<h3> +<a NAME="CORBA-conformance"></a>CORBA Standards Conformance</h3> +Here is a summary of TAO's conformance issues with CORBA latest CORBA specifications +(updated 9 August 2000): +<br>2.3.1 and 2.3 differ in very little, if at all, check: +<br><a href="ftp://ftp.omg.org/pub/docs/formal/99-10-07.pdf">ftp://ftp.omg.org/pub/docs/formal/99-10-07.pdf</a> +<br>and search for the change bars, meanwhile this can help: <ul> +<li> +The full OBV (valueboxes, valuetypes in all sorts of things, value graphs, +Anys and value types, abstract interfaces, etc. etc.)</li> - <li>The full OBV (valueboxes, valuetypes in all sorts of things, value - graphs, Anys and value types, abstract interfaces, etc. etc.) - - <li>The IfR database cannot be populated (so it is less than fully - operational ;-)) +<li> +The IfR database cannot be populated (so it is less than fully operational +;-))</li> - <li>Fixed data types (who cares) +<li> +Fixed data types (who cares)</li> - <li>GIOP fragments (1.1 and 1.2) are not completely tested. +<li> +GIOP fragments (1.1 and 1.2) are not completely tested.</li> - <li>The old ServantManager interfaces (POA stuff) +<li> +The old ServantManager interfaces (POA stuff)</li> - <li>Domain Managers (useful for security, but otherwise nobody seems to - care) +<li> +Domain Managers (useful for security, but otherwise nobody seems to care)</li> - <li>I think our interpretation of codesets is compliant (we only - support one codeset), but would have to check. +<li> +I think our interpretation of codesets is compliant (we only support one +codeset), but would have to check.</li> </ul> - - -<p>Future Work (aka. known problems):</p> +Future Work (aka. known problems): <ul> - <li>Supposedly, any constructed types that contains local types - become local automatically. TAO_IDL currently doesn't handle - the array type very well if one is defined outside the scope of - a local interface.</li> - <li>Need to test local object support more systematically and - comprehensively. (Does TAO throw a MARSHAL exception when trying - to marshal a local type?) +<li> +Supposedly, any constructed types that contains local types become local +automatically. TAO_IDL currently doesn't handle the array type very well +if one is defined outside the scope of a local interface.</li> + +<li> +Need to test local object support more systematically and comprehensively. +(Does TAO throw a MARSHAL exception when trying to marshal a local type?)</li> </ul> -<hr> +<hr> <p>Back to the TAO <a href="../index.html">documentation index</a>.<!--#include virtual="/~schmidt/cgi-sig.html" --> - - <hr> -<!-- hhmts start --> -Last modified: Mon Aug 25 12:30:29 PDT 2003 -<!-- hhmts end --> - +<hr><!-- hhmts start -->Last modified: Mon Aug 25 12:30:29 PDT 2003<!-- hhmts end --> </body> </html> diff --git a/TAO/docs/releasenotes/rtc10_sched.html b/TAO/docs/releasenotes/rtc10_sched.html new file mode 100644 index 00000000000..669d895d5f7 --- /dev/null +++ b/TAO/docs/releasenotes/rtc10_sched.html @@ -0,0 +1,293 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<!-- $Id$ --> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="Author" content="Venkita Subramonian"> + <meta name="GENERATOR" content="Mozilla/4.79 [en] (Windows NT 5.0; U) [Netscape]"> + <title>RTCORBA 1.0 Scheduling Service</title> +</head> +<body> + +<center> +<h2> +RTCORBA 1.0 Scheduling Service</h2></center> + +<p><br>Matt Murphy <murphym@cs.uri.edu> +<br>University of Rhode Island +<p>This is an implementation of the RTCORBA 1.0 Scheduling Service. Per +section 3 of the RTCORBA 1.0 specification (OMG), the scheduling service +is comprised of two local interfaces, a ClientScheduler and a ServerScheduler. +<br> +<h3> +Build Issues:</h3> +Run tao_idl -I $TAO_ROOT/ RTCosScheduling.pidl. Some versions of TAO incorrectly +include the line #include "tao/PortableServer/PortableServerS.h" +<br>in RTCosSchedulingS.h when making the IDL. Before running make +on your program, please check if this line was included in RTCosSchedulingS.h, +and if so, comment it out. Run make -f Makefile.RTCosScheduling from ../ +<br> +<h3> +Synopsis:</h3> +The RTCosScheduler allows clients to schedule tasks according to scheduling +information determined a priori. This scheduling information is stored +in a config file so that both the client and the server has access to it. +(If the client and server exists on different nodes then place a copy of +the config file on each node.) +<p>Per the RTCORBA 1.0 spec, clients use a ClientScheduler object and servers +use a ServerScheduler object to schedule activities on the system. +Since each may or may not use its scheduler, there are four possible scenarios +in which the system may run. These are: +<p>1. Client uses ClientScheduler, Server uses ServerScheduler. In +this case the system follows the rules set forth in the "Scheduling Service" +section of this document below. +<p>2. Client uses ClientScheduler, Server does not use ServerScheduler. +In this case activities are scheduled on the client and run at the mapped +Real Time priority set forth in the config file while executing on +the client. However, any activity on the server does not run at a +real time priority. This means that Multiprocessor Priority Ceiling +Protocol does not manage activities on the server. Currently, the +client has no way of knowing that activity on the server did not follow +the MPCP protocol. Future enhancements to the RTCORBA 1.0 scheduling +service should notify the client (perhaps through a flag to a client interceptor) +that the server did not use MPCP. Please note that this +scenario is generally not recommended as there is a strong possibility +for priority inversion or unexpected blocking in this situation since +any and all server activity that uses the ServerScheduler will run +at a higher priority that server activity that does not. Use +scenario 1 above. Here, the server's priority lowers from RTCORBA::maxPriority +to RTCORBA::minPriority and things will execute on a best effort +basis. +<p>3. Client does not use ClientScheduler, Server uses ServerScheduler. +In this case the client does not use priorities set forth in the config +file. The ServerScheduler, on the other hand, does use MPCP to schedule +execution on the server. It uses the priority sent to the server +by the client, which is the default priority that the +<br> client ran at (since the client priority was not changed +by schedule_activity(). This follows the scenario of the ServerScheduler +set forth below. Please note that it is recommended +that you use +scenario 1, above, instead so that the client sends appropriate priorities +to the server. +<p>4. Client does not use ClientScheduler, server does not use ServerScheduler. +In this case neither the client nor the server take advantage of +the RTCORBA 1.0 Scheduler. +<br> +<h3> +Scheduling Service:</h3> +ClientScheduler: +<br>Clients wishing to use the ClientScheduler to schedule activities +<br>must first create a local ClientScheduler object reference. The +<br>ClientScheduler is declared as: +<p>RTCosScheduling_ClientScheduler_i ( +<br> CORBA::ORB_var orb, /// Orb reference +<br> char* node, +/// Node the client resides on +<br> char* file); +/// Config file holding scheduling information +<br> +<p>The ClientScheduler constructor parses the config file and populates +an ACE_MAP with the activity/priority associations for the node on which +the client resides. It also constructs a ClientScheduler_Interceptor +that adds a service context the send_request interceptor that contains +the priority the client is running at when the call is made. +<p>Once initialized, calls to the ClientScheduler schedule_activity(const +char * activity_name) method will match the activity_name parameter to +the CORBA priority value in the ACE_Map. It linearly maps CORBA priority +to a local OS priority and sets the local OS priority using RT Current. +If the activity name provided is not valid (i.e. not found in the config +file), a RTCosScheduling::UnknownName exception is thrown. +<p>The ClientScheduler also registers an client side interceptor with the +orb. This ClientScheduler_Interceptor finds the CORBA priority that +the client is running at when the remote method call is made and adds this +priority to a service context for the ServerScheduler_Interceptor to use. +Initial tests find that this interceptor adds 0.00015 seconds of execution +on an Intel 3.0 GHz processor. +<br> +<h3> +ServerScheduler:</h3> +Servers that contain local objects that will accept CORBA calls must create +a local ServerScheduler object. The ServerScheduler uses TAO's PortableInterceptors +to intercept incoming client requests and schedule execution on the server. +These interceptors are registered by the ORB_Core as explained in the create_POA +method below. The ServerScheduler is defined as: +<p> RTCosScheduling_ServerScheduler_i ( +<br> char *node, /// Node the ServerScheduler +resides on +<br> char *file, /// Config file holding +scheduling information +<br> char *shared_file, /// File used for shared +memory +<br> int numthreads); /// Number of threads +to create in the threadpool +<p>During initialization, the ServerScheduler finds the appropriate node +information in the config file and stores resources (key) on the node and +the appropriate priority ceiling (value) in a map. It also reads +in the base priority for the resource. +<p>The ServerScheduler constructor then registers the PortableInterceptors +necessary to scheduler execution on the server. It also set up the +linear mapping policy and a reference to the RT Current object, both of +which are used for adjusting the server's local OS priority when using +the priority ceiling control protocol. +<p>Once the ServerScheduler object is constructed, users may create an +orb and establish any non real time POA policies they wish to install by +calling the ServerScheduler's create_POA method. +<p>ServerScheduler's create_POA method creates a real time POA that will +set and enforce all non-real time policies. This method also sets +the real time POA to enforce the Server Declared Priority Model Policy +and creates a threadpool responsible for executing calls to the server. +Server Declared Priority Model is used so that the server threads may run +at a high enough priority to intercept requests as soon as they come in. +If Client Propagated Priority Ceilings were used, incoming requests would +not be intercepted until all existing servant execution is completed. +This is because MPCP elevates the priority of servant execution to be higher +than the client priorities. +<p>Recall that the number of threads in the threadpool was supplied by +the ServerScheduler constructor. The create_POA method is defined +as: +<p> virtual ::PortableServer::POA_ptr create_POA ( +<br> PortableServer::POA_ptr parent, +/// Non RT POA parent +<br> const char * adapter_name, /// +Name for the POA +<br> PortableServer::POAManager_ptr a_POAManager, +/// Manager for the POA +<br> const CORBA::PolicyList & policies /// +List of non RT policies +<br> ACE_ENV_ARG_DECL) +<br> ACE_THROW_SPEC (( +<br> CORBA::SystemException +<br> , PortableServer::POA::AdapterAlreadyExists +<br> , PortableServer::POA::InvalidPolicy +<br> )); +<br> +<p>Once a RT POA has been created, schedule_object is called to store CORBA +Object references (key) with a name (value) in an ACE_MAP. An +<br>RTCosScheduling::UnknownName exception is thrown if the schedule_object +name parameter is not found in the resource map (i.e. it was not in the +<br>config file.) The schedule_object method is declared as: +<p> virtual void schedule_object ( +<br> CORBA::Object_ptr obj, /// A CORBA object +reference +<br> const char * name /// Name to +associate with obj +<br> ACE_ENV_ARG_DECL) +<br> ACE_THROW_SPEC (( +<br> CORBA::SystemException +<br> , RTCosScheduling::UnknownName +<br> )); +<br> +<p>Once all objects that will receive client requests have been scheduled +using schedule_object, clients are free to make calls on those objects. +The scheduling service interceptors catch these calls and perform the necessary +priority ceiling control measures to ensure that the calls are executed +in the appropriate order. The ServerScheduler_Interceptor receive_request +method intercepts all incoming request immediately since it is set to run +at RTCORBA::maxPriority (the highest priority on the server OS). +It then gets the client priority sent in the service context as well as +the resource ceiling for the object and the base priority for the server. +<br>Initial tests indicate that the receive_request interceptor takes around +0.002 seconds to complete on an Intel 3.0 GHz processor. +<p>Given these values it is able to use the Multiprocessor Priority Ceiling +Protocol to schedule execution on the server to handle the request. +MPCP schedules all global critical sections at a higher priority than tasks +on the local processor by adding the client priority to the base priority +of the servant, then adding the resource ceiling of the resource to the +base priority to find the appropriate priority ceiling. For more information +about MPCP, please refer to the book "Real Time Systems", By Jane Liu (2000). +<p>Please not that the locking mechanisms are stored in shared memory on +the server. This means that the locks cannot be stored in linked +lists and are therefore manipulated using memory offsets. The total +number of locks that may be stored in shared memory is currently set at +1024. +<p>When remote execution is complete the send_reply interceptor resets +the thread to listen at RTCORBA::maxPriority and removes the task form +the Invocation +<br>list. Initial test indicate that the send_reply interceptor takes +0.000075 seconds to complete on an Intel 3.0 GHz processor. +<br> +<h3> +Scheduling Service Config File:</h3> +The scheduling service config file holds the information necessary to schedule +the system. Task and resource ceiling information is stored for each +of the nodes as follows: +<p>Node 1 /// The node name is 1 +<p>Resources: +<br>BP 6000 /// The base priority for +the resource +<br>Server1 1000 /// A list of resources and their priority +ceiling +<br>Server2 2000 +<br>END /// The end of the resource list +<p>Tasks: /// A list of tasks that will execute on the +node +<br>Client1 1000 +<br>Client2 3000 +<br>Client3 5000 +<br>END /// The end of the task list. +<p>Please note that these associations are tab delimited. Please +do not include comments in the scheduling service config file. The +priorities associated +<br>with each task and resource are considered to be CORBA priorities, +and will be mapped to local OS level priorities using the Linear Mapping +<br>model. Per the OMG RT CORBA spec, CORBA priorities have a valid +range up to 32767, where a larger value indicates a higher priority. +The current +<br>config file assumes that the Multiprocessor Priority Ceiling Protocol +is used. +<br> +<h3> +Known Issues:</h3> +TAO does not currently support request buffering, and there are no immediate +plans to do so. Consequently, the RT CORBA 1.0 Scheduling Service +is +<br>limited in that it will only function properly in systems that do not +require request buffering on the servant side. +<p>There is a bug in TAO in which mapped priorities are mapped a second +time when using Client Propagated Priority Ceiling Protocol. This +in effect +<br>lowers the priority that the servant receives. This happens to +each priority, so there should be no effect on the system. +<p>The config file assumes CORBA priorities in the range of 0 to 32767. +The Linear Priority Mapping Manager will map these to valid local OS priorities. +Take care though, in determining the priority range in the config file, +as low numbers or numbers very close in value may produce priority inversion +and other issues. For example, if the CORBA priorities used for three +tasks are 100 200 300, these will all map to OS priority 1 in on some real +time Linux systems. Please take this into +<br>account when determining the CORBA priority range to use. +<p>The 1.0 Scheduling service currently works with one orb and one POA. +If someone tries to install more than one scheduling service (client or +server side) on a single POA, then it should not add a second interceptor. +Please use a single scheduling service per POA. Furthermore, there +is a bug when more than one orb is created, an invalid policy exception +is thrown during the second call to create_POA. This bug is actively +being investigated. In the meantime please use the scheduling service +with one ORB. +<br> +<h3> +Future Enhancements:</h3> +ACE_XML +<br>The current RT CORBA 1.0 Scheduling Service uses a private method to +read the config file. This will soon be replaced with a new XML based +config +<br>file using ACE_XML to parse the config file. +<p>Priority Lanes +<br>Although not currently implemented, Priority Lanes and Thread Borrowing +may increase performance as they would help to prevent lower priority tasks +from exhausting all threads. This is considered a possible future +enhancement. +<p>Client Interceptor +<br>A client interceptor that sends a flag to notify the server interceptor +if schedule_activity() was used to set the client priority. If schedule_activity() +was not used, then the server should probably not try and schedule server +execution using MPCP. Doing so adds competition to other method calls +by other client requests that were scheduled with schedule_activity(). +<br> +<h3> +References</h3> +The Object Management Group, Real Time CORBA 1.0 Specification, www.omg.org +<br>Liu, Jane, Real Time Systems, Prentice Hall, 2000 +<br> +</body> +</html> diff --git a/TAO/orbsvcs/FTRT_Event_Service/Readme b/TAO/orbsvcs/FTRT_Event_Service/Readme deleted file mode 100644 index 016c80c530c..00000000000 --- a/TAO/orbsvcs/FTRT_Event_Service/Readme +++ /dev/null @@ -1,192 +0,0 @@ -// $Id$ - - -Fault Tolerant Real-time Event Service -========================================================================================== - -Introduction --------------- - -The Fault Tolerant Real-time Event Service provides the fault tolerant capability to the -TAO Real-time Event Service. Essentially, it allows you to start several event services -in different machines. These event services form an object group which can be treated as -a logical event service by clients. The clients only communicate with the primary (leader) of -the object group. The rest event channels in the object group are called backups. Once the primary -dies, one of the backups will assume the reponsibility of primary and this process is transparent -to the clients. - -The key to provide fault tolerance to event channels is to replicate the states of primary to its -backups. There are two kinds of states in the event channels, transient and persistent. A transient -state in the event channels is the events which are yet to be delivered to the consumers. Those events -are hard to replicate because the time scale is too small. They might be delivered late or out of -scope if we tried to replicate the events. However, the subscription information occurs at a suitable -time scale for replication, and is in fact more essential for the delivery of events since it establishes -a kind of connectivity from suppliers to consumers. Therefore, we only replicate the subscriptions - -Once the primary receives the subscription requests from the clients, it -will replicate the requests to the backup event channels.In order to provide time bounds on replication, -we introduce the concept of transaction depth. If we say the transaction depth is n, that means a -subscription method invocation has to be blocked until the first n replicas complete the subscription -operation, illustrated by the assured-replicate arc in the figure. Other replicas can get the state -change via a so called soft-replicate which conceptually means the replication is not assured to -complete before the subscription operation returns. So, if the soft-replicate fails due to loss -of the primary, we will have only the assured depth of replication. The clients are allowed to configure -the transaction depth to tradeoff reliability and responsiveness. Furthermore, it is necessary to -roll back an operation in some replicas if the transaction depth can not be met. In addition, -we can use either two-way or AMI calls for assured-replication and one-way operations for soft-replication. - - -Important Note : In current stage, the Fault Tolerant Event Service can only be made under - MPC build. The conventional makefiles are yet to be supported. - - -Programs -------------- -This directory contains the following programs: - - ftrt_eventservice : Implements the functionality of fault tolerant event channel. - It can be started directly or be started by the ft_factory. - - ftrtec_factory_service : A program used to spawn the ftrt_eventservice process. The process it - create can be controled through "test.cfg" whose contents should begin with the - repository id of EventChannel followed by the executable path of - ftrt_eventservice. - - ftrtec_gateway_service : An intermediator program between the ftrt_eventservice and the clients which do not support FT CORBA. - - consumer : A shell script to start the consumer test program. The actual consumer pragram is in orbsvcs/tests/FtRtEvent. - - supplier : A shell script to start the supplier test program. The actual supplier pragram is in orbsvcs/tests/FtRtEvent. - - ftec : a shell script to start ftrt_eventservice. - - -Quick start: -------------- - - Run the applications as follows: - - - 1. Start Naming_Service - $ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -m 1 - or you can use the shell script NameService in this directory to start it. - - 2. Start the ftrt_eventservice. Use the "-p" option to start it as a primary and - use the "-j" option to start it as a backup. - - $ ./ftec -p - $ ./ftec -j - $ ./ftec -j - - - 3. Start the consumer and supplier. - $ ./consumer - $ ./supplier - -How do we add a new FTRTEC to the system? ---------------------------------------------- - Just use - - ./ftec -j - - The newly created process will contact to the naming service and then join to - the existing object group. - -Is there any adjustable options for FTRTEC? - - Here is the list of options for the ftec script - - -sciop Use SCIOP for CORBA communication - -sctp Use SCTP for fault detection - -hb n Specify the heart beat interval in sec - for SCTP connection, this option also activate sctp option. - -ami Use AMI call for replication messages (The default is - two-way CORBA call for replication) - -p activate as a primary replica. - -j activate as a backup replica. - - - Below are some options that are used for the consumer and supplier - test scripts. - - -sciop Use SCIOP for CORBA communication. This requires that the Naming - Service and ftec are also started using SCIOP transport protocol. - - -d n Specify the transaction depth. The transaction depth indicates the - number of replicas that must complete the subscription request before - the request can return. - - -t f.f For supplier only. Specify the time interval between event sending - in seconds, this value should be a float point. - - If you the naming service are not running at the same machine with above programs, - you can always set the environmental variables NameServiceIOR before starting the - ftec, consumer or supplier. - - - How do I start the FTRTEC using ftrtec_factory_service? ---------------------------------------------------------------- - The ftrtec_factory_service is a small program that can instaniate a ftrt_eventservice on demand. - It exports the FT::GenericFactory interface to its client. There are two ways that - you can get the IOR for the factory object. 1) specify the name you want the factory - register to the naming service and then get the IOR from the naming service by - the name. 2) output the IOR to a file when the factory starts. Here are the options - - ftrtec_factory_service : - - -i id_string The id field of the name that is used to register to the naming service - -k kind_string The kind field of the name that is used to register to the naming service - -o output_filename The output file name for the factory IOR. - -Once you get the IOR for the factory, you can use create_object to intantiate the ftrt_eventservice. -Here are the parameters in create_object() to control how ftrt_eventservice is created. - - type_id : this value should be "IDL:FtRtecEventChannelAdmin/EventChannel:1.0" - the_criteria : the_criteria is a sequence of Property which in term consists of - "nam" and "value". Below a a list of possible nam and values. - - nam value - ========================================================================== - FTEC_MEMBERSHIP PRIMARY - BACKUP - NONE - ---------------------------------------------------------------------- - FTEC_DETECTOR_TRANSPORT_PROTOCL TCP - SCTP - ----------------------------------------------------------------------- - FTEC_HEART_BEAT the heart beat value in sec. - (Note, you have to specify it using string, i.e. - the_criteria[0].value <<= "5"); - --------------------------------------------------------------------------------- - FTEC_REPLICATION_STRATEGY AMI - - (If not specified, the ftrt_eventservice use default - two-way call for replication) - ---------------------------------------------------------------------------------- - NameServieIOR the corbaloc representation for the - naming service - ======================================================================================= - - Any nam string started with "-" will be used as a command line option to start ftrt_eventservice. - For example, if you specfiy the name as "-ORBEndpoint" and value as "sciop://" then the - ftrt_eventservice can be started using sciop. - -How do I use the ftrtec_gateway_service program ? ------------------------------------------------------ - The FTRTEC uses some features in FT CORBA that requires every client to use FT ORB to work. If your - client is written based other ORBs other than TAO. You cannot get the desired fault tolerance feature. - In this case you can have the ftec_gateway as an intermediator between the FTRTEC and you client program. - For example, if you have an existing client called my_supplier. - - # setting up the event channel group as previously stated. - - $ftrtec_gateway_service -o gateway.ior ## start the gateway and output the IOR of the gateway to a file - $my_supplier -i file://gateway.ior ## start the supplier using the gateway - - - - - - - - diff --git a/TAO/orbsvcs/orbsvcs/RTCosScheduling/README b/TAO/orbsvcs/orbsvcs/RTCosScheduling/README deleted file mode 100644 index 6f0261edead..00000000000 --- a/TAO/orbsvcs/orbsvcs/RTCosScheduling/README +++ /dev/null @@ -1,301 +0,0 @@ -README,v 1.0 2003/08/21 - -RTCORBA 1.0 Scheduling Service. - -Matt Murphy <murphym@cs.uri.edu> -University of Rhode Island - -This is an implementation of the RTCORBA 1.0 Scheduling Service. -Per section 3 of the RTCORBA 1.0 specification (OMG), the scheduling -service is comprised of two local interfaces, a ClientScheduler and -a ServerScheduler. - - -Build Issues: ---------- -Run tao_idl -I $TAO_ROOT/ RTCosScheduling.pidl -Some versions of TAO incorrectly include the line -#include "tao/PortableServer/PortableServerS.h" -in RTCosSchedulingS.h when making the IDL. Before running -make on your program, please check if this line was included in -RTCosSchedulingS.h, and if so, comment it out. -Run make -f Makefile.RTCosScheduling from ../ - - - -Synopsis: ---------- -The RTCosScheduler allows clients to schedule tasks according to -scheduling information determined a priori. This scheduling information -is stored in a config file so that both the client and the server has -access to it. (If the client and server exists on different nodes then -place a copy of the config file on each node.) - -Per the RTCORBA 1.0 spec, clients use a ClientScheduler object and -servers use a ServerScheduler object to schedule activities on the -system. Since each may or may not use its scheduler, there are four -possible scenarios in which the system may run. These are: - -1. Client uses ClientScheduler, Server uses ServerScheduler. - In this case the system follows the rules set forth in the - "Scheduling Service" section of this document below. - -2. Client uses ClientScheduler, Server does not use ServerScheduler. - In this case activities are scheduled on the client - and run at the mapped Real Time priority set forth in the config - file while executing on the client. However, any activity on the - server does not run at a real time priority. This means that - Multiprocessor Priority Ceiling Protocol does not manage activities - on the server. Currently, the client has no way of knowing that - activity on the server did not follow the MPCP protocol. Future - enhancements to the RTCORBA 1.0 scheduling service should notify - the client (perhaps through a flag to a client interceptor) that - the server did not use MPCP. Please note that this scenario is generally - not recommended as there is a strong possibility for - priority inversion or unexpected blocking in this situation - since any and all server activity that uses the ServerScheduler - will run at a higher priority that server activity that does not. - Use scenario 1 above. Here, the server's priority lowers from - RTCORBA::maxPriority to RTCORBA::minPriority and things will - execute on a best effort basis. - -3. Client does not use ClientScheduler, Server uses ServerScheduler. - In this case the client does not use priorities set forth in the - config file. The ServerScheduler, on the other hand, does use - MPCP to schedule execution on the server. It uses the priority sent - to the server by the client, which is the default priority that the - client ran at (since the client priority was not changed by - schedule_activity(). This follows the scenario of the ServerScheduler - set forth below. Please note that it is recommended that you use - scenario 1, above, instead so that the client sends appropriate priorities - to the server. - -4. Client does not use ClientScheduler, server does not use - ServerScheduler. - In this case neither the client nor the server take advantage of - the RTCORBA 1.0 Scheduler. - - - -Scheduling Service: ------------------- -ClientScheduler: -Clients wishing to use the ClientScheduler to schedule activities -must first create a local ClientScheduler object reference. The -ClientScheduler is declared as: - -RTCosScheduling_ClientScheduler_i ( - CORBA::ORB_var orb, /// Orb reference - char* node, /// Node the client resides on - char* file); /// Config file holding scheduling information - - -The ClientScheduler constructor parses the config file and populates -an ACE_MAP with the activity/priority associations for the node on -which the client resides. It also constructs a ClientScheduler_Interceptor -that adds a service context the send_request interceptor that contains -the priority the client is running at when the call is made. - -Once initialized, calls to the ClientScheduler schedule_activity( -const char * activity_name) method will match the activity_name -parameter to the CORBA priority value in the ACE_Map. It linearly -maps CORBA priority to a local OS priority and sets the local OS -priority using RT Current. If the activity name provided is not -valid (i.e. not found in the config file), a -RTCosScheduling::UnknownName exception is thrown. - -The ClientScheduler also registers an client side interceptor with the -orb. This ClientScheduler_Interceptor finds the CORBA priority that the -client is running at when the remote method call is made and adds this priority -to a service context for the ServerScheduler_Interceptor to use. Initial -tests find that this interceptor adds 0.00015 seconds of execution on an -Intel 3.0 GHz processor. - - -ServerScheduler: -Servers that contain local objects that will accept CORBA calls must -create a local ServerScheduler object. The ServerScheduler uses -TAO's PortableInterceptors to intercept incoming client requests and -schedule execution on the server. These interceptors are registered -by the ORB_Core as explained in the create_POA method below. -The ServerScheduler is defined as: - - RTCosScheduling_ServerScheduler_i ( - char *node, /// Node the ServerScheduler resides on - char *file, /// Config file holding scheduling information - char *shared_file, /// File used for shared memory - int numthreads); /// Number of threads to create in the threadpool - -During initialization, the ServerScheduler finds the appropriate node -information in the config file and stores resources (key) on the node -and the appropriate priority ceiling (value) in a map. It also reads -in the base priority for the resource. - -The ServerScheduler constructor then registers the PortableInterceptors -necessary to scheduler execution on the server. It also set up the -linear mapping policy and a reference to the RT Current object, both -of which are used for adjusting the server's local OS priority when -using the priority ceiling control protocol. - -Once the ServerScheduler object is constructed, users may create an -orb and establish any non real time POA policies they wish to install by -calling the ServerScheduler's create_POA method. - -ServerScheduler's create_POA method creates a real time POA that will -set and enforce all non-real time policies. This method also sets the -real time POA to enforce the Server Declared Priority Model Policy and -creates a threadpool responsible for executing calls to the server. -Server Declared Priority Model is used so that the server threads may run at -a high enough priority to intercept requests as soon as they come in. -If Client Propagated Priority Ceilings were used, incoming requests would not -be intercepted until all existing servant execution is completed. This is -because MPCP elevates the priority of servant execution to be higher than -the client priorities. - -Recall that the number of threads in the threadpool was supplied by the -ServerScheduler constructor. The create_POA method is defined as: - - virtual ::PortableServer::POA_ptr create_POA ( - PortableServer::POA_ptr parent, /// Non RT POA parent - const char * adapter_name, /// Name for the POA - PortableServer::POAManager_ptr a_POAManager, /// Manager for the POA - const CORBA::PolicyList & policies /// List of non RT policies - ACE_ENV_ARG_DECL) - ACE_THROW_SPEC (( - CORBA::SystemException - , PortableServer::POA::AdapterAlreadyExists - , PortableServer::POA::InvalidPolicy - )); - - -Once a RT POA has been created, schedule_object is called to store CORBA -Object references (key) with a name (value) in an ACE_MAP. An -RTCosScheduling::UnknownName exception is thrown if the schedule_object -name parameter is not found in the resource map (i.e. it was not in the -config file.) -The schedule_object method is declared as: - virtual void schedule_object ( - CORBA::Object_ptr obj, /// A CORBA object reference - const char * name /// Name to associate with obj - ACE_ENV_ARG_DECL) - ACE_THROW_SPEC (( - CORBA::SystemException - , RTCosScheduling::UnknownName - )); - - -Once all objects that will receive client requests have been scheduled -using schedule_object, clients are free to make calls on those objects. -The scheduling service interceptors catch these calls and perform the -necessary priority ceiling control measures to ensure that the calls -are executed in the appropriate order. The ServerScheduler_Interceptor -receive_request method intercepts all incoming request immediately since it -is set to run at RTCORBA::maxPriority (the highest priority on the server -OS). It then gets the client priority sent in the service context as well -as the resource ceiling for the object and the base priority for the server. -Initial tests indicate that the receive_request interceptor takes around -0.002 seconds to complete on an Intel 3.0 GHz processor. - -Given these values it is able to use the Multiprocessor Priority Ceiling -Protocol to schedule execution on the server to handle the request. MPCP -schedules all global critical sections at a higher priority than tasks on -the local processor by adding the client priority to the base -priority of the servant, then adding the resource ceiling of the resource -to the base priority to find the appropriate priority ceiling. For more -information about MPCP, please refer to the book "Real Time Systems", -By Jane Liu (2000). - -Please not that the locking mechanisms are stored in shared memory -on the server. This means that the locks cannot be stored in linked lists -and are therefore manipulated using memory offsets. The total number of -locks that may be stored in shared memory is currently set at 1024. - -When remote execution is complete the send_reply interceptor resets the thread -to listen at RTCORBA::maxPriority and removes the task form the Invocation -list. Initial test indicate that the send_reply interceptor takes 0.000075 -seconds to complete on an Intel 3.0 GHz processor. - - -Scheduling Service Config File: -The scheduling service config file holds the information necessary to -schedule the system. Task and resource ceiling information is stored for -each of the nodes as follows: - -Node 1 /// The node name is 1 - -Resources: -BP 6000 /// The base priority for the resource -Server1 1000 /// A list of resources and their priority ceiling -Server2 2000 -END /// The end of the resource list - -Tasks: /// A list of tasks that will execute on the node -Client1 1000 -Client2 3000 -Client3 5000 -END /// The end of the task list. - -Please note that these associations are tab delimited. Please do not include -comments in the scheduling service config file. The priorities associated -with each task and resource are considered to be CORBA priorities, and -will be mapped to local OS level priorities using the Linear Mapping -model. Per the OMG RT CORBA spec, CORBA priorities have a valid range up -to 32767, where a larger value indicates a higher priority. The current -config file assumes that the Multiprocessor Priority Ceiling Protocol is -used. - -Known Issues: -TAO does not currently support request buffering, and there are no immediate -plans to do so. Consequently, the RT CORBA 1.0 Scheduling Service is -limited in that it will only function properly in systems that do not -require request buffering on the servant side. - -There is a bug in TAO in which mapped priorities are mapped a second time -when using Client Propagated Priority Ceiling Protocol. This in effect -lowers the priority that the servant receives. This happens to each -priority, so there should be no effect on the system. - -The config file assumes CORBA priorities in the range of 0 to 32767. -The Linear Priority Mapping Manager will map these to valid local OS -priorities. Take care though, in determining the priority range in -the config file, as low numbers or numbers very close in value may -produce priority inversion and other issues. For example, if the CORBA -priorities used for three tasks are 100 200 300, these will all map to -OS priority 1 in on some real time Linux systems. Please take this into -account when determining the CORBA priority range to use. - -The 1.0 Scheduling service currently works with one orb and one POA. -If someone tries to install more than one scheduling service (client or server -side) on a single POA, then it should not add a second interceptor. Please -use a single scheduling service per POA. Furthermore, there is a bug when -more than one orb is created, an invalid policy exception is thrown during the -second call to create_POA. This bug is actively being investigated. In the -meantime please use the scheduling service with one ORB. - - - -Future Enhancements: -ACE_XML -The current RT CORBA 1.0 Scheduling Service uses a private method to -read the config file. This will soon be replaced with a new XML based config -file using ACE_XML to parse the config file. - -Priority Lanes -Although not currently implemented, Priority Lanes and Thread Borrowing -may increase performance as they would help to prevent lower priority -tasks from exhausting all threads. This is considered a possible future -enhancement. - -Client Interceptor -A client interceptor that sends a flag to notify the server interceptor if -schedule_activity() was used to set the client priority. If -schedule_activity() was not used, then the server should probably not try -and schedule server execution using MPCP. Doing so adds competition to other -method calls by other client requests that were scheduled with -schedule_activity(). - -References -The Object Management Group, Real Time CORBA 1.0 Specification, www.omg.org -Liu, Jane, Real Time Systems, Prentice Hall, 2000 - - |