Авторы: Савенко Дмитрий, Кузнецов Алексей
Дата создания: 18.01.2006
Версия: 0.1
Дата последнего изменения: 18.01.2006
Коллектив разработчиков системы Testing Grid единодушно признает, что система BOINC непригодна для дальнейшей разработки проекта. Мы использовали ее для создания прототипа как наиболее простое средство, которое можно максимально быстро подработать для наших нужд, и это было оправданным решением. Но дальнейшая разработка в рамках системы BOINC чревата глубинными проблемами, требующими переписывания недокументированных модулей. Также при работе с BOINC и разборе его исходных кодов было замечено довольно много недостатков чисто технического характера.
Далее идет более подробное описание проблем.
Проблемы разграничения полномочий. Изначально не предполагается различия между клиентами. Фактически, в системе тестирования есть несколько ролей: администратор, разработчик и просто хостер (предоставляет машину, и не имеет права на просмотр рез-тов исполнения. Примером может служить пользователь рабочей станции из другого отдела компании)
Однако в случае с BOINC мы имеем систему, которая не различает клиентов. Т.е. всякий может подключиться к системе. И все имеют одинаковые права. В этих условиях простая запись в каталог сервера уже является дырой в безопасности. К тому же разграничение полномочий фактически - задача веб-интерфейса и сетевого экрана, который придется тонко настраивать для того, чтобы оградить систему от нежелательных пользователей. В рамках системы BOINC эта задача требует длительного анализа её разрешимости (разрешимость сомнительна).
В системе BOINC предполагается, что код исходит от администратора системы, однако в нашем случае это не так. Необходимо связывать новые рабочие модули с идентификатором пользователя, который их создал.
Хранение рабочих модулей. Хранение рабочих модулей и результатов их работы на файловой системе не является правильным. Это пораждает очень интересную систему уникальных имен каталогов и деформацию имен файлов, для того, чтобы файлы не заменялись, если их имена совпадают. Более того, удаление этих файлов — цель дополнительного демона File Deleter, котрый постоянно работает на сервере. Предлагается полностью отказаться от подобного подхода и размещать файлы рабочих модулей и результаты в БД без сохранения их в каталогах сервера
Скудные возможности для диалога между сервером и клинетами. Это является основной проблемой. Фактически, весь диалог сводится к тому, что клиент запрашивает работу у сервера и возвращает ему результат. В нашем случае это означает, что сервер не может заранее узнать, обладает ли клиент необходимыми ресурсами для выполнения рабочего модуля. Дело в том, что система определения возможностей клиента находится в зачаточном состоянии, и стандартных средств для ее расширения не предусмотрено. Нам же крайне важна именно развернутая система определения ресурсов клиентских машин. Также принятая в BOINC система рабочих модулей предполагает, что в нашем случае тестирующий фреймворк должен передаваться каждый раз вместе с очередным тестирующим модулем, что очень накладно.
Ошибки на уровне стандартных приложений. Личный опыт одного из разработчиков, подключившегося с SETI@home (самому известному проекту на базе BOINC) с домашней машины, показал, что клиент BOINC для платформы Linux написан настолько безобразно, что пришлось отказаться от благой цели помочь человечеству в поиске внеземных цивилизаций и удалить BOINC.
Также при тестировании замечено, что один из необходимых серверных модулей (под названием feeder) постоянно "отваливается", и реанимировать его удается только при помощи пересоздания проекта с нуля. Причины такого поведения неясны, все попытки поправить положение не увенчались успехом.
Очень неаккуратный, а местами и просто ошибочный код. В частности, в некоторых местах были выявленны утечки памяти, консольные утилиты иногда падают по Segmentation fault, предлагаемые средства парсинга XML чрезвычайно бедны и, ко всему прочему, работают ошибочно (правильный парсинг зависит от расстановки whitespace'ов в файле, что для формата XML неприемлемо).