Issue 7225: Implications about BiDirIds (firewall-traversal-ftf) Source: Syracuse University (Mr. C. Joncheng Kuo, joncheng_kuo(at)bristol.com) Nature: Uncategorized Issue Severity: Summary: I'll use the following example to explain the implications that I derive from my understanding about the spec. I hope that it makes sense to you. If I'm wrong, please let me know. Suppose I set up a client that has some POAs with BI_DIR_EXPORT policy ALLOW. The client wants to invoke a server that accepts bi-directional GIOP. This invocation will cause callbacks to a few objects on the client using bi-directional GIOP. The server is not allowed to create new connections to the client. In the code of my client application, I can simply use the following statement to invoke the target object. And I would expect that the target object will call back some of the objects on the client ORB during this invocation. obj = ...; // target obj.invoke_target(...); In order for the above scenario to work, I derive the following implications from the spec. 1. This invocation requires the target to call back on some of the objects on the client ORB. Because the client ORB has no knowledge about what objects might be called back, the client ORB has to ensure that the BiDirIds on *all* of its POAs that have EXPORT policy ALLOW must be available at the server side. This conclusion also implies that the client ORB may have to track what BiDirIds that have been sent (and accepted) over every connection that allows bi-directional GIOP in order to figure out what BiDirIds have not yet been sent, assuming that you don't want to send all BiDirIds in every request. Furthermore, when someone creates a new POA with the EXPORT policy ALLOW later on the client ORB, the next new invocation on *each* bi-directional connection will also have to transmit the BiDirId for this new POA to the server side. 2. When the server receives a GIOP Request with BI_DIR_GIOP_OFFER service context, the server cannot dispatch the request to the target object implementation until this connection becomes bi-directional. Why? If the server dispatches the request before this connection becomes bi-directional, this request may fail because the target is not able to call back objects on the client ORB. In the case of Strong BiDirIds, the server may even have to send CHALLENGE and wait for RESPONSE before the server can dispatch the request. If we put both implications together in the case of Strong BiDirIds, when someone creates a new POA with EXPORT policy ALLOW on a client ORB, a longer delay will be expected in the next request on *every* bi-directional connection because the server has to verify the BiDirId of this new POA no matter whether this new BiDirId will be used for callbacks on that connection or not. To me this overhead is not acceptable if it is the only way to implement bi-directional GIOP according to the spec. I hope the spec can be written in a way that *allows* efficient implementation, though efficiency is not always a concern for everyone. Resolution: Revised Text: Actions taken: April 8, 2004: receievd issue Discussion: End of Annotations:===== Date: Thu, 08 Apr 2004 18:15:00 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: firewall-traversal-ftf@omg.org CC: Rebecca.Bergersen@iona.com, Polar Humenn Subject: Implications about BiDirIds I'll use the following example to explain the implications that I derive from my understanding about the spec. I hope that it makes sense to you. If I'm wrong, please let me know. Suppose I set up a client that has some POAs with BI_DIR_EXPORT policy ALLOW. The client wants to invoke a server that accepts bi-directional GIOP. This invocation will cause callbacks to a few objects on the client using bi-directional GIOP. The server is not allowed to create new connections to the client. In the code of my client application, I can simply use the following statement to invoke the target object. And I would expect that the target object will call back some of the objects on the client ORB during this invocation. obj = ...; // target obj.invoke_target(...); In order for the above scenario to work, I derive the following implications from the spec. 1. This invocation requires the target to call back on some of the objects on the client ORB. Because the client ORB has no knowledge about what objects might be called back, the client ORB has to ensure that the BiDirIds on *all* of its POAs that have EXPORT policy ALLOW must be available at the server side. This conclusion also implies that the client ORB may have to track what BiDirIds that have been sent (and accepted) over every connection that allows bi-directional GIOP in order to figure out what BiDirIds have not yet been sent, assuming that you don't want to send all BiDirIds in every request. Furthermore, when someone creates a new POA with the EXPORT policy ALLOW later on the client ORB, the next new invocation on *each* bi-directional connection will also have to transmit the BiDirId for this new POA to the server side. 2. When the server receives a GIOP Request with BI_DIR_GIOP_OFFER service context, the server cannot dispatch the request to the target object implementation until this connection becomes bi-directional. Why? If the server dispatches the request before this connection becomes bi-directional, this request may fail because the target is not able to call back objects on the client ORB. In the case of Strong BiDirIds, the server may even have to send CHALLENGE and wait for RESPONSE before the server can dispatch the request. If we put both implications together in the case of Strong BiDirIds, when someone creates a new POA with EXPORT policy ALLOW on a client ORB, a longer delay will be expected in the next request on *every* bi-directional connection because the server has to verify the BiDirId of this new POA no matter whether this new BiDirId will be used for callbacks on that connection or not. To me this overhead is not acceptable if it is the only way to implement bi-directional GIOP according to the spec. I hope the spec can be written in a way that *allows* efficient implementation, though efficiency is not always a concern for everyone. Cheers, Joncheng Subject: RE: issue 7225 -- Firewall Traversal FTF issue Date: Mon, 12 Apr 2004 17:39:13 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 7225 -- Firewall Traversal FTF issue Thread-Index: AcQgz6y/R5VB2/32QaiO/Hwo1zoIZAABZ4pA From: "Bergersen, Rebecca" To: Cc: "Bergersen, Rebecca" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3CLfmna002319 Comments inlined --Rebecca > -----Original Message----- > From: Juergen Boldt [mailto:juergen@omg.org] > Sent: Monday, April 12, 2004 4:35 PM > To: issues@omg.org; firewall-traversal-ftf@omg.org > Subject: issue 7225 -- Firewall Traversal FTF issue > > > This is issue # 7225 From: Joncheng Kuo > > Implications about BiDirIds > > I'll use the following example to explain the implications > that I derive > from my understanding about the spec. I hope that it makes > sense to you. If > I'm wrong, please let me know. > > > Suppose I set up a client that has some POAs with > BI_DIR_EXPORT policy > ALLOW. The client wants to invoke a server that accepts > bi-directional > GIOP. This invocation will cause callbacks to a few objects > on the client > using bi-directional GIOP. The server is not allowed to create new > connections to the client. > > > In the code of my client application, I can simply use the following > statement to invoke the target object. And I would expect > that the target > object will call back some of the objects on the client ORB > during this > invocation. > > > obj = ...; // target > obj.invoke_target(...); > > > In order for the above scenario to work, I derive the following > implications from the spec. > > > 1. This invocation requires the target to call back on some > of the objects > on the client ORB. Because the client ORB has no knowledge about what > objects might be called back, the client ORB has to ensure that the > BiDirIds on *all* of its POAs that have EXPORT policy ALLOW must be > available at the server side. Agreed. We handled this by having the callback objects "register" with the server after they have been created. The server gets their BiDirIds from their IORs and stores them. > > > This conclusion also implies that the client ORB may have to > track what > BiDirIds that have been sent (and accepted) over every > connection that > allows bi-directional GIOP in order to figure out what > BiDirIds have not > yet been sent, assuming that you don't want to send all > BiDirIds in every > request. Yes, the client ORB has to keep track of what BiDirIds have been sent and which ones haven't. > Furthermore, when someone creates a new POA with the > EXPORT policy > ALLOW later on the client ORB, the next new invocation on *each* > bi-directional connection will also have to transmit the > BiDirId for this > new POA to the server side. > That conclusion doesn't follow. The next invocation on an object with an Offer policy will pick up the unoffered BiDirId, put it in its ServiceContext, and send it to the server. There's no implication that *every* bidir connection will have to have it transmitted. > > 2. When the server receives a GIOP Request with > BI_DIR_GIOP_OFFER service > context, the server cannot dispatch the request to the target object > implementation until this connection becomes bi-directional. > Why? If the > server dispatches the request before this connection becomes > bi-directional, this request may fail because the target is > not able to > call back objects on the client ORB. In the case of Strong > BiDirIds, the > server may even have to send CHALLENGE and wait for RESPONSE > before the > server can dispatch the request. > Agreed. > > If we put both implications together in the case of Strong > BiDirIds, when > someone creates a new POA with EXPORT policy ALLOW on a client ORB, a > longer delay will be expected in the next request on *every* > bi-directional > connection because the server has to verify the BiDirId of > this new POA no > matter whether this new BiDirId will be used for callbacks on that > connection or not. Again, I don't see how you conclude that every connection has to be involved. > To me this overhead is not acceptable if > it is the only > way to implement bi-directional GIOP according to the spec. I > hope the spec > can be written in a way that *allows* efficient > implementation, though > efficiency is not always a concern for everyone. > > > > > ================================= > Jürgen Boldt > Director, Member Services > > Object Management Group > 250 First Avenue, Suite 100 > Needham, MA 02494 > > Tel. +1 781 444 0404 ext. 132 > Fax: +1 781 444 0320 > email: juergen@omg.org > www www.omg.org > > ================================ > > Date: Tue, 13 Apr 2004 10:18:32 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: firewall-traversal-ftf@omg.org Subject: RE: issue 7225 -- Firewall Traversal FTF issue X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by amethyst.omg.org id i3DEPYna007537 On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > obj = ...; // target > > obj.invoke_target(...); > > > > > > In order for the above scenario to work, I derive the following > > implications from the spec. > > > > > > 1. This invocation requires the target to call back on some of the > > objects on the client ORB. Because the client ORB has no knowledge > > about what objects might be called back, the client ORB has to ensure > > that the BiDirIds on *all* of its POAs that have EXPORT policy ALLOW > > must be available at the server side. > > Agreed. We handled this by having the callback objects "register" with > the server after they have been created. The server gets their BiDirIds > from their IORs and stores them. I understand that you agree that offers for *ALL* BiDirIds on every open connection. What I don't understand, is the following comment. What do you mean by "handle" and how is "registering" done, and what does it cause? > > This conclusion also implies that the client ORB may have to track > > what BiDirIds that have been sent (and accepted) over every connection > > that allows bi-directional GIOP in order to figure out what BiDirIds > > have not yet been sent, assuming that you don't want to send all > > BiDirIds in every request. > > Yes, the client ORB has to keep track of what BiDirIds have been sent and which ones haven't. > > > Furthermore, when someone creates a new POA with the EXPORT policy > > ALLOW later on the client ORB, the next new invocation on *each* > > bi-directional connection will also have to transmit the BiDirId for > > this new POA to the server side. > > > > That conclusion doesn't follow. The next invocation on an object with > an Offer policy will pick up the unoffered BiDirId, put it in its > ServiceContext, and send it to the server. There's no implication that > *every* bidir connection will have to have it transmitted. Who said the Offer had to be sent in an invocation? In fact, it has to be sent in a NegotiationSession messsage on every open connection in order to comply, because you may never make an invocation from the client side, and servers may be chompping at the bit to make an invocation on the clients objects! > > 2. When the server receives a GIOP Request with BI_DIR_GIOP_OFFER > > service context, the server cannot dispatch the request to the target > > object implementation until this connection becomes bi-directional. > > Why? If the server dispatches the request before this connection > > becomes bi-directional, this request may fail because the target is > > not able to call back objects on the client ORB. In the case of Strong > > BiDirIds, the server may even have to send CHALLENGE and wait for > > RESPONSE before the server can dispatch the request. > > Agreed. > > > > > If we put both implications together in the case of Strong > > BiDirIds, when > > someone creates a new POA with EXPORT policy ALLOW on a client ORB, a > > longer delay will be expected in the next request on *every* > > bi-directional > > connection because the server has to verify the BiDirId of > > this new POA no > > matter whether this new BiDirId will be used for callbacks on that > > connection or not. > > Again, I don't see how you conclude that every connection has to be involved. Because, the ORB has NFC about what the applications on either side wants to do. So, it must make for the most general case. Cheers, -Polar > > To me this overhead is not acceptable if it is the only way to > > implement bi-directional GIOP according to the spec. I hope the spec > > can be written in a way that *allows* efficient implementation, though > > efficiency is not always a concern for everyone. > > > > > > ================================= > > Jürgen Boldt > > Director, Member Services > > > > Object Management Group > > 250 First Avenue, Suite 100 > > Needham, MA 02494 > > > > Tel. +1 781 444 0404 ext. 132 > > Fax: +1 781 444 0320 > > email: juergen@omg.org > > www www.omg.org > > > > ================================ > > > > > ------------------------------------------------------------------- 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, 13 Apr 2004 10:59:28 -0400 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: issue 7225 -- Firewall Traversal FTF issue X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: Because the client ORB has no knowledge about what objects might be called back, the client ORB has to ensure that the BiDirIds on *all* of its POAs that have EXPORT policy ALLOW must be available at the server side. Agreed. We handled this by having the callback objects "register" with the server after they have been created. What is the interface for doing such a "registration"? Is it proprietary? Who does this registration, client ORB, client application, or object implementation? The server gets their BiDirIds from their IORs and stores them. Even if the server gets BiDirIds using this private way, the client ORB still has to transmit these BiDirIds over GIOP connections. Besides, in the case of Strong BiDirIds, the RSA modulus is not available in IORs. Joncheng Subject: RE: issue 7225 -- Firewall Traversal FTF issue Date: Tue, 13 Apr 2004 08:31:00 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 7225 -- Firewall Traversal FTF issue Thread-Index: AcQgz6y/R5VB2/32QaiO/Hwo1zoIZAABZ4pAAABn99A= From: "Dave Stringer" To: "Bergersen, Rebecca" , X-OriginalArrivalTime: 13 Apr 2004 15:31:00.0922 (UTC) FILETIME=[533281A0:01C4216C] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3DFZfna008728 Rebecca To pull out part of your response: > Agreed. We handled this by having the callback objects "register" with > the server after they have been created. The server gets their BiDirIds > from their IORs and stores them. What do you mean by "register"? Does this imply any additional semantics over and above the normal ways in which an object reference is acquired? E.g. invoking string_to_object or unmarshaling a CORBA::Object parameter. I think we must be at cross-purposes because it makes no sense to me to say "The server gets their BidirIds from their IOR and stores them". The server needs the BiDirIds to remain associated with the object references. When the application on this (server) ORB wants to make an invocation on an object reference, the ORB will have to find the BiDirId for that object reference and then look that up against all the connections and the advertised BiDirIds they they represent. I'm also concerned over your use of the term "callback object". To the server these are just object references and whatever you assert is done for callback object references will have to be done for all object references. Unless of course you're thinking of a different treatment for object references that include a TAG_BI_DIR_GIOP, in which case that different treatment needs to be spelled out. You say later: > ... There's no implication that *every* bidir connection will have to have > it transmitted. But there is just that implication. A BiDirId exists in the client (sic) ORB as soon as the POA is created. There is no way to associate it with just one of the many (even 1000s !!) of connections that might be open to other ORBs. Perhaps your use-case is for a simple client that connects to just one server but a **specification** cannot be limited to work only in that scenario. Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 2:39 PM To: firewall-traversal-ftf@omg.org Cc: Bergersen, Rebecca Subject: RE: issue 7225 -- Firewall Traversal FTF issue Comments inlined --Rebecca > -----Original Message----- > From: Juergen Boldt [mailto:juergen@omg.org] > Sent: Monday, April 12, 2004 4:35 PM > To: issues@omg.org; firewall-traversal-ftf@omg.org > Subject: issue 7225 -- Firewall Traversal FTF issue > > > This is issue # 7225 From: Joncheng Kuo > > Implications about BiDirIds > > I'll use the following example to explain the implications > that I derive > from my understanding about the spec. I hope that it makes > sense to you. If > I'm wrong, please let me know. > > > Suppose I set up a client that has some POAs with > BI_DIR_EXPORT policy > ALLOW. The client wants to invoke a server that accepts > bi-directional > GIOP. This invocation will cause callbacks to a few objects > on the client > using bi-directional GIOP. The server is not allowed to create new > connections to the client. > > > In the code of my client application, I can simply use the following > statement to invoke the target object. And I would expect > that the target > object will call back some of the objects on the client ORB > during this > invocation. > > > obj = ...; // target > obj.invoke_target(...); > > > In order for the above scenario to work, I derive the following > implications from the spec. > > > 1. This invocation requires the target to call back on some > of the objects > on the client ORB. Because the client ORB has no knowledge about what > objects might be called back, the client ORB has to ensure that the > BiDirIds on *all* of its POAs that have EXPORT policy ALLOW must be > available at the server side. Agreed. We handled this by having the callback objects "register" with the server after they have been created. The server gets their BiDirIds from their IORs and stores them. > > > This conclusion also implies that the client ORB may have to > track what > BiDirIds that have been sent (and accepted) over every > connection that > allows bi-directional GIOP in order to figure out what > BiDirIds have not > yet been sent, assuming that you don't want to send all > BiDirIds in every > request. Yes, the client ORB has to keep track of what BiDirIds have been sent and which ones haven't. > Furthermore, when someone creates a new POA with the > EXPORT policy > ALLOW later on the client ORB, the next new invocation on *each* > bi-directional connection will also have to transmit the > BiDirId for this > new POA to the server side. > That conclusion doesn't follow. The next invocation on an object with an Offer policy will pick up the unoffered BiDirId, put it in its ServiceContext, and send it to the server. There's no implication that *every* bidir connection will have to have it transmitted. > > 2. When the server receives a GIOP Request with > BI_DIR_GIOP_OFFER service > context, the server cannot dispatch the request to the target object > implementation until this connection becomes bi-directional. > Why? If the > server dispatches the request before this connection becomes > bi-directional, this request may fail because the target is > not able to > call back objects on the client ORB. In the case of Strong > BiDirIds, the > server may even have to send CHALLENGE and wait for RESPONSE > before the > server can dispatch the request. > Agreed. > > If we put both implications together in the case of Strong > BiDirIds, when > someone creates a new POA with EXPORT policy ALLOW on a client ORB, a > longer delay will be expected in the next request on *every* > bi-directional > connection because the server has to verify the BiDirId of > this new POA no > matter whether this new BiDirId will be used for callbacks on that > connection or not. Again, I don't see how you conclude that every connection has to be involved. > To me this overhead is not acceptable if > it is the only > way to implement bi-directional GIOP according to the spec. I > hope the spec > can be written in a way that *allows* efficient > implementation, though > efficiency is not always a concern for everyone. > > > > > ================================= > Jürgen Boldt > Director, Member Services > > Object Management Group > 250 First Avenue, Suite 100 > Needham, MA 02494 > > Tel. +1 781 444 0404 ext. 132 > Fax: +1 781 444 0320 > email: juergen@omg.org > www www.omg.org > > ================================ > > Subject: RE: issue 7225 -- Firewall Traversal FTF issue Date: Tue, 13 Apr 2004 14:15:12 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 7225 -- Firewall Traversal FTF issue Thread-Index: AcQgz6y/R5VB2/32QaiO/Hwo1zoIZAABZ4pAAABn99AAJiN/QA== From: "Bergersen, Rebecca" To: "Dave Stringer" , Cc: "Bergersen, Rebecca" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3DII5na011147 Comments inline... --Rebecca > -----Original Message----- > From: Dave Stringer [mailto:Dave.Stringer@borland.com] > Sent: Tuesday, April 13, 2004 11:31 AM > To: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > Subject: RE: issue 7225 -- Firewall Traversal FTF issue > > > Rebecca > > To pull out part of your response: > > > Agreed. We handled this by having the callback objects > "register" with > > the server after they have been created. The server gets > their BiDirIds > > from their IORs and stores them. > > What do you mean by "register"? Does this imply any > additional semantics > over and above the normal ways in which an object reference > is acquired? > E.g. invoking string_to_object or unmarshaling a > CORBA::Object parameter. The registration process is the mechanism we put in place to inform the server about the callback objects. It's a server-side operation. The client app, after it has created a callback object, calls register(), passing the newly created object as a parameter. There are any number of ways the client can get its callback objects to the server. The idea of "registering" a newly created object is used in so many places we just reused the idea here, since the standard didn't specify any particular mechanism. > > I think we must be at cross-purposes because it makes no > sense to me to > say "The server gets their BidirIds from their IOR and stores > them". The > server needs the BiDirIds to remain associated with the > object references. > When the application on this (server) ORB wants to make an > invocation on > an object reference, the ORB will have to find the BiDirId > for that object > reference and then look that up against all the connections > and the advertised > BiDirIds they they represent. I guess I'm not making myself clear because your description is exactly what I meant. I didn't mean to disassociate the BiDirIds from the references! All I meant was to construct that lookup table. > > I'm also concerned over your use of the term "callback > object". To the server > these are just object references and whatever you assert is > done for callback > object references will have to be done for all object > references. Unless of > course you're thinking of a different treatment for object > references that > include a TAG_BI_DIR_GIOP, in which case that different > treatment needs to > be spelled out. The BiDir "callback" objects are already being treated differently. They require a lookup of their BiDirId and a crossmatch with what connection they may be invoked over. Their ID can be challenged, and their response evaluated. Building the lookup table is part of setting up the protocol. If you think that it's necessary to standardize on "registering" the objects, that's fine with me. > > You say later: > > ... There's no implication that *every* bidir connection > will have to have > > it transmitted. > > But there is just that implication. A BiDirId exists in the > client (sic) ORB > as soon as the POA is created. There is no way to associate > it with just one > of the many (even 1000s !!) of connections that might be open > to other ORBs. I still don't get this point. I'm willing to believe it's valid but my view of how things work just doesn't match with the statement. Here's the simplest example I can come up with, a stock ticker example. Let me go through the steps and you tell me where I'm deviating from your view: Server processing 1. Initialize the ORB and obtain a reference to the RootPOA. 2. Create the stock registry servant and export the object ref to a file. This object has a Register() function, Deregister() function and a Notify() function. 3. Activate the POA Manager and call ORB.run() to allow the ORB to receive and process incoming requests. 4. Receive callback references registered by the client to indicate interest in receiving stock price change notifications 5. In order to accept client's bidirectional offer, the effective policies on each callback reference are overridden with the BidirectionalAcceptPolicy set to ALLOW. 6. Regularly notify overridden callback references of price changes Client processing 1. Initialize the ORB and obtain a reference to the RootPOA 2. Read and destringify the stock registry IOR, overriding the effective policies with a BidirectionalOfferPolicy set to ALLOW in order to allow a bidirectional offer to be made with invocations on this reference. 3. Create the callback POA with the effective BidirectionalExportPolicy set to ALLOW in order to allow an appropriate BiDirId to be published in the callback reference 4. Create and activate the callback object. 5. Register the callback object by invoking register() on the overridden stock registry object, passing the callback object as a parameter. 6. Activate the POA Manager and call ORB.run() to allow the ORB to receive and process incoming requests. 7. Receive incoming bidirectional callback invocations. The register() call to the server carries the offer and passes the callback object as a parameter. Only the connection that is used to carry the offer is established as bidirectional and the BiDirId carried in the offer is valid only for that connection. > > Perhaps your use-case is for a simple client that connects to > just one server > but a **specification** cannot be limited to work only in > that scenario. > The example I provided above is as simple as I can come up with and it does have a simple client and one server. However, it can readily be expanded to multiple servers and multiple clients without any change in the processing. > Dave > > > -----Original Message----- > From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] > Sent: Monday, April 12, 2004 2:39 PM > To: firewall-traversal-ftf@omg.org > Cc: Bergersen, Rebecca > Subject: RE: issue 7225 -- Firewall Traversal FTF issue > > > > Comments inlined > > --Rebecca > > > -----Original Message----- > > From: Juergen Boldt [mailto:juergen@omg.org] > > Sent: Monday, April 12, 2004 4:35 PM > > To: issues@omg.org; firewall-traversal-ftf@omg.org > > Subject: issue 7225 -- Firewall Traversal FTF issue > > > > > > This is issue # 7225 From: Joncheng Kuo > > > > Implications about BiDirIds > > > > I'll use the following example to explain the implications > > that I derive > > from my understanding about the spec. I hope that it makes > > sense to you. If > > I'm wrong, please let me know. > > > > > > Suppose I set up a client that has some POAs with > > BI_DIR_EXPORT policy > > ALLOW. The client wants to invoke a server that accepts > > bi-directional > > GIOP. This invocation will cause callbacks to a few objects > > on the client > > using bi-directional GIOP. The server is not allowed to create new > > connections to the client. > > > > > > In the code of my client application, I can simply use the > following > > statement to invoke the target object. And I would expect > > that the target > > object will call back some of the objects on the client ORB > > during this > > invocation. > > > > > > obj = ...; // target > > obj.invoke_target(...); > > > > > > In order for the above scenario to work, I derive the following > > implications from the spec. > > > > > > 1. This invocation requires the target to call back on some > > of the objects > > on the client ORB. Because the client ORB has no knowledge > about what > > objects might be called back, the client ORB has to ensure that the > > BiDirIds on *all* of its POAs that have EXPORT policy ALLOW must be > > available at the server side. > > Agreed. We handled this by having the callback objects > "register" with the server after they have been created. The > server gets their BiDirIds from their IORs and stores them. > > > > > > > This conclusion also implies that the client ORB may have to > > track what > > BiDirIds that have been sent (and accepted) over every > > connection that > > allows bi-directional GIOP in order to figure out what > > BiDirIds have not > > yet been sent, assuming that you don't want to send all > > BiDirIds in every > > request. > > Yes, the client ORB has to keep track of what BiDirIds have > been sent and which ones haven't. > > > Furthermore, when someone creates a new POA with the > > EXPORT policy > > ALLOW later on the client ORB, the next new invocation on *each* > > bi-directional connection will also have to transmit the > > BiDirId for this > > new POA to the server side. > > > > That conclusion doesn't follow. The next invocation on an > object with an Offer policy will pick up the unoffered > BiDirId, put it in its ServiceContext, and send it to the > server. There's no implication that *every* bidir connection > will have to have it transmitted. > > > > > 2. When the server receives a GIOP Request with > > BI_DIR_GIOP_OFFER service > > context, the server cannot dispatch the request to the > target object > > implementation until this connection becomes bi-directional. > > Why? If the > > server dispatches the request before this connection becomes > > bi-directional, this request may fail because the target is > > not able to > > call back objects on the client ORB. In the case of Strong > > BiDirIds, the > > server may even have to send CHALLENGE and wait for RESPONSE > > before the > > server can dispatch the request. > > > > Agreed. > > > > > If we put both implications together in the case of Strong > > BiDirIds, when > > someone creates a new POA with EXPORT policy ALLOW on a > client ORB, a > > longer delay will be expected in the next request on *every* > > bi-directional > > connection because the server has to verify the BiDirId of > > this new POA no > > matter whether this new BiDirId will be used for callbacks on that > > connection or not. > > Again, I don't see how you conclude that every connection has > to be involved. > > > > To me this overhead is not acceptable if > > it is the only > > way to implement bi-directional GIOP according to the spec. I > > hope the spec > > can be written in a way that *allows* efficient > > implementation, though > > efficiency is not always a concern for everyone. > > > > > > > > > > ================================= > > Jürgen Boldt > > Director, Member Services > > > > Object Management Group > > 250 First Avenue, Suite 100 > > Needham, MA 02494 > > > > Tel. +1 781 444 0404 ext. 132 > > Fax: +1 781 444 0320 > > email: juergen@omg.org > > www www.omg.org > > > > ================================ > > > > > Subject: RE: issue 7225 -- Firewall Traversal FTF issue Date: Tue, 13 Apr 2004 11:43:23 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 7225 -- Firewall Traversal FTF issue Thread-Index: AcQgz6y/R5VB2/32QaiO/Hwo1zoIZAABZ4pAAABn99AAJiN/QAAFWxUw From: "Dave Stringer" To: "Bergersen, Rebecca" , X-OriginalArrivalTime: 13 Apr 2004 18:43:24.0531 (UTC) FILETIME=[33B97430:01C42187] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3DIm4na011591 Rebecca You wrote, at the end of tutorial ;-) : > The register() call to the server carries the offer and passes > the callback object as a parameter. Only the connection that is > used to carry the offer is established as bidirectional and the > BiDirId carried in the offer is valid only for that connection. This is the problem. As you said, "register" is just one of many ways The object reference could arrive at the server. E.g. it could be bound to some name in a completely separate name service (i.e. at a different internet address) from where the server gets the reference by "resolve". Or stringified and then cut-and-paste into an Instant Message. Now in these cases there has been no communication between the client and server over the bideirectional connection, the server hasn't yet seen the BiDirId to Connection association. It can't send the inverse direction Request message. In the absence of the "register" Reguest over the would-be bidirectional connection. The client ORB has to send a NegotiateSession Message with the BI_DIR_GIOP_OFFER service context. BUT as the ORB can't predict which connection the newly created BiDirId will apply to it has to send it offer every open connection. It is difficult for it to even narrow these down to ones "declared" to be "Offer=ALLOW" as that policy applies to an object reference, and as we agreed earlier, an object reference is not synonymous with a connection. It appears to me as if your scenario relies on the "register" Request message being sent over the same connection that the reverse direction "notify" will also be sent over. Unfortunately there is no support for this assumption in the spec and therefore very little hope that two implementations of the spec would interoperate. Hope we are iterating nearer to a common understanding :-) Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Tuesday, April 13, 2004 11:15 AM To: Dave Stringer; firewall-traversal-ftf@omg.org Cc: Bergersen, Rebecca Subject: RE: issue 7225 -- Firewall Traversal FTF issue Comments inline... --Rebecca > -----Original Message----- > From: Dave Stringer [mailto:Dave.Stringer@borland.com] > Sent: Tuesday, April 13, 2004 11:31 AM > To: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > Subject: RE: issue 7225 -- Firewall Traversal FTF issue > > > Rebecca > > To pull out part of your response: > > > Agreed. We handled this by having the callback objects > "register" with > > the server after they have been created. The server gets > their BiDirIds > > from their IORs and stores them. > > What do you mean by "register"? Does this imply any > additional semantics > over and above the normal ways in which an object reference > is acquired? > E.g. invoking string_to_object or unmarshaling a > CORBA::Object parameter. The registration process is the mechanism we put in place to inform the server about the callback objects. It's a server-side operation. The client app, after it has created a callback object, calls register(), passing the newly created object as a parameter. There are any number of ways the client can get its callback objects to the server. The idea of "registering" a newly created object is used in so many places we just reused the idea here, since the standard didn't specify any particular mechanism. > > I think we must be at cross-purposes because it makes no > sense to me to > say "The server gets their BidirIds from their IOR and stores > them". The > server needs the BiDirIds to remain associated with the > object references. > When the application on this (server) ORB wants to make an > invocation on > an object reference, the ORB will have to find the BiDirId > for that object > reference and then look that up against all the connections > and the advertised > BiDirIds they they represent. I guess I'm not making myself clear because your description is exactly what I meant. I didn't mean to disassociate the BiDirIds from the references! All I meant was to construct that lookup table. > > I'm also concerned over your use of the term "callback > object". To the server > these are just object references and whatever you assert is > done for callback > object references will have to be done for all object > references. Unless of > course you're thinking of a different treatment for object > references that > include a TAG_BI_DIR_GIOP, in which case that different > treatment needs to > be spelled out. The BiDir "callback" objects are already being treated differently. They require a lookup of their BiDirId and a crossmatch with what connection they may be invoked over. Their ID can be challenged, and their response evaluated. Building the lookup table is part of setting up the protocol. If you think that it's necessary to standardize on "registering" the objects, that's fine with me. > > You say later: > > ... There's no implication that *every* bidir connection > will have to have > > it transmitted. > > But there is just that implication. A BiDirId exists in the > client (sic) ORB > as soon as the POA is created. There is no way to associate > it with just one > of the many (even 1000s !!) of connections that might be open > to other ORBs. I still don't get this point. I'm willing to believe it's valid but my view of how things work just doesn't match with the statement. Here's the simplest example I can come up with, a stock ticker example. Let me go through the steps and you tell me where I'm deviating from your view: Server processing 1. Initialize the ORB and obtain a reference to the RootPOA. 2. Create the stock registry servant and export the object ref to a file. This object has a Register() function, Deregister() function and a Notify() function. 3. Activate the POA Manager and call ORB.run() to allow the ORB to receive and process incoming requests. 4. Receive callback references registered by the client to indicate interest in receiving stock price change notifications 5. In order to accept client's bidirectional offer, the effective policies on each callback reference are overridden with the BidirectionalAcceptPolicy set to ALLOW. 6. Regularly notify overridden callback references of price changes Client processing 1. Initialize the ORB and obtain a reference to the RootPOA 2. Read and destringify the stock registry IOR, overriding the effective policies with a BidirectionalOfferPolicy set to ALLOW in order to allow a bidirectional offer to be made with invocations on this reference. 3. Create the callback POA with the effective BidirectionalExportPolicy set to ALLOW in order to allow an appropriate BiDirId to be published in the callback reference 4. Create and activate the callback object. 5. Register the callback object by invoking register() on the overridden stock registry object, passing the callback object as a parameter. 6. Activate the POA Manager and call ORB.run() to allow the ORB to receive and process incoming requests. 7. Receive incoming bidirectional callback invocations. The register() call to the server carries the offer and passes the callback object as a parameter. Only the connection that is used to carry the offer is established as bidirectional and the BiDirId carried in the offer is valid only for that connection. > > Perhaps your use-case is for a simple client that connects to > just one server > but a **specification** cannot be limited to work only in > that scenario. > The example I provided above is as simple as I can come up with and it does have a simple client and one server. However, it can readily be expanded to multiple servers and multiple clients without any change in the processing. > Dave > > > -----Original Message----- > From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] > Sent: Monday, April 12, 2004 2:39 PM > To: firewall-traversal-ftf@omg.org > Cc: Bergersen, Rebecca > Subject: RE: issue 7225 -- Firewall Traversal FTF issue > > > > Comments inlined > > --Rebecca > > > -----Original Message----- > > From: Juergen Boldt [mailto:juergen@omg.org] > > Sent: Monday, April 12, 2004 4:35 PM > > To: issues@omg.org; firewall-traversal-ftf@omg.org > > Subject: issue 7225 -- Firewall Traversal FTF issue > > > > > > This is issue # 7225 From: Joncheng Kuo > > > > Implications about BiDirIds > > > > I'll use the following example to explain the implications > > that I derive > > from my understanding about the spec. I hope that it makes > > sense to you. If > > I'm wrong, please let me know. > > > > > > Suppose I set up a client that has some POAs with > > BI_DIR_EXPORT policy > > ALLOW. The client wants to invoke a server that accepts > > bi-directional > > GIOP. This invocation will cause callbacks to a few objects > > on the client > > using bi-directional GIOP. The server is not allowed to create new > > connections to the client. > > > > > > In the code of my client application, I can simply use the > following > > statement to invoke the target object. And I would expect > > that the target > > object will call back some of the objects on the client ORB > > during this > > invocation. > > > > > > obj = ...; // target > > obj.invoke_target(...); > > > > > > In order for the above scenario to work, I derive the following > > implications from the spec. > > > > > > 1. This invocation requires the target to call back on some > > of the objects > > on the client ORB. Because the client ORB has no knowledge > about what > > objects might be called back, the client ORB has to ensure that the > > BiDirIds on *all* of its POAs that have EXPORT policy ALLOW must be > > available at the server side. > > Agreed. We handled this by having the callback objects > "register" with the server after they have been created. The > server gets their BiDirIds from their IORs and stores them. > > > > > > > This conclusion also implies that the client ORB may have to > > track what > > BiDirIds that have been sent (and accepted) over every > > connection that > > allows bi-directional GIOP in order to figure out what > > BiDirIds have not > > yet been sent, assuming that you don't want to send all > > BiDirIds in every > > request. > > Yes, the client ORB has to keep track of what BiDirIds have > been sent and which ones haven't. > > > Furthermore, when someone creates a new POA with the > > EXPORT policy > > ALLOW later on the client ORB, the next new invocation on *each* > > bi-directional connection will also have to transmit the > > BiDirId for this > > new POA to the server side. > > > > That conclusion doesn't follow. The next invocation on an > object with an Offer policy will pick up the unoffered > BiDirId, put it in its ServiceContext, and send it to the > server. There's no implication that *every* bidir connection > will have to have it transmitted. > > > > > 2. When the server receives a GIOP Request with > > BI_DIR_GIOP_OFFER service > > context, the server cannot dispatch the request to the > target object > > implementation until this connection becomes bi-directional. > > Why? If the > > server dispatches the request before this connection becomes > > bi-directional, this request may fail because the target is > > not able to > > call back objects on the client ORB. In the case of Strong > > BiDirIds, the > > server may even have to send CHALLENGE and wait for RESPONSE > > before the > > server can dispatch the request. > > > > Agreed. > > > > > If we put both implications together in the case of Strong > > BiDirIds, when > > someone creates a new POA with EXPORT policy ALLOW on a > client ORB, a > > longer delay will be expected in the next request on *every* > > bi-directional > > connection because the server has to verify the BiDirId of > > this new POA no > > matter whether this new BiDirId will be used for callbacks on that > > connection or not. > > Again, I don't see how you conclude that every connection has > to be involved. > > > > To me this overhead is not acceptable if > > it is the only > > way to implement bi-directional GIOP according to the spec. I > > hope the spec > > can be written in a way that *allows* efficient > > implementation, though > > efficiency is not always a concern for everyone. > > > > > > > > > > ================================= > > Jürgen Boldt > > Director, Member Services > > > > Object Management Group > > 250 First Avenue, Suite 100 > > Needham, MA 02494 > > > > Tel. +1 781 444 0404 ext. 132 > > Fax: +1 781 444 0320 > > email: juergen@omg.org > > www www.omg.org > > > > ================================ > > > > > Date: Tue, 13 Apr 2004 18:36:55 -0400 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: Dave Stringer , firewall-traversal-ftf@omg.org Subject: Re: issue 7225 -- Firewall Traversal FTF issue X-Virus-Scanned: Symantec AntiVirus Scan Engine Comments from Joncheng below. Bergersen, Rebecca wrote: I guess I'm not making myself clear because your description is exactly what I meant. I didn't mean to disassociate the BiDirIds from the references! All I meant was to construct that lookup table. What BiDirIds do you construct your lookup table from? I suppose that your server ORB constructs this lookup table from the BiDirIds sent over OFFER service contexts, not from the list of callback object references sent through Register(), as the server ORB has no knowledge about what object references passed in an invocation will be used later. The BiDir "callback" objects are already being treated differently. They require a lookup of their BiDirId and a crossmatch with what connection they may be invoked over. The "callback" object references are just object references with a BiDirId. The ORB may treat it differently in searching for a connection for it, but, other than that, there is really not much difference. An ORB could simply ignore this BiDirId and creates a new connection for invocation on this "callback" object. Their ID can be challenged, and their response evaluated. You don't challenge or verify a BiDirId from an IOR. You challege or verify a BiDirId sent over OFFER service contexts. The BiDirId in an IOR does not contain a RSA modulus for you to verify. Building the lookup table is part of setting up the protocol. Yes, but building the lookup table should be done through the BiDirIds provided in the OFFER service context, not from the "registration". As I stated before, because the client ORB has no knowledge about what BiDirIds will be used over a particular connection, the client ORB has to send them all. And that's the point! Cheers, Joncheng If you think that it's necessary to standardize on "registering" the objects, that's fine with me. You say later: ... There's no implication that *every* bidir connection will have to have it transmitted. But there is just that implication. A BiDirId exists in the client (sic) ORB as soon as the POA is created. There is no way to associate it with just one of the many (even 1000s !!) of connections that might be open to other ORBs. I still don't get this point. I'm willing to believe it's valid but my view of how things work just doesn't match with the statement. Here's the simplest example I can come up with, a stock ticker example. Let me go through the steps and you tell me where I'm deviating from your view: Server processing 1. Initialize the ORB and obtain a reference to the RootPOA. 2. Create the stock registry servant and export the object ref to a file. This object has a Register() function, Deregister() function and a Notify() function. 3. Activate the POA Manager and call ORB.run() to allow the ORB to receive and process incoming requests. 4. Receive callback references registered by the client to indicate interest in receiving stock price change notifications 5. In order to accept client's bidirectional offer, the effective policies on each callback reference are overridden with the BidirectionalAcceptPolicy set to ALLOW. 6. Regularly notify overridden callback references of price changes Client processing 1. Initialize the ORB and obtain a reference to the RootPOA 2. Read and destringify the stock registry IOR, overriding the effective policies with a BidirectionalOfferPolicy set to ALLOW in order to allow a bidirectional offer to be made with invocations on this reference. 3. Create the callback POA with the effective BidirectionalExportPolicy set to ALLOW in order to allow an appropriate BiDirId to be published in the callback reference 4. Create and activate the callback object. 5. Register the callback object by invoking register() on the overridden stock registry object, passing the callback object as a parameter. 6. Activate the POA Manager and call ORB.run() to allow the ORB to receive and process incoming requests. 7. Receive incoming bidirectional callback invocations. The register() call to the server carries the offer and passes the callback object as a parameter. Only the connection that is used to carry the offer is established as bidirectional and the BiDirId carried in the offer is valid only for that connection. Perhaps your use-case is for a simple client that connects to just one server but a **specification** cannot be limited to work only in that scenario. The example I provided above is as simple as I can come up with and it does have a simple client and one server. However, it can readily be expanded to multiple servers and multiple clients without any change in the processing. Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 2:39 PM To: firewall-traversal-ftf@omg.org Cc: Bergersen, Rebecca Subject: RE: issue 7225 -- Firewall Traversal FTF issue Comments inlined --Rebecca -----Original Message----- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, April 12, 2004 4:35 PM To: issues@omg.org; firewall-traversal-ftf@omg.org Subject: issue 7225 -- Firewall Traversal FTF issue This is issue # 7225 From: Joncheng Kuo Implications about BiDirIds I'll use the following example to explain the implications that I derive from my understanding about the spec. I hope that it makes sense to you. If I'm wrong, please let me know. Suppose I set up a client that has some POAs with BI_DIR_EXPORT policy ALLOW. The client wants to invoke a server that accepts bi-directional GIOP. This invocation will cause callbacks to a few objects on the client using bi-directional GIOP. The server is not allowed to create new connections to the client. In the code of my client application, I can simply use the following statement to invoke the target object. And I would expect that the target object will call back some of the objects on the client ORB during this invocation. obj = ...; // target obj.invoke_target(...); In order for the above scenario to work, I derive the following implications from the spec. 1. This invocation requires the target to call back on some of the objects on the client ORB. Because the client ORB has no knowledge about what objects might be called back, the client ORB has to ensure that the BiDirIds on *all* of its POAs that have EXPORT policy ALLOW must be available at the server side. Agreed. We handled this by having the callback objects "register" with the server after they have been created. The server gets their BiDirIds from their IORs and stores them. This conclusion also implies that the client ORB may have to track what BiDirIds that have been sent (and accepted) over every connection that allows bi-directional GIOP in order to figure out what BiDirIds have not yet been sent, assuming that you don't want to send all BiDirIds in every request. Yes, the client ORB has to keep track of what BiDirIds have been sent and which ones haven't. Furthermore, when someone creates a new POA with the EXPORT policy ALLOW later on the client ORB, the next new invocation on *each* bi-directional connection will also have to transmit the BiDirId for this new POA to the server side. That conclusion doesn't follow. The next invocation on an object with an Offer policy will pick up the unoffered BiDirId, put it in its ServiceContext, and send it to the server. There's no implication that *every* bidir connection will have to have it transmitted. 2. When the server receives a GIOP Request with BI_DIR_GIOP_OFFER service context, the server cannot dispatch the request to the target object implementation until this connection becomes bi-directional. Why? If the server dispatches the request before this connection becomes bi-directional, this request may fail because the target is not able to call back objects on the client ORB. In the case of Strong BiDirIds, the server may even have to send CHALLENGE and wait for RESPONSE before the server can dispatch the request. Agreed. If we put both implications together in the case of Strong BiDirIds, when someone creates a new POA with EXPORT policy ALLOW on a client ORB, a longer delay will be expected in the next request on *every* bi-directional connection because the server has to verify the BiDirId of this new POA no matter whether this new BiDirId will be used for callbacks on that connection or not. Again, I don't see how you conclude that every connection has to be involved. To me this overhead is not acceptable if it is the only way to implement bi-directional GIOP according to the spec. I hope the spec can be written in a way that *allows* efficient implementation, though efficiency is not always a concern for everyone. ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ Subject: RE: issue 7225 -- Firewall Traversal FTF issue Date: Tue, 13 Apr 2004 18:50:36 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 7225 -- Firewall Traversal FTF issue Thread-Index: AcQgz6y/R5VB2/32QaiO/Hwo1zoIZAABZ4pAAABn99AAJiN/QAAFWxUwAAiiU2A= From: "Bergersen, Rebecca" To: "Dave Stringer" , Cc: "Bergersen, Rebecca" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3DMrJna014408 I think we're getting closer, yes! I've found that many times it takes walking through something step by step for somebody to declare that 'oh! I meant this, while you meant that at this step' or 'Uh... we would use these steps, not those' and understanding of each other's point of view gets clearer. I'm sorry about the tutorial - I know you know all that. I needed it in order to understand where we were diverging. Between this and Polar's help with the scurity angle, I'm understanding many of the points that confused me before. All right, I agree that offers must be sent out over all legitimate connections - that is, ones that allow an offer. I agree that all unoffered BiDirIds must be sent when an offer is made. Where does that leave us? If we state the above and shut down all special cases that could use NegotiateSession messages (codeset, et al) do we a viable spec? --Rebecca > -----Original Message----- > From: Dave Stringer [mailto:Dave.Stringer@borland.com] > Sent: Tuesday, April 13, 2004 2:43 PM > To: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > Subject: RE: issue 7225 -- Firewall Traversal FTF issue > > > Rebecca > > You wrote, at the end of tutorial ;-) : > > > The register() call to the server carries the offer and passes > > the callback object as a parameter. Only the connection that is > > used to carry the offer is established as bidirectional and the > > BiDirId carried in the offer is valid only for that connection. > > This is the problem. As you said, "register" is just one of many ways > The object reference could arrive at the server. E.g. it > could be bound > to some name in a completely separate name service (i.e. at a > different > internet address) from where the server gets the reference by > "resolve". > Or stringified and then cut-and-paste into an Instant Message. > > Now in these cases there has been no communication between the client > and server over the bideirectional connection, the server hasn't yet > seen the BiDirId to Connection association. It can't send the inverse > direction Request message. In the absence of the "register" > Reguest over > the would-be bidirectional connection. The client ORB has to send a > NegotiateSession Message with the BI_DIR_GIOP_OFFER service context. > > BUT as the ORB can't predict which connection the newly > created BiDirId > will apply to it has to send it offer every open connection. It is > difficult for it to even narrow these down to ones "declared" to be > "Offer=ALLOW" as that policy applies to an object reference, and as > we agreed earlier, an object reference is not synonymous with > a connection. > > It appears to me as if your scenario relies on the "register" Request > message being sent over the same connection that the reverse > direction > "notify" will also be sent over. Unfortunately there is no > support for > this assumption in the spec and therefore very little hope that two > implementations of the spec would interoperate. > > Hope we are iterating nearer to a common understanding :-) > > Dave > > -----Original Message----- > From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] > Sent: Tuesday, April 13, 2004 11:15 AM > To: Dave Stringer; firewall-traversal-ftf@omg.org > Cc: Bergersen, Rebecca > Subject: RE: issue 7225 -- Firewall Traversal FTF issue > > > Comments inline... > --Rebecca > > > -----Original Message----- > > From: Dave Stringer [mailto:Dave.Stringer@borland.com] > > Sent: Tuesday, April 13, 2004 11:31 AM > > To: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > > Subject: RE: issue 7225 -- Firewall Traversal FTF issue > > > > > > Rebecca > > > > To pull out part of your response: > > > > > Agreed. We handled this by having the callback objects > > "register" with > > > the server after they have been created. The server gets > > their BiDirIds > > > from their IORs and stores them. > > > > What do you mean by "register"? Does this imply any > > additional semantics > > over and above the normal ways in which an object reference > > is acquired? > > E.g. invoking string_to_object or unmarshaling a > > CORBA::Object parameter. > > The registration process is the mechanism we put in place to > inform the server about the callback objects. It's a > server-side operation. The client app, after it has created > a callback object, calls register(), passing the newly > created object as a parameter. > > There are any number of ways the client can get its callback > objects to the server. The idea of "registering" a newly > created object is used in so many places we just reused the > idea here, since the standard didn't specify any particular mechanism. > > > > > I think we must be at cross-purposes because it makes no > > sense to me to > > say "The server gets their BidirIds from their IOR and stores > > them". The > > server needs the BiDirIds to remain associated with the > > object references. > > When the application on this (server) ORB wants to make an > > invocation on > > an object reference, the ORB will have to find the BiDirId > > for that object > > reference and then look that up against all the connections > > and the advertised > > BiDirIds they they represent. > > I guess I'm not making myself clear because your description > is exactly what I meant. I didn't mean to disassociate the > BiDirIds from the references! All I meant was to construct > that lookup table. > > > > > I'm also concerned over your use of the term "callback > > object". To the server > > these are just object references and whatever you assert is > > done for callback > > object references will have to be done for all object > > references. Unless of > > course you're thinking of a different treatment for object > > references that > > include a TAG_BI_DIR_GIOP, in which case that different > > treatment needs to > > be spelled out. > > The BiDir "callback" objects are already being treated > differently. They require a lookup of their BiDirId and a > crossmatch with what connection they may be invoked over. > Their ID can be challenged, and their response evaluated. > Building the lookup table is part of setting up the protocol. > If you think that it's necessary to standardize on > "registering" the objects, that's fine with me. > > > > > You say later: > > > ... There's no implication that *every* bidir connection > > will have to have > > > it transmitted. > > > > But there is just that implication. A BiDirId exists in the > > client (sic) ORB > > as soon as the POA is created. There is no way to associate > > it with just one > > of the many (even 1000s !!) of connections that might be open > > to other ORBs. > > I still don't get this point. I'm willing to believe it's > valid but my view of how things work just doesn't match with > the statement. Here's the simplest example I can come up > with, a stock ticker example. Let me go through the steps > and you tell me where I'm deviating from your view: > > Server processing > 1. Initialize the ORB and obtain a reference to the RootPOA. > 2. Create the stock registry servant and export the > object ref to a file. > This object has a Register() function, Deregister() > function and > a Notify() function. > 3. Activate the POA Manager and call ORB.run() to allow > the ORB to receive > and process incoming requests. > 4. Receive callback references registered by the client > to indicate > interest in receiving stock price change notifications > 5. In order to accept client's bidirectional offer, the > effective policies > on each callback reference are overridden with the > BidirectionalAcceptPolicy set to ALLOW. > 6. Regularly notify overridden callback references of > price changes > > Client processing > 1. Initialize the ORB and obtain a reference to the RootPOA > 2. Read and destringify the stock registry IOR, > overriding the effective > policies with a BidirectionalOfferPolicy set to > ALLOW in order to > allow a bidirectional offer to be made with > invocations on this > reference. > 3. Create the callback POA with the effective > BidirectionalExportPolicy > set to ALLOW in order to allow an appropriate > BiDirId to be published > in the callback reference > 4. Create and activate the callback object. > 5. Register the callback object by invoking register() > on the overridden > stock registry object, passing the callback object > as a parameter. > 6. Activate the POA Manager and call ORB.run() to allow > the ORB to receive > and process incoming requests. > 7. Receive incoming bidirectional callback invocations. > > The register() call to the server carries the offer and > passes the callback object as a parameter. Only the > connection that is used to carry the offer is established as > bidirectional and the BiDirId carried in the offer is valid > only for that connection. > > > > > Perhaps your use-case is for a simple client that connects to > > just one server > > but a **specification** cannot be limited to work only in > > that scenario. > > > > The example I provided above is as simple as I can come up > with and it does have a simple client and one server. > However, it can readily be expanded to multiple servers and > multiple clients without any change in the processing. > > > Dave > > > > > > -----Original Message----- > > From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] > > Sent: Monday, April 12, 2004 2:39 PM > > To: firewall-traversal-ftf@omg.org > > Cc: Bergersen, Rebecca > > Subject: RE: issue 7225 -- Firewall Traversal FTF issue > > > > > > > > Comments inlined > > > > --Rebecca > > > > > -----Original Message----- > > > From: Juergen Boldt [mailto:juergen@omg.org] > > > Sent: Monday, April 12, 2004 4:35 PM > > > To: issues@omg.org; firewall-traversal-ftf@omg.org > > > Subject: issue 7225 -- Firewall Traversal FTF issue > > > > > > > > > This is issue # 7225 From: Joncheng Kuo > > > > > > Implications about BiDirIds > > > > > > I'll use the following example to explain the implications > > > that I derive > > > from my understanding about the spec. I hope that it makes > > > sense to you. If > > > I'm wrong, please let me know. > > > > > > > > > Suppose I set up a client that has some POAs with > > > BI_DIR_EXPORT policy > > > ALLOW. The client wants to invoke a server that accepts > > > bi-directional > > > GIOP. This invocation will cause callbacks to a few objects > > > on the client > > > using bi-directional GIOP. The server is not allowed to > create new > > > connections to the client. > > > > > > > > > In the code of my client application, I can simply use the > > following > > > statement to invoke the target object. And I would expect > > > that the target > > > object will call back some of the objects on the client ORB > > > during this > > > invocation. > > > > > > > > > obj = ...; // target > > > obj.invoke_target(...); > > > > > > > > > In order for the above scenario to work, I derive the following > > > implications from the spec. > > > > > > > > > 1. This invocation requires the target to call back on some > > > of the objects > > > on the client ORB. Because the client ORB has no knowledge > > about what > > > objects might be called back, the client ORB has to > ensure that the > > > BiDirIds on *all* of its POAs that have EXPORT policy > ALLOW must be > > > available at the server side. > > > > Agreed. We handled this by having the callback objects > > "register" with the server after they have been created. The > > server gets their BiDirIds from their IORs and stores them. > > > > > > > > > > > This conclusion also implies that the client ORB may have to > > > track what > > > BiDirIds that have been sent (and accepted) over every > > > connection that > > > allows bi-directional GIOP in order to figure out what > > > BiDirIds have not > > > yet been sent, assuming that you don't want to send all > > > BiDirIds in every > > > request. > > > > Yes, the client ORB has to keep track of what BiDirIds have > > been sent and which ones haven't. > > > > > Furthermore, when someone creates a new POA with the > > > EXPORT policy > > > ALLOW later on the client ORB, the next new invocation on *each* > > > bi-directional connection will also have to transmit the > > > BiDirId for this > > > new POA to the server side. > > > > > > > That conclusion doesn't follow. The next invocation on an > > object with an Offer policy will pick up the unoffered > > BiDirId, put it in its ServiceContext, and send it to the > > server. There's no implication that *every* bidir connection > > will have to have it transmitted. > > > > > > > > 2. When the server receives a GIOP Request with > > > BI_DIR_GIOP_OFFER service > > > context, the server cannot dispatch the request to the > > target object > > > implementation until this connection becomes bi-directional. > > > Why? If the > > > server dispatches the request before this connection becomes > > > bi-directional, this request may fail because the target is > > > not able to > > > call back objects on the client ORB. In the case of Strong > > > BiDirIds, the > > > server may even have to send CHALLENGE and wait for RESPONSE > > > before the > > > server can dispatch the request. > > > > > > > Agreed. > > > > > > > > If we put both implications together in the case of Strong > > > BiDirIds, when > > > someone creates a new POA with EXPORT policy ALLOW on a > > client ORB, a > > > longer delay will be expected in the next request on *every* > > > bi-directional > > > connection because the server has to verify the BiDirId of > > > this new POA no > > > matter whether this new BiDirId will be used for > callbacks on that > > > connection or not. > > > > Again, I don't see how you conclude that every connection has > > to be involved. > > > > > > > To me this overhead is not acceptable if > > > it is the only > > > way to implement bi-directional GIOP according to the spec. I > > > hope the spec > > > can be written in a way that *allows* efficient > > > implementation, though > > > efficiency is not always a concern for everyone. > > > > > > > > > > > > > > > ================================= > > > Jürgen Boldt > > > Director, Member Services > > > > > > Object Management Group > > > 250 First Avenue, Suite 100 > > > Needham, MA 02494 > > > > > > Tel. +1 781 444 0404 ext. 132 > > > Fax: +1 781 444 0320 > > > email: juergen@omg.org > > > www www.omg.org > > > > > > ================================ > > > > > > > > > Date: Tue, 13 Apr 2004 20:55:09 -0400 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: Dave Stringer , firewall-traversal-ftf@omg.org Subject: Re: issue 7225 -- Firewall Traversal FTF issue X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: All right, I agree that offers must be sent out over all legitimate connections - that is, ones that allow an offer. I agree that all unoffered BiDirIds must be sent when an offer is made. This inefficiency can be greatly improved if you simply allow applications to supply a list of object references to be "called back" in the BidirectionalOfferPolicy. In other words, we'll have three values in the policy: ALLOW_ALL, ALLOW_LISTED, and DENY. This change should be fairly easy. Joncheng Where does that leave us? If we state the above and shut down all special cases that could use NegotiateSession messages (codeset, et al) do we a viable spec? --Rebecca Subject: RE: issue 7225 -- Firewall Traversal FTF issue Date: Wed, 14 Apr 2004 10:34:26 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 7225 -- Firewall Traversal FTF issue Thread-Index: AcQgz6y/R5VB2/32QaiO/Hwo1zoIZAABZ4pAAABn99AAJiN/QAAFWxUwAAiiU2AAJS7Z0A== From: "Dave Stringer" To: "Bergersen, Rebecca" , X-OriginalArrivalTime: 14 Apr 2004 17:34:26.0343 (UTC) FILETIME=[BB95D370:01C42246] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3EHdLna022876 Rebecca You wrote: > All right, I agree that offers must be sent out over all legitimate > connections - that is, ones that allow an offer. I agree that all > unoffered BiDirIds must be sent when an offer is made. > Next point, what is a "legitimate connection"? I assume that by "allow an offer" you're drawing on the BidirectionalOfferPolicy. The policy is applied to an object reference and not to a GIOP connection. I still maintain it is dangerous for a specification to assume a particular relationship between an object reference and a connection - without making this assumption explicit. So lets explore this ... This policy is applied to an object reference held by an ORB (any ORB!) but for this discussion we'll confine it to the connection-initiating ORB (sometimes colloquially called the "client ORB"). Now the connection is not initiated (even in the uni-dir case) until there is an invocation upon the object reference. [I'll skip over the validate_connection rathole, for now ;-) ] Next suppose that before ever invoking on this reference, I call set_policy_overrides to set a BidirectioanlOfferPolicy=ALLOW. There are now two object references held by the connection-initiating ORB that happen to point at the same host,port but that have different policy. There is no legitimate connection as there is no connection at all just yet. Next suppose that an invocation is made upon the first object reference, the one without a BidirectionalOfferPolicy. A connection will be setup but is it legitimate or illegitimate? On the one hand it is onerous for the ORB to look through all other object references it holds to see any would eventually share that connection if it were to be invoked upon (this would involve a determination of its policy, e.g. the RTCORBA::PrivateConnectionPolicy). So I guess we take the other option and deem the connection to still be illegitimate. When there is an invocation on the 2nd object reference (the one with Offer=ALLOW policy) the connection can be legitimised and all exisitng (and future) BiDirIds can be sent over the connection. What if the connection is closed due to an ORB internal idle timeout? It will be reconnected upon an invocation upon the first object reference. But now it will again be illegitimate (or is the ORB expected to remember that this is a reincarnation of a connection that was made before? This model presents the programmer a problem. The connection is legitimised only by the invocation of an operation on a suitable object reference. How does the programmer know when that needs to be repeated? What if the 2nd object reference is destroyed? Does the connection revert to illegitimate? This needs to be stated if the ORB is obliged to convey every new BiDirId along every "legitimate" connection. > Where does that leave us? If we state the above and shut down all > special cases that could use NegotiateSession messages (codeset, > et al) do we a viable spec? > The spec would still need a definition for "legitimate". It needs proper defintions for the "connection setup", "session setup" and "connection established" periods of a GIOP connection. It needs all constraints on the sequencing of the flavours of NegotiateSession message to be made explicit. To conclude, I think the spec is a bad spec. If it is made available it will, in my opinion, cause pain and suffering. I'm not sure if that means it isn't viable. Dave