- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Jan 2019 17:13:23 +0000
- To: public-webrtc-logs@w3.org
> Those SCTP chunks data retransmissions will use bandwidth, that won't be available for audio and video. Note that audio/video may be hardware accelerated and not affected by the js loop at all. Ah, I misread your comment. That is a different story though. We have the competition discussion longer than I've been participating and I doubt it's going to make much of a difference if we intentionally drop packets because the event loop queue is already overburdened. The browser will likely have different issues once it reaches that point. > I am speaking about receiving data, not sure how the .send call is involved. `.send` raises an exception if one tries to send a message larger than the other peer supports. > And I was referring that without a new API we will be in this situation anyway. What situation are we in with the current API? Can spontaneously deadlock? No. Can go OOM? Perhaps in dire circumstances. I wouldn't judge browsers killing data channels or even peer connections that go insane with memory usage as long as it's documented. > Maybe the sctp transmission will not be halted, but the browser will die when having reserved several GBs on intermediary buffers. So yes, I prefer the sctp spontaneous deadlock (Note: I am speaking without an API change). Then let's agree that we will not agree on this. -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-458218755 using your GitHub account
Received on Monday, 28 January 2019 17:13:25 UTC