Review my startup - Plura Processing: Web Traffic = Grid Computer

Interesting comments. First, let me explain that the client side runs entirely within memory; the hard drive is not touched at all. All processing or computation is done within the Java sandbox. In other words, you are not giving us unfettered access. In fact, it's quite the opposite. :) We follow everything listed at http://java.sun.com/sfaq/, whether we're running an applet from the browser or from within a desktop application.

Second, although we encourage disclosure, we leave the disclosure up to the individual sites and some have chosen to use some form of opt-out or opt-in. That being said, we also provide a TOS that they can use for disclosure if they choose. If the disclosure is done in a positive way, the users should see the benefits of getting more game features for free.

Thanks. We are really focused on this as well. :)

Here's a blog post we wrote comparing us to Amazon's EC2 for HPC apps: http://pluraprocessing.wordpress.com/2008/10/23/comparing-pl.... Our numbers should be very compelling for certain types of applications compared to the cost of building your own clusters or using an EC2-type service.

There are definitely certain applications where this form of grid or cloud computing (I hate to use such a popular buzzword) will enable apps that weren't possible before. Previous attempts at grid computing for HPC depended more on philanthropy instead of having a scalable business model that allowed the addition of 100s and 1000s of nodes at a time.

One of the issues that I see with this approach is that for most applications the scaling issue is data scaling rather than CPU. Here's why I think you will run into scaling issues:

Lets assume you have a gigabit line out of your colo. Lets also assume that your average game client is on a cable modem with a 1megabit connection. That gives you capabilities to stream work units to 1024 clients simultaneously as an upper limit. In keeping with an average 1 megabit client, it will take 3 minutes to stream down a 20 megabyte work unit, maxing their connection. 1024 concurrent clients * 20 megabytes = 20 gigabytes. So you're looking at 3 minutes of overhead transfer out, and likely another 3 minutes or so of overhead transfer of results back from the client. So that's approximately 6 minutes per gigabyte just in transmission overhead. And it gets worse as clients are added to the system, since you would need scale out your datacenter just to handle coordinating all of the clients. Which begs the question: why aren't all those servers just doing the dang work already?

That kind of overhead limits this technique's usefulness only to applications which have relatively high computational complexity and relatively small amounts of data. And those applications do exist, however they're pretty far from the day to day needs of most companies. Sun found this out the hard way with their Sun Grid project, which last time I checked was a failure. Sorry, I really wish you the best of luck.

I can see your point, but wouldn't be any ad-driven website/game be considered theft of service?

A ton of flash ads might have a bigger impact on your system performance (and on your wallet, if your ISP charges by traffic)

I applaud your effort. Great idea! Personally, I can see this widely used, on both the user and customer side. Man, why didn't I think of that! hahahha.