Issue 1133: Optimization of LOCATION_FORWARD replies (interop) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: As of GIOP/IIOP 1.1, if a server wants to have a client use some locally hashed down object_key in future requests for an object, it must require one of the following: a) the client use a LocateRequest in order for the server to reply with a forwarded object reference that has a hashed down object key. b) respond with an OBJECT_FORWARD reply to the request, forcing the client to remarshal the request with the new target (the forwarded object reference"s key). With some already recommended changes to GIOP 1.1, such a reply will only require remarshaling the message header, but an extra roundtrip is still required. This could be avoided by addind a new service context to the reply that contains the forward IOR, or a new Reply type such as NO_EXCEPTION_AND_FORWARD that indicates the first request has succeeded and that subsequent requests can use the supplied forward IOR. Resolution: Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do Revised Text: Actions taken: April 2, 1998: received issue February 27, 2001: closed issue Discussion: End of Annotations:===== Return-Path: Date: Thu, 02 Apr 1998 06:33:29 -0800 From: Jon Goldberg To: interop@omg.org CC: issues@omg.org Subject: Optimization of LOCATION_FORWARD replies Hi Folks- As of GIOP/IIOP 1.1, if a server wants to have a client use some locally hashed down object_key in future requests for an object, it must require one of the following: a) the client use a LocateRequest in order for the server to reply with a forwarded object reference that has a hashed down object key. b) respond with an OBJECT_FORWARD reply to the request, forcing the client to remarshal the request with the new target (the forwarded object reference's key). With some already recommended changes to GIOP 1.1, such a reply will only require remarshaling the message header, but an extra roundtrip is still required. This could be avoided by addind a new service context to the reply that contains the forward IOR, or a new Reply type such as NO_EXCEPTION_AND_FORWARD that indicates the first request has succeeded and that subsequent requests can use the supplied forward IOR. -Jon Return-Path: Sender: goldberg@corp.inprise.com Date: Fri, 08 May 1998 13:05:16 -0700 From: Jon Goldberg To: interop@omg.org Subject: Issue 1133: Optimization of LOCATION_FORWARD replies Hi Folks- Here's a starter proposal for solving issue #1133 along with some background explanation... take care, Jon =========================================================== ===Issue 1133: Optimization of LOCATION_FORWARD replies =========================================================== As review, the basic issue is that if you want to forward a client to a hashed-down IOR when a request is received, a roundtrip is wasted because the LOCATION_FORWARD reply must be sent back, and then the client must resend the request with the new key. We'd like to add a reply service context that contains the forward IOR, so the client can get a reply to the first (non-optimal) request and then can use the new IOR for subsequent requests. This change is backward-compatible, because the reply service context will be ignored by previous versions. The following specific changes to Ch. 13, GIOP are proposed: **Section 13.6, after paragraph 2 on page 13-33 of CORBA2.2 add the following paragraph: Further optimization over the use of LOCATION_FORWARD replies may be attained by using a LocateForwardContext service context. The service context may be included in any non-forwarding reply (e.g. NO_EXCEPTION, USER_EXCEPTION, SYSTEM_EXCEPTION) to indicate that the request has been processed and that for future requests, the forwarded object reference should be used. This allows a server to forward a client to using an optimized object reference for the duration of the connection without consuming an extra roundtrip as would be necessary with a LOCATION_FORWARD reply. The LocationForwardContext is defined as follows: module GIOP { //IDL const IOP::ServiceId LocationForwardContextId = @@@; typedef short AddressLongevity; const AddressLongevity CONNECTION = 0; const AddressLongevity PERMANENT = 1; struct LocationForwardContext { AddressLongevity lifetime; TargetAddress forward_address; }; }; A service context with tag LocationForwardContextId contains a CDR encapsulation holding a LocationForwardContext structure. The forward_reference member is the object reference to which the client is forwarded for future requests. The lifetime member can have one of the following values: -CONNECTION - The forward_address is valid for the lifetime of the current connection only. Once the connection on which the location forwarding information was sent is closed, the client ORB shall use the original address specified in the initial object reference. -PERMANENT - The forward_address is valid after the current connection is closed. The new reference is considered to replace the initial object reference. Return-Path: Sender: jon@floorboard.com Date: Fri, 08 May 1998 14:02:55 -0700 From: Jonathan Biggar To: Jon Goldberg CC: interop@omg.org Subject: Re: Issue 1133: Optimization of LOCATION_FORWARD replies References: <3553657C.E47D5540@corp.inprise.com> Jon Goldberg wrote: I like this proposal, but we need to explore a couple of things: 1. If processing of this context is optional on the client side, then the client is stuck making suboptimal requests. Is there a solution to this? 2. If processing of this context is mandatory for the client, what is the pain vs gain ratio for client implementations? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org > > =========================================================== > ===Issue 1133: Optimization of LOCATION_FORWARD replies > =========================================================== > > As review, the basic issue is that if you want to forward > a client to a hashed-down IOR when a request is received, > a roundtrip is wasted because the LOCATION_FORWARD reply > must be sent back, and then the client must resend the > request with the new key. > > We'd like to add a reply > service context that contains the forward IOR, so the > client can get a reply to the first (non-optimal) request > and then can use the new IOR for subsequent requests. > This change is backward-compatible, because the reply > service context will be ignored by previous versions. > > The following specific changes to Ch. 13, GIOP are proposed: > > **Section 13.6, after paragraph 2 on page 13-33 of CORBA2.2 > add the following paragraph: > > Further optimization over the use of LOCATION_FORWARD replies > may be attained by using a LocateForwardContext service context. > The service context may be included in any non-forwarding > reply (e.g. NO_EXCEPTION, USER_EXCEPTION, SYSTEM_EXCEPTION) > to indicate that the request has been processed and that for > future requests, the forwarded object reference should > be used. This allows a server to forward a client to > using an optimized object reference for the duration of the > connection without consuming an extra roundtrip as would > be necessary with a LOCATION_FORWARD reply. The > LocationForwardContext is defined as follows: > > module GIOP { //IDL > const IOP::ServiceId LocationForwardContextId = @@@; > > typedef short AddressLongevity; > const AddressLongevity CONNECTION = 0; > const AddressLongevity PERMANENT = 1; > > struct LocationForwardContext { > AddressLongevity lifetime; > TargetAddress forward_address; > }; > }; > > A service context with tag LocationForwardContextId contains > a CDR encapsulation holding a LocationForwardContext structure. > The forward_reference member is the object reference to which > the client is forwarded for future requests. The lifetime > member can have one of the following values: > > -CONNECTION - The forward_address is valid for the lifetime > of the current connection only. Once the connection on which > the location forwarding information was sent is closed, the > client ORB shall use the original address specified in the > initial object reference. > -PERMANENT - The forward_address is valid after the current > connection is closed. The new reference is considered to replace > the initial object reference. Return-Path: From: Jeffrey Mischkinsky Subject: Re: Issue 1133: Optimization of LOCATION_FORWARD replies To: goldberg@corp.inprise.com (Jon Goldberg) Date: Fri, 8 May 1998 15:29:38 -0700 (PDT) Cc: interop@omg.org Hi, AS part of this Could we also, as some of us have discussed, tighten up the wording WRT locate forward permanent and make the "permanent" mean just that, and take out the weasel words which say that this is a "hint". From the various "hallway discussions" i've heard on this topic, the intent of adding this was more than a "hint". thx, jeff 'Jon Goldberg' writes: > > Hi Folks- > Here's a starter proposal for solving issue #1133 along with some > background explanation... > > take care, > Jon > > =========================================================== > ===Issue 1133: Optimization of LOCATION_FORWARD replies > =========================================================== > > As review, the basic issue is that if you want to forward > a client to a hashed-down IOR when a request is received, > a roundtrip is wasted because the LOCATION_FORWARD reply > must be sent back, and then the client must resend the > request with the new key. > > We'd like to add a reply > service context that contains the forward IOR, so the > client can get a reply to the first (non-optimal) request > and then can use the new IOR for subsequent requests. > This change is backward-compatible, because the reply > service context will be ignored by previous versions. > > The following specific changes to Ch. 13, GIOP are proposed: > > **Section 13.6, after paragraph 2 on page 13-33 of CORBA2.2 > add the following paragraph: > > Further optimization over the use of LOCATION_FORWARD replies > may be attained by using a LocateForwardContext service context. > The service context may be included in any non-forwarding > reply (e.g. NO_EXCEPTION, USER_EXCEPTION, SYSTEM_EXCEPTION) > to indicate that the request has been processed and that for > future requests, the forwarded object reference should > be used. This allows a server to forward a client to > using an optimized object reference for the duration of the > connection without consuming an extra roundtrip as would > be necessary with a LOCATION_FORWARD reply. The > LocationForwardContext is defined as follows: > > module GIOP { //IDL > const IOP::ServiceId LocationForwardContextId = @@@; > > typedef short AddressLongevity; > const AddressLongevity CONNECTION = 0; > const AddressLongevity PERMANENT = 1; > > struct LocationForwardContext { > AddressLongevity lifetime; > TargetAddress forward_address; > }; > }; > > A service context with tag LocationForwardContextId contains > a CDR encapsulation holding a LocationForwardContext structure. > The forward_reference member is the object reference to which > the client is forwarded for future requests. The lifetime > member can have one of the following values: > > -CONNECTION - The forward_address is valid for the lifetime > of the current connection only. Once the connection on which > the location forwarding information was sent is closed, the > client ORB shall use the original address specified in the > initial object reference. > -PERMANENT - The forward_address is valid after the current > connection is closed. The new reference is considered to replace > the initial object reference. > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@corp.inprise.com +1 650-312-5158 jeffm@visigenic.com +1 650-312-5158 Return-Path: Sender: jon@floorboard.com Date: Fri, 08 May 1998 16:17:58 -0700 From: Jonathan Biggar To: Jeffrey Mischkinsky CC: Jon Goldberg , interop@omg.org Subject: Re: Issue 1133: Optimization of LOCATION_FORWARD replies References: <199805082229.PAA29178@wheel.dcn.davis.ca.us> Jeffrey Mischkinsky wrote: > > Hi, > AS part of this Could we also, as some of us have discussed, > tighten up the > wording WRT locate forward permanent and make the "permanent" mean > just > that, and take out the weasel words which say that this is a > "hint". > From the various "hallway discussions" i've heard on this topic, > the intent > of adding this was more than a "hint". Nice idea, but until someone comes up with an API for the ORB to notify the application that the IOR has changed permanently so that the application can save the new IOR in its persistent store, we can't do anything more than "hint". -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Fri, 8 May 1998 19:16:35 -0600 From: Javier Lopez-Martin To: interop@omg.org, goldberg@corp.inprise.com Subject: Re: Issue 1133: Optimization of LOCATION_FORWARD replies Content-Md5: 8VZ3WLg5VkQvuOuzmiJ1bg== Hello Jon, I don't have a strong opinion on this issue, and I'm no expert on GIOP either, but I think this might be non-backwards compatible. Imagine the situation where the client is not aware of this new LocationForward Context. The client will send a request to a server, that will in turn forward the request to the new "home" for the object. Then, the new server will respond, attaching the ContextId. When the client receives the response, the Context is dropped (not understood). The next time the same object reference is used, the same scenario above will happen, so nothing is gained, in fact, each interaction involves three network jumps ... Besides, there is no way for the intermediate party to know whether the client will or will not understand the new service context, so nothing may be done to prevent the above scenario from happening. Please, correct me if I am wrong, but I believe the above scenario might very well happen, and will not have the desired consequences. Regards, Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com > Hi Folks- > Here's a starter proposal for solving issue #1133 along with some > background explanation... > > take care, > Jon > > =========================================================== > ===Issue 1133: Optimization of LOCATION_FORWARD replies > =========================================================== > > As review, the basic issue is that if you want to forward > a client to a hashed-down IOR when a request is received, > a roundtrip is wasted because the LOCATION_FORWARD reply > must be sent back, and then the client must resend the > request with the new key. > > We'd like to add a reply > service context that contains the forward IOR, so the > client can get a reply to the first (non-optimal) request > and then can use the new IOR for subsequent requests. > This change is backward-compatible, because the reply > service context will be ignored by previous versions. > > The following specific changes to Ch. 13, GIOP are proposed: > > **Section 13.6, after paragraph 2 on page 13-33 of CORBA2.2 > add the following paragraph: > > Further optimization over the use of LOCATION_FORWARD replies > may be attained by using a LocateForwardContext service context. > The service context may be included in any non-forwarding > reply (e.g. NO_EXCEPTION, USER_EXCEPTION, SYSTEM_EXCEPTION) > to indicate that the request has been processed and that for > future requests, the forwarded object reference should > be used. This allows a server to forward a client to > using an optimized object reference for the duration of the > connection without consuming an extra roundtrip as would > be necessary with a LOCATION_FORWARD reply. The > LocationForwardContext is defined as follows: > > module GIOP { //IDL > const IOP::ServiceId LocationForwardContextId = @@@; > > typedef short AddressLongevity; > const AddressLongevity CONNECTION = 0; > const AddressLongevity PERMANENT = 1; > > struct LocationForwardContext { > AddressLongevity lifetime; > TargetAddress forward_address; > }; > }; > > A service context with tag LocationForwardContextId contains > a CDR encapsulation holding a LocationForwardContext structure. > The forward_reference member is the object reference to which > the client is forwarded for future requests. The lifetime > member can have one of the following values: > > -CONNECTION - The forward_address is valid for the lifetime > of the current connection only. Once the connection on which > the location forwarding information was sent is closed, the > client ORB shall use the original address specified in the > initial object reference. > -PERMANENT - The forward_address is valid after the current > connection is closed. The new reference is considered to replace > the initial object reference. Return-Path: From: Jeffrey Mischkinsky Subject: Re: Issue 1133: Optimization of LOCATION_FORWARD replies To: jon@floorboard.com (Jonathan Biggar) Date: Sat, 9 May 1998 14:03:51 -0700 (PDT) Cc: jmischki@wheel.dcn.davis.ca.us, goldberg@corp.inprise.com, interop@omg.org 'Jonathan Biggar' writes: > > Jeffrey Mischkinsky wrote: > > > > Hi, > > AS part of this Could we also, as some of us have discussed, > tighten up the > > wording WRT locate forward permanent and make the "permanent" > mean just > > that, and take out the weasel words which say that this is a > "hint". > > From the various "hallway discussions" i've heard on this topic, > the intent > > of adding this was more than a "hint". > > Nice idea, but until someone comes up with an API for the ORB to > notify > the application that the IOR has changed permanently so that the > application can save the new IOR in its persistent store, we can't > do > anything more than "hint". That would be required if in "application land", the app was going to "re-register" the new obj ref, with whatever source it got it from > originally. While that might be desireable, i don't believe that was the intention of this feature. What i'm suggesting is a way for the ORB runtime to be able to count on the "new location" without having to go back and make the extra call. The orb implementation can choose to "remember" the new location (or not i suppose) however it does. I suppose the "more persistent" its memory, the better the orb implementation. jeff > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@corp.inprise.com +1 650-312-5158 jeffm@visigenic.com +1 650-312-5158 Return-Path: Sender: jon@floorboard.com Date: Sat, 09 May 1998 14:47:01 -0700 From: Jonathan Biggar To: Jeffrey Mischkinsky CC: goldberg@corp.inprise.com, interop@omg.org Subject: Re: Issue 1133: Optimization of LOCATION_FORWARD replies References: <199805092103.OAA07075@wheel.dcn.davis.ca.us> > > > AS part of this Could we also, as some of us have discussed, tighten up the > > > wording WRT locate forward permanent and make the "permanent" mean just > > > that, and take out the weasel words which say that this is a "hint". > > > From the various "hallway discussions" i've heard on this topic, the intent > > > of adding this was more than a "hint". > > > > Nice idea, but until someone comes up with an API for the ORB to notify > > the application that the IOR has changed permanently so that the > > application can save the new IOR in its persistent store, we can't do > > anything more than "hint". > That would be required if in "application land", the app was going to > "re-register" the new obj ref, with whatever source it got it from originally. > While that might be desireable, i don't believe that was the intention > of this feature. > > What i'm suggesting is a way for the ORB runtime to be able to count on the > "new location" without having to go back and make the extra call. > The orb implementation can choose to "remember" the new location (or not i > suppose) however it does. I suppose the "more persistent" its memory, the > better the orb implementation. Yeah, you might be able to make something like that work, while still improving efficiency. I could see four levels of support (nothing official here, just implementation suggestsions): 1. The ORB run-time throws away the original IOR and replaces it with the new one, so that any new connections with the IOR go immediately to the new source. However, the ORB does not remember it beyond the lifetime of the application. 2. The ORB run-time stores the IOR in a machine-wide persistent cache, and use the cache to translate old IORs into new ones at run-time. 3. The ORB run-time stores the IOR in an application specific persistent cache, and uses the cache to translate old IORs into new ones. This one would be faster than #2, but would use more space due to redundant entries in different application caches. 4. The ORB (in the future if we define an API) could notify the application that the IOR has changed, so that it can update whatever persistent store it used to get the IOR in the first place. I still think that this needs to remain a "hint" however, because it should be legal to ignore the "hint", which is the right thing to do for an application that only wants to send one request to the object, and has no persistent store of its own. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: From: Jeffrey Mischkinsky Subject: Re: Issue 1133: Optimization of LOCATION_FORWARD replies To: jon@floorboard.com (Jonathan Biggar) Date: Sat, 9 May 1998 20:11:24 -0700 (PDT) Cc: jmischki@wheel.dcn.davis.ca.us, goldberg@corp.inprise.com, interop@omg.org 'Jonathan Biggar' writes: [ previous discussion elided ] > > > What i'm suggesting is a way for the ORB runtime to be able to count on the > > "new location" without having to go back and make the extra call. > > The orb implementation can choose to "remember" the new location (or not i > > suppose) however it does. I suppose the "more persistent" its memory, the > > better the orb implementation. > > Yeah, you might be able to make something like that work, while still > improving efficiency. I could see four levels of support (nothing > official here, just implementation suggestsions): > > 1. The ORB run-time throws away the original IOR and replaces it with > the new one, so that any new connections with the IOR go immediately to > the new source. However, the ORB does not remember it beyond the > lifetime of the application. > > 2. The ORB run-time stores the IOR in a machine-wide persistent cache, > and use the cache to translate old IORs into new ones at run-time. > > 3. The ORB run-time stores the IOR in an application specific > persistent cache, and uses the cache to translate old IORs into new > ones. This one would be faster than #2, but would use more space due to > redundant entries in different application caches. > > 4. The ORB (in the future if we define an API) could notify the > application that the IOR has changed, so that it can update whatever > persistent store it used to get the IOR in the first place. > > I still think that this needs to remain a "hint" however, because it > should be legal to ignore the "hint", which is the right thing to do for > an application that only wants to send one request to the object, and > has no persistent store of its own. Those 4 things are all good suggestions and could be done, the first 3 w/o any spec changes. But without making it more than a "hint", they're probably not worth doing. The (only) guarantee i'm suggesting is that the new reference will continue to work. I wasn't suggesting that the it also mean that the old one will no longer work. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@corp.inprise.com +1 650-312-5158 jeffm@visigenic.com +1 650-312-5158 Return-Path: Sender: jon@floorboard.com Date: Sat, 09 May 1998 20:55:19 -0700 From: Jonathan Biggar To: Jeffrey Mischkinsky CC: goldberg@corp.inprise.com, interop@omg.org Subject: Re: Issue 1133: Optimization of LOCATION_FORWARD replies References: <199805100311.UAA16062@wheel.dcn.davis.ca.us> Jeffrey Mischkinsky wrote: > Those 4 things are all good suggestions and could be done, the first 3 w/o any > spec changes. But without making it more than a "hint", they're probably > not worth doing. The (only) guarantee i'm suggesting is that the new reference > will continue to work. I wasn't suggesting that the it also mean that the > old one will no longer work. Ok, I see what you mean now. We are talking about two different "hints". The spec should be clarified to state that both the old and new IORs are still valid after receiving a permanent LOCATION_FORWARD reply, so that clients that ignore the new IOR and clients that forget the old IOR are both safe. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Sun, 10 May 1998 18:46:53 -0700 From: Jon Goldberg To: Javier Lopez-Martin CC: interop@omg.org Subject: Re: Issue 1133: Optimization of LOCATION_FORWARD replies References: Hi- I don't think we really need to worry about this scenario, particularly with respect to backward compatibility. If the version of GIOP for the request is < 1.2, the forwarder just has to reply with the location_forward response rather than using the service context. take care, Jon Javier Lopez-Martin wrote: > > Hello Jon, > > I don't have a strong opinion on this issue, and I'm no expert > on GIOP either, but I think this might be non-backwards compatible. > > Imagine the situation where the client is not aware of this new > LocationForward Context. The client will send a request to a > server, that will in turn forward the request to the new "home" > for the object. Then, the new server will respond, attaching > the ContextId. When the client receives the response, the > Context is dropped (not understood). The next time the same > object reference is used, the same scenario above will happen, > so nothing is gained, in fact, each interaction involves three > network jumps ... Besides, there is no way for the intermediate > party to know whether the client will or will not understand the > new service context, so nothing may be done to prevent the above > scenario from happening. > > Please, correct me if I am wrong, but I believe the above scenario > might very well happen, and will not have the desired consequences. > > Regards, > > Javier Lopez-Martin > Hewlett-Packard Co > javier@cnd.hp.com > > > > Hi Folks- > > Here's a starter proposal for solving issue #1133 along with some > > background explanation... > > > > take care, > > Jon > > > > =========================================================== > > ===Issue 1133: Optimization of LOCATION_FORWARD replies > > =========================================================== > > > > As review, the basic issue is that if you want to forward > > a client to a hashed-down IOR when a request is received, > > a roundtrip is wasted because the LOCATION_FORWARD reply > > must be sent back, and then the client must resend the > > request with the new key. > > > > We'd like to add a reply > > service context that contains the forward IOR, so the > > client can get a reply to the first (non-optimal) request > > and then can use the new IOR for subsequent requests. > > This change is backward-compatible, because the reply > > service context will be ignored by previous versions. > > > > The following specific changes to Ch. 13, GIOP are proposed: > > > > **Section 13.6, after paragraph 2 on page 13-33 of CORBA2.2 > > add the following paragraph: > > > > Further optimization over the use of LOCATION_FORWARD replies > > may be attained by using a LocateForwardContext service context. > > The service context may be included in any non-forwarding > > reply (e.g. NO_EXCEPTION, USER_EXCEPTION, SYSTEM_EXCEPTION) > > to indicate that the request has been processed and that for > > future requests, the forwarded object reference should > > be used. This allows a server to forward a client to > > using an optimized object reference for the duration of the > > connection without consuming an extra roundtrip as would > > be necessary with a LOCATION_FORWARD reply. The > > LocationForwardContext is defined as follows: > > > > module GIOP { //IDL > > const IOP::ServiceId LocationForwardContextId = @@@; > > > > typedef short AddressLongevity; > > const AddressLongevity CONNECTION = 0; > > const AddressLongevity PERMANENT = 1; > > > > struct LocationForwardContext { > > AddressLongevity lifetime; > > TargetAddress forward_address; > > }; > > }; > > > > A service context with tag LocationForwardContextId contains > > a CDR encapsulation holding a LocationForwardContext structure. > > The forward_reference member is the object reference to which > > the client is forwarded for future requests. The lifetime > > member can have one of the following values: > > > > -CONNECTION - The forward_address is valid for the lifetime > > of the current connection only. Once the connection on which > > the location forwarding information was sent is closed, the > > client ORB shall use the original address specified in the > > initial object reference. > > -PERMANENT - The forward_address is valid after the current > > connection is closed. The new reference is considered to replace > > the initial object reference. Return-Path: Sender: goldberg@corp.inprise.com Date: Mon, 11 May 1998 18:16:10 -0700 From: Jon Goldberg To: Jonathan Biggar CC: goldberg@visigenic.com, interop@omg.org Subject: Re: Issue 1133: Optimization of LOCATION_FORWARD replies References: <3553657C.E47D5540@corp.inprise.com> Jonathan Biggar wrote: > > Jon Goldberg wrote: > > I like this proposal, but we need to explore a couple of things: > > 1. If processing of this context is optional on the client side, > then > the > client is stuck making suboptimal requests. Is there a solution to > this? this seems like an implementation issue to me. If the server checks for GIOP version, it can use the old remarshal-and-resend location forward reply to force optimization. The server could also check and if it has tried to use the forward but the client sends new messages with the full object key the server can force the client to pay the one-time resend cost by sending the LOCATION_FORWARD reply. again, I think this is all implementation detail. As long as interoperability works, I think we're fine. If some ORB implementation doesn't choose to look at this service context, that ORB is a lower-quality product than one that does. > 2. If processing of this context is mandatory for the client, what is > the pain vs gain ratio for client implementations? I'd keep it optional as described above, but it isn't particularly painful for the client. If repeated requests are going to be made, the gain is significant (since object keys are probably only going to grow as a result of the POA specification). take care, Jon > > > > =========================================================== > > ===Issue 1133: Optimization of LOCATION_FORWARD replies > > =========================================================== > > > > As review, the basic issue is that if you want to forward > > a client to a hashed-down IOR when a request is received, > > a roundtrip is wasted because the LOCATION_FORWARD reply > > must be sent back, and then the client must resend the > > request with the new key. > > > > We'd like to add a reply > > service context that contains the forward IOR, so the > > client can get a reply to the first (non-optimal) request > > and then can use the new IOR for subsequent requests. > > This change is backward-compatible, because the reply > > service context will be ignored by previous versions. > > > > The following specific changes to Ch. 13, GIOP are proposed: > > > > **Section 13.6, after paragraph 2 on page 13-33 of CORBA2.2 > > add the following paragraph: > > > > Further optimization over the use of LOCATION_FORWARD replies > > may be attained by using a LocateForwardContext service context. > > The service context may be included in any non-forwarding > > reply (e.g. NO_EXCEPTION, USER_EXCEPTION, SYSTEM_EXCEPTION) > > to indicate that the request has been processed and that for > > future requests, the forwarded object reference should > > be used. This allows a server to forward a client to > > using an optimized object reference for the duration of the > > connection without consuming an extra roundtrip as would > > be necessary with a LOCATION_FORWARD reply. The > > LocationForwardContext is defined as follows: > > > > module GIOP { //IDL > > const IOP::ServiceId LocationForwardContextId = @@@; > > > > typedef short AddressLongevity; > > const AddressLongevity CONNECTION = 0; > > const AddressLongevity PERMANENT = 1; > > > > struct LocationForwardContext { > > AddressLongevity lifetime; > > TargetAddress forward_address; > > }; > > }; > > > > A service context with tag LocationForwardContextId contains > > a CDR encapsulation holding a LocationForwardContext structure. > > The forward_reference member is the object reference to which > > the client is forwarded for future requests. The lifetime > > member can have one of the following values: > > > > -CONNECTION - The forward_address is valid for the lifetime > > of the current connection only. Once the connection on which > > the location forwarding information was sent is closed, the > > client ORB shall use the original address specified in the > > initial object reference. > > -PERMANENT - The forward_address is valid after the current > > connection is closed. The new reference is considered to replace > > the initial object reference. Return-Path: Sender: goldberg@inprise.com Date: Thu, 14 May 1998 18:04:26 -0700 From: Jon Goldberg To: ter@holta.ho.lucent.com CC: interop@omg.org, orb_revision@omg.org, goldberg@inprise.com Subject: Interop issue 1133: Optimization of LOCATION_FORWARD replies Hi Tom- I'm not sure what happened here. I seem to have stopped getting interop mail sometime earlier this week and missed your mail that initiated voting. It has just come to my attention that my proposed solution to Issue 1133 was dropped. It seemed pretty complete (to me) and I didn't see any unanswered discussion on the list that poked holes in the resolution. Since discussion had ended, I had assumed no one had additional problems. Is there a reason it was left off the list? I've attached the proposal to this message. take care, Jon =========================================================== ===Issue 1133: Optimization of LOCATION_FORWARD replies =========================================================== As review, the basic issue is that if you want to forward a client to a hashed-down IOR when a request is received, a roundtrip is wasted because the LOCATION_FORWARD reply must be sent back, and then the client must resend the request with the new key. We'd like to add a reply service context that contains the forward IOR, so the client can get a reply to the first (non-optimal) request and then can use the new IOR for subsequent requests. This change is backward-compatible, because the reply service context will be ignored by previous versions. The following specific changes to Ch. 13, GIOP are proposed: **Section 13.6, after paragraph 2 on page 13-33 of CORBA2.2 add the following paragraph: Further optimization over the use of LOCATION_FORWARD replies may be attained by using a LocateForwardContext service context. The service context may be included in any non-forwarding reply (e.g. NO_EXCEPTION, USER_EXCEPTION, SYSTEM_EXCEPTION) to indicate that the request has been processed and that for future requests, the forwarded object reference should be used. This allows a server to forward a client to using an optimized object reference for the duration of the connection without consuming an extra roundtrip as would be necessary with a LOCATION_FORWARD reply. The LocationForwardContext is defined as follows: module GIOP { //IDL const IOP::ServiceId LocationForwardContextId = @@@; typedef short AddressLongevity; const AddressLongevity CONNECTION = 0; const AddressLongevity PERMANENT = 1; struct LocationForwardContext { AddressLongevity lifetime; TargetAddress forward_address; }; }; A service context with tag LocationForwardContextId contains a CDR encapsulation holding a LocationForwardContext structure. The forward_reference member is the object reference to which the client is forwarded for future requests. The lifetime member can have one of the following values: -CONNECTION - The forward_address is valid for the lifetime of the current connection only. Once the connection on which the location forwarding information was sent is closed, the client ORB shall use the original address specified in the initial object reference. -PERMANENT - The forward_address is valid after the current connection is closed. The new reference is considered to replace the initial object reference.