Комментарии 23
Очень интересно, продолжайте, спасибо.
А что Вы имели в виду под «killer #define»?
А что Вы имели в виду под «killer #define»?
Ну это дакая хитрая директива препроцессору, которая разворачивает код в бесконечную последовательность благодаря рекурсии. На своей машине такое никто делать, ясное дело, не станет, а вот тестирующую систему «полечить» находятся любители. Обычно — школьники, от скуки, часу на 2-3 (по словам Саши Кирова, попытки такие были, причём неоднократно).
Систему перезагрузить — дело двух-трёх минут, даже если такое излияние души не пресекается. А вот по ушам за проказы подобные получить можно.
Систему перезагрузить — дело двух-трёх минут, даже если такое излияние души не пресекается. А вот по ушам за проказы подобные получить можно.
На личном опыте помню случаи, когда устанавливали таймлимит и для компиляции. Нечто вроде описаной бесконечной рекурсии, но несколько в ином виде.
А у нас есть своя! И вправду изначально это был диплом…
А почему не запускать программы в виртуальных машинах? Тогда можно уйти от Windows и писать сервер на нормальных ОС.
Критерий нормальности в студию, пожалуйста.
Операционки от MS у нас в универ поставляются по MSDNAA, так что проблем с лицензионностью нет. При написании уже было ядро тестирующей системы на WinApi (WinKill собственно). Без проблем решаются проблемы масштабирования тестирующих клиентов (пример будет приведён в следующей моей статье), Windows есть на машинах во всех терминалках гарантированно.
Операционки от MS у нас в универ поставляются по MSDNAA, так что проблем с лицензионностью нет. При написании уже было ядро тестирующей системы на WinApi (WinKill собственно). Без проблем решаются проблемы масштабирования тестирующих клиентов (пример будет приведён в следующей моей статье), Windows есть на машинах во всех терминалках гарантированно.
Ну виртуальные машины позволяют не только от lock-in’а на продукцию Microsoft уйти. У них ещё много плюсов, в том числе гарантированная подчистка системы и невероятная защищённость тестирующего ПО от присланной участниками программы (и более простое в использовании).
Скажем так. Защита и сейчас обеспечена хорошая. А система базируется на менее-более старом ядре, которое ещё задолго до 2005 года было написано. В то время виртуализация такой стабильной и надёжной не была. Это сейчас много новых умных технологий и мощностей. Чем руководствовался Женя Четвертаков, когда писал свою систему, я знать не могу.
Написание текущей NSUts проходило же в весьма сжатые сроки. Влад и Саша всё лето дорабатывали ujudge Андрея Таранцова, достигли неплохого прироста в скорости. Но первое же испытание боем (интернет-тур Всесиба) положил его на лопатки. Поэтому ребята форсированно совместили дизайн ujudge с ядром старой системы + починили кое-какие костыли (о которых расскажу попозже). Сейчас же медленно, но верно код обновляется, пишется стабильней и надёжней. На лето тоже планы есть, но они под неразглашением =)
Написание текущей NSUts проходило же в весьма сжатые сроки. Влад и Саша всё лето дорабатывали ujudge Андрея Таранцова, достигли неплохого прироста в скорости. Но первое же испытание боем (интернет-тур Всесиба) положил его на лопатки. Поэтому ребята форсированно совместили дизайн ujudge с ядром старой системы + починили кое-какие костыли (о которых расскажу попозже). Сейчас же медленно, но верно код обновляется, пишется стабильней и надёжней. На лето тоже планы есть, но они под неразглашением =)
Если вы так сразу только о holly war и без юмора, то, например, резонный вопрос, зачем вам GUI и куча других сервисов на тестирующем сервере. Так вы можете сделать очень тонкое ядро с жирными ВМ. Плюс скриптовое и веб ПО для UNIX традиционно лучше, хотя это конечно спорно (но тот же Perl изначально проектировался для UNIX-платформ). Ну и вендор lock-in в Вашем случае думаю тоже не такая идеальная ситуация.
Сразу хочу извиниться за holly war’ную шутку. Основная тема — это виртуальные машины.
Когда сам занимался ACM. Contester — на мой взгляд одна из лучших тестирующих систем на сегодня, можно скачать и потренироваться, если кому интересно.
Хм, раньше почему-то не сталкивался. Спасибо за совет, буду использовать для командных тренировок.
ну, если на то пошло, пропиарю и другие тестирующие системы:
Executor (acmtest.ru) — удобная, легконастраиваемая тестирующая система под Win. из преимуществ: легконастраиваемость, интутивно-понятный интерфейс. из минусов — ограничения: 16 задач, малофункциональность(допустим, нельзя ручную регистрацию участников и т.п.). Насколько я помню, чтобы устраивать командные и личные контесты, нужно качать две разные версии.
PCMS2 — кроссплатформенная тестирующая система, написанная на java. честно говоря, никогда не юзал, но всем известный СПБГУ ИТМО тренируется/устраивает олимпиады, основываясь на ней.
Ejudge(ejudge.ru) — это полнофункциональная тестирующая система под Linux. Очень мощная, стабильная, защищенная тестирующая система.Ее используют МГУ, Бауманка etc. Из плюсов: функциональная, очень защищенная тестирующая система. Поддерживает командные, личные олимпиады и т.д. Из минусов: Linux =) на Win-машинах не работает.
Сам активно использую ejudge
Executor (acmtest.ru) — удобная, легконастраиваемая тестирующая система под Win. из преимуществ: легконастраиваемость, интутивно-понятный интерфейс. из минусов — ограничения: 16 задач, малофункциональность(допустим, нельзя ручную регистрацию участников и т.п.). Насколько я помню, чтобы устраивать командные и личные контесты, нужно качать две разные версии.
PCMS2 — кроссплатформенная тестирующая система, написанная на java. честно говоря, никогда не юзал, но всем известный СПБГУ ИТМО тренируется/устраивает олимпиады, основываясь на ней.
Ejudge(ejudge.ru) — это полнофункциональная тестирующая система под Linux. Очень мощная, стабильная, защищенная тестирующая система.Ее используют МГУ, Бауманка etc. Из плюсов: функциональная, очень защищенная тестирующая система. Поддерживает командные, личные олимпиады и т.д. Из минусов: Linux =) на Win-машинах не работает.
Сам активно использую ejudge
Очень интересно. Нас в свое время на написание своей системы не хватило, использовали питерскую PCMS2, но полноценного контроля над использованием функций WinAPI сделать не смогли). К счастью, олимпиада была чисто студенческая, люди более-менее адекватные, все прошло просто отлично.
В ДВГУ уже давно действует система CATS:
imcs.dvgu.ru/cats
imcs.dvgu.ru/cats
А что-нибудь из описанного выложено в открытый доступ?
Интересуют библиотека для запуска программы и контроля ограничений, а также обрезанные библиотеки для компиляторов.
Интересуют библиотека для запуска программы и контроля ограничений, а также обрезанные библиотеки для компиляторов.
ИМХО, описанные вещи в статье относительно тестирующей системы — это набор костылей и протезов. Не могу оценить, конечно, качество этих протезов, но сдаётся мне, что всё плохо будет если кому-то будет очень скучно и он решит таки убить систему да ещё и с потрохами может её достать. Патчить каждый отдельный компилятор — это ни себе чего задачка.
Так вот, к чему я веду, лучше забудьте об этом пути. Смотрите на современный мир — виртуализация и контейнеризация. У нас в Харькове тоже уже много лет была собственная самописная система только она была более здраво спроектирована, чем описанное решение из статьи, — Web-интерфейс с базой отдельно, а тесты гонялись на других машинах (это и безопаснее, и масштабируется отлично, и просто лучше выглядит с точки зрения дизайна). Ну и да, она очень плотно использовала возможности Linux для всяческих ограничений (время — setitimer, память — ulimit, доступ — chroot, ограничение системных вызовов — патч в ядро). Тем не менее, тестирующая часть из-за непортируемого патча на ядро была слишком сильно завязана на систему и всё равно имела ряд сложностей особенно с добавлением новых языков, так как все их нужно было бы собирать под старую ОС — это опять же связано, как и у авторов статьи с их «возрождённой» тестовой системой, с тем, что тогда альтернатив особо не нашлось.
И вот, наконец, подводя черту, хочу сказать, что мне удалось написать с нуля тестирующую систему, которая максимально использует возможности новых ядер Linux, но без каких-либо патчей, и Docker для управления контейнерами. Все решения запускаются в строго ограниченных контейнерах, из которых (теоретически) выбраться нельзя и всё это дело достаточно производительно работает. При этом каждый компилятор — это просто новый отдельный контейнер, так что добавление компилятора делается крайне просто и при этом все ограничения связанные с безопасностью идут практически из коробки. У нас сейчас уже есть такие языки: C/C++ (GCC), FreePascal, Python 2.7, Python 3.5, Ruby, Go, Haskell, OpenJDK 7, OracleJDK 8, Scala, PHP, C# (mono), Nim, Rust. Вот сегодня успешно провели 30 районных олимпиад одновременно (30 районов Харькова ~= 1000 индивидуальных участников), которые генерировали в среднем 38 решений в минуту (6700 решений за 3 часа). И всё это протестировала одна двухъядерная виртуалка с 1ГБ ОЗУ, а Web UI на PHP с MySQL жили и вовсе на одноядерной VDS (тоже 1ГБ ОЗУ).
Так вот, к чему я веду, лучше забудьте об этом пути. Смотрите на современный мир — виртуализация и контейнеризация. У нас в Харькове тоже уже много лет была собственная самописная система только она была более здраво спроектирована, чем описанное решение из статьи, — Web-интерфейс с базой отдельно, а тесты гонялись на других машинах (это и безопаснее, и масштабируется отлично, и просто лучше выглядит с точки зрения дизайна). Ну и да, она очень плотно использовала возможности Linux для всяческих ограничений (время — setitimer, память — ulimit, доступ — chroot, ограничение системных вызовов — патч в ядро). Тем не менее, тестирующая часть из-за непортируемого патча на ядро была слишком сильно завязана на систему и всё равно имела ряд сложностей особенно с добавлением новых языков, так как все их нужно было бы собирать под старую ОС — это опять же связано, как и у авторов статьи с их «возрождённой» тестовой системой, с тем, что тогда альтернатив особо не нашлось.
И вот, наконец, подводя черту, хочу сказать, что мне удалось написать с нуля тестирующую систему, которая максимально использует возможности новых ядер Linux, но без каких-либо патчей, и Docker для управления контейнерами. Все решения запускаются в строго ограниченных контейнерах, из которых (теоретически) выбраться нельзя и всё это дело достаточно производительно работает. При этом каждый компилятор — это просто новый отдельный контейнер, так что добавление компилятора делается крайне просто и при этом все ограничения связанные с безопасностью идут практически из коробки. У нас сейчас уже есть такие языки: C/C++ (GCC), FreePascal, Python 2.7, Python 3.5, Ruby, Go, Haskell, OpenJDK 7, OracleJDK 8, Scala, PHP, C# (mono), Nim, Rust. Вот сегодня успешно провели 30 районных олимпиад одновременно (30 районов Харькова ~= 1000 индивидуальных участников), которые генерировали в среднем 38 решений в минуту (6700 решений за 3 часа). И всё это протестировала одна двухъядерная виртуалка с 1ГБ ОЗУ, а Web UI на PHP с MySQL жили и вовсе на одноядерной VDS (тоже 1ГБ ОЗУ).
Неплохой стартовый вариант для размышлений, как мне кажется — www.domjudge.org (я только что на неё набрёл, но прочитав документацию увидел там всё то, что мы используем у себя)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Олимпиады по программированию, взгляд из НГУ. Статья 2 — тестирующая система