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

[whatwg] Issues with Web Sockets API

From: Alexey Proskuryakov <ap@webkit.org>
Date: Mon, 27 Jul 2009 13:14:29 -0700
Message-ID: <4B84866D-E504-4CB6-AE51-30F85F33E214@webkit.org>

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.

- WBR, Alexey Proskuryakov
Received on Monday, 27 July 2009 13:14:29 UTC

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