<br><div class="gmail_quote">On Mon, Jul 27, 2009 at 1:14 PM, Alexey Proskuryakov <span dir="ltr"><<a href="mailto:ap@webkit.org">ap@webkit.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
27.07.2009, в 12:35, Maciej Stachowiak написал(а):<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

</blockquote>
<br>
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.<br>

</blockquote>
<br>
<br></div>
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.</blockquote>
<div><br></div><div>I would suggest that the solution to this situation is an appropriate application-level protocol (i.e. acks) to allow the application to have no more than (say) 1MB of data outstanding.</div><div><br></div>
<div>I'm just afraid that we're burdening the API to handle degenerative cases that the vast majority of users won't encounter. Specifying in the API that any arbitrary send() invocation could throw some kind of "retry exception" or return some kind of error code is really really cumbersome.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
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.<br>

<br>
- WBR, Alexey Proskuryakov<br>
<br>
</blockquote></div><br>