Как работает INN

Основная программа INN это демон innd. innd должен обработать все входящие статьи, сохранить их на локальной машине и передать по запросу. Он запускается при начальной загрузке и выполняется непрерывно как фоновый процесс. Это улучшает производительность, поскольку файлы состояния читаются только однажды при запуске. В зависимости от объема новостей, некоторые файлы типа history (который содержит список всех недавно обработанных статей) могут раздуться на несколько десятков мегабайт.

Другое важное свойство INN: всегда имеется только один экземпляр innd. Это также сильно повышает эффективность потому, что daemon может обрабатывать все статьи без необходимости синхронизации внутренних переменных с другими копиями. Поскольку важно, чтобы входящие новости были обработаны настолько быстро, насколько возможно, недопустимо, чтобы сервер занимался всякими побочными задачами, например, предоставлением доступа клиентам по NNTP или распаковкой пакетов новостей с каналов UUCP. Следовательно, эти задачи вынесены в отдельные программы поддержки.

Сегодня NNTP наиболее общее средство транспортировки статей, и innd непосредственно не поддерживает другие протоколы. Это означает, что innd ждет соединений по TCP (порт 119) и принимает статьи, использующие протокол ihave.

Статьи, прибывающие транспортом, отличным от NNTP, поддержаны косвенно при наличии другого процесса, принимающего статьи и передающего их innd по NNTP. Новости, поступающие по UUCP, например, традиционно обрабатываются программой rnews. Версия rnews из INN распаковывает пакет в случае необходимости, делит его на индивидуальные статьи, а затем передает innd.

Программы работы с новостями (newsreaders) могут доставлять новости, когда пользователь посылает статью. Так как обработка newsreaders заслуживает особого внимания, мы возвратимся к этому немного позже.

При получении статьи innd сначала ищет идентификатор сообщения (message ID) в файле history . Дубликаты статей игнорируются. То же произойдет со старыми статьями или статьями с неправильным заголовком. Если innd находит, что статья приемлема, он рассматривает строку заголовка Newsgroups:, чтобы выяснить, в какой группе эта статья должна быть сохранена. Если группа или группы найдены в файле active, статья записывается на диск. Иначе, она попадает в спецгруппу junk.

Индивидуальные статьи сохраняются ниже каталога /var/spool/news, также называемого news spool. Каждая группа новостей имеет отдельный каталог, в котором каждая статья будет сохранена в отдельном файле. Имена файлов представляют собой последовательные числа. Например, статья в группе comp.risks может иметь имя файла comp/risks/217. Если каталог, в котором требуется сохранить статью не существует, он будет создан автоматически innd.

Кроме сохранения статей Вы можете также передавать их своим подписчикам. Это управляется файлом newsfeeds, который вносит в список всех подписчиков наряду с группами новостей, которые должны быть посланы к ним.

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

Для исходящего трафика NNTP innd может порождать несколько процессов innxmit. Каждой копии этой программы передается имя файла статьи, ее размер и message ID через стандартный ввод. Для исходящего трафика UUCP данные о статье вносятся в файл протокола, обрабатываемый затем программой, которая собирает статьи в пакеты, сжимает их и отсылает по назначению.

Помимо этих двух примеров, имеются другие типы каналов. Они используются, например, при архивировании групп новостей или при подготовке краткого обзора. Информация краткого обзора предназначена, чтобы помочь программам работы с новостями обрабатывать потоки новостей. Раньше такая программа должна была просмотреть все статьи, чтобы получить информацию заголовка, требуемую для создания потоков. Это перегружало сервер новостей, особенно при использовании NNTP. Кроме того, этот подход был очень медленным. Механизм краткого обзора облегчает эту задачу, сохраняя все подходящие заголовки в отдельном файле (.overview) для каждой группы. Эта информация может быть поднята программой чтения новостей из каталога spool или командой XOVER протокола NNTP.