mirror of https://github.com/BOINC/boinc.git
197 lines
5.6 KiB
Plaintext
197 lines
5.6 KiB
Plaintext
HIGH-PRIORITY (must be done to support SETI@home)
|
|
|
|
- Code-signing
|
|
research tools for code-signing
|
|
|
|
- Upload authentication
|
|
Each result contains a "certificate", signed with project key, giving
|
|
- list of: file name, max size
|
|
- min, max times to xfer
|
|
modify put program to decrypt certificate, enforce name/size/time limits
|
|
|
|
- Network retry policies
|
|
can't download file: when to give up? how to retry?
|
|
exponential backoff
|
|
can't upload file: when to give up/retry?
|
|
can't connect to sched server
|
|
error return from sched server
|
|
|
|
- proxy support
|
|
HTTP, Socks
|
|
Look at other open source code
|
|
|
|
- team system
|
|
in PHP
|
|
|
|
- credit display
|
|
in PHP
|
|
|
|
- CPU accounting in the presence of checkpoint/restart
|
|
core client periodically gets CPU time, accumulates in state file
|
|
|
|
- test versioning mechanisms for core
|
|
Idea: need to notify user if core becomes out of date.
|
|
Send messages if either
|
|
1) some WU couldn't be sent because core is too old
|
|
2) no WUs could be sent because core is too old
|
|
|
|
- Think about issues in update core client
|
|
What if state file is incompatible?
|
|
What if app versions are incompatible?
|
|
|
|
- test reporting of app errors
|
|
|
|
- test checksumming of executables
|
|
|
|
- Think about making the set of scheduling servers dynamic
|
|
one approach: allow "redirect" reply from server
|
|
(requires old address to still work)
|
|
second approach: "master URL"
|
|
returns a file with list of scheduler address
|
|
and email address of "problems" contact
|
|
|
|
- complete client side and test hi/lo water mark scheme
|
|
- initialize rsc_fpops and rsc_iops in client WORKUNIT
|
|
- check server sends correct number of work units
|
|
- check client requests correct number of seconds of work
|
|
|
|
- measure hardware parameters: CPU speed, #CPUs, memory, disk
|
|
- define CPU benchmarks
|
|
- do this for other platforms
|
|
- Get info periodically rather than always at startup
|
|
|
|
- core client / app trigger file interface
|
|
core->app
|
|
init:
|
|
app preferences
|
|
name of graphics shared-mem seg
|
|
recommended graphics size
|
|
recommended frame rate
|
|
recommended checkpoint period
|
|
dynamic:
|
|
whether to do graphics
|
|
exit
|
|
app->core
|
|
init:
|
|
actual graphics size
|
|
dynamic:
|
|
% done
|
|
I just checkpointed
|
|
|
|
- implement graphics system
|
|
Basic idea: core client passes shared-memory segment name to app,
|
|
recommended size and frame rate.
|
|
App creates pixmap + dirty flag in shared mem,
|
|
renders to it, sets dirty flag.
|
|
Core client (or screensaver) maps shared mem.
|
|
When dirty, blit pixmap to screen
|
|
- X11 version
|
|
It's not clear whether X11 allows you to draw into memory.
|
|
Does everything have to go through server?
|
|
- Win32-based version
|
|
- The API by which the app draws into shared-mem pixmap should
|
|
be platform-independent.
|
|
In the first pass we can use our own library based on Win32 primitives.
|
|
In principle we should be able to use any library
|
|
capable of offscreen drawing.
|
|
OpenGL version?
|
|
|
|
- GUI and screensaver around core client
|
|
design default (core client) display
|
|
screensaver options
|
|
move around screen?
|
|
system tray icon behavior
|
|
|
|
|
|
- get idle-only behavior without screensaver
|
|
Windows
|
|
UNIX
|
|
|
|
- sched server should return total credit info (user, team?)
|
|
could display in default core client display
|
|
|
|
- edit user account
|
|
--------------------------
|
|
MEDIUM-PRIORITY (must be done for CM)
|
|
|
|
- review and complete documentation
|
|
|
|
- test sticky files
|
|
|
|
- test multiple-file applications
|
|
change add.C to support multi-file applications
|
|
|
|
- implement WU/result sequences
|
|
|
|
--------------------------
|
|
LOW-PRIORITY
|
|
|
|
- implement checkpoint/restart for file transfers
|
|
use features of HTTP 1.1
|
|
Return an error to server if transfer fails
|
|
(store in DB in server)
|
|
|
|
- implement and test the batch mechanism
|
|
|
|
- test environment-var mechanism
|
|
|
|
- test alpha/beta/prod for apps
|
|
|
|
- test on a multiprocessor
|
|
|
|
- define logging system on client
|
|
|
|
- server-side estimates of WU time requirements
|
|
- DB entry for WU has int/FP/RAM/disk/net
|
|
|
|
- server sends only feasible WUs
|
|
- limit by RAM, disk
|
|
- test
|
|
|
|
- implement file upload/download requests
|
|
This can be done in the current WU/result paradigm;
|
|
WU has a special "null" application
|
|
use sticky input files to download;
|
|
use upload-when-done output files to upload
|
|
|
|
- preferences
|
|
finish PHP web interface
|
|
specific preferences:
|
|
disk usage
|
|
% of free space?
|
|
all except X GB?
|
|
X GB?
|
|
minimum checkpoint interval
|
|
max bytes upload/download per day
|
|
implement in client
|
|
hours/days to communicate/compute
|
|
implement in client
|
|
control over priorities?
|
|
|
|
- define a notion of "app preferences": arbitrary XML edited on server,
|
|
passed to app client.
|
|
This could be used to e.g. select a color scheme for graphics
|
|
Could pass entire prefs?
|
|
|
|
- NET_XFER_SET:: do_select: prevent one stream from starving others
|
|
|
|
- add the ability to store input data directly in WU,
|
|
and output directly in result (blob).
|
|
For projects with small data.
|
|
|
|
--------------------------
|
|
DONE (may need test)
|
|
|
|
- mechanism for returning app stderr output to server? store in blob?
|
|
|
|
- add size to FILE_INFO
|
|
server, client sides
|
|
|
|
- measure bandwidth on each network xfer
|
|
maintain exponential average, weighted by #bytes xferred
|
|
|
|
- make scheduling server work with fast cgi
|
|
|
|
- high and low water marks implemented
|
|
|