Re: My personal input to the WebRTC-NV discussions

Hey everyone, I would like to add a wish for WebRTC-NV:

As you may have heard, we have added the possibility to send large data
channel messages to Firefox and handle them correctly when receiving
(obeying SCTP's EOR flag to not violate message integrity).
But the key issue hasn't been addressed which is that the data channel
API is too high level for sending large messages. We need a way to (at
least optionally) send and receive data channel messages in chunks, so
large messages can be exchanged without creating enormous backpressure
for both peers. The current API forces every application that wants to
transfer large amounts of data into rolling their own
fragmentation/reassembly implementation. That is annoying and entirely
unnecessary as this is done on top of a transport protocol that is
already able to do fragmentation/reassembly easily and probably more
efficiently-

Currently, the RTCQuicStream API is being developed for the ORTC spec
(https://github.com/w3c/ortc/pull/785) with buffering aspects in mind.
Maybe we can take a few ideas regarding the buffering aspect of the API
from there (even though this is a byte stream and data channels exchange
datagrams). I already have a few ideas regarding the API to send/receive
in chunks, so feel free to ping me.

Cheers
Lennart


On 07.11.2017 08:24, Harald Alvestrand wrote:
> I've tried to put together my thinking about what I think we should try
> to achieve with WebRTC-NV.
> 
> Chiefly, I've tried to look for the principles: What we should keep on
> doing, what we should make it possible to live without, and what we
> should extend further.
> 
> I've enclosed it in PDF. It looked prettier that way. Comments can also
> be made here:
> 
> https://docs.google.com/document/d/1pU4YR0hbH2IhE-s8_CggRdADps_9rambnfsOz3VH_ew/edit?usp=sharing
> 
> Harald
>

Received on Tuesday, 7 November 2017 22:38:03 UTC