Оцените этот текст:


Оригинал этого документа расположен на
http://www.star.spb.ru/~dz/articles/diffussion/diffus.html
---------------------------------------------------------------

   

Статья была написана для публикации в журнале, но не была опубликована ввиду недостатка времени для доведения ее до приличествующего состояния. Фактически, не окончена, но уж чем богаты...

Злые языки говорят, что если кусочек золота приложить к кусочку свинца и долго прижимать, то со временем они не то, чтобы полюбят друг друга, но оторвать будет тяжко. На практике с золотом и свинцом такое бывает редко, если не сказать больше. Зато с сетями - на каждом шагу.

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

Позволю себе обратить внимание высказавшегося (который не является членом ФИДО, кстати), что среди пользователей Интернета и ФИДО в Москве добрая треть контингента сидит в обоих сетях сразу, и уж много лет. Да вот и меня взять в пример - обе сети живут на моей машине испокон веку. Стал бы я держать у себя "Интернет для бедных", имея доступ к Интернету "настоящему". Видимо, есть привлекательность и там, и там, не так ли. Мерседес по всем характеристикам лучше Запорожца, что совершенно не мешает Запорожцу существовать и пользоваться некоторым спросом. За все надо платить, и лучшим решением в каждом случае является то, которое предоставляет нужные возможности при минимуме затрат. Очевидно, что на шкале затрат ФИДО занимает неплохие, прямо скажем, позиции, что и делает его иной раз, более удачным выбором, нежели старшего соседа. Это утверждение, как правило, не базируется на реальном сравнении технологий в равных условиях. Если сравнивать передачу почты и новостей в ФИДО и Интернет на одинаковых каналах связи, то порядка 90% разницы в скорости испарится. Интернет, в общем, все равно будет быстрее, но теперь уже придется напрячься, чтобы заметить разницу.

При всем сказанном нужно осознавать, безусловно, что технология ФИДО - безбожно отстала еще до своего рождения, и создана, как правило, программистами-любителями в худшем смысле этого слова. (Подчеркиваю - технология, а не сегодняшние программные продукты.) Нет никакого сомнения в том, что годы ее сосчитаны. Есть сомнение, что годы. Вполне возможно, что десятилетия. Но, все же, что Вам в том? Все мы смертны, и это ведь не повод игнорировать собственное существование. Так же и со старушкой ФИДО. Умрет, когда придет время. Покуда же - исправно служит, и на том спасибо.

Взаимопроникновение сетевых технологий, частенько, ограничивается отношениями "лошадь - наездник". Одна сеть поставляет трафик, другая его тащит. Все (Конечно, изо всех правил есть исключения.) сети сидят на горбу телефонистов, за исключением тех, что висят, зацепившись за спутник. И одновременно норовят проехаться на шее у сети-соседа. Иногда это дешевле, иногда - проще, а бывает, что и выбора нет. Отношения эти бывают как "паразитическими", так и "симбиотическими", Оккам подери эти длинные слова. :-) Оговорюсь сразу, что я не зря взял их, слова, в кавычки. В отличие от живых существ, сети нельзя в полном смысле называть "паразитами" - они не имеют собственной цели существования и служат потребностям человека, потому всякое их совместное использование следует рассматривать как решение некоторой внешней (по отношению к сетям) задачи, которая и определяет конкретный вид взаимодействия данной пары сетей. Не удержусь, кстати, и от пинка в сторону семиуровневой модели 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, и поздравляю. Хорошая штука получилась.

См. также:

Для эффективной работы поверх TCP/IP во всех трех (чистый TCP, Telnet и vmodem) режимах почтовое программное обеспечение требует корректной настройки. Поскольку традиционные протоколы ориентированы на работу через модем, стандартное их поведение при работе через TCP/IP не всегда адекватно. Например, категорически не имеют смысла какие-либо попытки ретрансмиссии блоков - ведь потерь в "линии" быть не может. Могут быть только задержки, зато, временами, длительные - иной раз до нескольких минут. Отсюда рекомендация - если это возможно, установите длительность тайм-аутов протоколов Вашего мейлера на максимум, а длительность фатального тайм-аута (времени, по истечении которого связь разрывается, если данные так и не пошли) - на несколько минут, но лучше - меньше, чем обычный тайм-аут. Это гарантирует отсутствие излишней загрузки каналов и никак не уменьшает производительность. Время ожидания соединения необходимо устанавливать из расчета времени работы DNS (если Вы работаете с именами хостов) плюс несколько секунд на вхождение в режим самого TCP. Странно, кстати, но среди тех, кто пользуется туннелингом преобладает стремление давать свой адрес в цифровой форме, вместо указания имени хоста. Причин тому я, честно сказать, не вижу и, пользуясь случаем, рекомендую по возможности, все же, пользоваться именами. Проблем окружающим будет меньше, если вдруг IP-адреса поменяются.

Как и в случае с обычной телефонией, при работе по IP рекомендуется разносить входные и выходные каналы. Если Вы активно работаете по TCP/IP, хорошо выделить для этой цели не менее двух мейлеров, один из которых большую часть времени ожидает входящего соединения, а другой - в основном "названивает" сам. Речь не идет, конечно, про ifcico и binkd системы, в которых мейлеров запускается произвольное количество по мере необходимости.

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

Увы, беда ФИДОшных почтовых форматов в их упорном следовании ограниченным форматам представления данных. Поля, выделенные под адреса, имена и иные идентификаторы сообщений, имеют, как правило, жесткий, иногда нетекстовый формат и часто - явно заданную длину. Это приводит к неописуемым мучениям при попытке гейтописателя запихнуть письмо интернетовское в формат ФИДО без потерь служебной информации. Применяется масса ухищрений, но главное - при пересылке новостей из Интернета в ФИДО строка Message-ID дополняется префиксом ^ARFC (первый символ - Control-A), и помещается в заголовок ФИДОшного письма. При обратном преобразовании, соответственно, Message-ID восстанавливается из тела письма и помещается в заголовок. Желательно выполнять аналогичные преобразования и над остальными заголовками, но для Message-ID это просто обязательно.

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

Design (if any) and contents of these pages is (c) Dmitry Zavalishin, 1996-1997.

Last-modified: Wed, 03 Sep 1997 06:48:03 GMT
Оцените этот текст: