Re: [Bug 15206] Add API for sending and receiving p2p application data

On 1/26/2012 3:15 PM, bugzilla@jessica.w3.org wrote:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15206
>
> --- Comment #9 from Justin Uberti<juberti@google.com>  2012-01-26 23:15:35 UTC ---
> New in this version:
>
> Changes for Jan 2012 W3C meeting; tied DataStreams to a PeerConnection; changed
> DataStream base class; added MTU for unreliable streams; better WebSocket
> alignment (added other send() variants, removed onreadytosend); added reliable
> and multiparty examples

Thanks Justin.

I'll note that creating a datastream here requires a full renegotiation 
of the entire peerconnection (though one assumes the other items don't 
change state and thus would end up being no-ops after lots of processing 
occurs.

There are alternatives that would not require renegotations of the 
peerconnection, as mentioned in a previous message thread titled "Data 
channel setup and signalling", starting 11/15/2011, or would only 
*require* negotiating one channel and use an application-specific 
protocol over that one to open additional ones.

http://www.ietf.org/mail-archive/web/rtcweb/current/msg02861.html

I'll repeat one bit from that which is relevant:

>  The other option is to have (some) data channels be separate from media, in
>  particular app-specific anonymous data channels.  There's no requirement for
>  describing the channels if they're private to the app, at least to the first
>  approximation.  An app could pre-define data channel 3 as a private message
>  structure for game map updates, so long as it knows its talking to itself.


Unless there's some higher-level structure imposed on the data somehow, 
data channels are inherently application-specific, so generic stream 
specifications and "negotiation" of them actually buys you very little 
(except *maybe* the first one).  This is different from audio and video 
streams and their encodings.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Friday, 27 January 2012 00:33:33 UTC