Далее, невозможность нормального диалога между клиентом и сервером приводит к тому, что приходится отказаться от какого-либо составления расписания заданий, ведь совершенно непонятно, какой клиент в какое время запросит работу и в какое время вернет результат.
Также принятая в BOINC система рабочих модулей предполагает, что в нашем случае тестирующий модуль должен передаваться каждый раз вместе с очередным тестом, что очень накладно.
Проблемы разграничения полномочий. Изначально не предполагается различия между клиентами. Фактически, в системе тестирования есть несколько ролей: администратор, разработчик и просто хостер (предоставляет машину, и не имеет права на просмотр результатов исполнения). Примером может служить пользователь рабочей станции из другого отдела компании.
Однако в случае с BOINC мы имеем систему, которая не различает клиентов. Т.е. всякий может подключиться к системе. И все имеют одинаковые права. В этих условиях простая запись в каталог сервера уже является дырой в безопасности. К тому же разграничение полномочий — фактически, задача веб-интерфейса и сетевого экрана, который придется тонко настраивать для того, чтобы оградить систему от нежелательных пользователей. В рамках системы BOINC эта задача требует длительного анализа её разрешимости (разрешимость сомнительна).
В системе BOINC предполагается, что код компонента исходит от администратора системы, то есть, доверенного лица, однако в нашем случае это не так. Необходимо связывать новые рабочие модули с идентификатором пользователя, который их создал.
Хранение рабочих модулей. BOINC хранит рабочие модули и результаты их работы в виде простых файлов на файловой системе сервера. Мы считаем такой подход неудобным и неправильным. Это порождает необходимость в запутанной системе уникальных имен каталогов и деформацию имен файлов, для того, чтобы файлы не заменялись, если их имена совпадают. Более того, в целях решения проблемы удаления этих файлов разработчикам BOINC пришлось даже ввести отдельного демона — File Deleter, который постоянно работает на сервере и занимается сборкой мусора. Предлагается полностью отказаться от подобного подхода и размещать файлы рабочих модулей и результаты в БД без сохранения их в каталогах сервера.
Ошибки на уровне стандартных приложений. В целях установления возможностей системы BOINC мы подключались к различным проектам, основанным на ней, и пробовали принимать в них участие. Это выявило несколько интересных фактов о системе, например, подключившись к SETI@home (самому известному проекту на базе BOINC) с домашней машины, я понял, что клиент BOINC для платформы Linux не соответствует никаким критериям качества.
Также при тестировании замечено, что один из необходимых серверных модулей (под названием feeder) время от времени прекращает работу, и реанимировать его удается только при помощи пересоздания проекта с нуля. Причины такого поведения неясны, все попытки поправить положение не увенчались успехом.
Очень неаккуратный, а местами и просто ошибочный код. В частности, в некоторых местах исходного кода компонентов BOINC были выявлены утечки памяти, консольные утилиты иногда вызывают ошибку Segmentation fault, предлагаемые средства разбора XML чрезвычайно бедны и, ко всему прочему, работают ошибочно (правильный разбор зависит от расстановки пробельных символов в файле, что для формата XML неприемлемо).
Система BOINC поставляется вместе с полными исходными текстами, поэтому теоретически исправить вышеперечисленные недостатки можно. Однако в результате анализа размеров правки системы было решено, что целесообразнее написать все с нуля. Усугубляется же положение еще и тем, что документация имеется только по небольшому числу компонентов системы, остальное же не содержит никаких комментариев, поскольку разработчики посчитали, что эти компоненты переписываться или правиться не будут.
Подробнее о том, какая же архитектура должна прийти на смену BOINC, смотрите доклад Кузнецова Алексея [6].
Что сделано:.
1. Доказана возможность эффективного применения технологии GRID в задаче тестирования программного обеспечения.
2. Написан прототип системы распределенного тестирования приложений.
3. В ходе работы над прототипом и его тестирования детально разобраны и четко поняты требования к реальной системе распределенного тестирования приложений.
4. Разработана модель будущей архитектуры системы (см. [6]).
Планы на будущее:
1. Реализация новой архитектуры системы.
2. Разработка эффективных алгоритмов составления расписания выполнения тестов на разных машинах.
3. Апробация системы в реальных условиях (тестирование в фирме SWsoft).
1. http://grid.org — общая информация о GRID-системах.
2. http://globus.org — популярный GRID-инструментарий Globus.
3. http://boinc.berkeley.edu — популярный GRID-инструментарий BOINC.
4. Kelly Michael, Using Test Agents (http://www-128.ibm.com/developerworks/rational/library/3842.html)
5. http://swsoft.nsu.ru/~savenko/tgrid — сайт проекта.
6. Курсовая работа Кузнецова Алексея.