ChangeLogTag:Mon Apr 16 12:32:48 2001 Nanbor Wang <nanbor@cs.wustl.edu>

1 files changed, 40 insertions, 59 deletions

diff --git a/TAO/examples/PluggableUDP/DIOP/README b/TAO/examples/PluggableUDP/DIOP/README
index 8fa4a224ddd..d2dd98faa2b 100644
--- a/TAO/examples/PluggableUDP/DIOP/README
+++ b/TAO/examples/PluggableUDP/DIOP/README
@@ -2,33 +2,33 @@ DIOP - UDP Based Pluggable Protocol
 ===================================
 
 This directory contains all of the code needed to use the UDP
-Pluggable Protocol (DIOP).  It should be considered a work in progress
-and will eventually be integrated in with the other standard pluggable
-protocols in tao/Strategies.
+Pluggable Protocol (DIOP).  It is work-in-progress that when complete
+will be integrated with the other standard pluggable protocols in
+$TAO_ROOT/tao/Strategies/.
 
 Notes on the DIOP implementation:
 
-- The DIOP implemenation uses unconnected UDP sockets.
+- The DIOP implemenation uses connectionless UDP sockets.
 
-- The server side implementation bypasses the actual TAO acceptor
+- The server DIOP implementation bypasses the actual TAO Acceptor
   and opens always a UDP socket on start-up.
 
-- The address of that UDP socket can be configured via
-  e.g. -ORBEndpoint diop://:1303
+- The address of that UDP socket can be configured via -ORBendpoint,
+  e.g., -ORBEndpoint diop://:1303
 
-  If nothing is specified, the implementation will select a port
-  and open a socket on all network interfaces.
-  (This is the default ORB behavior and can be overwritten using
-   the -ORBEndpoint switch)
+  If nothing is specified, the implementation will select a port and
+  open a socket on all network interfaces.  This is the default ORB
+  behavior and can be overwritten using the -ORBEndpoint switch.
 
 - Because no connections - no state - exist, all client requests
   from different clients arrive at the same socket!
 
-- The client side DIOP implementation bypasses the actual
-  TAO connector. It installs a connection handler on the first
+- The client DIOP implementation bypasses the actual
+  TAO Connector.  It installs a connection handler on the first
   invocation on a remote CORBA object.
 
-DIOP Installation:
+DIOP Installation (this will be simplified when DIOP is integrated in the 
+$TAO_ROOT/tao/Strategies/ directory):
 
 - Compile TAO/examples/PluggableUDP/DIOP to create the DIOP library.
 
@@ -46,19 +46,18 @@ Limitations:
 
 - No preconnections are supported.
 
-- No thread-per connection is supported.
+- No thread-per-connection is supported.
 
 - Requests from multiple clients are received on the same socket.
 
 - Only oneway invocations operations are supported.
 
-  Using exclusive connections (see ORB configuration) twoways
-  might work, but are not explicitely supported. Please note
-  that you need to use timeouts in combination with twoways
-  in order to avoid deadlocking your application.
+  Using exclusive connections (see ORB configuration) twoways might
+  work, but are not supported yet.  Please note that you need to use
+  timeouts in combination with twoways in order to avoid deadlocking
+  your application.
 
-
-Issues:
+Open Issues:
 
 - Default port is the same on client and server, therefore
   the client ports need to be explicitly set by -ORBEndpoint option.
@@ -66,45 +65,33 @@ Issues:
 
 - GIOP invocations containing more than ACE_MAX_DGRAM_SIZE bytes of header
   and invocation data will not be sent to the remote side, they will
-  be dropped without error notification.
-  The reason for this is that we want to ensure all invocation information
-  is received at once by the server. Supporting multiple UDP packets would
-  require keeping state in the server and is therefore avoided.
-
-  A hook might be provided in the future in order to notify applications
-  about dropped invocations.
+  be dropped without error notification.  The reason for this is that
+  we want to ensure all invocation information is received at once by
+  the server. Supporting multiple UDP packets would require keeping
+  state in the server and is therefore avoided.
 
+  A hook might be provided in the future in order to notify
+  applications about dropped invocations.
 
 Disclaimer:
 
-  This UDP Pluggable Protocol has been developed for Siemens base station
-  software. We assumed certain requriements, which do not fit everybody, so
-  be careful applying this pluggable protocol to your application. 
-
-  The assumptions we had:
+  This UDP Pluggable Protocol has been developed for a particular
+  set of assumptions:
 
-  - Almost 100% reliable UDP communication as we use IP over ATM
-
-    (Even if it would be less reliable you can manage it by using one-way
-    request operations and one-way response operations in combination with
-    application level timeouts.)
+  - Almost 100% reliable UDP communication, e.g., IP over ATM.
+    Even if it would be less reliable you can manage it by using
+    one-way request operations and one-way response operations in
+    combination with application level timeouts.
   
-  - TCP got ruled out as it behaves to sluggish on sudden disconnections, we
-    needed to be able to plug & play CPU cards without impacting any ORB
-    communicating to that CPU.
-
-    (This is the main reason why we do not keep any state in the client side
-    of the Pluggable Protocol)
-
-  - As we use a special hardware configuration we defined that every GIOP message
-    (and therefore every IDL signature) message is shorter than 4kB, which is the
-    maximum length of a UDP packet anyway.
-	  
-    (Support for fragmentation, as GIOP 1.2 supports it might help, this is
-    a future option)
-
-  - No data sent via DIOP would be larger than ACE_MAX_DGRAM_SIZE.
+  - TCP is inappropriate due to its sluggish on sudden disconnections,
+    e.g., it must be possible to "plug & play" CPU cards without
+    impacting any ORB communicating to a CPU.  This is the main reason
+    why we do not keep any state in the client of the Pluggable Protocol.
 
+  - Every GIOP message (and therefore every IDL signature) message is
+    <= 4kB, i.e., ACE_MAX_DGRAM_SIZE.  Support for fragmentation, as
+    GIOP 1.2 supports it might help, this is a future option.
+    Thus, no data sent via DIOP can be larger than ACE_MAX_DGRAM_SIZE.
 
 Appendix:
 
@@ -113,9 +100,3 @@ Appendix:
                            -k <ior>
                            -t <timeout in ms>
                            -i <iterations>
-
-Comments, Suggestions, or Feedback:
-
-  mailto:Michael.Kircher@mchp.siemens.de or,
-  mailto:John.Mackenzie.extern@icn.siemens.de or,
-  mailto:fhunleth@cs.wustl.edu