Issue 488: Problem with GIOP CancelRequest when fragments are used (interop) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Potential problem in determining whether CancelRequest message applies to the current message or a message that has already had a reply sent. Resolutions to this: (file) Resolution: closed with revised text Revised Text: Actions taken: January 30, 1997: received issue March 26, 1998: closed issue Discussion: End of Annotations:===== 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 488: Problem with GIOP CancelRequest when fragments are used (interop) Source: (, Paul.Patrick@beasys.com) Nature: Uncategorized Severity: Summary: Potential problem in determining whether CancelRequest message applies to the current message or a message that has already had a reply sent. Resolutions to this: (file) Resolution: The GIOP text states the client must managed its use of request ids to avoid this problem. If the client does not reuse requestIds in the same connection until the associated reply is received, it does not seem that this problem would happen. Revised Text: Actions taken: Proposed No revision. January 30, 1997: received issue Return-Path: From: "Daniel R. Frantz" To: "'T E Rutt'" , "interop@omg.org" Cc: "Paul Patrick (E-mail)" , "Me (E-mail)" Subject: RE: Interop 1.2 RTF Conference call (Proposed revisions and issues) Date: Fri, 19 Dec 1997 10:40:07 -0500 Issue 488 doesn't seems to have the body on the OMG site, leading Tom to misinterpret what we meant. See below. >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. >Issue 488: Problem with GIOP CancelRequest when >fragments are used (interop) > >Source: (, Paul.Patrick@beasys.com) >Nature: Uncategorized >Severity: >Summary: Potential problem in determining whether >CancelRequest message >applies to the current message or a message that has already >had a reply sent. >Resolutions to this: (file) >Resolution: The GIOP text states the client must managed its >use of request ids to avoid this problem. If the client >does not reuse requestIds in the same connection until the >associated reply is received, it does not seem that this >problem would happen. >Revised Text: >Actions taken: Proposed No revision. >January 30, 1997: received issue The problem is this: Site A sends a message to site B, fragmenting the message. The problem comes when the service context is very long and fragmentation occurs in the middle of the service context. Given the definition: // GIOP 1.1 struct RequestHeader_1_1 { IOP::ServiceContextList service_context; unsigned long request_id; boolean response_expected; octet reserved[3]; // Added in GIOP 1.1 sequence object_key; string operation; Principal requesting_principal; }; The request_id doesn't appear until the second (or later) fragment. If the client ORB sends the cancel message before the request_id of the fragmented message reaches the target ORB, what does the target ORB do? There are several potential resolutions to this (quoted from our original mail). 1. We could be missing something obvious which handles this case and therefore, no resolution is needed, just a clarification. 2. Ignore it due to the chances that this would happen are slim. 3. Make more rigid specification of how and where a message can be fragmented. This includes at least the option of saying that a message can not be fragmented in its header and only in its body. 4. Refine when it is valid for a CancelRequest message to be sent when there are Fragments which have not been sent. This includes all of the following options: a. Specify that a CancelRequest message cannot be sent unless the Fragment that includes the RequestID has been sent. b. Specify that a CancelRequest message cannot be sent unless all of the Fragments which make up the header of a Request or LocateRequest message have been sent. c. Specify that a CancelRequest message cannot be sent unless all of the Fragments have been sent. 5. Specify that if a message with fragments is in progress when a CancelRequest message is sent over a Connection, that the message in progress is cancelled as well as the one mentioned in the CancelRequest message. (NOTE: the messages may be one and the same). 6. Specify that if a message with fragments is in progress when a CancelRequest message is sent over a Connection, that only the message in progress is cancelled. -------------------------------------------------- Dan Frantz BEA Systems, Inc. 436 Amherst St. Nashua, NH 03063 Voice:(603)579-2519 Fax:(603)579-2510