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

Re: Data Channel Buffer Management Proposal

From: Benjamin Schwartz <bemasc@google.com>
Date: Mon, 18 May 2015 15:09:25 -0400
Message-ID: <CAHbrMsDC+JyD1w8Dyqmoc5yGCqkEWe1kosC-=kamqHCXW7m-1Q@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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>

> 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:09:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC