I second that: PHP (from the command line) would be a great language to learn. Uses simple text files, no compiling, reasonable error messages, and it is enough like C/C++/JavaScript/Java that a person could transfer most of their experience into any of those languages.
If you wnat confirmation that AGP is asymmetric then read the spec!
Also, as I already stated, the MAX read is ~132 MB per second (33 MHz bus, 32 bits wide). There is no way you could get a transfer rate of 200 MB per second.
I already hinted that the frame buffer format could be a bottle neck. For example, the frame buffer might not be in a 'normal' RGB or RGBA format. I could be in a format like ARBG, BRG, or even somehting exotic like RGBAZZZS (Z-buffer, Stencil buffer). And it is very likely the scan lines are not contiguous, so the padding will need to be skipped.
This has been discussed many times on various news groups. Here is my 'Readers Digest' version:
If you read the AGP spec, which was written by Intel, you will note that it is based on the PCI 2.0 spec. The PCI 2.0 spec is for a 32 bit, 33 MHz symmetric bus which gives you a max transfer of rate of 132 MB per second. The AGP spec is for an asymmetric bus, 33 MHz read and 66+ MHz write. But writes were optimized at the expense of reads, since Intel was pushing video with NO onboard texture memory, and who would want to read back the image in real-time anyway, right?!?
Yes, I am sure that drivers do have some affect, but the AGP spec is the first bottleneck. On an OpenGL news group it was reported last year that a person tested two identical video cards, the only difference being one was AGP and the other was PCI. The read performance for the PCI version was several times faster than the AGP version.
Of course, some video cards are also to blame because of the frame buffer format they use, but that is another story...
I am a fan of distibuted computing, and I see the great potential. However, I also dislike hidden programs, so when I decided to right about my idea I picked a name that would have a negative context. And while I had to acknowledge the similarities between distributed and leech computing, I tried to make the differences clear.
First, Leech Computing is nothing like viruses and other intrusions.
Second, the Condor Project (of which I am aware but did not mention because I thought SETI at Home and distibuted.net were better known examples) is simply another distributed computing project.
Third, I am simply a programmer who thought this idea was interesting enough to spend the time to write an article. I am no longer in school, but my oldest daughter will be attending a university this fall.
Forth, I did mention Parasitic Computing in my article. I read the Parasitic Computing article that was published in Dr. Dobb's Journal.
I thought that would be a good way to get your attention! Even though it is really just a plain button that sends no data, it COULD have been something else.
Just wait for part 2 and you can try out some real leeching pages....
I am afraid I don't know what 'ghost ships and zombie processes' are, and while I am not looking at this from a Windows only perspective, I am looking at a web browser centric view. That is because the web browser is the key software for leeching to work.
Yes, part 2 will actually have pages running example leech programs. I just wanted to 'lightly' smack readers on the side of the head to get their attention:)
JavaScript is about 1/60 the speed of compiled C for floating point intensive calculations. But a leech could also be embeded in a Java applet or ActiveX component for greater speed.
I never said that Java or ActiveX would not work, only that for my simple examples I would use JavaScript. I will get into more details in part 2, but let me say that I think it would be best to add a leech program to an ActiveX component that is needed to access a site. For example, your bank may require you to download an ActiveX component to display interactive tables, or how about for updating your software:)
In part 2, I will have more details for #2 and #3.
I agree that voluntary projects are better at #1 and #4, but under the right conditions, leeching could a a large resource for companies that have a regular captive audience (MSN/Hotmail anyone:)
Remember, my article if for personal enlightenment . I personally think this has some potential, right or wrong, but it is not a universal solution for a companies computing needs.
The client will probably NOT know they are running a leech, and the leech cannot be modified easily since it is imbedded in the web page.
However, just like ANY distributed computing, it is possible to hack the client to send back garbage, so the central server will need to perform sanity checks on the returned data.
And, yes, an antivirus scanner would detect them, but not easily. Since the code is embedded in the web page dynamically, you could change the code signature daily to foil the antivirus scanners.
Yes, the basic definition is broad, but not in the context of my article. And I quickly clarify it within a few paragraphs.
A major difference between spyware and a leech is that the spyware was installed by (but without the knowledge of) the user, but a leech does not install itself to the system. The leech is gone as soon as you exit the browser ar at least change pages.
Stay tuned for part 2. Yes, the JavaScript or Java applet run in browser threads, so they will be at normal priority. But, you can throttle the main loop....
You missed the whole point. A leech as I descibe it would not have any access to the system; It would only be able to process the information sent with it.
Also, as soon as you change web pages, or close the pop-up, the leech is gone.
Slashdot Mirror
I second that: PHP (from the command line) would be a great language to learn. Uses simple text files, no compiling, reasonable error messages, and it is enough like C/C++/JavaScript/Java that a person could transfer most of their experience into any of those languages.
Also, as I already stated, the MAX read is ~132 MB per second (33 MHz bus, 32 bits wide). There is no way you could get a transfer rate of 200 MB per second.
I already hinted that the frame buffer format could be a bottle neck. For example, the frame buffer might not be in a 'normal' RGB or RGBA format. I could be in a format like ARBG, BRG, or even somehting exotic like RGBAZZZS (Z-buffer, Stencil buffer). And it is very likely the scan lines are not contiguous, so the padding will need to be skipped.
If you read the AGP spec, which was written by Intel, you will note that it is based on the PCI 2.0 spec. The PCI 2.0 spec is for a 32 bit, 33 MHz symmetric bus which gives you a max transfer of rate of 132 MB per second. The AGP spec is for an asymmetric bus, 33 MHz read and 66+ MHz write. But writes were optimized at the expense of reads, since Intel was pushing video with NO onboard texture memory, and who would want to read back the image in real-time anyway, right?!?
Yes, I am sure that drivers do have some affect, but the AGP spec is the first bottleneck. On an OpenGL news group it was reported last year that a person tested two identical video cards, the only difference being one was AGP and the other was PCI. The read performance for the PCI version was several times faster than the AGP version.
Of course, some video cards are also to blame because of the frame buffer format they use, but that is another story...
#1 You are right; JavaScript is about 1/60 the speed of compiled C code. But the leech could easily use Java or ActiveX.
.js file so that it would be cached. Then only the data would be sent with the page.
#2 The JavaScript code could be in a separate
#3 A and C affect the server, and the CGI programs would need to be efficiant.
Also, if the leech were throttled to about 75-80% of the cycles the user would not notice unless he was monitoring his CPU cycles.
I agree with you!
I am a fan of distibuted computing, and I see the great potential. However, I also dislike hidden programs, so when I decided to right about my idea I picked a name that would have a negative context. And while I had to acknowledge the similarities between distributed and leech computing, I tried to make the differences clear.
You will still need to create one kick-a** site to get all of us to visit everyday and stay awhile. You know, just like /. ;)
Thank you, I missed that error, and so did the six people I had preview it!
First, Leech Computing is nothing like viruses and other intrusions.
Second, the Condor Project (of which I am aware but did not mention because I thought SETI at Home and distibuted.net were better known examples) is simply another distributed computing project.
Third, I am simply a programmer who thought this idea was interesting enough to spend the time to write an article. I am no longer in school, but my oldest daughter will be attending a university this fall.
Forth, I did mention Parasitic Computing in my article. I read the Parasitic Computing article that was published in Dr. Dobb's Journal.
I thought that would be a good way to get your attention! Even though it is really just a plain button that sends no data, it COULD have been something else.
Just wait for part 2 and you can try out some real leeching pages....
I am afraid I don't know what 'ghost ships and zombie processes' are, and while I am not looking at this from a Windows only perspective, I am looking at a web browser centric view. That is because the web browser is the key software for leeching to work.
Yes, part 2 will actually have pages running example leech programs. I just wanted to 'lightly' smack readers on the side of the head to get their attention :)
Thank you! Someone else that read the article and understands the concept.
JavaScript is about 1/60 the speed of compiled C for floating point intensive calculations. But a leech could also be embeded in a Java applet or ActiveX component for greater speed.
I never said that Java or ActiveX would not work, only that for my simple examples I would use JavaScript. I will get into more details in part 2, but let me say that I think it would be best to add a leech program to an ActiveX component that is needed to access a site. For example, your bank may require you to download an ActiveX component to display interactive tables, or how about for updating your software :)
In part 2, I will have more details for #2 and #3.
:)
I agree that voluntary projects are better at #1 and #4, but under the right conditions, leeching could a a large resource for companies that have a regular captive audience (MSN/Hotmail anyone
Remember, my article if for personal enlightenment . I personally think this has some potential, right or wrong, but it is not a universal solution for a companies computing needs.
You can throttle the main loop of the JavaScript program to prevent it from hogging all the cycles.
Part 2 will have pages that leech off you, but there will be proper warnings.
??
The client will probably NOT know they are running a leech, and the leech cannot be modified easily since it is imbedded in the web page.
However, just like ANY distributed computing, it is possible to hack the client to send back garbage, so the central server will need to perform sanity checks on the returned data.
And, yes, an antivirus scanner would detect them, but not easily. Since the code is embedded in the web page dynamically, you could change the code signature daily to foil the antivirus scanners.
Yes, the basic definition is broad, but not in the context of my article. And I quickly clarify it within a few paragraphs.
A major difference between spyware and a leech is that the spyware was installed by (but without the knowledge of) the user, but a leech does not install itself to the system. The leech is gone as soon as you exit the browser ar at least change pages.
Stay tuned for part 2. Yes, the JavaScript or Java applet run in browser threads, so they will be at normal priority. But, you can throttle the main loop....
You missed the whole point. A leech as I descibe it would not have any access to the system; It would only be able to process the information sent with it.
Also, as soon as you change web pages, or close the pop-up, the leech is gone.
That is exactly the type of project that is possible!
I don't need /. readers to write part 2 for me....I am already working on the CGI program and JavaScript for the demos.
SpyWare needs to be installed, but a leech written in JavaScript runs as long as you are viewing the page.