Issue 4115: BiDir GIOP Policy Clarification (firewall-traversal-ftf) Source: Network Associates (Mr. Brian Niebuhr, bniebuhr(at)nai.com) Nature: Uncategorized Issue Severity: Summary: I am a little confused as to the scope of the BiDirPolicy in the 2.4.1 specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In section 15.8 paragraph 5 on page 15-55, the specification states: "If the client ORB policy permits bi-directional use of a connection, a Request message should contain an IOP::ServiceContext structure in its Request header, which indicates that this GIOP connection is bi-directional." but then in section 15.9 paragraph 4 on page 15-59, the specification states: "In the absence of a BidirectionalPolicy being passed in the PortableServer::POA::create_POA operation, a POA will assume a policy value of NORMAL." but then again in the next sentence the specification states: "A client and a server ORB must each have a BidirectionalPolicy with a value of BOTH for bi-directional communication to take place." Could someone clarify for me what the intent for the scope of the policy was here, and what the rationale behind that decision was? We are currently reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP, and I would like to understand the issues regarding the scope of the BiDir policy. Resolution: Revised Text: Actions taken: December 19, 2000: received issue March 7, 2002: moved to Core RTF February 14, 2003: moved to Firewall Traversal FTF April 28, 2003: closed issue Discussion: This territory is covered by the new Firewall spec. Transfer this issue to the Firewall FTF End of Annotations:===== From: "Niebuhr, Brian" To: "'interop@omg.org'" Subject: BiDir GIOP Policy Clarification Date: Tue, 19 Dec 2000 10:31:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: #%bd9@F;!!7o%e9dbJ!! Hello all - I am a little confused as to the scope of the BiDirPolicy in the 2.4.1 specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In section 15.8 paragraph 5 on page 15-55, the specification states: "If the client ORB policy permits bi-directional use of a connection, a Request message should contain an IOP::ServiceContext structure in its Request header, which indicates that this GIOP connection is bi-directional." but then in section 15.9 paragraph 4 on page 15-59, the specification states: "In the absence of a BidirectionalPolicy being passed in the PortableServer::POA::create_POA operation, a POA will assume a policy value of NORMAL." but then again in the next sentence the specification states: "A client and a server ORB must each have a BidirectionalPolicy with a value of BOTH for bi-directional communication to take place." Could someone clarify for me what the intent for the scope of the policy was here, and what the rationale behind that decision was? We are currently reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP, and I would like to understand the issues regarding the scope of the BiDir policy. Thanks! Brian _____________________________ Brian Niebuhr Network Associates - NAI Labs 3060 Washington Rd. (Rt. 97) Glenwood, MD 21738 443-259-2349 bniebuhr@nai.com PGP Fingerprint: 6466 FC24 3594 CA50 ED8B 82ED 359A ECED 4F19 086B Sender: "Vishy Kasar" Message-ID: <3A3FB45D.82D2077A@inprise.com> Date: Tue, 19 Dec 2000 11:17:49 -0800 From: Vishy Kasar Organization: Inprise Corporation - Visibroker Development X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Niebuhr, Brian" CC: "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5el!!C,)!!A'#e9KLl!! Brian, BiDir Policy is both an object policy and a POA policy. The following example may help illustrate it. Client has 2 POAs poa1, poa2. poa1 hosts callback object cb1 and poa2 hosts callback object cb2. poa1 is created with bidir policy. poa2 is has no bidir policy. Let us say client got hold of 2 remote objrefs o1 and o2 that are hosted in servers s1 and s2 respectively. On o1, client sets bidir policy (by set_policy_override). The object o2 has the default (non bidir) policy. When client makes invocation on o1, it publishes the end point of poa1 through SC, so that any invocation on cb1 from server s1 will NOTt establish a new connection. When client makes invocation on o1, it does not publish the end point of poa2 through SC. So any invocation on cb2 from server s1 WILL establish a new connection. When client makes invocation on o2, it does not publish the end point of poa1 or poa2 through SC. So any invocation on cb1 or cb2 from server s2 WILL establish a new connection. "Niebuhr, Brian" wrote: > Hello all - > > I am a little confused as to the scope of the BiDirPolicy in the >2.4.1 > specification. Is the BiDirPolicy a POA policy, an ORB policy, or >both? In > section 15.8 paragraph 5 on page 15-55, the specification states: > > "If the client ORB policy permits bi-directional use > of a connection, a Request message should contain an >IOP::ServiceContext > structure in its Request header, which indicates that this GIOP >connection > is bi-directional." > > but then in section 15.9 paragraph 4 on page 15-59, the >specification > states: > > "In the absence of a BidirectionalPolicy being passed in the > PortableServer::POA::create_POA operation, a POA will assume a >policy value > of > NORMAL." > > but then again in the next sentence the specification states: > > "A client and a server ORB must each have a BidirectionalPolicy with >a value > of > BOTH for bi-directional communication to take place." > > Could someone clarify for me what the intent for the scope of the >policy was > here, and what the rationale behind that decision was? We are >currently > reviewing how to use/fix BiDirIIOP in our submission to the firewall >RFP, > and I would like to understand the issues regarding the scope of the >BiDir > policy. > > Thanks! > > Brian > > _____________________________ > Brian Niebuhr > Network Associates - NAI Labs > 3060 Washington Rd. (Rt. 97) > Glenwood, MD 21738 > 443-259-2349 > bniebuhr@nai.com > PGP Fingerprint: 6466 FC24 3594 CA50 ED8B 82ED 359A ECED 4F19 086B -- Cheers! Date: Tue, 19 Dec 2000 15:15:21 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Niebuhr, Brian" CC: "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Ed,!!Cm8!!aXU!!%;nd9 Brian, If you look back in the archives, there is extensive discussion on this. But in spite of that it was never resolved. I don't recall the issue number, but I submitted one, well over a year ago, maybe two. Martin stonewalled me for a long time, and then finally agreed that there was an issue. But by the time the RTF closed, nothing worthwhile was done. The one policy that is referenced is insufficient. There need to be at least two policies - one governing whether the "client" wants to offer use of bidir to the "server", and another for whether the server wants to accept the offer. It is total nonsense for the first of these to be a POA policy, because it affects actions on outgoing requests, so there would be no basis to decide which POA's policies to use. The case for the server's policy isn't much better. While the offer will presumably be carried on some request targetted at some POA, it too is actually intended to affect outgoing operations that have no relationship to any object or POA in the server. The entire design is fatally flawed. In the new and improved firewall RFP this should either be dropped entirely, or completely redesigned. Originally I had intended to implement this in Rogue Wave's Nouveau orb, and I did get much of it done before leaving. But I was leaving the policy part for later. And I am quite certain that code will never be shipped. My guess is that nobody else implemented either, since if anybody had tried they would have been asking all the same questions I did. Paul "Niebuhr, Brian" wrote: > > Hello all - > > I am a little confused as to the scope of the BiDirPolicy in the 2.4.1 > specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In > section 15.8 paragraph 5 on page 15-55, the specification states: > > "If the client ORB policy permits bi-directional use > of a connection, a Request message should contain an IOP::ServiceContext > structure in its Request header, which indicates that this GIOP connection > is bi-directional." > > but then in section 15.9 paragraph 4 on page 15-59, the specification > states: > > "In the absence of a BidirectionalPolicy being passed in the > PortableServer::POA::create_POA operation, a POA will assume a policy value > of > NORMAL." > > but then again in the next sentence the specification states: > > "A client and a server ORB must each have a BidirectionalPolicy with a value > of > BOTH for bi-directional communication to take place." > > Could someone clarify for me what the intent for the scope of the policy was > here, and what the rationale behind that decision was? We are currently > reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP, > and I would like to understand the issues regarding the scope of the BiDir > policy. > > Thanks! > > Brian > > _____________________________ > Brian Niebuhr > Network Associates - NAI Labs > 3060 Washington Rd. (Rt. 97) > Glenwood, MD 21738 > 443-259-2349 > bniebuhr@nai.com > PGP Fingerprint: 6466 FC24 3594 CA50 ED8B 82ED 359A ECED 4F19 086B Date: Tue, 19 Dec 2000 15:33:41 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Vishy Kasar CC: "Niebuhr, Brian" , "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: <3A3FB45D.82D2077A@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^'p!!)W;e9m!ad9Yo/!! Vishy, That makes more sense than anything I have previously seen on the subject. (Where were you when there was discussion on this?) But it still leaves many open questions. See below. Paul Vishy Kasar wrote: > > Brian, > > BiDir Policy is both an object policy and a POA policy. The following example > may help illustrate it. > > Client has 2 POAs poa1, poa2. poa1 hosts callback object cb1 and poa2 hosts > callback object cb2. poa1 is created with bidir policy. poa2 is has no bidir > policy. > > Let us say client got hold of 2 remote objrefs o1 and o2 that are hosted in > servers s1 and s2 respectively. On o1, client sets bidir policy (by > set_policy_override). The object o2 has the default (non bidir) policy. > > When client makes invocation on o1, it publishes the end point of poa1 through > SC, so that any invocation on cb1 from server s1 will NOTt establish a new > connection. > > When client makes invocation on o1, it does not publish the end point of poa2 > through SC. So any invocation on cb2 from server s1 WILL establish a new > connection. > > When client makes invocation on o2, it does not publish the end point of poa1 > or poa2 through SC. So any invocation on cb1 or cb2 from server s2 WILL > establish a new connection. This implies that the client needs two unique tcp/ip endpoint addresses (ports) - one for poas that can be accessed bidir and another for those that can't. And it can't reduce this to one by making all of its POAs bidir, since it has no control over the root poa. This is kind of a pain, since one of the reasons for bidir was for things like browsers that might not be able to accept incoming connections at all. Even if the client simply wants things to fail if the server won't do bidir (which is optional for the server), there is no good way for the client to ensure this. To do so it must come up with some endpoint address that will never be used by another server. There is/was some mumbo-jumbo in the spec about the client using the address of his end of the outgoing connection to the server for this. But this can only be guaranteed to belong to the client as long as that connection is maintained. Once it is dropped, that address may be recycled for another use, perhaps by a different client or server. Paul From: "Niebuhr, Brian" To: "'interop@omg.org'" Subject: RE: BiDir GIOP Policy Clarification Date: Tue, 19 Dec 2000 13:38:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: (ERd9\Khd9EBm!!f^1e9 Vishy - So if I can attempt to summarize your example, your client-side algorithm is: If the object being invoked has had policy "BiDir Allowed" set Send listen points for all POAs in this ORB with policy "BiDir Allowed" else Do not send listen points What is the server-side algorithm for deciding if BiDir connections should be used? Under what circumstances does the client decide to override the BiDir policy on a object reference received? Brian > -----Original Message----- > From: Vishy Kasar [mailto:vishy@borland.com] > Sent: Tuesday, December 19, 2000 2:18 PM > To: Niebuhr, Brian > Cc: 'interop@omg.org' > Subject: Re: BiDir GIOP Policy Clarification > > > Brian, > > BiDir Policy is both an object policy and a POA policy. The > following example > may help illustrate it. > > Client has 2 POAs poa1, poa2. poa1 hosts callback object cb1 > and poa2 hosts > callback object cb2. poa1 is created with bidir policy. poa2 > is has no bidir > policy. > > Let us say client got hold of 2 remote objrefs o1 and o2 that > are hosted in > servers s1 and s2 respectively. On o1, client sets bidir policy (by > set_policy_override). The object o2 has the default (non > bidir) policy. > > When client makes invocation on o1, it publishes the end > point of poa1 through > SC, so that any invocation on cb1 from server s1 will NOTt > establish a new > connection. > > When client makes invocation on o1, it does not publish the > end point of poa2 > through SC. So any invocation on cb2 from server s1 WILL > establish a new > connection. > > When client makes invocation on o2, it does not publish the > end point of poa1 > or poa2 through SC. So any invocation on cb1 or cb2 from > server s2 WILL > establish a new connection. > > > > "Niebuhr, Brian" wrote: > > > Hello all - > > > > I am a little confused as to the scope of the BiDirPolicy > in the 2.4.1 > > specification. Is the BiDirPolicy a POA policy, an ORB > policy, or both? In > > section 15.8 paragraph 5 on page 15-55, the specification states: > > > > "If the client ORB policy permits bi-directional use > > of a connection, a Request message should contain an > IOP::ServiceContext > > structure in its Request header, which indicates that this > GIOP connection > > is bi-directional." > > > > but then in section 15.9 paragraph 4 on page 15-59, the > specification > > states: > > > > "In the absence of a BidirectionalPolicy being passed in the > > PortableServer::POA::create_POA operation, a POA will > assume a policy value > > of > > NORMAL." > > > > but then again in the next sentence the specification states: > > > > "A client and a server ORB must each have a > BidirectionalPolicy with a value > > of > > BOTH for bi-directional communication to take place." > > > > Could someone clarify for me what the intent for the scope > of the policy was > > here, and what the rationale behind that decision was? We > are currently > > reviewing how to use/fix BiDirIIOP in our submission to the > firewall RFP, > > and I would like to understand the issues regarding the > scope of the BiDir > > policy. > > > > Thanks! > > > > Brian > > > > _____________________________ > > Brian Niebuhr > > Network Associates - NAI Labs > > 3060 Washington Rd. (Rt. 97) > > Glenwood, MD 21738 > > 443-259-2349 > > bniebuhr@nai.com > > PGP Fingerprint: 6466 FC24 3594 CA50 ED8B 82ED 359A ECED 4F19 086B > > -- > Cheers! > > > From: "Niebuhr, Brian" To: "'interop@omg.org'" Subject: RE: BiDir GIOP Policy Clarification Date: Tue, 19 Dec 2000 13:38:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: S,@!!K@D!!D%3!!_^c!! Comments inline... > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, December 19, 2000 3:15 PM > To: Niebuhr, Brian > Cc: 'interop@omg.org' > Subject: Re: BiDir GIOP Policy Clarification > > > Brian, > > If you look back in the archives, there is extensive > discussion on this. > But in spite of that it was never resolved. I don't recall the issue > number, > but I submitted one, well over a year ago, maybe two. Martin > stonewalled > me for a long time, and then finally agreed that there was an > issue. But > by the time the RTF closed, nothing worthwhile was done. Indeed, this was what I was reading when I asked the question. I thought that somehow it had been resolved and I missed the solution. > The one policy that is referenced is insufficient. There need to be at > least > two policies - one governing whether the "client" wants to > offer use of > bidir > to the "server", and another for whether the server wants to > accept the > offer. I agree. > It is total nonsense for the first of these to be a POA > policy, because > it > affects actions on outgoing requests, so there would be no basis to > decide which POA's policies to use. If I understand Vishy's example correctly, he makes assumption that if the policy on the POA containing the object making the invocation allows BiDir, then the listen points are placed in the service context. Is it unreasonable to assume that whatever portion of the ORB builds the ListenPoint SC knows from which POA the invocation originates? > The case for the server's policy isn't much better. While the > offer will > presumably be carried on some request targetted at some POA, it too > is > actually intended to affect outgoing operations that have no > relationship to any object or POA in the server. I believe this is the same problem... > The entire design is fatally flawed. In the new and improved firewall > RFP this should either be dropped entirely, or completely redesigned. We are looking at redesigning it, and that's why I wanted to understand the policy issues. > Originally I had intended to implement this in Rogue Wave's > Nouveau orb, > and I did get much of it done before leaving. But I was leaving the > policy part for later. And I am quite certain that code will never > be > shipped. My guess is that nobody else implemented either, since if > anybody had tried they would have been asking all the same questions > I > did. I get the impression (though I can't verify) that BiDir has been implemented by at least one ORB vendor. IMHO, the problem is that the policy has only been vaguely spec'd (hence my questions) allowing vendors to invent their own interpretation. And while this may work for a proprietary solution, the code will not be portable. Brian Date: Tue, 19 Dec 2000 14:07:02 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Niebuhr, Brian" CC: "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: P@jd9'"bd9dZad93]Ie9 "Niebuhr, Brian" wrote: > Vishy - > > So if I can attempt to summarize your example, your client-side >algorithm > is: > > If the object being invoked has had policy "BiDir Allowed" set > Send listen points for all POAs in this ORB with policy >"BiDir > Allowed" > else > Do not send listen points That is exactly right. > What is the server-side algorithm for deciding if BiDir connections should > be used? By this, I am assuming you are asking when a server decides to send its call back requests over an incoming connection. The decision there is based on the listen points received on that connection. All Callback objects that have listen points published over that connection are allowed to make their requests using that connection, provided the server side ORB policy is set to allow BiDir communication. > Under what circumstances does the client decide to override the BiDir policy > on a object reference received? This is really upto the user. Given that using bidir connections exposes client objects to the server, it is conceivable that clients may be selective about which servers they want to allow access to their callback objects. That information will be reflected by this policy on the object reference. > > > Brian > > > -----Original Message----- > > From: Vishy Kasar [mailto:vishy@borland.com] > > Sent: Tuesday, December 19, 2000 2:18 PM > > To: Niebuhr, Brian > > Cc: 'interop@omg.org' > > Subject: Re: BiDir GIOP Policy Clarification > > > > > > Brian, > > > > BiDir Policy is both an object policy and a POA policy. The > > following example > > may help illustrate it. > > > > Client has 2 POAs poa1, poa2. poa1 hosts callback object cb1 > > and poa2 hosts > > callback object cb2. poa1 is created with bidir policy. poa2 > > is has no bidir > > policy. > > > > Let us say client got hold of 2 remote objrefs o1 and o2 that > > are hosted in > > servers s1 and s2 respectively. On o1, client sets bidir policy >(by > > set_policy_override). The object o2 has the default (non > > bidir) policy. > > > > When client makes invocation on o1, it publishes the end > > point of poa1 through > > SC, so that any invocation on cb1 from server s1 will NOTt > > establish a new > > connection. > > > > When client makes invocation on o1, it does not publish the > > end point of poa2 > > through SC. So any invocation on cb2 from server s1 WILL > > establish a new > > connection. > > > > When client makes invocation on o2, it does not publish the > > end point of poa1 > > or poa2 through SC. So any invocation on cb1 or cb2 from > > server s2 WILL > > establish a new connection. > > > > > > > > "Niebuhr, Brian" wrote: > > > > > Hello all - > > > > > > I am a little confused as to the scope of the BiDirPolicy > > in the 2.4.1 > > > specification. Is the BiDirPolicy a POA policy, an ORB > > policy, or both? In > > > section 15.8 paragraph 5 on page 15-55, the specification >states: > > > > > > "If the client ORB policy permits bi-directional use > > > of a connection, a Request message should contain an > > IOP::ServiceContext > > > structure in its Request header, which indicates that this > > GIOP connection > > > is bi-directional." > > > > > > but then in section 15.9 paragraph 4 on page 15-59, the > > specification > > > states: > > > > > > "In the absence of a BidirectionalPolicy being passed in the > > > PortableServer::POA::create_POA operation, a POA will > > assume a policy value > > > of > > > NORMAL." > > > > > > but then again in the next sentence the specification states: > > > > > > "A client and a server ORB must each have a > > BidirectionalPolicy with a value > > > of > > > BOTH for bi-directional communication to take place." > > > > > > Could someone clarify for me what the intent for the scope > > of the policy was > > > here, and what the rationale behind that decision was? We > > are currently > > > reviewing how to use/fix BiDirIIOP in our submission to the > > firewall RFP, > > > and I would like to understand the issues regarding the > > scope of the BiDir > > > policy. > > > > > > Thanks! > > > > > > Brian > > > > > > _____________________________ > > > Brian Niebuhr > > > Network Associates - NAI Labs > > > 3060 Washington Rd. (Rt. 97) > > > Glenwood, MD 21738 > > > 443-259-2349 > > > bniebuhr@nai.com > > > PGP Fingerprint: 6466 FC24 3594 CA50 ED8B 82ED 359A ECED 4F19 >086B > > > > -- > > Cheers! > > > > > > From: "Niebuhr, Brian" To: "'interop@omg.org'" Subject: RE: BiDir GIOP Policy Clarification Date: Tue, 19 Dec 2000 14:16:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: oX+e9MCBe9]0Od9RfA!! > > So if I can attempt to summarize your example, your > client-side algorithm > > is: > > > > If the object being invoked has had policy "BiDir Allowed" set > > Send listen points for all POAs in this ORB with > policy "BiDir > > Allowed" > > else > > Do not send listen points > > That is exactly right. > > > What is the server-side algorithm for deciding if BiDir > connections should > > be used? > > By this, I am assuming you are asking when a server decides > to send its call > back requests over an incoming connection. Yes. > The decision there > is based on the > listen points received on that connection. All Callback > objects that have listen > points published over that connection are allowed to make > their requests using > that connection, provided the server side ORB policy is set > to allow BiDir > communication. That is exactly the question I am asking. I understand how the listen points indicate which objects are available on a connection, but how does the server decide if it _should_ use those connections or not? It can't just be based on the BiDirPolicy, because in the client side algorithm we stated that the BiDirPolicy is used to determine if an ORB acting as a client may send the ListenPoints when establishing a connection. > > Under what circumstances does the client decide to override > the BiDir policy > > on a object reference received? > > This is really upto the user. Given that using bidir > connections exposes client > objects to the server, it is conceivable that clients may be > selective about > which servers they want to allow access to their callback > objects. That > information will be reflected by this policy on the object reference. Are you suggesting that the application make a determination on an object-by-object basis whether or not to allow BiDir connections when invoking on that object? That seems awfully cumbersome. It would seem much more logical to have some kind of ORB-level policy stating whether BiDir should be allowed or not. Am I missing something here? Brian Date: Tue, 19 Dec 2000 14:25:13 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Niebuhr, Brian" CC: "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: p#d!!HJIe9f*V!!?[Td9 "Niebuhr, Brian" wrote: > Comments inline... > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, December 19, 2000 3:15 PM > > To: Niebuhr, Brian > > Cc: 'interop@omg.org' > > Subject: Re: BiDir GIOP Policy Clarification > > > > > > Brian, > > > > If you look back in the archives, there is extensive > > discussion on this. > > But in spite of that it was never resolved. I don't recall the >issue > > number, > > but I submitted one, well over a year ago, maybe two. Martin > > stonewalled > > me for a long time, and then finally agreed that there was an > > issue. But > > by the time the RTF closed, nothing worthwhile was done. > > Indeed, this was what I was reading when I asked the question. I >thought > that somehow it had been resolved and I missed the solution. > > > The one policy that is referenced is insufficient. There need to >be at > > least > > two policies - one governing whether the "client" wants to > > offer use of > > bidir > > to the "server", and another for whether the server wants to > > accept the > > offer. > > I agree. Makes sense. I think this can be accurately reflected though by adding more values to the BiDir policy to include client/server in addition to normal and both. > > > > It is total nonsense for the first of these to be a POA > > policy, because > > it > > affects actions on outgoing requests, so there would be no basis >to > > decide which POA's policies to use. > > If I understand Vishy's example correctly, he makes assumption that >if the > policy on the POA containing the object making the invocation allows >BiDir, > then the listen points are placed in the service context. Is it > unreasonable to assume that whatever portion of the ORB builds the > ListenPoint SC knows from which POA the invocation originates? The invocation may not originate from within a POA. In a typical client situation, the invocation comes from the client code which has also created a callback object and is passing this object over to the server. However, the rest of the analysis is correct. If a POA has the BiDir policy set then the associated listen points are published, else not. and the code that publishes the listen points can reasonably be expected to know which points are available for publishing. > > The case for the server's policy isn't much better. While the > > offer will > > presumably be carried on some request targetted at some POA, it > > too is > > actually intended to affect outgoing operations that have no > > relationship to any object or POA in the server. > > I believe this is the same problem... Not really, in this case the question is whether the server wishes to trust client information about the listen points that is published. Server policy can also be set at the ORB level to indicate whether the server is to accept and use listen points published over an incoming connection. IMO, the POA policy doubling as the ORB policy was an error. The POA policy should merely dictate whether the objects hosted by that POA are to be exposed or not and neither NORMAL nor BOTH (the values for this policy) reflects that accurately. > > The entire design is fatally flawed. In the new and improved firewall > > RFP this should either be dropped entirely, or completely redesigned. > > We are looking at redesigning it, and that's why I wanted to understand the > policy issues. > > > Originally I had intended to implement this in Rogue Wave's > > Nouveau orb, > > and I did get much of it done before leaving. But I was leaving the > > policy part for later. And I am quite certain that code will never be > > shipped. My guess is that nobody else implemented either, since if > > anybody had tried they would have been asking all the same questions I > > did. > > I get the impression (though I can't verify) that BiDir has been implemented > by at least one ORB vendor. IMHO, the problem is that the policy has only > been vaguely spec'd (hence my questions) allowing vendors to invent their > own interpretation. And while this may work for a proprietary solution, the > code will not be portable. The policy part of the spec definitely needs some refinement. The only conclusion I can make based on the current spec was that the same policy was used to mean different things at different areas which is the cause of confusion. Vijay Date: Tue, 19 Dec 2000 14:41:49 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Niebuhr, Brian" CC: "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !4\d9HI""!S,+e9/!#!! Brian, "Niebuhr, Brian" wrote: > > > So if I can attempt to summarize your example, your > > client-side algorithm > > > is: > > > > > > If the object being invoked has had policy "BiDir Allowed" set > > > Send listen points for all POAs in this ORB with > > policy "BiDir > > > Allowed" > > > else > > > Do not send listen points > > > > That is exactly right. > > > > > What is the server-side algorithm for deciding if BiDir > > connections should > > > be used? > > > > By this, I am assuming you are asking when a server decides > > to send its call > > back requests over an incoming connection. > > Yes. > > > The decision there > > is based on the > > listen points received on that connection. All Callback > > objects that have listen > > points published over that connection are allowed to make > > their requests using > > that connection, provided the server side ORB policy is set > > to allow BiDir > > communication. > > That is exactly the question I am asking. I understand how the listen > points indicate which objects are available on a connection, but how does > the server decide if it _should_ use those connections or not? It can't > just be based on the BiDirPolicy, because in the client side algorithm we > stated that the BiDirPolicy is used to determine if an ORB acting as a > client may send the ListenPoints when establishing a connection. As I mentioned in my next mail, the problem is the same policy is being used to mean a bunch of different things. As we interpreted it ;-) the same policy with the BOTH value implies that an ORB acting as server would use these connections and the same ORB acting as client would publish its listen points. > > > Under what circumstances does the client decide to override > > the BiDir policy > > > on a object reference received? > > > > This is really upto the user. Given that using bidir > > connections exposes client > > objects to the server, it is conceivable that clients may be > > selective about > > which servers they want to allow access to their callback > > objects. That > > information will be reflected by this policy on the object reference. > > Are you suggesting that the application make a determination on an > object-by-object basis whether or not to allow BiDir connections when > invoking on that object? That seems awfully cumbersome. It would seem much > more logical to have some kind of ORB-level policy stating whether BiDir > should be allowed or not. Am I missing something here? Well, the policy can be set at the ORB, thread or object level. The object level override of this policy just gives the user finer control in case the user wants to selectively expose callback objects to certain servers over bidir connections. Vijay Sender: "Vishy Kasar" Message-ID: <3A3FE695.11E3E9DE@inprise.com> Date: Tue, 19 Dec 2000 14:52:05 -0800 From: Vishy Kasar Organization: Inprise Corporation - Visibroker Development X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Vishy Kasar , "Niebuhr, Brian" , "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: <3A3FB45D.82D2077A@inprise.com> <3A3FC624.6CFC0ECB@cisco.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: =F;!!VjKe9n99!!Sl_!! Paul, It is not necessary for the client to create a POA that actually opens a TCP socket to listen. In an implementation specific manner, client can create a POA with a psuedo listen point there by satisfying the applet requirement you brought up below. In this case, the listen points will be used by POA to build IOR but there is nobody really listening at that point. As to choosing a safe psuedo listen point, we can achieve that by co-operation of the client side firewall. We can set up the client side firewall to block any incoming connection within the port range X and Y. That range X to Y is now available for use as psuedo listen point ports that can be published. If there is no applet involved, we can use the firewall block above to achieve different semantics for servers inside firewall and servers outside firewall if we want. In this case, listen point is not psuedo. Servers within firewall can actually conenct to that callback object using a new connection. Servers outside firewall will be able to connect only through bi dir connection. > This implies that the client needs two unique tcp/ip endpoint addresses > (ports) - one for poas that can be accessed bidir and another for those > that can't. And it can't reduce this to one by making all of its POAs > bidir, since it has no control over the root poa. This is kind of a > pain, since one of the reasons for bidir was for things like browsers > that might not be able to accept incoming connections at all. > > Even if the client simply wants things to fail if the server won't do > bidir (which is optional for the server), there is no good way for the > client to ensure this. To do so it must come up with some endpoint > address that will never be used by another server. > > There is/was some mumbo-jumbo in the spec about the client using the > address of his end of the outgoing connection to the server for this. > But this can only be guaranteed to belong to the client as long as that > connection is maintained. Once it is dropped, that address may be > recycled for another use, perhaps by a different client or server. > > Paul -- Cheers! From: "Niebuhr, Brian" To: "'interop@omg.org'" Subject: RE: BiDir GIOP Policy Clarification Date: Tue, 19 Dec 2000 14:53:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: nPUd9%F\d9D,=e9/P[!! > As I mentioned in my next mail, the problem is the same > policy is being used to > mean a bunch of different things. As we interpreted it ;-) > the same policy with > the BOTH value implies that an ORB acting as server would use > these connections > and the same ORB acting as client would publish its listen points. > Well, the policy can be set at the ORB, thread or object > level. The object level > override of this policy just gives the user finer control in > case the user wants > to selectively expose callback objects to certain servers over bidir > connections. > > Vijay > Ok, well I think my question has been sufficiently answered. The conclusions I draw from this discussion are: 1) The BiDirPolicy semantics are not clear and need to be revised. 2) We need a both a server-side ("should I use an offered BiDir connection?") and a client-side ("should I offer a BiDir connection?") policy. 3) The client-side policy should consist of two parts: A POA policy to indicate which objects can have their listen point exported, and a policy (ORB or object scope) to determine when listen points should be sent over a connection. Do these seem correct to everyone? Brian Date: Tue, 19 Dec 2000 19:25:34 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Niebuhr, Brian" CC: "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 7\Pe9H\9!!e4Wd9]KB!! See below "Niebuhr, Brian" wrote: > > Ok, well I think my question has been sufficiently answered. The > conclusions I draw from this discussion are: > > 1) The BiDirPolicy semantics are not clear and need to be revised. > > 2) We need a both a server-side ("should I use an offered BiDir > connection?") and a client-side ("should I offer a BiDir connection?") > policy. > > 3) The client-side policy should consist of two parts: A POA policy to > indicate which objects can have their listen point exported, and a policy > (ORB or object scope) to determine when listen points should be sent over a > connection. > > Do these seem correct to everyone? > > Brian I agree with everything you say. Doing all that would help a lot. But I don't think it is enough. Having to make up fake addresses that are guaranteed to be invalid in order to use bidir is stupid. Equally stupid is the consequence of that - that an orb deciding how to access an ior when bidir has been offered has no way to know if it is valid to skip the bidir and really use the address. Instead, it must try and wait for failure. Seems to me there should be a BiDir *profile* that is placed in IORs that may be used bidirectionally. If you only want access bidirectionally, include only that. If you want both options, put both it and a regular profile, in which ever order you prefer. Paul Date: Tue, 19 Dec 2000 16:47:52 -0800 From: "Andy Cutright" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "Niebuhr, Brian" , "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: <3A3FFC7E.71F830C5@cisco.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: =lUd9(Rn!!eY See below > > "Niebuhr, Brian" wrote: > > > > Do these seem correct to everyone? > > > > Brian > > I agree with everything you say. Doing all that would help a lot. > > But I don't think it is enough. > > Having to make up fake addresses that are guaranteed to be invalid >in > order to use bidir is stupid. Equally stupid is the consequence of >that > - that an orb deciding how to access an ior when bidir has been >offered > has no way to know if it is valid to skip the bidir and really use >the > address. Instead, it must try and wait for failure. > > Seems to me there should be a BiDir *profile* that is placed in IORs > that may be used bidirectionally. If you only want access > bidirectionally, include only that. If you want both options, put >both > it and a regular profile, in which ever order you prefer. > > Paul ok, so i understand the general argument about applet mode, etc. what do you propose to put into the bidir profile.. don't you still need some endpoint information? cheers, andy Date: Tue, 19 Dec 2000 17:18:27 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "Niebuhr, Brian" , "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: <3A3FFC7E.71F830C5@cisco.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Sp8!![MJd9!Cfd94Ead9 I've been thinking about this a bit and here's what I came up with as a possible solution to this. IORs manufactured by BiDir POAs contain a component w/ some unique identifier client connections publish same unique identifier in BiDir service context on the server side, if identifiers match, then the connection is used for that object reference. As I see it, this has the following advantages 1. No need to publish end points at all 2. Implies no need to manufacture end points where it is not possible (0 could be used as port in the IIOP profile) 3. Spoofing becomes not possible as identifier is manufactured privately by client ORB 4. Skipping bidir is easy (ignore component) 5. skipping IIOP for fake listen points is easy (0 in port indicates fake) Note policies still need to be cleaned up. The only remaining issue is the uniqueness of the identifier, which can be implementation specific as no other information is needed. comments? Vijay Paul Kyzivat wrote: > See below > > "Niebuhr, Brian" wrote: > > > > Ok, well I think my question has been sufficiently answered. The > > conclusions I draw from this discussion are: > > > > 1) The BiDirPolicy semantics are not clear and need to be revised. > > > > 2) We need a both a server-side ("should I use an offered BiDir > > connection?") and a client-side ("should I offer a BiDir >connection?") > > policy. > > > > 3) The client-side policy should consist of two parts: A POA >policy to > > indicate which objects can have their listen point exported, and a >policy > > (ORB or object scope) to determine when listen points should be >sent over a > > connection. > > > > Do these seem correct to everyone? > > > > Brian > > I agree with everything you say. Doing all that would help a lot. > > But I don't think it is enough. > > Having to make up fake addresses that are guaranteed to be invalid >in > order to use bidir is stupid. Equally stupid is the consequence of >that > - that an orb deciding how to access an ior when bidir has been >offered > has no way to know if it is valid to skip the bidir and really use >the > address. Instead, it must try and wait for failure. > > Seems to me there should be a BiDir *profile* that is placed in IORs > that may be used bidirectionally. If you only want access > bidirectionally, include only that. If you want both options, put >both > it and a regular profile, in which ever order you prefer. > > Paul Date: Wed, 20 Dec 2000 08:52:04 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: "Niebuhr, Brian" , "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: <3A3FFC7E.71F830C5@cisco.com> <3A4008E3.1549F08D@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4:R!!%nhd9&8c!!-DRd9 What I had in mind is along the same lines as what Vijay proposes. But it still takes a bit more to prevent spoofing. As he describes, a bidir component should contain a unique id, which is essentially a server identifier. And this is then also passed in a bidir service context, identifying the sender as the server with that identity. There are a couple of issues to deal with: - how does a recipient of a bidir context know the sender is who he claims he is? - how does the sender of a bidir context prevent the recipient from using the contained identity to impersonate the sender? (Of course these are really flip sides of the same problem.) This is essentially a crypto problem, so there should be a crypto solution to it. Probably one of the security guys would be a lot of help here. I am no expert, but I think this can be solved using public key techniques. However it probably requires extra interchanges between the two ends. I think what is needed is for the "unique id / server identity" to contain an encryption key. The recipient can then use that key to perform a challenge/response test with the sender. Of course this in turn means having some way to carry out the challenge response interaction with the sender. I see a couple of ways to do this. - send an object reference for the purpose as part of the bidir context. - add a new operation on Object to do this - add some new messages to GIOP to do it. Of course there could also be a mechanism to disable this verification for those that are trusting. Paul Vijaykumar Natarajan wrote: > > I've been thinking about this a bit and here's what I came up with as a possible > solution to this. > > IORs manufactured by BiDir POAs contain a component w/ some unique identifier > > client connections publish same unique identifier in BiDir service context > > on the server side, if identifiers match, then the connection is used for that > object reference. > > As I see it, this has the following advantages > > 1. No need to publish end points at all > 2. Implies no need to manufacture end points where it is not possible (0 could be > used as port in the IIOP profile) > 3. Spoofing becomes not possible as identifier is manufactured privately by > client ORB > 4. Skipping bidir is easy (ignore component) > 5. skipping IIOP for fake listen points is easy (0 in port indicates fake) > > Note policies still need to be cleaned up. > > The only remaining issue is the uniqueness of the identifier, which can be > implementation specific as no other information is needed. > > comments? > > Vijay > > Paul Kyzivat wrote: > > > See below > > > > "Niebuhr, Brian" wrote: > > > > > > Ok, well I think my question has been sufficiently answered. The > > > conclusions I draw from this discussion are: > > > > > > 1) The BiDirPolicy semantics are not clear and need to be revised. > > > > > > 2) We need a both a server-side ("should I use an offered BiDir > > > connection?") and a client-side ("should I offer a BiDir connection?") > > > policy. > > > > > > 3) The client-side policy should consist of two parts: A POA policy to > > > indicate which objects can have their listen point exported, and a policy > > > (ORB or object scope) to determine when listen points should be sent over a > > > connection. > > > > > > Do these seem correct to everyone? > > > > > > Brian > > > > I agree with everything you say. Doing all that would help a lot. > > > > But I don't think it is enough. > > > > Having to make up fake addresses that are guaranteed to be invalid in > > order to use bidir is stupid. Equally stupid is the consequence of that > > - that an orb deciding how to access an ior when bidir has been offered > > has no way to know if it is valid to skip the bidir and really use the > > address. Instead, it must try and wait for failure. > > > > Seems to me there should be a BiDir *profile* that is placed in IORs > > that may be used bidirectionally. If you only want access > > bidirectionally, include only that. If you want both options, put both > > it and a regular profile, in which ever order you prefer. > > > > Paul From: "Niebuhr, Brian" To: "'interop@omg.org'" Subject: RE: BiDir GIOP Policy Clarification Date: Wed, 20 Dec 2000 07:20:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: d7Pe9VM:!!?+O!!M$Fe9 > What I had in mind is along the same lines as what Vijay proposes. I agree. > But it still takes a bit more to prevent spoofing. As he describes, > a bidir component should contain a unique id, which is essentially > a server identifier. And this is then also passed in a bidir service > context, identifying the sender as the server with that identity. > > There are a couple of issues to deal with: > > - how does a recipient of a bidir context know the sender is who > he claims he is? > > - how does the sender of a bidir context prevent the recipient from > using the contained identity to impersonate the sender? > > (Of course these are really flip sides of the same problem.) You are correct. During the discussion in the firewall RTF, there was mention of creating some kind of random BiDir ID. The idea was that this would at least be a little better because the attacker would have to try a whole bunch of IDs to actually get one right, which would make something like a DoS attack much more difficult. However this solution also has some problems: ideally, as far as I understand ORB implementation, it would be much easier to assign a single BiDir ID to a POA or an ORB so when sending the BiDir context one wouldn't have to send a thousand BiDir IDs. Changing the ID on a POA or ORB would just invalidate all of the BiDir IDs in the object references that contained the original ID - so changing the ID often eliminates the usefulness of BiDir, and not changing it opens you up to spoofing attacks. > This is essentially a crypto problem, so there should be a crypto > solution > to it. Probably one of the security guys would be a lot of help > here. > I am no expert, but I think this can be solved using public key > techniques. > However it probably requires extra interchanges between the two > ends. > I think what is needed is for the "unique id / server identity" to > contain an encryption key. The recipient can then use that key to > perform a challenge/response test with the sender. This is an interesting idea. First I'd like to point out that solving this problem is not possible without proper authentication and authorization, the best we can do is to make spoofing a little more difficult. That being said, I'll propose the obvious solution: The BiDir ID placed in the IOR's BiDir Component is some ID of the implementation's choosing (maybe an int?) and a public key from an asymmetric key pair. The client ORB keeps the private half secret. When opening a connection that could be used for BiDir, the client encrypts some well-known value (e.g. "Magic" or "BiDir") using the private key. This token is the token sent in the BiDir service context along with the ID that the implementation chose. When the server receives the token, if the ID in the IOR matches the ID in the service context, the server attempts to decrypt the token sent on that connection using the public key from the IOR. If this is successful, then it is likely that the connection is not being spoofed. So what do we gain here? All we can really say from this protocol is that the last entity to touch this IOR is the same entity on the other end of this connection. However, it does make it much more difficult for an attacker to spoof an object because the attacker must first modify the IOR, and then spoof the BiDir identifier. Then at least the spoofing of BiDir GIOP would be no worse than the spoofing problems we have in other insecure protocols - in other words connecion hijacking and connection interception are still possible. There are a couple of disadvantages to this solution. 1) Any ORB that wants to do BiDir would need crypto code packaged with it. Due to export restrictions this may be undesireable. 2) Public-key operations can be expensive. However, the client only has to encrypt the token once per BiDir ID, and it can store the token to send in the service contexts of other BiDir connections. The server can also do some caching by storing the decrypted token along with the encrypted token, so that it only has to decrypt a token once. 3) Public keys are large (relative to other IOR components) and could cause IOR bloat. I am not necessarily advocating this idea, its just one possibility if we really want to try and solve the spoofing problem. It would be interesting to hear from ORB vendors to hear what they think is reasonable or unreasonable overhead to solve this problem. Likewise, it would be nice to know if a large number of users actually intend to use IIOP with no security in an environment where spoofing is a big problem (e.g. public networks - Internet). > Of course this in turn means having some way to carry out the > challenge > response interaction with the sender. I see a couple of ways > to do this. > - send an object reference for the purpose as part of the > bidir context. > - add a new operation on Object to do this > - add some new messages to GIOP to do it. > > Of course there could also be a mechanism to disable this > verification > for those that are trusting. In the solution I presented above, the challenge response is done out-of-band through the IOR, which eliminates the need for any extra protocols. Unfortunately there's no way to disable the process on the client side - it must always encrypt the token. But like I said earlier, the client only has to do this once per token, which isn't much overhead. The server does have the option to bypass verification, say in a situation where the BiDir offer came over a trusted connection. Brian Date: Wed, 20 Dec 2000 10:59:08 -0800 From: "Andy Cutright" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Niebuhr, Brian" CC: "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: f*:e9F=!!!81^!!_-Fe9 hi all, "Niebuhr, Brian" wrote: > > > But it still takes a bit more to prevent spoofing. As he describes, > > a bidir component should contain a unique id, which is essentially > > a server identifier. And this is then also passed in a bidir service > > context, identifying the sender as the server with that identity. > > > > There are a couple of issues to deal with: > > > > - how does a recipient of a bidir context know the sender is who > > he claims he is? > > > > - how does the sender of a bidir context prevent the recipient from > > using the contained identity to impersonate the sender? > > > > (Of course these are really flip sides of the same problem.) > > > > This is essentially a crypto problem, so there should be a crypto > > solution > > to it. Probably one of the security guys would be a lot of help here. > > I am no expert, but I think this can be solved using public key > > techniques. > > However it probably requires extra interchanges between the two ends. > > I think what is needed is for the "unique id / server identity" to > > contain an encryption key. The recipient can then use that key to > > perform a challenge/response test with the sender. > > There are a couple of disadvantages to this solution. 1) Any ORB that wants > to do BiDir would need crypto code packaged with it. Due to export > restrictions this may be undesireable. this is a pretty serious step to take. we need to be able to provide our implementation to folks that don't have access to export restricted code. we don't really want to tie an implementation to this sort of restriction do we? shouldn't the the usage of appropriate secure transports & security services be able to solve most of these problems? cheers, andy From: "Niebuhr, Brian" To: "'interop@omg.org'" Subject: RE: BiDir GIOP Policy Clarification Date: Wed, 20 Dec 2000 11:08:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ]Se!!0T0e9,f8!!IcF!! > -----Original Message----- > From: Andy Cutright [mailto:acutright@borland.com] > Sent: Wednesday, December 20, 2000 1:59 PM > To: Niebuhr, Brian > Cc: 'interop@omg.org' > Subject: Re: BiDir GIOP Policy Clarification > > > hi all, > > "Niebuhr, Brian" wrote: > > > > > > But it still takes a bit more to prevent spoofing. As he > describes, > > > a bidir component should contain a unique id, which is essentially > > > a server identifier. And this is then also passed in a > bidir service > > > context, identifying the sender as the server with that identity. > > > > > > There are a couple of issues to deal with: > > > > > > - how does a recipient of a bidir context know the sender is who > > > he claims he is? > > > > > > - how does the sender of a bidir context prevent the > recipient from > > > using the contained identity to impersonate the sender? > > > > > > (Of course these are really flip sides of the same problem.) > > > > > > > This is essentially a crypto problem, so there should be a crypto > > > solution > > > to it. Probably one of the security guys would be a lot > of help here. > > > I am no expert, but I think this can be solved using public key > > > techniques. > > > However it probably requires extra interchanges between > the two ends. > > > I think what is needed is for the "unique id / server identity" to > > > contain an encryption key. The recipient can then use that key to > > > perform a challenge/response test with the sender. > > > > There are a couple of disadvantages to this solution. 1) > Any ORB that wants > > to do BiDir would need crypto code packaged with it. Due to export > > restrictions this may be undesireable. > > this is a pretty serious step to take. we need to be able to > provide our > implementation to folks that don't have access to export > restricted code. we > don't really want to tie an implementation to this sort of > restriction do we? > shouldn't the the usage of appropriate secure transports & > security services be > able to solve most of these problems? Yes it is a big step to take. Actually, while Vijay and I were discussing this issue on the phone, it became apparent that the solution I suggested does not work. Security services do solve the problem, but the question is whether or not people are going to want to use BiDir without using the security services. If so, we should do our best to at least prevent spoofing. In the current BiDir spec, it is entirely too easy to spoof a client object - the attacker doesn't need any special software, and there's no locality constraints on the attacker as with many connection hijacking/spoofing attacks. The client just needs to tell the server "Hey, I've got those objects!". Essentially the only solution to this problem is some sort of cryptographic protection using some kind of challenge/response (or at least some probabilistic protection), and even that isn't going to be foolproof. I thought this could be done out-of-band, but I made a mistake in my initial analysis. I'm not suggesting that we are going to have to put crypto into the ORB, but there is going to be a tradeoff between the complexity of the solution and the amount of spoofing protection provided. Brian Date: Wed, 20 Dec 2000 17:24:47 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Niebuhr, Brian" CC: "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: BaXd93en!!>PG!!^8`!! "Niebuhr, Brian" wrote: ... > Yes it is a big step to take. Actually, while Vijay and I were discussing > this issue on the phone, it became apparent that the solution I suggested > does not work. Security services do solve the problem, but the question is > whether or not people are going to want to use BiDir without using the > security services. If so, we should do our best to at least prevent > spoofing. In the current BiDir spec, it is entirely too easy to spoof a > client object - the attacker doesn't need any special software, and there's > no locality constraints on the attacker as with many connection > hijacking/spoofing attacks. The client just needs to tell the server "Hey, > I've got those objects!". Yes. I think it has to be made at least strong enough that bidir is no weaker than using IIOP otherwise is. > Essentially the only solution to this problem is some sort of cryptographic > protection using some kind of challenge/response (or at least some > probabilistic protection), and even that isn't going to be foolproof. I > thought this could be done out-of-band, but I made a mistake in my initial > analysis. I'm not suggesting that we are going to have to put crypto into > the ORB, but there is going to be a tradeoff between the complexity of the > solution and the amount of spoofing protection provided. I was thinking that the need to verify the connection via a crypto challenge/response could be an option in the BiDir profile in the IOR, placed there as a consequence of a policy on the POA where the object reference is published. I don't think the user of the IOR need have any added say in it - if the provider of the IOR isn't concerned then it is equally likely that the IOR itself could have been hacked in any number of ways. Then, use of crypto could be a separate conformance point. The source of the IOR won't be able to specify it without implementing that. The recipient will simply not be able to use the profile if it requires crypto that isn't supported. Then the use will succeed or fail depending on whether there is another profile. Date: Wed, 20 Dec 2000 19:04:22 -0800 From: "Andy Cutright" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "Niebuhr, Brian" , "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: <3A4131AF.F951DEA4@cisco.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,%b!!C+cd9:=fd9_8;e9 hi all, i understand the security issues with spoofing (i believe ;^), but i'm still of the mind this issue is outside our scope. if you want secure connectivity, use SSL. if you want more security than that, add in security services.. cheers, andy Paul Kyzivat wrote: > "Niebuhr, Brian" wrote: > ... > > Yes it is a big step to take. Actually, while Vijay and I were > discussing > > this issue on the phone, it became apparent that the solution I > suggested > > does not work. Security services do solve the problem, but the > question is > > whether or not people are going to want to use BiDir without using > the > > security services. If so, we should do our best to at least > prevent > > spoofing. In the current BiDir spec, it is entirely too easy to > spoof a > > client object - the attacker doesn't need any special software, > and there's > > no locality constraints on the attacker as with many connection > > hijacking/spoofing attacks. The client just needs to tell the > server "Hey, > > I've got those objects!". > > Yes. I think it has to be made at least strong enough that bidir is > no > weaker than using IIOP otherwise is. > > > Essentially the only solution to this problem is some sort of > cryptographic > > protection using some kind of challenge/response (or at least some > > probabilistic protection), and even that isn't going to be > foolproof. I > > thought this could be done out-of-band, but I made a mistake in my > initial > > analysis. I'm not suggesting that we are going to have to put > crypto into > > the ORB, but there is going to be a tradeoff between the > complexity of the > > solution and the amount of spoofing protection provided. > > I was thinking that the need to verify the connection via a crypto > challenge/response could be an option in the BiDir profile in the > IOR, > placed there as a consequence of a policy on the POA where the > object > reference is published. > > I don't think the user of the IOR need have any added say in it - if > the > provider of the IOR isn't concerned then it is equally likely that > the > IOR itself could have been hacked in any number of ways. > > Then, use of crypto could be a separate conformance point. The > source of > the IOR won't be able to specify it without implementing that. The > recipient will simply not be able to use the profile if it requires > crypto that isn't supported. Then the use will succeed or fail > depending > on whether there is another profile. Date: Thu, 21 Dec 2000 08:23:06 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Andy Cutright CC: "Niebuhr, Brian" , "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: <3A4131AF.F951DEA4@cisco.com> <3A417336.58709875@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: MgU!!6[)!!8XT!!-b^d9 I'm not sure I agree, but it is worth consideration. If this philosophy is adopted, it seems like the BiDir mechanism needs some further detailing. E.g.: - some examination of what sort of security is needed to avoid spoofing; - a way for somebody to specify that an existing connection only be used if it is secure. How would use of SSL help? Perhaps if the "server id" in the BiDir profile had to match some field carried in an SSL certificate? Seems like some assistance from the security folks is needed here. Paul Andy Cutright wrote: > > hi all, > > i understand the security issues with spoofing (i believe ;^), but i'm still of > the mind this issue is outside our scope. if you want secure connectivity, use > SSL. if you want more security than that, add in security services.. > > cheers, > andy From: "Niebuhr, Brian" To: "'interop@omg.org'" Subject: RE: BiDir GIOP Policy Clarification Date: Thu, 21 Dec 2000 06:10:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 4-Rd9Fgfd9U(9e9CP?e9 > I'm not sure I agree, but it is worth consideration. Paul - don't cave on this one :-). Your arguments on the firewall RTF convinced me of the magnitude of the BiDir spoofing problem. > If this philosophy is adopted, it seems like the BiDir mechanism needs > some further detailing. E.g.: > > - some examination of what sort of security is needed to > avoid spoofing; > > - a way for somebody to specify that an existing connection > only be used > if it is secure. If we have a secure connection then BiDir spoofing is not a problem. Essentially, if we trust the authenticated principal on the other end of the connection so serve the object we're invoking on, we can go ahead and reuse the connection. Its essentially the same kind of trust decision we have to make whenever invoking on an object, BiDir or not. However, I believe (but I cannot verify - I only have a cursory understanding of the security spec) that CORBASec does not provide a means for invoker-side access control, i.e. the invoker does not check if the implementor has authorization to implement any specific object (though the implementor can be authenticated). Security folks please correct me if I'm wrong. This would have to be implemented before the spoofing problem would go away. > > i understand the security issues with spoofing (i believe > ;^), but i'm still of > > the mind this issue is outside our scope. if you want > secure connectivity, use > > SSL. if you want more security than that, add in security services.. In general I would tend to agree, but the problem is that with BiDir we open up a whole new type of attack that is unprecedented with current internet protocols. And the real problem is that the vulnerability is extremely simple to exploit. The point of this discussion is to determine how we can make it a little harder, with or without using crypto, for the attacker. I just don't feel that we should unleash a protocol on the world that provides less security than already exists in current protocols. Isn't the internet already insecure enough? ;-) Brian Date: Thu, 21 Dec 2000 12:01:45 -0800 From: "Andy Cutright" X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Andy Cutright , "Niebuhr, Brian" , "'interop@omg.org'" Subject: Re: BiDir GIOP Policy Clarification References: <3A4131AF.F951DEA4@cisco.com> <3A417336.58709875@inprise.com> <3A420439.A20FCADC@cisco.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %!5e98PMe9P))!!i1g!! hi all, Paul Kyzivat wrote: > I'm not sure I agree, but it is worth consideration. > If this philosophy is adopted, it seems like the BiDir mechanism > needs > some further detailing. E.g.: > > - some examination of what sort of security is needed to avoid > spoofing; > > - a way for somebody to specify that an existing connection only be > used > if it is secure. > > How would use of SSL help? Perhaps if the "server id" in the BiDir > profile had to match some field carried in an SSL certificate? > > Seems like some assistance from the security folks is needed here. this is a definite requirement ;^) cheers, andy Date: Fri, 19 Jan 2001 14:31:34 +0000 From: Owen Rees To: Juergen Boldt , issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 4115 -- Interop RTF issue Message-ID: <662150722.979914694@ore> In-Reply-To: <4.2.0.58.20010118143548.05425b30@emerald.omg.org> X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii; format=flowed X-UIDL: B wrote: This is issue # 4115 Niebuhr, Brian" Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Date: Wed, 15 May 2002 15:58:57 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Proposed resolution 4115 The following resolution to transfer this issue to the Firewall FTF will appear in the next vote unless there is significant technical objection to it. Jishnu. _________________________________________________________________________ Issue 4115: BiDir GIOP Policy Clarification (interop) http://cgi.omg.org/issues/issue4115.txt Source: Network Associates (Mr. Brian Niebuhr, bniebuhr@nai.com) Nature: Uncategorized Issue Severity: Summary: I am a little confused as to the scope of the BiDirPolicy in the 2.4.1 specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In section 15.8 paragraph 5 on page 15-55, the specification states: "If the client ORB policy permits bi-directional use of a connection, a Request message should contain an IOP::ServiceContext structure in its Request header, which indicates that this GIOP connection is bi-directional." but then in section 15.9 paragraph 4 on page 15-59, the specification states: "In the absence of a BidirectionalPolicy being passed in the PortableServer::POA::create_POA operation, a POA will assume a policy value of NORMAL." but then again in the next sentence the specification states: "A client and a server ORB must each have a BidirectionalPolicy with a value of BOTH for bi-directional communication to take place." Could someone clarify for me what the intent for the scope of the policy was here, and what the rationale behind that decision was? We are currently reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP and I would like to understand the issues regarding the scope of the BiDir policy. Resolution: Transfer to Firewall FTF, since they are handling the most recent revisions to BiDir IIOP, which was done as a part of the Firewall submission. Revised Text: Actions taken: Transfer to Firewall FTF -- Jishnu Mukerji Senior Systems Architect, SGBU Staff Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA tel:+1 973 443 7528 mailto:jishnu_mukerji@hp.com Date: Tue, 22 Oct 2002 14:40:52 -0400 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Propose to transfer issue 4115 to Firewal FTF Unless there is great objection this proposal to transfer this issue to the Firewall FTF will appear in the next vote. Jishnu. ____________________________________________________________________________ Issue 4115: BiDir GIOP Policy Clarification (interop) Click here for this issue's archive. Source: Network Associates (Mr. Brian Niebuhr, bniebuhr@nai.com) Nature: Uncategorized Issue Severity: Summary: I am a little confused as to the scope of the BiDirPolicy in the 2.4.1 specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In section 15.8 paragraph 5 on page 15-55, the specification states: "If the client ORB policy permits bi-directional use of a connection, a Request message should contain an IOP::ServiceContext structure in its Request header, which indicates that this GIOP connection is bi-directional." but then in section 15.9 paragraph 4 on page 15-59, the specification states: "In the absence of a BidirectionalPolicy being passed in the PortableServer::POA::create_POA operation, a POA will assume a policy value of NORMAL." but then again in the next sentence the specification states: "A client and a server ORB must each have a BidirectionalPolicy with a value of BOTH for bi-directional communication to take place." Could someone clarify for me what the intent for the scope of the policy was here, and what the rationale behind that decision was? We are currently reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP and I would like to understand the issues regarding the scope of the BiDir policy. Resolution: Thi territory is covered by the new Firewall spec. Transfer this issue to the Firewall FTF. Revised Text: Date: Fri, 19 Mar 2004 10:49:07 -0500 (EST) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: Discussion Issue 4115 Comments below. -Polar On Fri, 19 Mar 2004, Polar Humenn wrote: > > ---------------------------------------------------------------------------------------------------------- > > Issue 4115: BiDir GIOP Policy Clarification (firewall-traversal-ftf) > > Click here for this issue's archive. > > Source: Network Associates (Mr. Brian Niebuhr, bniebuhr@nai.com) > > Nature: Uncategorized Issue > > Severity: > > Summary: > > > > I am a little confused as to the scope of the BiDirPolicy in the 2.4.1 > > specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In > > section 15.8 paragraph 5 on page 15-55, the specification states: > > > > "If the client ORB policy permits bi-directional use > > of a connection, a Request message should contain an IOP::ServiceContext > > structure in its Request header, which indicates that this GIOP connection > > is bi-directional." > > > > but then in section 15.9 paragraph 4 on page 15-59, the specification > > states: > > > > "In the absence of a BidirectionalPolicy being passed in the > > PortableServer::POA::create_POA operation, a POA will assume a policy value > > of > > NORMAL." > > > > but then again in the next sentence the specification states: > > > > "A client and a server ORB must each have a BidirectionalPolicy with a value > > of > > BOTH for bi-directional communication to take place." > > > > Could someone clarify for me what the intent for the scope of the policy was > > here, and what the rationale behind that decision was? We are currently > > reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP, > > and I would like to understand the issues regarding the scope of the BiDir > > policy. > > > > > > Resolution: > > Revised Text: > > Actions taken: > > December 19, 2000: received issue > > March 7, 2002: moved to Core RTF > > February 14, 2003: moved to Firewall Traversal FTF > > April 28, 2003: closed issue > > > > Discussion: > > > > This territory is covered by the new Firewall spec. Transfer this > > issue to the Firewall FTF > > > > (Further) Discussion: > > The issue was resolved in the Firewall specification through the use > > of three separate policies - BidirectionalExportPolicy, > > BidirectionalOfferPolicy and BidirectionalAcceptPolicy. The text > > describing their use is found in the revised GIOP chapter > > (ptc/04-03-02), section 15-9 and quoted below: > > > > "A BidirectionalExportPolicy can be applied to a POA using the > > PortableServer::POA::create_POA operation. If the BidirectionalExportPolicy > > value of the POA is ALLOW, then the objects managed by that POA are > > allowed to be called back via a bi-directional connection. > > Therefore, > > when opening a bi-directional connection, the ORB is allowed to send > > to the server, in the BI_DIR_GIOP IOP::ServiceContext, the BiDirId > > associated with the objects in that POA. The above sentence is confusing in this context. I believe the sentence is talking about the client ORB, however this paragraph seems to be about the Server ORB. A clarification should be made. > > In addition, when IORs are > > created for the objects in the POA, the BiDirId for that POA should be > > placed in the IOR in the TAG_BI_DIR_GIOP component. If the > > BidirectionalExportPolicy value of the POA is DENY, then a > > TAG_BI_DIR_GIOP component should not be placed in the IOR of objects > > in that POA, and the bidirectional identifier for objects in that POA > > should not be sent in any BI_DIR_GIOP_OFFER service contexts. If the above sentences are indeed requirements, the language needs to change to "shall" instead of "should". Of course, that is only if your ORB supports this type of BiDir. > > A BidirectionalOfferPolicy can be applied to a client ORB, and it can > > be overridden for specific object references received by the client ORB. A > > BidirectionalOfferPolicy of ALLOW indicates that the ORB may send a > > BI_DIR_GIOP_OFFER service context containing the BiDirID's of the objects in > > POAs with a BidirectionalExportPolicy of ALLOW. What conditions constitutes whether it "may" send a BI_DIR_GIOP_OFFER? This sentence is also misleading in that assumes that the client ORB has some idea of what's going on with the server ORBs and its POA policies. It should not. I also don't really know what "received" means in this context. I would suggest something like: A BidirectionalOfferPolicy of ALLOW indicates that the Client ORB may, depending on configuration and security conditions, send a BI_DIR_GIOP_OFFER service context on GIOP connections that the Client ORB has established with a Server ORB. A Client ORB shall only send the BiDirIds on the GIOP connections used to invoke operations on IORs that contain the same BiDirIds listed in their TAG_BI_DIR_GIOP IOR component. > > An object reference with a > > BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional > > connection. If the ORB BidirectionalOfferPolicy is DENY, and the policy has not > > been overridden for a specific object, then no bi-directional > > connections can be negotiated by the client ORB. What is the definition of a "bi-directional connection"? Does this paragraph assume the client ORB or the server ORB. I'm confused. Perhaps: A bi-directional GIOP connection is a client established GIOP connection that has been negotiated to accept invocations from the server ORB. But then: It would seem illogical to override an OfferPolicy on a client ORB can be overridden for a particular object reference without regard for the client ORB's server capabilities. Let's say that the OfferPolicy is DENY on the client ORB, yet overridden to be ALLOW on object X's object reference. This policy doesn't state which POA BiDir Ids should be sent down the connection to this object, so therefore it probably should be all BiDirIds that belong to the client ORB's POAs. This is a serious concern in ORBs that reuse connections for multiple object references. A Client ORB must make special note for object references with a policy of ALLOW NOT to use already established GIOP connections for BiDir Offers where object references used to connect the server ORB are stated to have a OfferPolicy of DENY. The reverse is also true. A Client ORB must make special note for object references with a an OfferPolicy of DENY NOT to use already established GIOP connections made by object references with a policy of ALLOW. In that light, if an ORB has an OfferPolicy of DENY, and it is overridden to be ALLOW at the object reference level, the sentences above are not strong enough, because once you have an object reference that ALLOWs an offer to be sent, means you open up the whole ORB to that connection. The wording of this policy is a bit off the mark as well. It's not so much a DENY/ALLOW situation, because DENY implies guard against sending offers. The value of the OfferPolicy would make more sense by (ALL,NONE, or specific BiDirIds). > > A BidirectionalAcceptPolicy can be applied to a server ORB, and it can be > > overridden for specific object references received by the server ORB. A > > BidirectionalAcceptPolicy of ALLOW indicates that the ORB may accept and use > > any connections that a client has offered as bi-directional. This policy can be > > overridden for specific objects in which case those objects must not > > be invoked over a bi-directional connection. A > > BidirectionalAcceptPolicy of DENY indicates that the ORB must not > > accept any offers of bi-directional connections, except for invoking > > on objects which have this policy overridden. Is the AcceptPolicy is a server ORB policy? Then what does "overridden for specific objects" mean? Does that mean placing this policy on the on the POA of the server ORB or the client ORB? How does an ORB distinguish between an ORB AcceptPolicy of ALLOW and a POA policy of DENY, when it doesn't even know for which POA the connection is for? Date: Thu, 25 Mar 2004 13:12:02 -0500 (EST) From: Polar Humenn To: "Bergersen, Rebecca" Cc: firewall-traversal-ftf@omg.org Subject: RE: Discussion Issue 4115 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by amethyst.omg.org id i2PIF7Z5024480 On Thu, 25 Mar 2004, Bergersen, Rebecca wrote: > Yes, it's a replacement. The term "bi-directional connection" is used > 13 times in the document, so I don't think we should drop it in this > case. I had thought the term was self-defining - that is, a single > connection that can be used in both directions. The term > "bidirectional" is used a jillion times. It's a standard English term. > The American Heritage Dictionary defines it as: > > 1) bidirectional. The American Heritage® Dictionary of the English > Language: Fourth Edition. 2000. ...Moving or operating in two usually > opposite directions: bidirectional data flow; a bidirectional > microphone. bidi·rection·ali·ty (-nali-t) -NOUNbidi·rection·al·ly... > > I'm not trying to be difficult, but I don't really think we have to > define standard English terms used in a standard way. I'm not arguing on the English definition of "bidirectional", but on the definition of "bidirectional connection". That is to say, when does a "connection" become "bidirectional"? > If you really think it's necessary, however, how about "A bidirectional > connection, as used in the context of this bi-directional GIOP > specification, is a connection in which both endpoints are prepared to > receive object invocations, and which follows the initialization and > usage protocols defined in this specification."? But I believe all this > is self-evident and spelled out in the spec. Are all GIOP connections "bidirectional"? Or does at least one BI_DIR_OFFER must be accepted? What state transitions must a connection go through to be considered bidirectional, and from what direction is the connection considered bidirectional? One could argue both. Statements like the following lead to the confusion: Therefore, when opening a bi-directional connection, the ORB is allowed to send to the server, in the BI_DIR_GIOP IOP::ServiceContext, the BiDirId associated with the objects in that POA. Is it "opening" like a box that already existed, because the ORB is "allowed to send", or is it more determined, such as: To establish a bidirectional connection, the Client ORB shall send to the Server ORB a BI_DIR_GIOP_OFFER in the BI_DIR_GIOP IOP::ServiceContext over an established GIOP connection. > As for the BiDirIds, the spec doesn't specify how many BiDirIds are sent > in an Offer, only that there's a list of them. It's up to the ORB to > decide whether to send all 20,000 or some subset. How is a Standard ORB being used by *any* Application using Standard ORB interfaces supposed to know when to send a subset? > It's also part of the application design. If the app wants to handle > 20,000 bidirectional invocations over a single connection by setting up > all 20,000 callback objects and then establishing a single connection, > it will get the performance it deserves! (Assuming the ORB sends all > BiDirIds that haven't as yet been Offered.) I'm not talking about performance, that is not the issue. I'm talking about the determinacy of the specification. So far, then, the following requirement is implied. The ORB SHALL send ALL of the BiDirIds for ALL of its POAs with a BiDirectionalExportPolicy of ALLOW down EVERY GIOP connection used to contact objects with a BiDirectionalOfferPolicy of ALLOW. Because if the ORB doesn't follow that, then some standard based code won't work deterministically in a standard fashion with standard interface usage. The ORB cannot decide to send only a subset and be compliant. Cheers, -Polar > > However, I'm still confused as to which BiDirIds it includes > > in the in the > > offers? I'll illustrate with a concrete example. > > > > For example, I have an ORB with 20,000 POAs, each has an BiDirectional > > Export Policy of ALLOW. > > > > The Application puts a BirDirectionalOfferPolicy of ALLOW on > > object X's > > IOR because the Application wants object X's implementation > > to invoke an > > operation on the Application's object Y in POA-4521? > > > > As an ORB, am I to supply all 20,000 BiDirIds in this case? > > > > Cheers, > > -Polar > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 25 Mar 2004 14:16:15 -0500 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: firewall-traversal-ftf@omg.org Subject: Re: Discussion Issue 4115 X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] "A BidirectionalExportPolicy can be applied to a POA on a client ORB using the PortableServer::POA::create_POA operation. If the BidirectionalExportPolicy value of the POA is ALLOW, then the objects managed by that POA are allowed to be called back via a bi-directional connection established by the client ORB. When IORs are created for the objects in that POA, the BiDirId for that POA shall be placed in the TAG_BI_DIR_GIOP component of these IORs. ..." [Bergersen, Rebecca] Your paragraph is fine - it's quite clear. However, it doesn't include the fact that the client ORB sends a BI_DIR_GIOP_OFFER service context that contains BiDirIds to the server. How about completing your paragraph with the sentence, "When opening a bidirectional connection, the client ORB sends to the server a BI_DIR_GIOP_OFFER service context that contains the BiDirIds of the objects that may be invoked by the server."? You're right. We do want to say that the client is allowed to do so in this case. However, I have a second thought about the second sentece: "If ... is ALLOW, then ... are allowed to be called back ...". We don't really have a mechanism to allow or disallow objects to be called back. We can merely say that we allow or disallow BiDirIds to be exported. I think that's what exactly this policy for. Thus, I suggest the following replacement. "A BidirectionalExportPolicy can be applied to a POA on a client ORB using the PortableServer::POA::create_POA operation. If the BidirectionalExportPolicy value of the POA is ALLOW, the client ORB is allowed to send to the server, in the BI_DIR_GIOP IOP::ServiceContext, the BiDirId associated with the objects in that POA. In addition, when IORs are created for the objects in that POA, the BiDirId for that POA shall be placed in the TAG_BI_DIR_GIOP component of those IORs. If the BidirectionalExportPolicy value of the POA is DENY, then a TAG_BI_DIR_GIOP component shall not be placed in the IOR of the objects in that POA, and the BiDirId for objects in that POA shall not be sent in any BI_DIR_GIOP_OFFER service contexts." A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden for specific object references received by the client ORB. A BidirectionalOfferPolicy of ALLOW indicates that the ORB may send a BI_DIR_GIOP_OFFER service context containing the BiDirID's of the objects in POAs with a BidirectionalExportPolicy of ALLOW. I think we can just state the fact about some object references on the client ORB or that the client ORB has some object references without saying that they are from somewhere outside. To the extreme, if I'm a hacker and I know how your ORB constructs your object ID, I might be able to construct object references from nowhere and try to probe objects on your ORB. [Bergersen, Rebecca] Fair enough. Any suggestions? "A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden for specific object references on the client ORB. ..." Cheers, Joncheng A BidirectionalAcceptPolicy can be applied to a server ORB, and it can be overridden for specific object references received by the server ORB. A BidirectionalAcceptPolicy of ALLOW indicates that the ORB may accept and use any connections that a client has offered as bi-directional. This policy can be overridden for specific objects in which case those objects must not be invoked over a bi-directional connection. A BidirectionalAcceptPolicy of DENY indicates that the ORB must not accept any offers of bi-directional connections, except for invoking on objects which have this policy overridden. Is the AcceptPolicy is a server ORB policy? Then what does "overridden for specific objects" mean? Does that mean placing this policy on the on the POA of the server ORB or the client ORB? How does an ORB distinguish between an ORB AcceptPolicy of ALLOW and a POA policy of DENY, when it doesn't even know for which POA the connection is for? Just like the Offer policy, an Accept policy can be applied to a server ORB and to an object (in this case, the callback reference). The server ORB may have an Accept policy of DENY (implying that the default is to deny any Offer), but a bidirectional connection to specific callback object can be accepted by the server by overriding that object's policy set with an Accept policy. Again, it's the application that applies these policies, so it *may* or may not decide to override. My understanding is that the BidirectionalAcceptPolicy is a client policy on the server ORB. In other words, the server ORB uses this policy when it acts as a client making a callback to the objects on the client ORB. Am I right? [Bergersen, Rebecca] That's the way I understood it, too. However, it can also be applied not just to the ORB, but also to the callback object through an override. Actually, I like the symmetry of this design. Me too, but we have to be very precise on the language that we use in the spec. Otherwise, it'll be very confusing. In particular, I believe that the word "object" in the following paragraph should be replaced by "object reference" The Client receives an object from somewhere, applies an Offer policy to it and invokes on it. The Server gets a callback object from somewhere, and acting as a Client in the ensuing communication, applies an Accept policy to it and invokes on it. In both cases the default ORB policy can be overridden on a "received" object by the "client," based on the application's logic. [Bergersen, Rebecca] Sure, object reference is okay. I'm new to the Firewall task force and the BiDir stuff. If I misunderstand anything, please let me know. [Bergersen, Rebecca] And vice-versa.... Best regards, Joncheng Kuo -Polar Date: Thu, 25 Mar 2004 18:22:27 -0500 (EST) From: Polar Humenn To: "Bergersen, Rebecca" Cc: firewall-traversal-ftf@omg.org Subject: RE: Discussion Issue 4115 On Thu, 25 Mar 2004, Bergersen, Rebecca wrote: > > Are all GIOP connections "bidirectional"? > > No, only those in which the setup protocol has been followed - a BI_DIR_GIOP_OFFER has been sent over a connection and has been accepted by the server. > > > Or does at least one BI_DIR_OFFER must be accepted? > > I'm concerned with your use of "at least." Sending an offer over one > connection doesn't make other connections bidirectional, only the one > over which the offer was sent. I mean "at least" in the literal sense. The protocol allows for multiple OFFERS to be sent in multiple ServiceContexts, and in Multiple Negotiation Session messages, and in multiple arbitrary GIOP Request Messages. It only takes one successful offer for a connection to become bidirectional. Right? > > What state transitions must a connection > > go through to be considered bidirectional > > A BI_DIR_GIOP_OFFER service context is sent from a client wishing to > establish the connection as bidirectional and the server has returned a > BI_DIR_GIOP_ACCEPT service context (maybe after some negotiation) with a > value of BI_DIR_NO_ERROR. Good. So that text or something like it should be in the spec. I would say that the ACCEPT is not even necessary in the definition. For instance, the statement that says the ORB shall not invoke on a connection that is bidirectional. If you are in the process of negotiating a bidirectional connection, you can effectively send an invocation before the ACCEPT is receieved, but after the server has sent it. And that invocation would technically would be a violation, especially since the Reply would come back on the now bidirectional connection. > > and from what > > direction is the > > connection considered bidirectional? One could argue both. > > I would argue both. Either end of the connection can both receive > invocations and perform invocations. However, only the client can > initiate the protocol. > > Statements like the following lead to the confusion: > > > > Therefore, when opening a bi-directional connection, the > > ORB is allowed > > to send to the server, in the BI_DIR_GIOP IOP::ServiceContext, the > > BiDirId associated with the objects in that POA. > > > > Is it "opening" like a box that already existed, because the ORB is > > "allowed to send", or is it more determined, such as: > > > > To establish a bidirectional connection, the Client ORB > > shall send to > > the Server ORB a BI_DIR_GIOP_OFFER in the BI_DIR_GIOP > > IOP::ServiceContext over an established GIOP connection. > > > > My take on the process is that a connection is set up on the socket > level, below GIOP. Assume success. We both "know" the process, I'd just rather have it spelled out correctly and sufficiently in the spec. Otherwise, there'll be problems. > Then a GIOP LocateRequest is sent to make sure you're talking directly > to the right endpoint. Assume success. NB. Not required by GIOP. > Then a GIOP Request is sent with a BI_DIR_GIOP_OFFER > service context. Or in NegotiationSession Message. > And the protocol continues. So, "opening" a bidirectional connection is > the same as beginning the establishment of the bidirectionality of a > connection through following the BI_DIR protocol. That is a conclusion. Why don't we reword the specification in terms of definitions and requirements. Here is your text and mine (with some clarifications). A BI_DIR_GIOP_OFFER service context is sent from a client wishing to establish the connection as bidirectional. To establish a bidirectional connection, the client ORB shall send to the server ORB a BI_DIR_GIOP_OFFER in the BI_DIR_GIOP IOP::ServiceContext over an established GIOP connection. > > > As for the BiDirIds, the spec doesn't specify how many > > BiDirIds are sent > > > in an Offer, only that there's a list of them. It's up to > > the ORB to > > > decide whether to send all 20,000 or some subset. > > > > How is a Standard ORB being used by *any* Application using > > Standard ORB > > interfaces supposed to know when to send a subset? > > > > Well, one scenario might be for the ORB to have configuration values > that define the upper and lower limits for numbers of BiDirs to send at > one time. > > A lower limit of 1 might indicate that a BI_DIR_GIOP_OFFER > service context should not be sent, even if the policy allows it, if > there are no BiDirIds to be included. The upper limit is whatever the > user has specified for performance or other reasons. However, you're > right - determinancy is an issue. I would expect that the upper limit > in the above scenario is "unlimited" and if the user changes it, then > the user's application better know enough to make sure it sets up enough > bidirectional connections to cover all of the BiDirIds. It's not > difficult since the app knows how many bidirids it has and knows what > the upper limit was set to. > > It's an implementation detail of the ORB. However, I would expect all > of the ORBs to be implemented such that all of the BiDirIds that have > not been already Offered would be included in the next Offer that's > made. This behavior would be documented by the ORB vendor so the app > designer could decide that it might be better to set up call-back > objects with BiDirIds and establish the bidirectional connections for > them a few at a time rather than 20,000 in one swell foop! The implementation detail may be how many BiDirIds to send in a single or multiple messages. The application designer may choose one ORB over the other because of the way it gets the ids there. But all the ORBs better behave in the same abstract way, or you end up with silly work arounds, vendor-lockin (which may be desirable), and portability headaches. So, according to the spec right now, the ORB has to make sure all the BiDirIds get there to every open connection as well as future connections. That means when a new BIDIR POA is created, the ORB must also make offers to all open connections as a result. I don't mind this, as long as it is completely stated in the specification, and cannot be argued about. However, since the application controls the offer feature, I'd say give the application more of its conntrol. Let the Application specify the BiDirIDs (since it created them anyway) to OFFER over the wire to particular objects. That cuts down on a whole bunch of the ORB having to do everything for not much. If I create POA-X with callback object X, and BiDirId-X, and I'm about to send it in an invocation to Object Y, I can put BiDirId-X in an Offer policy on ObjectY's object reference, and the ORB knows what to do with it. Send an Offer with only BiDirId-X down the line to Object Y's server. Simplisitic and determininistic. > > > It's also part of the application design. If the app wants > > to handle > > > 20,000 bidirectional invocations over a single connection > > by setting up > > > all 20,000 callback objects and then establishing a single > > connection, > > > it will get the performance it deserves! (Assuming the ORB sends all > > > BiDirIds that haven't as yet been Offered.) > > > > I'm not talking about performance, that is not the issue. I'm talking > > about the determinacy of the specification. > > > > So far, then, the following requirement is implied. > > > > The ORB SHALL send ALL of the BiDirIds for ALL of its POAs with a > > BiDirectionalExportPolicy of ALLOW down EVERY GIOP connection used to > > contact objects with a BiDirectionalOfferPolicy of ALLOW. > > > > Oh, I wouldn't agree to that statement! If I'm interpreting it > correctly, you are saying that every bidir connection will handle every > one of the BiDirIds. That's surely not the intent of this spec. See my > discussion above. I realize the intent. that's why I brought up the discussion. You cannot tell me the requirement is not the result of the current specification. How else would you have standard behavior? Cheers, -Polar > > Because if the ORB doesn't follow that, then some standard based code > > won't work deterministically in a standard fashion with > > standard interface > > usage. > > > > The ORB cannot decide to send only a subset and be compliant. > > > > Cheers, > > -Polar > > > > > > > > > > However, I'm still confused as to which BiDirIds it includes > > > > in the in the > > > > offers? I'll illustrate with a concrete example. > > > > > > > > For example, I have an ORB with 20,000 POAs, each has an > > BiDirectional > > > > Export Policy of ALLOW. > > > > > > > > The Application puts a BirDirectionalOfferPolicy of ALLOW on > > > > object X's > > > > IOR because the Application wants object X's implementation > > > > to invoke an > > > > operation on the Application's object Y in POA-4521? > > > > > > > > As an ORB, am I to supply all 20,000 BiDirIds in this case? > > > > > > > > Cheers, > > > > -Polar > > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 25 Mar 2004 20:32:48 -0500 (EST) From: Polar Humenn To: "Bergersen, Rebecca" Cc: Juergen Boldt Subject: RE: Discussion Issue 4115 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by amethyst.omg.org id i2Q1ZtZ5028934 Rebecca, The email you have registered with the OMG is: "Bergersen, Rebecca" The email you are using to send messages lately is: "Bergersen, Rebecca" That's why your email is probably bouncing from the ftf list. Forgive me for not getting back to you sooner on this. I only noticed this because your personal messages to me (i.e. without the list name in the address fields ) to me showed up in my "Unknown Sender" box (which I don't plow through too often). Strange, I thought, I have you in my address book. Then I looked in my address book and your addresses don't match. I have only the Rebecca.Bergersen@iona.com address, which I am sure is the only one Juergen has as well. Hope you fix the problem. Cheers, -Polar On Thu, 25 Mar 2004, Bergersen, Rebecca wrote: > Hmmm.... That's upsetting. I called and talked with Juergen and he thought it was due to the attacks they've been going through, but maybe it's on my side. Oh well, I'll look into it tomorrow. > > Thanks, > Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Thursday, March 25, 2004 6:25 PM > > To: Bergersen, Rebecca > > Subject: RE: Discussion Issue 4115 > > > > > > > > On Thu, 25 Mar 2004, Bergersen, Rebecca wrote: > > > > > Polar, is your mail getting delivered by the firewall-traversal-ftf > > > reflector at OMG? Everything I send to that address, to the MARS > > > mailing list, to Juergen and to Andrew is bouncing. However, I'm > > > receiving mail from the MOF ftf mailing lists.... > > > > I seem to have no problem. I'm getting the messages I have sent to the > > list from the list. > > > > Cheers, > > -Polar > > > > > > > > --Rebecca > > > > > > > -----Original Message----- > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > Sent: Thursday, March 25, 2004 1:12 PM > > > > To: Bergersen, Rebecca > > > > Cc: firewall-traversal-ftf@omg.org > > > > Subject: RE: Discussion Issue 4115 > > > > > > > > > > > > On Thu, 25 Mar 2004, Bergersen, Rebecca wrote: > > > > > > > > > Yes, it's a replacement. The term "bi-directional > > > > connection" is used > > > > > 13 times in the document, so I don't think we should > > drop it in this > > > > > case. I had thought the term was self-defining - that > > is, a single > > > > > connection that can be used in both directions. The term > > > > > "bidirectional" is used a jillion times. It's a standard > > > > English term. > > > > > The American Heritage Dictionary defines it as: > > > > > > > > > > 1) bidirectional. The American Heritage® Dictionary of > > the English > > > > > Language: Fourth Edition. 2000. ...Moving or operating in > > > > two usually > > > > > opposite directions: bidirectional data flow; a bidirectional > > > > > microphone. bidi·rection·ali·ty (-nali-t) > > -NOUNbidi·rection·al·ly... > > > > > > > > > > I'm not trying to be difficult, but I don't really > > think we have to > > > > > define standard English terms used in a standard way. > > > > > > > > I'm not arguing on the English definition of "bidirectional", > > > > but on the > > > > definition of "bidirectional connection". That is to say, > > when does a > > > > "connection" become "bidirectional"? > > > > > > > > > If you really think it's necessary, however, how about "A > > > > bidirectional > > > > > connection, as used in the context of this bi-directional GIOP > > > > > specification, is a connection in which both endpoints are > > > > prepared to > > > > > receive object invocations, and which follows the > > initialization and > > > > > usage protocols defined in this specification."? But I > > > > believe all this > > > > > is self-evident and spelled out in the spec. > > > > > > > > Are all GIOP connections "bidirectional"? Or does at least one > > > > BI_DIR_OFFER must be accepted? What state transitions must a > > > > connection > > > > go through to be considered bidirectional, and from what > > > > direction is the > > > > connection considered bidirectional? One could argue both. > > > > > > > > Statements like the following lead to the confusion: > > > > > > > > Therefore, when opening a bi-directional connection, the > > > > ORB is allowed > > > > to send to the server, in the BI_DIR_GIOP > > IOP::ServiceContext, the > > > > BiDirId associated with the objects in that POA. > > > > > > > > Is it "opening" like a box that already existed, because > > the ORB is > > > > "allowed to send", or is it more determined, such as: > > > > > > > > To establish a bidirectional connection, the Client ORB > > > > shall send to > > > > the Server ORB a BI_DIR_GIOP_OFFER in the BI_DIR_GIOP > > > > IOP::ServiceContext over an established GIOP connection. > > > > > > > > > As for the BiDirIds, the spec doesn't specify how many > > > > BiDirIds are sent > > > > > in an Offer, only that there's a list of them. It's up to > > > > the ORB to > > > > > decide whether to send all 20,000 or some subset. > > > > > > > > How is a Standard ORB being used by *any* Application using > > > > Standard ORB > > > > interfaces supposed to know when to send a subset? > > > > > > > > > It's also part of the application design. If the app wants > > > > to handle > > > > > 20,000 bidirectional invocations over a single connection > > > > by setting up > > > > > all 20,000 callback objects and then establishing a single > > > > connection, > > > > > it will get the performance it deserves! (Assuming the > > ORB sends all > > > > > BiDirIds that haven't as yet been Offered.) > > > > > > > > I'm not talking about performance, that is not the issue. > > I'm talking > > > > about the determinacy of the specification. > > > > > > > > So far, then, the following requirement is implied. > > > > > > > > The ORB SHALL send ALL of the BiDirIds for ALL of its POAs with a > > > > BiDirectionalExportPolicy of ALLOW down EVERY GIOP > > connection used to > > > > contact objects with a BiDirectionalOfferPolicy of ALLOW. > > > > > > > > Because if the ORB doesn't follow that, then some > > standard based code > > > > won't work deterministically in a standard fashion with > > > > standard interface > > > > usage. > > > > > > > > The ORB cannot decide to send only a subset and be compliant. > > > > > > > > Cheers, > > > > -Polar > > > > > > > > > > > > > > > > > > However, I'm still confused as to which BiDirIds it includes > > > > > > in the in the > > > > > > offers? I'll illustrate with a concrete example. > > > > > > > > > > > > For example, I have an ORB with 20,000 POAs, each has an > > > > BiDirectional > > > > > > Export Policy of ALLOW. > > > > > > > > > > > > The Application puts a BirDirectionalOfferPolicy of ALLOW on > > > > > > object X's > > > > > > IOR because the Application wants object X's implementation > > > > > > to invoke an > > > > > > operation on the Application's object Y in POA-4521? > > > > > > > > > > > > As an ORB, am I to supply all 20,000 BiDirIds in this case? > > > > > > > > > > > > Cheers, > > > > > > -Polar > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > Polar Humenn Adiron, LLC > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Mon, 29 Mar 2004 12:29:34 -0500 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Polar Humenn CC: "Bergersen, Rebecca" , firewall-traversal-ftf@omg.org Subject: Re: Discussion Issue 4115 X-Virus-Scanned: Symantec AntiVirus Scan Engine Polar Humenn wrote: Here is your text and mine (with some clarifications). A BI_DIR_GIOP_OFFER service context is sent from a client wishing to establish the connection as bidirectional. To establish a bidirectional connection, the client ORB shall send to the server ORB a BI_DIR_GIOP_OFFER in the BI_DIR_GIOP IOP::ServiceContext over an established GIOP connection. Over an established GIOP connection or a to-be-established GIOP connection (in the case of NegotiationSession), I think. So, according to the spec right now, the ORB has to make sure all the BiDirIds get there to every open connection as well as future connections. That means when a new BIDIR POA is created, the ORB must also make offers to all open connections as a result. I don't mind this, as long as it is completely stated in the specification, and cannot be argued about. However, since the application controls the offer feature, I'd say give the application more of its conntrol. Let the Application specify the BiDirIDs (since it created them anyway) to OFFER over the wire to particular objects. That cuts down on a whole bunch of the ORB having to do everything for not much. If I create POA-X with callback object X, and BiDirId-X, and I'm about to send it in an invocation to Object Y, I can put BiDirId-X in an Offer policy on ObjectY's object reference, and the ORB knows what to do with it. Send an Offer with only BiDirId-X down the line to Object Y's server. Simplisitic and determininistic. In summary, it seems that we need to expand the BI_DIR_OFFER policy to have more values: ALL -- all BiDirIds on POAs that have BI_DIR_EXPORT policy of ALLOW will be sent to the server (unless they have been sent and accepted) NONE -- no BiDirIds will be allowed to be sent to the server (on object refereces with this policy value) LISTED -- a list of POAs (or objects) whose BiDirIds are to be sent to the server (unless they have been sent and accepted) Besides, we may also want a BI_DIR_ID policy that allows an application to either give a BiDirId to a POA or ask the ORB to create one when the BI_DIR_EXPORT policy is set to ALLOW on the POA. Joncheng Subject: RE: Discussion Issue 4115 Date: Fri, 2 Apr 2004 12:03:54 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion Issue 4115 Thread-Index: AcQVtHJJQhc4haf3QcmDClDdNQSO6gDHOHDg From: "Bergersen, Rebecca" To: "Joncheng Kuo" , "Polar Humenn" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i34BZeAQ012910 I think the matter of how many BiDirIds get sent should just be left to the implementation. The programmer can ad the documentation and adjust accordingly. There may be valid implementation reasons for one ORB to send all and for another to send five and for another to send whatever the configuration limits are. There's no reason to insist on a particular number. As for a policy governing whether the user or the ORB generates the BiDirId, I think the ORB should always generate the BiDirId. It's the only way to insure compatibility with persistent BiDirIds and ones being created in different components of the system. User-generated IDs would be a big source of errors. --Rebecca > -----Original Message----- > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > Sent: Monday, March 29, 2004 12:30 PM > To: Polar Humenn > Cc: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > Subject: Re: Discussion Issue 4115 > > > Polar Humenn wrote: > > >Here is your text and mine (with some clarifications). > > > > A BI_DIR_GIOP_OFFER service context is sent from a client wishing to > > establish the connection as bidirectional. To establish a > bidirectional > > connection, the client ORB shall send to the server ORB a > > BI_DIR_GIOP_OFFER in the BI_DIR_GIOP IOP::ServiceContext over an > > established GIOP connection. > > > Over an established GIOP connection or a to-be-established GIOP > connection (in the case of NegotiationSession), I think. > > >So, according to the spec right now, the ORB has to make sure all the > >BiDirIds get there to every open connection as well as > future connections. > >That means when a new BIDIR POA is created, the ORB must > also make offers > >to all open connections as a result. > > > >I don't mind this, as long as it is completely stated in the > >specification, and cannot be argued about. However, since > the application > >controls the offer feature, I'd say give the application more of its > >conntrol. Let the Application specify the BiDirIDs (since > it created them > >anyway) to OFFER over the wire to particular objects. > > > >That cuts down on a whole bunch of the ORB having to do > everything for not > >much. > > > >If I create POA-X with callback object X, and BiDirId-X, and > I'm about to > >send it in an invocation to Object Y, I can put BiDirId-X in an Offer > >policy on ObjectY's object reference, and the ORB knows what > to do with > >it. Send an Offer with only BiDirId-X down the line to > Object Y's server. > >Simplisitic and determininistic. > > > In summary, it seems that we need to expand the BI_DIR_OFFER > policy to > have more values: > > ALL -- all BiDirIds on POAs that have BI_DIR_EXPORT policy of > ALLOW will > be sent to the server (unless they have been sent and accepted) > NONE -- no BiDirIds will be allowed to be sent to the server > (on object > refereces with this policy value) > LISTED -- a list of POAs (or objects) whose BiDirIds are to > be sent to > the server (unless they have been sent and accepted) > > Besides, we may also want a BI_DIR_ID policy that allows an > application > to either give a BiDirId to a POA or ask the ORB to create > one when the > BI_DIR_EXPORT policy is set to ALLOW on the POA. > > Joncheng > > > > Subject: RE: Discussion Issue 4115 Date: Fri, 2 Apr 2004 12:18:43 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion Issue 4115 Thread-Index: AcQSwZvI0YwhdQZqQJ6lBszEQ3vjTwGE6y8A From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: , "Bergersen, Rebecca" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i34AYsAQ012801 > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Thursday, March 25, 2004 6:22 PM > To: Bergersen, Rebecca > Cc: firewall-traversal-ftf@omg.org > Subject: RE: Discussion Issue 4115 > > > On Thu, 25 Mar 2004, Bergersen, Rebecca wrote: > > > > Are all GIOP connections "bidirectional"? > > > > No, only those in which the setup protocol has been > followed - a BI_DIR_GIOP_OFFER has been sent over a > connection and has been accepted by the server. > > > > > Or does at least one BI_DIR_OFFER must be accepted? > > > > I'm concerned with your use of "at least." Sending an > offer over one > > connection doesn't make other connections bidirectional, > only the one > > over which the offer was sent. > > I mean "at least" in the literal sense. The protocol allows > for multiple > OFFERS to be sent in multiple ServiceContexts, and in > Multiple Negotiation > Session messages, and in multiple arbitrary GIOP Request > Messages. It only > takes one successful offer for a connection to become bidirectional. > Right? Right, but why would you make multiple offers over the same connection? > > > > What state transitions must a connection > > > go through to be considered bidirectional > > > > A BI_DIR_GIOP_OFFER service context is sent from a client wishing to > > establish the connection as bidirectional and the server > has returned a > > BI_DIR_GIOP_ACCEPT service context (maybe after some > negotiation) with a > > value of BI_DIR_NO_ERROR. > > Good. So that text or something like it should be in the > spec. I would say > that the ACCEPT is not even necessary in the definition. For > instance, the > statement that says the ORB shall not invoke on a connection that is > bidirectional. If you are in the process of negotiating a > bidirectional > connection, you can effectively send an invocation before the > ACCEPT is > receieved, but after the server has sent it. And that invocation would > technically would be a violation, especially since the Reply > would come > back on the now bidirectional connection. > > > > and from what > > > direction is the > > > connection considered bidirectional? One could argue both. > > > > I would argue both. Either end of the connection can both receive > > invocations and perform invocations. However, only the client can > > initiate the protocol. > > > Statements like the following lead to the confusion: > > > > > > Therefore, when opening a bi-directional connection, the > > > ORB is allowed > > > to send to the server, in the BI_DIR_GIOP > IOP::ServiceContext, the > > > BiDirId associated with the objects in that POA. > > > > > > Is it "opening" like a box that already existed, because > the ORB is > > > "allowed to send", or is it more determined, such as: > > > > > > To establish a bidirectional connection, the Client ORB > > > shall send to > > > the Server ORB a BI_DIR_GIOP_OFFER in the BI_DIR_GIOP > > > IOP::ServiceContext over an established GIOP connection. > > > > > > > My take on the process is that a connection is set up on the socket > > level, below GIOP. Assume success. > > We both "know" the process, I'd just rather have it spelled > out correctly > and sufficiently in the spec. Otherwise, there'll be problems. > > > Then a GIOP LocateRequest is sent to make sure you're > talking directly > > to the right endpoint. Assume success. > > NB. Not required by GIOP. > > > Then a GIOP Request is sent with a BI_DIR_GIOP_OFFER > > service context. > > Or in NegotiationSession Message. > > > And the protocol continues. So, "opening" a bidirectional > connection is > > the same as beginning the establishment of the bidirectionality of a > > connection through following the BI_DIR protocol. > > That is a conclusion. Why don't we reword the specification > in terms of > definitions and requirements. > > Here is your text and mine (with some clarifications). > > A BI_DIR_GIOP_OFFER service context is sent from a client wishing to > establish the connection as bidirectional. To establish a > bidirectional > connection, the client ORB shall send to the server ORB a > BI_DIR_GIOP_OFFER in the BI_DIR_GIOP IOP::ServiceContext over an > established GIOP connection. > > > > > As for the BiDirIds, the spec doesn't specify how many > > > BiDirIds are sent > > > > in an Offer, only that there's a list of them. It's up to > > > the ORB to > > > > decide whether to send all 20,000 or some subset. > > > > > > How is a Standard ORB being used by *any* Application using > > > Standard ORB > > > interfaces supposed to know when to send a subset? > > > > > > > Well, one scenario might be for the ORB to have configuration values > > that define the upper and lower limits for numbers of > BiDirs to send at > > one time. > > > > A lower limit of 1 might indicate that a BI_DIR_GIOP_OFFER > > service context should not be sent, even if the policy allows it, if > > there are no BiDirIds to be included. The upper limit is > whatever the > > user has specified for performance or other reasons. > However, you're > > right - determinancy is an issue. I would expect that the > upper limit > > in the above scenario is "unlimited" and if the user > changes it, then > > the user's application better know enough to make sure it > sets up enough > > bidirectional connections to cover all of the BiDirIds. It's not > > difficult since the app knows how many bidirids it has and > knows what > > the upper limit was set to. > > > > It's an implementation detail of the ORB. However, I would > expect all > > of the ORBs to be implemented such that all of the BiDirIds > that have > > not been already Offered would be included in the next Offer that's > > made. This behavior would be documented by the ORB vendor > so the app > > designer could decide that it might be better to set up call-back > > objects with BiDirIds and establish the bidirectional > connections for > > them a few at a time rather than 20,000 in one swell foop! > > The implementation detail may be how many BiDirIds to send in > a single or > multiple messages. The application designer may choose one > ORB over the > other because of the way it gets the ids there. But all the > ORBs better > behave in the same abstract way, or you end up with silly > work arounds, > vendor-lockin (which may be desirable), and portability headaches. > > So, according to the spec right now, the ORB has to make sure all the > BiDirIds get there to every open connection as well as future > connections. > That means when a new BIDIR POA is created, the ORB must also > make offers > to all open connections as a result. > No, that's not what the spec says. It does not say that "all the BiDirIds get there to every open connection as well as future connections." Nor does it say that when a new BiDir POA is created the ORB must make offers to all open connections." The fact that there are unoffered BiDirIds does not imply that the ORB has to do anything with them. The ORB only has to offer one or more BiDirIds when the application wants to establish a new BiDir connection, as detailed above. And I think the number of BiDirIds offered should be left as an implementation detail of the ORB - one or five or all should be up to the implementation. The user can read the doc about how the ORB operates - the number could be configurable or for some implementation reason maxed out at some number that doesn't apply to a different implementation. > I don't mind this, as long as it is completely stated in the > specification, and cannot be argued about. However, since the > application > controls the offer feature, I'd say give the application more of its > conntrol. Let the Application specify the BiDirIDs (since it > created them > anyway) to OFFER over the wire to particular objects. > > That cuts down on a whole bunch of the ORB having to do > everything for not > much. > > If I create POA-X with callback object X, and BiDirId-X, and > I'm about to > send it in an invocation to Object Y, I can put BiDirId-X in an Offer > policy on ObjectY's object reference, and the ORB knows what > to do with > it. Send an Offer with only BiDirId-X down the line to Object > Y's server. > Simplisitic and determininistic. > > > > > It's also part of the application design. If the app wants > > > to handle > > > > 20,000 bidirectional invocations over a single connection > > > by setting up > > > > all 20,000 callback objects and then establishing a single > > > connection, > > > > it will get the performance it deserves! (Assuming the > ORB sends all > > > > BiDirIds that haven't as yet been Offered.) > > > > > > I'm not talking about performance, that is not the issue. > I'm talking > > > about the determinacy of the specification. > > > > > > So far, then, the following requirement is implied. > > > > > > The ORB SHALL send ALL of the BiDirIds for ALL of its POAs with a > > > BiDirectionalExportPolicy of ALLOW down EVERY GIOP > connection used to > > > contact objects with a BiDirectionalOfferPolicy of ALLOW. > > > > > > > Oh, I wouldn't agree to that statement! If I'm interpreting it > > correctly, you are saying that every bidir connection will > handle every > > one of the BiDirIds. That's surely not the intent of this > spec. See my > > discussion above. > > I realize the intent. that's why I brought up the discussion. > You cannot > tell me the requirement is not the result of the current > specification. > How else would you have standard behavior? > > Cheers, > -Polar > > > > > Because if the ORB doesn't follow that, then some > standard based code > > > won't work deterministically in a standard fashion with > > > standard interface > > > usage. > > > > > > The ORB cannot decide to send only a subset and be compliant. > > > > > > Cheers, > > > -Polar > > > > > > > > > > > > > > However, I'm still confused as to which BiDirIds it includes > > > > > in the in the > > > > > offers? I'll illustrate with a concrete example. > > > > > > > > > > For example, I have an ORB with 20,000 POAs, each has an > > > BiDirectional > > > > > Export Policy of ALLOW. > > > > > > > > > > The Application puts a BirDirectionalOfferPolicy of ALLOW on > > > > > object X's > > > > > IOR because the Application wants object X's implementation > > > > > to invoke an > > > > > operation on the Application's object Y in POA-4521? > > > > > > > > > > As an ORB, am I to supply all 20,000 BiDirIds in this case? > > > > > > > > > > Cheers, > > > > > -Polar > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > Polar Humenn Adiron, LLC > > > > > mailto:polar@adiron.com 2-212 CST > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > Date: Fri, 2 Apr 2004 13:38:19 -0500 (EST) From: Polar Humenn To: "Bergersen, Rebecca" Cc: Joncheng Kuo , firewall-traversal-ftf@omg.org Subject: RE: Discussion Issue 4115 On Fri, 2 Apr 2004, Bergersen, Rebecca wrote: > I think the matter of how many BiDirIds get sent should just be left to > the implementation. The programmer can ad the documentation and adjust > accordingly. There may be valid implementation reasons for one ORB to > send all and for another to send five and for another to send whatever > the configuration limits are. There's no reason to insist on a > particular number. I'm not arguing about whether chunks of a particular number of BiDirIds get sent, or even in what order. The fact is that in this model, according to the standard, the ORB must offer/send EVERY one its has, (and future ones, activated?) since the application has no standard programatic control over it. If you have to check the particular ORB vendor's manual, then you are outside of the standard, and that ruins portability. As a result, we don't need anything standardize anything on the ORB/POA interface, since it really won't mean anything useful. If I put an OfferPolicy of ALLOW on a particular object reference, how am I going to be assured that the offer for any particular object I have got sent down that pipe, unless, I'm sure that the ORB sent them ALL? How do I proceed with processing incoming requests for that object in a standard manner? Just wait, hope, take bets, pray for it? > As for a policy governing whether the user or the ORB generates the > BiDirId, I think the ORB should always generate the BiDirId. It's the > only way to insure compatibility with persistent BiDirIds and ones being > created in different components of the system. This is issue 6313. The spec says that the POA must generate a "random" BiDirId, which for persistent objects is really a contradiction. This needs to be clarified. > User-generated IDs would be a big source of errors. I'll agree. You just need a way to specify that the BiDirId in persistent objects will be the same every time. Cheers, -Polar > --Rebecca > > > -----Original Message----- > > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > > Sent: Monday, March 29, 2004 12:30 PM > > To: Polar Humenn > > Cc: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > > Subject: Re: Discussion Issue 4115 > > > > > > Polar Humenn wrote: > > > > >Here is your text and mine (with some clarifications). > > > > > > A BI_DIR_GIOP_OFFER service context is sent from a client wishing to > > > establish the connection as bidirectional. To establish a > > bidirectional > > > connection, the client ORB shall send to the server ORB a > > > BI_DIR_GIOP_OFFER in the BI_DIR_GIOP IOP::ServiceContext over an > > > established GIOP connection. > > > > > Over an established GIOP connection or a to-be-established GIOP > > connection (in the case of NegotiationSession), I think. > > > > >So, according to the spec right now, the ORB has to make sure all the > > >BiDirIds get there to every open connection as well as > > future connections. > > >That means when a new BIDIR POA is created, the ORB must > > also make offers > > >to all open connections as a result. > > > > > >I don't mind this, as long as it is completely stated in the > > >specification, and cannot be argued about. However, since > > the application > > >controls the offer feature, I'd say give the application more of its > > >conntrol. Let the Application specify the BiDirIDs (since > > it created them > > >anyway) to OFFER over the wire to particular objects. > > > > > >That cuts down on a whole bunch of the ORB having to do > > everything for not > > >much. > > > > > >If I create POA-X with callback object X, and BiDirId-X, and > > I'm about to > > >send it in an invocation to Object Y, I can put BiDirId-X in an Offer > > >policy on ObjectY's object reference, and the ORB knows what > > to do with > > >it. Send an Offer with only BiDirId-X down the line to > > Object Y's server. > > >Simplisitic and determininistic. > > > > > In summary, it seems that we need to expand the BI_DIR_OFFER > > policy to > > have more values: > > > > ALL -- all BiDirIds on POAs that have BI_DIR_EXPORT policy of > > ALLOW will > > be sent to the server (unless they have been sent and accepted) > > NONE -- no BiDirIds will be allowed to be sent to the server > > (on object > > refereces with this policy value) > > LISTED -- a list of POAs (or objects) whose BiDirIds are to > > be sent to > > the server (unless they have been sent and accepted) > > > > Besides, we may also want a BI_DIR_ID policy that allows an > > application > > to either give a BiDirId to a POA or ask the ORB to create > > one when the > > BI_DIR_EXPORT policy is set to ALLOW on the POA. > > > > Joncheng > > > > > > > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: Discussion Issue 4115 Date: Fri, 2 Apr 2004 14:19:21 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion Issue 4115 Thread-Index: AcQY4h7EGx+qQT0/RVqL2TEjUcNLSwAAkhAQ From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: "Joncheng Kuo" , , "Bergersen, Rebecca" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i34BhHAQ012966 Hi! Comments inline. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Friday, April 02, 2004 1:38 PM > To: Bergersen, Rebecca > Cc: Joncheng Kuo; firewall-traversal-ftf@omg.org > Subject: RE: Discussion Issue 4115 > > > > On Fri, 2 Apr 2004, Bergersen, Rebecca wrote: > > > I think the matter of how many BiDirIds get sent should > just be left to > > the implementation. The programmer can ad the > documentation and adjust > > accordingly. There may be valid implementation reasons for > one ORB to > > send all and for another to send five and for another to > send whatever > > the configuration limits are. There's no reason to insist on a > > particular number. > > I'm not arguing about whether chunks of a particular number > of BiDirIds > get sent, or even in what order. > > The fact is that in this model, according to the standard, > the ORB must > offer/send EVERY one its has, (and future ones, activated?) since the > application has no standard programatic control over it. > The user's control is to put offer policies on connections. The user must know how the ORB will deal with the BiDirIds, but it isn't necessary or even desirable for every ORB to offer only a fixed standardized strategy. It's better to let the implementation define a strategy that's tuned for the typical situations the ORB will be deployed into. I believe a configurable value is best, but another designer may want a fixed value and a third want all unoffered Ids, every time, as you do. It's trivial to write a method that can handle any of those eventualities, that could be easily ported among them. Of course we could declare one standard strategy of always offereing all, but then you can have the pathological case you mentioned earlier with 20,000 BiDirIds all offered over a single connection. I think it's better to let the implementations innovate to avoid such pathologies. > If you have to check the particular ORB vendor's manual, then you are > outside of the standard, and that ruins portability. > > As a result, we don't need anything standardize anything on > the ORB/POA > interface, since it really won't mean anything useful. > > If I put an OfferPolicy of ALLOW on a particular object > reference, how am > I going to be assured that the offer for any particular > object I have got > sent down that pipe, unless, I'm sure that the ORB sent them ALL? > > How do I proceed with processing incoming requests for that > object in a > standard manner? Just wait, hope, take bets, pray for it? > You just keep offering connections until all of the BiDirIds have been offered. If you know the ORB only sends a maximum of five per connection, you just set up your loop appropriately. The same loop works if all of them are sent with each offered connection. > > As for a policy governing whether the user or the ORB generates the > > BiDirId, I think the ORB should always generate the > BiDirId. It's the > > only way to insure compatibility with persistent BiDirIds > and ones being > > created in different components of the system. > > This is issue 6313. > > The spec says that the POA must generate a "random" BiDirId, which for > persistent objects is really a contradiction. This needs to > be clarified. > > > User-generated IDs would be a big source of errors. > > I'll agree. You just need a way to specify that the BiDirId > in persistent > objects will be the same every time. I agreed with you, back about 47 emails ago. :-) > > Cheers, > -Polar > > > --Rebecca > > > > > -----Original Message----- > > > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > > > Sent: Monday, March 29, 2004 12:30 PM > > > To: Polar Humenn > > > Cc: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > > > Subject: Re: Discussion Issue 4115 > > > > > > > > > Polar Humenn wrote: > > > > > > >Here is your text and mine (with some clarifications). > > > > > > > > A BI_DIR_GIOP_OFFER service context is sent from a > client wishing to > > > > establish the connection as bidirectional. To establish a > > > bidirectional > > > > connection, the client ORB shall send to the server ORB a > > > > BI_DIR_GIOP_OFFER in the BI_DIR_GIOP IOP::ServiceContext over an > > > > established GIOP connection. > > > > > > > Over an established GIOP connection or a to-be-established GIOP > > > connection (in the case of NegotiationSession), I think. > > > > > > >So, according to the spec right now, the ORB has to make > sure all the > > > >BiDirIds get there to every open connection as well as > > > future connections. > > > >That means when a new BIDIR POA is created, the ORB must > > > also make offers > > > >to all open connections as a result. > > > > > > > >I don't mind this, as long as it is completely stated in the > > > >specification, and cannot be argued about. However, since > > > the application > > > >controls the offer feature, I'd say give the application > more of its > > > >conntrol. Let the Application specify the BiDirIDs (since > > > it created them > > > >anyway) to OFFER over the wire to particular objects. > > > > > > > >That cuts down on a whole bunch of the ORB having to do > > > everything for not > > > >much. > > > > > > > >If I create POA-X with callback object X, and BiDirId-X, and > > > I'm about to > > > >send it in an invocation to Object Y, I can put > BiDirId-X in an Offer > > > >policy on ObjectY's object reference, and the ORB knows what > > > to do with > > > >it. Send an Offer with only BiDirId-X down the line to > > > Object Y's server. > > > >Simplisitic and determininistic. > > > > > > > In summary, it seems that we need to expand the BI_DIR_OFFER > > > policy to > > > have more values: > > > > > > ALL -- all BiDirIds on POAs that have BI_DIR_EXPORT policy of > > > ALLOW will > > > be sent to the server (unless they have been sent and accepted) > > > NONE -- no BiDirIds will be allowed to be sent to the server > > > (on object > > > refereces with this policy value) > > > LISTED -- a list of POAs (or objects) whose BiDirIds are to > > > be sent to > > > the server (unless they have been sent and accepted) > > > > > > Besides, we may also want a BI_DIR_ID policy that allows an > > > application > > > to either give a BiDirId to a POA or ask the ORB to create > > > one when the > > > BI_DIR_EXPORT policy is set to ALLOW on the POA. > > > > > > Joncheng > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > Date: Fri, 2 Apr 2004 15:24:16 -0500 (EST) From: Polar Humenn To: "Bergersen, Rebecca" Cc: Joncheng Kuo , firewall-traversal-ftf@omg.org Subject: RE: Discussion Issue 4115 On Fri, 2 Apr 2004, Bergersen, Rebecca wrote: > The user's control is to put offer policies on connections. The user > must know how the ORB will deal with the BiDirIds, but it isn't > necessary or even desirable for every ORB to offer only a fixed > standardized strategy. That's like saying the result of: x = 3 + 5; depends upon whose standard C compiler you are using, and go get their manual. > It's better to let the implementation define a > strategy that's tuned for the typical situations the ORB will be > deployed into. If we had a valid strategy that allowed that, then fine, I wouldn't have a problem with it. However, the spec does not. > I believe a configurable value is best, but another designer may want a > fixed value and a third want all unoffered Ids, every time, as you do. > It's trivial to write a method that can handle any of those > eventualities, that could be easily ported among them. Oh, that's just what I want to do, is to do a "port" to different products of the same standard! What about Java? How do you know what ORB you'll be running? And Applets? How are you going to configure a non-standard ORB on the client side? > Of course we > could declare one standard strategy of always offereing all, but then > you can have the pathological case you mentioned earlier with 20,000 > BiDirIds all offered over a single connection. I think it's better to > let the implementations innovate to avoid such pathologies. That is fine, if we have a standards based strategy that allows for it, but the spec doesn't support that. > > If you have to check the particular ORB vendor's manual, then you are > > outside of the standard, and that ruins portability. > > > > As a result, we don't need anything standardize anything on > > the ORB/POA > > interface, since it really won't mean anything useful. > > > > If I put an OfferPolicy of ALLOW on a particular object > > reference, how am > > I going to be assured that the offer for any particular > > object I have got > > sent down that pipe, unless, I'm sure that the ORB sent them ALL? > > > > > > > How do I proceed with processing incoming requests for that > > object in a > > standard manner? Just wait, hope, take bets, pray for it? > > > > You just keep offering connections until all of the BiDirIds have been > offered. If you know the ORB only sends a maximum of five per > connection, you just set up your loop appropriately. The same loop > works if all of them are sent with each offered connection. So, in order to use BiDir in a standard way for every ORB, for every object reference, obj, I must some such nonsense: int myNumberOfBiDirPOAs; obj._set_policy_overrides(myBiDirOfferAllowPolicy, SET_OVERRIDES_ADD); for(int i = 0; i < 1+myNumberOfBiDirPOAs/5; i++) { obj._non_existent(); } provided that the number you state is 5. Is that a standard, if it's not, I'd better go with 1. Oh, that might not work. You'd better be sure to set the REBIND policy as well so you don't get a LocationForward somewhere in there, and the whole process starts again. Oh, and a NO_RECONNECT policy as well. Then later, when I create a new BiDir POA, I probaly have to do it all over again to make sure the offer got down the pipe. Cheers, -Polar > > > As for a policy governing whether the user or the ORB generates the > > > BiDirId, I think the ORB should always generate the > > BiDirId. It's the > > > only way to insure compatibility with persistent BiDirIds > > and ones being > > > created in different components of the system. > > > > This is issue 6313. > > > > The spec says that the POA must generate a "random" BiDirId, which for > > persistent objects is really a contradiction. This needs to > > be clarified. > > > > > User-generated IDs would be a big source of errors. > > > > I'll agree. You just need a way to specify that the BiDirId > > in persistent > > objects will be the same every time. > > I agreed with you, back about 47 emails ago. :-) > > > > > Cheers, > > -Polar > > > > > --Rebecca > > > > > > > -----Original Message----- > > > > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > > > > Sent: Monday, March 29, 2004 12:30 PM > > > > To: Polar Humenn > > > > Cc: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > > > > Subject: Re: Discussion Issue 4115 > > > > > > > > > > > > Polar Humenn wrote: > > > > > > > > >Here is your text and mine (with some clarifications). > > > > > > > > > > A BI_DIR_GIOP_OFFER service context is sent from a > > client wishing to > > > > > establish the connection as bidirectional. To establish a > > > > bidirectional > > > > > connection, the client ORB shall send to the server ORB a > > > > > BI_DIR_GIOP_OFFER in the BI_DIR_GIOP IOP::ServiceContext over an > > > > > established GIOP connection. > > > > > > > > > Over an established GIOP connection or a to-be-established GIOP > > > > connection (in the case of NegotiationSession), I think. > > > > > > > > >So, according to the spec right now, the ORB has to make > > sure all the > > > > >BiDirIds get there to every open connection as well as > > > > future connections. > > > > >That means when a new BIDIR POA is created, the ORB must > > > > also make offers > > > > >to all open connections as a result. > > > > > > > > > >I don't mind this, as long as it is completely stated in the > > > > >specification, and cannot be argued about. However, since > > > > the application > > > > >controls the offer feature, I'd say give the application > > more of its > > > > >conntrol. Let the Application specify the BiDirIDs (since > > > > it created them > > > > >anyway) to OFFER over the wire to particular objects. > > > > > > > > > >That cuts down on a whole bunch of the ORB having to do > > > > everything for not > > > > >much. > > > > > > > > > >If I create POA-X with callback object X, and BiDirId-X, and > > > > I'm about to > > > > >send it in an invocation to Object Y, I can put > > BiDirId-X in an Offer > > > > >policy on ObjectY's object reference, and the ORB knows what > > > > to do with > > > > >it. Send an Offer with only BiDirId-X down the line to > > > > Object Y's server. > > > > >Simplisitic and determininistic. > > > > > > > > > In summary, it seems that we need to expand the BI_DIR_OFFER > > > > policy to > > > > have more values: > > > > > > > > ALL -- all BiDirIds on POAs that have BI_DIR_EXPORT policy of > > > > ALLOW will > > > > be sent to the server (unless they have been sent and accepted) > > > > NONE -- no BiDirIds will be allowed to be sent to the server > > > > (on object > > > > refereces with this policy value) > > > > LISTED -- a list of POAs (or objects) whose BiDirIds are to > > > > be sent to > > > > the server (unless they have been sent and accepted) > > > > > > > > Besides, we may also want a BI_DIR_ID policy that allows an > > > > application > > > > to either give a BiDirId to a POA or ask the ORB to create > > > > one when the > > > > BI_DIR_EXPORT policy is set to ALLOW on the POA. > > > > > > > > Joncheng > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Fri, 02 Apr 2004 20:44:28 -0500 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: firewall-traversal-ftf@omg.org Subject: Re: Discussion Issue 4115 X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: You just keep offering connections until all of the BiDirIds have been offered. If you know the ORB only sends a maximum of five per connection, you just set up your loop appropriately. The same loop works if all of them are sent with each offered connection. I can't see how a loop can fit into this picture. We are talking about setting policies on POAs and object references. If I am writing a client application, I would expect to do the following: // create a POA with BI_DIR_EXPORT policy ALLOW poa = ...; // create an object implementation on the client ORB using this POA cltObj = new ObjectImpl(poa)._this(orb); // create a BI_DIR_OFFER policy with value ALLOW myBiDirOfferPolicy = ...; // set the BI_DIR_OFFER policy on the object reference obj = obj._set_policy_overrides( myBiDirOfferPolicy, SET_OVERRIDES_ADD); // invoke the target and expect the target to call back the passed cltObj obj.invoke_target(cltObj); As you can see, the client application does not really have control over BI_DIR_GIOP_OFFER service contexts (and BiDirIds in them). The client can/should only expect that the bi-directional GIOP will happen (if the server permits bi-dir) and the invoked target will call back the passed object (cltObj) without any prolem. In this example, the only way to achieve the above expectation is to *assume* that the BiDirId on the client POA will get to the server when the client invokes the target, i.e., obj.invoke_target(cltObj). Joncheng smime.p7s Date: Mon, 5 Apr 2004 09:59:08 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: firewall-traversal-ftf@omg.org Subject: RE: Discussion Issue 4115 On Fri, 2 Apr 2004, Bergersen, Rebecca wrote: > > I mean "at least" in the literal sense. The protocol allows > > for multiple > > OFFERS to be sent in multiple ServiceContexts, and in > > Multiple Negotiation > > Session messages, and in multiple arbitrary GIOP Request > > Messages. It only > > takes one successful offer for a connection to become bidirectional. > > Right? > > Right, but why would you make multiple offers over the same connection? Because a client can have more than one POA with a BirDirId. > > So, according to the spec right now, the ORB has to make sure all the > > BiDirIds get there to every open connection as well as future > > connections. > > That means when a new BIDIR POA is created, the ORB must also > > make offers > > to all open connections as a result. > > > > No, that's not what the spec says. I know the spec doesn't say that. It is logically implied. > It does not say that "all the BiDirIds get there to every open > connection as well as future connections." It is implied, if this spec is to be STANDARD vendor independant behavior. > Nor does it say that when a new BiDir POA is created the ORB must make > offers to all open connections." How else would the ORB know what the application intends? Is there a "CrystalBall" service the ORB can contact? > The fact that there are unoffered BiDirIds does not imply that the ORB > has to do anything with them. Then how would an application force to make an specific BiDir offer with the current policies? > The ORB only has to offer one or more BiDirIds when the application > wants to establish a new BiDir connection, as detailed above. There is no detail. Which offers? > And I think the number of BiDirIds offered should be left as an > implementation detail of the ORB - one or five or all should be up to > the implementation. As I said before, I don't care about the number in chunks going across, 5 or 10,000 would be fine. and it may be an implementation detail about how many your orb sends. How about a standard limit on how many it accepts? Given the current interface, ALL BiDirIds (it's still debatable about whether the bidirectionally enabled POAs are activated or not) MUST be offered on all open connections, or there is ambiguity in the application interface. > The user can read the doc about how the ORB operates - the number could > be configurable or for some implementation reason maxed out at some > number that doesn't apply to a different implementation. Then we do not have a STANDARD! So why bother? Cheers, -Polar > > I don't mind this, as long as it is completely stated in the > > specification, and cannot be argued about. However, since the > > application > > controls the offer feature, I'd say give the application more of its > > conntrol. Let the Application specify the BiDirIDs (since it > > created them > > anyway) to OFFER over the wire to particular objects. > > > > That cuts down on a whole bunch of the ORB having to do > > everything for not > > much. > > > > If I create POA-X with callback object X, and BiDirId-X, and > > I'm about to > > send it in an invocation to Object Y, I can put BiDirId-X in an Offer > > policy on ObjectY's object reference, and the ORB knows what > > to do with > > it. Send an Offer with only BiDirId-X down the line to Object > > Y's server. > > Simplisitic and determininistic. > > > > > > > It's also part of the application design. If the app wants > > > > to handle > > > > > 20,000 bidirectional invocations over a single connection > > > > by setting up > > > > > all 20,000 callback objects and then establishing a single > > > > connection, > > > > > it will get the performance it deserves! (Assuming the > > ORB sends all > > > > > BiDirIds that haven't as yet been Offered.) > > > > > > > > I'm not talking about performance, that is not the issue. > > I'm talking > > > > about the determinacy of the specification. > > > > > > > > So far, then, the following requirement is implied. > > > > > > > > The ORB SHALL send ALL of the BiDirIds for ALL of its POAs with a > > > > BiDirectionalExportPolicy of ALLOW down EVERY GIOP > > connection used to > > > > contact objects with a BiDirectionalOfferPolicy of ALLOW. > > > > > > > > > > Oh, I wouldn't agree to that statement! If I'm interpreting it > > > correctly, you are saying that every bidir connection will > > handle every > > > one of the BiDirIds. That's surely not the intent of this > > spec. See my > > > discussion above. > > > > I realize the intent. that's why I brought up the discussion. > > You cannot > > tell me the requirement is not the result of the current > > specification. > > How else would you have standard behavior? > > > > Cheers, > > -Polar > > > > > > > > Because if the ORB doesn't follow that, then some > > standard based code > > > > won't work deterministically in a standard fashion with > > > > standard interface > > > > usage. > > > > > > > > The ORB cannot decide to send only a subset and be compliant. > > > > > > > > Cheers, > > > > -Polar > > > > > > > > > > > > > > > > > > However, I'm still confused as to which BiDirIds it includes > > > > > > in the in the > > > > > > offers? I'll illustrate with a concrete example. > > > > > > > > > > > > For example, I have an ORB with 20,000 POAs, each has an > > > > BiDirectional > > > > > > Export Policy of ALLOW. > > > > > > > > > > > > The Application puts a BirDirectionalOfferPolicy of ALLOW on > > > > > > object X's > > > > > > IOR because the Application wants object X's implementation > > > > > > to invoke an > > > > > > operation on the Application's object Y in POA-4521? > > > > > > > > > > > > As an ORB, am I to supply all 20,000 BiDirIds in this case? > > > > > > > > > > > > Cheers, > > > > > > -Polar > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > Polar Humenn Adiron, LLC > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: Discussion Issue 4115 Date: Mon, 5 Apr 2004 11:40:21 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion Issue 4115 Thread-Index: AcQbFqI5vJtpiILaSpW2nRwiSMvzdQAC+brA From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i35FftAQ021237 Look, we're going around and around on this. I would like the spec to leave it up to the individual ORB to determine the maximum number of offers per service context, and provide a way of configuring this as an ORB-specific QoS. This particular issue is suitable for configuration - i.e. the maximum offers per context doesn't necessarily require the flexibility of a programmatic API and should, indeed, be as transparent as possible. Providing all unoffered BiDirIds for each offer leads to pathological cases, so a configurable value is the best answer. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Monday, April 05, 2004 9:59 AM > To: Bergersen, Rebecca > Cc: firewall-traversal-ftf@omg.org > Subject: RE: Discussion Issue 4115 > > > On Fri, 2 Apr 2004, Bergersen, Rebecca wrote: > > > > I mean "at least" in the literal sense. The protocol allows > > > for multiple > > > OFFERS to be sent in multiple ServiceContexts, and in > > > Multiple Negotiation > > > Session messages, and in multiple arbitrary GIOP Request > > > Messages. It only > > > takes one successful offer for a connection to become > bidirectional. > > > Right? > > > > Right, but why would you make multiple offers over the same > connection? > > Because a client can have more than one POA with a BirDirId. > > > > > So, according to the spec right now, the ORB has to make > sure all the > > > BiDirIds get there to every open connection as well as future > > > connections. > > > That means when a new BIDIR POA is created, the ORB must also > > > make offers > > > to all open connections as a result. > > > > > > > No, that's not what the spec says. > > I know the spec doesn't say that. It is logically implied. > > > It does not say that "all the BiDirIds get there to every open > > connection as well as future connections." > > It is implied, if this spec is to be STANDARD vendor > independant behavior. > > > Nor does it say that when a new BiDir POA is created the > ORB must make > > offers to all open connections." > > How else would the ORB know what the application intends? Is there a > "CrystalBall" service the ORB can contact? > > > The fact that there are unoffered BiDirIds does not imply > that the ORB > > has to do anything with them. > > Then how would an application force to make an specific BiDir > offer with > the current policies? > > > The ORB only has to offer one or more BiDirIds when the application > > wants to establish a new BiDir connection, as detailed above. > > There is no detail. Which offers? > > > And I think the number of BiDirIds offered should be left as an > > implementation detail of the ORB - one or five or all > should be up to > > the implementation. > > As I said before, I don't care about the number in chunks > going across, 5 > or 10,000 would be fine. and it may be an implementation > detail about how > many your orb sends. How about a standard limit on how many > it accepts? > > Given the current interface, ALL BiDirIds (it's still debatable about > whether the bidirectionally enabled POAs are activated or not) MUST be > offered on all open connections, or there is ambiguity in the > application > interface. > > > The user can read the doc about how the ORB operates - the > number could > > be configurable or for some implementation reason maxed out at some > > number that doesn't apply to a different implementation. > > Then we do not have a STANDARD! So why bother? > > > Cheers, > -Polar > > > > > I don't mind this, as long as it is completely stated in the > > > specification, and cannot be argued about. However, since the > > > application > > > controls the offer feature, I'd say give the application > more of its > > > conntrol. Let the Application specify the BiDirIDs (since it > > > created them > > > anyway) to OFFER over the wire to particular objects. > > > > > > That cuts down on a whole bunch of the ORB having to do > > > everything for not > > > much. > > > > > > If I create POA-X with callback object X, and BiDirId-X, and > > > I'm about to > > > send it in an invocation to Object Y, I can put BiDirId-X > in an Offer > > > policy on ObjectY's object reference, and the ORB knows what > > > to do with > > > it. Send an Offer with only BiDirId-X down the line to Object > > > Y's server. > > > Simplisitic and determininistic. > > > > > > > > > It's also part of the application design. If the app wants > > > > > to handle > > > > > > 20,000 bidirectional invocations over a single connection > > > > > by setting up > > > > > > all 20,000 callback objects and then establishing a single > > > > > connection, > > > > > > it will get the performance it deserves! (Assuming the > > > ORB sends all > > > > > > BiDirIds that haven't as yet been Offered.) > > > > > > > > > > I'm not talking about performance, that is not the issue. > > > I'm talking > > > > > about the determinacy of the specification. > > > > > > > > > > So far, then, the following requirement is implied. > > > > > > > > > > The ORB SHALL send ALL of the BiDirIds for ALL of its > POAs with a > > > > > BiDirectionalExportPolicy of ALLOW down EVERY GIOP > > > connection used to > > > > > contact objects with a BiDirectionalOfferPolicy of ALLOW. > > > > > > > > > > > > > Oh, I wouldn't agree to that statement! If I'm interpreting it > > > > correctly, you are saying that every bidir connection will > > > handle every > > > > one of the BiDirIds. That's surely not the intent of this > > > spec. See my > > > > discussion above. > > > > > > I realize the intent. that's why I brought up the discussion. > > > You cannot > > > tell me the requirement is not the result of the current > > > specification. > > > How else would you have standard behavior? > > > > > > Cheers, > > > -Polar > > > > > > > > > > > Because if the ORB doesn't follow that, then some > > > standard based code > > > > > won't work deterministically in a standard fashion with > > > > > standard interface > > > > > usage. > > > > > > > > > > The ORB cannot decide to send only a subset and be compliant. > > > > > > > > > > Cheers, > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > However, I'm still confused as to which BiDirIds > it includes > > > > > > > in the in the > > > > > > > offers? I'll illustrate with a concrete example. > > > > > > > > > > > > > > For example, I have an ORB with 20,000 POAs, each has an > > > > > BiDirectional > > > > > > > Export Policy of ALLOW. > > > > > > > > > > > > > > The Application puts a BirDirectionalOfferPolicy > of ALLOW on > > > > > > > object X's > > > > > > > IOR because the Application wants object X's > implementation > > > > > > > to invoke an > > > > > > > operation on the Application's object Y in POA-4521? > > > > > > > > > > > > > > As an ORB, am I to supply all 20,000 BiDirIds in > this case? > > > > > > > > > > > > > > Cheers, > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > Polar Humenn Adiron, LLC > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > Polar Humenn Adiron, LLC > > > > > mailto:polar@adiron.com 2-212 CST > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > Date: Mon, 5 Apr 2004 11:59:35 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: firewall-traversal-ftf@omg.org Subject: RE: Discussion Issue 4115 On Mon, 5 Apr 2004, Bergersen, Rebecca wrote: > Look, we're going around and around on this. Yeah, I know. > I would like the spec to leave it up to the individual ORB to determine > the maximum number of offers per service context, and provide a way of > configuring this as an ORB-specific QoS. How can I make you understand that this problem is not an implemenation or QOS issue. It is a programming logic issue. I've already presented a solution that will take care of the issue, and you can configure all the QOS per vendor ORB that you want behind it. > This particular issue is suitable for configuration - i.e. the maximum > offers per context doesn't necessarily require the flexibility of a > programmatic API and should, indeed, be as transparent as possible. > Providing all unoffered BiDirIds for each offer leads to pathological > cases, so a configurable value is the best answer. The solution I proposed will solve the pathological case. -Polar > > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Monday, April 05, 2004 9:59 AM > > To: Bergersen, Rebecca > > Cc: firewall-traversal-ftf@omg.org > > Subject: RE: Discussion Issue 4115 > > > > > > On Fri, 2 Apr 2004, Bergersen, Rebecca wrote: > > > > > > I mean "at least" in the literal sense. The protocol allows > > > > for multiple > > > > OFFERS to be sent in multiple ServiceContexts, and in > > > > Multiple Negotiation > > > > Session messages, and in multiple arbitrary GIOP Request > > > > Messages. It only > > > > takes one successful offer for a connection to become > > bidirectional. > > > > Right? > > > > > > Right, but why would you make multiple offers over the same > > connection? > > > > Because a client can have more than one POA with a BirDirId. > > > > > > > > So, according to the spec right now, the ORB has to make > > sure all the > > > > BiDirIds get there to every open connection as well as future > > > > connections. > > > > That means when a new BIDIR POA is created, the ORB must also > > > > make offers > > > > to all open connections as a result. > > > > > > > > > > No, that's not what the spec says. > > > > I know the spec doesn't say that. It is logically implied. > > > > > It does not say that "all the BiDirIds get there to every open > > > connection as well as future connections." > > > > It is implied, if this spec is to be STANDARD vendor > > independant behavior. > > > > > Nor does it say that when a new BiDir POA is created the > > ORB must make > > > offers to all open connections." > > > > How else would the ORB know what the application intends? Is there a > > "CrystalBall" service the ORB can contact? > > > > > The fact that there are unoffered BiDirIds does not imply > > that the ORB > > > has to do anything with them. > > > > Then how would an application force to make an specific BiDir > > offer with > > the current policies? > > > > > The ORB only has to offer one or more BiDirIds when the application > > > wants to establish a new BiDir connection, as detailed above. > > > > There is no detail. Which offers? > > > > > And I think the number of BiDirIds offered should be left as an > > > implementation detail of the ORB - one or five or all > > should be up to > > > the implementation. > > > > As I said before, I don't care about the number in chunks > > going across, 5 > > or 10,000 would be fine. and it may be an implementation > > detail about how > > many your orb sends. How about a standard limit on how many > > it accepts? > > > > Given the current interface, ALL BiDirIds (it's still debatable about > > whether the bidirectionally enabled POAs are activated or not) MUST be > > offered on all open connections, or there is ambiguity in the > > application > > interface. > > > > > The user can read the doc about how the ORB operates - the > > number could > > > be configurable or for some implementation reason maxed out at some > > > number that doesn't apply to a different implementation. > > > > Then we do not have a STANDARD! So why bother? > > > > > > Cheers, > > -Polar > > > > > > > > I don't mind this, as long as it is completely stated in the > > > > specification, and cannot be argued about. However, since the > > > > application > > > > controls the offer feature, I'd say give the application > > more of its > > > > conntrol. Let the Application specify the BiDirIDs (since it > > > > created them > > > > anyway) to OFFER over the wire to particular objects. > > > > > > > > That cuts down on a whole bunch of the ORB having to do > > > > everything for not > > > > much. > > > > > > > > If I create POA-X with callback object X, and BiDirId-X, and > > > > I'm about to > > > > send it in an invocation to Object Y, I can put BiDirId-X > > in an Offer > > > > policy on ObjectY's object reference, and the ORB knows what > > > > to do with > > > > it. Send an Offer with only BiDirId-X down the line to Object > > > > Y's server. > > > > Simplisitic and determininistic. > > > > > > > > > > > It's also part of the application design. If the app wants > > > > > > to handle > > > > > > > 20,000 bidirectional invocations over a single connection > > > > > > by setting up > > > > > > > all 20,000 callback objects and then establishing a single > > > > > > connection, > > > > > > > it will get the performance it deserves! (Assuming the > > > > ORB sends all > > > > > > > BiDirIds that haven't as yet been Offered.) > > > > > > > > > > > > I'm not talking about performance, that is not the issue. > > > > I'm talking > > > > > > about the determinacy of the specification. > > > > > > > > > > > > So far, then, the following requirement is implied. > > > > > > > > > > > > The ORB SHALL send ALL of the BiDirIds for ALL of its > > POAs with a > > > > > > BiDirectionalExportPolicy of ALLOW down EVERY GIOP > > > > connection used to > > > > > > contact objects with a BiDirectionalOfferPolicy of ALLOW. > > > > > > > > > > > > > > > > Oh, I wouldn't agree to that statement! If I'm interpreting it > > > > > correctly, you are saying that every bidir connection will > > > > handle every > > > > > one of the BiDirIds. That's surely not the intent of this > > > > spec. See my > > > > > discussion above. > > > > > > > > I realize the intent. that's why I brought up the discussion. > > > > You cannot > > > > tell me the requirement is not the result of the current > > > > specification. > > > > How else would you have standard behavior? > > > > > > > > Cheers, > > > > -Polar > > > > > > > > > > > > > > Because if the ORB doesn't follow that, then some > > > > standard based code > > > > > > won't work deterministically in a standard fashion with > > > > > > standard interface > > > > > > usage. > > > > > > > > > > > > The ORB cannot decide to send only a subset and be compliant. > > > > > > > > > > > > Cheers, > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > However, I'm still confused as to which BiDirIds > > it includes > > > > > > > > in the in the > > > > > > > > offers? I'll illustrate with a concrete example. > > > > > > > > > > > > > > > > For example, I have an ORB with 20,000 POAs, each has an > > > > > > BiDirectional > > > > > > > > Export Policy of ALLOW. > > > > > > > > > > > > > > > > The Application puts a BirDirectionalOfferPolicy > > of ALLOW on > > > > > > > > object X's > > > > > > > > IOR because the Application wants object X's > > implementation > > > > > > > > to invoke an > > > > > > > > operation on the Application's object Y in POA-4521? > > > > > > > > > > > > > > > > As an ORB, am I to supply all 20,000 BiDirIds in > > this case? > > > > > > > > > > > > > > > > Cheers, > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > Polar Humenn Adiron, LLC > > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > Polar Humenn Adiron, LLC > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: Discussion Issue 4115 Date: Mon, 5 Apr 2004 13:51:17 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion Issue 4115 Thread-Index: AcQbJ3SRaSObh1lfQUmBjifTn5v+KQADyF8A From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i36JIMqq005480 Polar, if I understand your solution correctly, it is to offer ALL BiDirIds on ALL open connections. Is that right? --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Monday, April 05, 2004 12:00 PM > To: Bergersen, Rebecca > Cc: firewall-traversal-ftf@omg.org > Subject: RE: Discussion Issue 4115 > > > > > On Mon, 5 Apr 2004, Bergersen, Rebecca wrote: > > > Look, we're going around and around on this. > > Yeah, I know. > > > I would like the spec to leave it up to the individual ORB > to determine > > the maximum number of offers per service context, and > provide a way of > > configuring this as an ORB-specific QoS. > > How can I make you understand that this problem is not an > implemenation or > QOS issue. It is a programming logic issue. > > I've already presented a solution that will take care of the > issue, and > you can configure all the QOS per vendor ORB that you want behind it. > > > This particular issue is suitable for configuration - i.e. > the maximum > > offers per context doesn't necessarily require the flexibility of a > > programmatic API and should, indeed, be as transparent as possible. > > Providing all unoffered BiDirIds for each offer leads to > pathological > > cases, so a configurable value is the best answer. > > The solution I proposed will solve the pathological case. > > > -Polar > > > > > --Rebecca > > > > > -----Original Message----- > > > From: Polar Humenn [mailto:polar@adiron.com] > > > Sent: Monday, April 05, 2004 9:59 AM > > > To: Bergersen, Rebecca > > > Cc: firewall-traversal-ftf@omg.org > > > Subject: RE: Discussion Issue 4115 > > > > > > > > > On Fri, 2 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > I mean "at least" in the literal sense. The protocol allows > > > > > for multiple > > > > > OFFERS to be sent in multiple ServiceContexts, and in > > > > > Multiple Negotiation > > > > > Session messages, and in multiple arbitrary GIOP Request > > > > > Messages. It only > > > > > takes one successful offer for a connection to become > > > bidirectional. > > > > > Right? > > > > > > > > Right, but why would you make multiple offers over the same > > > connection? > > > > > > Because a client can have more than one POA with a BirDirId. > > > > > > > > > > > So, according to the spec right now, the ORB has to make > > > sure all the > > > > > BiDirIds get there to every open connection as well as future > > > > > connections. > > > > > That means when a new BIDIR POA is created, the ORB must also > > > > > make offers > > > > > to all open connections as a result. > > > > > > > > > > > > > No, that's not what the spec says. > > > > > > I know the spec doesn't say that. It is logically implied. > > > > > > > It does not say that "all the BiDirIds get there to every open > > > > connection as well as future connections." > > > > > > It is implied, if this spec is to be STANDARD vendor > > > independant behavior. > > > > > > > Nor does it say that when a new BiDir POA is created the > > > ORB must make > > > > offers to all open connections." > > > > > > How else would the ORB know what the application intends? > Is there a > > > "CrystalBall" service the ORB can contact? > > > > > > > The fact that there are unoffered BiDirIds does not imply > > > that the ORB > > > > has to do anything with them. > > > > > > Then how would an application force to make an specific BiDir > > > offer with > > > the current policies? > > > > > > > The ORB only has to offer one or more BiDirIds when the > application > > > > wants to establish a new BiDir connection, as detailed above. > > > > > > There is no detail. Which offers? > > > > > > > And I think the number of BiDirIds offered should be left as an > > > > implementation detail of the ORB - one or five or all > > > should be up to > > > > the implementation. > > > > > > As I said before, I don't care about the number in chunks > > > going across, 5 > > > or 10,000 would be fine. and it may be an implementation > > > detail about how > > > many your orb sends. How about a standard limit on how many > > > it accepts? > > > > > > Given the current interface, ALL BiDirIds (it's still > debatable about > > > whether the bidirectionally enabled POAs are activated or > not) MUST be > > > offered on all open connections, or there is ambiguity in the > > > application > > > interface. > > > > > > > The user can read the doc about how the ORB operates - the > > > number could > > > > be configurable or for some implementation reason maxed > out at some > > > > number that doesn't apply to a different implementation. > > > > > > Then we do not have a STANDARD! So why bother? > > > > > > > > > Cheers, > > > -Polar > > > > > > > > > > > I don't mind this, as long as it is completely stated in the > > > > > specification, and cannot be argued about. However, since the > > > > > application > > > > > controls the offer feature, I'd say give the application > > > more of its > > > > > conntrol. Let the Application specify the BiDirIDs (since it > > > > > created them > > > > > anyway) to OFFER over the wire to particular objects. > > > > > > > > > > That cuts down on a whole bunch of the ORB having to do > > > > > everything for not > > > > > much. > > > > > > > > > > If I create POA-X with callback object X, and BiDirId-X, and > > > > > I'm about to > > > > > send it in an invocation to Object Y, I can put BiDirId-X > > > in an Offer > > > > > policy on ObjectY's object reference, and the ORB knows what > > > > > to do with > > > > > it. Send an Offer with only BiDirId-X down the line to Object > > > > > Y's server. > > > > > Simplisitic and determininistic. > > > > > > > > > > > > > It's also part of the application design. If > the app wants > > > > > > > to handle > > > > > > > > 20,000 bidirectional invocations over a single > connection > > > > > > > by setting up > > > > > > > > all 20,000 callback objects and then > establishing a single > > > > > > > connection, > > > > > > > > it will get the performance it deserves! (Assuming the > > > > > ORB sends all > > > > > > > > BiDirIds that haven't as yet been Offered.) > > > > > > > > > > > > > > I'm not talking about performance, that is not the issue. > > > > > I'm talking > > > > > > > about the determinacy of the specification. > > > > > > > > > > > > > > So far, then, the following requirement is implied. > > > > > > > > > > > > > > The ORB SHALL send ALL of the BiDirIds for ALL of its > > > POAs with a > > > > > > > BiDirectionalExportPolicy of ALLOW down EVERY GIOP > > > > > connection used to > > > > > > > contact objects with a BiDirectionalOfferPolicy of ALLOW. > > > > > > > > > > > > > > > > > > > Oh, I wouldn't agree to that statement! If I'm > interpreting it > > > > > > correctly, you are saying that every bidir connection will > > > > > handle every > > > > > > one of the BiDirIds. That's surely not the intent of this > > > > > spec. See my > > > > > > discussion above. > > > > > > > > > > I realize the intent. that's why I brought up the discussion. > > > > > You cannot > > > > > tell me the requirement is not the result of the current > > > > > specification. > > > > > How else would you have standard behavior? > > > > > > > > > > Cheers, > > > > > -Polar > > > > > > > > > > > > > > > > > Because if the ORB doesn't follow that, then some > > > > > standard based code > > > > > > > won't work deterministically in a standard fashion with > > > > > > > standard interface > > > > > > > usage. > > > > > > > > > > > > > > The ORB cannot decide to send only a subset and > be compliant. > > > > > > > > > > > > > > Cheers, > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > However, I'm still confused as to which BiDirIds > > > it includes > > > > > > > > > in the in the > > > > > > > > > offers? I'll illustrate with a concrete example. > > > > > > > > > > > > > > > > > > For example, I have an ORB with 20,000 POAs, > each has an > > > > > > > BiDirectional > > > > > > > > > Export Policy of ALLOW. > > > > > > > > > > > > > > > > > > The Application puts a BirDirectionalOfferPolicy > > > of ALLOW on > > > > > > > > > object X's > > > > > > > > > IOR because the Application wants object X's > > > implementation > > > > > > > > > to invoke an > > > > > > > > > operation on the Application's object Y in POA-4521? > > > > > > > > > > > > > > > > > > As an ORB, am I to supply all 20,000 BiDirIds in > > > this case? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > > Polar Humenn Adiron, LLC > > > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > Polar Humenn Adiron, LLC > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > Polar Humenn Adiron, LLC > > > > > mailto:polar@adiron.com 2-212 CST > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > Date: Tue, 6 Apr 2004 16:01:05 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: firewall-traversal-ftf@omg.org Subject: RE: Discussion Issue 4115 On Mon, 5 Apr 2004, Bergersen, Rebecca wrote: > Polar, if I understand your solution correctly, it is to offer ALL > BiDirIds on ALL open connections. Is that right? The solution I proposed, as did Joncheng, albeit in a slightly different form was to change the BiDirOfferPolicy to basically contain a flag of NONE, ALL, or LISTED, and to contain a user defined list of BiDirIds. NONE would prevent any offers being made on that connection. If the ORB already set up a connection with an offer on it, it must use a new connection. ALL would send all and all future POAs with BiDir, and LISTED would just send the ones listed. That way an application that dynamically creates a POA for the explicit purpose of getting a callback from Object X, can indeed make sure that that callback will only come from the connection from Object X's server by naming the BiDirId (POA, see below) in the LISTED option. Then, nothing else will come through that connection unexpectedly. (which was the whole problem with BiDir in the first place). Now, being that we do not want to anything but the ORB define the BiDirIds, in the LISTED option you could name the POA by name, since they are basically synonymous with BiDirIds. We would just have to state that any POA named that doesn't exist, or doesn't have a BiDirExportPolicy of ALLOW, be exceptionalized (BAD_PARAM) when the policy is placed on an object reference, saved in case the POA gets created later, or is just ignored. (Not sure how many ORBs really do that kind of checking, so probably ignored is better?). Questions to solve are (which have to be solved anyway): 1. What happens if the POA doesn't exist. 2. What happens when a BiDir POA is created 1. What happens if the BiDir POA is not activated? 2. What happens when the BiDir POA does become activated? 3. What happens if the BiDir POA becomes deactivated? Otherwise, the only way to go, is send ALL available (whatever that means) BiDirIds and future BiDirIds down all open connections and future connections till the cows come home. Cheers, -Polar > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Monday, April 05, 2004 12:00 PM > > To: Bergersen, Rebecca > > Cc: firewall-traversal-ftf@omg.org > > Subject: RE: Discussion Issue 4115 > > > > > > > > > > On Mon, 5 Apr 2004, Bergersen, Rebecca wrote: > > > > > Look, we're going around and around on this. > > > > Yeah, I know. > > > > > I would like the spec to leave it up to the individual ORB > > to determine > > > the maximum number of offers per service context, and > > provide a way of > > > configuring this as an ORB-specific QoS. > > > > How can I make you understand that this problem is not an > > implemenation or > > QOS issue. It is a programming logic issue. > > > > I've already presented a solution that will take care of the > > issue, and > > you can configure all the QOS per vendor ORB that you want behind it. > > > > > This particular issue is suitable for configuration - i.e. > > the maximum > > > offers per context doesn't necessarily require the flexibility of a > > > programmatic API and should, indeed, be as transparent as possible. > > > Providing all unoffered BiDirIds for each offer leads to > > pathological > > > cases, so a configurable value is the best answer. > > > > The solution I proposed will solve the pathological case. > > > > > > -Polar > > > > > > > > --Rebecca > > > > > > > -----Original Message----- > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > Sent: Monday, April 05, 2004 9:59 AM > > > > To: Bergersen, Rebecca > > > > Cc: firewall-traversal-ftf@omg.org > > > > Subject: RE: Discussion Issue 4115 > > > > > > > > > > > > On Fri, 2 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > > I mean "at least" in the literal sense. The protocol allows > > > > > > for multiple > > > > > > OFFERS to be sent in multiple ServiceContexts, and in > > > > > > Multiple Negotiation > > > > > > Session messages, and in multiple arbitrary GIOP Request > > > > > > Messages. It only > > > > > > takes one successful offer for a connection to become > > > > bidirectional. > > > > > > Right? > > > > > > > > > > Right, but why would you make multiple offers over the same > > > > connection? > > > > > > > > Because a client can have more than one POA with a BirDirId. > > > > > > > > > > > > > > So, according to the spec right now, the ORB has to make > > > > sure all the > > > > > > BiDirIds get there to every open connection as well as future > > > > > > connections. > > > > > > That means when a new BIDIR POA is created, the ORB must also > > > > > > make offers > > > > > > to all open connections as a result. > > > > > > > > > > > > > > > > No, that's not what the spec says. > > > > > > > > I know the spec doesn't say that. It is logically implied. > > > > > > > > > It does not say that "all the BiDirIds get there to every open > > > > > connection as well as future connections." > > > > > > > > It is implied, if this spec is to be STANDARD vendor > > > > independant behavior. > > > > > > > > > Nor does it say that when a new BiDir POA is created the > > > > ORB must make > > > > > offers to all open connections." > > > > > > > > How else would the ORB know what the application intends? > > Is there a > > > > "CrystalBall" service the ORB can contact? > > > > > > > > > The fact that there are unoffered BiDirIds does not imply > > > > that the ORB > > > > > has to do anything with them. > > > > > > > > Then how would an application force to make an specific BiDir > > > > offer with > > > > the current policies? > > > > > > > > > The ORB only has to offer one or more BiDirIds when the > > application > > > > > wants to establish a new BiDir connection, as detailed above. > > > > > > > > There is no detail. Which offers? > > > > > > > > > And I think the number of BiDirIds offered should be left as an > > > > > implementation detail of the ORB - one or five or all > > > > should be up to > > > > > the implementation. > > > > > > > > As I said before, I don't care about the number in chunks > > > > going across, 5 > > > > or 10,000 would be fine. and it may be an implementation > > > > detail about how > > > > many your orb sends. How about a standard limit on how many > > > > it accepts? > > > > > > > > Given the current interface, ALL BiDirIds (it's still > > debatable about > > > > whether the bidirectionally enabled POAs are activated or > > not) MUST be > > > > offered on all open connections, or there is ambiguity in the > > > > application > > > > interface. > > > > > > > > > The user can read the doc about how the ORB operates - the > > > > number could > > > > > be configurable or for some implementation reason maxed > > out at some > > > > > number that doesn't apply to a different implementation. > > > > > > > > Then we do not have a STANDARD! So why bother? > > > > > > > > > > > > Cheers, > > > > -Polar > > > > > > > > > > > > > > I don't mind this, as long as it is completely stated in the > > > > > > specification, and cannot be argued about. However, since the > > > > > > application > > > > > > controls the offer feature, I'd say give the application > > > > more of its > > > > > > conntrol. Let the Application specify the BiDirIDs (since it > > > > > > created them > > > > > > anyway) to OFFER over the wire to particular objects. > > > > > > > > > > > > That cuts down on a whole bunch of the ORB having to do > > > > > > everything for not > > > > > > much. > > > > > > > > > > > > If I create POA-X with callback object X, and BiDirId-X, and > > > > > > I'm about to > > > > > > send it in an invocation to Object Y, I can put BiDirId-X > > > > in an Offer > > > > > > policy on ObjectY's object reference, and the ORB knows what > > > > > > to do with > > > > > > it. Send an Offer with only BiDirId-X down the line to Object > > > > > > Y's server. > > > > > > Simplisitic and determininistic. > > > > > > > > > > > > > > > It's also part of the application design. If > > the app wants > > > > > > > > to handle > > > > > > > > > 20,000 bidirectional invocations over a single > > connection > > > > > > > > by setting up > > > > > > > > > all 20,000 callback objects and then > > establishing a single > > > > > > > > connection, > > > > > > > > > it will get the performance it deserves! (Assuming the > > > > > > ORB sends all > > > > > > > > > BiDirIds that haven't as yet been Offered.) > > > > > > > > > > > > > > > > I'm not talking about performance, that is not the issue. > > > > > > I'm talking > > > > > > > > about the determinacy of the specification. > > > > > > > > > > > > > > > > So far, then, the following requirement is implied. > > > > > > > > > > > > > > > > The ORB SHALL send ALL of the BiDirIds for ALL of its > > > > POAs with a > > > > > > > > BiDirectionalExportPolicy of ALLOW down EVERY GIOP > > > > > > connection used to > > > > > > > > contact objects with a BiDirectionalOfferPolicy of ALLOW. > > > > > > > > > > > > > > > > > > > > > > Oh, I wouldn't agree to that statement! If I'm > > interpreting it > > > > > > > correctly, you are saying that every bidir connection will > > > > > > handle every > > > > > > > one of the BiDirIds. That's surely not the intent of this > > > > > > spec. See my > > > > > > > discussion above. > > > > > > > > > > > > I realize the intent. that's why I brought up the discussion. > > > > > > You cannot > > > > > > tell me the requirement is not the result of the current > > > > > > specification. > > > > > > How else would you have standard behavior? > > > > > > > > > > > > Cheers, > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > Because if the ORB doesn't follow that, then some > > > > > > standard based code > > > > > > > > won't work deterministically in a standard fashion with > > > > > > > > standard interface > > > > > > > > usage. > > > > > > > > > > > > > > > > The ORB cannot decide to send only a subset and > > be compliant. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > However, I'm still confused as to which BiDirIds > > > > it includes > > > > > > > > > > in the in the > > > > > > > > > > offers? I'll illustrate with a concrete example. > > > > > > > > > > > > > > > > > > > > For example, I have an ORB with 20,000 POAs, > > each has an > > > > > > > > BiDirectional > > > > > > > > > > Export Policy of ALLOW. > > > > > > > > > > > > > > > > > > > > The Application puts a BirDirectionalOfferPolicy > > > > of ALLOW on > > > > > > > > > > object X's > > > > > > > > > > IOR because the Application wants object X's > > > > implementation > > > > > > > > > > to invoke an > > > > > > > > > > operation on the Application's object Y in POA-4521? > > > > > > > > > > > > > > > > > > > > As an ORB, am I to supply all 20,000 BiDirIds in > > > > this case? > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > > > Polar Humenn Adiron, LLC > > > > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > Polar Humenn Adiron, LLC > > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > Polar Humenn Adiron, LLC > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: Discussion Issue 4115 Date: Tue, 6 Apr 2004 16:39:29 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion Issue 4115 Thread-Index: AcQcEl6x8FnZa9hBQkS0mXunAM/Z0AAAvWqQ From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i36Kh1qq007385 I'd be amenable to adding an additional attribute on the BiDirOfferPolicy that defined the maximum number of BiDirIds to be sent over the connection being initiated. That number could be 0 (though I don't know why you would send an offer with no BiDirIds) or some other arbitrary maximum (200,000?) that could be gotten from a configurable value or defined by the ORB. I really don't like the idea of having the user list BiDirIds. They should be completely transparent - handled by the system, not the user. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Tuesday, April 06, 2004 4:01 PM > To: Bergersen, Rebecca > Cc: firewall-traversal-ftf@omg.org > Subject: RE: Discussion Issue 4115 > > > > > On Mon, 5 Apr 2004, Bergersen, Rebecca wrote: > > > Polar, if I understand your solution correctly, it is to offer ALL > > BiDirIds on ALL open connections. Is that right? > > The solution I proposed, as did Joncheng, albeit in a > slightly different > form was to change the BiDirOfferPolicy to basically contain a flag of > NONE, ALL, or LISTED, and to contain a user defined list of BiDirIds. > > NONE would prevent any offers being made on that connection. > If the ORB > already set up a connection with an offer on it, it must use a new > connection. ALL would send all and all future POAs with > BiDir, and LISTED > would just send the ones listed. > > That way an application that dynamically creates a POA for > the explicit > purpose of getting a callback from Object X, can indeed make sure that > that callback will only come from the connection from Object > X's server by > naming the BiDirId (POA, see below) in the LISTED option. > Then, nothing > else will come through that connection unexpectedly. (which > was the whole > problem with BiDir in the first place). > > Now, being that we do not want to anything but the ORB define the > BiDirIds, in the LISTED option you could name the POA by > name, since they > are basically synonymous with BiDirIds. > > We would just have to state that any POA named that doesn't exist, or > doesn't have a BiDirExportPolicy of ALLOW, be exceptionalized > (BAD_PARAM) > when the policy is placed on an object reference, saved in > case the POA > gets created later, or is just ignored. (Not sure how many > ORBs really do > that kind of checking, so probably ignored is better?). > > Questions to solve are (which have to be solved anyway): > > 1. What happens if the POA doesn't exist. > 2. What happens when a BiDir POA is created > 1. What happens if the BiDir POA is not activated? > 2. What happens when the BiDir POA does become activated? > 3. What happens if the BiDir POA becomes deactivated? > > Otherwise, the only way to go, is send ALL available > (whatever that means) > BiDirIds and future BiDirIds down all open connections and future > connections till the cows come home. > > Cheers, > -Polar > > > --Rebecca > > > > > -----Original Message----- > > > From: Polar Humenn [mailto:polar@adiron.com] > > > Sent: Monday, April 05, 2004 12:00 PM > > > To: Bergersen, Rebecca > > > Cc: firewall-traversal-ftf@omg.org > > > Subject: RE: Discussion Issue 4115 > > > > > > > > > > > > > > > On Mon, 5 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > Look, we're going around and around on this. > > > > > > Yeah, I know. > > > > > > > I would like the spec to leave it up to the individual ORB > > > to determine > > > > the maximum number of offers per service context, and > > > provide a way of > > > > configuring this as an ORB-specific QoS. > > > > > > How can I make you understand that this problem is not an > > > implemenation or > > > QOS issue. It is a programming logic issue. > > > > > > I've already presented a solution that will take care of the > > > issue, and > > > you can configure all the QOS per vendor ORB that you > want behind it. > > > > > > > This particular issue is suitable for configuration - i.e. > > > the maximum > > > > offers per context doesn't necessarily require the > flexibility of a > > > > programmatic API and should, indeed, be as transparent > as possible. > > > > Providing all unoffered BiDirIds for each offer leads to > > > pathological > > > > cases, so a configurable value is the best answer. > > > > > > The solution I proposed will solve the pathological case. > > > > > > > > > -Polar > > > > > > > > > > > --Rebecca > > > > > > > > > -----Original Message----- > > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > > Sent: Monday, April 05, 2004 9:59 AM > > > > > To: Bergersen, Rebecca > > > > > Cc: firewall-traversal-ftf@omg.org > > > > > Subject: RE: Discussion Issue 4115 > > > > > > > > > > > > > > > On Fri, 2 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > > > > I mean "at least" in the literal sense. The > protocol allows > > > > > > > for multiple > > > > > > > OFFERS to be sent in multiple ServiceContexts, and in > > > > > > > Multiple Negotiation > > > > > > > Session messages, and in multiple arbitrary GIOP Request > > > > > > > Messages. It only > > > > > > > takes one successful offer for a connection to become > > > > > bidirectional. > > > > > > > Right? > > > > > > > > > > > > Right, but why would you make multiple offers over the same > > > > > connection? > > > > > > > > > > Because a client can have more than one POA with a BirDirId. > > > > > > > > > > > > > > > > > So, according to the spec right now, the ORB has to make > > > > > sure all the > > > > > > > BiDirIds get there to every open connection as > well as future > > > > > > > connections. > > > > > > > That means when a new BIDIR POA is created, the > ORB must also > > > > > > > make offers > > > > > > > to all open connections as a result. > > > > > > > > > > > > > > > > > > > No, that's not what the spec says. > > > > > > > > > > I know the spec doesn't say that. It is logically implied. > > > > > > > > > > > It does not say that "all the BiDirIds get there to > every open > > > > > > connection as well as future connections." > > > > > > > > > > It is implied, if this spec is to be STANDARD vendor > > > > > independant behavior. > > > > > > > > > > > Nor does it say that when a new BiDir POA is created the > > > > > ORB must make > > > > > > offers to all open connections." > > > > > > > > > > How else would the ORB know what the application intends? > > > Is there a > > > > > "CrystalBall" service the ORB can contact? > > > > > > > > > > > The fact that there are unoffered BiDirIds does not imply > > > > > that the ORB > > > > > > has to do anything with them. > > > > > > > > > > Then how would an application force to make an specific BiDir > > > > > offer with > > > > > the current policies? > > > > > > > > > > > The ORB only has to offer one or more BiDirIds when the > > > application > > > > > > wants to establish a new BiDir connection, as > detailed above. > > > > > > > > > > There is no detail. Which offers? > > > > > > > > > > > And I think the number of BiDirIds offered should > be left as an > > > > > > implementation detail of the ORB - one or five or all > > > > > should be up to > > > > > > the implementation. > > > > > > > > > > As I said before, I don't care about the number in chunks > > > > > going across, 5 > > > > > or 10,000 would be fine. and it may be an implementation > > > > > detail about how > > > > > many your orb sends. How about a standard limit on how many > > > > > it accepts? > > > > > > > > > > Given the current interface, ALL BiDirIds (it's still > > > debatable about > > > > > whether the bidirectionally enabled POAs are activated or > > > not) MUST be > > > > > offered on all open connections, or there is ambiguity in the > > > > > application > > > > > interface. > > > > > > > > > > > The user can read the doc about how the ORB operates - the > > > > > number could > > > > > > be configurable or for some implementation reason maxed > > > out at some > > > > > > number that doesn't apply to a different implementation. > > > > > > > > > > Then we do not have a STANDARD! So why bother? > > > > > > > > > > > > > > > Cheers, > > > > > -Polar > > > > > > > > > > > > > > > > > I don't mind this, as long as it is completely > stated in the > > > > > > > specification, and cannot be argued about. > However, since the > > > > > > > application > > > > > > > controls the offer feature, I'd say give the application > > > > > more of its > > > > > > > conntrol. Let the Application specify the > BiDirIDs (since it > > > > > > > created them > > > > > > > anyway) to OFFER over the wire to particular objects. > > > > > > > > > > > > > > That cuts down on a whole bunch of the ORB having to do > > > > > > > everything for not > > > > > > > much. > > > > > > > > > > > > > > If I create POA-X with callback object X, and > BiDirId-X, and > > > > > > > I'm about to > > > > > > > send it in an invocation to Object Y, I can put BiDirId-X > > > > > in an Offer > > > > > > > policy on ObjectY's object reference, and the ORB > knows what > > > > > > > to do with > > > > > > > it. Send an Offer with only BiDirId-X down the > line to Object > > > > > > > Y's server. > > > > > > > Simplisitic and determininistic. > > > > > > > > > > > > > > > > > It's also part of the application design. If > > > the app wants > > > > > > > > > to handle > > > > > > > > > > 20,000 bidirectional invocations over a single > > > connection > > > > > > > > > by setting up > > > > > > > > > > all 20,000 callback objects and then > > > establishing a single > > > > > > > > > connection, > > > > > > > > > > it will get the performance it deserves! > (Assuming the > > > > > > > ORB sends all > > > > > > > > > > BiDirIds that haven't as yet been Offered.) > > > > > > > > > > > > > > > > > > I'm not talking about performance, that is > not the issue. > > > > > > > I'm talking > > > > > > > > > about the determinacy of the specification. > > > > > > > > > > > > > > > > > > So far, then, the following requirement is implied. > > > > > > > > > > > > > > > > > > The ORB SHALL send ALL of the BiDirIds for ALL of its > > > > > POAs with a > > > > > > > > > BiDirectionalExportPolicy of ALLOW down EVERY GIOP > > > > > > > connection used to > > > > > > > > > contact objects with a > BiDirectionalOfferPolicy of ALLOW. > > > > > > > > > > > > > > > > > > > > > > > > > Oh, I wouldn't agree to that statement! If I'm > > > interpreting it > > > > > > > > correctly, you are saying that every bidir > connection will > > > > > > > handle every > > > > > > > > one of the BiDirIds. That's surely not the > intent of this > > > > > > > spec. See my > > > > > > > > discussion above. > > > > > > > > > > > > > > I realize the intent. that's why I brought up the > discussion. > > > > > > > You cannot > > > > > > > tell me the requirement is not the result of the current > > > > > > > specification. > > > > > > > How else would you have standard behavior? > > > > > > > > > > > > > > Cheers, > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > Because if the ORB doesn't follow that, then some > > > > > > > standard based code > > > > > > > > > won't work deterministically in a standard > fashion with > > > > > > > > > standard interface > > > > > > > > > usage. > > > > > > > > > > > > > > > > > > The ORB cannot decide to send only a subset and > > > be compliant. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > However, I'm still confused as to which BiDirIds > > > > > it includes > > > > > > > > > > > in the in the > > > > > > > > > > > offers? I'll illustrate with a concrete example. > > > > > > > > > > > > > > > > > > > > > > For example, I have an ORB with 20,000 POAs, > > > each has an > > > > > > > > > BiDirectional > > > > > > > > > > > Export Policy of ALLOW. > > > > > > > > > > > > > > > > > > > > > > The Application puts a BirDirectionalOfferPolicy > > > > > of ALLOW on > > > > > > > > > > > object X's > > > > > > > > > > > IOR because the Application wants object X's > > > > > implementation > > > > > > > > > > > to invoke an > > > > > > > > > > > operation on the Application's object Y > in POA-4521? > > > > > > > > > > > > > > > > > > > > > > As an ORB, am I to supply all 20,000 BiDirIds in > > > > > this case? > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > > > > Polar Humenn Adiron, LLC > > > > > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > > > > > Phone: 315-443-3171 Syracuse, > NY 13244-4100 > > > > > > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > Polar Humenn Adiron, LLC > > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > Polar Humenn Adiron, LLC > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 7 Apr 2004 13:54:26 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: firewall-traversal-ftf@omg.org Subject: RE: Discussion Issue 4115 On Tue, 6 Apr 2004, Bergersen, Rebecca wrote: > I'd be amenable to adding an additional attribute on the > BiDirOfferPolicy that defined the maximum number of BiDirIds to be sent > over the connection being initiated. That number could be 0 (though I > don't know why you would send an offer with no BiDirIds) or some other > arbitrary maximum (200,000?) that could be gotten from a configurable > value or defined by the ORB. I really don't like the idea of having the > user list BiDirIds. They should be completely transparent - handled by > the system, not the user. That number is a QOS/efficiency issue, which I would rather leave to the ORB. I'm talking about the logical condition in which in the absence of stating which id's go accross the conection, you have to send all of them. No number of 0-200,000 is going to fix that problem. -Polar > > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Tuesday, April 06, 2004 4:01 PM > > To: Bergersen, Rebecca > > Cc: firewall-traversal-ftf@omg.org > > Subject: RE: Discussion Issue 4115 > > > > > > > > > > On Mon, 5 Apr 2004, Bergersen, Rebecca wrote: > > > > > Polar, if I understand your solution correctly, it is to offer ALL > > > BiDirIds on ALL open connections. Is that right? > > > > The solution I proposed, as did Joncheng, albeit in a > > slightly different > > form was to change the BiDirOfferPolicy to basically contain a flag of > > NONE, ALL, or LISTED, and to contain a user defined list of BiDirIds. > > > > NONE would prevent any offers being made on that connection. > > If the ORB > > already set up a connection with an offer on it, it must use a new > > connection. ALL would send all and all future POAs with > > BiDir, and LISTED > > would just send the ones listed. > > > > That way an application that dynamically creates a POA for > > the explicit > > purpose of getting a callback from Object X, can indeed make sure that > > that callback will only come from the connection from Object > > X's server by > > naming the BiDirId (POA, see below) in the LISTED option. > > Then, nothing > > else will come through that connection unexpectedly. (which > > was the whole > > problem with BiDir in the first place). > > > > Now, being that we do not want to anything but the ORB define the > > BiDirIds, in the LISTED option you could name the POA by > > name, since they > > are basically synonymous with BiDirIds. > > > > We would just have to state that any POA named that doesn't exist, or > > doesn't have a BiDirExportPolicy of ALLOW, be exceptionalized > > (BAD_PARAM) > > when the policy is placed on an object reference, saved in > > case the POA > > gets created later, or is just ignored. (Not sure how many > > ORBs really do > > that kind of checking, so probably ignored is better?). > > > > Questions to solve are (which have to be solved anyway): > > > > 1. What happens if the POA doesn't exist. > > 2. What happens when a BiDir POA is created > > 1. What happens if the BiDir POA is not activated? > > 2. What happens when the BiDir POA does become activated? > > 3. What happens if the BiDir POA becomes deactivated? > > > > Otherwise, the only way to go, is send ALL available > > (whatever that means) > > BiDirIds and future BiDirIds down all open connections and future > > connections till the cows come home. > > > > Cheers, > > -Polar > > > > > --Rebecca > > > > > > > -----Original Message----- > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > Sent: Monday, April 05, 2004 12:00 PM > > > > To: Bergersen, Rebecca > > > > Cc: firewall-traversal-ftf@omg.org > > > > Subject: RE: Discussion Issue 4115 > > > > > > > > > > > > > > > > > > > > On Mon, 5 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > Look, we're going around and around on this. > > > > > > > > Yeah, I know. > > > > > > > > > I would like the spec to leave it up to the individual ORB > > > > to determine > > > > > the maximum number of offers per service context, and > > > > provide a way of > > > > > configuring this as an ORB-specific QoS. > > > > > > > > How can I make you understand that this problem is not an > > > > implemenation or > > > > QOS issue. It is a programming logic issue. > > > > > > > > I've already presented a solution that will take care of the > > > > issue, and > > > > you can configure all the QOS per vendor ORB that you > > want behind it. > > > > > > > > > This particular issue is suitable for configuration - i.e. > > > > the maximum > > > > > offers per context doesn't necessarily require the > > flexibility of a > > > > > programmatic API and should, indeed, be as transparent > > as possible. > > > > > Providing all unoffered BiDirIds for each offer leads to > > > > pathological > > > > > cases, so a configurable value is the best answer. > > > > > > > > The solution I proposed will solve the pathological case. > > > > > > > > > > > > -Polar > > > > > > > > > > > > > > --Rebecca > > > > > > > > > > > -----Original Message----- > > > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > > > Sent: Monday, April 05, 2004 9:59 AM > > > > > > To: Bergersen, Rebecca > > > > > > Cc: firewall-traversal-ftf@omg.org > > > > > > Subject: RE: Discussion Issue 4115 > > > > > > > > > > > > > > > > > > On Fri, 2 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > > > > > > I mean "at least" in the literal sense. The > > protocol allows > > > > > > > > for multiple > > > > > > > > OFFERS to be sent in multiple ServiceContexts, and in > > > > > > > > Multiple Negotiation > > > > > > > > Session messages, and in multiple arbitrary GIOP Request > > > > > > > > Messages. It only > > > > > > > > takes one successful offer for a connection to become > > > > > > bidirectional. > > > > > > > > Right? > > > > > > > > > > > > > > Right, but why would you make multiple offers over the same > > > > > > connection? > > > > > > > > > > > > Because a client can have more than one POA with a BirDirId. > > > > > > > > > > > > > > > > > > > > So, according to the spec right now, the ORB has to make > > > > > > sure all the > > > > > > > > BiDirIds get there to every open connection as > > well as future > > > > > > > > connections. > > > > > > > > That means when a new BIDIR POA is created, the > > ORB must also > > > > > > > > make offers > > > > > > > > to all open connections as a result. > > > > > > > > > > > > > > > > > > > > > > No, that's not what the spec says. > > > > > > > > > > > > I know the spec doesn't say that. It is logically implied. > > > > > > > > > > > > > It does not say that "all the BiDirIds get there to > > every open > > > > > > > connection as well as future connections." > > > > > > > > > > > > It is implied, if this spec is to be STANDARD vendor > > > > > > independant behavior. > > > > > > > > > > > > > Nor does it say that when a new BiDir POA is created the > > > > > > ORB must make > > > > > > > offers to all open connections." > > > > > > > > > > > > How else would the ORB know what the application intends? > > > > Is there a > > > > > > "CrystalBall" service the ORB can contact? > > > > > > > > > > > > > The fact that there are unoffered BiDirIds does not imply > > > > > > that the ORB > > > > > > > has to do anything with them. > > > > > > > > > > > > Then how would an application force to make an specific BiDir > > > > > > offer with > > > > > > the current policies? > > > > > > > > > > > > > The ORB only has to offer one or more BiDirIds when the > > > > application > > > > > > > wants to establish a new BiDir connection, as > > detailed above. > > > > > > > > > > > > There is no detail. Which offers? > > > > > > > > > > > > > And I think the number of BiDirIds offered should > > be left as an > > > > > > > implementation detail of the ORB - one or five or all > > > > > > should be up to > > > > > > > the implementation. > > > > > > > > > > > > As I said before, I don't care about the number in chunks > > > > > > going across, 5 > > > > > > or 10,000 would be fine. and it may be an implementation > > > > > > detail about how > > > > > > many your orb sends. How about a standard limit on how many > > > > > > it accepts? > > > > > > > > > > > > Given the current interface, ALL BiDirIds (it's still > > > > debatable about > > > > > > whether the bidirectionally enabled POAs are activated or > > > > not) MUST be > > > > > > offered on all open connections, or there is ambiguity in the > > > > > > application > > > > > > interface. > > > > > > > > > > > > > The user can read the doc about how the ORB operates - the > > > > > > number could > > > > > > > be configurable or for some implementation reason maxed > > > > out at some > > > > > > > number that doesn't apply to a different implementation. > > > > > > > > > > > > Then we do not have a STANDARD! So why bother? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > I don't mind this, as long as it is completely > > stated in the > > > > > > > > specification, and cannot be argued about. > > However, since the > > > > > > > > application > > > > > > > > controls the offer feature, I'd say give the application > > > > > > more of its > > > > > > > > conntrol. Let the Application specify the > > BiDirIDs (since it > > > > > > > > created them > > > > > > > > anyway) to OFFER over the wire to particular objects. > > > > > > > > > > > > > > > > That cuts down on a whole bunch of the ORB having to do > > > > > > > > everything for not > > > > > > > > much. > > > > > > > > > > > > > > > > If I create POA-X with callback object X, and > > BiDirId-X, and > > > > > > > > I'm about to > > > > > > > > send it in an invocation to Object Y, I can put BiDirId-X > > > > > > in an Offer > > > > > > > > policy on ObjectY's object reference, and the ORB > > knows what > > > > > > > > to do with > > > > > > > > it. Send an Offer with only BiDirId-X down the > > line to Object > > > > > > > > Y's server. > > > > > > > > Simplisitic and determininistic. > > > > > > > > > > > > > > > > > > > It's also part of the application design. If > > > > the app wants > > > > > > > > > > to handle > > > > > > > > > > > 20,000 bidirectional invocations over a single > > > > connection > > > > > > > > > > by setting up > > > > > > > > > > > all 20,000 callback objects and then > > > > establishing a single > > > > > > > > > > connection, > > > > > > > > > > > it will get the performance it deserves! > > (Assuming the > > > > > > > > ORB sends all > > > > > > > > > > > BiDirIds that haven't as yet been Offered.) > > > > > > > > > > > > > > > > > > > > I'm not talking about performance, that is > > not the issue. > > > > > > > > I'm talking > > > > > > > > > > about the determinacy of the specification. > > > > > > > > > > > > > > > > > > > > So far, then, the following requirement is implied. > > > > > > > > > > > > > > > > > > > > The ORB SHALL send ALL of the BiDirIds for ALL of its > > > > > > POAs with a > > > > > > > > > > BiDirectionalExportPolicy of ALLOW down EVERY GIOP > > > > > > > > connection used to > > > > > > > > > > contact objects with a > > BiDirectionalOfferPolicy of ALLOW. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Oh, I wouldn't agree to that statement! If I'm > > > > interpreting it > > > > > > > > > correctly, you are saying that every bidir > > connection will > > > > > > > > handle every > > > > > > > > > one of the BiDirIds. That's surely not the > > intent of this > > > > > > > > spec. See my > > > > > > > > > discussion above. > > > > > > > > > > > > > > > > I realize the intent. that's why I brought up the > > discussion. > > > > > > > > You cannot > > > > > > > > tell me the requirement is not the result of the current > > > > > > > > specification. > > > > > > > > How else would you have standard behavior? > > > > > > > > > > > > > > > > Cheers, > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > Because if the ORB doesn't follow that, then some > > > > > > > > standard based code > > > > > > > > > > won't work deterministically in a standard > > fashion with > > > > > > > > > > standard interface > > > > > > > > > > usage. > > > > > > > > > > > > > > > > > > > > The ORB cannot decide to send only a subset and > > > > be compliant. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > However, I'm still confused as to which BiDirIds > > > > > > it includes > > > > > > > > > > > > in the in the > > > > > > > > > > > > offers? I'll illustrate with a concrete example. > > > > > > > > > > > > > > > > > > > > > > > > For example, I have an ORB with 20,000 POAs, > > > > each has an > > > > > > > > > > BiDirectional > > > > > > > > > > > > Export Policy of ALLOW. > > > > > > > > > > > > > > > > > > > > > > > > The Application puts a BirDirectionalOfferPolicy > > > > > > of ALLOW on > > > > > > > > > > > > object X's > > > > > > > > > > > > IOR because the Application wants object X's > > > > > > implementation > > > > > > > > > > > > to invoke an > > > > > > > > > > > > operation on the Application's object Y > > in POA-4521? > > > > > > > > > > > > > > > > > > > > > > > > As an ORB, am I to supply all 20,000 BiDirIds in > > > > > > this case? > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > > > > > Polar Humenn Adiron, LLC > > > > > > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > > > > > > Phone: 315-443-3171 Syracuse, > > NY 13244-4100 > > > > > > > > > > > > Fax: 315-443-4745 > http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > > Polar Humenn Adiron, LLC > > > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > Polar Humenn Adiron, LLC > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > Polar Humenn Adiron, LLC > > > > > mailto:polar@adiron.com 2-212 CST > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: Discussion Issue 4115 Date: Fri, 9 Apr 2004 10:56:57 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discussion Issue 4115 Thread-Index: AcQcydxfhKU7LPltQly7cFI4heWB7wBcj1Yw From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i39Ewqqq005799 Hi! All right, let's back up to a higher level. Issue 4115, as stated by Brian Niebuhr, was "I am a little confused as to the scope of the BiDirPolicy in the 2.4.1 specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? ... Could someone clarify for me what the intent for the scope of the policy was here, and what the rationale behind that decision was?" Joncheng and I worked out a clear answer to the question earlier in this thread. So, this discussion about the the number of BiDirIds being sent in an offer is a good question but is really not strictly relevant to the issue. Since the job of an FTF is to make editorial changes to clarify the text, and since we have addressed the actual issue as stated by Brian Niebuhr by clarifying the text, I suggest that we incorporate those editorial changes and close this issue. Polar, open a new issue that addresses the number of BiDirIds to be sent in an offer and we'll continue this discussion in that context. I'm not tossing out your concern - it will be dealt with - I'm just trying to move forward on the existing issues for the FTF. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Wednesday, April 07, 2004 1:54 PM > To: Bergersen, Rebecca > Cc: firewall-traversal-ftf@omg.org > Subject: RE: Discussion Issue 4115 > > > On Tue, 6 Apr 2004, Bergersen, Rebecca wrote: > > > I'd be amenable to adding an additional attribute on the > > BiDirOfferPolicy that defined the maximum number of > BiDirIds to be sent > > over the connection being initiated. That number could be > 0 (though I > > don't know why you would send an offer with no BiDirIds) or > some other > > arbitrary maximum (200,000?) that could be gotten from a > configurable > > value or defined by the ORB. I really don't like the idea > of having the > > user list BiDirIds. They should be completely transparent > - handled by > > the system, not the user. > > That number is a QOS/efficiency issue, which I would rather > leave to the > ORB. > > I'm talking about the logical condition in which in the > absence of stating > which id's go accross the conection, you have to send all of them. No > number of 0-200,000 is going to fix that problem. > > -Polar > > > > > > > > --Rebecca > > > > > -----Original Message----- > > > From: Polar Humenn [mailto:polar@adiron.com] > > > Sent: Tuesday, April 06, 2004 4:01 PM > > > To: Bergersen, Rebecca > > > Cc: firewall-traversal-ftf@omg.org > > > Subject: RE: Discussion Issue 4115 > > > > > > > > > > > > > > > On Mon, 5 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > Polar, if I understand your solution correctly, it is > to offer ALL > > > > BiDirIds on ALL open connections. Is that right? > > > > > > The solution I proposed, as did Joncheng, albeit in a > > > slightly different > > > form was to change the BiDirOfferPolicy to basically > contain a flag of > > > NONE, ALL, or LISTED, and to contain a user defined list > of BiDirIds. > > > > > > NONE would prevent any offers being made on that connection. > > > If the ORB > > > already set up a connection with an offer on it, it must use a new > > > connection. ALL would send all and all future POAs with > > > BiDir, and LISTED > > > would just send the ones listed. > > > > > > That way an application that dynamically creates a POA for > > > the explicit > > > purpose of getting a callback from Object X, can indeed > make sure that > > > that callback will only come from the connection from Object > > > X's server by > > > naming the BiDirId (POA, see below) in the LISTED option. > > > Then, nothing > > > else will come through that connection unexpectedly. (which > > > was the whole > > > problem with BiDir in the first place). > > > > > > Now, being that we do not want to anything but the ORB define the > > > BiDirIds, in the LISTED option you could name the POA by > > > name, since they > > > are basically synonymous with BiDirIds. > > > > > > We would just have to state that any POA named that > doesn't exist, or > > > doesn't have a BiDirExportPolicy of ALLOW, be exceptionalized > > > (BAD_PARAM) > > > when the policy is placed on an object reference, saved in > > > case the POA > > > gets created later, or is just ignored. (Not sure how many > > > ORBs really do > > > that kind of checking, so probably ignored is better?). > > > > > > Questions to solve are (which have to be solved anyway): > > > > > > 1. What happens if the POA doesn't exist. > > > 2. What happens when a BiDir POA is created > > > 1. What happens if the BiDir POA is not activated? > > > 2. What happens when the BiDir POA does become activated? > > > 3. What happens if the BiDir POA becomes deactivated? > > > > > > Otherwise, the only way to go, is send ALL available > > > (whatever that means) > > > BiDirIds and future BiDirIds down all open connections and future > > > connections till the cows come home. > > > > > > Cheers, > > > -Polar > > > > > > > --Rebecca > > > > > > > > > -----Original Message----- > > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > > Sent: Monday, April 05, 2004 12:00 PM > > > > > To: Bergersen, Rebecca > > > > > Cc: firewall-traversal-ftf@omg.org > > > > > Subject: RE: Discussion Issue 4115 > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 5 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > > > Look, we're going around and around on this. > > > > > > > > > > Yeah, I know. > > > > > > > > > > > I would like the spec to leave it up to the individual ORB > > > > > to determine > > > > > > the maximum number of offers per service context, and > > > > > provide a way of > > > > > > configuring this as an ORB-specific QoS. > > > > > > > > > > How can I make you understand that this problem is not an > > > > > implemenation or > > > > > QOS issue. It is a programming logic issue. > > > > > > > > > > I've already presented a solution that will take care of the > > > > > issue, and > > > > > you can configure all the QOS per vendor ORB that you > > > want behind it. > > > > > > > > > > > This particular issue is suitable for configuration - i.e. > > > > > the maximum > > > > > > offers per context doesn't necessarily require the > > > flexibility of a > > > > > > programmatic API and should, indeed, be as transparent > > > as possible. > > > > > > Providing all unoffered BiDirIds for each offer leads to > > > > > pathological > > > > > > cases, so a configurable value is the best answer. > > > > > > > > > > The solution I proposed will solve the pathological case. > > > > > > > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > --Rebecca > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > > > > Sent: Monday, April 05, 2004 9:59 AM > > > > > > > To: Bergersen, Rebecca > > > > > > > Cc: firewall-traversal-ftf@omg.org > > > > > > > Subject: RE: Discussion Issue 4115 > > > > > > > > > > > > > > > > > > > > > On Fri, 2 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > > > > > > > > I mean "at least" in the literal sense. The > > > protocol allows > > > > > > > > > for multiple > > > > > > > > > OFFERS to be sent in multiple ServiceContexts, and in > > > > > > > > > Multiple Negotiation > > > > > > > > > Session messages, and in multiple arbitrary > GIOP Request > > > > > > > > > Messages. It only > > > > > > > > > takes one successful offer for a connection to become > > > > > > > bidirectional. > > > > > > > > > Right? > > > > > > > > > > > > > > > > Right, but why would you make multiple offers > over the same > > > > > > > connection? > > > > > > > > > > > > > > Because a client can have more than one POA with > a BirDirId. > > > > > > > > > > > > > > > > > > > > > > > So, according to the spec right now, the ORB > has to make > > > > > > > sure all the > > > > > > > > > BiDirIds get there to every open connection as > > > well as future > > > > > > > > > connections. > > > > > > > > > That means when a new BIDIR POA is created, the > > > ORB must also > > > > > > > > > make offers > > > > > > > > > to all open connections as a result. > > > > > > > > > > > > > > > > > > > > > > > > > No, that's not what the spec says. > > > > > > > > > > > > > > I know the spec doesn't say that. It is logically implied. > > > > > > > > > > > > > > > It does not say that "all the BiDirIds get there to > > > every open > > > > > > > > connection as well as future connections." > > > > > > > > > > > > > > It is implied, if this spec is to be STANDARD vendor > > > > > > > independant behavior. > > > > > > > > > > > > > > > Nor does it say that when a new BiDir POA is created the > > > > > > > ORB must make > > > > > > > > offers to all open connections." > > > > > > > > > > > > > > How else would the ORB know what the application intends? > > > > > Is there a > > > > > > > "CrystalBall" service the ORB can contact? > > > > > > > > > > > > > > > The fact that there are unoffered BiDirIds does > not imply > > > > > > > that the ORB > > > > > > > > has to do anything with them. > > > > > > > > > > > > > > Then how would an application force to make an > specific BiDir > > > > > > > offer with > > > > > > > the current policies? > > > > > > > > > > > > > > > The ORB only has to offer one or more BiDirIds when the > > > > > application > > > > > > > > wants to establish a new BiDir connection, as > > > detailed above. > > > > > > > > > > > > > > There is no detail. Which offers? > > > > > > > > > > > > > > > And I think the number of BiDirIds offered should > > > be left as an > > > > > > > > implementation detail of the ORB - one or five or all > > > > > > > should be up to > > > > > > > > the implementation. > > > > > > > > > > > > > > As I said before, I don't care about the number in chunks > > > > > > > going across, 5 > > > > > > > or 10,000 would be fine. and it may be an implementation > > > > > > > detail about how > > > > > > > many your orb sends. How about a standard limit > on how many > > > > > > > it accepts? > > > > > > > > > > > > > > Given the current interface, ALL BiDirIds (it's still > > > > > debatable about > > > > > > > whether the bidirectionally enabled POAs are activated or > > > > > not) MUST be > > > > > > > offered on all open connections, or there is > ambiguity in the > > > > > > > application > > > > > > > interface. > > > > > > > > > > > > > > > The user can read the doc about how the ORB > operates - the > > > > > > > number could > > > > > > > > be configurable or for some implementation reason maxed > > > > > out at some > > > > > > > > number that doesn't apply to a different implementation. > > > > > > > > > > > > > > Then we do not have a STANDARD! So why bother? > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > I don't mind this, as long as it is completely > > > stated in the > > > > > > > > > specification, and cannot be argued about. > > > However, since the > > > > > > > > > application > > > > > > > > > controls the offer feature, I'd say give the > application > > > > > > > more of its > > > > > > > > > conntrol. Let the Application specify the > > > BiDirIDs (since it > > > > > > > > > created them > > > > > > > > > anyway) to OFFER over the wire to particular objects. > > > > > > > > > > > > > > > > > > That cuts down on a whole bunch of the ORB > having to do > > > > > > > > > everything for not > > > > > > > > > much. > > > > > > > > > > > > > > > > > > If I create POA-X with callback object X, and > > > BiDirId-X, and > > > > > > > > > I'm about to > > > > > > > > > send it in an invocation to Object Y, I can > put BiDirId-X > > > > > > > in an Offer > > > > > > > > > policy on ObjectY's object reference, and the ORB > > > knows what > > > > > > > > > to do with > > > > > > > > > it. Send an Offer with only BiDirId-X down the > > > line to Object > > > > > > > > > Y's server. > > > > > > > > > Simplisitic and determininistic. > > > > > > > > > > > > > > > > > > > > > It's also part of the application design. If > > > > > the app wants > > > > > > > > > > > to handle > > > > > > > > > > > > 20,000 bidirectional invocations over a single > > > > > connection > > > > > > > > > > > by setting up > > > > > > > > > > > > all 20,000 callback objects and then > > > > > establishing a single > > > > > > > > > > > connection, > > > > > > > > > > > > it will get the performance it deserves! > > > (Assuming the > > > > > > > > > ORB sends all > > > > > > > > > > > > BiDirIds that haven't as yet been Offered.) > > > > > > > > > > > > > > > > > > > > > > I'm not talking about performance, that is > > > not the issue. > > > > > > > > > I'm talking > > > > > > > > > > > about the determinacy of the specification. > > > > > > > > > > > > > > > > > > > > > > So far, then, the following requirement > is implied. > > > > > > > > > > > > > > > > > > > > > > The ORB SHALL send ALL of the BiDirIds > for ALL of its > > > > > > > POAs with a > > > > > > > > > > > BiDirectionalExportPolicy of ALLOW down EVERY GIOP > > > > > > > > > connection used to > > > > > > > > > > > contact objects with a > > > BiDirectionalOfferPolicy of ALLOW. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Oh, I wouldn't agree to that statement! If I'm > > > > > interpreting it > > > > > > > > > > correctly, you are saying that every bidir > > > connection will > > > > > > > > > handle every > > > > > > > > > > one of the BiDirIds. That's surely not the > > > intent of this > > > > > > > > > spec. See my > > > > > > > > > > discussion above. > > > > > > > > > > > > > > > > > > I realize the intent. that's why I brought up the > > > discussion. > > > > > > > > > You cannot > > > > > > > > > tell me the requirement is not the result of > the current > > > > > > > > > specification. > > > > > > > > > How else would you have standard behavior? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Because if the ORB doesn't follow that, then some > > > > > > > > > standard based code > > > > > > > > > > > won't work deterministically in a standard > > > fashion with > > > > > > > > > > > standard interface > > > > > > > > > > > usage. > > > > > > > > > > > > > > > > > > > > > > The ORB cannot decide to send only a subset and > > > > > be compliant. > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > However, I'm still confused as to > which BiDirIds > > > > > > > it includes > > > > > > > > > > > > > in the in the > > > > > > > > > > > > > offers? I'll illustrate with a > concrete example. > > > > > > > > > > > > > > > > > > > > > > > > > > For example, I have an ORB with 20,000 POAs, > > > > > each has an > > > > > > > > > > > BiDirectional > > > > > > > > > > > > > Export Policy of ALLOW. > > > > > > > > > > > > > > > > > > > > > > > > > > The Application puts a > BirDirectionalOfferPolicy > > > > > > > of ALLOW on > > > > > > > > > > > > > object X's > > > > > > > > > > > > > IOR because the Application wants object X's > > > > > > > implementation > > > > > > > > > > > > > to invoke an > > > > > > > > > > > > > operation on the Application's object Y > > > in POA-4521? > > > > > > > > > > > > > > > > > > > > > > > > > > As an ORB, am I to supply all 20,000 > BiDirIds in > > > > > > > this case? > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > > > > > > Polar Humenn Adiron, LLC > > > > > > > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > > > > > > > Phone: 315-443-3171 Syracuse, > > > NY 13244-4100 > > > > > > > > > > > > > Fax: 315-443-4745 > > http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > > > Polar Humenn Adiron, LLC > > > > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > > > > Phone: 315-443-3171 Syracuse, NY > 13244-4100 > > > > > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > Polar Humenn Adiron, LLC > > > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > Polar Humenn Adiron, LLC > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Actions taken: Transfer to Firewall FTF. Subject: RE: Firewall FTF Vote 2 - resolution for 4115 Date: Mon, 12 Apr 2004 10:35:19 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF Vote 2 - resolution for 4115 Thread-Index: AcQgohSrDKWNB2+nQSCcV3WCfj3OqgADUGiw From: "Dave Stringer" To: "Bergersen, Rebecca" , , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" Cc: X-OriginalArrivalTime: 12 Apr 2004 17:35:19.0957 (UTC) FILETIME=[86B72C50:01C420B4] regarding this proposed resolution ... Replace the third paragraph from the end of Section 15.9 with: .A BidirectionalExportPolicy can be applied to a POA on a client ORB using the PortableServer::POA::create_POA operation. If the BidirectionalExportPolicy value of the POA is ALLOW, the client ORB is allowed to send to the server, in the BI_DIR_GIOP_OFFER IOP::ServiceContext, the BiDirId associated with the objects in that POA. In addition, when IORs are created for the objects in that POA, the BiDirId for that POA shall be placed in the TAG_BI_DIR_GIOP component of those IORs. If the BidirectionalExportPolicy value of the POA is DENY, then a TAG_BI_DIR_GIOP component shall not be placed in the IOR of the objects in that POA, and the BiDirId for objects in that POA shall not be sent in any BI_DIR_GIOP_OFFER service contexts.. An ORB maybe connected to a number of "servers". Should the BiDirIds be sent to any or all of the open connections, subject to BidirectionalOfferPolicy? Or just to new connections? How could an application arrange for disjoint sets of BiDirIds to be sent to two different servers? Section 15.4.10 states that NegotiateSession messages are sent during the "session setup" period. Its left ambiguous whether NegotiateSession messages are allowed after the first Request / LocateRequest. If not, how do newly created POAs get their BiDirIds sent to extant connections? This state-machine (ho ho) for session establishment (connection setup, session setup, session established) lacks rigor. For example, having established a connection, is it legal for the accepting-end to send the first Request (afterall it will have the BiDirIds by then) Replace the first sentence of the second paragraph from the end of Section 15.9 with: .A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden for specific object references on the client ORB.. This text seems to be a step backwards from that posted by Jishnu - as the 7168 fix (actual doc number unknown?) - which says: A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden for specific object references received by the client ORB. The wording "received by the client ORB" is better than "on the client ORB" as the latter perpetuates the confusion over whiich references: those created by the POA that resides on the client (sic) ORB or the references to objects on a remote server. Also the term "overridden" is too loose. I presume this means "invoking CORBA::Object::set_policy_overrides" However this is not stated. Also it is not stated whether the BidirectionalOfferPolicy can be overriden at the thread (i.e. Current) level. Nor is it stated what it would mean to override this policy (at the object reference level) after a connection has been exstablished and a BiDirId sent. Is it invalid to attempt such an override or should the ORB close the connection? In any case the association between an Object Reference (held by the client (sic) ORB and an IIOP connection is tenuous at best. It is possible for a client (sic) ORB to open more than one connection to the **same** server. If a BiDirId is sent along both connections what behaviour is expected at the server ORB as to which connection it may use for sending Request messages. The effect of set_policy_overrides on an object reference is to create a new object reference. As the end point will be the same, the connection is now represented by two object references with contrary BidirectionalOfferPolicies. If a new POA is created, how does the ORB decide whether this new BiDirId needs to be sent to the server? Should such a set_policy_overrides result in a new connection being established? In short, I don't believe the resolution addresses the issue originally raised: what is the scope (and impact) of the Bidir policies.. Dave Date: Mon, 12 Apr 2004 13:45:17 -0400 (EDT) From: Polar Humenn To: Dave Stringer Cc: "Bergersen, Rebecca" , ckuo01@syr.edu, "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , firewall-traversal-ftf@omg.org Subject: RE: Firewall FTF Vote 2 - resolution for 4115 On Mon, 12 Apr 2004, Dave Stringer wrote: > regarding this proposed resolution ... [snip] > In short, I don't believe the resolution addresses the issue originally > raised: what is the scope (and impact) of the Bidir policies.. I concur. -Polar > > Dave > > > > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: Firewall FTF Vote 2 - resolution for 4115 Date: Mon, 12 Apr 2004 10:35:19 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF Vote 2 - resolution for 4115 Thread-Index: AcQgohSrDKWNB2+nQSCcV3WCfj3OqgADUGiw From: "Dave Stringer" To: "Bergersen, Rebecca" , , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" Cc: X-OriginalArrivalTime: 12 Apr 2004 17:35:19.0957 (UTC) FILETIME=[86B72C50:01C420B4] regarding this proposed resolution ... Replace the third paragraph from the end of Section 15.9 with: .A BidirectionalExportPolicy can be applied to a POA on a client ORB using the PortableServer::POA::create_POA operation. If the BidirectionalExportPolicy value of the POA is ALLOW, the client ORB is allowed to send to the server, in the BI_DIR_GIOP_OFFER IOP::ServiceContext, the BiDirId associated with the objects in that POA. In addition, when IORs are created for the objects in that POA, the BiDirId for that POA shall be placed in the TAG_BI_DIR_GIOP component of those IORs. If the BidirectionalExportPolicy value of the POA is DENY, then a TAG_BI_DIR_GIOP component shall not be placed in the IOR of the objects in that POA, and the BiDirId for objects in that POA shall not be sent in any BI_DIR_GIOP_OFFER service contexts.. An ORB maybe connected to a number of "servers". Should the BiDirIds be sent to any or all of the open connections, subject to BidirectionalOfferPolicy? Or just to new connections? How could an application arrange for disjoint sets of BiDirIds to be sent to two different servers? Section 15.4.10 states that NegotiateSession messages are sent during the "session setup" period. Its left ambiguous whether NegotiateSession messages are allowed after the first Request / LocateRequest. If not, how do newly created POAs get their BiDirIds sent to extant connections? This state-machine (ho ho) for session establishment (connection setup, session setup, session established) lacks rigor. For example, having established a connection, is it legal for the accepting-end to send the first Request (afterall it will have the BiDirIds by then) Replace the first sentence of the second paragraph from the end of Section 15.9 with: .A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden for specific object references on the client ORB.. This text seems to be a step backwards from that posted by Jishnu - as the 7168 fix (actual doc number unknown?) - which says: A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden for specific object references received by the client ORB. The wording "received by the client ORB" is better than "on the client ORB" as the latter perpetuates the confusion over whiich references: those created by the POA that resides on the client (sic) ORB or the references to objects on a remote server. Also the term "overridden" is too loose. I presume this means "invoking CORBA::Object::set_policy_overrides" However this is not stated. Also it is not stated whether the BidirectionalOfferPolicy can be overriden at the thread (i.e. Current) level. Nor is it stated what it would mean to override this policy (at the object reference level) after a connection has been exstablished and a BiDirId sent. Is it invalid to attempt such an override or should the ORB close the connection? In any case the association between an Object Reference (held by the client (sic) ORB and an IIOP connection is tenuous at best. It is possible for a client (sic) ORB to open more than one connection to the **same** server. If a BiDirId is sent along both connections what behaviour is expected at the server ORB as to which connection it may use for sending Request messages. The effect of set_policy_overrides on an object reference is to create a new object reference. As the end point will be the same, the connection is now represented by two object references with contrary BidirectionalOfferPolicies. If a new POA is created, how does the ORB decide whether this new BiDirId needs to be sent to the server? Should such a set_policy_overrides result in a new connection being established? In short, I don't believe the resolution addresses the issue originally raised: what is the scope (and impact) of the Bidir policies.. Dave Date: Mon, 12 Apr 2004 13:45:17 -0400 (EDT) From: Polar Humenn To: Dave Stringer Cc: "Bergersen, Rebecca" , ckuo01@syr.edu, "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , firewall-traversal-ftf@omg.org Subject: RE: Firewall FTF Vote 2 - resolution for 4115 On Mon, 12 Apr 2004, Dave Stringer wrote: > regarding this proposed resolution ... [snip] > In short, I don't believe the resolution addresses the issue originally > raised: what is the scope (and impact) of the Bidir policies.. I concur. -Polar > > Dave > > > > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: Firewall FTF Vote 2 - resolution for 4115 Date: Mon, 12 Apr 2004 15:35:21 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF Vote 2 - resolution for 4115 Thread-Index: AcQgohSrDKWNB2+nQSCcV3WCfj3OqgADUGiwAAGilVA= From: "Bergersen, Rebecca" To: "Dave Stringer" , , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" Cc: , "Bergersen, Rebecca" Comments inlined.... --Rebecca -----Original Message----- From: Dave Stringer [mailto:Dave.Stringer@borland.com] Sent: Monday, April 12, 2004 1:35 PM To: Bergersen, Rebecca; ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail) Cc: firewall-traversal-ftf@omg.org Subject: RE: Firewall FTF Vote 2 - resolution for 4115 regarding this proposed resolution ... Replace the third paragraph from the end of Section 15.9 with: .A BidirectionalExportPolicy can be applied to a POA on a client ORB using the PortableServer::POA::create_POA operation. If the BidirectionalExportPolicy value of the POA is ALLOW, the client ORB is allowed to send to the server, in the BI_DIR_GIOP_OFFER IOP::ServiceContext, the BiDirId associated with the objects in that POA. In addition, when IORs are created for the objects in that POA, the BiDirId for that POA shall be placed in the TAG_BI_DIR_GIOP component of those IORs. If the BidirectionalExportPolicy value of the POA is DENY, then a TAG_BI_DIR_GIOP component shall not be placed in the IOR of the objects in that POA, and the BiDirId for objects in that POA shall not be sent in any BI_DIR_GIOP_OFFER service contexts.. An ORB maybe connected to a number of "servers". Should the BiDirIds be sent to any or all of the open connections, subject to BidirectionalOfferPolicy? Or just to new connections? How could an application arrange for disjoint sets of BiDirIds to be sent to two different servers? Section 15.4.10 states that NegotiateSession messages are sent during the "session setup" period. Its left ambiguous whether NegotiateSession messages are allowed after the first Request / LocateRequest. If not, how do newly created POAs get their BiDirIds sent to extant connections? [Bergersen, Rebecca] BiDirIds are sent in an Offer. It's up to the user to add an Offer to a message (by doing an override on the object being invoked). That Offer will contain the new BiDirIds. Ah - but what would allow those BiDirIds to also be sent on another connection, in a different Offer? There is no mechanism to do so, as things stand now. You've just made Polar's and Joncheng's argument clear to me. The only mechanism now is to bundle up unoffered BiDirIds and send them in an Offer, at which point they are not available to further Offers. If you think it is important to allow BiDirIds to be available over multiple connections, an issue ought to be created so the RTF can extend the protocol to allow for this additional behavior. This state-machine (ho ho) for session establishment (connection setup, session setup, session established) lacks rigor. For example, having established a connection, is it legal for the accepting-end to send the first Request (afterall it will have the BiDirIds by then) Replace the first sentence of the second paragraph from the end of Section 15.9 with: .A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden for specific object references on the client ORB.. This text seems to be a step backwards from that posted by Jishnu - as the 7168 fix (actual doc number unknown?) - which says: A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden for specific object references received by the client ORB. The wording "received by the client ORB" is better than "on the client ORB" as the latter perpetuates the confusion over whiich references: those created by the POA that resides on the client (sic) ORB or the references to objects on a remote server. [Bergersen, Rebecca] The wording was changed because Polar and Joncheng felt that if "received by" was included in the sentence, then it needed to be spelled out how clients might "receive" an object - is retrieving it from a file considered receiving it, for example? Joncheng and I worked out a wording in the mailing list that seemed clear enough and nobody commented further, so that's what I put in the resolution. Also the term "overridden" is too loose. I presume this means "invoking CORBA::Object::set_policy_overrides" However this is not stated. Also it is not stated whether the BidirectionalOfferPolicy can be overriden at the thread (i.e. Current) level. Nor is it stated what it would mean to override this policy (at the object reference level) after a connection has been exstablished and a BiDirId sent. Is it invalid to attempt such an override or should the ORB close the connection? [Bergersen, Rebecca] "Overridden" is the term used in the spec and we've all presumed it means set_policy_overrides. I can't think of another way to "override" at an object level. Also, nothing specifies any thread-level semantics. Is it necessary to indicate that the override does not apply at the thread level? As for the second question, I'm unsure of your assumptions. Let's say an object has had its policyset overriden and a new object has been created with the new policyset. Then that new object has been invoked upon, thereby establishing a connection and communicating a BiDirId. Now you're suggesting that the new object's policy set is overridden? Or the old object's and a third object is created? In any case the association between an Object Reference (held by the client (sic) ORB and an IIOP connection is tenuous at best. It is possible for a client (sic) ORB to open more than one connection to the **same** server. If a BiDirId is sent along both connections what behaviour is expected at the server ORB as to which connection it may use for sending Request messages. [Bergersen, Rebecca] As I stated above, it isn't possible in the current version to have a BiDir Id valid over more than one connection. Though the writers of the spec clearly intended for that to happen, they didn't define a mechanism in which that could occur. The effect of set_policy_overrides on an object reference is to create a new object reference. As the end point will be the same, the connection is now represented by two object references with contrary BidirectionalOfferPolicies. If a new POA is created, how does the ORB decide whether this new BiDirId needs to be sent to the server? Should such a set_policy_overrides result in a new connection being established? [Bergersen, Rebecca] When a new POA is created with an export policy of ALLOW, a BiDirId is created for it. This Id has not been offered yet, so when the next offer is sent (by invoking on an object whose policies have been overridden with a BidirectionalOfferPolicy), the unoffered BiDirId will be picked up and sent in the service context. I guess it depends on the ORB's connection architectiure, but in ours a new connection would be created only when an existing connection with the same policy set doesn't already exist. In short, I don't believe the resolution addresses the issue originally raised: what is the scope (and impact) of the Bidir policies.. Dave Subject: RE: Firewall FTF Vote 2 - resolution for 4115 Date: Mon, 12 Apr 2004 13:57:54 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF Vote 2 - resolution for 4115 Thread-Index: AcQgohSrDKWNB2+nQSCcV3WCfj3OqgADUGiwAAGilVAABozYMA== From: "Dave Stringer" To: "Bergersen, Rebecca" , , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" Cc: X-OriginalArrivalTime: 12 Apr 2004 20:57:55.0131 (UTC) FILETIME=[D3C388B0:01C420D0] Rebecca The BidirectionalOfferPolicy has the value ALLOW or the value DENY. How does setting this policy on an object reference tell the ORB which BiDirIds to put in a BI_DIR_GIOP_OFFER ServiceContext for a subsequent Request or NegotiateSession message? I guess I don't understand your remark "It's up to the user to add an Offer to a message" below. My assumption was that it would send ALL known BiDirIds. If this assumption is incorrect then I hope it illustrates the danger of having an incomplete specification. An object reference is **not** synonymous with an IIOP connection. Do you agree? My reading of your response indicates a reliance on a well-defined relationship between the two that is not supported by the CORBA spec. Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 12:35 PM To: Dave Stringer; ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail) Cc: firewall-traversal-ftf@omg.org; Bergersen, Rebecca Subject: RE: Firewall FTF Vote 2 - resolution for 4115 Comments inlined.... --Rebecca -----Original Message----- From: Dave Stringer [mailto:Dave.Stringer@borland.com] Sent: Monday, April 12, 2004 1:35 PM To: Bergersen, Rebecca; ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail) Cc: firewall-traversal-ftf@omg.org Subject: RE: Firewall FTF Vote 2 - resolution for 4115 regarding this proposed resolution ... Replace the third paragraph from the end of Section 15.9 with: .A BidirectionalExportPolicy can be applied to a POA on a client ORB using the PortableServer::POA::create_POA operation. If the BidirectionalExportPolicy value of the POA is ALLOW, the client ORB is allowed to send to the server, in the BI_DIR_GIOP_OFFER IOP::ServiceContext, the BiDirId associated with the objects in that POA. In addition, when IORs are created for the objects in that POA, the BiDirId for that POA shall be placed in the TAG_BI_DIR_GIOP component of those IORs. If the BidirectionalExportPolicy value of the POA is DENY, then a TAG_BI_DIR_GIOP component shall not be placed in the IOR of the objects in that POA, and the BiDirId for objects in that POA shall not be sent in any BI_DIR_GIOP_OFFER service contexts.. An ORB maybe connected to a number of "servers". Should the BiDirIds be sent to any or all of the open connections, subject to BidirectionalOfferPolicy? Or just to new connections? How could an application arrange for disjoint sets of BiDirIds to be sent to two different servers? Section 15.4.10 states that NegotiateSession messages are sent during the "session setup" period. Its left ambiguous whether NegotiateSession messages are allowed after the first Request / LocateRequest. If not, how do newly created POAs get their BiDirIds sent to extant connections? [Bergersen, Rebecca] BiDirIds are sent in an Offer. It's up to the user to add an Offer to a message (by doing an override on the object being invoked). That Offer will contain the new BiDirIds. Ah - but what would allow those BiDirIds to also be sent on another connection, in a different Offer? There is no mechanism to do so, as things stand now. You've just made Polar's and Joncheng's argument clear to me. The only mechanism now is to bundle up unoffered BiDirIds and send them in an Offer, at which point they are not available to further Offers. If you think it is important to allow BiDirIds to be available over multiple connections, an issue ought to be created so the RTF can extend the protocol to allow for this additional behavior. This state-machine (ho ho) for session establishment (connection setup, session setup, session established) lacks rigor. For example, having established a connection, is it legal for the accepting-end to send the first Request (afterall it will have the BiDirIds by then) Replace the first sentence of the second paragraph from the end of Section 15.9 with: .A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden for specific object references on the client ORB.. This text seems to be a step backwards from that posted by Jishnu - as the 7168 fix (actual doc number unknown?) - which says: A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden for specific object references received by the client ORB. The wording "received by the client ORB" is better than "on the client ORB" as the latter perpetuates the confusion over whiich references: those created by the POA that resides on the client (sic) ORB or the references to objects on a remote server. [Bergersen, Rebecca] The wording was changed because Polar and Joncheng felt that if "received by" was included in the sentence, then it needed to be spelled out how clients might "receive" an object - is retrieving it from a file considered receiving it, for example? Joncheng and I worked out a wording in the mailing list that seemed clear enough and nobody commented further, so that's what I put in the resolution. Also the term "overridden" is too loose. I presume this means "invoking CORBA::Object::set_policy_overrides" However this is not stated. Also it is not stated whether the BidirectionalOfferPolicy can be overriden at the thread (i.e. Current) level. Nor is it stated what it would mean to override this policy (at the object reference level) after a connection has been exstablished and a BiDirId sent. Is it invalid to attempt such an override or should the ORB close the connection? [Bergersen, Rebecca] "Overridden" is the term used in the spec and we've all presumed it means set_policy_overrides. I can't think of another way to "override" at an object level. Also, nothing specifies any thread-level semantics. Is it necessary to indicate that the override does not apply at the thread level? As for the second question, I'm unsure of your assumptions. Let's say an object has had its policyset overriden and a new object has been created with the new policyset. Then that new object has been invoked upon, thereby establishing a connection and communicating a BiDirId. Now you're suggesting that the new object's policy set is overridden? Or the old object's and a third object is created? In any case the association between an Object Reference (held by the client (sic) ORB and an IIOP connection is tenuous at best. It is possible for a client (sic) ORB to open more than one connection to the **same** server. If a BiDirId is sent along both connections what behaviour is expected at the server ORB as to which connection it may use for sending Request messages. [Bergersen, Rebecca] As I stated above, it isn't possible in the current version to have a BiDir Id valid over more than one connection. Though the writers of the spec clearly intended for that to happen, they didn't define a mechanism in which that could occur. The effect of set_policy_overrides on an object reference is to create a new object reference. As the end point will be the same, the connection is now represented by two object references with contrary BidirectionalOfferPolicies. If a new POA is created, how does the ORB decide whether this new BiDirId needs to be sent to the server? Should such a set_policy_overrides result in a new connection being established? [Bergersen, Rebecca] When a new POA is created with an export policy of ALLOW, a BiDirId is created for it. This Id has not been offered yet, so when the next offer is sent (by invoking on an object whose policies have been overridden with a BidirectionalOfferPolicy), the unoffered BiDirId will be picked up and sent in the service context. I guess it depends on the ORB's connection architectiure, but in ours a new connection would be created only when an existing connection with the same policy set doesn't already exist. In short, I don't believe the resolution addresses the issue originally raised: what is the scope (and impact) of the Bidir policies.. Dave