In my
introduction to AJAX Stream Processing I introduced the idea of using web browsers as stream processing machines. The idea being that stream computing kernels and data packets were downloaded to browsers using AJAX technology and calculated on the client.
So how does it actually work?
Let's take the problem of testing the primality of a number,
n. A naive implementation is to check if
n is divisible by any of the primes up to
n / 2.
So a datastream is created containing
n along with all of the primes up to
n / 2 and this is sent via AJAX calls to the client. Next a kernel program is downloaded to the client and executed via Javascript's
window.eval() function.
A kernel to test the primality of
n would look something like this:
isPrime = true;
for (var i = 0; i < primeArray.length; i++)
{
if (n % primeArray[i] == 0)
{
isPrime = false;
break;
}
}
{n, isPrime} is then returned to the server - another AJAX transaction - and saved into a database. Finally, the Javascript application asks for a new number to test and the cycle continues.
Calculating prime numbers through AJAX stream processing shows this theory in practice.
There are some issues with security (along with the normal AJAX problems):
- What if the user decides that they are going to change the data returned using some kind of Javascript debugger?
- How do you guarantee server-side that you are getting a valid processed result?
- How do you get around the
XMLHttpRequest security, stopping it from contacting one site from another (as would be needed with a host site showing the "calculation banner")?
Right now, I don't have a concrete answer for the first two questions, although I think some kind of random key that is passed to the client and then back again could solve the issue.
The third problem is commonly solved through the use of a proxy.
Next time, I'll discuss the morality issues of (sneakily) using a client's computer to do complex calculations for your means.
Posts
