[whatwg] Web-sockets + Web-workers to produce a P2P website or application

[Gleicon Moraes]

My 2c (as of talking to myself trying to figure out how to do a prototype of
this)...

I'm not sure where such service would belong, but it would suffer the same
problem that early VoIP systems suffered behind a firewall... While one
would be able to open a socket and serve data, there would have to be some
kind of uPnP or NAT integration to make it visible to the web (or a
tunneling solution as those old http-tunnel stuff).

Apart from that, I think it would be something like embedding a webserver
(or better yet embedding node.js [http://nodejs.org/]) in the same level as
the javascript API is implemented and allow pure or pre-arranged sockets to
be open.

AFAIK, using websockets, the browser initiates a connection with the server,
which will proceed upgrading the connection type and opening a two way
communication with the server and from now on the application defines the
line protocol. At least is what I gathered when doing this:
http://github.com/gleicon/txwebsockets

That way, apart from the browser doing this 2-way connection, it could open
a standard tcp socket, or better, a kind of special server and register
itself on a DHT or tracker (that I think would need to be an obligatory
step).

The p2p like mesh network is a great idea, but I think it would take some
security heads thinking around on what socket/server models it would be safe
to let a browser start, a framework for the tracker registering and a
sandbox akin to crossdomain.xml to protect it from turning to a giant
botnet.

I think this kind of thinking would be great with w3c behind it (and a wide
open discussion on security issues), as I think the node.js approach could
be "quicker" to implement browser-wise...

gm



On Fri, Jan 22, 2010 at 6:58 AM, Ivan Žužak <izuzak at gmail.com> wrote:

> On Fri, Jan 22, 2010 at 03:03, Andrew de Andrade
> <andrew at deandrade.com.br> wrote:
> > comments inline
> >
> > On Thu, Jan 21, 2010 at 5:44 PM, Ivan Žužak <izuzak at gmail.com> wrote:
> >> As your Google friend noted, I'm wondering why you'd want to implement
> >> this on the HTML5 level, not on the browser (C++) level. Implementing
> >> such a protocol within the browser would probably be faster, more
> >> secure and a better design choice since the functionality is basically
> >> the same for every web application. I'm guessing the reason is that
> >> you do not want to achieve this by changing/extending the browser but
> >> rather by using new HTML5 technologies instead. Am I right?
> >
> > While I realize that this is best implemented at the browser level, my
> > concern is if it will be an idea that would be broadly adopted by all
> > browser vendors if it is implemented at that level. It's an idea that
> > really has value once you've reached critical mass. For example, this
> > would be an extremely potent idea if the two most popular browsers
> > have implemented this by 2014 to 2015 or so. HTML5 is a web technology
> > spec. I imagine that putting it in the spec would greatly increase the
> > chances of browsers supporting this functionality.
> >
> > However, I am not familiar with the politics that govern whether or
> > not browser product managers implement these features at the browser
> > level?
> >
> > Being pragmatic, do you think it's possible to get widespread adoption
> > quickly for a feature like this as the browser level or do you agree
> > that this would be more likely to be adopted quickly if it was part of
> > a W3C spec?
>
> I think there are two separate issues here. First, if this idea is to
> be widely adopted and implemented - I believe there must be an open
> specification of it. And there are basically two ways of doing this -
> by having it proposed by a specific browser vendor or by having it
> proposed by a standardization organisation like the W3C or IETF. And
> yes, you're right - having something proposed by W3C versus a specific
> browser vendor - I'd say it's more likely to catch on if the W3C puts
> it foot behind it.
>
> Second, there is a difference between a) implementing the idea in the
> browser engine versus b) implementing it as a part of the application
> executing on the browser engine. The same functionality can be
> achieved by defining a protocol which browsers would implement as a
> part their engine (e.g. using some other available protocol instead of
> WebSockets (e.g. plan old HTTP or SPDY) and threads instead of
> WebWorkers) or by creating web applications where each application
> would implement this protocol itself using application level
> technologies (i.e. the proposed WebSockets and WebWorkers tech). In
> essence, it doesn't matter which technology you use to implement it as
> long as it implements the protocol you define. So, since technologies
> used for implementation are open and available, why would the W3C
> wan't this implemented at the application level versus the browser
> level? Both scenarios require changes to both the server of an
> application and the browser.
>
> >> If so, then a major problem is that the browser is not a network
> >> server, rather only a client. In order for a browser A to connect
> >> using WebSockets to a browser B which executes some process, browser B
> >> must expose a network accessible end-point to which that process is
> >> tied i.e. the browser must expose TCP/IP end-point. I guess that the
> >> NAT traversal problem Melvin mentioned basically covers this.
> >>
> >
> > Assuming that this idea really only sees adoption within a few years,
> > won't IPv6 resolve the issue of NAT traversal?
>
> I'm not familiar with NAT traversal or what other novelties IPv6
> introduces other than a broader address space, so I may be wrong when
> saying this but - only by switching from IPv4 to IPv6 will not solve
> this problem. The browser would still be a client initiating
> connections to other network entities, not a server accepting
> connections from those clients. Or as Mike put it: "WebSockets doesn't
> let you open arbitrary ports and listen on them". I'm not getting into
> how hard this is to do, I'm just saying that it's something which is
> necessary.
>
> >> In a broader context of connecting both servers and client devices
> >> into a large network for scalable execution of applications, your idea
> >> reminds me of a recent blog article I read:
> >>
> http://highscalability.com/blog/2009/12/16/building-super-scalable-systems-blade-runner-meets-autonomic.html
> .
> >> Definitely have a look at it - it's a bit on the visionary side and
> >> longish, but worth it. I believe a planet-wide execution platform
> >> consisting of every network device will eventually happen and that's
> >> why I think we should all be contributing in that direction, which
> >> your idea definitely is.
> >
> > I took a brief look. This article looks very interesting. I'm going to
> > have a gander at it tomorrow. Maybe I'll shoot the HighScalability
> > people an email and see if they want to comment on this idea on their
> > blog.
>
> I believe Todd from HighScalability will like the idea. It's a
> direction in which lots of people see the Internet/WWW going. I hope
> you didn't get me wrong with my comments - I like your idea of
> distributing the load towards clients.
>
> Cheers,
> Ivan
>



-- 
More cowbell, please !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100122/f5f0fb18/attachment-0002.htm>