Issue 3680: Version and byte order changes when fragmenting messages (interop) (interop) Source: ICL (Mr. Chris Wood, ) Nature: Uncategorized Issue Severity: Summary: It's occoured to me that according to the spec it's allowable for a message to be fragmented and have second and subsequent fragments change the version fields. Having the version change while in the middle of reading a wstring could cause problems, the CDR encoding of version 1.1 strings is always two bytes longer than the corresponding 1.2 encoding, if the version changed while in the middle of reading the wstring the length field would be out by two. Secondly if request IDs are per-protocol rather than per-connection (as aired in issue 3438) then the request ids of the fragments could interfere. I think an extra phrase should be added to the spec with regards to fragmentation, similar to the one regarding byte order: The version of fragments must match the version of the initial message that the fragment extends. Resolution: Close without revision since the spec was already clarified to state this. Revised Text: Actions taken: June 16, 2000: received issue February 27, 2001: closed issue Discussion: End of Annotations:===== From: "Chris Wood" To: Subject: Version and byte order changes when fragmenting messages (interop) Date: Fri, 16 Jun 2000 11:52:12 +1000 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: /~o!!"o6e9^Iad9%VE!! It's occoured to me that according to the spec it's allowable for a message to be fragmented and have second and subsequent fragments change the version fields. Having the version change while in the middle of reading a wstring could cause problems, the CDR encoding of version 1.1 strings is always two bytes longer than the corresponding 1.2 encoding, if the version changed while in the middle of reading the wstring the length field would be out by two. Secondly if request IDs are per-protocol rather than per-connection (as aired in issue 3438) then the request ids of the fragments could interfere. I think an extra phrase should be added to the spec with regards to fragmentation, similar to the one regarding byte order: The version of fragments must match the version of the initial message that the fragment extends. From: Paul Kyzivat To: "'Chris Wood'" , "Interop RTF (E-mail)" Subject: RE: Version and byte order changes when fragmenting messages (int erop) Date: Mon, 19 Jun 2000 13:11:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" X-UIDL: a#?e9Z5;e9YUb!!al0!! This has been discussed before, at least w/r/t byte order, and it was decided that the byte order may not change in a fragment. (I thought this was adopted, but I don't have the current text handy.) Regarding the others, given that we have decided that multiple versions can coexist on a connection, I have concluded that the only sensible way for this to work is to first demultiplex the messages on the connection based on version. In principle, each version could then reuse the same request ids without confusion. Based on that, fragments by definition have the same version as the message they continue. Our giop 1.2 implementation is based on this assumption, and will happily accept interleaved messages and fragments of different versions that are using the same request id. But to preserve sanity, and in the expectation that not all orbs will be so forgiving, we are assigning request ids in a unified way across versions so that this sort of behavior will never be initiated by us. Paul > -----Original Message----- > From: Chris Wood [mailto:wood@intalio.com] > Sent: Thursday, June 15, 2000 9:52 PM > To: issues@omg.org > Subject: Version and byte order changes when fragmenting messages > (interop) > > > > It's occoured to me that according to the spec it's allowable for > a message to be fragmented and have second and subsequent > fragments change the version fields. > > Having the version change while in the middle of reading a > wstring could cause problems, the CDR encoding of version 1.1 > strings is always two bytes longer than the corresponding 1.2 > encoding, if the version changed while in the middle of reading > the wstring the length field would be out by two. > > Secondly if request IDs are per-protocol rather than > per-connection (as aired in issue 3438) then the request ids of > the fragments could interfere. > > I think an extra phrase should be added to the spec with regards > to fragmentation, similar to the one regarding byte order: > > The version of fragments must match the version of the > initial message that > the fragment extends. > Date: Mon, 19 Jun 2000 12:23:57 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "'Chris Wood'" , "Interop RTF (E-mail)" Subject: Re: Version and byte order changes when fragmenting messages (interop) References: <9B164B713EE9D211B6DC0090273CEEA926BEF6@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: XQ~e96)\d98Ng!!F6E!! Paul - Paul Kyzivat wrote: > This has been discussed before, at least w/r/t byte order, and it was > decided that the byte order may not change in a fragment. (I thought this > was adopted, but I don't have the current text handy.) > > Regarding the others, given that we have decided that multiple versions can > coexist on a connection, I have concluded that the only sensible way for > this to work is to first demultiplex the messages on the connection based on > version. In principle, each version could then reuse the same request ids > without confusion. Based on that, fragments by definition have the same > version as the message they continue. Aren't we keeping request id's unique with the scope of the connection? Why should they be kept unique with the scope of version classes on a connection? There's some light-hearted discussion on the uniqueness scope of request id's but that was far from an agreement as far as I can remember. > Our giop 1.2 implementation is based on this assumption, and will happily > accept interleaved messages and fragments of different versions that are > using the same request id. But to preserve sanity, and in the expectation > that not all orbs will be so forgiving, we are assigning request ids in a > unified way across versions so that this sort of behavior will never be > initiated by us. Uniqueness of request id's on a connection makes much better sense that uniqueness within version classes on a connection. Max > Paul > > > -----Original Message----- > > From: Chris Wood [mailto:wood@intalio.com] > > Sent: Thursday, June 15, 2000 9:52 PM > > To: issues@omg.org > > Subject: Version and byte order changes when fragmenting messages > > (interop) > > > > > > > > It's occoured to me that according to the spec it's allowable for > > a message to be fragmented and have second and subsequent > > fragments change the version fields. > > > > Having the version change while in the middle of reading a > > wstring could cause problems, the CDR encoding of version 1.1 > > strings is always two bytes longer than the corresponding 1.2 > > encoding, if the version changed while in the middle of reading > > the wstring the length field would be out by two. > > > > Secondly if request IDs are per-protocol rather than > > per-connection (as aired in issue 3438) then the request ids of > > the fragments could interfere. > > > > I think an extra phrase should be added to the spec with regards > > to fragmentation, similar to the one regarding byte order: > > > > The version of fragments must match the version of the > > initial message that > > the fragment extends. > > From: Paul Kyzivat To: "Interop RTF (E-mail)" Subject: RE: Version and byte order changes when fragmenting messages (int erop) Date: Mon, 19 Jun 2000 16:38:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" X-UIDL: m@Wd9k;\!!Ao6!!PL[d9 > -----Original Message----- > From: M. Mortazavi [mailto:masood.mortazavi@eng.sun.com] > Sent: Monday, June 19, 2000 3:24 PM > To: Paul Kyzivat > Cc: 'Chris Wood'; Interop RTF (E-mail) > Subject: Re: Version and byte order changes when fragmenting messages > (interop) > > > Paul - > > Paul Kyzivat wrote: > > > This has been discussed before, at least w/r/t byte order, > and it was > > decided that the byte order may not change in a fragment. > (I thought this > > was adopted, but I don't have the current text handy.) > > > > Regarding the others, given that we have decided that > multiple versions can > > coexist on a connection, I have concluded that the only > sensible way for > > this to work is to first demultiplex the messages on the > connection based on > > version. In principle, each version could then reuse the > same request ids > > without confusion. Based on that, fragments by definition > have the same > > version as the message they continue. > > Aren't we keeping request id's unique with the scope of > the connection? > Why should they be kept unique with the scope of version > classes on a connection? > There's some light-hearted discussion on the uniqueness > scope of request id's but that > was far from an agreement as far as I can remember. I agree that this has not been seriously discussed. But it makes a lot of sense. For one thing, it defines away the problem you raised of fragments of a request having different versions. For another thing, it means that different versions can use differing rules for assignment of request ids. In 1.0 and 1.1 request ids could be any unsigned long value, but in giop 1.2 it is required to follow the even/odd rule. An orb that has working implementations of 1.0 and 1.1 would otherwise have to change them (to follow the even/odd rule when assigning request ids) before adding support for 1.2. In any case, if you view the giop implementation on a connection as a state machine (and it is difficult to avoid this to some extent), then it is much easier to define a separate state machine for each version than it is to define a single state machine that deals with all the versions. Why would we want to make life more complex than it needs to be when it adds no value. The only place where the state machines need to interact is at the time when a close connection message is received. Paul > > > > Our giop 1.2 implementation is based on this assumption, > and will happily > > accept interleaved messages and fragments of different > versions that are > > using the same request id. But to preserve sanity, and in > the expectation > > that not all orbs will be so forgiving, we are assigning > request ids in a > > unified way across versions so that this sort of behavior > will never be > > initiated by us. > > > Uniqueness of request id's on a connection makes much > better sense that uniqueness > within version classes on a connection. > > Max > > > > Paul > > > > > -----Original Message----- > > > From: Chris Wood [mailto:wood@intalio.com] > > > Sent: Thursday, June 15, 2000 9:52 PM > > > To: issues@omg.org > > > Subject: Version and byte order changes when fragmenting > messages > > > (interop) > > > > > > > > > > > > It's occoured to me that according to the spec it's allowable > for > > > a message to be fragmented and have second and subsequent > > > fragments change the version fields. > > > > > > Having the version change while in the middle of reading a > > > wstring could cause problems, the CDR encoding of version 1.1 > > > strings is always two bytes longer than the corresponding 1.2 > > > encoding, if the version changed while in the middle of reading > > > the wstring the length field would be out by two. > > > > > > Secondly if request IDs are per-protocol rather than > > > per-connection (as aired in issue 3438) then the request ids of > > > the fragments could interfere. > > > > > > I think an extra phrase should be added to the spec with regards > > > to fragmentation, similar to the one regarding byte order: > > > > > > The version of fragments must match the version of the > > > initial message that > > > the fragment extends. > > > > Sender: seyed@khazaneh.Eng.Sun.COM Message-ID: <394E89D0.3ADB678E@eng.sun.com> Date: Mon, 19 Jun 2000 14:00:01 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "Interop RTF (E-mail)" Subject: Re: Version and byte order changes when fragmenting messages (interop) References: <9B164B713EE9D211B6DC0090273CEEA926BEFB@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Ye9e9/W*e9hp1e98God9 Paul Kyzivat wrote: > > -----Original Message----- > > From: M. Mortazavi [mailto:masood.mortazavi@eng.sun.com] > > Sent: Monday, June 19, 2000 3:24 PM > > To: Paul Kyzivat > > Cc: 'Chris Wood'; Interop RTF (E-mail) > > Subject: Re: Version and byte order changes when fragmenting messages > > (interop) > > > > > > Paul - > > > > Paul Kyzivat wrote: > > > > > This has been discussed before, at least w/r/t byte order, > > and it was > > > decided that the byte order may not change in a fragment. > > (I thought this > > > was adopted, but I don't have the current text handy.) > > > > > > Regarding the others, given that we have decided that > > multiple versions can > > > coexist on a connection, I have concluded that the only > > sensible way for > > > this to work is to first demultiplex the messages on the > > connection based on > > > version. In principle, each version could then reuse the > > same request ids > > > without confusion. Based on that, fragments by definition > > have the same > > > version as the message they continue. > > > > Aren't we keeping request id's unique with the scope of > > the connection? > > Why should they be kept unique with the scope of version > > classes on a connection? > > There's some light-hearted discussion on the uniqueness > > scope of request id's but that > > was far from an agreement as far as I can remember. > > I agree that this has not been seriously discussed. > But it makes a lot of sense. > > For one thing, it defines away the problem you raised of fragments of a > request having different versions. Why would one want to be sending fragments of a single request according to multiple versions? You're referring to 1.2+ versions, I assume, and can only think of some weak arguments in favor of it. > For another thing, it means that different versions can use differing rules > for assignment of request ids. In 1.0 and 1.1 request ids could be any > unsigned long value, but in giop 1.2 it is required to follow the even/odd > rule. An orb that has working implementations of 1.0 and 1.1 would otherwise > have to change them (to follow the even/odd rule when assigning request ids) > before adding support for 1.2. That's a good argument for scoping id uniqueness in version classes. But I think id uniqueness on a connection has equal if not stronger advantages on the reading side. It should be possible to factor out id creation from 1.0 and 1.1 legacy orb and incorporate the 1.2 algorithm for all. I don't see that as a major undertaking. Keeping track of id-uniqueness on a version class is more of an undertaking, specially on the server-side reads of messages. > In any case, if you view the giop implementation on a connection as a state > machine (and it is difficult to avoid this to some extent), then it is much > easier to define a separate state machine for each version than it is to > define a single state machine that deals with all the versions. Why would we > want to make life more complex than it needs to be when it adds no value. > The only place where the state machines need to interact is at the time when > a close connection message is received. That's one possible design. Regards, Max > Paul > > > > > > > > Our giop 1.2 implementation is based on this assumption, > > and will happily > > > accept interleaved messages and fragments of different > > versions that are > > > using the same request id. But to preserve sanity, and in > > the expectation > > > that not all orbs will be so forgiving, we are assigning > > request ids in a > > > unified way across versions so that this sort of behavior > > will never be > > > initiated by us. > > > > > > Uniqueness of request id's on a connection makes much > > better sense that uniqueness > > within version classes on a connection. > > > > Max > > > > > > > Paul > > > > > > > -----Original Message----- > > > > From: Chris Wood [mailto:wood@intalio.com] > > > > Sent: Thursday, June 15, 2000 9:52 PM > > > > To: issues@omg.org > > > > Subject: Version and byte order changes when fragmenting >messages > > > > (interop) > > > > > > > > > > > > > > > > It's occoured to me that according to the spec it's allowable >for > > > > a message to be fragmented and have second and subsequent > > > > fragments change the version fields. > > > > > > > > Having the version change while in the middle of reading a > > > > wstring could cause problems, the CDR encoding of version 1.1 > > > > strings is always two bytes longer than the corresponding 1.2 > > > > encoding, if the version changed while in the middle of >reading > > > > the wstring the length field would be out by two. > > > > > > > > Secondly if request IDs are per-protocol rather than > > > > per-connection (as aired in issue 3438) then the request ids >of > > > > the fragments could interfere. > > > > > > > > I think an extra phrase should be added to the spec with >regards > > > > to fragmentation, similar to the one regarding byte order: > > > > > > > > The version of fragments must match the version of the > > > > initial message that > > > > the fragment extends. > > > > > > From: "Chris Wood" To: "M. Mortazavi" , "Paul Kyzivat" Cc: "Interop RTF \(E-mail\)" Subject: RE: Version and byte order changes when fragmenting messages (interop) Date: Tue, 20 Jun 2000 09:19:54 +1000 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <394E734D.AE4E00C3@eng.sun.com> Content-Type: text/plain; charset="US-ASCII" X-UIDL: @!>!!4,Pd9U7k!!oOb!! > > This has been discussed before, at least w/r/t byte order, and it was > > decided that the byte order may not change in a fragment. (I > > thought this > > was adopted, but I don't have the current text handy.) Yeh it was, i was looking in the wrong place... > > Regarding the others, given that we have decided that multiple > versions can > > coexist on a connection, I have concluded that the only sensible way for > > this to work is to first demultiplex the messages on the > connection based on > > version. In principle, each version could then reuse the same > request ids > > without confusion. Based on that, fragments by definition have the same > > version as the message they continue. > > Aren't we keeping request id's unique with the scope of the > connection? > Why should they be kept unique with the scope of version > classes on a connection? > There's some light-hearted discussion on the uniqueness scope > of request id's but that > was far from an agreement as far as I can remember. I think this does need to be cleared up. It's clear that changing versions for fragments should not be allowed for the reasons i outlined in the original message. If noone has actualy made use of per-protocol-version rather than per-connection request IDs it makes sense to add that also to the spec. From: "Rutt, T E (Tom)" To: issues@emerald.omg.org, interop@emerald.omg.org, "'Juergen Boldt'" Subject: RE: issue 3680 -- Interop RTF issue Date: Mon, 10 Jul 2000 14:02:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-UIDL: I/nd93DH!!K,1!!c ---------- > From: Juergen Boldt[SMTP:juergen@omg.org] > Sent: Friday, July 07, 2000 2:15 PM > To: issues@emerald.omg.org; interop@emerald.omg.org > Subject: issue 3680 -- Interop RTF issue > > This is issue# 3680 > > Version and byte order changes when fragmenting messages (interop) > > It's occoured to me that according to the spec it's allowable for > a message to be fragmented and have second and subsequent > fragments change the version fields. > > Having the version change while in the middle of reading a > wstring could cause problems, the CDR encoding of version 1.1 > strings is always two bytes longer than the corresponding 1.2 > encoding, if the version changed while in the middle of reading > the wstring the length field would be out by two. > > Secondly if request IDs are per-protocol rather than > per-connection (as aired in issue 3438) then the request ids of > the fragments could interfere. > > I think an extra phrase should be added to the spec with regards > to fragmentation, similar to the one regarding byte order: > > The version of fragments must match the version of the initial message > that > the fragment extends. > > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > > > > ================================================================ >