Issue 5662: Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 (corba-rtf) Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com) Nature: Uncategorized Issue Severity: Summary: It is impossible to use the routing protocol to communicate with servers that only support GIOP 1.0 or 1.1, because the information contained in struct MessageBody does not contain enough information to determine the alignment requirements of the contents of body member. The GIOP 1.0 & 1.1 RequestHeader struct contain an octet sequence for principle as the last member, and specify no alignment requirements for the message body. Thus, it is impossible for the final router to determine the proper alignment for the message body when marshalling a GIOP Request message for delivery to the target object. The same problem applies to the Response message. Resolution: Revised Text: Actions taken: September 26, 2002: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== Sender: jbiggar@Resonate.com Date: Wed, 25 Sep 2002 17:14:31 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: issues@omg.org, corba-rtf@omg.org Subject: Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 It is impossible to use the routing protocol to communicate with servers that only support GIOP 1.0 or 1.1, because the information contained in struct MessageBody does not contain enough information to determine the alignment requirements of the contents of body member. The GIOP 1.0 & 1.1 RequestHeader struct contain an octet sequence for principle as the last member, and specify no alignment requirements for the message body. Thus, it is impossible for the final router to determine the proper alignment for the message body when marshalling a GIOP Request message for delivery to the target object. The same problem applies to the Response message. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 25 Sep 2002 17:50:12 -0700 From: Ke Jin Subject: Re: Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 To: Jonathan Biggar Cc: issues@omg.org, corba-rtf@omg.org Organization: Borland Software Corp. X-Mailer: Mozilla 4.05 [en] (WinNT; U) This is not an issue. It works this way, the client ORB first marshals a normal GIOP request as if it is going to be directly(i.e. synchronously) sent to the target. Then, the client ORB takes the request version, target, service context list and the "already marshalled payload" out of this GIOP request message and puts them into a Messaging::RequestInfo and sends it to a router using send_request(). The final router simply recreates the original normal GIOP request using the same version, target, service context list and the already marshalled payload body in this RequestInfo. This means, the GIOP request recreated by the final router will have the exactly same header size as the one created by the original client and no need to adjust the alignment of the payload which was originally marshalled by the client based on the same request header size. Regards, Ke Jonathan Biggar wrote: > It is impossible to use the routing protocol to communicate with servers > that only support GIOP 1.0 or 1.1, because the information contained in > struct MessageBody does not contain enough information to determine the > alignment requirements of the contents of body member. The GIOP 1.0 & > 1.1 RequestHeader struct contain an octet sequence for principle as the > last member, and specify no alignment requirements for the message > body. Thus, it is impossible for the final router to determine the > proper alignment for the message body when marshalling a GIOP Request > message for delivery to the target object. > > The same problem applies to the Response message. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Sender: jbiggar@Resonate.com Date: Fri, 27 Sep 2002 12:54:02 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Juergen Boldt Subject: Re: [Fwd: Messaging Routing Protocol is broken for GIOP 1.0&1.1] Juergen Boldt wrote: > > wanna send the thread for the archive? Here's the relevant thread: Jonathan Biggar wrote: > Then how do you explain the text in this section: > > 22.14.1.1 MessageBody > > This structure is used to wrap the marshaled GIOP message data (either > request > > arguments or reply data) to support repackaging as the request components > > around that data (such as service contexts or object key) change due to > > Routing. Since GIOP 1.2 Request and Reply Bodies are always aligned to an > > 8-octet boundary, it is necessary to keep track of the > > > o data and the length of that data as a sequence of octet, and > > o the byte order with which that data was originally marshaled. > > which strongly implies that the object key and/or service context list > can change in size, which will affect the alignment of the body of the > Request message for GIOP 1.0 and 1.1. Ke Jin wrote: > Yes, I agree with you. Also, the final router doesn't know the final router > has no knowledge on the principal size. So, even if the key and service > context list are intact, the final router still can't recreate the request > unless it assumes a size of principal (e.g. 0 length). -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 23 Oct 2002 16:59:59 -0400 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar , corba-rtf@omg.org Subject: Question about 5662 None of the AMI stuff is supposed to work with GIOP 1.1 or 1.0. The Messaging related contexts are optional in 1.2 and mandatory in 1.3. Given that, I was wondering if this really is an issue. Thanks, Jishnu. ______________________________________________________________________ Issue 5662: Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 (corba-rtf) Click here for this issue's archive. Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) Nature: Uncategorized Issue Severity: Summary: It is impossible to use the routing protocol to communicate with servers that only support GIOP 1.0 or 1.1, because the information contained in struct MessageBody does not contain enough information to determine the alignment requirements of the contents of body member. The GIOP 1.0 & 1.1 RequestHeader struct contain an octet sequence for principle as the last member, and specify no alignment requirements for the message body. Thus, it is impossible for the final router to determine the proper alignment for the message body when marshalling a GIOP Request message for delivery to the target object. Sender: jbiggar@Resonate.com Date: Wed, 23 Oct 2002 16:32:34 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Question about 5662 Jishnu Mukerji wrote: > > None of the AMI stuff is supposed to work with GIOP 1.1 or 1.0. The > Messaging related contexts are optional in 1.2 and mandatory in 1.3. > Given that, I was wondering if this really is an issue. True, the AMI contexts can't be transmistted, but 22.4 says: "Asynchronous Method Invocations allow clients to make non-blocking requests on a target. The AMI is treated as a client-side language mapping issue only. In most cases, server-side implementations are not required to change as from the server-side programmer s point of view all invocations can be treated identically regardless of their synchronicity characteristics. In certain situations, such as with transactional servers, the asynchrony of a client does matter and requires server-side changes if expected to handle transactional asynchronous requests. This specific issue is addressed in Appendix C, Section B.2.1, Transaction Service, on page 22-89." There's no exception in there for servers that only support GIOP 1.1 or less. This is still a problem, since it breaks object transparancy, and even if banned leaves the question of what to do if a router tries to talk to an object that only supports GIOP 1.1 or less (for example, if FORWARDed from a 1.2 object to a 1.1 object.) > ______________________________________________________________________ > > Issue 5662: Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 > (corba-rtf) > > Click here for this issue's archive. > Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) > Nature: Uncategorized Issue > Severity: > Summary: > > It is impossible to use the routing protocol to communicate with servers > that only support GIOP 1.0 or 1.1, because the information contained in > struct MessageBody does not contain enough information to determine the > alignment requirements of the contents of body member. The GIOP 1.0 & > 1.1 RequestHeader struct contain an octet sequence for principle as the > last member, and specify no alignment requirements for the message > body. Thus, it is impossible for the final router to determine the > proper alignment for the message body when marshalling a GIOP Request > message for delivery to the target object. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 24 Oct 2002 11:35:44 -0400 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: corba-rtf@omg.org Subject: Re: Question about 5662 The fundamental problem with doing any fixes to 1.0 or 1.1 to make this work is that as soon as you do the fix the resulting GIOP version ceases to be 1.0 or 1.1. And secondly if I were a product manager I would find it beyond impossible to justify fixing a deployed 1.0 or 1.1 product for this purpose (rather than simply upgrading to 1.2 or later). So while it may be nice to fix this from a theoretical perspective I don't see any practical use of fixing up GIOP 1.0 or 1.1 to make this work. Of course others may have other opinions. Jishnu. Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > > None of the AMI stuff is supposed to work with GIOP 1.1 or 1.0. The > > Messaging related contexts are optional in 1.2 and mandatory in 1.3. > > Given that, I was wondering if this really is an issue. > > True, the AMI contexts can't be transmistted, but 22.4 says: > > "Asynchronous Method Invocations allow clients to make non-blocking > requests on a target. The AMI is treated as a client-side language > mapping issue only. In most cases, server-side implementations are not > required to change as from the server-side programmer s point of view > all invocations can be treated identically regardless of their > synchronicity characteristics. In certain situations, such as with > transactional servers, the asynchrony of a client does matter and > requires server-side changes if expected to handle transactional > asynchronous requests. This specific issue is addressed in Appendix C, > Section B.2.1, Transaction Service, on page 22-89." > > There's no exception in there for servers that only support GIOP 1.1 or > less. This is still a problem, since it breaks object transparancy, and > even if banned leaves the question of what to do if a router tries to > talk to an object that only supports GIOP 1.1 or less (for example, if > FORWARDed from a 1.2 object to a 1.1 object.) > > > ______________________________________________________________________ > > > > Issue 5662: Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 > > (corba-rtf) > > > > Click here for this issue's archive. > > Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) > > Nature: Uncategorized Issue > > Severity: > > Summary: > > > > It is impossible to use the routing protocol to communicate with servers > > that only support GIOP 1.0 or 1.1, because the information contained in > > struct MessageBody does not contain enough information to determine the > > alignment requirements of the contents of body member. The GIOP 1.0 & > > 1.1 RequestHeader struct contain an octet sequence for principle as the > > last member, and specify no alignment requirements for the message > > body. Thus, it is impossible for the final router to determine the > > proper alignment for the message body when marshalling a GIOP Request > > message for delivery to the target object. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Jishnu Mukerji Senior Systems Architect 1001 Frontier Road, Suite 300 Technology Office Bridgewater NJ 08807, USA Software Global Business Unit Tel: +1 908 243 8924 Hewlett-Packard Company Fax: +1 908 243 8850 mailto: jishnu@hp.com Sender: jbiggar@Resonate.com Date: Thu, 24 Oct 2002 09:23:26 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: corba-rtf@omg.org Subject: Re: Question about 5662 Jishnu Mukerji wrote: > > The fundamental problem with doing any fixes to 1.0 or 1.1 to make this > work is that as soon as you do the fix the resulting GIOP version ceases > to be 1.0 or 1.1. And secondly if I were a product manager I would find > it beyond impossible to justify fixing a deployed 1.0 or 1.1 product for > this purpose (rather than simply upgrading to 1.2 or later). > > So while it may be nice to fix this from a theoretical perspective I > don't see any practical use of fixing up GIOP 1.0 or 1.1 to make this > work. Of course others may have other opinions. Oh sure, you can't touch GIOP 1.0 or 1.1. But what you can do is upgrade the routing protocol somehow so that it can interoperate with GIOP 1.0 and 1.1 servers. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 04 Nov 2002 16:15:12 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: corba-rtf@omg.org Subject: Re: Question about 5662 Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > > None of the AMI stuff is supposed to work with GIOP 1.1 or 1.0. The > > Messaging related contexts are optional in 1.2 and mandatory in 1.3. > > Given that, I was wondering if this really is an issue. > > True, the AMI contexts can't be transmistted, but 22.4 says: > > "Asynchronous Method Invocations allow clients to make non-blocking > requests on a target. The AMI is treated as a client-side language > mapping issue only. In most cases, server-side implementations are not > required to change as from the server-side programmer s point of view > all invocations can be treated identically regardless of their > synchronicity characteristics. In certain situations, such as with > transactional servers, the asynchrony of a client does matter and > requires server-side changes if expected to handle transactional > asynchronous requests. This specific issue is addressed in Appendix C, > Section B.2.1, Transaction Service, on page 22-89." > > There's no exception in there for servers that only support GIOP 1.1 or > less. This is still a problem, since it breaks object transparancy, and > even if banned leaves the question of what to do if a router tries to > talk to an object that only supports GIOP 1.1 or less (for example, if > FORWARDed from a 1.2 object to a 1.1 object.) Right. I think we should focus on that specific issue. My take is that unloess the specific changes to a server running pre-1.2 GIOP are spelled out we should not get into the business of spelling those out. We should certainly deal with the issue if what happens when one of those servers inadvertently gets hit with an unexpected message. So specifically, doesn;t the router know from the GIOP vedrsion that is gets to use with the server in question whether the server is 1.2 or pre-1.2, and in the latter case shouldn't it be able to raise something like NO_IMPLEMENT or some such, that we could specify in the specification for the Router, and be done with it? We could perhaps make the fine distinction between those things that do require a server side change and those that don't too. But given the GIOP message format problems that you mention, its seems to me that the best thing to do would be to say that Messaging stuff does not work with pre-1.2. That is what is said in the conformance table in Chapter 13 in so many wordes, and we should fill in any holes relative to unspecified exceptions etc. to make that more solid. Comments? Jishnu. Sender: jbiggar@Resonate.com Date: Tue, 05 Nov 2002 11:06:43 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Question about 5662 Jishnu Mukerji wrote: > > True, the AMI contexts can't be transmistted, but 22.4 says: > > > > "Asynchronous Method Invocations allow clients to make non-blocking > > requests on a target. The AMI is treated as a client-side language > > mapping issue only. In most cases, server-side implementations are not > > required to change as from the server-side programmer s point of view > > all invocations can be treated identically regardless of their > > synchronicity characteristics. In certain situations, such as with > > transactional servers, the asynchrony of a client does matter and > > requires server-side changes if expected to handle transactional > > asynchronous requests. This specific issue is addressed in Appendix C, > > Section B.2.1, Transaction Service, on page 22-89." > > > > There's no exception in there for servers that only support GIOP 1.1 or > > less. This is still a problem, since it breaks object transparancy, and > > even if banned leaves the question of what to do if a router tries to > > talk to an object that only supports GIOP 1.1 or less (for example, if > > FORWARDed from a 1.2 object to a 1.1 object.) > > Right. I think we should focus on that specific issue. > > My take is that unloess the specific changes to a server running pre-1.2 > GIOP are spelled out we should not get into the business of spelling > those out. We should certainly deal with the issue if what happens when > one of those servers inadvertently gets hit with an unexpected message. > > So specifically, doesn;t the router know from the GIOP vedrsion that is > gets to use with the server in question whether the server is 1.2 or > pre-1.2, and in the latter case shouldn't it be able to raise something > like NO_IMPLEMENT or some such, that we could specify in the > specification for the Router, and be done with it? We could, but I consider that punting, and violates the intent of the Messaging service as it was conceived--that it should work without changing server implementations if transactions are not involved. > We could perhaps make the fine distinction between those things that do > require a server side change and those that don't too. But given the > GIOP message format problems that you mention, its seems to me that the > best thing to do would be to say that Messaging stuff does not work with > pre-1.2. That is what is said in the conformance table in Chapter 13 in > so many wordes, and we should fill in any holes relative to unspecified > exceptions etc. to make that more solid. I don't really think that the table in Chapter 13 says that. It does have limits on the INVOCATION_POLICIES service context and TAG_INV_POLICY, but not on the actual use of a Router to invoke a pre 1.2 server. I'd much rather work to find a solution that increases interoperability than just punting. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 05 Nov 2002 14:36:54 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: corba-rtf@omg.org Subject: Re: Question about 5662 OK, another one for "sense of the RTF" then? Jishnu. Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > True, the AMI contexts can't be transmistted, but 22.4 says: > > > > > > "Asynchronous Method Invocations allow clients to make non-blocking > > > requests on a target. The AMI is treated as a client-side language > > > mapping issue only. In most cases, server-side implementations are not > > > required to change as from the server-side programmer s point of view > > > all invocations can be treated identically regardless of their > > > synchronicity characteristics. In certain situations, such as with > > > transactional servers, the asynchrony of a client does matter and > > > requires server-side changes if expected to handle transactional > > > asynchronous requests. This specific issue is addressed in Appendix C, > > > Section B.2.1, Transaction Service, on page 22-89." > > > > > > There's no exception in there for servers that only support GIOP 1.1 or > > > less. This is still a problem, since it breaks object transparancy, and > > > even if banned leaves the question of what to do if a router tries to > > > talk to an object that only supports GIOP 1.1 or less (for example, if > > > FORWARDed from a 1.2 object to a 1.1 object.) > > > > Right. I think we should focus on that specific issue. > > > > My take is that unloess the specific changes to a server running pre-1.2 > > GIOP are spelled out we should not get into the business of spelling > > those out. We should certainly deal with the issue if what happens when > > one of those servers inadvertently gets hit with an unexpected message. > > > > So specifically, doesn;t the router know from the GIOP vedrsion that is > > gets to use with the server in question whether the server is 1.2 or > > pre-1.2, and in the latter case shouldn't it be able to raise something > > like NO_IMPLEMENT or some such, that we could specify in the > > specification for the Router, and be done with it? > > We could, but I consider that punting, and violates the intent of the > Messaging service as it was conceived--that it should work without > changing server implementations if transactions are not involved. > > > We could perhaps make the fine distinction between those things that do > > require a server side change and those that don't too. But given the > > GIOP message format problems that you mention, its seems to me that the > > best thing to do would be to say that Messaging stuff does not work with > > pre-1.2. That is what is said in the conformance table in Chapter 13 in > > so many wordes, and we should fill in any holes relative to unspecified > > exceptions etc. to make that more solid. > > I don't really think that the table in Chapter 13 says that. It does > have limits on the INVOCATION_POLICIES service context and > TAG_INV_POLICY, but not on the actual use of a Router to invoke a pre > 1.2 server. > > I'd much rather work to find a solution that increases interoperability > than just punting. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Jishnu Mukerji Senior Systems Architect 1001 Frontier Road, Suite 300 Technology Office Bridgewater NJ 08807, USA Software Global Business Unit Tel: +1 908 243 8924 Hewlett-Packard Company Fax: +1 908 243 8850 mailto: jishnu@hp.com Sender: jon@floorboard.com Date: Tue, 05 Nov 2002 12:56:59 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Question about 5662 Jishnu Mukerji wrote: > > OK, another one for "sense of the RTF" then? Perhaps, although in this case, I suspect that not much passion will be involved because I don't know of any real routing implementations yet. I think I'd prefer waiting until I can at least scope out a framework for what the solution would be. > > > So specifically, doesn;t the router know from the GIOP vedrsion that is > > > gets to use with the server in question whether the server is 1.2 or > > > pre-1.2, and in the latter case shouldn't it be able to raise something > > > like NO_IMPLEMENT or some such, that we could specify in the > > > specification for the Router, and be done with it? > > > > We could, but I consider that punting, and violates the intent of the > > Messaging service as it was conceived--that it should work without > > changing server implementations if transactions are not involved. > > > > > We could perhaps make the fine distinction between those things that do > > > require a server side change and those that don't too. But given the > > > GIOP message format problems that you mention, its seems to me that the > > > best thing to do would be to say that Messaging stuff does not work with > > > pre-1.2. That is what is said in the conformance table in Chapter 13 in > > > so many wordes, and we should fill in any holes relative to unspecified > > > exceptions etc. to make that more solid. > > > > I don't really think that the table in Chapter 13 says that. It does > > have limits on the INVOCATION_POLICIES service context and > > TAG_INV_POLICY, but not on the actual use of a Router to invoke a pre > > 1.2 server. > > > > I'd much rather work to find a solution that increases interoperability > > than just punting. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org