[whatwg] Issues with Web Sockets API
Maciej Stachowiak
mjs at apple.com
Mon Jul 27 17:25:53 PDT 2009
On Jul 27, 2009, at 2:14 PM, Alexey Proskuryakov 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.
If an application could usefully choose to do something other than
buffer in memory (as applies to both of your examples), then yes, it
would be useful to tell it when to back off on the send rate. But this
could also be combined with buffering inside the implementation but
outside the kernel, so the client of WebSocket never has to resend
whole or partial packets, it can just note that it should back off on
the send rate, and delay future packets.
Regards,
Maciej
More information about the whatwg
mailing list