[whatwg] Issues with Web Sockets API
jorlow at chromium.org
Mon Jul 27 13:20:19 PDT 2009
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
> 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...
More information about the whatwg