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

Re: Data Channel Buffer Management Proposal

From: Randell Jesup <randell-ietf@jesup.org>
Date: Tue, 19 May 2015 02:46:44 -0400
Message-ID: <555ADC54.6000304@jesup.org>
To: public-webrtc@w3.org
On 5/18/2015 3:09 PM, Benjamin Schwartz wrote:
> 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!

There are reasons "small" timers often get bumped up.  And don't forget 
that this would be originating in a different thread than JS execution 
as well.  However, point taken that promises are better than timer-polling!

 > 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.

There are some details about this to resolve:
* Does this resolve on a transition from "> amount" to "<= amount"?  Or 
does it fire as written (loosely) above, which implies it resolves 
immediately if the current state is <= amount.

If the usage is roughly "check bufferedAmount after each send(), then if 
above upper_threshold call waitForBufferedAmountBelow(lower_threshold) 
and stop sending", then firing immediately makes sense.   I assume this 
is what was intended.

I'm in favor of this.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam
Received on Tuesday, 19 May 2015 06:47:53 UTC

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