WebSocket framing

[Bronislav Klučka]

Hello,
I'm looking at current WebSocket interface specification
http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#the-websocket-interface

1/ and I'm missing the ability to specify, whether data to be sent are
final or not (whether the frame to be sent should be continuous or not)
I suppose some parameter for specifying final/continuing frame should be
there, or some new methods for framing. I've tried to send 100 MiB text
from Chrome for testing purposes and since there is no way to specify
framing it was send in one piece.  There is no way to stream data from
client to server, all data must be kept in memory and sent at once.

2/ The same issue for receiving. I understand the need for simple API.
But again, there is streaming ability missing, all data are received at
once. Receiving large amount of data could hang up browser. There should
be onFrameMessage event intercepting frames one by one and (probably by
some event property) define, whether all those frames should be cached
and finally exposed by onMessage event (true by default). Programmer
than can choose to ignore such event (not implement it) and receive all
messages by onmessage event or implement it, use it for streaming, and
possibly prevent onMessage calls and unnecessary caching of large data

3/ MessageEvent should expose what kind of data was received, textual,
blob or arrayBuffer. This would prevent testing for data type and
problems with testing |binaryType
<http://dev.w3.org/html5/websockets/#dom-websocket-binarytype> |property
if changed during data receiving.

Brona Klucka

[John Tamplin]

On Sun, Aug 21, 2011 at 5:05 AM, Bronislav Klučka <
Bronislav.Klucka@...> wrote:

> Hello,
> I'm looking at current WebSocket interface specification
> http://www.whatwg.org/specs/**web-apps/current-work/**
> complete/network.html#the-**websocket-interface<http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#the-websocket-interface>
>
> 1/ and I'm missing the ability to specify, whether data to be sent are
> final or not (whether the frame to be sent should be continuous or not)
> I suppose some parameter for specifying final/continuing frame should be
> there, or some new methods for framing. I've tried to send 100 MiB text from
> Chrome for testing purposes and since there is no way to specify framing it
> was send in one piece.  There is no way to stream data from client to
> server, all data must be kept in memory and sent at once.
>

The JS API is entirely at the message level -- the fact that it might be
fragmented into frames is an implementation detail of the browser and the
rest of the network.


> 3/ MessageEvent should expose what kind of data was received, textual, blob
> or arrayBuffer. This would prevent testing for data type and problems with
> testing |binaryType <http://dev.w3.org/html5/**websockets/#dom-websocket-*
> *binarytype <http://dev.w3.org/html5/websockets/#dom-websocket-binarytype>>
> |property if changed during data receiving.
>

At the WebSocket protocol level, there is only text data and byte data.
 There is no notion of it being sent as a blob or array buffer, and any
binary data could be received as either, as is convenient to the receiver.

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

[Bronislav Klučka]

On 21.8.2011 18:44, John Tamplin wrote:

> On Sun, Aug 21, 2011 at 5:05 AM, Bronislav Klučka<
> Bronislav.Klucka@...>  wrote:
>
>> Hello,
>> I'm looking at current WebSocket interface specification
>> http://www.whatwg.org/specs/**web-apps/current-work/**
>> complete/network.html#the-**websocket-interface<http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#the-websocket-interface>
>>
>> 1/ and I'm missing the ability to specify, whether data to be sent are
>> final or not (whether the frame to be sent should be continuous or not)
>> I suppose some parameter for specifying final/continuing frame should be
>> there, or some new methods for framing. I've tried to send 100 MiB text from
>> Chrome for testing purposes and since there is no way to specify framing it
>> was send in one piece.  There is no way to stream data from client to
>> server, all data must be kept in memory and sent at once.
>>
> The JS API is entirely at the message level -- the fact that it might be
> fragmented into frames is an implementation detail of the browser and the
> rest of the network.

That was not the point, the point was that current WebSocket JS API does
not allow streaming of data either from browser or from server (browser
sends data as one frame, and when receiving exposes to the programmer
the whole message at once regardless of how server sent the message).  
As persistent and low latency connection, WS would be perfect for
streaming data. But due to this JS API inability to handle frames, one
has to implement streaming on server and client all over again even
though the protocol can be used.
So the point is, couldn't JS API use the ability of the protocol to ease
streaming implementation?

>
>> 3/ MessageEvent should expose what kind of data was received, textual, blob
>> or arrayBuffer. This would prevent testing for data type and problems with
>> testing |binaryType<http://dev.w3.org/html5/**websockets/#dom-websocket-*
>> *binarytype<http://dev.w3.org/html5/websockets/#dom-websocket-binarytype>>
>> |property if changed during data receiving.
>>
> At the WebSocket protocol level, there is only text data and byte data.
>   There is no notion of it being sent as a blob or array buffer, and any
> binary data could be received as either, as is convenient to the receiver.
>

