On Mon, Jul 27, 2009 at 1:44 PM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com">atwilson@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Mon, Jul 27, 2009 at 1:36 PM, Alexey Proskuryakov <span dir="ltr"><<a href="mailto:ap@webkit.org" target="_blank">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, в 13:20, Jeremy Orlow написал(а):<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<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>
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.<br>
</blockquote>
<br>
<br></div>
This sounds like the best approach to me.<br>
<br>
<br>
27.07.2009, в 13:27, Drew Wilson написал(а):<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.<br>
</blockquote>
<br></div>
Having a send() that doesn't return anything and doesn't raise exceptions would be a clear signal that send() just blocks until it's possible to send data to me, and I'm sure to many others, as well. There is no reason to silently drop data sent over a TCP connection - after all, we could as well base the protocol on UDP if we did, and lose nothing.<br>
</blockquote><div><br></div></div></div><div>There's another option besides blocking, raising an exception, and dropping data: unlimited buffering in user space. So I'm saying we should not put any limits on the amount of user-space buffering we're willing to do, any more than we put any limits on the amount of other types of user-space memory allocation a page can perform.</div>
</div></blockquote><div><br></div><div>I agree with Alexey that applications need feedback when they're consistentiently exceeding what your net connection can handle. I think an application getting an exception rather than filling up its buffer until it OOMs is a much better experience for the user and the web developer.</div>
<div><br></div><div>If you have application level ACKs (which you probably should--especially in high-throughput uses), you really shouldn't even hit the buffer limits that a UA might have in place. I don't really think that having a limit on the buffer size is a problem and that, if anything, it'll promote better application level flow control.</div>
<div><br></div><div>J </div></div>