CORBA 3.4 RTF Avatar
  1. OMG Issue

CORBA34 — What BiDirIds shall be sent over what bidirectional connections?

  • Key: CORBA34-284
  • Legacy Issue Number: 7312
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send all BiDirIds on an ORB to every connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of every existing bi-directional connections (before or in the next request).

    The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted.

    Proposed resolution:
    1. Extend the choices of the value field of the BidirectionalOfferPolicy:
    ALLOW_ALL – same as ALLOW now, but the implication shall be explicitely stated in the spec
    ALLOW_LISTED – a list of POAs being provided in the policy
    DENY – same as it now
    2. Add a field to the policy to allow a sequence of POAs being specified.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT