- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Mon, 27 Jul 2009 13:20:19 -0700
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