Re: [hybi] [Uri-review] ws: and wss: schemes

Křištof Želechovski wrote:
> AIUI, in order to provide a service over WebSockets, you have to
> implement it in raw stream first.  This stream, once implemented,
> can run quite happily under tcpd, and the WebSockets shim is only a
> wrapper.

All those points are false, so the rest of your argument falls apart.

You seem to think WebSockets is a wrapper around a two-way raw byte
stream, but it isn't.  In fact it's quite tricky to transport a raw
byte stream over WebSockets, and you'd have to define your own
protocol on top of WebSockets to do it.

WebSockets provides application-visible framing with NUL-terminated
UTF-8 strings.  (I haven't checked what it does if you have a real NUL
character to transmit - does the spec say?).  You cannot transmit
binary data in those UTF-8 string frames, or even arbitrary non-zero
bytes; they must be valid UTF-8.

Although the protocol has binary frames and room for other frame
types, Javascript browser implementations will not support them for a
long time if ever, therefore binary is not practical to use.  You can
of course encode binary data to UTF-8 strings, but your encoding would
be application-specific.

The framing is explicit; it cannot be altered in transit (unlike TCP),
is visible to applications, and was intentionally designed to map to
Javascript DOM events - one event per UTF-8 frame.  Applications are
very likely to be coded around that assumption.  (Even if binary
frames ever get supported, this differentiates it from a raw stream.)

So, no, you would not code a WebSockets service by writing a raw
stream protocol first and then using WebSockets as a shim.  It would
be a very complicated way to do it.

You would only do that, if you _already_ have a raw stream protocol,
but you'd still need an additional layer for binary-to-UTF-8 encoding
and packetising, of your own design, on top of WebSockets.

> So there is one protocol and one implementation thereof,
> only exposed over two different transport channels.

If that were true (it's not), you'd still need to write non-browser
things which talk to other people's services over WebSockets, in order
to access services that are only offered over one channel because they
don't care to provide the other one.

By the way, I have argued in favour of WebSockets being more like a
raw stream to applications (mostly for efficiency reasons but the shim
argument you've given is also a good one), so I'm only describing what
it is and what consequences to expect, not saying I like it.

-- Jamie

Received on Thursday, 10 September 2009 22:42:36 UTC