<br><br><div class="gmail_quote">On Tue, Jan 19, 2010 at 5:59 PM, Andrew de Andrade <span dir="ltr"><<a href="mailto:andrew@deandrade.com.br">andrew@deandrade.com.br</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have an idea for a possible use case that as far as I can tell from<br>
previous discussions on this list has not been considered or at least<br>
not in the form I present below.<br>
<br>
I have a friend whose company produces and licenses online games for<br>
social networks such as Facebook, Orkut, etc.<br>
<br>
One of the big problems with these games is the shear amount of static<br>
content that must be delivered via HTTP once the application becomes<br>
popular. In fact, if a game becomes popular overnight, the scaling<br>
problems with this static content quickly becomes a technical and<br>
financial problem.<br>
<br>
To give you an idea of the magnitude and scope, more than 4 TB of<br>
static content is streamed on a given day for one of the applications.<br>
It's very likely that others with similarly popular applications have<br>
encountered the same challenge.<br>
<br>
When thinking about how to resolve this, I took my usual approach of<br>
thinking how do we decentralize the content delivery and move towards<br>
an agent-based message passing model so that we do not have a single<br>
bottleneck technically and so we can dissipate the cost of delivering<br>
this content.<br>
<br>
My idea is to use web-sockets to allow the browser function more a<br>
less like a bit-torrent client. Along with this, web-workers would<br>
provide threads for handling the code that would function as a server,<br>
serving the static content to peers also using the program.<br>
<br>
If you have lots of users (thousands) accessing the same application,<br>
you effectively have the equivalent of one torrent with a large swarm<br>
of users, where the torrent is a package of the most frequently<br>
requested static content. (I am assuming that the static content<br>
requests follow a power law distribution, with only a few static files<br>
being responsible for the overwhelming bulk of static data<br>
transferred.).<br>
<br>
As I have only superficial knowledge of the technologies involved and<br>
the capabilities of HTML5, I passed this idea by a couple of<br>
programmer friends to get their opinions. Generally they thought is<br>
was a very interesting idea, but that as far as they know, the<br>
specification as it stands now is incapable of accommodating such a<br>
use case.<br>
<br>
Together we arrived at a few criticisms of this idea that appear to be<br>
resolvable:<br>
<br>
-- Privacy issues<br>
-- Security issues (man in the middle attack).<br>
-- content labeling (i.e. how does the browser know what content is<br>
truly static and therefore safe to share.)<br>
-- content signing (i.e. is there some sort of hash that allows the<br>
peers to confirm that the content has not been adulterated).<br>
-- privacy issues<br></blockquote><div><br>Yes I sort of see this kind of thing as the future of the web.  There's an argument to say that it should have been done 10 or even 20 years ago, but we're still not there.  I think websockets will be a huge step forward for this kind of thing.  One issue still remains NAT traversal, perhaps this is what has held developers back, though notable exceptions such as skype have provided a great UX here.<br>
<br>Gaming is one obvious application for this, which in many ways is the pinnacle of software engineering.<br><br>I see this kind of technique really bringing linked data into its own (including RDFa) where browsers become more data aware and more socially aware and are able interchage relevant information.   Something like FOAF (as a means to mark up data) is well suited to provide a distributed network of peers, can certainly handle global namespaced data naming, and is getting quite close to solving privacy and security challenges.  <br>
<br>Im really looking forward to seeing what people start to build on top of this technology, and your idea certainly sounds exciting.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
All in all, many of these issues have been solved by the many talented<br>
programmers that have developed the current bit-torrent protocol,<br>
algorithms and security features. The idea would simply to design the<br>
HTML5 in such a way that it can permit the browser to function as a<br>
full-fledged web-application bit-torrent client-server.<br>
<br>
Privacy issues can be resolved by possibly defining something such as<br>
"browser security zones" or "content label" whereby the content<br>
provider (application developer) labels content (such as images and<br>
CSS files) as safe to share (static content) and labels dynamic<br>
content (such as personal photos, documents, etc.) as unsafe to share.<br>
<br>
Also in discussing this, we come up with some potentially useful<br>
extensions to this use case.<br>
<br>
One would be the versioning of the "torrent file", such that the<br>
torrent file could represent versions of the application. i.e. I<br>
release an application that is version 1.02 and it becomes very<br>
popular and there is a sizable swarm. At some point in the future I<br>
release a new version with bug-fixes and additional features (such as<br>
CSS sprites for the social network game). I should be able to<br>
propagate this new version to all clients in the swarm so that over<br>
some time window such as 2 to 4 hours all clients in the swarm<br>
discover (via push or pull) the new version and end up downloading it<br>
from the peers with the new version. The only security feature I could<br>
see that would be required would be that once a client discovers that<br>
their is a new version, it would hit up the original server to<br>
download a signature/fingerprint file to verify that the new version<br>
that it is downloading from its peers is legitimate.<br>
<br>
The interesting thing about this idea is that it would permit large<br>
portions of sites to exist in virtual form. Long-term I can imagine<br>
large non-profit sites such as Wikipedia functioning on top of this<br>
structure in such a way that it greatly reduces the amount of funding<br>
necessary. It would be partially distributed with updates to wikipedia<br>
being distributed via lots of tiny versions from super-nodes à la a<br>
Skype type P2P model.<br>
<br>
This would also take a lot of power out of the hands of those telcos<br>
that are anti-net neutrality. This feature would basically permit a<br>
form of net neutrality by moving content to the fringes of the<br>
network.<br>
<br>
Let me know your thoughts and if you think this would be possible<br>
using Web-sockets and web-workers, and if not, what changes would be<br>
necessary to allow this to evolve.<br>
<br>
Sincerely,<br>
<br>
Andrew J. L. de Andrade<br>
São Paulo, Brazil<br>
<br>
(P.S. I consider myself a pretty technical person, but I don't really<br>
program. I only dabble in programming as a hobby and to better<br>
understand my colleagues. Feel free to be as technical as you want in<br>
your reply, but please forgive me if I make or made any bonehead<br>
mistakes.)<br>
</blockquote></div><br>