Issue 7312: What BiDirIds shall be sent over what bidirectional connections? (firewall-traversal-ftf) Source: Syracuse University (Mr. C. Joncheng Kuo, joncheng_kuo@bristol.com) Nature: Uncategorized Issue Severity: Summary: The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send *all* BiDirIds on an ORB to *every* connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of *every* existing bi-directional connections (before or in the next request). The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted. Proposed resolution: 1. Extend the choices of the value field of the BidirectionalOfferPolicy: ALLOW_ALL -- same as ALLOW now, but the implication shall be explicitely stated in the spec ALLOW_LISTED -- a list of POAs being provided in the policy DENY -- same as it now 2. Add a field to the policy to allow a sequence of POAs being specified. Resolution: Revised Text: Actions taken: May 6, 2004: received issue Discussion: End of Annotations:===== te: Thu, 06 May 2004 17:07:33 -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: issues@omg.org CC: firewall-traversal-ftf@omg.org Subject: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send *all* BiDirIds on an ORB to *every* connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of *every* existing bi-directional connections (before or in the next request). The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted. Proposed resolution: 1. Extend the choices of the value field of the BidirectionalOfferPolicy: ALLOW_ALL -- same as ALLOW now, but the implication shall be explicitely stated in the spec ALLOW_LISTED -- a list of POAs being provided in the policy DENY -- same as it now 2. Add a field to the policy to allow a sequence of POAs being specified. Joncheng Kuo Syracuse University Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Date: Fri, 7 May 2004 15:27:45 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQzro1zHUZUV9v3Qoqvphf/SYwKdQAub4BQ From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i47JTCFh019902 If I'm understanding you correctly, you want to be able to specify which BiDirIds get sent over which connections. However, your recommendation only specifies the 'which BiDirIds' part of the process. 'Which connections' is left unspecified when the policy value is ALLOW_LISTED. In normal use, I doubt that there will be very many POAs for a particular client and there will be very few separate connections between the particular client and the server, so we're not talking about a significant difference between the m*n and c*n cases. The protocol should be tuned for the normal situation, so I don't see a significant need for ALLOW_LISTED value and its attendant list. Do you really think that the usual condition will have a large number of separate connections between a single client and server? --Rebecca > -----Original Message----- > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > Sent: Thursday, May 06, 2004 5:08 PM > To: issues@omg.org > Cc: firewall-traversal-ftf@omg.org > Subject: Firewall Issue: What BiDirIds shall be sent over what > bidirectional connections? > > > The new BiDir spec is not clean about what BiDirIds shall be send to > what connections. Because the BidirectionalOfferPolicy is > either ALLOW > or DENY, the only way to make bi-directional GIOP possible is to send > *all* BiDirIds on an ORB to *every* connection that is used > by an object > reference that has effective BidirectionalOfferPolicy ALLOW. Besides, > when a new POA with BidirectionalExportPolicy ALLOW is created, the > BiDirId of this new POA must be transmitted to the server side of > *every* existing bi-directional connections (before or in the > next request). > > The above implication derived from the spec is very inefficient. > Consider an ORB with n bi-directional connections and m BiDirIds. The > communication overhead for sending these BiDirIds is (m * n), > while, in > the ideal case, the communication overhead for sending > BiDirIds is (c * > n) where c is the average number of BiDirIds needed on each > bi-directional connection. This ideal case can be easily achieved by > allowing the BidirectionalOfferPolicy to specify a list of POAs whose > BiDirIds shall be transmitted. > > Proposed resolution: > 1. Extend the choices of the value field of the > BidirectionalOfferPolicy: > ALLOW_ALL -- same as ALLOW now, but the implication shall be > explicitely stated in the spec > ALLOW_LISTED -- a list of POAs being provided in the policy > DENY -- same as it now > 2. Add a field to the policy to allow a sequence of POAs > being specified. > > Joncheng Kuo > Syracuse University > > > > Date: Fri, 07 May 2004 17:11:45 -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: "Bergersen, Rebecca" CC: firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Bergersen, Rebecca wrote: If I'm understanding you correctly, you want to be able to specify which BiDirIds get sent over which connections. However, your recommendation only specifies the 'which BiDirIds' part of the process. 'Which connections' is left unspecified when the policy value is ALLOW_LISTED. If you set the BidirectionalOfferPolicy on a particular object reference, it's obvious that these listed BiDirIds are sent on the connections to be used for the invocations on that particular object reference. Similarly, if this policy is set on the ORB, it's for all connections unless overridden. In normal use, I doubt that there will be very many POAs for a particular client and there will be very few separate connections between the particular client and the server, so we're not talking about a significant difference between the m*n and c*n cases. A protocol is not just for a few use cases (what you called "normal"), it's for various uses that are possible with the protocol. As a protocol designer, making a simple, realistic, yet flexible protocol is really important. My proposed resolution is simple yet powerful enough to solve a potential performance issue. Why do you want to reject it and hold on only the simplistic use cases? Joncheng The protocol should be tuned for the normal situation, so I don't see a significant need for ALLOW_LISTED value and its attendant list. Do you really think that the usual condition will have a large number of separate connections between a single client and server? --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Thursday, May 06, 2004 5:08 PM To: issues@omg.org Cc: firewall-traversal-ftf@omg.org Subject: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send *all* BiDirIds on an ORB to *every* connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of *every* existing bi-directional connections (before or in the next request). The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted. Proposed resolution: 1. Extend the choices of the value field of the BidirectionalOfferPolicy: ALLOW_ALL -- same as ALLOW now, but the implication shall be explicitely stated in the spec ALLOW_LISTED -- a list of POAs being provided in the policy DENY -- same as it now 2. Add a field to the policy to allow a sequence of POAs being specified. Joncheng Kuo Syracuse University Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Date: Mon, 10 May 2004 15:08:52 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQ0d/L/OWWKvWZFROiRxK2tK1MKXgCSWd1w From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: Your proposal makes the *application* responsible for defining what BiDirIds go out over what connections. I think the application should keep its hands off both BiDirIds and connections. That is something that the infrastructure should be completely responsible for. You are talking about having the application do some sort of load balancing and that's not an appropriate requirement for most apps. The management of connections and the data that flows over them is the responsibility of the ORB, not the application. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Friday, May 07, 2004 5:12 PM To: Bergersen, Rebecca Cc: firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Bergersen, Rebecca wrote: If I'm understanding you correctly, you want to be able to specify which BiDirIds get sent over which connections. However, your recommendation only specifies the 'which BiDirIds' part of the process. 'Which connections' is left unspecified when the policy value is ALLOW_LISTED. If you set the BidirectionalOfferPolicy on a particular object reference, it's obvious that these listed BiDirIds are sent on the connections to be used for the invocations on that particular object reference. Similarly, if this policy is set on the ORB, it's for all connections unless overridden. In normal use, I doubt that there will be very many POAs for a particular client and there will be very few separate connections between the particular client and the server, so we're not talking about a significant difference between the m*n and c*n cases. A protocol is not just for a few use cases (what you called "normal"), it's for various uses that are possible with the protocol. As a protocol designer, making a simple, realistic, yet flexible protocol is really important. My proposed resolution is simple yet powerful enough to solve a potential performance issue. Why do you want to reject it and hold on only the simplistic use cases? Joncheng The protocol should be tuned for the normal situation, so I don't see a significant need for ALLOW_LISTED value and its attendant list. Do you really think that the usual condition will have a large number of separate connections between a single client and server? --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Thursday, May 06, 2004 5:08 PM To: issues@omg.org Cc: firewall-traversal-ftf@omg.org Subject: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send *all* BiDirIds on an ORB to *every* connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of *every* existing bi-directional connections (before or in the next request). The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted. Proposed resolution: 1. Extend the choices of the value field of the BidirectionalOfferPolicy: ALLOW_ALL -- same as ALLOW now, but the implication shall be explicitely stated in the spec ALLOW_LISTED -- a list of POAs being provided in the policy DENY -- same as it now 2. Add a field to the policy to allow a sequence of POAs being specified. Joncheng Kuo Syracuse University Date: Mon, 10 May 2004 16:28:37 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? On Mon, 10 May 2004, Bergersen, Rebecca wrote: > Your proposal makes the *application* responsible for defining what > BiDirIds go out over what connections. I think the application should > keep its hands off both BiDirIds and connections. That is something > that the infrastructure should be completely responsible for. You are > talking about having the application do some sort of load balancing and > that's not an appropriate requirement for most apps. The management of > connections and the data that flows over them is the responsibility of > the ORB, not the application. I think what Joncheng might be getting at, is not the BiDirIds explicitly, but some way to indicate which BiDirIds may be sent. Since these things seem to be tightly coupled to the object adabpter, perhaps you can use the adapter ids. -Polar Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Date: Mon, 10 May 2004 17:19:36 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQ2zYlxw7q55t5eRqCj7xCq4tN00gAAK4ig From: "Bergersen, Rebecca" To: "Polar Humenn" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4ALMX8k004796 Joncheng says in the earlier part of this thread, that "My proposed resolution is simple yet powerful enough to solve a potential performance issue." The performance issue was defined as follows: "The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send *all* BiDirIds on an ORB to *every* connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of *every* existing bi-directional connections (before or in the next request). "The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted." Joncheng's proposal is designed to address the number of BiDirIds that use a particular connection. True, he raises the level of abstraction of the BiDirId to the POA. However, the proposal addresses only half of the problem. It neglects to define the means of assigning the 'c' BiDirIds to a particular connection or of querying a connection to determine how many BiDirIds are used on it so that 'c' can be reached, or, indeed, of determining how many connections (and which ones) are bi-directional. The proposal's goal is to balance the load 'for performance reasons'. Even if the proposal were complete, I'd still say it's up to the ORB to deal with connection management and the generation and distribution of BiDirIds. It's not the application's responsibility. Only very specialized applications (and a very specialized ORB) allow an app to even know, much less determine, what connection an object invocation uses. This is an area we don't want to get into. After two or three weeks of arguing, I finally accepted your statement that *all* BiDirIds needed to be sent in an offer and that the offer be extended over *all* existing BiDir connections. That's what I wrote up as the resolution. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Monday, May 10, 2004 4:29 PM > To: firewall-traversal-ftf@omg.org > Subject: RE: Firewall Issue: What BiDirIds shall be sent over what > bidirectional connections? > > > > > On Mon, 10 May 2004, Bergersen, Rebecca wrote: > > > Your proposal makes the *application* responsible for defining what > > BiDirIds go out over what connections. I think the > application should > > keep its hands off both BiDirIds and connections. That is something > > that the infrastructure should be completely responsible > for. You are > > talking about having the application do some sort of load > balancing and > > that's not an appropriate requirement for most apps. The > management of > > connections and the data that flows over them is the > responsibility of > > the ORB, not the application. > > I think what Joncheng might be getting at, is not the > BiDirIds explicitly, > but some way to indicate which BiDirIds may be sent. Since > these things > seem to be tightly coupled to the object adabpter, perhaps you can use > the adapter ids. > > -Polar > Date: Mon, 10 May 2004 17:49:10 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? On Mon, 10 May 2004, Bergersen, Rebecca wrote: > Joncheng's proposal is designed to address the number of BiDirIds that > use a particular connection. I don't think it really says anything about connections. Just that when talking to a server behind a certain object reference, you shall make specific offers to that server. I think the ORB is free to do that however. It just states that any transport used to talk to that server should at least have an offer for the particular listed BiDirIds. > True, he raises the level of abstraction of the BiDirId to the POA. > However, the proposal addresses only half of the problem. Well, you certainly got that right! This whole shebang is a monstrosity. Halfway to infinity doesn't get you very far. > After two or three weeks of arguing, I finally accepted your statement > that *all* BiDirIds needed to be sent in an offer and that the offer be > extended over *all* existing BiDir connections. That's what I wrote up > as the resolution. I still think Joncheng's proposal has merit, and can avoid ghastly performance headaches on your so-called "edge-cases". However, I would state, that for a company that builds ORBs to serve that "edge-case", it is not an edge case. Although I can still see vast problems with the entire thing. It's certainly better to have a little programmatic control. -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 Date: Mon, 10 May 2004 18:03:21 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? To anxwer my own response, I don't like any of it! :) Dave Stringer brings up the very valid point about ending up with two conflicting object references, one with a policy of ALLOW and the other DENY, which blows the whole model out of the water. The same, would exist for NONE, ALL, and LISTED. There should probably be some other way to solve this problem without using CORBA Policies placed on object references. That's for sure. I think that object reference CORBA policy should just be eliminated. -Polar On Mon, 10 May 2004, Polar Humenn wrote: > On Mon, 10 May 2004, Bergersen, Rebecca wrote: > > > Joncheng's proposal is designed to address the number of BiDirIds that > > use a particular connection. > > I don't think it really says anything about connections. Just that when > talking to a server behind a certain object reference, you shall make > specific offers to that server. > > I think the ORB is free to do that however. It just states that any > transport used to talk to that server should at least have an offer for > the particular listed BiDirIds. > > > True, he raises the level of abstraction of the BiDirId to the POA. > > However, the proposal addresses only half of the problem. > > Well, you certainly got that right! This whole shebang is a monstrosity. > Halfway to infinity doesn't get you very far. > > > After two or three weeks of arguing, I finally accepted your statement > > that *all* BiDirIds needed to be sent in an offer and that the offer be > > extended over *all* existing BiDir connections. That's what I wrote up > > as the resolution. > > I still think Joncheng's proposal has merit, and can avoid ghastly > performance headaches on your so-called "edge-cases". However, I would > state, that for a company that builds ORBs to serve that "edge-case", it > is not an edge case. > > Although I can still see vast problems with the entire thing. It's > certainly better to have a little programmatic control. > > -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 Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Date: Mon, 10 May 2004 18:53:23 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQ22LBzm4B77JgmQV2YO1q8Z5JDBwAAsdEg From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4AN408k005731 > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Monday, May 10, 2004 5:49 PM > To: Bergersen, Rebecca > Cc: firewall-traversal-ftf@omg.org > Subject: RE: Firewall Issue: What BiDirIds shall be sent over what > bidirectional connections? > > > On Mon, 10 May 2004, Bergersen, Rebecca wrote: > > > Joncheng's proposal is designed to address the number of > BiDirIds that > > use a particular connection. > > I don't think it really says anything about connections. Just > that when > talking to a server behind a certain object reference, you shall make > specific offers to that server. What're the m*n and c*n measures if they aren't discussing how many BiDirIds go over the connections? According to Joncheng, 'n' is the total number of bidirectional connections between a client and a server. He also says the total number of BiDirIds is 'm' and the average number is 'c'. Assuming all BiDirIds are eventually offered, if there is any difference between 'm' and 'c' it must be because a set of BiDirIds was not sent over every connection but only selected ones. Other BiDirIds (which, by the way, the application must now manage to make sure all get offered) are offered over some of the same and some other connections, thereby eventually achieving Joncheng's goal of averaging the load, which he says will provide better performance. Averaging the load is load balancing, not an application's job. And, in order to accomplish it, you must select some connections but not all for each set of IDs. If you are going to eventually offer all BiDirIds, then 'm' and 'c' are the same unless you send sets out over less than all connections and judge for each set how much overhead each will entail and keep track of which connections are handling which sets. You definitely do have to deal with connections in Joncheng's proposal. > > I think the ORB is free to do that however. It just states that any > transport used to talk to that server should at least have an > offer for > the particular listed BiDirIds. > > > True, he raises the level of abstraction of the BiDirId to the POA. > > However, the proposal addresses only half of the problem. > > Well, you certainly got that right! This whole shebang is a > monstrosity. > Halfway to infinity doesn't get you very far. I was talking about Joncheng's proposal. :-) > > > After two or three weeks of arguing, I finally accepted > your statement > > that *all* BiDirIds needed to be sent in an offer and that > the offer be > > extended over *all* existing BiDir connections. That's > what I wrote up > > as the resolution. > > I still think Joncheng's proposal has merit, and can avoid ghastly > performance headaches on your so-called "edge-cases". However, I would > state, that for a company that builds ORBs to serve that > "edge-case", it > is not an edge case. > > Although I can still see vast problems with the entire thing. It's > certainly better to have a little programmatic control. I just don't agree that an application should have programmatic control over what connections are used and the load they carry. You're treading on active connection management, on fault tolerance, on other load balancing and load distribution services that almost every ORB provides. And you're attempting to do this at the *application* level, making for much more complex (and error-prone) applications since they will have to be aware of and coordinate with all of these facilities as well as have the logic in place for performing the 'averaging' strategy. This is not a good thing. --Rebecca > > -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 > Date: Mon, 10 May 2004 22:47:39 -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: Polar Humenn , firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? X-Virus-Scanned: Symantec AntiVirus Scan Engine Hi, Rebecca, I think Polar's understanding about my proposal is right. Having a policy with a list of POAs (or BiDirIds) requires invocations using that policy must have these BiDirIds sent over the connection to be used. The ORB can still send all BiDirIds to all (bidir) connections and still satisfy this requirement, though, in this case, there is no performance gain. Bergersen, Rebecca wrote: I just don't agree that an application should have programmatic control over what connections are used and the load they carry. Applications don't have actual control over connections, but it is sometimes needed for applications to use policies to give requirements or hints to the ORB such that the ORB can do a proper or better job, e.g., the REBIND policy. Cheers, Joncheng You're treading on active connection management, on fault tolerance, on other load balancing and load distribution services that almost every ORB provides. And you're attempting to do this at the *application* level, making for much more complex (and error-prone) applications since they will have to be aware of and coordinate with all of these facilities as well as have the logic in place for performing the 'averaging' strategy. This is not a good thing. --Rebecca -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 Date: Mon, 10 May 2004 23:10:56 -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: Polar Humenn , firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: After two or three weeks of arguing, I finally accepted your statement that *all* BiDirIds needed to be sent in an offer and that the offer be extended over *all* existing BiDir connections. That's what I wrote up as the resolution. It was required for the ORB to send *all* BiDirIds because the ORB had no idea what BiDirIds would be needed on a connection for a particular invocation. Now I'm proposing a way to give the ORB some hints about what BiDirIds would be used for invocations on a particular object reference. The proposal is not talking about directly controlling BiDirIds over connections. It is talking about a list of BiDirIds that must be sent over a connection on which an invocation using that BidirectionalOfferPolicy (ALLOW_LISTED). The ORB can send only this list, or all BiDirIds. Besides, if there is no invocations, the ORB does not even have to send anything, though the ORB is still free to send something if it wishes. I know it's a little confusing by mentioning various possible implementations of the same requirement, but I try to distinguish between a specification requirement and possible implementations that satisfy this requirement. Joncheng --Rebecca Date: Tue, 11 May 2004 08:26:39 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by amethyst.omg.org id i4BCS58k009789 Rebecca, If you think programmatic control shouldn't be given to the application, then why is the application in charge of doing anything? We should just eliminate the policies and just state it's up to the ORB to guess what the application wants to do, or say that there is some proprietary configuration that the ORB can do to perform BiDir in this horrible manner. -Polar On Mon, 10 May 2004, Bergersen, Rebecca wrote: > > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Monday, May 10, 2004 5:49 PM > > To: Bergersen, Rebecca > > Cc: firewall-traversal-ftf@omg.org > > Subject: RE: Firewall Issue: What BiDirIds shall be sent over what > > bidirectional connections? > > > > > > On Mon, 10 May 2004, Bergersen, Rebecca wrote: > > > > > Joncheng's proposal is designed to address the number of > > BiDirIds that > > > use a particular connection. > > > > I don't think it really says anything about connections. Just > > that when > > talking to a server behind a certain object reference, you shall make > > specific offers to that server. > > What're the m*n and c*n measures if they aren't discussing how many BiDirIds go over the connections? According to Joncheng, 'n' is the total number of bidirectional connections between a client and a server. He also says the total number of BiDirIds is 'm' and the average number is 'c'. Assuming all BiDirIds are eventually offered, if there is any difference between 'm' and 'c' it must be because a set of BiDirIds was not sent over every connection but only selected ones. Other BiDirIds (which, by the way, the application must now manage to make sure all get offered) are offered over some of the same and some other connections, thereby eventually achieving Joncheng's goal of averaging the load, which he says will provide better performance. Averaging the load is load balancing, not an application's job. And, in order to accomplish it, you must select some connections but not all for each set of IDs. If you are going to eventually offer all BiDirIds, then 'm' and 'c' are the same unless you send sets out over less than all connections and judge for each set how much overhead each will entail and keep track of which connections are handling which sets. You definitely do have to deal with connections in Joncheng's proposal. > > > > > I think the ORB is free to do that however. It just states that any > > transport used to talk to that server should at least have an > > offer for > > the particular listed BiDirIds. > > > > > True, he raises the level of abstraction of the BiDirId to the POA. > > > However, the proposal addresses only half of the problem. > > > > Well, you certainly got that right! This whole shebang is a > > monstrosity. > > Halfway to infinity doesn't get you very far. > > I was talking about Joncheng's proposal. :-) > > > > > > After two or three weeks of arguing, I finally accepted > > your statement > > > that *all* BiDirIds needed to be sent in an offer and that > > the offer be > > > extended over *all* existing BiDir connections. That's > > what I wrote up > > > as the resolution. > > > > I still think Joncheng's proposal has merit, and can avoid ghastly > > performance headaches on your so-called "edge-cases". However, I would > > state, that for a company that builds ORBs to serve that > > "edge-case", it > > is not an edge case. > > > > Although I can still see vast problems with the entire thing. It's > > certainly better to have a little programmatic control. > > I just don't agree that an application should have programmatic control over what connections are used and the load they carry. You're treading on active connection management, on fault tolerance, on other load balancing and load distribution services that almost every ORB provides. And you're attempting to do this at the *application* level, making for much more complex (and error-prone) applications since they will have to be aware of and coordinate with all of these facilities as well as have the logic in place for performing the 'averaging' strategy. This is not a good thing. > > --Rebecca > > > > > -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: Tue, 11 May 2004 09:42:38 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? On Mon, 10 May 2004, Bergersen, Rebecca wrote: > > > True, he raises the level of abstraction of the BiDirId to the POA. > > > However, the proposal addresses only half of the problem. > > > > Well, you certainly got that right! This whole shebang is a > > monstrosity. > > Halfway to infinity doesn't get you very far. > > I was talking about Joncheng's proposal. :-) And I was talking about the whole bloody specification even with Jonchengs proposal. :^( -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 Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Date: Tue, 11 May 2004 19:03:14 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQ3BZiJ2AtYYy/ITau2FuBhPQppZgAeM4Jw From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: "Polar Humenn" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4CDno8k025182 Joncheng, Polar, I can see so many problems with your proposal of having the client provide a 'hint' and a list of BiDirIds for a particular connection that I hardly know where to begin. So, let me walk you through some of my reasoning: 1. Offering specific BiDirIds over a connection implies that you know which connection acceptors (servers) will (potentially) be making callbacks to which callback objects. 2. You are trying to determine the connection by invoking on an object and the connection used by that invocation is the one that will have the offered BiDirIds associated with it. (More on that later) That presupposes that the application knows what specific server each object is associated with and that goes against the entire CORBA mindset. You require some very special configuration in the application, maybe by having servers know about their specific deployment and storing specific objects in specific files that the application clients know about and can distinguish. Otherwise, you just don't know what server is going to be used when you invoke on an object. What if there is more than one instance of a server in a deployment (a very common situation)? The application client will have to know that and make decisions based on it. 3. Since the client is defining which connections (and therefore which connection acceptors - servers) can be used to invoke on specific callback objects, that implies that the client must control the distribution of the references to those callback objects and make sure that every one of the appropriate server instances get every one of the appropriate references. The application that falls under these conditions is a special case because it is quite severely constrained. You say the application is doing all of this in order to have less overhead. What kind of overhead are we talking about? 1. There's the overhead of the BiDirIds carried in the offer. There would have to be a huge number of IDs sent in a single offer for this overhead to be significant. In the worst case, all of the BiDirIds in an offer would be strong IDs. A BiDirStrongOffer struct consists of an unsigned long index (32 bits), a BiDirId (160 bits) and a BiDirModulus (512 bits). The service context would contain a sequence of this struct and a short (16 bits) for the ID type it wants to offer. That's 720 bits or 45 bytes per ID offered. We have large scale deployments of this BiDir GIOP being used by customers in enterprise-wide operations (thousands of clients). The clients, when they use bi-directional GIOP, have dozens of callback objects but less than 100. So, let's say that 100 BiDirIds is the usual case, based on our experience (it's actually closer to half that.) That's 4500 bytes if they all went out in a single offer - a trivial amount even to send over all connections from a client. So, let's look at what would be considered an extreme edge case - a 1000 BiDirIds in a single offer. That's a message size of about 45K. IONA sets a message fragment size at 16K, so that's a single message of 3 fragments. That's not a big message. So, an offer, which is sent only once over a connection and in the worst case contains the strong BiDirIds for all of the callback objects in a client, can be sent in a single, small to reasonably-sized message. That's not much overhead. 2. There's the overhead for the connection acceptor (server) to keep track of the BiDirIds that apply to a connection. After any challenge/response has been dealt with, the only info that needs to be associated with the connection is the BiDirId (160 bits - 10 bytes). That's 10K of info for our edge condition above of 1000 callback objects in a single client. Assuming it's stored in a hash table, processing time won't be high but the storage/memory size is somewhat high - obviously 1K would be better than 10K. Let's further assume 1000 connections active to the server - all bi-directional! That would mean 10,000,000 bytes of info to manage for our edge case. You know, even that isn't bad. Servers commonly handle that and much more. So, the overhead you are talking about isn't significant even for an extreme edge case. 3. There's the overhead of the invocations on the callback objects coming from the connection acceptor to the connection initiator. Since the callback objects' BiDirIds are no longer associated with multiple connections, you have taken away the ability of the ORB to load balance. This has significantly added to your overhead. You've also taken away the flexibility of the deployment, since objects can't moved from server to server without client application changes. Let's continue by assuming an application that completely manages the distribution of specific callback object references to specific servers. Also assume that it is an edge case where each client has 1000 callback objects. I think this is a pathological application, but let's continue anyway. Let's see what the trade-off is for allowing the application to attempt to define which connections should handle which BiDirIds. 1. Since it's taking control, the client will have to make sure, itself, that all BiDirIds are offered. 2. It will have to know how the ORB is dealing with the hint: (Is it sending all BiDirIds anyway? Is it sending the BiDirIds over every connection anyway? It is just a hint, after all.) It must take into consideration the ORB's behavior on *each* offer since it must make sure all BiDirIds are eventually offered. 3. Since it is attempting to create an average load over each of the connections to a server, it must know which connections are being used. This information isn't commonly available. When an application invokes on an object, it doesn't know what connection is eventually used to get to the server. Invoking on object 'O1' may use connection 'C1'. Invoking on object 'O2' may also use connection 'C1'. In IONA's system, that's highly likely (I'll get into that in more detail in a minute). So, making an offer containing 333 BiDirIds in an invocation of one object and making an offer containing a different set of 333 BiDirIds in an invocation of another object is very likely to result in there now being 666 BiDirIds associated with a single connection! You've gained nothing and have significantly added to the application's complexity to manage all of this. (Orbix associates a policy set with a connection. An object invocation involves determining its EffectivePolicySet. The invocation occurs over a connection with a compatible policy set. This assignment of policysets to connections and then the determination of compatibility occurs deep in the ORB; the application is oblivious to this information.) So, to sum up, you're asking for a protocol to be put in place just to tweak the performance of a special case: an extreme number of callback objects, an application that knows what servers are in the server environment and that maintains control over which server has access to which callback objects and that requires prior knowledge of which server and connection will be used for an object invocation and that can tell what action the ORB actually performed using the hint so it can determine how to offer the next set of BiDirIds. I've said it before - protocols should be designed for the normal case. Edge cases will take a hit (and in the specific pathological case above it's not even a significant one). Extreme edge cases should probably be redesigned to make better use of the protocol. Finally, more application complexity is not better. As I have illustrated, you are requiring an application to become much more complex while dumbing down the ORB/server environment. And, since it is the ORB that actually manages connections and knows about their use and throughput, if the application actually achieves some performance gain through the use of your list and hint, it would only be due to luck. --Rebecca > -----Original Message----- > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > Sent: Monday, May 10, 2004 11:11 PM > To: Bergersen, Rebecca > Cc: Polar Humenn; firewall-traversal-ftf@omg.org > Subject: Re: Firewall Issue: What BiDirIds shall be sent over what > bidirectional connections? > > > Bergersen, Rebecca wrote: > > >After two or three weeks of arguing, I finally accepted your > statement that *all* BiDirIds needed to be sent in an offer > and that the offer be extended over *all* existing BiDir > connections. That's what I wrote up as the resolution. > > > It was required for the ORB to send *all* BiDirIds because > the ORB had > no idea what BiDirIds would be needed on a connection for a > particular > invocation. Now I'm proposing a way to give the ORB some hints about > what BiDirIds would be used for invocations on a particular object > reference. The proposal is not talking about directly controlling > BiDirIds over connections. It is talking about a list of > BiDirIds that > must be sent over a connection on which an invocation using that > BidirectionalOfferPolicy (ALLOW_LISTED). The ORB can send only this > list, or all BiDirIds. Besides, if there is no invocations, > the ORB does > not even have to send anything, though the ORB is still free to send > something if it wishes. > > I know it's a little confusing by mentioning various possible > implementations of the same requirement, but I try to distinguish > between a specification requirement and possible implementations that > satisfy this requirement. > > Joncheng > > > > > --Rebecca > > > > > > > > > > > Date: Wed, 12 May 2004 09:58:07 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? On Tue, 11 May 2004, Bergersen, Rebecca wrote: > Joncheng, Polar, > > I can see so many problems with your proposal of having the client > provide a 'hint' and a list of BiDirIds for a particular connection that > I hardly know where to begin. So, let me walk you through some of my > reasoning: I can see so many problems with the BiDirOfferPolicy in general. > 1. Offering specific BiDirIds over a connection implies that you know > which connection acceptors (servers) will (potentially) be making > callbacks to which callback objects. If you insist on using this "callback object" terminology, then you do know. The very term "callback object" means that, I as a client am going to give this "callback" object reference to a particular target object sitting on a particular server, so it can "callback" (i.e. make a normal CORBA invocation). It may get there by the "register" operation that you eluded to before. In anycase, the object reference gets to the target object, presumably though the target object reference (although not required). So, placing a policy on the object reference stating which BiDirs are going to be offered to the server behind that target object reference, fits within that "callback" model. That does NOT imply, at the application level, that you need know anything about connections! Notwithstanding, I still don't like either of the ALLOW/DENY, or NONE/ALL/LISTED resolutions, because it makes contradictory object references. ALLOW/DENY is really worse than the other. The latter resolution stands a chance, if NONE is elminated, but I still don't like it. > 2. You are trying to determine the connection by invoking on an object > and the connection used by that invocation is the one that will have the > offered BiDirIds associated with it. (More on that later) That > presupposes that the application knows what specific server each object > is associated with and that goes against the entire CORBA mindset. Again, you are off the mark on that one. That is not what Jonchengs proposal is suggesting. > You require some very special configuration in the application, maybe by > having servers know about their specific deployment and storing specific > objects in specific files that the application clients know about and > can distinguish. Otherwise, you just don't know what server is going to > be used when you invoke on an object. What if there is more than one > instance of a server in a deployment (a very common situation)? The > application client will have to know that and make decisions based on > it. The application knows nothing about connections. Only object references. Then again, there is the "validate_connection" rathole. > 3. Since the client is defining which connections (and therefore which > connection acceptors - servers) can be used to invoke on specific > callback objects, that implies that the client must control the > distribution of the references to those callback objects and make sure > that every one of the appropriate server instances get every one of the > appropriate references. You are describing a particular application scenario that fits your "callback" terminology. > The application that falls under these conditions is a special case > because it is quite severely constrained. I don't get it. You just described a particular application with your constraints. I don't see how the ORB or the policies MANDATE that the application control the distribution of object references. > You say the application is doing all of this in order to have less > overhead. What kind of overhead are we talking about? The overhead of having to send 20,000 BiDirOffers down a connection, when I may only need to offer 1. > 1. There's the overhead of the BiDirIds carried in the offer. There > would have to be a huge number of IDs sent in a single offer for this > overhead to be significant. In the worst case, all of the BiDirIds in > an offer would be strong IDs. A BiDirStrongOffer struct consists of an > unsigned long index (32 bits), a BiDirId (160 bits) and a BiDirModulus > (512 bits). The service context would contain a sequence of this struct > and a short (16 bits) for the ID type it wants to offer. That's 720 > bits or 45 bytes per ID offered. Yep, your point is? > We have large scale deployments of this BiDir GIOP being used by > customers in enterprise-wide operations (thousands of clients). The > clients, when they use bi-directional GIOP, have dozens of callback > objects but less than 100. So, let's say that 100 BiDirIds is the usual > case, based on our experience (it's actually closer to half that.) > That's 4500 bytes if they all went out in a single offer - a trivial > amount even to send over all connections from a client. So, let's look > at what would be considered an extreme edge case - a 1000 BiDirIds in a > single offer. That's a message size of about 45K. IONA sets a message > fragment size at 16K, so that's a single message of 3 fragments. > That's not a big message. You have to process them all. > So, an offer, which is sent only once over a connection and in the worst > case contains the strong BiDirIds for all of the callback objects in a > client, can be sent in a single, small to reasonably-sized message. > That's not much overhead. You've got other problems, like ACKin them. You are always taking the "feature" angle, which is the Micro$oft attitude of here how it works, never mind how it breaks. > 2. There's the overhead for the connection acceptor (server) to keep > track of the BiDirIds that apply to a connection. After any > challenge/response has been dealt with, the only info that needs to be > associated with the connection is the BiDirId (160 bits - 10 bytes). > That's 10K of info for our edge condition above of 1000 callback objects > in a single client. Assuming it's stored in a hash table, processing > time won't be high but the storage/memory size is somewhat high - > obviously 1K would be better than 10K. Let's further assume 1000 > connections active to the server - all bi-directional! That would mean > 10,000,000 bytes of info to manage for our edge case. You know, even > that isn't bad. Servers commonly handle that and much more. > > So, the overhead you are talking about isn't significant even for an extreme edge case. > > 3. There's the overhead of the invocations on the callback objects > coming from the connection acceptor to the connection initiator. Since > the callback objects' BiDirIds are no longer associated with multiple > connections, you have taken away the ability of the ORB to load balance. > This has significantly added to your overhead. You've also taken away > the flexibility of the deployment, since objects can't moved from server > to server without client application changes. No, you haven't taken the ability of the ORB to load balance. Where did you get that one? With a policy stating which BiDirIds go to which targets, the ORB may divi that up anyway it wants. Again, we are not talking about connections at the application level. > Let's continue by assuming an application that completely manages the > distribution of specific callback object references to specific servers. > Also assume that it is an edge case where each client has 1000 callback > objects. I think this is a pathological application, but let's continue > anyway. Let's see what the trade-off is for allowing the application to > attempt to define which connections should handle which BiDirIds. > > 1. Since it's taking control, the client will have to make sure, itself, > that all BiDirIds are offered. Or the policy is set to ALL. (Forever and ever). Remember, if the application stays "DENY" then it may allow have a policy of "ALLOW", and then what does that mean? > 2. It will have to know how the ORB is dealing with the hint: (Is it > sending all BiDirIds anyway? Is it sending the BiDirIds over every > connection anyway? It is just a hint, after all.) It must take into > consideration the ORB's behavior on *each* offer since it must make sure > all BiDirIds are eventually offered. That is true, if the application puts a policy of ALLOW on a single object reference, and DENY on another (but they go to the same server), then the client may get invocations from the object with the DENY policy. How do you suppose to resolve that? > 3. Since it is attempting to create an average load over each of the > connections to a server, it must know which connections are being used. > This information isn't commonly available. When an application invokes > on an object, it doesn't know what connection is eventually used to get > to the server. Invoking on object 'O1' may use connection 'C1'. > Invoking on object 'O2' may also use connection 'C1'. In IONA's system, > that's highly likely (I'll get into that in more detail in a minute). > So, making an offer containing 333 BiDirIds in an invocation of one > object and making an offer containing a different set of 333 BiDirIds in > an invocation of another object is very likely to result in there now > being 666 BiDirIds associated with a single connection! You've gained > nothing and have significantly added to the application's complexity to > manage all of this. I'm miffed now. I think you are just completely missing the point of Joncheng's proposal. Since he tried to "explain" it with connections, you are asumming its about connections. > (Orbix associates a policy set with a connection. An object invocation > involves determining its EffectivePolicySet. The invocation occurs over > a connection with a compatible policy set. This assignment of > policysets to connections and then the determination of compatibility > occurs deep in the ORB; the application is oblivious to this > information.) Maybe this is the problem with your understanding. You're object reference/policy/connection based. Which is not bad, but its not the only way to go. > So, to sum up, you're asking for a protocol to be put in place just to > tweak the performance of a special case: an extreme number of callback > objects, an application that knows what servers are in the server > environment and that maintains control over which server has access to > which callback objects and that requires prior knowledge of which server > and connection will be used for an object invocation and that can tell > what action the ORB actually performed using the hint so it can > determine how to offer the next set of BiDirIds. No, I'm asking for a protocol that doesn't make me have to do rediculous things for the "edge-case". > I've said it before - protocols should be designed for the normal case. > Edge cases will take a hit (and in the specific pathological case above > it's not even a significant one). Extreme edge cases should probably be > redesigned to make better use of the protocol. If you think hard enough, you can get there. > Finally, more application complexity is not better. As I have > illustrated, you are requiring an application to become much more > complex while dumbing down the ORB/server environment. And, since it is > the ORB that actually manages connections and knows about their use and > throughput, if the application actually achieves some performance gain > through the use of your list and hint, it would only be due to luck. We are not talking about the application managing connections. -Polar > > --Rebecca > > > > -----Original Message----- > > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > > Sent: Monday, May 10, 2004 11:11 PM > > To: Bergersen, Rebecca > > Cc: Polar Humenn; firewall-traversal-ftf@omg.org > > Subject: Re: Firewall Issue: What BiDirIds shall be sent over what > > bidirectional connections? > > > > > > Bergersen, Rebecca wrote: > > > > >After two or three weeks of arguing, I finally accepted your > > statement that *all* BiDirIds needed to be sent in an offer > > and that the offer be extended over *all* existing BiDir > > connections. That's what I wrote up as the resolution. > > > > > It was required for the ORB to send *all* BiDirIds because > > the ORB had > > no idea what BiDirIds would be needed on a connection for a > > particular > > invocation. Now I'm proposing a way to give the ORB some hints about > > what BiDirIds would be used for invocations on a particular object > > reference. The proposal is not talking about directly controlling > > BiDirIds over connections. It is talking about a list of > > BiDirIds that > > must be sent over a connection on which an invocation using that > > BidirectionalOfferPolicy (ALLOW_LISTED). The ORB can send only this > > list, or all BiDirIds. Besides, if there is no invocations, > > the ORB does > > not even have to send anything, though the ORB is still free to send > > something if it wishes. > > > > I know it's a little confusing by mentioning various possible > > implementations of the same requirement, but I try to distinguish > > between a specification requirement and possible implementations that > > satisfy this requirement. > > > > Joncheng > > > > > > > > --Rebecca > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- 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, 12 May 2004 11:02:01 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? On Wed, 12 May 2004, Bergersen, Rebecca wrote: > Joncheng goes on to discuss how putting a subset of BiDirIds on an offer > can achieve this average. Since all BiDirIds are eventually going to > get offered, how is offering a subset at a time going to achieve an > "average number of BiDirIds on each bi-directional connection"? I think this is where you are missing the point. All BiDirIds do not get offered. The LISTED ones do. I don't know why Joncheng chose to explain it with this BiDirId averaging, but I can certainly see why it is confusing you if you think ALL BiDirIds will eventually be offered. They are not. I believe having the ability to place he LISTED policy on an object reference limits the problematic situation in which all 20,000 BiDirIds have to go down EVERY pipe. -Polar Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Date: Wed, 12 May 2004 11:38:45 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQ4MjjmOU9UoxclRNetlR8yztaNkwAAtdIQ From: "Bergersen, Rebecca" To: "Polar Humenn" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4D0L8un002336 But not offering all of the BiDirIds radically changes the semantics of the spec. Whether that's a good thing or a bad thing is irrelevant - it is outside the purview of an FTF. The Task Force has approved the spec; the Architecture Board has approved the spec; the Platform Technical Committee has approved the spec. It's not up to us to change that - it's only to add clarifying text, make textual edits, etc. However, there may be a way to achieve what you are looking for that doesn't change the semantics. To say that you are not going to eventually offer all BiDirIds implies that there are BiDirIds that could be offered but which aren't. What is the point of having those unoffered BiDirIds at all, then? Why apply the export policy to the POAs that aren't going to have their potential BiDirIds offered? If you have 10 POAs that your application knows could possibly be used for callbacks (or whatever you want to call their invocation from the connection acceptor) but somehow the application decides that it would be efficient to only offer 4 of these, why not just apply the export policy to those specific 4? The next offer includes those 4 rather than all ten and you have achieved the offering of your subset. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Wednesday, May 12, 2004 11:02 AM > To: firewall-traversal-ftf@omg.org > Subject: RE: Firewall Issue: What BiDirIds shall be sent over what > bidirectional connections? > > > On Wed, 12 May 2004, Bergersen, Rebecca wrote: > > > Joncheng goes on to discuss how putting a subset of > BiDirIds on an offer > > can achieve this average. Since all BiDirIds are > eventually going to > > get offered, how is offering a subset at a time going to achieve an > > "average number of BiDirIds on each bi-directional connection"? > > I think this is where you are missing the point. All BiDirIds > do not get > offered. The LISTED ones do. > > I don't know why Joncheng chose to explain it with this > BiDirId averaging, > but I can certainly see why it is confusing you if you think > ALL BiDirIds > will eventually be offered. They are not. > > I believe having the ability to place he LISTED policy on an object > reference limits the problematic situation in which all > 20,000 BiDirIds > have to go down EVERY pipe. > > -Polar > Date: Wed, 12 May 2004 12:07:30 -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: Polar Humenn , firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? X-Virus-Scanned: Symantec AntiVirus Scan Engine Hi, Rebecca, Thank you for your detailed analysis, which took you quite some time after working hours. :) Your argument about performance is generally valid for the so-called typical scenarios, but your understanding about my proposal -- "Since the client is defining which connections (and therefore which connection acceptors - servers) can be used to invoke on specific callback objects" -- is completely wrong. The model in my proposal can be explained using the following scenario: A client application creates some objects that will be called (back) through bi-directional GIOP. The client application knows what objects will be called (back) for each target object reference that the client talks to -- my assumption. For example, in your "registration" example, when a client application invokes "objref.register(obj)", the client application knows that obj will be called (back) by the server associated with objref through bi-directional GIOP. This level of abstraction is completely above the concept of connections. In other words, a BidirectionalOfferPolicy is intended for object references, not for connections. If a client application sets a BidirectionalOfferPolicy on an object reference, the client application would expect this policy to have effect when the client application makes an invocation on this object reference is used. As for how this policy affects the underlying connections is completely out of the scope of the client application. Because the ORB is in charge of picking up a connection for conducting such an invocation, the ORB knows what connection is in use and the ORB has to make sure that the BiDirIds cited in the policy are delivered (or have been delivered) to the connection acceptor. As Polar have said, my proposal does not help solving the fundamental problem of bi-directional GIOP at all. We're trying to use the CORBA object model to define the behavior of connections. This approach is really problematic because they are in different abstraction levels. Joncheng Bergersen, Rebecca wrote: Joncheng, Polar, I can see so many problems with your proposal of having the client provide a 'hint' and a list of BiDirIds for a particular connection that I hardly know where to begin. So, let me walk you through some of my reasoning: 1. Offering specific BiDirIds over a connection implies that you know which connection acceptors (servers) will (potentially) be making callbacks to which callback objects. 2. You are trying to determine the connection by invoking on an object and the connection used by that invocation is the one that will have the offered BiDirIds associated with it. (More on that later) That presupposes that the application knows what specific server each object is associated with and that goes against the entire CORBA mindset. You require some very special configuration in the application, maybe by having servers know about their specific deployment and storing specific objects in specific files that the application clients know about and can distinguish. Otherwise, you just don't know what server is going to be used when you invoke on an object. What if there is more than one instance of a server in a deployment (a very common situation)? The application client will have to know that and make decisions based on it. 3. Since the client is defining which connections (and therefore which connection acceptors - servers) can be used to invoke on specific callback objects, that implies that the client must control the distribution of the references to those callback objects and make sure that every one of the appropriate server instances get every one of the appropriate references. The application that falls under these conditions is a special case because it is quite severely constrained. You say the application is doing all of this in order to have less overhead. What kind of overhead are we talking about? 1. There's the overhead of the BiDirIds carried in the offer. There would have to be a huge number of IDs sent in a single offer for this overhead to be significant. In the worst case, all of the BiDirIds in an offer would be strong IDs. A BiDirStrongOffer struct consists of an unsigned long index (32 bits), a BiDirId (160 bits) and a BiDirModulus (512 bits). The service context would contain a sequence of this struct and a short (16 bits) for the ID type it wants to offer. That's 720 bits or 45 bytes per ID offered. We have large scale deployments of this BiDir GIOP being used by customers in enterprise-wide operations (thousands of clients). The clients, when they use bi-directional GIOP, have dozens of callback objects but less than 100. So, let's say that 100 BiDirIds is the usual case, based on our experience (it's actually closer to half that.) That's 4500 bytes if they all went out in a single offer - a trivial amount even to send over all connections from a client. So, let's look at what would be considered an extreme edge case - a 1000 BiDirIds in a single offer. That's a message size of about 45K. IONA sets a message fragment size at 16K, so that's a single message of 3 fragments. That's not a big message. So, an offer, which is sent only once over a connection and in the worst case contains the strong BiDirIds for all of the callback objects in a client, can be sent in a single, small to reasonably-sized message. That's not much overhead. 2. There's the overhead for the connection acceptor (server) to keep track of the BiDirIds that apply to a connection. After any challenge/response has been dealt with, the only info that needs to be associated with the connection is the BiDirId (160 bits - 10 bytes). That's 10K of info for our edge condition above of 1000 callback objects in a single client. Assuming it's stored in a hash table, processing time won't be high but the storage/memory size is somewhat high - obviously 1K would be better than 10K. Let's further assume 1000 connections active to the server - all bi-directional! That would mean 10,000,000 bytes of info to manage for our edge case. You know, even that isn't bad. Servers commonly handle that and much more. So, the overhead you are talking about isn't significant even for an extreme edge case. 3. There's the overhead of the invocations on the callback objects coming from the connection acceptor to the connection initiator. Since the callback objects' BiDirIds are no longer associated with multiple connections, you have taken away the ability of the ORB to load balance. This has significantly added to your overhead. You've also taken away the flexibility of the deployment, since objects can't moved from server to server without client application changes. Let's continue by assuming an application that completely manages the distribution of specific callback object references to specific servers. Also assume that it is an edge case where each client has 1000 callback objects. I think this is a pathological application, but let's continue anyway. Let's see what the trade-off is for allowing the application to attempt to define which connections should handle which BiDirIds. 1. Since it's taking control, the client will have to make sure, itself, that all BiDirIds are offered. 2. It will have to know how the ORB is dealing with the hint: (Is it sending all BiDirIds anyway? Is it sending the BiDirIds over every connection anyway? It is just a hint, after all.) It must take into consideration the ORB's behavior on *each* offer since it must make sure all BiDirIds are eventually offered. 3. Since it is attempting to create an average load over each of the connections to a server, it must know which connections are being used. This information isn't commonly available. When an application invokes on an object, it doesn't know what connection is eventually used to get to the server. Invoking on object 'O1' may use connection 'C1'. Invoking on object 'O2' may also use connection 'C1'. In IONA's system, that's highly likely (I'll get into that in more detail in a minute). So, making an offer containing 333 BiDirIds in an invocation of one object and making an offer containing a different set of 333 BiDirIds in an invocation of another object is very likely to result in there now being 666 BiDirIds associated with a single connection! You've gained nothing and have significantly added to the application's complexity to manage all of this. (Orbix associates a policy set with a connection. An object invocation involves determining its EffectivePolicySet. The invocation occurs over a connection with a compatible policy set. This assignment of policysets to connections and then the determination of compatibility occurs deep in the ORB; the application is oblivious to this information.) So, to sum up, you're asking for a protocol to be put in place just to tweak the performance of a special case: an extreme number of callback objects, an application that knows what servers are in the server environment and that maintains control over which server has access to which callback objects and that requires prior knowledge of which server and connection will be used for an object invocation and that can tell what action the ORB actually performed using the hint so it can determine how to offer the next set of BiDirIds. I've said it before - protocols should be designed for the normal case. Edge cases will take a hit (and in the specific pathological case above it's not even a significant one). Extreme edge cases should probably be redesigned to make better use of the protocol. Finally, more application complexity is not better. As I have illustrated, you are requiring an application to become much more complex while dumbing down the ORB/server environment. And, since it is the ORB that actually manages connections and knows about their use and throughput, if the application actually achieves some performance gain through the use of your list and hint, it would only be due to luck. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Monday, May 10, 2004 11:11 PM To: Bergersen, Rebecca Cc: Polar Humenn; firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Bergersen, Rebecca wrote: After two or three weeks of arguing, I finally accepted your statement that *all* BiDirIds needed to be sent in an offer and that the offer be extended over *all* existing BiDir connections. That's what I wrote up as the resolution. It was required for the ORB to send *all* BiDirIds because the ORB had no idea what BiDirIds would be needed on a connection for a particular invocation. Now I'm proposing a way to give the ORB some hints about what BiDirIds would be used for invocations on a particular object reference. The proposal is not talking about directly controlling BiDirIds over connections. It is talking about a list of BiDirIds that must be sent over a connection on which an invocation using that BidirectionalOfferPolicy (ALLOW_LISTED). The ORB can send only this list, or all BiDirIds. Besides, if there is no invocations, the ORB does not even have to send anything, though the ORB is still free to send something if it wishes. I know it's a little confusing by mentioning various possible implementations of the same requirement, but I try to distinguish between a specification requirement and possible implementations that satisfy this requirement. Joncheng --Rebecca Date: Wed, 12 May 2004 12:30:03 -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: Polar Humenn , firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? X-Virus-Scanned: Symantec AntiVirus Scan Engine Hi, Rebecca, I'm sorry to confuse you with my proposal and arguments. Here is a list of import points: 1. I believe that it's not necessary to offer all BiDirIds on an ORB over all bi-directional connections. An ORB can do a better job if the ORB has the knowledge about what BiDirIds will be needed on what connections (which is decided by (2)). 2. When there is an invocation on an object reference, the ORB can derive the set of BiDirIds that must be sent over the connection to be used by checking the proposed BidirectionalOfferPolicy of that object reference. 3. Listing a set of BiDirIds that must be sent over does not imply that the ORB cannot send all BiDirIds. Joncheng Bergersen, Rebecca wrote: Hi! I'm not going to answer each of your arguments because they all amount to the same thing - that Joncheng's proposal has nothing to do with connections. Here's what he said in the beginning of this thread and what the discussion has been about ever since: "The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted." He's saying that placing and average number of BiDirIds on a connection is more efficient than all BiDirIds. I have no argument with the statement, but it *does* have to do with connections. His whole point is about efficiency. He measures efficiency as some X per some Y ("number of BiDirIds needed on each bi-directional connection") How can you claim that such a statement isn't about Y (bi-directional connections)? It is about X and it is about Y - neither can be separated from the other. Joncheng goes on to discuss how putting a subset of BiDirIds on an offer can achieve this average. Since all BiDirIds are eventually going to get offered, how is offering a subset at a time going to achieve an "average number of BiDirIds on each bi-directional connection"? The only way is if you are somehow establishing what connection that subset is associated with. That's what my analysis was about. --Rebecca -----Original Message----- From: Polar Humenn [mailto:polar@adiron.com] Sent: Wednesday, May 12, 2004 9:58 AM To: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? On Tue, 11 May 2004, Bergersen, Rebecca wrote: Joncheng, Polar, I can see so many problems with your proposal of having the client provide a 'hint' and a list of BiDirIds for a particular connection that I hardly know where to begin. So, let me walk you through some of my reasoning: I can see so many problems with the BiDirOfferPolicy in general. 1. Offering specific BiDirIds over a connection implies that you know which connection acceptors (servers) will (potentially) be making callbacks to which callback objects. If you insist on using this "callback object" terminology, then you do know. The very term "callback object" means that, I as a client am going to give this "callback" object reference to a particular target object sitting on a particular server, so it can "callback" (i.e. make a normal CORBA invocation). It may get there by the "register" operation that you eluded to before. In anycase, the object reference gets to the target object, presumably though the target object reference (although not required). So, placing a policy on the object reference stating which BiDirs are going to be offered to the server behind that target object reference, fits within that "callback" model. That does NOT imply, at the application level, that you need know anything about connections! Notwithstanding, I still don't like either of the ALLOW/DENY, or NONE/ALL/LISTED resolutions, because it makes contradictory object references. ALLOW/DENY is really worse than the other. The latter resolution stands a chance, if NONE is elminated, but I still don't like it. 2. You are trying to determine the connection by invoking on an object and the connection used by that invocation is the one that will have the offered BiDirIds associated with it. (More on that later) That presupposes that the application knows what specific server each object is associated with and that goes against the entire CORBA mindset. Again, you are off the mark on that one. That is not what Jonchengs proposal is suggesting. You require some very special configuration in the application, maybe by having servers know about their specific deployment and storing specific objects in specific files that the application clients know about and can distinguish. Otherwise, you just don't know what server is going to be used when you invoke on an object. What if there is more than one instance of a server in a deployment (a very common situation)? The application client will have to know that and make decisions based on it. The application knows nothing about connections. Only object references. Then again, there is the "validate_connection" rathole. 3. Since the client is defining which connections (and therefore which connection acceptors - servers) can be used to invoke on specific callback objects, that implies that the client must control the distribution of the references to those callback objects and make sure that every one of the appropriate server instances get every one of the appropriate references. You are describing a particular application scenario that fits your "callback" terminology. The application that falls under these conditions is a special case because it is quite severely constrained. I don't get it. You just described a particular application with your constraints. I don't see how the ORB or the policies MANDATE that the application control the distribution of object references. You say the application is doing all of this in order to have less overhead. What kind of overhead are we talking about? The overhead of having to send 20,000 BiDirOffers down a connection, when I may only need to offer 1. 1. There's the overhead of the BiDirIds carried in the offer. There would have to be a huge number of IDs sent in a single offer for this overhead to be significant. In the worst case, all of the BiDirIds in an offer would be strong IDs. A BiDirStrongOffer struct consists of an unsigned long index (32 bits), a BiDirId (160 bits) and a BiDirModulus (512 bits). The service context would contain a sequence of this struct and a short (16 bits) for the ID type it wants to offer. That's 720 bits or 45 bytes per ID offered. Yep, your point is? We have large scale deployments of this BiDir GIOP being used by customers in enterprise-wide operations (thousands of clients). The clients, when they use bi-directional GIOP, have dozens of callback objects but less than 100. So, let's say that 100 BiDirIds is the usual case, based on our experience (it's actually closer to half that.) That's 4500 bytes if they all went out in a single offer - a trivial amount even to send over all connections from a client. So, let's look at what would be considered an extreme edge case - a 1000 BiDirIds in a single offer. That's a message size of about 45K. IONA sets a message fragment size at 16K, so that's a single message of 3 fragments. That's not a big message. You have to process them all. So, an offer, which is sent only once over a connection and in the worst case contains the strong BiDirIds for all of the callback objects in a client, can be sent in a single, small to reasonably-sized message. That's not much overhead. You've got other problems, like ACKin them. You are always taking the "feature" angle, which is the Micro$oft attitude of here how it works, never mind how it breaks. 2. There's the overhead for the connection acceptor (server) to keep track of the BiDirIds that apply to a connection. After any challenge/response has been dealt with, the only info that needs to be associated with the connection is the BiDirId (160 bits - 10 bytes). That's 10K of info for our edge condition above of 1000 callback objects in a single client. Assuming it's stored in a hash table, processing time won't be high but the storage/memory size is somewhat high - obviously 1K would be better than 10K. Let's further assume 1000 connections active to the server - all bi-directional! That would mean 10,000,000 bytes of info to manage for our edge case. You know, even that isn't bad. Servers commonly handle that and much more. So, the overhead you are talking about isn't significant even for an extreme edge case. 3. There's the overhead of the invocations on the callback objects coming from the connection acceptor to the connection initiator. Since the callback objects' BiDirIds are no longer associated with multiple connections, you have taken away the ability of the ORB to load balance. This has significantly added to your overhead. You've also taken away the flexibility of the deployment, since objects can't moved from server to server without client application changes. No, you haven't taken the ability of the ORB to load balance. Where did you get that one? With a policy stating which BiDirIds go to which targets, the ORB may divi that up anyway it wants. Again, we are not talking about connections at the application level. Let's continue by assuming an application that completely manages the distribution of specific callback object references to specific servers. Also assume that it is an edge case where each client has 1000 callback objects. I think this is a pathological application, but let's continue anyway. Let's see what the trade-off is for allowing the application to attempt to define which connections should handle which BiDirIds. 1. Since it's taking control, the client will have to make sure, itself, that all BiDirIds are offered. Or the policy is set to ALL. (Forever and ever). Remember, if the application stays "DENY" then it may allow have a policy of "ALLOW", and then what does that mean? 2. It will have to know how the ORB is dealing with the hint: (Is it sending all BiDirIds anyway? Is it sending the BiDirIds over every connection anyway? It is just a hint, after all.) It must take into consideration the ORB's behavior on *each* offer since it must make sure all BiDirIds are eventually offered. That is true, if the application puts a policy of ALLOW on a single object reference, and DENY on another (but they go to the same server), then the client may get invocations from the object with the DENY policy. How do you suppose to resolve that? 3. Since it is attempting to create an average load over each of the connections to a server, it must know which connections are being used. This information isn't commonly available. When an application invokes on an object, it doesn't know what connection is eventually used to get to the server. Invoking on object 'O1' may use connection 'C1'. Invoking on object 'O2' may also use connection 'C1'. In IONA's system, that's highly likely (I'll get into that in more detail in a minute). So, making an offer containing 333 BiDirIds in an invocation of one object and making an offer containing a different set of 333 BiDirIds in an invocation of another object is very likely to result in there now being 666 BiDirIds associated with a single connection! You've gained nothing and have significantly added to the application's complexity to manage all of this. I'm miffed now. I think you are just completely missing the point of Joncheng's proposal. Since he tried to "explain" it with connections, you are asumming its about connections. (Orbix associates a policy set with a connection. An object invocation involves determining its EffectivePolicySet. The invocation occurs over a connection with a compatible policy set. This assignment of policysets to connections and then the determination of compatibility occurs deep in the ORB; the application is oblivious to this information.) Maybe this is the problem with your understanding. You're object reference/policy/connection based. Which is not bad, but its not the only way to go. So, to sum up, you're asking for a protocol to be put in place just to tweak the performance of a special case: an extreme number of callback objects, an application that knows what servers are in the server environment and that maintains control over which server has access to which callback objects and that requires prior knowledge of which server and connection will be used for an object invocation and that can tell what action the ORB actually performed using the hint so it can determine how to offer the next set of BiDirIds. No, I'm asking for a protocol that doesn't make me have to do rediculous things for the "edge-case". I've said it before - protocols should be designed for the normal case. Edge cases will take a hit (and in the specific pathological case above it's not even a significant one). Extreme edge cases should probably be redesigned to make better use of the protocol. If you think hard enough, you can get there. Finally, more application complexity is not better. As I have illustrated, you are requiring an application to become much more complex while dumbing down the ORB/server environment. And, since it is the ORB that actually manages connections and knows about their use and throughput, if the application actually achieves some performance gain through the use of your list and hint, it would only be due to luck. We are not talking about the application managing connections. -Polar --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Monday, May 10, 2004 11:11 PM To: Bergersen, Rebecca Cc: Polar Humenn; firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Bergersen, Rebecca wrote: After two or three weeks of arguing, I finally accepted your statement that *all* BiDirIds needed to be sent in an offer and that the offer be extended over *all* existing BiDir connections. That's what I wrote up as the resolution. It was required for the ORB to send *all* BiDirIds because the ORB had no idea what BiDirIds would be needed on a connection for a particular invocation. Now I'm proposing a way to give the ORB some hints about what BiDirIds would be used for invocations on a particular object reference. The proposal is not talking about directly controlling BiDirIds over connections. It is talking about a list of BiDirIds that must be sent over a connection on which an invocation using that BidirectionalOfferPolicy (ALLOW_LISTED). The ORB can send only this list, or all BiDirIds. Besides, if there is no invocations, the ORB does not even have to send anything, though the ORB is still free to send something if it wishes. I know it's a little confusing by mentioning various possible implementations of the same requirement, but I try to distinguish between a specification requirement and possible implementations that satisfy this requirement. Joncheng --Rebecca ------------------------------------------------------------------- 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, 13 May 2004 09:02:54 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Rebecca, You are arguing about "why would you want to do this and that" as an application, when the ORB is at the service of ANY application, not just the ones YOU think are appropriate. Cars are built with safety features, and it's not because people want to crash. -Polar On Wed, 12 May 2004, Bergersen, Rebecca wrote: > But not offering all of the BiDirIds radically changes the semantics of the spec. Whether that's a good thing or a bad thing is irrelevant - it is outside the purview of an FTF. The Task Force has approved the spec; the Architecture Board has approved the spec; the Platform Technical Committee has approved the spec. It's not up to us to change that - it's only to add clarifying text, make textual edits, etc. > > However, there may be a way to achieve what you are looking for that doesn't change the semantics. To say that you are not going to eventually offer all BiDirIds implies that there are BiDirIds that could be offered but which aren't. What is the point of having those unoffered BiDirIds at all, then? Why apply the export policy to the POAs that aren't going to have their potential BiDirIds offered? If you have 10 POAs that your application knows could possibly be used for callbacks (or whatever you want to call their invocation from the connection acceptor) but somehow the application decides that it would be efficient to only offer 4 of these, why not just apply the export policy to those specific 4? The next offer includes those 4 rather than all ten and you have achieved the offering of your subset. > > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Wednesday, May 12, 2004 11:02 AM > > To: firewall-traversal-ftf@omg.org > > Subject: RE: Firewall Issue: What BiDirIds shall be sent over what > > bidirectional connections? > > > > > > On Wed, 12 May 2004, Bergersen, Rebecca wrote: > > > > > Joncheng goes on to discuss how putting a subset of > > BiDirIds on an offer > > > can achieve this average. Since all BiDirIds are > > eventually going to > > > get offered, how is offering a subset at a time going to achieve an > > > "average number of BiDirIds on each bi-directional connection"? > > > > I think this is where you are missing the point. All BiDirIds > > do not get > > offered. The LISTED ones do. > > > > I don't know why Joncheng chose to explain it with this > > BiDirId averaging, > > but I can certainly see why it is confusing you if you think > > ALL BiDirIds > > will eventually be offered. They are not. > > > > I believe having the ability to place he LISTED policy on an object > > reference limits the problematic situation in which all > > 20,000 BiDirIds > > have to go down EVERY pipe. > > > > -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 Date: Thu, 13 May 2004 09:56: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: Polar Humenn , firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: But not offering all of the BiDirIds radically changes the semantics of the spec. Whether that's a good thing or a bad thing is irrelevant - it is outside the purview of an FTF. The Task Force has approved the spec; the Architecture Board has approved the spec; the Platform Technical Committee has approved the spec. It's not up to us to change that - it's only to add clarifying text, make textual edits, etc. You may argue that this proposed change changes the semantics of the spec, but this "offer all" semantics is never explicit in the spec. Maybe the original spec writers had this semantics in mind but didn't spell it out. We argue that the spec has this "offer all" implication just because of the deficiency of the offer policy. The whole bi-directional protocol does not depend on this semantics. Thus, we see it as a defect that can be fixed easily in order to make the spec more "useable". >From your next paragraph, it seems that you didn't get the problem that we want to convey. Say I have a client that wants to talk to 10 servers using bi-directional GIOP. It is possible (and likely) that I want to set up 10 "callback" objects (and 10 BiDirIds) each of which is for a particular server. In this case, each BiDirId is needed only for a particular server, but not for the other servers. I hope this example is clear enough to explain the problem. Joncheng However, there may be a way to achieve what you are looking for that doesn't change the semantics. To say that you are not going to eventually offer all BiDirIds implies that there are BiDirIds that could be offered but which aren't. What is the point of having those unoffered BiDirIds at all, then? Why apply the export policy to the POAs that aren't going to have their potential BiDirIds offered? If you have 10 POAs that your application knows could possibly be used for callbacks (or whatever you want to call their invocation from the connection acceptor) but somehow the application decides that it would be efficient to only offer 4 of these, why not just apply the export policy to those specific 4? The next offer includes those 4 rather than all ten and you have achieved the offering of your subset. --Rebecca -----Original Message----- From: Polar Humenn [mailto:polar@adiron.com] Sent: Wednesday, May 12, 2004 11:02 AM To: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? On Wed, 12 May 2004, Bergersen, Rebecca wrote: Joncheng goes on to discuss how putting a subset of BiDirIds on an offer can achieve this average. Since all BiDirIds are eventually going to get offered, how is offering a subset at a time going to achieve an "average number of BiDirIds on each bi-directional connection"? I think this is where you are missing the point. All BiDirIds do not get offered. The LISTED ones do. I don't know why Joncheng chose to explain it with this BiDirId averaging, but I can certainly see why it is confusing you if you think ALL BiDirIds will eventually be offered. They are not. I believe having the ability to place he LISTED policy on an object reference limits the problematic situation in which all 20,000 BiDirIds have to go down EVERY pipe. -Polar Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Date: Thu, 13 May 2004 15:47:43 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQ46tScRqvc+feNQsupAzNfLCyplQAN5KhA From: "Bergersen, Rebecca" To: "Polar Humenn" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4DJn0un014584 I like your arguments, Polar, particularly the car safety one :-). However, I don't see their relevancy. I proposed a solution that lets you do what you want - offer a subset of BiDirIds - and the proposal does it without requiring the hint and list in the policy. Your response was that the ORB is at the service of any app. I truly don't see any connection between my proposal and your response. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Thursday, May 13, 2004 9:03 AM > To: firewall-traversal-ftf@omg.org > Subject: RE: Firewall Issue: What BiDirIds shall be sent over what > bidirectional connections? > > > > Rebecca, > > You are arguing about "why would you want to do this and that" as an > application, when the ORB is at the service of ANY > application, not just > the ones YOU think are appropriate. > > Cars are built with safety features, and it's not because > people want to > crash. > > -Polar > > > On Wed, 12 May 2004, Bergersen, Rebecca wrote: > > > But not offering all of the BiDirIds radically changes the > semantics of the spec. Whether that's a good thing or a bad > thing is irrelevant - it is outside the purview of an FTF. > The Task Force has approved the spec; the Architecture Board > has approved the spec; the Platform Technical Committee has > approved the spec. It's not up to us to change that - it's > only to add clarifying text, make textual edits, etc. > > > > However, there may be a way to achieve what you are looking > for that doesn't change the semantics. To say that you are > not going to eventually offer all BiDirIds implies that there > are BiDirIds that could be offered but which aren't. What is > the point of having those unoffered BiDirIds at all, then? > Why apply the export policy to the POAs that aren't going to > have their potential BiDirIds offered? If you have 10 POAs > that your application knows could possibly be used for > callbacks (or whatever you want to call their invocation from > the connection acceptor) but somehow the application decides > that it would be efficient to only offer 4 of these, why not > just apply the export policy to those specific 4? The next > offer includes those 4 rather than all ten and you have > achieved the offering of your subset. > > > > --Rebecca > > > > > -----Original Message----- > > > From: Polar Humenn [mailto:polar@adiron.com] > > > Sent: Wednesday, May 12, 2004 11:02 AM > > > To: firewall-traversal-ftf@omg.org > > > Subject: RE: Firewall Issue: What BiDirIds shall be sent over what > > > bidirectional connections? > > > > > > > > > On Wed, 12 May 2004, Bergersen, Rebecca wrote: > > > > > > > Joncheng goes on to discuss how putting a subset of > > > BiDirIds on an offer > > > > can achieve this average. Since all BiDirIds are > > > eventually going to > > > > get offered, how is offering a subset at a time going > to achieve an > > > > "average number of BiDirIds on each bi-directional connection"? > > > > > > I think this is where you are missing the point. All BiDirIds > > > do not get > > > offered. The LISTED ones do. > > > > > > I don't know why Joncheng chose to explain it with this > > > BiDirId averaging, > > > but I can certainly see why it is confusing you if you think > > > ALL BiDirIds > > > will eventually be offered. They are not. > > > > > > I believe having the ability to place he LISTED policy on > an object > > > reference limits the problematic situation in which all > > > 20,000 BiDirIds > > > have to go down EVERY pipe. > > > > > > -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 > Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Date: Thu, 13 May 2004 17:25:33 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQ48h6L2g4paXzQQ9qFCr8T/yXbUAAM3WUA From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: "Polar Humenn" , inlined commentary.... -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Thursday, May 13, 2004 9:56 AM To: Bergersen, Rebecca Cc: Polar Humenn; firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Bergersen, Rebecca wrote: But not offering all of the BiDirIds radically changes the semantics of the spec. Whether that's a good thing or a bad thing is irrelevant - it is outside the purview of an FTF. The Task Force has approved the spec; the Architecture Board has approved the spec; the Platform Technical Committee has approved the spec. It's not up to us to change that - it's only to add clarifying text, make textual edits, etc. You may argue that this proposed change changes the semantics of the spec, but this "offer all" semantics is never explicit in the spec. Maybe the original spec writers had this semantics in mind but didn't spell it out. We argue that the spec has this "offer all" implication just because of the deficiency of the offer policy. The whole bi-directional protocol does not depend on this semantics. Thus, we see it as a defect that can be fixed easily in order to make the spec more "useable". From your next paragraph, it seems that you didn't get the problem that we want to convey. Say I have a client that wants to talk to 10 servers using bi-directional GIOP. It is possible (and likely) that I want to set up 10 "callback" objects (and 10 BiDirIds) each of which is for a particular server. In this case, each BiDirId is needed only for a particular server, but not for the other servers. I hope this example is clear enough to explain the problem. [Bergersen, Rebecca] I do understand what you are trying to achieve - you want to offer particular BiDirIds only to particular servers. You want this because, as you said in the attached email, "The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send *all* BiDirIds on an ORB to *every* connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW." Your conclusion, therefore, was that the spec was inefficient: "The above implication derived from the spec is very inefficient" (same email). However, Joncheng, you yourself said, in another (attached) email, "However, in practice, it's not always possible to tell whether two object references point to the same server or not." I agree with that statement. It's not possible to tell what server an object reference points to, much less tell if two are pointing to the same server. That was part of my argument for why your proposal won't work as you desire. You are trying to make sure particular BiDirIds are only offered over particular connections, in the name of efficiency. And I'm saying that since you can't tell what object references point to what servers, you cannot accomplish your goal by only offering a subset of BiDirIds when you invoke on an object. 1. How do you know what server is going to get that offer? 2. How do you know that whatever server does get the offer is the one that needs to callback to those particular objects? [This is the most important question] 3. How do you know that that is the only server that will need to callback? Much of the rest of my analysis was over "efficiency" since that is the reason you gave for having the hint and subset list. There really is no reason to have them, otherwise. Would your final goal of offering BiDirIds for callback objects to only those servers that will need to invoke them be more efficient? Sure - I'm not arguing that the goal is faulty. My conclusion was twofold: 1. since you don't know what server an object points to, you don't know what object to use to inform a server about a specific subset of callback objects. 2. it is "efficient enough" to offer all BiDirIds over all connections. I worked out several kinds of efficiency since you hadn't indicated which ones were the cause of your concern, and showed that the efficiency of each was well within normal operational parameters. So, since simply sending all BiDirIds over all connections was normally efficient, there wasn't sufficient need to have the additional hint and subset list, and, even if there were some need for more efficiency, you couldn't achieve it by offering a subset of BiDirIds over an invocation on an object whose server you can't determine. --Rebecca Joncheng However, there may be a way to achieve what you are looking for that doesn't change the semantics. To say that you are not going to eventually offer all BiDirIds implies that there are BiDirIds that could be offered but which aren't. What is the point of having those unoffered BiDirIds at all, then? Why apply the export policy to the POAs that aren't going to have their potential BiDirIds offered? If you have 10 POAs that your application knows could possibly be used for callbacks (or whatever you want to call their invocation from the connection acceptor) but somehow the application decides that it would be efficient to only offer 4 of these, why not just apply the export policy to those specific 4? The next offer includes those 4 rather than all ten and you have achieved the offering of your subset. --Rebecca -----Original Message----- From: Polar Humenn [mailto:polar@adiron.com] Sent: Wednesday, May 12, 2004 11:02 AM To: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? On Wed, 12 May 2004, Bergersen, Rebecca wrote: Joncheng goes on to discuss how putting a subset of BiDirIds on an offer can achieve this average. Since all BiDirIds are eventually going to get offered, how is offering a subset at a time going to achieve an "average number of BiDirIds on each bi-directional connection"? I think this is where you are missing the point. All BiDirIds do not get offered. The LISTED ones do. I don't know why Joncheng chose to explain it with this BiDirId averaging, but I can certainly see why it is confusing you if you think ALL BiDirIds will eventually be offered. They are not. I believe having the ability to place he LISTED policy on an object reference limits the problematic situation in which all 20,000 BiDirIds have to go down EVERY pipe. -Polar X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Received: from amereast-ems2.IONAGLOBAL.COM ([10.65.6.84]) by amereast-ems1.IONAGLOBAL.COM with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 May 2004 10:44:06 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C43766.68F07F00" Received: from amereast-smg1.iona.com ([10.70.2.37]) by amereast-ems2.IONAGLOBAL.COM with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 May 2004 10:44:06 -0400 Received: from amethyst.omg.org (amethyst.omg.org [192.67.184.64]) by amereast-smg1.iona.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id i4BEi5W02629 for ; Tue, 11 May 2004 10:44:05 -0400 (EDT) Received: from hobbit.omg.org (hobbit.omg.org [192.67.184.3]) by amethyst.omg.org (8.12.8/8.12.8) with ESMTP id i4BEdS8k012472; Tue, 11 May 2004 10:39:28 -0400 Received: from ms-smtp-02.nyroc.rr.com [24.24.2.56] by hobbit.omg.org asmtp(3.1c-beta4) id 19386; Tue, 11 May 2004 10:38:39 -0400 (EDT) Received: from syr.edu (syr-24-59-196-6.twcny.rr.com [24.59.196.6]) by ms-smtp-02.nyroc.rr.com (8.12.10/8.12.10) with ESMTP id i4BEcMuX014565; Tue, 11 May 2004 10:38:24 -0400 (EDT) content-class: urn:content-classes:message Subject: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY Date: Tue, 11 May 2004 10:38:25 -0400 Message-ID: <40A0E561.5020206@syr.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY Thread-Index: AcQ3ZmljZK2/IZRbRZy9esrT2ecyjw== From: "Joncheng Kuo" To: Cc: Part of this issue has been surfaced in the discussions over the mail list. I now file it as an issue. The Bi-directional GIOP spec says, "An object reference with a BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional connection." Satisfying this policy requirement does not close some potential limitation and ambiguity when other policies or policy instances are around. For example, at the connection initiator side, we may have two object references one of which has BidirectionalOfferPolicy of DENY and the other has BidirectionalOfferPolicy of ALLOW. If these two object references point to the same server, according to spec, we need two connections to the server: one is bi-directional and one is not. However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection. There is an argument (by Brian Niebuhr) saying that it's not realistic to both trust and not trust the same server. However, in practice, it's not always possible to tell whether two object references point to the same server or not. Furthermore, the client may decide whether or not to trust the server of an object reference depending on reasons other than the information about the server. For example, the client may decide to use BidirectionalOfferPolicy of ALLOW or DENY according to the source of an object reference. On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and *effective* BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction? X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Received: from amereast-ems2.IONAGLOBAL.COM ([10.65.6.84]) by amereast-ems1.IONAGLOBAL.COM with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 May 2004 17:10:26 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_004_01C433AE.8D3B0D00" Received: from amereast-smg1.iona.com ([10.70.2.37]) by amereast-ems2.IONAGLOBAL.COM with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 May 2004 17:10:26 -0400 Received: from amethyst.omg.org (amethyst.omg.org [192.67.184.64]) by amereast-smg1.iona.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id i46LAPW19790 for ; Thu, 6 May 2004 17:10:25 -0400 (EDT) Received: from hobbit.omg.org (hobbit.omg.org [192.67.184.3]) by amethyst.omg.org (8.12.8/8.12.8) with ESMTP id i46L8FFh001941; Thu, 6 May 2004 17:08:15 -0400 Received: from mailbox.syr.edu [128.230.18.5] by hobbit.omg.org asmtp(3.1c-beta4) id 3079; Thu, 06 May 2004 17:08:23 -0400 (EDT) Received: from syr.edu (syru210-198.ecs.syr.edu [128.230.210.198]) by mailbox.syr.edu (8.12.10/8.12.10) with ESMTP id i46L7fEs018594; Thu, 6 May 2004 17:07:48 -0400 (EDT) content-class: urn:content-classes:message Subject: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Date: Thu, 6 May 2004 17:07:33 -0400 Message-ID: <409AA915.7040606@syr.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQzro1zHUZUV9v3Qoqvphf/SYwKdQ== From: "Joncheng Kuo" To: Cc: The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send *all* BiDirIds on an ORB to *every* connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of *every* existing bi-directional connections (before or in the next request). The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted. Proposed resolution: 1. Extend the choices of the value field of the BidirectionalOfferPolicy: ALLOW_ALL -- same as ALLOW now, but the implication shall be explicitely stated in the spec ALLOW_LISTED -- a list of POAs being provided in the policy DENY -- same as it now 2. Add a field to the policy to allow a sequence of POAs being specified. Joncheng Kuo Syracuse University Date: Fri, 14 May 2004 08:20:40 -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: Polar Humenn , firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: However, Joncheng, you yourself said, in another (attached) email, "However, in practice, it's not always possible to tell whether two object references point to the same server or not." I agree with that statement. It's not possible to tell what server an object reference points to, much less tell if two are pointing to the same server. It is not always possible to tell doesn't mean that it can never tell. In some cases, an ORB can determine that two object references point to the same end point (e.g., IP and port) and may (optionally) choose to reuse the same connection. That was part of my argument for why your proposal won't work as you desire. You are trying to make sure particular BiDirIds are only offered over particular connections, in the name of efficiency. And I'm saying that since you can't tell what object references point to what servers, you cannot accomplish your goal by only offering a subset of BiDirIds when you invoke on an object. My goal can be achieved only by the cooperation between two levels. Here is the situation now. A client application: - knows what object references to use. - may set the BidirectionalOfferPolicy overrides on an object reference - may know what BiDirIds will be used when (or after) the client invokes a particular object reference. E.g., a client application may set up a "callback" object for each object reference that the client talks to. - doesn't know what connection will be used when the client invokes a particular object reference. The ORB for a client application: - knows all of the BiDirIds on the ORB. - knows the effective BidirectionalOfferPolicy on each object reference. - knows what connection will be used when the client application invokes a particular object reference. - doesn't know what BiDirIds will be needed on a particular connection. If you agree with the above situation, you may notice that both the client application and the ORB hold half of the missing link that I'm looking for. The ORB has the link from an object reference to the connection to be used; the client application may (or may not) have the link from an object reference to the needed BiDirIds. If both links exist, by pulling both links together, it is possible for the ORB to derive what BiDirIds will be needed on a connection. Again, what I said above is the optimal case. An ORB is free to ignore the possibility of optimization and sends all BiDirIds on each connection. Joncheng 1. How do you know what server is going to get that offer? 2. How do you know that whatever server does get the offer is the one that needs to callback to those particular objects? [This is the most important question] 3. How do you know that that is the only server that will need to callback? Much of the rest of my analysis was over "efficiency" since that is the reason you gave for having the hint and subset list. There really is no reason to have them, otherwise. Would your final goal of offering BiDirIds for callback objects to only those servers that will need to invoke them be more efficient? Sure - I'm not arguing that the goal is faulty. My conclusion was twofold: 1. since you don't know what server an object points to, you don't know what object to use to inform a server about a specific subset of callback objects. 2. it is "efficient enough" to offer all BiDirIds over all connections. I worked out several kinds of efficiency since you hadn't indicated which ones were the cause of your concern, and showed that the efficiency of each was well within normal operational parameters. So, since simply sending all BiDirIds over all connections was normally efficient, there wasn't sufficient need to have the additional hint and subset list, and, even if there were some need for more efficiency, you couldn't achieve it by offering a subset of BiDirIds over an invocation on an object whose server you can't determine. --Rebecca Joncheng However, there may be a way to achieve what you are looking for that doesn't change the semantics. To say that you are not going to eventually offer all BiDirIds implies that there are BiDirIds that could be offered but which aren't. What is the point of having those unoffered BiDirIds at all, then? Why apply the export policy to the POAs that aren't going to have their potential BiDirIds offered? If you have 10 POAs that your application knows could possibly be used for callbacks (or whatever you want to call their invocation from the connection acceptor) but somehow the application decides that it would be efficient to only offer 4 of these, why not just apply the export policy to those specific 4? The next offer includes those 4 rather than all ten and you have achieved the offering of your subset. --Rebecca -----Original Message----- From: Polar Humenn [mailto:polar@adiron.com] Sent: Wednesday, May 12, 2004 11:02 AM To: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? On Wed, 12 May 2004, Bergersen, Rebecca wrote: Joncheng goes on to discuss how putting a subset of BiDirIds on an offer can achieve this average. Since all BiDirIds are eventually going to get offered, how is offering a subset at a time going to achieve an "average number of BiDirIds on each bi-directional connection"? I think this is where you are missing the point. All BiDirIds do not get offered. The LISTED ones do. I don't know why Joncheng chose to explain it with this BiDirId averaging, but I can certainly see why it is confusing you if you think ALL BiDirIds will eventually be offered. They are not. I believe having the ability to place he LISTED policy on an object reference limits the problematic situation in which all 20,000 BiDirIds have to go down EVERY pipe. -Polar -------------------------------------------------------------------------------- Subject: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY From: "Joncheng Kuo" Date: Tue, 11 May 2004 10:38:25 -0400 To: Part of this issue has been surfaced in the discussions over the mail list. I now file it as an issue. The Bi-directional GIOP spec says, "An object reference with a BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional connection." Satisfying this policy requirement does not close some potential limitation and ambiguity when other policies or policy instances are around. For example, at the connection initiator side, we may have two object references one of which has BidirectionalOfferPolicy of DENY and the other has BidirectionalOfferPolicy of ALLOW. If these two object references point to the same server, according to spec, we need two connections to the server: one is bi-directional and one is not. However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection. There is an argument (by Brian Niebuhr) saying that it's not realistic to both trust and not trust the same server. However, in practice, it's not always possible to tell whether two object references point to the same server or not. Furthermore, the client may decide whether or not to trust the server of an object reference depending on reasons other than the information about the server. For example, the client may decide to use BidirectionalOfferPolicy of ALLOW or DENY according to the source of an object reference. On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and *effective* BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has off