Issue 1968: CloseConnection (interop) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: There are quite a few words about CloseConnection in the GIOP 1.2 draft. The major change is that either end of a connection can send the message for a bi-directional connection. However, the spec doesn"t say that a client *must* send a CloseConnection message to the server before closing down. It just says that it *may*. Similarly, CloseConnection is only partially defined for the server side, as far as I can see. Resolution: resolved Revised Text: Resolution: Clarify section 15.5.1.1 Based on a circulated proposed resolution, it was agreed to make the client use of CloseConnection required for orderly release in GIOP 1.2, given the change can be published with CORBA 2.3a. After the first vote on a proposed resolution, discussion pointed out the need to keep the semantics of a connection shutdown implicitly cancelling any pending non-oneway requests. This requires changes to section 15.8. The close connection semantics, with the proposed resolution below, are stated in 15.5.1.1, for all versions of GIOP. The text imported from the bidirectional GIOP chapter has been changed to having a close connection automatically imply cancel of outstanding requests, for all versions of GIOP. The connection closure text in 15.8 is changed to a reference to the new proposed text for 15.5.1.1 Proposed Revised Text: 15.5.1.1 Change the clause to the following, given that the output of this Interop 2.4 RTF will be adopted in time for publication of CORBA 2.3 " Connections can be closed in two ways: orderly shutdown, or abortive disconnect. For GIOP versions 1.0, and 1.1: orderly shutdown is initiated by servers reliably sending a CloseConnection message, or by clients just closing down a connection. Orderly shutdown may be initiated by the client at any time. A server may not initiate shutdown if it has begun processing any requests for which it has not either received a CancelRequest or sent a corresponding reply. If a client detects connection closure without receiving a CloseConnection message, it must assume an abortive disconnect has occurred, and treat the condition as an error. . For GIOP Version 1.2 : Orderly shutdown is initiated by either the originating client orb (connection initiator) or by the server orb (connection responder) reliably sending a Close Connection message If the ORB sending the CloseConnection is a server, or BiDirectional GIOP is in use, the sending ORB must not currently be processing any Requests from the other side. The ORB which sends the CloseConnection must not send any messages after the CloseConnection. If either ORB detects connection closure without receiving a CloseConnection message, it must assume an abortive disconnect has occurred, and treat the condition as an error. If bidirectional GIOP is in use, the conditions of section 15.7 apply. For all uses of CloseConnection (for GIOP versions 1.0, 1.1, and 1.2): If there are any pending non-oneway requests which were initiated on a connection by the ORB shutting down that connection, the connection-peer ORB should consider them as canceled. If an orb receives a CloseConnection message from its connection-peer ORB, it should assume that any outstanding messages (i.e., without replies) were received after the connection-peer ORB sent the CloseConnection message, were not processed, and may be safely resent on a new connection. After reliably issuing a CloseConnection message, the issuing orb may close the connection. Some transport protocols (not including TCP) do not provide an "orderly disconnect" capability, guaranteeing reliable delivery of the last message sent. When GIOP is used with such protocols, an additional handshake needs to be provided as part of the mapping to that protocol's connection mechanisms, to guarantee that both ends of the connection understand the disposition of any outstanding GIOP requests. " In section 15.4.6 (CloseConnection): Change the sentence: " In GIOP version 1.2, if BiDirectional GIOP (see “Bi-DirectionalvGIOP” on page 15-48) is in use, both sides of the connection may send the CloseConnection message. " to the following: " In GIOP version 1.2, both sides of the connection may send the CloseConnection message. " In Section 15.8, Change the paragraph: " CloseConnection messages are a special case however. Either ORB may send a CloseConnection message, but the conditions in “Connection Management” on page 15-41, are modified for GIOP version 1.2, in that the ORB sending the CloseConnection must not be awaiting Replies to any Requests, and must not have begun processing any Requests from the other side. If these conditions are satisfied and the ORB sends a CloseConnection, the ORB on the opposite side must assume that any outstanding Requests it has sent were not processed and may be resent on a new connection. The ORB which sends the CloseConnection must not send any messages after the CloseConnection. It may also close the connection, although the caveats regarding protocols which do not implement "orderly shutdown" in “Connection Management” on page 15-41, apply. " to " CloseConnection messages are a special case however. Either ORB may send a CloseConnection message, but the conditions in “Connection Management” on page 15-41, apply. " Actions taken: September 18, 1998: received issue March 8, 1999: closed issue Discussion: End of Annotations:===== Return-Path: X-Authentication-Warning: fatcat.dstc.edu.au: michi owned process doing -bs Date: Fri, 18 Sep 1998 14:58:40 +1000 (EST) From: Michi Henning To: interop@omg.org Subject: CloseConnection There are quite a few words about CloseConnection in the GIOP 1.2 draft. The major change is that either end of a connection can send the message for a bi-directional connection. However, the spec doesn't say that a client *must* send a CloseConnection message to the server before closing down. It just says that it *may*. Similarly, CloseConnection is only partially defined for the server side, as far as I can see. The spec says: If a client detects connection closure without receiving a CloseConnection message, it should assume an abortive disconnect has occurred, and treat the condition as an error. Specifically, it should report COMM_FAILURE exceptions for all pending requests on the connection, with completion_status values set to COMPLETED_MAYBE. The word "should" here must be replaced with "must", otherwise the text is not normative. But more seriously, the text doesn't say specifically what must happen if a connection to a server goes down *between* completed requests. In particular, it is ambiguous whether this obliges the client to report an error next time a request goes out on the now dead connection. Questions: - Is the client obliged to rebind if the connection goes down between requests? Clearly, if a CloseConnection message was received earlier, the client must rebind (but this is not stated). - What if no CloseConnection message was received before the connection went down? Is the client *obliged* to try a rebind or is this optional? On the next request, if the client won't rebind, or if the rebind attempt fails, what exception must be raised? According to the recent changes to the IDL chapter, the client must raise TRANSIENT and cannot raise COMM_FAILURE. I think this should be stated to make this clearer. In general, it would be nice to enumerate the possible scenarios for connection closure and to explicitly state what must happen in each case. Also, why does the spec say *may* send CloseConnection instead of *must*? Why don't we force both client and server to always send a CloseConnection message for GIOP 1.2 before closing a connection? That way, there would *finally* be a reliable way for the server to detect when a client has died. I would suggest to make sending of a CloseConnection message mandatory in GIOP 1.2. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Fri, 18 Sep 1998 08:49:00 -0700 From: David Brownell To: Michi Henning CC: interop@omg.org Subject: Re: CloseConnection References: Michi Henning wrote: > > > If a client detects connection closure without receiving > a CloseConnection message, it should assume an abortive > disconnect has occurred, and treat the condition as an > error. > Specifically, it should report COMM_FAILURE exceptions for > all pending requests on the connection, with > completion_status > values set to COMPLETED_MAYBE. > > The word "should" here must be replaced with "must", otherwise the > text > is not normative. I suspect this was an oversight in the IIOP 1.0 spec, inherited. > But more seriously, the text doesn't say specifically what must happen > if a connection to a server goes down *between* completed requests. > In particular, it is ambiguous whether this obliges the client to report > an error next time a request goes out on the now dead connection. The original intent was that it shouldn't: there's no message lost, the client ORB can reestablish a connection, hence no error. But if the OMG decides to stipulate that it's an error, perhaps it could; folk have been adding more semantics to connections than were there originally, so that change might be needed. - Dave Return-Path: Sender: jon@floorboard.com Date: Fri, 18 Sep 1998 09:46:38 -0700 From: Jonathan Biggar To: David Brownell CC: Michi Henning , interop@omg.org Subject: Re: CloseConnection References: <360280EC.D725FF07@eng.sun.com> David Brownell wrote: > > Michi Henning wrote: > > > > > > If a client detects connection closure without receiving > > a CloseConnection message, it should assume an abortive > > disconnect has occurred, and treat the condition as an > error. > > Specifically, it should report COMM_FAILURE exceptions for > > all pending requests on the connection, with > completion_status > > values set to COMPLETED_MAYBE. > > > > The word "should" here must be replaced with "must", otherwise the > text > > is not normative. > > I suspect this was an oversight in the IIOP 1.0 spec, inherited. > > > But more seriously, the text doesn't say specifically what must > happen > > if a connection to a server goes down *between* completed > requests. > > In particular, it is ambiguous whether this obliges the client to > report > > an error next time a request goes out on the now dead connection. > > The original intent was that it shouldn't: there's no message lost, > the client ORB can reestablish a connection, hence no error. But if > the OMG decides to stipulate that it's an error, perhaps it could; > folk have been adding more semantics to connections than were there > originally, so that change might be needed. I would prefer that no error be allowed or required in this case. It simply "no harm, no foul" and the client (or server) should transparently rebind. Of course, this isn't taking into consideration the policy from the messaging spec that affects rebinding. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: fatcat.dstc.edu.au: michi owned process doing -bs Date: Sat, 19 Sep 1998 06:00:01 +1000 (EST) From: Michi Henning To: David Brownell cc: interop@omg.org Subject: Re: CloseConnection On Fri, 18 Sep 1998, David Brownell wrote: > > But more seriously, the text doesn't say specifically what must happen > > if a connection to a server goes down *between* completed requests. > > In particular, it is ambiguous whether this obliges the client to report > > an error next time a request goes out on the now dead connection. > > The original intent was that it shouldn't: there's no message lost, > the client ORB can reestablish a connection, hence no error. I agree, and every ORB I've ever used does a rebind in this case. But it's no good if the spec doesn't say that. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: From: "Ken Fleming" To: "Michi Henning" , Subject: RE: CloseConnection Date: Fri, 18 Sep 1998 14:07:27 -0700 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal I agree. This is so obvious, I do not see why anyone objects. > -----Original Message----- > From: Michi Henning [mailto:michi@dstc.edu.au] > Sent: Thursday, September 17, 1998 9:59 PM > To: interop@omg.org > Subject: CloseConnection > > > There are quite a few words about CloseConnection in the GIOP 1.2 > draft. > The major change is that either end of a connection can send the > message > for a bi-directional connection. > > However, the spec doesn't say that a client *must* send a > CloseConnection > message to the server before closing down. It just says that it > *may*. > > Similarly, CloseConnection is only partially defined for the server > side, > as far as I can see. The spec says: > > If a client detects connection closure without receiving > a CloseConnection message, it should assume an abortive > disconnect has occurred, and treat the condition as an error. > Specifically, it should report COMM_FAILURE exceptions for > all pending requests on the connection, with completion_status > values set to COMPLETED_MAYBE. > > The word "should" here must be replaced with "must", otherwise the > text > is not normative. > > But more seriously, the text doesn't say specifically what must > happen > if a connection to a server goes down *between* completed requests. > In particular, it is ambiguous whether this obliges the client to > report > an error next time a request goes out on the now dead connection. > > Questions: > > - Is the client obliged to rebind if the connection goes down > between requests? > > Clearly, if a CloseConnection message was received earlier, > the client must rebind (but this is not stated). > > - What if no CloseConnection message was received before > the connection went down? > > Is the client *obliged* to try a rebind or is this optional? > > On the next request, if the client won't rebind, or if the > rebind attempt fails, what exception must be raised? > According to the recent changes to the IDL chapter, the > client > must raise TRANSIENT and cannot raise COMM_FAILURE. > I think this should be stated to make this clearer. > > In general, it would be nice to enumerate the possible scenarios for > connection closure and to explicitly state what must happen in each > case. > > Also, why does the spec say *may* send CloseConnection instead of > *must*? > Why don't we force both client and server to always send a > CloseConnection > message for GIOP 1.2 before closing a connection? That way, there > would *finally* be a reliable way for the server to detect when a > client > has died. > > I would suggest to make sending of a CloseConnection message > mandatory > in GIOP 1.2. > > Cheers, > > Michi. > -- > Michi Henning +61 7 33654310 > DSTC Pty Ltd +61 7 33654311 (fax) > University of Qld 4072 michi@dstc.edu.au > AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Mon, 21 Sep 1998 16:09:32 PDT Sender: Bill Janssen From: Bill Janssen To: interop@omg.org, Michi Henning Subject: Re: CloseConnection References: CloseConnection isn't really useful without a better indication of why the peer has closed the connection. In HTTP-NG, we define the following reasons: 1) Lost protocol sync -- can't understand the other side 2) Process termination -- server group responsible for the set of objects on the other side of the connection will shortly no longer exist 3) Resource management -- server needs to reclaim "less important" connections to re-use buffer space and/or fds 4) Bad endpoint identity -- peer has reason to believe other side is talking to the "wrong" service -- details of how are unspecified 5) Max serial number -- connection has to be closed because we've hit the limit on serial numbers over any single connection 6) Relocating -- server is moving to another host/port combination 7) Received EOF -- got abrupt close from peer, so closing politely Knowing which reason applies is a help to the client in determining what to do next. If the reason is (1), (3), or (5), doing a re-connect on the next call is probably a good idea. However, if (6) or (2) or (4) or (7), other actions might be appropriate (such as re-binding if (6), etc.). If we're going to change CloseConnection, I'd be in favor of adding a field somewhere which contains the reason for sending it. Perhaps using a service context would be the most appropriate mechanism for doing this in a backwards-compatible fashion. Bill Return-Path: Sender: jon@floorboard.com Date: Mon, 21 Sep 1998 17:06:21 -0700 From: Jonathan Biggar To: Bill Janssen CC: interop@omg.org, Michi Henning Subject: Re: CloseConnection References: Bill Janssen wrote: > > CloseConnection isn't really useful without a better indication of > why > the peer has closed the connection. In HTTP-NG, we define the > following > reasons: > > 1) Lost protocol sync -- can't understand the other side > 2) Process termination -- server group responsible for the > set of > objects on the other side of the connection will shortly no longer > exist > 3) Resource management -- server needs to reclaim "less > important" > connections to re-use buffer space and/or fds > 4) Bad endpoint identity -- peer has reason to believe > other side is > talking to the "wrong" service -- details of how are unspecified > 5) Max serial number -- connection has to be closed because > we've hit > the limit on serial numbers over any single connection > 6) Relocating -- server is moving to another host/port > combination > 7) Received EOF -- got abrupt close from peer, so closing > politely > > Knowing which reason applies is a help to the client in determining > what > to do next. If the reason is (1), (3), or (5), doing a re-connect > on > the next call is probably a good idea. However, if (6) or (2) or > (4) or > (7), other actions might be appropriate (such as re-binding if (6), > etc.). > > If we're going to change CloseConnection, I'd be in favor of adding > a > field somewhere which contains the reason for sending it. Perhaps > using > a service context would be the most appropriate mechanism for doing > this > in a backwards-compatible fashion. This is a good suggestion, except for the last. There isn't a service-context available for a CloseConnection currently, so we'd have to add one to do it that way. Since that entails changing the CloseConnection message format, we might as well just add an enumeration and avoid the extra wrappers. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 21 Sep 1998 17:23:13 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Jonathan Biggar Subject: Re: CloseConnection CC: interop@omg.org, Michi Henning References: <3606E9FD.25438129@floorboard.com> Oops! As Jon says, there is no service context currently defined for CloseConnection. Bill Date: Mon, 22 Feb 1999 16:14:35 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies - Bell Labs To: interop@omg.org Subject: Tom Rutt vote on INterop 2.4 vote 1 I vote yes on the following proposed resolutions: Issue 543: IIOP server-initiated connection closure problem Issue 1129: How to handle unexpected exceptions? Issue 1653: CDR encoding for fixed Issue 1948: Clarification requested on GIOP 1.1 and wstring Issue 1975: GIOP/IIOP version alignment? Issue 1976: GIOP/IIOP version alignment? (duplicate of 1975) Issue 1978: COMM_FAILURE and completion_status Issue 1982: GIOP fragment alignment issue for CORBA 2.3 Issue 2045: Obsolete text in ptc/98-08-13.pdf Issue 2068: Tagged Component interactions Issue 2324: Move recently added text to correct place Issue 2333: GIOP encoding of nil Abstract Interface is unspecified Issue 2338: Potential interop. problem in CORBA 2.3: pseudo-operation marshalling I vote no on the proposed change as worded for the following issue, but will vote yes on a reworded proposal )which will come from Jeff Mischkinsky) which makes it clear that the case "2" can be used whenever the actual type is a subtype or exact match to the formal parameter type, irregardless of truncation. Issue 2315: OBV GIOP clarification needed The possible votes on the following issue are: a)no revision, b) clarification as written for client sending closeConnection only for bidirectional giop c) extend GIOP 1.2 to require client to alowys use CloseConnection for orderly disconnect, without rev of GIOP to 1.3. If any ORB vendor raises a veto on option c, then we must revert to option b. Issue 1968: CloseConnection I prefer option c, but am willing to live with option b is any orb vendor is unwilling to change the GIOP 1.2 to require clients to send closeConnection on graceful shutdown. -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- Date: Fri, 26 Feb 1999 13:29:46 -0500 From: Bob Kukura Organization: IONA Technologies X-Accept-Language: en To: terutt@lucent.com CC: jeffm@inprise.com, jis@fpk.hp.com, jon@biggar.org, drs@nortelnetworks.com, stephen@aptest.ie, randyfox@austin.ibm.com, janssen@parc.xerox.com, michi@triodia.com, bill@novell.com, bill.beckwith@ois.com, ed.cobb@beasys.com, Ken Cavanaugh , interop@omg.org Subject: Re: Final Notice of Interop 2.4 RTF Vote 1 References: <36CDCCC8.A56C7C0B@lucent.com> <36CDDE9C.660B21B0@lucent.com> <36CDE13C.C5FA5660@lucent.com> <36D5B46F.23437F78@lucent.com> IONA votes as follows: YES on 543, 1129, 1653, 1948, 1975, 1978, 1982, 2045, 2324, 2333, 2338 NO on 2068, 2315 1968: I prefer C, provided that its gets in CORBA 2.3. But I want to make sure everyone is aware that the proposed text (for B or C) basically requires a (bidirectional for B) client ORB to send CancelRequest messages for any outstanding requests before sending CloseConnection, whereas B makes the connection closure imply cancelation for for non-bidirectional clients. If anyone strongly believes CloseConnection should imply cancellation, we could probably live with that and this additional change could be incorporated into the next vote (Monday?). -Bob Date: Fri, 26 Feb 1999 21:04:31 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies To: interop@OMG.ORG Subject: Draft Final Proposal for CloseConnection Issue for Review Please review the following text. After a round of comments, closing Monday evening, If there is a agreement we can send the final text out for final vote. Please comment before monday eveining, and remember we should not be adding new features,just clarifying the semantics of CloseConnection usage. -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- closecon Issue 1968: CloseConnection (interop) Click here for this issue's archive. Source: DSTC (Mr. Michi Henning, michi@triodia.com) Nature: Uncategorized Issue Severity: Summary: There are quite a few words about CloseConnection in the GIOP 1.2 draft. The major change is that either end of a connection can send the message for a bi-directional connection. However, the spec doesn't say that a client *must* send a CloseConnection message to the server before closing down. It just says that it *may*. Similarly, CloseConnection is only partially defined for the server side, as far as I can see. Resolution: Clarify section 15.5.1.1 Proposed Revised Text: 15.5.1.1 Change the clause to the following, dependant on whether the output of this Interop 2.4 RTF will be adopted in time for publication of CORBA 2.3 If the report is not adopted in time for publication in CORBA 2.3,: change the clause to: " Connections can be closed in two ways: orderly shutdown, or abortive disconnect. If bidirectional GIOP is not in use: * orderly shutdown is initiated by servers reliably sending a * CloseConnection message, or by clients just closing down a * connection. * * Orderly shutdown may be initiated by the client at any time. * * If there are pending requests when a client shuts down a connection, * the server should consider all such requests canceled. * * A server may not initiate shutdown if it has begun processing any * requests for which it has not either received a CancelRequest or * sent a corresponding reply. * * If a client detects connection closure without receiving a * CloseConnection message, it must assume an abortive disconnect has * occurred, and treat the condition as an error. * If bidirectional GIOP is in use, the conditions of section 15.7 * apply. In particular: * Orderly shutdown is initiated by either the originating client * orb(connection initiator) or by the server orb (connection * responder) by reliably sending a Close Connection message * * The ORB sending the CloseConnection must not be awaiting Replies to * any Requests, and must not have begun processing any Requests from * the other side. * * The ORB which sends the CloseConnection must not send any messages * after the CloseConnection. * * If either ORB detects connection closure without receiving a * CloseConnection message, it must assume an abortive disconnect has * occurred, and treat the condition as an error. * For either bidirectional or asymetric use of GIOP,: * if an orb receives an CloseConnection message from its * connection-peer orb, it should assume that any outstanding messages * (i.e., without replies) were received after the connection-peer orb * sent the CloseConnection message, were not processed, and may be * safely resent on a new connection. * * After reliably issuing a CloseConnection message, the issuing orb * may close the connection. Some transport protocols (not including * TCP) do not provide a n capability, guaranteeing reliable delivery * of the last message sent. When GIOP is used with such protocols, an * additional handshake needs to be provided as part of the mapping to * that protocol's connection mechanisms, to guarantee that both ends * of the connection understand the disposition of any outstanding GIOP * requests. * " If the report is adopted in time for publication in CORBA 2.3,: change the clause to: " Connections can be closed in two ways: orderly shutdown, or abortive disconnect. For GIOP versions 1.0, and 1.1: * orderly shutdown is initiated by servers reliably sending a * CloseConnection message, or by clients just closing down a * connection. * * Orderly shutdown may be initiated by the client at any time. * * If there are pending requests when a client shuts down a connection, * the server should consider all such requests canceled. * * A server may not initiate shutdown if it has begun processing any * requests for which it has not either received a CancelRequest or * sent a corresponding reply. * * If a client detects connection closure without receiving a * CloseConnection message, it must assume an abortive disconnect has * occurred, and treat the condition as an error. * . For GIOP Version 1.2 :: * Orderly shutdown is initiated by either the originating client * orb(connection initiator) or by the server orb (connection * responder) by reliably sending a Close Connection message * * The ORB sending the CloseConnection must not be awaiting Replies to * any Requests * * If the ORB sending the CloseConnection is a server, or BiDirectional * GIOP is in use, she sending ORB must not have begun processing any * Requests from the other side. * * The ORB which sends the CloseConnection must not send any messages * after the CloseConnection. * * If either ORB detects connection closure without receiving a * CloseConnection message, it must assume an abortive disconnect has * occurred, and treat the condition as an error. * * If bidirectional GIOP is in use, the conditions of section 15.7 * apply. * In all uses of CloseConnection (for GIOP versions 1.0, 1.1, and 1.2): * * if an orb receives an CloseConnection message from its * connection-peer orb, it should assume that any outstanding messages * (i.e., without replies) were received after the connection-peer orb * sent the CloseConnection message, were not processed, and may be * safely resent on a new connection. * * After reliably issuing a CloseConnection message, the issuing orb * may close the connection. Some transport protocols (not including * TCP) do not provide a n capability, guaranteeing reliable delivery * of the last message sent. When GIOP is used with such protocols, an * additional handshake needs to be provided as part of the mapping to * that protocol's connection mechanisms, to guarantee that both ends * of the connection understand the disposition of any outstanding GIOP * requests. * " Sender: jon@floorboard.com Date: Fri, 26 Feb 1999 21:04:47 -0800 From: Jonathan Biggar X-Accept-Language: en To: terutt@lucent.com CC: interop@OMG.ORG Subject: Re: Draft Final Proposal for CloseConnection Issue for Review References: <36D752AF.EC401F3@lucent.com> > Tom Rutt wrote: > > Please review the following text. After a round of comments, > closing Monday evening, If there is a agreement we can send the > final text out for final vote. > > Please comment before monday eveining, and remember we should not be > adding new > features,just clarifying the semantics of CloseConnection usage. Tom, Bill Jansen pointed out a problem with oneway operations. Let me propose a change to a couple of your bullet points: > If bidirectional GIOP is not in use: > > * orderly shutdown is initiated by servers reliably sending a > CloseConnection message, or by clients just closing down a > connection. > * Orderly shutdown may be initiated by the client at any time. > * If there are pending requests when a client shuts down a > connection, the server should consider all such requests > canceled. * If there are pending non-oneway requests when a client shuts down a connection, the server should consider all such requests cancelled. > * A server may not initiate shutdown if it has begun processing any > requests for which it has not either received a CancelRequest or > sent a corresponding reply. > * If a client detects connection closure without receiving a > CloseConnection message, it must assume an abortive disconnect > has occurred, and treat the condition as an error. > > If bidirectional GIOP is in use, the conditions of section 15.7 > apply. In particular: > > * Orderly shutdown is initiated by either the originating client > orb(connection initiator) or by the server orb (connection > responder) by reliably sending a Close Connection message > * The ORB sending the CloseConnection must not be awaiting Replies > to any Requests, and must not have begun processing any Requests > from the other side. > * The ORB which sends the CloseConnection must not send any > messages after the CloseConnection. > * If either ORB detects connection closure without receiving a > CloseConnection message, it must assume an abortive disconnect > has occurred, and treat the condition as an error. > > For either bidirectional or asymetric use of GIOP,: > > * if an orb receives an CloseConnection message from its > connection-peer orb, it should assume that any outstanding > messages (i.e., without replies) were received after the > connection-peer orb sent the CloseConnection message, were not > processed, and may be safely resent on a new connection. > * After reliably issuing a CloseConnection message, the issuing orb > may close the connection. Some transport protocols (not > including TCP) do not provide an ?orderly disconnect? capability, > guaranteeing reliable delivery of the last message sent. When > GIOP is used with such protocols, an additional handshake needs > to be provided as part of the mapping to that protocol's > connection mechanisms, to guarantee that both ends of the > connection understand the disposition of any outstanding GIOP > requests. > > " > > If the report is adopted in time for publication in CORBA 2.3,: change > the clause to: > > " > Connections can be closed in two ways: orderly shutdown, or abortive > disconnect. > > For GIOP versions 1.0, and 1.1: > > * orderly shutdown is initiated by servers reliably sending a > CloseConnection message, or by clients just closing down a > connection. > * Orderly shutdown may be initiated by the client at any time. > * If there are pending requests when a client shuts down a > connection, the server should consider all such requests > canceled. > * A server may not initiate shutdown if it has begun processing any > requests for which it has not either received a CancelRequest or > sent a corresponding reply. > * If a client detects connection closure without receiving a > CloseConnection message, it must assume an abortive disconnect > has occurred, and treat the condition as an error. > > . > For GIOP Version 1.2 :: > > * Orderly shutdown is initiated by either the originating client > orb(connection initiator) or by the server orb (connection > responder) by reliably sending a Close Connection message > * The ORB sending the CloseConnection must not be awaiting Replies > to any Requests > * If the ORB sending the CloseConnection is a server, or > BiDirectional GIOP is in use, she sending ORB must not have begun > processing any Requests from the other side. Also add this bullet here: * If there are pending non-oneway requests when an ORB receives a CloseConnection message the receiving ORB should consider all such requests cancelled. > * The ORB which sends the CloseConnection must not send any > messages after the CloseConnection. > * If either ORB detects connection closure without receiving a > CloseConnection message, it must assume an abortive disconnect > has occurred, and treat the condition as an error. > * If bidirectional GIOP is in use, the conditions of section 15.7 > apply. > > In all uses of CloseConnection (for GIOP versions 1.0, 1.1, and > 1.2): > > * if an orb receives an CloseConnection message from its > connection-peer orb, it should assume that any outstanding > messages (i.e., without replies) were received after the > connection-peer orb sent the CloseConnection message, were not > processed, and may be safely resent on a new connection. > * After reliably issuing a CloseConnection message, the issuing > orb > may close the connection. Some transport protocols (not > including TCP) do not provide an ?orderly disconnect? > capability, > guaranteeing reliable delivery of the last message sent. When > GIOP is used with such protocols, an additional handshake needs > to be provided as part of the mapping to that protocol's > connection mechanisms, to guarantee that both ends of the > connection understand the disposition of any outstanding GIOP > requests. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Jeffrey Mischkinsky Subject: Interop 2.4 RTF Inprise vote 1 To: terrutt@lucent.com Date: Fri, 26 Feb 1999 13:57:25 -0800 (PST) Cc: terutt@lucent.com, jeffm@inprise.com, jis@fpk.hp.com, jon@biggar.org, drs@nortelnetworks.com, stephen@aptest.ie, randyfox@austin.ibm.com, janssen@parc.xerox.com, michi@triodia.com, bill@novell.com, bill.beckwith@ois.com, ed.cobb@beasys.com, Ken.Cavanaugh@Eng.Sun.COM, interop@OMG.ORG, kukura@iona.com Inprise votes as follows: YES on 543, 1129, 1653, 1948, 1975, 1978, 1982, 2045, 2315 (assuming that the vote is with my suggested change with paranthetical second sentence, No otherwise) 2324, 2333, 2338 NO on 2068, 2315 1968: C, provided it's in CORBA 2.3, a) NO otherwise (actually defer) -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Date: Sat, 27 Feb 1999 11:48:10 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies To: interop@OMG.ORG Subject: Re: Draft Final Proposal for CloseConnection Issue for Review References: <36D752AF.EC401F3@lucent.com> > Tom Rutt wrote: > > Please review the following text. After a round of comments, > closing Monday evening, If there is a agreement we can send the > final text out for final vote. > > Please comment before monday eveining, and remember we should not be > adding new > features,just clarifying the semantics of CloseConnection usage. > I just realized we also have to change the sentence in the CloseConnection clause which states that only servers can send the message. in GIOP 1.2 this is extended. Thus we also have to change that paragraph. -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- Date: Sun, 28 Feb 1999 14:13:20 PST Sender: Bill Janssen From: Bill Janssen To: terutt@lucent.com, Jonathan Biggar Subject: Re: Draft Final Proposal for CloseConnection Issue for Review CC: interop@omg.org References: <36D752AF.EC401F3@lucent.com> <36D77CEF.9F2E23B1@floorboard.com> I notice a problem with another section of this. > * After reliably issuing a CloseConnection message, the issuing orb > may close the connection. Some transport protocols (not > including TCP) do not provide an ?orderly disconnect? capability, > guaranteeing reliable delivery of the last message sent. When > GIOP is used with such protocols, an additional handshake needs > to be provided as part of the mapping to that protocol's > connection mechanisms, to guarantee that both ends of the > connection understand the disposition of any outstanding GIOP > requests. Actually, TCP does not seem to provide reliable delivery of the last message sent. Take the case where the server sends a CloseConnection, then closes the TCP connection. If the client is writing to the socket during this, it will send data to a closed connection on the server. The server will then respond with a TCP reset. This reset ``jumps the queue'', and instead of seeing the CloseConnection message on its next read on the socket, the client will see an ECONNRESET error. This means that one side may still see connection failures while the other side presumes to have sent an orderly shutdown. Bill Sender: jon@floorboard.com Date: Sun, 28 Feb 1999 14:49:41 -0800 From: Jonathan Biggar X-Accept-Language: en To: Bill Janssen CC: terutt@lucent.com, interop@omg.org Subject: Re: Draft Final Proposal for CloseConnection Issue for Review References: <36D752AF.EC401F3@lucent.com> <36D77CEF.9F2E23B1@floorboard.com> Bill Janssen wrote: > > I notice a problem with another section of this. > > > * After reliably issuing a CloseConnection message, the issuing > orb > > may close the connection. Some transport protocols (not > > including TCP) do not provide an ?orderly disconnect? > capability, > > guaranteeing reliable delivery of the last message sent. When > > GIOP is used with such protocols, an additional handshake > needs > > to be provided as part of the mapping to that protocol's > > connection mechanisms, to guarantee that both ends of the > > connection understand the disposition of any outstanding GIOP > > requests. > > Actually, TCP does not seem to provide reliable delivery of the last > message sent. Take the case where the server sends a > CloseConnection, > then closes the TCP connection. If the client is writing to the > socket > during this, it will send data to a closed connection on the server. > The server will then respond with a TCP reset. This reset ``jumps > the > queue'', and instead of seeing the CloseConnection message on its > next > read on the socket, the client will see an ECONNRESET error. This > means > that one side may still see connection failures while the other side > presumes to have sent an orderly shutdown. This is actually dependent on the TCP implementation. Some throw away any data pending to read when the ECONNRESET occurs, others keep it. It would be best to document this using the TCP standard rather than the sockets implementation of it anyway. In the real TCP standard, each direction of the connection can be shutdown (i.e. send a FIN) independently. In practice, for sockets, use the shutdown() call instead, with the argument 1, which means close the sending side only. I would rewrite this paragraph like this: * After reliably issuing a CloseConnection message, the issuing orb may close the connection. Some transport protocols (not including TCP) do not provide an "orderly disconnect" capability, guaranteeing reliable delivery of the last message sent. When GIOP is used with such protocols, an additional handshake needs to be provided as part of the mapping to that protocol's connection mechanisms, to guarantee that both ends of the connection understand the disposition of any outstanding GIOP requests. For TCP, the orb should only shutdown the sending side of the connection, and then read and discard any incoming data until it receives an indication that the other side has also shutdown. At this point, the TCP connection can be closed completely. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 1 Mar 1999 09:16:23 +1000 (EST) From: Michi Henning To: Bill Janssen cc: terutt@lucent.com, Jonathan Biggar , interop@omg.org Subject: Re: Draft Final Proposal for CloseConnection Issue for Review Organization: Triodia Technologies On Sun, 28 Feb 1999, Bill Janssen wrote: > Actually, TCP does not seem to provide reliable delivery of the last > message sent. Take the case where the server sends a > CloseConnection, > then closes the TCP connection. If the client is writing to the > socket > during this, it will send data to a closed connection on the > server. > The server will then respond with a TCP reset. This reset ``jumps > the > queue'', and instead of seeing the CloseConnection message on its > next > read on the socket, the client will see an ECONNRESET error. This > means > that one side may still see connection failures while the other side > presumes to have sent an orderly shutdown. Hmmm... The solution to this would be to require the sending side to wait for the connection to be closed by the receiving end. In case the receiving end is catatonic, the sending side should probably use a timeout to avoid getting stuck. Cheers, Michi. Date: Sun, 28 Feb 1999 18:35:34 -0500 From: Bob Kukura Organization: IONA Technologies X-Accept-Language: en To: Michi Henning CC: Bill Janssen , terutt@lucent.com, Jonathan Biggar , interop@omg.org Subject: Re: Draft Final Proposal for CloseConnection Issue for Review References: Michi Henning wrote: > > On Sun, 28 Feb 1999, Bill Janssen wrote: > > > Actually, TCP does not seem to provide reliable delivery of the > last > > message sent. Take the case where the server sends a > CloseConnection, > > then closes the TCP connection. If the client is writing to the > socket > > during this, it will send data to a closed connection on the > server. > > The server will then respond with a TCP reset. This reset ``jumps > the > > queue'', and instead of seeing the CloseConnection message on its > next > > read on the socket, the client will see an ECONNRESET error. This > means > > that one side may still see connection failures while the other > side > > presumes to have sent an orderly shutdown. > > Hmmm... The solution to this would be to require the sending side to > wait > for the connection to be closed by the receiving end. In case the > receiving > end is catatonic, the sending side should probably use a timeout to > avoid > getting stuck. The resolution to issue 543 quoted below is intended to make the behaviour Michi describes conformant, but not required. I believe that issue 543, which I submitted, is exactly the same situation Bill described. If anyone cares to tighten up the requirements even more for GIOP 1.2, I'd probably go along, but I don't think we can require any particular timeout value (i.e. a timeout of 0 is equivalent to closing immediately). > Issue 543: IIOP server-initiated connection closure problem (interop) > > Click here for this issue's archive. > Source: IONA (Mr. Robert Kukura, kukura@iona.com) > Nature: Uncategorized > Severity: > Summary: On several operating systems the client's writing of Request message after CloseConnection message can cause the > unread CloseConnection message to be discarded from buffer > Resolution: Clarify behaviour of server closure to allow other options to avoid problems with some TCP/IP platforms > Proposed Revised Text: change > " > After sending (or receiving) a CloseConnection message, both client or server must > close the TCP/IP connection. > " > to > " > After receiving a CloseConnection message, an orb must close the TCP/IP connection. After sending a CloseConnection, an orb > may close the TCP/IP connection immediately, or may delay closing the connection until it receives an indication that the other side > has closed the connection. > " > Actions taken: > April 16, 1997: received issue > > -Bob Date: Sun, 28 Feb 1999 18:02:14 PST Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Jonathan Biggar Subject: Re: Draft Final Proposal for CloseConnection Issue for Review CC: terutt@lucent.com, interop@omg.org References: <36D752AF.EC401F3@lucent.com> <36D77CEF.9F2E23B1@floorboard.com> <36D9C805.2A2A4429@floorboard.com> Excerpts from direct: 28-Feb-99 Re: Draft Final Proposal fo.. Jonathan Biggar@floorboa (2706*) > This is actually dependent on the TCP implementation. Some throw away > any data pending to read when the ECONNRESET occurs, others keep it. Yes, Jon, I agree with this. Unfortunately, a lot of operating systems have this implementation policy in their TCP stack. > For TCP, the orb should only shutdown the sending side > of the connection, and then read and discard any incoming data > until > it receives an indication that the other side has also > shutdown. This works, but is not a particularly satisfactory solution. If I'm closing a connection in order to reclaim a UNIX file descriptor, I'm not going to want to wait for some (possibly flaky) client software to acknowledge that shutdown. As Michi suggests, some form of timeout, chosen by the side originating the shutdown, is necessary. But if so, there's still the possibility of connection errors on TCP. I don't think there's a real solution here. All we can do is minimize the number of connection failures we generate; I doubt we should attempt to completely eliminate them. I'd be happy to have someone present a real solution, though. Bill Date: Wed, 3 Mar 1999 18:10:05 PST Sender: Bill Janssen From: Bill Janssen To: jeffm@inprise.com, jis@fpk.hp.com, kukura@iona.com, terutt@lucent.com, jon@biggar.org, drs@nortelnetworks.com, stephen@aptest.ie, randyfox@austin.ibm.com, janssen@parc.xerox.com, michi@triodia.com, bill@novell.com, bill.beckwith@ois.com, ed.cobb@beasys.com, Ken Cavanaugh , terutt@lucent.com Subject: Re: Interop 2.4 RTF Vote 2 (due Friday) CC: interop@omg.org References: <36CDCCC8.A56C7C0B@lucent.com> <36CDDE9C.660B21B0@lucent.com> <36CDE13C.C5FA5660@lucent.com> <36D5B46F.23437F78@lucent.com> <36DC6033.5BDACD0D@lucent.com> Xerox votes Yes on 665a, 2338, and 2495. No on 543b: I feel that the wording ("should") is too constraining. A server which is shutting down a connection usually has a reason for doing so. It doesn't necessarily want to wait for a flaky client to acknowledge its request. This is particularly true in a real-world setting where a server might have to service lots and lots of clients. I'd vote Yes if the words "it is recommended that an orb should" were changed to "an ORB may wish to". No on 1968: The proposed wording is not factually correct (TCP *does* have delivery problems around closes), and the discussion on this point has not yet reached a satisfactory conclusion. (Incidentally, my colleague Mike Spreitzer has raised this issue on the TCP implementors mailing list.) In addition, I'm not sure that requiring "orderly shutdown" is a good idea, from a scalability point of view. I also take issue with the phrasing of ``If the ORB sending the CloseConnection is a server, [...], the sending ORB must not have begun processing any Requests from the other side.'' I presume what's really meant is that the sending ORB must not currently *be* processing any requests from the other side. The way it's written, it means that the ORB may not send CloseConnection if it's *ever* processed any requests. Abstain on 2315: I think the discussion on the exact wording is still in progress. I have confidence that the worked-out example will be OK, but don't care to approve it in absentia. Bill Cc: jeffm@inprise.com, jis@fpk.hp.com, kukura@iona.com, jon@biggar.org, drs@nortelnetworks.com, stephen@aptest.ie, randyfox@austin.ibm.com, michi@triodia.com, bill@novell.com, bill.beckwith@ois.com, ed.cobb@beasys.com, Ken Cavanaugh , interop@omg.org Date: Thu, 04 Mar 1999 14:57:21 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies - Bell Labs To: Bill Janssen Original-CC: jeffm@inprise.com, jis@fpk.hp.com, kukura@iona.com, jon@biggar.org, drs@nortelnetworks.com, stephen@aptest.ie, randyfox@austin.ibm.com, michi@triodia.com, bill@novell.com, bill.beckwith@ois.com, ed.cobb@beasys.com, Ken Cavanaugh , interop@omg.org Subject: Re: Interop 2.4 RTF Vote 2 (due Friday) References: <36CDCCC8.A56C7C0B@lucent.com> <36CDDE9C.660B21B0@lucent.com> <36CDE13C.C5FA5660@lucent.com> <36D5B46F.23437F78@lucent.com> <36DC6033.5BDACD0D@lucent.com> Bill Janssen wrote: > > > No on 543b: I feel that the wording ("should") is too > constraining. A > server which is shutting down a connection usually has a reason for > doing so. It doesn't necessarily want to wait for a flaky client to > acknowledge its request. This is particularly true in a real-world > setting where a server might have to service lots and lots of > clients. > I'd vote Yes if the words "it is recommended that an orb should" > were > changed to "an ORB may wish to". I can accept Bill's Rewording as an editorial fix > > No on 1968: .. I also take > issue with the phrasing of ``If the ORB sending the CloseConnection > is a > server, [...], the sending ORB must not have begun processing any > Requests from the other side.'' I presume what's really meant is > that > the sending ORB must not currently *be* processing any requests from > the > other side. The way it's written, it means that the ORB may not > send > CloseConnection if it's *ever* processed any requests. > I can agree with Bill's rewording as an editorial fix (must not currently be processing). These words are not new, but are from Corba 2.0) > Bill -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- Date: Fri, 05 Mar 1999 11:16:21 -0500 From: Bob Kukura Organization: IONA Technologies X-Accept-Language: en To: terutt@lucent.com CC: jeffm@inprise.com, jis@fpk.hp.com, jon@biggar.org, drs@nortelnetworks.com, stephen@aptest.ie, randyfox@austin.ibm.com, janssen@parc.xerox.com, michi@triodia.com, bill@novell.com, bill.beckwith@ois.com, ed.cobb@beasys.com, Ken Cavanaugh , interop@omg.org Subject: Re: Resend Interop 2.4 RTF Vote 2 (due Friday) References: <36CDCCC8.A56C7C0B@lucent.com> <36CDDE9C.660B21B0@lucent.com> <36CDE13C.C5FA5660@lucent.com> <36D5B46F.23437F78@lucent.com> <36DC6033.5BDACD0D@lucent.com> <36DC63FC.4A4521E4@lucent.com> IONA votes as follows on votes 2 and 3: YES: 665a, 2331, 2338, 2494 2315: YES as is. NO on Vijay's ammendment. 543b: YES as is. I prefer "it is recommended that an ORB should" over "an ORB may wish to" (Bill's ammendment), but would accept this change if it was necessary to get the resolution approved. Please editorially change "imlement" to "implement". I also think this is missing context as a separate paragraph. It either needs to be appended to the previous paragraph, or have the phrase "after sending a CloseConnection message" editorially inserted before "should only shutdown ...". 1968: YES as is or with Bill's ammendment. Also, editorially change "she" to "the" and "an CloseConnection" to "a CloseConnection". Date: Tue, 12 Jun 2001 12:41:03 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Andrew Watson CC: Juergen Boldt , interop@omg.org Subject: Re: Issue 1968 References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id f5CGbMd04934 Content-Type: text/plain; charset=iso-8859-1 X-UIDL: "?od92M`d9l8#e9JiGe9 It was closed in interop rtf 2.4 (interop/99-03-01) report. The text from the report is as follows: --- Issue 1968: CloseConnection (interop) Click here for this issue's archive. Source: DSTC (Mr. Michi Henning, michi@triodia.com) Nature: Uncategorized Issue Severity: Summary: There are quite a few words about CloseConnection in the GIOP 1.2 draft. The major change is that either end of a connection can send the message for a bi-directional connection. However, the spec doesn't say that a client *must* send a CloseConnection message to the server before closing down. It just says that it *may*. Similarly, CloseConnection is only partially defined for the server side, as far as I can see. Resolution: Clarify section 15.5.1.1 Based on a circulated proposed resolution, it was agreed to make the client use of CloseConnection required for orderly release in GIOP 1.2, given the change can be published with CORBA 2.3a. After the first vote on a proposed resolution, discussion pointed out the need to keep the semantics of a connection shutdown implicitly cancelling any pending non-oneway requests. This requires changes to section 15.8. The close connection semantics, with the proposed resolution below, are stated in 15.5.1.1, for all versions of GIOP. The text imported from the bidirectional GIOP chapter has been changed to having a close connection automatically imply cancel of outstanding requests, for all versions of GIOP. The connection closure text in 15.8 is changed to a reference to the new proposed text for 15.5.1.1 Proposed Revised Text: 15.5.1.1 Change the clause to the following, given that the output of this Interop 2.4 RTF will be adopted in time for publication of CORBA 2.3 " Connections can be closed in two ways: orderly shutdown, or abortive disconnect. For GIOP versions 1.0, and 1.1: orderly shutdown is initiated by servers reliably sending a CloseConnection message, or by clients just closing down a connection. Orderly shutdown may be initiated by the client at any time. A server may not initiate shutdown if it has begun processing any requests for which it has not either received a CancelRequest or sent a corresponding reply. If a client detects connection closure without receiving a CloseConnection message, it must assume an abortive disconnect has occurred, and treat the condition as an error. . For GIOP Version 1.2 : Orderly shutdown is initiated by either the originating client orb (connection initiator) or by the server orb (connection responder) reliably sending a Close Connection message If the ORB sending the CloseConnection is a server, or BiDirectional GIOP is in use, the sending ORB must not currently be processing any Requests from the other side. The ORB which sends the CloseConnection must not send any messages after the CloseConnection. If either ORB detects connection closure without receiving a CloseConnection message, it must assume an abortive disconnect has occurred, and treat the condition as an error. If bidirectional GIOP is in use, the conditions of section 15.7 apply. For all uses of CloseConnection (for GIOP versions 1.0, 1.1, and 1.2): If there are any pending non-oneway requests which were initiated on a connection by the ORB shutting down that connection, the connection-peer ORB should consider them as canceled. If an orb receives a CloseConnection message from its connection-peer ORB, it should assume that any outstanding messages (i.e., without replies) were received after the connection-peer ORB sent the CloseConnection message, were not processed, and may be safely resent on a new connection. After reliably issuing a CloseConnection message, the issuing orb may close the connection. Some transport protocols (not including TCP) do not provide an "orderly disconnect" capability, guaranteeing reliable delivery of the last message sent. When GIOP is used with such protocols, an additional handshake needs to be provided as part of the mapping to that protocol's connection mechanisms, to guarantee that both ends of the connection understand the disposition of any outstanding GIOP requests. " In section 15.4.6 (CloseConnection): Change the sentence: " In GIOP version 1.2, if BiDirectional GIOP ( 15-48) is in use, both sides of the connection may send the CloseConnection message. " to the following: " In GIOP version 1.2, both sides of the connection may send the CloseConnection message. " In Section 15.8, Change the paragraph: " CloseConnection messages are a special case however. Either ORB may send a CloseConnection message, but the conditions see in on page 15-41, are modified for GIOP version 1.2, in that the ORB sending the CloseConnection must not be awaiting Replies to any Requests, and must not have begun processing any Requests from the other side. If these conditions are satisfied and the ORB sends a CloseConnection, the ORB on the opposite side must assume that any outstanding Requests it has sent were not processed and may be resent on a new connection. The ORB which sends the CloseConnection must not send any messages after the CloseConnection. It may also close the connection, although the caveats regarding protocols which do not implement "orderly shutdown" " to " CloseConnection messages are a special case however. Either ORB may send a CloseConnection message, but the conditions in in on page 15-41, apply. " Actions taken: September 18, 1998: received issue March 8, 1999: Close by incorporation of proposed change into CORBA 2.3 Publication --------------- Andrew Watson wrote: > > Juergen, > > Please can you check the status of issue 1968? If looks as though the > Interop RTF resolved it in a previous report, but it hasn't been flagged as > resolved in the database (?). > > Thanks, > > Andrew > > Date: Sun, 10 Jun 2001 07:59:54 +1000 (EST) > From: Michi Henning > To: Jonathan Biggar > cc: jishnu_mukerji@hp.com, "Rutt, T E (Tom)" , > Bob Kukura , Interoperability RTF > Subject: Re: Urgent Issue Vote 1 Interop Dec2000 > Organization: IONA Technologies > MIME-Version: 1.0 > > On Fri, 8 Jun 2001, Jonathan Biggar wrote: > > > > Good catch Bob. I missed that one. > > > > > > I would like to change HP's vote on 4311 to NO. > > > > Ditto for Floorboard. My reading of section 15.4.7 and 15.5.1.1 is that > > it is absolutely clear that a CloseConnection *must* be sent by a GIOP > > 1.2 client for orderly shutdown even without bidirctional GIOP under the > > current specification. > > That is my reading too, and that was the intent when we resolved the > corresponding issue. See http://cgi.omg.org/issues/interop.html#Issue1968. > (Strange -- the issue is still marked as open in the issue database, but > I distinctly remember voting on this and making the change to the spec. > What's up with that?) > > Cheers, > > Michi. > -- > Michi Henning +61 7 3324 9633 > Chief CORBA Scientist +61 4 1118 2700 (mobile) > IONA Technologies +61 7 3324 9799 (fax) > Total Business Integration http://www.ooc.com.au/staff/michi -- ---------- Tom Rutt Tel: +1 732 949 7862 Global Strategic Standards Fax: +1 732 949 1192 Lucent Technologies terutt@lucent.com