Issue 6283: CodeSet and CSIv2 Negotitaion (corba-rtf) Source: Adiron, LLC (Mr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Summary: I believe that we send CSIv2 stuff in a GIOP Request until a corresponding GIOP reply has been containing corresponding CSIv2 context ids is sent. For Codeset, I think the policy is to send the service context in each GIOP request until a corresponding GIOP Reply is received, thereby saying that the "negotiation" is completed and excepted (otherwise an exception will be raised. We should probably look at the fact that multiple NSReq messages can be sent, and there are no corresponding reply messages depending on the service contexts. I think that these messages should be intercepted since they are delivering service contexts. Resolution: Revised Text: Actions taken: October 2, 2003: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== X-Authentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Thu, 2 Oct 2003 15:01:14 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: corba-rtf@omg.org Subject: CodeSet and CSIv2 Negotitaion I believe that we send CSIv2 stuff in a GIOP Request until a corresponding GIOP reply has been containing corresponding CSIv2 context ids is sent. For Codeset, I think the policy is to send the service context in each GIOP request until a corresponding GIOP Reply is received, thereby saying that the "negotiation" is completed and excepted (otherwise an exception will be raised. We should probably look at the fact that multiple NSReq messages can be sent, and there are no corresponding reply messages depending on the service contexts. I think that these messages should be intercepted since they are delivering service contexts. Thoughts? -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 02 Oct 2003 12:42:59 -0700 From: Jonathan Biggar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: corba-rtf@omg.org Subject: Re: CodeSet and CSIv2 Negotitaion Polar Humenn wrote: I believe that we send CSIv2 stuff in a GIOP Request until a corresponding GIOP reply has been containing corresponding CSIv2 context ids is sent. I agree. For Codeset, I think the policy is to send the service context in each GIOP request until a corresponding GIOP Reply is received, thereby saying that the "negotiation" is completed and excepted (otherwise an exception will be raised. I agree (but the word is "accepted"). We should probably look at the fact that multiple NSReq messages can be sent, and there are no corresponding reply messages depending on the service contexts. I think that these messages should be intercepted since they are delivering service contexts. Yes, I think so too. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Authentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Thu, 2 Oct 2003 19:05:01 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: Jonathan Biggar cc: corba-rtf@omg.org, firewall-traversal-ftf@omg.org Subject: Re: CodeSet and CSIv2 Negotitaion On Thu, 2 Oct 2003, Jonathan Biggar wrote: > Polar Humenn wrote: > > I believe that we send CSIv2 stuff in a GIOP Request until a corresponding > > GIOP reply has been containing corresponding CSIv2 context ids is sent. > > I agree. > > > For Codeset, I think the policy is to send the service context in each > > GIOP request until a corresponding GIOP Reply is received, thereby saying > > that the "negotiation" is completed and excepted (otherwise an exception > > will be raised. > > I agree (but the word is "accepted"). Opps. I'm probably too frazzeled and righting fonetically. :^) > > > We should probably look at the fact that multiple NSReq messages can be > > sent, and there are no corresponding reply messages depending on the > > service contexts. > > > > I think that these messages should be intercepted since they are > > delivering service contexts. > > Yes, I think so too. I thought about this over lunch, and I'm not quite sure. There really two kinds of Service Contexts. 1. Session Oriented 2. Request Oriented For example, the CodeSet may be transmitted with GIOP Requests, but they are in a sense only related to the request once they are set (can they be reset?), i.e. with the ongoing session. Others are strictly request oriented. So, looking at the current document let's look Num Title Req/Rep Session 0 TransactionService X 1 Codeset X 2 ChainBypassCheck X 3 ChainBypassinfo X 4 LogicalThreadId X 5 BI_DIR_IIOP X (will be deprecated) 6 SendingContextRuntime X 7 INVOCATION_POLICIES X 8 FORWARDED_IDENTITY X (will be deprecated) 9 UnknownExceptionInfo X 10 RTCorbaPriority X 11 RTPriorityRange X 12 FT_GROUP_VERSION X 13 FT_REQUEST X 14 ExceptionDetailMessage X 15 SecurityAttributeService X * 16 ActivityService X * The SecurityAttributeService context has "session" semantics, but only in the context of each particular request. Soon to be: 20 FIREWALL_PATH X 21 FIREWALL_PATH_RESP X xx BI_DIR_GIOP_OFFER X xx BI_DIR_GIOP_CHALLENGE X xx BI_DIR_GIOP_RESPONSE X xx BI_DIR_GIOP_ERROR X xx BI_DIR_GIOP_NO_ERROR X xx BI_DIR_GIOP_ACCEPT X So, it looks like we have two kinds. Interceptors are Request Interceptors and therefore should only hold "Request" related service contexts. Session service contexts don't make much sense in this regard. Session Service Contexts, especially this BiDir animal, which can be sent at any time with or without a request has no way of getting intercepted at the request level, and not sure if the request level interceptor should be exposing these service contexts. I'm now thinking that GIOP 1.4 should just have messages for Firewall Traversal and Bidirection. If you can turn the channel around, why not have specific messages to enable it in the protocol engine, instead of doing this half-assed and complicated through interpreted service contexts which GIOP will have to follow anyway? So, doing it that way wouldn't be a new feature, just a shift of format from creating one new message, NegotiateSession with complicated ServiceContexts, to simplistic GIOP messages each with specific semantics related to the session. I would probably organize it this way. // GIOP 1.4 enum MsgType_1_4{ Request, Reply, CancelRequest, LocateRequest, LocateReply, CloseConnection, MessageError, Fragment. // GIOP 1.1 addition // GIOP 1.4 addition FirewallPathRequest, FirewallPathResponse, BiDirOffer, BiDirChallenge, BiDirResponse, }; This way, we get GIOP formally taking care of this firewall traversal problem that has plagued us for so friggin long instead of hiding it under the rugs in the service context. You should probably do the same with Codeset Negotiation. The rest of the service contexts are "Request" related and can be handled the same way. Later, we need can make complicated Session Level Interceptors and be able to introduce generic session level negotiation. That way you can assign an internal session id, and probably carry it in the Request Slot and get the associated information, such as negotiated codeset, etc. Anyway, that would probably be the subject of an RFP. Cheers, -Polar > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 02 Oct 2003 23:04:11 -0700 From: Jon Biggar User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: firewall-traversal-ftf@omg.org, corba-rtf@omg.org Subject: Re: CodeSet and CSIv2 Negotitaion Polar Humenn wrote: I think that these messages should be intercepted since they are delivering service contexts. Yes, I think so too. I thought about this over lunch, and I'm not quite sure. There really two kinds of Service Contexts. 1. Session Oriented 2. Request Oriented For example, the CodeSet may be transmitted with GIOP Requests, but they are in a sense only related to the request once they are set (can they be reset?), i.e. with the ongoing session. Others are strictly request oriented. No, CodSet is session oriented. You can't change it once it is set. [snip] This way, we get GIOP formally taking care of this firewall traversal problem that has plagued us for so friggin long instead of hiding it under the rugs in the service context. Hmmm, there's a thought. I'm not sure it really is better than having a single NegotiateSession message with service contexts. That avoids perterbing parts of the GIOP engine in the future by having to add new message types. You should probably do the same with Codeset Negotiation. The rest of the service contexts are "Request" related and can be handled the same way. Later, we need can make complicated Session Level Interceptors and be able to introduce generic session level negotiation. That way you can assign an internal session id, and probably carry it in the Request Slot and get the associated information, such as negotiated codeset, etc. Anyway, that would probably be the subject of an RFP. Ayup. But using a NegotiateSession message with service contexts leaves it more like the accepted FireWall spec and would still work with a newfangled "session" interceptor concept. Leaving them as service contexts means that things work right for sessionless communication over a datagram service, such as MIOP. So all in all, I think using service contexts is the better way to go. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Authentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Fri, 3 Oct 2003 02:17:31 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: corba-rtf@omg.org, firewall-traversal-ftf@omg.org Subject: Re: CodeSet and CSIv2 Negotitaion (fwd) ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com ---------- Forwarded message ---------- Date: Fri, 3 Oct 2003 02:11:08 -0400 (EDT) From: Polar Humenn To: Jon Biggar Subject: Re: CodeSet and CSIv2 Negotitaion On Thu, 2 Oct 2003, Jon Biggar wrote: > Ayup. But using a NegotiateSession message with service contexts leaves > it more like the accepted FireWall spec and would still work with a > newfangled "session" interceptor concept. > > Leaving them as service contexts means that things work right for > sessionless communication over a datagram service, such as MIOP. So all > in all, I think using service contexts is the better way to go. I wouldn't want to implement them that way. It's way too unwieldy. I'm effectively running all sorts of protocols in parallel affecting the ONE protocol I want set up and use. You have to make all these ordering restrictions, all which are prone to error in specifcation. You got NegotiateSession messages potentially coming out of nowhere and everywhere, containing a whole lot of other stuff, and you don't even know how to process them. And you have to sit there and analyze each one depending on whether it is supposed to be there or not. It's a typeless kludge. And believe me, if you have to implement this protocol with service contexts, its going to affect your GIOP engine anyway and slow you down to boot. What I'm suggesting is equivalent. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 02 Oct 2003 23:31:46 -0700 From: Jon Biggar User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: corba-ftf@omg.org, firewall-traversal-ftf@omg.org Subject: Re: CodeSet and CSIv2 Negotitaion Polar Humenn wrote: Ayup. But using a NegotiateSession message with service contexts leaves it more like the accepted FireWall spec and would still work with a newfangled "session" interceptor concept. Leaving them as service contexts means that things work right for sessionless communication over a datagram service, such as MIOP. So all in all, I think using service contexts is the better way to go. I wouldn't want to implement them that way. It's way too unwieldy. I'm effectively running all sorts of protocols in parallel affecting the ONE protocol I want set up and use. You have to make all these ordering restrictions, all which are prone to error in specifcation. You got NegotiateSession messages potentially coming out of nowhere and everywhere, containing a whole lot of other stuff, and you don't even know how to process them. And you have to sit there and analyze each one depending on whether it is supposed to be there or not. It's a typeless kludge. And believe me, if you have to implement this protocol with service contexts, its going to affect your GIOP engine anyway and slow you down to boot. Yes, it affects the protocol stack, but at a higher level of abstraction. What I'm suggesting is equivalent. No, it's not, because it breaks transport of GIOP over sessionless transports. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Authentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Fri, 3 Oct 2003 02:47:43 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: Jon Biggar cc: corba-ftf@omg.org, firewall-traversal-ftf@omg.org Subject: Re: CodeSet and CSIv2 Negotitaion On Thu, 2 Oct 2003, Jon Biggar wrote: > > And believe me, if you have to implement this protocol with service > > contexts, its going to affect your GIOP engine anyway and slow you down > > to boot. > > Yes, it affects the protocol stack, but at a higher level of abstraction. That's nothing when you have actually implement it down at the protocol level. > > What I'm suggesting is equivalent. > > No, it's not, because it breaks transport of GIOP over sessionless > transports. There is no such thing as a sessionless transport, unless you are sending only GIOP requests. In that case, you haven't got a problem. -Polar > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Fri, 03 Oct 2003 11:55:58 -0700 From: Jonathan Biggar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: corba-rtf@omg.org, firewall-traversal-ftf@omg.org Subject: Re: CodeSet and CSIv2 Negotitaion Polar Humenn wrote: On Thu, 2 Oct 2003, Jon Biggar wrote: And believe me, if you have to implement this protocol with service contexts, its going to affect your GIOP engine anyway and slow you down to boot. Yes, it affects the protocol stack, but at a higher level of abstraction. That's nothing when you have actually implement it down at the protocol level. From many years implementing protocol stacks, it's my opinion that it matters. The code that handles the GIOP Message type switch is at a different level of abstraction than the code that handles service contexts. The latter has to be designed to handle new types of service contexts, primarily because an interceptor can invent one any time it feels like. The same is not true of the Message type. What I'm suggesting is equivalent. No, it's not, because it breaks transport of GIOP over sessionless transports. There is no such thing as a sessionless transport, unless you are sending only GIOP requests. In that case, you haven't got a problem. I'm afraid I have no clue what you are saying here. Of course there are sessionless transports--MIOP is the primary example. Now in that case the BiDir stuff is meaningless, but the concept of a firewall service context is not. The messages that you propose to add are useless for sessionless transports. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Authentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Fri, 3 Oct 2003 15:03:00 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: corba-rtf@omg.org, firewall-traversal-ftf@omg.org Subject: Re: CodeSet and CSIv2 Negotitaion (fwd) On Fri, 3 Oct 2003, Jonathan Biggar wrote: > > That's nothing when you have actually implement it down at the protocol > > level. > > From many years implementing protocol stacks, it's my opinion that it > matters. The code that handles the GIOP Message type switch is at a > different level of abstraction than the code that handles service > contexts. That is true, I'm with you there. However, each one of these messages with a special Service Context is a special GIOP message "hiding" in the trees. > The latter has to be designed to handle new types of service > contexts, primarily because an interceptor can invent one any time it > feels like. The same is not true of the Message type. Yes, but this happens at the Request level, and that is taken care of, so far, because they travel with GIOP (or whatever messaging engine that supports them) requests and replys. > > >>>What I'm suggesting is equivalent. > >> > >>No, it's not, because it breaks transport of GIOP over sessionless > >>transports. > > > > There is no such thing as a sessionless transport, unless you are sending > > only GIOP requests. In that case, you haven't got a problem. > > I'm afraid I have no clue what you are saying here. Of course there are > sessionless transports--MIOP is the primary example. I assume you mean Unreliable Multicast? Aren't you just sending one ways? > Now in that case the BiDir stuff is meaningless, but the concept of a > firewall service context is not. Well, meaningless or not, you'd still be required to process it. Both these things require repsonses anyway. Furthermore, I don't see what breaks with MIOP? You probably wouldn't stick a Firewall Path component in the IOR of a MIOP object. Then again, perhaps you would to get to the object that is going to do the multicast. So, in that case it will be benficial. -Polar > > The messages that you propose to add are useless for sessionless transports. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com