Взаимодействие Web-сервера и сервера тестирования

Как Web-сервер, так и сервер тестирования написаны на языке Go и для обмена сообщениями используют сетевые именованные типизированные каналы, реализованные в пакете netchan стандартной библиотеки языка Go. При этом Web-сервер поддерживает работу сразу с несколькими серверами тестирования, что предоставляет возможность разворачивания системы тестирования T-BMSTU на кластерной вычислительной системе.

Сервер тестирования сам инициирует соединение с Web-сервером. Для этого он устанавливает соединение с каналом «setup», экспортируемым Web-сервером. Канал «setup» направлен от Web-сервера к серверу тестирования. Из него сервер тестирования считывает пакет Setup, структура которого описана в таблице 1. В этом пакете записаны сгенерированные Web-сервером уникальные имена трёх каналов, через которые будет осуществляться взаимодействие Web-сервера и сервера тестирования. Получив имена каналов, сервер тестирования устанавливает соединения с каждым каналом и переходит в режим ожидания запроса на тестирование решения пользователя. Web-сервер содержит пул подключённых к нему серверов тестирования, и при получении решения от пользователя выбирает один из свободных серверов тестирования и отправляет ему запрос.

Таблица 1 – Структура пакета Setup

Имя поля	Тип поля	Описание
QueryChanName	строка	Имя канала запросов
AnswerChanName	строка	Имя канала ответов
TaskChanName	строка	Имя канала проверочных данных

Канал запросов направлен от Web-сервера к серверу тестирования. Из него сервер тестирования получает пакеты Query, структура которых описана в таблице 2. Каждый пакет описывает одно решение, отправленное на проверку. Задача, соответствующая решению, определяется значением поля Uid. Это значение является ключом, по которому сервер тестирования получает проверочные данные из кэша задач. Сервер тестирования компилирует полученное решение с использованием компилятора, определяемого значением поля Language запроса, и если компиляция прошла успешно, прогоняет решение через набор тестов, используя для этого «песочницу». При этом каждый запуск решения ограничен по времени выполнения и по объёму используемой оперативной памяти.

Отдельного обсуждения заслуживает поле Task в составе пакета Query. Оно либо пусто, либо содержит массив байт, в котором находятся сжатые в tar.gz проверочные данные для задачи. Web-сервер заполняет это поле только по требованию сервера тестирования. Происходит это следующим образом: если сервер тестирования не находит в кэше задач проверочные данных для задачи, решение которой находится в запросе, он отправляет Web-серверу ответ, содержащий вердикт UNKNOWN_TASK, и тогда Web-сервер повторно отправляет запрос, заполнив в нём поле Task.

Таблица 2 – Структура пакета Query

Имя поля	Тип поля	Описание
Uid	64-разрядное целое число	Уникальный идентификатор задачи
TimeLimit	32-разрядное целое число	Максимальное время работы решения (в миллисекундах)
MemoryLimit	32-разрядное целое число	Максимальный размер данных в адресном пространстве процесса, в котором запущено решение (в Кб)
Language	32-разрядное целое число	Идентификатор языка, на котором написано решение
Solution	строка	Исходный код решения
Task	массив байт	Проверочные данные для задачи (в tar.gz)

Канал ответов направлен от сервера тестирования к Web-серверу. В него сервер тестирования записывает свой вердикт в виде пакета Answer, структура которого описана в таблице 3. Поле Result пакета Answer содержит код, описывающий вердикт сервера тестирования (таблица 4). Если решение успешно откомпилировалось, но не прошло какой-то тест, то данные этого теста также помещаются в пакет.

Таблица 3 – Структура пакета Answer

Имя поля	Тип поля	Описание
Result	32-разрядное целое число	Код результата
CompilerOutput	строка	Сообщения компилятора
FailedTest	строка	Входные данные для теста, не пройденного решением
SolutionOutput	строка	Ошибочный результат выполнения решения
RightOutput	строка	Правильный результат для теста, не пройденного решением.

