https://arxiv.org/abs/1903.01699
记录一下对文中一些特殊词语的翻译，这些词在译文中第一次出现时均以 中文翻译（原文） 格式进行表示 首先是在正文中以粗体表示的概念性词语： - 志愿计算（volunteer computing）
- 项目（project）
- 志愿者（volunteer）
- 资源分享率（resource share）
- 账户管理器（account managers ,AMs）
- 协作志愿计算模式（coordinated VC model）
- 计算参数设置（computing preferences）
- CPU节流（CPU throttling）
- 关键词配置（keyword preferences）
- 计算程序版本（app versions）
- 计算程序（app）
- 平台（platforms）
- 方案类型（plan class）
- 峰值计算能力（peak FLOPS）
- 匿名平台（anonymous platform）
- 任务（job）
- 例证（instances）
- 捆绑器（submitter）
- 验证器（validator）
- 重复验证（replication-based validation）
- 等价平台冗余（homogeneous redundancy）
- 同版本计算程序（homogeneous app version）
- 自适应重复验证（adaptive replication）
- 限定任务处理（Specialized job processing）
- 汇聚信息（trickle-up messages）
- 本地调度（locality scheduling）
- 粘性（sticky）
- 指定的（targeted）
- 非CPU密集（non-CPU-intensive）
- 项目目录（project directory）
- 任务目录（job directories）
- 原生计算程序（native application）
- 包装器（wrapper program）
- 计时器线程（timer thread）
- masked sections
- 临时退出（temporary exit）
- BOINC 包装器（BOINC wrapper）
- VBox包装器（VBox wrapper）
- 通用计算程序（universal app）
然后是一些专有名词和一些我查到的术语
- 美国国家科学院院刊（PNAS）
- 物理评论（Physical Review）
- 蛋白质（Proteins）
- 亚马逊弹性云计算（Amazon EC2）
- 高吞吐量计算（high-throughput computing ,HTC）
- 远程过程调用（RPC）
- 拒绝服务攻击（DoS attack）
- 高级SIMD延伸指令集（NEON）
- 向量浮点运算单元（VFP floating-point units）
- 数学函数库（math libraries）
- 数学稳定（numerically stable）
- 标准错误输出（standard error output）
- 符号连接（symbolic links）
- 行程群组（或称过程群组，process-group）
- 序列程序（sequential programs）
- 线程函数库（thread library）
BOINC:一种志愿计算的平台 DavidP. Anderson Universityof California, Berkeley SpaceSciences Laboratory Berkeley,CA 94720
2018年12月9日
摘要： “志愿计算”是一种利用消费级数码设备协助高吞吐量科学计算的方式，这种方式可以提供大量低成本的计算能力。而同时也面临着设备间差异性、不可靠性以及频繁更新换代带来的严峻挑战。BOINC是一个广泛用于志愿计算的开源中间件系统，该系统能够较好地处理这些挑战。我们在本文中描述了这个系统的功能特性、架构以及实现。
关键词 BOINC，志愿计算，分布式计算，科学计算，高吞吐量计算
1.引言 1.1 志愿计算 志愿计算（Volunteercomputing）是一种利用消费级数码设备协助高吞吐量科学计算的方式，可利用的设备包括台式个人电脑、笔记本电脑、平板电脑和智能手机等。设备持有者可通过安装来自科研项目的计算程序来参与到志愿计算之中。目前在各领域、各机构中处于运作状态的志愿计算项目总共约共有30个。收到志愿计算协助的许多科学研究项目都产生了丰硕的成果：《自然》、《科学》、《美国国家科学院院刊（PNAS）》、《物理评论（Physical Review）》、《蛋白质（Proteins）》、《PloS Biology》、Bioinformatics, J. of Mol. Biol., J.Chem. Phys, [1]等顶尖期刊中都有他们的身影。
现在，大约有700,000台设备正活跃在志愿计算的各个项目中。这些设备全部加起来有大约4,000,000颗CPU核心以及560,000颗GPU核心，总共拥有约93 PetaFLOPS的计算能力。这些设备中，主要是现代的高端计算机：他们平均有着16.5 GigaFLOPS（CPU计算能力）以及11.4GB的内存，其中大部分还带有支持OpenCL 与 CUDA通用计算的显卡。
就算已经具有如此强大的性能，志愿计算仍具有更大的潜力：全世界目前有约2亿台消费级个人电脑[2]。目前的计算机性能大约都在3 TeraFLOPS（含GPU）左右，以这个值估算，2亿台电脑总共能够输出超过6,000 ExaFLOPS（译：10的18次方）的峰值计算能力。而对于移动设备来说，他们的性能总和也正接近这个水平：目前世界上有大约10亿部移动设备，以目前的移动硬件水平看，每台移动设备算上片上集成的GPU总共能达到4 TeraFLOPS [3]的性能。研究显示，在了解志愿计算的人群中，有5%-10%人会参与其中，而这些人中能用台式机和移动设备进行计算的时间分别为60%和40%。[4] [5]考虑到这些因素，我们可以估算出，目前来说，志愿计算的潜在计算能力是在百ExaFLOPS（译：也就是10的20次方）数量级的。
=======0314更新=======
志愿计算活动的开销由志愿者与科学家共同承担。志愿者花钱购买可用于计算的设备并提供电能与互联网连接。科学家的开销则来自购买用于管理项目的服务器、雇佣程序及网页开发者。一个典型的志愿计算项目，包含若干台Linux服务器以及一名兼职的系统管理员，其运营成本大约在100,000美元每年。许多运行于BOINC平台上的项目（Einstein@Home, Rosetta@home, SETI@home）都属于这种规模，这几个项目平均每个项目都获得了约为1 PetaFLOPS的计算能力。
那么，要想在亚马逊弹性云计算（AmazonEC2）平台上获取这个数量级的计算能力，需要多少成本呢？根据Ostermann的研究[6]来看，最高性价比的节点模式是这样的：0.24美元/小时，提供50 GigaFLOPS的计算能力。要达到1 PetaFLOPS则需要20,000个这样的节点，也就是说每年要花4,200,000美元——是志愿计算所需开销的420倍。Kondo在一篇文章中更详细地对比了志愿计算的与云计算的开销，并得到了类似的结论。[7]
从能源耗费上来看，数据中心节点确实比消费级的设备更高效（比如有着更高的FLOPS/瓦值）。但要是想比较能量的总消耗量，则还需考虑两点因素。一是散热设备消耗。数据中心使用空调来对硬件进行降温，而消费级设备一般没有这种设计。二是硬件热量的副作用。当周围温度较低时，消费级设备所产生的热量可以帮助升高周围的温度，所以这时我们可以将计算所需的总能量看做零。因此，我们并不能确定究竟志愿计算和数据中心计算两者到底哪方有着更高的能量效率。但不管怎么说，这并不影响志愿计算帮助科学家省去一大笔开销，因为进行计算所需的电费是由志愿者买单的。
志愿计算最适合的工作是高吞吐量计算（high-throughput computing ,HTC）：需要计算的数据包含大量的可分组的、流式的计算数据，且这些数据在被分成小组或小段后，能够在较短时间内完成计算。（译：也就是可以拆分成若干很小的部分，同时处理后再将结果合并在一起）。对内存或存储空间要求过高的工作、以及对网络连接过于依赖的工作则不适宜使用志愿计算来解决。
志愿计算在以下几个方面不同于网格和云等高吞吐量计算的其他形式：
·（参与计算的）计算机是匿名且不被信任的； ·（参与计算的）计算机在软硬件等各方面都不尽相同。比如，在所有参与计算的个人电脑中，85%使用的是Windows系统，7%使用Mac系统，还有7%用的是Linux系统； ·任务所需时间并不确定，因为参与计算的计算机并不会全时运行计算； ·设备有着显著的更迭，比如新计算机的加入和老计算机的退出； ·形成（计算能力的）资源池需要进行志愿者的招募与保留，且客户端软件须简单易用； ·志愿计算的规模更大：高至百万数量级的计算机参与计算，百万数量级的日任务量。
对一个志愿计算平台来说，以上每一点都是必须直面的挑战。
=======0315更新=======
1.2 BOINC
BOINC是一种针对志愿计算开发的开源的中间件系统[8]，它能够比较好地克服上文中提到的几个难题。且能让科学家能够比较方便的建立并运营起志愿计算项目，并招募志愿者协助进行计算。大部分志愿计算项目都是运行在此平台上的。
志愿者参与项目的方式很简单：只需安装BOINC客户端，并在其中选择想要参加的一个或多个项目即可。BOINC客户端在各种桌面操作系统上都有对应的版本（Windows，Mac，Linux），对于移动设备则有安卓版本的客户端（译：是的，很遗憾并不支持苹果设备）。BOINC中的计算过程对于志愿者来说是隐形的，它只会在后台以最低优先级运行，并且会限制计算程序使用的内存量以避免过度占用内存。在移动设备上，它仅会在设备进行充电且已充满时进行计算，项目所需的互联网通信则只会在WiFi环境下进行。
原则上，BOINC能够管理所有高吞吐量计算程序。许多BOINC平台上的项目运行的是典型的科学计算程序，比如Autodock, Gromacs, Rosetta, LAMMPS, 和BLAST 等项目。BOINC同样也支持使用GPU的计算程序（使用CUDA和OpenCL）、使用多CPU的计算程序（OpenMP或者OpenCL）和运行在虚拟机或容器中的计算程序。
BOINC平台的开发工作始于2002年，由作者领导的来自加利福尼亚大学伯克利分校的开发团队完成。平台的开发工作受到了美国国家科学基金的赞助。首个基于BOINC平台的项目开始于2004年。BOINC遵循LGPL v3 许可证，但是并不强制开源。
2.BOINC的高层架构
BOINC的架构包括多个使用基于HTTP的远程过程调用（RPC）接口互联的部分。这样设计是为了保证模块化与可扩展性。
图一
图一：BOINC系统的各部分与RPC接口
2.1项目与志愿者
在BOINC系统用于中，“项目（project）”指的是使用BOINC进行计算的实体。每个项目都有一个基于BOINC服务器软件的服务器，这个服务器负责向志愿者的设备发放任务。项目之间相互独立，没有依赖关系。一个项目可仅隶属于单个研究组织（比如SETI@home），可同时隶属于使用多个组织（比如Climateprediction.net, nanoHUB@home），也可隶属于几个独立的科学家（比如IBM World Community Grid, BOINC@TACC）。
项目一般会有一个面向公众的网站。BOINC服务器软件提供了数据库驱动的网站脚本，供志愿者建立自己的个人页面、进行讨论交流、开发者发布信息、显示成就（徽章）以及其他社区功能和鼓励机制。项目运营者可使用自己的内容对网站进行扩充，比如加入项目介绍和关于研究的新闻等。每个项目都以自己网站的网址为标识。
“志愿者（volunteer）”指的是愿意使用自己的设备参与计算的人。他们通过以下方式参与：a）在设备上安装BOINC客户端；b）选择想要支持的项目，并在项目中建立自己的账号；c）在BOINC客户端上分别绑定自己在各项目上的账号。每次绑定时都可设定一次“资源分享率（resource share）”，这个设置决定了BOINC将要分配给这台机器多少时间为此项目进行计算。
2.2客户端与服务器的通信
添加一个项目之后，BOINC客户端将定期通过RPC与项目服务器进行联系，报告完成的任务并获取新任务。随后客户端会下载计算程序，导入数据文件，运行任务并上报计算结果文件。所有的通信都是通过客户端发起的HTTP连接进行，也就是说BOINC客户端使用HTTP代理并工作于允许上行HTTP连接的防火墙之后。服务器必须能够通过HTTP进行访问。
下载的文件在传输过程中可被压缩，尔后由客户端对其进行解压。文件并不需要存放于项目服务器中。文件的有效性由哈希值和代码签名（对于计算程序使用这个方法）进行验证，这方面的信息会在本文的3.10部分进行详细描述。
文件上传由HTTP POST操作进行，上传请求由服务器上的CGI程序进行处理。上传的文件名包含一段随机字符，目的是防止伪造文件。为了防止拒绝服务攻击（DoS attack），项目可以选择使用加密令牌来限制上传文件的尺寸。文件上传目标不必是像保姆服务器，举例来说，Climateprediction.net项目与许多国家的科学家共同合作，这个项目的计算结果文件会直接送至合作者共用的服务器中。
客户端偶尔也会与BOINC自己的服务器进行通信，用来更新项目列表以及检查客户端版本。
所有的客户端和服务端的通信失败时，重试的时间间隔以指数形式递增。这样做的目的是限制重新发起请求的次数，防止当服务器从离线状态恢复时承受过大的压力。
2.3 账户管理器
上文所描述的寻找与添加项目的步骤在下列情况中会显得比较繁琐：a)志愿者打算在多台计算机上添加或删除项目；b）志愿者想要一次性添加多个项目。
为了解决这个问题，BOINC提供了一个基于网页的框架，称为账户管理器（account managers ,AMs）。BOINC客户端与账户管理器关联后，将通过RPC与其进行定期通信。通过与账户管理器通信，客户端可以获取志愿者设置的需要添加与删除的项目（以及对应的账号）。
我们将账户管理器设计成支持“项目选择”网页的结构，志愿者可以通过“勾选自己中意的项目”的方式来批量添加这些项目。这样的结构解就解决了上文所述的两个问题。比如，一名拥有许多计算机的志愿者，可以将所有的计算机都与他的账户管理器关联，然后再对自己的账户管理器进行配置，选择想要添加的项目，并一次性更新他所有计算机上的BOINC客户端。目前，已有两套账户管理器可供志愿者们使用：GridRepublic ( https://www.gridrepublic.org/)和BAM! ( https://boincstats.com/en/bam/)。最近，账户管理器还实现了协作志愿计算模式（coordinated VC model），在这个模式下志愿者可选择协助支持的科学领域，而非特定的某个项目。关于这个模式我们会在10.1处进行详细介绍。
当志愿者在账户管理器上选择了一个项目时，最初在这个项目上是没有账号的。所以账户管理器需要具有在项目上创建账号的能力，要做到这点，项目会输出一系列远程过程调用用以实现创建及查询用户。
2.4 计算与关键词配置（keyword preferences）
志愿者可以通过计算参数设置（computing preferences）来控制BOINC如何使用计算机的资源。比如，可以启用CPU节流（CPU throttling），这个功能可以通过自动地开关计算来控制CPU的温度。其他的选项包括“是否在计算机处于使用状态时暂停计算”，“对硬盘及内存空间的使用限制”，“对网络使用的限制”，“对每日计算时间与网络使用量的限制”以及“缓存任务量”等等。计算参数设置即可以通过项目主页上的界面进行配置，也可以直接在账户管理器中进行配置。如果在账户管理器中进行配置的话，志愿者所有添加到账户管理器中的计算机都将继承这些设置。另外，这些设置也可以在本地的客户端上单独修改。
最近，我们引入了一种称为关键词配置的概念。BOINC定义了两组“关键词（key words）”。一组描述科学领域（比如物理学、天体物理学、生物医学、癌症研究等），另一组描述项目的位置（比如亚洲、美国、加利福尼亚大学伯克利分校等）。志愿者们可以对某些关键词勾选“是”或“否”，以指出他们所偏好或希望避开的项目特征。这一系统可用于两种目的：
·包含多个科学领域研究的项目，可以让志愿者自主选择支持其中的哪个领域。项目在任务上添加关键词标记，在向志愿者们发送任务的时候，BOINC即可根据每个志愿者设定的关键词向他们发送更加贴合他们偏好的任务。 ·这一功能的实现也是协作志愿计算模式的一个前提。“协作者”账户管理器会依据志愿者设定好的关键词，动态地将接近志愿者偏好的项目分配给他们。（详见10.1部分）
=======0316更新=======
3. 任务处理概要与特性
3.1 处理资源不一致问题
志愿计算中，参与计算的计算机数量时刻处于变化状态。在硬件层面上，计算机中可能有英特尔兼容架构的、Alpha架构的、MIPS架构的或者ARM架构的CPU，以及这些CPU的32位和64位版本。英特尔兼容架构的CPU拥有多种特殊的指令集，比如SSE3。ARM处理器则有高级SIMD延伸指令集（NEON）或者向量浮点运算单元（VFP floating-point units）。诸多计算机中运算的系统也不尽相同（Windows, Mac OS X, Linux, FreeBSD,Android），更不用提这些操作系统的不同版本。另外还有很多由NVIDIA、AMD和英特尔制造的GPU，以及与之对应的提供不同特性的不同版本驱动。
BOINC提供了一个框架，这个框架能够让项目更加方便有效地使用这些基于不同硬件架构、运行不同系统的计算机。项目方可以针对每个特定的软硬件组合进行不同版本计算程序的开发。这些版本称为“计算程序版本”（app versions），而为了某一研究开发的所有版本的计算程序则统称为“计算程序”（app）。项目分发的任务必与计算程序对应，而非与计算程序版本对应。
BOINC定义了一系列的“平台”（platforms），平台指的是某种处理器与某种操作系统的组合。比如Windows，Intelx64就是一个平台。每个计算程序版本都对应一种平台，并且只会被发放至支持（使用）此平台的计算机。
为了更有效地选择计算程序版本，BIONC提供了“方案类型”（plan class）机制。方案类型是的功能是，它读取算机软件与硬件方面的简要信息，并返回三部分内容：一是某一版本的计算程序能否在此电脑上运行；二是如果能够运行，有何种计算资源（CPU和GPU）可供使用；三是可用资源的峰值计算能力（peak FLOPS）。比如，一个方案类型可以指明某一版本的计算程序需要的GPU型号以及需要的最低驱动版本。方案类型可由XML进行配置，亦可由C++函数形式进行实现。计算程序版本可与方案类型关联。
计算程序版本都是整数。一般来说，对于已经开始计算的任务，会沿用开始计算时所使用的计算程序版本；而对于新任务则会使用最新版本的（且适配于当前平台及其可用资源的）计算程序。
当BOINC客户端向服务器请求任务时，发送的请求中包含了当前计算机支持的平台，以及自身软硬件的简要信息。当项目服务器向计算机分发任务时，服务器会选择一个与计算机平台相兼容的计算程序版本。有关任务调度策略的内容会在6.4部分进行详细描述。
简单举例来说，SETI@home支持9种平台，拥有2套计算程序，86个计算程序版本以及34种方案类型。
=======0317更新=======
3.2 匿名平台机制
默认情况下，BOINC客户端会从项目服务器获取计算程序。但是这样的方法在下列三种情况中并不适用： ·项目没有开发支持当前使计算机的计算程序； ·志愿者出于安全性考虑，只运行由自己从源码编译的计算程序； ·志愿者希望为特定的型号CPU进行优化，或想要为GPU或其他协处理器开发计算程序；
为了解决这些问题，BOINC提供了一种称为“匿名平台”（anonymous platform）的机制。这种机制允许志愿者使用自主开发，或从第三方获取计算程序。但是该机制仅适用于开放计算程序源代码的项目。
在完成志愿者自己版本的计算程序之后，还需要创建一个配置文件对此版本的计算程序进行描述：计算程序包含的文件，对CPU和GPU的使用情况，以及预计的计算能力。如果BOINC客户端发现了这样的配置文件，即将文件内容送至调度器，用以向服务器申请对应的任务包。支持匿名平台的项目一般也都具有导入导出“参照任务”的功能，用来检查他们使用的计算程序版本是否有问题。
在一些项目中（比如SETI@home），已经围绕匿名平台机制形成了志愿者社区，在这个社区中志愿者们完成了多种适用于不同GPU及CPU特性的计算程序开发工作。这些开发工作对整套计算程序的开发也产生了积极的影响，许多由志愿者开发的计算程序版本已被项目官方所采用。
=======0318更新=======
3.3 任务属性
BOINC中的“任务”（job）包含其对应的计算程序信息，以及一组原始数据文件（input files）。一个任务都带有至少一个instances。任务有输入文件，instances有输出文件。服务器向一个客户端发放instance的同时会指定要使用的计算程序版本。客户端下载原始数据文件以及计算程序，执行计算程序，并（如果计算成功完成的话）上传计算结果文件以及标准的错误输出（standard error output）。
下文中，我们使用“FLOPs”来表示FLOP（浮点操作，floating-point operation）的复数形式。用FLOPS表示浮点操作每秒（译：前文中多数直接译为“计算能力”）。
每个任务都由捆绑器（submitter）赋予了如下几种特性： ·完成任务需要的浮点操作次数估计值（用来估算运行时间，详见6.3部分）； ·完成任务所需的最大浮点操作次数，用来跳过会进入死循环的任务； ·任务对磁盘空间用量的上限，用于服务器挑选任务和跳过会占用无限空间的问题任务； ·（可选特性）一组描述该任务所属科学领域的关键词。
3.4 结果验证 由于硬件错误或者用户恶意操作等原因，主机可能会向服务器返回错误的结果。项目一般会要求最终的结果具有比较高的正确率，在BOINC中我们提供了几种方法来做到这点：在对物质世界进行模拟的计算中，可以对能量守恒以及最终结果的稳定性进行验证；对于其他类型的计算来说，可以使用叫做“多重验证”（replication-based validation）的机制。这种机制会要求每个任务都要由两台无关的计算机进行处理。如果双方得出一致的结果，那么就将此结果作为正确的结果接受；如果不一致，则生成第三个参照（instance）并进行计算。此过程将持续至一致结果数量达到某一阈值，或者参照任务的数量达到设定上界。
=======0319更新=======
两结果一致意味着什么？由于参与浮点计算的硬件以及不容版本计算程序所使用数学库（math libraries）的不同，两台电脑有可能传回不同但却等效的有效结果。McIntosh等的研究[9]表明：通过精心选择的编译器、编译选项以及程序库，在不同主流平台上运行同一FORTRAN程序，是有可能得到完全相同的运算结果的。但实际上，一般来说不同平台的运算结果还是会存在差异。对于那些数学稳定（numerically stable）的计算程序来说，这些差异只会造成结果出现细微的偏差。BOINC允许项目为特定的计算程序提供验证器（validator），用来决定究竟是否能将两结果视为等效（比如以一个规定的容忍范围为准）。
对现实世界的模拟计算一般都是不稳定的。对于此类计算程序，BOINC提供一种称为“等价平台冗余”（homogeneous redundancy）[10]的机制。在这种机制中，所有参与计算的计算机都按照软硬件被归为不同的等价组（equivalence class），这样处于同一等价组的计算机的计算结果就有可比较性了。只要一个参照任务发给了某台计算机，那么后续的其他参照任务都将被分发给与其同组的计算机。BOINC提供两种分组方式：一种较为粗糙的方式，只包含操作系统以及CPU制造商信息；另一种稍精细的，还加入了CPU型号。另外，项目也可对分组方式进行自定义。
在某些情况下，不同计算程序版本之间的结果也有可能不同。比如，CPU计算程序与GPU计算程序的结果，都是有效结果，然而两者间并不具备可比性。为解决此问题，BOINC提供了一个称为“同版本计算程序”（homogeneous app version）的选项。该选项会使一个任务的所有参照任务都是用相同版本的计算程序进行计算。此选项可与等价平台冗余功能配合使用。
仅单纯的进行重复验证对计算效率有着很大的影响，一旦使用则最少使效率减半。BOINC提供了一个好一些的方法，称为“自适应重复验证”（adaptive replication）。这种方法的思想是辨识持续返回正确结果的主机（一般来说这样的主机是占绝大多数），对于这些主机的任务偶尔使用重复验证。实际上，由于一些机器在CPU任务上表现很好，但GPU任务却经常出错，我们使用主机标识和计算程序版本两个参数来共同描述某台主机的“声望值”。
=======0321更新=======
自适应重复验证功能是这样工作的：BOINC服务器为每个主机-计算程序版本组合进行统计，当某一组合通过重复验证连续返回有效结果的次数N大于某一阈值时，后续发放给该主机的使用该版本计算程序的任务便不再全部要求重复验证，而是以概率方式决定是否重复验证。随着N增大，需要重复验证的概率将趋于0。就算在恶意“志愿者”存在的情况下，自适应重复验证仍能保证相当低的错误率（错误结果被当做有效结果接受），仅有少部分错误能够逃过它的鉴别。
结果验证对于处理积分作弊（credit cheating）（详见第7部分）行为非常有效。积分仅授予有效结果，而绝大多数“伪造的”结果将无法通过验证，从而无法得分。对于那些经常返回相同结果的计算程序（比如验证质数的程序，只返回是或否），作弊者非常容易对结果进行伪造，并经常能依次得到积分。对此，计算程序可以加入一些基于中间结果的额外输出予以应对。
3.5 “限定任务处理”（Specialized job processing）特性 计算程序的版本号按发布的先后顺序从小到大排列。一般来说，对于给定的某一平台-方案类型组合，BOINC总会使用与其对应的最新版本计算程序。但在某些情形中，也有可能出现新版本计算程序的计算结果有效，但却不同于老版本的情况。对于这个问题，BOINC允许任务被“指定”（pinned）由特定版本计算程序进行处理，这时，此任务将仅可由指定版本的计算程序进行处理。
有些BOINC项目的任务运行时间可达数周甚至数月之久。由于主机的变化或用户失去耐心，有些任务并不能够完成全部计算，但它们产生的一些中间结果有可能还具有一些科学价值。针对这样的任务，BOINC有两个特性能够予以很好的支持。第一，计算程序可以告知BOINC客户端，哪些输文件已经输出完毕，并在任务完成之前就提前上传；第二，计算程序可生成汇聚信息（trickle-up messages）直接上传至服务器，并由项目的有关逻辑进行管理。这一特性主可用于任务的分段得分（即没算完整个任务也可获得已完成部分的分数）。
有些计算程序的原始数据文件非常大，但很多任务用的都是同一组原始数据。为了最小化网络占用以及服务器负担，BOINC提供了名为“本地调度”（locality scheduling）的特性。这样的数据文件会被标记为“粘性”（sticky）数据（详见3.10部分）。当任务计算完成后，该数据将仍驻留在计算机中，而此时任务调度器将优先为该主机发放使用这些驻留数据的任务（详见3.5部分）。
BOINC允许指定任务交由特定主机或账户进行处理。这项功能主要供项目开发者运行测试任务时使用。
志愿者手中不同设备，比如说一台高配置的台式机和一部智能手机，他们之间的性能差距，在各种意义上都非常重要：同一个任务，由前者处理五分钟即能完成，而后者则需要花费超过一周的时间。为了控制服务器的负载，以及保持志愿者们参与的动力，我们希望任务的运行时间是在“小时”这一尺度上。为了保证任务在不同平台上的运行时间一致，BOINC提供了一种机制，这种机制允许项目生成一尺寸范围（也就是处理数据量的多与少）内的任务。BOINC服务器对每个主机-计算程序版本的组合进行记录，统计他们的性能表现，并分发给他们与其能力相符的任务——给性能更高的设备发放更大的任务。
对于轻度使用CPU的计算程序（比如传感器监测，网络性能测试以及网络爬虫等），可被标记为“非CPU密集”（non-CPU-intensive）。在BOINC中，这类计算程序享受特殊待遇：每个客户端中仅可运行一个任务、计算程序一直运行，并且这类计算程序的优先级为标准优先级。
对BOINC的计算程序进行调试是非常困难的，因为错误往往出现在远程端，很难直接接触。为此，BOINC提供了一个特性：（出错时）客户端将上报异常退出代码以及标志数字（signal numbers）和标准错误输出（standard error output）。服务器可提供网页界面工具，供开发者分解平台、计算程序版本、错误类型等因素，以及查看出错设备的详细信息，从而更简单地查找问题所在。这一特性对于出现在特定操作系统版本或显卡驱动版本上的错误非常有效。
=======0322更新=======
3.6 BOINC的运行环境
我们现在来讨论BOINC客户端运行计算程序的环境，以及客户端对（运行中的）任务的控制和通信方式。
Windows和Mac OS X 系统中的BOINC客户端安装程序会在系统中创建一个最低权限的账户，BOINC会运行于此账户下。这种模式能够在一定程度上保护BOINC相关的文件不受问题程序和恶意程序的影响，因为这些程序不能够读写属于现存用户（existing users）的文件。
BOINC客户端的文件存储于一个单独的目录中，此目录中包含：1.项目目录，用于分别存放与客户端已添加的项目有关的文件；2.任务目录，每个运行中的任务都拥有一个专属目录，其中包含对存放于对应项目目录中一些文件的符号连接（symbolic links）引用，这样当存在多个任务的时候，他们就可以共享同一个计算程序和原始数据文件了。
为了更满足合志愿者的使用需求同时也为了支持CPU节流以及客户端图形界面的监测与控制功能，客户端须具备挂起（暂停）计算、恢复计算、终止任务以及监测CPU时间和内存用量的能力。有些任务可能需要有多个进程共同进行处理，一些先进些的操作系统会带有“行程群组”（或过程群组，process-group）操作，BOINC还必须同时兼容不具备此功能的系统。因此BOINC由自己实现此功能，BOINC对该功能的实现基于客户端与计算程序间的消息传递（message-passing）。此处的消息传递使用共享内存（shared memory），所有操作系统都支持这种方式。在不同方向的消息传递中，都存在着多个队列。由客户端至计算程序的消息传递：已挂起，恢复，退出；由计算程序至客户端的消息传递：当前CPU时间，上一存盘点的CPU时间，已完成部分，工作集（working set）大小。所有队列每一秒都会对入队内容进行检测。
=======0325更新=======
所有运行于BOINC平台的计算程序都必须实现这种消息协议（message protocol）。一种实现方法是针对目标平台，使用BOINC运行环境库重及API建计算程序（rebuild the application）。这种计算程序我们称之为“原生计算程序”（native application）；另一种途径是使用“包装器”（wrapper program），这一内容将在下一部分详细介绍。这两种实现途径如图二所示。
图二
对于序列程序（sequential programs），运行库会创建一个计时器线程（timer thread），当工作线程运行计算程序的时候，该线程会与客户端进行通信。在Windows系统中，the timer thread controls the workerthread with Windows thread primitives .Unix方面，由于它的线程函数库（thread library）不允许一个线程将另一个线程挂起，所以我们使用一种由工作线程控制的10Hz信号，通过这个信号来控制工作线程自己定时进行休眠。
对于多线程计算程序（比如OpenMP及OpenCL CPU），处理结构有些细微的差异。在Unix系统中，程序会产生分支。父进程（parent process）通过信号来掌握进程控制消息，子进程则负责运行程序以及使用计时器线程来处理状态及检查点消息。
BOINC支持计算程序级的检查点及重启。每隔几分钟，客户端就会发送消息要求计算程序进行存盘（保存检查点）。当计算程序进行到某个能够有效进行存盘的位置时（比如进行到外循环的起点时），就会对一个检查点文件进行写入，并向客户端发送消息进行告知，也就是说，当计算程序保存完检查点数据后，客户端会得到消息，这样可以避免抢占过长时间未进行存盘的任务。
=======0413更新=======
在使用GPU的计算程序中，程序的CPU部分会向GPU发放简短的“核”（dispatches short “kernels”）。在对核进行处理的过程中，计算程序必须不能处于挂起状态。因此，BOINC运行环境库提供了对masked sections 的支持。这项特性可以用来推迟挂起与终止操作的执行。对GPU核的操作应当在masked sections 中进行（写入存盘点文件同样）。
默认情况下，BOINC客户端会使用最低优先级运行计算程序，而非CPU密集型计算程序以及打包程序运行于普通优先级。GPU计算程序已经被证实在低优先级下运行时，性能表现极差，所以我们将它设定为运行于普通优先级。
CPU限流（见2.4部分）的实现方式：通过挂起客户端并以一定的时间间隔暂停、恢复计算程序，来满足以用户设定的使用率使用CPU。
计算程序有可能会遇到无法继续计算的情况，比如当一个GPU计算程序分配显存失败的时候。BOINC的API提供了一个“临时退出”（temporary exit）函数，这个函数能够使计算程序退出，并告知客户端在一定的时间后重新对其进行调度。多次造成此情况的任务将会被直接终止。
计算程序必须对主机的软件环境有一个最坏的估计。如果他们需要标准系统库以外的依赖库，则计算程序必须要包含这些库，当BOINC客户端运行一个任务的时候，将会首先在任务目录中寻找所需的依赖库。
3.7 计算程序的图形
每个版本的计算程序中还可以包含另一个可执行文件，这个文件负责根据计算的过程生成可视化图像。这个程序可以由BOINC屏保运行（BOINC屏保会轮流显示处于运行状态任务的图像），也可以直接通过BOINC Manager 打开。
图形程序运行于任务目录下，它获取当前任务状态的方式有两种：一种是通过读取同目录下的文件；另一种是通过创建一个共享内存区域，与计算程序共享数据。考虑到可移植性，图像程序一般使用OpenGl开发。
3.8 打包的计算程序与虚拟机计算程序 本地的计算程序必须修改为使用BOINC API运行，并针对目标平台进行重建。这件事情做起来会很难，所以BOINC提供了“包装器”机制来解决这个问题。
BOINC 包装器允许任意的可执行程序运行于BOINC平台（需满足程序对平台的要求）。包装器在BOINC客户端与计算程序之间起到一个媒介的作用。它负责协调来自客户端的运行环境消息（见3.6部分），并将其翻译成操作系统操作指令（比如Unix系统中的信号）以实现对计算程序的控制。BOINC分别为主流平台提供了不同版本的包装器。每个版本包含有对应版本的包装器版本（作为主程序）以及可执行文件。包装器可以按指令运行一个执行序列。Marosi et al. 开发了一款通用性更强的包装器，这种包装器使用类shell 脚本语言（shell-like scripting language），能够支持任意工作流程。[11]
VirtualBox是一款面向英特尔兼容计算机的、多平台的开源虚拟机系统，BOINC支持在该系统中运行的计算程序。因此，计算程序可以在Linux上进行开发，而运行在Windows 和 Mac OS X系统中。BOINC客户端会自动探测当前计算机中是否已安装VirtualBox，仅当计算机中没有安装时，才会向计算机中分发安装程序。在Windows系统中，BOINC安装程序的推荐配置为在安装BOINC时也安装VirtualBox。
为了支持虚拟机计算程序，BOINC提供了成为“VBox包装器（VBox wrapper）”的程序。该程序是BOINC客户端与VirtualBox程序之间的桥梁，它能将运行环境系统消息翻译成VirtualBox的操作。VirtualBox支持在宿主与虚拟机之间共享目录。VBox 包装器会为虚拟机任务创建一个共享的目录，将原始数据放置于此，并从这里获得任务结果文件。
在解决异质性问题上，虚拟机技术还提供了一个牢固的沙盒，可以允许使用不信任的计算程序。与此同时，该技术还利用“快照（snapshot）”特性，实现了计算程序独立的存盘点/重启能力。包装器告知VirtualBox每隔几分钟就创建一个快照，如果计算由于某种原因停止了（比如计算机关闭），那么该任务能够在回到能够计算的环境时，从快照中恢复计算状态。
BOINC的虚拟机系统可与容器系统（比如Docker[12]）配合使用。基于Docker 的计算程序包含一个Docker 映像（操作系统以及指定的环境库）以及一个可执行程序。容器将运行于VirtualBox 虚拟机中。Docker 映像中包含有一套分层的文件（a layered set of files）。典型情况下，当新版本计算程序发布时仅有顶层文件会改变，所以对网络流量以及存储能力的要求比仅使用虚拟机映像时要低。
虚拟机计算程序一般都会包含虚拟机或容器映像，不过也可以把映像作为原始输入数据进行存放，如果使用这个方法，则即可用一种计算程序对进行任意的科学计算。This is significant becausecreating an app includes signing its files, which is a manual operation.我们将这种计算程序成为“通用计算程序（universal app）”。如果项目的计算程序已经打包成虚拟机或容器映像，那么他们就可以不经过任何移植或其他工序的情况下运行在BOINC平台上。
在使用通用计算程序的时候，需要考虑一点安全上的问题。由于任务的原始数据文件并不带有代码签名（not code-signed）（详见3.10部分）。所以一旦项目服务器被攻击，那么攻击者即可使用其他的虚拟机镜像进行替换。不过这种风险的概率还是比较小的，因为虚拟机是沙盒，除去任务数据文件及结果文件意外，它并不能自由地访问宿主机的其他内容。
虚拟机计算程序由González et al. [13]于2007年提出，虚拟机包装器则是由CERN [14] 与 SZTAKI [15]完成开发。此外，Ferreira et al. 描述了一种可以作为多个虚拟机管理程序接口的包装器[16]。
3.9 任务提交（Job submission）与文件管理 任务提交包含以下三个步骤：1.将任务的原始数据文件置于公众可访问的web服务器中；2.创建任务；3.处理返回的任务结果。BIONC提供用于在服务器上传输文件以及任务提交的C++ API以及命令行工具。此外还提供用于远程文件管理与任务提交的HTTP RPC API 以及在Python 、PHP 及C++ 语言中打包好的所有这些接口。处于效率考虑，这些接口以“任务组”（“batches” of jobs）的形式进行定义，
每一个计算程序都有负责处理已完成任务的收集器守护进程（assimilator daemon）。该进程与项目提供的使用C++或Python 语言编写的计算结果处理函数连接。此函数有会将计算结果文件移动至其他目录，或者将其解析并写入某个数据库。 | 
发表于 2019-3-13 23:32:23
（