-
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
CORBA34 — What BiDirIds shall be sent over what bidirectional connections?
- Key: CORBA34-284
- OMG Task Force: CORBA 3.4 RTF