Issue 2240: Issue for Firewall RTF - Chapter 5 needs clarification (firewall-rtf) Source: (, ) Nature: Clarification Severity: Summary: Summary: Chapter 5 - Bi-directional GIOP misled me in a number of points, even after numerous readings and a discussion with an author. I believe the chapter contains all the pertinent information; it just has to be a bit more carefully presented. Resolution: Revised Text: Actions taken: December 7, 1998: received issue Discussion: End of Annotations:===== Return-Path: From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: issues@omg.org cc: firewall-rtf@omg.org, randyfox@us.ibm.com Date: Fri, 4 Dec 1998 16:16:35 -0600 Subject: Issue for Firewall RTF - Chapter 5 needs clarification. Content-Disposition: inline Chapter 5 - Bi-directional GIOP misled me in a number of points, even after numerous readings and a discussion with an author. I believe the chapter contains all the pertinent information; it just has to be a bit more carefully presented. Page 5-2, near the middle: "The server receives the Request. If it recognizes the service context and supports bi-directional connections, it may send invocations on this object back along the connection." It was not immediately clear to me what "recognizes the service context" meant. I understand this paragraph is an overview, so it can't be too deep. How about this? "The server receives the Request. If it supports bi-directional connections, it may send invocations on this object back along the connection if the information in the service context indicates that it may do so." Page 5-3, first paragraph of section 5.1.1 "The IOP::ServiceContext used to support bi-directional IIOP contains a BiDirIIOPServiceContext structure as defined below:" The discussion in this section assumes that the server supports bi-directional connections. Granted, this section is rather meaningless without that assumption, but it doesn't take much to make it clear. "Once a server has decided to support bi-directional connections, it will make use of the bi-directional service context. The IIOP::ServiceContext used to support bi-directional IIOP contains a BiDirIIOPServiceContext structure as defined below:" A note appears in the first paragraph on page 5-4. This note is good and should stay. But I like to make something like this apparent as early as possible. Page 5-3, bottom paragraph: "The data encapsulated in the BiDirIIOPServiceContext structure allows the ORB, which intends to open a new connection in order to invoke on an object, to look up its list of active client-initiated connections and examine the structures associated with them, if any. If a host and port pair in a listen_points list matches a host and port which the ORB intends to open a connection to, rather than open a new connection to that listen_point, the server may re-use any of the connections that were initiated by the client on which the listen point data was received." I was misled by the phrase, use here twice: the ORB intends to open a new connection. My interpretation was that once the ORB sees a BI_DIR_IIOP service context, it's first inclination is NOT to intend to open a new connection. It assumes that it will find a match in the ListPointsList (otherwise it wouldn't bother looking in the ListPointsList). Only when it doesn't find a match will it intend to open a new connection. Granted, this may be a pure interpretation quirk on my part (since I DIDN'T immediately make the assumption noted in my previous bullet), but how about a little rewrite: "The data encapsulated in the BiDirIIOPServiceContext structure allows the ORB to determine whether it needs to open a new connection in order to invoke on an object. If a host and port pair in a listen_points list matches a host and port of an object to which it does not yet have a connection (a callback object newly received, for instance), rather than open a new connection, the server may re-use any of the connections that were initiated by the client on which the listen point data was received." Thanks Russell Butek butek@us.ibm.com From: Paul Kyzivat To: "'mchapman@iona.com'" , firewall-rtf@omg.org Subject: RE: Round 1 Date: Mon, 29 Nov 1999 10:37:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Attached is an html file that will form the basis of vote 1. > I have drafted responses to 7 of the issues. You have until > next Friday (3 dec) to comment and suggest alternatives, > and then i will put what we have out for a vote. I think this is still misleading even with the changes. The actual mechanism affects all IORs containing the address sent in the bidir context, not just those passed in a request to the server. Describing the functionality without pointing that out is misleading. This probably can't be fully straightened out until we finish deciding how the policies should work. But I am thinking of a wording like: "The client exports the IOR, as a parameter of a GIOP Request on the server object or by some other means." "If the ORB policy [TERMINOLOGY MAY NEED SOME WORK] permits bi-directional use of a connection to receive requests, a Request message to the server should contain an IOP::ServiceContext message in the Request header which indicates information that the server needs to identify IORs that may be invoked via bi-directional use of the client's connection to the server. (To determine whether an ORB may support bi-directional use of a connection to receive requests, TBD.)" ... "The server receives a Request containing a bi-directional service context. If the server supports bi-directional use of connections to send requests, it may send invocations back along the connection on any objects exported by the client with addresses matching the service context." Reply-To: From: "Martin Chapman" To: "Paul Kyzivat" , Subject: RE: Round 1 Date: Mon, 29 Nov 1999 16:19:50 -0000 Message-ID: <002c01bf3a85$8fe25760$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-reply-to: <9B164B713EE9D211B6DC0090273CEEA91401ED@bos1.noblenet.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: &c#e9g(Zd9-?&!!4$Ne9 Paul, Could you be more precise in what text you want changed. Is this against the proposed resolution text or additions of new text to the resolution - if it's the latter can you provide references (section, page, para #) to the text that you want changed/added. Without this we risk not being able to track precise changes when it comes to voting. Cheers, Martin. > -----Original Message----- > From: Paul Kyzivat [mailto:paulk@roguewave.com] > Sent: 29 November 1999 15:37 > To: 'mchapman@iona.com'; firewall-rtf@omg.org > Subject: RE: Round 1 > > > Re: Issue 2240 > > > Attached is an html file that will form the basis of vote 1. > > I have drafted responses to 7 of the issues. You have until > > next Friday (3 dec) to comment and suggest alternatives, > > and then i will put what we have out for a vote. > > I think this is still misleading even with the changes. > The actual mechanism affects all IORs containing the address > sent in the bidir context, not just those passed in a request > to the server. Describing the functionality without pointing > that out is misleading. > > This probably can't be fully straightened out until we finish > deciding how the policies should work. But I am thinking of > a wording like: > > "The client exports the IOR, as a parameter of a GIOP Request on > the server > object or by some other means." > > "If the ORB policy [TERMINOLOGY MAY NEED SOME WORK] permits > bi-directional > use of a connection to receive requests, a Request message to the > server > should contain an IOP::ServiceContext message in the Request header > which > indicates information that the server needs to identify IORs that > may be > invoked via bi-directional use of the client's connection to the > server. (To > determine whether an ORB may support bi-directional use of a > connection to > receive requests, TBD.)" > > ... > > "The server receives a Request containing a bi-directional > service context. > If the server supports bi-directional use of connections to send > requests, > it may send invocations back along the connection on any objects > exported by > the client with addresses matching the service context." > Date: Mon, 29 Nov 1999 17:40:43 +0000 From: Owen Rees To: mchapman@iona.com, firewall-rtf@omg.org Subject: RE: Round 1 - Issue 2240 Message-ID: <3299405676.943897243@ews-proj-2.hpl.hp.com> In-Reply-To: <001701bf3a6e$650b0da0$4d01020a@leo.dublin.iona.ie> Originator-Info: login-id=ore; server=ticb.hpl.hp.com X-Mailer: Mulberry (Win32) [1.4.3, s/n P005-300802-001] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: kE>e9AR=e9~VIe9EXed9 --On 29 November 1999, 13:34 +0000 Martin Chapman wrote: > Issue 2240: Issue for Firewall RTF - Chapter 5 needs clarification > (firewall-rtf) > > Click here for this issue's archive. > Nature: Clarification > Severity: > Summary: Chapter 5 - Bi-directional GIOP misled me in a number of > points, > even after Resolution: improved clarity the text (giop chapter 15 > in > corba 2.3.1) I don't think we can deal with this in isolation from issue 2633 since that affects the same parts of the text and deals with related issues. > > Note I didn't change text related to the page 5-3 first para of > 5.1.1 > (see archive). Since this para just defines bidirservice context, > when, > why and how it is used is adequately explained in the preceeding > section. > > > Revised Text: > > Section 15.8 page 15-53(of corba 2.3.1) , para 7: > > Replace: "The server receives the Request. If it recognizes the > service > context and supports bi-directional connections, it may send > invocations > on this object back along the connection." > > With: "The server receives the Request. If the server supports > bi-directional connections, it may send invocations on this object > back > along the connection if the information in the service context > indicates > that it may do so." This relates back to para 5 on page 15-53 which has started from the assumption that *one* request contained both an IOR and a service context with the bidir data. The wording "this object" in the proposed replacement text suggests that it matters that the IOR was in the request - my interpretation of previous discussion of issue 2633 is that this is irrelevant and all that matters is that the host/port in the IOR match a listen_point in the service context. I would prefer replacement text more like this: With: "The server receives the Request which contains an IOP::ServiceContext. If the server supports bi-directional connections, it may send invocations on any object whose reference matches the data in the service context back along this connection." I would also replace para 4 and part of para 5 to clarify the point: Replace: "The client creates an object for exporting to a server. The client exports the IOR as a parameter of a GIOP Request on the server object. If the ORB policy permits bi-directional use of a connection, a Request message should contain an IOP::ServiceContext structure in its Request header, which indicates that this GIOP connection is bi-directional." With: "The client creates an object for exporting to a server, and arranges that the server receive an IOR for the object. The most common case would be for the client to pass the IOR as a parameter in a GIOP request. If the client ORB policy permits bi-directional use of a connection, a Request message on that connection should contain an IOP::ServiceContext structure in its Request header, which indicates that this GIOP connection is bi-directional." > > Section 15.8 page 15-53 (of corba 2.3.1), para 8: > > Replace: "In this case, it may fall back to initiating a connection > in > the usual way." > > With: "In this case, it may fall back to initiating a connection in > the > usual way, and only host/port information found in the IOR can be > used. > > Section 15.8.1 page 15-54 (of corba 2.3.1), para 2: > > Replace: "The data encapsulated in the BiDirIIOPServiceContext > structure > allows the ORB, which intends to open a new connection in order to > invoke > on an object, to look up its list of active client-initiated > connections > and examine the structures associated with them, if any. If a host > and > port pair in a listen_points list matches a host and port which the > ORB > intends to open a connection to, rather than open a new connection > to > that listen_point, the server may re-use any of the connections that > were > initiated by the client on which the listen point data was > received." > > With: "The data encapsulated in the BiDirIIOPServiceContext > structure > allows the ORB to determine whether it needs to open a new > connection in > order to invoke on an object. If a host and port pair in a > listen_points > list matches a host and port of an object to which it does not yet > have a > connection (a callback object newly received, for instance), rather > than > open a new connection, the server may re-use any of the connections > that > were initiated by the client on which the listen point data was > received." Delete "that were initiated by the client " from the replacement text. The server has no way to relate connections to clients so it must decide purely on whether or not the matching listen_point data was received on a connection. The text to be replaced does not match the document - "which is identified .. page 13.22," is missing after the first "structure" - this text should remain in the replacement. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 29 Nov 1999 13:30:56 -0500 (EST) From: Polar Humenn To: Martin Chapman cc: firewall-rtf@omg.org Subject: RE: Round 1 In-Reply-To: <001701bf3a6e$650b0da0$4d01020a@leo.dublin.iona.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 2b2e9O^`d92/?e9UcR!! Issue 2240: With: "The server receives the Request. If the server supports bi-directional connections, it may send invocations on this object back along the connection if the information in the service context indicates that it may do so." I don't see what the context of "object" is here, i.e. what "object", where? Perhaps the paragraph and the following one "The server may not support ..." should be merged into one: "The server receives a Request with the BirDir service context. If the server supports bi-directional connections for that protocol, it may now send invocations along the same connection to any object that supports the particular protocol and matches the particular location information found in the BirDir service context. If the server does not support bi-directional connections for that protocol, the service context is effectively ignored." Question: I imagine that a BiDir service context is illegal in a situation where we are now sending Requests to a client? :) ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com