- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Sat, 26 Jan 2019 22:14:18 +0000
- To: public-webrtc-logs@w3.org
> let's put it in a different view. Taking into account just one single datachannel will the proposed solution solve the issue? No, not with the message-based API that we have. My second example in https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-457827612 (2 MiB message, 1 MiB receive buffer) would still apply for just a single channel. > Also, does the problem about multichannel buffering still exist without taking into account the event loop queueing issue? Yes. We can pause receiving on the whole association (read: all streams simultaneously) which lets the flow control kick in. We cannot selectively pause receiving on individual streams. It's either receiving data on all streams or (eventually) receiving no data. > you may have a solution for not problems simultaneously, but it also requires a change in w3c apis and ietf specs. Yeah, there's no easy fix. It's just how it is. :woman_shrugging: @jan-ivar and I briefly touched this topic as part of the streams extension. My idea to ~~solve~~ work around this goes into the direction of kindly asking the sender to pause/continue sending data on a particular stream by using a special PPID. > To solve this issue we only need one line in the spec without api change. Unfortunately not. -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-457870428 using your GitHub account
Received on Saturday, 26 January 2019 22:14:20 UTC