W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] Issues with Web Sockets API

From: Jeremy Orlow <jorlow@chromium.org>
Date: Mon, 27 Jul 2009 13:20:19 -0700
Message-ID: <5dd9e5c50907271320t6903cd9fy279fc6f4c9fe6be4@mail.gmail.com>
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>
Received on Monday, 27 July 2009 13:20:19 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC