Kuznetsov Alexey, 19 September 2005.
Здесь будет дано описание системы BOINC на предмет её возможностей и применимости в проекте Test Grid.

Место системы в реальном мире: An open-source software platform for computing using volunteered resources
Системные требования: (здесь)
Требования к задаче:
Вычислительная задача предполагает независимое параллельное исполнение отдельных её частей с малыми или отсутствующими зависимостями по данным.

Входные и выходные данные передаются через Интернет, поэтому их должно быть не много

Данные, приходящие в ответ не могут считаться 100% достоверными и корректными. (так заявляют разработчики, несмотря на всю систему безопасности.)

Общие сведения
Система представляет собой инфраструктуру, позволяющую любому пользователю сети Интернет принять участие в научных проектах путем предоставления исследователям вычислительных мощностей во время простоя компьютера.

Система BOINC сделана для того, чтобы максимально загрузить рабочие станции, до тех пор, пока доля host-specific ошибок не достигнет определенного уровня.

Вместе с тем, существует достаточно много ограничений, которые могут наложить участники. Например, на объемы данных, передаваемых по сети.

Cуществуют ограничения при распределении заданий. Например, ограничение на количество пользователей, на версии клиентского ПО, на системные требования (CPU\Memory usage)

Запросы клиентов:
Клиенты являются ненадежными в этой системе, поэтому они сами решают, что им пора работать. Запрос на работу выглядит примерно так:
"Я -- супер-клиент, который занят как правило на 5%, и мне нужна такая работа, чтобы быть занятым на 100% в течение Х секунд" Честно говоря, это сильно не укладывается в контекст тестирования, т.к. продолжительность работы непредсказуема, в том числе, возможно, что работа никогда не завершится. Предположительно, данный подход оправдан для экранных заставок.



Безопасность:
 Система рассчитана на защиту сервера от клиентов. Т.к. клиенты в общем случае сами напрашиваются на работу в данной системе,то единственной гарантией того, что выполняется то, что хотят исследователи, является подписанный код. Для этого используются сертификаты, известные клиентам, и при получении задания происходит их проверка.

Клиенты не защищены от некорректных действий кода, который подписан: код может в принципе все, в том числе вывести клиентскую машину из строя. Предполагается, что исследователи протестировали(!) свой код. Как уже говорилось, BOINC использует ЭЦП для подписи распространяемого кода, Каждый проект имеет пару ключей для подписи. Секретный ключ в данной системе должен храниться на изолированной машине, которая используется для генерации цифровых подписей для исполняемого кода. Публичный ключ распространяется вместе с клиентами, все файлы, связанные с проектом отправляются с их цифровыми подписями, созданными с помощью этой пары ключей.

Входные и выходные файлы не шифруются, поэтому, как говорят разработчики, существует опасность кражи этих данных. Разработчики предлагают позаботиться об этом самостоятельно.

Сервер защищен, особенно если учитывать следующие требования соблюдаются: Также предусмотрена защита от некорректных сведений от клиентов, путем дублирования заданий на разных клиентах и сравнения полученных результатов.

Сервер защищен от флуда, путем ограничений на прием результатов, как по размеру, так и по периодичности.

Патенты и авторские права:
BOINC - открытая система, распространяемая под Lesser GNU Public License (LGPL).

Особенности системы:
* Система должна быть остановлена при внесении изменений в задания или настройке.
* Система (сервер) управляется скриптами. (Остановка и запуск, планирование заданий, создание нового проекта)
* Система предлагает на выбор два интерфейса: администратора и участника. Администратору доступен не только web-интерфейс, но и графический интерфейс сервера. (Использует графич. библиотеку WxWidgets)
* Система предоставляет файл конфигурации, расположенный на Web-сервере (конфигурационный файл здесь)


Демоны (на стороне сервера):
Work generator Для каждого проекта свой. Он создает workunit'ы и соответствующие входные файлы для каждого такого unit'а. имеется специальное API для регистрации всего этого в базе данных BOINC-сервера.

Feeder Один на всю систему. Управляет сегментом разделяемой памяти, где хранятся записи БД.

Transitioner Один на всю систему. Обрабатывает состояния и рузультаты работы workunit'ов. Похоже, что этот компонент не предполагает вмешательства исследователя

Validator Для каждого проекта свой. Управляет избыточностью и контролирует принятие согласованных результатов, как предположительно верных.

Assimilator Для каждого проекта свой. Управляет теми заданиями, которые были помечены как выполненные, вернувшие предположительно верный результат или сообщение об ошибке. Успешное завершение может инициировать его фиксацию в БД, и/или генерацию новой работы для клиентов.

File deletion Один на всю систему. Чистит сервер от входных и выходных файлов для workunit-ов, которые больше не нужны.

Database purging Один на всю систему. Очищает БД от тех записей о заданиях, которые уже не нужны, что позволяет избежать разростания БД, если проект работает уже долго.



BOINC API: Описание доступно (Здесь)
API - набор функций С, использующийся клиентами при работе, который позволяет:
Initialization and termination - Специфические процедуры инициализации и остановки задания.
Resolving file names - Доступ к входной информации
I/O wrappers - Обертки ввода-вывода для клиента (fopen заменяется специфическими вызовами)
Checkpointing - Отправка состояния дел на сервер.
Critical sections - Указываются секции кода, при работе в которых остановка не желательна.
Credit reporting - CPU usage report to server.
Communicating with the core client - Сообщает графическому интерфейсу клиента, сколько работы уже сделано и сколько предстоит сделать.
Non-CPU-intensive periods - Указать, что задание не требует в какой-то момент большой загрузки процессора.
Requesting network connection - Потребовать сетевого соединения для задачи.


Результаты работы:
Результаты работы клиентские машины отправляют на сервер, в виде выходных файлов. Список сведений, отправляемых клиентами на сервер:

name A text string, unique across all results in the project.
workunit name Identifies the associated workunit
host The host that executed the computation
exit status The exit status (0 if success)
CPU time The CPU time that was used.
output files The sizes and checksums of its output files. Files with output data.
stderr The stderr output of the computation
recieved time The time when the result was received.