support for HTTP and SOCKS proxies make get_local_ip_addr() work in all cases est_time_to_completion doesn't work for non-running tasks get timezone working on all platforms get benchmark working as separate process must do this before send first scheduler request validate in crontab Windows client make mini-logo test uninstall xfers: show file size, ----------------------- test feeder reread-DB mechanism use PHP session mechanism instead of our own cookies use https for login (don't sent account ID or password in clear) protect project admin web pages (htaccess) Deadline mechanism for results - use in result dispatching - use in file uploading (decide what to upload next) - use in deciding when to make scheduler RPC (done already?) create "result adder" program that detects WUs that don't have a canonical result yet, and should, and creates more results for them. This should detect situations where we're getting lots of error results, and skip over those WUs CPU benchmarking This should be done by a pseudo-application rather than by the core client. This would eliminate the GUI-starvation problem, and would make it possible to have architecture-specific benchmarking programs (e.g. for graphics coprocessor) or project-specific programs. Testing framework better mechanisms to model server/client/communication failure better mechanisms to simulate large load do client/server on separate hosts? Add "garbage-collect state" fields to WU, result whether deletion of files is OK, is done investigate binary diff mechanism for updating persistent files verify support for > 4 GB files everywhere use FTP instead of HTTP for file xfer?? measure speed diff Delete files if needed to honor disk usage constraint inform user if this happens implement max bytes/sec network preferences Local scheduling more intelligent decision about when/what to work on - monitor VM situation, run small-footprint programs even if user active - monitor network usage, do net xfers if network idle even if user active The following would require client to accept connections: - clients can act as proxy scheduling server - exiting client can pass work to another client - client can transfer files to other clients User/host "reputation" keep track of % results bad, %results claimed > 2x granted credit both per-host and per-user. Make these visible to project, to that user (only) Storage validation periodic rehash of persistent files; compare results between hosts Include account ID in URL for file xfers This would let you verify network xfers by scanning web logs (could use that to give credit for xfers) Global preferences implement disk usage prefs time-of-day prefs? test propagation mechanism set up multi-project, multi-host test; change global prefs at one web site, make sure they propagate to all hosts limit on frequency of disk writes? max net traffic per day? implement in client Per-project preferences test project-specific prefs make example web edit pages make app that uses them set up a test with multiple projects test "add project" feature, GUI and cmdline test resource share mechanism Proxies work through HTTP, Socks proxies look at other open-source code (Mozilla?) Documentation simplify/finish docs on server installation get rid of text in INSTALL and INSTALL_CLIENT; they should just refer to .html files Testing in general figure out how to set up multi-project, multi-host tests from a single script automate some simple test cases Messages from core client decide what messages should be shown to user, and how log file? GUI? dialog? CPU benchmarking review CPU benchmarks - do they do what we want? what to do when tests show hardware problem? How should we weight factors for credit? run CPU tests unobtrusively, periodically check that on/conn/active fracs are maintainted correctly check that bandwidth is measured correctly measure disk/mem size on all platforms get timezone to work WU/result sequence mechanism design/implement/document Multiple application files document, test CPU accounting in the presence of checkpoint/restart test Test nslots > 1 Redundancy checking and validation test the validation mechanism make sure credit is granted correctly make sure average, total credit maintained correctly for user, host Scheduler RPC formalize notion of "permanent failure" (e.g. can't download file) report perm failures to scheduler, record in DB make sure RPC backoff is done for any perm failure (in general, should never make back-to-back RPCs to a project) make sure that client eventually reloads master URL Data transfer make sure restart of downloads works make sure restart of uploads works test download/upload with multiple data servers make sure it tries servers in succession, does exponential backoff if all fail review and document prioritization of transfers review protocol; make sure error returns are possible and handled correctly Application graphics finish design, implementation, doc, testing size, frame rate, whether to generate Work generation generation of upload signature is very slow Windows GUI finish design/implement display credit info, team Windows screensaver functionality idle-only behavior without screensaver - test Versioning think through issues involved in: compatibility of core client and scheduling server compatibility of core client and data server compatibility of core client and app version compatibility of core client and client state file? Need version numbers for protocols/interfaces? What messages to show user? Project? Scheduler Should dispatch results based on deadline? test that scheduler estimates WU completion time correctly test that scheduler sends right amount of work test that client estimates remaining work correctly, requests correct # of seconds test that hi/low water mark system works test that scheduler sends only feasible WUs Persistent files test design/implement test reporting, retrieval mechanisms (do this using WU/results with null application?) User HTML leader boards NET_XFER_SET review logic; prevent one stream for starving others test HTTP redirect mechanism for all types of ops prevent file_xfer->req1 from overflowing. This problems seems to be happening when the file_upload_handler returnes a message to the client that is large. This causes project->parsefile to get wrong input and so on.