Таблица 4 – Коды вердикта сервера тестирования

Код	Описание
OK	Компиляция решения выполнена успешно, все тесты пройдены.
COMPILATION_ERROR	Решение не прошло компиляцию, сообщения компилятора помещены в поле CompilerOutput.
WRONG_ANSWER	Результат выполнения решения на одном из тестов был проанализирован и признан ошибочным.
PRESENTATION_ERROR	Формат результата выполнения решения на одном из тестов неправилен и не может быть разобран сервером тестирования.
TIME_LIMIT_EXCEEDED	Выполнение решения на одном из тестов было прервано из-за превышения лимита времени.
MEMORY_LIMIT_EXCEEDED	Выполнение решения на одном из тестов было прервано из-за превышения лимита памяти.
RUN_TIME_ERROR	В процессе выполнения решения на одном из тестов произошла ошибка времени выполнения.
INTERNAL_ERROR	Внутренняя ошибка сервера.
UNKNOWN_TASK	Проверочные данные для задачи отсутствуют в кэше задач.

2.4 Организация «песочницы»

Для безопасного управляемого запуска решений применяются четыре утилиты ОС Linux: утилита «chroot» позволяет изолировать запускаемую программу внутри заданного каталога; утилита «su» запускает программу от имени специального непривилегированного пользователя; утилита «ulimit» ограничивает ресурсы, доступные программе; утилита «time» измеряет время работы программы.

Сервер тестирования работает от имени пользователя «root», потому что только администратору операционной системы разрешено пользоваться утилитой «chroot». Решение задачи изолируется в каталоге «/var/chroot», который, собственно, и является «песочницей». Это означает, что для решения этот каталог представляется корнем файловой системы, и поэтому доступ к элементам файловой системы вне этого каталога становится невозможным.

«Песочница» содержит копии всех исполняемых файлов и библиотек, которые могут понадобиться запускаемому решению. Кроме того, в рамках «песочницы» создан непривилегированный пользователь «tbmstu», от имени которого запускается решение. Этому пользователю доступен для записи только каталог «/home/tbmstu» в рамках песочницы (реально «/var/chroot/home/tbmstu»). Перед каждым запуском решения содержимое этого каталога стирается. Затем в каталог помещается исполняемый файл решения, а также файл «input», содержащий входные данные очередного теста. Файл «input» направляется в стандартный входной поток запускаемого решения, а стандартный выходной поток перенаправляется в файл «output».

Когда решение поступает на сервер тестирования, оно компилируется, после чего осуществляется пробный запуск. Пробный запуск позволяет оценить размер секций кода исполняемого файла решения. Этот размер прибавляется к значению поля MemoryLimit пакета Query для получения максимального размера оперативной памяти, предоставляемой решению.

Выполнение решения для каждого теста осуществляется под контролем утилиты «ulimit», которая не позволяет решению использовать больше памяти, нежели посчитанный максимальный размер. Кроме того, утилита «ulimit» не разрешает решению порождать дочерние процессы и создавать файлы, суммарный размер которых превышает 100 Мб.

Время выполнения решения контролируется самим сервером тестирования. Если решение на каком-то тесте работает вдвое дольше, чем указано в поле TimeLimit пакета Query, сервер тестирования принудительно завершает выполнение решения. Сервер тестирования задаёт грубую верхнюю границу времени выполнения приложения, потому что неспособен производить точное измерение времени.

За точное измерение времени выполнения решения отвечает утилита «time». Если решение не было принудительно завершено сервером тестирования, то время, измеренное, утилитой «time», умножается на поправочный коэффициент, зависящий от производительности компьютера, на котором запущен сервер тестирования, сравнивается со значением TimeLimit, и, в случае превышения этого значения, выносится вердикт с кодом TIME_LIMIT_EXCEEDED.

Из-за того что организация «песочницы» требует активного использования утилит ОС Linux, сервер тестирования не может работать в ОС Windows. Однако, предположительно, его можно развернуть на FreeBSD и MacOS X.

Дата добавления: 2015-08-21