- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Jan 2019 10:00:50 +0000
- To: public-webrtc-logs@w3.org
> As long as streams are sharing this buffer, one stream not being read from would eventually bring all other streams to a standstill. As I understand it, it is impossible not to read from a stream under normal conditions. As soon as the message has arrived, _W_ is emptied and "onmessage" fires (or with my proposal: _W_ is emptied when JS thread is no longer blocked). It doesn't matter if anybody listens to this event or not, from SCTP's point of view the message has been delivered. The only way a stream would not be read from is if it never arrives in its entirety, a half-received message clogging up _W_ forever. If messages are sent sequentially, I believe this is an impossibility (_B_'s message would complete before _A_'s messages are put in _W_). If messages are sent "in parallel" (doesn't have to be true parallelism, but assuming there is competition here), there may be a possibility of lots of small messages on one channel "choking" a large message on another channel that never fully completes in _W_. If so this could potentially be a problem for both the the receiver's receive buffer (discussed here) and sender's send buffer (analogous problem). I do believe this is a very important but separate problem from: > Feeding back a signal to the SCTP stack to let the flow control kick in and stop receiving data due to CPU load on the JS thread? As for this: > Feeding back a signal to whatever thread is handling the SCTP stack to stop delivering messages to the JS thread? (No, this does not allow the flow control to kick in or it would be equivalent to 1.) If congestion control kicks in then a consequence of that would be that messages are not delivered on the JS thread, because they have not fully arrived on _W_. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-458065575 using your GitHub account
Received on Monday, 28 January 2019 10:00:55 UTC