Issue 3438: GIOP version and CloseConnection (interop) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: I believe that, at some point, we decided that it is legal to send request for different GIOP versions over the same connection. Could someone please confirm or deny? (My memory is a bit hazy on the details.) At any rate, careful scrutiny of the spec does not reveal any words that would either state that separate connections must be used for different GIOP versions or that they can share a single connection. A definite statement is required either way. Assuming that different GIOP versions can indeed coexist on the same connection, we get an interesting problem: for GIOP 1.0 and 1.1, the spec disallows a client to send a CloseConnection message; for GIOP 1.2, it requires the client to send a CloseConnection message. This begs the question: if different GIOP versions can coexist on the same connection, it becomes impossible to achieve orderly connection shutdown. Sending a CloseConnection message is illegal for GIOP 1.0 and 1.1, whereas it is required for GIOP 1.2... So, what's the client to do if multiple GIOP versions are used over the same connection? Resolution: To close with revision Revised Text: In 15.5.1, after the existing third paragraph, add the following new paragraph: " If multiple GIOP versions are used on an underlying transport connection, the highest GIOP version used on the connection can be used for handling the close. A CloseConnection message sent using any GIOP version applies to all GIOP versions used on the connection (i.e., the underlying transport connection is closed for all GIOP versions). In particular, if GIOP version 1.2 or higher has been used on the connection, the client can send the CloseConnection message by using the highest GIOP version in use. " Actions taken: March 22, 2000: received issue October 4, 2000: closed issue Discussion: If multiple versions are being used on the connection, since the close isn't determined by anything that is version specific, the highest known good version can be used for handling the close. So, if 1.2 is known to be valid on the connection, the client can send the CloseConnection message using GIOP version 1.2.. End of Annotations:===== Date: Wed, 22 Mar 2000 10:49:19 +1000 (EST) From: Michi Henning Reply-To: interop@omg.org To: interop@omg.org cc: issues@omg.org Subject: GIOP version and CloseConnection Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: VN*!!Hmk!!UKld9n8Xd9 I believe that, at some point, we decided that it is legal to send request for different GIOP versions over the same connection. Could someone please confirm or deny? (My memory is a bit hazy on the details.) At any rate, careful scrutiny of the spec does not reveal any words that would either state that separate connections must be used for different GIOP versions or that they can share a single connection. A definite statement is required either way. Assuming that different GIOP versions can indeed coexist on the same connection, we get an interesting problem: for GIOP 1.0 and 1.1, the spec disallows a client to send a CloseConnection message; for GIOP 1.2, it requires the client to send a CloseConnection message. This begs the question: if different GIOP versions can coexist on the same connection, it becomes impossible to achieve orderly connection shutdown. Sending a CloseConnection message is illegal for GIOP 1.0 and 1.1, whereas it is required for GIOP 1.2... So, what's the client to do if multiple GIOP versions are used over the same connection? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: "'interop@omg.org'" Subject: RE: GIOP version and CloseConnection Date: Wed, 22 Mar 2000 10:50:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: (e+e95kO!!go-e9Z&jd9 Michi, Yes, we did decide that it is legal. To me, the CloseConnection is the one point where you cannot pretend the different versions are independent of one another. If a close is sent with some version, it seems that it either results in the connection being closed or not. But, that doesn't to make things worse than they already are. If multiple versions are being used on the connection, since the close isn't determined by anything that is version specific, the highest known good version can be used for handling the close. So, if 1.2 is known to be valid on the connection, the client can send the CloseConnection message. If the implementations of the different versions are able to interact with each other, then even the 1.0 and 1.1 code can take advantage of the orderly shutdown even though they can't initiate it. My approach to this is to treat each version on a connection as a separate protocol engine and state machine. The first thing that happens with a message is to demux it according to version, and from then on everything is version dependent. After that, there is only very limited and controlled interaction between the versions: - exclusive access to the connection for purposes of sending individual messages - common assignment of request ids. - shared logic for closing the connection In theory, request ids only need to be unique per version, and I treat it that way on the server side, but using common request id assignment across versions is a way to avoid breaking some other implementation that isn't so tolerant. Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Tuesday, March 21, 2000 7:49 PM > To: interop@omg.org > Cc: issues@omg.org > Subject: GIOP version and CloseConnection > > > > I believe that, at some point, we decided that it is legal to send > request for different GIOP versions over the same connection. > Could someone > please confirm or deny? (My memory is a bit hazy on the details.) > > At any rate, careful scrutiny of the spec does not reveal any > words that would > either state that separate connections must be used for > different GIOP versions > or that they can share a single connection. A definite > statement is required > either way. > > Assuming that different GIOP versions can indeed coexist on the same > connection, we get an interesting problem: for GIOP 1.0 and > 1.1, the spec > disallows a client to send a CloseConnection message; for GIOP 1.2, > it > requires the client to send a CloseConnection message. This > begs the question: > if different GIOP versions can coexist on the same > connection, it becomes > impossible to achieve orderly connection shutdown. Sending a > CloseConnection > message is illegal for GIOP 1.0 and 1.1, whereas it is required for > GIOP 1.2... So, what's the client to do if multiple GIOP > versions are used > over the same connection? > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > From: "Rutt, T E (Tom)" To: "'interop@omg.org'" Subject: RE: GIOP version and CloseConnection Date: Wed, 22 Mar 2000 10:56:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: NU)!!P"Zd9=Ehd9?9+!! > ---------- > From: Michi Henning[SMTP:michi@ooc.com.au] > Reply To: interop@omg.org > Sent: Tuesday, March 21, 2000 7:49 PM > To: interop@omg.org > Cc: issues@omg.org > Subject: GIOP version and CloseConnection > > > I believe that, at some point, we decided that it is legal to send > request for different GIOP versions over the same connection. Could > someone > please confirm or deny? (My memory is a bit hazy on the details.) > Yes we voted this clarfication in the interop 2000 rtf report -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com Date: Thu, 23 Mar 2000 15:20:13 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: "'interop@omg.org'" Subject: RE: GIOP version and CloseConnection In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD23@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: RH1!!-@De95AT!!KK*e9 On Wed, 22 Mar 2000, Paul Kyzivat wrote: > Michi, > > Yes, we did decide that it is legal. Thanks! So at least my memory isn't totally shot ;-) > To me, the CloseConnection is the one point where you cannot pretend the > different versions are independent of one another. If a close is sent with > some version, it seems that it either results in the connection being closed > or not. But, that doesn't to make things worse than they already are. > > If multiple versions are being used on the connection, since the close isn't > determined by anything that is version specific, the highest known good > version can be used for handling the close. So, if 1.2 is known to be valid > on the connection, the client can send the CloseConnection message. That's my feeling too -- at least it would provide an acceptable resolution for the current ambiguity. But the spec must say that, instead of saying nothing. > If the implementations of the different versions are able to interact with > each other, then even the 1.0 and 1.1 code can take advantage of the orderly > shutdown even though they can't initiate it. Sure. > In theory, request ids only need to be unique per version, and I treat it > that way on the server side, but using common request id assignment across > versions is a way to avoid breaking some other implementation that isn't so > tolerant. That's another one that is completely unspecified right now, and needs fixing. Personally, I don't think that it is necessary to permit overlapping request IDs per version (although I can certainly build my client to work that way). My feeling is that we should state that the namespace for request IDs is the connection, so that no two outstanding requests can use the same request ID, regardless of the version of each request. That's the simpler solution, IMO. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: "'interop@omg.org'" Subject: RE: GIOP version and CloseConnection Date: Thu, 23 Mar 2000 09:22:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: +4Pe9#ZN!!@jTd9:O]d9 Status: U > From: Michi Henning [mailto:michi@ooc.com.au] > > If multiple versions are being used on the connection, > since the close isn't > > determined by anything that is version specific, the > highest known good > > version can be used for handling the close. So, if 1.2 is > known to be valid > > on the connection, the client can send the CloseConnection > message. > > That's my feeling too -- at least it would provide an > acceptable resolution for the current ambiguity. > But the spec must say that, instead of saying nothing. I agree. > > In theory, request ids only need to be unique per version, > and I treat it > > that way on the server side, but using common request id > assignment across > > versions is a way to avoid breaking some other > implementation that isn't so > > tolerant. > > That's another one that is completely unspecified right now, > and needs fixing. I agree that this should be more clearly specified. > Personally, I don't think that it is necessary > to permit overlapping request IDs per version > (although I can certainly build my client to work that way). > My feeling is that we should state that the namespace for > request IDs is the connection, so that no two outstanding requests > can use the same request ID, regardless of the version of each > request. That's the simpler solution, IMO. I personally would have no problem with such a restriction. But based on what I recall of the discussions about multiple GIOP versions on a wire, I have this feeling that there may be some implementations where the giop versions are more loosely coupled. It could be the case that such an implementation might have difficulty doing common id assignment across versions. On the flip side, it shouldn't be difficult for every implementation to do the bookkeeping of received request ids on a per-version basis. It would be best if we heard from some other orb implementors on this. To: interop@omg.org Subject: resolution on 3438 too hazy Sender: Bill Janssen From: Bill Janssen Mime-Version: 1.0 Message-Id: <00May8.173100pdt."3438"@watson.parc.xerox.com> Date: Mon, 8 May 2000 17:31:06 PDT Content-Type: text/plain; charset=US-ASCII X-UIDL: ;P(e9p#Yd9jTnd98V!e9 The reasoning on 3438 seems to hazy to be useful. I urge a "No" vote on this resolution. In particular, how do we know the "highest known good" version on a connection? That is, what algorithm is the client or server supposed to use to accumulate this state? Bill Date: Tue, 9 May 2000 10:59:02 +1000 (EST) From: Michi Henning To: Bill Janssen cc: interop@omg.org Subject: Re: resolution on 3438 too hazy In-Reply-To: <00May8.173100pdt."3438"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: /]3!!J2\!!TLZ!!C2]!! On Mon, 8 May 2000, Bill Janssen wrote: > The reasoning on 3438 seems to hazy to be useful. I urge a "No" vote > on this resolution. In particular, how do we know the "highest known > good" version on a connection? That is, what algorithm is the client > or server supposed to use to accumulate this state? Remember the highest version number of any message received on that connection. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html To: Michi Henning cc: Bill Janssen , interop@omg.org Subject: Re: resolution on 3438 too hazy In-Reply-To: Your message of "Mon, 08 May 2000 18:02:39 PDT." From: Bill Janssen Message-Id: <00May8.184455pdt."3438"@watson.parc.xerox.com> Date: Mon, 8 May 2000 18:45:09 PDT Content-Type: text X-UIDL: $Ul!!(bVd9ne,!!Dfe!! > On Mon, 8 May 2000, Bill Janssen wrote: > > > The reasoning on 3438 seems to hazy to be useful. I urge a "No" > vote > > on this resolution. In particular, how do we know the "highest > known > > good" version on a connection? That is, what algorithm is the > client > > or server supposed to use to accumulate this state? > > Remember the highest version number of any message received on that > connection. Hmmm. `Sucessfully received', perhaps. Bill Date: Mon, 8 May 2000 22:20:21 -0400 (EDT) Message-Id: <200005090220.WAA00912@emerald.omg.org> Received: (qmail 10516 invoked from network); 9 May 2000 02:01:04 -0000 Received: from grub.paragon-software.com (204.91.29.200) by drudge1.paragon-software.com with SMTP; 9 May 2000 02:01:04 -0000 Received: (qmail 26134 invoked from network); 9 May 2000 02:20:34 -0000 Received: from localhost.paragon-software.com (HELO camros.com) (127.0.0.1) by localhost.paragon-software.com with SMTP; 9 May 2000 02:20:34 -0000 To: Michi Henning , Bill Janssen Subject: Re: resolution on 3438 too hazy From: "Jeffrey A. Marshall" X-Mailer: TWIG 2.1.1 Cc: interop@omg.org Content-Type: text X-UIDL: ;nTd9#5(e90Fkd9MOW!! The highest version number of a "well-formed" message? Or any message? (Well- formed meaning one a message that is marshaled without any errors?). Michi Henning said: > On Mon, 8 May 2000, Bill Janssen wrote: > > > The reasoning on 3438 seems to hazy to be useful. I urge a "No" > vote > > on this resolution. In particular, how do we know the "highest > known > > good" version on a connection? That is, what algorithm is the > client > > or server supposed to use to accumulate this state? > > Remember the highest version number of any message received on that connection. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > Date: Tue, 9 May 2000 12:24:51 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Bill Janssen , interop@omg.org Subject: Re: resolution on 3438 too hazy In-Reply-To: <00May8.184455pdt."3438"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 2^b!!X3^d9g<#!!e3Ke9 On Mon, 8 May 2000, Bill Janssen wrote: > > On Mon, 8 May 2000, Bill Janssen wrote: > > > > > The reasoning on 3438 seems to hazy to be useful. I urge a "No" > > vote > > > on this resolution. In particular, how do we know the "highest > > known > > > good" version on a connection? That is, what algorithm is the > > client > > > or server supposed to use to accumulate this state? > > > > Remember the highest version number of any message received on > > that connection. > > Hmmm. `Sucessfully received', perhaps. Dangerous concept maybe? How would you define "successful"? It seems easiest to maintain a simple version counter that remembers the highest version number by simply looking at the GIOP header of all messages. Receipt of such a header over a connection indicates that the other end understands 1.2 (otherwise, it wouldn't have sent that header). Whether the request is then "successfully" processed in any sense seems irrelevant. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Tue, 9 May 2000 12:28:11 +1000 (EST) From: Michi Henning To: "Jeffrey A. Marshall" cc: Bill Janssen , interop@omg.org Subject: Re: resolution on 3438 too hazy In-Reply-To: <200005090220.MAA24942@janus.ooc.com.au> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: `i'!!]o>e9fUK!!DRCe9 On Tue, 9 May 2000, Jeffrey A. Marshall wrote: > The highest version number of a "well-formed" message? Or any message? (Well- > formed meaning one a message that is marshaled without any errors?). Any message. Once a header containing 1.2 is received, the receiving end can reliably conclude that the other end is aware of 1.2, otherwise it would have sent such a header. Whether everything else then works, such as whether the request can be unmarshaled, is an orthogonal issue. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: interop@omg.org Subject: RE: resolution on 3438 too hazy Date: Tue, 9 May 2000 08:25:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: URA!!0;6!!\+Z!!h:nd9 Bill, While I think the wording is sufficient, I have no objection to clarifying it further. The suggestion by Michi (the highest version number received on the connection) is a good one. I would go a bit further: the larger of the highest version number received on the connection, and the highest iiop version number in any IOR available to the sender that could legally be invoked on this connection. This covers information that could have been derived from IORs that the orb has touched (via string_to_object or unmarshalling) but not yet invoked. I don't think this has to be normative text - it can simply be examples of how an orb might infer the highest version number that its peer can accept. Paul > -----Original Message----- > From: Bill Janssen [mailto:w.janssen@ieee.org] > Sent: Monday, May 08, 2000 8:31 PM > To: interop@omg.org > Subject: resolution on 3438 too hazy > > > The reasoning on 3438 seems to hazy to be useful. I urge a "No" vote > on this resolution. In particular, how do we know the "highest known > good" version on a connection? That is, what algorithm is the client > or server supposed to use to accumulate this state? > > Bill > To: Michi Henning cc: Bill Janssen , interop@omg.org Subject: Re: resolution on 3438 too hazy In-Reply-To: Your message of "Mon, 08 May 2000 19:25:06 PDT." From: Bill Janssen Message-Id: <00May9.161811pdt."3438"@watson.parc.xerox.com> Date: Tue, 9 May 2000 16:18:12 PDT Content-Type: text X-UIDL: 7gK!! Dangerous concept maybe? How would you define "successful"? It seems easiest > to maintain a simple version counter that remembers the highest version > number by simply looking at the GIOP header of all messages. Receipt > of such a header over a connection indicates that the other end understands > 1.2 (otherwise, it wouldn't have sent that header). Actually, that isn't clear. Wasn't Iona talking about muxing packets from various ORBs onto a single connection? Wasn't that the whole justification for having different GIOP versions on a single connection? Under that sort of scheme, one of the muxed ORBs might understand a version, but not necessarily the ORB on the other end of the connection. Bill Sender: jbiggar@corvette.floorboard.com Message-ID: <3918A4CF.7E1F7692@floorboard.com> Date: Tue, 09 May 2000 16:52:47 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Michi Henning , Bill Janssen , interop@omg.org Subject: Re: resolution on 3438 too hazy References: <00May9.161811pdt."3438"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: V&I!!fe'!!/SRd90^dd9 Bill Janssen wrote: > > > Dangerous concept maybe? How would you define "successful"? It seems easiest > > to maintain a simple version counter that remembers the highest version > > number by simply looking at the GIOP header of all messages. Receipt > > of such a header over a connection indicates that the other end understands > > 1.2 (otherwise, it wouldn't have sent that header). > > Actually, that isn't clear. Wasn't Iona talking about muxing packets > from various ORBs onto a single connection? Wasn't that the whole > justification for having different GIOP versions on a single > connection? Under that sort of scheme, one of the muxed ORBs might > understand a version, but not necessarily the ORB on the other end of > the connection. Except if they are muxing connections, then CloseConnection has to be handled specially anyway, since it affects the entire connection state. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 10 May 2000 10:01:26 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Bill Janssen , interop@omg.org Subject: Re: resolution on 3438 too hazy In-Reply-To: <00May9.161811pdt."3438"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: _hkd9k:Td9E02!!?&De9 On Tue, 9 May 2000, Bill Janssen wrote: > > Dangerous concept maybe? How would you define "successful"? It seems easiest > > to maintain a simple version counter that remembers the highest version > > number by simply looking at the GIOP header of all messages. Receipt > > of such a header over a connection indicates that the other end understands > > 1.2 (otherwise, it wouldn't have sent that header). > > Actually, that isn't clear. Wasn't Iona talking about muxing packets > from various ORBs onto a single connection? I don't see how this would be possible -- wouldn't you get confused about the origin of the packets? And how would you ensure that they have unique request IDs? > Wasn't that the whole > justification for having different GIOP versions on a single > connection? Under that sort of scheme, one of the muxed ORBs might > understand a version, but not necessarily the ORB on the other end > of > the connection. I don't think this scenario can ever happen. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html To: Paul Kyzivat cc: interop@omg.org Subject: Re: resolution on 3438 too hazy In-Reply-To: Your message of "Tue, 09 May 2000 05:24:27 PDT." <9B164B713EE9D211B6DC0090273CEEA926BE7B@bos1.noblenet.com> From: Bill Janssen Message-Id: <00May9.181928pdt."3438"@watson.parc.xerox.com> Date: Tue, 9 May 2000 18:19:35 PDT Content-Type: text X-UIDL: 40:!!<+2!!`h@!! I don't think this has to be normative text - it can simply be examples of > how an orb might infer the highest version number that its peer can accept. Actually, I would like normative text. Many of our problems have stemmed from people having half-baked `good ideas' about how to do things. Bill Sender: jon@corvette.floorboard.com Message-ID: <3918D0C4.BDB97DA4@floorboard.com> Date: Tue, 09 May 2000 20:00:20 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Bill Janssen , Bill Janssen , interop@omg.org Subject: Re: resolution on 3438 too hazy References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &N$!!Z%@!!H,;!!4\Nd9 Michi Henning wrote: > > On Tue, 9 May 2000, Bill Janssen wrote: > > > > Dangerous concept maybe? How would you define "successful"? It seems easiest > > > to maintain a simple version counter that remembers the highest version > > > number by simply looking at the GIOP header of all messages. Receipt > > > of such a header over a connection indicates that the other end understands > > > 1.2 (otherwise, it wouldn't have sent that header). > > > > Actually, that isn't clear. Wasn't Iona talking about muxing packets > > from various ORBs onto a single connection? > > I don't see how this would be possible -- wouldn't you get confused about > the origin of the packets? And how would you ensure that they have > unique request IDs? Patch the request IDs in the marshalled packets. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 10 May 2000 13:28:47 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Bill Janssen , Bill Janssen , interop@omg.org Subject: Re: resolution on 3438 too hazy In-Reply-To: <3918D0C4.BDB97DA4@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: l2dd98C:!!nVed99c(!! On Tue, 9 May 2000, Jonathan Biggar wrote: > > I don't see how this would be possible -- wouldn't you get confused about > > the origin of the packets? And how would you ensure that they have > > unique request IDs? > > Patch the request IDs in the marshalled packets. I see. That's more like a protocol bridge than an ORB then. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html To: Jonathan Biggar cc: Michi Henning , Bill Janssen , interop@omg.org Subject: Re: resolution on 3438 too hazy In-Reply-To: Your message of "Tue, 09 May 2000 16:53:22 PDT." <3918A4CF.7E1F7692@floorboard.com> From: Bill Janssen Message-Id: <00May10.155459pdt."3438"@watson.parc.xerox.com> Date: Wed, 10 May 2000 15:55:07 PDT Content-Type: text X-UIDL: ~pMe9XJ1!!W]Ke9Q$8!! > Bill Janssen wrote: > > > > > Dangerous concept maybe? How would you define "successful"? It seems easiest > > > to maintain a simple version counter that remembers the highest version > > > number by simply looking at the GIOP header of all messages. Receipt > > > of such a header over a connection indicates that the other end understands > > > 1.2 (otherwise, it wouldn't have sent that header). > > > > Actually, that isn't clear. Wasn't Iona talking about muxing packets > > from various ORBs onto a single connection? Wasn't that the whole > > justification for having different GIOP versions on a single > > connection? Under that sort of scheme, one of the muxed ORBs might > > understand a version, but not necessarily the ORB on the other end of > > the connection. > > Except if they are muxing connections, then CloseConnection has to be > handled specially anyway, since it affects the entire connection state. Yes, I think I'm convinced, Jon. Bill