[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5578 [Flashproxy]: Investigate WebRTC for flash proxy NAT punching
#5578: Investigate WebRTC for flash proxy NAT punching
------------------------+---------------------------------------------------
Reporter: dcf | Owner: dcf
Type: task | Status: new
Priority: minor | Milestone:
Component: Flashproxy | Version:
Keywords: | Parent:
Points: | Actualpoints:
------------------------+---------------------------------------------------
Comment(by cjb):
I chatted with a friend who is a Google WebRTC developer (Ben Schwartz),
and he had some good ideas and pointed out some problems that I hadn't
thought of.
The largest problem is how the client transport plugin is going to work,
because there's not yet any headless WebRTC implementation; it's very
attached to the DOM. I'd been assuming that node.js will grow a library
that speaks WebRTC across each of Firefox/Chrome/node with a common API --
socket.io does this for websockets -- but the requirements for WebRTC are
far greater. Ideally you need a full libjingle port, and at the least you
need ICE and SCTP. Node currently doesn't have any SCTP support, as far
as I can see.
So our options include waiting for node to grow a lot of code that doesn't
exist right now, or having the client transport plugin be written in C
instead of node and linked with libjingle, or finding a way to avoid
having a full client transport plugin.
Ben's suggestion for avoiding a client transport plugin is that the plugin
could be a SOCKS-style proxy that bounces the data back into the local
browser through a websocket on the local machine, and some JavaScript in
the browser handles brokering between the websocket and an outgoing WebRTC
datachannel.
Some interesting node projects:
https://npmjs.org/package/peer-connection-shim
https://github.com/rogerwang/node-webkit
Current status of the browser-side code is that peerjs.com looks like the
right thing for a common API, but it only supports Chrome rather than
Firefox, and only Firefox has support for reliable transfers in
datachannels. So we're either waiting for Chrome to support reliable
transfers, or PeerJS to support Firefox.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5578#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs