ChangeLogTag:Fri Feb 25 10:46:52 2000 Ossama Othman <ossama@uci.edu>

1 files changed, 95 insertions, 36 deletions

diff --git a/TAO/docs/releasenotes/index.html b/TAO/docs/releasenotes/index.html
index dff10963c7a..792b8426f2c 100644
--- a/TAO/docs/releasenotes/index.html
+++ b/TAO/docs/releasenotes/index.html
@@ -414,12 +414,27 @@ object. Each profile for an object may encode information pertaining to
 QoS, network and transport protocols, addresses or routes.<p>
 
 <li>
-<b>Example Transport protocols</b>- The first example, aside from IIOP, that
-has been implemented, UIOP, uses local IPC. Other interesting transport
-protocols would be for ATM, Buses (VME or PCI), shared memory, TP4, GSMP, and
-UDP/IP.</li> <p>
+<b>Example Transport protocols</b> - Aside from IIOP, three additional
+transport protocols have been implemented:
+<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).
+   <FONT COLOR=RED>SSLIOP is not distributed with TAO due
+   to US cryptographic software export restrictions.
+   There are <STRONG>no</STRONG> security hooks in
+   TAO.</FONT></li>
+</ol>
 
-<li>
+<P>
+Other interesting transport protocols could be for ATM, Buses (VME or
+PCI), TP4, GSMP, and UDP/IP.  TAO users have also created their own
+pluggable transport protocols, such as a ScramNet pluggable protocol.
+
+</li>
+
+
+<P><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>
@@ -431,9 +446,9 @@ Current Status:
 The basic framework to support pluggable transport protocols has been
 completed.  The standard TAO regression tests <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>
+can be used to verify performance using the new framework.</li>
 
-<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
@@ -444,72 +459,95 @@ can be used to verify performance using the new framework.</li><P>
             in URL format (ex: <code>iiop://foo.bar.com:0</code>),
             this format can be extended to support different
             protocols.
-</li><P>
+</li>
 
-<li>
+<P><li>
             If the user does not specify a list of endpoints then the
             ORB creates a default endpoint for each protocol
-            configured.
-</li><P>
+            configured, unless the pluggable protocol explicitly
+	    prevents that in an effort to prevent resource leaks.
+</li>
 
-<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>
 
-<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>
 
-<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.  If no explicit
-            <code>-ORBEndpoint</code> option is used (ex:
-            <code>-ORBEndpoint uiop:///tmp/my_rendezvous</code>).
+            protocol is loaded by default.
 
-</li><P>
+</li>
 
-<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>
+	      SSLIOP is not distributed with TAO due to US
+	      cryptographic laws.  No changes were made to TAO to
+	      provide this SSL support, nor does TAO contain any
+	      security related hooks.  TAO's SSLIOP implementation is
+	      completely self-contained.  This ensures that TAO
+	      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 and UIOP (if supported by the
-            platform) are loaded.
-</li><P>
+            By default only IIOP, UIOP (if supported by the platform)
+	    and SHMIOP are loaded.
+</li>
 
-<li>
+<P><li>
 
 The service configurator is now used to load protocol factories.
 
-</li><P>
+</li>
 
-<li>
+<P><li>
 	    The <code>-ORBHost</code> and <code>-ORBPort</code>
             options are deprecated. The new <code>-ORBEndpoint</code>
             option supercedes them. If the deprecated options are
             used, the ORB issues a warning.  The user should not
             depend on the existence of these options in the future.
-</li><P>
+</li>
 
-<li>
+<P><li>
             The <code>-ORBPreconnect</code> option supports multiple
             protocols using the same URL formats that
             <code>-ORBEndpoint</code> does. Note that the old
             <em><code>host:port</code></em> format is supported for
             backwards compatibility, but the user should not depend on
             the existence of this old format since it is now deprecated.
-</li><P>
+</li>
 
-<li>
+<P><li>
             The URL style object reference format has been updated to
             conform with the format that <code>iioploc</code>
             uses. The BNF specification for <code>iioploc</code> is:
@@ -552,6 +590,7 @@ The service configurator is now used to load protocol factories.
             string begins since both may contain forward
             slashes in them.
 </li>
+
 <P><li>
             The <i>rendezvous point</i> for <code>uiop</code> is
             any valid path and filename that the ORB has permission to
@@ -615,12 +654,32 @@ The service configurator is now used to load protocol factories.
             The <code>-ORBEndpoint</code> 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.<P>
+            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>
 
-<p>
 </ul>
 
+<P>
 Known Issues:
 
 <ul>
@@ -631,9 +690,9 @@ Critical Work:
 <ul>
 <li>
 None.
-</li><p>
+</li>
 
-<p>
+<p><p>
 </ul>
 Future Work:
 <ul>
@@ -645,9 +704,9 @@ 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>
 
-<p>
 </ul>
 
+<p>
 <hr>
 
 <h3> <a NAME="rtcorba"></a>Real-Time CORBA </h3>