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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15206

Randell Jesup <rjesup@jesup.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rjesup@jesup.org

--- Comment #2 from Randell Jesup <rjesup@jesup.org> 2011-12-19 17:06:39 UTC ---
There's an extensive discussion on this point starting on Nov 15 2011 on the
rtcweb mailing list (started by me), under the title "Data channel setup and
signalling".  http://www.ietf.org/mail-archive/web/rtcweb/current/msg02861.html

Summary: I propose that (some) data channels be opened without use of
offer-answer signaling, based on the application, perhaps using a data channel
initially set up to let the application request data channels using
application-specific messages.  In particular, applications should be allowed
to avoid a re-negotiation of all channels to open data channels, when the
application knows it's talking to another copy of itself (or equivalent).

This proposal mostly covered the IETF side of things; how these would be
exposed to the JS app is something I hadn't answered and would enjoy
suggestions on.

Quoting one bit to highlight:


A use-case would be a background http proxy-server during chat. If you have to
re-OFFER for each data channel that comes and goes to transfer a resource, it
will both swamp the server and be slow (due to the triangle signalling). If
instead the application can open a single control data channel, and invoke
transfers over it, the application can efficiently transfer a high number of
URIs. Are there other ways to do this without re-OFFERing constantly? yes. But
they generally involve building protocols on top of an array of long-lasting
generic connections.

For example, the control data channel might pass messages (directly
browser-to-browser) like

{
   id: 1,
   command: "GET",
   URI: "blah/foo/bar",
   channel: 5,
}
with an answer:
{
   id: 1,
   result: "ok",
   size: 1234,
}

followed by transfer of the URI on data channel 5. (Note: in this I'm assuming
an API that lets the app open a specific data channel of the peer connection.)

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.

Received on Monday, 19 December 2011 17:06:46 UTC