- From: Toni Ruottu <toni.ruottu@iki.fi>
- Date: Tue, 30 Nov 2010 20:08:18 +0200
- To: nathan@webr3.org
- Cc: public-webapps@w3.org, Konrad Markus <konrad.markus@hiit.fi>, Sasu A O Tarkoma <starkoma@cc.helsinki.fi>
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 <nathan@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 >> >> >> > > >
Received on Tuesday, 30 November 2010 18:08:52 UTC