W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2019

[webrtc-pc] (How) does SCTP handle CPU-bound congestion on JavaScript thread? (#2086)

From: henbos via GitHub <sysbot+gh@w3.org>
Date: Fri, 25 Jan 2019 14:04:42 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-403170249-1548425081-sysbot+gh@w3.org>
henbos has just created a new issue for https://github.com/w3c/webrtc-pc:

== (How) does SCTP handle CPU-bound congestion on JavaScript thread? ==
How is the JavaScript application supposed to be able to apply back pressure?
CC @marinaciocea 

The spec says:

> When an RTCDataChannel message has been received via the underlying data transport with type type and data rawData, the user agent MUST queue a task to run the following steps:
>
> [Convert data to the appropriate JS object and fire "onmessage".]

I don't see any feedback mechanism to tell the underlying data transport that we're actually done consuming the message. It looks like the underlying transport is free to queue tasks ad-infinitum to fire messages. The message is just taken out of the SCTP buffer and put on a PostTask to another thread. So SCTP should be free to receive more messages, whether or not JavaScript can keep up.

What if that other thread (JavaScript) is really slow at processing "onmessage"? E.g. I'm being sent 10000 numbers p*q per second and I spend 1 second per message calculating the values of p and q. Will the task queue get overflooded?

Am I missing something?

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086 using your GitHub account
Received on Friday, 25 January 2019 14:04:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:54 UTC