- From: Sergio Garcia Murillo via GitHub <sysbot+gh@w3.org>
- Date: Sat, 26 Jan 2019 08:26:11 +0000
- To: public-webrtc-logs@w3.org
What kernel? All I am saying is that the 4GB limit in the spec is enough and we don't need another mechanism on the wire protocol for that, as the bottleneck is in another place. As I said before, an API for delivering data to the app as soon as it is received on the sctp chunks, ndata for interleaving and the change to the a_rnwd handling would solve all the issues. For the specific topic of this issue, the a_rnwd change is enough. El sáb., 26 ene. 2019 9:18, Lennart Grahl <notifications@github.com> escribió: > that's an implementation issue > > I said that. 🙂 However, ... > > either modify usersctp to support it or use anothet datachannel > implementation. > > But you do realise that this is pretty unrealistic? Announcing a 4 GiB > receive window is essentially lying if the buffer is dynamic. And it is > even more unrealistic in the kernel. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-457812740>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ABBW87j8HuDCOzdB3U0ZBBEr0dMbm8Eiks5vHA9JgaJpZM4aS7_J> > . > -- GitHub Notification of comment by murillo128 Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-457813125 using your GitHub account
Received on Saturday, 26 January 2019 08:26:12 UTC