Re: [hybi] Multiplexing in WebSocket

[Greg Wilkins <[e-mail]>]

Ian Hickson wrote:

>> I've made this programming error myself many times! So perhaps I too am 
>> one of the authors that should not be writing network protocols.
> 
> If you don't think you should be writing one, you almost certainly 
> shouldn't be designing one. :-)

touche!   :)


> The main difference is that most people won't manage UTF-8 encoding. In 
> Perl, for instance, there's the "Encode" library that you can just pass 
> byte strings to to have them converted into UTF-8, and vice-versa.

Forgive my total lack of knowledge of perl, but given the availability
of the encode library in perl, I see little difference in the complexity
of sentinel marked code which is:

  $octets = encode("utf-8", $message)
  write ($octets)
  write (oxff)

versus length encoding code which is

  $octets = encode("utf-8", $message)
  write ($octets.length)
  write ($octets)


They will need a method to correctly encode the length
as an unlimited integer, but they will probably need that
anyway as  you currently specify that length encoded
framing is part of the standard (stacked out).


> We have binary frames already staked out in the protocol, waiting for 
> support in JS for binary.

I don't see why an IETF protocol proposal needs to wait for
the js implementation?

Since the binary framing is about the same level of
complexity, is more capable and is already stacked
out - they why not avoid the complexity to two
different framings and just use length?

JS is free to limit it's usage to just utf-8 as long
as it likes.   But JS is not the only client language
that is going to use an IETF sanctioned bidirectional
protocol.


>> * A mobile phone that is restricted to a single outgoing
>>   connection (not uncommon) so the browser wants to
>>   transport HTTP over the websocket connection
> 
> Could you elaborate on this use case?

I unfortunately don't have all the details, but I have
been a little involved in the development of a comet
system for a large mobile phone company for global
deployment.

One of the issues that we had to deal with was a single
connection limit that apparently affects many millions
of phones.  This was a restriction for a non
browser application running on the phone with direct
access to the TCP/IP layer.

However I'm unclear if the limit was imposed by firmware
in the phone or carriers.


>> * Something that none of us has thought of yet
> 
> Once we think of it, we can address it. There's no point trying to 
> optimise for something we don't know about; we have no way to know if we 
> are optimising in the right way.


I fundamentally disagree - and I think that this difference is
probably at the root of most/all our other differences on the
protocol.


I think the wait and see position you advocate is entirely
correct for the websocket API.

But i think it is entirely wrong for the websocket protocol.

A flexible and extensible protocol can be restricted to known
uses by the API.  You then do not need to update the entire
network infrastructure for each and every new idea.   Your
attempt to "stack out" the binary protocol is justified
by avoiding exactly this type of breakage.



> To send a stream of images with WebSocket, you will need to wait until 
> JavaScript gives you a way to get the image data in a usable form. I 
> certainly wouldn't recommend sending it as text, that would be stupid.

I think this is another fundamental disagreement.

I think the IETF should be considering a bidirectional solution for all
web clients - not just for HTML5 JS clients

Again, from my mobile experience, I have seen comet protocols
stream a users thumbnail image with a chat message, because of the
latencies involved with a separate fetch.   For the corresponding
web browser solution, the comet stream just sends a URL of the
thumbnail.


So I think it is really important for the IETF BOF/WG to resolve
these fundamental differences.   If you are designing a non-extensible
protocol that only supports HTML5 websocket API, then you may well
end up with something like the websocket protocol.   But if you
want something that is extensible and supports bidirectionality
for any web client, then I think then it will look substantially
different.


regards