Issue 2651: new_callback (firewall-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: OMG document orbos/98-07-03, section 4.7.4 under new_callback page 4-16, the first paragraph reads When the client side object adapter creates the object reference for the callback object, it may invoke the new_callback operation on the outermost inbound GIOP Proxy on the server side and pass the callback object as the argument. Say, there are no client-side firewalls and there is only one server-side GIOPproxy firewall. 1. how does the object adapter or the client orb get access to the IOR of the GIOPProxy object ??? 2. how does the object adpater know that the object that is being created/instantiated will be used as a callback object ?? Does POA provide any m Resolution: Revised Text: Actions taken: May 13, 1999: received issue Discussion: End of Annotations:===== From: "Martin Chapman" To: Subject: FW: new_callback Date: Thu, 13 May 1999 10:51:35 +0100 Message-ID: <000e01be9d26$30173d20$0f01020a@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.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 064e46938994273e1748f5167d4eb9ef can you add this to the issues list -----Original Message----- From: Venuturimilli, Krishna [mailto:krishna@ipo.att.com] Sent: 12 May 1999 20:09 To: 'firewall-rtf@omg.org' Subject: new_callback OMG document orbos/98-07-03, section 4.7.4 under new_callback page 4-16, the first paragraph reads When the client side object adapter creates the object reference for the callback object, it may invoke the new_callback operation on the outermost inbound GIOP Proxy on the server side and pass the callback object as the argument. Say, there are no client-side firewalls and there is only one server-side GIOPproxy firewall. 1. how does the object adapter or the client orb get access to the IOR of the GIOPProxy object ??? 2. how does the object adpater know that the object that is being created/instantiated will be used as a callback object ?? Does POA provide any mechanisms to make the above possible ?? thanks -krishna _______________________________________________________________ Krishna Venuturimilli (krishna@ipo.att.com) Off: 408-576-1364 Fax: 408-576-1354 AT&T Labs - Internet Platforms 2665 N.First Street, San Jose, CA - 95134. Date: Fri, 10 Dec 1999 15:25:55 +0000 From: Owen Rees To: mchapman@iona.com, firewall-rtf@omg.org Subject: Re: Vote 2. - issue 2651 Message-ID: <4241717863.944839555@ews-proj-2.hpl.hp.com> In-Reply-To: <000301bf4268$dd222e20$4d01020a@leo.dublin.iona.ie> 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: UFo!!8+-!!"h$!!\>G!! --On 09 December 1999, 17:14 +0000 Martin Chapman wrote: > Issue 2651: new_callback (firewall-rtf) Major problems with this one. > > Click here for this issue's archive. > Nature: Uncategorized Issue > Severity: > Summary: OMG document orbos/98-07-03, section 4.7.4 under > new_callback > page 4-16, the first paragraph reads When the client side object > adapter > creates the object reference for the callback object, it may invoke > the > new_callback operation on the outermost inbound GIOP Proxy on the > server > side and pass the callback object as the argument. Say, there are no > client-side firewalls and there is only one server-side GIOPproxy > firewall. 1. how does the object adapter or the client orb get > access to > the IOR of the GIOPProxy object ??? 2. how does the object adpater > know > that the object that is being created/instantiated will be used as a > callback object ?? > Resolution: In the call back model (to address the browser case) you > invoke an object passing the callback object as a parameter. You can > find > the GIOP Proxy ref (if present) in the IOR of the object you are > invoking. If you are not using this callback model (e.g you get the > IOR > from the Name service) or if there is no GIOP Proxy in the targets > IOR > you have to fall back to other means ( a server side initialed > connection > or bi-dir giop) i.e you cannot call new_callback. When to use it is > really a question of knowing the environment and configuration so is > really an implementation issue. > Revised Text: all changes relative to orbos/98-07-03 > > Section 4.7.4, page 4-16, 1st para: > > replace: "When the client side object adapter creates the object > reference for the callback object, it may invoke the new_callback > operation on the outermost inbound GIOP Proxy on the server side and > pass > the callback object as the argument. " > > with: "When the client side object adapter creates the object > reference > for the callback object, it may invoke the new_callback operation on > the > outermost inbound GIOP Proxy on the server side and pass the > callback > object as the argument. If an outermost inbound GIOP Proxy exists, > its > reference can be found in the IOR of the target. " See the responses to issue 2638 - "When the client side object adapter creates the object reference for the callback object, ..." it may have absolutely no clue as to where the server is. In this context, the proposed resolution does not answer the question: "1. how does the object adapter or the client orb get access to the IOR of the GIOPProxy object ???" The issue also asks: "2. how does the object adpater know that the object that is being created/instantiated will be used as a callback object ??". The proposed resolution does not answer this question. If new_callback is for some special case, that must be stated explicitly. I just don't see any way to have the necessary information available in the general case. > > Actions taken: Close on agreement of text. > May 13, 1999: received issue > > Discussion: > There is a further problem with p 4-16 last para "3. If there are ...". When new_callback is invoked on the outermost inbound proxy, it is not told the server reference so cannot know whether or not the server is behind a further proxy. 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" , Subject: RE: Vote 2. - issue 2651 Date: Tue, 14 Dec 1999 10:55:18 -0000 Message-ID: <000a01bf4621$b5eaeb00$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: <4241717863.944839555@ews-proj-2.hpl.hp.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: '%o!!JN+e9/>U!!c'?e9 The new_callback is intended for the special case where you cannot accept incomming connections, either in a browser environment or because of client side firewall (the orb will have to determine this in some unspecified way). If we add text to clarify this would this be acceptable? Martin. > -----Original Message----- > From: Owen Rees [mailto:owen_rees@hp.com] > Sent: 10 December 1999 15:26 > To: mchapman@iona.com; firewall-rtf@omg.org > Subject: Re: Vote 2. - issue 2651 > > > --On 09 December 1999, 17:14 +0000 Martin Chapman > wrote: > > > Issue 2651: new_callback (firewall-rtf) > > Major problems with this one. > > > > > Click here for this issue's archive. > > Nature: Uncategorized Issue > > Severity: > > Summary: OMG document orbos/98-07-03, section 4.7.4 under > new_callback > > page 4-16, the first paragraph reads When the client side object > adapter > > creates the object reference for the callback object, it may > invoke the > > new_callback operation on the outermost inbound GIOP Proxy on the > server > > side and pass the callback object as the argument. Say, there are > no > > client-side firewalls and there is only one server-side GIOPproxy > > firewall. 1. how does the object adapter or the client orb get > access to > > the IOR of the GIOPProxy object ??? 2. how does the object adpater > know > > that the object that is being created/instantiated will be used as > a > > callback object ?? > > Resolution: In the call back model (to address the browser case) > you > > invoke an object passing the callback object as a parameter. > You can find > > the GIOP Proxy ref (if present) in the IOR of the object you are > > invoking. If you are not using this callback model (e.g you get > the IOR > > from the Name service) or if there is no GIOP Proxy in the targets > IOR > > you have to fall back to other means ( a server side initialed > connection > > or bi-dir giop) i.e you cannot call new_callback. When to use it > is > > really a question of knowing the environment and configuration so > is > > really an implementation issue. > > Revised Text: all changes relative to orbos/98-07-03 > > > > Section 4.7.4, page 4-16, 1st para: > > > > replace: "When the client side object adapter creates the object > > reference for the callback object, it may invoke the new_callback > > operation on the outermost inbound GIOP Proxy on the server > side and pass > > the callback object as the argument. " > > > > with: "When the client side object adapter creates the object > reference > > for the callback object, it may invoke the new_callback operation > on the > > outermost inbound GIOP Proxy on the server side and pass the > callback > > object as the argument. If an outermost inbound GIOP Proxy exists, > its > > reference can be found in the IOR of the target. " > > See the responses to issue 2638 - "When the client side object > adapter > creates the object reference for the callback object, ..." it may > have > absolutely no clue as to where the server is. In this context, > the proposed > resolution does not answer the question: "1. how does the object > adapter or > the client orb get access to the IOR of the GIOPProxy object ???" > > The issue also asks: "2. how does the object adpater know that the > object > that is being created/instantiated will be used as a callback object > ??". > The proposed resolution does not answer this question. > > If new_callback is for some special case, that must be stated > explicitly. I > just don't see any way to have the necessary information available > in the > general case. > > > > > Actions taken: Close on agreement of text. > > May 13, 1999: received issue > > > > Discussion: > > > > There is a further problem with p 4-16 last para "3. If there are > ...". > When new_callback is invoked on the outermost inbound proxy, it > is not told > the server reference so cannot know whether or not the server is > behind a > further proxy. > > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 > Date: Tue, 14 Dec 1999 14:10:44 +0000 From: Owen Rees To: mchapman@iona.com, firewall-rtf@omg.org Subject: RE: Vote 2. - issue 2651 Message-ID: <287839820.945180644@localhost> In-Reply-To: <000a01bf4621$b5eaeb00$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: fGZ!!!X"!!=<2!!W!!e9 --On 14 December 1999 10:55 +0000 Martin Chapman wrote: > The new_callback is intended for the special case where you cannot accept > incomming connections, either in a browser environment or because of > client side firewall (the orb will have to determine this in some > unspecified way). If we add text to clarify this would this be acceptable? Clarifying the intent may be useful, but is not sufficient. It seems to me that the purpose of new_callback is to esablish a proxy at the other end of a bi-dir connection that terminates at a proxy so that invocations on callbacks come back up the bi-dir connection. In this case, the proxy on which new_callback should be invoked is known, at least in principle. In other circumstances, it is not clear which proxy is involved. Note here that a bi-dir connection terminates at a NORMAL proxy but not at a PASSTHRU proxy, and the text must allow for this - more details are interspersed with the text below. > > Martin. > >> -----Original Message----- >> From: Owen Rees [mailto:owen_rees@hp.com] >> Sent: 10 December 1999 15:26 >> To: mchapman@iona.com; firewall-rtf@omg.org >> Subject: Re: Vote 2. - issue 2651 >> >> >> --On 09 December 1999, 17:14 +0000 Martin Chapman >> wrote: >> >> > Issue 2651: new_callback (firewall-rtf) >> >> Major problems with this one. >> >> > >> > Click here for this issue's archive. >> > Nature: Uncategorized Issue >> > Severity: >> > Summary: OMG document orbos/98-07-03, section 4.7.4 under > new_callback >> > page 4-16, the first paragraph reads When the client side object >> > adapter creates the object reference for the callback object, it > may >> > invoke the new_callback operation on the outermost inbound GIOP > Proxy >> > on the server side and pass the callback object as the > argument. Say, >> > there are no client-side firewalls and there is only one > server-side >> > GIOPproxy firewall. 1. how does the object adapter or the client > orb >> > get access to the IOR of the GIOPProxy object ??? 2. how does the >> > object adpater know that the object that is being > created/instantiated >> > will be used as a callback object ?? >> > Resolution: In the call back model (to address the browser case) > you >> > invoke an object passing the callback object as a parameter. >> You can find >> > the GIOP Proxy ref (if present) in the IOR of the object you are >> > invoking. If you are not using this callback model (e.g you get > the IOR >> > from the Name service) or if there is no GIOP Proxy in the > targets IOR >> > you have to fall back to other means ( a server side initialed >> connection >> > or bi-dir giop) i.e you cannot call new_callback. When to use it > is >> > really a question of knowing the environment and configuration so > is >> > really an implementation issue. >> > Revised Text: all changes relative to orbos/98-07-03 >> > >> > Section 4.7.4, page 4-16, 1st para: >> > >> > replace: "When the client side object adapter creates the object >> > reference for the callback object, it may invoke the new_callback >> > operation on the outermost inbound GIOP Proxy on the server >> side and pass >> > the callback object as the argument. " >> > >> > with: "When the client side object adapter creates the object > reference >> > for the callback object, it may invoke the new_callback operation > on >> > the outermost inbound GIOP Proxy on the server side and pass the >> > callback object as the argument. If an outermost inbound GIOP > Proxy >> > exists, its reference can be found in the IOR of the > target. > > para>" >> >> See the responses to issue 2638 - "When the client side object > adapter >> creates the object reference for the callback object, ..." it may > have >> absolutely no clue as to where the server is. In this context, >> the proposed >> resolution does not answer the question: "1. how does the object >> adapter or >> the client orb get access to the IOR of the GIOPProxy object ???" At the time when the object reference is created, the ORB cannot in general have enough information. Do not mandate reference creation time. If a PASSTHRUONLY bi-dir connection is used, using new_callback on any of the intervening proxies would replace a reference that would work with a useless one. This also applies if PASSTHRU was requested and all proxies accepted it. If the outermost inbound proxy is PASSTHRU with a NORMAL proxy beyond it, new_callback must be invoked on the outermost NORMAL proxy, not the outermost proxy. It is not clear that the client has the right information to detect and act on this. It may be possible to work the right information into the resolution of issue 2261. Removing the things that will sometimes be wrong, the proposed replacement text reduces to: with: "The client side object adapter may invoke the new_callback operation on an inbound GIOP Proxy on the server side and pass the callback object as the argument." I would suggest that the client side ORB might not know that this is the right thing to do until it marshalls a reference which will match a listen_point which it is sending (or will send) down a [potentially] bi-dir connection that it knows terminates at an inbound GIOP proxy. Note also that it is quite possible to have two separate PASSTHRU connections to different NORMAL proxies with different servers behind them. In this case it is necessary to invoke new_callback on each proxy separately, and send the appropriate references down the different connections. >> >> The issue also asks: "2. how does the object adpater know that the >> object >> that is being created/instantiated will be used as a callback >> object ??". >> The proposed resolution does not answer this question. This is no longer a problem if the "creation time" text goes away. >> >> If new_callback is for some special case, that must be stated >> explicitly. I >> just don't see any way to have the necessary information available >> in the >> general case. >> >> > >> > Actions taken: Close on agreement of text. >> > May 13, 1999: received issue >> > >> > Discussion: >> > >> >> There is a further problem with p 4-16 last para "3. If there are >> ...". >> When new_callback is invoked on the outermost inbound proxy, it >> is not told >> the server reference so cannot know whether or not the server is >> behind a >> further proxy. Nothing that went before fixes this problem. Since there is no way to control how the reference (to the callback proxy) is passed around at the server end, there is nothing that can usefully be done based on the server that will invoke the callback. I suggest that the solution is to leave this to whatever mechanism allows invoking of an object in an outer enclave (this is option 1. of the three and the only one that makes any sense). The fix to the text is to delete the last four paragraphs on p 4-16: Delete: "In the case where there are firewalls between the outer most inbound GIOP Proxy and the servers, there are different ways to deal with routing the request message(s) depending on the GIOP Proxy implementation and firewall configuration. 1. If the server knows how to reach the outermost GIOP Proxy through the firewalls between them, these firewalls can be treated as outbound firewalls to the server. 2. If the GIOP Proxy knows how the server should reach the GIOP Proxy through the firewalls between them, these firewalls can be treated as inbound firewalls to the GIOP Proxy 3. If there are more GIOP Proxies between the outer most inbound GIOP Proxy and the server, the outer most inbound GIOP Proxy can invoke new_callback on the inner inbound GIOP Proxy to create a proxy object which is closer and directly reachable to the server." Paragraph 3 on page 4-16 needs a minor change to be consistent with the resolutions passed in vote 1. Replace: "When the server wants to invoke the methods on the callback object, the request messages will be sent to the GIOP Proxy because the IOR of the callback object is the IOR of the proxy object on the GIOP Proxy. The GIOP Proxy should forward the request messages on the connection on which the new_callback for this proxy object was received if the bi-directional IIOP is used." With: "When the server wants to invoke the methods on the callback object, the request messages will be sent to the GIOP Proxy because the IOR of the callback object is the IOR of the proxy object on the GIOP Proxy. The GIOP Proxy should forward the request messages on the connection on which the listen_point matching the callback object was received if the bi-directional IIOP is used." 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" , Subject: RE: Vote 2. - issue 2651 Date: Tue, 14 Dec 1999 14:55:24 -0000 Message-ID: <001901bf4643$4060c4a0$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: <287839820.945180644@localhost> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 0$od9IG~!!-Tb!!6H -----Original Message----- > From: Owen Rees [mailto:owen_rees@hp.com] > Sent: 14 December 1999 14:11 > To: mchapman@iona.com; firewall-rtf@omg.org > Subject: RE: Vote 2. - issue 2651 > > > --On 14 December 1999 10:55 +0000 Martin Chapman > wrote: > > > The new_callback is intended for the special case where you > cannot accept > > incomming connections, either in a browser environment or because > of > > client side firewall (the orb will have to determine this in some > > unspecified way). If we add text to clarify this would this be > acceptable? > > Clarifying the intent may be useful, but is not sufficient. It seems > to me > that the purpose of new_callback is to esablish a proxy at the > other end of > a bi-dir connection that terminates at a proxy so that invocations > on > callbacks come back up the bi-dir connection. Correct > In this case, the proxy on which new_callback should be invoked is known, > at least in principle. In other circumstances, it is not clear which proxy > is involved. Correct. > > Note here that a bi-dir connection terminates at a NORMAL proxy but > not at > a PASSTHRU proxy, and the text must allow for this - more details > are > interspersed with the text below. Indeed - as far as the server is concerned the proxy is the target. the server may set up normal or passthru to the proxy(what it thinks is the target) therefore as currently defined you can't get an end-end passthru from server to client. > > > > > Martin. > > > >> -----Original Message----- > >> From: Owen Rees [mailto:owen_rees@hp.com] > >> Sent: 10 December 1999 15:26 > >> To: mchapman@iona.com; firewall-rtf@omg.org > >> Subject: Re: Vote 2. - issue 2651 > >> > >> > >> --On 09 December 1999, 17:14 +0000 Martin Chapman > >> wrote: > >> > >> > Issue 2651: new_callback (firewall-rtf) > >> > >> Major problems with this one. > >> > >> > > >> > Click here for this issue's archive. > >> > Nature: Uncategorized Issue > >> > Severity: > >> > Summary: OMG document orbos/98-07-03, section 4.7.4 under > new_callback > >> > page 4-16, the first paragraph reads When the client side > object > >> > adapter creates the object reference for the callback object, > it may > >> > invoke the new_callback operation on the outermost inbound GIOP > Proxy > >> > on the server side and pass the callback object as the > argument. Say, > >> > there are no client-side firewalls and there is only one > server-side > >> > GIOPproxy firewall. 1. how does the object adapter or the > client orb > >> > get access to the IOR of the GIOPProxy object ??? 2. how does > the > >> > object adpater know that the object that is being > created/instantiated > >> > will be used as a callback object ?? > >> > Resolution: In the call back model (to address the browser > case) you > >> > invoke an object passing the callback object as a parameter. > >> You can find > >> > the GIOP Proxy ref (if present) in the IOR of the object you > are > >> > invoking. If you are not using this callback model (e.g you > get the IOR > >> > from the Name service) or if there is no GIOP Proxy in the > targets IOR > >> > you have to fall back to other means ( a server side initialed > >> connection > >> > or bi-dir giop) i.e you cannot call new_callback. When to use > it is > >> > really a question of knowing the environment and configuration > so is > >> > really an implementation issue. > >> > Revised Text: all changes relative to orbos/98-07-03 > >> > > >> > Section 4.7.4, page 4-16, 1st para: > >> > > >> > replace: "When the client side object adapter creates the > object > >> > reference for the callback object, it may invoke the > new_callback > >> > operation on the outermost inbound GIOP Proxy on the server > >> side and pass > >> > the callback object as the argument. " > >> > > >> > with: "When the client side object adapter creates the > object reference > >> > for the callback object, it may invoke the new_callback > operation on > >> > the outermost inbound GIOP Proxy on the server side and pass > the > >> > callback object as the argument. If an outermost inbound GIOP > Proxy > >> > exists, its reference can be found in the IOR of the > target. >> > para>" > >> > >> See the responses to issue 2638 - "When the client side object > adapter > >> creates the object reference for the callback object, ..." it may > have > >> absolutely no clue as to where the server is. In this context, > >> the proposed > >> resolution does not answer the question: "1. how does the object > >> adapter or > >> the client orb get access to the IOR of the GIOPProxy object ???" > > At the time when the object reference is created, the ORB cannot > in general > have enough information. Do not mandate reference creation time. I agree with this - as long as it happens before you export the callback IOR is all that needs to be said. > > If a PASSTHRUONLY bi-dir connection is used, using new_callback on > any of > the intervening proxies would replace a reference that would work > with a > useless one. This also applies if PASSTHRU was requested and all > proxies > accepted it. not sure I understand this - new_callback does not have a mode you are just creating a proxy object. > > If the outermost inbound proxy is PASSTHRU with a NORMAL proxy beyond it, > new_callback must be invoked on the outermost NORMAL proxy, not the > outermost proxy. It is not clear that the client has the right information > to detect and act on this. It may be possible to work the right > information > into the resolution of issue 2261. > > Removing the things that will sometimes be wrong, the proposed replacement > text reduces to: > > with: "The client side object adapter may invoke the new_callback > operation > on an inbound GIOP Proxy on the server side and pass the callback > object as > the argument." > > I would suggest that the client side ORB might not know that this is the > right thing to do until it marshalls a reference which will match a > listen_point which it is sending (or will send) down a > [potentially] bi-dir > connection that it knows terminates at an inbound GIOP proxy. > > Note also that it is quite possible to have two separate PASSTHRU > connections to different NORMAL proxies with different servers > behind them. > In this case it is necessary to invoke new_callback on each proxy > separately, and send the appropriate references down the different > connections. > > >> > >> The issue also asks: "2. how does the object adpater know that > the object > >> that is being created/instantiated will be used as a callback > object ??". > >> The proposed resolution does not answer this question. > > This is no longer a problem if the "creation time" text goes away. > > >> > >> If new_callback is for some special case, that must be stated > >> explicitly. I > >> just don't see any way to have the necessary information > available in the > >> general case. > >> > >> > > >> > Actions taken: Close on agreement of text. > >> > May 13, 1999: received issue > >> > > >> > Discussion: > >> > > >> > >> There is a further problem with p 4-16 last para "3. If there are ...". > >> When new_callback is invoked on the outermost inbound proxy, it > >> is not told > >> the server reference so cannot know whether or not the server > is behind a > >> further proxy. > > Nothing that went before fixes this problem. Since there is no way to > control how the reference (to the callback proxy) is passed around at the > server end, there is nothing that can usefully be done based on the server > that will invoke the callback. I suggest that the solution is to > leave this > to whatever mechanism allows invoking of an object in an outer enclave > (this is option 1. of the three and the only one that makes any > sense). The > fix to the text is to delete the last four paragraphs on p 4-16: > > Delete: "In the case where there are firewalls between the outer most > inbound GIOP Proxy and the servers, there are different ways to deal with > routing the request message(s) depending on the GIOP Proxy implementation > and firewall configuration. > > 1. If the server knows how to reach the outermost GIOP Proxy through the > firewalls between them, these firewalls can be treated as outbound > firewalls to the server. > > 2. If the GIOP Proxy knows how the server should reach the GIOP Proxy > through the firewalls between them, these firewalls can be treated as > inbound firewalls to the GIOP Proxy > > 3. If there are more GIOP Proxies between the outer most inbound > GIOP Proxy > and the server, the outer most inbound GIOP Proxy can invoke new_callback > on the inner inbound GIOP Proxy to create a proxy object which is closer > and directly reachable to the server." Suits me - less is better in this case i think!! > > > Paragraph 3 on page 4-16 needs a minor change to be consistent with the > resolutions passed in vote 1. > > Replace: "When the server wants to invoke the methods on the callback > object, the request messages will be sent to the GIOP Proxy > because the IOR > of the callback object is the IOR of the proxy object on the GIOP Proxy. > The GIOP Proxy should forward the request messages on the connection on > which the new_callback for this proxy object was received if the > bi-directional IIOP is used." > > With: "When the server wants to invoke the methods on the callback object, > the request messages will be sent to the GIOP Proxy because the IOR of the > callback object is the IOR of the proxy object on the GIOP Proxy. The GIOP > Proxy should forward the request messages on the connection on which the > listen_point matching the callback object was received if the > bi-directional IIOP is used." > > sounds fine > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 > Date: Tue, 14 Dec 1999 19:49:17 +0000 From: Owen Rees To: mchapman@iona.com, firewall-rtf@omg.org cc: Owen Rees Subject: RE: Vote 2. - issue 2651 Message-ID: <308152749.945200957@rees-o-home-1.hpl.hp.com> 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: 8Fjd9>?m!!o7Pd9`W wrote: >> If a PASSTHRUONLY bi-dir connection is used, using new_callback on any of >> the intervening proxies would replace a reference that would work with a >> useless one. This also applies if PASSTHRU was requested and all proxies >> accepted it. > > not sure I understand this - new_callback does not have a mode you are > just creating a proxy object. I thought that creating proxy objects was what new_callback did. Perhaps it would help to put the situation in more concrete terms. This will also explain the next point more clearly. >> >> If the outermost inbound proxy is PASSTHRU with a NORMAL proxy >> beyond it, >> new_callback must be invoked on the outermost NORMAL proxy, not the >> outermost proxy. It is not clear that the client has the right >> information to detect and act on this. It may be possible to work >> the >> right information >> into the resolution of issue 2261. Suppose we have a client C that cannot listen (i.e. callbacks must use bi-dir), and a server S behind two proxies, PO the outer proxy and PI the inner proxy, both GIOP proxies. I.e. connectivity is like this: C --- PO --- PI --- S Example 1 - end-to-end passthrough forced by client. 1.1. C creates an object Co. 1.2. C calls PO->new_target(S,PASSTHRUONLY) receiving Sx, an IOR indicating success (some PO-PI interactions happened here) 1.3. C calls Sx->op(Co) with a bi-dir context listen_point for Co. 1.4. S calls Co->op() listen_point matches, bi-dir used. In this case, C must not pass the result of a call to new_callback as the parameter. Example 2 - NORMAL. 2.1. C creates an object Co. 2.2. C calls PO->new_target(S,NORMAL) receiving Sx, an IOR indicating success (Sx refers to an object at PO that will forward via PI to S) 2.3. C calls PO->new_callback(Co) receiving POo, a reference to an outbound proxy object at PO that will forward invocations to Co. 2.4. C calls Sx->op(POo) with a bi-dir context listen_point for Co. 2.5. PO (actual target of Sx) forwards via PI to S ->op(POo) 2.6. S calls POo->op() 2.7. POo forwards to Co via the bi-dir connection In this case C must call new_callback on PO (or should that be Sx?) to get the reference it must pass. Example 3 - end-to-end passthrough, proxies willing. 3.1. C creates an object Co. 3.2. C calls PO->new_target(S,PASSTHRU) receiving Sx, an IOR indicating success, in this case both PO and PI permit PASSTHRU 3.3. C calls Sx->op(Co) with a bi-dir context listen_point for Co. 3.4. S calls Co->op() listen_point matches, bi-dir used. In this case, C must not pass the result of a call to new_callback, since PI was willing, the situation is the same as example 1. 4.1. C creates an object Co. 4.2. C calls PO->new_target(S,PASSTHRU) receiving Sx, an IOR indicating success. In this case, PO permits PASSTHRU, PI does not, PO retries NORMAL and this succeeds. Sx refers to a passthrough via PO to an object at PI that will forward to S. 4.3. C calls PI->new_callback(Co) receiving PIo, a reference to an outbound proxy object at PI that will forward invocations to Co. 4.4. C calls Sx->op(PIo) with a bi-dir context listen_point for Co. 4.5. PI (actual target of Sx) forwards to S ->op(PIo) 4.6. S calls PIo->op() 4.7. PIo forwards to Co via the bi-dir connection In this case C must call new_callback on PI (or should that be Sx?) to get the reference it must pass. How does C know that this situation is different from example 3? How does C call PI? Presumably, it must do this via PO; perhaps it creates some refererence out of pieces of S or Sx (it finds PO from S in the first place). There will have to be something in the reference returned from new_target that distinguishes these cases, and allows C to know which proxy to call. For interoperability, that must be defined in the specification. The examples above do not cover all cases, but should be enough to start with. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 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" , Subject: RE: Vote 2. - issue 2651 Date: Thu, 16 Dec 1999 10:37:05 -0000 Message-ID: <001301bf47b1$7eece0e0$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: <308152749.945200957@rees-o-home-1.hpl.hp.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: /RB!!8[(e9*][d9[g\d9 > -----Original Message----- > From: Owen Rees [mailto:owen_rees@hp.com] > Sent: 14 December 1999 19:49 > To: mchapman@iona.com; firewall-rtf@omg.org > Cc: Owen Rees > Subject: RE: Vote 2. - issue 2651 > > > --On 14 December 1999 14:55 +0000 Martin Chapman > wrote: > > >> If a PASSTHRUONLY bi-dir connection is used, using > new_callback on any of > >> the intervening proxies would replace a reference that would > work with a > >> useless one. This also applies if PASSTHRU was requested and > all proxies > >> accepted it. > > > > not sure I understand this - new_callback does not have a mode you > are > > just creating a proxy object. > > I thought that creating proxy objects was what new_callback did. > Perhaps it > would help to put the situation in more concrete terms. This will > also > explain the next point more clearly. > > >> > >> If the outermost inbound proxy is PASSTHRU with a NORMAL proxy > beyond it, > >> new_callback must be invoked on the outermost NORMAL proxy, not > the > >> outermost proxy. It is not clear that the client has the right > >> information to detect and act on this. It may be possible to work > the > >> right information > >> into the resolution of issue 2261. > > Suppose we have a client C that cannot listen (i.e. callbacks must > use > bi-dir), and a server S behind two proxies, PO the outer proxy and > PI the > inner proxy, both GIOP proxies. I.e. connectivity is like this: > > C --- PO --- PI --- S > > Example 1 - end-to-end passthrough forced by client. > 1.1. C creates an object Co. > 1.2. C calls PO->new_target(S,PASSTHRUONLY) receiving Sx, an IOR > indicating > success (some PO-PI interactions happened here) > 1.3. C calls Sx->op(Co) with a bi-dir context listen_point for Co. > 1.4. S calls Co->op() listen_point matches, bi-dir used. > > In this case, C must not pass the result of a call to new_callback > as the > parameter. Correct. > > Example 2 - NORMAL. > 2.1. C creates an object Co. > 2.2. C calls PO->new_target(S,NORMAL) receiving Sx, an IOR > indicating > success (Sx refers to an object at PO that will forward via PI to S) > 2.3. C calls PO->new_callback(Co) receiving POo, a reference to > an outbound > proxy object at PO that will forward invocations to Co. > 2.4. C calls Sx->op(POo) with a bi-dir context listen_point for Co. > 2.5. PO (actual target of Sx) forwards via PI to S ->op(POo) > 2.6. S calls POo->op() > 2.7. POo forwards to Co via the bi-dir connection > > In this case C must call new_callback on PO (or should that be Sx?) > to get > the reference it must pass. I don't see why you must call new_callback - NORMAL connections can be bidir. even if C-PO is a NORMAL connection if it is bidir S can do Co->op() It's only when its not bidir do you need to invoke new_callback. > > Example 3 - end-to-end passthrough, proxies willing. > 3.1. C creates an object Co. > 3.2. C calls PO->new_target(S,PASSTHRU) receiving Sx, an IOR > indicating > success, in this case both PO and PI permit PASSTHRU > 3.3. C calls Sx->op(Co) with a bi-dir context listen_point for Co. > 3.4. S calls Co->op() listen_point matches, bi-dir used. > > In this case, C must not pass the result of a call to new_callback, > since > PI was willing, the situation is the same as example 1. again its not the passthru/normal that makes the difference but whether C -PO are coinnected with bidir connections. > > 4.1. C creates an object Co. > 4.2. C calls PO->new_target(S,PASSTHRU) receiving Sx, an IOR indicating > success. In this case, PO permits PASSTHRU, PI does not, PO retries NORMAL > and this succeeds. Sx refers to a passthrough via PO to an object at PI > that will forward to S. > 4.3. C calls PI->new_callback(Co) receiving PIo, a reference to > an outbound > proxy object at PI that will forward invocations to Co. > 4.4. C calls Sx->op(PIo) with a bi-dir context listen_point for Co. > 4.5. PI (actual target of Sx) forwards to S ->op(PIo) > 4.6. S calls PIo->op() > 4.7. PIo forwards to Co via the bi-dir connection > > In this case C must call new_callback on PI (or should that be Sx?) to get > the reference it must pass. > > How does C know that this situation is different from example 3? > > How does C call PI? Presumably, it must do this via PO; perhaps it creates > some refererence out of pieces of S or Sx (it finds PO from S in the first > place). > > There will have to be something in the reference returned from new_target > that distinguishes these cases, and allows C to know which proxy to call. > For interoperability, that must be defined in the specification. > > The examples above do not cover all cases, but should be enough to start > with. We have here a classic "feature interaction" problem i.e. not all combinations were well thought out!! Speaking from a strict IONA view (not a chir view) I would be happy to deprecate new_callback, and just rely on bidir connections. The current text is cleary full of holes and issues, so what can we do to at least improve the situation in the time remaining? Martin. Date: Thu, 16 Dec 1999 17:34:11 +0000 From: Owen Rees To: mchapman@iona.com, firewall-rtf@omg.org Subject: RE: Vote 2. - issue 2651 Message-ID: <472846036.945365651@ews-proj-2.hpl.hp.com> In-Reply-To: <001301bf47b1$7eece0e0$4d01020a@leo.dublin.iona.ie> 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: QjHe9M["!!YY#!!b8Me9 --On 16 December 1999, 10:37 +0000 Martin Chapman wrote: >> -----Original Message----- >> From: Owen Rees [mailto:owen_rees@hp.com] >> Sent: 14 December 1999 19:49 >> Suppose we have a client C that cannot listen (i.e. callbacks must use >> bi-dir), and a server S behind two proxies, PO the outer proxy and PI the >> inner proxy, both GIOP proxies. I.e. connectivity is like this: >> >> C --- PO --- PI --- S >> >> Example 2 - NORMAL. >> 2.1. C creates an object Co. >> 2.2. C calls PO->new_target(S,NORMAL) receiving Sx, an IOR >> indicating >> success (Sx refers to an object at PO that will forward via PI to >> S) >> 2.3. C calls PO->new_callback(Co) receiving POo, a reference to >> an outbound >> proxy object at PO that will forward invocations to Co. >> 2.4. C calls Sx->op(POo) with a bi-dir context listen_point for Co. >> 2.5. PO (actual target of Sx) forwards via PI to S ->op(POo) >> 2.6. S calls POo->op() >> 2.7. POo forwards to Co via the bi-dir connection >> >> In this case C must call new_callback on PO (or should that be Sx?) >> to >> get the reference it must pass. > > I don't see why you must call new_callback - NORMAL connections can >> be > bidir. > even if C-PO is a NORMAL connection if it is bidir S can do Co->op() > It's only when its not bidir do you need to invoke new_callback. Until we consider new_callback, there is nothing that requires that inbound and outbound proxies be 'together' (e.g. in the same process). Suppose PinO is the inbound proxy on host HiO and PoutO is the outbound proxy on some other host HoO, and similar for the inner ones. Sx created (or found) at step 2.2 is presumably on host PinO, being an inbound proxy. The [NORMAL,bi-dir] (i.e. has both propeerties) connection from C goes to that host. In this scenario there were no firewall proxies at the client end so Co has no firewall proxy components. Presumably the listen restriction is applet sandbox or equivalent. Presumably S is configured to know its outbound proxy PoutI which in turn is configured to know PoutO. S invokes C->op(). It has an outbound proxy so invokes PoutI (if GIOP, otherwise does SOCKS etc.). PoutI invokes PoutO which tries to connect to C and fails - no way to use the bi-dir connection, the end you need is on some other host. If we require that PoutO "located with" PinO, and that both must be the same kind of proxy (e.g. both GIOP) then an incoming invocation to PoutO could be routed back up the bi-dir connect that is attached to PinO. My "located with" above is defined as whatever it takes to make this happen (e.g. same process, ORB instance, whatever). I was assuming that the whole point of new_callback was to create an outbound proxy "located with" the inbound proxy on which new_callback was invoked, and that the reference returned from new_target(x,NORMAL) is also "located with" those objects so that the proxies will be together enough for callbacks to be sent to the right place to go back up the bi-dir connection. In the example, the new_callback creates POo 'near' Sx so that when S calls PoutI, the target is POo which is in the right place to forward the invocation back up the bi-dir connection. If there is no bi-dir then S calling C is essentially the same problem as C calling S, there just have to be the right proxies configured in the right way and new_callback is not needed. > > > >> >> Example 3 - end-to-end passthrough, proxies willing. >> 3.1. C creates an object Co. >> 3.2. C calls PO->new_target(S,PASSTHRU) receiving Sx, an IOR > indicating >> success, in this case both PO and PI permit PASSTHRU >> 3.3. C calls Sx->op(Co) with a bi-dir context listen_point for Co. >> 3.4. S calls Co->op() listen_point matches, bi-dir used. >> >> In this case, C must not pass the result of a call to new_callback, > since >> PI was willing, the situation is the same as example 1. > > again its not the passthru/normal that makes the difference but > whether > C -PO are coinnected with bidir connections. In this case, the bi-dir IIOP is C-S with PI and PO being transparent relays (hard to distinguish from SOCKS or TCP after setup). Neither C not S can see the joins between the three TCP connections - it looks like a straight TCP to them. >> >> 4.1. C creates an object Co. >> 4.2. C calls PO->new_target(S,PASSTHRU) receiving Sx, an IOR >> indicating >> success. In this case, PO permits PASSTHRU, PI does not, PO retries >> NORMAL and this succeeds. Sx refers to a passthrough via PO to an >> object >> at PI that will forward to S. >> 4.3. C calls PI->new_callback(Co) receiving PIo, a reference to >> an outbound >> proxy object at PI that will forward invocations to Co. >> 4.4. C calls Sx->op(PIo) with a bi-dir context listen_point for Co. >> 4.5. PI (actual target of Sx) forwards to S ->op(PIo) >> 4.6. S calls PIo->op() >> 4.7. PIo forwards to Co via the bi-dir connection >> >> In this case C must call new_callback on PI (or should that be Sx?) >> to >> get the reference it must pass. >> >> How does C know that this situation is different from example 3? >> >> How does C call PI? Presumably, it must do this via PO; perhaps it >> creates some refererence out of pieces of S or Sx (it finds PO from >> S in >> the first place). >> >> There will have to be something in the reference returned from >> new_target >> that distinguishes these cases, and allows C to know which proxy to >> call. >> For interoperability, that must be defined in the specification. >> >> The examples above do not cover all cases, but should be enough to >> start >> with. > > We have here a classic "feature interaction" problem i.e. not all > combinations were well thought out!! > > Speaking from a strict IONA view (not a chir view) I would be happy >> to > deprecate new_callback, and just rely on bidir connections. As the examples above illustrate, my interpretation of the intent of the authors (not being one myself, nor HP being a submitter) is that new_callback is there to make bi-dir work when there is a NORMAL proxy at the server end. If this is right you can't just "rely on bidir" without new_callback. Is it possible for us to have some input from whoever wrote the new_callback section? > > The current text is cleary full of holes and issues, so what can we > do to > at least improve the situation in the time remaining? > > Martin. > Some of these are too drastic, and all but the last would still leave plenty of the existing issues (we would have new set of issues for that one)! 1) Require that the 'host' in a listen point be matched against the 'host' in an IOR purely as a string comparison, and place no other constraints on the content of that string. How you fix various bi-dir issues on the back of that is left as an opportunity for the vendor. 2) Delete PASSTHRU leaving PASSTHRUONLY and NORMAL as the only options - this eliminates various combinations that cause trouble. 3) Restrict bi-dir to PASSTHRUONLY (and SOCKS, TCP) and delete new_callback which is now redundant. 4) Adopt Brian's solution (1) for PASSTHRUONLY (now that PASSTHRU is eliminated[*]): process is client *opens*new*connection* to proxy, calls new_target(t,PASSTHRUONLY) on *that* connection, if no exception that connection is used as if direct to target host:port. Returned object can be ignored in this case. ([*] N.B. not doing (2) as well leaves some nasty scaling problems, or lots of work to resolve them.) 5) Delete the whole spec! If you don't mind the performance hit, you can deploy a proxy that does not need any of the stuff described in the spec. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 16 Dec 1999 16:02:03 -0500 (EST) From: Polar Humenn To: Owen Rees cc: mchapman@iona.com, firewall-rtf@omg.org Subject: RE: Vote 2. - issue 2651 In-Reply-To: <472846036.945365651@ews-proj-2.hpl.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: &+od9Xeod9&H6!!`W+e9 > 5) Delete the whole spec! If you don't mind the performance hit, you can > deploy a proxy that does not need any of the stuff described in the spec. > > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 I'm with Owen on this one! :) Unconstructive, I know, but you know how I feel. (sorry, there's a bit of an office xmas party going on now). Later, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 16 Dec 1999 19:51:31 -0500 (EST) From: Polar Humenn To: Owen Rees cc: mchapman@iona.com, firewall-rtf@omg.org Subject: RE: Vote 2. - issue 2651 In-Reply-To: <472846036.945365651@ews-proj-2.hpl.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: nF=e9oD_d9ZfX!!I!"!! On Thu, 16 Dec 1999, Owen Rees wrote: > 5) Delete the whole spec! If you don't mind the performance hit, you can > deploy a proxy that does not need any of the stuff described in the spec. Hell, we have one of these things, and it works fine, and it's even written in Java, besides using CORBA security. (Okay, I just got back from the xmas office party). %^P Later, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com