Re: Data Channel Buffer Management Proposal

We could certainly add an event that fires every time bufferedAmount
decreases.  I expect this would generally amount to an event for every call
to send().  In my view, this is wasteful, because the only real use I see
for the event is to check whether bufferedAmount is below a threshold.

On Mon, May 18, 2015 at 3:06 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> Instead of having a promise, could we have a "buffer drain" event which
> fires whenever the buffer drains, and then you could check the size
> in the callback?
>
> -Ekr
>
>
> On Mon, May 18, 2015 at 11:53 AM, 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
>>>
>>
>>
>