Issue 7352: Bi-directional connections considered volatile at connection acceptor side (firewall-traversal-ftf) Source: Syracuse University (C. Joncheng Kuo, nobody) Nature: Uncategorized Issue Severity: Summary: This issue was mentioned by Dave Stringer. I now file it as an issue. When a bi-directional connection is established between a connection initiator and a connection acceptor, the connection acceptor may have to consider this bi-directional connection is volatile, i.e., the connection acceptor may lose (and is not able to resume) its capability of making invocations on such a connection anytime. For example, the connection may be lost due to network problems or the client may close a connection due to an idle time-out. These situations are not a problem for uni-directional GIOP because the ORB who wants to make an invocation can always initiate a new connection when the old connection is not available. This problem may be less serious when bi-directional communication occurs only during the period of an invocation from the connection initiator. In other words, if the connection is lost and results in the failure of bi-directional "callback", the connection initiator may retry, effectively resuming the bi-directional connection. On the other hand, for the use case in which a connection initiator "registers" an object reference to the connection acceptor, there is no guarantee that "callbacks" from the connection acceptor to the connection initiator will eventually succeed, assuming the network is not always down. If this issue is a limitation that cannot be solved easily, we should spell it out in the spec. Resolution: Revised Text: Actions taken: May 11, 2004: received issue Discussion: End of Annotations:===== te: Tue, 11 May 2004 11:17:02 -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: issues@omg.org CC: firewall-traversal-ftf@omg.org Subject: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side X-Virus-Scanned: Symantec AntiVirus Scan Engine This issue was mentioned by Dave Stringer. I now file it as an issue. When a bi-directional connection is established between a connection initiator and a connection acceptor, the connection acceptor may have to consider this bi-directional connection is volatile, i.e., the connection acceptor may lose (and is not able to resume) its capability of making invocations on such a connection anytime. For example, the connection may be lost due to network problems or the client may close a connection due to an idle time-out. These situations are not a problem for uni-directional GIOP because the ORB who wants to make an invocation can always initiate a new connection when the old connection is not available. This problem may be less serious when bi-directional communication occurs only during the period of an invocation from the connection initiator. In other words, if the connection is lost and results in the failure of bi-directional "callback", the connection initiator may retry, effectively resuming the bi-directional connection. On the other hand, for the use case in which a connection initiator "registers" an object reference to the connection acceptor, there is no guarantee that "callbacks" from the connection acceptor to the connection initiator will eventually succeed, assuming the network is not always down. If this issue is a limitation that cannot be solved easily, we should spell it out in the spec. Subject: RE: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side Date: Wed, 12 May 2004 12:02:17 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side Thread-Index: AcQ3a4jFh5ORSBgaS/mV08Pyze4VsQAzsa/Q From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4CG3a8k027983 I agree that the effect of losing a connection should be spelled out. Additionally, this condition is an argument for offering BiDirIds over all connections so the connection acceptor has the possibility of other choices if a connection is lost. --Rebecca > -----Original Message----- > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > Sent: Tuesday, May 11, 2004 11:17 AM > To: issues@omg.org > Cc: firewall-traversal-ftf@omg.org > Subject: Firewall FTF Issue: Bi-directional connections are considered > volatile at the connection acceptor side > > > This issue was mentioned by Dave Stringer. I now file it as an issue. > > When a bi-directional connection is established between a connection > initiator and a connection acceptor, the connection acceptor > may have to > consider this bi-directional connection is volatile, i.e., the > connection acceptor may lose (and is not able to resume) its > capability > of making invocations on such a connection anytime. For example, the > connection may be lost due to network problems or the client > may close a > connection due to an idle time-out. These situations are not > a problem > for uni-directional GIOP because the ORB who wants to make an > invocation > can always initiate a new connection when the old connection is not > available. > > This problem may be less serious when bi-directional communication > occurs only during the period of an invocation from the connection > initiator. In other words, if the connection is lost and > results in the > failure of bi-directional "callback", the connection initiator may > retry, effectively resuming the bi-directional connection. > > On the other hand, for the use case in which a connection initiator > "registers" an object reference to the connection acceptor, > there is no > guarantee that "callbacks" from the connection acceptor to the > connection initiator will eventually succeed, assuming the network is > not always down. > > If this issue is a limitation that cannot be solved easily, we should > spell it out in the spec. > > > > Date: Wed, 12 May 2004 12:17:11 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: firewall-traversal-ftf@omg.org Subject: Re: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: I agree that the effect of losing a connection should be spelled out. Additionally, this condition is an argument for offering BiDirIds over all connections so the connection acceptor has the possibility of other choices if a connection is lost. What other choices are you talking about? Are you talking about possible some other redundant connections to the same server? If so, these connections should in general not to be relied on. Joncheng --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Tuesday, May 11, 2004 11:17 AM To: issues@omg.org Cc: firewall-traversal-ftf@omg.org Subject: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side This issue was mentioned by Dave Stringer. I now file it as an issue. When a bi-directional connection is established between a connection initiator and a connection acceptor, the connection acceptor may have to consider this bi-directional connection is volatile, i.e., the connection acceptor may lose (and is not able to resume) its capability of making invocations on such a connection anytime. For example, the connection may be lost due to network problems or the client may close a connection due to an idle time-out. These situations are not a problem for uni-directional GIOP because the ORB who wants to make an invocation can always initiate a new connection when the old connection is not available. This problem may be less serious when bi-directional communication occurs only during the period of an invocation from the connection initiator. In other words, if the connection is lost and results in the failure of bi-directional "callback", the connection initiator may retry, effectively resuming the bi-directional connection. On the other hand, for the use case in which a connection initiator "registers" an object reference to the connection acceptor, there is no guarantee that "callbacks" from the connection acceptor to the connection initiator will eventually succeed, assuming the network is not always down. If this issue is a limitation that cannot be solved easily, we should spell it out in the spec. Subject: RE: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side Date: Thu, 13 May 2004 14:35:03 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side Thread-Index: AcQ4PJdtVVvFB9wBQhyaayl/Zhs57QA3EDDQ From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: We spent last month discussing the need to offer BiDirIds over all connections. You and Polar and Brian Niebuhr finally convinced me that was necessary. Now you're saying more than one connection can not be relied on? --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Wednesday, May 12, 2004 12:17 PM To: Bergersen, Rebecca Cc: firewall-traversal-ftf@omg.org Subject: Re: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side Bergersen, Rebecca wrote: I agree that the effect of losing a connection should be spelled out. Additionally, this condition is an argument for offering BiDirIds over all connections so the connection acceptor has the possibility of other choices if a connection is lost. What other choices are you talking about? Are you talking about possible some other redundant connections to the same server? If so, these connections should in general not to be relied on. Joncheng --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Tuesday, May 11, 2004 11:17 AM To: issues@omg.org Cc: firewall-traversal-ftf@omg.org Subject: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side This issue was mentioned by Dave Stringer. I now file it as an issue. When a bi-directional connection is established between a connection initiator and a connection acceptor, the connection acceptor may have to consider this bi-directional connection is volatile, i.e., the connection acceptor may lose (and is not able to resume) its capability of making invocations on such a connection anytime. For example, the connection may be lost due to network problems or the client may close a connection due to an idle time-out. These situations are not a problem for uni-directional GIOP because the ORB who wants to make an invocation can always initiate a new connection when the old connection is not available. This problem may be less serious when bi-directional communication occurs only during the period of an invocation from the connection initiator. In other words, if the connection is lost and results in the failure of bi-directional "callback", the connection initiator may retry, effectively resuming the bi-directional connection. On the other hand, for the use case in which a connection initiator "registers" an object reference to the connection acceptor, there is no guarantee that "callbacks" from the connection acceptor to the connection initiator will eventually succeed, assuming the network is not always down. If this issue is a limitation that cannot be solved easily, we should spell it out in the spec. Date: Thu, 13 May 2004 15:42:05 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: RE: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side On Thu, 13 May 2004, Bergersen, Rebecca wrote: > We spent last month discussing the need to offer BiDirIds over all > connections. You and Polar and Brian Niebuhr finally convinced me that > was necessary. Now you're saying more than one connection can not be > relied on? Rebecca, I spent the last month convincing you that the specification implied that ALL BiDirIds had to be transmitted over EVERY connection. I also tried to get the point across that this implication is an EXTREMELY BAD idea. Cheers, -Polar > > --Rebecca > > -----Original Message----- > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > Sent: Wednesday, May 12, 2004 12:17 PM > To: Bergersen, Rebecca > Cc: firewall-traversal-ftf@omg.org > Subject: Re: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side > > > Bergersen, Rebecca wrote: > > > I agree that the effect of losing a connection should be spelled out. Additionally, this condition is an argument for offering BiDirIds over all connections so the connection acceptor has the possibility of other choices if a connection is lost. > > What other choices are you talking about? Are you talking about possible some other redundant connections to the same server? If so, these connections should in general not to be relied on. > > Joncheng > > > > > --Rebecca > > > > > > > > -----Original Message----- > > From: Joncheng Kuo [ mailto:ckuo01@syr.edu] > > Sent: Tuesday, May 11, 2004 11:17 AM > > To: issues@omg.org > > Cc: firewall-traversal-ftf@omg.org > > Subject: Firewall FTF Issue: Bi-directional connections are considered > > volatile at the connection acceptor side > > > > > > This issue was mentioned by Dave Stringer. I now file it as an issue. > > > > When a bi-directional connection is established between a connection > > initiator and a connection acceptor, the connection acceptor > > may have to > > consider this bi-directional connection is volatile, i.e., the > > connection acceptor may lose (and is not able to resume) its > > capability > > of making invocations on such a connection anytime. For example, the > > connection may be lost due to network problems or the client > > may close a > > connection due to an idle time-out. These situations are not > > a problem > > for uni-directional GIOP because the ORB who wants to make an > > invocation > > can always initiate a new connection when the old connection is not > > available. > > > > This problem may be less serious when bi-directional communication > > occurs only during the period of an invocation from the connection > > initiator. In other words, if the connection is lost and > > results in the > > failure of bi-directional "callback", the connection initiator may > > retry, effectively resuming the bi-directional connection. > > > > On the other hand, for the use case in which a connection initiator > > "registers" an object reference to the connection acceptor, > > there is no > > guarantee that "callbacks" from the connection acceptor to the > > connection initiator will eventually succeed, assuming the network is > > not always down. > > > > If this issue is a limitation that cannot be solved easily, we should > > spell it out in the spec. > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side Date: Thu, 13 May 2004 17:41:09 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side Thread-Index: AcQ5IqDMv2b4f2fFS3uBFFs7gG2lPQADmbQA From: "Bergersen, Rebecca" To: "Polar Humenn" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4DLgRun016334 inlined comments, as usual ... > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Thursday, May 13, 2004 3:42 PM > To: firewall-traversal-ftf@omg.org > Subject: RE: Firewall FTF Issue: Bi-directional connections are > considered volatile at the connection acceptor side > > > > On Thu, 13 May 2004, Bergersen, Rebecca wrote: > > > We spent last month discussing the need to offer BiDirIds over all > > connections. You and Polar and Brian Niebuhr finally > convinced me that > > was necessary. Now you're saying more than one connection > can not be > > relied on? > > Rebecca, > > I spent the last month convincing you that the specification implied > that ALL BiDirIds had to be transmitted over EVERY connection. > And you did a VERY good job. It took me a while but I eventually got it. :-) > I also tried to get the point across that this implication is > an EXTREMELY > BAD idea. > And now I don't get that. My analysis showed that transmitting all BiDirIds over all connections was efficient within normal operating parameters, even with an extreme edge case. Is it as efficient as only transmitting specific BiDirIds to the servers that require them? No, obviously not. But it's efficient enough for normal use. I also showed that you can't achieve the goal of offering specific BiDirIds to only the servers that need them by invoking on an object and offering the hint and list that was proposed. As Joncheng has said, it is not possible to know what server an object reference points to. So, how do you know that you are sending the proper subset to the proper server? > Cheers, > -Polar > > > > > > > --Rebecca > > > > -----Original Message----- > > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > > Sent: Wednesday, May 12, 2004 12:17 PM > > To: Bergersen, Rebecca > > Cc: firewall-traversal-ftf@omg.org > > Subject: Re: Firewall FTF Issue: Bi-directional connections > are considered volatile at the connection acceptor side > > > > > > Bergersen, Rebecca wrote: > > > > > > I agree that the effect of losing a connection should be > spelled out. Additionally, this condition is an argument for > offering BiDirIds over all connections so the connection > acceptor has the possibility of other choices if a connection is lost. > > > > What other choices are you talking about? Are you talking > about possible some other redundant connections to the same > server? If so, these connections should in general not to be > relied on. > > > > Joncheng > > > > > > > > > > --Rebecca > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Joncheng Kuo [ mailto:ckuo01@syr.edu] > > > > Sent: Tuesday, May 11, 2004 11:17 AM > > > > To: issues@omg.org > > > > Cc: firewall-traversal-ftf@omg.org > > > > Subject: Firewall FTF Issue: Bi-directional connections are > considered > > > > volatile at the connection acceptor side > > > > > > > > > > > > This issue was mentioned by Dave Stringer. I now file it as > an issue. > > > > > > > > When a bi-directional connection is established between a connection > > > > initiator and a connection acceptor, the connection acceptor > > > > may have to > > > > consider this bi-directional connection is volatile, i.e., the > > > > connection acceptor may lose (and is not able to resume) its > > > > capability > > > > of making invocations on such a connection anytime. For example, the > > > > connection may be lost due to network problems or the client > > > > may close a > > > > connection due to an idle time-out. These situations are not > > > > a problem > > > > for uni-directional GIOP because the ORB who wants to make an > > > > invocation > > > > can always initiate a new connection when the old connection is not > > > > available. > > > > > > > > This problem may be less serious when bi-directional communication > > > > occurs only during the period of an invocation from the connection > > > > initiator. In other words, if the connection is lost and > > > > results in the > > > > failure of bi-directional "callback", the connection initiator may > > > > retry, effectively resuming the bi-directional connection. > > > > > > > > On the other hand, for the use case in which a connection initiator > > > > "registers" an object reference to the connection acceptor, > > > > there is no > > > > guarantee that "callbacks" from the connection acceptor to the > > > > connection initiator will eventually succeed, assuming the > network is > > > > not always down. > > > > > > > > If this issue is a limitation that cannot be solved easily, > we should > > > > spell it out in the spec. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > 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 17:53:33 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: RE: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side On Thu, 13 May 2004, Bergersen, Rebecca wrote: > And now I don't get that. My analysis showed that transmitting all > BiDirIds over all connections was efficient within normal operating > parameters, even with an extreme edge case. Is it as efficient as only > transmitting specific BiDirIds to the servers that require them? No, > obviously not. Well, you answered your own question. :) > But it's efficient enough for normal use. I may point out that is YOUR particular "normal" use. > I also showed that you can't achieve the goal of offering specific > BiDirIds to only the servers that need them by invoking on an object and > offering the hint and list that was proposed. As Joncheng has said, it > is not possible to know what server an object reference points to. So, > how do you know that you are sending the proper subset to the proper > server? That is exactly why the model of "ALLOW/DENY" doesn't work. It does't make sense, in that regard. If I have two object references that point to the same server, and one has BiDirOffer policy of ALLOW and the other has DENY? Your programming model suffers from a complete contradiction. I have better solutions to this situation, but again, they aren't all that well thought out (no time). And, you don't seem to be entertaining anything else anyway. Cheers, -Polar > > Cheers, > > -Polar > > > > > > > > > > > > --Rebecca > > > > > > -----Original Message----- > > > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > > > Sent: Wednesday, May 12, 2004 12:17 PM > > > To: Bergersen, Rebecca > > > Cc: firewall-traversal-ftf@omg.org > > > Subject: Re: Firewall FTF Issue: Bi-directional connections > > are considered volatile at the connection acceptor side > > > > > > > > > Bergersen, Rebecca wrote: > > > > > > > > > I agree that the effect of losing a connection should be > > spelled out. Additionally, this condition is an argument for > > offering BiDirIds over all connections so the connection > > acceptor has the possibility of other choices if a connection is lost. > > > > > > What other choices are you talking about? Are you talking > > about possible some other redundant connections to the same > > server? If so, these connections should in general not to be > > relied on. > > > > > > Joncheng > > > > > > > > > > > > > > > --Rebecca > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Joncheng Kuo [ mailto:ckuo01@syr.edu] > > > > > > Sent: Tuesday, May 11, 2004 11:17 AM > > > > > > To: issues@omg.org > > > > > > Cc: firewall-traversal-ftf@omg.org > > > > > > Subject: Firewall FTF Issue: Bi-directional connections are > > considered > > > > > > volatile at the connection acceptor side > > > > > > > > > > > > > > > > > > This issue was mentioned by Dave Stringer. I now file it as > > an issue. > > > > > > > > > > > > When a bi-directional connection is established between a connection > > > > > > initiator and a connection acceptor, the connection acceptor > > > > > > may have to > > > > > > consider this bi-directional connection is volatile, i.e., the > > > > > > connection acceptor may lose (and is not able to resume) its > > > > > > capability > > > > > > of making invocations on such a connection anytime. For example, the > > > > > > connection may be lost due to network problems or the client > > > > > > may close a > > > > > > connection due to an idle time-out. These situations are not > > > > > > a problem > > > > > > for uni-directional GIOP because the ORB who wants to make an > > > > > > invocation > > > > > > can always initiate a new connection when the old connection is not > > > > > > available. > > > > > > > > > > > > This problem may be less serious when bi-directional communication > > > > > > occurs only during the period of an invocation from the connection > > > > > > initiator. In other words, if the connection is lost and > > > > > > results in the > > > > > > failure of bi-directional "callback", the connection initiator may > > > > > > retry, effectively resuming the bi-directional connection. > > > > > > > > > > > > On the other hand, for the use case in which a connection initiator > > > > > > "registers" an object reference to the connection acceptor, > > > > > > there is no > > > > > > guarantee that "callbacks" from the connection acceptor to the > > > > > > connection initiator will eventually succeed, assuming the > > network is > > > > > > not always down. > > > > > > > > > > > > If this issue is a limitation that cannot be solved easily, > > we should > > > > > > spell it out in the spec. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > 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 FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side Date: Thu, 13 May 2004 18:34:38 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side Thread-Index: AcQ5NOEayp2D8NP4RR63xAzAJLmoYwAA+kVQ From: "Bergersen, Rebecca" To: "Polar Humenn" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4DMZuun016788 > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Thursday, May 13, 2004 5:54 PM > To: firewall-traversal-ftf@omg.org > Subject: RE: Firewall FTF Issue: Bi-directional connections are > considered volatile at the connection acceptor side > > > On Thu, 13 May 2004, Bergersen, Rebecca wrote: > > > And now I don't get that. My analysis showed that transmitting all > > BiDirIds over all connections was efficient within normal operating > > parameters, even with an extreme edge case. Is it as > efficient as only > > transmitting specific BiDirIds to the servers that require > them? No, > > obviously not. > > Well, you answered your own question. :) > > > But it's efficient enough for normal use. > > I may point out that is YOUR particular "normal" use. > > > I also showed that you can't achieve the goal of offering specific > > BiDirIds to only the servers that need them by invoking on > an object and > > offering the hint and list that was proposed. As Joncheng > has said, it > > is not possible to know what server an object reference > points to. So, > > how do you know that you are sending the proper subset to the proper > > server? > > That is exactly why the model of "ALLOW/DENY" doesn't work. But it's the APPLICATION that's putting the ALLOW on one object and DENY on the other. It's the application that is messed up if that is contradictory. Unless, as Joncheng pointed out, the app doesn't trust one source of objects and does another, and so DENY's the one source's objects. (I'm thinking aloud here.) But if that's true, why would the app instantiate the objects from the untrustworthy source in the first place? So, it's still the application that's messed up. The ORB will just make offers from the object that ALLOWs it and not make offers from the object that the application has said to DENY making offers from. What's wrong with that? The application has to get its act together, that's all. We're not going to save the world from such behavior. > > It does't make sense, in that regard. > > If I have two object references that point to the same server, and one > has BiDirOffer policy of ALLOW and the other has DENY? > > Your programming model suffers from a complete contradiction. > > I have better solutions to this situation, but again, they > aren't all that > well thought out (no time). And, you don't seem to be entertaining > anything else anyway. Our hands are tied. An FTF can't come up with a different solution from the one approved by the AB/*TC. > > Cheers, > -Polar > > > > > Cheers, > > > -Polar > > > > > > > > > > > > > > > > > --Rebecca > > > > > > > > -----Original Message----- > > > > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > > > > Sent: Wednesday, May 12, 2004 12:17 PM > > > > To: Bergersen, Rebecca > > > > Cc: firewall-traversal-ftf@omg.org > > > > Subject: Re: Firewall FTF Issue: Bi-directional connections > > > are considered volatile at the connection acceptor side > > > > > > > > > > > > Bergersen, Rebecca wrote: > > > > > > > > > > > > I agree that the effect of losing a connection should be > > > spelled out. Additionally, this condition is an argument for > > > offering BiDirIds over all connections so the connection > > > acceptor has the possibility of other choices if a > connection is lost. > > > > > > > > What other choices are you talking about? Are you talking > > > about possible some other redundant connections to the same > > > server? If so, these connections should in general not to be > > > relied on. > > > > > > > > Joncheng > > > > > > > > > > > > > > > > > > > > --Rebecca > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Joncheng Kuo [ mailto:ckuo01@syr.edu] > > > > > > > > Sent: Tuesday, May 11, 2004 11:17 AM > > > > > > > > To: issues@omg.org > > > > > > > > Cc: firewall-traversal-ftf@omg.org > > > > > > > > Subject: Firewall FTF Issue: Bi-directional connections are > > > considered > > > > > > > > volatile at the connection acceptor side > > > > > > > > > > > > > > > > > > > > > > > > This issue was mentioned by Dave Stringer. I now file it as > > > an issue. > > > > > > > > > > > > > > > > When a bi-directional connection is established between > a connection > > > > > > > > initiator and a connection acceptor, the connection acceptor > > > > > > > > may have to > > > > > > > > consider this bi-directional connection is volatile, i.e., the > > > > > > > > connection acceptor may lose (and is not able to resume) its > > > > > > > > capability > > > > > > > > of making invocations on such a connection anytime. For > example, the > > > > > > > > connection may be lost due to network problems or the client > > > > > > > > may close a > > > > > > > > connection due to an idle time-out. These situations are not > > > > > > > > a problem > > > > > > > > for uni-directional GIOP because the ORB who wants to make an > > > > > > > > invocation > > > > > > > > can always initiate a new connection when the old > connection is not > > > > > > > > available. > > > > > > > > > > > > > > > > This problem may be less serious when bi-directional > communication > > > > > > > > occurs only during the period of an invocation from the > connection > > > > > > > > initiator. In other words, if the connection is lost and > > > > > > > > results in the > > > > > > > > failure of bi-directional "callback", the connection > initiator may > > > > > > > > retry, effectively resuming the bi-directional connection. > > > > > > > > > > > > > > > > On the other hand, for the use case in which a > connection initiator > > > > > > > > "registers" an object reference to the connection acceptor, > > > > > > > > there is no > > > > > > > > guarantee that "callbacks" from the connection acceptor to the > > > > > > > > connection initiator will eventually succeed, assuming the > > > network is > > > > > > > > not always down. > > > > > > > > > > > > > > > > If this issue is a limitation that cannot be solved easily, > > > we should > > > > > > > > spell it out in the spec. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > Date: Fri, 14 May 2004 11:34:45 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: RE: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side On Thu, 13 May 2004, Bergersen, Rebecca wrote: > > has said, it > > > is not possible to know what server an object reference > > points to. So, > > > how do you know that you are sending the proper subset to the proper > > > server? > > > > That is exactly why the model of "ALLOW/DENY" doesn't work. > > But it's the APPLICATION that's putting the ALLOW on one object and DENY > on the other. It's the application that is messed up if that is > contradictory. You are assuming that the application has COMPLETE control of the ORB, and has omnipresent knowledge of what it and its components are doing. Remember we are working in the OBJECT MODEL, where ENCAPSULATION is PARAMOUNT! To explain: One component sets a DENY policy and then it (or another component) gets (unexpected) BiDir Requests because some other component set an ALLOW policy. This doesn't wash, no matter how much sodium carbonate you use. > Our hands are tied. An FTF can't come up with a different solution from > the one approved by the AB/*TC. Political Hogwash This FTF has proven to me, at least, that it cannot FIX this spec, so therefore this spec can go take a permanent visit to Davy Jones locker. Cheers, -Polar Subject: RE: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side Date: Fri, 14 May 2004 15:29:01 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF Issue: Bi-directional connections are considered volatile at the connection acceptor side Thread-Index: AcQ5yTuRLsQoI3c3RY+6eTQPHQdcfgAH793g From: "Bergersen, Rebecca" To: "Polar Humenn" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4EJaKun029190 > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Friday, May 14, 2004 11:35 AM > To: firewall-traversal-ftf@omg.org > Subject: RE: Firewall FTF Issue: Bi-directional connections are > considered volatile at the connection acceptor side > > > > On Thu, 13 May 2004, Bergersen, Rebecca wrote: > > > > has said, it > > > > is not possible to know what server an object reference > > > points to. So, > > > > how do you know that you are sending the proper subset > to the proper > > > > server? > > > > > > That is exactly why the model of "ALLOW/DENY" doesn't work. > > > > But it's the APPLICATION that's putting the ALLOW on one > object and DENY > > on the other. It's the application that is messed up if that is > > contradictory. > > You are assuming that the application has COMPLETE control of > the ORB, and > has omnipresent knowledge of what it and its components are doing. > > Remember we are working in the OBJECT MODEL, where ENCAPSULATION is > PARAMOUNT! > > To explain: One component sets a DENY policy and then it (or another > component) gets (unexpected) BiDir Requests because some > other component > set an ALLOW policy. Isn't this the point of communicating BiDirIds in the first place? Why would one component get unexpected BiDir requests on its callback objects if it hasn't offered their BiDirIds. If the encapsulation you discuss is viable, one component's callback objects aren't known by other components. Although there might be callback connection that *could* be used, the connection acceptor wouldn't know to use it for sending a BiDir Request to a component that hasn't offered it's BiDirIds. > > This doesn't wash, no matter how much sodium carbonate you use. > > > > Our hands are tied. An FTF can't come up with a different > solution from > > the one approved by the AB/*TC. > > Political Hogwash > > This FTF has proven to me, at least, that it cannot FIX this spec, so > therefore this spec can go take a permanent visit to Davy > Jones locker. > > Cheers, > -Polar >