Issue 543: IIOP server-initiated connection closure problem (interop) Source: (, ) Nature: Uncategorized Severity: Summary: 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: resolved, see above 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. For maximum interoperability with ORBs using TCP implementations which do not properly implement orderly shutdown, an ORB may wish to only shutdown the sending side of the connection, and then read any incoming data until it receives an indication that the other side has also shutdown, at which point the TCP connection can be closed completely. " Actions taken: April 16, 1997: received issue March 8, 1999: closed issue Discussion: Clarify behaviour of server closure to allow other options to avoid problems with some TCP/IP platforms As a result of discussion on issue 2338, a recommendation for maximum interoperability using TCP/IP was proposed to be added to the GIOP text End of Annotations:===== Return-Path: From: kukura@apollo.hp.com Date: Tue, 15 Apr 1997 20:41:48 -0400 Subject: IIOP server-initiated connection closure problem Errors-To: owner-interop Sender: owner-interop X-OMG: interop To: interop I've mentioned this issue a few times, but I'm not sure it made it into the official Interop 1.2 RTF issues database, so here it is: IIOP server-initiated connection closure problem As long as it is not in the middle of processing any requests, an IIOP server can initiate a graceful connection closure by sending a CloseConnection message and then closing its end of the connection. Before reading the CloseConnection message, an IIOP client might send a new Request message over the that connection. Then, by reading the CloseConnection message, the client is assured that the server did not begin processing that request, and that it can safely attempt to rebind and reissue the request without violating CORBA's at-most-once semantics. Unfortunately, on several popular operating systems, the client's writing of the Request message, after the CloseConnection message and connection closure indication have been received by the TCP/IP implementation but before they have been read by the IIOP implementation, can cause the received but unread CloseConnection message to be discarded from the buffer. This prevents the IIOP client from transparently rebinding and requires a system exception, such as COMM_FAILURE, with a completion status of MAYBE, to be returned to the application. It might be necessary to require the server to wait, before closing its end of the connection, for some sort of acknowledgment from the client that it read the CloseConnection message, at least when the client is on an operating system that exhibits this behaviour. -Bob -- Robert A. Kukura Internet Technology Lab email: kukura@apollo.hp.com Hewlett-Packard Company phone: 508-436-4512 300 Apollo Drive CHR-03-WR fax: 508-436-5176 Chelmsford, MA 01824 Return-Path: Date: Wed, 10 Dec 1997 16:49:32 -0500 From: ter@holta.ho.lucent.com (T E Rutt) To: interop@omg.org Subject: Interop 1.2 RTF Conference call (Proposed revisions and issues) To: Interop 1.2 RTF Subject: Dec 19, Conference Call From: Tom Rutt, RTF Chair I have attached my proposed Resolutions of Issues for ORB Interoperability 1.2 Revision Task Force. There was no meeting of the RTF at the NJ meeting, since everyone is so busy I decided to take a whack at coming up with resolutions for the issues. We need further discussion on some of these issues, as indicated in the actions section of each issue. A conference Call is scheduled for Friday, December 19, at 11:00 EST. I have the bridge reserved for 2 hours. The bridge phone number (16 ports reserved) is: +1 630 224 444 Conference Code 674 369 Let me know if you will participate, so I can ensure 16 is enough ports. Tom Rutt Issue 543: IIOP server-initiated connection closure problem (interop) 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: This is not a problem with the protocol, but with the apis. The application should avoid such behaviour, for portability, but is this a protocol issue? Revised Text: Actions taken: Proposed No revision. April 16, 1997: received issue 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".