Subject: Re: [hybi] The MessageBroker WebSocket Subprotocol

From: Hapner mark <[email-masked]>
Date: Tue, 04 Oct 2011 04:47:15 +0000

I'll be traveling in Japan for two weeks starting this Thursday and will likely have intermittent email access. I apologize in advance for my lack of responsiveness during this time.

on Sun, 02 Oct 2011 13:54:23 +0200 Martin Sustrik wrote:

> Hi Mark, Clebert,
> 
> What I *really* like about the proposal is that unlike other messaging 
> protocols it takes care to cleanly separate the reliability from the 
> broker behaviour. The latter is explicitly defined as out-of-scope.
> 
> Some comments follow:
> 
> 1. Given the explicit focus on reliability, it's strange that the 
> proposal deals with message metadata, which have to do with broker or 
> even application behaviour and have absolutely nothing to do with 
> reliability. What ensues is a spec where metadata are defined as opaque 
> syntactic placeholders with no associated semantics. The semantics are 
> meant to be defined on the broker or application level. The question is 
> whether it doesn't follow that the syntax should be defined on those 
> layers as well.
> 

Both the reliability and message metadata are defined with the expectation that they are generic for a broad class of MessageBroker services. The majority of those I'm familiar with could easily make do with this metadata. The semantics of messages having a text address, an optional content type, and an optional property list covers a very broad set of MessageBroker scenarios. On the other hand, without this additional message metadata, the protocol would not be usable by any MessageBrokers I'm aware of. 

> 2. AFAICS there's nothing in the spec that presumes existence of the 
> broker. It can be as well used for direct communication between 
> applications. Thus, I would suggest replacing messaging broker/messaging 
> client terminology with WebSocket server and WebSocket client wording.
> 

Yes, while the protocol has been defined for the MessageBroker usecase, nothing prevents its use in other contexts. On the other hand, if it were called 'foobar' instead of 'MessageBroker' it would be hard to explain why it contains the specific elements it does.

> 3. As for reliability itself, it should be clear what kind of error 
> conditions is the protocol meant to handle. Possible options:
> 
> a. Network failure. If so, how does it differ from simply turning off 
> TCP keepalives?
> 
> b. Client failure and restart?
> 
> c. Server failure and restart?
> 

The reliability elements of MBWS are just the protocol elements that client and MessageBroker use to jointly create and maintain a connection abstraction. This shared abstraction exists independent of MBWS. This allows a connection to be 'carried' over an open-ended sequence of MBWS sessions. Since connections exist independent of the network, they survive any form of network failure. 

The degree to which a connection will or won't survive a client/MessageBroker failure depends entirely on the ability of the client/MessageBroker to retain the state needed for it to maintain the connection across its failure. MBWS does not define how this is to be done; however, there are many practical ways of doing it. A client or MessageBroker could fully implement MBWS and only recover from failed MBWS sessions (i.e. not support connection recovery across program failures).  

> Martin

on Sun, 2 Oct 2011 12:51:27 -0400 John Tamplin wrote:

> It isn't entirely clear to me whether this is defining a subprotocol or a
> WebSocket extension.  3.3 clearly makes it seem to be a subprotocol, but
> then 2.1.2 defines two opcodes, which is something that can only be done by
> an extension.  Also, if it is an extension, there should probably be more
> care to reduce the number of opcodes used, as they are in very limited
> supply.  Finally, since new opcodes can only be allocated by IANA, it is
> hard to experiment with before it is standardized - an alternative would be
> to define binary frames exchanged over the subprotocol as having a 1-byte
> extended opcode in the first byte, which would not require a WebSocket
> extension or allocation of scarce opcodes.  After gaining some experience
> with the protocol, then we will have better information about whether
> allocating scarce opcodes to this use is warranted.

MBWS was originally drafted in March and since then WebSocket has further distinguished between 'subprotocols' and 'extensions'. Draft 17 still seems to be a little vague about the distinction between these.

If only an extension can define new control frames then MBWS is an extension and not a subprotocol. 

As you note, the issue here goes beyond MBWS. If WebSocket lacks the ability to define usecase specific control frames it lacks a fundamental degree of extensibility. MBWS requires two MBWS-specific control frames. If there is a practical way to create these without defining new opcodes that would be fine.

