[whatwg] Issues with Web Sockets API

[Jeremy Orlow]

On Mon, Jul 27, 2009 at 1:14 PM, Alexey Proskuryakov <ap at webkit.org> wrote:

>
> 27.07.2009, в 12:35, Maciej Stachowiak написал(а):
>
>  However, I do not think that raising an exception is an appropriate
>>> answer. Often, the TCP implementation takes a part of data given to it, and
>>> asks to resubmit the rest later. So, just returning an integer result from
>>> send() would be best in my opinion.
>>>
>>
>> With WebSocket, another possibility is for the implementation to buffer
>> pending data that could not yet be sent to the TCP layer, so that the client
>> of WebSocket doesn't have to be exposed to system limitations. At that
>> point, an exception is only needed if the implementation runs out of memory
>> for buffering. With a system TCP implementation, the buffering would be in
>> kernel space, which is a scarce resource, but user space memory inside the
>> implementation is no more scarce than user space memory held by the Web
>> application waiting to send to the WebSocket.
>>
>
>
> I agree that this will help if the application sends data in burst mode,
> but what if it just constantly sends more than the network can transmit? It
> will never learn that it's misbehaving, and will just take more and more
> memory.
>
> An example where adapting to network bandwidth is needed is of course file
> uploading, but even if we dismiss it as a special case that can be served
> with custom code, there's also e.g. captured video or audio that can be
> downgraded in quality for slow connections.


Maybe the right behavior is to buffer in user-space (like Maciej explained)
up until a limit (left up to the UA) and then anything beyond that results
in an exception.  This seems like it'd handle bursty communication and would
keep the failure model simple.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090727/279ebf68/attachment-0001.htm>