Re: Data API: what is agreed, what is open

(As contributor)

On 02/07/2012 09:20 PM, Justin Uberti wrote:
> Inline:
>
> On Tue, Feb 7, 2012 at 3:03 PM, Randell Jesup <randell-ietf@jesup.org
> <mailto:randell-ietf@jesup.org>> wrote:
>
>     On 2/7/2012 12:10 PM, Stefan Hakansson LK wrote:
>
>         Hi all,
>
>         trying to summarize the discussion on the Data API, I come to this:
>
>
>     Unless otherwise specified, I agree with the comments here.
>
>
>         Agreed
>         ======
>         * The API should allow for the application to use multiple channels
>         (without having to to do muxing in the app)
>         * The API should allow the application to select reliable or
>         unreliable
>         transmission (where "reliable" also means "in order delivery")
>         * The API should initially enable sending and receiving
>         DOMString, Blob
>         and ArrayBuffer data
>
>
> Agree. The last point implies we need some header information to be
> passed to allow the remote side to know if it is getting a DOMString or
> binary data. During today's hangout, the PPID field was suggested for
> this purpose.

I agree. And that info field should not be one bit; looking ahead we can 
expect that the Stream API makes it into the File API spec (this seems 
likely to happen this year), and then we would like to be able to send a 
Stream. And we should not exclude other types in the future (note that 
XHR can send even more types). All I'm trying to say is that this is a 
point were we should have some extensibility built in.

>
>
>     We also need to decide how the JS API can be designed to feed back
>     out-of-order and loss data for unreliable data (i.e. on an
>     unreliable stream, you need to be able to examine the sequence
>     numbers).  It probably should be available on all message receptions
>     (though pretty much irrelevant for reliable in-order dataChannels).
>
>
> I was thinking we would have an additional parameter to onmessage that
> would contain sequence number and other meta-info for the message.

That might be a good idea (but has the downside that we can't use 
MessageEvent as-is, we need to add some stuff).

>
>
>
>     Are we agreeing that the API is purely a JS-level datagram API, or
>     do we split "too-large" blobs/etc into smaller datagrams internally
>     (closer to WebSockets)?  Note that for unreliable data, that would
>     require us to buffer until all parts of a blob/etc had been received
>     (or throw it all away if parts are missing for "too long").  This
>     could be moderately complex and require significant memory space for
>     very large blobs, as well as requiring our own user-level
>     fragmentation/reassembly code. Even for reliable in-order data, if
>     we fragment we must do reassembly before delivering it.
>
>     If instead we consider the API to be a user-level (typed) datagram
>     API, then we (WebRTC) do no direct fragmentation or reassembly, and
>     simply rely on the SCTP stack to do that.  There is a (minor?)
>     downside in that massive datagrams may block other channels until
>     they're sent; I think Randall Stewart was saying they want to fix
>     this.  (Randall?)
>
>     I am very much in favor of sticking to a datagram API and not adding
>     another layer of fragmentation/reassembly.  If need be, we can
>     suggest (as mentioned in the Interim) that applications avoid
>     sending too-large blobs.  I think it would be easy to provide some
>     example JS helper functions to transfer files while avoiding sending
>     a single humungous datagram.
>
>
> +1

If sending a huge blob does not make things crash (unless you run out of 
memory that is), but merely blocks other channels, I'm all for it.

Note that the File API spec has tools for splitting up blobs into 
smaller pieces (the slice method), and of course for re-assembling them, 
so this would be quite simple if the app developer wants to ensure other 
channels are not blocked.

>
>
>
>         * The API should allow the application to check if data is being
>         buffered (so that it can adjust the send rate)
>         * The API should be designed to allow extension in functionality
>         (e.g.
>         set priority, set that in-order delivery is not to be used for
>         reliable,
>         etc.) and data types (e.g. to introduce Stream once the WebApps WG
>         defines it)
>
>         Open
>         ====
>         * Should the API be uni- or bi-directional?
>
>
>     I plan to write it up as unidirectional barring objection.
>
>
>         * Should there be a specific "open" signal to the application
>         (or should
>         the object dealt with when sending only be made available when
>         transmission is possible), or should data be buffered until it
>         can be
>         transmitted (i.e. the app can always "send")?
>
>
>     Open question.  There are two variants of open: one is wait until
>     the other side has reacted to the onadd notification (which would
>     likely require us to reserve a stream for control info, which I'm ok
>     with), the other is to wait until the channel is available to send
>     into (association created and SCTP stream available), but not wait
>     for a handshake.  There's an open question here about how incoming
>     data is handled and queued for delivery relative to onadd.
>
>
>     Also: we have a receive object; once we set the onmessage attribute,
>     I assume any queued data would be delivered (how much can queue?
>       Probably limited by buffer space.)  If the app *doesn't* set
>     onmessage, what happens?  If this is a problem, we may need a
>     handshake back to the sender (for onopen) when the receiver has set
>     onmessage, and set the receive object to drop datagrams if/whenever
>     onmessage isn't set.
>
>
>
>         We would like comments, both if you agree to what we state as
>         "agreed",
>         and input on what you prefer on the open issues. And of course other
>         things we have a agreement on, and other things that are open.
>
>
>
>     --
>     Randell Jesup
>     randell-ietf@jesup.org <mailto:randell-ietf@jesup.org>
>
>

Received on Wednesday, 8 February 2012 09:31:33 UTC