When we started studying the subject we looked at multiple different
addressing and routing options. We had discussions with some HIP and
PSIRP researchers about their experiences with related problems. At
some point we considered designing a separate overlay that would
connect browsers. In the end we came to the conclusion that we wanted
BrowserSocket to be completely agnostic towards addressing and
routing, so it could benefit from all available solutions. Still
BrowserSockets don't limit ones ability to design an overlay
specifically for browsers.
For the existing technologies, using IPv6 for addressing, and Teredo
for connecting hosts seems the best alternative. For servers that do
not require a stable IP address, that is. This fits perfectly the
peer-to-peer, and browser-to-browser cases where nodes might leave or
change addresses suddenly anyway. Teredo is available for Windows,
Mac, and Linux directly from the operating system vendors themselves
who also run the required infrastructure. Note that using Teredo does
not require IPv6 Internet connectivity, only support for IPv6
addressing. We built our prototype as a Firefox extension, and because
of limitations of the extension APIs were not able to use IPv6
addressing ourselves.
The most straight forward way for finding out a working address for a
node is to ask a trusted service to provide one. Such a service could
be run by the browser-to-browser system developers. We are running
such a service at http://ipv4.0-9.fi/ The service allows javascript to
ask for the browser's external IPv4 address. Normally this would be
impossible due to same-origin policy, but we are allowing it
explicitly by setting access control rules with Cross-Origin Resource
Sharing (CORS). A similar scheme could be used with Teredo and IPv6
addressing.
As for advertising nodes, it might make sense for the developer to
provide the discovery service. This might be something as simple as a
data store that browsers can use to exchange peer advertisements.
Alternatively one might use discovery services run by third parties.
We have made some experiments with OpenLookup to see how a third party
operated discovery service might work. As with the address resolution
service, making third party services available to javascript requires
specifying CORS policies on the server side.
--Toni
On Tue, Nov 30, 2010 at 7:14 PM, Nathan nat...@webr3.org wrote:
Hi Toni,
Any notes or thoughts on the DNS and IP Routing side of things, as in how to
distinguish between the various listening browsers on my private network
which all share a single public IP address, and also how to negate conflicts
+ expose the details of the listening socket to the user in order to make a
connection over the web.
As in, what address do I provide you with (and how do I find it) so that we
can use the chat demo client-to-client, also how to communicate that address
when the connection hasn't been made? out-of-band via some other messaging
system?
Best,
Nathan
Toni Ruottu wrote:
Hello,
I work for the computer science department at the University of
Helsinki, Finland. We've been trying to define an API that would allow
web site developers to run simple servers in their web pages. The
motivation behind the research is establishing some ground for
browser-to-browser networking, enabling web sites to co-operate with
end-user systems in new ways.
Today, we are publishing our API draft and working prototype at
http://browsersocket.org/ We are hoping our work will be useful for
people designing related web standards. We look forward to discussing
related topics on the mailing lists.
--Toni
