From 65566a4be54cc015f34811a96436e9483524f25b Mon Sep 17 00:00:00 2001 From: Nick Williams Date: Fri, 8 Sep 2023 13:40:20 -0500 Subject: [PATCH] Improve documentation for TAO_UIPMC_Protocol_Factory and TAO_MIOP_Resource_Factory --- TAO/docs/Options.html | 54 +++++++++++++++++++++---------------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/TAO/docs/Options.html b/TAO/docs/Options.html index 7c6d234aa88de..09552d66d6d61 100644 --- a/TAO/docs/Options.html +++ b/TAO/docs/Options.html @@ -35,10 +35,10 @@

Table of Contents

  • TAO_Advanced_Resource_Factory
  • -
  • Server_Strategy_Factory
  • -
  • Client_Strategy_Factory
  • -
  • TAO_UIPMC_Protocol_Factory
  • -
  • MIOP_Strategy_Factory
  • +
  • Server_Strategy_Factory
  • +
  • Client_Strategy_Factory
  • +
  • TAO_UIPMC_Protocol_Factory
  • +
  • TAO_MIOP_Resource_Factory
  • Time_Policy_Manager
  • @@ -1834,10 +1834,10 @@

    3. Client_Strategy_Factory

    4. TAO_UIPMC_Protocol_Factory

    This factory is located in the TAO_PortableGroup library and - is used with the DIOP and MIOP protocols managing the UDP connectionless - sockets (normally one-way calls only) instead of the standard IIOP TCP/IP - two-way connection based sockets. It accepts the options shown below. - (Any options required should be given + implements the MIOP protocol. It uses the + TAO_MIOP_Resource_Factory to manage UDP connection options + shared with the TAO_DIOP_Protocol_Factory. It accepts its own un-shared + options shown below. (Any options required should be given to the TAO_UIPMC_Protocol_Factory between the two double-quotes at the end of the line as a space separated list; however none are required as all options take default values if not specified.) This factory can be loaded @@ -1909,15 +1909,15 @@

    4. TAO_UIPMC_Protocol_Factory

    -

    5. MIOP_Strategy_Factory

    +

    5. TAO_MIOP_Resource_Factory

    This factory is located in the TAO_PortableGroup library and - uses the TAO_UIPMC_Protocol_Factory (see above) to - manage its UDP sockets, you should also look at that factories configuration - options. The MIOP factory accepts it own options detailed below which - should be specified between the two double-quotes shown here as a space - separated list; however none are required as all options take default - values if not specified. This factory can be loaded dynamically using a - service configurator directive of the form (all on one line): + manages UDP connection options shared between the TAO_DIOP_Protocol_Factory + and the TAO_UIPMC_Protocol_Factory (see above). It + accepts the options detailed below, which should be specified between the + two double-quotes shown here as a space-separated list; however none are + required as all options take default values if not specified. This factory + can be loaded dynamically using a service configurator directive of the + form (all on one line):

    dynamic MIOP_Resource_Factory Service_Object * TAO_PortableGroup:_make_TAO_MIOP_Resource_Factory () ""

    You would normally have to use other service configurator @@ -1930,17 +1930,17 @@

    5. MIOP_Strategy_Factory

    TAO_PortableGroup:_make_TAO_PortableGroup_Loader() ""
    dynamic MIOP_Resource_Factory Service_Object * TAO_PortableGroup:_make_TAO_MIOP_Resource_Factory () ""

    - Since MIOP uses UDP sockets (which is not a "reliable" transport unlike tcp/ip) - it is easy to configure MIOP in such a way that messages will not actually - reach the servant. The options below are intended to maximize MIOP reliability - but they must be used with care; users of MIOP must understand that large - messages are sent in fragments and they have to be reassembled by the server in - their entirety to be usable by the servant. If even a single data - fragment/packet is lost, the whole message cannot be reconstructed and will be - unusable. There is no way for the servant to even know it has missed such a - MIOP message, and being a one-way protocol, neither will the client be aware - that the message has been lost. Fragments can be lost due to a variety of - reasons: + Since DIOP and MIOP use UDP sockets (which is not a "reliable" transport unlike + TCP/IP), it is easy to configure them in such a way that messages will not + actually reach the servant. The options below are intended to maximize DIOP and + MIOP reliability, but they must be used with care; users of DIOP and MIOP must + understand that large messages are sent in fragments and they have to be + reassembled by the server in their entirety to be usable by the servant. If + even a single data fragment/packet is lost, the whole message cannot be + reconstructed and will be unusable. There is no way for the servant to even + know it has missed such a DIOP or MIOP message, and being a one-way protocol, + neither will the client be aware that the message has been lost. Fragments + can be lost due to a variety of reasons: