Legacy Issue Number: 7312
Source: Syracuse University ( Joncheng Kuo)
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.
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
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