Re: [hybi] Subprotocol and Control Frames

["Arman Djusupov" <[e-mail]>]

I believe that this sub-protocol is needed, as it can provide a common way
of message dispatching and connection recovery for various applicationσ
irrespective of what format they use for the message.

For example there are various JSON RPC or Protobuff RPC in development and
most of them are not interoperable with each other due to incompatible
message metadata format. Having a common message metadata format would be
very beneficial.

Message Extension Data Fields
   
   |    Address    |    base 128 varint   |   UTF-8 character string   |
   |  Content-Type |    base 128 varint   |   UTF-8 character string   |
   | Property List |    base 128 varint   |    Sequence of Property    |
   
In addition to the implicit sequence number, a MessageID/ReleatesTo field
could also be added to the message header. Most applications would need this
to associate the messages they receive with the messages they send. This
property can obviously be added to the property list or even be part of the
Address field but this would add additional overhead when processing the
message.

For example, multiple outbound requests were sent by one side and received
by the remote side in correct order, but processing each request took
different amounts of time so the responses may arrive in a different order.
In such cases the application that sent the requests would have to use a
Property list and search for e.g. "RelatesTo" in message properties. This
would definitely be slower than if there would be some sort of fixed
"Topic/ID" field in the message header that would associate requests with
responses. This field could be a variant integer number for faster
processing.

