Issue 7312: What BiDirIds shall be sent over what bidirectional connections? (firewall-traversal-ftf) Source: Syracuse University (Mr. C. Joncheng Kuo, joncheng_kuo(at)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 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? -------------------------------------------------------------------------------- Subject: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? From: "Joncheng Kuo" Date: Thu, 6 May 2004 17:07:33 -0400 To: 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, 17 May 2004 16:36:31 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQ5regGLINsxEfmSUupssV7iCWJZgCjXrqgAAQEFYA= From: "Bergersen, Rebecca" To: "Bergersen, Rebecca" , "Joncheng Kuo" Cc: Hi! I just want to be clear about something - I'm not against optimizing connections, per se. It's just that this proposed protocol only applies in a special case (app knows which objects reference which servers) and since the results aren't known and the application wouldn't know how to proceed, it is incomplete. We have only a limited time left to deal with another ten or so issues, many of which have a dependency on this one. We must conclude this and move on. That's why I say that we should go with the recommendation that does work, though it might not be optimal, and move on to get the other issues resolved. The optimization can be worked out for the next version of this spec. I'd like to hear all of the other FTF members' opinions on this point. --Rebecca -----Original Message----- From: Bergersen, Rebecca Sent: Monday, May 17, 2004 3:05 PM To: 'Joncheng Kuo' Cc: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Friday, May 14, 2004 8:21 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: 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. [Bergersen, Rebecca] Oh, the ORB can always tell. It's the application that can't tell. However, in your proposal, it's the application that is choosing what object reference to use to inform a particular server about a particular set of BiDirIds. Thus, it won't work. 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. [Bergersen, Rebecca] But the problem is that what is known by the ORB isn't shared with the app. Your protocol asks the application to assign a subset of BiDirIds to a particular object reference. The application doesn't know what server that object reference refers to, much less what connection would be used. So it can't logically make the right choice. 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. [Bergersen, Rebecca] And this gets into the other problems I pointed out in my analysis. What is the app supposed to do after it has offered a subset of BiDirIds? It doesn't know if all of them were offered or not. What about the remaining BiDirIds? Did the ORB ignore the possibility of optimization and send all BiDirIds on each connection? If it did and the application turns around and offers another subset using another specific object reference, your optimization has just gone out the window. The application wouldn't know how the hints were used without some feedback from the ORB. Look, as I've pointed out, this optimization isn't going to work. Let's drop the idea and move on. Let's agree to send all BiDirIds on all connections. That will work and we have other decisions to make in the next couple of weeks. Introduce an optimization design in the RTF. 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 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? -------------------------------------------------------------------------------- Subject: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? From: "Joncheng Kuo" Date: Thu, 6 May 2004 17:07:33 -0400 To: 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, 17 May 2004 17:06:07 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard SGBU/MSO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: "Bergersen, Rebecca" Cc: Joncheng Kuo , firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? I am afraid I am a bit lost in this mailing list thread, and even the debating positions seem to have transmogirified a bit. So, could someone please crisply state what the two positions that we are debating are? I am in general all for doing the least amount of work at present that produces a usable specification.:-) Thanks, Jishnu. Bergersen, Rebecca wrote: Hi! I just want to be clear about something - I'm not against optimizing connections, /per se/. It's just that this proposed protocol only applies in a special case (app knows which objects reference which servers) and since the results aren't known and the application wouldn't know how to proceed, it is incomplete. We have only a limited time left to deal with another ten or so issues, many of which have a dependency on this one. We must conclude this and move on. That's why I say that we should go with the recommendation that does work, though it might not be optimal, and move on to get the other issues resolved. The optimization can be worked out for the next version of this spec. I'd like to hear all of the other FTF members' opinions on this point. --Rebecca Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Date: Mon, 17 May 2004 15:04:49 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQ5regGLINsxEfmSUupssV7iCWJZgCjXrqg From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Friday, May 14, 2004 8:21 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: 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. [Bergersen, Rebecca] Oh, the ORB can always tell. It's the application that can't tell. However, in your proposal, it's the application that is choosing what object reference to use to inform a particular server about a particular set of BiDirIds. Thus, it won't work. 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. [Bergersen, Rebecca] But the problem is that what is known by the ORB isn't shared with the app. Your protocol asks the application to assign a subset of BiDirIds to a particular object reference. The application doesn't know what server that object reference refers to, much less what connection would be used. So it can't logically make the right choice. 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. [Bergersen, Rebecca] And this gets into the other problems I pointed out in my analysis. What is the app supposed to do after it has offered a subset of BiDirIds? It doesn't know if all of them were offered or not. What about the remaining BiDirIds? Did the ORB ignore the possibility of optimization and send all BiDirIds on each connection? If it did and the application turns around and offers another subset using another specific object reference, your optimization has just gone out the window. The application wouldn't know how the hints were used without some feedback from the ORB. Look, as I've pointed out, this optimization isn't going to work. Let's drop the idea and move on. Let's agree to send all BiDirIds on all connections. That will work and we have other decisions to make in the next couple of weeks. Introduce an optimization design in the RTF. 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 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? -------------------------------------------------------------------------------- Subject: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? From: "Joncheng Kuo" Date: Thu, 6 May 2004 17:07:33 -0400 To: 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, 17 May 2004 19:10:48 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQ8VOrNXZbhxcL/T7GrPmsUXvZFJAACTRsQ From: "Bergersen, Rebecca" To: "Jishnu Mukerji" Cc: "Joncheng Kuo" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4HNCgun026964 The base decision to be made is whether to stop debate and go with always offering all unoffered BiDirIds over all connections or to continue trying to design an optimization so BiDirIds are only associated with the connections that will actually use them. Other issues depend on how this one is resolved. So, I'd like to get the sense of the task force as to whether we should postpone the optimization to another version of the spec and accept the non-optimized solution for this version or whether we should continue to debate the workability of the proposal. The proposal is to change the value of the field on the BiDir Offer Policy which indicates whether an invocation on the object to which it is applied can be used to carry a BiDir Offer service context. The current values are ALLOW and DENY. The proposal is to change that to ALLOW_ALL, ALLOW_LISTED and DENY. ALLOW_ALL is the same as the current ALLOW. ALLOW_LISTED is the additional value and it is a hint as to how the ORB may deal with a list of POAs that has also been added to the BiDir Offer Policy. The ORB will derive the subset of BiDirIds to be offered from the list of POAs provided in the offer. Only these BiDirIds will be included in the BiDir Offer service context and they will only be sent to the server that the invoked object references. Since ALLOW_LISTED is only a hint, the ORB may choose to offer all BiDirIds over all connections even if ALLOW_LISTED is specified. My objection to the proposal is that it: 1. only works in the special case where the application knows what specific servers the objects used for the offers reference, what callback objects each specific server is going to require, and that no other server will need to invoke on those objects. 2. doesn't work beyond its first use because the application has no way of knowing what the ORB actually did with the hint and thus can't know how it should proceed optimally. Maybe I'm all wet and the task force thinks the proposal is a good thing and will work or with a little more effort will work. That's fine, but only Polar/Joncheng and I have been discussing this, so I don't know how people feel about continuing. I started to write up a ballot and realized that other issues depend on this one, so I'd like to get a sense of the TF as to how they feel about this. --Rebecca > -----Original Message----- > From: Jishnu Mukerji [mailto:jishnu@hp.com] > Sent: Monday, May 17, 2004 5:06 PM > To: Bergersen, Rebecca > Cc: Joncheng Kuo; firewall-traversal-ftf@omg.org > Subject: Re: Firewall Issue: What BiDirIds shall be sent over what > bidirectional connections? > > > I am afraid I am a bit lost in this mailing list thread, and > even the > debating positions seem to have transmogirified a bit. So, > could someone > please crisply state what the two positions that we are debating are? > > I am in general all for doing the least amount of work at > present that > produces a usable specification.:-) > > Thanks, > > Jishnu. > > Bergersen, Rebecca wrote: > > > Hi! > > > > I just want to be clear about something - I'm not against > optimizing > > connections, /per se/. It's just that this proposed > > protocol only applies in a special case (app knows which objects > > reference which servers) and since the results aren't known and the > > application wouldn't know how to proceed, it is incomplete. > We have > > only a limited time left to deal with another ten or so > issues, many > > of which have a dependency on this one. We must conclude this and > > move on. That's why I say that we should go with the > recommendation > > that does work, though it might not be optimal, and move on > to get the > > other issues resolved. The optimization can be worked out for the > > next version of this spec. > > > > I'd like to hear all of the other FTF members' opinions on > this point. > > > > --Rebecca > > > Date: Tue, 18 May 2004 09:57:30 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji Cc: firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? The issue is about the contradictory nature of the BiDir programming model. Concisely, if you place a BiDirOfferPolicy of DENY on an object reference using set_policy_overrides, which needs an existing object reference, which may have a BiDirOfferPolicy of ALLOW, then you have two contradictory object references to the same "server". The ALLOW one ORDERS the ORB to *make* bidir offers to the server. The DENY one ORDERS the ORB NOT TO *make* bidir offers to the server. This situation is contraditory and is unreconcilable in its current form. You can make all sorts of arguments about which one may take precedence, but those arguments hardly work, because I can always think of an argument to reverse the precendence (or importance) of an ALLOW/DENY decision. Also, the temporal conditions of when these policies are placed on object references lead to all kind of integrity complexities. The result will be a programming model people would call hogwash, and the integrity of CORBA will greatly suffer. I could go on and on about all the other problems, but I'll stop here. ------------------------------------------------------------------- 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, 18 May 2004 11:29:22 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org, interop@omg.org, ab@omg.org Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? On Mon, 17 May 2004, Bergersen, Rebecca wrote: > Hi! > I just want to be clear about something - I'm not against optimizing > connections, per se. It's just that this proposed protocol only applies > in a special case (app knows which objects reference which servers) and > since the results aren't known and the application wouldn't know how to > proceed, it is incomplete. We have only a limited time left to deal > with another ten or so issues, many of which have a dependency on this > one. We must conclude this and move on. That's why I say that we > should go with the recommendation that does work, though it might not be > optimal, and move on to get the other issues resolved. > The optimization can be worked out for the next version of this spec. Next Version??? Is there going to be an RFP to fix this abomination? Or is this going to be like one of those arguments you hear at the adoption process, "This can be fixed in an FTF", which allows us to accept broken/incomplete specifications? We now move this insanity to "This can be fixed in an RTF"?!?! Just realize guys, the result of this FTF, if it gets through, is going into the CORE, and it's going to be your headache should this thing get through the picket fence, and you can be sure you'll be spending your precious time fixing/overhauling something that is so friggin optional that nobody will implement it anyway. Nobody has addressed problems with BiDir Strong Offers, because the interested parties do not want to implement them. Nobody has even investigated the Firewall Traversal problems, because the interested parties do not want to implement them. And because they are *SUPPOSED* to be "optional", nobody really cares how it turns out. The whole focus seems to revolve around this Weak BiDirectional Offer, which, I might add, is already in the CORE. It is the "impression" that this newer version of BiDir, because of the use of some random number as a BiDir Id instead of a hostname and port number, it offers better "security". It does not. One can easily put a random sequence of characters as a host, and a bogus port number in a LISTEN_POINT service context and get the exact same result. The "newer" version of BiDir is like a bruised apple, but only comes in a cart with a lot of rotting meat. It just offers ridiculous GIOP headaches, such as these new NegotiationSession messages added to GIOP, GIOP versioning, acking BiDir Offer messages in service contexts, not to mention its flawed programming model, and I can go on and on. You pass this FTF/specification, you'll give yourselves a debt that will haunt not only you, but your children as well. -Polar > I'd like to hear all of the other FTF members' opinions on this point. > > --Rebecca > > -----Original Message----- > From: Bergersen, Rebecca > Sent: Monday, May 17, 2004 3:05 PM > To: 'Joncheng Kuo' > Cc: firewall-traversal-ftf@omg.org > Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? > > > > > -----Original Message----- > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > Sent: Friday, May 14, 2004 8:21 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: > > > 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. > > [Bergersen, Rebecca] > Oh, the ORB can always tell. It's the application that can't tell. However, in your proposal, it's the application that is choosing what object reference to use to inform a particular server about a particular set of BiDirIds. Thus, it won't work. > > > 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. > > [Bergersen, Rebecca] > But the problem is that what is known by the ORB isn't shared with the app. Your protocol asks the application to assign a subset of BiDirIds to a particular object reference. The application doesn't know what server that object reference refers to, much less what connection would be used. So it can't logically make the right choice. > > 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. > > [Bergersen, Rebecca] > And this gets into the other problems I pointed out in my analysis. What is the app supposed to do after it has offered a subset of BiDirIds? It doesn't know if all of them were offered or not. What about the remaining BiDirIds? Did the ORB ignore the possibility of optimization and send all BiDirIds on each connection? If it did and the application turns around and offers another subset using another specific object reference, your optimization has just gone out the window. The application wouldn't know how the hints were used without some feedback from the ORB. > > Look, as I've pointed out, this optimization isn't going to work. Let's drop the idea and move on. Let's agree to send all BiDirIds on all connections. That will work and we have other decisions to make in the next couple of weeks. Introduce an optimization design in the RTF. > > 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 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? > > > > > _____ > > > > Subject: > Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? > > From: > "Joncheng Kuo" > > Date: > Thu, 6 May 2004 17:07:33 -0400 > > To: > > > > 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 > > > > ------------------------------------------------------------------- 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, 18 May 2004 11:42:11 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQ5regGLINsxEfmSUupssV7iCWJZgCjXrqgACxgZLA= From: "Dave Stringer" To: "Bergersen, Rebecca" , "Joncheng Kuo" Cc: X-OriginalArrivalTime: 18 May 2004 18:42:12.0180 (UTC) FILETIME=[D50ED140:01C43D07] An ORB cannot always tell what server an Object reference "points to" (as someone claimed) An Object Reference with multiple profiles, or with TAG_ALTERNATE_IIOP_ADDRESS components, or with the address of a location daemon or of a proxy/bridge cannot provide a determination of what server it "points to" simply by inspecting the contents of the IOR. The term "points to" is hopelessly undefined. If instead, we use the only term that has any meaning, in the context of the CORBA specification, for discussing the relationship between an Object Reference and a GIOP connection: "binding", we will still struggle to make progress. So when does a GIOP connection "become" bi-directional? It would seem that this can only be when an invocation is made upon an Object Reference, that has an effective Offer Policy of Allow, AND that the ORB selects (resolving forwarding as necessary) a particular GIOP connection. The act of changing the effective policy for an Object Reference cannot change the state of a connection unless the relationship from Object reference to GIOP connection is defined. Although this relationship will exist in an implementation (so that an invocation does lead to a GIOP Request message), a relationship is not defined in the CORBA specification. And so a relationship cannot be assumed by this specification nor should it be defined - as this restricts the freedom of ORB implementers for relatively little gain. Continuing ... When does a GIOP connection cease to be bi-directional? I would guess (and I have to guess as there are insufficient clues in the spec!) that it remains bi-directional until it is closed. This presents two problems: 1. if an ORB actions an idle timeout on a connection, any reconnection is, in GIOP terms, a new (different) connection and therefore not (yet) bi-directional. This might be a severe disappointment to the application. 2. if an application has finished with the bi-directional capability (e.g. by destroying the POA with Export Policy of Allow, is the ORB expected to close or to maintain the bi-directional GIOP connection? Dave Subject: RE: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Date: Tue, 18 May 2004 13:02:36 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: What BiDirIds shall be sent over what bidirectional connections? Thread-Index: AcQ8VO+UK8PpNefATqCsJ2G3mirIXgAuSncQ From: "Dave Stringer" To: "Jishnu Mukerji" , "Bergersen, Rebecca" Cc: "Joncheng Kuo" , X-OriginalArrivalTime: 18 May 2004 20:02:36.0980 (UTC) FILETIME=[10DCDF40:01C43D13] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4IK5Oun031425 Jishnu A "usable" specification is certainly necessary but I'm not convinced its sufficient. I think we should expect a "complete" specification and one that is "consistent", both in itself and crucially with CORBA as it stands. I can't tell if your use of the word "usable :-)" covers all of this or is, in some sense, less ambitious. Mathematically, there is no doubt a "least amount of work" that would achieve the goal. My question would be: is it realistic to expect it will happen within this FTF? At present, even fairly simple questions don't receive answers due, I suspect, to the different assumptions we're all making about the spec. I don't think we've identified the issues that will break the log-jam, that is, will document those assumptions. Dave Jishnu Mukerji wrote: > I am afraid I am a bit lost in this mailing list thread, and even the > debating positions seem to have transmogirified a bit. So, could someone > please crisply state what the two positions that we are debating are? > > I am in general all for doing the least amount of work at present that > produces a usable specification.:-) > > Thanks, > > Jishnu. Subject: RE: Firewall FTF BALLOT 4 - Please Vote! Date: Tue, 1 Jun 2004 22:48:18 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF BALLOT 4 - Please Vote! Thread-Index: AcRIRUSU1X+cz/yXRcGqvhhr6eT6ygAABk4w From: "Bergersen, Rebecca" To: "Bergersen, Rebecca" , IONA votes: YES on Issue 6311: Negotiation Session message is unwieldy YES on Issue 7303: Firewall issue - Number of BiDirIds in a BiDirOffer YES on issue 7308: Firewall issue: Response to failed BiDir challenge is unclear YES on issue 7309: Firewall Issue: Connection over which BiDir Offers are sent is unspecified YES on issue 7310: Firewall Issue: Random BiDirIds can't be used for persistent POAs YES on issue 7311: Interplay of contexts allowed in NegotiateSession messages too ill-defined NO on issue 7312: What BiDirIds shall be sent over what bidirectional connections? YES on issue 7313: Firewall FTF Issue: No end-to-end security for firewall traversal YES on issue 7314: Processing of NegotiateSession messages at various stages of connection setup YES on issue 7315: Targets of Export and Offer Policies incompletely specified YES on issue 7316: Expected behavior of a non-conformant implementation YES on Issue 7317: connection_complete field of the FirewallPathRespContext is under specified YES on issue 7318: How many BI_DIR_GIOP_OFFER service contexts are allowed YES on issue 7332: GIOP and IIOP versioning must be clearly and consistently specified YES on issue 7351: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY YES on issue 7352: Bi-directional connections considered volatile at connection acceptor side YES on issue 7356: when is a connection a "bi-directional connection"? IONA voted NO on issue 7312 for two reasons: The "optimization" proposed relies on the application knowing what specific servers the objects used for the offers reference, what callbacks objects each specific server is going to require, and that no other server will need to invoke on those objects. Thus this optimization applies to only a very special limited case. The proposal specifies that the ORB takes the use of this optimization only as a hint and may choose instead to send all BiDirIds over all connections. However, the proposal does not specify how the application finds out what the ORB did, so the application is not able to proceed optimally. Regards, Rebecca Bergersen PRINCIPAL ARCHITECT, MIDDLEWARE STANDARDS rebecca.bergersen@iona.com ------------------------------------------------------- IONA Technologies 200 West Street Waltham, MA 02451 USA Tel: (781) 902-8265 Fax: (781) 902-8001 ------------------------------------------------------- Making Software Work Together TM -----Original Message----- From: Bergersen, Rebecca Sent: Tuesday, June 01, 2004 10:00 PM To: 'firewall-traversal-ftf@omg.org' Cc: Bergersen, Rebecca Subject: Firewall FTF BALLOT 4 - Please Vote! Firewall Traversal FTF members, The fourth ballot for the Firewall Traversal FTF is attached. It covers 17 issues. Please cast your votes before the deadline of 5:00 PM EDT on Tuesday, June 8th. The issues being balloted are the root issues, as much as I was able to determine those. Unfortunately, the issues posed are not orthogonal to each other and our discussions on specific issues have frequently extended into aspects of other issues, thus further entangling them. However, I have attempted to pick those issues on which others depend for this ballot. These were also the issues most discussed during this term of the FTF. I believe if these are resolved, most of the others will "fall out" or simply be redundant. Most of the issues have a Discussion section. I attempted to summarize the end point reached in the email dialogue about the topic. I also used that section to indicate the interrelationships among the issues being balloted. In some cases, I indicated that the issue was subsumed by another issue and thus closed as a duplicate. This was necessary because of the lack of orthogonality and the fact that we don't have the liesure to sort it all out and vote on them in dependency order through progressive ballots. I attempted to frame the resolutions to incorporate any agreement that we reached in our email discussions. In several cases there was no agreement, so I chose one side or another (not always my own!) and presented it. Where there had been no discussion but a resolution had been offered by the issue's author, I used that resolution. In the end, it is an imperfect work. Vote Early! Regards, Rebecca Bergersen, FTF Chair PRINCIPAL ARCHITECT, MIDDLEWARE STANDARDS rebecca.bergersen@iona.com ------------------------------------------------------- IONA Technologies 200 West Street Waltham, MA 02451 USA Tel: (781) 902-8265 Fax: (781) 902-8001 ------------------------------------------------------- Making Software Work Together TM