I agree it would be wrong for MBWS to use up WebSocket generic protocol elements of any kind. My interpretation of the spec was that the mechanism for defining MBWS specific control frames was to define MBWS specific opcodes, i.e. that the current unused opcodes were available for this purpose. 

If they are not, I suggest that one opcode be assigned as a 'subprotocol control frame opcode'.  A subprotocol would then use this along with 'application data' (as is used by Ping/Pong) to define whatever subprotocol-specific control frames it requires. The subprotocol can then define whether the data for its control frames is text or binary.

Whatever form the resolution of this issue takes, the WG should insure that WebSocket provides a formal mechanism for defining subprotocol-specific control frames.

-- Mark

---

From: John Tamplin <[email-masked]>
Date: Tue, 4 Oct 2011 01:02:56 -0400

On Tue, Oct 4, 2011 at 12:47 AM, Hapner mark <[email-masked]> wrote:

> Whatever form the resolution of this issue takes, the WG should insure that
> WebSocket provides a formal mechanism for defining subprotocol-specific
> control frames.

I disagree -- a subprotocol defines the interpretation of payload frames.  A
subprotocol can create whatever interpretation it likes of those bytes,
including defining a subprotocol opcode.  New opcodes should be for WS
infrastructure to determine, rather than higher layers.

TCP and UDP doesn't allow higher-layer protocols space to store their own
opcodes (the port number would be similar to identifying the subprotocol),
but instead expect them to store it in the payload.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Brian <[email-masked]>
Date: Mon, 3 Oct 2011 22:09:59 -0700

First off, I'd like to say that I think it's really exciting to see
proposals like MBWS coming forward!  This is just the beginning of the
creation of standard, interoperable building blocks on WebSocket that will
enable the development of entirely new classes of web applications, and I,
for one, can't wait!  ;)

> extension and not a subprotocol.

IMO, MBWS is and should be a subprotocol.  It's entirely inappropriate to
think of it or implement it as an extension.

As you note, the issue here goes beyond MBWS. If WebSocket lacks the ability
> to define usecase specific control frames it lacks a fundamental degree of
> extensibility. MBWS requires two MBWS-specific control frames. If there is a
> practical way to create these without defining new opcodes that would be
> fine.
>

Why?  There are two differentiating characteristics of control frames in
WebSockets:

1.) They can be injected in the middle of a fragmented message.
2.) They can only carry a payload up to 125 bytes.

The first may make them desirable to trigger events in the middle of a
message fragmentation, but there is currently no way to do this and expose
it via the WebSocket API layer, so another approach must be taken.

The second can potentially limit the scope of their usefulness in a generic
case.

> I agree it would be wrong for MBWS to use up WebSocket generic protocol
> elements of any kind. My interpretation of the spec was that the mechanism
> for defining MBWS specific control frames was to define MBWS specific
> opcodes, i.e. that the current unused opcodes were available for this
> purpose.
>
>
Indeed they are not.  WebSocket opcodes are not (and I strongly believe
should not ever be) available for use by subprotocols.  What is your
specific use case for defining a special application specific control frame?

As far as I'm concerned, you can use the first byte or two of a binary
message or the first few characters of your utf-8 message as an opcode field
and interpret it at the application layer.  Obviously there are many other
ways of doing this, but the only appropriate place for extended opcodes that
have meaning specific to the application or subprotocol are in the
application data payload itself, where the subprotocol implementation can
parse the opcode directly and separate it from the rest of the message
contents.

If they are not, I suggest that one opcode be assigned as a 'subprotocol
> control frame opcode'.  A subprotocol would then use this along with
> 'application data' (as is used by Ping/Pong) to define whatever
> subprotocol-specific control frames it requires. The subprotocol can then
> define whether the data for its control frames is text or binary.
>

Can you elaborate on your use case?  I think that actually sounds like a
pretty reasonable idea, if for nothing else just so that they can be
injected and handled in the middle of a long fragmented message.  It's one
building block for the application level to take advantage of that is
currently not available.  Unfortunately, the time for getting this into the
base spec seems to be past, so we'll have to revisit this for the next
version of the WebSocket protocol.  The only option available for now is to
fake it with opcodes in your binary/utf-8 messages.  If you need to inject
control frames in the middle of a fragmentation sequence, you will be forced
to implement a separate fragmentation layer at the application level, not
taking advantage of websocket's fragmentation.

Perhaps this could be made available via a standard extension that the
browsers all implement at some point, since we almost certainly can't get it
into the spec now.

> WebSocket provides a formal mechanism for defining subprotocol-specific

I actually really like the idea of one generic control frame that can be
handled at the application level, but there should only be one.  Any
differentiation of message type should be done exclusively through the
payload data of the frame.

Brian

---

From: Brian <[email-masked]>
Date: Mon, 3 Oct 2011 22:17:33 -0700

On Mon, Oct 3, 2011 at 10:02 PM, John Tamplin <[email-masked]> wrote:

> On Tue, Oct 4, 2011 at 12:47 AM, Hapner mark <[email-masked]>wrote:
>
>> Whatever form the resolution of this issue takes, the WG should insure
>> that WebSocket provides a formal mechanism for defining subprotocol-specific
>> control frames.
>
>
> I disagree -- a subprotocol defines the interpretation of payload frames.
>  A subprotocol can create whatever interpretation it likes of those bytes,

I agree completely and wholeheartedly.  But I'd like to know what you and
others think about his idea of, perhaps for the next version of WebSockets,
defining a single generic control frame with its <= 125 byte payload that is
exposed through the WebSocket JS API as a separate event, so the application
can handle its own kind of control frames interjected into large fragmented
message sequences?

Brian

---

From: John Tamplin <[email-masked]>
Date: Tue, 4 Oct 2011 12:04:25 -0400

> can handle its own kind of control frames interjected into large fragmented

It wouldn't have to be a new version of WebSockets, just a separate standard
defining it.

For it to be useful, you would have to expose control frame handling in the
API.  While there certainly are non-browser WS clients, WS exists because of
them (the others could just use TCP directly) and has to deal with
potentially hostile JS.  Opening up control frame processing by that hostile
JS would require very careful consideration.

Also, since once a frame is sent, you can't interject a control frame into
it until it is done, I don't know how effective it would be unless the WS
implementation specifically limited frame sizes.

I'm not sure exactly what the need is, but if it is for out-of-band
messaging, then maybe a better idea would be to expose that concept in the
API, and then define a control frame for carrying out-of-band messages.

---

From: Clebert Suconic <[email-masked]>
Date: Tue, 4 Oct 2011 09:11:47 -0700

> API, and then define a control frame for carrying out-of-band messages.
Having the control frame exposed through the API would be great.

That's actually something I asked here before we opened the standard... you
will probably see it.

---

From: John Tamplin <[email-masked]>
Date: Tue, 4 Oct 2011 12:20:41 -0400

> Having the control frame exposed through the API would be great.

As mentioned, doing so would seem to open a lot of possibilities for abuse
since the JS code must be assumed to be hostile.  It would take some effort
to determine what level of access should be granted and what checks to be
performed.  It is much easier to add later if warranted than to try and
remove it after you discover it has problems.

> That's actually something I asked here before we opened the standard... you

Note that the API is not the developed in this group -- this group is about
defining the wire protocol.

---

From: Scott Ferguson <[email-masked]>
Date: Tue, 04 Oct 2011 09:25:36 -0700

On 10/04/2011 09:11 AM, Clebert Suconic wrote:
>
>     Also, since once a frame is sent, you can't interject a control
>     frame into it until it is done, I don't know how effective it
>     would be unless the WS implementation specifically limited frame
>     sizes.
>
>     I'm not sure exactly what the need is, but if it is for
>     out-of-band messaging, then maybe a better idea would be to expose
>     that concept in the API, and then define a control frame for
>     carrying out-of-band messages.
>
>

Remember, though, that your application protocol can define messages 
however it wants. Some of those messages can be control messages. And 
some of those messages can be fragments.

As an example, you could build an entire muxing layer as a subprotocol, 
not an extension. That subprotocol's WebSocket messages might be 
fragments of a larger file. Or a streaming video service, where each 
WebSocket message is a chunk of a video stream, interlaced with 
streaming control messages. Neither of those control messages need to 
have anything to do with a WebSocket control frame.

I'd think layering sub-protocols on top of WebSockets would be a better 
approach for now, instead of trying to make everything an extension.

-- Scott

>
> That's actually something I asked here before we opened the 
> standard... you will probably see it.
>
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Clebert Suconic <[email-masked]>
Date: Tue, 4 Oct 2011 09:32:43 -0700

> however it wants. Some of those messages can be control messages. And some
> of those messages can be fragments.
>
> As an example, you could build an entire muxing layer as a subprotocol, not
> an extension. That subprotocol's WebSocket messages might be fragments of a
> larger file. Or a streaming video service, where each WebSocket message is a
> chunk of a video stream, interlaced with streaming control messages. Neither
> of those control messages need to have anything to do with a WebSocket
> control frame.
>
I don't think there's another option with the current state of the web
socket API on the browser. but I'm not sure if that's the ideal (I will have
to hear from Mark Hapner when he's back).

I have heard from Mark that there is at least one WebSocket implementations
that will expose the control frame but that's meant for a server's side. But
the protocol has to take care of the Web Browser as well.

---

From: Martin Sustrik <[email-masked]>
Date: Wed, 05 Oct 2011 10:39:12 +0200

Hi Mark,

>> proposal deals with message metadata, which have to do with broker
>> or even application behaviour and have absolutely nothing to do
>> with reliability. What ensues is a spec where metadata are defined
>> as opaque syntactic placeholders with no associated semantics. The
>> semantics are meant to be defined on the broker or application
>> level. The question is whether it doesn't follow that the syntax
>> should be defined on those layers as well.
>>
>
> Both the reliability and message metadata are defined with the
> expectation that they are generic for a broad class of MessageBroker
> services. The majority of those I'm familiar with could easily make
> do with this metadata. The semantics of messages having a text
> address, an optional content type, and an optional property list
> covers a very broad set of MessageBroker scenarios. On the other
> hand, without this additional message metadata, the protocol would
> not be usable by any MessageBrokers I'm aware of.

I think the argument goes rather like this: If the metadata is to be 
used by the protocol, the semantics of the usage should be defined. If 
it's not defined, there's no interoperability. If there's no 
interoperability, there's no point in having a standard in the first place.

>> 2. AFAICS there's nothing in the spec that presumes existence of
>> the broker. It can be as well used for direct communication
>> between applications. Thus, I would suggest replacing messaging
>> broker/messaging client terminology with WebSocket server and
>> WebSocket client wording.
>>
> Yes, while the protocol has been defined for the MessageBroker
> usecase, nothing prevents its use in other contexts. On the other
> hand, if it were called 'foobar' instead of 'MessageBroker' it would
> be hard to explain why it contains the specific elements it does.

What I meant was that there are messaging solutions out there with no 
broker (Tibco RV, LBM, 0MQ). There's nothing expect the "broker" wording 
in the protocol to prevent these solutions to use the protocol.

Btw, I've heard something about Kaazing providing access to Tibco 
through the web on top of websockets...

>> 3. As for reliability itself, it should be clear what kind of
>> error conditions is the protocol meant to handle. Possible
>> options:
>>
>> a. Network failure. If so, how does it differ from simply turning
>> off TCP keepalives?
>>
> The reliability elements of MBWS are just the protocol elements that
> client and MessageBroker use to jointly create and maintain a
> connection abstraction. This shared abstraction exists independent of
> MBWS. This allows a connection to be 'carried' over an open-ended
> sequence of MBWS sessions. Since connections exist independent of the
> network, they survive any form of network failure.

This is interesting. Can you give an example of such network failure?

> The degree to which a connection will or won't survive a
> client/MessageBroker failure depends entirely on the ability of the
> client/MessageBroker to retain the state needed for it to maintain
> the connection across its failure. MBWS does not define how this is
> to be done; however, there are many practical ways of doing it. A
> client or MessageBroker could fully implement MBWS and only recover
> from failed MBWS sessions (i.e. not support connection recovery
> across program failures).

Ack. The failures of server/client are not addressed in the protocol. 
You can handle them on top of it though.

Martin

---

From: Clebert Suconic <[email-masked]>
Date: Wed, 5 Oct 2011 09:36:12 -0700

>
> I think the argument goes rather like this: If the metadata is to be used
> by the protocol, the semantics of the usage should be defined. If it's not
> defined, there's no interoperability. If there's no interoperability,
> there's no point in having a standard in the first place.
>
>
>
Any message implementation will need some context to perform reconnections.
That shouldn't be a problem for any message-like systems.

It should be a simple solution that just works.. and I believe this would
bring a lot of advantages over other over-complex standards that are defined
on the message-world.

This can actually be used for other communications where some context needs
to be defined as well.

I'm sure Mark will have more to say on top of this.