Perhaps the reason we have not seen single-page html applications that connect directly to peers without an intermediate server is that browsers cannot easily listen on a local port. They can open outgoing connections all day long, but WebRTC may be the first web standard that allows the browser to listen on a port. If there are others, please let me know.
Of course, the WebRTC spec looks overly complicated for the incredibly simple thing I want to do. I just want the browser to be able to listen on a port like any other process on the machine can. Sure, there are security implications, but these exist for everything the browser exposes to web applications, and there's an entire class of Peer-to-Peer web apps that simply cannot easily be written using current web technologies.
There are many examples of a Peer-to-Peer experience being delivered to users using a client-server architecture. ChatRoulette, Omegle, and even more recently, products like Google Hangouts. These applications must be implemented by using servers in the middle to connect the peers, making scaling them much harder than it would be if browsers could just listen.
There is an opportunity to explore a generic Client-Agent-Peer architecture, where Clients (Browsers) talk to an Agent server using HTTP to configure the state of the Agent, which would then be contacted by the Peer on behalf of the Client when the Browser is not online. When the Browser is online, the Agent can refer the Peer directly to the Client. When the Browser is offline, the Agent can handle the request itself using a cached copy of the material the Browser was sharing, or it can just decline to fulfill the request.
Reverse HTTP was my attempt to push out the simplest thing that could possibly work to get browsers to talk to each other. It didn't really go anywhere in terms of being implemented in actual browsers. Coincidentally, someone else had the same idea around the same time, and implemented Reverse HTTP in terms of actual HTTP Requests encoded in Responses, and vice versa. This makes it possible to write a pure javascript client rather than needing the browser to support the Upgrade protocol itself.
Really, though, it would be very nice if all of the hacks and tricks and workarounds weren't necessary, and I could just listen on a port with javascript. I'll keep dreaming.
3 comments:
One approach is to do a browser plugin, though I don't think it'll work in Chrome since you don't get that kind of low level access.
Jeff Hammel of Mozilla pointed me to this, which he tells me they use in testing in some places: https://mxr.mozilla.org/mozilla-central/source/netwerk/test/httpserver/httpd.js
The bigger question I've struggled with when thinking about this space is what to do about global addressability. Peer to peer web apps are neat, but you still need to rendezvous at a known origin to get the app and set up your NAT traversal. Whereas, for me, the *real* peer to peer web app is the one that my browser serves to your browser, but then we need something you can put in the location bar that resolves to me.
We could register using some dynamic dns host, but I'd still be behind a NAT much of the time. I'm still holding on to the dream that a proper overlay network could let us all have inbound connectivity even behind NATs, but then we have to create such an overlay and tunnel HTTP over it. Probably do-able, but a lot of work needs to be done to get there.
Thanks for pointing me to httpd.js!
For addressability, that is where I usually reach for the "Agent" concept... the browser has a server, but it uses the Agent as it's public address and the Agent either proxies to the browser if it's online or handles the request itself if the browser is offline.
If IPv6 ever takes off and NAT starts to slowly die, maybe eventually there won't be as many obstacles to this.
You can't just dismiss security concerns with "but these exist for everything the browser exposes to web applications"!
Well, maybe YOU can, but browser developers can't.
Post a Comment