Re: Data Channel Buffer Management Proposal

Yes, Promises only resolve once, so you would need to call this method each
time you wanted to start waiting.  Promises are fast: the slowest Promise
operation I could find takes 54 microseconds in Chrome for Android on my
Nexus 4.  That's a lot better than setTimeout/setInterval, which takes at
least 4000 microseconds!

On Mon, May 18, 2015 at 2:53 PM, Peter Thatcher <pthatcher@google.com>
wrote:

> Would the JS need to call waitForBufferedAmountBelow again each time the
> Promise is fired?  It's too bad we don't have promises that can fire
> multiple times.
>
> Other than the need to have this be called many times, and the possible
> performance consequences of that, I like this API.
>
> On Mon, May 18, 2015 at 11:43 AM, Benjamin Schwartz <bemasc@google.com>
> wrote:
>
>> Right now, the data channel specification allows the sender to check the
>> amount of pending outbound data using the ".bufferedAmount" property.  In
>> fact, senders are effectively required to check this value when sending
>> large amounts, to avoid queueing up too much data in memory.  However, if
>> the sender does need to wait for bufferedAmount to decrease, it must use
>> timer-based polling to determine when bufferedAmount has decreased, and it
>> is safe to send again.
>>
>> To remove the need for polling, I propose the following addition to the
>> RTCDataChannel API:
>>
>> Promise<void> waitForBufferedAmountBelow (unsigned long amount);
>>
>> This method returns a Promise that resolves when this.bufferedAmount <=
>> amount, or rejects if the channel reaches the "closed" state.
>>
>> --Ben
>>
>> P.S.  This issue has also been discussed at
>> https://code.google.com/p/webrtc/issues/detail?id=4613
>>
>
>