With best regards,
Arman

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Hapner mark
> Sent: Wednesday, October 05, 2011 4:36 AM
> To: Greg Wilkins
> Cc: [e-mail]
> Subject: Re: [hybi] Subprotocol and Control Frames
> 
> Thanks for everyone's comments. Clebert and I are learning as we go ...
> 
> Greg,
> 
> Thanks for the clarifications ...
> 
> I agree that MBWS could define its own framing protocol within the
> WebSocket message payload, i.e. MBWS could be defined as a WebSocket
> subprotocol. (Sorry for my original confabulation of subprotocol and
> extension)
> 
> The option also exists to implement MBWS as it is currently defined as a
> WebSocket extension that adds extension data and extension control frame
> opcodes.
> 
> WebSocket provides support for both subprotocols and extensions and I
> believe both are available for use by outside parties as long as the IANA
> registration mechanisms are followed. Is this correct?
> 
> My primary concern is that implementing MBWS as a subprotocol will add
> complexity and overhead. The only rationale I can see for defining MBWS as
> a subprotocol would be if, for some reason, browsers/proxies/firewalls
> blocked WebSocket extensions, i.e. MBWS has to use a 'subprotocol tunnel'
> through them.
> 
> The core point in favor of using an extension is that WebSocket already
> defines an excellent framing protocol. There is simply no need for MBWS to
> layer yet another framing protocol over it. It would be equivalent to a
REST
> service defining a request-response framing protocol within the HTTP
> request-response body when all it needed was to add a few new header
> fields. Let me see, I think I remember this being done, it was called WS*
:>)
> 
> The point about control frame opcodes being 'scarce' is an issue; however,
> the spec already suggests the use of an extension bit to resolve this.
> 
> The spec does not describe how the opcode space will be distributed across
> extensions. It does not say whether or not an extension opcode value can
be
> 'redefined' by different extensions. Since a session can only be operating
> under one extension, there does not appear to be a technical reason why
> extensions could not redefine extension opcodes. If this is possible, then
> MBWS does not 'use up' any extension opcodes.
> 
> Perhaps the fact that WebSocket itself does not reserve any of the opcode
> extension space for itself is an issue. There seems to be an implication
in the
> comments so far that, in effect, they are all reserved and none are
available
> for 'outside' use. I don't believe this is the case.
> 
> I think subprotocols and extensions are both useful. For an application
> specific case, say the transport of Insurance Policies and Quotes,
defining a
> subprotocol for transport of this Insurance Message Schema would be
> sensible. I believe that MBWS is case where the use of an extension is
> sensible.
> 
> Again, I think this issue is worthy of some serious debate. I'm not ready
to
> concede, as yet, that defining MBWS as a WebSocket extension is wrong.
> 
> -- Mark
> 
>  >On 5 October 2011 07:23, Hapner mark <[e-mail]>
> wrote:
>  >>
>  >> In my reading of draft 17, I do not find a definition of subprotocol
that  >>
> puts any restrictions on the WebSocket extensibility features a
subprotocol
> >> may use.
>  >
>  >Mark,
>  >
>  >in section 5.8 Extensibility:
>  >
>  >   This specification provides opcodes 0x3 through 0x7 and
>  >   0xB through 0xF, the extension data field, and the frame-rsv1, frame-
>  >   rsv2, and frame-rsv3 bits of the frame header for use by extensions.
>  >
>  >So while there is no explicit restriction on subprotocols using
>opcodes,
> the only allowance given is to extensions.
>  >
>  >> If the sense of the WG is that subprotocols are restricted to use  >>
only
> extension data and message format/schema restrictions, this is not  >>
> apparent in the content of this draft.
>  >
>  >The specification also describes subprotocols in section 1.3 as  >
>  >   ... used to indicate what subprotocols (application-level protocols
>  >   layered over the WebSocket protocol) are acceptable to the client.
>  >
>  >
>  >> It is my observation that there will be a number of WebSocket usecases
> that  >> could benefit from the ability to define usecase-specific control
> frames to  >> mediate message flow. Telling developers to stuff this
> mediation protocol  >> into extension data rather than in control frames
does
> not appear to  >> increase security;  >  >Firstly subprotocols can no more
use
> extensions data than they can use  >extension opcodes.
>  >They can however use the payload and are free to define arbitrary
> >message semantics within that payload that may include application
> >control messages.
>  >
>  >The restriction of subprotocols to not use opcodes is not done for
> >security.  It is done for protocol layering reasons.
>  >The opcode is there to inform the WS implementation (and it's
>  >extensions) how to handle the message.  There is no application
> >semantics associated with any of the opcodes.  For example the text vs
> >binary opcodes instructs the implementation if UTF-8 decoding is
>required
> and to which part of the websocket API a message should be  >delivered.
> There is no semantic restriction imposed by a binary  >message, which may
> actually be a text message, but one for which the  >application or
> subprotocol has taken responsibility for character  >encoding.
>  >
>  >> rather, it likely decreases security because it  >> intermixes control
with
> data which is a fundamentally bad thing for a  >> protocol design to do.
The
> two control frames defined by MBWS are fairly simple and are likely  >>
> representative of what other subprotocols would need. It would be far
> better  >> to allow MBWS to properly factor its control and data than
force it
> to put  >> control in its data.
>  >
>  >Indeed there is a limitation in the current protocol of providing only
>a
> single stream per connection, so there can be no separation of
>  >control/data on a single connection.   However the solution is not to
>  >allow applications to put their control messages into the protocols
>control
> stream, but rather to better support multiple streams - ie  >MUX.  For the
> protocol, it is clear that there are two streams of
>  >frames: data and control,  but there is no reason why this taxonomy
>will
> apply generally to all applications and subprotocols.  There may  >be use
> cases where applications/subprotocols need n streams or control  >frames
> larger than 125 bytes.
>  >
>  >The solution is to not see that the protocols control frame mechanism
>is
> somewhat like the applications need for control messages and thus  >to
> attempt to expose the protocols control channel to the application.
>  > The solution is to allow applications to efficiently create their own
>control
> channels - MUX!
>  >
>  >
>  >> It is true that TCP does not support application control extension;
> however,  >> HTTP clearly does support this with a very open-ended
> extension of the HTTP  >> header. The WG needs to think carefully about
> this. I hope there is room to  >> resolve this issue in this version of
> WebSocket.
>  >> It is up to the W3C WebSocket API to insure it provides the
functionality
> >> that both native users of WebSocket and implementors of WebSocket  >>
> subprotocols require. In looking over what is currently defined, this API
>>
> does not yet provide an API sufficient for the later. Possibly later it
>> will. I
> don't believe that the design of WebSocket needs to be restricted by  >>
the
> current limitations of this API.
>  >
>  >This distinction between extensions and subprotocols has not been made
> >because of any API limitations.  It has been done for good protocol
> >layering reasons.
>  >
>  >Consider if we open up the control channel to applications, then this
>will
> make the task of creating things like MUX extensions much more
>difficult.
> The mux solution would have to allow for extending control  >frames with
> extension data so that they may be correctly routed to the  >right
application
> control channel.  But if a 125 byte application  >control frame is sent,
then
> there may not be sufficient room to add
>  >the channel identifier!    Also if control frames are used to
>  >implement MUX flow control, will applications use their application
> >control frames to attempt to get around this flow control?  We may end
> >up needing to put flow control on the control channel to limit the
>number
> of application control frames.
>  >
>  >Mixing application control frames with protocol control frames is a
>far
> worse "solution" than mixing application control messages with
>application
> data messages.
>  >
>  >regards
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi