WikiSort.ru - Не сортированное

Стандартизация

Стандартами, в соответствии с которыми разрабатывается программное обеспечение FTN, служат документы, принимаемые FTSC (Комитет сети Фидо по техническим стандартам), но обязательность соблюдения тех или иных документов в левонетах и Фидо может различаться.

Понятие FTN-системы и адресация в FTN-сетях

Единицей FTN-сети является так называемая система — комплект программ, настроенный на выполнение функций, связанных с пересылкой и обработкой почты и файлов. Человек, поддерживающий систему называется системным оператором (сисопом). У каждой системы есть адрес.

Стандартная схема FTN-адресации описана в FSP-1028. При полной записи адрес выглядит следующим образом: Zone:Net/Node.Point@Domain, где первые четыре поля заполняются номерами соответственно зоны, сети, узла и поинта, а пятое представляет собой буквенное обозначение FTN-сети. Такая полная запись называется 5D-записью. Возможны также сокращённые формы (4D, 3D и 2D) — когда программы могут предположить значения остальных полей.

Системы бывают узловыми и поинтовыми. Различие между ними обычно заключается только в правовом положении в сети (например, в Фидо поинты формально не являются членами сети). На первый взгляд, узловой адрес кажется короче, поскольку не содержит числа после точки, но на самом деле оно присутствует всегда, просто в узловых адресах оно равно нулю и обычно опускается. В 5D-форме узловые адреса также обычно записывают без номера поинта.

Поле «Domain» FTN-адреса (буквенное обозначение сети) не следует путать с доменными именами Интернета (см. FQDN). Так, доменное имя fidonet.org, на котором располагается официальный сайт сети Фидо, не будет являться корректным доменом при использовании в FTN-адресе. Вместо этого следует использовать просто fidonet.

На одном компьютере может быть не одна система. Во-первых, один комплект программ может быть настроен на одновременную работу под несколькими адресами. Тогда говорят об AKA (от also known as) в дополнение к основному адресу системы (первому указанному в конфиге). Во-вторых, может быть несколько комплектов, настроенных на независимую работу. Такое бывает, например, когда у узла выделен технический поинтовый адрес для работы BBS или роботов.

Управление сетью, нодлист и поинтлист

Управление сетью осуществляется должностными лицами — координаторами. В обязанности координаторов входит определение схем маршрутизации и ведение нодлиста. Нодлист — это список узловых систем, состоящих в FTN-сети. Нодлист содержит информацию, необходимую для того, чтобы одна система могла вызвать другую через общедоступную сеть. Поинтовые системы также могут принимать входящие соединения, информация для связи с ними заносится в поинтлист.

Формат нодлиста и его флаги описаны в FTS-5000, FTS-5001 (основные стандарты) и FSP-1035 (DNS Distributed Nodelist). В Фидо допустимые флаги также описываются в эпилоге нодлиста. Формат поинтлиста описан в FTS-5002.

Транспорт и передача

FTN сама по себе не привязана к физическим каналам передачи данных, её суть заключается в офлайновости. Связь происходит по сеансному принципу: в соединении участвуют только две системы, соединение требуется только на короткое время, чтобы принять и передать новые сообщения. Информация распространяется сериями соединений аплинков и даунлинков (uplinks and downlinks). Крупные раздающие узлы получают статус хаба. Постоянные линки защищаются паролем, но если система принимает входящие соединения, то по данным нодлиста или поинтлиста можно переслать ей сообщение или файл напрямую («директом») через непарольную сессию.

Работу с каналом передачи данных в FTN-системе осуществляет мейлер. Первоначально технология создавалась для связи с помощью модема по телефонным линиям, но уже с середины 1990-х годов для обмена почтой между крупными узлами Фидо начинает использоваться Интернет.

Применяемые в настоящее время протоколы передачи данных: binkp (FTS-1026), ifcico (FTS-1024) и fido-over-email (FTS-1025 и др.) для связи через Интернет и EMSI (FSC-0056) для модемного соединения.

Теоретически FTN-сеть может использовать сколько угодно физических сетей одновременно — вопрос только в создании соответствующих мейлеров. Фидошники, говоря о независимости от каналов связи, порой добавляют: «хоть голубиной почтой!» И действительно, бандлы можно кодировать в UUE, распечатывать как текст и отправлять с голубями, а на принимающей стороне распознавать, декодировать и передавать тоссеру — голубь будет «мейлером», а UUE вместе с принтером и сканером — специфическим типом inbound/outbound.

Inbound/Outbound и пакеты с сообщениями

«Инбаунд» и «аутбаунд» — это каталоги с входящими и исходящими данными. Собственная функция мейлера заключается только в том, чтобы принять в инбаунд и передать из аутбаунда — обработку осуществляют другие программы. И приём, и передачу мейлер в большинстве случаев может одинаково осуществлять как на входящих, так и на исходящих сессиях.

Если инбаунд всегда один (однако обычно для парольных и непарольных сессий разные каталоги инбаунда), то аутбаунд бывает разных типов. Известны ArcMail Attach (AMA), Amiga Style Outbound (ASO) и Binkley Style Outbound (BSO).

Для передачи эхопочты используется ArcMail^[3] — пакеты с почтой сжимаются архиватором. Обычно в один аркмейловый бандл помещается много пакетов с сообщениями. Эхопочта передаётся аркмейлом (то есть в сжатом виде) независимо от типа аутбаунда.

Пакеты с нетмейлом обычно передаются в несжатом виде. И для нетмейла, и для эхопочты используется один и тот же формат пакета (в настоящее время — пакет типа 2+, описанный в FSC-0048). Формат, в котором сообщение записывается в пакет, описан в FTS-0001.

Здесь кроется одна терминологическая ловушка. Дело в том, что часто можно слышать, как говорят «непакованный нетмейл». В данном случае имеется в виду нетмейл, не сжатый в аркмейл. Для отправки любое сообщение должно быть упаковано в пакет (файл с расширением pkt), но пакеты с эхопочтой сжимаются и передаются аркмейлом, а пакеты с нетмейлом передаются сами по себе, без сжатия. Есть возможность передавать аркмейлом и нетмейл, но это делается очень редко.

О несжатом («непакованном») нетмейле говорят в связи с почтовым часом. Согласно уставу сети Фидо, узел сети должен быть способен принять в почтовый час незаархивированный нетмейл при непарольной сессии (пункт 2.1.8).

По принятии в инбаунд определённых данных мейлер может запустить программу-обработчик или создать файл-флаг.

Тоссинг эхопочты

Если мейлер принимает аркмейл, то запускается тоссер. Тоссер производит разархивацию аркмейла и распаковку пакетов с сообщениями. При получении сообщения в некоторую эхообласть (кладж AREA) тоссер проверяет статус подписки линков системы на эту область и упаковывает новые сообщения каждому подписанному линку, после чего помещает созданные бандлы в аутбаунд. Для предотвращения повторной отправки сообщения системам, через которые оно уже прошло, существует кладж SEEN-BY. Линки могут управлять своей подпиской на эхоконференции с помощью менеджера подписки (робот Areafix), отправляя ему нетмейлом специальные команды.

Тоссер может сохранять сообщения в базу, с которой локально может работать сисоп с помощью редактора сообщений или удалённо множество пользователей через BBS. Тоссер должен сканировать базы на предмет появления новых сообщений и упаковывать их для отправки линкам системы.

Эхопочта описана в FTS-0004.

Трекинг нетмейла

Если мейлер принимает нетмейл, то для его обработки запускается трекер (хотя функции трекера может выполнять тоссер или сам мейлер). Трекер распаковывает пакет с сообщениями и поступает с ними в соответствии с настройками системы. Прежде всего трекер должен осуществлять роутинг транзитных сообщений — если сообщение адресовано не той системе, которой принадлежит трекер, оно будет упаковано для отправки другому линку в соответствии с правилами маршрутизации. Перед отправкой трекер вставляет в сообщения строку с кладжем Via, содержащую адрес системы, время обработки и идентификатор программы, осуществляющей трекинг (формат этого кладжа описан в FTS-4009). Свою строку с кладжем Via должна вставлять каждая транзитная система, через которую проходит сообщение.

Дополнительно трекер может проверять наличие отправителя и получателя сообщения в нодлисте и поинтлисте (эти документы должны быть актуальны), отправлять уведомления о приёме и обработке сообщения (если отправитель задал соответствующие атрибуты), передавать сообщения роботам (например, факсерверу или менеджеру подписки).

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

Обработка файлэхоконференций

Если мейлер получает файл с расширением tic, то при нормальном функционировании системы-отправителя это означает, что перед этим файлом был отправлен файл, распространяемый по файлэхоконференции. Tic-файл отправляется следом за новым файлом и выполняет по отношению к нему те же функции, что кладжи для сообщений, и для его обработки следует запустить файлэхопроцессор.

Схема работы файлэхопроцессора аналогична работе тоссера. Функционирование файлэхоконференций и формат tic-файла описаны в FSC-0087.

Обработка файловых запросов

Если мейлер получает файл с расширением req, это означает, что системе был направлен файловый запрос (фрек), и следует запустить соответствующий обработчик. Фреки описаны в FSC-0086 и FTS-0006.

Атрибуты сообщений

В атрибутах сообщения задаётся срочность отправки, запросы уведомлений о получении или прочтении и другие параметры. Например, атрибут K/s (от kill/send) говорит о том, что письмо следует удалить из базы после отправки. Сообщение с атрибутом Dir должно быть отправлено напрямую получателю, а не по роутингу. При атрибуте Pvt письмо считается частным. Атрибут Uns устанавливается на новые сообщения и меняется на Snt после отправки. Редактор устанавливает атрибует Rcv на новое полученное сообщение, адресованное пользователю, когда тот его прочитает. Атрибут Loc означает, что сообщение было создано в системе, а не пришло извне.

Пока сообщение не отправлено, атрибуты хранятся в базе сообщений. При передаче атрибуты становятся частью упакованного в пакет сообщения (формат упакованного сообщения описан в FTS-0001). Когда тоссер после распаковки записывает сообщения во временный каталог, атрибуты могут записываться в кладже FLAGS (FSC-0053)^[4].