[whatwg] Issues with Web Sockets API

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

Received on Monday, 27 July 2009 17:25:53 UTC