IronBits
05-08-2003, 09:04 AM
This is an excellent post by Larry Loen, over on Ars, and I quote
"
We do have some ideas on what a good client should look like.
Our requirements tend to look about like this (the more you meet, the more we're likely to participate):
1. Solid reliability. Must have 99 per cent uptime or greater on the client side. Should be robust enough that restarting the client has some odds of getting past the problem (we know there's no guarantee of that, but many projects have met such a criteria).
2. Solid network performance. Science-type projects are prone to bandwidth limitations. At some point, we know, projects run out of the ability to pay for more bandwidth. This has not so far inhibited any save the most popular projects, but it is worth highlighting, because communications saturation has some very bad effects (ie, you wait hours instead of minutes for the next work unit). Close on to that is reasonably robust retry logic that persists if this situation occurs. We also require very high uptime on whatever server(s) distribute work since a crash is similar or worse than running out of bandwidth. Compressing the data you upload or download may be a good idea, if you can manage it.
3. Some sort of queueing strategy. In the end, if saturation happens, downloading multiple work units to the client won't help. But, if you aren't at saturation, this is a very useful and essential feature, especially for those with dialup access. We're looking for the ability to connect to the server between daily and weekly (more rarely, monthly unless the logic of the project is against such a delay). The delay should be more-or-less at our choosing, though you can put in sensible limits relative to the logic of your project.
3.5 Hack proof server. You should not accept bogus results from patched clients. You especially should not accept a simple replaying of old results in hopes of getting credit again and again for the same answer. Both of these have happened to other projects and hurt them in the "marketplace" for free CPU cycles. You need not (and, nowadays, cannot) defeat all attacks, but the better your effort, the better off you'll be.
4. Linux capability. If you can only have one Linux binary, let it be statically linked to avoid version issues.
5. A "command line" or other mechanism to deal with and dispense with GUI requirements. The most unique form of this was the SETI Linux client that had the crunch part with little or no output to "standard output" and a separate program that you could optionally launch to create pretty pictures. Veterans like us would just as soon crunch on without the pretty pictures. We appreciate how the screen savers are important for the casual participant. On a machine count, however, we usually provide half the total horsepower and we like it minimal. Some of us have very minimal machines we put these things on. If you have a GUI form that visibly speeds up when minimized (or runs in the "tray") this is worth highlighting.
6. Some ability to use one machine to do upload or download and another to do the crunching. We call this "sneakernetting" and it enables us to use machines unconnected to the 'net or deep behind corporate firewalls (when we get permission for such operations).
7. Thorough proxy support (socks and simple). This is again for getting past firewalls.
8. Options for doing pieces of work. We've already talked about upload and download (should do either with a switch and then quit). Should also be a "doomsday" option to delete troublesome work units that aren't advancing. Configuration should be possible as well without running anything.
9. Built-in benchmarking of some sort so that we know our hardware is running OK. You would run a brief, relevant benchmark and exit.
10. Some ability to adjust priority from "worst" to "second worst" (allows running with more than one project, something we sometimes do, especially on dialup). This can also help with certain Windows issues (e.g. Outlook).
11. Runnable as a Windows Service on the NT family. Running out of the tray on Win9x.
12. Ability to run more than one instance of the client per CPU. This is related to queuing and it is sometimes helpful. Ability to exploit SMP. This can be as simple as running a second copy of the client in another directory (and, in fact, is all most projects do). But, avoid reliance on the Windows repository.
13. A nice feature only one client has is the ability to run for a specified per centage of the CPU. This is not a requirement, but with #10, it has some nice uses.
14. If possible, have your client appear ready for continuous performance improvement. Be wary of the bandwidth dilemma (some projects cannot usefully speed up their clients because of this), but generally, some users like to think the project is implemented as optimally as possible. It isn't enough for this group not to waste cycles -- they want maximum production as well. An assembler core for key parts has a certain "marketing" appeal to this group and helps in that the Linux and Windows performance is more equal.
15. Mac support. OS X is probably sufficient nowadays. We do have people on this team that own Macs and so do other DC teams.
Again, except for the first handful, none of these are absolute requirements, but the more of these you can follow, the bigger an audience you can probably draw.
"
"
We do have some ideas on what a good client should look like.
Our requirements tend to look about like this (the more you meet, the more we're likely to participate):
1. Solid reliability. Must have 99 per cent uptime or greater on the client side. Should be robust enough that restarting the client has some odds of getting past the problem (we know there's no guarantee of that, but many projects have met such a criteria).
2. Solid network performance. Science-type projects are prone to bandwidth limitations. At some point, we know, projects run out of the ability to pay for more bandwidth. This has not so far inhibited any save the most popular projects, but it is worth highlighting, because communications saturation has some very bad effects (ie, you wait hours instead of minutes for the next work unit). Close on to that is reasonably robust retry logic that persists if this situation occurs. We also require very high uptime on whatever server(s) distribute work since a crash is similar or worse than running out of bandwidth. Compressing the data you upload or download may be a good idea, if you can manage it.
3. Some sort of queueing strategy. In the end, if saturation happens, downloading multiple work units to the client won't help. But, if you aren't at saturation, this is a very useful and essential feature, especially for those with dialup access. We're looking for the ability to connect to the server between daily and weekly (more rarely, monthly unless the logic of the project is against such a delay). The delay should be more-or-less at our choosing, though you can put in sensible limits relative to the logic of your project.
3.5 Hack proof server. You should not accept bogus results from patched clients. You especially should not accept a simple replaying of old results in hopes of getting credit again and again for the same answer. Both of these have happened to other projects and hurt them in the "marketplace" for free CPU cycles. You need not (and, nowadays, cannot) defeat all attacks, but the better your effort, the better off you'll be.
4. Linux capability. If you can only have one Linux binary, let it be statically linked to avoid version issues.
5. A "command line" or other mechanism to deal with and dispense with GUI requirements. The most unique form of this was the SETI Linux client that had the crunch part with little or no output to "standard output" and a separate program that you could optionally launch to create pretty pictures. Veterans like us would just as soon crunch on without the pretty pictures. We appreciate how the screen savers are important for the casual participant. On a machine count, however, we usually provide half the total horsepower and we like it minimal. Some of us have very minimal machines we put these things on. If you have a GUI form that visibly speeds up when minimized (or runs in the "tray") this is worth highlighting.
6. Some ability to use one machine to do upload or download and another to do the crunching. We call this "sneakernetting" and it enables us to use machines unconnected to the 'net or deep behind corporate firewalls (when we get permission for such operations).
7. Thorough proxy support (socks and simple). This is again for getting past firewalls.
8. Options for doing pieces of work. We've already talked about upload and download (should do either with a switch and then quit). Should also be a "doomsday" option to delete troublesome work units that aren't advancing. Configuration should be possible as well without running anything.
9. Built-in benchmarking of some sort so that we know our hardware is running OK. You would run a brief, relevant benchmark and exit.
10. Some ability to adjust priority from "worst" to "second worst" (allows running with more than one project, something we sometimes do, especially on dialup). This can also help with certain Windows issues (e.g. Outlook).
11. Runnable as a Windows Service on the NT family. Running out of the tray on Win9x.
12. Ability to run more than one instance of the client per CPU. This is related to queuing and it is sometimes helpful. Ability to exploit SMP. This can be as simple as running a second copy of the client in another directory (and, in fact, is all most projects do). But, avoid reliance on the Windows repository.
13. A nice feature only one client has is the ability to run for a specified per centage of the CPU. This is not a requirement, but with #10, it has some nice uses.
14. If possible, have your client appear ready for continuous performance improvement. Be wary of the bandwidth dilemma (some projects cannot usefully speed up their clients because of this), but generally, some users like to think the project is implemented as optimally as possible. It isn't enough for this group not to waste cycles -- they want maximum production as well. An assembler core for key parts has a certain "marketing" appeal to this group and helps in that the Linux and Windows performance is more equal.
15. Mac support. OS X is probably sufficient nowadays. We do have people on this team that own Macs and so do other DC teams.
Again, except for the first handful, none of these are absolute requirements, but the more of these you can follow, the bigger an audience you can probably draw.
"