Issue 2638: Outgoing local port in Bi-directional IIOP (firewall-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: In ptc/98-10-11 5.8.1 it says "If a client has not set up any mechanism for traditional-style callbacks using a listening socket, then the port entry in its IOR must be set to the outgoing connection"s local port (as retrieved using the getsockname() sockets API call)". At IOR creation time there may be no connection, or there may be many, so the mandated local port may be non-existent or ambiguous. This topic was discussed on the firewall-rtf list during Feb-Mar 1999 but was not raised as an issue. Resolution: Revised Text: Actions taken: May 6, 1999: received issue Discussion: End of Annotations:===== Date: Thu, 06 May 1999 10:20:33 +0100 From: Owen Rees To: OMG Issues cc: OMG Firewall RTF , OMG interop RTF Subject: Outgoing local port in Bi-directional IIOP Originator-Info: login-id=ore; server=ews.hpl.hp.com Content-Disposition: inline In ptc/98-10-11 5.8.1 it says "If a client has not set up any mechanism for traditional-style callbacks using a listening socket, then the port entry in its IOR must be set to the outgoing connection's local port (as retrieved using the getsockname() sockets API call)". At IOR creation time there may be no connection, or there may be many, so the mandated local port may be non-existent or ambiguous. This topic was discussed on the firewall-rtf list during Feb-Mar 1999 but was not raised as an issue. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Sender: jon@floorboard.com Date: Thu, 06 May 1999 08:09:28 -0700 From: Jonathan Biggar X-Accept-Language: en To: Owen Rees CC: OMG Firewall RTF , OMG interop RTF Subject: Re: Outgoing local port in Bi-directional IIOP References: <2568064781.925986033@ews-proj-2.hpl.hp.com> Owen Rees wrote: > > In ptc/98-10-11 5.8.1 it says "If a client has not set up any > mechanism for > traditional-style callbacks using a listening socket, then the port > entry > in its IOR must be set to the outgoing connection's local port (as > retrieved using the getsockname() sockets API call)". At IOR > creation time > there may be no connection, or there may be many, so the mandated > local > port may be non-existent or ambiguous. > > This topic was discussed on the firewall-rtf list during Feb-Mar > 1999 but > was not raised as an issue. I don't see this as a specification problem. It is simply up to the implementation to make sure that it has a port number to use before the first IOR is generated. For the typical UNIX sockets implementation, you can create a socket and call listen() without bind() in order to generate a random port number. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 06 May 1999 16:52:36 +0100 From: Owen Rees To: Jonathan Biggar , Owen Rees cc: OMG Firewall RTF , OMG interop RTF Subject: Re: Outgoing local port in Bi-directional IIOP Originator-Info: login-id=ore; server=ews.hpl.hp.com Content-Disposition: inline --On 06 May 1999, 08:09 -0700 Jonathan Biggar wrote: > Owen Rees wrote: >> >> In ptc/98-10-11 5.8.1 it says "If a client has not set up any >> mechanism >> for traditional-style callbacks using a listening socket, then the >> port >> entry in its IOR must be set to the outgoing connection's local >> port (as >> retrieved using the getsockname() sockets API call)". At IOR >> creation >> time there may be no connection, or there may be many, so the >> mandated >> local port may be non-existent or ambiguous. >> >> This topic was discussed on the firewall-rtf list during Feb-Mar >> 1999 but >> was not raised as an issue. > > I don't see this as a specification problem. It is simply up to the > implementation to make sure that it has a port number to use before >> the > first IOR is generated. For the typical UNIX sockets >> implementation, > you can create a socket and call listen() without bind() in order to > generate a random port number. Such an implementation would be in violation of the specification as written - note the use of 'must' in the quoted text. It could be converted to an implementation issue by changing 'must' to 'may', but I would prefer a replacement paragraph that said what was needed (a port value that is and will remain unambiguous), rather than suggesting a particular implementation. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Sender: jon@floorboard.com Date: Thu, 06 May 1999 11:13:27 -0700 From: Jonathan Biggar X-Accept-Language: en To: Owen Rees CC: OMG Firewall RTF , OMG interop RTF Subject: Re: Outgoing local port in Bi-directional IIOP References: <2591587750.926009556@ews-proj-2.hpl.hp.com> Owen Rees wrote: > --On 06 May 1999, 08:09 -0700 Jonathan Biggar > wrote: > > Owen Rees wrote: > >> In ptc/98-10-11 5.8.1 it says "If a client has not set up any > mechanism > >> for traditional-style callbacks using a listening socket, then > the port > >> entry in its IOR must be set to the outgoing connection's local > port (as > >> retrieved using the getsockname() sockets API call)". At IOR > creation > >> time there may be no connection, or there may be many, so the > mandated > >> local port may be non-existent or ambiguous. > >> > >> This topic was discussed on the firewall-rtf list during Feb-Mar > 1999 but > >> was not raised as an issue. > > > > I don't see this as a specification problem. It is simply up to > the > > implementation to make sure that it has a port number to use > before the > > first IOR is generated. For the typical UNIX sockets > implementation, > > you can create a socket and call listen() without bind() in order > to > > generate a random port number. > > Such an implementation would be in violation of the specification as > written - note the use of 'must' in the quoted text. It could be > converted > to an implementation issue by changing 'must' to 'may', but I would > prefer > a replacement paragraph that said what was needed (a port value that > is and > will remain unambiguous), rather than suggesting a particular > implementation. I guess I wasn't clear. After the implementation generates a random port number using the process I described above, it then uses bind() to assign that port number to every outgoing connection that it creates so that it fullfills the requirements of the spec. This will also require the use of the SO_REUSEADDR socket option. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 07 May 1999 12:06:38 +0100 From: Owen Rees To: Jonathan Biggar , Owen Rees cc: OMG Firewall RTF , OMG interop RTF Subject: Re: Outgoing local port in Bi-directional IIOP Originator-Info: login-id=ore; server=ews.hpl.hp.com Content-Disposition: inline --On 06 May 1999, 11:13 -0700 Jonathan Biggar wrote: > Owen Rees wrote: >> --On 06 May 1999, 08:09 -0700 Jonathan Biggar >> wrote: >> > Owen Rees wrote: >> >> In ptc/98-10-11 5.8.1 it says "If a client has not set up any >> >> mechanism for traditional-style callbacks using a listening >> socket, >> >> then the port entry in its IOR must be set to the outgoing >> >> connection's local port (as retrieved using the getsockname() >> sockets >> >> API call)". At IOR creation time there may be no connection, or >> there >> >> may be many, so the mandated local port may be non-existent or >> >> ambiguous. >> >> >> >> This topic was discussed on the firewall-rtf list during Feb-Mar >> 1999 >> >> but was not raised as an issue. >> > >> > I don't see this as a specification problem. It is simply up to >> the >> > implementation to make sure that it has a port number to use >> before the >> > first IOR is generated. For the typical UNIX sockets >> implementation, >> > you can create a socket and call listen() without bind() in order >> to >> > generate a random port number. >> >> Such an implementation would be in violation of the specification >> as >> written - note the use of 'must' in the quoted text. It could be >> converted to an implementation issue by changing 'must' to 'may', >> but I >> would prefer a replacement paragraph that said what was needed (a >> port >> value that is and will remain unambiguous), rather than suggesting >> a >> particular >> implementation. > > I guess I wasn't clear. After the implementation generates a random > port number using the process I described above, it then uses bind() >> to > assign that port number to every outgoing connection that it creates >> so > that it fullfills the requirements of the spec. This will also >> require > the use of the SO_REUSEADDR socket option. Well, I suppose that you have not "set up any mechanism for traditional-style callbacks" although you are "using a listening socket" so the spec can be interpreted to permit this strategy. That still leaves the question of which port to use when there are already two or more outgoing connections open. Is this strategy going to work for Java applets? The obvious Java call to create a listening socket on a system chosen port throws a security exception under MSIE4. Perhaps someone who understands the Java applet security issues could comment on this? I am still not happy about the spec mandating implementation at that level of detail, rather that stating the requirement, and perhaps suggesting an implementation. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Date: Mon, 10 May 1999 08:49:42 -0400 From: Paul H Kyzivat Organization: NobleNet To: Owen Rees CC: Jonathan Biggar , OMG Firewall RTF , OMG interop RTF Subject: Re: Outgoing local port in Bi-directional IIOP References: <2660829485.926078798@ews-proj-2.hpl.hp.com> I agree with Owen that it is inappropriate for the spec to so tightly specify the implementation when there is no obvious purpose in doing so. Paul Owen Rees wrote: > > --On 06 May 1999, 11:13 -0700 Jonathan Biggar > wrote: > > > Owen Rees wrote: > >> --On 06 May 1999, 08:09 -0700 Jonathan Biggar > > wrote: > >> > Owen Rees wrote: > >> >> In ptc/98-10-11 5.8.1 it says "If a client has not set up any > >> >> mechanism for traditional-style callbacks using a listening > socket, > >> >> then the port entry in its IOR must be set to the outgoing > >> >> connection's local port (as retrieved using the getsockname() > sockets > >> >> API call)". At IOR creation time there may be no connection, > or > there > >> >> may be many, so the mandated local port may be non-existent or > >> >> ambiguous. > >> >> > >> >> This topic was discussed on the firewall-rtf list during > Feb-Mar > 1999 > >> >> but was not raised as an issue. > >> > > >> > I don't see this as a specification problem. It is simply up > to > the > >> > implementation to make sure that it has a port number to use > before the > >> > first IOR is generated. For the typical UNIX sockets > implementation, > >> > you can create a socket and call listen() without bind() in > order > to > >> > generate a random port number. > >> > >> Such an implementation would be in violation of the specification > as > >> written - note the use of 'must' in the quoted text. It could be > >> converted to an implementation issue by changing 'must' to 'may', > but I > >> would prefer a replacement paragraph that said what was needed (a > port > >> value that is and will remain unambiguous), rather than > suggesting > a > >> particular > >> implementation. > > > > I guess I wasn't clear. After the implementation generates a > random > > port number using the process I described above, it then uses > bind() > to > > assign that port number to every outgoing connection that it > creates > so > > that it fullfills the requirements of the spec. This will also > require > > the use of the SO_REUSEADDR socket option. > > Well, I suppose that you have not "set up any mechanism for > traditional-style callbacks" although you are "using a listening > socket" so > the spec can be interpreted to permit this strategy. That still > leaves > the > question of which port to use when there are already two or more > outgoing > connections open. > > Is this strategy going to work for Java applets? The obvious Java > call > to > create a listening socket on a system chosen port throws a security > exception under MSIE4. Perhaps someone who understands the Java > applet > security issues could comment on this? > > I am still not happy about the spec mandating implementation at that > level > of detail, rather that stating the requirement, and perhaps > suggesting > an > implementation. > > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 From: "Martin Chapman" To: "Owen Rees" , "Jonathan Biggar" Cc: "OMG Firewall RTF" , "OMG interop RTF" Subject: RE: Outgoing local port in Bi-directional IIOP Date: Mon, 10 May 1999 17:41:35 +0100 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 > -----Original Message----- > From: Owen Rees [mailto:Owen_Rees@hplb.hpl.hp.com] > Sent: 07 May 1999 12:07 > To: Jonathan Biggar; Owen Rees > Cc: OMG Firewall RTF; OMG interop RTF > Subject: Re: Outgoing local port in Bi-directional IIOP > > > --On 06 May 1999, 11:13 -0700 Jonathan Biggar > wrote: > > > Owen Rees wrote: > >> --On 06 May 1999, 08:09 -0700 Jonathan Biggar > wrote: > >> > Owen Rees wrote: > >> >> In ptc/98-10-11 5.8.1 it says "If a client has not set up any > >> >> mechanism for traditional-style callbacks using a listening > socket, > >> >> then the port entry in its IOR must be set to the outgoing > >> >> connection's local port (as retrieved using the > getsockname() sockets > >> >> API call)". At IOR creation time there may be no > connection, or there > >> >> may be many, so the mandated local port may be non-existent or > >> >> ambiguous. > >> >> > >> >> This topic was discussed on the firewall-rtf list during > Feb-Mar 1999 > >> >> but was not raised as an issue. > >> > > >> > I don't see this as a specification problem. It is simply up > to the > >> > implementation to make sure that it has a port number to use > before the > >> > first IOR is generated. For the typical UNIX sockets > implementation, > >> > you can create a socket and call listen() without bind() in > order to > >> > generate a random port number. > >> > >> Such an implementation would be in violation of the specification > as > >> written - note the use of 'must' in the quoted text. It could be > >> converted to an implementation issue by changing 'must' to 'may', > but I > >> would prefer a replacement paragraph that said what was needed (a > port > >> value that is and will remain unambiguous), rather than > suggesting a > >> particular > >> implementation. > > > > I guess I wasn't clear. After the implementation generates a > random > > port number using the process I described above, it then uses > bind() to > > assign that port number to every outgoing connection that it > creates so > > that it fullfills the requirements of the spec. This will also > require > > the use of the SO_REUSEADDR socket option. > > Well, I suppose that you have not "set up any mechanism for > traditional-style callbacks" although you are "using a listening > socket" so > the spec can be interpreted to permit this strategy. That still > leaves the > question of which port to use when there are already two or more > outgoing > connections open. > > Is this strategy going to work for Java applets? The obvious Java > call to > create a listening socket on a system chosen port throws a security > exception under MSIE4. Perhaps someone who understands the Java > applet > security issues could comment on this? > > I am still not happy about the spec mandating implementation at that > level > of detail, rather that stating the requirement, and perhaps > suggesting an > implementation. I agree with you - i does sound to restrictive on the implementation. However I'm not an applet expert so there may have been a reason foir this. Any experts out there? From: Paul Kyzivat To: "'mchapman@iona.com'" , firewall-rtf@omg.org Subject: RE: Vote 2. Date: Thu, 9 Dec 1999 20:38:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 9H8!!a08!!L>Ie960H!! Rogue Wave votes as follows: ABSTAIN on the following: Issue 2638: Outgoing local port in Bi-directional IIOP Issue 2639: Firewall POA Policy does not control access Issue 2648: new_target Issue 2651: new_callback Issue 2865: Proxified object references Issue 2866: Reusing PASSTHRU NO on Issue 2638. I don't think it quite says what needs to be said. I suggest the following replacement text: "If a client has not set up any mechanism for traditional-style callbacks using a listening socket (such as in a browser), the ORB shall select an address to designate the client in IORs, and include this address in the BI_DIR_IIOP structure. For as long as IORs including this address remain valid, the ORB shall ensure that this address cannot be used to accept connections." (Both the original text and the replacement text seemed to imply that the address of the client's end of an outgoing connection is suitable for this use. In general that is a bad assumption. Perhaps it would work if the address of the connection that is to be used for callbacks is used, but it is likely that that address will not be known at the time the reference is created. It can be left up to the ORB to do the right thing, but we need to make clear what the right thing is.) Date: Fri, 10 Dec 1999 14:18:06 +0000 From: Owen Rees To: Paul Kyzivat , "'mchapman@iona.com'" , firewall-rtf@omg.org Subject: RE: Vote 2. - issue 2638 Message-ID: <4237648879.944835486@ews-proj-2.hpl.hp.com> In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA9140234@bos1.noblenet.com> Originator-Info: login-id=ore; server=ticb.hpl.hp.com X-Mailer: Mulberry (Win32) [1.4.3, s/n P005-300802-001] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 9mm!!S0#!![^[!!cYR!! --On 09 December 1999, 20:38 -0500 Paul Kyzivat wrote: > NO on Issue 2638. I don't think it quite says what needs to be said. > I suggest the following replacement text: > > "If a client has not set up any mechanism for traditional-style > callbacks > using a listening socket (such as in a browser), the ORB shall > select an > address to designate the client in IORs, and include this address in > the > BI_DIR_IIOP structure. For as long as IORs including this address > remain > valid, the ORB shall ensure that this address cannot be used to > accept > connections." This is better, but seems to imply that the ORB (in a browser) can control what addresses can be used to accept connections. I think the emphasis has to be on the ORB choosing an address over which it has enough control. Perhaps replace the last sentence - "For as long ..." with: "The ORB must select an address that will not be used (in particular will not be used by some other ORB) for as long as the IORs including that address remain valid." > > (Both the original text and the replacement text seemed to imply > that the > address of the client's end of an outgoing connection is suitable > for this > use. In general that is a bad assumption. Perhaps it would work if > the > address of the connection that is to be used for callbacks is used, > but it > is likely that that address will not be known at the time the > reference is > created. It can be left up to the ORB to do the right thing, but we > need > to make clear what the right thing is.) The key point is "likely that that address will not be known at the time". I see no difficulty in creating an applet that will eventually retrieve a stringified IOR for the server using HTTP, but which creates an object to be used for callback before doing anything else. In this case the ORB has no way to guess which server will eventually be invoked. If the applet choses to stringify the reference to its callback object, the opportunity to defer filling in the address ends. There is a special case where there is one connection already open and this has been done before the reference has to be completely defined, but the specification must cover the other cases too. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 From: Paul Kyzivat To: "'Owen Rees'" , Paul Kyzivat , "'mchapman@iona.com'" , firewall-rtf@omg.org Subject: RE: Vote 2. - issue 2638 Date: Fri, 10 Dec 1999 13:12:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 2k)e9j[]!!bYZ!!@WR!! Owen, I agree with our revisions and comments. Further, there are other scenarios where the special case that Martin favors doesn't work. Suppose a connection to some server has been established at the time the callback object is created, and the orb decides to use the address from that connection as its callback address. If the "client" then loses interest in that server, drops the connection to it, and then establishes a connection to some other server, the old address may well have been released, and could be picked up and used by some other server. If the original callback ior, with the old address, is then sent to the new server, there can be considerable confusion. To prevent this, the orb must ensure that the connection it has used to obtain an address is not released even if it is no longer needed for any other purpose. Paul > -----Original Message----- > From: Owen Rees [mailto:owen_rees@hp.com] > Sent: Friday, December 10, 1999 9:18 AM > To: Paul Kyzivat; 'mchapman@iona.com'; firewall-rtf@omg.org > Subject: RE: Vote 2. - issue 2638 > > > --On 09 December 1999, 20:38 -0500 Paul Kyzivat > wrote: > > > NO on Issue 2638. I don't think it quite says what needs to be > said. > > I suggest the following replacement text: > > > > "If a client has not set up any mechanism for > traditional-style callbacks > > using a listening socket (such as in a browser), the ORB > shall select an > > address to designate the client in IORs, and include this > address in the > > BI_DIR_IIOP structure. For as long as IORs including this > address remain > > valid, the ORB shall ensure that this address cannot be > used to accept > > connections." > > This is better, but seems to imply that the ORB (in a > browser) can control > what addresses can be used to accept connections. I think the > emphasis has > to be on the ORB choosing an address over which it has enough > control. > Perhaps replace the last sentence - "For as long ..." with: > > "The ORB must select an address that will not be used (in > particular will > not be used by some other ORB) for as long as the IORs including > that > address remain valid." > > > > > (Both the original text and the replacement text seemed to > imply that the > > address of the client's end of an outgoing connection is > suitable for this > > use. In general that is a bad assumption. Perhaps it would > work if the > > address of the connection that is to be used for callbacks > is used, but it > > is likely that that address will not be known at the time > the reference is > > created. It can be left up to the ORB to do the right > thing, but we need > > to make clear what the right thing is.) > > The key point is "likely that that address will not be known > at the time". > I see no difficulty in creating an applet that will > eventually retrieve a > stringified IOR for the server using HTTP, but which creates > an object to > be used for callback before doing anything else. In this case > the ORB has > no way to guess which server will eventually be invoked. If the > applet > choses to stringify the reference to its callback object, the > opportunity > to defer filling in the address ends. > > There is a special case where there is one connection already > open and this > has been done before the reference has to be completely > defined, but the > specification must cover the other cases too. > > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 > From: Paul Kyzivat To: "'Owen Rees'" , Paul Kyzivat > , "'mchapman@iona.com'" , firewall-rtf@omg.org Subject: RE: Vote 2. - issue 2638 Date: Fri, 10 Dec 1999 13:12:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ;3pd9VHj!!<(L!!_c1!! Owen, I agree with our revisions and comments. Further, there are other scenarios where the special case that Martin favors doesn't work. Suppose a connection to some server has been established at the time the callback object is created, and the orb decides to use the address from that connection as its callback address. If the "client" then loses interest in that server, drops the connection to it, and then establishes a connection to some other server, the old address may well have been released, and could be picked up and used by some other server. If the original callback ior, with the old address, is then sent to the new server, there can be considerable confusion. To prevent this, the orb must ensure that the connection it has used to obtain an address is not released even if it is no longer needed for any other purpose. Paul > -----Original Message----- > From: Owen Rees [mailto:owen_rees@hp.com] > Sent: Friday, December 10, 1999 9:18 AM > To: Paul Kyzivat; 'mchapman@iona.com'; firewall-rtf@omg.org > Subject: RE: Vote 2. - issue 2638 > > > --On 09 December 1999, 20:38 -0500 Paul Kyzivat > wrote: > > > NO on Issue 2638. I don't think it quite says what needs to be > said. > > I suggest the following replacement text: > > > > "If a client has not set up any mechanism for > traditional-style callbacks > > using a listening socket (such as in a browser), the ORB > shall select an > > address to designate the client in IORs, and include this > address in the > > BI_DIR_IIOP structure. For as long as IORs including this > address remain > > valid, the ORB shall ensure that this address cannot be > used to accept > > connections." > > This is better, but seems to imply that the ORB (in a > browser) can control > what addresses can be used to accept connections. I think the > emphasis has > to be on the ORB choosing an address over which it has enough > control. > Perhaps replace the last sentence - "For as long ..." with: > > "The ORB must select an address that will not be used (in > particular will > not be used by some other ORB) for as long as the IORs including > that > address remain valid." > > > > > (Both the original text and the replacement text seemed to > imply that the > > address of the client's end of an outgoing connection is > suitable for this > > use. In general that is a bad assumption. Perhaps it would > work if the > > address of the connection that is to be used for callbacks > is used, but it > > is likely that that address will not be known at the time > the reference is > > created. It can be left up to the ORB to do the right > thing, but we need > > to make clear what the right thing is.) > > The key point is "likely that that address will not be known > at the time". > I see no difficulty in creating an applet that will > eventually retrieve a > stringified IOR for the server using HTTP, but which creates > an object to > be used for callback before doing anything else. In this case > the ORB has > no way to guess which server will eventually be invoked. If the > applet > choses to stringify the reference to its callback object, the > opportunity > to defer filling in the address ends. > > There is a special case where there is one connection already > open and this > has been done before the reference has to be completely > defined, but the > specification must cover the other cases too. > > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 > Reply-To: From: "Martin Chapman" To: "Paul Kyzivat" , "'Owen Rees'" > , Subject: RE: Vote 2. - issue 2638 Date: Tue, 14 Dec 1999 10:02:48 -0000 Message-ID: <000801bf461a$601ef9c0$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA9140239@bos1.noblenet.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: @l=e9;NJe9I-5!!SF$!! First I want to say that allocation of ports is a very implementation specific activity. The corba spec does not tell you what ports to setup, when, when to deallocate them, when to set connections, how long to keep them up, etc etc. The spec can't prevent a vendor doing screwy things (unless is specifies absolutely everything, which is not the OMG way, like it or not. Secondly, we are running out of time on this round of the RTF. For this issue,and others, ask yourselves - is it better than the original text? Sometimes it's better to make small steps than solve the whole thing in one go. New issues can be raised which will be considerd in the next RTF. If we can't resolve or vote down issues we are left with the original text that will be formally published next year. Obvioulsy you the voters decide this, I'm merely advising. Martin. > -----Original Message----- > From: Paul Kyzivat [mailto:paulk@roguewave.com] > Sent: 10 December 1999 18:12 > To: 'Owen Rees'; Paul Kyzivat; 'mchapman@iona.com'; > firewall-rtf@omg.org > Subject: RE: Vote 2. - issue 2638 > > > Owen, I agree with our revisions and comments. > > Further, there are other scenarios where the special case that > Martin favors > doesn't work. > > Suppose a connection to some server has been established at the time > the > callback object is created, and the orb decides to use the > address from that > connection as its callback address. If the "client" then loses > interest in > that server, drops the connection to it, and then establishes a > connection > to some other server, the old address may well have been > released, and could > be picked up and used by some other server. If the original callback > ior, > with the old address, is then sent to the new server, there can be > considerable confusion. > > To prevent this, the orb must ensure that the connection it has used > to > obtain an address is not released even if it is no longer needed for > any > other purpose. > > Paul > > > -----Original Message----- > > From: Owen Rees [mailto:owen_rees@hp.com] > > Sent: Friday, December 10, 1999 9:18 AM > > To: Paul Kyzivat; 'mchapman@iona.com'; firewall-rtf@omg.org > > Subject: RE: Vote 2. - issue 2638 > > > > > > --On 09 December 1999, 20:38 -0500 Paul Kyzivat > > wrote: > > > > > NO on Issue 2638. I don't think it quite says what needs to be > said. > > > I suggest the following replacement text: > > > > > > "If a client has not set up any mechanism for > > traditional-style callbacks > > > using a listening socket (such as in a browser), the ORB > > shall select an > > > address to designate the client in IORs, and include this > > address in the > > > BI_DIR_IIOP structure. For as long as IORs including this > > address remain > > > valid, the ORB shall ensure that this address cannot be > > used to accept > > > connections." > > > > This is better, but seems to imply that the ORB (in a > > browser) can control > > what addresses can be used to accept connections. I think the > > emphasis has > > to be on the ORB choosing an address over which it has enough > control. > > Perhaps replace the last sentence - "For as long ..." with: > > > > "The ORB must select an address that will not be used (in > > particular will > > not be used by some other ORB) for as long as the IORs including > that > > address remain valid." > > > > > > > > (Both the original text and the replacement text seemed to > > imply that the > > > address of the client's end of an outgoing connection is > > suitable for this > > > use. In general that is a bad assumption. Perhaps it would > > work if the > > > address of the connection that is to be used for callbacks > > is used, but it > > > is likely that that address will not be known at the time > > the reference is > > > created. It can be left up to the ORB to do the right > > thing, but we need > > > to make clear what the right thing is.) > > > > The key point is "likely that that address will not be known > > at the time". > > I see no difficulty in creating an applet that will > > eventually retrieve a > > stringified IOR for the server using HTTP, but which creates > > an object to > > be used for callback before doing anything else. In this case > > the ORB has > > no way to guess which server will eventually be invoked. If the > applet > > choses to stringify the reference to its callback object, the > > opportunity > > to defer filling in the address ends. > > > > There is a special case where there is one connection already > > open and this > > has been done before the reference has to be completely > > defined, but the > > specification must cover the other cases too. > > > > Regards, > > Owen Rees > > Hewlett Packard Laboratories, Bristol, UK > > tel: +44 117 312 9439 fax: +44 117 312 9285 > > > Date: Tue, 14 Dec 1999 11:19:45 +0000 From: Owen Rees To: mchapman@iona.com, Paul Kyzivat , firewall-rtf@omg.org Subject: RE: Vote 2. - issue 2638 Message-ID: <277580528.945170385@rees-o-home-1.hpl.hp.com> In-Reply-To: <000801bf461a$601ef9c0$4d01020a@leo.dublin.iona.ie> X-Mailer: Mulberry (Win32) [2.0.0b4, s/n P005-300802-002] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: oWa!!RS4!!c-7!!/j4!! --On 14 December 1999 10:02 +0000 Martin Chapman wrote: > First I want to say that allocation of ports is a very implementation > specific activity. The corba spec does not tell you what ports to setup, > when, when to deallocate them, when to set connections, how long to keep > them up, etc etc. The spec can't prevent a vendor doing screwy things > (unless is specifies absolutely everything, which is not the OMG way, like > it or not. > > Secondly, we are running out of time on this round of the RTF. For this > issue,and others, ask yourselves - is it better than the original text? > Sometimes it's better to make small steps than solve the whole thing in > one go. New issues can be raised which will be considerd in the next RTF. > If we can't resolve or vote down issues we are left with the original > text that will be formally published next year. Obvioulsy you the voters > decide this, I'm merely advising. > > Martin. > In that context consider the intent if the resolution: > Resolution: Revise text to ensure it does not mandate a solution. and the proposed replacement text: > with: "It is the ORB's resposibility to ensure that an IOR contains an > approprite address. For an object that is being used as a callback in an > environment where incomming connections are not permitted (such as in a > browser), and hence bi-directional GIOP is the only way to invoke the > object, the ORB must ensure that the IOR contains a valid address of an > outgoing connection on which bi-directional communication may take place > (as retireved using getsockname() sockets API call, for example). > The second sentence onwards is mandating a specific implementation and telling you what port may be used. If this is not the OMG way, that should be deleted from the revised text for that reason, leaving: > with: "It is the ORB's resposibility to ensure that an IOR contains an > approprite address. This is obviously always true for all IORs and does not need stating so should also be deleted. This leaves no replacement text. I would be happy with a resolution that just deletes the text that was to be replaced (i.e. that starts "If a client has not ..."). This would leave vendors free to do whatever they like within the constraints imposed by the rest of CORBA. As far as I am concerned, the replacement text that Paul and I seemed to be agreed on was just pointing out the consequences of other constraints (in particular, that object references must be unambiguous). Given the nature of the questions I see asked about CORBA, I would have thought that it would be helpful to have the consequences explained, but it is not necessary. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Reply-To: From: "Martin Chapman" To: "Owen Rees" , "Paul Kyzivat" , Subject: RE: Vote 2. - issue 2638 Date: Tue, 14 Dec 1999 12:06:46 -0000 Message-ID: <001201bf462b$b1c85ee0$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <277580528.945170385@rees-o-home-1.hpl.hp.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: %! -----Original Message----- > From: Owen Rees [mailto:owen_rees@hp.com] > Sent: 14 December 1999 11:20 > To: mchapman@iona.com; Paul Kyzivat; firewall-rtf@omg.org > Subject: RE: Vote 2. - issue 2638 > > > --On 14 December 1999 10:02 +0000 Martin Chapman > wrote: > > > First I want to say that allocation of ports is a very > implementation > > specific activity. The corba spec does not tell you what ports to > setup, > > when, when to deallocate them, when to set connections, how long > to keep > > them up, etc etc. The spec can't prevent a vendor doing screwy > things > > (unless is specifies absolutely everything, which is not the > OMG way, like > > it or not. > > > > Secondly, we are running out of time on this round of the RTF. For > this > > issue,and others, ask yourselves - is it better than the original > text? > > Sometimes it's better to make small steps than solve the whole > thing in > > one go. New issues can be raised which will be considerd in the > next RTF. > > If we can't resolve or vote down issues we are left with the > original > > text that will be formally published next year. Obvioulsy you the > voters > > decide this, I'm merely advising. > > > > Martin. > > > > In that context consider the intent if the resolution: > > > Resolution: Revise text to ensure it does not mandate a solution. > > and the proposed replacement text: > > > with: "It is the ORB's resposibility to ensure that an IOR > contains an > > approprite address. For an object that is being used as a callback > in an > > environment where incomming connections are not permitted (such as > in a > > browser), and hence bi-directional GIOP is the only way to invoke > the > > object, the ORB must ensure that the IOR contains a valid address > of an > > outgoing connection on which bi-directional communication may take > place > > (as retireved using getsockname() sockets API call, for example). > > > > The second sentence onwards is mandating a specific implementation > and > telling you what port may be used. If this is not the OMG way, that > should > be deleted from the revised text for that reason, leaving: > > > with: "It is the ORB's resposibility to ensure that an IOR > contains an > > approprite address. > > This is obviously always true for all IORs and does not need stating > so > should also be deleted. This leaves no replacement text. > > I would be happy with a resolution that just deletes the text that > was to > be replaced (i.e. that starts "If a client has not ..."). This would > leave > vendors free to do whatever they like within the constraints > imposed by the > rest of CORBA. > > As far as I am concerned, the replacement text that Paul and I > seemed to be > agreed on was just pointing out the consequences of other > constraints (in > particular, that object references must be unambiguous). Given the > nature > of the questions I see asked about CORBA, I would have thought that > it > would be helpful to have the consequences explained, but it is not > necessary. > > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 > From: Paul Kyzivat To: "'mchapman@iona.com'" , Paul Kyzivat , "'Owen Rees'" , firewall-rtf@omg.org Subject: RE: Vote 2. - issue 2638 Date: Tue, 14 Dec 1999 12:06:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Q>Je9)/"!!hD""!!XHe9 Martin, This issue was raised *long* ago. (February I think.) The FTF date was extended once without addressing the issue. Now you want to hastily close the issue, in a way consistent with what your orb implements, even though there appear to be valid issues with that approach. This doesn't seem appropriate to me. I agree that allocation of ports is very implementation dependent, and we don't want to mandate something overly constraining. The ORB should have considerable discression in how to manage ports. But it doesn't have total freedom. For instance, it can't assign ports in a way that results in two distinct servers creating exactly the same IOR. The objects for the two servers must be distinguished in some way, by address, port, or poa name. With bidir we are backed into a corner because of the semantics as they are currently defined. The IORs that the "client" uses must have some sort of unique identification in them that permits them to be associated with a connection via a BiDir service context. Since we are using a TCP/IP port as that unique identification, and since the orb assigns that, it is the responsibility of the orb to ensure that what it supplies is in fact unique. Of course some orbs probably won't fulfill this responsibility. But the spec should be written in a way that this is clearly non-conformant. Perhaps an important use case (e.g. a browser) cannot be implemented in a way that meets this requirement. If so, then we need to make a bigger change that solves the problem in another way. Paul > -----Original Message----- > From: Martin Chapman [mailto:mchapman@iona.com] > Sent: Tuesday, December 14, 1999 5:03 AM > To: Paul Kyzivat; 'Owen Rees'; firewall-rtf@omg.org > Subject: RE: Vote 2. - issue 2638 > > > First I want to say that allocation of ports is a very > implementation > specific activity. The corba spec does not tell you what > ports to setup, > when, when to deallocate them, when to set connections, how > long to keep > them up, etc etc. The spec can't prevent a vendor doing screwy > things > (unless is specifies absolutely everything, which is not the > OMG way, like > it or not. > > Secondly, we are running out of time on this round of the > RTF. For this > issue,and others, ask yourselves - is it better than the > original text? > Sometimes it's better to make small steps than solve the > whole thing in one > go. New issues can be raised which will be considerd in the > next RTF. If we > can't resolve or vote down issues we are left with the > original text that > will be formally published next year. Obvioulsy you the > voters decide this, > I'm merely advising. > > Martin. > > > -----Original Message----- > > From: Paul Kyzivat [mailto:paulk@roguewave.com] > > Sent: 10 December 1999 18:12 > > To: 'Owen Rees'; Paul Kyzivat; 'mchapman@iona.com'; > firewall-rtf@omg.org > > Subject: RE: Vote 2. - issue 2638 > > > > > > Owen, I agree with our revisions and comments. > > > > Further, there are other scenarios where the special case that > > Martin favors > > doesn't work. > > > > Suppose a connection to some server has been established at > the time the > > callback object is created, and the orb decides to use the > > address from that > > connection as its callback address. If the "client" then > loses interest in > > that server, drops the connection to it, and then > establishes a connection > > to some other server, the old address may well have been > > released, and could > > be picked up and used by some other server. If the original > callback ior, > > with the old address, is then sent to the new server, there can be > > considerable confusion. > > > > To prevent this, the orb must ensure that the connection it > has used to > > obtain an address is not released even if it is no longer > needed for any > > other purpose. > > > > Paul > > > > > -----Original Message----- > > > From: Owen Rees [mailto:owen_rees@hp.com] > > > Sent: Friday, December 10, 1999 9:18 AM > > > To: Paul Kyzivat; 'mchapman@iona.com'; firewall-rtf@omg.org > > > Subject: RE: Vote 2. - issue 2638 > > > > > > > > > --On 09 December 1999, 20:38 -0500 Paul Kyzivat > > > wrote: > > > > > > > NO on Issue 2638. I don't think it quite says what > needs to be said. > > > > I suggest the following replacement text: > > > > > > > > "If a client has not set up any mechanism for > > > traditional-style callbacks > > > > using a listening socket (such as in a browser), the ORB > > > shall select an > > > > address to designate the client in IORs, and include this > > > address in the > > > > BI_DIR_IIOP structure. For as long as IORs including this > > > address remain > > > > valid, the ORB shall ensure that this address cannot be > > > used to accept > > > > connections." > > > > > > This is better, but seems to imply that the ORB (in a > > > browser) can control > > > what addresses can be used to accept connections. I think the > > > emphasis has > > > to be on the ORB choosing an address over which it has > enough control. > > > Perhaps replace the last sentence - "For as long ..." with: > > > > > > "The ORB must select an address that will not be used (in > > > particular will > > > not be used by some other ORB) for as long as the IORs > including that > > > address remain valid." > > > > > > > > > > > (Both the original text and the replacement text seemed to > > > imply that the > > > > address of the client's end of an outgoing connection is > > > suitable for this > > > > use. In general that is a bad assumption. Perhaps it would > > > work if the > > > > address of the connection that is to be used for callbacks > > > is used, but it > > > > is likely that that address will not be known at the time > > > the reference is > > > > created. It can be left up to the ORB to do the right > > > thing, but we need > > > > to make clear what the right thing is.) > > > > > > The key point is "likely that that address will not be known > > > at the time". > > > I see no difficulty in creating an applet that will > > > eventually retrieve a > > > stringified IOR for the server using HTTP, but which creates > > > an object to > > > be used for callback before doing anything else. In this case > > > the ORB has > > > no way to guess which server will eventually be invoked. > If the applet > > > choses to stringify the reference to its callback object, the > > > opportunity > > > to defer filling in the address ends. > > > > > > There is a special case where there is one connection already > > > open and this > > > has been done before the reference has to be completely > > > defined, but the > > > specification must cover the other cases too. > > > > > > Regards, > > > Owen Rees > > > Hewlett Packard Laboratories, Bristol, UK > > > tel: +44 117 312 9439 fax: +44 117 312 9285 > > > > > > Reply-To: From: "Martin Chapman" To: "Paul Kyzivat" , "'Owen Rees'" > , Subject: RE: Vote 2. - issue 2638 Date: Wed, 15 Dec 1999 13:35:05 -0000 Message-ID: <000c01bf4701$321d8cc0$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA914024D@bos1.noblenet.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: N]H!!-TAe9EdAe9?a8e9 > -----Original Message----- > From: Paul Kyzivat [mailto:paulk@roguewave.com] > Sent: 14 December 1999 17:07 > To: 'mchapman@iona.com'; Paul Kyzivat; 'Owen Rees'; > firewall-rtf@omg.org > Subject: RE: Vote 2. - issue 2638 > > > Martin, > > This issue was raised *long* ago. (February I think.) > The FTF date was extended once without addressing the issue. > Now you want to hastily close the issue, in a way consistent with > what your > orb implements, even though there appear to be valid issues with > that > approach. This doesn't seem appropriate to me. I'm not trying to hastily close it. If we can't resolve it this time round it will still be open for the next rtf. As far as our implementation goes, the current text exactly matches what we do, so from a personal level I would be happy to close with no change. However as a chair I'm trying to be neutral, in order to get to something that we all agree on. > > I agree that allocation of ports is very implementation dependent, > and we > don't want to mandate something overly constraining. The ORB should > have > considerable discression in how to manage ports. But it doesn't have > total > freedom. For instance, it can't assign ports in a way that results > in two > distinct servers creating exactly the same IOR. The objects for the > two > servers must be distinguished in some way, by address, port, or poa > name. but this is true of all IORs, and nothing in the current spec goes to this level of detail. > > With bidir we are backed into a corner because of the semantics > as they are > currently defined. The IORs that the "client" uses must have some > sort of > unique identification in them that permits them to be associated > with a > connection via a BiDir service context. Since we are using a > TCP/IP port as > that unique identification, and since the orb assigns that, it is > the > responsibility of the orb to ensure that what it supplies is in > fact unique. Absolutely, so we need to express this requirement. > > Of course some orbs probably won't fulfill this responsibility. > But the spec > should be written in a way that this is clearly non-conformant. > > Perhaps an important use case (e.g. a browser) cannot be implemented > in a > way that meets this requirement. If so, then we need to make a > bigger change > that solves the problem in another way. > > Paul > > > -----Original Message----- > > From: Martin Chapman [mailto:mchapman@iona.com] > > Sent: Tuesday, December 14, 1999 5:03 AM > > To: Paul Kyzivat; 'Owen Rees'; firewall-rtf@omg.org > > Subject: RE: Vote 2. - issue 2638 > > > > > > First I want to say that allocation of ports is a very > implementation > > specific activity. The corba spec does not tell you what > > ports to setup, > > when, when to deallocate them, when to set connections, how > > long to keep > > them up, etc etc. The spec can't prevent a vendor doing screwy > things > > (unless is specifies absolutely everything, which is not the > > OMG way, like > > it or not. > > > > Secondly, we are running out of time on this round of the > > RTF. For this > > issue,and others, ask yourselves - is it better than the > > original text? > > Sometimes it's better to make small steps than solve the > > whole thing in one > > go. New issues can be raised which will be considerd in the > > next RTF. If we > > can't resolve or vote down issues we are left with the > > original text that > > will be formally published next year. Obvioulsy you the > > voters decide this, > > I'm merely advising. > > > > Martin. > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:paulk@roguewave.com] > > > Sent: 10 December 1999 18:12 > > > To: 'Owen Rees'; Paul Kyzivat; 'mchapman@iona.com'; > > firewall-rtf@omg.org > > > Subject: RE: Vote 2. - issue 2638 > > > > > > > > > Owen, I agree with our revisions and comments. > > > > > > Further, there are other scenarios where the special case that > > > Martin favors > > > doesn't work. > > > > > > Suppose a connection to some server has been established at > > the time the > > > callback object is created, and the orb decides to use the > > > address from that > > > connection as its callback address. If the "client" then > > loses interest in > > > that server, drops the connection to it, and then > > establishes a connection > > > to some other server, the old address may well have been > > > released, and could > > > be picked up and used by some other server. If the original > > callback ior, > > > with the old address, is then sent to the new server, there can > be > > > considerable confusion. > > > > > > To prevent this, the orb must ensure that the connection it > > has used to > > > obtain an address is not released even if it is no longer > > needed for any > > > other purpose. > > > > > > Paul > > > > > > > -----Original Message----- > > > > From: Owen Rees [mailto:owen_rees@hp.com] > > > > Sent: Friday, December 10, 1999 9:18 AM > > > > To: Paul Kyzivat; 'mchapman@iona.com'; firewall-rtf@omg.org > > > > Subject: RE: Vote 2. - issue 2638 > > > > > > > > > > > > --On 09 December 1999, 20:38 -0500 Paul Kyzivat > > > > wrote: > > > > > > > > > NO on Issue 2638. I don't think it quite says what > > needs to be said. > > > > > I suggest the following replacement text: > > > > > > > > > > "If a client has not set up any mechanism for > > > > traditional-style callbacks > > > > > using a listening socket (such as in a browser), the ORB > > > > shall select an > > > > > address to designate the client in IORs, and include this > > > > address in the > > > > > BI_DIR_IIOP structure. For as long as IORs including this > > > > address remain > > > > > valid, the ORB shall ensure that this address cannot be > > > > used to accept > > > > > connections." > > > > > > > > This is better, but seems to imply that the ORB (in a > > > > browser) can control > > > > what addresses can be used to accept connections. I think the > > > > emphasis has > > > > to be on the ORB choosing an address over which it has > > enough control. > > > > Perhaps replace the last sentence - "For as long ..." with: > > > > > > > > "The ORB must select an address that will not be used (in > > > > particular will > > > > not be used by some other ORB) for as long as the IORs > > including that > > > > address remain valid." > > > > > > > > > > > > > > (Both the original text and the replacement text seemed to > > > > imply that the > > > > > address of the client's end of an outgoing connection is > > > > suitable for this > > > > > use. In general that is a bad assumption. Perhaps it would > > > > work if the > > > > > address of the connection that is to be used for callbacks > > > > is used, but it > > > > > is likely that that address will not be known at the time > > > > the reference is > > > > > created. It can be left up to the ORB to do the right > > > > thing, but we need > > > > > to make clear what the right thing is.) > > > > > > > > The key point is "likely that that address will not be known > > > > at the time". > > > > I see no difficulty in creating an applet that will > > > > eventually retrieve a > > > > stringified IOR for the server using HTTP, but which creates > > > > an object to > > > > be used for callback before doing anything else. In this case > > > > the ORB has > > > > no way to guess which server will eventually be invoked. > > If the applet > > > > choses to stringify the reference to its callback object, the > > > > opportunity > > > > to defer filling in the address ends. > > > > > > > > There is a special case where there is one connection already > > > > open and this > > > > has been done before the reference has to be completely > > > > defined, but the > > > > specification must cover the other cases too. > > > > > > > > Regards, > > > > Owen Rees > > > > Hewlett Packard Laboratories, Bristol, UK > > > > tel: +44 117 312 9439 fax: +44 117 312 9285 > > > > > > > > > > From: Paul Kyzivat To: "'mchapman@iona.com'" , Paul Kyzivat , "'Owen Rees'" , firewall-rtf@omg.org Subject: RE: Vote 2. - issue 2638 Date: Wed, 15 Dec 1999 19:12:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: b2Yd9P2;!!=H3e9N5 From: Martin Chapman [mailto:mchapman@iona.com] > I'm not trying to hastily close it. If we can't resolve it > this time round it will still be open for the next rtf. > As far as our implementation goes, the current text exactly > matches what we do, so from a personal level I would be happy > to close with no change. I finally understand this. But, based on scenarios raised both by Owen and me, it appears that your approach cannot work in general. Hence I don't want to see it in the spec, either as normative behavior or as an example. I could be talked out of this if you could explain to me how it is not broken. Consider the following scenario: - client creates POA - client creates callback object in the POA - client obtains an object reference to a server - client stores own callback object deep in some complex structure - client sends request to server containing this structure - orb establishes connection to server, sends bidir context in request - server calls back on the connection At the time the callback object reference is created, there is no outgoing connection. There isn't even an indication that an outbound tcp/ip connection will ever be needed. (This will depend on what IORs are used and the profiles they contain.) For your approach to work, the orb apparently must assign a port no later than the time when the first object reference is created, or else defer it for lazy evaluation the first time it is marshalled. Continuing: - client is done with this server, releases all object references - client does other things with lots of other servers using lots of connections - the orb sends the bidir service context on each new connection, referencing the address selected earlier - because of demand for connections, or for whatever reason, orb drops the connection to the first server - orb may close the socket bound to the address it is using freeing it for use by some other program on the same host. - another program is assigned the port our client is using in its IORs. It also starts handing out IORs with this address. - some server gets an ior with the original address in it and sends a request bidirectionally to our client. It may be from our client, or it may be from the other program. To prevent this, the client orb must not close the original socket until it is sure the there will be no valid callbacks. At the least, it must not do so while it holds connections on which it has sent the bidir context. The above may be workable in some contexts. But it is a sufficiently restrictive implementation model that it ought not be normative. Reply-To: From: "Martin Chapman" To: "Paul Kyzivat" , "'Owen Rees'" , Subject: RE: Vote 2. - issue 2638 Date: Thu, 16 Dec 1999 10:17:25 -0000 Message-ID: <001201bf47ae$bfe068e0$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA9140257@bos1.noblenet.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: B[A!!,_jd96eZd9EV"e9 > -----Original Message----- > From: Paul Kyzivat [mailto:paulk@roguewave.com] > Sent: 16 December 1999 00:13 > To: 'mchapman@iona.com'; Paul Kyzivat; 'Owen Rees'; > firewall-rtf@omg.org > Subject: RE: Vote 2. - issue 2638 > > > > > From: Martin Chapman [mailto:mchapman@iona.com] > > > I'm not trying to hastily close it. If we can't resolve it > > this time round it will still be open for the next rtf. > > As far as our implementation goes, the current text exactly > > matches what we do, so from a personal level I would be happy > > to close with no change. > > I finally understand this. > > But, based on scenarios raised both by Owen and me, it appears that > your > approach cannot work in general. Hence I don't want to see it in the > spec, > either as normative behavior or as an example. > > I could be talked out of this if you could explain to me how it is > not > broken. Consider the following scenario: > > - client creates POA > - client creates callback object in the POA > - client obtains an object reference to a server > - client stores own callback object deep in some complex > structure > - client sends request to server containing this structure > - orb establishes connection to server, > sends bidir context in request > - server calls back on the connection > > At the time the callback object reference is created, there is no > outgoing > connection. There isn't even an indication that an outbound tcp/ip > connection will ever be needed. (This will depend on what IORs > are used and > the profiles they contain.) > > For your approach to work, the orb apparently must assign a port no > later > than the time when the first object reference is created, or else > defer it > for lazy evaluation the first time it is marshalled. Owen suggested that the test that says "object creation time" is changed, and it does makes sense that anytime up until first marshalling is appropriate. > > Continuing: > > - client is done with this server, releases all object references > - client does other things with lots of other servers > using lots of connections > - the orb sends the bidir service context on each new connection, > referencing the address selected earlier > - because of demand for connections, or for whatever reason, > orb drops the connection to the first server > - orb may close the socket bound to the address it is using > freeing it for use by some other program on the same host. > - another program is assigned the port our client is using > in its IORs. It also starts handing out IORs with this > address. > - some server gets an ior with the original address > in it and sends a request bidirectionally to our client. > It may be from our client, or it may be from the other program. > > To prevent this, the client orb must not close the original > socket until it > is sure the there will be no valid callbacks. At the least, it must > not do > so while it holds connections on which it has sent the bidir > context. Agreed - but even if you don't have bidir and you release a port, another app could grab that and hence invalidate exported IORs - ORB implementations have (non normative) schemes to deal with this and I see this case as being no different. > > The above may be workable in some contexts. But it is a sufficiently > restrictive implementation model that it ought not be normative. > The reason for the original text was someone was bound to raise an issue when you can't setup ports so it was basically a hint to implementors that they could, if they wanted use an outbound port. The recent draft I circulated now just states the obvious: "It is the ORB's resposibility to ensure that an IOR contains an appropriate address." Personally this is too damm obvious and doesnlt need to be said at all so removing the whole orginal para would be just as acceptable. Martin. From: Paul Kyzivat To: "'mchapman@iona.com'" , Paul Kyzivat , "'Owen Rees'" , firewall-rtf@omg.org Subject: RE: Vote 2. - issue 2638 Date: Thu, 16 Dec 1999 09:18:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: #el!!'/f!!aUB!![n)!! > From: Martin Chapman [mailto:mchapman@iona.com] > > To prevent this, the client orb must not close the original > > socket until it is sure the there will be no valid callbacks. > > At the least, it must not do so while it holds connections on > > which it has sent the bidir context. > > Agreed - but even if you don't have bidir and you release a > port, another app could grab that and hence invalidate exported > IORs - ORB implementations have (non normative) schemes to deal > with this and I see this case as being no different. But releasing the port for an outgoing connection is different than releasing the port on which you expect connects. > > The above may be workable in some contexts. But it is a sufficiently > > restrictive implementation model that it ought not be normative. > > > > The reason for the original text was someone was bound to > raise an issue when you can't setup ports so it was basically > a hint to implementors that they could, if they wanted use an > outbound port. The recent draft I circulated now just states the > obvious: "It is the ORB's resposibility to > ensure that an IOR contains an appropriate address." > Personally this is too damm obvious and doesnlt need to be > said at all so removing the whole orginal para would be just as > acceptable. I could live with removing the statement altogether. But, given the discussions we have had, it seems that the implications aren't all that clear, so I would prefer to state them. Reply-To: From: "Martin Chapman" To: "Polar Humenn" Cc: "Paul Kyzivat" , "'Owen Rees'" , Subject: RE: Vote 2. - issue 2638 Date: Thu, 16 Dec 1999 17:16:53 -0000 Message-ID: <001801bf47e9$59371f40$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: gd -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: 16 December 1999 16:37 > To: Martin Chapman > Cc: Paul Kyzivat; 'Owen Rees'; firewall-rtf@omg.org > Subject: RE: Vote 2. - issue 2638 > > > > Hi, > > Personally, I don't know why this has to work off of the Host/Port > scheme. > And Martin, answer me a question. Everytime I try to do something > POA > specific with the Security Spec, Bob Kukura jumps on me, because you > don't > have to have a POA. So, how is this POA based policy stuff getting > by him? > Do you have to have a POA to have a firewall compliant ORB? I guess bob works on the assupmtion that while a compliant orb has to have a poa, and the soution must work on that, there may be other object adapters about. Bob will have to defened himself though (he's way bigger than me:-) > > I think if BiDir is really needed. Some other solution should used > to work > this, tying this stuff to Host/Port ignores other protocols, and > ignores > security instead of providing it. > > Firewalls are supposed to provide security, and this stuff the way > it is > now just seems to open up a hole you can drive a couple of Rovers > through! > Although, it might have a nice effect of eliminating Firewalls > althogether > as useless garbage. :^) I agree and I think your outline soultion below is architecturally much better. I think that's a job for GIOP 2.0 if that gets off the ground. So how do we do damage limitation in the tim eremainaing? Martin. > > The following solution (although rough) might be the subject of another > RTF, or RFP. Unfortunately, the spec EXPLICITLY ignores SECIOP, of which > I'm highly offended 8^). However, if it were paid attention to, you might > have not gotten into this Host/Port google, masquerade, and other > problems. I know, hindsight is 20/20. > > So, I only put the following comments out there for your thought and > comments in response to Paul's request that you need a "greater solution" > to solve the problem. I don't expect anything done in this RTF. > (Although, I wholely disagree with the BirDir they way it is now). > > I believe that some other component should be in an IOR to state that this > object is a BidDir object. This approach would also get rid of the > masquerade problem somewhat. > > If BirDir is POA based then you *can* get the POA and the client ORB do > the right thing. Add a Birdirectional identifer to the IOR of those > objects created in the POA. This component basically states that it can be > used over a BiDir connection that was set up on a matching Birdir context > ID. This ID can also encode its security requirements, as which SECIOP > security context to use, i.e. credentials matching, etc. > > The POA must do something to get this whole shabang rolling, quite > naturally by having Policy for it when the POA is created. Then, why not > have a BirDir unique ID set up when the POA is created based on this > policy? The policy would direct the POA to stick a TaggedComponent in the > IOR of every object reference created under that POA. This component > states that the object is intended to be contacted using BirDir, if > possible. > > Furthermore, the object can only be contacted BiDir on GIOP "connections" > (Not necessarily TCP/IP (IIOP), or SSLIOP connections, but can be a SECIOP > security contexts as well) that have the matching BiDir ID associated with > it. It just requires the Client to make that ID unique somewhat > globally.(there are schemes for doing that). > > So in Paul's scenario, no ports or "hard", potentially shared resources > are allocated. > > - client creates POA > It allocates some BiDir Unique ID. > The policy direct POA not to even allocate a port! > (use 0 in IORs). > - client creates callback object in the POA > Sticks ID in IOR as a component. > - client obtains an object reference to a server > - client stores own callback object deep in some complex structure > - client sends request to server containing this structure > > - orb establishes connection to server, > >> Based on Policy to the Server: > sends bidir context in request > >> Using the ID. > > >> Server wants to make invocation on Client's object. > Server notices BiDir TaggedComponent in IOR. > If server side policy allows BiDir, ORB searches "connection" > table for which the matching ID is assoicated. If found: > - server calls back on the connection > >> Otherwise, server makes normal invocation. > If the port was zero, this was impossible anyway. > > Continuing: > > - client is done with this server, releases all object references > - client does other things with lots of other servers > using lots of connections > - the orb sends the bidir service context on each new connection, > referencing the address selected earlier > - because of demand for connections, or for whatever reason, > orb drops the connection to the first server > - orb may close the socket bound to the address it is using > freeing it for use by some other program on the same host. > - another program is assigned the port our client is using > in its IORs. It also starts handing out IORs with this > address. > - some server gets an ior with the original address > in it and sends a request bidirectionally to our client. > It may be from our client, or it may be from the other program. > This will not happen because the BirDir ID will not match. > > None of this is a problem because the BirDir ID was unique to the objects > created in the POA. It had nothing to do with Host and Port. > > The Port is the problem here (not so much the host). The port is a semi > global resource that is allocated by many other things on the host, and is > a transient thing. The client only "owns" this resource for a short period > of time. > > If the client ORB is holding on to a resource for this purpose, it should > own that resource forever. > > Cheers, > -Polar > > On Thu, 16 Dec 1999, Martin Chapman wrote: > > > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:paulk@roguewave.com] > > > Sent: 16 December 1999 00:13 > > > To: 'mchapman@iona.com'; Paul Kyzivat; 'Owen Rees'; > firewall-rtf@omg.org > > > Subject: RE: Vote 2. - issue 2638 > > > > > > > > > > > > > From: Martin Chapman [mailto:mchapman@iona.com] > > > > > > > I'm not trying to hastily close it. If we can't resolve it > > > > this time round it will still be open for the next rtf. > > > > As far as our implementation goes, the current text exactly > > > > matches what we do, so from a personal level I would be happy > > > > to close with no change. > > > > > > I finally understand this. > > > > > > But, based on scenarios raised both by Owen and me, it > appears that your > > > approach cannot work in general. Hence I don't want to see it > in the spec, > > > either as normative behavior or as an example. > > > > > > I could be talked out of this if you could explain to me how it is not > > > broken. Consider the following scenario: > > > > > > - client creates POA > > > - client creates callback object in the POA > > > - client obtains an object reference to a server > > > - client stores own callback object deep in some complex structure > > > - client sends request to server containing this structure > > > - orb establishes connection to server, > > > sends bidir context in request > > > - server calls back on the connection > > > > > > At the time the callback object reference is created, there > is no outgoing > > > connection. There isn't even an indication that an outbound tcp/ip > > > connection will ever be needed. (This will depend on what IORs > > > are used and > > > the profiles they contain.) > > > > > > For your approach to work, the orb apparently must assign a > port no later > > > than the time when the first object reference is created, or > else defer it > > > for lazy evaluation the first time it is marshalled. > > > > Owen suggested that the test that says "object creation time" > is changed, > > and it does makes sense that anytime up until first marshalling is > > appropriate. > > > > > > > > Continuing: > > > > > > - client is done with this server, releases all object references > > > - client does other things with lots of other servers > > > using lots of connections > > > - the orb sends the bidir service context on each new connection, > > > referencing the address selected earlier > > > - because of demand for connections, or for whatever reason, > > > orb drops the connection to the first server > > > - orb may close the socket bound to the address it is using > > > freeing it for use by some other program on the same host. > > > - another program is assigned the port our client is using > > > in its IORs. It also starts handing out IORs with this > > > address. > > > - some server gets an ior with the original address > > > in it and sends a request bidirectionally to our client. > > > It may be from our client, or it may be from the other program. > > > > > > To prevent this, the client orb must not close the original > > > socket until it > > > is sure the there will be no valid callbacks. At the least, > it must not do > > > so while it holds connections on which it has sent the bidir context. > > > > Agreed - but even if you don't have bidir and you release a > port, another > > app could grab that and hence invalidate exported IORs - ORB > implementations > > have (non normative) schemes to deal with this and I see this > case as being > > no different. > > > > > > > > The above may be workable in some contexts. But it is a sufficiently > > > restrictive implementation model that it ought not be normative. > > > > > > > The reason for the original text was someone was bound to raise an issue > > when you can't setup ports so it was basically a hint to > implementors that > > they could, if they wanted use an outbound port. The recent draft I > > circulated now just states the obvious: "It is the ORB's > resposibility to > > ensure that an IOR contains an appropriate address." > > Personally this is too damm obvious and doesnlt need to be said > at all so > > removing the whole orginal para would be just as acceptable. > > > > Martin. > > > > ------------------------------------------------------------------- > 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 > > > > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 16 Dec 1999 11:37:23 -0500 (EST) From: Polar Humenn To: Martin Chapman cc: Paul Kyzivat , "'Owen Rees'" , firewall-rtf@omg.org Subject: RE: Vote 2. - issue 2638 In-Reply-To: <001201bf47ae$bfe068e0$4d01020a@leo.dublin.iona.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: fm#e9`,6e9R@k!!1o> Based on Policy to the Server: sends bidir context in request >> Using the ID. >> Server wants to make invocation on Client's object. Server notices BiDir TaggedComponent in IOR. If server side policy allows BiDir, ORB searches "connection" table for which the matching ID is assoicated. If found: - server calls back on the connection >> Otherwise, server makes normal invocation. If the port was zero, this was impossible anyway. Continuing: - client is done with this server, releases all object references - client does other things with lots of other servers using lots of connections - the orb sends the bidir service context on each new connection, referencing the address selected earlier - because of demand for connections, or for whatever reason, orb drops the connection to the first server - orb may close the socket bound to the address it is using freeing it for use by some other program on the same host. - another program is assigned the port our client is using in its IORs. It also starts handing out IORs with this address. - some server gets an ior with the original address in it and sends a request bidirectionally to our client. It may be from our client, or it may be from the other program. This will not happen because the BirDir ID will not match. None of this is a problem because the BirDir ID was unique to the objects created in the POA. It had nothing to do with Host and Port. The Port is the problem here (not so much the host). The port is a semi global resource that is allocated by many other things on the host, and is a transient thing. The client only "owns" this resource for a short period of time. If the client ORB is holding on to a resource for this purpose, it should own that resource forever. Cheers, -Polar On Thu, 16 Dec 1999, Martin Chapman wrote: > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:paulk@roguewave.com] > > Sent: 16 December 1999 00:13 > > To: 'mchapman@iona.com'; Paul Kyzivat; 'Owen Rees'; > firewall-rtf@omg.org > > Subject: RE: Vote 2. - issue 2638 > > > > > > > > > From: Martin Chapman [mailto:mchapman@iona.com] > > > > > I'm not trying to hastily close it. If we can't resolve it > > > this time round it will still be open for the next rtf. > > > As far as our implementation goes, the current text exactly > > > matches what we do, so from a personal level I would be happy > > > to close with no change. > > > > I finally understand this. > > > > But, based on scenarios raised both by Owen and me, it appears > that your > > approach cannot work in general. Hence I don't want to see it in > the spec, > > either as normative behavior or as an example. > > > > I could be talked out of this if you could explain to me how it is > not > > broken. Consider the following scenario: > > > > - client creates POA > > - client creates callback object in the POA > > - client obtains an object reference to a server > > - client stores own callback object deep in some complex > structure > > - client sends request to server containing this structure > > - orb establishes connection to server, > > sends bidir context in request > > - server calls back on the connection > > > > At the time the callback object reference is created, there is no > outgoing > > connection. There isn't even an indication that an outbound tcp/ip > > connection will ever be needed. (This will depend on what IORs > > are used and > > the profiles they contain.) > > > > For your approach to work, the orb apparently must assign a port > no later > > than the time when the first object reference is created, or else > defer it > > for lazy evaluation the first time it is marshalled. > > Owen suggested that the test that says "object creation time" is > changed, > and it does makes sense that anytime up until first marshalling is > appropriate. > > > > > Continuing: > > > > - client is done with this server, releases all object > references > > - client does other things with lots of other servers > > using lots of connections > > - the orb sends the bidir service context on each new > connection, > > referencing the address selected earlier > > - because of demand for connections, or for whatever reason, > > orb drops the connection to the first server > > - orb may close the socket bound to the address it is using > > freeing it for use by some other program on the same host. > > - another program is assigned the port our client is using > > in its IORs. It also starts handing out IORs with this > > address. > > - some server gets an ior with the original address > > in it and sends a request bidirectionally to our client. > > It may be from our client, or it may be from the other > program. > > > > To prevent this, the client orb must not close the original > > socket until it > > is sure the there will be no valid callbacks. At the least, it > must not do > > so while it holds connections on which it has sent the bidir > context. > > Agreed - but even if you don't have bidir and you release a port, > another > app could grab that and hence invalidate exported IORs - ORB > implementations > have (non normative) schemes to deal with this and I see this case > as being > no different. > > > > > The above may be workable in some contexts. But it is a > sufficiently > > restrictive implementation model that it ought not be normative. > > > > The reason for the original text was someone was bound to raise an > issue > when you can't setup ports so it was basically a hint to > implementors that > they could, if they wanted use an outbound port. The recent draft I > circulated now just states the obvious: "It is the ORB's > resposibility to > ensure that an IOR contains an appropriate address." > Personally this is too damm obvious and doesnlt need to be said at > all so > removing the whole orginal para would be just as acceptable. > > Martin. > ------------------------------------------------------------------- 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