[whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)

On Fri, Aug 14, 2009 at 3:45 AM, Ian Hickson<ian at hixie.ch> wrote:
> On Fri, 7 Aug 2009, Jonas Sicking wrote:
>> I agree that these are very interesting features. Especially connection
>> multiplexing is something that I think is a good idea, for the reasons
>> you've mentioned elsewhere in this thread (multiple widgets on the same
>> page).
>
> How do you envisage multiplexing working? It's not clear to me what we
> could do that would be easier to handle than just having the script
> manually do the multiplexing at the application layer. What would the API
> look like? What would the wire level look like?

Some advantages of putting it in the protocol:

1. More likely the UA implementors will make the effort of
implementing multiplexing (and doing so correctly), than that website
authors will.
2. There are much fewer UA implementors than website authors, so the
level of code reuse would be much higher.
3. Scripts in different tabs, and even from different sites, that
connect to the same server would be able to share TCP/IP channel.
4. If websocket is successful, websocket proxies will likely show up,
allowing multiplexing across different users that share the same
proxy.

Looking at how much HTTP benefits from "multiplexing" in the form of
connection: keep-alive, and how much more it would have benefitted
from good multiplexing in the form of pipelineing, I'd be very
surprised if websocket wouldn't benefit from it as well.

But I agree that we need a concrete proposal before we can usefully
get further in the discussion.

>> But even compression is nice if it was possible.
>
> It's not clear to me that compression would be particularly useful for
> short packets.

Indeed, short packets probably won't benefit from compression. Likely
any frame that fits in a single IP packet probably stands little to
gain from getting compressed. Except in the case when it allows
fitting additional frames into the same IP packet.

> I agree that it could be useful for bigger packets; maybe
> when we support binary frames we should say that the frames are
> compressed?

Well, I'm not sure all binary frames needs to be compressed. For
example transmitting a jpeg over websocket should be done in a binary
frame, but would unlikely benefit from being compressed. One possible
solution is to keep the 0x80 frame type as a raw binary frame, 0x81 is
a compressed frame, with the following contents:

frame-type
name-of-encoding
00
encoded-contents

frame-type is a single byte indicating which frame-type is encoded.
name-of-encoding is a US-ASCII encoded string indicating the name of
the encoding, this could be 'gzip' for gzipped compression, etc.
00 is the single byte with value 0
encoded-contents is the actual contents, ending at the end of the frame.

Once the frame has been decoded, the implementation treats the frame
as if a frame with the given frame-type was received, with the
contents being the decoded contents.


There's a few things that needs to be defined. Such as:
Is it allowed to put an 0x81 frame inside a 0x81 frame?
What to do if the frame-type is 0x7f or lower, but the decoded
contents contains a 0xff?
What to do if the decoding produces an error?
What to do if name-of-encoding is not recognized?
What to do if no 00 is found?

/ Jonas

Received on Friday, 14 August 2009 14:13:27 UTC