FTN (от FidoNet Technology Network ) — технология организации офлайновой сети, использующаяся в Фидо и .

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

Основные особенности технологии

• Независимость от транспорта. В настоящее время существует ПО для передачи данных по обычной телефонной линии с использованием модема и по Интернету или локальной сети на основе TCP/IP .
• Связь происходит по сеансному принципу (приняли-передали и отключились). FTN — офлайновая технология построения сетей.
• Возможность непосредственной («директной») связи одной системы с любой другой с использованием данных из нодлиста — единого списка узлов сети.
• Наличие программ под популярные ОС и низкая требовательность к аппаратным ресурсам.
• Иерархическая адресация (зоны, сети, узлы и поинты), что предполагает наличие в такой сети административной иерархии (координаторов разных уровней).

Организация

Крупнейшей и наиболее сложно организованной FTN-сетью является сеть Фидо (FidoNet). В ней адресация основана на геополитической принадлежности, а жизнь сети регулируется . обычно значительно проще в организационном плане.

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

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

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

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

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

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

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

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

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

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

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

Передаваемые данные

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

Долгое время в FTN-сетях устанавливались ограничения на размер сообщения (например, правилами эхоконференций), обусловленные несовершенством используемых в то время программ. Постепенно допускался всё больший размер. Последним мыслимым ограничением остался объём письма в 64 КБ , поскольку проприетарная программа , всё ещё остающаяся ^{[ когда? ]} достаточно популярной, не способна обрабатывать больше . Но в настоящее время в Фидо идут оживлённые споры, и всё больше людей отказываются от неё в пользу более современных программ, не имеющих ограничений на размер сообщений.

Существующие редакторы сообщений для FTN не поддерживают Юникод и способы разметки. Это приводит к тому, что через FTN передаётся только простой неформатированный текст в CP866 или другом наборе символов с однобайтным кодированием. FTN позволяет передавать сообщения в любых кодировках, содержащие любые теги разметки, но отсутствуют редакторы, поддерживающие их.

Для задания различных характеристик передаваемого сообщения, в него вставляются специальные управляющие строки — кладжи , схожие с RFC-заголовком сообщений электронной почты . Общее описание кладжей содержится в , но сами кладжи описываются в отдельных документах. Каждое сообщение должно содержать кладж MSGID ( ), кодировка сообщения указывается в кладже CHRS ( ), зашифрованные или подписанные ЭЦП сообщения обозначаются кладжем ENC ( ) и т. д.

Информация, необходимая для распространения файлов по файловым эхоконференциям, содержится в сопроводительном файле, имеющим расширение tic . Распространение файлов этим способом описано в . В настоящее время, когда есть множество более совершенных способов распространения файлов, файловые эхоконференции в Фидо служат прежде всего распространению официальной информации.

Устройство и функционирование FTN-системы

Можно выделить следующие функции, для выполнения которых предназначены соответствующие программы:

• приём и передача почты и файлов другим системам — мейлер ;
• роутинг и паковка нетмейла — ;
• тоссинг эхопочты — эхопроцессор (тоссер);
• работа с файловыми эхоконференциями — (тикер);
• обработка файловых запросов — .

На деле часто функции одной программы выполняет другая. Например, трекингом нетмейла может заниматься тоссер HPT из комплекта , а мейлер T-Mail способен ещё и самостоятельно обрабатывать файловые запросы. В настоящее время большинство систем составляют только мейлер и тоссер.

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

О BBS можно говорить в том случае, если к базе сообщений предоставляется многопользовательский доступ по сети. Пользователи BBS не нуждаются в полном наборе FTN-программ, а обходятся только программой-клиентом. В настоящее время распространены BBS, основанные на протоколах NNTP и HTTP . Пользователи не имеют собственного адреса в сети — они пишут с адреса системы, на которой работает BBS.

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

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

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

Применяемые в настоящее время протоколы передачи данных: binkp ( ), ( ) и ( и др.) для связи через Интернет и ( ) для модемного соединения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные утилиты

Часто дополнительно используются программы для:

• автоматической конфигурации;
• анализа логов и генерации статистики;
• работы с базами сообщений (очистка, сортировка, сжатие, конвертация);
• формирования файловых запросов;
• кодирования/декодирования UUE;
• разовой отправки сообщений или файлов;
• автоматизации работы системы;
• работы с нодлистами (сборка, индексирование).

Примеры FTN-сетей

Существовало большое количество, в основном, некоммерческих сетей, использовавших FTN как технологию. Так, по состоянию на 1994 год в Африке FTN использовали 13 сетей . Одним из наиболее известных проектов, использовавших FTN была международная сеть для детей и родителей K12network .

По состоянию на 2021 год кроме FidoNet множество других FTN-сетей продолжают функционировать и вести обмен сообщениями между узлами и BBS. Это такие сети как, например:

• AdvnetureNet
• AgoraNet
• EggNet
• Pascal-Net
• RetroNet
• STN
• SurvNet
• VirNet
• VKRadio
• (ZX-Net)
• ZyXELNet

Примечания

Ссылки

• (недоступная ссылка)
• (недоступная ссылка) (информация во многом устарела)