Re: [rtcweb] Open data channel issues

[Randell Jesup <[e-mail]>]

On 3/3/2014 8:53 AM, Martin Thomson wrote:
> On 3 March 2014 03:44, Randell Jesup <[e-mail]> wrote:
>> Hopefully so, though I hate forcing apps to include a bunch of code for
>> backwards compat for a year or two (and many won't, or won't test it, etc).
>> That hurts the feature.  And today no one has ndata.
> Since WebRTC is behind a flag, I don't find this particularly
> convincing.  We can implement ndata.

I don't understand the "behind a flag" comment; an app using 
DataChannels for anything variable-length (unless with low bounds) must 
care until all old implementations are gone.  Since we already have 
DataChannel impls in  ESR releases, there's no avoiding this if we rely 
on that (even worse, since this undefined property doesn't exist yet 
(let alone in ESR), the app has to handle that case as well).  Or add 
browser and version sniffing to all the apps...

> I think that we could even remove our temporary length restriction.

Sure, we can.  This will reduce or eliminate source changes for apps 
that don't care about interleaving, which is a plus.  It will cause 
total stall of all other DataChannels during  transmission of one large 
message, which some applications would be ok with, and others would not, 
and so those that would not would have to somehow deal with it.

So, applications that are ok with blocking other channels with large 
sends could be allowed to send arbitrary-sized messages, and receivers 
would be required to receive them (without chunking). Applications that 
do care about other channels would need to restrict their sending size 
when ndata isn't available at both ends.  We really only need to know if 
ndata is available and expose that fact to the application, not a 
receive size from the receiver.

So this plan would be:
1) We expose ndata being agreed to (currently == false);
2) We turn off the PPID chunking in Firefox (and live with ESR24 and 
current revs of Firefox not being compatible; see 2a)
2a) we make sure the app can detect if the local client has the ndata 
property at all (supports this solution).
3) We make sure Chrome and Firefox both implement both EOR sending and 
EOR reception and unlimited (or virtually) send/receive sizes.

For bonus points, on EOR reception of a blob, spool it to disk in the 
browser (if over some limit perhaps), and on EOR send of a blob, 
optimize it to avoid send-side memory hits and performance issues.

This will break large send/receive between Chrome and current/older 
Firefox - but those are broken today by Chrome not implement PPID 
chunking and Firefox doing so.  Firefox can still fall back on PPID 
chunking if it knows it's talking to another Firefox until we decide 
that this no longer matters.  I could be wrong, but I think Chrome 
doesn't support EOR sending currently; I know Firefox doesn't since we 
were using PPID chunking, so we'd need to add that.

Once ndata is supported, all will work well, and applications that 
didn't care about interleaving don't have to change, and those that do 
will trigger on ndata and switch (and they can test ndata==true mode 
reasonably well by forcing it in the app, since send(large) will work).

-- 
Randell Jesup -- rjesup a t mozilla d o t com