The Theory of Leech Computing

Phil Frisbie, Jr. writes "I am defining Leech Computing as 'a program running on a client computer without user knowledge that can process data and report back the results, but otherwise does not effect the usability of the client computer and makes no changes to the client'. Leech Computing, Part 1 covers basic theory."

Comments

Interesting concept

[GreyPoopon]

Conceptually, I find this interesting. It can run without user notice. The only problem is that it does steal CPU cycles, and as far as I know there is no real way in Javascript (or Java applets) to make the program run only when it isn't competing with other applications. I can imagine that some users might get really upset because you are stealing their computer resources. Because of this, I wouldn't recommend doing this kind of thing without notifying the user and perhaps giving them the option to turn it off. However, I can see some potential uses for this as long as the user is aware. For example, slashdot viewers probably wouldn't mind some leech Javascript working on the latest encryption cracking contest, especially if they got to "share the wealth."

If used properly, this could replace banner ads.

[Bonker]

Say you're running a 1.5 ghz machine and browsing the web. Chances are, even if you're playing MP3's in the background, you're using less than 5% of your processor cycles. If you could trade another 50% of those cycles you're not otherwise using for the ability to kill ads or for access to a restricted site, Would you?

(I can see it now. 50 to 100 years from now, the Porn Website Coalition has won a Nobel prize for creating a vast distributed network for math intensive problems....)

The problem with this model is that the implimentation of Javascript is slow and horrendously messy. It's brutally inefficient for anything other than the most minor effects carried out in a browser window. I shudder to think of what most browsers would do, given a math-intensive task. FFT's in Javascript anyone?

Unlike the author, I think that Java and/or ActiveX applets will probably see this sort of exploitation first, since they're easier to tune speed out of.

background tasks are not transparent

[RussRoss]

At least on Linux systems, the scheduler behavior is definately affected by even a single low priority (nice value 19) task. I run distributed.net clients full time on my system and generally it's not a problem, but sometimes when running another CPU bound interactive job (playing back movies or MP3s, playing games on an emulator, games in general) the effects are noticeable.

When I was an undergrad I did a semester research project on this and identified some of the problems:

http://www.russross.com/cs261/paper.html

I run a dual CPU machine now which generally masks the problem, but even the fastest single CPU systems will suffer noticeable effects once the scheduler falls back to a round robin scheme with weighted timeslice lengths which is essentially what happens once you have two or more CPU bound jobs competing for CPU time.

- Russ

Slight Surprise

[rgmoore]

The one thing that surprised me a bit was that the author didn't take advantage of the opportunity to put a bit of leech computing onto his own web page. He mentions (on the second page) that:

Of course, you would not label such a button 'Click here to submit hidden data', but what if it were labeled 'Next Page'? How many times have you pressed a button like that without even thinking about it? When the user presses the button, the leech submits the hidden data and redirects to the next page. As long as the user gets to the next page, they will not have any reason to think that the button had any other function.

Then I remembered that there was, in fact, just such a button on the first page. But when I went back to check, there wasn't actually a Javascript applet there trying to leech a little bit of computing power from me. There wasn't even a cute little message thanking me for checking to see if there was such a Javascript applet. Too bad, he missed a great chance.