Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages

From: "Bob Gezelter" <[email-masked]>
Date: Tue, 16 Aug 2011 08:32:31 -0700

Tobias,

Without having the time for a re-read at this instant, I will presume
that John's comments about no explicit binding (insofar as the protocol
specification is concerned) between the data and control channels in a
connection.

As a general matter, I would be reluctant to rely upon seeming
connections between the control and the data channels. The connections
between control and data can conceivably be disconnected in any number
of ways (see my recent comment about "gateways"; I would not advocate
attempting to clone and correspondingly coalesce control frames and
their responses at gateways). 

Even within a single destination endpoint, I do not see any reason for
presuming a relationship between OnMessage and OnControl.

- Bob Gezelter, http://www.rlgsc.com

> -------- Original Message --------
> Subject: AW: [hybi] Intermedaries: coalescing with interleaved control
> messages
> From: Tobias Oberstein <[email-masked]>
> Date: Tue, August 16, 2011 8:20 am
> To: John Tamplin <[email-masked]>
> Cc: Bob Gezelter <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> 
> My concern is wrt to the ordering guarantees (if any) between messages and control frames.
> 
> 
> 
> C2 changes the order in which "OnControl" and "OnMessage" handlers would fire on the receiving endpoint.
> 
> 
> 
> original:
> 
> [MSG1-fragment1] [CONTROL-frame1] [MSG1-fragment2] [MSG2-fragment1] [CONTROL-frame2] [MSG2-fragment2]
> 
> 
> 
> by C2 =>
> 
> [MSG1-fragment1] [MSG1-fragment2] [CONTROL-frame1] [MSG2-fragment1] [MSG2-fragment2] [CONTROL-frame2]
> 
> 
> 
> by coalescing =>
> 
> [MSG1-fragment12] [CONTROL-frame1] [MSG2-fragment12] [CONTROL-frame2]
> 
> 
> 
> ?? =>
> 
> [MSG1-fragment12] [MSG2-fragment12] [CONTROL-frame1] [CONTROL-frame2]
> 
> 
> 
> ==
> 
> 
> 
> If the spec does not require anything in this area, then we have actually 2 channels (control/data) with strict ordering
> 
> within, but no ordering relationship between?
> 
> 
> 
> 
> 
> 
> 
> Von: John Tamplin [mailto:[email-masked]]
> 
> Gesendet: Dienstag, 16. August 2011 16:53
> 
> An: Tobias Oberstein
> 
> Cc: Bob Gezelter; [email-masked]
> 
> Betreff: Re: [hybi] Intermedaries: coalescing with interleaved control messages
> 
> 
> 
> On Tue, Aug 16, 2011 at 10:47 AM, Tobias Oberstein When an intermediary receives
> 
> 
> 
> [MSG1-fragment1] [MSG1-fragment2] [CONTROL-frame] [MSG1-fragment3]
> 
> 
> 
> which of the following is it allowed to coalesce into when forwarding:
> 
> 
> 
> C1.
> 
> [MSG1-fragment12] [CONTROL- frame] [MSG1-fragment3]
> 
> 
> 
> C2.
> 
> [MSG1-fragment123] [CONTROL- frame]
> 
> 
> 
> C3.
> 
> [CONTROL-message] [MSG1-fragment123]
> 
> 
> 
> C4.
> 
> [MSG1-fragment1] [CONTROL- frame] [MSG1-fragment23]
> 
> 
> 
> ==
> 
> 
> 
> "allowed" = according to rules as defined by the base WS spec with no active extension
> 
> 
> 
> I don't believe the spec has anything to say about this currently, so I believe all of them would be allowed.  Personally, I would think #1 should definitely be allowed, and that it might be useful for an intermediary that collected small frames to do #3 or #4.  It seems you wouldn't want to delay a control frame while waiting for more frames in a message, so I would prefer to outlaw #2, but I don't feel strongly about it.
> 
> 
> 
> --
> 
> John A. Tamplin
> 
> Software Engineer (GWT), Google

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 16 Aug 2011 08:45:30 -0700

Bob,

if there are no ordering guarantees between control frames and messages,
this would have a number of consequences. My feeling is it's bad.

Here is one example. The spec:

4.5.1.  Close

The application MUST NOT send any more data frames after sending a
   close frame.

That seems to be pointless then, since interm. might reorder Close wrt
to data.

2nd example: some extension uses control frames that really relates to
data .. i.e. a MUX ext. doing credit repl.

So without any ordering guar. the use of reserved control opcodes
could be limited. 

In general: in a multi-channel messaging system, what are conceivable/sane
ordering guarantees that can be made? Or is it bad to do so? That is
strict ordering is guar. within each channel, but no guar. whatsoever is made
for ordering relationship between channels.

> -----Ursprüngliche Nachricht-----
> Von: Bob Gezelter [mailto:[email-masked]]
> Gesendet: Dienstag, 16. August 2011 17:33
> An: Tobias Oberstein
> Cc: [email-masked]; John Tamplin
> Betreff: RE: AW: [hybi] Intermedaries: coalescing with interleaved control
> messages
> 
> Tobias,
> 
> Without having the time for a re-read at this instant, I will presume that
> John's comments about no explicit binding (insofar as the protocol
> As a general matter, I would be reluctant to rely upon seeming connections
> between the control and the data channels. The connections between
> control and data can conceivably be disconnected in any number of ways
> (see my recent comment about "gateways"; I would not advocate
> attempting to clone and correspondingly coalesce control frames and their
> responses at gateways).
> 
> > [MSG1-fragment1] [CONTROL-frame1] [MSG1-fragment2] [MSG2-
> fragment1]
> > [CONTROL-frame2] [MSG2-fragment2]
> >
> >
> >
> > by C2 =>
> >
> > [MSG1-fragment1] [MSG1-fragment2] [CONTROL-frame1] [MSG2-
> fragment1]
> > [MSG2-fragment2] [CONTROL-frame2]
> >
> >
> >
> > by coalescing =>
> >
> > If the spec does not require anything in this area, then we have
> > actually 2 channels (control/data) with strict ordering
> >
> > I don't believe the spec has anything to say about this currently, so I believe
> all of them would be allowed.  Personally, I would think #1 should definitely
> be allowed, and that it might be useful for an intermediary that collected
> small frames to do #3 or #4.  It seems you wouldn't want to delay a control
> frame while waiting for more frames in a message, so I would prefer to
> outlaw #2, but I don't feel strongly about it.
> >
> >
> >
> > --
> >
> > John A. Tamplin
> >