This notice was not about how data are sent, but how data are received.
Regardless of data type the message is received by onmesssage event and
exposed in data property,
but I guess one can test for data type of this property

Brona.

[James Graham-7]

On 08/22/2011 09:09 AM, Bronislav Klučka wrote:

>
>
> On 21.8.2011 18:44, John Tamplin wrote:
>> On Sun, Aug 21, 2011 at 5:05 AM, Bronislav Klučka<
>> Bronislav.Klucka@...> wrote:
>>
>>> Hello,
>>> I'm looking at current WebSocket interface specification
>>> http://www.whatwg.org/specs/**web-apps/current-work/**
>>> complete/network.html#the-**websocket-interface<http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#the-websocket-interface>
>>>
>>>
>>> 1/ and I'm missing the ability to specify, whether data to be sent are
>>> final or not (whether the frame to be sent should be continuous or not)
>>> I suppose some parameter for specifying final/continuing frame should be
>>> there, or some new methods for framing. I've tried to send 100 MiB
>>> text from
>>> Chrome for testing purposes and since there is no way to specify
>>> framing it
>>> was send in one piece. There is no way to stream data from client to
>>> server, all data must be kept in memory and sent at once.
>>>
>> The JS API is entirely at the message level -- the fact that it might be
>> fragmented into frames is an implementation detail of the browser and the
>> rest of the network.
> That was not the point, the point was that current WebSocket JS API does
> not allow streaming of data either from browser or from server (browser
> sends data as one frame, and when receiving exposes to the programmer
> the whole message at once regardless of how server sent the message). As
> persistent and low latency connection, WS would be perfect for streaming
> data. But due to this JS API inability to handle frames, one has to
> implement streaming on server and client all over again even though the
> protocol can be used.
> So the point is, couldn't JS API use the ability of the protocol to ease
> streaming implementation?

I imagine that at some point in the future we will expose an interface
that is optimised for streaming data over websockets. But it seems
foolhardy to do that before we have any real-world experience with the
basic API. It is also something that will need to be designed to
integrate with other streaming APIs in the platform, e.g. the audio and
video stuff that is currently being discussed (mostly elsewhere).

[Ian Hickson]

On Sun, 21 Aug 2011, Bronislav Klu�~Mka wrote:
>
> 1/ and I'm missing the ability to specify, whether data to be sent are
> final or not (whether the frame to be sent should be continuous or not)
> I suppose some parameter for specifying final/continuing frame should be
> there, or some new methods for framing. I've tried to send 100 MiB text
> from Chrome for testing purposes and since there is no way to specify
> framing it was send in one piece.  There is no way to stream data from
> client to server, all data must be kept in memory and sent at once.

Whether the frames are split into multiple frames or not is a browser
decision; at the API level you just say what to send and let the browser
take care of it. It doesn't have to be kept in memory; in fact, if you're
sending a Blob, for example, it's quite possible that the whole thing will
never be stored in RAM. In certain architectures it might never be stored
in RAM, but be sent straight from the disk controller to the network
controller bypassing RAM and the CPU entirely.


> 2/ The same issue for receiving. I understand the need for simple API.
> But again, there is streaming ability missing, all data are received at
> once. Receiving large amount of data could hang up browser. There should
> be onFrameMessage event intercepting frames one by one and (probably by
> some event property) define, whether all those frames should be cached
> and finally exposed by onMessage event (true by default). Programmer
> than can choose to ignore such event (not implement it) and receive all
> messages by onmessage event or implement it, use it for streaming, and
> possibly prevent onMessage calls and unnecessary caching of large data

Supporting sending and receiving streams is something that we'll probably
add in due course. First we have to actually have streams at all in the
Web platform.


> 3/ MessageEvent should expose what kind of data was received, textual,
> blob or arrayBuffer. This would prevent testing for data type and
> problems with testing |binaryType
> <http://dev.w3.org/html5/websockets/#dom-websocket-binarytype> |property
> if changed during data receiving.

I don't really follow here. Isn't the type just going to be what you ask
for?


On Mon, 22 Aug 2011, James Graham wrote:
>
> I imagine that at some point in the future we will expose an interface
> that is optimised for streaming data over websockets. But it seems
> foolhardy to do that before we have any real-world experience with the
> basic API. It is also something that will need to be designed to
> integrate with other streaming APIs in the platform, e.g. the audio and
> video stuff that is currently being discussed (mostly elsewhere).

Indeed.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'