Новый клиент-серверный протокол
Новый клиент-сервер предполагает передачу сообщений на языке xml по протоколу http.
Преймущества
- работа с базой данных переносится полностью на сторону сервера.
- расширяем
- возможно написание параллельного тестировщика, так чтобы один поток запрашивал несколько задач, а затем запускал много потоков (по числу задач), которые бы получали исходный код, тестировали задачу и отсылали решение. Это позволит получать информацию о задаче (лимиты времени, памяти) один раз, параллельно запускать винкилл.
Описание протокола (однопоточный httpClientServer)
Комментарии
(слева направо)
Первая диаграмма: один поток запрашивает решения на тестирование, получает мета-информацию о решениях, задачах, компиляторах.
Запрашивает и получает архив с тестами к задачам, если их текущая версия на клиенте устарела.
(В многопоточной реализации предполагается запрос сразу по нескольким задачам)
Вторая диаграмма: отдельный поток запрашивает исходный код данного решения, компилирует, запускает программу, присылает решение на сервер
Третья диаграмма: сообщения общего вида, которые могут быть получены на любой стадии
Проблемы
- следующую информацию о компиляторах целесообразно хранить в конфиге на клиенте: название bat-файла, расширение файла. Сейчас эта информация хранится в базе данных и запрашивается с сервера, тогда как сами файлы тестировщика лежат на клиенте, и с сервером никак не завязаны.
- в таблице clients базы данных используется поле ip для идентификации клиента, таким образом невозможно запустить несколько тестировщиков на машинах с одним Ip
- в таблице submits вместо поля host логичнее писать поле с id клиента из таблицы clients
- непонятно зачем использовались поля srtt, rttvar, rto, rtt в таблице clients
- компилятор Pascal не урезан! Не удалось получить Security violation, притом что программа участника может удалять файлы, папку Win Kill Info и т.д.
Предложения
Сделать более гибкий тестировщик, как когда-то было ранее
1. Позволить указывать задачи для тестирования (included_tasks=1234)
2. Указывать задачи, которые не тестировать (excluded_tasks)
3. Хранить историю «плохих» решений на тестировщике – решений на которых упал винкилл
