Issue 2801: fragmentation broken with bi-dir giop (interop) Source: (, ) Nature: Uncategorized Issue Severity: Critical Summary: Summary: I wish to raise the following as an urgent issue: The way that message fragments are encoded in giop 1.2, in conjunction with the giop 1.2 specification for bi-directional use of a connection, can lead to situations where the protocol is ambiguous. (This is urgent because it is impossible to implement the bi-directional part of GIOP 1.2 without it.) Resolution: Revised Text: Actions taken: July 13, 1999: received issue August 4, 1999: closed issue Discussion: End of Annotations:===== Date: Tue, 13 Jul 1999 15:47:11 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: issues@omg.org, andrew@omg.org CC: interop@omg.org Subject: fragmentation broken with bi-dir giop I wish to raise the following as an urgent issue: The way that message fragments are encoded in giop 1.2, in conjunction with the giop 1.2 specification for bi-directional use of a connection, can lead to situations where the protocol is ambiguous. (This is urgent because it is impossible to implement the bi-directional part of GIOP 1.2 without it.) Consider two servers, SA and SB, communicating over a connection that has been negotiated for bi-directional usage. Server SA has a request to make. Both the request and the response are large enough to require fragmentation, leading to the following exchange of messages: SA SB ========== ========== M1-Rqst:#A -> M2-Frag:#A -> <- M3-Resp:#A <- M4-Frag:#A For each message, I have shown my own message label to reference the message, together with the message type for each message and the request id, denoted by A because SA chooses it. This is all that is significant for the point I am making. Server SB also has a similar request to make, leading to the following exchange: SA SB ========== ========== <- M5-Rqst:#B <- M6-Frag:#B M7-Resp:#B -> M8-Frag:#B -> It is supposed to be possible for these requests to overlap in time, so long as the sequence of messages in each is preserved. That could lead to the following combined sequence of messages: SA SB ========== ========== M1-Rqst:#A -> <- M5-Rqst:#B M2-Frag:#A -> <- M3-Resp:#A <- M6-Frag:#B <- M4-Frag:#A M7-Resp:#B -> M8-Frag:#B -> The protocol must allow this. However, note that with bi-directional giop, each side is responsible for assigning request ids for the requests it originates. These are to be assigned in such a way that they are not reused while responses are still pending. There are no rules placing dependencies between the two sides on how they assign request ids. So, it may happen that SA chooses 1 as the value for A, and SB also chooses the value 1 for B. Then the combined sequence looks like: SA SB ========== ========== M1-Rqst:#1 -> <- M5-Rqst:#1 M2-Frag:#1 -> <- M3-Resp:#1 <- M6-Frag:#1 <- M4-Frag:#1 M7-Resp:#1 -> M8-Frag:#1 -> As SA is processing this, when it receives M6, it has no way of knowing that it is the continuation of M5 rather than the continuation of M1. This is the problem with the protocol! There is no way of looking at a fragment and knowing whether the request id is one assigned by the sender or by the recipient. I can see two ways of fixing this: 1) mandate a system for assigning request ids that guarantees that the two sides will never assign the same one. For instance, require the initiator of a connection to use even numbers and the other side to use odd request ids. 2) put additional data into the FragmentHeader. A couple of possibilities are: an enum with possibilities {SENDER_ASSIGNED_ID, RECIPIENT_ASSIGNED_ID}, or a copy of the MsgType that this fragment is a continuation of. Sorry for being so long winded, but I wanted to make this clear. It is surprising to me that this hasn't been reported before. Sender: jon@floorboard.com Date: Tue, 13 Jul 1999 13:46:43 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: Paul H Kyzivat CC: issues@omg.org, andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > So, it may happen that SA chooses 1 as the value for A, and SB also > chooses the value 1 for B. Then the combined sequence looks like: > > SA SB > ========== ========== > M1-Rqst:#1 -> > <- M5-Rqst:#1 > M2-Frag:#1 -> > <- M3-Resp:#1 > <- M6-Frag:#1 > <- M4-Frag:#1 > M7-Resp:#1 -> > M8-Frag:#1 -> > > As SA is processing this, when it receives M6, it has no way of knowing > that it is the continuation of M5 rather than the continuation of M1. > > This is the problem with the protocol! There is no way of looking at a > fragment and knowing whether the request id is one assigned by the > sender or by the recipient. I just took a scan through ptc/99-03-07 and discovered to my suprise, that although the existence of the fragment header in GIOP 1.2 suggests that different messages can be interleaved, there is no text that states that this is possible. Since GIOP 1.1 and earlier didn't allow interleaving of messages, one could argue that your message sequence above is illegal, since it is not explicitly allowed! > I can see two ways of fixing this: > > 1) mandate a system for assigning request ids that guarantees that the > two sides will never assign the same one. For instance, require the > initiator of a connection to use even numbers and the other side to use > odd request ids. Ah, the old ISO presentation context hack! > 2) put additional data into the FragmentHeader. A couple of > possibilities are: an enum with possibilities {SENDER_ASSIGNED_ID, > RECIPIENT_ASSIGNED_ID}, or a copy of the MsgType that this fragment is a > continuation of. > > Sorry for being so long winded, but I wanted to make this clear. > It is surprising to me that this hasn't been reported before. Perhaps noone has tried to interleave fragments before? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 13 Jul 1999 13:50:51 PDT Sender: Bill Janssen From: Bill Janssen To: issues@omg.org, andrew@omg.org, Paul H Kyzivat Subject: Re: fragmentation broken with bi-dir giop CC: interop@omg.org Excerpts from local.omg: 13-Jul-99 fragmentation broken with b.. Paul H Kyzivat@roguewave (3292*) > 1) mandate a system for assigning request ids that guarantees that the > two sides will never assign the same one. For instance, require the > initiator of a connection to use even numbers and the other side to use > odd request ids. That's the system used by the HTTP-NG MUX system. However, the NG MUX system further clarifies things by not confusing request IDs and channel identifiers. Bill To: Bill Janssen cc: issues@omg.org, andrew@omg.org, Paul H Kyzivat , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Date: Tue, 13 Jul 1999 22:53:41 +0200 From: Craig Ryan >Excerpts from local.omg: 13-Jul-99 fragmentation broken with b.. Paul H >Kyzivat@roguewave (3292*) > >> 1) mandate a system for assigning request ids that guarantees that the >> two sides will never assign the same one. For instance, require the >> initiator of a connection to use even numbers and the other side to use >> odd request ids. > >That's the system used by the HTTP-NG MUX system. However, the NG MUX >system further clarifies things by not confusing request IDs and channel >identifiers. > >Bill This would mean both halving the id range for each side, and redefining the rules in the specification for request id uniqueness and the range of possible ids. This is also specific only to 1.2 traffic so it shouldn't effect the id range for other 1.0/1.1 traffic sharing a 1.2 connection. Since the problem is specific to 1.2 interleaved fragmentation, it makes sense that any changes should only apply to the specification for 1.2 fragments, in which case suggestion 2) seems more appropriate. The problem though, is that this requires changing the fragment header (thus upsetting the ideal alignment we have with the current 1.2 fragment header) so perhaps an alternative is to instead make use of a free bit in the giop header flag for 1.2 fragments, to indicate which side assigned the id? >> Since GIOP 1.1 and earlier didn't allow >> interleaving of messages, one could argue that your message >> sequence above is illegal, since it is not explicitly allowed! I dont follow this since interleaving was specifically not possible in 1.1, while this problem is specific to 1.2 (which does allow it). craig. To: Bill Janssen cc: issues@omg.org, andrew@omg.org, Paul H Kyzivat , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Date: Tue, 13 Jul 1999 22:55:15 +0200 From: Craig Ryan >Excerpts from local.omg: 13-Jul-99 fragmentation broken with b.. Paul H >Kyzivat@roguewave (3292*) > >> 1) mandate a system for assigning request ids that guarantees that the >> two sides will never assign the same one. For instance, require the >> initiator of a connection to use even numbers and the other side to use >> odd request ids. > >That's the system used by the HTTP-NG MUX system. However, the NG MUX >system further clarifies things by not confusing request IDs and channel >identifiers. > >Bill This would mean both halving the id range for each side, and redefining the rules in the specification for request id uniqueness and the range of possible ids. This is also specific only to 1.2 traffic so it shouldn't effect the id range for other 1.0/1.1 traffic sharing a 1.2 connection. Since the problem is specific to 1.2 interleaved fragmentation, it makes sense that any changes should only apply to the specification for 1.2 fragments, in which case suggestion 2) seems more appropriate. The problem though, is that this requires changing the fragment header (thus upsetting the ideal alignment we have with the current 1.2 fragment header) so perhaps an alternative is to instead make use of a free bit in the giop header flag for 1.2 fragments, to indicate which side assigned the id? >> Since GIOP 1.1 and earlier didn't allow >> interleaving of messages, one could argue that your message >> sequence above is illegal, since it is not explicitly allowed! I dont follow this since interleaving was specifically not possible in 1.1, while this problem is specific to 1.2 (which does allow it). craig. Date: Tue, 13 Jul 1999 14:13:54 PDT Sender: Bill Janssen From: Bill Janssen To: Paul H Kyzivat , Jonathan Biggar Subject: Re: fragmentation broken with bi-dir giop CC: andrew@omg.org, interop@omg.org Excerpts from local.omg: 13-Jul-99 Re: fragmentation broken wi.. Jonathan Biggar@floorboa (2001*) > Since GIOP 1.1 and earlier didn't allow > interleaving of messages, one could argue that your message sequence > above is illegal, since it is not explicitly allowed! In fact, I recall we discussed exactly this at an Interop meeting, and decided that interleaving was still disallowed. That seems to be the simplest answer to Paul's issue. Bill Date: Tue, 13 Jul 1999 17:14:20 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jonathan Biggar CC: issues@omg.org, andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jonathan Biggar wrote: > > I just took a scan through ptc/99-03-07 and discovered to my suprise, > that although the existence of the fragment header in GIOP 1.2 > suggests > that different messages can be interleaved, there is no text that > states > that this is possible. Since GIOP 1.1 and earlier didn't allow > interleaving of messages, one could argue that your message sequence > above is illegal, since it is not explicitly allowed! That would be sad! I don't believe that anything in GIOP 1.1 explicitly said that they couldn't be interleaved; its just clear from examination of the messages that interleaving couldn't work. It is my impression that this was an oversight. Then GIOP 1.2 introduced request ids to fragment messages. Presumably it wasn't done just to consume resources - the only good reason to add them was to permit interleaving. And, interleaving works as long as you don't try to use it bi-directionally. So, I conclude this is another example of an unintended consequence of a change. I don't thing that forbidding interleaving is the right way to fix this. > > It is surprising to me that this hasn't been reported before. > > Perhaps noone has tried to interleave fragments before? Or perhaps no one has tried to implement bi-directional giop yet! You don't have to actually interleave fragments to find this - all you have to do is try to write the code on the assumption that the other guy might interleave fragments. And its hard to imaging anyone looking at the protocol and deciding they don't have to worry about that! Date: Tue, 13 Jul 1999 17:17:53 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Bill Janssen CC: issues@omg.org, andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Bill Janssen wrote: > > That's the system used by the HTTP-NG MUX system. However, the NG MUX > system further clarifies things by not confusing request IDs and > channel identifiers. You don't have to keep rubbing it in Bill! I wish you would start the band wagon to replace IIOP, so we can all get the benefits. From: "Carlos O'Ryan" Date: Tue, 13 Jul 1999 16:30:44 -0500 (CDT) To: Bill Janssen Cc: Paul H Kyzivat , Jonathan Biggar , andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Hi, Bill Janssen writes: > > Since GIOP 1.1 and earlier didn't allow > > interleaving of messages, one could argue that your message sequence > > above is illegal, since it is not explicitly allowed! > > In fact, I recall we discussed exactly this at an Interop meeting, and > decided that interleaving was still disallowed. That seems to be the > simplest answer to Paul's issue. Hmmmm, one wonders what was the purpose of adding a request id into the fragment header? It may be that the current wording of GIOP 1.2 still disallows fragment interleaving, but i always assumed that the intention of adding request ids in the header was to support such interleaving, am i wrong? Jon Biggar writes: >> Sorry for being so long winded, but I wanted to make this clear. >> It is surprising to me that this hasn't been reported before. > Perhaps noone has tried to interleave fragments before? Well, since GIOP 1.1 does not allow it and the ink on GIOP 1.2 is still drying this is no surprize... Good for Paul to be so brave, btw ;-) -- Carlos O'Ryan (coryan@cs.wustl.edu) #include #include // "Speak softly and carry a megawatt laser" Sender: jon@floorboard.com Date: Tue, 13 Jul 1999 15:58:47 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: Craig Ryan CC: Bill Janssen , andrew@omg.org, Paul H Kyzivat , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Craig Ryan wrote: > The problem though, is that this requires changing the fragment header > (thus upsetting the ideal alignment we have with the current 1.2 > fragment header) so perhaps an alternative is to instead make use of a > free bit in the giop header flag for 1.2 fragments, to indicate which > side assigned the id? There are still spare bits, so this seems like a workable suggestion. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Jeffrey Mischkinsky Subject: Re: fragmentation broken with bi-dir giop To: paulk@roguewave.com (Paul H Kyzivat) Date: Tue, 13 Jul 1999 23:44:53 -0700 (PDT) Cc: jon@floorboard.com, issues@omg.org, andrew@omg.org, interop@omg.org X-Mailer: ELM [version 2.4 PL25] Hi, Having been present at all the interop revisions, maybe i can shed a little light on this. (Or maybe it will just make things darker :-) I believe message fragments were introduced in GIOP 1.1. (correct?) At the time it was understood that only one "open" message at a time was possible because there was no request id in the fragments. I remember some people not wanting to have to manage buffering of multiple outstanding interleaved messages. At the time, i also think that not many implementations did much in the way of connection multiplexing. Of course, w/o the ability to interleave much of the attraction of fragmentation is lost. (This is probably why there aren't a whole lot of GIOP 1.1 implementations. I know we're skipping to 1.2) The intent in adding the request id to GIOP 1.2 was in fact to make interleaving of more than one "open" message possible. This IS an example of unintended consequences. Bi-directional GIOP was added by the firewall RFP and "folded into" GIOP 1.2. It was done by a slightly different set of people, working in a completely different context from the interop RTF which defined GIOP 1.2. It was only when we realized that we didn't really want to have a GIOP 1.2, 1.3, 1.4, all defined within several different months (the result of interop RTF, the messaging RFP, the Firewall RFP, etc.) that the decision was taken to fold all the new features into GIOP 1.2 in the final editing of the GIOP chapter. So the features were defined separately and the interaction which Paul has been pointed out was not noticed, until now. 'Paul H Kyzivat' writes: > > Jonathan Biggar wrote: > > > > I just took a scan through ptc/99-03-07 and discovered to my suprise, > > that although the existence of the fragment header in GIOP 1.2 > > suggests > > that different messages can be interleaved, there is no text that > > states > > that this is possible. > > Since GIOP 1.1 and earlier didn't allow > > interleaving of messages, one could argue that your message sequence > > above is illegal, since it is not explicitly allowed! This is not correct for GIOP 1.2. > > That would be sad! I don't believe that anything in GIOP 1.1 explicitly > said that they couldn't be interleaved; its just clear from examination > of the messages that interleaving couldn't work. It is my impression > that this was an oversight. It was not an oversight. The text doesn't "have to" expressly forbid it since it clearly can't be supported. Adding the words for GIOP 1.1 might relieve some of the spec lawyers, but won't change anything. (Of course the spec doesn't explicitly forbid many other things that can't be implemented by following the spec. Should we identify that (infinite) list?) The oversight was in not noticing the interaction with bi-directional giop. > > Then GIOP 1.2 introduced request ids to fragment messages. Presumably it > wasn't done just to consume resources - the only good reason to add them > was to permit interleaving. And, interleaving works as long as you don't > try to use it bi-directionally. > > So, I conclude this is another example of an unintended consequence of a > change. I don't thing that forbidding interleaving is the right way to > fix this. > > > > It is surprising to me that this hasn't been reported before. > > > > Perhaps noone has tried to interleave fragments before? That's true. Because GIOP 1.1 does not support fragment interleaving. > > Or perhaps no one has tried to implement bi-directional giop yet! > > You don't have to actually interleave fragments to find this - all you > have to do is try to write the code on the assumption that the other guy > might interleave fragments. And its hard to imaging anyone looking at > the protocol and deciding they don't have to worry about that! It may be hard to imagine, but since it happenned i guess reality must really be stranger than fiction. :-) jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Date: Wed, 14 Jul 1999 08:33:57 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jonathan Biggar CC: Craig Ryan , Bill Janssen , andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jonathan Biggar wrote: > > Craig Ryan wrote: > > The problem though, is that this requires changing the fragment > > header (thus upsetting the ideal alignment we have with the > > current 1.2 fragment header) so perhaps an alternative is to instead > > make use of a free bit in the giop header flag for 1.2 fragments, > > to indicate which side assigned the id? > > There are still spare bits, so this seems like a workable suggestion. I gather you have in mind a bit in the message header that affects only the fragment message? I suppose this could be made to work, but it is certainly a hack. It further blurs the distinction between the semantics of GIOP messages in general, and the specifics of particular kinds of messages. A similar solution would be to have two kinds of fragment messages - perhaps we could call them request fragments and reply fragments. At the moment my highest priority is in getting a revision/clarification that makes it possible to implement GIOP 1.2 correctly and interoperably. My next highest priority is doing this in a way that allows for a reasonable and efficient implementation. Permitting interleaving is part of this, because it allows buffers to be disposed of earlier. Date: Wed, 14 Jul 1999 08:41:03 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jeffrey Mischkinsky CC: jon@floorboard.com, issues@omg.org, andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jeffrey Mischkinsky wrote: > > Hi, > > Having been present at all the interop revisions, maybe i can shed a > little light on this. (Or maybe it will just make things darker :-) > > I believe message fragments were introduced in GIOP 1.1. (correct?) > At the time it was understood that only one "open" message at a time > was possible because there was no request id in the fragments. > I remember some people not wanting to have to manage buffering of > multiple outstanding interleaved messages. At the time, i also > think that not many implementations did much in the way of > connection multiplexing. Of course, w/o the ability to interleave > much of the attraction of fragmentation is lost. > (This is probably why there aren't a whole lot of GIOP 1.1 > implementations. I know we're skipping to 1.2) > > The intent in adding the request id to GIOP 1.2 was in fact to make > interleaving of more than one "open" message possible. > > This IS an example of unintended consequences. Bi-directional > GIOP was added by the firewall RFP and "folded into" GIOP 1.2. > It was done by a slightly different set of people, working in a > completely > different context from the interop RTF which defined GIOP 1.2. It > was only when we realized that we didn't really want to have a > GIOP 1.2, 1.3, 1.4, all defined within several different months > (the result of interop RTF, the messaging RFP, the Firewall RFP, etc.) > that the decision was taken to fold all the new features into GIOP 1.2 > in the final editing of the GIOP chapter. > So the features were defined separately and the interaction which > Paul has been pointed out was not noticed, until now. thanks for the clarification jeff. I wasn't there, but you have confirmed what I had inferred from reading between the lines. From: Jeffrey Mischkinsky Subject: Re: fragmentation broken with bi-dir giop To: paulk@roguewave.com (Paul H Kyzivat) Date: Wed, 14 Jul 1999 07:47:04 -0700 (PDT) Cc: jon@floorboard.com, cryan@iona.com, janssen@parc.xerox.com, andrew@omg.org, interop@omg.org X-Mailer: ELM [version 2.4 PL25] 'Paul H Kyzivat' writes: > > Jonathan Biggar wrote: > > > > Craig Ryan wrote: > > > The problem though, is that this requires changing the fragment > > > header (thus upsetting the ideal alignment we have with the > > > current 1.2 fragment header) so perhaps an alternative is to instead > > > make use of a free bit in the giop header flag for 1.2 fragments, > > > to indicate which side assigned the id? > > > > There are still spare bits, so this seems like a workable suggestion. > > I gather you have in mind a bit in the message header that affects only > the fragment message? I suppose this could be made to work, but it is > certainly a hack. It further blurs the distinction between the semantics > of GIOP messages in general, and the specifics of particular kinds of > messages. > > A similar solution would be to have two kinds of fragment messages - > perhaps we could call them request fragments and reply fragments. > > At the moment my highest priority is in getting a revision/clarification > that makes it possible to implement GIOP 1.2 correctly and > interoperably. > > My next highest priority is doing this in a way that allows for a > reasonable and efficient implementation. Permitting interleaving is part > of this, because it allows buffers to be disposed of earlier. I would definitely agree with this sentiment. We are currently in beta with the next major release of our ORB, which includes support for GIOP 1.2. It would be real nice to be able to fix this quickly. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Date: Wed, 14 Jul 1999 08:57:35 PDT Sender: Bill Janssen From: Bill Janssen To: paulk@roguewave.com (Paul H Kyzivat), Jeffrey Mischkinsky Subject: Re: fragmentation broken with bi-dir giop CC: jon@floorboard.com, issues@omg.org, andrew@omg.org, interop@omg.org Excerpts from local.omg: 13-Jul-99 Re: fragmentation broken wi.. Jeffrey Mischkinsky@whee (4049*) > The intent in adding the request id to GIOP 1.2 was in fact to make > interleaving of more than one "open" message possible. Yes, this seems right to me. I must have been be thinking back to 1.1 discussions about adding fragmentation. Bill Sender: jon@floorboard.com Date: Wed, 14 Jul 1999 09:08:17 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: Jeffrey Mischkinsky CC: Paul H Kyzivat , issues@omg.org, andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jeffrey Mischkinsky wrote: > > > Since GIOP 1.1 and earlier didn't allow > > > interleaving of messages, one could argue that your message sequence > > > above is illegal, since it is not explicitly allowed! > > This is not correct for GIOP 1.2. > > > > > That would be sad! I don't believe that anything in GIOP 1.1 explicitly > > said that they couldn't be interleaved; its just clear from examination > > of the messages that interleaving couldn't work. It is my impression > > that this was an oversight. > > It was not an oversight. The text doesn't "have to" expressly forbid it since > it clearly can't be supported. Adding the words for GIOP 1.1 might relieve > some of the spec lawyers, but won't change anything. (Of course the spec > doesn't explicitly forbid many other things that can't be implemented by > following the spec. Should we identify that (infinite) list?) > > The oversight was in not noticing the interaction with bi-directional giop. Just to make it clear, I'm not seriously arguing that GIOP 1.2 as defined in the current spec does not allow interleaving of fragments, but I am pointing out that the spec does not make it clear that GIOP 1.1 does not allow interleaving and GIOP 1.2 does. So, however we decide to fix this, let's also add explicit text to the spec that defines when interleaving fragments is allowed. It's hard enough to implement a protocol without the spec being ambiguous and underdefined. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 15 Jul 1999 02:11:34 +1000 (EST) From: Michi Henning To: Andrew Watson cc: Paul H Kyzivat , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Organization: Triodia Technologies On Wed, 14 Jul 1999, Andrew Watson wrote: > Can you come up with some exact wording for a plausible > default resolution for me? If not, I'm likely to try to do it myself, and > you don't want that :-). Talk about threatening people... We had better review the policies and procedures yet again :-) Cheers, Michi. Date: Wed, 14 Jul 1999 12:29:07 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Andrew Watson CC: interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Andrew Watson wrote: > > Paul, > > You wrote: > > > I wish to raise the following as an urgent issue: > > > > The way that message fragments are encoded in giop 1.2, in > conjunction > > with the giop 1.2 specification for bi-directional use of a > connection, > > can lead to situations where the protocol is ambiguous. > > > > (This is urgent because it is impossible to implement the > bi-directional > > part of GIOP 1.2 without it.) > > No-one in the extended thread that followed questioned your > conclusion, so > this is clearly a real issue. I'm happy to flag it as an urgent issue > so > that we have a mechanism to get a resolution on the books quickly. To > do > that I need a default resolution which will be used if the RTF > discussion > fails to converge. Can you come up with some exact wording for a > plausible > default resolution for me? If not, I'm likely to try to do it myself, > and > you don't want that :-). Andrew - I seem to recall that you handled this before by proposing something so outrageous that the RTF was guaranteed to propose a better fix. I think you are fully qualified to do that in this case as well. :-) For the core of a default resolution I suggest that in GIOP 1.2 the values that are assigned for request ids be restricted - the orb that initiated the connection shall use only even request ids, and the orb that accepts a connection shall use only odd request ids. I propose this as the default not because I think it is the best solution, but because I think it is the most easily stated solution that preserves the ability to interleave. I can live with this solution, but am equally (or more) happy to work out something better. To: Andrew Watson CC: interop@omg.org, paulk@roguewave.com Subject: Re: fragmentation broken with bi-dir giop Date: Thu, 15 Jul 1999 15:23:08 +0200 From: Craig Ryan >For the core of a default resolution I suggest that in GIOP 1.2 the >values that are assigned for request ids be restricted - the orb that >initiated the connection shall use only even request ids, and the orb >that accepts a connection shall use only odd request ids. I disagree this is the most simple solution. If this odd/even requirement is violated then what behaviour is specifed - eg the initiator uses an odd id in a 1.2 message, is the message rejected and an exception returned? What exception? Since this also requires unresticted use of id's for non-1.2 bindings sharing these connections (for backward-compat.), this now complicates the potential re-use of id's, distinguished by version uniqueness!. SA SB 1.1Req#1-> <- 1.2Req#1 1.1Frg (#1)-> 1.2Rep#1-> 1.2Frg#1-> // another frag for id 1, though for 1.2 1.1Frg (#1)-> ... How has this simplied the situation? I still think the solution should only require a per-1.2 fragment message change (eg 1.2 fragment header enum, giop 1.2 flags setting or whatever) and not a blanket per-connection change, simply to make it as transparent as possible for all connections and all versions. Otherwise you may as well re-write the whole specification of message 'uniqueness' in terms of direction AND id AND version. BTW, the points about 1.1 and 1.2 fragmentation being unclear is simply not true - it is impossible for 1.1 to support interleaving because fragments do not contain a request id to allow them to be 'de-interleaved'. 1.2 fragments define a fragment header containing a request id, specifically to allow them to be associated with a particular initial fragment. This does not seem ill defined or ambiguous. regards, craig. Sender: jon@floorboard.com Date: Thu, 15 Jul 1999 09:10:34 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: Craig Ryan CC: Andrew Watson , interop@omg.org, paulk@roguewave.com Subject: Re: fragmentation broken with bi-dir giop Craig Ryan wrote: > > >For the core of a default resolution I suggest that in GIOP 1.2 the > >values that are assigned for request ids be restricted - the orb that > >initiated the connection shall use only even request ids, and the orb > >that accepts a connection shall use only odd request ids. > > I disagree this is the most simple solution. If this odd/even > requirement is violated then what behaviour is specifed - eg the > initiator uses an odd id in a 1.2 message, is the message rejected and > an exception returned? What exception? Since this also requires > unresticted use of id's for non-1.2 bindings sharing these connections > (for backward-compat.), this now complicates the potential re-use of > id's, distinguished by version uniqueness!. You can't mix GIOP 1.1 and 1.2 messages on the same connection! If the connection is negotiated as a GIOP/IIOP 1.2 connection (via the IIOP version number embedded in the target IOR, and the client choice to use GIOP/IIOP 1.2), then all messages must be in 1.2 format. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 15 Jul 1999 12:15:47 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Craig Ryan CC: Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Craig Ryan wrote: > > >For the core of a default resolution I suggest that in GIOP 1.2 the > >values that are assigned for request ids be restricted - the orb that > >initiated the connection shall use only even request ids, and the orb > >that accepts a connection shall use only odd request ids. > > I disagree this is the most simple solution. I didn't really expect that everyone would agree that this is most simple to implement. I was asked to propose a default resolution, in case the RTF doesn't, and I proposed this partly because it is easily *stated*. It is fine by me for the RTF to negotiate some other solution. And I will be happy to participate in the discussions. > If this odd/even > requirement is violated then what behaviour is specifed - eg the > initiator uses an odd id in a 1.2 message, is the message rejected and > an exception returned? What exception? I'm not sure it is necessary to specify this. But it seems like this would be a protocol violation, and so could result in sending a MessageError message and then closing the connection. > Since this also requires > unresticted use of id's for non-1.2 bindings sharing these connections > (for backward-compat.), this now complicates the potential re-use of > id's, distinguished by version uniqueness!. An orb that implements 1.2 can use the same id assignment technique when speaking 1.1 and 1.0 as a client, since it is free to choose ids as it wishes and the ones that would be legal for 1.2 would also be legal in the earlier releases. When the orb is talking 1.1 or 1.0 as a server, it must of course be prepared for unrestricted use of ids assigned by the client orb. This is at most a matter of avoiding a validity check based on negotiated version. There won't be any ambiguity about request ids because there is no bidirectional use of connections in the earlier versions, and because fragments don't exist or don't have request ids. > > SA SB > > 1.1Req#1-> > <- 1.2Req#1 > 1.1Frg (#1)-> > 1.2Rep#1-> > 1.2Frg#1-> // another frag for id 1, though for > 1.2 > 1.1Frg (#1)-> > ... I don't understand the above. The connection is always at a particular version. > > How has this simplied the situation? I still think the solution > should only require a per-1.2 fragment message change (eg 1.2 fragment > header enum, giop 1.2 flags setting or whatever) and not a blanket > per-connection change, simply to make it as transparent as possible > for all connections and all versions. Otherwise you may as well > re-write the whole specification of message 'uniqueness' in terms of > direction AND id AND version. If the concensus is to change the format of the fragment message in some way, that is fine by me. > BTW, the points about 1.1 and 1.2 fragmentation being unclear is > simply not true - it is impossible for 1.1 to support interleaving > because fragments do not contain a request id to allow them to be > 'de-interleaved'. 1.2 fragments define a fragment header containing a > request id, specifically to allow them to be associated with a > particular initial fragment. This does not seem ill defined or > ambiguous. Whether something is unclear or not is clearly subjective. *I* think it is less clear than it might be. Cc: issues@omg.org, andrew@omg.org, interop@omg.org Date: Thu, 15 Jul 1999 12:35:02 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Paul H Kyzivat Original-CC: issues@omg.org, andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > > I wish to raise the following as an urgent issue: > > . > > It is supposed to be possible for these requests to overlap in time, so > long as the sequence of messages in each is preserved. That could lead > to the following combined sequence of messages: > > SA SB > ========== ========== > M1-Rqst:#A -> > <- M5-Rqst:#B As soon as SA sees that #B is equal to an outstanding requiest id of its own, it can send a system exception, rejecting the M5 request. This seems less radical a proposed change than even/odd request ids per side. > M2-Frag:#A -> > <- M3-Resp:#A > <- M6-Frag:#B > <- M4-Frag:#A > M7-Resp:#B -> > M8-Frag:#B -> > > The protocol must allow this. However, note that with bi-directional > giop, each side is responsible for assigning request ids for the > requests it originates. These are to be assigned in such a way that they > are not reused while responses are still pending. There are no rules > placing dependencies between the two sides on how they assign request > ids. > > So, it may happen that SA chooses 1 as the value for A, and SB also > chooses the value 1 for B. Then the combined sequence looks like: > > SA SB > ========== ========== > M1-Rqst:#1 -> > <- M5-Rqst:#1 > M2-Frag:#1 -> > <- M3-Resp:#1 > <- M6-Frag:#1 > <- M4-Frag:#1 > M7-Resp:#1 -> > M8-Frag:#1 -> > > As SA is processing this, when it receives M6, it has no way of knowing > that it is the continuation of M5 rather than the continuation of M1. > > This is the problem with the protocol! There is no way of looking at a > fragment and knowing whether the request id is one assigned by the > sender or by the recipient. > > I can see two ways of fixing this: > > 1) mandate a system for assigning request ids that guarantees that the > two sides will never assign the same one. For instance, require the > initiator of a connection to use even numbers and the other side to use > odd request ids. > > 2) put additional data into the FragmentHeader. A couple of > possibilities are: an enum with possibilities {SENDER_ASSIGNED_ID, > RECIPIENT_ASSIGNED_ID}, or a copy of the MsgType that this fragment is a > continuation of. > > Sorry for being so long winded, but I wanted to make this clear. > It is surprising to me that this hasn't been reported before. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Sender: sgw@adnovum.com Date: Thu, 15 Jul 1999 10:07:59 -0700 From: Stefan Wengi Organization: AdNovum Software Inc. X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en To: Jonathan Biggar CC: Craig Ryan , Andrew Watson , interop@omg.org, paulk@roguewave.com Subject: Re: fragmentation broken with bi-dir giop Jonathan Biggar wrote: > > Craig Ryan wrote: > > > > >For the core of a default resolution I suggest that in GIOP 1.2 the > > >values that are assigned for request ids be restricted - the orb that > > >initiated the connection shall use only even request ids, and the orb > > >that accepts a connection shall use only odd request ids. > > > > I disagree this is the most simple solution. If this odd/even > > requirement is violated then what behaviour is specifed - eg the > > initiator uses an odd id in a 1.2 message, is the message rejected and > > an exception returned? What exception? Since this also requires > > unresticted use of id's for non-1.2 bindings sharing these connections > > (for backward-compat.), this now complicates the potential re-use of > > id's, distinguished by version uniqueness!. > > You can't mix GIOP 1.1 and 1.2 messages on the same connection! If the > connection is negotiated as a GIOP/IIOP 1.2 connection (via the IIOP > version number embedded in the target IOR, and the client choice to use > GIOP/IIOP 1.2), then all messages must be in 1.2 format. disagree. When gateways and proxies are used (e.g. firewalls) you may have mixed GIOP version over a single connection. Stefan -- +-----------------------------------+-------------------------+ | Stefan G. Wengi | voice: ++1 650 525-9322 | | AdNovum Software Inc. | fax: ++1 650 525-9324 | | 1500 Fashion Island Blvd. Ste 201 | mailto:sgw@acm.org | | San Mateo, CA 94404, USA | http://www.AdNovum.ch | Cc: Andrew Watson , interop@omg.org Date: Thu, 15 Jul 1999 13:34:27 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Paul H Kyzivat Original-CC: Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Can we deal with the use of a standard exception if it is detected. That way the protocol is not changed. I think it can always be detected by one of the sides when it first receives a request which uses a request ID that itself has used on an outstanding request from its side. Paul H Kyzivat wrote: > > Andrew Watson wrote: > > > > Paul, > > > > You wrote: > > > > > I wish to raise the following as an urgent issue: > > > > > > The way that message fragments are encoded in giop 1.2, in > > conjunction > > > with the giop 1.2 specification for bi-directional use of a > > connection, > > > can lead to situations where the protocol is ambiguous. > > > > > > (This is urgent because it is impossible to implement the > > bi-directional > > > part of GIOP 1.2 without it.) > > > > No-one in the extended thread that followed questioned your > > conclusion, so > > this is clearly a real issue. I'm happy to flag it as an urgent issue > > so > > that we have a mechanism to get a resolution on the books quickly. To > > do > > that I need a default resolution which will be used if the RTF > > discussion > > fails to converge. Can you come up with some exact wording for a > > plausible > > default resolution for me? If not, I'm likely to try to do it myself, > > and > > you don't want that :-). > > Andrew - > > I seem to recall that you handled this before by proposing something so > outrageous that the RTF was guaranteed to propose a better fix. > I think you are fully qualified to do that in this case as well. :-) > > For the core of a default resolution I suggest that in GIOP 1.2 the > values that are assigned for request ids be restricted - the orb that > initiated the connection shall use only even request ids, and the orb > that accepts a connection shall use only odd request ids. > > I propose this as the default not because I think it is the best > solution, but because I think it is the most easily stated solution that > preserves the ability to interleave. I can live with this solution, but > am equally (or more) happy to work out something better. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Sender: jon@floorboard.com Date: Thu, 15 Jul 1999 11:10:30 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: terutt@lucent.com CC: Paul H Kyzivat , andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Tom Rutt wrote: > > Paul H Kyzivat wrote: > > > > I wish to raise the following as an urgent issue: > > > > . > > > > It is supposed to be possible for these requests to overlap in time, so > > long as the sequence of messages in each is preserved. That could lead > > to the following combined sequence of messages: > > > > SA SB > > ========== ========== > > M1-Rqst:#A -> > > <- M5-Rqst:#B > As soon as SA sees that #B is equal to an outstanding requiest > id of its own, it can send a system exception, rejecting > the M5 request. > > This seems less radical a proposed change than even/odd request > ids per side. This won't work. There isn't a standard system exception that forces the sending side to resend the invocation transparently, so this "fix" would cause spurious exceptions on the sender. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Cc: Craig Ryan , Andrew Watson , interop@omg.org Date: Thu, 15 Jul 1999 14:17:41 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Paul H Kyzivat Original-CC: Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > > Craig Ryan wrote: > > > > >For the core of a default resolution I suggest that in GIOP 1.2 the > > >values that are assigned for request ids be restricted - the orb that > > >initiated the connection shall use only even request ids, and the orb > > >that accepts a connection shall use only odd request ids. > > > > I disagree this is the most simple solution. > > I sent an earlier mail out, but have not seen it yet. Sorry if this duplicate gets to you twice. Why cannot the orb detect that it has received a requiest with a request ID which it has outstanding from its own side? It can then reject the request by sending a system exception. This does not change the protocol, but allows for an escape when this not typical situation occurs. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Cc: Paul H Kyzivat , andrew@omg.org, interop@omg.org Date: Thu, 15 Jul 1999 14:21:37 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Jonathan Biggar Original-CC: Paul H Kyzivat , andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jonathan Biggar wrote: > > Tom Rutt wrote: > > > > Paul H Kyzivat wrote: > > > > > > I wish to raise the following as an urgent issue: > > > > > > . > > > > > > It is supposed to be possible for these requests to overlap in time, so > > > long as the sequence of messages in each is preserved. That could lead > > > to the following combined sequence of messages: > > > > > > SA SB > > > ========== ========== > > > M1-Rqst:#A -> > > > <- M5-Rqst:#B > > As soon as SA sees that #B is equal to an outstanding requiest > > id of its own, it can send a system exception, rejecting > > the M5 request. > > > > This seems less radical a proposed change than even/odd request > > ids per side. > > This won't work. There isn't a standard system exception that forces > the sending side to resend the invocation transparently, so this "fix" > would cause spurious exceptions on the sender. > Why not a TRANSIENT error. If the original orb waits long enough, the request ID will no longer be in use by the other orb in outstanding request, and the oridinal invocation would work if resent. I do not see it as unworkable, and this event will hardly ever occur. > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Sender: jon@floorboard.com Date: Thu, 15 Jul 1999 13:52:13 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: terutt@lucent.com CC: Paul H Kyzivat , andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Tom Rutt wrote: > > This won't work. There isn't a standard system exception that forces > > the sending side to resend the invocation transparently, so this "fix" > > would cause spurious exceptions on the sender. > > > > Why not a TRANSIENT error. > > If the original orb waits long enough, the request ID will no longer > be in use by the other orb in outstanding request, and the oridinal > invocation would work if resent. > > I do not see it as unworkable, and this event will hardly ever > occur. Because the semantics of TRANSIENT do not currently guarantee that the protocol stack resend the request rather than exposing the exception to the client code. I also disagree that this will hardly ever occur, unless we also have a requirement that all connections start with a random number for the request id. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 15 Jul 1999 17:19:40 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: terutt@lucent.com CC: Jonathan Biggar , andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Tom - I just saw all of your replies in a bunch. So this is a response to all of them. I don't believe what you suggest would totally fix the problem. The following is a minor variation on the original posting: SA SB ========== ========== M1-Rqst:#A -> <- M5-Rqst:#B M2-Frag:#A -> <- M3-Resp:#A <- M6-Frag:#B <- M4-Frag:#A M7-Resp:#B -> M8-Frag:#B -> If M6 is sent before SA notices that M5 contains a conflicting request id, then when SA receives M6 it won't know whether it is a continuation of the rejected M5 or of the response M3. I suppose SB could be responsible for detecting the situation when it receives M1, but then what should it do? Must it send a CancelRequest with request id #A? This seems far to complex and fraught with race conditions to be an acceptable technique to me. And handling this via backoff retry also seems ugly. Nor is there any guarantee that the two sides won't continue to conflict if they both keep retrying. Paul Tom Rutt wrote: > > Jonathan Biggar wrote: > > > > Tom Rutt wrote: > > > > > > Paul H Kyzivat wrote: > > > > > > > > I wish to raise the following as an urgent issue: > > > > > > > > . > > > > > > > > It is supposed to be possible for these requests to overlap in > time, so > > > > long as the sequence of messages in each is preserved. That > could lead > > > > to the following combined sequence of messages: > > > > > > > > SA SB > > > > ========== ========== > > > > M1-Rqst:#A -> > > > > <- M5-Rqst:#B > > > As soon as SA sees that #B is equal to an outstanding requiest > > > id of its own, it can send a system exception, rejecting > > > the M5 request. > > > > > > This seems less radical a proposed change than even/odd request > > > ids per side. > > > > This won't work. There isn't a standard system exception that > forces > > the sending side to resend the invocation transparently, so this > "fix" > > would cause spurious exceptions on the sender. > > > > Why not a TRANSIENT error. > > If the original orb waits long enough, the request ID will no longer > be in use by the other orb in outstanding request, and the oridinal > invocation would work if resent. > > I do not see it as unworkable, and this event will hardly ever > occur. > > -- > > Jon Biggar > > Floorboard Software > > jon@floorboard.com > > jon@biggar.org > > -- > > Tom Rutt email: > terutt@lucent.com > Lucent Technologies Bell Labs Tel: +1(732)949-7862 > Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA Date: Thu, 15 Jul 1999 17:25:42 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Stefan Wengi CC: Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Stefan Wengi wrote: > > disagree. > When gateways and proxies are used (e.g. firewalls) you may have mixed > GIOP version over a single connection. Could you please elaborate on that? Mixed protocol use implies to me that you have independent agents dropping full messages into the message stream without remarshalling them. If so, how do they manage to coordinate their assignment of request ids? At the least you must have only one entity assigning request ids in each direction on the connection. Sender: sgw@adnovum.com Date: Thu, 15 Jul 1999 14:28:28 -0700 From: Stefan Wengi Organization: AdNovum Software Inc. X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en To: Paul H Kyzivat CC: Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > > Stefan Wengi wrote: > > > > disagree. > > When gateways and proxies are used (e.g. firewalls) you may have mixed > > GIOP version over a single connection. > > Could you please elaborate on that? Mixed protocol use implies to me > that you have independent agents dropping full messages into the message > stream without remarshalling them. If so, how do they manage to > coordinate their assignment of request ids? At the least you must have > only one entity assigning request ids in each direction on the > connection. This entity can also be a proxy assigning new (unique) request ids before forwarding a request. Stefan Date: Thu, 15 Jul 1999 17:46:52 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Craig Ryan CC: jon@floorboard.com, kukura@eggs.dublin.iona.ie, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Craig Ryan wrote: > > Hi Jon, Paul > > I spoke to Bob about this some time back and it wasnt clear if > multiple versions were specifically illegal over a specific > connection, I also cant see an obvious reason not to allow a client to > establish multiple bindings over a connection, each talking different > versions - hence my assumption they're legal. Can you please clarify > why this restriction would exist, and specifically where the spec > points it out? This would also help clarify the current issue. Bidirectional giop is only defined in giop 1.2. Are you suggesting that SA might send a giop 1.2 request to SB and use it to negotiate bidir giop on a connection, send a 1.2 compatible callback object reference, take callbacks from SB on the same connection, and still decide to send some requests with giop 1.1? Perhaps you are correct. It would seem peculiar, but perhaps it is only necessary for a request, its continuation fragments, the corresponding reply and its fragments to be of the same version. I suppose this could happen if some old object references that have been stored in a name server for a long time are picked up and used by applications that have been migrated to a new orb version. If so, then either we must assume that the implementations of all the versions on the same end of the same connection coordinate their request id assignment, or else we must require the request ids for one version of the protocol to be independent of those for another version of the protocol. Date: Thu, 15 Jul 1999 18:08:05 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Stefan Wengi CC: Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Stefan Wengi wrote: > > Paul H Kyzivat wrote: > > > > Could you please elaborate on that? Mixed protocol use implies to me > > that you have independent agents dropping full messages into the > > message stream without remarshalling them. If so, how do they manage > > to coordinate their assignment of request ids? At the least you must > > have only one entity assigning request ids in each direction on the > > connection. > > This entity can also be a proxy assigning new (unique) request ids > before forwarding a request. If the proxy is assigning new request ids, then it should be capable of assigning them compatibly with the rule we are proposing for giop 1.2. Of course it had better have a way of resolving the same ambiguities in order to correctly assign the new request ids. But I don't want to push this solution too hard. If it is going to present problems, then we can try something else. One possibility that just occurred to me is to use a bit in the giop header to indicate that this message is a reverse-flow message; traveling in the opposite direction from normal due to use of bi-directional giop. It would be redundant for all asymetric message types that normally only flow in one direction, but would be significant for Fragments. The initiator of a connection would set the reverse-flow bit on fragments that continue a reply, while the acceptor of a connection would do the reverse. Date: Thu, 15 Jul 1999 15:26:18 PDT Sender: Bill Janssen From: Bill Janssen To: Craig Ryan , Paul H Kyzivat Subject: Re: fragmentation broken with bi-dir giop CC: jon@floorboard.com, kukura@eggs.dublin.iona.ie, interop@omg.org Excerpts from local.omg: 15-Jul-99 Re: fragmentation broken wi.. Paul H Kyzivat@roguewave (1545*) > Bidirectional giop is only defined in giop 1.2. Are you suggesting that > SA might send a giop 1.2 request to SB and use it to negotiate bidir > giop on a connection, send a 1.2 compatible callback object reference, > take callbacks from SB on the same connection, and still decide to send > some requests with giop 1.1? While things could be defined this way, it makes little sense to me. It's fairly clear in the current spec that GIOP is a connection-oriented protocol. The version of GIOP being used on the connection must be a primary characteristic of that connection. It's what allows us to decide what to do with various connection settings, like character sets. It allows us to decide which are allowed and/or required. I'd suggest that the setting available on the server determines a range of acceptable GIOP levels, and the first request on the connection determines the actual level. That is, a server advertising GIOP 1.2 really offers GIOP 1.0, 1.1, and 1.2, and the client then determines which level to use. But after making that determination, the client should not drop down in levels. I'd hate to have to remember that I can fragment replies to this request, but not to that request -- much less implement that chaos. Maybe it's past time to replace GIOP with something rationally designed? Bill Date: Thu, 15 Jul 1999 15:28:37 PDT Sender: Bill Janssen From: Bill Janssen To: Stefan Wengi , Paul H Kyzivat Subject: Re: fragmentation broken with bi-dir giop CC: Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Excerpts from local.omg: 15-Jul-99 Re: fragmentation broken wi.. Paul H Kyzivat@roguewave (1421*) > One possibility that just occurred to me is to use a bit in the giop > header to indicate that this message is a reverse-flow message; > traveling in the opposite direction from normal due to use of > bi-directional giop. While I might quibble with the idea of "normal", this would be fine with me. Bill Sender: sgw@adnovum.com Date: Thu, 15 Jul 1999 15:30:42 -0700 From: Stefan Wengi Organization: AdNovum Software Inc. X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en To: Paul H Kyzivat CC: Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > > Stefan Wengi wrote: > > > > Paul H Kyzivat wrote: > > > > > > Could you please elaborate on that? Mixed protocol use implies to me > > > that you have independent agents dropping full messages into the > > > message stream without remarshalling them. If so, how do they manage > > > to coordinate their assignment of request ids? At the least you must > > > have only one entity assigning request ids in each direction on the > > > connection. > > > > This entity can also be a proxy assigning new (unique) request ids > > before forwarding a request. > > If the proxy is assigning new request ids, then it should be capable of > assigning them compatibly with the rule we are proposing for giop 1.2. > > Of course it had better have a way of resolving the same ambiguities in > order to correctly assign the new request ids. > > But I don't want to push this solution too hard. If it is going to > present problems, then we can try something else. I just wanted to stress the fact that multiple GIOP versions over a single connection must be possible. > One possibility that just occurred to me is to use a bit in the giop > header to indicate that this message is a reverse-flow message; > traveling in the opposite direction from normal due to use of > bi-directional giop. It would be redundant for all asymetric message > types that normally only flow in one direction, but would be significant > for Fragments. The initiator of a connection would set the reverse-flow > bit on fragments that continue a reply, while the acceptor of a > connection would do the reverse. To me the correct solution would be to add a member to the GIOP_FragmentHeader_1_2. This would be a bool indicating the message type (request/reply) or even better an enum of type GIOP_MsgType_1_2. Reserving one bit of the 'flags' in the header only for fragmentation is a waste and bad design ;-) Stefan Date: Thu, 15 Jul 1999 15:41:11 PDT Sender: Bill Janssen From: Bill Janssen To: Paul H Kyzivat , Stefan Wengi Subject: Re: fragmentation broken with bi-dir giop CC: Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Excerpts from local.omg: 15-Jul-99 Re: fragmentation broken wi.. Stefan Wengi@adnovum.com (1915*) > I just wanted to stress the fact that multiple GIOP versions over a > single connection must be possible. Again, I think that this is a broken idea. What makes you think claim it `must be possible'? That is, why do you want it to be possible? Bill Date: Thu, 15 Jul 1999 19:38:34 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Stefan Wengi CC: Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Stefan Wengi wrote: > > To me the correct solution would be to add a member to the > GIOP_FragmentHeader_1_2. > This would be a bool indicating the message type (request/reply) or > even better an enum of type GIOP_MsgType_1_2. > Reserving one bit of the 'flags' in the header only for fragmentation > is a waste and bad design ;-) These were both other possibilities that I floated early on. I would be happy with either. The 1.2 fragment header is different from 1.1 so a change is needed to support it in any case, and this is no harder. Sender: jon@floorboard.com Date: Thu, 15 Jul 1999 16:49:39 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: Paul H Kyzivat CC: Stefan Wengi , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > > Stefan Wengi wrote: > > > > To me the correct solution would be to add a member to the > > GIOP_FragmentHeader_1_2. > > This would be a bool indicating the message type (request/reply) or > > even better an enum of type GIOP_MsgType_1_2. > > Reserving one bit of the 'flags' in the header only for fragmentation > > is a waste and bad design ;-) > > These were both other possibilities that I floated early on. > I would be happy with either. The 1.2 fragment header is different from > 1.1 so a change is needed to support it in any case, and this is no > harder. This isn't a good idea, since there isn't a spare bit in the 1.2 fragment header. You would have to increase its size, which messes up the current nice alignment characteristics of the 1.2 fragment header. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@floorboard.com Date: Thu, 15 Jul 1999 16:54:10 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: Paul H Kyzivat CC: Stefan Wengi , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > But I don't want to push this solution too hard. If it is going to > present problems, then we can try something else. > > One possibility that just occurred to me is to use a bit in the giop > header to indicate that this message is a reverse-flow message; > traveling in the opposite direction from normal due to use of > bi-directional giop. It would be redundant for all asymetric message > types that normally only flow in one direction, but would be significant > for Fragments. The initiator of a connection would set the reverse-flow > bit on fragments that continue a reply, while the acceptor of a > connection would do the reverse. I think that this is the best idea so far in terms of cleanness. It consistently applies a bit to all GIOP messages rather than just the kludge for only fragment messages, and perhaps may be useful for other purposes in the future. I would accept this change if we can style it as an "urgent" clarification/bugfix for GIOP 1.2. If we can't do that, then I think the only thing left that could just be called a "clarification" is the even/odd hack. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: sgw@adnovum.com Date: Thu, 15 Jul 1999 17:02:06 -0700 From: Stefan Wengi Organization: AdNovum Software Inc. X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en To: Jonathan Biggar CC: Paul H Kyzivat , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jonathan Biggar wrote: > > Paul H Kyzivat wrote: > > > > Stefan Wengi wrote: > > > > > > To me the correct solution would be to add a member to the > > > GIOP_FragmentHeader_1_2. > > > This would be a bool indicating the message type (request/reply) or > > > even better an enum of type GIOP_MsgType_1_2. > > > Reserving one bit of the 'flags' in the header only for fragmentation > > > is a waste and bad design ;-) > > > > These were both other possibilities that I floated early on. > > I would be happy with either. The 1.2 fragment header is different from > > 1.1 so a change is needed to support it in any case, and this is no > > harder. > > This isn't a good idea, since there isn't a spare bit in the 1.2 > fragment header. You would have to increase its size, which messes up > the current nice alignment characteristics of the 1.2 fragment header. Well, considering that fragmentation is used only in the case of big messages one could argue that 'wasting' a few bytes wouldn't be too bad. Stefan From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: Jonathan Biggar cc: interop@omg.org Date: Fri, 16 Jul 1999 07:30:29 -0500 Subject: Re: fragmentation broken with bi-dir giop I DO NOT think this is a good idea. The concept of reverse flow gets shadowy in a multi-tiered system. When a creature is both a client and a server, one would have to be careful to determine which messages are reverse flow; and if the communication is peer-to-peer, the distinction is obliterated. I see no problem with an extra flag on the Fragment header for request/reply. Or, if folks don't like mucking with the size of the header, just replace the Fragment message with a RequestFragment message and a ReplyFragment message. (Question from my naivete: has anyone actually implemented fragment messages?) Russell Butek butek@us.ibm.com Jonathan Biggar on 07/15/99 06:54:10 PM To: Paul H Kyzivat cc: Stefan Wengi , Craig Ryan , Andrew Watson , interop@omg.org (bcc: Russell Butek/Austin/IBM) Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > But I don't want to push this solution too hard. If it is going to > present problems, then we can try something else. > > One possibility that just occurred to me is to use a bit in the giop > header to indicate that this message is a reverse-flow message; > traveling in the opposite direction from normal due to use of > bi-directional giop. It would be redundant for all asymetric message > types that normally only flow in one direction, but would be significant > for Fragments. The initiator of a connection would set the reverse-flow > bit on fragments that continue a reply, while the acceptor of a > connection would do the reverse. I think that this is the best idea so far in terms of cleanness. It consistently applies a bit to all GIOP messages rather than just the kludge for only fragment messages, and perhaps may be useful for other purposes in the future. I would accept this change if we can style it as an "urgent" clarification/bugfix for GIOP 1.2. If we can't do that, then I think the only thing left that could just be called a "clarification" is the even/odd hack. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 16 Jul 1999 08:39:34 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: "Adrian St. John" CC: Bill Janssen , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Adrian St. John wrote: > > > Again, I think that this is a broken idea. What makes you think > > claim it `must be possible'? That is, why do you want it to be > > possible? > > It is possible because of: > > 1. GIOP header has a version number in it > 2. Nothing in the spec says that the client can't change GIOP > versions, > as long as it doesn't go higher than the advertised version in the > IOR. > > As long as these two conditions are true, nobody can make assumptions > about the GIO version staying the same for the lifetime of the > connection. This seemed odd to me at first, but upon reflection it now seems almost unavoidable to me. The following is one likely scenario for this happening: 1) a server publishes an object reference to itself in a persistent name service. The object reference indicates giop 1.1 because that is the highest version the orb supports. 2) the application is shutdown and rebuilt with a newer version of the orb that supports giop 1.2. 3) a client with a giop 1.2 capable orb fetches the old object reference from the name service and invokes on it. Because the objref specifies giop 1.1, the client uses 1.1 to do the invocation. 4) the first invocation causes the server to create and return a new object reference to itself. Because the server is now using a 1.2 capable orb, the new reference is marked as 1.2. 5) the client invokes on the newly returned reference. Because it has the same address, the same connection is used. Because the reference specifies 1.2 and the client is capable of 1.2, the request is sent using giop 1.2. In this scenario I suppose the client could decide to use giop 1.1 for the second invocation, for consistency. But I think I could come up with another scenario where giop 1.2 was used first and the giop 1.1 IOR was discovered and used later. In this case there would be no choice according to current rules. Date: Fri, 16 Jul 1999 08:45:30 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jonathan Biggar CC: Stefan Wengi , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jonathan Biggar wrote: > > Paul H Kyzivat wrote: > > > > Stefan Wengi wrote: > > > > > > To me the correct solution would be to add a member to the > > > GIOP_FragmentHeader_1_2. > > > This would be a bool indicating the message type (request/reply) > > > or even better an enum of type GIOP_MsgType_1_2. > > > Reserving one bit of the 'flags' in the header only for > > > fragmentation is a waste and bad design ;-) > > > > These were both other possibilities that I floated early on. > > I would be happy with either. The 1.2 fragment header is different > > from 1.1 so a change is needed to support it in any case, and this > > is no harder. > > This isn't a good idea, since there isn't a spare bit in the 1.2 > fragment header. You would have to increase its size, which messes up > the current nice alignment characteristics of the 1.2 fragment header. I guess the 1.2 fragment header currently is just the right size to put the fragment body on a mod-8 boundary. If it is important to preserve that, I would have no problem adding 8 bytes to the header instead of just 4. As stefan mentioned in another reply, wasting a few more bytes isn't a big deal in a fragment header. Date: Fri, 16 Jul 1999 08:57:08 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jonathan Biggar CC: Stefan Wengi , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jonathan Biggar wrote: > > Paul H Kyzivat wrote: > > But I don't want to push this solution too hard. If it is going to > > present problems, then we can try something else. > > > > One possibility that just occurred to me is to use a bit in the giop > > header to indicate that this message is a reverse-flow message; > > traveling in the opposite direction from normal due to use of > > bi-directional giop. It would be redundant for all asymetric message > > types that normally only flow in one direction, but would be > > significant for Fragments. The initiator of a connection would set > > the reverse-flow bit on fragments that continue a reply, while the > > acceptor of a connection would do the reverse. > > I think that this is the best idea so far in terms of cleanness. It > consistently applies a bit to all GIOP messages rather than just the > kludge for only fragment messages, and perhaps may be useful for other > purposes in the future. I thought so to. My earlier thoughts on how to use a bit in the giop header all seemed like a kludge, while this doesn't. > I would accept this change if we can style it as an "urgent" > clarification/bugfix for GIOP 1.2. If we can't do that, then I think > the only thing left that could just be called a "clarification" is the > even/odd hack. After the discussion I think I strongly prefer this because the even/odd "clarification" is rapidly becoming an obfuscation due to the accomodations needed for mixed giop version usage on a connection. I would like to request a straw vote on whether this would be an acceptable urgent bugfix for GIOP 1.2. If it seems to be, then I can write up some precise editing instructions for a formal vote. Date: Fri, 16 Jul 1999 10:50:48 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: butek@us.ibm.com CC: Jonathan Biggar , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop butek@us.ibm.com wrote: > > I DO NOT think this is a good idea. The concept of reverse flow gets > shadowy in a multi-tiered system. When a creature is both a client > and a server, one would have to be careful to determine which > messages are reverse flow; and if the communication is peer-to-peer, > the distinction is obliterated. Perhaps "reverse flow" is not the best possible terminology. But the fact is that every connection has two distinguishable ends - the one that initiated the connection and the one that accepted it. And in the absence of the bi-directional feature, each giop message type flows in only one direction, with the exception of fragment message. And in its case, its role is different depending on the direction it flows. I don't think the concept gets any more shadowy with multiple tiers. > > I see no problem with an extra flag on the Fragment header for > request/reply. Or, if folks don't like mucking with the size of > the header, just replace the Fragment message with a RequestFragment > message and a ReplyFragment message. I can also live with either of those approaches. > > (Question from my naivete: has anyone actually implemented fragment > messages?) We implement GIOP 1.1 with fragmentation. Obviously I am working on 1.2. Sender: jis@fpk.hp.com Date: Fri, 16 Jul 1999 11:06:21 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Bill Janssen CC: Paul H Kyzivat , Stefan Wengi , Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Bill Janssen wrote: > > Excerpts from local.omg: 15-Jul-99 Re: fragmentation broken wi.. Stefan > Wengi@adnovum.com (1915*) > > > I just wanted to stress the fact that multiple GIOP versions over a > > single connection must be possible. > > Again, I think that this is a broken idea. What makes you think claim > it `must be possible'? That is, why do you want it to be possible? > > Bill I strongly agree with Bill on this one. I would like to see a very persuasive argument for requiring this before we say that it is allowed. So far I have not seen such an argument, and currebtly this is not allowed. If necessary we should add language to the spec to specifically say that mixing of GIOP versions on the same connection is not allowed. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Fri, 16 Jul 1999 11:16:45 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en To: Jishnu Mukerji CC: Bill Janssen , Paul H Kyzivat , Stefan Wengi , Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Here's a potentially persuasive argument on the mixing versions issue: * nothing in the officially published GIOP 1.1 specification prohibits mixing GIOP 1.0 and 1.1 messages over a connection (if anyone has evidence to the contrary, please supply it) * some existing GIOP 1.1 implementations already do mix vesions 1.0 and 1.1 over a connection * we can't retroactively change GIOP 1.1 * there's not much point in prohibiting mixing 1.2 with 1.0 and 1.1 if 1.0 and 1.1 can already be mixed Several IIOP client implementations I am familiar with share connections when the host and port are identical. Forcing this code to also take the advertized version into account would make this code more complicated without achieving anything. It would also waste connections to not allow this sharing. In this case, I suggest we either leave it alone, or add some text explicitly clarifying that GIOP versions can be mixed on an IIOP connection. -Bob Jishnu Mukerji wrote: > > Bill Janssen wrote: > > > > Excerpts from local.omg: 15-Jul-99 Re: fragmentation broken wi.. Stefan > > Wengi@adnovum.com (1915*) > > > > > I just wanted to stress the fact that multiple GIOP versions over a > > > single connection must be possible. > > > > Again, I think that this is a broken idea. What makes you think claim > > it `must be possible'? That is, why do you want it to be possible? > > > > Bill > > I strongly agree with Bill on this one. I would like to see a very > persuasive argument for requiring this before we say that it is allowed. > So far I have not seen such an argument, and currebtly this is not > allowed. If necessary we should add language to the spec to specifically > say that mixing of GIOP versions on the same connection is not allowed. > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Sender: andrew@emerald.omg.org Date: Fri, 16 Jul 1999 11:17:14 -0400 To: Paul H Kyzivat From: Andrew Watson Subject: Re: fragmentation broken with bi-dir giop Cc: interop@omg.org Paul, You wrote: > > > One possibility that just occurred to me is to use a bit in the giop > > > header to indicate that this message is a reverse-flow message; > > > traveling in the opposite direction from normal due to use of > > > bi-directional giop. It would be redundant for all asymetric message > > > types that normally only flow in one direction, but would be > > > significant for Fragments. The initiator of a connection would set > > > the reverse-flow bit on fragments that continue a reply, while the > > > acceptor of a connection would do the reverse. > > > > I think that this is the best idea so far in terms of cleanness. It > > consistently applies a bit to all GIOP messages rather than just the > > kludge for only fragment messages, and perhaps may be useful for other > > purposes in the future. > > I thought so to. My earlier thoughts on how to use a bit in the giop > header all seemed like a kludge, while this doesn't. > > > I would accept this change if we can style it as an "urgent" > > clarification/bugfix for GIOP 1.2. If we can't do that, then I think > > the only thing left that could just be called a "clarification" is the > > even/odd hack. > > After the discussion I think I strongly prefer this because the even/odd > "clarification" is rapidly becoming an obfuscation due to the > accomodations needed for mixed giop version usage on a connection. > > I would like to request a straw vote on whether this would be an > acceptable urgent bugfix for GIOP 1.2. If it seems to be, then I can > write up some precise editing instructions for a formal vote. If you can send me your precisely-worded issue resolution today, I'll start the clock running on an urgent resolution, with your fix as the default. In the unlikely event that the TF deadlocks, the default automatically becomes the resolution of the issue in two weeks' time. However, in spite of the existence of a default, the TF can choose any resolution it pleases using the normal voting process, coordinated by the chair (Tom Rutt) in the usual way. Thanks, Andrew Sender: jon@floorboard.com Date: Fri, 16 Jul 1999 09:07:40 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: Paul H Kyzivat CC: "Adrian St. John" , Bill Janssen , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > > As long as these two conditions are true, nobody can make assumptions > > about the GIO version staying the same for the lifetime of the > > connection. > > This seemed odd to me at first, but upon reflection it now seems almost > unavoidable to me. The following is one likely scenario for this > happening: > > 1) a server publishes an object reference to itself in a persistent name > service. The object reference indicates giop 1.1 because that is the > highest version the orb supports. > > 2) the application is shutdown and rebuilt with a newer version of the > orb that supports giop 1.2. > > 3) a client with a giop 1.2 capable orb fetches the old object reference > from the name service and invokes on it. Because the objref specifies > giop 1.1, the client uses 1.1 to do the invocation. > > 4) the first invocation causes the server to create and return a new > object reference to itself. Because the server is now using a 1.2 > capable orb, the new reference is marked as 1.2. > > 5) the client invokes on the newly returned reference. Because it has > the same address, the same connection is used. Because the reference > specifies 1.2 and the client is capable of 1.2, the request is sent > using giop 1.2. This scenario is broken, since the connection is established using GIOP 1.1 and the client has no information that suggests that the server on the other end supports GIOP 1.2. This means that the client MUST open a new connection if it wants to use GIOP 1.2 for the second object reference. > In this scenario I suppose the client could decide to use giop 1.1 for > the second invocation, for consistency. But I think I could come up with > another scenario where giop 1.2 was used first and the giop 1.1 IOR was > discovered and used later. In this case there would be no choice > according to current rules. In this scenario, there is no reason for the client to use GIOP 1.1, since it already knows that the connection supports GIOP 1.2! -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 16 Jul 1999 09:46:14 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , "Adrian St. John" Subject: Re: fragmentation broken with bi-dir giop CC: interop@omg.org Excerpts from direct: 16-Jul-99 Re: fragmentation broken wi.. "Adrian St. John"@realob (913*) > > Again, I think that this is a broken idea. What makes you think claim > > it `must be possible'? That is, why do you want it to be possible? > It is possible because of: > 1. GIOP header has a version number in it > 2. Nothing in the spec says that the client can't change GIOP versions, > as long as it doesn't go higher than the advertised version in the IOR. > As long as these two conditions are true, nobody can make assumptions > about the GIO version staying the same for the lifetime of the > connection. But what is it good for? Bill Date: Fri, 16 Jul 1999 10:03:33 PDT Sender: Bill Janssen From: Bill Janssen To: Jishnu Mukerji , Bob Kukura Subject: Re: fragmentation broken with bi-dir giop CC: Bill Janssen , Paul H Kyzivat , Stefan Wengi , Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Hmmm, let's see if this persuades? Excerpts from direct: 16-Jul-99 Re: fragmentation broken wi.. Bob Kukura@iona.com (2007*) > Here's a potentially persuasive argument on the mixing versions issue: > * nothing in the officially published GIOP 1.1 specification prohibits > mixing GIOP 1.0 and 1.1 messages over a connection (if anyone has > evidence to the contrary, please supply it) That's not persuasive, it's just another of the many omissions in the spec. > * some existing GIOP 1.1 implementations already do mix vesions 1.0 and > 1.1 over a connection That's the only half-way decent argument I've heard. But it's not really a reason to do it; that is, it doesn't explain what's improved by letting this happen. I'd just declare this a bug. > * we can't retroactively change GIOP 1.1 Well, we did it with 1.0 when we defined 1.1. We just explicitly declare the mixing behavior (which is nowhere explicitly specified, and, I argue, implicitly disallowed by the connection semantics introduced in the Type Extensions RFP) broken. > * there's not much point in prohibiting mixing 1.2 with 1.0 and 1.1 if > 1.0 and 1.1 can already be mixed This point then goes away. Bill Date: Fri, 16 Jul 1999 13:03:47 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jonathan Biggar CC: "Adrian St. John" , Bill Janssen , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jonathan Biggar wrote: > > This scenario is broken, since the connection is established using > GIOP 1.1 and the client has no information that suggests that the > server on the other end supports GIOP 1.2. Why do you say that? The client has the object reference with says the server of that object reference supports 1.2. There is no separate handshake to negotiate the version of the connection - there is only the request that is sent in a version compatible with what the object reference specifies. Why should the client think that a different connection to the same endpoint would have any different capabilities that the connection it already has? > This means that the client MUST open a new connection if it wants > to use GIOP 1.2 for the second object reference. > > In this scenario I suppose the client could decide to use giop 1.1 > > for the second invocation, for consistency. But I think I could > > come up with another scenario where giop 1.2 was used first and the > > giop 1.1 IOR was discovered and used later. In this case there would > > be no choice according to current rules. > > In this scenario, there is no reason for the client to use GIOP 1.1, > since it already knows that the connection supports GIOP 1.2! If I have an IOR that specifies 1.1, am I permitted to invoke it using 1.2? I don't think so. Section 15.4.1 states "A client should not send a GIOP message having a higher minor version number than that published by the server in the tag Internet IIOP Profile body of an IOR." This is itself ambiguous because it says "an IOR", not "the IOR". For reasons that have been stated by several others, I now believe the use of multiple giop versions on the same connection must be permitted. In the situation of the first scenario above, I do not want to be forced to keep multiple connections to the same endpoint, distinguished only by the giop version, and have to select which to use based on ior attributes. This is a much harder problem for me than handling a different message header format. Date: Fri, 16 Jul 1999 13:11:17 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Andrew Watson CC: interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Andrew, Can you explain the details of the urgent issue process? When did/does the two week clock start? When I sent you the issue; when you have a default resolution in hand, or what? Based on discussion so far I am now not convinced that the default resolution I sketched out using even/odd request ids is a correct one. At best it is incomplete and will require added constraints to make it sufficient. Also, are there limitations on the extent of a change permitted according to this process? In other words, does this process favor a change like the even/odd one that doesn't require any change to the on-wire formats? Depending on the answers to the above, I am willing to draft a default resolution. But I think it is almost certain to be unacceptable to someone, and may prove to be unacceptable to me after a bit more discussion. Paul Andrew Watson wrote: > > Paul, > > You wrote: > > > > > One possibility that just occurred to me is to use a bit in the > giop > > > > header to indicate that this message is a reverse-flow message; > > > > traveling in the opposite direction from normal due to use of > > > > bi-directional giop. It would be redundant for all asymetric > message > > > > types that normally only flow in one direction, but would be > > > > significant for Fragments. The initiator of a connection would > set > > > > the reverse-flow bit on fragments that continue a reply, while > the > > > > acceptor of a connection would do the reverse. > > > > > > I think that this is the best idea so far in terms of cleanness. > It > > > consistently applies a bit to all GIOP messages rather than just > the > > > kludge for only fragment messages, and perhaps may be useful for > other > > > purposes in the future. > > > > I thought so to. My earlier thoughts on how to use a bit in the giop > > header all seemed like a kludge, while this doesn't. > > > > > I would accept this change if we can style it as an "urgent" > > > clarification/bugfix for GIOP 1.2. If we can't do that, then I > think > > > the only thing left that could just be called a "clarification" is > the > > > even/odd hack. > > > > After the discussion I think I strongly prefer this because the > even/odd > > "clarification" is rapidly becoming an obfuscation due to the > > accomodations needed for mixed giop version usage on a connection. > > > > I would like to request a straw vote on whether this would be an > > acceptable urgent bugfix for GIOP 1.2. If it seems to be, then I can > > write up some precise editing instructions for a formal vote. > > If you can send me your precisely-worded issue resolution today, I'll > start > the clock running on an urgent resolution, with your fix as the > default. In > the unlikely event that the TF deadlocks, the default automatically > becomes > the resolution of the issue in two weeks' time. However, in spite of > the > existence of a default, the TF can choose any resolution it pleases > using > the normal voting process, coordinated by the chair (Tom Rutt) in the > usual > way. > > Thanks, > > Andrew Date: Fri, 16 Jul 1999 10:12:05 PDT Sender: Bill Janssen From: Bill Janssen To: Jonathan Biggar , Paul H Kyzivat Subject: Re: fragmentation broken with bi-dir giop CC: "Adrian St. John" , Bill Janssen , interop@omg.org Excerpts from direct: 16-Jul-99 Re: fragmentation broken wi.. Paul H Kyzivat@roguewave (2049*) > Section 15.4.1 states "A client should not send a GIOP message having a > higher minor version number than that published by the server in the tag > Internet IIOP Profile body of an IOR." This is itself ambiguous because > it says "an IOR", not "the IOR". > For reasons that have been stated by several others, I now believe the > use of multiple giop versions on the same connection must be permitted. > In the situation of the first scenario above, I do not want to be forced > to keep multiple connections to the same endpoint, distinguished only by > the giop version, and have to select which to use based on ior > attributes. This is a much harder problem for me than handling a > different message header format. Yes, I agree that it's a nasty little implementation problem. But the connection-oriented semantics of GIOP force it on us. It's not just the host and port that determine `what' a connection connects to; it's the semantics allowed on that connection, which is defined by the GIOP version. Why? Because we've allowed semantics to be established by tunnelling connection characteristics inside individual requests and replies, instead of adding messages specifically designed for that purpose. So instead of keeping track of connections by a 2-ple of (host, port), keep them as a 3-ple of (host, port, giop-version). Bill Date: Fri, 16 Jul 1999 13:18:47 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Bob Kukura CC: Jishnu Mukerji , Bill Janssen , Stefan Wengi , Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Bob Kukura wrote: > > Here's a potentially persuasive argument on the mixing versions issue: [snip] I have been convinced. Date: Fri, 16 Jul 1999 10:29:54 PDT Sender: Bill Janssen From: Bill Janssen To: Paul H Kyzivat , Jonathan Biggar Subject: Re: fragmentation broken with bi-dir giop CC: Stefan Wengi , Craig Ryan , Andrew Watson , interop@omg.org I'd go for this one, too. It also works regardless of what we think about sending mixed GIOP headers on the same connection. Excerpts from local.omg: 15-Jul-99 Re: fragmentation broken wi.. Jonathan Biggar@floorboa (1191*) > Paul H Kyzivat wrote: > > But I don't want to push this solution too hard. If it is going to > > present problems, then we can try something else. > > > > One possibility that just occurred to me is to use a bit in the giop > > header to indicate that this message is a reverse-flow message; > > traveling in the opposite direction from normal due to use of > > bi-directional giop. It would be redundant for all asymetric message > > types that normally only flow in one direction, but would be significant > > for Fragments. The initiator of a connection would set the reverse-flow > > bit on fragments that continue a reply, while the acceptor of a > > connection would do the reverse. > I think that this is the best idea so far in terms of cleanness. It > consistently applies a bit to all GIOP messages rather than just the > kludge for only fragment messages, and perhaps may be useful for other > purposes in the future. > I would accept this change if we can style it as an "urgent" > clarification/bugfix for GIOP 1.2. If we can't do that, then I think > the only thing left that could just be called a "clarification" is the > even/odd hack. > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Sender: sgw@adnovum.com Date: Fri, 16 Jul 1999 10:31:29 -0700 From: Stefan Wengi Organization: AdNovum Software Inc. X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en To: Bill Janssen CC: "Adrian St. John" , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Bill Janssen wrote: > > Excerpts from direct: 16-Jul-99 Re: fragmentation broken wi.. "Adrian > St. John"@realob (913*) > > > > Again, I think that this is a broken idea. What makes you think claim > > > it `must be possible'? That is, why do you want it to be possible? > > > It is possible because of: > > > 1. GIOP header has a version number in it > > 2. Nothing in the spec says that the client can't change GIOP versions, > > as long as it doesn't go higher than the advertised version in the IOR. > > > As long as these two conditions are true, nobody can make assumptions > > about the GIO version staying the same for the lifetime of the > > connection. > > But what is it good for? Again, for generic gateways, maybe store&forward systems. Nobody has opposed to that yet. If you would forbid version mixing the GIOP header would carry redundant version information in messages 2..n. -> you'd better redefine the header (adding something like a connection setup message) and I bet nobody wants to do that. Btw. talking about versions: has anyone ever brought up the idea to add a vendor tag and a vendor version to the GIOP header? I know that this seems ugly from a theoretical point of view but in reality it would be very, very helpful (workarounds for known implementation flaws/bugs). Stefan Date: Fri, 16 Jul 1999 13:35:12 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jishnu Mukerji CC: Bill Janssen , Stefan Wengi , Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jishnu Mukerji wrote: > > I strongly agree with Bill on this one. I would like to see a very > persuasive argument for requiring this before we say that it is > allowed. I made one, and Bob Kukura made another. > So far I have not seen such an argument, and currebtly this is not > allowed. If necessary we should add language to the spec to > specifically say that mixing of GIOP versions on the same connection > is not allowed. I am becoming quite frustrated by the evolution of connection oriented properties without any means of negotiating same. There is no connection establishment protocol, so everything is being piggybacked on service contexts and other properties of the first request on the connection. This makes it very difficult to partition the code in any reasonable way. If you feel that we should make this sort of change, then I think we need a much more extensive revamp of the protocol. (I think I might prefer to see us begin to adopt HTTP-NG.) Here is an example of the difficulties presented currently: Suppose that a client has two threads trying, at more or less the same time, to invoke on references to the same endpoint, and that no connection has yet been established to that endpoint. Each must marshal a request, and must make some decisions about how to marshal the request before it is time to send it. The issue about giop version shows up here if the two iors specify differing giop versions. Another similar issue is code set selection. The codeset service context is supposed to be sent in the first request to go on the wire. But ideally the one to go on the wire is the one that finishes marshaling the request header first. Under current rules, I am forced to special case this to ensure that the connection is reserved for one or the other before I begin to marshal its header. Date: Fri, 16 Jul 1999 10:36:17 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Stefan Wengi Subject: Re: fragmentation broken with bi-dir giop CC: "Adrian St. John" , interop@omg.org Excerpts from direct: 16-Jul-99 Re: fragmentation broken wi.. Stefan Wengi@adnovum.com (1319*) > If you would forbid version mixing the GIOP header would carry redundant > version information in messages 2..n. > -> you'd better redefine the header (adding something like a connection > setup message) and I bet nobody wants to do that. Except for me, perhaps. The GIOP header is ridiculously redundant already. Bill Date: Fri, 16 Jul 1999 13:46:42 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Bill Janssen CC: Jonathan Biggar , "Adrian St. John" , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Bill Janssen wrote: > > Yes, I agree that it's a nasty little implementation problem. But the > connection-oriented semantics of GIOP force it on us. It's not just > the > host and port that determine `what' a connection connects to; it's the > semantics allowed on that connection, which is defined by the GIOP > version. Why? Because we've allowed semantics to be established by > tunnelling connection characteristics inside individual requests and > replies, instead of adding messages specifically designed for that > purpose. > > So instead of keeping track of connections by a 2-ple of (host, port), > keep them as a 3-ple of (host, port, giop-version). The problem is that it appears to be an n-tuple. It appears that it may also be necessary to key this by the selected transmission code sets as well. And I will probably continue to find other attributes that must constrain use of a connection. This cannot continue. Sender: jon@floorboard.com Date: Fri, 16 Jul 1999 11:00:27 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: Paul H Kyzivat CC: "Adrian St. John" , Bill Janssen , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > > Jonathan Biggar wrote: > > > > This scenario is broken, since the connection is established using > > GIOP 1.1 and the client has no information that suggests that the > > server on the other end supports GIOP 1.2. > > Why do you say that? The client has the object reference with says the > server of that object reference supports 1.2. There is no separate > handshake to negotiate the version of the connection - there is only the > request that is sent in a version compatible with what the object > reference specifies. Why should the client think that a different > connection to the same endpoint would have any different capabilities > that the connection it already has? Because the connection was first opened to invoke an operation on a IIOP 1.1 IOR. I don't see how the client can then assume that the server on the other end of the connection can now accept GIOP 1.2 messages, EVEN if the client now has a IIOP 1.2 IOR from the same host/port pair. There's no guarantee that the two IORs are actually implemented by the same server, since the receiveing side might be doing some multiplexing under the covers. > > This means that the client MUST open a new connection if it wants > > to use GIOP 1.2 for the second object reference. > > > > In this scenario I suppose the client could decide to use giop 1.1 > > > for the second invocation, for consistency. But I think I could > > > come up with another scenario where giop 1.2 was used first and the > > > giop 1.1 IOR was discovered and used later. In this case there would > > > be no choice according to current rules. > > > > In this scenario, there is no reason for the client to use GIOP 1.1, > > since it already knows that the connection supports GIOP 1.2! > > If I have an IOR that specifies 1.1, am I permitted to invoke it using > 1.2? I don't think so. > > Section 15.4.1 states "A client should not send a GIOP message having a > higher minor version number than that published by the server in the tag > Internet IIOP Profile body of an IOR." This is itself ambiguous because > it says "an IOR", not "the IOR". > > For reasons that have been stated by several others, I now believe the > use of multiple giop versions on the same connection must be permitted. > In the situation of the first scenario above, I do not want to be forced > to keep multiple connections to the same endpoint, distinguished only by > the giop version, and have to select which to use based on ior > attributes. This is a much harder problem for me than handling a > different message header format. I still think that this is a bad idea. There are probably several unintended consequenses of allowing this that will bite us. No one explicitly designed GIOP to support multiple protocol versions over the same IIOP connection. In particular, there are probably some other interactions of fragment and bidirectional GIOP with earlier GIOP versions that are problematical. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@floorboard.com Date: Fri, 16 Jul 1999 11:02:23 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: Bill Janssen CC: Paul H Kyzivat , "Adrian St. John" , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Bill Janssen wrote: > > Excerpts from direct: 16-Jul-99 Re: fragmentation broken wi.. Paul H > Kyzivat@roguewave (2049*) > > > Section 15.4.1 states "A client should not send a GIOP message having a > > higher minor version number than that published by the server in the tag > > Internet IIOP Profile body of an IOR." This is itself ambiguous because > > it says "an IOR", not "the IOR". > > > For reasons that have been stated by several others, I now believe the > > use of multiple giop versions on the same connection must be permitted. > > In the situation of the first scenario above, I do not want to be forced > > to keep multiple connections to the same endpoint, distinguished only by > > the giop version, and have to select which to use based on ior > > attributes. This is a much harder problem for me than handling a > > different message header format. > > Yes, I agree that it's a nasty little implementation problem. But the > connection-oriented semantics of GIOP force it on us. It's not just the > host and port that determine `what' a connection connects to; it's the > semantics allowed on that connection, which is defined by the GIOP > version. Why? Because we've allowed semantics to be established by > tunnelling connection characteristics inside individual requests and > replies, instead of adding messages specifically designed for that > purpose. > > So instead of keeping track of connections by a 2-ple of (host, port), > keep them as a 3-ple of (host, port, giop-version). I agree with Bill here, that it isn't particularly hard to track the version number as well as the host/port. Also, once you have established the GIOP 1.2 connection, you can close the GIOP 1.1 connection as it is redundant. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 16 Jul 1999 14:06:58 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: interop@omg.org CC: Bill Janssen , Jonathan Biggar , Stefan Wengi , Craig Ryan , Andrew Watson Subject: Re: fragmentation broken with bi-dir giop OK, we are drifting again, so I want to try a more complete straw poll. Will all voting RTF members please informally vote on each of the following possibilities? For each, vote yea/nay on whether it is acceptable to you, and rank the acceptable ones from most preferred to least preferred. 1) use of even/odd request ids. (Connection initiator must assign only even request ids, connection acceptor must assign only odd request ids.) 2) assign one of the unused bits in the giop header as a "reverse-flow" bit. This bit is only set in conjunction with use of bidirectional giop. If set, it means that the message is related to a request sent in the reverse direction on the connection. 3) add additional data to the giop 1.2 FragmentHeader. Specifically, add a field containing the MsgType of the message that this fragment continues. It would have one of the values Request, Reply, LocateRequest, LocateReply from the MsgType_1_1 enumeration. (Lets not argue about padding. Extra pad fields can be added until everyone is happy.) I *think* I am a voting member of Interop now, but am not sure. If so, my votes are as follows, in descending order of preference: 2) yes 3) yes 1) yes Sender: jon@floorboard.com Date: Fri, 16 Jul 1999 11:08:17 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: Paul H Kyzivat CC: interop@omg.org, Bill Janssen , Stefan Wengi , Craig Ryan , Andrew Watson Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > > OK, we are drifting again, so I want to try a more complete straw poll. > Will all voting RTF members please informally vote on each of the > following possibilities? For each, vote yea/nay on whether it is > acceptable to you, and rank the acceptable ones from most preferred to > least preferred. > > 1) use of even/odd request ids. > (Connection initiator must assign only even request ids, > connection acceptor must assign only odd request ids.) > > 2) assign one of the unused bits in the giop header as a > "reverse-flow" bit. This bit is only set in conjunction with > use of bidirectional giop. If set, it means that the message > is related to a request sent in the reverse direction on the > connection. > > 3) add additional data to the giop 1.2 FragmentHeader. > Specifically, add a field containing the MsgType of the > message that this fragment continues. It would have one of > the values Request, Reply, LocateRequest, LocateReply from > the MsgType_1_1 enumeration. (Lets not argue about padding. > Extra pad fields can be added until everyone is happy.) My votes in order of preference: 2 (most preferred), 1, 3. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 16 Jul 1999 14:25:43 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en To: Paul H Kyzivat CC: interop@omg.org, Bill Janssen , Jonathan Biggar , Stefan Wengi , Craig Ryan , Andrew Watson Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > > OK, we are drifting again, so I want to try a more complete straw poll. > Will all voting RTF members please informally vote on each of the > following possibilities? For each, vote yea/nay on whether it is > acceptable to you, and rank the acceptable ones from most preferred to > least preferred. > > 1) use of even/odd request ids. > (Connection initiator must assign only even request ids, > connection acceptor must assign only odd request ids.) yes - This is IONA's preference, provided that it is specified such that the constraints only apply to GIOP 1.2 (and greater) implementations that are capable of negotiating bi-directionality. This will maintain interoperability with existing uni-directional GIOP 1.2 implementations, as well as with GIOP 1.0 and 1.1 implmentations. It also has the advantage of allowing use of a simple unsigned long as the key when associating incoming fragments with the messages to which they belong. > > 2) assign one of the unused bits in the giop header as a > "reverse-flow" bit. This bit is only set in conjunction with > use of bidirectional giop. If set, it means that the message > is related to a request sent in the reverse direction on the > connection. yes - This would be acceptable, provided it also maintained compatability with existing uni-directional 1.2 implementations. But it has the disadvantage of either requiring separate tables or a more complicated key to be used when associating incoming fragments with the messages to which they belong. > > 3) add additional data to the giop 1.2 FragmentHeader. > Specifically, add a field containing the MsgType of the > message that this fragment continues. It would have one of > the values Request, Reply, LocateRequest, LocateReply from > the MsgType_1_1 enumeration. (Lets not argue about padding. > Extra pad fields can be added until everyone is happy.) no - Padding is an issue for us. To maintain the ability for a router to defragment/refragment messages, at least eight (maybe sixteen?) bytes would have to be added, which we consider unacceptably excessive. 4) I think someone suggested using distinct RequestFragment and ReplyFragment message types. no - This would not maintain compatability with existing uni-directional 1.2 implementations, and would complicate associating incoming fragments with the messages to which they belong. IONA's order of preference (in consultation with Craig) is: 1, 2, 4, 3. > > I *think* I am a voting member of Interop now, but am not sure. > If so, my votes are as follows, in descending order of preference: > > 2) yes > 3) yes > 1) yes -Bob Date: Fri, 16 Jul 1999 14:28:55 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en To: Jonathan Biggar CC: Bill Janssen , Paul H Kyzivat , "Adrian St. John" , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jonathan Biggar wrote: > > > > So instead of keeping track of connections by a 2-ple of (host, port), > > keep them as a 3-ple of (host, port, giop-version). > > I agree with Bill here, that it isn't particularly hard to track the > version number as well as the host/port. Also, once you have > established the GIOP 1.2 connection, you can close the GIOP 1.1 > connection as it is redundant. I don't think you can close the 1.1 connection if some of the IORs whose objects you want to communicate with only claim to support 1.1. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -Bob Date: Fri, 16 Jul 1999 15:01:29 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jonathan Biggar CC: "Adrian St. John" , Bill Janssen , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jonathan Biggar wrote: > > Paul H Kyzivat wrote: > > > > Jonathan Biggar wrote: > > > > > > This scenario is broken, since the connection is established using > > > GIOP 1.1 and the client has no information that suggests that the > > > server on the other end supports GIOP 1.2. > > > > Why do you say that? The client has the object reference with says > > the server of that object reference supports 1.2. There is no > > separate handshake to negotiate the version of the connection - > > there is only the request that is sent in a version compatible with > > what the object reference specifies. Why should the client think > > that a different connection to the same endpoint would have any > > different capabilities that the connection it already has? > > Because the connection was first opened to invoke an operation on a > IIOP 1.1 IOR. I don't see how the client can then assume that the > server on the other end of the connection can now accept GIOP 1.2 > messages, EVEN if the client now has a IIOP 1.2 IOR from the same > host/port pair. There's no guarantee that the two IORs are actually > implemented by the same server, since the receiveing side might be > doing some multiplexing under the covers. It is hard for me to imagine how or why that sort of multiplexing could be made to work. Do you expect that two servers, implementing different versions of giop, can service the exact same object instances? When I open a connection, before I send a message, I am already connected to something, and that something doesn't yet know what giop version I plan to use. However, if there are both 1.1 and 1.2 IORs floating around with that address, then it must be able to handle both. How has that situation changed once I send a request with a 1.1 header? > > In the situation of the first scenario above, I do not want to be > > forced to keep multiple connections to the same endpoint, > > distinguished only by the giop version, and have to select which to > > use based on ior attributes. This is a much harder problem for me > > than handling a different message header format. > > I still think that this is a bad idea. There are probably several > unintended consequenses of allowing this that will bite us. No one > explicitly designed GIOP to support multiple protocol versions over > the same IIOP connection. In particular, there are probably some > other interactions of fragment and bidirectional GIOP with earlier > GIOP versions that are problematical. Frankly, it doesn't appear that anyone explicitly designed GIOP! There are probably other consequences to be discovered either way. One has already been mentioned - existing implementations that already mix 1.0 and 1.1 on the same connection, and that might be broken if this was not permitted with 1.2. I don't know for a fact that this happens. Our orb Nouveau is certainly happy to play this game if it comes across both 1.0 and 1.1 IORs for the same destination, but won't currently cause the problem on its own because it won't create 1.0 IORs. Date: Fri, 16 Jul 1999 12:01:57 PDT Sender: Bill Janssen From: Bill Janssen To: Jishnu Mukerji , Paul H Kyzivat Subject: Re: fragmentation broken with bi-dir giop CC: Bill Janssen , Stefan Wengi , Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Excerpts from direct: 16-Jul-99 Re: fragmentation broken wi.. Paul H Kyzivat@roguewave (1831*) > I am becoming quite frustrated by the evolution of connection oriented > properties without any means of negotiating same. There is no connection > establishment protocol, so everything is being piggybacked on service > contexts and other properties of the first request on the connection. I share this frustration. > If you feel that we should make this sort of change, then I think we > need a much more extensive revamp of the protocol. (I think I might > prefer to see us begin to adopt HTTP-NG.) I'd be happy to work with you on that :-). Bill Sender: jis@fpk.hp.com Date: Fri, 16 Jul 1999 15:20:43 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Bill Janssen CC: Paul H Kyzivat , Stefan Wengi , Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Bill Janssen wrote: > > Excerpts from direct: 16-Jul-99 Re: fragmentation broken wi.. Paul H > Kyzivat@roguewave (1831*) > > > I am becoming quite frustrated by the evolution of connection oriented > > properties without any means of negotiating same. There is no connection > > establishment protocol, so everything is being piggybacked on service > > contexts and other properties of the first request on the connection. Heh, heh, wait till you see some of the submissions to some of the current RFP processes.:-) There is this ungodly problem of establishing any kind of binding, a.k.a. shared context between the two ends without a connection establishment protocol, so inventive minds are figuring out ways of piggybacking connection establishment protocols on various interesting pieces of GIOP. > I share this frustration. > > > If you feel that we should make this sort of change, then I think we > > need a much more extensive revamp of the protocol. (I think I might > > prefer to see us begin to adopt HTTP-NG.) > > I'd be happy to work with you on that :-). Hopefully, y'all don't expect this massive revamp to happen through the emergency issue resolution process.:-) Sounds like it might be time to issue an RFP if this is what you want to do. This will be way beyond the scope of any RTF I am quite sure. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Fri, 16 Jul 1999 15:30:34 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Bob Kukura CC: interop@omg.org, Bill Janssen , Jonathan Biggar , Stefan Wengi , Craig Ryan , Andrew Watson Subject: Re: fragmentation broken with bi-dir giop Bob Kukura wrote: > > > 1) use of even/odd request ids. > > (Connection initiator must assign only even request ids, > > connection acceptor must assign only odd request ids.) > > yes - This is IONA's preference, provided that it is specified such that > the constraints only apply to GIOP 1.2 (and greater) implementations > that are capable of negotiating bi-directionality. This will maintain > interoperability with existing uni-directional GIOP 1.2 > implementations, > as well as with GIOP 1.0 and 1.1 implmentations. It also has the > advantage of allowing use of a simple unsigned long as the key when > associating incoming fragments with the messages to which they belong. I am not sure if the constraints you mention can be honored. If earlier versions are used together with 1.2 on the connection, then I think both sides must use the odd/even assignments regardless of the version of the particular message being sent. Sender: jis@fpk.hp.com Date: Fri, 16 Jul 1999 15:32:18 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Bob Kukura CC: Bill Janssen , Paul H Kyzivat , Stefan Wengi , Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Bob Kukura wrote: > > Here's a potentially persuasive argument on the mixing versions issue: > > * nothing in the officially published GIOP 1.1 specification prohibits > mixing GIOP 1.0 and 1.1 messages over a connection (if anyone has > evidence to the contrary, please supply it) > > * some existing GIOP 1.1 implementations already do mix vesions 1.0 and > 1.1 over a connection > > * we can't retroactively change GIOP 1.1 > > * there's not much point in prohibiting mixing 1.2 with 1.0 and 1.1 if > 1.0 and 1.1 can already be mixed > > Several IIOP client implementations I am familiar with share connections > when the host and port are identical. Forcing this code to also take > the advertized version into account would make this code more > complicated without achieving anything. It would also waste connections > to not allow this sharing. > > In this case, I suggest we either leave it alone, or add some text > explicitly clarifying that GIOP versions can be mixed on an IIOP > connection. Given Stefan's argument, I am happy with that if that is the general feeling and the consequences of mixing 1.2 and 1.x:x<2 have been studied and are well understood and are known to be benign. Jishnu -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jon@floorboard.com Date: Fri, 16 Jul 1999 12:47:57 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: Paul H Kyzivat CC: Bob Kukura , interop@omg.org, Bill Janssen , Stefan Wengi , Craig Ryan , Andrew Watson Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > > Bob Kukura wrote: > > > > > 1) use of even/odd request ids. > > > (Connection initiator must assign only even request ids, > > > connection acceptor must assign only odd request ids.) > > > > yes - This is IONA's preference, provided that it is specified such that > > the constraints only apply to GIOP 1.2 (and greater) implementations > > that are capable of negotiating bi-directionality. This will maintain > > interoperability with existing uni-directional GIOP 1.2 > > implementations, > > as well as with GIOP 1.0 and 1.1 implmentations. It also has the > > advantage of allowing use of a simple unsigned long as the key when > > associating incoming fragments with the messages to which they belong. > > I am not sure if the constraints you mention can be honored. > If earlier versions are used together with 1.2 on the connection, > then I think both sides must use the odd/even assignments regardless > of the version of the particular message being sent. I don't think it is a problem. Look at it this way: If an implementation always uses the even/odd protocol on the client side, it is compatible with all servers on the other end. Only when bidirectional GIOP is negotiated will there be an issue, and in that case, the server must also use even/odd as well. The client side will know that it needs to use even/odd because it is the one that has chosen to advertise that it can use bidirectional connections. The only thing that the client has to do special is check for even/odd correctness on incoming GIOP messages and then only if bidirectional GIOP is in force on that connection. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jis@fpk.hp.com Date: Fri, 16 Jul 1999 16:15:25 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Paul H Kyzivat CC: Bob Kukura , interop@omg.org, Bill Janssen , Jonathan Biggar , Stefan Wengi , Craig Ryan , Andrew Watson Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > > Bob Kukura wrote: > > > > > 1) use of even/odd request ids. > > > (Connection initiator must assign only even request ids, > > > connection acceptor must assign only odd request ids.) > > > > yes - This is IONA's preference, provided that it is specified such that > > the constraints only apply to GIOP 1.2 (and greater) implementations > > that are capable of negotiating bi-directionality. This will maintain > > interoperability with existing uni-directional GIOP 1.2 > > implementations, > > as well as with GIOP 1.0 and 1.1 implmentations. It also has the > > advantage of allowing use of a simple unsigned long as the key when > > associating incoming fragments with the messages to which they belong. > > I am not sure if the constraints you mention can be honored. > If earlier versions are used together with 1.2 on the connection, > then I think both sides must use the odd/even assignments regardless > of the version of the particular message being sent. Why is that so? by the time you see a request_id, you have already looked at the GIOP header and you already know which version of GIOP this particular message is of. Isn't this together with the message type (which you know since you knew to look for a request_id) enough info to make propoer sense of the request_id? Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jis@fpk.hp.com Date: Fri, 16 Jul 1999 16:15:35 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Paul H Kyzivat CC: interop@omg.org, Bill Janssen , Jonathan Biggar , Stefan Wengi , Craig Ryan , Andrew Watson Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > > OK, we are drifting again, so I want to try a more complete straw poll. > Will all voting RTF members please informally vote on each of the > following possibilities? For each, vote yea/nay on whether it is > acceptable to you, and rank the acceptable ones from most preferred to > least preferred. > > 1) use of even/odd request ids. > (Connection initiator must assign only even request ids, > connection acceptor must assign only odd request ids.) > > 2) assign one of the unused bits in the giop header as a > "reverse-flow" bit. This bit is only set in conjunction with > use of bidirectional giop. If set, it means that the message > is related to a request sent in the reverse direction on the > connection. > > 3) add additional data to the giop 1.2 FragmentHeader. > Specifically, add a field containing the MsgType of the > message that this fragment continues. It would have one of > the values Request, Reply, LocateRequest, LocateReply from > the MsgType_1_1 enumeration. (Lets not argue about padding. > Extra pad fields can be added until everyone is happy.) > > I *think* I am a voting member of Interop now, but am not sure. > If so, my votes are as follows, in descending order of preference: > > 2) yes > 3) yes > 1) yes Either of 1 or 2, both with the caveats mentioned by Bob Kukura in his message. I would vote against 3 at the present time. Adding a field in GIOP version 1.2 at this late hour I think is a bad idea. We should refrain from changing the basic shape of GIOP 1.2 messages a this point in time. I also do not want scads of new bytes added to the header at the drop of each pin, so I will have a tendency to oppose any additional fields in headers. So my votes at present are: 1) yes 2) yes 3) no BTW, a side issue that has impact on this, I want OMG to get GIOP 1.2 to ISO ASAP in order to expedite the PAS process on GIOP there, and I don't want this issue to hold it up inordinately. It is already way past time for that. This consideration makes choice 1 or 2 above the most desirable ones, since they involve the least amount of edits. Then we can always do the grand fix to all known problems in 1.3 in the current RTF and have it come out in conjunction with CORBA components et. al. and everyone can happily live ever after, or until Paul and Bill bring up the issue of adopting HTTP-NG as GIOP 2.0 again.:-) Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Fri, 16 Jul 1999 16:34:41 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jishnu Mukerji CC: Bob Kukura , interop@omg.org, Bill Janssen , Jonathan Biggar , Stefan Wengi , Craig Ryan , Andrew Watson Subject: Re: fragmentation broken with bi-dir giop Jishnu Mukerji wrote: > > > I am not sure if the constraints you mention can be honored. > > If earlier versions are used together with 1.2 on the connection, > > then I think both sides must use the odd/even assignments regardless > > of the version of the particular message being sent. > > Why is that so? [snip] Jon Biggar wrote something similar. Perhaps I am just reading too much into Bob's constraint. I thought he might be suggesting that his orb should be able to use 1.1 assignment rules when sending 1.1 messages, and only apply 1.2 rules when sending 1.2 messages, even if both were on the same connection. As long as everyone agrees that a 1.2 capable orb should always assign request ids according to the proposed more stringent rules then I have no problem. From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: Jishnu Mukerji cc: interop@omg.org Date: Fri, 16 Jul 1999 15:43:37 -0500 Subject: Re: fragmentation broken with bi-dir giop I'm rather a purist, so I despise solutions 1 & 2 because they look like nothing more than hacks. But given Jishnu's comments about readdressing this in 1.3, I could live with either (2 preferred over 1) for 1.2. By the way, this is not a vote since I'm not IBM's interop rep and Simon Nash (who is) is in a time zone where he's probably eating a late supper right now, rather than reading these notes. But Simon would like to pass the mantle on to me, so I've got to expose myself to this group sometime. Russell Butek butek@us.ibm.com Jishnu Mukerji on 07/16/99 03:15:35 PM To: Paul H Kyzivat cc: interop@omg.org, Bill Janssen , Jonathan Biggar , Stefan Wengi , Craig Ryan , Andrew Watson (bcc: Russell Butek/Austin/IBM) Subject: Re: fragmentation broken with bi-dir giop Paul H Kyzivat wrote: > > OK, we are drifting again, so I want to try a more complete straw poll. > Will all voting RTF members please informally vote on each of the > following possibilities? For each, vote yea/nay on whether it is > acceptable to you, and rank the acceptable ones from most preferred to > least preferred. > > 1) use of even/odd request ids. > (Connection initiator must assign only even request ids, > connection acceptor must assign only odd request ids.) > > 2) assign one of the unused bits in the giop header as a > "reverse-flow" bit. This bit is only set in conjunction with > use of bidirectional giop. If set, it means that the message > is related to a request sent in the reverse direction on the > connection. > > 3) add additional data to the giop 1.2 FragmentHeader. > Specifically, add a field containing the MsgType of the > message that this fragment continues. It would have one of > the values Request, Reply, LocateRequest, LocateReply from > the MsgType_1_1 enumeration. (Lets not argue about padding. > Extra pad fields can be added until everyone is happy.) > > I *think* I am a voting member of Interop now, but am not sure. > If so, my votes are as follows, in descending order of preference: > > 2) yes > 3) yes > 1) yes Either of 1 or 2, both with the caveats mentioned by Bob Kukura in his message. I would vote against 3 at the present time. Adding a field in GIOP version 1.2 at this late hour I think is a bad idea. We should refrain from changing the basic shape of GIOP 1.2 messages a this point in time. I also do not want scads of new bytes added to the header at the drop of each pin, so I will have a tendency to oppose any additional fields in headers. So my votes at present are: 1) yes 2) yes 3) no BTW, a side issue that has impact on this, I want OMG to get GIOP 1.2 to ISO ASAP in order to expedite the PAS process on GIOP there, and I don't want this issue to hold it up inordinately. It is already way past time for that. This consideration makes choice 1 or 2 above the most desirable ones, since they involve the least amount of edits. Then we can always do the grand fix to all known problems in 1.3 in the current RTF and have it come out in conjunction with CORBA components et. al. and everyone can happily live ever after, or until Paul and Bill bring up the issue of adopting HTTP-NG as GIOP 2.0 again.:-) Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Fri, 16 Jul 1999 16:45:17 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Juergen Boldt CC: issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent This was: Re: fragmentation broken with bi-dir giop but that is getting boring and we might as well start using the issue number in the subject line. regarding the straw vote, I have received four votes so far, and proposal (2) is the clear winner to date, with three first places and a second place, while (1) is in second with two first places, a second and a third. (Jishnu didn't express a preference for 1 vs 2 so I counted them both as first place.) But we are far from quorum. Paul > 1) use of even/odd request ids. > (Connection initiator must assign only even request ids, > connection acceptor must assign only odd request ids.) > > 2) assign one of the unused bits in the giop header as a > "reverse-flow" bit. This bit is only set in conjunction with > use of bidirectional giop. If set, it means that the message > is related to a request sent in the reverse direction on the > connection. > > 3) add additional data to the giop 1.2 FragmentHeader. > Specifically, add a field containing the MsgType of the > message that this fragment continues. It would have one of > the values Request, Reply, LocateRequest, LocateReply from > the MsgType_1_1 enumeration. (Lets not argue about padding. > Extra pad fields can be added until everyone is happy.) Date: Fri, 16 Jul 1999 16:45:17 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Juergen Boldt CC: issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent This was: Re: fragmentation broken with bi-dir giop but that is getting boring and we might as well start using the issue number in the subject line. regarding the straw vote, I have received four votes so far, and proposal (2) is the clear winner to date, with three first places and a second place, while (1) is in second with two first places, a second and a third. (Jishnu didn't express a preference for 1 vs 2 so I counted them both as first place.) But we are far from quorum. Paul > 1) use of even/odd request ids. > (Connection initiator must assign only even request ids, > connection acceptor must assign only odd request ids.) > > 2) assign one of the unused bits in the giop header as a > "reverse-flow" bit. This bit is only set in conjunction with > use of bidirectional giop. If set, it means that the message > is related to a request sent in the reverse direction on the > connection. > > 3) add additional data to the giop 1.2 FragmentHeader. > Specifically, add a field containing the MsgType of the > message that this fragment continues. It would have one of > the values Request, Reply, LocateRequest, LocateReply from > the MsgType_1_1 enumeration. (Lets not argue about padding. > Extra pad fields can be added until everyone is happy.) From: Jeffrey Mischkinsky Subject: Re: fragmentation broken with bi-dir giop To: paulk@roguewave.com (Paul H Kyzivat) Date: Fri, 16 Jul 1999 14:04:23 -0700 (PDT) Cc: jis@fpk.hp.com, kukura@iona.com, interop@omg.org, janssen@parc.xerox.com, jon@floorboard.com, sgw@adnovum.com, cryan@iona.com, andrew@omg.org X-Mailer: ELM [version 2.4 PL25] 'Paul H Kyzivat' writes: > > Jishnu Mukerji wrote: > > > > > I am not sure if the constraints you mention can be honored. > > > If earlier versions are used together with 1.2 on the connection, > > > then I think both sides must use the odd/even assignments regardless > > > of the version of the particular message being sent. > > > > Why is that so? > [snip] > > Jon Biggar wrote something similar. > > Perhaps I am just reading too much into Bob's constraint. > I thought he might be suggesting that his orb should be able to use 1.1 > assignment rules when sending 1.1 messages, and only apply 1.2 rules > when sending 1.2 messages, even if both were on the same connection. > > As long as everyone agrees that a 1.2 capable orb should always assign > request ids according to the proposed more stringent rules then I have > no problem. Maybe i'm too naive, but i don't see how it could possibly make sense to interpret an n.m message as anything else but an n.m message and claim that one has a conformant implementation of n.m. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Sender: jis@fpk.hp.com Date: Fri, 16 Jul 1999 17:16:31 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Paul H Kyzivat CC: Juergen Boldt , issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent Paul H Kyzivat wrote: > > This was: Re: fragmentation broken with bi-dir giop > but that is getting boring and we might as well start using the issue > number in the subject line. > > regarding the straw vote, I have received four votes so far, and > proposal (2) is the clear winner to date, with three first places and a > second place, while (1) is in second with two first places, a second and > a third. (Jishnu didn't express a preference for 1 vs 2 so I counted > them both as first place.) I personally prefer 1 over 2, since I prefer not to muck around with bits in the GIOP header at this stage if we can avoid it. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jis@fpk.hp.com Date: Fri, 16 Jul 1999 17:16:31 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Paul H Kyzivat CC: Juergen Boldt , issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent Paul H Kyzivat wrote: > > This was: Re: fragmentation broken with bi-dir giop > but that is getting boring and we might as well start using the issue > number in the subject line. > > regarding the straw vote, I have received four votes so far, and > proposal (2) is the clear winner to date, with three first places and a > second place, while (1) is in second with two first places, a second and > a third. (Jishnu didn't express a preference for 1 vs 2 so I counted > them both as first place.) I personally prefer 1 over 2, since I prefer not to muck around with bits in the GIOP header at this stage if we can avoid it. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 16 Jul 1999 14:42:02 -0700 To: interop@omg.org From: Edward Cobb Subject: RE: issue 2801 -- Interop issue...urgent BEA's preferences on the various alternatives: 1) Yes 2) Yes 3) No Option #3 breaks all implementations today and to fix this correctly (and finally) requires non-compatible changes. >>>Date: Fri, 16 Jul 1999 16:45:17 -0400 >>From: Paul H Kyzivat >>Organization: NobleNet >>X-Mailer: Mozilla 4.0 [en] (WinNT; I) >>To: Juergen Boldt >>CC: issues@emerald.omg.org, interop@emerald.omg.org >>Subject: Re: issue 2801 -- Interop issue...urgent >> >>This was: Re: fragmentation broken with bi-dir giop >>but that is getting boring and we might as well start using the issue >>number in the subject line. >> >>regarding the straw vote, I have received four votes so far, and >>proposal (2) is the clear winner to date, with three first places and a >>second place, while (1) is in second with two first places, a second and >>a third. (Jishnu didn't express a preference for 1 vs 2 so I counted >>them both as first place.) >> >>But we are far from quorum. >> >> Paul >> >>> 1) use of even/odd request ids. >>> (Connection initiator must assign only even request ids, >>> connection acceptor must assign only odd request ids.) >>> >>> 2) assign one of the unused bits in the giop header as a >>> "reverse-flow" bit. This bit is only set in conjunction with >>> use of bidirectional giop. If set, it means that the message >>> is related to a request sent in the reverse direction on the >>> connection. >>> >>> 3) add additional data to the giop 1.2 FragmentHeader. >>> Specifically, add a field containing the MsgType of the >>> message that this fragment continues. It would have one of >>> the values Request, Reply, LocateRequest, LocateReply from >>> the MsgType_1_1 enumeration. (Lets not argue about padding. >>> Extra pad fields can be added until everyone is happy.) >> >************************************************************** >Ed Cobb, Technical Director, Systems Architecture >BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 >Tel: 408-570-8264 / Fax: 408-570-8942 >E-mail: ed.cobb@beasys.com >************************************************************** > > ************************************************************** Ed Cobb, Technical Director, Systems Architecture BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Sat, 17 Jul 1999 07:45:23 +1000 (EST) From: Michi Henning To: Stefan Wengi cc: Bill Janssen , "Adrian St. John" , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Organization: Triodia Technologies On Fri, 16 Jul 1999, Stefan Wengi wrote: > Btw. talking about versions: has anyone ever brought up the idea to add > a vendor tag and a vendor version to the GIOP header? I know that this > seems ugly from a theoretical point of view but in reality it would be > very, very helpful (workarounds for known implementation flaws/bugs). No, I'd vigorously oppose this. That way lies madness, IMO. "You are in twisty maze of IIOP features, all different..." Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Sat, 17 Jul 1999 07:48:37 +1000 (EST) From: Michi Henning To: Paul H Kyzivat cc: Jishnu Mukerji , Bill Janssen , Stefan Wengi , Jonathan Biggar , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Organization: Triodia Technologies On Fri, 16 Jul 1999, Paul H Kyzivat wrote: > I am becoming quite frustrated by the evolution of connection oriented > properties without any means of negotiating same. There is no connection > establishment protocol, so everything is being piggybacked on service > contexts and other properties of the first request on the connection. > > This makes it very difficult to partition the code in any reasonable > way. Agreed. We've been down this path before, when we considered optimizing the transmission of Anys by caching type codes. A nice idea in theory, but poor separation of concerns in IIOP makes this pretty much impossible. > If you feel that we should make this sort of change, then I think we > need a much more extensive revamp of the protocol. (I think I might > prefer to see us begin to adopt HTTP-NG.) I would strongly support such a move. It is getting increasingly difficult to evolve IIOP in any sort of sensible way. In addition, the weird CDR marshaling rules mean that we have a representation for many data types on the wire that is neither efficient nor compact. Truly the worst of both worlds. I could also see a lot of benefit in having CORBA and the web share a common protocol. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Sat, 17 Jul 1999 07:50:44 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Paul H Kyzivat , "Adrian St. John" , Bill Janssen , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Organization: Triodia Technologies On Fri, 16 Jul 1999, Jonathan Biggar wrote: > Paul H Kyzivat wrote: > > > > Why should the client think that a different > > connection to the same endpoint would have any different capabilities > > that the connection it already has? > > Because the connection was first opened to invoke an operation on a IIOP > 1.1 IOR. I don't see how the client can then assume that the server on > the other end of the connection can now accept GIOP 1.2 messages, EVEN > if the client now has a IIOP 1.2 IOR from the same host/port pair. > There's no guarantee that the two IORs are actually implemented by the > same server, since the receiveing side might be doing some multiplexing > under the covers. However, what else can the client do in that case? If the client has already opened a connection for a 1.1 invocation, and then wants to invoke on a 1.2 IOR with the same host and port, what should it do? Close the connection and then reopen it again with the same host and port? That doesn't make sense to me. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Sat, 17 Jul 1999 07:51:45 +1000 (EST) From: Michi Henning To: Paul H Kyzivat cc: interop@omg.org, Bill Janssen , Jonathan Biggar , Stefan Wengi , Craig Ryan , Andrew Watson Subject: Re: fragmentation broken with bi-dir giop Organization: Triodia Technologies On Fri, 16 Jul 1999, Paul H Kyzivat wrote: > 1) use of even/odd request ids. > (Connection initiator must assign only even request ids, > connection acceptor must assign only odd request ids.) > > 2) assign one of the unused bits in the giop header as a > "reverse-flow" bit. This bit is only set in conjunction with > use of bidirectional giop. If set, it means that the message > is related to a request sent in the reverse direction on the > connection. > > 3) add additional data to the giop 1.2 FragmentHeader. > Specifically, add a field containing the MsgType of the > message that this fragment continues. It would have one of > the values Request, Reply, LocateRequest, LocateReply from > the MsgType_1_1 enumeration. (Lets not argue about padding. > Extra pad fields can be added until everyone is happy.) My vote goes 2 - yes, preferred 1 - yes 3 - no Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Fri, 16 Jul 1999 14:54:16 PDT Sender: Bill Janssen From: Bill Janssen To: interop@omg.org, Paul H Kyzivat Subject: Re: fragmentation broken with bi-dir giop CC: Bill Janssen , Jonathan Biggar , Stefan Wengi , Craig Ryan , Andrew Watson My votes are the same as Paul's: (2) yes, (3) yes, (1) yes. Bill Date: Sat, 17 Jul 1999 00:23:55 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en To: interop@omg.org CC: butek@us.ibm.com Subject: Re: fragmentation broken with bi-dir giop I concur with Russ's "vote". Simon butek@us.ibm.com wrote: > > I'm rather a purist, so I despise solutions 1 & 2 because they look like nothing > more than hacks. But given Jishnu's comments about readdressing this in 1.3, I > could live with either (2 preferred over 1) for 1.2. > > By the way, this is not a vote since I'm not IBM's interop rep and Simon Nash > (who is) is in a time zone where he's probably eating a late supper right now, > rather than reading these notes. But Simon would like to pass the mantle on to > me, so I've got to expose myself to this group sometime. > > Russell Butek > butek@us.ibm.com > > Jishnu Mukerji on 07/16/99 03:15:35 PM > > To: Paul H Kyzivat > cc: interop@omg.org, Bill Janssen , Jonathan Biggar > , Stefan Wengi , Craig Ryan > , Andrew Watson (bcc: Russell > Butek/Austin/IBM) > Subject: Re: fragmentation broken with bi-dir giop > > Paul H Kyzivat wrote: > > > > OK, we are drifting again, so I want to try a more complete straw poll. > > Will all voting RTF members please informally vote on each of the > > following possibilities? For each, vote yea/nay on whether it is > > acceptable to you, and rank the acceptable ones from most preferred to > > least preferred. > > > > 1) use of even/odd request ids. > > (Connection initiator must assign only even request ids, > > connection acceptor must assign only odd request ids.) > > > > 2) assign one of the unused bits in the giop header as a > > "reverse-flow" bit. This bit is only set in conjunction with > > use of bidirectional giop. If set, it means that the message > > is related to a request sent in the reverse direction on the > > connection. > > > > 3) add additional data to the giop 1.2 FragmentHeader. > > Specifically, add a field containing the MsgType of the > > message that this fragment continues. It would have one of > > the values Request, Reply, LocateRequest, LocateReply from > > the MsgType_1_1 enumeration. (Lets not argue about padding. > > Extra pad fields can be added until everyone is happy.) > > > > I *think* I am a voting member of Interop now, but am not sure. > > If so, my votes are as follows, in descending order of preference: > > > > 2) yes > > 3) yes > > 1) yes > > Either of 1 or 2, both with the caveats mentioned by Bob Kukura in his > message. I would vote against 3 at the present time. Adding a field in > GIOP version 1.2 at this late hour I think is a bad idea. We should > refrain from changing the basic shape of GIOP 1.2 messages a this point > in time. I also do not want scads of new bytes added to the header at > the drop of each pin, so I will have a tendency to oppose any additional > fields in headers. So my votes at present are: > > 1) yes > 2) yes > 3) no > > BTW, a side issue that has impact on this, I want OMG to get GIOP 1.2 to > ISO ASAP in order to expedite the PAS process on GIOP there, and I don't > want this issue to hold it up inordinately. It is already way past time > for that. This consideration makes choice 1 or 2 above the most > desirable ones, since they involve the least amount of edits. Then we > can always do the grand fix to all known problems in 1.3 in the current > RTF and have it come out in conjunction with CORBA components et. al. > and everyone can happily live ever after, or until Paul and Bill bring > up the issue of adopting HTTP-NG as GIOP 2.0 again.:-) > > Jishnu. > > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Jeffrey Mischkinsky Subject: Re: fragmentation broken with bi-dir giop To: michi@triodia.com (Michi Henning) Date: Fri, 16 Jul 1999 17:27:10 -0700 (PDT) Cc: jon@floorboard.com, paulk@roguewave.com, adrian@realobjects.co.uk, janssen@parc.xerox.com, interop@omg.org X-Mailer: ELM [version 2.4 PL25] 'Michi Henning' writes: > > On Fri, 16 Jul 1999, Jonathan Biggar wrote: > > > Paul H Kyzivat wrote: > > > > > > Why should the client think that a different > > > connection to the same endpoint would have any different capabilities > > > that the connection it already has? > > > > Because the connection was first opened to invoke an operation on a IIOP > > 1.1 IOR. I don't see how the client can then assume that the server on > > the other end of the connection can now accept GIOP 1.2 messages, EVEN > > if the client now has a IIOP 1.2 IOR from the same host/port pair. > > There's no guarantee that the two IORs are actually implemented by the > > same server, since the receiveing side might be doing some multiplexing > > under the covers. > > However, what else can the client do in that case? If the client has > already opened a connection for a 1.1 invocation, and then wants to > invoke on a 1.2 IOR with the same host and port, what should it do? > Close the connection and then reopen it again with the same host and port? The 1.1 connection doesn't have to be closed. That IOR might continue to be used either by that client, or possibly by another one on the same machine. > That doesn't make sense to me. First, the "client" here is not the application, it is the client-side orb code. Second, i'm not sure opening another connection in this case is so terrible. This strikes me as a rather uncommon case, so the overhead involved in doing the "extra" open is not going to show up on anyone's radar screen. So i don't think it's worth complicating the protocol, creating yet another version to maintain, etc., just for this case. This strikes me as a contrived case jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Sender: jon@floorboard.com Date: Fri, 16 Jul 1999 18:32:31 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: Jeffrey Mischkinsky CC: Michi Henning , paulk@roguewave.com, adrian@realobjects.co.uk, janssen@parc.xerox.com, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jeffrey Mischkinsky wrote: > First, the "client" here is not the application, it is the client-side orb code. > Second, i'm not sure opening another connection in this case is so terrible. > This strikes me as a rather uncommon case, > so the overhead involved in doing the "extra" open is not > going to show up on anyone's radar screen. So i don't think it's worth > complicating the protocol, creating yet another version to maintain, etc., > just for this case. This strikes me as a contrived case Hear, hear. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 19 Jul 1999 10:02:40 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jeffrey Mischkinsky CC: Michi Henning , jon@floorboard.com, adrian@realobjects.co.uk, janssen@parc.xerox.com, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jeffrey Mischkinsky wrote: > > 'Michi Henning' writes: > > > > However, what else can the client do in that case? If the client has > > already opened a connection for a 1.1 invocation, and then wants to > > invoke on a 1.2 IOR with the same host and port, what should it do? > > Close the connection and then reopen it again with the same host and > port? > > The 1.1 connection doesn't have to be closed. That IOR might continue > to be used either by that client, or possibly by another one on the > same machine. > > > That doesn't make sense to me. > First, the "client" here is not the application, it is the client-side > orb code. Second, i'm not sure opening another connection in this > case is so terrible. This strikes me as a rather uncommon case, > so the overhead involved in doing the "extra" open is not > going to show up on anyone's radar screen. So i don't think it's worth > complicating the protocol, creating yet another version to maintain, > etc., just for this case. This strikes me as a contrived case I believe this case can be a lot more common that it first appears to be. The INS spec results in a situation where an initial IOR to a server is created by a client that might not have visibility to the giop version of the server. As a result, a client may connect using one giop version as a result of a url generated IOR, and then retrieve an object actually created by the server (e.g. a NamingContext object) that is of another giop version. I realize that some orbs expect to require use of a daemon process for url resolution so that all references via urls would result in a forward to a different ior & address. In this case there is no net increase in cost, because you pay with two connects each time you use a url. But some of us prefer to permit the url resolution to be handled by the target server itself. In this case, it is a significant burden to require a reconnect if the giop version generated by the url differs from that of the actual server. Yes, the INS spec permits the version to be explicitly specified as part of the url, but this shifts a burden to the end user that shouldn't be there. Date: Mon, 19 Jul 1999 11:38:47 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Juergen Boldt , issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent This was: Re: fragmentation broken with bi-dir giop but that is getting boring and we might as well start using the issue number in the subject line. Here is informal tally so far: (1) (2) (3) (4) odd/ reverse fragHdr rqst/reply who even flow exten. fragments ============== ==== ======= ======== ========== kyzivat y/4 y/1 y/3 y/2 biggar y/2 y/1 y/3 - kukura y/1 y/2 n n mukerji y/1 y/2 n - mischkinsky y/1 y/2 n - jansen y/3 y/1 y/2 - henning y/2 y/1 n - cobb y/1.5 y/1.5 n - nash/butek y/4 y/3 y/2 y/1 I have taken the liberty of adding the 4th approach proposed by ibm, and have updated my vote to include it. Most have not voted on it. The 3rd approach has a preponderance of no votes, and the 4th already has one no vote. So, summarizing for only (1) and (2), and counting which is most preferred for each, we get: (1) 3 most preferred (2) 5 most preferred That adds to 8 rather than 9 because Ed didn't express a preference between those two. So it looks like reverse-flow is winning at the moment. I am sure someone will correct me if I have screwed this up. Paul > > > 1) use of even/odd request ids. > > (Connection initiator must assign only even request ids, > > connection acceptor must assign only odd request ids.) > > > > 2) assign one of the unused bits in the giop header as a > > "reverse-flow" bit. This bit is only set in conjunction with > > use of bidirectional giop. If set, it means that the message > > is related to a request sent in the reverse direction on the > > connection. > > > > 3) add additional data to the giop 1.2 FragmentHeader. > > Specifically, add a field containing the MsgType of the > > message that this fragment continues. It would have one of > > the values Request, Reply, LocateRequest, LocateReply from > > the MsgType_1_1 enumeration. (Lets not argue about padding. > > Extra pad fields can be added until everyone is happy.) 4) replace Fragment with RequestFragment and ReplyFragment Date: Mon, 19 Jul 1999 11:38:47 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Juergen Boldt , issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent This was: Re: fragmentation broken with bi-dir giop but that is getting boring and we might as well start using the issue number in the subject line. Here is informal tally so far: (1) (2) (3) (4) odd/ reverse fragHdr rqst/reply who even flow exten. fragments ============== ==== ======= ======== ========== kyzivat y/4 y/1 y/3 y/2 biggar y/2 y/1 y/3 - kukura y/1 y/2 n n mukerji y/1 y/2 n - mischkinsky y/1 y/2 n - jansen y/3 y/1 y/2 - henning y/2 y/1 n - cobb y/1.5 y/1.5 n - nash/butek y/4 y/3 y/2 y/1 I have taken the liberty of adding the 4th approach proposed by ibm, and have updated my vote to include it. Most have not voted on it. The 3rd approach has a preponderance of no votes, and the 4th already has one no vote. So, summarizing for only (1) and (2), and counting which is most preferred for each, we get: (1) 3 most preferred (2) 5 most preferred That adds to 8 rather than 9 because Ed didn't express a preference between those two. So it looks like reverse-flow is winning at the moment. I am sure someone will correct me if I have screwed this up. Paul > > > 1) use of even/odd request ids. > > (Connection initiator must assign only even request ids, > > connection acceptor must assign only odd request ids.) > > > > 2) assign one of the unused bits in the giop header as a > > "reverse-flow" bit. This bit is only set in conjunction with > > use of bidirectional giop. If set, it means that the message > > is related to a request sent in the reverse direction on the > > connection. > > > > 3) add additional data to the giop 1.2 FragmentHeader. > > Specifically, add a field containing the MsgType of the > > message that this fragment continues. It would have one of > > the values Request, Reply, LocateRequest, LocateReply from > > the MsgType_1_1 enumeration. (Lets not argue about padding. > > Extra pad fields can be added until everyone is happy.) 4) replace Fragment with RequestFragment and ReplyFragment Cc: Jonathan Biggar , Paul H Kyzivat , andrew@omg.org, interop@omg.org Date: Mon, 19 Jul 1999 11:57:26 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Bill Janssen Original-CC: Jonathan Biggar , Paul H Kyzivat , andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Ok I give up on the exception idea. How about using the service context which negotiates bidirectional giop. This is a bidirectional problem, and ammending the bidirectional giop service context struct, (perhaps with with the chosen evenness of request ids the originator will use, and an ack in the return service context) might be better than hacking bits in the giop protocol itself. If interleaving is not to be used, there would be no need to negotiate this capability. Bill Janssen wrote: > > Tom, > > I dislike this proposed solution. It would require that part of the > code which is receiving requests to have knowledge of all outstanding > outgoing requests on the connection, which may be managed by a > completely different piece of code, in different threads. I'd strongly > prefer the odd/even resolution, or an equivalent design using currently > unused bits in the fragment header. > > Bill -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Cc: Craig Ryan , Paul H Kyzivat , jon@floorboard.com, kukura@eggs.dublin.iona.ie, interop@omg.org Date: Mon, 19 Jul 1999 12:11:02 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Bill Janssen Original-CC: Craig Ryan , Paul H Kyzivat , jon@floorboard.com, kukura@eggs.dublin.iona.ie, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Bill Janssen wrote: > > > While things could be defined this way, it makes little sense to me. > It's fairly clear in the current spec that GIOP is a connection-oriented > protocol. The version of GIOP being used on the connection must be a > primary characteristic of that connection. It's what allows us to > decide what to do with various connection settings, like character sets. > It allows us to decide which are allowed and/or required. > I agree with Bill, the connection has only one GIOP version. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Cc: Paul H Kyzivat , Stefan Wengi , Craig Ryan , Andrew Watson , interop@omg.org Date: Mon, 19 Jul 1999 12:17:46 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Jonathan Biggar Original-CC: Paul H Kyzivat , Stefan Wengi , Craig Ryan , Andrew Watson , interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Jonathan Biggar wrote: > > Paul H Kyzivat wrote: > > > > Stefan Wengi wrote: > > > -> > I would be happy with either. The 1.2 fragment header is different from > > 1.1 so a change is needed to support it in any case, and this is no > > harder. > > This isn't a good idea, since there isn't a spare bit in the 1.2 > fragment header. You would have to increase its size, which messes up > the current nice alignment characteristics of the 1.2 fragment header. > I agree with Jon Biggar. What about using the bidirectional service context to negotate use of even/odd by the two sides if either wants to fragment. That way if they do not fragment (as many light orbs will not) there is no change to the protocol. > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Cc: Juergen Boldt , issues@emerald.omg.org, interop@emerald.omg.org Date: Mon, 19 Jul 1999 12:30:49 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Paul H Kyzivat Original-CC: Juergen Boldt , issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent Sorry I was on vacation friday. I vote for one (even/odd) with a new service context to negotiate its use. Thus, stock 1.2 without the new service context will not allow interleaving with bidirectional giop, but the new context negotation of even/odd request ids will enable the new feature. Paul H Kyzivat wrote: > > This was: Re: fragmentation broken with bi-dir giop > but that is getting boring and we might as well start using the issue > number in the subject line. > > regarding the straw vote, I have received four votes so far, and > proposal (2) is the clear winner to date, with three first places and a > second place, while (1) is in second with two first places, a second and > a third. (Jishnu didn't express a preference for 1 vs 2 so I counted > them both as first place.) > > But we are far from quorum. > > Paul > > > 1) use of even/odd request ids. > > (Connection initiator must assign only even request ids, > > connection acceptor must assign only odd request ids.) > > > > 2) assign one of the unused bits in the giop header as a > > "reverse-flow" bit. This bit is only set in conjunction with > > use of bidirectional giop. If set, it means that the message > > is related to a request sent in the reverse direction on the > > connection. > > > > 3) add additional data to the giop 1.2 FragmentHeader. > > Specifically, add a field containing the MsgType of the > > message that this fragment continues. It would have one of > > the values Request, Reply, LocateRequest, LocateReply from > > the MsgType_1_1 enumeration. (Lets not argue about padding. > > Extra pad fields can be added until everyone is happy.) -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Cc: Juergen Boldt , issues@emerald.omg.org, interop@emerald.omg.org Date: Mon, 19 Jul 1999 12:30:49 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Paul H Kyzivat Original-CC: Juergen Boldt , issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent Sorry I was on vacation friday. I vote for one (even/odd) with a new service context to negotiate its use. Thus, stock 1.2 without the new service context will not allow interleaving with bidirectional giop, but the new context negotation of even/odd request ids will enable the new feature. Paul H Kyzivat wrote: > > This was: Re: fragmentation broken with bi-dir giop > but that is getting boring and we might as well start using the issue > number in the subject line. > > regarding the straw vote, I have received four votes so far, and > proposal (2) is the clear winner to date, with three first places and a > second place, while (1) is in second with two first places, a second and > a third. (Jishnu didn't express a preference for 1 vs 2 so I counted > them both as first place.) > > But we are far from quorum. > > Paul > > > 1) use of even/odd request ids. > > (Connection initiator must assign only even request ids, > > connection acceptor must assign only odd request ids.) > > > > 2) assign one of the unused bits in the giop header as a > > "reverse-flow" bit. This bit is only set in conjunction with > > use of bidirectional giop. If set, it means that the message > > is related to a request sent in the reverse direction on the > > connection. > > > > 3) add additional data to the giop 1.2 FragmentHeader. > > Specifically, add a field containing the MsgType of the > > message that this fragment continues. It would have one of > > the values Request, Reply, LocateRequest, LocateReply from > > the MsgType_1_1 enumeration. (Lets not argue about padding. > > Extra pad fields can be added until everyone is happy.) -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Cc: Juergen Boldt , issues@emerald.omg.org, interop@emerald.omg.org Date: Mon, 19 Jul 1999 14:30:32 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Paul H Kyzivat Original-CC: Juergen Boldt , issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent I a concerned that implementations of 1.2 that do not interleave on bidirectional GIOP, will have to change their implementation. The mandatory even/odd means what, if Bidirectional GIOP is not in use does the even/odd apply. What if bidirecational giop is in use, but the sender never wants to fragment? Paul H Kyzivat wrote: > > Tom Rutt wrote: > > > > Sorry I was on vacation friday. > > > > I vote for one (even/odd) with a new service context to negotiate > > its use. Thus, stock 1.2 without the new service context will > > not allow interleaving with bidirectional giop, but the new > > context negotation of even/odd request ids will enable the new > > feature. > > I guess I should have seen this one before replying to your earlier > message. > > I am not sure I fully understand what you are proposing. I think there > are several parts: > > - a new service context(s) that "negotiate" that negotiate the > partitioning of the request id space into even/odd parts for > the two ends of the connection. > > - continued use of the BiDirectional service context. > > - in the absence of negotiated bidirectional use of a connection, > it is presumably ok to interleave requests and replies as they > move in their intended directions. > > - it is ok to use bidir without even/odd, but with a restriction > that interleaving of fragments is forbidden in some way. > (Not clear to me what the precise restriction is.) > > - full interleaving on bidirectional connections only permitted > if even/odd also negotiated. > > If I have this right, then I am opposed to it on the basis that it adds > needless complexity, and I am not sure that it wouldn't introduce new > problems as well. > > If we want to consider this as a resolution, I would prefer to keep it > distinct from the current even/odd proposal which is considerably > simpler. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA From: Jeffrey Mischkinsky Subject: Re: issue 2801 -- Interop issue...urgent To: paulk@roguewave.com (Paul H Kyzivat) Date: Mon, 19 Jul 1999 11:31:03 -0700 (PDT) Cc: juergen@omg.org, issues@emerald.omg.org, interop@emerald.omg.org X-Mailer: ELM [version 2.4 PL25] 'Paul H Kyzivat' writes: > > This was: Re: fragmentation broken with bi-dir giop > but that is getting boring and we might as well start using the issue > number in the subject line. > > Here is informal tally so far: > > (1) (2) (3) (4) > odd/ reverse fragHdr rqst/reply > who even flow exten. fragments > ============== ==== ======= ======== ========== > kyzivat y/4 y/1 y/3 y/2 > biggar y/2 y/1 y/3 - > kukura y/1 y/2 n n > mukerji y/1 y/2 n - > mischkinsky y/1 y/2 n - > jansen y/3 y/1 y/2 - > henning y/2 y/1 n - > cobb y/1.5 y/1.5 n - > nash/butek y/4 y/3 y/2 y/1 > > I have taken the liberty of adding the 4th approach proposed by ibm, and > have updated my vote to include it. Most have not voted on it. > > The 3rd approach has a preponderance of no votes, and the 4th already > has one no vote. So, summarizing for only (1) and (2), and counting > which is most preferred for each, we get: > > (1) 3 most preferred > (2) 5 most preferred Let me give an argument here about why i believe odd/even is a more robust approach. Giop 1.2 leaves the alg for req id generation unspecified. The odd/even approach puts an additional constraint on how the id's are to be generated, but it doesn't change the msg structure which using an unused bit does. An existing giop 1.2 implementation which chose to implement odd/even is certainly compliant with the current def and also with the new proposed one. (important if this goes into 1.3, and not 1.2) An existing giop 1.2 implementation which chose not support bi-directional giop in its first release (and no, we didn't make that choice, so i'm not pushing this solution for that reason :-), could go to odd/even when they chose to support bi-directional, simply by generating req id's a slightly different way. They wouldn't introduce a backwards incompatibility. If we take the approach that this fix will go into giop 1.3, not giop 1.2, then because odd/even does not require a structural change (using an unused bit) it will create fewer incompatiblities. The only time there will be a problem is if one is using bi-directional giop AND fragmenting those bi-directional messages AND assigning the same req-ids. With the reverse flow solution, the new messages will be incompatible, and from a pragmatic perspecitive there will be more problems. jeff > > > > > 1) use of even/odd request ids. > > > (Connection initiator must assign only even request ids, > > > connection acceptor must assign only odd request ids.) > > > > > > 2) assign one of the unused bits in the giop header as a > > > "reverse-flow" bit. This bit is only set in conjunction with > > > use of bidirectional giop. If set, it means that the message > > > is related to a request sent in the reverse direction on the > > > connection. > > > > > > 3) add additional data to the giop 1.2 FragmentHeader. > > > Specifically, add a field containing the MsgType of the > > > message that this fragment continues. It would have one of > > > the values Request, Reply, LocateRequest, LocateReply from > > > the MsgType_1_1 enumeration. (Lets not argue about padding. > > > Extra pad fields can be added until everyone is happy.) > > 4) replace Fragment with RequestFragment and ReplyFragment > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Cc: Bill Janssen , Jonathan Biggar , andrew@omg.org, interop@omg.org Date: Mon, 19 Jul 1999 14:40:04 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Paul H Kyzivat Original-CC: Bill Janssen , Jonathan Biggar , andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop I could live with the even/odd as a requirement only when bi directional giop is in use. I still do not know how we could get this into 1.2 giop, since it is now published? Paul H Kyzivat wrote: > > Tom Rutt wrote: > > > > Ok I give up on the exception idea. > > > > How about using the service context which negotiates bidirectional > > giop. > > > > This is a bidirectional problem, and ammending the bidirectional > > giop service context struct, > > (perhaps with with the chosen evenness of request ids the originator > > will use, and an ack in the return service context) might be better > > than hacking bits in the giop protocol itself. > > certainly this is a bidirectional problem, so it would be helpful if the > solution could be restricted to that scope. > > But short of saying that something only needs to be done if > bidirectional has been negotiated (like using even/odd request ids), I > don't currently see much value in sending extra data in the > bidirectional context. If my orb is ever to use bidirectional, then the > code that is to be enabled must be present, and complicating the > negotiation only makes things worse. In particular, sending an ack in a > return context would certainly make things more complex than they > already are. > > > > > If interleaving is not to be used, there would be no need to > > negotiate this capability. > > Writing code that supports interleaving with 1.2 while continuing to > support the non-interleaving of 1.1 is already tricky. And at least it > can be confident that bidirectional giop can't be negotiated in 1.1. > Permitting giop 1.2 to be used, with bidirectional enabled, and without > fixing the request id ambiguity, as long as somebody promises not to use > interleaving, sounds like something that I would not want to attempt to > implement. > > If we were to choose the even/odd request id technique, it would be > acceptable to me to only require this if bidirectional is to be > negotiated. Then, an orb that has no intent to ever accept use of > bidirectional giop need not implement the even/odd stuff. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Date: Mon, 19 Jul 1999 15:26:10 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: terutt@lucent.com CC: Bill Janssen , Jonathan Biggar , andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Tom Rutt wrote: > > I could live with the even/odd as a requirement only when > bi directional giop is in use. > > I still do not know how we could get this into 1.2 giop, since it > is now published? One possibility would be to adopt an even/odd rule like this informally as a private multilateral agreement of (some subset of) giop 1.2 implementors, since it is at least compatible with giop 1.2. Then formally giop 1.2 would remain broken, but it would just happen to work ok for those that subscribe to the private agreement. In parallel, we could formally adopt some solution for giop 1.3; either the same one or a different one. (But a number of vendors would have a vested interest in choosing the same solution.) I think this is more or less what Jeff M was suggesting. While it isn't an ideal solution, it is one I could live with. Date: Tue, 20 Jul 1999 07:57:58 +1000 (EST) From: Michi Henning To: Jeffrey Mischkinsky cc: Paul H Kyzivat , juergen@omg.org, issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent Organization: Triodia Technologies On Mon, 19 Jul 1999, Jeffrey Mischkinsky wrote: > > henning y/2 y/1 n - > Let me give an argument here about why i believe odd/even is a more > robust approach. > > Giop 1.2 leaves the alg for req id generation unspecified. The odd/even > approach puts an additional constraint on how the id's are to be generated, > but it doesn't change the msg structure which using an unused bit does. > [ Lots of good reasons deleted. ] I find that's a convincing argument. If we treat this as an interim fix until we can think of something better, the odd/even approach appears to cause the least pain, so I'm flipping the above vote in preference of odd/even. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html X-Sender: andrew@emerald.omg.org Date: Tue, 20 Jul 1999 17:01:41 -0400 To: interop@omg.org From: Andrew Watson Subject: Issue 2801 classified as urgent Cc: firewall-rtf@omg.org Good Afternoon, I am classifying Issue 2801 (fragmentation broken with bi-dir giop) as urgent, in accordance with procedure described in section 4.4.1.5 of the P&P. The summary of this issue, and also the thread of discussion since it was received, can be found here: http://www.omg.org/issues/issue2801.txt The issue will be voted on by the Interoperability RTF: however, I am also informing the Firewall RTF, since bidirectional GIOP is relevant to the firewall specification. The default resolution will be to insert the following paragraph into section 15.8 of the CORBA 2.3 spec on page 15-53, just after the paragraph beginning "The server may not wish to support ...": A GIOP connection may not be used bi-directionally if the client has previously initiated a request with fragmentation on that connection, and if bi-directional GIOP is negotiated then neither the client nor the server may subsequently use fragmented requests. This default resolution will be applied to CORBA 2.3 if and only if the Interop RTF fails to generate an alternative resolution within 14 days (i.e. by Tue 3rd August). It is not necessarily the most desirable resolution. Regards, Andrew Andrew Watson Tel: +1 508 820 4300 x111 Vice President & Technical Director, Fax: +1 508 820 4303 Object Management Group, Email: andrew@omg.org 492 Old Connecticut Path, Lat/Lon: 42.3122 N 71.3927 W Framingham, MA 01701, USA http://www.omg.org/~andrew Date: Tue, 20 Jul 1999 22:02:46 +0100 From: Owen Rees To: butek@us.ibm.com, Jeffrey Mischkinsky cc: issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent Originator-Info: login-id=ore; server=ticb.hpl.hp.com X-Mailer: Mulberry (Win32) [1.4.3, s/n P005-300802-002] --On 20 July 1999, 08:07 -0500 butek@us.ibm.com wrote: > I'll go back to my purist stance and say that this is simply an ugly > solution. (And thanks, Dave Stringer; I'm glad I'm not the only one that > thinks this is an embarrassing hack.) When we move up to 1.3, we should > attempt to present a more elegant solution; one that ONLY affects > fragment messages (or fragments and bi-dir giop) since this is where the > issue is. > > I like Andrew's suggested solution. This or the modification of it - that > interleaved GIOP fragments and Bidir GIOP cannot coexist in 1.2 - would > suit us. Why not add a "BiDirFragment" message type - exactly like Fragment except that it is used for the fragments whose request id was allocated by the ORB that acceped the connection (i.e. Requests using the bidir "reverse channel" and what follows from them). This seems to me to disambiguate the request id while leaving both fragmentation without bidir and bidir without fragmentation exactly as they are now. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Date: Tue, 20 Jul 1999 19:01:47 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Owen Rees CC: butek@us.ibm.com, Jeffrey Mischkinsky , issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent Owen Rees wrote: > > Why not add a "BiDirFragment" message type - exactly like Fragment > except that it is used for the fragments whose request id was > allocated by the ORB that acceped the connection (i.e. Requests > using the bidir "reverse channel" and what follows from them). > > This seems to me to disambiguate the request id while leaving both > fragmentation without bidir and bidir without fragmentation exactly as > they are now. This is very similar to the "reverse-flow" approach. It has the appeal of not consuming one of the remaining unused flag bits. I think the reverse-flow is slightly less of a kludge, but that is debatable. If we are going to do this sort I would rather have RequestFragment and ReplyFragment (and maybe LocateRequestFragment and LocateReplyFragment). But of course that change would affect the non-bi-dir case, so it probably isn't acceptable. I would consider this bidir-fragment solution to be about equally acceptable to even/odd and reverse-flow. Sender: jis@fpk.hp.com Date: Wed, 21 Jul 1999 11:55:12 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Owen Rees CC: butek@us.ibm.com, Jeffrey Mischkinsky , issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent Owen Rees wrote: > > --On 20 July 1999, 08:07 -0500 butek@us.ibm.com wrote: > > > I'll go back to my purist stance and say that this is simply an ugly > > solution. (And thanks, Dave Stringer; I'm glad I'm not the only one that > > thinks this is an embarrassing hack.) When we move up to 1.3, we should > > attempt to present a more elegant solution; one that ONLY affects > > fragment messages (or fragments and bi-dir giop) since this is where the > > issue is. > > > > I like Andrew's suggested solution. This or the modification of it - that > > interleaved GIOP fragments and Bidir GIOP cannot coexist in 1.2 - would > > suit us. > > Why not add a "BiDirFragment" message type - exactly like Fragment except > that it is used for the fragments whose request id was allocated by the ORB > that acceped the connection (i.e. Requests using the bidir "reverse > channel" and what follows from them). > > This seems to me to disambiguate the request id while leaving both > fragmentation without bidir and bidir without fragmentation exactly as they > are now. That would not be an appropriate thing to do through the urgent interpretation process. It could be taken into consideration in the RTF later and incorproated in GIOP 1.3. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jis@fpk.hp.com Date: Wed, 21 Jul 1999 11:56:51 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Paul H Kyzivat CC: Owen Rees , butek@us.ibm.com, Jeffrey Mischkinsky , issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent Paul H Kyzivat wrote: > > Owen Rees wrote: > > > > Why not add a "BiDirFragment" message type - exactly like Fragment > > except that it is used for the fragments whose request id was > > allocated by the ORB that acceped the connection (i.e. Requests > > using the bidir "reverse channel" and what follows from them). > > > > This seems to me to disambiguate the request id while leaving both > > fragmentation without bidir and bidir without fragmentation exactly as > > they are now. > > This is very similar to the "reverse-flow" approach. > It has the appeal of not consuming one of the remaining unused flag > bits. I think the reverse-flow is slightly less of a kludge, but that is > debatable. > > If we are going to do this sort I would rather have RequestFragment and > ReplyFragment (and maybe LocateRequestFragment and LocateReplyFragment). > But of course that change would affect the non-bi-dir case, so it > probably isn't acceptable. > > I would consider this bidir-fragment solution to be about equally > acceptable to even/odd and reverse-flow. Let me point out that this would not be an appropriate thing to do through the urgetn interpretation process. This belongs to regular RTF work, not in the consideration of urgent interpretation. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: Peter Furniss To: "'issues@emerald.omg.org'" , "'interop@emerald.omg.org'" Subject: RE: issue 2801 -- Interop issue...urgent Date: Wed, 21 Jul 1999 17:01:01 +0100 It seems to me: A) For all solutions apart from even/odd and not-allowing bidir+frag+interleave at all, any existing 1.2 implementation cannot do bidirectional with a new (future) implementation, because it won't be setting the bits/using the new headers. B) Assuming even/odd, and that there are existing 1.2 implementations based on the published text: Because there is (currently) no way of negotiating out fragmentation from 1.2, an existing 1.2 implementation (that ignores the even/odd rule) but supports bidirectional might receive interleaved fragments from a "new" implementation that obeys the rule (but does not reject an incoming request that uses the wrong polarity). This will not cause trouble until and unless there is a collision in the request id's on outstanding messages. The "new" implementation could ensure interworking by avoiding interleaving fragments of messages that used the colliding request id. (This is at "minimum" in terms of when the rule is applied - an implementation could be more restrictive in various ways, and very likely would be for simplicity ) If you must mix versions, as has been said (by Paul) it would seem usual that request ids (which are definitely per-connection-unique) would have a common, version-independent generator which can obey the even/odd rule. If req id's are being chosen independently for each version (e.g. bottom n bits are version ?) then it still doesn't matter if 1.1 request ids violate the rule, precisely because 1.1 doesn't have request id on the fragments. You can even interleave 1.1 frags from one message and 1.2 frags of several messages ( you don't use request id to reassemble the only 1.1 fragmented message (this sounds like an excellent reason for not mixing versions :-) Mixing versions would give problems if you allow a 1.2 reply from a 1.1 request - not clear if that is allowed. You could expect a very high chance of trouble-free interoperation if the server deliberately chose very different ids from those received, at least when it expected it was working with a "current" 1.2 implementation. If the server receives a request id of 1 (contrary to even=initiator), it starts numbering from 382791 or somewhere (and vice versa) Given that, it would probably work 99.999% to just break connections if an incoming request encroached on the dynamically set number space. (this is only to interwork with 1.2 implementations that are completed before an even/odd or similar solution is specified, so does it matter that it's a kludge) C) On the aesthetic question of whether even/odd is a hack or if the solution should be confined to fragments: Can we be sure the problem of colliding request ids will only ever affect fragmentation It only affects them now. Choosing disjoint numbers spaces for request id's seems like a good idea in general. (suppose one day we want something that refers to outstanding requests - a more precise MessageError that gave the offending msgid, or a command to transfer some "work in progress" to another connection) ( Although I have no vote, part of my interest is in aligning the Open Distributed Processing mapping to GIOP/IIOP ( see liaison/99-03-01 - comments welcome if soon) with the up-to-date specification) Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk Cc: interop@omg.org, firewall-rtf@omg.org Date: Wed, 21 Jul 1999 15:28:08 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Andrew Watson Original-CC: interop@omg.org, firewall-rtf@omg.org Subject: Re: Issue 2801 classified as urgent I guess the Interop RTF is involved afterall. I would say we have to decide between the two most often cited as acceptable approached to solving this urgent issue: a) the one which Andrew made the default resolution " A GIOP connection may not be used bi-directionally if the client has previously initiated a request with fragmentation on that connection, and if bi-directional GIOP is negotiated then neither the client nor the server may subsequently use fragmented requests. " b) the other proposal, which I worded as follows: " To avoid collisions of request Ids in fragment messages when bidirectional giop is in use, the originator of the connection should use even request IDs, and the other side of the connecstion should uses odd request IDs. " Before we go into any voting type of discussions, I would like to concentrate on the exact wording of these two counterproposals. So if we could first focus on the proper intent of the two proposed solutions we might make better progress. I do believe the other approaches which have been discussed are not appropriate for an urgent clarification on GIOP 1.2, but might be very good solutions for GIOP 1.3, which will come sometime next year or later. Tom Rutt Interop RTF chair -------- Andrew Watson wrote: > > Good Afternoon, > > I am classifying Issue 2801 (fragmentation broken with bi-dir giop) as > urgent, in accordance with procedure described in section 4.4.1.5 of the > P&P. The summary of this issue, and also the thread of discussion since it > was received, can be found here: > > http://www.omg.org/issues/issue2801.txt > > The issue will be voted on by the Interoperability RTF: however, I am also > informing the Firewall RTF, since bidirectional GIOP is relevant to the > firewall specification. > > The default resolution will be to insert the following paragraph into > section 15.8 of the CORBA 2.3 spec on page 15-53, just after the paragraph > beginning "The server may not wish to support ...": > > A GIOP connection may not be used bi-directionally if the client has > previously initiated a request with fragmentation on that connection, and > if bi-directional GIOP is negotiated then neither the client nor the > server may subsequently use fragmented requests. > > This default resolution will be applied to CORBA 2.3 if and only if the > Interop RTF fails to generate an alternative resolution within 14 days > (i.e. by Tue 3rd August). It is not necessarily the most desirable > resolution. > > Regards, > > Andrew > Andrew Watson Tel: +1 508 820 4300 x111 > Vice President & Technical Director, Fax: +1 508 820 4303 > Object Management Group, Email: andrew@omg.org > 492 Old Connecticut Path, Lat/Lon: 42.3122 N 71.3927 W > Framingham, MA 01701, USA http://www.omg.org/~andrew -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Date: Wed, 21 Jul 1999 21:14:03 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en To: Paul H Kyzivat CC: interop@emerald.omg.org Subject: Re: issue 2801 -- Interop issue...urgent Paul, I think this is better than even/odd and reverse flow, because it limits the change to the case that is broken: reverse-flowing fragments. It is less of a hack than even/odd and it does not introduce dependencies across functional boundaries as does the reverse flow bit in the message header. It is less of a clean solution than RequestFragment and ReplyFragment, but this will not be visible to users and must be balanced against the pragmatic difficulties of changing the protocol in the non-bi-dir case. So IBM's position is that this is about the best proposal so far, if we are allowed to add a new message type to GIOP 1.2. If not, then we should go with the even/odd hack for 1.2 and revisit this for 1.3. Simon Paul H Kyzivat wrote: > > Owen Rees wrote: > > > > Why not add a "BiDirFragment" message type - exactly like Fragment > > except that it is used for the fragments whose request id was > > allocated by the ORB that acceped the connection (i.e. Requests > > using the bidir "reverse channel" and what follows from them). > > > > This seems to me to disambiguate the request id while leaving both > > fragmentation without bidir and bidir without fragmentation exactly as > > they are now. > > This is very similar to the "reverse-flow" approach. > It has the appeal of not consuming one of the remaining unused flag > bits. I think the reverse-flow is slightly less of a kludge, but that is > debatable. > > If we are going to do this sort I would rather have RequestFragment and > ReplyFragment (and maybe LocateRequestFragment and LocateReplyFragment). > But of course that change would affect the non-bi-dir case, so it > probably isn't acceptable. > > I would consider this bidir-fragment solution to be about equally > acceptable to even/odd and reverse-flow. -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Wed, 21 Jul 1999 13:30:12 PDT Sender: Bill Janssen From: Bill Janssen To: Andrew Watson , terutt@lucent.com Subject: Re: Issue 2801 classified as urgent CC: interop@omg.org, firewall-rtf@omg.org Excerpts from local.omg: 21-Jul-99 Re: Issue 2801 classified a.. Tom Rutt@lucent.com (3140*) > b) the other proposal, which I worded as follows: > " > To avoid collisions of request Ids in fragment messages > when bidirectional giop is in use, the originator of the connection > should use even request IDs, and the other > side of the connecstion should uses odd request IDs. Actually, Tom, there's been a lot of chat about this variant, but I think if you count carefully there's still more support for using one of the unused bits in the GIOP header. Bill Sender: jis@fpk.hp.com Date: Wed, 21 Jul 1999 16:42:18 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: terutt@lucent.com CC: Andrew Watson , interop@omg.org, firewall-rtf@omg.org Subject: Re: Issue 2801 classified as urgent Tom Rutt wrote: > > I guess the Interop RTF is involved afterall. > > I would say we have to decide between the two most often > cited as acceptable approached to solving this urgent issue: > > a) the one which Andrew made the default resolution > " > A GIOP connection may not be used bi-directionally if the client has > previously initiated a request with fragmentation on that connection, > and if bi-directional GIOP is negotiated then neither the client > nor the server may subsequently use fragmented requests. > " > b) the other proposal, which I worded as follows: > " > To avoid collisions of request Ids in fragment messages > when bidirectional giop is in use, the originator of the connection > should use even request IDs, and the other > side of the connecstion should uses odd request IDs. > " > > Before we go into any voting type of discussions, I would like > to concentrate on the exact wording of these two counterproposals. > > So if we could first focus on the proper intent of the two > proposed solutions we might make better progress. > It seems to me that Andrew's proposal is more restrictive than is necessary. From what I recall from a message from Jon Biggar: Jon Biggar says: > I also disagree with the proposed "default" resolution. It is only > interleaved fragmentation that causes a problem with bi-dir GIOP, since > it is the interleaving that causes the ambiguity as to which GIOP > message the fragment belongs to. I would prefer the default to be that > in GIOP 1.2, if bi-dir GIOP is enabled, then the implementation cannot > interleave GIOP fragments with other messages. It seems to me that all that is required is to not interleave other messages with fragments of a message if bi-directional GIOP is being used. Did I get that right, or am I completely confused? If I am correct then the modified resolution (a) would be: a1) "A GIOP connection may not be used bi-directionally on a connection if that connection has been used to transmit interleaved framgemented messages, and if bi-directional GIOP is negotiated for a connection then other messages may not be interleaved with fragments of a message on that connection." - or to state it more succinctly - a2) "In GIOP 1.2 if bi-directinal GIOP is used on a connection then GIOP fragments must not be interleaved with other messages". Comments? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Cc: Andrew Watson , interop@omg.org, firewall-rtf@omg.org Date: Wed, 21 Jul 1999 17:15:52 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Bill Janssen Original-CC: Andrew Watson , interop@omg.org, firewall-rtf@omg.org Subject: Re: Issue 2801 classified as urgent Bill Janssen wrote: > > Excerpts from local.omg: 21-Jul-99 Re: Issue 2801 classified a.. Tom > Rutt@lucent.com (3140*) > > > b) the other proposal, which I worded as follows: > > " > > To avoid collisions of request Ids in fragment messages > > when bidirectional giop is in use, the originator of the connection > > should use even request IDs, and the other > > side of the connecstion should uses odd request IDs. > > Actually, Tom, there's been a lot of chat about this variant, but I > think if you count carefully there's still more support for using one of > the unused bits in the GIOP header. > > Bill Unfortunately, this would require a giop version change to 1.3, which is not acceptable to me and several others. I agree, that when we do change for 1.3, the bit changes are allowed, and may be the better approach. We are constrained by the now published 1.2 giop spec. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Cc: Andrew Watson , interop@omg.org, firewall-rtf@omg.org Date: Wed, 21 Jul 1999 17:19:08 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Jishnu Mukerji Original-CC: Andrew Watson , interop@omg.org, firewall-rtf@omg.org Subject: Re: Issue 2801 classified as urgent I think your latter proposal is much better wording for the "don't do what might cause it to break" alternative a). Peter Furniss has also added a twist to b) if a new implmentation detects that the other side is not using odd/even restriction, it can move to a different portion of the requestId space to avoid collistion. Jishnu Mukerji wrote: > > Tom Rutt wrote: > > > > I guess the Interop RTF is involved afterall. > > > > I would say we have to decide between the two most often > > cited as acceptable approached to solving this urgent issue: > > > > a) the one which Andrew made the default resolution > > " > > A GIOP connection may not be used bi-directionally if the client has > > previously initiated a request with fragmentation on that connection, > > and if bi-directional GIOP is negotiated then neither the client > > nor the server may subsequently use fragmented requests. > > " > > b) the other proposal, which I worded as follows: > > " > > To avoid collisions of request Ids in fragment messages > > when bidirectional giop is in use, the originator of the connection > > should use even request IDs, and the other > > side of the connecstion should uses odd request IDs. > > " > > > > Before we go into any voting type of discussions, I would like > > to concentrate on the exact wording of these two counterproposals. > > > > So if we could first focus on the proper intent of the two > > proposed solutions we might make better progress. > > > > It seems to me that Andrew's proposal is more restrictive than is > necessary. From what I recall from a message from Jon Biggar: > > Jon Biggar says: > > I also disagree with the proposed "default" resolution. It is only > > interleaved fragmentation that causes a problem with bi-dir GIOP, since > > it is the interleaving that causes the ambiguity as to which GIOP > > message the fragment belongs to. I would prefer the default to be that > > in GIOP 1.2, if bi-dir GIOP is enabled, then the implementation cannot > > interleave GIOP fragments with other messages. > > It seems to me that all that is required is to not interleave other > messages with fragments of a message if bi-directional GIOP is being > used. Did I get that right, or am I completely confused? If I am correct > then the modified resolution (a) would be: > > a1) "A GIOP connection may not be used bi-directionally on a connection > if that connection has been used to transmit interleaved framgemented > messages, and if bi-directional GIOP is negotiated for a connection then > other messages may not be interleaved with fragments of a message on > that connection." > > - or to state it more succinctly - > > a2) "In GIOP 1.2 if bi-directinal GIOP is used on a connection then GIOP > fragments must not be interleaved with other messages". > > Comments? > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Date: Wed, 21 Jul 1999 17:21:06 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: terutt@lucent.com CC: Andrew Watson , interop@omg.org, firewall-rtf@omg.org Subject: Re: Issue 2801 classified as urgent Tom Rutt wrote: > > I guess the Interop RTF is involved afterall. > > I would say we have to decide between the two most often > cited as acceptable approached to solving this urgent issue: > > a) the one which Andrew made the default resolution > " > A GIOP connection may not be used bi-directionally if the client has > previously initiated a request with fragmentation on that connection, > and if bi-directional GIOP is negotiated then neither the client > nor the server may subsequently use fragmented requests. > " > b) the other proposal, which I worded as follows: > " > To avoid collisions of request Ids in fragment messages > when bidirectional giop is in use, the originator of the connection > should use even request IDs, and the other > side of the connecstion should uses odd request IDs. > " > > Before we go into any voting type of discussions, I would like > to concentrate on the exact wording of these two counterproposals. > > So if we could first focus on the proper intent of the two > proposed solutions we might make better progress. > > I do believe the other approaches which have been discussed > are not appropriate for an urgent clarification on GIOP 1.2, but > might be very good solutions for GIOP 1.3, which will come sometime > next year or later. I am not (yet) convinced that all the other approaches which we have been straw voting on are not appropriate for an urgent clarification on GIOP 1.2. - the reverse-flow doesn't change the message structure, and it only affects the message content of messages sent as a result of bidirectional negotiation. So it only affects the implementation of a feature that is already broken. - the recently suggested BiDirFragment message type is in essentially the same situation - it also only affects the implementation of a feature that is already broken. As far as I know, nobody has yet shipped anything claiming to be a conforming implementation of bidirectional giop. It may well be in everyones best interest to select the choice that is best for the long term. Having said that, I agree that even/odd is relatively benign because I can assign request ids that way now and in the future regardless of what else we decide to do. But if we decide on even/odd, I have no interest in hacking my code to work with an orb that doesn't use even/odd. ============== Here is a cut at revision text for the even/odd approach: In section 15.8 (Bi-Directional GIOP), replace that begins with "Bi-directional GIOP connections modify the behavior of Request IDs" with the following new paragraph: "Bi-directional GIOP connections modify the behavior of Request IDs. In the GIOP specification, "Connection Management" on page 15-44, it is noted that "Request IDs must unambiguously associate replies with requests within the scope and lifetime of a connection". With Bi-directional GIOP this guarantee must be preserved while permitting each end to generate Request IDs for new requests. To ensure this, on a connection that is used bi-directionally, clients shall assign only even valued Request IDs and servers shall assign only odd valued Request IDs. This requirement applies to the full lifetime of the connection, even before a BiDirIIOPServiceContext is transmitted." ========================== Here is a cut at revision text for the reverse-flow approach: In section 15.4.1 (GIOP Message Header), replace the paragraph starting with "The most significant 6 bits are reserved" with the following: "In GIOP 1.2, the third least significant bit indicates, when TRUE(1), that the client and server roles of the connection are reversed for this message; the endpoint that initiated the connection is the server and the endpoint that accepted the connection is the client. This bit may only be set when Bi-directional GIOP is in use. In GIOP 1.1, and when Bi-directional GIOP is not in use, this bit must have the value FALSE(0)." "The most significant 5 bits are reserved. These 5 bits must have the value 0 for GIOP version 1.1 and 1.2." Cc: Andrew Watson , interop@omg.org, firewall-rtf@omg.org Date: Wed, 21 Jul 1999 17:27:35 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Paul H Kyzivat Original-CC: Andrew Watson , interop@omg.org, firewall-rtf@omg.org Subject: Re: Issue 2801 classified as urgent While I might be convinced to accept the reverse flow approach for giop 1.3, it does change the pdu format for GIOP 1.2, and thus do not think id is appropriate for an urgent clarification fix to giop 1.2. Paul H Kyzivat wrote: > > Tom Rutt wrote: > > > > I guess the Interop RTF is involved afterall. > > > > I would say we have to decide between the two most often > > cited as acceptable approached to solving this urgent issue: > > > > a) the one which Andrew made the default resolution > > " > > A GIOP connection may not be used bi-directionally if the client has > > previously initiated a request with fragmentation on that connection, > > and if bi-directional GIOP is negotiated then neither the client > > nor the server may subsequently use fragmented requests. > > " > > b) the other proposal, which I worded as follows: > > " > > To avoid collisions of request Ids in fragment messages > > when bidirectional giop is in use, the originator of the connection > > should use even request IDs, and the other > > side of the connecstion should uses odd request IDs. > > " > > > > Before we go into any voting type of discussions, I would like > > to concentrate on the exact wording of these two counterproposals. > > > > So if we could first focus on the proper intent of the two > > proposed solutions we might make better progress. > > > > I do believe the other approaches which have been discussed > > are not appropriate for an urgent clarification on GIOP 1.2, but > > might be very good solutions for GIOP 1.3, which will come sometime > > next year or later. > > I am not (yet) convinced that all the other approaches which we have > been straw voting on are not appropriate for an urgent clarification on > GIOP 1.2. > > - the reverse-flow doesn't change the message structure, and it only > affects the message content of messages sent as a result of > bidirectional negotiation. So it only affects the implementation of a > feature that is already broken. > > - the recently suggested BiDirFragment message type is in essentially > the same situation - it also only affects the implementation of a > feature that is already broken. > > As far as I know, nobody has yet shipped anything claiming to be a > conforming implementation of bidirectional giop. It may well be in > everyones best interest to select the choice that is best for the long > term. > > Having said that, I agree that even/odd is relatively benign because I > can assign request ids that way now and in the future regardless of what > else we decide to do. > > But if we decide on even/odd, I have no interest in hacking my code to > work with an orb that doesn't use even/odd. > > ============== > > Here is a cut at revision text for the even/odd approach: > > In section 15.8 (Bi-Directional GIOP), replace that begins with > "Bi-directional GIOP connections modify the behavior of Request IDs" > with the following new paragraph: > > "Bi-directional GIOP connections modify the behavior of Request IDs. In > the GIOP specification, "Connection Management" on page 15-44, it is > noted that "Request IDs must unambiguously associate replies with > requests within the scope and lifetime of a connection". With > Bi-directional GIOP this guarantee must be preserved while permitting > each end to generate Request IDs for new requests. To ensure this, on a > connection that is used bi-directionally, clients shall assign only even > valued Request IDs and servers shall assign only odd valued Request IDs. > This requirement applies to the full lifetime of the connection, even > before a BiDirIIOPServiceContext is transmitted." > > ========================== > > Here is a cut at revision text for the reverse-flow approach: > > In section 15.4.1 (GIOP Message Header), replace the paragraph starting > with "The most significant 6 bits are reserved" with the following: > > "In GIOP 1.2, the third least significant bit indicates, when TRUE(1), > that the client and server roles of the connection are reversed for this > message; the endpoint that initiated the connection is the server and > the endpoint that accepted the connection is the client. This bit may > only be set when Bi-directional GIOP is in use. In GIOP 1.1, and when > Bi-directional GIOP is not in use, this bit must have the value > FALSE(0)." > > "The most significant 5 bits are reserved. These 5 bits must have the > value 0 for GIOP version 1.1 and 1.2." -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Date: Wed, 21 Jul 1999 18:05:41 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: terutt@lucent.com CC: Andrew Watson , interop@omg.org, firewall-rtf@omg.org Subject: Re: Issue 2801 classified as urgent Tom Rutt wrote: > > While I might be convinced to accept the reverse flow approach for > giop 1.3, it does change the > pdu format for GIOP 1.2, and thus do not think id is appropriate > for an urgent clarification fix to giop 1.2. Is that opinion appealable, or overridable via vote? reverse-flow doesn't change the pdu format - it only changes the use of one bit that is already present, and only when bidir is in use. I think your preference for even/odd is because you believe if we adopt that solution then orbs that don't follow it will still work most of the time. But requests and responses are different sorts of things. I am not inclined to keep them in the same data structure. So when a fragment comes in the first thing I want to know is whether to look it up as a request or a response. This is straightforward with reverse-flow, and with even/odd. But to make my code work with non-conforming orbs I will need to look in two places. Why should I bother. And no matter what we do, orbs that don't follow will still work with themself to the same extent. Sender: jis@fpk.hp.com Date: Wed, 21 Jul 1999 18:13:39 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: terutt@lucent.com CC: Paul H Kyzivat , Andrew Watson , interop@omg.org, firewall-rtf@omg.org Subject: Re: Issue 2801 classified as urgent I agree with Tom on this one, and I plan to vote against the Reverse Flow proposal if it comes up as an alternative for urgent clarification, for reasons stated by Tom. Jishnu. Tom Rutt wrote: > > While I might be convinced to accept the reverse flow approach for > giop 1.3, it does change the > pdu format for GIOP 1.2, and thus do not think id is appropriate > for an urgent clarification fix to giop 1.2. > > Paul H Kyzivat wrote: > > > > Tom Rutt wrote: > > > > > > I guess the Interop RTF is involved afterall. > > > > > > I would say we have to decide between the two most often > > > cited as acceptable approached to solving this urgent issue: > > > > > > a) the one which Andrew made the default resolution > > > " > > > A GIOP connection may not be used bi-directionally if the client has > > > previously initiated a request with fragmentation on that connection, > > > and if bi-directional GIOP is negotiated then neither the client > > > nor the server may subsequently use fragmented requests. > > > " > > > b) the other proposal, which I worded as follows: > > > " > > > To avoid collisions of request Ids in fragment messages > > > when bidirectional giop is in use, the originator of the connection > > > should use even request IDs, and the other > > > side of the connecstion should uses odd request IDs. > > > " > > > > > > Before we go into any voting type of discussions, I would like > > > to concentrate on the exact wording of these two counterproposals. > > > > > > So if we could first focus on the proper intent of the two > > > proposed solutions we might make better progress. > > > > > > I do believe the other approaches which have been discussed > > > are not appropriate for an urgent clarification on GIOP 1.2, but > > > might be very good solutions for GIOP 1.3, which will come sometime > > > next year or later. > > > > I am not (yet) convinced that all the other approaches which we have > > been straw voting on are not appropriate for an urgent clarification on > > GIOP 1.2. > > > > - the reverse-flow doesn't change the message structure, and it only > > affects the message content of messages sent as a result of > > bidirectional negotiation. So it only affects the implementation of a > > feature that is already broken. > > > > - the recently suggested BiDirFragment message type is in essentially > > the same situation - it also only affects the implementation of a > > feature that is already broken. > > > > As far as I know, nobody has yet shipped anything claiming to be a > > conforming implementation of bidirectional giop. It may well be in > > everyones best interest to select the choice that is best for the long > > term. > > > > Having said that, I agree that even/odd is relatively benign because I > > can assign request ids that way now and in the future regardless of what > > else we decide to do. > > > > But if we decide on even/odd, I have no interest in hacking my code to > > work with an orb that doesn't use even/odd. > > > > ============== > > > > Here is a cut at revision text for the even/odd approach: > > > > In section 15.8 (Bi-Directional GIOP), replace that begins with > > "Bi-directional GIOP connections modify the behavior of Request IDs" > > with the following new paragraph: > > > > "Bi-directional GIOP connections modify the behavior of Request IDs. In > > the GIOP specification, "Connection Management" on page 15-44, it is > > noted that "Request IDs must unambiguously associate replies with > > requests within the scope and lifetime of a connection". With > > Bi-directional GIOP this guarantee must be preserved while permitting > > each end to generate Request IDs for new requests. To ensure this, on a > > connection that is used bi-directionally, clients shall assign only even > > valued Request IDs and servers shall assign only odd valued Request IDs. > > This requirement applies to the full lifetime of the connection, even > > before a BiDirIIOPServiceContext is transmitted." > > > > ========================== > > > > Here is a cut at revision text for the reverse-flow approach: > > > > In section 15.4.1 (GIOP Message Header), replace the paragraph starting > > with "The most significant 6 bits are reserved" with the following: > > > > "In GIOP 1.2, the third least significant bit indicates, when TRUE(1), > > that the client and server roles of the connection are reversed for this > > message; the endpoint that initiated the connection is the server and > > the endpoint that accepted the connection is the client. This bit may > > only be set when Bi-directional GIOP is in use. In GIOP 1.1, and when > > Bi-directional GIOP is not in use, this bit must have the value > > FALSE(0)." > > > > "The most significant 5 bits are reserved. These 5 bits must have the > > value 0 for GIOP version 1.1 and 1.2." > > -- > > Tom Rutt email: terutt@lucent.com > Lucent Technologies Bell Labs Tel: +1(732)949-7862 > Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Wed, 21 Jul 1999 18:34:45 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: terutt@lucent.com CC: Jishnu Mukerji , Andrew Watson , interop@omg.org, firewall-rtf@omg.org Subject: Re: Issue 2801 classified as urgent Tom Rutt wrote: > > Peter Furniss has also added a twist to b) if a new implmentation > detects that the other side is not using odd/even restriction, it > can move to a different portion of the requestId space to avoid > collistion. Without some definition of "portion of the requestId space" there is no way to figure out what is a different portion. The fact that I see value N used doesn't imply that the future intent is to use N+epsilon. I am free to use any permutation generator I want, as well as to re-use any values I have previously used that are no longer in play. To play this game I would need to remember the entire history of ids that have been sent to me, and apply some algorithm to guess what might be used in the future. All these games do is reduce the probability of collision. If you insist on an algorithm that works most of the time even though only one side plays, how about the following? - pick a random number B in range [1, 2^N) - assign request ids of form B+(2^N)*i for 0 < i < 2^(32-N) - assume any received request id of above form to have been assigned by you and all others to have been assigned by the other guy. I think this sucks (I don't believe in gambling), but for big enough N (e.g. 16) it will probably work most of the time whether or not the other guy plays. From: Jeffrey Mischkinsky Subject: Re: Issue 2801 classified as urgent To: jis@fpk.hp.com (Jishnu Mukerji) Date: Wed, 21 Jul 1999 17:30:28 -0700 (PDT) Cc: terutt@lucent.com, paulk@roguewave.com, andrew@omg.org, interop@omg.org, firewall-rtf@omg.org X-Mailer: ELM [version 2.4 PL25] 'Jishnu Mukerji' writes: > > I agree with Tom on this one, and I plan to vote against the Reverse > Flow proposal if it comes up as an alternative for urgent clarification, > for reasons stated by Tom. ditto jeff > > Jishnu. > > Tom Rutt wrote: > > > > While I might be convinced to accept the reverse flow approach for > > giop 1.3, it does change the > > pdu format for GIOP 1.2, and thus do not think id is appropriate > > for an urgent clarification fix to giop 1.2. > > > > Paul H Kyzivat wrote: > > > > > > Tom Rutt wrote: > > > > > > > > I guess the Interop RTF is involved afterall. > > > > > > > > I would say we have to decide between the two most often > > > > cited as acceptable approached to solving this urgent issue: > > > > > > > > a) the one which Andrew made the default resolution > > > > " > > > > A GIOP connection may not be used bi-directionally if the client has > > > > previously initiated a request with fragmentation on that connection, > > > > and if bi-directional GIOP is negotiated then neither the client > > > > nor the server may subsequently use fragmented requests. > > > > " > > > > b) the other proposal, which I worded as follows: > > > > " > > > > To avoid collisions of request Ids in fragment messages > > > > when bidirectional giop is in use, the originator of the connection > > > > should use even request IDs, and the other > > > > side of the connecstion should uses odd request IDs. > > > > " > > > > > > > > Before we go into any voting type of discussions, I would like > > > > to concentrate on the exact wording of these two counterproposals. > > > > > > > > So if we could first focus on the proper intent of the two > > > > proposed solutions we might make better progress. > > > > > > > > I do believe the other approaches which have been discussed > > > > are not appropriate for an urgent clarification on GIOP 1.2, but > > > > might be very good solutions for GIOP 1.3, which will come sometime > > > > next year or later. > > > > > > I am not (yet) convinced that all the other approaches which we have > > > been straw voting on are not appropriate for an urgent clarification on > > > GIOP 1.2. > > > > > > - the reverse-flow doesn't change the message structure, and it only > > > affects the message content of messages sent as a result of > > > bidirectional negotiation. So it only affects the implementation of a > > > feature that is already broken. > > > > > > - the recently suggested BiDirFragment message type is in essentially > > > the same situation - it also only affects the implementation of a > > > feature that is already broken. > > > > > > As far as I know, nobody has yet shipped anything claiming to be a > > > conforming implementation of bidirectional giop. It may well be in > > > everyones best interest to select the choice that is best for the long > > > term. > > > > > > Having said that, I agree that even/odd is relatively benign because I > > > can assign request ids that way now and in the future regardless of what > > > else we decide to do. > > > > > > But if we decide on even/odd, I have no interest in hacking my code to > > > work with an orb that doesn't use even/odd. > > > > > > ============== > > > > > > Here is a cut at revision text for the even/odd approach: > > > > > > In section 15.8 (Bi-Directional GIOP), replace that begins with > > > "Bi-directional GIOP connections modify the behavior of Request IDs" > > > with the following new paragraph: > > > > > > "Bi-directional GIOP connections modify the behavior of Request IDs. In > > > the GIOP specification, "Connection Management" on page 15-44, it is > > > noted that "Request IDs must unambiguously associate replies with > > > requests within the scope and lifetime of a connection". With > > > Bi-directional GIOP this guarantee must be preserved while permitting > > > each end to generate Request IDs for new requests. To ensure this, on a > > > connection that is used bi-directionally, clients shall assign only even > > > valued Request IDs and servers shall assign only odd valued Request IDs. > > > This requirement applies to the full lifetime of the connection, even > > > before a BiDirIIOPServiceContext is transmitted." > > > > > > ========================== > > > > > > Here is a cut at revision text for the reverse-flow approach: > > > > > > In section 15.4.1 (GIOP Message Header), replace the paragraph starting > > > with "The most significant 6 bits are reserved" with the following: > > > > > > "In GIOP 1.2, the third least significant bit indicates, when TRUE(1), > > > that the client and server roles of the connection are reversed for this > > > message; the endpoint that initiated the connection is the server and > > > the endpoint that accepted the connection is the client. This bit may > > > only be set when Bi-directional GIOP is in use. In GIOP 1.1, and when > > > Bi-directional GIOP is not in use, this bit must have the value > > > FALSE(0)." > > > > > > "The most significant 5 bits are reserved. These 5 bits must have the > > > value 0 for GIOP version 1.1 and 1.2." > > > > -- > > > > Tom Rutt email: terutt@lucent.com > > Lucent Technologies Bell Labs Tel: +1(732)949-7862 > > Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 > > Holmdel NJ, 07733 USA > > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 From: Jeffrey Mischkinsky Subject: Re: issue 2801 -- Interop issue...urgent To: nash@hursley.ibm.com (Simon Nash) Date: Wed, 21 Jul 1999 17:49:19 -0700 (PDT) Cc: paulk@roguewave.com, interop@emerald.omg.org X-Mailer: ELM [version 2.4 PL25] 'Simon Nash' writes: > > Paul, > I think this is better than even/odd and reverse flow, because it limits > the change to the case that is broken: reverse-flowing fragments. It is > less of a hack than even/odd and it does not introduce dependencies across > functional boundaries as does the reverse flow bit in the message header. > > It is less of a clean solution than RequestFragment and ReplyFragment, but > this will not be visible to users and must be balanced against the pragmatic > difficulties of changing the protocol in the non-bi-dir case. > > So IBM's position is that this is about the best proposal so far, if we are > allowed to add a new message type to GIOP 1.2. If not, then we should go > with the even/odd hack for 1.2 and revisit this for 1.3. simon, I could easily be convinced of this approach, but i don't think it should be permissible to add a new messge type to an existing, approved, and published giop version. So i think we're stuck. jeff > > Simon > > Paul H Kyzivat wrote: > > > > Owen Rees wrote: > > > > > > Why not add a "BiDirFragment" message type - exactly like Fragment > > > except that it is used for the fragments whose request id was > > > allocated by the ORB that acceped the connection (i.e. Requests > > > using the bidir "reverse channel" and what follows from them). > > > > > > This seems to me to disambiguate the request id while leaving both > > > fragmentation without bidir and bidir without fragmentation exactly as > > > they are now. > > > > This is very similar to the "reverse-flow" approach. > > It has the appeal of not consuming one of the remaining unused flag > > bits. I think the reverse-flow is slightly less of a kludge, but that is > > debatable. > > > > If we are going to do this sort I would rather have RequestFragment and > > ReplyFragment (and maybe LocateRequestFragment and LocateReplyFragment). > > But of course that change would affect the non-bi-dir case, so it > > probably isn't acceptable. > > > > I would consider this bidir-fragment solution to be about equally > > acceptable to even/odd and reverse-flow. > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Date: Thu, 22 Jul 1999 12:32:34 +1000 (EST) From: Michi Henning To: Tom Rutt cc: Andrew Watson , interop@omg.org, firewall-rtf@omg.org Subject: Re: Issue 2801 classified as urgent Organization: Triodia Technologies On Wed, 21 Jul 1999, Tom Rutt wrote: > To avoid collisions of request Ids in fragment messages > when bidirectional giop is in use, the originator of the connection > should use even request IDs, and the other > side of the connecstion should uses odd request IDs. No "shoulds" please. If we take that resolution, it must say "must". Cheers, Michi. Date: Thu, 22 Jul 1999 12:53:17 +1000 (EST) From: Michi Henning To: Jeffrey Mischkinsky cc: terutt@lucent.com, andrew@omg.org, interop@omg.org, firewall-rtf@omg.org Subject: Re: Issue 2801 classified as urgent Organization: Triodia Technologies On Wed, 21 Jul 1999, Jeffrey Mischkinsky wrote: > 'Michi Henning' writes: > > > > On Wed, 21 Jul 1999, Tom Rutt wrote: > > > > > To avoid collisions of request Ids in fragment messages > > > when bidirectional giop is in use, the originator of the connection > > > should use even request IDs, and the other > > > side of the connecstion should uses odd request IDs. > > > > No "shoulds" please. If we take that resolution, it must say "must". > > you of course meant "shall" :-) Aw, alright then ;-) Actually, a neat way to avoid the issue entirely is to simply state the fact: To avoid collisions of request Ids in fragment messages when bidirectional giop is in use, the originator of the connection uses even request IDs, and the other side of the connection uses odd request IDs. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html From: Jeffrey Mischkinsky Subject: Re: Issue 2801 classified as urgent To: michi@triodia.com (Michi Henning) Date: Wed, 21 Jul 1999 19:57:16 -0700 (PDT) Cc: terutt@lucent.com, andrew@omg.org, interop@omg.org, firewall-rtf@omg.org X-Mailer: ELM [version 2.4 PL25] 'Michi Henning' writes: > > On Wed, 21 Jul 1999, Tom Rutt wrote: > > > To avoid collisions of request Ids in fragment messages > > when bidirectional giop is in use, the originator of the connection > > should use even request IDs, and the other > > side of the connecstion should uses odd request IDs. > > No "shoulds" please. If we take that resolution, it must say "must". you of course meant "shall" :-) jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 From: Jeffrey Mischkinsky Subject: Re: Issue 2801 classified as urgent To: michi@triodia.com (Michi Henning) Date: Wed, 21 Jul 1999 20:02:01 -0700 (PDT) Cc: terutt@lucent.com, andrew@omg.org, interop@omg.org, firewall-rtf@omg.org X-Mailer: ELM [version 2.4 PL25] works for me! jeff 'Michi Henning' writes: > > On Wed, 21 Jul 1999, Jeffrey Mischkinsky wrote: > > > 'Michi Henning' writes: > > > > > > On Wed, 21 Jul 1999, Tom Rutt wrote: > > > > > > > To avoid collisions of request Ids in fragment messages > > > > when bidirectional giop is in use, the originator of the connection > > > > should use even request IDs, and the other > > > > side of the connecstion should uses odd request IDs. > > > > > > No "shoulds" please. If we take that resolution, it must say "must". > > > > you of course meant "shall" :-) > > Aw, alright then ;-) > > Actually, a neat way to avoid the issue entirely is to simply state the > fact: > > To avoid collisions of request Ids in fragment messages > when bidirectional giop is in use, the originator of the connection > uses even request IDs, and the other > side of the connection uses odd request IDs. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3236 1633 > Triodia Technologies +61 4 1118 2700 (mobile) > PO Box 372 +61 7 3211 0047 (fax) > Annerley 4103 michi@triodia.com > AUSTRALIA http://www.triodia.com/staff/michi-henning.html > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 From: Peter Furniss To: "'terutt@lucent.com'" , "'Paul H Kyzivat'" Cc: "'Jishnu Mukerji'" , "'Andrew Watson'" , "'interop@omg.org'" , "'firewall-rtf@omg.org'" Subject: RE: Issue 2801 classified as urgent Date: Thu, 22 Jul 1999 10:46:14 +0100 Paul H Kyzivat sent : > Tom Rutt wrote: > > > > Peter Furniss has also added a twist to b) if a new implmentation > > detects that the other side is not using odd/even restriction, it > > can move to a different portion of the requestId space to avoid > > collistion. > > > All these games do is reduce the probability of collision. > If you insist on an algorithm that works most of the time even though > only one side plays, how about the following? > > - pick a random number B in range [1, 2^N) > - assign request ids of form B+(2^N)*i for 0 < i < 2^(32-N) > - assume any received request id of above form to have been > assigned by you and all others to have been assigned by the > other guy. Yes, that is a more complete description of what I was suggesting one could do if it was really, really worthwhile maximising interoperability with the already-completed 1.2 bidirectional implementations. > I think this sucks (I don't believe in gambling), but for big enough N > (e.g. 16) it will probably work most of the time whether or not the > other guy plays. I have no idea what the numbers are, but eventually one must start getting into the range of the residual error rate of TCP/IP. Of course a close relative of even/odd would be to use the top bit of the request id, not the bottom one, to partition the number space. If (as I infer from the comments of others) request id's have up till now invariably been less than 2^31, this would allow existing 1.2 clients to interwork for certain. (depends on that "invariably" of course, doesn't allow an existing 1.2 bidir server, and perhaps risks surprising someone whose hash algorithm misbehaves) Peter -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : p.furniss@mailbox.ulcc.ac.uk Web : http://www.furniss.co.uk Date: Thu, 22 Jul 1999 08:15:37 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Michi Henning CC: Jeffrey Mischkinsky , terutt@lucent.com, andrew@omg.org, interop@omg.org, firewall-rtf@omg.org Subject: Re: Issue 2801 classified as urgent Michi Henning wrote: > > Actually, a neat way to avoid the issue entirely is to simply state > the fact: > > To avoid collisions of request Ids in fragment messages > when bidirectional giop is in use, the originator of the > connection uses even request IDs, and the other > side of the connection uses odd request IDs. This doesn't read as normative to me. It suggests that if we (optionally) want to avoid collisions, then we do this, but someone that chooses not to avoid collisions is free to do so. *If* the urgent resolution process prevents us from making a normative change then I suppose this is about as good as we can do. But my understanding is that this process should permit us to make normative changes, and I consider it preferable to do so. It is nice that someone conformant to the prior language will sometimes continue to work, but it isn't necessary that they be technically conformant according to the new language. From: "Martin Chapman" To: "Paul H Kyzivat" , "Michi Henning" Cc: "Jeffrey Mischkinsky" , , , , Subject: RE: Issue 2801 classified as urgent Date: Thu, 22 Jul 1999 14:43:14 +0100 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal thats easy to fix. prefix Michi's stuff with "Collisions in request Ids shall be avoided. To avoid ....." > -----Original Message----- > From: Paul H Kyzivat [mailto:paulk@roguewave.com] > Sent: 22 July 1999 13:16 > To: Michi Henning > Cc: Jeffrey Mischkinsky; terutt@lucent.com; andrew@omg.org; > interop@omg.org; firewall-rtf@omg.org > Subject: Re: Issue 2801 classified as urgent > > > Michi Henning wrote: > > > > Actually, a neat way to avoid the issue entirely is to simply state > > the fact: > > > > To avoid collisions of request Ids in fragment messages > > when bidirectional giop is in use, the originator of the > > connection uses even request IDs, and the other > > side of the connection uses odd request IDs. > > This doesn't read as normative to me. It suggests that if we > (optionally) want to avoid collisions, then we do this, but someone that > chooses not to avoid collisions is free to do so. > > *If* the urgent resolution process prevents us from making a normative > change then I suppose this is about as good as we can do. But my > understanding is that this process should permit us to make normative > changes, and I consider it preferable to do so. > > It is nice that someone conformant to the prior language will sometimes > continue to work, but it isn't necessary that they be technically > conformant according to the new language. > Cc: Jeffrey Mischkinsky , andrew@omg.org, interop@omg.org, firewall-rtf@omg.org Date: Thu, 22 Jul 1999 12:33:32 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Michi Henning Original-CC: Jeffrey Mischkinsky , andrew@omg.org, interop@omg.org, firewall-rtf@omg.org Subject: Re: Alternatives a thru d for urgent issue I like this new wording by michi for alternative b). The intent is to have a way to avoid the problem as the fix. If an old implementation uses both odd and even, the acceleration rate of the other implemtation (thru the number sequence ) will be greater and will help avoid collistion. The worst case old/new interoperability with alternative b is that the orb will not be able to marshal, and will throw a marshall exception. Does not an orb have to be prepared for mistyped messages today? Michi Henning wrote: > > On Wed, 21 Jul 1999, Jeffrey Mischkinsky wrote: > > > 'Michi Henning' writes: > > > > > > On Wed, 21 Jul 1999, Tom Rutt wrote: > > > > > > > To avoid collisions of request Ids in fragment messages > > > > when bidirectional giop is in use, the originator of the connection > > > > should use even request IDs, and the other > > > > side of the connecstion should uses odd request IDs. > > > > > > No "shoulds" please. If we take that resolution, it must say "must". > > > > you of course meant "shall" :-) > > Aw, alright then ;-) > > Actually, a neat way to avoid the issue entirely is to simply state the > fact: > > To avoid collisions of request Ids in fragment messages > when bidirectional giop is in use, the originator of the connection > uses even request IDs, and the other > side of the connection uses odd request IDs. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3236 1633 > Triodia Technologies +61 4 1118 2700 (mobile) > PO Box 372 +61 7 3211 0047 (fax) > Annerley 4103 michi@triodia.com > AUSTRALIA http://www.triodia.com/staff/michi-henning.html -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA From: Jeffrey Mischkinsky Subject: Re: Issue 2801 classified as urgent To: paulk@roguewave.com (Paul H Kyzivat) Date: Thu, 22 Jul 1999 10:35:55 -0700 (PDT) Cc: michi@triodia.com, terutt@lucent.com, andrew@omg.org, interop@omg.org, firewall-rtf@omg.org X-Mailer: ELM [version 2.4 PL25] 'Paul H Kyzivat' writes: > > Michi Henning wrote: > > > > Actually, a neat way to avoid the issue entirely is to simply state > > the fact: > > > > To avoid collisions of request Ids in fragment messages > > when bidirectional giop is in use, the originator of the > > connection uses even request IDs, and the other > > side of the connection uses odd request IDs. > > This doesn't read as normative to me. It suggests that if we > (optionally) want to avoid collisions, then we do this, but someone that > chooses not to avoid collisions is free to do so. > > *If* the urgent resolution process prevents us from making a normative > change then I suppose this is about as good as we can do. But my > understanding is that this process should permit us to make normative > changes, and I consider it preferable to do so. It does not prevent us from making a normative change. In fact, the only kind of change that is meaningful is normative. If some the spec lawyers around here are going to start claimnig that the above isn't a requirement, then just change uses to "shall use". jeff > > It is nice that someone conformant to the prior language will sometimes > continue to work, but it isn't necessary that they be technically > conformant according to the new language. > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 From: Jeffrey Mischkinsky Subject: Re: Discussing Alternatives a thru d for urgent Issue To: terutt@lucent.com Date: Thu, 22 Jul 1999 10:37:52 -0700 (PDT) Cc: firewall-rtf@omg.org, interop@omg.org X-Mailer: ELM [version 2.4 PL25] 'Tom Rutt' writes: > > a) depricate broken feature > > a1) " > A GIOP connection may not be used bi-directionally on a connection if that > connection has been used to transmit interleaved framgemented messages, and if > bi-directional GIOP is negotiated for a connection then other messages may not > be interleaved with fragments of a message on that connection. > " > - or to state it more succinctly - > " > a2) " > In GIOP 1.2 if bi-directinal GIOP is used on a connection then GIOP fragments > must not be interleaved with other messages. shall > " > > > b) even/odd Request Id restriction > > Add the following sentence: > " > To avoid collisions of request Ids in fragment messages > when bi-directional giop is in use, the originator of the connection should use shall > even request IDs, and the other > side of the connection should uses odd request IDs. shall use > c) the reverse-flow bit of message header flags > > Modify the definition of the message header flags field to specify > usage of one bit to indicate the message is in reverse flow (i.e. > request fragment towards connection originator or reply fragment > from connection originator. > > d) Add new Fragment message type > > Modify the GIOP 1.2 protocol to add new message type(s) to distinguish > fragments. > > > For each of these alternative solutions, we should have discussion on > > - the exact wording of the proposed change to be published if the alternative is > accepted > - the interoperability aspects with pure implementations of the published GIOP > 1.2 protocol, from both oldClient/newServer and oldServer/newClient > perspectives. > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Date: Thu, 22 Jul 1999 13:46:34 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: interop@omg.org, firewall-rtf@omg.org Subject: Re: Discussing Alternatives a thru d for urgent Issue I provide some interoperability scenarios for alternatives a-d As a baseline, this is the scenario with the broken interleaved fragmentation. oldClient/oldServer - The oldclient originates connection and uses old GIOP 1.2 to send fragmented requests with requestid incremented by one. The oldServer sends fragmented requests with old GIOP 1.2 format, incrementing by one. Ocassionally, there will be marshalling exceptions passed to the invoking application due to the colliding fragment request Ids from one side's requests and the other side's responses. This is worst when the rates of invocation are equal on both sides. a) depricate broken feature a2) " In GIOP 1.2 if bi-directional GIOP is used on a connection then GIOP fragments must not be interleaved with other messages. " oldClient/NewServer - The oldClient originates a connection and starts using old GIOP 1.2 to send fragmented requests with requestId incrementing by one (note this places the oldClient out of conformance with the "fixed" giop 1.2 protocol). The newServer (assuming it is permissive and does not abort the connection because the oldClient is non-conformant to the "fixed" Giop 1.2), will not send interleaved fragments for requests or responses, and thus will never cause a collision. newClient/oldServer - similar interworking as with oldClient/NewServer, because one side is not sending fragmented requests the problem of collision never happens. One drawback to approach a) if interpreted as worded, would be if the new implementation aborted the connection each time the other side sent an interleaved fragment message. b) even/odd Request Id restriction Add the following sentence: " To avoid collisions of request Ids in fragment messages when bi-directional giop is in use, the originator of the connection should use even request IDs, and the other side of the connection should uses odd request IDs. " oldClient/NewServer - The oldClient originates a connection and starts using old GIOP 1.2 to send fragmented requests with requestId incrementing by one. The newServer, when sending requests to the oldClient will send fragmented request with requestId incremented by two (its request Ids will move out or range with the oldClient quickly). The likelihodd of the newServer sending requests at exactly half the rate of the oldClient (and thus subjecting the connection to the possibility of an interleaved fragment collision) is extrememly slim. newClient/oldServer - similar interworking as with oldClient/NewServer, except the client originating request ids will move twice as fast per invocation as the oldServers. c) the reverse-flow bit of message header flags Modify the definition of the message header flags field to specify usage of one bit to indicate the message is in reverse flow (i.e. request fragment towards connection originator or reply fragment from connection originator. oldClient/NewServer - The oldClient originates a connection and starts using old GIOP 1.2 to send fragmented requests with requestId incrementing by one. The newServer, will be able to process the messages sent by the oldClient, since the flow is not reverse. However the oldClient will abort the connection if the newServer tries to use the reverse-flow bit in a GIOP 1.2 message header. newClient/oldServer - The newClient originates a connection and starts using new GIOP 1.2 to send fragmented requests, but since it is not reverse-flow the header bit will not be set and the oldServer will be able to process the messages. However, when the oldServer sends a fragmented message without the reverse-flow bit set, the newClient will have to abort the connection, since the bit is not set on reverse flow. d) Add new Fragment message type Modify the GIOP 1.2 protocol to add new message type(s) to distinguish fragments. oldClient/NewServer - The oldClient originates a connection and starts using old GIOP 1.2 to send fragmented requests with requestId incrementing by one. The newServer, will be able to process the messages sent by the oldClient (assuming the request fragment message is unchanged) However the oldClient will abort the connection if the newServer tries to use the new fragment message for the response using a GIOP 1.2 message header. newClient/oldServer - The newClient originates a connection and starts using new GIOP 1.2 to send fragmented requests, and the old server will be able to process the request messages sent by the newClient However, when the oldServer does not send a new fragmented response message , the newClient will have to abort the connection, since it assumes GIOP 1.2 uses the new message type for responses. In summary, The scenarios for: a) takes away functionality but avoids collision between old and new implementations, and b) Makes the liklihood of the collision problem between old and new implementations much less possible than with the unfixed scenario c) just does not work d) just does not work -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Sender: jon@floorboard.com Date: Thu, 22 Jul 1999 11:46:41 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: terutt@lucent.com CC: interop@omg.org, firewall-rtf@omg.org Subject: Re: Discussing Alternatives a thru d for urgent Issue Tom Rutt wrote: > > I provide some interoperability scenarios for alternatives a-d This is a useful summary, and in general I agree with your analysis. > As a baseline, this is the scenario with the broken interleaved fragmentation. > > oldClient/oldServer - The oldclient originates connection and uses old GIOP 1.2 > to send fragmented requests with requestid incremented by one. The oldServer > sends fragmented requests with old GIOP 1.2 format, incrementing by one. > Ocassionally, there will be marshalling exceptions passed to the invoking > application due to the colliding fragment request Ids from one side's requests > and the other side's responses. This is worst when the rates of invocation are > equal on both sides. There are two worser :-) case scenarios: a) An occasional corrupt message may escape through the demarshalling process b) The invocation pattern of the client/server application might cause consistent provocation of this bug (typically early in the connection lifetime), thus preventing interoperation. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 23 Jul 1999 05:04:09 +1000 (EST) From: Michi Henning To: Paul H Kyzivat cc: Jeffrey Mischkinsky , terutt@lucent.com, andrew@omg.org, interop@omg.org, firewall-rtf@omg.org Subject: Re: Issue 2801 classified as urgent Organization: Triodia Technologies On Thu, 22 Jul 1999, Paul H Kyzivat wrote: > Michi Henning wrote: > > > > Actually, a neat way to avoid the issue entirely is to simply state > > the fact: > > > > To avoid collisions of request Ids in fragment messages > > when bidirectional giop is in use, the originator of the > > connection uses even request IDs, and the other > > side of the connection uses odd request IDs. > > This doesn't read as normative to me. It suggests that if we > (optionally) want to avoid collisions, then we do this, but someone that > chooses not to avoid collisions is free to do so. Sorry, but I don't see why it wouldn't be normative. The C++ standard uses the same language all over the place. Here is one example (of hundreds): --converting an rvalue of type "pointer to member function" to a dif- ferent pointer to member function type and back to its original type yields the original pointer to member value. --converting an rvalue of type "pointer to data member of X of type T1" to the type "pointer to data member of Y of type T2" (where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer to member value. Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Thu, 22 Jul 1999 15:43:07 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: terutt@lucent.com CC: interop@omg.org, firewall-rtf@omg.org Subject: Re: Discussing Alternatives a thru d for urgent Issue Tom Rutt wrote: > > In summary, > > The scenarios for: > a) takes away functionality but avoids collision between old and new > implementations, and > b) Makes the liklihood of the collision problem between old and new > implementations much less possible than with the unfixed scenario > c) just does not work > d) just does not work Exactly how many implementations of bidirectional giop do you think have been deployed, or will be deployed before this resolution is published? If this number were significantly greater than zero, then I think your scenarios would be important. However, I happen to believe the number to be approximately zero, in which case other concerns take precedence. I consider (c) and (d) to be preferable to random failures. At least it lets me know I am working with an orb that is not current, so that I can ask for a newer version of it. And I consider (a) undesireable because I have to add special functionality that is only useful if I happen to need to use bidir giop with one of these non-existent old implementations of it. Also, this fix degrades it even using bidir with another copy of itself. From: Jeffrey Mischkinsky Subject: Re: Discussing Alternatives a thru d for urgent Issue To: paulk@roguewave.com (Paul H Kyzivat) Date: Thu, 22 Jul 1999 13:55:00 -0700 (PDT) Cc: terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org X-Mailer: ELM [version 2.4 PL25] 'Paul H Kyzivat' writes: > > Tom Rutt wrote: > > > > In summary, > > > > The scenarios for: > > a) takes away functionality but avoids collision between old and new > > implementations, and > > b) Makes the liklihood of the collision problem between old and new > > implementations much less possible than with the unfixed scenario > > c) just does not work > > d) just does not work > > Exactly how many implementations of bidirectional giop do you think have > been deployed, or will be deployed before this resolution is published? we're in beta with it, but i'm sure we'd be willing to change our implementation to conform if we get a resolution soon.. jeff > > If this number were significantly greater than zero, then I think your > scenarios would be important. > > However, I happen to believe the number to be approximately zero, in > which case other concerns take precedence. > > I consider (c) and (d) to be preferable to random failures. At least it > lets me know I am working with an orb that is not current, so that I can > ask for a newer version of it. > > And I consider (a) undesireable because I have to add special > functionality that is only useful if I happen to need to use bidir giop > with one of these non-existent old implementations of it. Also, this > fix degrades it even using bidir with another copy of itself. > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 From: Jeffrey Mischkinsky Subject: Discussion of alternative a To: terutt@lucent.com Date: Thu, 22 Jul 1999 14:02:44 -0700 (PDT) Cc: firewall-rtf@omg.org, interop@omg.org X-Mailer: ELM [version 2.4 PL25] > a) depricate broken feature > > a1) " > A GIOP connection may not be used bi-directionally on a connection if that > connection has been used to transmit interleaved framgemented messages, and if > bi-directional GIOP is negotiated for a connection then other messages may not > be interleaved with fragments of a message on that connection. > " > - or to state it more succinctly - > " > a2) " > In GIOP 1.2 if bi-directinal GIOP is used on a connection then GIOP fragments > must not be interleaved with other messages. > " Hi, I have a question. If an ORB is multiplexing and/or reusing connections, is it always possible to meet these conditions. Is it possible to get into a situation where both sides of a connection independently start to do something which will violate the restriction. Let's say a fragmented message is used over a connection. At a later point it is desired to use bi-directional, the server will have to reject this and the client will have to open a new connection. How much application logic will have to be added so that the "state" of the conversation on the old connection can be re-established? Are there possible "race" conditions? C1 has a connection to S1. C2 has a (mulitplexed) connection to S1 C2 initiates a bi-dir negotiation which S1 oks. At the same time C1 starts sending a fragment message which arrives at S1 after S1 has ok'd the bi-dir. What happens then? Is this even a possibility? I think the answers may revolve around the definition of "connection", which may be sufficiently vagure that it would need a clarification. I'm getting an uncomfortable feeling that we haven't thought through all the implications, even for the case where we prohibit the combination. I know that these are vendor extensions, but we use them for performance reasons, and if it turns out that enforcing this restriction would prevent us, then i'm afraid i'd be strongly opposed to this alternative. Someone please correct me if i've missed something. thx, jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Date: Thu, 22 Jul 1999 18:17:11 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jeffrey Mischkinsky CC: terutt@lucent.com, firewall-rtf@omg.org, interop@omg.org Subject: Re: Discussion of alternative a Jeff, I am not sure I understand your concerns fully because I don't know what sort of optimizations you are using. But I have inserted some comments below where I could. Paul Jeffrey Mischkinsky wrote: > > Hi, > I have a question. If an ORB is multiplexing and/or reusing > connections, is it always possible to meet these conditions. I believe the connection that we refer to in chapter 15 must, in the case of IIOP, be a tcp/ip connection. It is the establishment of this that determines the client and server roles. Clearly it is possible for an orb to multiplex the use of a connection for more than one invocation, and for more that the invocations on a single object. Every orb does this I think. However presumably the orb must monitor and control the traffic on the connection sufficiently to honor the requirements imposed by the spec. For instance, managing the use of request ids. I don't think it would be possible to take two programs, each with its own copy of an orb, that don't cooperate in a close way, and multiplex their traffic over a single tcp/ip connection. If you could do it, it would have to be something like a giop gateway, that remapped all the messages. > > Is it possible to get into a situation where both sides of a > connection independently start to do something which will > violate the restriction. > > Let's say a fragmented message is used over a connection. At a later > point it is desired to use bi-directional, the server will have to > reject this and the client will have to open a new connection. > How much application logic will have to be added so that the > "state" of the conversation on the old connection can be > re-established? > > Are there possible "race" conditions? > C1 has a connection to S1. > C2 has a (mulitplexed) connection to S1 > C2 initiates a bi-dir negotiation which S1 oks. > At the same time C1 starts sending a fragment message which arrives > at S1 after S1 has ok'd the bi-dir. What happens then? > Is this even a possibility? I don't know what kind of relationship you have in mind between C1 and C2 regarding the degree of independence of their orbs. That is probably what will determine what problems can occur. I would expect that if there is a single tcp/ip connection to S1 that is being shared by C1 and C2, then the rules for use of the connection for bi-directional communication must apply to both C1 and C2. > > I think the answers may revolve around the definition of > "connection", which may be sufficiently vagure that it would > need a clarification. Since there is nothing in the GIOP protocol that explicitly encodes connection establishment, it seems like connection establishment must be defined by the lower layers - namely tcp/ip in the case of IIOP. Any other interpretation would not be interoperable. Of course you could layer GIOP over something other than tcp/ip in order to do more multiplexing. But this wouldn't be IIOP and so wouldn't interoperate with other orbs. > > I'm getting an uncomfortable feeling that we haven't thought through > all the implications, even for the case where we prohibit the > combination. You may be right, but I am not convinced yet, until I hear more. What you are describing sounds similar to the discussions, now dropped, about compatibility of differing giop versions on the same connection. I think that is a valid issue that needs to be addressed, but so far it seems to me to be a separate issue from the bi-dir fragmentation issue. > > I know that these are vendor extensions, but we use them for > performance reasons, and if it turns out that enforcing this > restriction would prevent us, then i'm afraid i'd be strongly > opposed to this alternative. We all do extensions. And now and then some change in the spec breaks an extension. I would like to think that we can be friendly about this up to a point - if there are two equally good ways of doing something, and one breaks an existing implementation while another does not, then we ought to pick the one that doesn't. In the end this comes down to details. I would like to hear more about your specific concerns. Date: Thu, 22 Jul 1999 15:30:42 PDT Sender: Bill Janssen From: Bill Janssen To: Jeffrey Mischkinsky , Paul H Kyzivat Subject: Re: Discussion of alternative a CC: terutt@lucent.com, firewall-rtf@omg.org, interop@omg.org Excerpts from local.omg: 22-Jul-99 Re: Discussion of alternati.. Paul H Kyzivat@roguewave (4204*) > I don't think it would be possible to take two programs, each with its > own copy of an orb, that don't cooperate in a close way, and multiplex > their traffic over a single tcp/ip connection. If you could do it, it > would have to be something like a giop gateway, that remapped all the > messages. I agree. And I think that this kind of connection is not strictly speaking a TCP/IP connection anymore. It's TCP/IP with some sort of multiplexing protocol on top of it, and then GIOP on top of that. Given that, the protocol traveling over it is not really IIOP, since it's not really GIOP on top of TCP/IP. Bill Date: Fri, 23 Jul 1999 13:04:45 +0100 From: Owen Rees To: terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Discussing Alternatives a thru d for urgent Issue Originator-Info: login-id=ore; server=ticb.hpl.hp.com X-Mailer: Mulberry (Win32) [1.4.3, s/n P005-300802-001] --On 22 July 1999, 13:46 -0400 Tom Rutt wrote: > d) Add new Fragment message type > > Modify the GIOP 1.2 protocol to add new message type(s) to distinguish > fragments. Two variants have been suggested, and they behave differently. d1) replace Fragment with RequestFragment, add ReplyFragment d2) add BiDirFragment > > oldClient/NewServer - The oldClient originates a connection and starts > using old GIOP 1.2 to send fragmented requests with requestId > incrementing by one. The newServer, will be able to process the messages > sent by the oldClient (assuming the request fragment message is > unchanged) However the oldClient will abort the connection if the > newServer tries to use the new fragment message for the response using a > GIOP 1.2 message header. The client should send MessageError when the message type is unknown. The newServer could have some fallback strategy for this case although there is not really enough information to be sure what is going on. This is the d1 case. In this case using bidir, when newServer sends a fragmented request oldClient will process it, but if the reply from oldClient is fragmented, newServer will fall into the ambiguity if there is an incoming fragmented request with the same id, otherwise it sees the fragment as out of new protocol and may abort or have an 'old client' fix that treats the fragment as a ReplyFragment. In the d2 case, fragmented requests from oldClient are accepted, fragmented replies from newServer are accepted. When using bidir, fragmented requests from newServer are unknown to oldClient which should respond MessageError to the BiDirFragment; newServer may be able to adopt a fallback strategy. If newServer sends a non-fragmented request and the response from oldClient is fragmented, the position is the same as for the d1 case. > > newClient/oldServer - The newClient originates a connection and starts > using new GIOP 1.2 to send fragmented requests, and the old server will > be able to process the request messages sent by the newClient However, > when the oldServer does not send a new fragmented response message , the > newClient will have to abort the connection, since it assumes GIOP 1.2 > uses the new message type for responses. This is the d1 case again; for d2, everything works until you go bidir. When using bidir, in the d1 case, the problem occurs when newClient sends a fragmented reply with the new ReplyFragment; oldServer should respond MessageError leaving newClient to abort or workaround. In the d2 case, a fragmented request from oldServer will use Fragment which may be ambiguous, but otherwise gives the fail/fallback option. A fragmented reply from newClient should cause oldServer to respond MessageError, leaving newClient with the fail/fallback option. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Cc: interop@omg.org, firewall-rtf@omg.org Date: Fri, 23 Jul 1999 11:58:37 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Paul H Kyzivat Original-CC: interop@omg.org, firewall-rtf@omg.org Subject: Re: Discussing Alternatives a thru d for urgent Issue I am concerned about the message sent out that the published finally adopted spec for giop 1.2 (in corba 2.3) is something we have to respect when making changes. There are public domain orbs out there (e.g., MICO) which may have implemented giop 1.2, and they will stay around and may try to interoperate with the "commercial" orbs which have not yet delivered giop 1.2. Paul H Kyzivat wrote: > > Tom Rutt wrote: > > > > In summary, > > > > The scenarios for: > > a) takes away functionality but avoids collision between old and new > > implementations, and > > b) Makes the liklihood of the collision problem between old and new > > implementations much less possible than with the unfixed scenario > > c) just does not work > > d) just does not work > > Exactly how many implementations of bidirectional giop do you think have > been deployed, or will be deployed before this resolution is published? > > If this number were significantly greater than zero, then I think your > scenarios would be important. > > However, I happen to believe the number to be approximately zero, in > which case other concerns take precedence. > > I consider (c) and (d) to be preferable to random failures. At least it > lets me know I am working with an orb that is not current, so that I can > ask for a newer version of it. > > And I consider (a) undesireable because I have to add special > functionality that is only useful if I happen to need to use bidir giop > with one of these non-existent old implementations of it. Also, this > fix degrades it even using bidir with another copy of itself. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Cc: firewall-rtf@omg.org, interop@omg.org Date: Fri, 23 Jul 1999 12:02:02 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Jeffrey Mischkinsky Original-CC: firewall-rtf@omg.org, interop@omg.org Subject: Re: Discussion of alternative a Jeffrey Mischkinsky wrote: > > > a) depricate broken feature > > > > a1) " > > A GIOP connection may not be used bi-directionally on a connection if that > > connection has been used to transmit interleaved framgemented messages, and if > > bi-directional GIOP is negotiated for a connection then other messages may not > > be interleaved with fragments of a message on that connection. > > " > > - or to state it more succinctly - I think the problem is with a1) wording, the a2) wording does not cause the restrictions you are alluding to. > > " > > a2) " > > In GIOP 1.2 if bi-directinal GIOP is used on a connection then GIOP fragments > > must not be interleaved with other messages. > > " > > Hi, > I have a question. If an ORB is multiplexing and/or reusing connections, > is it always possible to meet these conditions. > > Is it possible to get into a situation where both sides of a connection > independently start to do something which will violate the restriction. > > Let's say a fragmented message is used over a connection. At a later > point it is desired to use bi-directional, the server will have to reject > this and the client will have to open a new connection. How much application > logic will have to be added so that the "state" of the conversation on the > old connection can be re-established? > > Are there possible "race" conditions? > C1 has a connection to S1. > C2 has a (mulitplexed) connection to S1 > C2 initiates a bi-dir negotiation which S1 oks. > At the same time C1 starts sending a fragment message which arrives at > S1 after S1 has ok'd the bi-dir. What happens then? > Is this even a possibility? > > I think the answers may revolve around the definition of "connection", > which may be sufficiently vagure that it would need a clarification. > > I'm getting an uncomfortable feeling that we haven't thought through all > the implications, even for the case where we prohibit the combination. > > I know that these are vendor extensions, but we use them for performance > reasons, and if it turns out that enforcing this restriction would > prevent us, then i'm afraid i'd be strongly opposed to this alternative. > > Someone please correct me if i've missed something. > > thx, > jeff > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeffm@inprise.com +1 650-358-3049 -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Sender: jis@fpk.hp.com Date: Fri, 23 Jul 1999 13:34:54 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: Paul H Kyzivat CC: terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Discussing Alternatives a thru d for urgent Issue Paul H Kyzivat wrote: > > Tom Rutt wrote: > > > > I am concerned about the message sent out that the > > published finally adopted spec for giop 1.2 (in corba 2.3) > > is something we have to respect when making changes. > > > > There are public domain orbs out there (e.g., MICO) which may > > have implemented giop 1.2, and they will stay around and may > > try to interoperate with the "commercial" orbs which have not > > yet delivered giop 1.2. > > There are two cases to consider here: > > - orbs that may have implemented giop 1.2, but *without* bidir support. > This is a valid thing to do, and I can understand being concerned not to > break such an orb. The only fixes that has been discussed that would > break orbs of this sort are the RequestFragment/ReplyFragment and the > addition of data to the fragment header. I believe everyone has agreed > that these solutions are unacceptable. > > - orbs that claim to have implemented giop 1.2 *with* bidir support. I > claim that any orb that attempted to implement bidir would discover this > problem before they were done with the implementation. If they shipped > anyway, ignoring the problem, or if they made a proprietary work-around > without raising the issue publicly, then we need not have sympathy for > them. Paul, I think that is a good point that you make. However, I think you are being more harsh on the ORB 'with' bi-dir support implementers than they deserve. Since nowhere in the spec does it say that interleaved fragments must be supported, an implementation that did not do any interleaving would be perfectly compliant with the GIOP 1.2 spec as it stands. And some that did not try to do interleaving of fragments would not have run into this problem. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Fri, 23 Jul 1999 17:22:55 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Jishnu Mukerji CC: terutt@lucent.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: Discussing Alternatives a thru d for urgent Issue Jishnu Mukerji wrote: > > Paul, > > I think that is a good point that you make. However, I think you are > being more harsh on the ORB 'with' bi-dir support implementers than > they > deserve. Since nowhere in the spec does it say that interleaved > fragments must be supported, an implementation that did not do any > interleaving would be perfectly compliant with the GIOP 1.2 spec as it > stands. And some that did not try to do interleaving of fragments > would not have run into this problem. I disagree. Nowhere in the spec does it say that an orb must *send* interleaved fragments. However that orb also has no way of preventing the orb at the other end from sending them, so it must at least be prepared to *receive* interleaved fragments. And it is on the receiving side where the ambiguity becomes apparent. All you have to do is *think* about how to handle this to realize there is a problem. So I don't feel I am being too harsh. Date: Mon, 19 Jul 1999 13:01:25 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: terutt@lucent.com CC: Bill Janssen , Jonathan Biggar , andrew@omg.org, interop@omg.org Subject: Re: fragmentation broken with bi-dir giop Tom Rutt wrote: > > Ok I give up on the exception idea. > > How about using the service context which negotiates bidirectional > giop. > > This is a bidirectional problem, and ammending the bidirectional > giop service context struct, > (perhaps with with the chosen evenness of request ids the originator > will use, and an ack in the return service context) might be better > than hacking bits in the giop protocol itself. certainly this is a bidirectional problem, so it would be helpful if the solution could be restricted to that scope. But short of saying that something only needs to be done if bidirectional has been negotiated (like using even/odd request ids), I don't currently see much value in sending extra data in the bidirectional context. If my orb is ever to use bidirectional, then the code that is to be enabled must be present, and complicating the negotiation only makes things worse. In particular, sending an ack in a return context would certainly make things more complex than they already are. > > If interleaving is not to be used, there would be no need to > negotiate this capability. Writing code that supports interleaving with 1.2 while continuing to support the non-interleaving of 1.1 is already tricky. And at least it can be confident that bidirectional giop can't be negotiated in 1.1. Permitting giop 1.2 to be used, with bidirectional enabled, and without fixing the request id ambiguity, as long as somebody promises not to use interleaving, sounds like something that I would not want to attempt to implement. If we were to choose the even/odd request id technique, it would be acceptable to me to only require this if bidirectional is to be negotiated. Then, an orb that has no intent to ever accept use of bidirectional giop need not implement the even/odd stuff. From: Peter Furniss To: "'Paul H Kyzivat'" , "'Jishnu Mukerji'" Cc: "'terutt@lucent.com'" , "'interop@omg.org'" , "'firewall-rtf@omg.org'" Subject: RE: Discussing Alternatives a thru d for urgent Issue Date: Fri, 23 Jul 1999 22:55:32 +0100 Jishnu Mukerji sent : > Paul, > > I think that is a good point that you make. However, I think you are > being more harsh on the ORB 'with' bi-dir support implementers than they > deserve. Since nowhere in the spec does it say that interleaved > fragments must be supported, an implementation that did not do any > interleaving would be perfectly compliant with the GIOP 1.2 spec as it > stands. And some that did not try to do interleaving of fragments would > not have run into this problem. A non-interleaving ORB would be compliant in its sending, certainly. Should it be considered compliant in its receiving if it can't handle incoming interleaved fragments with different ids ? It wouldn't have found the problem in testing against itself, but that's the same as any other sender's option feature. Without a means of negotiating it out, a compliant implementation ought to be able to handle anything the other side could send at it. If bidir interworking with this possibly empty set of existing 1.2 implementations is important, would it be worth considering making the server choose ids in the rant 2^31 .. 2^32-1, leaving the clients where they (presumably) are now, in the bottom half of the number space. That ensures old client/new server interworking, and immediately detects (and can fail) new client/old server. (subject to some assumptions) (of course, if the "old" implementation is open source you can fix it yourself !) Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk Date: Fri, 23 Jul 1999 18:28:59 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Peter Furniss CC: "'Jishnu Mukerji'" , "'terutt@lucent.com'" , "'interop@omg.org'" , "'firewall-rtf@omg.org'" Subject: Re: Discussing Alternatives a thru d for urgent Issue Peter Furniss wrote: > > If bidir interworking with this possibly empty set of existing 1.2 > implementations is important, would it be worth considering making the > server choose ids in the rant 2^31 .. 2^32-1, leaving the clients > where they (presumably) are now, in the bottom half of the number > space. That ensures old client/new server interworking, and > immediately detects (and can fail) new client/old server. (subject > to some assumptions) This won't solve the problem. The "server" is defined as the end that accepted the connection. If an implementation following this rule is the client in a connection with an old server that doesn't follow the rule, then they may both end up using small positive numbers. An alteration might do what you have in mind: - Assume that "old" 1.2 implementations probably use small positive numbers. - Require "new improved" 1.2 clients to use even numbers with the 2^31 bit set, and new improved 1.2 servers to use odd numbers with the 2^31 bit set. This would keep new clients and servers in disjoint spaces, and would keep them out of the way of old clients and servers that use numbers without the 2^31 bit set. But I still think it is dumb to put effort into being compatible with the null set. Date: Tue, 27 Jul 1999 18:13:15 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: terutt@lucent.com CC: interop@omg.org, firewall-rtf@omg.org Subject: Re: Discussing Alternatives a thru d for urgent Issue Tom Rutt wrote: > > To focus discussions, I propose we label four alternative solutions, > a thru d, as follows Tom - We have discussed these ad nauseum, and we now have one more week before the due date. What is the next step? I am not sure that we have exact, precise, wording for all of the alternatives yet, but probably enough for everyone to know what we are talking about. Seems like we could take another straw vote, then do a precise proposal for the winner and formally vote it. (That seems like less trouble to me that precisely writing up all four.) Or what do you suggest. I would rather not end up with Andrew's default resolution. Cc: interop@omg.org, firewall-rtf@omg.org Date: Wed, 28 Jul 1999 19:14:51 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Paul H Kyzivat Original-CC: interop@omg.org, firewall-rtf@omg.org Subject: Re: Discussing Alternatives a thru d for urgent Issue Thanks Paul, I am working on a vote to send out tonight. I would like to have a conference call Monday August 2, 9:00 AM California time, 12:00 noon east coast us time for one hour to discuss the vote results. Voting members, please let me know asap whether you can call in on monday. The voting list is attached Paul H Kyzivat wrote: > > Tom Rutt wrote: > > > > To focus discussions, I propose we label four alternative solutions, > > a thru d, as follows > > Tom - We have discussed these ad nauseum, and we now have one more week > before the due date. > > What is the next step? I am not sure that we have exact, precise, > wording for all of the alternatives yet, but probably enough for > everyone to know what we are talking about. > > Seems like we could take another straw vote, then do a precise proposal > for the winner and formally vote it. (That seems like less trouble to me > that precisely writing up all four.) > > Or what do you suggest. I would rather not end up with Andrew's default > resolution. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Calendar of Events Download Specifications Become a Member Press Room OMG Publications International Offices Contact Us The OMG OMG Home About the OMG Member Companies Liaison Relationships OMG News & Info How We're Organized Staff Contacts & Partners Success Stories CORBA CORBA for Beginners CORBAnet CORBA 3 Release Info CORBA Academy Training Free Stuff The OMA IDL Text Files CORBA/IIOP Domain Interfaces CORBA Services CORBA Telecoms CORBA Finance CORBA Med MOF Documents UML Technology Process Form for Reporting Issues OMG Revision Issues Technical Commitee Groups Technology Process FAQ RFI FAQ TC Home Pages TC Work in Progress TC Deadlines TC Vote Status Technical Library Library Index Document Search About OMG Documentation Presentation Library Listen to the Experts Whitepapers Meeting Information Meeting Index Letter to Member Reps. Meeting Registration Upcoming Meetings Meeting Agendas Hotel Information TC Minutes Member Services Member Services Index Document Search Ask the Experts Mailing Lists Board of Directors Info BOD List BOD Meetings Speaker Request Form Marketing Support Membership Benefits Become a Member! Analyst Member Programs Related Information Reading Room Points of Interest User Groups OMG Company Store Publication Services OMG Geek Boutique Legal Information Legal Disclaimer Guidelines for Using OMG Trademarks OMG TC Work in Progress Last updated: Wednesday, 28-Jul-99 16:19:06 Interop RTF Status: No deadlines have passed. Schedule EventDateNotes Voting List Deadline March 26, 1999 RTF Public Comment Deadline November 19, 1999 RTF Revision Deadline January 14, 2000 RTF Revision Deadline List: CompanyDateNotes (none) (none received) Voting List: CompanyDateNotes ApTestMarch 26, 1999Stephen McNamara, stephen@aptest.ie BEA SystemsMarch 26, 1999Ed Cobb, ed.cobb@beasys.com DSTCMarch 26, 1999Michi Henning Floorboard SoftwareMarch 26, 1999Jon Biggar, jon@floorboard.com FujitsuMarch 26, 1999Sugino Hewlett-PackardMarch 26, 1999Jishnu Mukerji, jis@fpk.hp.com IONAMarch 26, 1999Bob Kukura, kukura@iona.com Inprise CorporationMarch 26, 1999Jeff Mischkinsky, jeffm@inprise.com International Business MachinesMarch 26, 1999Simon Nash Lucent TechnologiesMarch 26, 1999Tom Rutt (CHAIR), terutt@lucent.com NortelMarch 26, 1999Dave Stringer, d.r.stringer@nortel.co.uk NovellMarch 26, 1999Bill Cox, bill@novell.com Objective Interface SystemsMarch 26, 1999Bill Beckwith Rogue Wave SoftwareMarch 26, 1999Paul Kyzivat Sun MicrosystemsMarch 26, 1999Ken Cavanaugh, ken.cavanaugh@eng.sun.com XeroxMarch 26, 1999Bill Janssen, janssen@parc.xerox.com Help Copyright © 1997, 1998 Object Management Group, Inc. All Rights Reserved. For questions or comments about this site, please contact webeditor@omg.org. This site was prepared by Ummata LLC. Date: Wed, 28 Jul 1999 16:23:52 PDT Sender: Bill Janssen From: Bill Janssen To: Paul H Kyzivat , terutt@lucent.com Subject: Re: Discussing Alternatives a thru d for urgent Issue CC: interop@omg.org, firewall-rtf@omg.org Do we really need a conference call? But I can make it. Bill From: Jeffrey Mischkinsky Subject: Re: Discussing Alternatives a thru d for urgent Issue To: terutt@lucent.com Date: Wed, 28 Jul 1999 16:56:37 -0700 (PDT) Cc: interop@omg.org, firewall-rtf@omg.org, paulk@roguewave.com X-Mailer: ELM [version 2.4 PL25] Tom, Monday is the due date for most of the RFPs that are due for San Jose, so I suspect at lot of us will on double and triple booked for conf calls. Is there really that much else to say that can't happen via an email vote? jeff 'Tom Rutt' writes: > > This is a multi-part message in MIME format. > --------------AEBBF0B1168CCEB63D36BE38 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Thanks Paul, I am working on a vote to send out tonight. > > I would like to have a conference call Monday August 2, > 9:00 AM California time, 12:00 noon east coast us time > for one hour to discuss the vote results. > > Voting members, please let me know asap whether you can call > in on monday. The voting list is attached > > Paul H Kyzivat wrote: > > > > Tom Rutt wrote: > > > > > > To focus discussions, I propose we label four alternative solutions, > > > a thru d, as follows > > > > Tom - We have discussed these ad nauseum, and we now have one more week > > before the due date. > > > > What is the next step? I am not sure that we have exact, precise, > > wording for all of the alternatives yet, but probably enough for > > everyone to know what we are talking about. > > > > Seems like we could take another straw vote, then do a precise proposal > > for the winner and formally vote it. (That seems like less trouble to me > > that precisely writing up all four.) > > > > Or what do you suggest. I would rather not end up with Andrew's default > > resolution. > > -- > > Tom Rutt email: terutt@lucent.com > Lucent Technologies Bell Labs Tel: +1(732)949-7862 > Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA > --------------AEBBF0B1168CCEB63D36BE38 > Content-Type: text/html; charset=us-ascii; name="Interop_RTF.html" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; filename="Interop_RTF.html" > Content-Base: "file:///D|/data/omg/INTEROP/urgntiss/I > nterop_RTF.html" > > >> >> >> >> >> >> > >> content="text/html; charset=iso-8859-1"> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Connectivity Networking Distributed Computing"> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> class="navt">Calendar of >Events >> >> class="navt">Download Specifications >> >> class="navt">Become a Member >> >> class="navt">Press Room > >> class="navt">OMG >Publications >> >> class="navt">International >Offices > >> class="navt">Contact >Us >> >> > >> >> >> >> >> > >> >> >> >> >> > >> > >> >> >> border="0" width="160" height="75">src="/techprocess/meetings/graphix/banner.jpg" alt="Banner" align="top" >border="0" width="406" height="75"> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> > >> color="#000066" class="tocht"> >> >> The OMG >> >> >> >> >> >> > >> > >> >> >> OMG Home > >> About the OMG > >> Member Companies > >> Liaison Relationships > >> OMG News & Info > >> How We're Organized > >> Staff Contacts & Partners Success >Stories > >> > >> >> >> >> >> > >> > >> color="#000066" class="tocht"> >> >> CORBA >> >> >> >> >> >> > >> > >> >> >> CORBA for Beginners > >> >> >> >> >> CORBAnet > >> CORBA 3 Release Info > >> CORBA Academy Training > >> Free Stuff > >> > >> >> >> >> >> > >> > >> color="#000066" class="tocht"> >> >> The OMA >> >> >> >> >> >> > >> > >> >> >> IDL Text Files > >> CORBA/IIOP > >> Domain Interfaces > >> CORBA Services > >> CORBA Telecoms > >> CORBA Finance > >> CORBA Med > >> href="/techprocess/meetings/schedule/Technology_Adoptions.html#tbl_MOF_Speci fication">MOF Documents > >> href="/techprocess/meetings/schedule/Technology_Adoptions.html#tbl_UML_Speci fication">UML > >> > >> >> >> >> >> > >> > >> color="#000066" class="tocht"> >> >> Technology Process >> >> >> >> > >> > >> > >> >> >> Form for Reporting Issues > >> OMG Revision Issues > >> Technical Commitee Groups > >> Technology Process >FAQ > >> RFI FAQ > >> TC Home Pages > >> TC Work in >Progress > >> TC >Deadlines > >> TC Vote Status > >> > >> >> >> >> >> > >> > >> color="#000066" class="tocht"> >> >> Technical Library >> >> >> >> > >> > >> > >> >> >> Library Index > >> Document Search > >> About OMG Documentation > >> Presentation Library > >> Listen to the Experts > >> Whitepapers > >> > >> >> >> >> >> > >> > >> color="#000066" class="tocht"> >> >> Meeting Information >> >> >> >> >> > > >> > >> >> >> Meeting Index > >> Letter to Member >Reps. > >> >> >> Meeting >Registration > >> Upcoming Meetings > >> Meeting >Agendas > >> Hotel Information > >> >> >> TC Minutes > >> > >> >> >> >> >> > >> > >> color="#000066" class="tocht"> >> >> Member Services >> >> >> >> >> >> > >> > >> >> >> Member Services Index > >> >> >> Document Search > >> >> >> Ask the Experts > >> Mailing Lists > >> Board of Directors Info > >> BOD List > >> BOD Meetings > >> Speaker Request Form > >> Marketing Support > >> Membership Benefits > >> Become a Member! > >> Analyst Member Programs > >> > >> >> >> >> >> > >> > >> color="#000066" class="tocht"> >> >> Related Information >> >> >> >> >> > > >> > >> >> >> Reading Room > >> Points of Interest > >> User Groups > >> >> >> > >> >> >> >> >> > >> >> >> > >> color="#000066" class="tocht"> >> >> OMG Company Store >> >> >> >> > >> > >> > >> >> >> Publication Services > >> OMG Geek Boutique > >> > >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> color="#000066" class="tocht"> >> >> Legal Information >> >> >> >> > >> > >> > >> >> >> Legal Disclaimer > >> Guidelines for Using OMG > Trademarks > >> > >> >> >> > >> >> >> >> >> > >> >> >> >> >> src="/graphix/space.gif" width="2" height="1"> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> > >> OMG TC Work in Progress > >> Last updated: Wednesday, 28-Jul-99 16:19:06 >> >> > >> >> >> >> >> >> >> Interop RTF > Status: No deadlines have passed. > > > Schedule >> EventDateNotes > HREF="#Voting_List_Deadline">Voting List Deadline >> March 26, 1999 > > HREF="#RTF_Public_Comment_Deadline">RTF Public Comment Deadline >> November 19, 1999 > > HREF="#RTF_Revision_Deadline">RTF Revision Deadline >> January 14, 2000 > > > >> RTF Revision Deadline List: > > CompanyDateNotes > (none) (none received) > > >> Voting List: > > CompanyDateNotes > ApTestMarch 26, 1999Stephen McNamara, >stephen@aptest.ie > BEA SystemsMarch 26, 1999Ed Cobb, >ed.cobb@beasys.com > DSTCMarch 26, 1999Michi Henning > Floorboard SoftwareMarch 26, 1999Jon Biggar, >jon@floorboard.com > FujitsuMarch 26, 1999Sugino > Hewlett-PackardMarch 26, 1999Jishnu Mukerji, >jis@fpk.hp.com > IONAMarch 26, 1999Bob Kukura, >kukura@iona.com > Inprise CorporationMarch 26, 1999Jeff >Mischkinsky, jeffm@inprise.com > International Business MachinesMarch 26, >1999Simon Nash > Lucent TechnologiesMarch 26, 1999Tom Rutt >(CHAIR), terutt@lucent.com > NortelMarch 26, 1999Dave Stringer, >d.r.stringer@nortel.co.uk > NovellMarch 26, 1999Bill Cox, >bill@novell.com > Objective Interface SystemsMarch 26, 1999Bill >Beckwith > Rogue Wave SoftwareMarch 26, 1999Paul >Kyzivat > Sun MicrosystemsMarch 26, 1999Ken Cavanaugh, >ken.cavanaugh@eng.sun.com > XeroxMarch 26, 1999Bill Janssen, >janssen@parc.xerox.com > > >> >> >> >> >> >> >> >> > >> > >> > >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> > >> >> >> > >> >> >> >> >> value="Search"> Help >> >> > >> > >> > >> > >> >> >> width="200" height="26"> >> >> >> >> > >> >> >> > >> > >> >> >> > >> >> >> > >> >> >> >> >> Copyright © 1997, 1998 Object Management Group, Inc. > >> All Rights Reserved. > >> For questions or comments about this site, please contact > >> webeditor@omg.org. > >> This site was prepared by Ummata >LLC. >> >> >> >> > >> > >> >> >> > >> >> >> > >> >> >> > >> > >> >> >> >> >> > >> >> >> >> >> >> >> > > > --------------AEBBF0B1168CCEB63D36BE38-- > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 To: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, terutt@lucent.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, janssen@parc.xerox.com Cc: interop@omg.org, firewall-rtf@omg.org Date: Wed, 28 Jul 1999 20:36:52 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) Original-To: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, terutt@lucent.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@eng.sun.com, janssen@parc.xerox.com Original-CC: interop@omg.org, firewall-rtf@omg.org Subject: EXPEDITED VOTE on Interop Urgent Issue (due friday July 30) Here is the vote. Voting members should vote for one of the four alternatives a), b), c), or d). We can do final wordsmithing of the winning alternative (the one with the most votes) next week. I agree with the words of Jeff M , "I could easily be convinced of this approach (i.e, c or d), but i don't think it should be permissible to add a new messge type to an existing, approved, and published giop version. So i think we're stuck. jeff " I include all four on the vote only to avoid being cast as a dictator. I strongly do not believe alternatives c) or d) are appropriate for this urgent issue resolution, but can be input to the GIOP 1.3 discussions early next year. This is an expedited vote, and responses must be sent by 5:00 PM California Time this Friday July 30. (8:00 PM eastern time). We can try to do this without a conference call on monday. The voting list is: ApTest Stephen McNamara, stephen@aptest.ie BEA Systems Ed Cobb, ed.cobb@beasys.com DSTC Michi Henning, michi@triodia.com Floorboard Software Jon Biggar, jon@floorboard.com Fujitsu Sugino (??? email) Hewlett-Packard Jishnu Mukerji, jis@fpk.hp.com IONA Bob Kukura, kukura@iona.com Inprise Corporation Jeff Mischkinsky, jeffm@inprise.com IBM Simon Nash, nash@hursley.ibm.com Lucent Technologies Tom Rutt (CHAIR), terutt@lucent.com Nortel Dave Stringer, d.r.stringer@nortel.co.uk Novell Bill Cox, bill@novell.com OIS Bill Beckwith, bill.beckwith@ois.com Rogue Wave Software Paul Kyzivat, paulk@roguewave.com Sun Microsystems Ken Cavanaugh, ken.cavanaugh@eng.sun.com Xerox Bill Janssen, janssen@parc.xerox.com a) depricate broken feature Add the following paragraph to the section on Bi-Directional GIOP: " In GIOP 1.2, if bi-directional GIOP is used on a connection, then GIOP fragments shall not be sent interleaved with other messages. " b) even/odd request Ids approach In section 15.8 (Bi-Directional GIOP), replace that begins with "Bi-directional GIOP connections modify the behavior of Request IDs" with the following new paragraph: "Bi-directional GIOP connections modify the behavior of Request IDs. In the GIOP specification, "Connection Management" on page 15-44, it is noted that "Request IDs must unambiguously associate replies with requests within the scope and lifetime of a connection". With Bi-directional GIOP this guarantee must be preserved while permitting each end to generate Request IDs for new requests. To ensure this, on a connection that is used bi-directionally, the connection originator shall assign only even valued Request IDs and the other side of the connection shall assign only odd valued Request IDs. This requirement applies to the full lifetime of the connection, even before a BiDirIIOPServiceContext is transmitted." c) reverse flow bit approach In section 15.4.1 (GIOP Message Header), replace the paragraph startingwith "The most significant 6 bits are reserved" with the following: "In GIOP 1.2, the third least significant bit indicates, when TRUE(1), that the client and server roles of the connection are reversed for this message; the endpoint that initiated the connection is the server and the endpoint that accepted the connection is the client. This bit may only be set when Bi-directional GIOP is in use. In GIOP 1.1, and when Bi-directional GIOP is not in use, this bit must have the value FALSE(0)." "The most significant 5 bits are reserved. These 5 bits must have the value 0 for GIOP version 1.1 and 1.2." d) Add new Fragment message type Modify the GIOP 1.2 protocol to add new message type(s) to distinguish fragments of a request from fragments of a response. --------- Attached are the amended scenarios based on the discussions. The fact remains that solutions c) and d) require the new implementation to abort or take a non-standard fix up if interworking with an implementation of the published giop 1.2 spec. ---------------------------- Some interoperability scenarios for alternatives a-d As a baseline, this is the scenario with the broken interleaved fragmentation. oldClient/oldServer - The oldclient originates connection and uses old GIOP 1.2 to send fragmented requests with requestid incremented by one. The oldServer sends fragmented requests with old GIOP 1.2 format, incrementing by one. Ocassionally, there will be marshalling exceptions passed to the invoking application due to the colliding fragment request Ids from one side's requests and the other side's responses. This collision frequency will be worst when the rates of invocation are equal on both sides. In extremely rare cases when there are identical fragment sizes and compatible IDL syntax encoded in the fragment, the orb may pass undetected erroneous marshalled data.) a) depricate broken feature a2) " In GIOP 1.2, if bi-directional GIOP is used on a connection, then GIOP fragments shall not be sent interleaved with other messages. " oldClient/NewServer - The oldClient originates a connection and starts using old GIOP 1.2 to send fragmented requests with requestId incrementing by one (note this fix places the oldClient out of conformance with the "fixed" giop 1.2 protocol. The fix should be permissive and the new implementation must not abort the connection because the oldClient is non-conformant to the "fixed" Giop 1.2). The newServer, will not send interleaved fragments for requests or responses, and thus will never cause a collision. newClient/oldServer - similar interworking as with oldClient/NewServer, because one side is not sending fragmented requests the problem of collision never happens. One drawback to approach a) if interpreted as worded, would be if the new implementation aborted the connection each time the other side sent an interleaved fragment message. b) even/odd Request Id restriction Add the following sentence: " To avoid collisions of request Ids in fragment messages when bi-directional giop is in use, the originator of the connection should use even request IDs, and the other side of the connection should uses odd request IDs. " oldClient/NewServer - The oldClient originates a connection and starts using old GIOP 1.2 to send fragmented requests with requestId incrementing by one. The newServer, when sending requests to the oldClient will send fragmented request with requestId incremented by two (its request Ids will move out or range with the oldClient quickly). The likelihodd of the newServer sending requests at exactly half the rate of the oldClient (and thus subjecting the connection to the possibility of an interleaved fragment collision) is extrememly slim. newClient/oldServer - similar interworking as with oldClient/NewServer, except the client originating request ids will move twice as fast per invocation as the oldServers. c) the reverse-flow bit of message header flags Modify the definition of the message header flags field to specify usage of one bit to indicate the message is in reverse flow (i.e. request fragment towards connection originator or reply fragment from connection originator. oldClient/NewServer - The oldClient originates a connection and starts using old GIOP 1.2 to send fragmented requests with requestId incrementing by one. The newServer, will be able to process the messages sent by the oldClient, since the flow is not reverse. However the oldClient will abort the connection if the newServer tries to use the reverse-flow bit in a GIOP 1.2 message header. newClient/oldServer - The newClient originates a connection and starts using new GIOP 1.2 to send fragmented requests, but since it is not reverse-flow the header bit will not be set and the oldServer will be able to process the messages. However, when the oldServer sends a fragmented message without the reverse-flow bit set, the newClient will have to abort the connection, since the bit is not set on reverse flow. d) Add new Fragment message type Modify the GIOP 1.2 protocol to add new message type(s) to distinguish fragments. Two variants have been suggested, and they behave differently. d1) replace Fragment with RequestFragment, add ReplyFragment d2) add BiDirFragment oldClient/NewServer - The oldClient originates a connection and starts using old GIOP 1.2 to send fragmented requests with requestId incrementing by one. The newServer, will be able to process the messages sent by the old Client (assuming the request fragment message is unchanged) However the oldClient will abort the connection if the newServer tries to use the new fragment message for the response using a GIOP 1.2 message header. The client should send MessageError when the message type is unknown. The newServer could have some fallback strategy for this case although there is not really enough information to be sure what is going on. This is the d1 case. In this case using bidir, when newServer sends a fragmented request oldClient will process it, but if the reply from oldClient is fragmented, newServer will fall into the ambiguity if there is an incoming fragmented request with the same id, otherwise it sees the fragment as out of new protocol and may abort or have an 'old client' fix that treats the fragment as a ReplyFragment. In the d2 case, fragmented requests from oldClient are accepted, fragmented replies from newServer are accepted. When using bidir, fragmented requests from newServer are unknown to oldClient which should respond MessageError to the BiDirFragment; newServer may be able to adopt a fallback strategy. If newServer sends a non-fragmented request and the response from oldClient is fragmented, the position is the same as for the d1 case. newClient/oldServer - The newClient originates a connection and starts using new GIOP 1.2 to send fragmented requests, and the old server will be able to process the request messages sent by the newClient However, when the oldServer does not send a new fragmented response message , the newClient will have to abort the connection, since it assumes GIOP 1.2 uses the new message type for responses. This is the d1 case again; for d2, everything works until you go bidir. When using bidir, in the d1 case, the problem occurs when newClient sends a fragmented reply with the new ReplyFragment; oldServer should respond MessageError leaving newClient to abort or workaround. In the d2 case, a fragmented request from oldServer will use Fragment which may be ambiguous, but otherwise gives the fail/fallback option. A fragmented reply from newClient should cause oldServer to respond MessageError, leaving newClient with the fail/fallback option. --------- In summary, The Interworking scenarios for: a) takes away functionality but avoids collision between old and new implementations, and b) Fixes the problem completely between new implementations, and makes the liklihood of the collision problem between old and new implementations much less possible than with the unfixed scenario c) just does not work d) just does not work -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Date: Wed, 28 Jul 1999 18:19:47 PDT Sender: Bill Janssen From: Bill Janssen To: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, terutt@lucent.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, janssen@parc.xerox.com, terutt@lucent.com Subject: Re: EXPEDITED VOTE on Interop Urgent Issue (due friday July 30) CC: interop@omg.org, firewall-rtf@omg.org Xerox votes for C. Bill Cc: interop@omg.org, firewall-rtf@omg.org, paulk@roguewave.com Date: Wed, 28 Jul 1999 20:41:33 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Jeffrey Mischkinsky Original-CC: interop@omg.org, firewall-rtf@omg.org, paulk@roguewave.com Subject: Re: Discussing Alternatives a thru d for urgent Issue I guess we can see on monday if we have a vote. Thus, if we have a call, it will be announced on monday. Please vote before friday evening. Jeffrey Mischkinsky wrote: > > Tom, > Monday is the due date for most of the RFPs that are due for San Jose, so > I suspect at lot of us will on double and triple booked for conf calls. > Is there really that much else to say that can't happen via an email vote? > > jeff > 'Tom Rutt' writes: > > > > This is a multi-part message in MIME format. > > --------------AEBBF0B1168CCEB63D36BE38 > > Content-Type: text/plain; charset=us-ascii > > Content-Transfer-Encoding: 7bit > > > > Thanks Paul, I am working on a vote to send out tonight. > > > > I would like to have a conference call Monday August 2, > > 9:00 AM California time, 12:00 noon east coast us time > > for one hour to discuss the vote results. > > > > Voting members, please let me know asap whether you can call > > in on monday. The voting list is attached > > > > Paul H Kyzivat wrote: > > > > > > Tom Rutt wrote: > > > > > > > > To focus discussions, I propose we label four alternative solutions, > > > > a thru d, as follows > > > > > > Tom - We have discussed these ad nauseum, and we now have one more week > > > before the due date. > > > > > > What is the next step? I am not sure that we have exact, precise, > > > wording for all of the alternatives yet, but probably enough for > > > everyone to know what we are talking about. > > > > > > Seems like we could take another straw vote, then do a precise proposal > > > for the winner and formally vote it. (That seems like less trouble to me > > > that precisely writing up all four.) > > > > > > Or what do you suggest. I would rather not end up with Andrew's default > > > resolution. > > > > -- > > > > Tom Rutt email: terutt@lucent.com > > Lucent Technologies Bell Labs Tel: +1(732)949-7862 > > Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 > > Holmdel NJ, 07733 USA > > --------------AEBBF0B1168CCEB63D36BE38 > > Content-Type: text/html; charset=us-ascii; name="Interop_RTF.html" > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline; filename="Interop_RTF.html" > > Content-Base: "file:///D|/data/omg/INTEROP/urgntiss/I > > nterop_RTF.html" > > > > >> > >> > >> > >> > >> > >> > > > >> > content="text/html; charset=iso-8859-1"> >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> > >> > >> > >> > >> > >> > >> > >> > Connectivity Networking Distributed Computing"> >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> > >> > >> > >> > > > >> > >> > >> > >> > >> > > > >> > >> > >> > >> > >> > > > >> > face="tahoma,geneva" class="navt">Calendar >of Events >> > >> > face="tahoma,geneva" class="navt">href="/library/downinst.html">Download Specifications >> > >> > face="tahoma,geneva" class="navt">Become a >Member > > > > face="tahoma,geneva" class="navt">Press >Room >> > >> > face="tahoma,geneva" class="navt">OMG >Publications >> > >> > face="tahoma,geneva" class="navt">href="/homepages/partners">International Offices >> > >> > face="tahoma,geneva" class="navt">href="/omg/contacts/contact.html">Contact Us >> > >> > > > >> > >> > >> > >> > >> > > > >> > >> > >> > >> > >> > > > >> > > > >> > >> > >> > align="top" border="0" width="160" height="75">src="/techprocess/meetings/graphix/banner.jpg" alt="Banner" align="top" >border="0" width="406" height="75"> >> > >> > >> > >> > > > >> > >> > >> > >> > >> > >> > >> > > > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > >> > face="tahoma,geneva" color="#000066" class="tocht"> >> > >> > The OMG > > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" class="tocit"> >> > >> > OMG Home > > >> > About the >OMG > > >> > Member >Companies > > >> > Liaison Relationships > > >> > OMG News & Info > > >> > How We're >Organized > > >> > Staff >Contacts & Partners target="ex">Success Stories > > >> > > > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" color="#000066" class="tocht"> >> > >> > CORBA > > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" class="tocit"> >> > >> > CORBA for >Beginners > > >> > >> > >> > >> > >> > CORBAnet > > >> > CORBA 3 >Release Info > > >> > CORBA >Academy Training > > >> > Free >Stuff > > >> > > > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" color="#000066" class="tocht"> >> > >> > The OMA > > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" class="tocit"> >> > >> > IDL Text >Files > > >> > href="/library/c2indx.html">CORBA/IIOP > > >> > Domain >Interfaces > > >> > CORBA >Services > > >> > CORBA Telecoms > > >> > CORBA Finance > > >> > CORBA Med > > >> > href="/techprocess/meetings/schedule/Technology_Adoptions.html#tbl_MOF_Speci fication">MOF Documents > > >> > href="/techprocess/meetings/schedule/Technology_Adoptions.html#tbl_UML_Speci fication">UML > > >> > > > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" color="#000066" class="tocht"> >> > >> > Technology Process >> > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" class="tocit"> >> > >> > Form for Reporting Issues > > >> > OMG Revision Issues > > >> > Technical >Commitee Groups > > >> > href="/techprocess/faq_process.html">Technology Process FAQ > > >> > RFI >FAQ > > >> > TC Home Pages > > >> > href="/techprocess/meetings/schedule/index.html">TC Work in Progress > > >> > TC >Deadlines > > >> > href="/techprocess/faxvotes/index.html">TC Vote Status > > >> > > > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" color="#000066" class="tocht"> >> > >> > Technical Library >> > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" class="tocit"> >> > >> > Library Index > > >> > Document >Search > > >> > About OMG >Documentation > > >> > Presentation >Library > > >> > Listen to >the Experts > > >> > href="/library/whitepapers.html">Whitepapers > > >> > > > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" color="#000066" class="tocht"> >> > >> > Meeting Information >> > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" class="tocit"> >> > >> > Meeting >Index > > >> > Letter to Member >Reps. > > >> > >> > >> > href="/techprocess/meetings/meetingreg.html">Meeting Registration > > >> > Upcoming >Meetings > > >> > href="/techprocess/meetings/agendas/index.html">Meeting Agendas > > >> > href="/techprocess/meetings/hotel.html">Hotel Information > > >> > >> > >> > href="ftp://ftp.omg.org/pub/docs/TCdocuments/">TC Minutes > > >> > > > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" color="#000066" class="tocht"> >> > >> > Member Services >> > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" class="tocit"> >> > >> > Member Services >Index > > >> > >> > >> > href="/cgi-bin/members/doclistm.pl">Document Search > > >> > >> > >> > Ask the >Experts > > >> > Mailing >Lists > > >> > Board of >Directors Info > > >> > BOD >List > > >> > BOD >Meetings > > >> > Speaker >Request Form > > >> > Marketing >Support > > >> > href="/membership/benefits.html">Membership Benefits > > >> > Become a >Member! > > >> > Analyst Member Programs > > >> > > > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" color="#000066" class="tocht"> >> > >> > Related Information >> > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" class="tocit"> >> > >> > Reading >Room > > >> > Points of >Interest > > >> > User >Groups > > >> > >> > >> > > > >> > >> > >> > >> > >> > > > >> > >> > >> > > > >> > face="tahoma,geneva" color="#000066" class="tocht"> >> > >> > OMG Company Store >> > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" class="tocit"> >> > >> > Publication >Services > > >> > OMG Geek >Boutique > > >> > > > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > >> > >> > >> > >> > >> > > > >> > face="tahoma,geneva" color="#000066" class="tocht"> >> > >> > Legal Information >> > >> > >> > >> > >> > >> > > > >> > > > >> > face="tahoma,geneva" class="tocit"> >> > >> > Legal >Disclaimer > > >> > Guidelines for Using >OMG Trademarks > > >> > > > >> > >> > >> > > > >> > >> > >> > >> > >> > > > >> > >> > >> > >> > >> > class="tochb"> >> > >> > >> > >> > >> > >> > >> >> > >> > >> > > > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > >> > OMG TC Work in Progress > > >> > Last updated: Wednesday, 28-Jul-99 16:19:06 >> > >> > > > >> > >> > >> > >> > >> > >> > >> > Interop RTF > > Status: No deadlines have passed. > > > > > > Schedule >> > EventDateNotes > > HREF="#Voting_List_Deadline">Voting List Deadline >> > March 26, 1999 > > > > HREF="#RTF_Public_Comment_Deadline">RTF Public Comment Deadline >> > November 19, 1999 > > > > HREF="#RTF_Revision_Deadline">RTF Revision Deadline >> > January 14, 2000 > > > > > > >> > RTF Revision Deadline List: > > > > CompanyDateNotes > > (none) (none >received) > > > > >> > Voting List: > > > > CompanyDateNotes > > ApTestMarch 26, 1999Stephen McNamara, >stephen@aptest.ie > > BEA SystemsMarch 26, 1999Ed Cobb, >ed.cobb@beasys.com > > DSTCMarch 26, 1999Michi Henning > > Floorboard SoftwareMarch 26, 1999Jon Biggar, >jon@floorboard.com > > FujitsuMarch 26, 1999Sugino > > Hewlett-PackardMarch 26, 1999Jishnu Mukerji, >jis@fpk.hp.com > > IONAMarch 26, 1999Bob Kukura, >kukura@iona.com > > Inprise CorporationMarch 26, 1999Jeff >Mischkinsky, jeffm@inprise.com > > International Business MachinesMarch 26, >1999Simon Nash > > Lucent TechnologiesMarch 26, 1999Tom Rutt >(CHAIR), terutt@lucent.com > > NortelMarch 26, 1999Dave Stringer, >d.r.stringer@nortel.co.uk > > NovellMarch 26, 1999Bill Cox, >bill@novell.com > > Objective Interface SystemsMarch 26, 1999Bill >Beckwith > > Rogue Wave SoftwareMarch 26, 1999Paul >Kyzivat > > Sun MicrosystemsMarch 26, 1999Ken Cavanaugh, >ken.cavanaugh@eng.sun.com > > XeroxMarch 26, 1999Bill Janssen, >janssen@parc.xerox.com > > > > >> > >> > >> > >> > >> > >> > >> > >> > > > >> > > > >> > > > >> > >> > >> > > > >> > >> > >> > > > >> > action="http://www.omg.org:8765/query.html" name="search"> >> > >> > value="omgpub"> >> > >> > value=""> >> > >> > value="600"> >> > >> > value="0"> > > >> > value="0"> >> > >> > value="1"> >> > >> > value="10"> >> > >> > value="1"> >> > >> > value="0"> >> > >> > value="0"> >> > >> > > > >> > > > >> > >> > >> > > > >> > bgcolor="#CCCCFF"> >> > >> > >> > >> > size="30" name="qt"> href="http://www.omg.org:8765/help">Help >> > >> > >> > >> > >> > >> > > > >> > > > >> > >> > >> > src="/graphix/infoseeklogo.gif" alt="Ultraseek Server Logo" width="200" >height="26"> >> > >> > >> > >> > > > >> > >> > >> > > > >> > > > >> > >> > >> > > > >> > bgcolor="#EEEEEE"> >> > >> > > > >> > >> > >> > >> > >> > Copyright © 1997, >1998 Object Management Group, Inc. > > >> > All Rights Reserved. > > >> > For questions or comments >about this site, please contact > > >> > href="mailto:webeditor@omg.org">webeditor@omg.org. > > >> > This site was prepared by >Ummata LLC. >> > >> >> > >> > >> > >> > > > >> > >> > >> > > > >> > >> > >> > > > >> > >> > >> > > > >> > > > >> > >> > >> > >> > >> > > > >> > >> > >> > >> > >> > >> > >> > > > > > > > --------------AEBBF0B1168CCEB63D36BE38-- > > > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeffm@inprise.com +1 650-358-3049 -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA To: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, terutt@lucent.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, janssen@parc.xerox.com, interop@omg.org, firewall-rtf@omg.org Date: Wed, 28 Jul 1999 20:43:30 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) Original-To: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, terutt@lucent.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@eng.sun.com, janssen@parc.xerox.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: EXPEDITED VOTE on Interop Urgent Issue (due friday July 30) Tom Rutt wrote: > > Here is the vote. Voting members should vote for one of the four alternatives > a), b), c), or d). > Lucent's vote is for alternative b) even/odd request id. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA To: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, terutt@lucent.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, janssen@parc.xerox.com, interop@omg.org, firewall-rtf@omg.org Date: Wed, 28 Jul 1999 20:56:27 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) Original-To: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, terutt@lucent.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@eng.sun.com, janssen@parc.xerox.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: EXPEDITED VOTE on Interop Urgent Issue (due friday July 30) Tom Rutt wrote: > > Tom Rutt wrote: > > > > Here is the vote. Voting members should vote for one of the four alternatives > > a), b), c), or d). > > > I just talked to Michi on the phone. He is leaving to go to Germany to be with his ailing mother. He told me to record his vote to be for alternative a) depricate broken feature -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Sender: "Jeff Mischkinsky" Date: Wed, 28 Jul 1999 18:50:00 -0700 From: Jeff Mischkinsky Organization: INPRISE Corporation X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en To: terutt@lucent.com CC: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@eng.sun.com, janssen@parc.xerox.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: EXPEDITED VOTE on Interop Urgent Issue (due friday July 30) Tom Rutt wrote: > > Here is the vote. Voting members should vote for one of the four alternatives > a), b), c), or d). Inprise votes for b) odd/even jeff -- Jeff Mischkinsky email: jeffm@inprise.com Senior Software Architect INPRISE Corporation voice: +1(650)358-3049 951 Mariner's Island Blvd. Suite 460 fax: +1(650)358-3095 San Mateo, CA 94404 web: http://www.inprise.com Date: Wed, 28 Jul 1999 22:44:23 -0400 (EDT) From: Bill Beckwith X-Sender: beckwb@gamma To: Tom Rutt cc: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, terutt@lucent.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@eng.sun.com, janssen@parc.xerox.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: EXPEDITED VOTE on Interop Urgent Issue (due friday July 30) On Wed, 28 Jul 1999, Tom Rutt wrote: > Here is the vote. Voting members should vote for one of the four alternatives > a), b), c), or d). > a) depricate broken feature > Add the following paragraph to the section on Bi-Directional GIOP: > > " > In GIOP 1.2, if bi-directional GIOP is used on a connection, then GIOP fragments > shall not be sent interleaved with other messages. > " Objective Interface votes for (a), to deprecate bi-directional interleaving. -- Bill Date: Thu, 29 Jul 1999 09:43:44 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en To: terutt@lucent.com CC: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@eng.sun.com, janssen@parc.xerox.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: EXPEDITED VOTE on Interop Urgent Issue (due friday July 30) Tom Rutt wrote: > > Here is the vote. Voting members should vote for one of the four alternatives > a), b), c), or d). IONA votes for option b), using odd/even request IDs to fix the problem now. We don't necessarily expect a GIOP 1.3 to be specificed any time soon (if ever, since there seems to be quite a bit of interest in a GIOP 2.0). -Bob X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 29 Jul 1999 07:39:58 -0700 To: terutt@lucent.com, stephen@aptest.ie, michi@triodia.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, terutt@lucent.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, janssen@parc.xerox.com From: Edward Cobb Subject: Re: EXPEDITED VOTE on Interop Urgent Issue (due friday July 30) Cc: interop@omg.org, firewall-rtf@omg.org, Paul Patrick BEA votes for option a, deprecate the broken feature. At 08:36 PM 7/28/99 -0400, Tom Rutt wrote: >Here is the vote. Voting members should vote for one of the four alternatives >a), b), c), or d). > >We can do final wordsmithing of the winning alternative (the one with the most >votes) next week. > >I agree with the words of Jeff M , >"I could easily be convinced of this approach (i.e, c or d), but i don't think >it should be permissible to add a new messge type to an existing, approved, >and published giop version. > So i think we're stuck. > jeff >" > >I include all four on the vote only to avoid being cast as a dictator. I >strongly do not believe alternatives c) or d) are appropriate for this urgent >issue resolution, but can be input to the GIOP 1.3 discussions early next year. > > >This is an expedited vote, and responses must be sent by 5:00 PM California Time >this Friday July 30. (8:00 PM eastern time). > >We can try to do this without a conference call on monday. > >The voting list is: > >ApTest Stephen McNamara, stephen@aptest.ie >BEA Systems Ed Cobb, ed.cobb@beasys.com >DSTC Michi Henning, michi@triodia.com >Floorboard Software Jon Biggar, jon@floorboard.com >Fujitsu Sugino (??? email) >Hewlett-Packard Jishnu Mukerji, jis@fpk.hp.com >IONA Bob Kukura, kukura@iona.com >Inprise Corporation Jeff Mischkinsky, jeffm@inprise.com >IBM Simon Nash, nash@hursley.ibm.com >Lucent Technologies Tom Rutt (CHAIR), terutt@lucent.com >Nortel Dave Stringer, d.r.stringer@nortel.co.uk >Novell Bill Cox, bill@novell.com >OIS Bill Beckwith, bill.beckwith@ois.com >Rogue Wave Software Paul Kyzivat, paulk@roguewave.com >Sun Microsystems Ken Cavanaugh, ken.cavanaugh@eng.sun.com >Xerox Bill Janssen, janssen@parc.xerox.com > > > > > >a) depricate broken feature >Add the following paragraph to the section on Bi-Directional GIOP: > >" >In GIOP 1.2, if bi-directional GIOP is used on a connection, then GIOP fragments >shall not be sent interleaved with other messages. >" > > >b) even/odd request Ids approach > >In section 15.8 (Bi-Directional GIOP), replace that begins with >"Bi-directional GIOP connections modify the behavior of Request IDs" >with the following new paragraph: > >"Bi-directional GIOP connections modify the behavior of Request IDs. In >the GIOP specification, "Connection Management" on page 15-44, it is >noted that "Request IDs must unambiguously associate replies with >requests within the scope and lifetime of a connection". With >Bi-directional GIOP this guarantee must be preserved while permitting each end >to generate Request IDs for new requests. To ensure this, on a connection that >is used bi-directionally, the connection originator shall assign only even >valued Request IDs and the other side of the connection shall assign only odd >valued Request IDs. This requirement applies to the full lifetime of the >connection, even before a BiDirIIOPServiceContext is transmitted." > >c) reverse flow bit approach > > >In section 15.4.1 (GIOP Message Header), replace the paragraph startingwith "The >most significant 6 bits are reserved" with the following: > >"In GIOP 1.2, the third least significant bit indicates, when TRUE(1), that the >client and server roles of the connection are reversed for this message; the >endpoint that initiated the connection is the server and the endpoint that >accepted the connection is the client. This bit may only be set when >Bi-directional GIOP is in use. In GIOP 1.1, and when Bi-directional GIOP is not >in use, this bit must have the value FALSE(0)." > >"The most significant 5 bits are reserved. These 5 bits must have the value 0 >for GIOP version 1.1 and 1.2." > >d) Add new Fragment message type > >Modify the GIOP 1.2 protocol to add new message type(s) to distinguish fragments >of a request from fragments of a response. > > > >--------- >Attached are the amended scenarios based on the discussions. The fact remains >that solutions c) and d) require the new implementation to abort or take a >non-standard fix up if interworking with an implementation of the published giop >1.2 spec. >---------------------------- >Some interoperability scenarios for alternatives a-d > >As a baseline, this is the scenario with the broken interleaved fragmentation. > >oldClient/oldServer - The oldclient originates connection and uses old GIOP 1.2 >to send fragmented requests with requestid incremented by one. The oldServer >sends fragmented requests with old GIOP 1.2 format, incrementing by one. >Ocassionally, there will be marshalling exceptions passed to the invoking >application due to the colliding fragment request Ids from one side's requests >and the other side's responses. This collision frequency will be worst when the >rates of invocation are equal on both sides. > >In extremely rare cases when there are identical fragment sizes and compatible >IDL syntax encoded in the fragment, the orb may pass undetected erroneous >marshalled data.) > >a) depricate broken feature > >a2) " >In GIOP 1.2, if bi-directional GIOP is used on a connection, then GIOP fragments >shall not be sent interleaved with other messages. >" > >oldClient/NewServer - The oldClient originates a connection and starts using old >GIOP 1.2 to send fragmented requests with requestId incrementing by one >(note this fix places the oldClient out of conformance with the "fixed" giop 1.2 >protocol. The fix should be permissive and the new implementation must not abort >the connection because the oldClient is non-conformant to the "fixed" Giop >1.2). >The newServer, will not send interleaved fragments for >requests or responses, and thus will never cause a collision. > >newClient/oldServer - similar interworking as with oldClient/NewServer, because >one side is not sending fragmented requests the problem of collision never >happens. > >One drawback to approach a) if interpreted as worded, would be if the new >implementation aborted the connection each time the other side sent an >interleaved fragment message. > >b) even/odd Request Id restriction > >Add the following sentence: >" >To avoid collisions of request Ids in fragment messages >when bi-directional giop is in use, the originator of the connection should use >even request IDs, and the other >side of the connection should uses odd request IDs. >" > >oldClient/NewServer - The oldClient originates a connection and starts using old >GIOP 1.2 to send fragmented requests with requestId incrementing by one. The >newServer, when sending requests to the oldClient will send fragmented request >with requestId incremented by two (its request Ids will move out or range with >the oldClient quickly). The likelihodd of the newServer sending requests at >exactly half the rate of the oldClient (and thus subjecting the connection to >the possibility of an interleaved fragment collision) is extrememly slim. > >newClient/oldServer - similar interworking as with oldClient/NewServer, except >the client originating request ids will move twice as fast per invocation as the >oldServers. > >c) the reverse-flow bit of message header flags > >Modify the definition of the message header flags field to specify usage of one >bit to indicate the message is in reverse flow (i.e. request fragment towards >connection originator or reply fragment from connection originator. > >oldClient/NewServer - The oldClient originates a connection and starts using old >GIOP 1.2 to send fragmented requests with requestId incrementing by one. The >newServer, will be able to process the messages sent by the oldClient, since the >flow is not reverse. However the oldClient will abort the connection if the >newServer tries to use the reverse-flow bit in a GIOP 1.2 message header. > >newClient/oldServer - The newClient originates a connection and starts using new >GIOP 1.2 to send fragmented requests, but since it is not reverse-flow the >header bit will not be set and the oldServer will be able to process the >messages. However, when the oldServer sends a fragmented message without the >reverse-flow bit set, the newClient will have to abort the connection, since the >bit is not set on reverse flow. > >d) Add new Fragment message type > >Modify the GIOP 1.2 protocol to add new message type(s) to distinguish >fragments. > > >Two variants have been suggested, and they behave differently. > >d1) replace Fragment with RequestFragment, add ReplyFragment >d2) add BiDirFragment > > >oldClient/NewServer - The oldClient originates a connection and starts using old >GIOP 1.2 to send fragmented requests with requestId incrementing by one. The >newServer, will be able to process the messages sent by the old Client (assuming >the request fragment message is unchanged) However the oldClient will abort the >connection if the newServer tries to use the new fragment message for the >response using a GIOP 1.2 message header. > > >The client should send MessageError when the message type is unknown. The >newServer could have some fallback strategy for this case although there is not >really enough information to be sure what is going on. > >This is the d1 case. In this case using bidir, when newServer sends a fragmented >request oldClient will process it, but if the reply from oldClient is >fragmented, newServer will fall into the ambiguity if there is an incoming >fragmented request with the same id, otherwise it sees the fragment as out of >new protocol and may abort or have an 'old client' fix that treats the fragment >as a ReplyFragment. > >In the d2 case, fragmented requests from oldClient are accepted, fragmented >replies from newServer are accepted. When using bidir, fragmented requests from >newServer are unknown to oldClient which should respond MessageError to the >BiDirFragment; newServer may be able to adopt a fallback strategy. >If newServer sends a non-fragmented request and the response from oldClient is >fragmented, the position is the same as for the d1 case. > > >newClient/oldServer - The newClient originates a connection and starts using new >GIOP 1.2 to send fragmented requests, and the old server will be able to process >the request messages sent by the newClient However, when the oldServer does not >send a new fragmented response message , the newClient will have to abort the >connection, since it assumes GIOP 1.2 uses the new message type for responses. > > >This is the d1 case again; for d2, everything works until you go bidir. > >When using bidir, in the d1 case, the problem occurs when newClient sends a >fragmented reply with the new ReplyFragment; oldServer should respond >MessageError leaving newClient to abort or workaround. In the d2 case, a >fragmented request from oldServer will use Fragment which may be ambiguous, >but otherwise gives the fail/fallback option. A fragmented reply from newClient >should cause oldServer to respond MessageError, leaving newClient with the >fail/fallback option. > >--------- > > >In summary, > >The Interworking scenarios for: >a) takes away functionality but avoids collision between old and new >implementations, and >b) Fixes the problem completely between new implementations, and makes the >liklihood of the collision problem between old and new implementations much less >possible than with the unfixed scenario >c) just does not work >d) just does not work > >-- > >Tom Rutt email: terutt@lucent.com >Lucent Technologies Bell Labs Tel: +1(732)949-7862 >Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 >Holmdel NJ, 07733 USA > >-- > >Tom Rutt email: terutt@lucent.com >Lucent Technologies Bell Labs Tel: +1(732)949-7862 >Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 >Holmdel NJ, 07733 USA > ************************************************************** Ed Cobb, Technical Director, Systems Architecture BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Thu, 29 Jul 1999 20:43:21 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en To: terutt@lucent.com CC: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, janssen@parc.xerox.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: EXPEDITED VOTE on Interop Urgent Issue (due friday July 30) Tom, IBM votes for option a. Our preferred solution is option d but we accept that it is impractical to get this into GIOP 1.2. We think that adopting option b for 1.2 would in all likelihood cause this to become the permanent solution. We would like to re-address this in GIOP 1.3 or 2.0 or whatever comes next, and adopt the best technical solution without the constraints imposed by the "urgent clarification" process. Simon Tom Rutt wrote: > > Here is the vote. Voting members should vote for one of the four alternatives > a), b), c), or d). > > We can do final wordsmithing of the winning alternative (the one with the most > votes) next week. > > I agree with the words of Jeff M , > "I could easily be convinced of this approach (i.e, c or d), but i don't think > it should be permissible to add a new messge type to an existing, approved, > and published giop version. > So i think we're stuck. > jeff > " > > I include all four on the vote only to avoid being cast as a dictator. I > strongly do not believe alternatives c) or d) are appropriate for this urgent > issue resolution, but can be input to the GIOP 1.3 discussions early next year. > > This is an expedited vote, and responses must be sent by 5:00 PM California Time > this Friday July 30. (8:00 PM eastern time). > > We can try to do this without a conference call on monday. > > The voting list is: > > ApTest Stephen McNamara, stephen@aptest.ie > BEA Systems Ed Cobb, ed.cobb@beasys.com > DSTC Michi Henning, michi@triodia.com > Floorboard Software Jon Biggar, jon@floorboard.com > Fujitsu Sugino (??? email) > Hewlett-Packard Jishnu Mukerji, jis@fpk.hp.com > IONA Bob Kukura, kukura@iona.com > Inprise Corporation Jeff Mischkinsky, jeffm@inprise.com > IBM Simon Nash, nash@hursley.ibm.com > Lucent Technologies Tom Rutt (CHAIR), terutt@lucent.com > Nortel Dave Stringer, d.r.stringer@nortel.co.uk > Novell Bill Cox, bill@novell.com > OIS Bill Beckwith, bill.beckwith@ois.com > Rogue Wave Software Paul Kyzivat, paulk@roguewave.com > Sun Microsystems Ken Cavanaugh, ken.cavanaugh@eng.sun.com > Xerox Bill Janssen, janssen@parc.xerox.com > > a) depricate broken feature > Add the following paragraph to the section on Bi-Directional GIOP: > > " > In GIOP 1.2, if bi-directional GIOP is used on a connection, then GIOP fragments > shall not be sent interleaved with other messages. > " > > b) even/odd request Ids approach > > In section 15.8 (Bi-Directional GIOP), replace that begins with > "Bi-directional GIOP connections modify the behavior of Request IDs" > with the following new paragraph: > > "Bi-directional GIOP connections modify the behavior of Request IDs. In > the GIOP specification, "Connection Management" on page 15-44, it is > noted that "Request IDs must unambiguously associate replies with > requests within the scope and lifetime of a connection". With > Bi-directional GIOP this guarantee must be preserved while permitting each end > to generate Request IDs for new requests. To ensure this, on a connection that > is used bi-directionally, the connection originator shall assign only even > valued Request IDs and the other side of the connection shall assign only odd > valued Request IDs. This requirement applies to the full lifetime of the > connection, even before a BiDirIIOPServiceContext is transmitted." > > c) reverse flow bit approach > > In section 15.4.1 (GIOP Message Header), replace the paragraph startingwith "The > most significant 6 bits are reserved" with the following: > > "In GIOP 1.2, the third least significant bit indicates, when TRUE(1), that the > client and server roles of the connection are reversed for this message; the > endpoint that initiated the connection is the server and the endpoint that > accepted the connection is the client. This bit may only be set when > Bi-directional GIOP is in use. In GIOP 1.1, and when Bi-directional GIOP is not > in use, this bit must have the value FALSE(0)." > > "The most significant 5 bits are reserved. These 5 bits must have the value 0 > for GIOP version 1.1 and 1.2." > > d) Add new Fragment message type > > Modify the GIOP 1.2 protocol to add new message type(s) to distinguish fragments > of a request from fragments of a response. > > --------- > Attached are the amended scenarios based on the discussions. The fact remains > that solutions c) and d) require the new implementation to abort or take a > non-standard fix up if interworking with an implementation of the published giop > 1.2 spec. > ---------------------------- > Some interoperability scenarios for alternatives a-d > > As a baseline, this is the scenario with the broken interleaved fragmentation. > > oldClient/oldServer - The oldclient originates connection and uses old GIOP 1.2 > to send fragmented requests with requestid incremented by one. The oldServer > sends fragmented requests with old GIOP 1.2 format, incrementing by one. > Ocassionally, there will be marshalling exceptions passed to the invoking > application due to the colliding fragment request Ids from one side's requests > and the other side's responses. This collision frequency will be worst when the > rates of invocation are equal on both sides. > > In extremely rare cases when there are identical fragment sizes and compatible > IDL syntax encoded in the fragment, the orb may pass undetected erroneous > marshalled data.) > > a) depricate broken feature > > a2) " > In GIOP 1.2, if bi-directional GIOP is used on a connection, then GIOP fragments > shall not be sent interleaved with other messages. > " > > oldClient/NewServer - The oldClient originates a connection and starts using old > GIOP 1.2 to send fragmented requests with requestId incrementing by one > (note this fix places the oldClient out of conformance with the "fixed" giop 1.2 > protocol. The fix should be permissive and the new implementation must not abort > the connection because the oldClient is non-conformant to the "fixed" Giop > 1.2). > The newServer, will not send interleaved fragments for > requests or responses, and thus will never cause a collision. > > newClient/oldServer - similar interworking as with oldClient/NewServer, because > one side is not sending fragmented requests the problem of collision never > happens. > > One drawback to approach a) if interpreted as worded, would be if the new > implementation aborted the connection each time the other side sent an > interleaved fragment message. > > b) even/odd Request Id restriction > > Add the following sentence: > " > To avoid collisions of request Ids in fragment messages > when bi-directional giop is in use, the originator of the connection should use > even request IDs, and the other > side of the connection should uses odd request IDs. > " > > oldClient/NewServer - The oldClient originates a connection and starts using old > GIOP 1.2 to send fragmented requests with requestId incrementing by one. The > newServer, when sending requests to the oldClient will send fragmented request > with requestId incremented by two (its request Ids will move out or range with > the oldClient quickly). The likelihodd of the newServer sending requests at > exactly half the rate of the oldClient (and thus subjecting the connection to > the possibility of an interleaved fragment collision) is extrememly slim. > > newClient/oldServer - similar interworking as with oldClient/NewServer, except > the client originating request ids will move twice as fast per invocation as the > oldServers. > > c) the reverse-flow bit of message header flags > > Modify the definition of the message header flags field to specify usage of one > bit to indicate the message is in reverse flow (i.e. request fragment towards > connection originator or reply fragment from connection originator. > > oldClient/NewServer - The oldClient originates a connection and starts using old > GIOP 1.2 to send fragmented requests with requestId incrementing by one. The > newServer, will be able to process the messages sent by the oldClient, since the > flow is not reverse. However the oldClient will abort the connection if the > newServer tries to use the reverse-flow bit in a GIOP 1.2 message header. > > newClient/oldServer - The newClient originates a connection and starts using new > GIOP 1.2 to send fragmented requests, but since it is not reverse-flow the > header bit will not be set and the oldServer will be able to process the > messages. However, when the oldServer sends a fragmented message without the > reverse-flow bit set, the newClient will have to abort the connection, since the > bit is not set on reverse flow. > > d) Add new Fragment message type > > Modify the GIOP 1.2 protocol to add new message type(s) to distinguish > fragments. > > Two variants have been suggested, and they behave differently. > > d1) replace Fragment with RequestFragment, add ReplyFragment > d2) add BiDirFragment > > oldClient/NewServer - The oldClient originates a connection and starts using old > GIOP 1.2 to send fragmented requests with requestId incrementing by one. The > newServer, will be able to process the messages sent by the old Client (assuming > the request fragment message is unchanged) However the oldClient will abort the > connection if the newServer tries to use the new fragment message for the > response using a GIOP 1.2 message header. > > The client should send MessageError when the message type is unknown. The > newServer could have some fallback strategy for this case although there is not > really enough information to be sure what is going on. > > This is the d1 case. In this case using bidir, when newServer sends a fragmented > request oldClient will process it, but if the reply from oldClient is > fragmented, newServer will fall into the ambiguity if there is an incoming > fragmented request with the same id, otherwise it sees the fragment as out of > new protocol and may abort or have an 'old client' fix that treats the fragment > as a ReplyFragment. > > In the d2 case, fragmented requests from oldClient are accepted, fragmented > replies from newServer are accepted. When using bidir, fragmented requests from > newServer are unknown to oldClient which should respond MessageError to the > BiDirFragment; newServer may be able to adopt a fallback strategy. > If newServer sends a non-fragmented request and the response from oldClient is > fragmented, the position is the same as for the d1 case. > > newClient/oldServer - The newClient originates a connection and starts using new > GIOP 1.2 to send fragmented requests, and the old server will be able to process > the request messages sent by the newClient However, when the oldServer does not > send a new fragmented response message , the newClient will have to abort the > connection, since it assumes GIOP 1.2 uses the new message type for responses. > > This is the d1 case again; for d2, everything works until you go bidir. > > When using bidir, in the d1 case, the problem occurs when newClient sends a > fragmented reply with the new ReplyFragment; oldServer should respond > MessageError leaving newClient to abort or workaround. In the d2 case, a > fragmented request from oldServer will use Fragment which may be ambiguous, > but otherwise gives the fail/fallback option. A fragmented reply from newClient > should cause oldServer to respond MessageError, leaving newClient with the > fail/fallback option. > > --------- > > In summary, > > The Interworking scenarios for: > a) takes away functionality but avoids collision between old and new > implementations, and > b) Fixes the problem completely between new implementations, and makes the > liklihood of the collision problem between old and new implementations much less > possible than with the unfixed scenario > c) just does not work > d) just does not work > > -- > > Tom Rutt email: terutt@lucent.com > Lucent Technologies Bell Labs Tel: +1(732)949-7862 > Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA > > -- > > Tom Rutt email: terutt@lucent.com > Lucent Technologies Bell Labs Tel: +1(732)949-7862 > Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Fri, 30 Jul 1999 14:55:13 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: EXPEDITED VOTE on Interop Urgent Issue (due friday July 30) To: terutt@lucent.com Cc: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, janssen@parc.xerox.com, interop@omg.org, firewall-rtf@omg.org, rip-dev@eng.sun.com X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Tom, Sun votes for option b (even/odd). I agree with Paul that c is the better choice, but given the opinion that c will have difficulty being approved, I prefer b. I would like to see bi-dir and interleaving work, since both features are key to product features we plan to develop. I also don't believe that there will be a new version of GIOP in a timely fashion. Ken. Date: Mon, 02 Aug 1999 13:37:28 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: interop@omg.org, firewall-rtf@omg.org Subject: Urgent Issue Vote Results and Wordsmithing Request Here is the vote results. The voting results are: 9 for a) 5 for b) 1 for c) 16 voting members, 15 responses means we met quorum. The majority of responding votes if for a). With regard to wordsmithing, I realized that the current wording of our voted alternative might be clarified in two directions: 1) the current wording assumes that there is a clear demarcation of when bidirectional giop is in use. If fragments are being sent while the bidirectional giop service context is sent across the connnection, what is the exact behaviour required by the fix? 2) The current fix might be refined to not allow fragmented responses to be sent by an orb which is currently sending fragmented requests. This might be more difficult to detect, but will let more fragments be interleaved safely than the more restrictive proposal of not interleaving any fragment messages with other messages. Does anyone have proposals for appropriate rewording to reflect the above two concerns? --------------- nv ApTest Stephen McNamara, stephen@aptest.ie a) BEA Systems Ed Cobb, ed.cobb@beasys.com a) DSTC Michi Henning, michi@triodia.com a) Floorboard Software Jon Biggar, jon@floorboard.com a) Fujitsu Sugino (??? email) a) Hewlett-Packard Jishnu Mukerji, jis@fpk.hp.com b) IONA Bob Kukura, kukura@iona.com b) Inprise Corporation Jeff Mischkinsky, jeffm@inprise.com a) IBM Simon Nash, nash@hursley.ibm.com b) Lucent Technologies Tom Rutt (CHAIR), terutt@lucent.com a) Nortel Dave Stringer, d.r.stringer@nortel.co.uk a) Novell Bill Cox, bill@novell.com a) OIS Bill Beckwith, bill.beckwith@ois.com b) Rogue Wave Software Paul Kyzivat, paulk@roguewave.com b) Sun Microsystems Ken Cavanaugh, ken.cavanaugh@eng.sun.com c) Xerox Bill Janssen, janssen@parc.xerox.com ---------------- a) depricate broken feature Add the following paragraph to the section on Bi-Directional GIOP: " In GIOP 1.2, if bi-directional GIOP is used on a connection, then GIOP fragments shall not be sent interleaved with other messages. " b) even/odd request Ids approach In section 15.8 (Bi-Directional GIOP), replace that begins with "Bi-directional GIOP connections modify the behavior of Request IDs" with the following new paragraph: "Bi-directional GIOP connections modify the behavior of Request IDs. In the GIOP specification, "Connection Management" on page 15-44, it is noted that "Request IDs must unambiguously associate replies with requests within the scope and lifetime of a connection". With Bi-directional GIOP this guarantee must be preserved while permitting each end to generate Request IDs for new requests. To ensure this, on a connection that is used bi-directionally, the connection originator shall assign only even valued Request IDs and the other side of the connection shall assign only odd valued Request IDs. This requirement applies to the full lifetime of the connection, even before a BiDirIIOPServiceContext is transmitted." c) reverse flow bit approach In section 15.4.1 (GIOP Message Header), replace the paragraph starting with "The most significant 6 bits are reserved" with the following: "In GIOP 1.2, the third least significant bit indicates, when TRUE(1), that the client and server roles of the connection are reversed for this message; the endpoint that initiated the connection is the server and the endpoint that accepted the connection is the client. This bit may only be set when Bi-directional GIOP is in use. In GIOP 1.1, and when Bi-directional GIOP is not in use, this bit must have the value FALSE(0)." "The most significant 5 bits are reserved. These 5 bits must have the value 0 for GIOP version 1.1 and 1.2." d) Add new Fragment message type Modify the GIOP 1.2 protocol to add new message type(s) to distinguish fragments of a request from fragments of a response. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Sender: jis@fpk.hp.com Date: Mon, 02 Aug 1999 14:38:25 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: terutt@lucent.com CC: interop@omg.org, firewall-rtf@omg.org Subject: Re: Urgent Issue Vote Results and Wordsmithing Request > With regard to wordsmithing, I realized that the current wording of our voted > alternative might be clarified in two directions: > 1) the current wording assumes that there is a clear demarcation of when > bidirectional giop is in use. If fragments are being sent while the > bidirectional giop service context is sent across the connnection, what is the > exact behaviour required by the fix? Of course there is. Bidir GIOP is used after a server receives a BiDirGIOP Service Context and then takes a specific action to use an existing connection bi-directionally instead of opening a connection to the client's IOR. All that the server has to do is not use BiDir if it is already interleaving fragments. This holds true even if an errant client which itself is interleaving fragments insists on sending a BiDirGIOP service context. So the server always has full control over whether it is using BiDir or not, irrespective of whether the connection has been used for interleaved fragments. Admittedly, this unfortunate sequence of happenstances would be inconvenient if the client were a Java Applet, but then one could convince the Java applets and servers that intend to serve Java applets to refrain from interleaving fragments, until about Feb 2000, when we will have the full blown correct fix including new message types in place adn ready for prime time. > 2) The current fix might be refined to not allow fragmented responses to be sent > by an orb which is currently sending fragmented requests. This might be more > difficult to detect, but will let more fragments be interleaved safely than the > more restrictive proposal of not interleaving any fragment messages with other > messages. I don't see this as providing sufficient return for the added complexity in specification. How about we get off of this urgent resolution and start working quickly on the real fix so that we can vote it through the RTF and get the right fix done, ready to go by November. Then we will have the opportunity to sit and argue endlessly on whether that fix should be published quickly as GIOP 1.3 without waiting for the Component spec or not. Indeed, if we could light the fire under the Firewall RTF so that they complete their modifications of GIOP by the November meeting then we could make a good case for publishing a GIOP 1.3 spec independant of the Component spec. > Does anyone have proposals for appropriate rewording to reflect the above two > concerns? (1) requires no change. (2) why bother when we should be getting the real fix using new message types figured out and put in place ASAP. Of course, we also have considerable opportunity to enter into fun and games right now by veto-ing the proposed fix and then veto-ing Andrew's sledgehammer, and then starting from the beginning.:-) That of course would be taking away more precious time and energy from getting the right fix worked out and in place ASAP. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Tue, 3 Aug 1999 14:13:17 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Paul H Kyzivat Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) CC: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, terutt@lucent.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, interop@omg.org, firewall-rtf@omg.org Excerpts from direct: 3-Aug-99 Re: FINAL VOTE on WORDSMITH.. Paul H Kyzivat@roguewave (925*) > "To avoid collisions of requestId in fragment messages when > bi-directional GIOP is in use: > - a request may not be sent if a reply has been sent without a > terminating fragment. > > - a reply may not be sent if a request has been sent without a > terminating fragment." I'd be happy to vote yes for this, but not for the earlier one, which Tom sent around the vote on. Bill Date: Tue, 3 Aug 1999 14:14:35 PDT Sender: Bill Janssen From: Bill Janssen To: terutt@lucent.com, Paul H Kyzivat Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) CC: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, janssen@parc.xerox.com, interop@omg.org, firewall-rtf@omg.org Excerpts from direct: 3-Aug-99 Re: FINAL VOTE on WORDSMITH.. Paul H Kyzivat@roguewave (49*) > RogueWave votes YES on the reworded resolution. Paul, you did note that the controlling phrase in that reworded resolution is: ``...when bi-directional GIOP is in use, interleaving of reverse direction traffic is not allowed.'' Bill Date: Tue, 03 Aug 1999 22:23:17 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en To: Paul H Kyzivat , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, terutt@lucent.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM CC: interop@omg.org, firewall-rtf@omg.org Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) IBM prefers this wording and votes Yes for it. Since Tom has ruled that this change is editorial and does not affect the technical meaning, this should (I hope) count towards quorum on the vote Tom sent out earlier. Simon Paul H Kyzivat wrote: > > Bill Janssen wrote: > > > > Well, which is it? If interleaving of reverse direction traffic is > > not > > allowed, why are these two additional statements provided? You know > > what's going to happen: some people are going to ignore the > > ``interleaving of reverse direction traffic is not allowed'', and only > > implement the two specific cases. > > Bill - of course you are right. But what you suggest people might do is > exactly what they need to do! To fix it we just need to take out some > words, as follows, so it says exactly that: > > ========= > > "To avoid collisions of requestId in fragment messages when > bi-directional GIOP is in use: > > - a request may not be sent if a reply has been sent without a > terminating fragment. > > - a reply may not be sent if a request has been sent without a > terminating fragment." > > ============= > This applies only to bidir because neither of the two situations called > out can occur if it isn't. -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jis@fpk.hp.com Date: Tue, 03 Aug 1999 17:25:21 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) To: terutt@lucent.com CC: Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, interop@omg.org, firewall-rtf@omg.org Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) So just for mi (and I am sure others) edification, what is the exact wording that I voted YES on? Thanks, Jishnu. Tom Rutt wrote: > > Sorry Bill You have a point. > > Peter Furniss just suggested that the lead in sentence be changed to > > "To avoid ... interleaving of reverse direction > traffic with forward direction traffic is not allowed" > > This I think addresses your concern and is an editorial consistency > change, keeping the "in particular" part correct. > > I hope this can change your vote and not jeopardize any existing > yes votes. > > Bill Janssen wrote: > > > > Excerpts from direct: 3-Aug-99 FINAL VOTE on WORDSMITH URG.. Tom > > Rutt@lucent.com (1310*) > > > > > " > > > To avoid collisions of requestId in fragment messages when bi-directional GIOP > > > is in use, interleaving of reverse direction traffic is not allowed. In > > > particular: > > > > > - a request may not be sent if a reply has been sent without a terminating > > > fragment. > > > > > - a reply may not be sent if a request has been sent without a terminating > > > fragment. > > > > > " > > > > Well, which is it? If interleaving of reverse direction traffic is not > > allowed, why are these two additional statements provided? You know > > what's going to happen: some people are going to ignore the > > ``interleaving of reverse direction traffic is not allowed'', and only > > implement the two specific cases. > > > > Bill > > -- > > Tom Rutt email: terutt@lucent.com > Lucent Technologies Bell Labs Tel: +1(732)949-7862 > Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 03 Aug 1999 14:32:44 -0700 To: terutt@lucent.com, stephen@aptest.ie, michi@triodia.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, terutt@lucent.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, janssen@parc.xerox.com, interop@omg.org, firewall-rtf@omg.org From: Edward Cobb Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) BEA votes yes. At 02:11 PM 8/3/99 -0400, Tom Rutt wrote: >Lucent votes yes on the reworded urgent resolution. > >Jeff Mischkinsky told me he votes yes on the reworded resolution. > >Tom Rutt wrote: >> > >> >> In the Bi-directional GIOP spec (section 15.8), add the following restriction on >> inerleaving for reverse-direction traffic: >> " >> To avoid collisions of requestId in fragment messages when bi-directional GIOP >> is in use, interleaving of reverse direction traffic is not allowed. In >> particular: >> >> - a request may not be sent if a reply has been sent without a terminating >> fragment. >> >> - a reply may not be sent if a request has been sent without a terminating >> fragment. >> >> " >> >> -- >> >> Tom Rutt email: terutt@lucent.com >> Lucent Technologies Bell Labs Tel: +1(732)949-7862 >> Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 >> Holmdel NJ, 07733 USA > >-- > >Tom Rutt email: terutt@lucent.com >Lucent Technologies Bell Labs Tel: +1(732)949-7862 >Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 >Holmdel NJ, 07733 USA > ************************************************************** Ed Cobb, Technical Director, Systems Architecture BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Tue, 03 Aug 1999 18:07:43 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: terutt@lucent.com CC: Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@eng.sun.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) After the recent exchange of messages excepted below, I am lost. I want to vote YES to the revised wording, proposed by me, that Bill agrees to vote yes to at the end of the messages below. This is (I think) slightly different than what would hold with the Peter Furniss proposal. Paul Tom Rutt wrote: > > The two "In particular" cases cover reverse traffic as a special case. > > The other way to say the In particular: is > > - a server may not send a request if a reply or another request has > been > send without a terminating fragment. > > - a client may not send a reply if a request or another reply has been > send without a terminating fragment. > > However with the qualification in the final vote before the > "In Particular" text seems to make the two equivalent as a whole. Tom Rutt wrote: > > Sorry Bill You have a point. > > Peter Furniss just suggested that the lead in sentence be changed to > > "To avoid ... interleaving of reverse direction > traffic with forward direction traffic is not allowed" > > This I think addresses your concern and is an editorial consistency > change, keeping the "in particular" part correct. Tom Rutt wrote: > > I agree this is an editorial change (needed for consistency with > what the details intented > > Paul H Kyzivat wrote: ... > > Bill - of course you are right. But what you suggest people might do > > is exactly what they need to do! To fix it we just need to take out > > some words, as follows, so it says exactly that: > > > > ========= > > > > "To avoid collisions of requestId in fragment messages when > > bi-directional GIOP is in use: > > > > - a request may not be sent if a reply has been sent without a > > terminating fragment. > > > > - a reply may not be sent if a request has been sent without a > > terminating fragment." > > > > ============= > > This applies only to bidir because neither of the two situations > > called out can occur if it isn't. Bill Janssen wrote: > > Excerpts from direct: 3-Aug-99 Re: FINAL VOTE on WORDSMITH.. Paul H > Kyzivat@roguewave (925*) > > > "To avoid collisions of requestId in fragment messages when > > bi-directional GIOP is in use: > > > - a request may not be sent if a reply has been sent without a > > terminating fragment. > > > > - a reply may not be sent if a request has been sent without a > > terminating fragment." > > I'd be happy to vote yes for this, but not for the earlier one, which > Tom sent around the vote on. Cc: Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, interop@omg.org, firewall-rtf@omg.org Date: Tue, 03 Aug 1999 18:10:38 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Jishnu Mukerji Original-CC: Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, interop@omg.org, firewall-rtf@omg.org Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) I think what we have consensus on is the following text for the urgent resolution: The following change, resulting from an urgent issue resolution procedure to avoid collisions of requestIds in fragment messages when bidirectional GIOP is in use, disallows interleaving of reverse direction traffic with forward direction traffic Add the following paragraph to 15.8: > "To avoid collisions of requestId in fragment messages when > bi-directional GIOP is in use: > - a request may not be sent if a reply has been sent without a > terminating fragment. > > - a reply may not be sent if a request has been sent without a > terminating fragment." Jishnu Mukerji wrote: > > So just for mi (and I am sure others) edification, what is the exact > wording that I voted YES on? > > Thanks, > > Jishnu. > -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Cc: Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, interop@omg.org, firewall-rtf@omg.org Date: Tue, 03 Aug 1999 18:19:27 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Paul H Kyzivat Original-CC: Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, interop@omg.org, firewall-rtf@omg.org Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) The words you proposed are now agreed. The peter furnis words were only placed in the intro to the urgent resolution, not in the replacement text. Do you object to the intro I just sent out in the last concensus declaration message I sent out just a few minutes ago? Paul H Kyzivat wrote: > > After the recent exchange of messages excepted below, I am lost. > > I want to vote YES to the revised wording, proposed by me, that Bill > agrees to vote yes to at the end of the messages below. > > This is (I think) slightly different than what would hold with the > Peter Furniss proposal. > > Paul > > > > > > "To avoid collisions of requestId in fragment messages when > > > bi-directional GIOP is in use: > > > > > - a request may not be sent if a reply has been sent without a > > > terminating fragment. > > > > > > - a reply may not be sent if a request has been sent without a > > > terminating fragment." > > > > I'd be happy to vote yes for this, but not for the earlier one, which > > Tom sent around the vote on. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Date: Tue, 3 Aug 1999 15:31:41 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) To: stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, terutt@lucent.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@eng.sun.com, janssen@parc.xerox.com, interop@omg.org, firewall-rtf@omg.org Cc: rip-dev@eng.sun.com X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sun votes YES on the reworded urgent resolution. Ken. Date: Tue, 3 Aug 1999 15:53:36 PDT Sender: Bill Janssen From: Bill Janssen To: Paul H Kyzivat , terutt@lucent.com Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) CC: Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, interop@omg.org, firewall-rtf@omg.org Excerpts from direct: 3-Aug-99 Re: FINAL VOTE on WORDSMITH.. Paul H Kyzivat@roguewave (2482*) > "To avoid collisions of requestId in fragment messages when > bi-directional GIOP is in use: > - a request may not be sent if a reply has been sent without a > terminating fragment. > - a reply may not be sent if a request has been sent without a > terminating fragment." Sure, I'll vote yes on this. I would feel even better if it said ``one endpoint may not send a request if that endpoint has sent a reply without...'', to avoid confusion between the two endpoints. Bill Date: Tue, 03 Aug 1999 19:04:16 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: terutt@lucent.com CC: Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@eng.sun.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) Tom Rutt wrote: > > The words you proposed are now agreed. > > The peter furnis words were only placed in the intro to the > urgent resolution, not in the replacement text. > > Do you object to the intro I just sent out in the last concensus > declaration message I sent out just a few minutes ago? After re-reading the messages several times, I am pretty sure that the furnis words actually do fall into the replacement text. But I have also convinced myself that they don't alter the meaning. So I am satisfied. Date: Tue, 03 Aug 1999 19:09:47 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: terutt@lucent.com, Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jis@fpk.hp.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@eng.sun.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) Paul H Kyzivat wrote: > > Tom Rutt wrote: > > > > The words you proposed are now agreed. > > > > The peter furnis words were only placed in the intro to the > > urgent resolution, not in the replacement text. > > > > Do you object to the intro I just sent out in the last concensus > > declaration message I sent out just a few minutes ago? > > After re-reading the messages several times, I am pretty sure that the > furnis words actually do fall into the replacement text. But I have > also > convinced myself that they don't alter the meaning. > > So I am satisfied. Oops! After sending the above, I received the concensus message referenced by Tom - one I hadn't seen before. So now the Furnis words aren't in the replacement text. But that is OK too. From: Jeffrey Mischkinsky Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) To: terutt@lucent.com Date: Tue, 3 Aug 1999 17:04:33 -0700 (PDT) Cc: janssen@parc.xerox.com, stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@eng.sun.com, interop@omg.org, firewall-rtf@omg.org, jis@fpk.hp.com X-Mailer: ELM [version 2.4 PL25] Inprise votes YES (on any all of the proposals, provided of course that only the correct one passes, I think that's a polite way of saying Tom, do the right thing!:-) jeff 'Tom Rutt' writes: > > I think what we have consensus on is the following text for the > urgent resolution: > > > The following change, resulting from an urgent issue resolution > procedure to avoid collisions of requestIds in fragment messages when > bidirectional GIOP is in use, disallows interleaving of reverse > direction traffic with forward direction traffic > > Add the following paragraph to 15.8: > > > > "To avoid collisions of requestId in fragment messages when > > bi-directional GIOP is in use: > > > - a request may not be sent if a reply has been sent without a > > terminating fragment. > > > > - a reply may not be sent if a request has been sent without a > > terminating fragment." > > > > Jishnu Mukerji wrote: > > > > So just for mi (and I am sure others) edification, what is the exact > > wording that I voted YES on? > > > > Thanks, > > > > Jishnu. > > > > -- > > Tom Rutt email: terutt@lucent.com > Lucent Technologies Bell Labs Tel: +1(732)949-7862 > Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 X-My-Real-Login-Name: sugino; 10.35.109.43 X-Mailer: Denshin 8 Go V321.1b7 Date: Wed, 04 Aug 1999 09:46:24 +0900 From: Yasuaki Sugino To: terutt@lucent.com Cc: Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, kukura@iona.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@Eng.Sun.COM, interop@omg.org, firewall-rtf@omg.org Subject: Re^2: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) Fujitsu votes YES on the following reworded urgent resolution. ----- Best Regards Yasuaki SUGINO FUJITSU LIMITED terutt@lucent.com wrote Tue, 03 Aug 1999 18:10:38 -0400 Subject: "Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today)" Tom> I think what we have consensus on is the following text for the Tom> urgent resolution: Tom> Tom> Tom> The following change, resulting from an urgent issue resolution Tom> procedure to avoid collisions of requestIds in fragment messages when Tom> bidirectional GIOP is in use, disallows interleaving of reverse Tom> direction traffic with forward direction traffic Tom> Tom> Add the following paragraph to 15.8: Tom> Tom> Tom> > "To avoid collisions of requestId in fragment messages when Tom> > bi-directional GIOP is in use: Tom> Tom> > - a request may not be sent if a reply has been sent without a Tom> > terminating fragment. Tom> > Tom> > - a reply may not be sent if a request has been sent without a Tom> > terminating fragment." Tom> Tom> Tom> Tom> Jishnu Mukerji wrote: Tom> > Tom> > So just for mi (and I am sure others) edification, what is the exact Tom> > wording that I voted YES on? Tom> > Tom> > Thanks, Tom> > Tom> > Jishnu. Tom> > Tom> Tom> -- Tom> Tom> Tom Rutt email: terutt@lucent.com Tom> Lucent Technologies Bell Labs Tel: +1(732)949-7862 Tom> Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Tom> Holmdel NJ, 07733 USA Tom> Date: Tue, 03 Aug 1999 22:06:13 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en To: terutt@lucent.com CC: Jishnu Mukerji , Bill Janssen , stephen@aptest.ie, michi@triodia.com, ed.cobb@beasys.com, jon@floorboard.com, jeffm@inprise.com, nash@hursley.ibm.com, d.r.stringer@nortel.co.uk, bill@novell.com, bill.beckwith@ois.com, paujlk@roguewave.com, ken.cavanaugh@eng.sun.com, interop@omg.org, firewall-rtf@omg.org Subject: Re: FINAL VOTE on WORDSMITH URGENT RESOLUTION (due today) I took a day of vacation today, just checked my email, and saw I missed all kinds of fun. I haven't yet convinced myself that the proposed text is implementable or solves the problem, but it does seem better than the default resolution, so IONA votes yes (if its not too late). -Bob Tom Rutt wrote: > > I think what we have consensus on is the following text for the > urgent resolution: > > The following change, resulting from an urgent issue resolution > procedure to avoid collisions of requestIds in fragment messages when > bidirectional GIOP is in use, disallows interleaving of reverse > direction traffic with forward direction traffic > > Add the following paragraph to 15.8: > > > "To avoid collisions of requestId in fragment messages when > > bi-directional GIOP is in use: > > > - a request may not be sent if a reply has been sent without a > > terminating fragment. > > > > - a reply may not be sent if a request has been sent without a > > terminating fragment." > > Jishnu Mukerji wrote: > > > > So just for mi (and I am sure others) edification, what is the exact > > wording that I voted YES on? > > > > Thanks, > > > > Jishnu. > > > > -- > > Tom Rutt email: terutt@lucent.com > Lucent Technologies Bell Labs Tel: +1(732)949-7862 > Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA Date: Tue, 03 Aug 1999 22:33:18 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: andrew@omg.org, interop@omg.org, firewall-rtf@omg.org Subject: Final Report on Urgent Issue 2801 resolution Andrew, Thanks to the fine efforts of each of the Interop RTF members, we have a resolution to urgent issue 2801. The interop RTF has voted positively on the following text for the Urgent Resolution 2801, which you Assigned to us. The following change, resulting from an urgent issue resolution procedure to avoid collisions of requestIds in fragment messages when bidirectional GIOP is in use, disallows interleaving of reverse direction traffic with forward direction traffic Add the following paragraph to 15.8: "To avoid collisions of requestId in fragment messages when bi-directional GIOP is in use: - a request may not be sent by an endpoint if a reply has been sent by that endpoint without a terminating fragment. - a reply may not be sent by an endpoint if a request has been sent by that endpoint without a terminating fragment." --------------------------- Vote 2 results The voting results are: 11 yes 5 No response We met quorum and had unanamous consent to the final wording above. The Xerox request to make the statement totally precise by including "by an endpoint" in the text was acted upon by the chairman and included in the final output text, since it is purely editorial. Fujitsu y Lucent y Inprise y RogueWave y HP y floorboard y Xerox y accepted editorial of including "by an endpoint" BEA y IBM y SUN y IONA y ------------------------------- Vote 1 results. The voting results are: 9 for a) 5 for b) 1 for c) 16 voting members, 15 responses means we met quorum. The majority of responding votes if for a). With regard to wordsmithing, the current wording of our vote 1 alternative might be clarified by a Vote 2 in two directions: 1) the current wording assumes that there is a clear demarcation of when bidirectional giop is in use. If fragments are being sent while the bidirectional giop service context is sent across the connnection, what is the exact behaviour required by the fix? 2) The current fix might be refined to not allow fragmented responses to be sent by an orb which is currently sending fragmented requests. This might be more difficult to detect, but will let more fragments be interleaved safely than the more restrictive proposal of not interleaving any fragment messages with other messages. Does anyone have proposals for appropriate rewording to reflect the above two concerns? --------------- nv ApTest Stephen McNamara, stephen@aptest.ie a) BEA Systems Ed Cobb, ed.cobb@beasys.com a) DSTC Michi Henning, michi@triodia.com a) Floorboard Software Jon Biggar, jon@floorboard.com a) Fujitsu Sugino (??? email) a) Hewlett-Packard Jishnu Mukerji, jis@fpk.hp.com b) IONA Bob Kukura, kukura@iona.com b) Inprise Corporation Jeff Mischkinsky, jeffm@inprise.com a) IBM Simon Nash, nash@hursley.ibm.com b) Lucent Technologies Tom Rutt (CHAIR), terutt@lucent.com a) Nortel Dave Stringer, d.r.stringer@nortel.co.uk a) Novell Bill Cox, bill@novell.com a) OIS Bill Beckwith, bill.beckwith@ois.com b) Rogue Wave Software Paul Kyzivat, paulk@roguewave.com b) Sun Microsystems Ken Cavanaugh, ken.cavanaugh@eng.sun.com c) Xerox Bill Janssen, janssen@parc.xerox.com ---------------- Vote 1 text: a) depricate broken feature Add the following paragraph to the section on Bi-Directional GIOP: " In GIOP 1.2, if bi-directional GIOP is used on a connection, then GIOP fragments shall not be sent interleaved with other messages. " b) even/odd request Ids approach In section 15.8 (Bi-Directional GIOP), replace that begins with "Bi-directional GIOP connections modify the behavior of Request IDs" with the following new paragraph: "Bi-directional GIOP connections modify the behavior of Request IDs. In the GIOP specification, "Connection Management" on page 15-44, it is noted that "Request IDs must unambiguously associate replies with requests within the scope and lifetime of a connection". With Bi-directional GIOP this guarantee must be preserved while permitting each end to generate Request IDs for new requests. To ensure this, on a connection that is used bi-directionally, the connection originator shall assign only even valued Request IDs and the other side of the connection shall assign only odd valued Request IDs. This requirement applies to the full lifetime of the connection, even before a BiDirIIOPServiceContext is transmitted." c) reverse flow bit approach In section 15.4.1 (GIOP Message Header), replace the paragraph starting with "The most significant 6 bits are reserved" with the following: "In GIOP 1.2, the third least significant bit indicates, when TRUE(1), that the client and server roles of the connection are reversed for this message; the endpoint that initiated the connection is the server and the endpoint that accepted the connection is the client. This bit may only be set when Bi-directional GIOP is in use. In GIOP 1.1, and when Bi-directional GIOP is not in use, this bit must have the value FALSE(0)." "The most significant 5 bits are reserved. These 5 bits must have the value 0 for GIOP version 1.1 and 1.2." d) Add new Fragment message type Modify the GIOP 1.2 protocol to add new message type(s) to distinguish fragments of a request from fragments of a response. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA From: "Martin Chapman" To: , , , Subject: RE: Final Report on Urgent Issue 2801 resolution Date: Thu, 5 Aug 1999 11:42:06 +0100 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal I hope you realise what bad words you have all agreed on:-) > Add the following paragraph to 15.8: > > "To avoid collisions of requestId in fragment messages when > bi-directional GIOP is in use: > > - a request may not be sent by an endpoint if a reply has been > sent by that > endpoint without a terminating fragment. > > - a reply may not be sent by an endpoint if a request has been > sent by that > endpoint without a terminating fragment." > Why is a plain (non-fragmented) request/reply prohibited here? There has never been and feature interaction between fragmented request/replies and non-fragmented ones, so why have this restriction. Martin. From: "Martin Chapman" To: "Peter Furniss" , "'Tom Rutt'" Cc: , , Subject: RE: Final Report on Urgent Issue 2801 resolution Date: Fri, 6 Aug 1999 10:18:58 +0100 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal Peter hits the nail on the head. The thing that really bugs me about this is that we have taken something that is broken and fixed it (which is good) but at the same time outlawed something that works, was legal, and which invalidates our implmentation. Andrew, is there any power of veto here or a sensible way to get the wording below agreed to ? (i can't look at the p&p since the omg server is down !) Martin. > -----Original Message----- > From: Peter Furniss [mailto:p.furniss@mailbox.ulcc.ac.uk] > Sent: 05 August 1999 23:57 > To: Martin Chapman; 'Tom Rutt' > Cc: andrew@omg.org; interop@omg.org; firewall-rtf@omg.org > Subject: RE: Final Report on Urgent Issue 2801 resolution > > > Tom Rutt sent, in reply to Martin : > > > If bidirectional giop is not in use, an endpoint will never > > send both requests and responses. > > But that's wasn't the point - the agreed text unecessarily > disallows sending of a non-fragmented request in between > fragments of a response, (and vice versa) - which can indeed only > occur in bi-directional operation. However, there is no possible > ambiguity for the receiver that is re-assembling the fragments, > since it won't add a new complete message to the incomplete one, > even if the request id is the same. The problem is only with > fragments, which are distinguished only by their request id and > don't say what they are part of. The addition of the word > "fragmented" twice in the bullets would have allowed complete > requests in the middle of an incomplete response (and vice > versa), i.e. making the first bullet: > > - a fragmented request may not be sent by an endpoint if a > fragmented reply has been > sent by that endpoint without a terminating fragment > > and equivalently for the other bullet. I would think the ability > to interleave an exchange of short messages in the middle of some > large one could be quite useful. > > > But presumably this is water under the bridge (though I did > mention it in the message to Tom during the ballot (I didn't want > to disturb the ballot, since Open-IT doesn't have a vote). > > > Has the question of whether request ids will always be chosen by > both ends from the identical number space also been resolved for > all time ? I really believe this was the real bug - the fragment > business just showed it up, but I believe there's a good chance > it will turn up again in some future feature, risking another > kludge to get round it. Can 1.3+ declare that odd/even or > high/low applies ? (one might want to distinguish the message > (fragments) better *as well*, but it can't be right to multiplex > with colliding "connection" numbers, which is essentially what is > happening here). > > > Martin Chapman wrote: > > > > > > I hope you realise what bad words you have all agreed on:-) > > > > > > > > > > Add the following paragraph to 15.8: > > > > > > > > "To avoid collisions of requestId in fragment messages when > > > > bi-directional GIOP is in use: > > > > > > > > - a request may not be sent by an endpoint if a reply has been > > > > sent by that > > > > endpoint without a terminating fragment. > > > > > > > > - a reply may not be sent by an endpoint if a request has been > > > > sent by that > > > > endpoint without a terminating fragment." > > > > > > > > > > Why is a plain (non-fragmented) request/reply prohibited > here? There has > > > never been and feature interaction between fragmented > request/replies and > > > non-fragmented ones, so why have this restriction. > > > Peter Furniss > > -------------------------------------- > Associate > Open-IT Limited > 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK > Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) > Email : P.Furniss@mailbox.ulcc.ac.uk > > > Date: Fri, 06 Aug 1999 08:54:12 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Martin Chapman CC: Peter Furniss , "'Tom Rutt'" , andrew@omg.org, interop@omg.org, firewall-rtf@omg.org Subject: Re: Final Report on Urgent Issue 2801 resolution Martin Chapman wrote: > > Peter hits the nail on the head. > The thing that really bugs me about this is that we have taken > something that is broken and fixed it (which is good) but at the > same time outlawed something that works, was legal, and which > invalidates our implmentation. Andrew, is there any power of veto > here or a sensible way to get the wording below agreed to ? > (i can't look at the p&p since the omg server is down !) So Martin, where were you with this problem when the proposals and voting were going on? :-) I agree that the resolution is unnecessarily restrictive. The final wording was mine, so I accept the blame. It was my quick attempt to fix a proposal that was not my preference but was going to win anyway. I have no objection to relaxing the restriction in the manner you suggest if someone can suitably fix the wording *and* find procedural grounds for making the change, *and* do it right away. Fundamentally, all of the candidate resolutions have to do with giving the receiver a way to decide if the request_id in a fragment was assigned by this endpoint or the other endpoint. Resolution (a) and variants all work by allowing the receiver to make the decision based on what other messages have been seen recently. One algorithm for this (maybe the only algorithm) is: - Associate a piece of state with each connection - fragment_type. - Each time a (Locate)RequestMessage is received that is incomplete (will have following fragments), set fragment_type to OTHER_END. - Each time a (Locate)ReplyMessage is received that is incomplete (will have following fragments), set fragment_type to THIS_END. - Each time a Fragment Message is received, use the value of fragment_type to decide which end assigned its request_id This algorithm will work with or without Martin's changes. From: "Martin Chapman" To: "Paul H Kyzivat" Cc: "Peter Furniss" , "'Tom Rutt'" , , , Subject: RE: Final Report on Urgent Issue 2801 resolution Date: Fri, 6 Aug 1999 14:06:06 +0100 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal Paul, If you look at the timings on the email, the final proposed wording was only sent out at 19:15 Irish time, followed by a flurry of mails till the we hours. Hence this side of the atlantic was in the pub, and we only saw the resolution wednesday morning, by which time it was too late. We really must get an internet connection in the IONA dublin local:-) Martin. > -----Original Message----- > From: Paul H Kyzivat [mailto:paulk@roguewave.com] > Sent: 06 August 1999 13:54 > To: Martin Chapman > Cc: Peter Furniss; 'Tom Rutt'; andrew@omg.org; interop@omg.org; > firewall-rtf@omg.org > Subject: Re: Final Report on Urgent Issue 2801 resolution > > > Martin Chapman wrote: > > > > Peter hits the nail on the head. > > The thing that really bugs me about this is that we have taken > > something that is broken and fixed it (which is good) but at the > > same time outlawed something that works, was legal, and which > > invalidates our implmentation. Andrew, is there any power of veto > > here or a sensible way to get the wording below agreed to ? > > (i can't look at the p&p since the omg server is down !) > > So Martin, where were you with this problem when the proposals and > voting were going on? :-) > > I agree that the resolution is unnecessarily restrictive. The final > wording was mine, so I accept the blame. It was my quick attempt to fix > a proposal that was not my preference but was going to win anyway. > > I have no objection to relaxing the restriction in the manner you > suggest if someone can suitably fix the wording *and* find procedural > grounds for making the change, *and* do it right away. > > Fundamentally, all of the candidate resolutions have to do with giving > the receiver a way to decide if the request_id in a fragment was > assigned by this endpoint or the other endpoint. Resolution (a) and > variants all work by allowing the receiver to make the decision based on > what other messages have been seen recently. One algorithm for this > (maybe the only algorithm) is: > > - Associate a piece of state with each connection - fragment_type. > > - Each time a (Locate)RequestMessage is received that is incomplete > (will have following fragments), set fragment_type to OTHER_END. > > - Each time a (Locate)ReplyMessage is received that is incomplete (will > have following fragments), set fragment_type to THIS_END. > > - Each time a Fragment Message is received, use the value of > fragment_type to decide which end assigned its request_id > > This algorithm will work with or without Martin's changes. > From: Jeffrey Mischkinsky Subject: Re: Final Report on Urgent Issue 2801 resolution To: mchapman@iona.com (Martin Chapman) Date: Fri, 6 Aug 1999 08:01:41 -0700 (PDT) Cc: p.furniss@mailbox.ulcc.ac.uk, terutt@lucent.com, andrew@omg.org, interop@omg.org, firewall-rtf@omg.org X-Mailer: ELM [version 2.4 PL25] 'Martin Chapman' writes: > > Peter hits the nail on the head. > The thing that really bugs me about this is that we have taken something > that is broken and fixed it (which is good) but at the same time outlawed > something that works, was legal, and which invalidates our implmentation. > Andrew, is there any power of veto here or a sensible way to get the wording > below agreed to ? > (i can't look at the p&p since the omg server is down !) My last parting shot, before i conveniently leave for vacation and don't get to read email for a few days. :-) Since this "fix" is a change to the firewall submission, according to at least one set of rules, submitters have a veto on ANY changes for 18 months. In order to uphold the commercial availability reqs, this HAS to apply regardless of how the issue gets brought up. Once again, this points the utter ridiculousness of invoking an "urgent" interpretation process for an issue on a spec which is in an FTF state. There is no way I for one, ever intended that the urgent process could be invoked upon something that was in FTF. This of course begs the question, once again, of the issue of taking something that was in an FTF state and putting into something that is supposed to be stable. However we already did that. And are all collectively "guilty" i suppose. I suggest that we back off from the procedural morass, and adopt a real solution that solves the problem and which does as little damage as possible to giop 1.2. My biased view of course is that we reconsider adopting the odd/even "solution" which as far as i could tell from the discussion, did actually solve the problem, but wasn't felt to be the cleanest solution. (why i'm not sure, since from i think any deterministic way of dividing up the request id space fits the bill, and that way seems to be easy to implement). In any event, we will in all liklihood we modify our implementation, before we get out of beta, to do even/odd and also start allocating the req ids (in the reverse direction) with a "big" number. jeff > > Martin. > > > -----Original Message----- > > From: Peter Furniss [mailto:p.furniss@mailbox.ulcc.ac.uk] > > Sent: 05 August 1999 23:57 > > To: Martin Chapman; 'Tom Rutt' > > Cc: andrew@omg.org; interop@omg.org; firewall-rtf@omg.org > > Subject: RE: Final Report on Urgent Issue 2801 resolution > > > > > > Tom Rutt sent, in reply to Martin : > > > > > If bidirectional giop is not in use, an endpoint will never > > > send both requests and responses. > > > > But that's wasn't the point - the agreed text unecessarily > > disallows sending of a non-fragmented request in between > > fragments of a response, (and vice versa) - which can indeed only > > occur in bi-directional operation. However, there is no possible > > ambiguity for the receiver that is re-assembling the fragments, > > since it won't add a new complete message to the incomplete one, > > even if the request id is the same. The problem is only with > > fragments, which are distinguished only by their request id and > > don't say what they are part of. The addition of the word > > "fragmented" twice in the bullets would have allowed complete > > requests in the middle of an incomplete response (and vice > > versa), i.e. making the first bullet: > > > > - a fragmented request may not be sent by an endpoint if a > > fragmented reply has been > > sent by that endpoint without a terminating fragment > > > > and equivalently for the other bullet. I would think the ability > > to interleave an exchange of short messages in the middle of some > > large one could be quite useful. > > > > > > But presumably this is water under the bridge (though I did > > mention it in the message to Tom during the ballot (I didn't want > > to disturb the ballot, since Open-IT doesn't have a vote). > > > > > > Has the question of whether request ids will always be chosen by > > both ends from the identical number space also been resolved for > > all time ? I really believe this was the real bug - the fragment > > business just showed it up, but I believe there's a good chance > > it will turn up again in some future feature, risking another > > kludge to get round it. Can 1.3+ declare that odd/even or > > high/low applies ? (one might want to distinguish the message > > (fragments) better *as well*, but it can't be right to multiplex > > with colliding "connection" numbers, which is essentially what is > > happening here). > > > > > Martin Chapman wrote: > > > > > > > > I hope you realise what bad words you have all agreed on:-) > > > > > > > > > > > > > Add the following paragraph to 15.8: > > > > > > > > > > "To avoid collisions of requestId in fragment messages when > > > > > bi-directional GIOP is in use: > > > > > > > > > > - a request may not be sent by an endpoint if a reply has been > > > > > sent by that > > > > > endpoint without a terminating fragment. > > > > > > > > > > - a reply may not be sent by an endpoint if a request has been > > > > > sent by that > > > > > endpoint without a terminating fragment." > > > > > > > > > > > > > Why is a plain (non-fragmented) request/reply prohibited > > here? There has > > > > never been and feature interaction between fragmented > > request/replies and > > > > non-fragmented ones, so why have this restriction. > > > > > > Peter Furniss > > > > -------------------------------------- > > Associate > > Open-IT Limited > > 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK > > Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) > > Email : P.Furniss@mailbox.ulcc.ac.uk > > > > > > > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 X-Sender: andrew@emerald.omg.org Date: Fri, 6 Aug 1999 11:41:46 -0400 To: "Martin Chapman" From: Andrew Watson Subject: RE: Final Report on Urgent Issue 2801 resolution Cc: , Martin, You wrote: > Peter hits the nail on the head. > The thing that really bugs me about this is that we have taken something > that is broken and fixed it (which is good) but at the same time outlawed > something that works, was legal, and which invalidates our implmentation. > Andrew, is there any power of veto here or a sensible way to get the wording > below agreed to ? > (i can't look at the p&p since the omg server is down !) Unfortunately, I don't think there is. The Urgent Issue section (appended below) specifically says that this issue cannot be revisited by this RTF. Although it uses the "should" word rather than the "shall" word, I think the rationale makes it clear that once the resolution has passed, it cannot be revisited. As for a veto - well, the point is moot, since you can't retrospectively veto a poll after the voting deadline. Although this resolution applies to GIOP 1.2, the P&P wording also seems to preclude introducing a different (better?) resolution of the problem in the RTF's final report, for incorporation into GIOP 1.3. It looks to me as though the next time this issue can legally be visited is in the next Interop RTF. Cheers, Andrew 4.4.1.5 Urgent Issues In response to urgent requests for clarifications to a specification ("Urgent Issues"), the OMG shall provide clarifications of specific issues. [Issues may arise that require interpretation or clarification of a specification in a very short period of time. For example, there may be disputes over interpretation during the course of conformance testing in the context of a branding program, or urgent clarifications required by a vendor during product implementation. Resolution needs to occur within a very short period of time (approximately 2 weeks), and should result in modifications on a point-by-point basis.] Urgent Issues shall be directed to the OMG Technical Director (or his appointee), who will determine whether the issue is appropriate for urgent resolution, and if so direct it to the appropriate F/RTF. If no appropriate F/RTF is currently active, the Architecture Board will be responsible for resolving the issue. The Technical Director (or his appointee) will propose specific wording for the clarification to the committee (either the RTF or AB). The committee is then at liberty to vote on the proposed clarification or to propose other clarifications. The issue is deemed closed when a particular clarification has been accepted by a poll of the F/RTF members. If a period of two weeks has passed from the receipt of the issue by the Technical Director and no clarification has been accepted, the Technical Director (or his appointee) will determine an appropriate clarification. [A clarification (in the sense used here) typically eliminates an ambiguity by narrowing the possible interpretations of a specification when there are multiple, incompatible interpretations. In cases where a specification is not logically consistent, a clarification may also render a part of a specification void or add new content, only inasmuch as it is necessary to make the specification consistent. This process must never be used to extend a specification's functionality. The deployment of the Architecture Board in this role is intended as a backstop, a last resort in case an appropriate F/RTF is not active. The Architecture Board should by no means become the "normal" vehicle for resolving issues of this nature. It is the responsibility and duty of the Technology Committees to charter F/RTFs for Adopted and Available Specifications and maintain their readiness to respond as needed. It will most likely be the case that committee discussions and polls on urgent issues will be conducted electronically. OMG staff will maintain appropriate email and document exchange mechanisms to facilitate this process.] Resolutions of Urgent Issues will be formulated and maintained as isolated revisions to the specification, identified by sequential natural numbers and made publicly available. Any clarifications produced by this process shall be incorporated into the final recommendation produced by the F/RTF. Should there not be an appropriate F/RTF, or if the F/RTF does not produce a recommendation before its delivery deadline, any clarifications produced in this manner will automatically and collectively constitute a recommendation of revision. Once a clarification has been accepted, it should not be revisited by the F/RTF during the current revision cycle. [The prohibition against revisiting a clarification is not intended to shackle the F/RTF, but to give clarifications generated by this process some stability. The requirements of branding programs are the primary motivation for this process. An Urgent Issue that alters a branding test suite may affect the implementation of shipping, branded software products, requiring one or more vendors to alter their products to conform to the specification as clarified. It is reasonable for vendors to expect that the clarification will not be arbitrarily reversed simply because the balance of opinion in an F/RTF shifts for some reason (e.g., a change in membership) before its final revision proposal is recommended to the parent Technology Committee. The need for stability is balanced against the need for TC approval. It is possible for the TC to reject the recommendation of an TF (and thus, a set of clarifications), but our assumption is that the TC understands the consequences of such a decision and would only do so under extraordinary circumstances. As an example: If a specification's current revision is numbered 2.1, clarifications will be identified separately, such as "clarification 1 of revision 2.1", and so on. When an F/RTF produces its revision recommendation (either explicitly or by default), the clarifications will be folded into the overall revision, resulting in revision 2.2. If the F/RTF fails to produce a recommendation, OMG staff will collect clarifications into a revision recommendation. ] X-Sender: andrew@emerald.omg.org Date: Fri, 6 Aug 1999 20:34:35 -0400 To: Jeffrey Mischkinsky From: Andrew Watson Subject: Re: Final Report on Urgent Issue 2801 resolution Cc: interop@omg.org, firewall-rtf@omg.org Jeff, You wrote: > My last parting shot, before i conveniently leave for vacation and don't get > to read email for a few days. :-) Holidays without email - yes, I think I do dimly remember them .... :-) > Since this "fix" is a change to the firewall submission, according to at > least one set of rules, submitters have a veto on ANY changes for 18 months. > In order to uphold the commercial availability reqs, this HAS to apply > regardless of how the issue gets brought up. > Once again, this points the utter ridiculousness of invoking an "urgent" > interpretation process for an issue on a spec which is in an FTF state. > There is no way I for one, ever intended that the urgent process could be > invoked upon something that was in FTF. I'd completely agree with the sentiments on FTFs - they are are indeed intended to deal with exactly this situation in the specification they're working on, and it would be a bad idea to use the Urgent process on an issue in a spec subject to an FTF. However, this isn't in a spec belonging to an FTF. Instead, it's in a published, formal spec - which is why it needed attention, irrespective of how it got there. > This of course begs the question, once again, of the issue of taking > something that was in an FTF state and putting into something that is > supposed to be stable. However we already did that. And are all collectively > "guilty" i suppose. Agreed. > I suggest that we back off from the procedural morass, and adopt a real > solution that solves the problem and which does as little damage as possible > to giop 1.2. Agreed again. Of course, there were three weeks available to do that, but somehow it didn't seem to happen. The rules now expressly forbid the RTF from coming back and having another go, but if the entire RTF now agrees that its converged on a broken solution, we might be able to find a way round that (Good Grief, what am I saying?). Cheers, Andrew Sender: jon@floorboard.com Date: Fri, 06 Aug 1999 18:55:35 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en To: Andrew Watson CC: Jeffrey Mischkinsky , interop@omg.org, firewall-rtf@omg.org Subject: Re: Final Report on Urgent Issue 2801 resolution Andrew Watson wrote: > The rules now expressly forbid the RTF from coming back and having another > go, but if the entire RTF now agrees that its converged on a broken > solution, we might be able to find a way round that (Good Grief, what am I > saying?). I don't think that anyone is saying that the intent of the solution is broken, just that we hurried the wordsmithing along too fast and got something we didn't intend because we ran out of time to get it just right. This will generally happen with a hard deadline, but in this case it was worse, since there were 3 or 4 competing solutions almost right up until the end, which left little time for everyone to reality check the final solution. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Sun, 08 Aug 1999 16:26:22 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en To: Andrew Watson CC: Martin Chapman , interop@omg.org, firewall-rtf@omg.org Subject: Re: Final Report on Urgent Issue 2801 resolution Andrew, Andrew Watson wrote: > > Martin, > > You wrote: > > > Peter hits the nail on the head. > > The thing that really bugs me about this is that we have taken something > > that is broken and fixed it (which is good) but at the same time outlawed > > something that works, was legal, and which invalidates our implmentation. > > Andrew, is there any power of veto here or a sensible way to get the wording > > below agreed to ? > > (i can't look at the p&p since the omg server is down !) > > Unfortunately, I don't think there is. > > The Urgent Issue section (appended below) specifically says that this issue > cannot be revisited by this RTF. Although it uses the "should" word rather > than the "shall" word, I think the rationale makes it clear that once the > resolution has passed, it cannot be revisited. > > As for a veto - well, the point is moot, since you can't retrospectively > veto a poll after the voting deadline. > > Although this resolution applies to GIOP 1.2, the P&P wording also seems to > preclude introducing a different (better?) resolution of the problem in the > RTF's final report, for incorporation into GIOP 1.3. It looks to me as > though the next time this issue can legally be visited is in the next > Interop RTF. > I don't agree wuth this interpretation. This clarification applied to GIOP 1.2. Certain solutions (including the one favored by my company) were effectively excluded on the grounds that GIOP 1.2 was already published. Therefore, I believe the P&P words mean that the RTF cannot subsequently adopt a different solution for GIOP 1.2. I don't think they stop the RTF adopting changes for GIOP 1.3 that improve on the 1.2 solution. Simon > Cheers, > > Andrew > > 4.4.1.5 Urgent Issues > > In response to urgent requests for clarifications to a specification > ("Urgent Issues"), the OMG shall provide clarifications of specific > issues. > > [Issues may arise that require interpretation or clarification of a > specification in a very short period of time. For example, there may be > disputes over interpretation during the course of conformance testing in > the context of a branding program, or urgent clarifications required by a > vendor during product implementation. Resolution needs to occur within a > very short period of time (approximately 2 weeks), and should result in > modifications on a point-by-point basis.] > > Urgent Issues shall be directed to the OMG Technical Director (or his > appointee), who will determine whether the issue is appropriate for urgent > resolution, and if so direct it to the appropriate F/RTF. If no > appropriate F/RTF is currently active, the Architecture Board will be > responsible for resolving the issue. The Technical Director (or his > appointee) will propose specific wording for the clarification to the > committee (either the RTF or AB). The committee is then at liberty to vote > on the proposed clarification or to propose other clarifications. The > issue is deemed closed when a particular clarification has been accepted > by a poll of the F/RTF members. If a period of two weeks has passed from > the receipt of the issue by the Technical Director and no clarification > has been accepted, the Technical Director (or his appointee) will > determine an appropriate clarification. > > [A clarification (in the sense used here) typically eliminates an > ambiguity by narrowing the possible interpretations of a specification > when there are multiple, incompatible interpretations. In cases where a > specification is not logically consistent, a clarification may also render > a part of a specification void or add new content, only inasmuch as it is > necessary to make the specification consistent. This process must never be > used to extend a specification's functionality. > > The deployment of the Architecture Board in this role is intended as a > backstop, a last resort in case an appropriate F/RTF is not active. The > Architecture Board should by no means become the "normal" vehicle for > resolving issues of this nature. It is the responsibility and duty of the > Technology Committees to charter F/RTFs for Adopted and Available > Specifications and maintain their readiness to respond as needed. > > It will most likely be the case that committee discussions and polls on > urgent issues will be conducted electronically. OMG staff will maintain > appropriate email and document exchange mechanisms to facilitate this > process.] > > Resolutions of Urgent Issues will be formulated and maintained as isolated > revisions to the specification, identified by sequential natural numbers > and made publicly available. Any clarifications produced by this process > shall be incorporated into the final recommendation produced by the F/RTF. > Should there not be an appropriate F/RTF, or if the F/RTF does not produce > a recommendation before its delivery deadline, any clarifications produced > in this manner will automatically and collectively constitute a > recommendation of revision. Once a clarification has been accepted, it > should not be revisited by the F/RTF during the current revision cycle. > > [The prohibition against revisiting a clarification is not intended to > shackle the F/RTF, but to give clarifications generated by this process > some stability. The requirements of branding programs are the primary > motivation for this process. An Urgent Issue that alters a branding test > suite may affect the implementation of shipping, branded software > products, requiring one or more vendors to alter their products to conform > to the specification as clarified. It is reasonable for vendors to expect > that the clarification will not be arbitrarily reversed simply because the > balance of opinion in an F/RTF shifts for some reason (e.g., a change in > membership) before its final revision proposal is recommended to the > parent Technology Committee. The need for stability is balanced against > the need for TC approval. It is possible for the TC to reject the > recommendation of an TF (and thus, a set of clarifications), but our > assumption is that the TC understands the consequences of such a decision > and would only do so under extraordinary circumstances. > > As an example: If a specification's current revision is numbered 2.1, > clarifications will be identified separately, such as "clarification 1 of > revision 2.1", and so on. When an F/RTF produces its revision > recommendation (either explicitly or by default), the clarifications will > be folded into the overall revision, resulting in revision 2.2. If the > F/RTF fails to produce a recommendation, OMG staff will collect > clarifications into a revision recommendation. ] -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: "Martin Chapman" To: "Andrew Watson" Cc: , Subject: RE: Final Report on Urgent Issue 2801 resolution Date: Mon, 9 Aug 1999 11:24:21 +0100 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal Andrew, Here's the dilema. While resolving an urgent issue a new issue was created i.e. that you cannot send an unfragmented request/reply when there is an outstanding framgmeneted request/reply. This behaviour has and is perfectly valid, but has just been outlawed due to the hasty nature of the wording. The intention of the urgent resolution process for barnding makes it sensible not to revist the same issue (otherwise there will be no stable product standard), but in this case I think it is valid to see this as a new issue and not as an existing one. Also I think we should try to formalise a "cooling off period" and/or some higher approval authority (e.g. the AB) so we don't get into this mess again. Martin. > -----Original Message----- > From: Andrew Watson [mailto:andrew@omg.org] > Sent: 06 August 1999 16:42 > To: Martin Chapman > Cc: interop@omg.org; firewall-rtf@omg.org > Subject: RE: Final Report on Urgent Issue 2801 resolution > > > Martin, > > You wrote: > > > Peter hits the nail on the head. > > The thing that really bugs me about this is that we have taken something > > that is broken and fixed it (which is good) but at the same > time outlawed > > something that works, was legal, and which invalidates our > implmentation. > > Andrew, is there any power of veto here or a sensible way to > get the wording > > below agreed to ? > > (i can't look at the p&p since the omg server is down !) > > Unfortunately, I don't think there is. > > The Urgent Issue section (appended below) specifically says that > this issue > cannot be revisited by this RTF. Although it uses the "should" word rather > than the "shall" word, I think the rationale makes it clear that once the > resolution has passed, it cannot be revisited. > > As for a veto - well, the point is moot, since you can't retrospectively > veto a poll after the voting deadline. > > Although this resolution applies to GIOP 1.2, the P&P wording > also seems to > preclude introducing a different (better?) resolution of the > problem in the > RTF's final report, for incorporation into GIOP 1.3. It looks to me as > though the next time this issue can legally be visited is in the next > Interop RTF. > > Cheers, > > Andrew > > 4.4.1.5 Urgent Issues > > In response to urgent requests for clarifications to a specification > ("Urgent Issues"), the OMG shall provide clarifications of specific > issues. > > [Issues may arise that require interpretation or clarification of a > specification in a very short period of time. For example, there may be > disputes over interpretation during the course of conformance testing in > the context of a branding program, or urgent clarifications required by a > vendor during product implementation. Resolution needs to occur within a > very short period of time (approximately 2 weeks), and should result in > modifications on a point-by-point basis.] > > Urgent Issues shall be directed to the OMG Technical Director (or his > appointee), who will determine whether the issue is appropriate for urgent > resolution, and if so direct it to the appropriate F/RTF. If no > appropriate F/RTF is currently active, the Architecture Board will be > responsible for resolving the issue. The Technical Director (or his > appointee) will propose specific wording for the clarification to the > committee (either the RTF or AB). The committee is then at liberty to vote > on the proposed clarification or to propose other clarifications. The > issue is deemed closed when a particular clarification has been accepted > by a poll of the F/RTF members. If a period of two weeks has passed from > the receipt of the issue by the Technical Director and no clarification > has been accepted, the Technical Director (or his appointee) will > determine an appropriate clarification. > > [A clarification (in the sense used here) typically eliminates an > ambiguity by narrowing the possible interpretations of a specification > when there are multiple, incompatible interpretations. In cases where a > specification is not logically consistent, a clarification may also render > a part of a specification void or add new content, only inasmuch as it is > necessary to make the specification consistent. This process must never be > used to extend a specification's functionality. > > The deployment of the Architecture Board in this role is intended as a > backstop, a last resort in case an appropriate F/RTF is not active. The > Architecture Board should by no means become the "normal" vehicle for > resolving issues of this nature. It is the responsibility and duty of the > Technology Committees to charter F/RTFs for Adopted and Available > Specifications and maintain their readiness to respond as needed. > > It will most likely be the case that committee discussions and polls on > urgent issues will be conducted electronically. OMG staff will maintain > appropriate email and document exchange mechanisms to facilitate this > process.] > > Resolutions of Urgent Issues will be formulated and maintained as isolated > revisions to the specification, identified by sequential natural numbers > and made publicly available. Any clarifications produced by this process > shall be incorporated into the final recommendation produced by the F/RTF. > Should there not be an appropriate F/RTF, or if the F/RTF does not produce > a recommendation before its delivery deadline, any clarifications produced > in this manner will automatically and collectively constitute a > recommendation of revision. Once a clarification has been accepted, it > should not be revisited by the F/RTF during the current revision cycle. > > [The prohibition against revisiting a clarification is not intended to > shackle the F/RTF, but to give clarifications generated by this process > some stability. The requirements of branding programs are the primary > motivation for this process. An Urgent Issue that alters a branding test > suite may affect the implementation of shipping, branded software > products, requiring one or more vendors to alter their products to conform > to the specification as clarified. It is reasonable for vendors to expect > that the clarification will not be arbitrarily reversed simply because the > balance of opinion in an F/RTF shifts for some reason (e.g., a change in > membership) before its final revision proposal is recommended to the > parent Technology Committee. The need for stability is balanced against > the need for TC approval. It is possible for the TC to reject the > recommendation of an TF (and thus, a set of clarifications), but our > assumption is that the TC understands the consequences of such a decision > and would only do so under extraordinary circumstances. > > As an example: If a specification's current revision is numbered 2.1, > clarifications will be identified separately, such as "clarification 1 of > revision 2.1", and so on. When an F/RTF produces its revision > recommendation (either explicitly or by default), the clarifications will > be folded into the overall revision, resulting in revision 2.2. If the > F/RTF fails to produce a recommendation, OMG staff will collect > clarifications into a revision recommendation. ] > > Date: Mon, 09 Aug 1999 09:19:18 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) To: Andrew Watson CC: Martin Chapman , interop@omg.org, firewall-rtf@omg.org Subject: Re: Final Report on Urgent Issue 2801 resolution Andrew Watson wrote: > > Although this resolution applies to GIOP 1.2, the P&P wording also > seems to preclude introducing a different (better?) resolution of > the problem in the RTF's final report, for incorporation into GIOP > 1.3. It looks to me as though the next time this issue can legally > be visited is in the next Interop RTF. What about ammending the end date for this RTF and chartering a new one sooner?