Правила приема задач и выставления оценок

Терминология

• Обычная задача – задачи с номерами от 1 до 28 включительно
• Задача "proxy" – задачи с номерами 29–31
• Эффективная задача – одна обычная задача или 1/3 задачи "proxy" (т.е. одна задача "proxy" эквивалентна 3 обычным задачам)

Собственно правила

Оценка за практикум выставляется на основе оценки за 4 семестр и количества задач, сданных в 5 семестре. Правила определения оценки таковы:

По итогам практикума, студенты, получившие оценку 5, получают итоговую оценку 5 без сдачи экзамена ("автоматом"). Студенты, получившие за практикум оценку 4, обязаны сдавать экзамен и могут получить по результатам экзамена итоговую оценку от 2 до 5 включительно. Студенты, получившие за практикум оценку 3, обязаны сдавать экзамен и могут получить по результатам экзамена итоговую оценку от 2 до 4 включительно.

Студенты, не получившие оценки 3 за практикум, могут быть допущены к экзамену после собеседования и могут получить оценку не выше 3.

Требования к заданиям

Не допускается использование холостых циклов для синхронизации (если иное явно не оговорено заданием).

Трудновоспроизводимые "глюки" интерпретируются как ошибки соревнования. Обнаружив такое поведение, преподаватель обязан потребовать его устранения. Поскольку для трудновоспроизводимых ошибок безошибочный прогон и даже серия безошибочных прогонов программы не гарантирует отсутствия ошибки, студент должен не только устранить ошибку, но объяснить преподавателю ее причину. В том числе, при внесении исправлений в код программы, студент обязан объяснить, каким образом неисправленный код мог приводить к наблюдавшемуся поведению.

В случае неубедительного объяснения, преподаватель может требовать детализации объяснения вплоть до полного доказательства корректности применяемой схемы синхронизации. Преподаватель также имеет право требовать установки в коде программы дополнительных ожиданий (в том числе на случайные интервалы времени) и, напротив, требовать удаления существующих вызовов ожидания или межпоточной передачи управления.

Требования к заданиям "кэширующий proxy"

Прокси должен удовлетворять следующим требованиям:

1. Должен поддерживаться HTTP 1.0. Прокси должен корректно информировать как клиента, так и сервер об используемой версии протокола
2. Клиенты и серверы HTTP 0.9 (даже если таковые удастся найти) могут не поддерживаться, т.е. прокси может отказываться работать с ними, либо работа с ними может осуществляться в режиме HTTP 1.0. Возникающие при этом проблемы не являются основанием для отказа в приеме задания.
3. Поддержка HTTP 1.1 не обязательна. Поддерживать персистентные соединения 1.1 не требуется.
4. Необходимо поддерживать операцию GET. Поддержка всех остальных операций опциональна; отказ поддерживать остальные операции не является основанием для отказа в приеме задания. Ответы на операции PUT и POST, если сами эти операции будут реализованы, кэшировать не следует.
5. Кэшировать надлежит только ответы типа 200 (нормальная передача страницы). Все остальные ответы следует передавать браузеру без изменений и кэшировать не следует.
6. Кэшировать следует как текстовые, так и бинарные ресурсы, с обязательным сохранением MIME типа ресурса.
7. Кэш хранится в памяти и может полностью теряться при перезапуске прокси.
8. Обработка полей заголовка, управляющих кэшированием, таких, как last modified и pragma no cache, не обязательна. Некорректная работа сайтов с динамическим HTML, обусловленная некорректной обработкой этих параметров, не является основанием для отказа в приеме задания.
9. Поддержка cookies не обязательна. Некорректная работа сайтов, использующих cookie (в том числе и для авторизации) не является основанием для отказа в приеме задания
10. Поддержка любых механизмов авторизации на сайтах не обязательна. Проверяется только корректность анонимного доступа.
11. Допускается как самостоятельная реализация анализа заголовка HTTP, так и использование third-party библиотек парсеров заголовка.
12. Допускается использование языков C и C++
13. Все варианты задания предполагают параллельную обработку запросов, т.е. при тестировании необходимо продемонстрировать возможность открыть несколько клиентских сессий и показать, что ни одна из сессий не ждет завершения операции ни одной из других сессий.
14. Псевдомногопоточная реализация и реализация с пулом потоков не должны иметь ограничений по количеству клиентских сессий (кроме количества дескрипторов открытых файлов). Т.е. обе эти реализации обязаны поддерживать больше сессий, чем имеется потоков в пуле. В этом смысле, псевдомногопоточную реализацию можно рассматривать как вырожденный случай пула потоков.
15. Допускается сдача пула потоков с объемом пула, равным 1, в качестве псевдомногопоточной реализации. В этом случае, преподаватель имеет право потребовать удалить из кода все примитивы pthread (возможно, при помощи конструкции #ifdef) и продемонстрировать сборку и работу приложения без использования libpthread.
16. Простая многопоточная реализация имеет право отвергать или задерживать входящие соединения при невозможности создать новый поток.
17. Если две клиентские сессии скачивают одну и ту же страницу, необходимо, чтобы обе сессии работали с одной и той же записью кэша, понимали, что запись неполная и адекватно реагировали на докачку.
18. Прокси должен корректно обрабатывать сброс клиентских сессий. В том числе, в случае, когда две или более сессий работали с одной записью кэша, после сброса одной из них, остальные сессии должны корректно продолжить докачку страницы.
19. Допускается создание двух нитей на каждое клиентское соединение: "клиентская" нить обрабатывает соединение с клиентом, "серверная" – с сервером. При работе двух клиентских сессий с одной записью кэша при этом следует создавать две клиентские нити, но одну серверную. При передаче клиенту полной записи кэша, серверную нить можно не запускать. В случае пула потоков, допускается разделение пула на два, серверных и клиентских нитей, исполняющих разный код.
20. При сбросе единственной сессии, работавшей с записью кэша, допускается как сброс докачки страницы и уничтожение записи в кэше, так и фоновое продолжение докачки. Преподаватель имеет право потребовать изменения стратегии обработки этой ситуации, т.е. потребовать переделать сброс докачки на ее фоновое продолжение или наоборот (это может быть полезно для проверки корректности управления записями в кэше).
21. Использование явных и неявных холостых циклов, а в особенности холостых циклов с ожиданием, для синхронизации потоков не допускается. Допускается использование стандартных примитивов синхронизации pthread, системных вызовов select и poll и вызовов асинхронного ввода-вывода.
22. В частности, высокая загрузка процессора (по показаниям top) при малой активности соединений интерпретируется как явный или неявный холостой цикл и является основанием для отказа в приеме задания. При обнаружении такого поведения, преподаватель имеет право потребовать доказательства корректности используемой схемы синхронизации.
23. Задержки при открытии сайтов интерпретируются как холостой цикл с ожиданием, и являются основанием для отказа в приеме задания.
24. Вызовы функций sleep, usleep, pause и т.д. в коде приложения интерпретируются как холостой цикл с ожиданием и являются основанием для отказа в приеме задания.
25. Трудновоспроизводимые "глюки" при работе прокси интерпретируются как ошибки соревнования, и являются основанием для отказа в приеме задания. После обнаружения таких "глюков" преподаватель имеет право потребовать доказательства корректности используемой схемы синхронизации.
26. Допускается сдача подсистем прокси в качестве отдельных "простых" заданий. Студент сам должен понять, какие подсистемы могут быть сданы в качестве каких заданий. Необходимо продемонстрировать, что подсистема компилируется (возможно, с #ifdef'ами) и работает в виде самостоятельной программы. Сдача подсистем и целого прокси может производиться в любом порядке.