En fait il a fait comme les projets en VM de chez LHC (je sais pas si les autres projets à VM le font aussi) : le travail à calculer n'est pas inclus dans la tâche reçue (*) mais c'est le code de l'application boinc du projet qui s'occupe d'en demander au(x) serveur(s) du projet. Et ce n'est pas non plus le "renvoi" de la tâche par boinc une fois le calcul terminé qui permet de renvoyer tes résultats au projet, c'est aussi le code de l'application boinc du projet qui s'en occupe.
L'inconvénient c'est que des fois "les autres serveurs" (ce ne sont a priori pas les mêmes qui envoient le travail effectif que ceux qui envoient les tâches boinc) n'ont plus de travail effectif mais "les serveurs boinc" envoient quand même des tâches alors qu'il n'y a rien à calculer. Cela est arrivé pas mal de fois avec LHC, surtout quand ils mettaient au point leurs applis. (**)
D'un autre côté dans le cas de DHEP la raison de cette technique me parait évidente : Michael a déjà depuis longtemps son propre client de calcul indépendant spécifique à son projet (cf l'autre topic sur DHEP dans la section des projets non boinc du fofo) et que donc je pense que c'était beaucoup plus simple pour lui de coder une appli boinc "qui se greffe le plus directement possible" à son infrastructure client / serveur déjà en place, plutôt que tout recommencer de 0 avec une appli boinc traditionnelle.
(*) comme c'est traditionnellement le cas des applis boinc, c'est à dire qu'une tâche reçue = des paramètres de calcul à mettre en oeuvre par l'application du projet téléchargée dans ton ordinateur quand le projet est initialisé par boinc. Et quand le calcul est fini un (ou plusieurs) fichier de données résultantes est renvoyé au projet.
(**) et en plus chez LHC ce ne sont pas les mêmes équipes qui s'occupent "du travail effectif" (plutôt des scientifiques) que celles qui s'occupent des applis boinc, si j'ai bien compris