DIOP - UDP Based Pluggable Protocol
===================================

NOTE: The file that were in this directory have been moved to
      $TAO_ROOT/tao/Strategies/.

This directory contains all of the code needed to use the UDP
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 connectionless UDP sockets.

- 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 -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.

- Because no connections - no state - exist, all client requests
  from different clients arrive at the same socket!

- 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

- The application using DIOP should have a svc.conf file with the
  following entry:

  dynamic DIOP_Factory Service_Object * TAO_DIOP:_make_TAO_DIOP_Protocol_Factory() ""
  static Resource_Factory "-ORBProtocolFactory DIOP_Factory"

Limitations:

- No preconnections are 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 supported yet.  Please note that you need to use
  timeouts in combination with twoways in order to avoid deadlocking
  your application.

Open Issues:

- Default port is the same on client and server, therefore
  the client ports need to be explicitly set by -ORBEndpoint option.
  Maybe there is a way to find free ports?

- 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.

Disclaimer:

  This UDP Pluggable Protocol has been developed for a particular
  set of assumptions:

  - 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 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.