W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2015

Re: Data Channel Buffer Management Proposal

From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 18 May 2015 12:06:48 -0700
Message-ID: <CABcZeBMupVAmooerVtURrNb1OLN7OJKDMDctq9DDYLaR0_xtWw@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Cc: Benjamin Schwartz <bemasc@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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
>>
>
>
Received on Monday, 18 May 2015 19:07:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:06 UTC