Злые языки говорят, что если кусочек золота приложить к кусочку свинца и долго прижимать, то со временем они не то, чтобы полюбят друг друга, но оторвать будет тяжко. На практике с золотом и свинцом такое бывает редко, если не сказать больше. Зато с сетями - на каждом шагу.
Противопоставлять Интернет и ФИДО - дело нехитрое, и занимается им довольно людей. Не знаю, из каких соображений, право. Одно замечу - чем дальше человек от пересечения сих образований, тем легче ему скатиться в противопоставление. Вряд ли это странно, но отметить стоит. Я же своей целью ставлю рассказать о взаимодействии этих разных, во многом противоположных, но связанных общей судьбой, крупнейших сетей мира. Однако начну с комментариев на тему противопоставлений. Уж очень они меня смущают, честно сказать. В конференциях, журналах и личных беседах я слышал несколько утверждений на тему "Интернет лучше ФИДО" и "Интернет хуже ФИДО". Вот некоторые.
При всем сказанном нужно осознавать, безусловно, что технология ФИДО - безбожно отстала еще до своего рождения, и создана, как правило, программистами-любителями в худшем смысле этого слова. (Подчеркиваю - технология, а не сегодняшние программные продукты.) Нет никакого сомнения в том, что годы ее сосчитаны. Есть сомнение, что годы. Вполне возможно, что десятилетия. Но, все же, что Вам в том? Все мы смертны, и это ведь не повод игнорировать собственное существование. Так же и со старушкой ФИДО. Умрет, когда придет время. Покуда же - исправно служит, и на том спасибо.
Взаимопроникновение сетевых технологий, частенько, ограничивается отношениями "лошадь - наездник". Одна сеть поставляет трафик, другая его тащит. Все (Конечно, изо всех правил есть исключения.) сети сидят на горбу телефонистов, за исключением тех, что висят, зацепившись за спутник. И одновременно норовят проехаться на шее у сети-соседа. Иногда это дешевле, иногда - проще, а бывает, что и выбора нет. Отношения эти бывают как "паразитическими", так и "симбиотическими", Оккам подери эти длинные слова. :-) Оговорюсь сразу, что я не зря взял их, слова, в кавычки. В отличие от живых существ, сети нельзя в полном смысле называть "паразитами" - они не имеют собственной цели существования и служат потребностям человека, потому всякое их совместное использование следует рассматривать как решение некоторой внешней (по отношению к сетям) задачи, которая и определяет конкретный вид взаимодействия данной пары сетей. Не удержусь, кстати, и от пинка в сторону семиуровневой модели 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 системы, в которых мейлеров запускается произвольное количество по мере необходимости.
Следует четко различать гейтование (преобразование почты и новостей из формата в формат) в целях межсетевой связи (публичный гейт) и гейтование в личных целях - для обеспечения доступа группе лиц к сети, непосредственно им недоступной. Первое имеет относительно равноправный, симметричный характер, должно обеспечивать хорошую защиту от межсетевых циклов, не иметь завязок на конкретную точку гейтования (например, не опираться на табличное преобразование адресов) и быть надежным. Второе, частное - как правило, делает упор на незаметность гейта со стороны "большой" сети - часто именно с помощью табличного преобразования адресов. Остановимся на некоторых моментах подробнее.
Предполагалось, что статья будет дописана, но, увы, времени на это не нашлось, а актуальность, боюсь, уже не та. Так что продолжения нет, и, видимо, не последует. Впрочем, пишите, если Вам интересно.
Last-modified: Wed, 03 Sep 1997 06:48:03 GMT
