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

the issue that @lgrahl is highlighting is an original one,  IMO. With
current api,  data is buffered by the dc stack until all the chuncks are

So if ndata is in use, it may happen that non completed messages may drain
the receive buffer, stalling the sender.

But, again, that's a different problem that requires a different solution.
Maybe a new issue should be opened for not mixing both discussions?

El sáb., 26 ene. 2019 12:45, henbos <> escribió:

> Whenever there are multiple streams of traffic on the "same wire" there
> will be competition, some packets will get dropped and some packets will
> arrive. @lgrahl <> Why do you think that if the
> buffer is shared one data channel would end up dominating it? (How does
> SCTP prioritize different channels?) Is your concern in general use cases,
> or is this only a concern in edge cases such as if one data channel is
> sending messages the size of the entire buffer, leaving no room for other
> messages, and SCTP prioritizing the same channel every time? (Follow-up
> question: If there is a legitimate concern, is there no good way for the
> application to get around it?)
> The fix I'm proposing does not change how SCTP work but it does provide a
> feedback mechanism between the JS thread and the network thread. JS will
> still have "onmessage" fire in accordance to SCTP receiving messages, it
> will however ensure that the buffer does not get emptied faster than it is
> processed by the application.
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <>, or mute
> the thread
> <>
> .

GitHub Notification of comment by murillo128
Please view or discuss this issue at using your GitHub account

Received on Saturday, 26 January 2019 11:54:04 UTC