Pokud vim, CPDN je jediny projekt, ktery behem vypoctu jednotky komunikuje se serverem, tudiz je mozne ji napriklad ukoncit na zaklade nejakych kriterii.
(v BOINC 5.8 se tusim pocita s tim, ze by server mohl dat abort resultum, ktere na masine jeste nejsou rozpocitane a pritom jiz v ramci WU dosahly quora...a tudiz neni treba je dale pocitat a misto toho zaslat nove; je to takove zefektivneni. Kuprikladu neni treba chroupat na SETI sum 4x, kdyz uz se 3 vysledky sejdou - samozrejmne by se mohli naucit setrit traffic pakovanim a tak, ale tohle muze teoreticky progress zrychlit o 1/3 - v realu zalezi na tom, jak casto jsou masiny pripojene, jaky maji turn-around time atp. a myslim ze i 10% stoji za to tim, ze scheduler nebude uplne debilni krmic, jak jsem jiz drive kritizoval.).
Nicmene jakmile jednou BOINC stahne result k pocitani, uz to tak bezi; vsechny vstupni soubory musi byt kompletni, navic napriklad s digitalnim podpisem atp.
(nevim o zadnem projektu, ze by menil parametry vypoctu za chodu podle nalady serveru...to by pak uz byl grid, jenze to BOINC nikdy nebyl...i kdyz s castejsim "dialogem" clienta se serverem se pocita).
Jednotky na CPDN jsou generovany davkove, o souborech parametru se radej vedatori na zaklade dlouhodobeho designu vyzkumu i predchozich vysledku, soutezi o poradi atp.
Carl to na zaklade jejich pozadavku vygeneruje (jestli to po nem bude delat Tolu nebo Milo zatim nevim...nicmene ted predelavali servery (novejsi OS misto stareho RedHatu, upgradovali kde co z hlediska SW, nasli chyby v BOINCu, ktere zpusobili ze 300k jednotek se vyprazdnilo behem par minut atp,). Ale to uz jsou skoro drby jako ze Sylvia je na materske (coz je pravdiva informace) atp. a o to tady asi nikdo nestoji)
