Злые языки говорят, что если кусочек золота приложить
к кусочку свинца и долго прижимать, то со временем они не то, чтобы полюбят
друг друга, но оторвать будет тяжко. На практике с золотом и свинцом такое
бывает редко, если не сказать больше. Зато с сетями - на каждом шагу.
Противопоставлять Интернет и ФИДО - дело нехитрое, и занимается им довольно людей. Не знаю, из каких соображений, право. Одно замечу - чем дальше человек от пересечения сих образований, тем легче ему скатиться в противопоставление. Вряд ли это странно, но отметить стоит. Я же своей целью ставлю рассказать о взаимодействии этих разных, во многом противоположных, но связанных общей судьбой, крупнейших сетей мира. Однако начну с комментариев на тему противопоставлений. Уж очень они меня смущают, честно сказать. В конференциях, журналах и личных беседах я слышал несколько утверждений на тему "Интернет лучше ФИДО" и "Интернет хуже ФИДО". Вот некоторые.
При всем сказанном нужно осознавать, безусловно, что технология ФИДО
- безбожно отстала еще до своего рождения, и создана, как правило, программистами-любителями
в худшем смысле этого слова. (Подчеркиваю - технология, а не сегодняшние
программные продукты.) Нет никакого сомнения в том, что годы ее сосчитаны.
Есть сомнение, что годы. Вполне возможно, что десятилетия. Но, все же,
что Вам в том? Все мы смертны, и это ведь не повод игнорировать собственное
существование. Так же и со старушкой ФИДО. Умрет, когда придет время. Покуда
же - исправно служит, и на том спасибо.
Взаимопроникновение сетевых технологий, частенько, ограничивается отношениями
"лошадь - наездник". Одна сеть поставляет трафик, другая его тащит. Все
(Конечно, изо всех правил есть исключения.) сети сидят на горбу телефонистов,
за исключением тех, что висят, зацепившись за спутник. И одновременно норовят
проехаться на шее у сети-соседа. Иногда это дешевле, иногда - проще, а
бывает, что и выбора нет. Отношения эти бывают как "паразитическими", так
и "симбиотическими", Оккам подери эти длинные слова. :-) Оговорюсь сразу,
что я не зря взял их, слова, в кавычки. В отличие от живых существ, сети
нельзя в полном смысле называть "паразитами" - они не имеют собственной
цели существования и служат потребностям человека, потому всякое их совместное
использование следует рассматривать как решение некоторой внешней (по отношению
к сетям) задачи, которая и определяет конкретный вид взаимодействия данной
пары сетей. Не удержусь, кстати, и от пинка в сторону семиуровневой модели
OSI. В реальном мире ничто не мешает гонять не уровень по уровню, как предписывает
оная модель, а целую пачку уровней поверх другой пачки, которая может,
в свою очередь, транспортироваться еще одной группой уровней. Пример -
TCP/IP поверх X.25, который упакован во Frame Relay. Если сверху посадить
FTN (Fidonet Technology Network) и транспортировать ей факсы, то результирующий
пирог не вписывается в самый кошмарный сон разработчика семиуровневой модели,
а тем более в саму модель. Ну да я отвлекся, как водится. Ничего не могу
с собой поделать - вокруг этой темы так много интересного... :) Вернемся
же к нашей парочке. Существует три основных вида взаимодействия между FTN
и TCP/IP. Транспорт (туннелинг) фидо-протоколов поверх интернетовских,
транспорт изначально интернетовского информационного потока средствами
и в почтовых форматах ФИДО и, аналогично, транспорт фидошной почты в форматах
RFC-822 (почта) и RFC-1036 (новости). (Я называю их RFC-822 и RFC-1036,
скорее, по традиции - реально следует использовать самые последние версии
соответствующих документов.) Последние два вида включают в себя преобразование
форматов, обычно называемое гейтованием. (От английского gates - ворота.)
Логически мысля, должен быть четвертый вид - туннелинг IP через ФИДО, но
ввиду полной практической непригодности такого фортеля он даже в голову
никому не приходит. :-)
Чего уж греха таить: Интернет - идеальная среда для проброса сквозь
него других сетевых протоколов. Полная 8-ми битная прозрачность TCP-соединений
в сочетании со встроенными средствами контроля переполнения, гарантией
доставки и возможностью давать разным TCP-соединениям разные приоритеты
при роутинге позволяют "туннелируемому" протоколу чувствовать себя вольготно,
но и не создавать излишних проблем соседям. Традиционно применяются два
метода тунеллирования. Первый опирается на голое TCP-соединение (raw TCP
socket), второй - работа поверх протокола Telnet. Практически, особых причин
"прокладывать" между tcp и туннелируемым протоколом еще и Telnet нет. Одной
из предпосылок такого метода явилось появление "виртуального модема" vmodem
для OS/2. Vmodem представляется стандартным коммуникационным портом для
программ операционной системы, и позволяет использовать уже существующее
программное обеспечение, работающее через последовательный порт с модемом,
при работе через Интернет. Одним из вариантов использования vmodem стал
доступ к BBS через Интернет. В этом режиме на виртуальном "последовательном
порту" vmodem, который отображался на telnet-порт машины, запускалась традиционная
BBS, знать ничего не знающая про TCP/IP. Пользователь же мог зайти на эту
BBS обычным telnet-ом, не мудрствуя лукаво. Коль скоро vmodem позволял
связываться через Telnet, его стали использовать и для работы ФИДО-мейлеров
поверх IP. Интересно, что посредством vmodem даже древняя дос-программа,
обращающаяся к регистрам последовательного порта напрямую, может быть "прикручена"
к Интернету. Ведь vmodem, будучи полновесным виртуальным драйвером, создает
у программ полное впечатление наличия в машине самого настоящего последовательного
порта - с адресами, прерываниями и всем, что порту иметь положено.
Иллюстрации:
В процессе эксплуатации vmodem с Telnet в качестве протокола выяснилось, что выбор не особо удачен, и если связываются не человек с BBS, а две коммуникационные программы, то Telnet не столько помогает, сколько мешает. Возникло два решения. Программы, которые не имели собственной поддержки TCP/IP поимели возможность работать через vmodem-же, но использовать новый, специализированный протокол. Вновь же создаваемые фидо-мейлеры обзавелись встроенными средствами общения по TCP/IP. Как правило такие средства использовали чистое TCP-соединение, но иным показалось мало, и в качестве транспорта местами стали пользоваться разновидностью ftp. Опять же, это решение принесло больше проблем, чем решений, и нынче не очень популярно.Кстати, попутно при использовании Telnet для ФИДО выяснилась и еще одна
неудачная сторона такого решения. Дело в том, что Telnet считается протоколом,
используемым для интерактивного доступа человека к ресурсам сетевых компьютеров.
На большинстве роутеров сети этот протокол не без оснований ставят в класс
наиболее высокоприоритетных - для того, чтобы человек, работающий посредством
Telnet не оказался "выбитым из колеи" парой-тройкой потоков ftp или http.
Но если человек при работе через Telnet создает довольно слабую нагрузку
на канал, и повышенный приоритет этого протокола не вредит окружающим,
то почтовые системы столь спокойным нравом не обладают. Они занимаются
передачей файлов, что, в сочетании с высокоприоритетностью Telnet порождает
очень неравномерную загрузку каналов. Практически, при работе ФИДО-мейлеров
на стандартных Telnet-овских портах ФИДОшный трафик выдавливает всех и
вся с канала и занимает в нем столько, сколько может "съесть". Конечно,
особой радости это не вызвало и привело к тому, что telnet-протокол если
и используется для связи, то работает не на обычном 23-ем, а на каком-либо
ином порту. Часто для этого используют порт 60177.
Табличка протоколов
Протокол | Аббревиатура | Стандартный порт | "Подменный" порт |
Vmodem | VMP | 3141 | |
Telnet | TEL | 23 | 60177 |
Raw TCP | IFC* | 60179 | |
Binkd | BND | 24554 |
(* примечание: raw TCP впервые использовался в мейлере
ifcico, отсюда аббревиатура)
В имени этом любой, кто ковырялся в юниксе сразу узреет демоническое. И будет прав. Это - демон ФИДО собственной персоной. :) Программа, специально разработанная для передачи именно фидо-трафика и именно поверх Интернет. Практически, идеальное решение сей проблемы:
По интерфейсу с ФИДО-стороной binkd соответствует, как нетрудно догадаться,
стандартам binkley, что, опять же, идеально для применения на мощных ФИДО-узлах.
Еще одна приятная особенность - binkd поддерживает socks, что в наше параноидально-firewall'ное
время нельзя назвать излишним. Увы, к началу написания этой статьи binkd
еще не был мне известен - это совсем молодой продукт, и появился он у меня
буквально пару дней тому назад. Практического опыта мало, но он целиком
положительный. С чем тезку, автора binkd, и поздравляю. Хорошая штука получилась.
См. также:
Как и в случае с обычной телефонией, при работе по IP рекомендуется
разносить входные и выходные каналы. Если Вы активно работаете по TCP/IP,
хорошо выделить для этой цели не менее двух мейлеров, один из которых большую
часть времени ожидает входящего соединения, а другой - в основном "названивает"
сам. Речь не идет, конечно, про ifcico и binkd системы, в которых мейлеров
запускается произвольное количество по мере необходимости.
Следует четко различать гейтование (преобразование почты и новостей
из формата в формат) в целях межсетевой связи (публичный гейт) и гейтование
в личных целях - для обеспечения доступа группе лиц к сети, непосредственно
им недоступной. Первое имеет относительно равноправный, симметричный характер,
должно обеспечивать хорошую защиту от межсетевых циклов, не иметь завязок
на конкретную точку гейтования (например, не опираться на табличное преобразование
адресов) и быть надежным. Второе, частное - как правило, делает упор на
незаметность гейта со стороны "большой" сети - часто именно с помощью табличного
преобразования адресов. Остановимся на некоторых моментах подробнее.
Предполагалось, что статья
будет дописана, но, увы, времени на это не нашлось, а актуальность, боюсь,
уже не та. Так что продолжения нет, и, видимо, не последует. Впрочем, пишите,
если Вам интересно.