/
Tags: компьютерные технологии
ISBN: 5-89818-043-5
Text
Шабашвили Э. Е.
FidoNet
Руководство
системного оператора
Профессиональная работа
в непрофессиональной сети
Москва, 2000
ББК 32.973.26-018.2
Ш12
Шабашвили Э. Е.
Ш12 FidoNet. Руководство системного оператора: Профессиональная работа
в непрофессиональной сети. - М.: ДМК, 2000. - 736 с.: ил.
ISBN 5-89818-043-5
Предлагаемое издание адресовано прежде всего тем, кто хочет вступить
в компьютерное сообщество FidoNet. С помощью этого настольного руковод-
ства можно настроить компьютер, найти необходимые программы, выбрать
верный тон в общении с другими участниками сети.
Книга полезна и тем, кто уже знаком с FidoNet. Она поможет превра-
тить домашний ПК в станцию FidoNet, правильно выбрать программное
обеспечение.
Подробно рассмотрены организационное устройство сети, ее основные
услуги и правила их использования. Приведено краткое описание действу-
ющих стандартов и предложений FidoNet; рассказано о том, как использу-
ется подключение к Internet для передачи почты. Отдельные главы посвя-
щены протоколам передачи файлов и форматам данных.
Приложения включают перечень эхо-конференций FidoNet, словарь час-
то используемых компьютерных терминов, а также перевод действующего
устава сети (FidoNet Policy 4.07).
ББК 32.973.26-018.2
Все права защищены. Любая часть этой книги не может быть воспроизведена в какой бы то
ни было форме и какими бы то ни было средствами без письменного разрешения владельцев
авторских прав.
Материал, изложенный в данной книге, многократно проверен. Но, поскольку вероятность
технических ошибок все равно существует, издательство не может гарантировать абсолютную
точность и правильность приводимых сведений. В связи с этим издательство не несет ответ-
ственности за возможные ошибки, связанные с использованием книги.
ISBN 5-89818-043-5
© Шабашвили Э. Е., 2000
©ДМК, 2000
Содержание
Предисловие..........................................................19
Введение.............................................................20
Глава I
Неформальное введение в FidoNet 26
Как все начиналось ...............................................27
BBS, Xmodem и FidoNet ......................................... Т1
История FidoNet: сказка о Томе, Джоне и собаке Fido ............30
FidoNet в России ...............................................32
Fido7 - русская сеть ...........................................35
Сеть Fido и.......................................................35
FidoNet и Usenet ...............................................35
FidoNet и Internet .............................................36
FidoNet и общество .............................................36
FidoNet и Международная Ассоциация FidoNet (IFNA) ..............37
FidoNet и ее торговая марка ....................................37
Устройство FidoNet................................................38
fidohist.doc, или «Евангелие от Тома»: история FidoNet-85/l ....39
fidohist.doc, или «Евангелие от Тома II»: история FidoNet-85/2 .41
Командиры FidoNet: административное устройство сети ............41
Адрес FidoNet ..................................................42
Три кита FidoNet: ZMH, nodelist, FidoNews ......................44
Маршрутизация почты (netmail routing) ..........................45
FidoNet Policy, или Как стать узлом ..............................46
История Полиси .................................................46
Политика в FidoNet .............................................48
Можно ли изменить Полиси? ......................................48
Стандарты FidoNet ..............................................49
Технология FTN (FidoNet Technology Network) ..................49
Это может пригодиться ........................................49
«Вредные» советы: устаревшие и курьезные стандарты FTN .......50
FidoNews 15 лет каждую неделю ..................................50
Как опубликовать свою статью в FidoNews ......................51
Что дает FidoNet..............................................53
Передача личной почты .......................................54
Программы подготовки сообщений ..............................55
Атрибуты сообщения FidoNet ..................................55
Передача файлов с использованием личной почты ...............56
Маршрутизация личной почты FidoNet ..........................59
Кто и что вам должен ........................................63
Эхо-конференции FidoNet .....................................64
Какие бывают эхо-конференции ................................69
«Тусовки» виртуального мира .................................72
Файл-эхи ....................................................77
FAQ-серверы .................................................80
Подключаемся к FidoNet ........................................80
Модем и телефон .............................................82
Операционная система ........................................87
Как...? .....................................................92
Программы FidoNet: тысяча маленьких медвежат ................97
FidoNet over IP: сказка нового времени ......................102
Судьба новых идей в FidoNet .................................1 10
FidoNet сегодня: антропологические заметки ..................1 18
Куда идет FidoNet............................................123
Заключение....................................................126
Глава II
Введение в FidoNet...................................128
О чем эта глава....................................128
Язык FidoNet .......................................128
Некоммерческий характер сети .......................129
Структура и управление ............................129
Зона .............................................129
Регион ...........................................130
Сеть .......................................................13]
Узел .......................................................131
Пойнт .......................................................132
Форматадреса..................................................132
Зарезервированные адреса ...................................134
Координирование...............................................134
Деятельность системного оператора ..........................137
Деятельность сетевого координатора .........................137
Деятельность регионального координатора ....................139
Деятельность координатора зоны .............................140
Деятельность международного координатора ...................140
Принципы разрешения конфликтов .............................141
Некорректное поведение и чрезмерно некорректное поведение ..141
Процедура подачи жалобы ....................................141
Стандарты FidoNet.............................................142
FidoNet Technical Standards Committee ......................142
Структура и правила работы FTSC ............................143
Административные документы FTSC ............................144
Список узлов сети ............................................145
Стандарты, описывающие формат нодлиста .....................146
Структура и формат файла нодлиста (по FTS-0005,
FTS-5000 и FTS-5001) .......................................146
Стандартные поля строк данных нодлиста .....................148
Соблюдение зонального почтового часа на востоке России и флаг #пп .... 153
Примеры нодлистовых строк ..................................153
Система распространения нодлиста ...........................155
Пользовательские флаги в нодлисте ..........................156
Личная почта FidoNet (netmail)................................160
Финансирование передачи сообщений. Костшаринг ..............161
Зональные шлюзы (ZoneGates) ................................161
Маршрутизация почты по нодлисту ............................162
Системы автоматической маршрутизации почты в FidoNet........163
Стандарты FidoNet о представлении и передаче нетмейла ......165
Эхо-почта (echo-mail) ........................................168
Правила обращения с эхо-почтой ..............................169
Координация эхо-почты и эхо-бекбон .........................170
Стандарты эхо-почты ........................................170
Распространение файлов по сети ...............................171
Открытость и секретность в FidoNet............................173
Парольная защита соединения ..........................173
Шифрованная почта (encrypted mail) в FidoNet и PGP ...1 74
Заключение .............................................175
Глава III
Протоколы передачи файлов 176
Xmodem ................................................177
Протокол со стороны приемника .......................178
Протокол со стороны передатчика .....................178
Протокол Kermit .......................................179
Zmodem ................................................180
Быстродействие .................................... 181
Надежность ..........................................181
Простота реализации .................................182
Совместимость ........................................182
Протокол Hydra.........................................182
Протокол Binkp ........................................184
Описание протокола Binkp ............................185
Заключение..............................................188
Глава IV
Форматы данных FidoNet....................................189
Формат MSG ~ структура хранения писем FidoNet
в файлах *.msg ........................................189
Дата и время .........................................192
Атрибуты письма .....................................193
Текст письма и служебные строки ......................194
Спецификация файла ..................................195
База писем формата MSG ...............................196
Текстовый или бинарный? .............................196
Формат РКТ - структура временного хранения писем FidoNet
в файлах *.pkt ........................................196
Почтовая очередь и выходной директорий системы FidoNet
(Outbound directory) ..................................202
Архивированная почта (Arcmail) .................................203
Почтовый директорий типа Arcmail-Attach (АМА outbound) .........204
Достоинства и недостатки режима АМА ............................205
Почтовый директорий типа Binkley Term (Binkley-style outbound) .205
Преимущества и недостатки BSO ..................................209
Другие разновидности почтового аутбаунда .......................210
Заключение........................................................211
Глава V
Почтовая сессия
между двумя системами FidoNet.......................................212
Уровневая модель FidoNet .........................................213
Диагностика почтовой сессии FidoNet ..............................215
Xmodem в почтовой сессии FTS-0001 ................................217
Блоки данных Xmodem-Telink......................................219
Протокол передачи: конечный автомат Xmodem/Telink ..............221
FTS-0007 и протокол SeaLink.......................................223
Запрос файла (File-Request) в почтовой сессии FidoNet.............224
Формат файлового запроса WaZOO .................................225
Формат файлового запроса Bark ..................................226
Почтовые сессии YOOHOO и EMSI ....................................228
Протокол почтовой сессии YOOHOO ................................228
Протокол почтовой сессии EMSI/IEMSI ..............................233
Сообщения EMSI .................................................234
Основные этапы установления соединения EMSI ....................235
Сообщения EMSI ............................................... 237
Структура пакета EMSI_DAT.......................................239
Интерактивный стандарт EMSI (IEMSI) ............................241
Заключение........................................................242
Глава VI
Аппаратное
и программное обеспечение FidoNet...................................243
Требования к компьютеру...........................................243
Быстродействие ................................................ 243
Память ........................................................ 244
Жесткий диск .................................................245
Коммуникационный порт ........................................245
Модем ........................................................253
Знакомство с модемом .........................................254
Программы узла FidoNet..........................................264
Коммуникационный драйвер FOSSIL ..............................264
Примеры реализации и использования драйвера FOSSIL ...........265
Размещение файлов Fido-системы и потоки данных ...............278
Основной набор программ узла FidoNet .........................281
Заключение......................................................288
Глава VII
Обработка и передача по сети
ЛИЧНОЙ ПОЧТЫ .....................................................289
Вводные замечания ..............................................290
Атрибуты почтовых сообщений ..................................290
Служебные строки сообщений (kludge lines) ....................292
Почтовые программы FidoNet .....................................294
Структура и состав типичной почтовой программы FidoNet .......295
Установка переменной TZ (зона локального времени) ........310
Маршрутизация почты и программы-упаковщики ...............311
Правила маршрутизации для АМА-мейлеров .......................314
Упаковка почты для Binkley-style мейлеров ....................324
Упаковка почты с использованием эхо-процессора ...............329
Создание конфигурационного файла маршрутизации
с использованием программы Safrouter .........................332
Использование нодлиста .......................................332
Примеры настройки почтовых программ ..........................342
Дополнительная пост-обработка личной почты .....................358
Распаковка нетмейла ..........................................359
Обработка почты с использованием нетмейл-трекеров ............361
Координация доставки личной почты ..............................369
Возможные трудности в доставке почты FidoNet и их устранение .370
Заключение .....................................................376
Глава VIII
Обработка и передача
по сети эхо-конференций FidoNet.............................377
Основные понятия ........................................377
Алгоритм работы эхо-системы ...........................378
Формат эхо-письма .....................................378
Служебные строки сообщений эхо-почты ..................380
Форматы баз эхо-почты .................................383
Интерфейс пользователя ................................385
Настройка эхо-процессора ................................385
Системная информация и определение директориев ........386
Общие параметры эхо-процессора ........................392
База идентификаторов сообщений (дупобаза) .............392
Уровень секретности при тоссинге ......................393
Правила упаковки баз сообщений ........................395
Настройка архиваторов .................................396
Подсистема описания эхо-конференций ...................399
Подсистема описания линков ............................403
Подписываемся на эхи ..................................406
Координация распространения эхо-почты ...................408
Добавление конференции на бекбон и удаление с него .....411
Порядок разрешения конфликтов ..........................411
Схемы технической реализации эхо-бекбона ..............412
Бекбон и лонглинки ....................................414
Возможные трудности в доставке эхо-почты FidoNet
и их устранение..........................................415
Заключение...............................................416
Глава IX
Обработка и передача файлов по сети 417
Основные понятия ........................................417
Стандарты на пересылку файлов по FidoNet ..............418
Терминология ..........................................418
Локальная файловая база ...............................419
Формат Т1С-файла ......................................419
Правила передачи файлов при транспорте файл-эх ...............420
Функции файл-эхопроцессора ...................................423
Настройка и использование файл-эхопроцессора ...................423
Системная информация и определение директориев ...............424
Общие параметры эхо-процессора ...............................424
Группы файл-эх................................................425
Подсистема описания файл-эх...................................426
Магические имена файлов ......................................430
Подсистема описания линков ...................................430
Подписываемся на файл-эхи ....................................434
«Плохие» файлы и их Т1С-файлы ................................436
Использование шаблонов писем .................................437
Запуск процессора файл-эх ....................................438
Процессор файловых запросов ....................................442
Составление файл-листа..........................................442
Заключение .....................................................444
Глава X
Почтовые шлюзы FidoNet.............................................445
Шлюзы между FidoNet и Internet .................................445
История возникновения шлюзов с UseNet (Internet) .............446
Система распознавания имен Internet (Domain Name System) .....447
FidoNet.org: Fido из Internet ................................449
Правила использования почтовых шлюзов ........................451
Требования, предъявляемые к почтовым шлюзам ..................453
Примеры писем, прошедших почтовый шлюз Fido-Internet .........454
Возможные ошибки и диагностика работоспособности шлюза .......457
Проблемы с чтением русских текстов ...........................461
Стандарты на шлюзование почты между FidoNet и Internet .......466
Шлюзы между эхо-почтой FidoNet и news-конференциями Internet .466
Популярные программы ...........................................469
Шлюзы UUCP (UU2, UFGATE, LuckyGate) ..........................469
Шлюзы NNTP (Ifgate и FidoGate) ...............................472
Шлюзы между FidoNet и другими FTN-сетями .......................475
Заключение .....................................................476
Глава XI
Передача почты и файлов FidoNet
с помощью Internet...............................................477
Основные понятия ..............................................477
Адреса TCP/IP ...............................................478
Порты и протокол TCP ........................................478
Протоколы ...................................................479
Нодлист и Fido-over-IP ........................................480
Системы передачи почты Fido через Internet ....................480
Туннелирование FidoNet через электронную почту и FTP ..........482
Программа TransX ............................................483
Программа Internet REX (IRex) ...............................484
Строки-флаги для обозначения в нодлисте E-mail-и FTP-систем .485
Соединение Fido-программ через Internet
с использованием протокола TCP/IP .............................485
Использование драйвера Vmodem ...............................486
Программа Ifcico/IP .........................................489
Программа T-Mail для сетей TCP/IP ...........................490
От Vmodem, T-Mail/IP и Ifcico - к Binkp! ....................493
Заключение ....................................................505
Глава XII
Интерфейс пользователя:
редакторы Fido-почты.............................................506
Основные понятия ........................................506
Типы почтовых областей (Message Areas) ................507
Режимы работы .........................................510
Примеры использования ...................................511
Навигация по базе сообщений ...........................51 1
Навигация по списку писем в выбранной области .........514
Навигация по цепочкам дискуссий .......................51 6
Операции с письмами ...................................518
Режим ввода письма ....................................521
Просмотр нодлиста и компилятор нодлиста .....................533
Специальные возможности .....................................535
Конфигурирование FTN-редакторов ...............................536
Другие известные FTN-редакторы ..............................537
Заключение ....................................................539
Эпилог ........................................................540
Благодарности..................................................540
Приложение I
Справочник стандартов
и предложений FidoNet............................................541
Приложение II
Полиси FidoNet...................................................547
FidoNet Полиси, версия 4.07 ...................................547
1. Общая часть.................................................547
1.0. Язык....................................................547
1.1. Введение ...............................................548
1.2. Организационная структура ..............................548
1.3. Определения .......................................... 550
2. Процедуры сисопа ...........................................552
2.1. Общая часть ............................................552
2.2. Как стать узлом сети ...................................556
2.3. Если вы прекращаете работу .............................557
2.4. Как образовать сеть ....................................558
3. Общие обязанности для всех координаторов....................558
3.1. Распространение файлов изменений к нодлисту и FidoNews .558
3.2. Обработка изменений в нодлисте и передача их
вышестоящим уровням .................................559
3.3. Доступность Полиси .....................................559
3.4. Минимизация числа занимаемых постов ....................559
3.5. Принадлежность к управляемой области ...................559
3.6. Поощрение вступления в FidoNet новых сисопов ...........559
3.7. Традиции и прецеденты ..................................560
3.8. Техническое обеспечение .............................. 560
4. Деятельность сетевого координатора .........................560
4.1. Обязанности ............................................560
4.2. Маршрутизация входящей почты ...........................560
4.3. Присвоение номеров узлам сети ..........................561
4.4. Поддержка нодлиста .....................................561
4.5. Распространение Полиси, нодлистов и FidoNews ...........562
5. Деятельность регионального координатора ....................562
5.1. Обязанности ............................................562
5.2. Присвоение номеров узлам в регионе .....................562
5.3. Поощрение образования и роста сетей ....................563
5.4. Присвоение номеров сетей ...............................563
5.5. Поддержка нодлиста .....................................563
5.6. Географические исключения ..............................564
5.7. Наблюдение за функционированием сети ...................564
5.8. Распространение Полиси, нодлиста и FidoNews ............564
6. Деятельность координатора зоны .............................565
6.1. Общие задачи ...........................................565
6.2. Выборы координатора зоны ...............................565
7. Деятельность международного координатора ...................565
7.1. Общие задачи ...........................................565
7.2. Выборы международного координатора .....................566
8. Референдум .................................................566
8.1. Начало референдума .....................................566
8.2. Объявление о референдуме и обнародование результатов ...566
8.3. Право голоса ...........................................566
8.4. Механизм голосования ...................................567
8.5. Голосование Полиси как единого документа ...............567
8.6. Результаты голосования .................................567
8.7. Отстранение от должности (импичмент) координатора зоны .567
9. Разрешение конфликтов ......................................568
9.1. Общая часть ............................................568
9.2. Конфликты между сисопами ...............................569
9.3. Конфликты с сетевым координатором ......................569
9.4. Конфликты с другими координаторами .....................569
9.5. Апелляционный процесс ..................................570
9.6. Ограничения ............................................570
9.7. Время рассмотрения жалобы ..............................570
9.8. Возвращение в сеть .....................................571
9.9. Эхо-почта ..............................................571
9.10. Поучительные истории ..................................571
1 0. Приложения ..................................... 571
1 0.1. Общие замечания ...............................571
10.2 . Время ZMH .....................................572
10.3 . Поучительные истории ..........................572
10.4 . Благодарности и пр.............................574
Приложение III
Справочник сокращений
и аббревиатур............................................575
Приложение IV
Английский и русский жаргон,
используемый в переписке FidoNet.........................578
Часть I. Грамматика и фонетика.........................578
Часть II. Особенности синтаксиса ......................579
Часть III. Наиболее употребительные
аббревиатуры (сокращения)..............................580
Часть IV. Толковый словарь Fido-диалекта...............581
Приложение V
Справочник русскоязычных конференций
FidoNet..................................................611
Транспорт: авиация, автомобили, мотоциклы,
другие виды ...........................................613
Авторский: эхи авторов программ, поддержки Fido-софта .613
Армия, милиция, оружие, охранные системы, спецтехника..616
BBS и FidoNet: Fido-жизнь,
альтернативные и локальные сети, АТС ..................616
Волшебство, магия, фокусы .............................617
Еда, напитки: обсуждение вопросов,
связанных с различными продуктами потребления .........618
Природа, животный и растительный мир ...................618
Жизнь человека (что такое счастье,
как справляться с кризисами; другие ее проявления) .....619
Игровой мир: компьютерные, некомпьютерные игры,
эхи знатоков, интеллектуалов ...........................619
Internet и сетевые технологии ..........................622
Клубный: разговоры обо всем,
клубы по интересам, любовь, одиночество.................623
Коммерческий: эхи объявлений и обмена, халява ..........624
Локалки: Москва, районы Москвы, Подмосковье,
студенты, вузы, школы ..................................626
Музыкальный: музыкальные направления, фэн-клубы,
музыкальное творчество..................................627
Научный: научные, околонаучные, специализированные эхи .630
Новости, обсуждение новостей ...........................631
Операционные системы, оболочки, фирмы - создатели ОС..632
Предпринимательство и право ............................633
Программирование .......................................634
Путешествия, страноведение, туризм .....................637
Работа .................................................637
Религии, культы, атеизм,
мировоззренческие вопросы, философские установки .......638
Секс во всех проявлениях, антисекс .....................639
Семья, дети, дом, образование, школа....................639
Социум: общество, политика .............................640
Спорт ..................................................640
Средства массовой информации, мода, театры, выставки,
фотография, тату........................................642
Творчество, литература, искусство, культура ...643
Технический: эхи о функционировании сети ......645
Технологический (изделия, права потребителя) ..646
Эмиграция, иммиграция,
проживание в нетрадиционной обстановке ........649
Юмор ..........................................649
Языковой: иностранные языки, лингвистика ......650
Приложение VI
Справочник популярных международных
эхо-конференций FidoNet 651
Приложение VII
Справочник географического распределения
адресов FidoNet..................................675
Приложение VIII
Справочник Web-серверов,
посвященных FidoNet..............................696
Web-серверы, посвященные FidoNet ..............697
Общие для всей FidoNet Web-ресурсы ...........697
Ресурсы FidoNet по зонам, регионам и сетям ...697
Первая зона ..................................697
Вторая зона ..................................697
Странички регионов второй зоны ...............697
Регион 50 (Россия) ...........................698
Общие ресурсы ................................698
Местные сети региона 50 второй зоны ..........698
Третья зона ..................................699
Четвертая зона ...............................699
Шестая зона ..................................699
Приложение IX
Правила выборов сетевых координаторов
региона 50 сети FidoNet...................................700
FidoNet Zone 2 document NC_ELECT.Z2 ...................700
Введение ............................................ 700
1. Проводящий выборы (returning officer) .............700
2. Кандидаты .........................................701
3. Сроки выборов .....................................702
4. Голосование .......................................702
5. Определение победителя ............................703
6. Результаты ........................................703
7. Срок полномочий ...................................704
8. Нехватка кандидатов ...............................704
Приложение X
Эхо-Полиси региона 50 второй зоны FidoNet.................705
1. Введение ...........................................705
1.1. Цель данного документа ........................ 705
1.2. Определения .....................................705
1.3. Региональный бекбон .............................706
2. Функционирование на региональном уровне ............706
2.1. Обязанности регионального эхо-координатора .......706
2.2. Выборы регионального координатора ...............707
2.3. Региональные хабы ...............................707
2.4. Взаимодействие с координаторами FidoNet .........708
3. Модераторы конференций .............................708
3.1. Признание модераторов ...........................708
3.2. Обязанности модераторов .........................708
4. Другие функциональные процедуры ....................709
4.1. Технические области .............................709
4.2. Технические стандарты сообщений .................709
4.3. Добавление конференций на бекбон ................709
4.4. Удаление конференций с бекбона ..................710
4.5. Внешние и паритетные конференции ................710
4.6. Финансовые взаимоотношения ................71 1
4.7. Конференции вне регионального бекбона .....71 1
5. Порядок разрешения конфликтов ...............711
6. Порядок принятия и изменения Эхо-Полиси .....712
6.1. Принятие Эхо-Полиси и переходный период .712
6.2. Внесение изменений в Эхо-Полиси .........713
Приложение XI
Справочник по программному обеспечению
FidoNet...........................................714
Обозначения ....................................714
Библиография .....................................720
Предисловие
О параллельных мирах принято говорить лишь в фантастике. Попробуйте всерьез
сказать кому-либо, что рядом с нашим существует другой мир, почти невидимый,
но вездесущий. Со своими законами и темпом жизни, со своими героями и отще-
пенцами, со своими войнами и альянсами... Добавьте, что вы сам принадлежите это-
му миру, равно как и нашему, и ведете двойную жизнь. Что не только вы, но и мно-
гие другие жители города принадлежат двум мирам. Теперь заприте дверь и не
пускайте добрых людей со смирительными рубашками. А собеседнику покажите
эту книгу - книгу о мире по имени ФИДО.
Про компьютерную сеть по имени Internet знают все, про ФИДО - весьма не-
многие. Хотя возраст у них почти одинаковый. Это несправедливо, но правильно.
Да-да, именно так - несправедливо, но правильно. ФИДО - клуб, охраняющий
собственные границы. Попасть в него может любой, но лишь приняв его правила,
согласившись соблюдать писаные и устные законы жизни. О них - эта книга.
Internet - это доступ ко всему на свете за $50 в месяц. Увы, не всякому по си-
лам выложить эти деньги. Чтобы добраться до ФИДО, не нужно денег. Компью-
тер и модем откроют мир не менее интересный, чем мир Internet. В чем-то даже
более интересный. В чем - расскажет эта книга.
Став членом ФИДО, многие задумают приложить руку к тому, чтобы эта сеть
работала быстрее, лучше, удобнее. Кто-то откроет мощный узел ФИДО, кто-то на-
пишет удобную программу. ФИДО строилось именно таким образом. Словно му-
равейник - небольшими усилиями всех «жителей» сети. Однако мало хотеть стро-
ить ФИДО - нужно уметь это делать. И тут книга, которую вы держите в руках,
тоже будет подспорьем.
Если честно, я восхищен ей. Собрать все это воедино - огромный труд. Как
жаль, что этой книги не было, когда я приходил в ФИДО. Столь многое было бы
проще...
Дмитрий Завалишин, dz, житель двух параллельных миров. И еще одного пер-
пендикулярного.
dz@dz.ru, 2:5020/32
Моему первому адресу 2:5050/50©fidonet посвящается...
Введение
FidoNet - это любительская сеть домашних персональных компьютеров. Каждый,
имеющий компьютер, модем и телефонный номер, может бесплатно подключить-
ся к ней, необходимо только самостоятельно разобраться с программным обеспе-
чением и соблюдать правила поведения в сети, суммированные в ее уставе
(FidoNet Policy).
FidoNet предоставляет доступ к электронной почте, телеконференциям и файло-
вым архивам. Это известная всемирная сеть, имеющая почтовые шлюзы с Internet.
Иными словами, подключаясь к FidoNet, вы получаете адрес электронной почты
Internet.
Системы FidoNet есть почти в каждом крупном городе России и стран СНГ,
городах Западной и Восточной Европы, обеих Америк, Африки, Азии, Австралии
и Новой Зеландии. Десятки тысяч систем подключены к сети, множество систем-
ных операторов ежедневно общаются в тысячах телеконференций, охватывающих
все мыслимые и немыслимые темы.
И все это рядом с нами, мой читатель, все эти россыпи прямо у нас под ногами.
Эта книга поможет вам присоединиться к FidoNet, стать частью всемирного
компьютерного братства. Прочитав ее, вы познакомитесь со множеством вещей,
которые, возможно, никогда не понадобятся в обыденной жизни, но тем не менее
ясное представление о них совершенно необходимо для существования в FidoNet.
К тому же это не только знания, касающиеся особенностей настройки компьюте-
ра, модема и программного обеспечения, но и правила поведения, обычаи и жар-
гон, история возникновения и развития сети. При этом неважно, будете ли вы
активно участвовать в жизни FidoNet, или же станете сторонним свидетелем ее
дальнейшего развития.
В частности, вы узнаете:
□ как устроена FidoNet;
□ как она работает;
□ как правильно выбрать программное обеспечение для вашего узла FidoNet;
□ как планировать и настраивать FidoNet-систему;
□ как администрировать систему FidoNet;
□ как использовать FidoNet совместно с Internet, и многое другое.
Кому адресована эта книга
Впервые столкнувшись с FidoNet, пользователь испытывает трудности, связан-
ные прежде всего с нехваткой информации. Куцые описания множества разнород-
ных программ, незнакомая терминология и жаргон, неизвестно откуда взявшиеся
правила поведения, которые опытные участники FidoNet считают само собой ра-
зумеющимися, - все это затрудняет освоение, по сути, очень простой и богатой по
возможностям сети.
Книг, посвященных FidoNet, очень мало, особенно на русском языке, а те, что
есть, как правило, поверхностны и конспективны, и сеть порой рассматривается
в них как дополнительный BBS-сервис. Когда-то так оно и было, но сейчас все
иначе.
Итак, во-первых, это книга для тех, кто испытывает желание подключиться к сети.
Она надолго станет вашим настольным руководством по FidoNet, поможет на-
строить компьютер, найти необходимые программы, выбрать верный тон в обще-
нии с другими участниками сети.
Во-вторых, книга окажется небесполезной и тем, кто уже знаком с FidoNet.
Возможно, вам захочется изменить настройку своей системы, заменить програм-
мы обработки почты, написать свою Fido-программу или использовать Internet
для передачи Fido-почты - автор постарался охватить все возможные аспекты
FTN-технологии и варианты настройки Fido-системы.
И, наконец, если даже в ваши планы не входит стать в ближайшее время участ-
ником FidoNet, но вы тем не менее хотите знать как можно больше об этом инте-
реснейшем компьютерном сообществе, книга предоставит вам и эту возможность.
Что требуется от читателя
Любая книга - это дорога, которую автор и читатель проходят рука об руку. Для
того, чтобы в полной мере воспринять изложенный в книге материал, специаль-
ной подготовки не требуется, однако определенная степень знакомства с компью-
тером все же предполагается. Например, здесь не объясняется, что такое жесткий
диск, рабочий стол (desktop), дисковый кэш (disk cache), команда dir или такое
понятие как «многозадачность», хотя подобные термины и понятия используют-
ся. Если что-то покажется вам незнакомым и непонятным, то объяснение следует
искать вне рамок этой книги - в компьютерной литературе и на страницах под-
сказок вашей операционной системы.
Кроме того, мой читатель - это, безусловно, человек с компьютером и модемом.
Особых требований к мощности компьютера, установленной на нем операцион-
ной системе и скоростным характеристикам модема при этом не предъявляется.
Книга поможет вам «собрать» Fido-систему и на IBM PC AT 286 с 40-мегабайт-
ным жестким диском и модемом на 2400, оснащенным реликтом - операционной
системой MS DOS 3.3, и на современном компьютере с модемом V34+ и установ-
ленной многозадачной операционной системой вроде Windows 95/98, Windows NT,
OS/2 Warp или Linux.
Большим подспорьем при изучении книги и подключении к FidoNet будет до-
ступ к Internet on-line. Почти все упомянутые программы и справочные сведения
о FidoNet можно найти в Internet по адресам, указанным в приложении 8. Боль-
шая часть ссылок на текстовые источники, приведенных в конце книги, содержит
материалы, опубликованные в Internet, они снабжены дополнительными указа-
ниями на адреса, с которых эти тексты могут быть получены.
Знание английского языка желательно, особенно если вы намерены участвовать
в международных конференциях или выполнять функции координатора сети. Дело
в том, что английский язык - это официальный язык FidoNet. Все официальные
документы FidoNet выпускаются на этом языке и его незнание - существенное пре-
пятствие в освоении реалий сети. Отчасти автор попытался разрешить эту пробле-
му, переведя некоторые наиболее важные материалы, а также по возможности рас-
шифровав большую часть постоянно используемой англоязычной терминологии.
Понятно, что все перевести невозможно - для этого потребовалось бы издать от-
дельную большую книгу. Если же вы испытываете стойкое отвращение к изучению
английского языка и совершенно с ним незнакомы, не надо отчаиваться - руковод-
ствуясь указаниями, вы сможете использовать только русскоязычное программное
обеспечение, а общение в телеконференциях внутри России ведется, как правило,
на русском языке.
Терминология
В книге приведены термины и понятия, непосредственно связанные с технологи-
ей FidoNet. Как правило, используется исходная английская нотация или русская
калька с нее (netmail - «нетмейл»), поскольку, подключившись к сети, вы столк-
нетесь по преимуществу с таким написанием. Исключение делается для терми-
нов, имеющих устоявшиеся русские аналоги (например, message - «письмо» или
«сообщение», хотя можно услышать и «мессага»).
В случае если перевод неточен, предпочтение отдается английскому варианту.
Когда возникают затруднения подобного рода, обращайтесь к приложению 3
и приложению 4.
Отдельной проблемой является жаргон FidoNet. Отчасти это английские со-
кращения типа «1МН0» (от англ, in my humble opinion - «по моему скромному
мнению»), общеупотребительные в англоязычной электронной переписке. От-
части русские неологизмы («глюк» - программная ошибка, «нетмыл» - от англ,
netmail - личная почта), часть из которых представляет собой искаженные каль-
ки с английских оригиналов. Подключившись к сети, вы непременно столкнетесь
с активным использованием вашими корреспондентами этой терминологии. Ни-
кто не принуждает использовать ее (это дело вкуса), но понимать подобные вар-
варские словечки необходимо. В этом случае пригодится словарь, приведенный
в приложении 4.
О чем эта книга
Подготавливая издание, посвященное Fido, автор пытался создать исчерпыва-
ющее руководство, в котором подробно излагаются как технические моменты
(настройка и конфигурация программного обеспечения, выбор компьютера, мо-
дема и т.д.), так и основы административного устройства FidoNet, ее история
и правила общения, ее традиции. При этом акцент сделан на особенностях, при-
сущих России, Украине и некоторым другим странам бывшего СССР, в настоя-
щее время образующих в FidoNet 45, 46, 47, 49, 50 и 51-й регионы.
Книга состоит из двух частей. Первая часть включает первую главу книги. Цель
этой в высшей степени неформальной главы - дать необходимый набор сведений
о FidoNet до того, как вы начнете по-настоящему осваивать сеть. Этот материал
важен для первоначального ознакомления, даже если вы не собираетесь немед-
ленно подключаться к сети. Здесь кратко описана история создания сети, ее
современное «политическое устройство», основные услуги, предоставляемые
FidoNet, правила подключения, особенности программного обеспечения и мно-
гое другое. Другими словами, первая глава - это авторское видение сети, мое
«1МНО», книга в книге. Прочитав первую часть, вы составите свое представле-
ние о FidoNet как о целом и вам легче будет воспринять ее в «препарированном»,
разъятом на части виде - такой она предстает в остальных главах, посвященных
подробному изложению всех аспектов и реалий FidoNet.
Вторая часть книги в большей степени адресована пользователям, уже имеющим
опыт работы в сети. Она поможет превратить ваш домашний компьютер в станцию
FidoNet, правильно выбрать и настроить программное обеспечение. Сюда входят:
□ глава 2. Введение в FidoNet. В этой главе дано подробное описание организа-
ционного устройства сети на основе Полиси, структуры нодлиста - списка
узлов сети, принципов разрешения конфликтов и координации (управления)
сетью, описаны основные услуги FidoNet, правила и обычаи их использования.
В главе также приводится краткое описание действующих стандартов и пред-
ложений FidoNet;
□ глава 3. Протоколы передачи файлов. Здесь описаны используемые в FidoNet
протоколы передачи файлов - Xmodem, ZModem, Hydra и Binkp;
□ глава 4. Форматы данных FidoNet. Эта глава содержит подробное описание
основных форматов хранения почтовых сообщений FidoNet - так называе-
мых MSG- и РКТ-форматов; здесь же описано устройство исходящего дирек-
тория почтовых программ;
□ глава 5. Почтовая сессия между двумя системами FidoNet. Протоколы почто-
вой сессии, описанные в этой главе, включают как архаичный обмен данны-
ми по стандарту FTS-0001 с использованием протокола Xmodem, так и более
современные стандарты YOOHOO и EMSI, распространенные в настоящее
время;
□ глава 6. Состав аппаратного и программного обеспечения FidoNet. Здесь
описываются требования к компьютеру, его настройка, выбор операционной
системы, популярные модемы, коммуникационные драйверы, используемые
в FidoNet, дается обзор программного дизайна типичной системы FidoNet;
□ глава 7. Обработка и передача по сети личной почты. Здесь вы найдете подроб-
ное изложение всех аспектов доставки личной почты FidoNet. Глава начинается
с описания терминологии и стандартов FidoNet, касающихся передачи сетевой
почты, отдельно описаны почтовые программы, правила и обычаи маршру-
тизации личной почты, Arcmail-attach и Binkley-style почтовые программы,
упаковщики и обработчики почты, рассмотрены возможные трудности в дос-
тавке личной почты и способы их устранения;
□ глава 8. Обработка и передача по сети эхо-конференций FidoNet. В ней рас-
сказывается о принципах технической реализации системы эхо-конференций
FidoNet. Приводится руководство по конфигурации популярных программ
обработки эхо-конференций, подписки на конференции и отписки от них,
рассмотрены правила и обычаи координирования распространения эхо-кон-
ференций, уделено внимание функциям эхо-модераторов и рассказано, как
быть в случае пропадания эхо-почты или ее дублирования;
□ глава 9. Обработка и передача файлов по сети. Аналогична предыдущим двум,
только речь теперь идет о передаче файлов по сети и файл-эхах. Как запро-
сить нужный файл с Fido-системы, как передать нужный файл адресату, как
настроить программу файл-эхопроцессора, как отправить файл в файл-эху,
как бороться с возникающими трудностями и избежать ошибок - все эти во-
просы подробно освещены в этой главе;
□ глава 10. Почтовые шлюзы FidoNet. Здесь даны общие принципы организа-
ции почтовых шлюзов между FidoNet и другими сетями - прежде всего
между FidoNet и Internet, а также краткое описание нескольких популяр-
ных программ, используемых при построении шлюзов. В конце главы де-
тально разбирается диагностика работы почтового шлюза между сетями
FidoNet и Internet;
□ глава 11. FidoNet over IP. Рассказывает о том, как используются подключение
к Internet для передачи почты FidoNet, стандартные протоколы Internet
(telnet, ftp) и специально разработанные для передачи Fido-почты; уделено
внимание особенностям настройки программного обеспечения, новой схеме
адресации Fido DNS;
□ глава 12. Интерфейс пользователя: редакторы Fido-почты. В этой главе рас-
сказывается, как работать с популярными редакторами почты FidoNet.
Все ссылки на печатные и электронные издания, встречающиеся на страницах
книги, сведены в раздел «Библиография».
В приложениях содержится необходимая информация справочного характера:
□ справочник стандартов (FTS) и предложений (FSC) FidoNet;
□ перевод действующей FidoNet Policy 4.07;
□ терминологический и жаргонный словари;
□ справочники эхо-конференций FidoNet;
□ справочник Web-серверов, посвященных FidoNet;
□ справочник географического распределения адресов FidoNet;
□ Echo-Policy региона 50 второй зоны FidoNet;
□ правила выборов сетевых координаторов региона 50 второй зоны FidoNet;
□ справочник по программному обеспечению FidoNet;
□ предметный указатель.
Как читать эту книгу
Конечно, было бы смешно указывать искушенному пользователю компьютера по-
следовательность изучения FidoNet. Читайте книгу в том порядке, который вам по
душе - хоть от конца к началу, если угодно. Тем не менее я рассчитывал при написа-
нии книги, что читатель перед изучением основного материала обязательно озна-
комится с первой главой. Главы 3 и 4 при первом чтении можно опустить - они
понадобятся, если вы захотите в деталях ознакомиться с базовыми стандартами
и подробностями технического устройства FidoNet. При изучении остальных глав
разумно обращать внимание в первую очередь на те примеры, где идет речь об ис-
пользуемых вами программах.
Как связаться с автором
Вы можете посылать свои письма по электронной почте Internet на адрес:
Amir.Shabashvili@fl2.n5049.z2.fidonet.org. Так мой FidoNet-адрес представлен
в сети Internet. Из сети FidoNet я доступен по адресу 2:5049/12. Мой «истинный»
Internet-адрес сейчас выглядит как ashabash@mail.ru. Дополнения к книге и ново-
сти FidoNet можно найти в Internet по адресу: http://www.dmk.ru/FidoNet/.
Глава I
Неформальное введение
в FidoNet
Выпьем за сеть 5050,
Пока модемы ее висят,
Пока над морем черного льда
Безнадежно гудят провода...
Из песни
Как объяснить человеку, никогда не видевшему моря, что оно собой представ-
ляет?
- Это много воды...
- Как в большой реке?
- Больше, гораздо больше...
Море больше, чем просто много соленой воды, FidoNet - гораздо больше, чем
просто компьютеры, соединенные модемами и телефонной проволокой. Это и спо-
соб получения информации, быстрого ответа на технический или житейский во-
прос, и стиль общения, и образ жизни, и ворох милых традиций, и единственная
отдушина для дружеского разговора, и дом.
В полной мере осознавая невозможность объяснить все это, я все же попыта-
юсь хотя бы обозначить, назвать то, чем дорога мне FidoNet («море простирается
до края небес, вода его прозрачна и холодна, глубина невероятна...»).
FidoNet пришла к нам в 1990 году, обозначив водораздел между эпохой парт-
хозактивов и временем пусть призрачной, но свободы. Вспомним это время. 1991
год - ГКЧП - в магазинах очереди за хлебом и чаем. И - Private amateur worldwide
network - говоря по-русски, частная добровольная всемирная компьютерная сеть.
Надо хорошо представлять, что для Америки - FidoNet родом из Штатов - зна-
чит слово «private» - частный. Это означает «неприкосновенный», «недосягае-
мый», «защищенный». Оно не содержит того презрительного оттенка - «част-
ник», «частная собственность», столь привычного слуху бывшего гражданина
страны труда. Поэтому перевод неточен.
FidoNet существует на основе соглашения, называемого FidoNet Policy (услов-
но переводится как «устав») и заключающего в себе не знакомые по многочислен-
ным уставам нашей юности «права и обязанности члена...», а нечто совсем дру-
гое - настолько завораживающее и простое, что становится странно, как на основе
этого может существовать мировая сеть, раскинувшаяся на все материки.
Тем не менее она существовала и ждала нас, когда в 1991 году, уже знакомый
с терминологией FidoNet, уже обзвонивший десяток первых московских BBS,
я случайно оказался в поликлинике Генштаба, в комнате площадью 5 м2, где сто-
яли три компьютера и два жужжащих модема, а хмурый невыспавшийся чело-
век Григорий Степанов, отец казанского Fido, пытался словами и жестами пере-
дать мне то, что предстоит растолковать вам, мой читатель.
Российская FidoNet сильно изменилась с тех пор. Тогда это была в большей
степени сеть друзей, интеллектуалов, подвижников, избранных. Все знали друг
друга - сеть внутри страны была невелика. Все часто и с удовольствием перехо-
дили в переписке на английский язык FidoNet.
Потом была первая BBS в Казани, популярность которой началась с крошечного
объявления в «Вечерке», затем первый пойнт - почтовая станция Fido, первый
узел - полноправный член сообщества FidoNet (тогда это сеть 5050, KamaRiverNet,
объединявшая Ижевск, Казань, Оренбург, Чебоксары, Йошкар-Олу, Пермь и Сим-
бирск), и наконец в 1993 году в мировом списке узлов - нодлисте - появилась
как часть Fido сеть с адресами 2:5049 - TartarNet.
Так начиналось мое вхождение в сеть. Похожие истории может рассказать уча-
стник любой из сетей, составляющих FidoNet. И само возникновение сети, ее раз-
витие и распространение были полны драматизма, случайностей.
Как все начиналось
Чтобы понять истоки популярности FidoNet, следует уделить некоторое внима-
ние тому фону, на котором она возникла. Итак, что же было до FidoNet, что при-
вело к ее созданию?
BBS, Xmodem и FidoNet
Задолго до того как появились персональные компьютеры и были изобретены
мини-компьютеры, существовали устройства, называемые тогда просто компью-
терами, - огромные монстры, занимавшие целые этажи, требовавшие больших
ресурсов, многочисленного обслуживающего персонала и вследствие всего этого
очень дорогие. Выключать такие машины было экономически невыгодно. Чтобы
оправдать затраты на изготовление и сопровождение, их «заставляли» непрерыв-
но производить вычисления, продавая различным организациям машинное вре-
мя. Дневное время таких компьютеров стоило дорого, оно не всем было по карма-
ну, зато ночью машина часто простаивала, это время было недорогим и его могли
использовать небольшие фирмы и частные лица.
Наиболее удобным способом подключения к таким компьютерам частных
пользователей было использование удаленных терминалов - простых устройств,
состоящих из печатающей машинки (позднее алфавитно-цифрового терминала
с клавиатурой) и модема на 110 или 300 бод. Стоимость такого оборудования, как
правило, не превышала нескольких тысяч долларов и была вполне доступна даже
частным лицам. Возможность, не вставая со своего рабочего места или не выходя
из дома, подключиться к огромной вычислительной системе вдохновила многих
пользователей на изучение компьютеров. Появились первые компьютерные сети,
инструментарий для общения в сети. Можно было развлекать себя играми, посы-
лать друг другу письма. К этому времени (1969) относится возникновение первой
общедоступной on-line информационной службы CompuServe и многих других
информационных систем. Подключаясь к подобным системам, вы видели на экра-
не своего терминала текстовое меню, через которое осуществлялся доступ к инфор-
мационным страницам. Именно такие системы и были прототипом созданных
позже BBS.
Название BBS (от англ. Bulletin Board System - «электронная доска объявле-
ний») означает компьютерную телекоммуникационную систему, доступную извне
в интерактивном терминальном режиме.
Иными словами, это программа для компьютера, оснащенного модемом, дос-
туп к которой вы получаете, запустив терминальную программу на своем компь-
ютере (терминальная программа сделает из вашего компьютера подобие прими-
тивного алфавитно-цифрового терминала) и позвонив на входной номер BBS.
Нечто подобное схематически изображено на рис. 1.16. Не правда ли, очень напо-
минает работу удаленного пользователя с «большим» компьютером (рис. 1.1а)?
BBS были созданы после того, как в продаже появились первые персональные
компьютеры. История создания BBS чем-то напоминает другие легенды компью-
терной эпохи - историю компьютера Apple или возникновение самой FidoNet.
Компьютер
пользователя
Модем
Модем
компьютер
Компьютер
пользователя
Компьютер
BBS
Рис. 1.1. Примеры работы пользователей
с «большим» компьютером (а) и системой BBS (б)
Авторами первой программы BBS были два компьютерных фаната: Вард Кристи-
ансон (Ward Christianson) и Ренди Сасс (Randy Suess), встретившиеся в середине
70-х в Чикаго, штат Иллинойс. Все необходимые части для создания BBS уже
были у них в руках - компьютер наколенной сборки с операционной системой
СР/М, акустический модем для копирования информации с одного компьютера
на другой (акустический модем подключался к телефонной линии оригинальным
способом: надевался на трубку телефона и осуществлял передачу с ее помощью).
Любители компьютеров постоянно использовали модем для обмена исходными
текстами программ. Другие файлы передавать было невозможно, так как модемы
не имели контроля ошибок передачи и при перемещении файлов посредством
модема двоичные файлы обыкновенно портились. Тексты же программ можно
было поправить вручную и откомпилировать.
Вард и Ренди жили далеко друг от друга (больше 30 миль) и то и дело посыла-
ли по обычной почте кассеты с программами. Для передачи неискаженных фай-
лов по телефонной линии Вард написал программу, которая производила переда-
чу блоками по 128 байт, проверяя, правильно ли передался каждый блок. (Сейчас
этот протокол передачи называется Xmodem и считается устаревшим.)
Позднее Вард вспоминал, что если бы они жили ближе и не нуждались в способе
помехоустойчивого обмена в такой степени, то, вероятно, Xmodem никогда им не
был бы написан.
Иногда друзья пользовались утилитой BYE, автором которой был Дейв Джефф
(Dave Jaffe). Эта программа позволяла организовать доступ через модем к СР/М
и удаленно работать на компьютере. Однако делать это было неудобно, поскольку
использовавшиеся тогда модемы работали очень медленно и с ошибками. Поиск
приемлемого компьютерного способа общения и обмена файлами привел к идее
написания специализированной программы для доступа к ресурсам компьютера.
Вард занялся созданием ее прототипа на языке Basic, а Ренди - мощного компью-
тера для будущей BBS. В начале февраля 1978 года на свет появилась CBBS
(Community Bulletin Board System), первая и самая известная программа BBS.
BBS быстро стали основным способом общения компьютерных любителей,
и в конце 70-х - начале 80-х тысячи таких систем были установлены на персональ-
ные компьютеры. Подключившись к BBS, можно было почитать письма в дискус-
сионных группах, написать письмо одному из пользователей данной BBS, прос-
мотреть файловые области и скачать понравившиеся файлы на диск своего
компьютера, поразвлечься on-line-играми, «поговорить» с системным операто-
ром. Это уже было настоящее общение, настоящая работа.
FidoNet возникла как развитие идеи BBS, как удобный способ off-line обмена ин-
формацией между системными операторами BBS, и очень часто две эти сущности
смешиваются: FidoNet называют сетью BBS. Однако сейчас это не так. Более того,
в некоторых областях распространения FidoNet, в частности в регионах, охватыва-
ющих страны бывшего СССР, BBS не являются основой FidoNet и далеко не каж-
дая Fido-система поддерживает BBS-доступ. Напротив, в Соединенных Штатах по
традиции BBS считается обязательной принадлежностью каждого узла FidoNet
и МО системы (от англ. Mail Only - «только почта») составляют меньшинство.
История FidoNet: сказка о Томе, Джоне и собаке Fido
История FidoNet в большей степени, чем история других компьютерных образо-
ваний, связана с конкретными людьми - ведь это сеть не организаций и общест-
венных объединений, а сеть людей. И если Билла Гейтса только условно можно
считать создателем MS DOS, а Питера Нортона - программы Norton Commander,
то у FidoNet есть «родители».
Том Дженнингс (Tom Jennings), программист из Сан-Франциско, положил нача-
ло сети в 1984 году. Анархист по убеждениям, Том создавал сеть «под себя» и поки-
нул ее, когда новая редакция устава (Policy) показалась ему ограничивающей сво-
боду личности. Вот что говорит сам Том о времени начала:
«Когда FidoNet тестировалась впервые, было два узла: мой Fido # 1 здесь, в Сан-
Франциско, и Fido #2 Джона Мэдила в Балтиморе. Джон и я делали все для тести-
рования и развития первой версии FidoNet. Цель - посмотреть, как она работа-
ет, большею частью для развлечения, вроде любительского радио. Она быстро
стала полезной: вместо попыток позвонить друг другу на BBS и оставить пись-
мо или дорогих голосовых телефонных звонков письма FidoNet доставлялись более
или менее автоматически. Это была седьмая версия Fido где-то в июне 84-го или
около того...» [1.1].
Том дал сети название «FidoNet», чтобы как-то обозначить дружеский и не-
официальный ее характер. По-английски «Fido» - кличка домашней собаки, что-
то вроде Шарика или Дружка. Вопреки распространенной легенде, у Дженнингса
никогда не было собаки Fido.
FidoNet возникла как сеть персональных домашних компьютеров IBM PC с опе-
рационной системой MS DOS, поскольку именно IBM PC стал к тому времени под-
линно народным компьютером.
Идея и технология FidoNet вначале были очень просты, поскольку проста была
и сеть - сначала всего два, потом десяток-другой узлов. Адреса узлов решили выб-
рать цифровые, просто номера: #1 - у Тома, #2 - у Джона и далее по возрастающей.
Программа, которая осуществляла обмен почтой, была написана Томом и так же
называлась - fido.exe. От нее и от одноименного странного компьютера, на котором
работал Том, и пошло название сети. Звонки на другие узлы осуществлялись в со-
ответствии со списком узлов, который вначале велся от руки.
Главное достоинство сети заключалось в том, что Fido работала автоматически,
не требуя присутствия владельца узла у компьютера. Хозяин узла или системный
оператор, сисоп (sysop) в общепринятой терминологии, читал и писал письма, ис-
пользуя адресацию FidoNet, а программа Fido отправляла их в удобное время (по
преимуществу ночью, чтобы воспользоваться льготным телефонным тарифом).
На рис. 1.2 схематически изображена работа сети образца первой половины 1984
года. Системным оператором узла с адресом #1 подготовлены письма для узлов #2,
#3 и #4. Каждый из этих узлов в свою очередь подготовил несколько писем для
узла #1. После того как письма помещены в исходящий директорий (outbound), где
их может обнаружить программа fido.exe, начинается ее работа. Сначала из несколь-
ких писем для каждого адреса формируется единый пакет. Этот процесс называется
упаковкой писем (mail packing}, а программа, выполняющая упаковку - паковщиком
сетевой почты (netmail packer). В описывае-
мое время эту функцию выполняла все та же
программа fido.exe. Затем программы Fido на
каждой из четырех систем делают непрерыв-
ные попытки отправить почтовый пакет адре-
сату; системы #2, #3 и #4 звонят по телефону
первого узла, который они находят в списке
узлов, помещенном в один из конфигураци-
онных файлов, а первый узел аналогичным
образом поочередно обзванивает системы #2,
#3 и #4. При этом все системы конкурируют
друг с другом за установление связи, так как
телефон у каждой только один и часть попы-
Рис. 1.2. Схематическое
изображение работы сети FidoNet
образца 1984 года
ток дает результат «занято».
После того как соединение установлено, производится обмен почтой в обоих
направлениях: сначала вызывающей системой отсылается исходящая почта, за-
тем принимается входящая.
Полученный почтовый пакет попадает во входной директорий (inbound), рас-
паковывается, после чего сисоп узла может прочитать принятую почту и написать
ответы.
Описанная технология еще непригодна для создания большой сети, так как при
возрастании количества узлов обмен почтой становится затруднительным.
Представим, к примеру, что на систему #1 пытаются отправить почту более ты-
сячи систем (случай реальный, если системный оператор #1 выполняет функции
координатора FidoNet). Работа системы #1 будет блокирована, и попытки отпра-
вить почту потерпят неудачу. Кроме того, затраты на звонки в сумме будут очень
велики.
В следующих разделах книги подробно остановимся на том, как FidoNet была
усовершенствована, чтобы преодолеть эту и многие другие трудности; сейчас же
отметим, что, несмотря на эти недостатки, в технологии FidoNet уже с самого на-
чала были реализованы важные идеи:
□ автоматическое функционирование систем, составляющих сеть;
□ их независимость, децентрализованный характер сети;
□ несинхронизированность, конкурентный характер установления связи;
□ упаковка писем в пакет перед отправкой для повышения эффективности про-
цесса обмена почтой;
□ передача почты в обоих направлениях при установлении соединения.
Именно эти простые особенности заложили фундамент популярности FidoNet
как доступной, живучей и дешевой off-line сети передачи электронной почты.
На рис. 1.3 изображен снимок одного из первых нодлистов, составленный
Дженнингсом с пометками от руки. Казалось бы, немногого можно ожидать от
сети, работающей на основании такого вот списка, составляемого отчасти из
информации, надиктованной голосом по телефону, с ошибками, неточностями
CI.P-BBS Pikesville, MD John. Madill
MICRONET Atlanta, GA Lane Fowler
Chance Load Mgt St. Fx>uis, MO Tony Clerk
Batie’s Backyard Corvallis OR Alan Batie
CastleNet Corvallis OR Lee Damon
Strictly Software Waimea, HI Hob Overlock
Demon New York, NY Danny Feinsmith
Silver Screen Danbury, CT Jim Ryan
MDC/RCC St. Louis MO Ben Baker
PRO-TECIi Sanford Zelkovitz
Vern's Fido San Jose, CA Vern Crawford
14. WayStar Marlboro, HA Kevin Porter
16. Mikes Board Mike Mellinger St. Louis,
17. DCA_BBS Jon Wichman St. Louis, MO
z 7/yy
(301,-484-2831
(404,-979-5105
(314,-895-6471
-DOWN—
-DOWN-
(808)-338-1277
(212)-591-4487 Юр - 3p
(203,-748-5146 Bp - 8a
(314,-234-1462 5p - 8a
(714,-898-8634
( 408,-923-5565 when r
*18,
Steve Hedlund
*22. PCLUG St. Louis,
23. CoraWorx Encino,
Van Nuys, CA
;, MO Ken Kaplan
*25. Take-A-Byte Anaheim, CA Robert Collins
*26,
'28,
MicroFonePC Fresno, СЛ Bob Robesky
??? Gardner, MA David Rene
World Control Baltimore MD Rob White
*32.
33. Rod Smallwood England
*34. CrossFiro Todd Savar Philadelphia, Pa
*35. ConsultNet Jim Turley Saratoga, CA
*36. Rainbow Data Los Angeles, CA
* 38. Bill Thousand Jr Madison W1
* 39. Karl Regier Reedley CA
* 40. Ron Crain Birmingham MI
МО
(314)-962-0395
(415,-989-2415
(7148)-?95-24278 +^S
(209,-227-2083 5p-9a twkends
/Г. 1АЛ4
(301,-653-2074
(soon)
44-635-4680
(215,-576-5009
(408,-867-5078 Jin _ ,,
(Aug 15) p Ja
(608)-274-6377 330d -
(617,-646—3610
Seequa Computer Odenton MD
NECS Ar ling ton, HA Davo Mitton
И I
кг,?;
714 ъ
7/3
Рис. 1.3. Один из первых нодлистов FidoNet
(факс-копия с бумажного оригинала)
5/Z. 32-? оу/Г ।
^-Z Гт
/>
оП
и исправлениями. Однако никто из создателей и не ждал от Fido слишком много-
го, быть полезной - вот что было основной целью проекта. И Том, и Джон были
системными операторами BBS, и в начале обмен почтой и файлами посредством
Fido воспринимался как еще одна утилита BBS, полезное, хотя и мелкое усовер-
шенствование. Трудно было распознать в этом уродливом изделии зародыш буду-
щей глобальной сети.
FidoNet в России
FidoNet проникла в Россию (в те времена еще СССР) в 1990 году. Поскольку сеть
эта некоммерческая, нигде не рекламировалась, то и распространение ее носило
характер спонтанный и случайный.
В России повезло городу Новосибирску, в котором жил и работал программист
Евгений Чуприянов, более известный в сети как Eric Fletcher. Именно им была
основана первая Fido-станция на территории России, получившая при регистра-
ции адрес 2:42/100 и принадлежавшая к адресному пространству региона 42 (Че-
хия и Словакия). Дело в том, что первая информация о FidoNet пришла именно
из Чехии.
Затем Fido шагнула в уральский город Челябинск усилиями человека по имени
Юрий Потапюк (Yuri PQ), до сих пор бессменно координирующего работу челя-
бинской сети, а уже затем появилась в Москве, Петербурге и быстро распространи-
лась по стране. Интересно, что Yuri PQ помогал в установке и конфигурации про-
грамм первых московских Fido-станций. В утверждении FidoNet в городе-герое
Москве важную роль сыграла станция FidoNet, называвшаяся Kremlin BBS. Ее сис-
темным оператором был гражданин Польши Тадеуш Радюш (Tadeusz Radiusz), жив-
ший тогда в Москве. За станцией в основном присматривала жена Тадеуша, Елена
Радюш, сотрудничавшая с издававшимся в Москве советско-польским журналом
«Компьютер». Вокруг Kremlin BBS вскоре образовался круг пользователей моде-
мов, перезнакомившихся и положивших начало самой крупной сейчас в регионе
московской сети.
Ниже приведен фрагмент нодлиста за август 1991 года. Весь регион 50 занима-
ет в нем всего несколько десятков строк (в примере приведена только часть ин-
формации из нодлистовых строк):
Region, 50, Russia, Novosibirsk_USSR, Evgeny_Chupriyanov...
, 200,The_Communication_Tube, Leningrad_Russia, Michael_Bravo,...
Host, 5000, Novosibirsk_NET, Novosibirsk_USSR, Igor_Vasichkin,...
, 10, The_Court_of_the_Crimson_King, Novosibirsk_USSR, Evgeny_Chupriyanov,...
Pvt, 13, Toad’ s_Quake, Novosibirsk_USSR, Serge_Terekhov,...
, 20, Hall_of_Guild, Novosibirsk_USSR, Igor_Vasichkin,...
, 30, Sine_Lex, Novosibirsk_USSR, Maxim_Nikitin,...
Host, 5010, South_Ural. Chelyabinsk_SU, Yuri_PQ,...
Down,1, SoftwareService_Board_System,Chelyabinsk,Serge_Korotovskih,
, 2, PsychodeliQ_Hacker_Club_BBS, Chelyabinsk, Yuri_PQ,...
,3,ICC-BBS,Chelyabinsk,Konstantin_Yudaev,.
Host, 5020, Moscow_Fair, Moscow_Russia, Alexey_Zabrodin,...
, 1, Nightmare_BBS, Moscow_Russia, Evil_SysOp,...
, 2, Wild_Moon, Moscow_Russia, Alexey_Zabrodin,...
,4,MostNet_2,Moscow_Russia,Pavel_Galyamin,..
, 6, JV_Dialogue_1st_BBS, Moscow_Russia, Dmit ry_Bondarenko,...
, 7, Bargain_BBS, Moscow_Russia, Igor_Kriwchenko,..
, 9, Bowhill_BBS, Moscow_Russia, Max_Mikheenkov,...
, 10, Angel_Station_BBS, Moscow_Russia, Kuzma_Mikhailoff,...
, 11, Alan_BBS, Zelenograd_Russia, Alexander_Yashin,...
, 12, ASSUNI-BBS, Moscow_Russia, Sergey_Mansurov,...
,13, Do-Mail! _BBS, Moscow_Russia, Michael_Andronov,...
,16,DATAB0ARD_BBS,Moscow_Russia,Serg_Khan,..
, 17, Soft_Parade_System, Moscow_Russia, Andrew_Kovalev,...
Host, 5030, NorthWest_Net, Leningrad-Russia, Michael_Bravo, ...
, 1, KREIT_BBS, Leningrad-Russia, Dmitry_Klimenkov,...
2 - 431
, 2, Kronverk_BBS, Leningrad-Russia, Nick_Nemirow,...
, 3, Midnight_Blues, Leningrad-Russia, Leonid_Avtushenko,... i
, 4, Petersburg_Future_BBS, Leningrad-Russia, Denis_Eropkin,...
, 5, Nice_Landing, Leningrad-Russia, Yuri_Ivanov,...
, 10, The_Last_Homely_House, Leningrad-Russia, Michael_Bravo,...
Распространение FidoNet в России происходило очень быстро. Сейчас регион
50 составляют более пяти тысяч узлов FidoNet и рост продолжается.
К событиям, имевшим важное значения для функционирования сети, следует
отнести запуск шлюза между регионом 50 FidoNet и сетью «Релком». Шлюз был
создан усилиями москвича Дмитрия Завалишина (Fido-адрес 2:5020/32) и зара-
ботал летом 1991 года. После появления этого шлюза стал возможным обмен поч-
той с сетью Internet без использования дорогостоящих международных каналов
(до этого приходилось пользоваться зарубежными шлюзами, транспортируя поч-
ту до них по FidoNet).
Другим существенным результатом деятельности шлюза было появление сре-
ди групп новостей российского Internet иерархии relcom.fido.*, содержащей про-
шедшие шлюз эхо-конференции FidoNet. В FidoNet, в свою очередь, появились
конференции сети «Релком» (ныне «Деловая сеть»). Подробное описание попу-
лярных программ для шлюзования почты FidoNet в Internet и их настройки со-
держится в главе 10.
Развитие сети, увеличение ежедневно транспортируемого объема почты вызва-
ло к жизни более совершенные системы обработки и распространения информа-
ции. Был создан московский бекбон (Moscow echo backbone) - система раздачи
эхо-почты, скоростной скелет сети. Сейчас подобные структуры существуют во
многих сетях региона, есть и бекбон регионального уровня, поставляющий инфор-
мацию сетевым бекбонам. Подробно устройство бекбона описано в главе 8.
FidoNet в России и странах бывшего СССР имеет свои особенности. Пока была
упомянута только одна из них: разделение BBS-сервиса и собственно FidoNet.
Есть и более существенные отличия от FidoNet западного образца, стоит обратить
на них внимание:
□ FidoNet в России русскоязычно (насколько мне известно, практически не
используются национальные языки, за исключением украинского);
□ значительная часть систем FidoNet установлена в организациях;
□ для передачи почты на большие расстояния в настоящее время, как правило,
используется соединение через Internet;
□ практически не распространены столь популярные в Соединенных Штатах
и Западной Европе финансирование междугородних звонков в складчину
(costsharing) и коммерческие услуги BBS.
Отдельно стоит остановиться на неустранимой особенности России - она очень
большая. Территория России покрывает несколько часовых поясов и создает спе-
цифические трудности для желающих использовать ночное время при установле-
нии соединения на больших расстояниях. Одним из столпов FidoNet до сих пор
остается ZMH (от англ. Zone Mail Hour - «зональный почтовый час»), подробно
описанный далее в этой и второй главах. До последнего времени соблюдение ZMH
было одним из обязательных условий выдачи узлового адреса FidoNet, а почтовый
час второй зоны (Европа), к которой принадлежит Россия, зафиксирован в ин-
тервале 2.30-3.30 по Гринвичу (5.30-6.30 московского времени зимой и 6.30-
7.30 летом). И если западнее Москвы это время еще можно считать ночным, то
в восточных областях ZMH приходится на дневные часы, когда обеспечить рабо-
тоспособность станции FidoNet подчас очень трудно и дорого.
В 1994-1995 годах в FidoNet активно обсуждалось предложение о выделении
Российского сегмента сети в отдельную (седьмую) зону. Была даже создана тест-
сеть с адресами седьмой зоны, но до реальной трансформации адресов и измене-
ния ZMH дело так и не дошло. Подробнее этот вопрос обсуждается далее в этой
главе.
Fido7 - русская сеть
FidoNet впервые появилась в России еще до распада Советского Союза. Между-
народным телефонным кодом СССР была цифра «семь». Поэтому с тех пор все
русскоязычное Fido, уже много лет как разделенное на несколько независимых
регионов (45 - Беларусь, 46 - Украина и Молдова, 47 - Литва, 49 - Эстония, 50 -
Россия и республики Средней Азии, 51 - Латвия), воспринимается многими как
единое русскоязычное пространство и даже имеет название «Fido7». В сети
Internet в одноименной иерархии news-конференций представлены почти все рус-
скоязычные эхо-конференции FidoNet. Многие особенности российского Fido,
перечисленные выше, являются общими и для всего Fido7.
Сеть Fido и...
FidoNet и Usenet
Практически одновременно с FidoNet возникла другая сеть, известная как
USENet (UNIX User Network). Основой USENet послужил простой протокол об-
мена почтой UUCP (UNIX-to-UNIX Copy Protocol), ведущий свою родословную
из набора скриптов для командного процессора (shell) операционной системы
UNIX, написанных в 1979 году Стивом Белловином (Steve Bellovin) для обмена
почтой UNIX-систем в двух американских университетах.
FidoNet и USENet имеют много общего: обе предоставляют off-line доступ, то
есть сначала ваш компьютер скачивает пакет информации, а потом вы читаете
письма и пишете ответы, не занимая линии связи. В разное время услугами
USENet пользовались миллионы людей. Когда FidoNet только возникла, первая
сеть, с которой осуществлялся обмен почтой (гейтование), была именно USENet.
В наши дни о ней лучше говорить в прошедшем времени - сейчас эта сеть вошла
в состав Internet, поскольку on-line доступ стал дешев и протокол NNTP, поддер-
живаемый на многих хост-компьютерах Internet, позволяет распространять те же
конференции USENet. Однако системы классической USENet кое-где еще встре-
чаются, особенно в России.
FidoNet и Internet
FidoNet и Internet часто противопоставляют друг другу, на самом же деле FidoNet
сейчас не может существовать без транспортных услуг Internet:
□ подключаясь к FidoNet, получая адрес в этой сети, вы автоматически по-
лучаете и адрес электронной почты в Internet, и можете обмениваться поч-
той с пользователями этой сети через почтовые шлюзы (глава 10);
□ ваше письмо, отправленное по адресу сети FidoNet, если только оно адресо-
вано достаточно удаленному корреспонденту, скорее всего большую часть
пути пройдет по Internet, поскольку скоростной скелет сети FidoNet (бекбон)
работает с использованием соединений через Internet;
□ почти все эхо-конференции FidoNet доступны для чтения в составе Internet
News, например конференции российского Fido в иерархии fido7.*.
Будущее существование и развитие FidoNet, наверняка, будет еще прочнее свя-
зано с Internet. И несмотря на это, FidoNet - единственная всемирная компью-
терная сеть, по-настоящему дистанцированная от Internet. Все остальные сети,
некогда бывшие самостоятельными и отличными от Internet, например упоми-
навшаяся выше USENet или североамериканская академическая BITNET, к на-
стоящему времени полностью вошли в состав Internet. Подробно взаимодействие
FidoNet и Internet изложено в главе 10, а использование сервиса Internet для нужд
FidoNet - в главе И.
FidoNet и общество
Компьютерные сети создают среду для свободного обмена информацией. Так сло-
жилось исторически, это подарок судьбы. Вполне вероятным было бы и развитие
событий, при котором с самого начала возникновения сетей во главу угла было
бы поставлено слежение и контроль за циркулирующей по сети информацией.
Именно так развивались сети стандарта Х.25, и несмотря на то, что они до сих пор
чрезвычайно широко распространены по всему миру, публичный сервис и откры-
тый доступ для них - редчайшее исключение.
Правительства постоянно пытаются ограничить свободу электронного сообщества,
с этой целью издаются соответствующие указы и распоряжения. К счастью, пока на
просторах Internet мы ощущаем себя свободными. Такова и FidoNet: здесь нет цензу-
ры, свобода отдельных личностей ограничена только свободой других участников
сети. Кроме того, сеть FidoNet еще и независима и неконтролируема, в отличие от
большинства поставщиков Internet-услуг. Демократия, уважение к свободе личности,
наличие гражданских свобод - непременное условие существования FidoNet. Поэто-
му, вероятно, численность узлов FidoNet в крошечном Тайване больше, чем в Индии
или Китае, а в Северной Корее, в отличие от Южной, Fido и вовсе отсутствует.
Несмотря на то, что FidoNet изначально в высшей степени неформальное сооб-
щество и не может существовать в условиях тоталитарного режима, само ее уст-
ройство никогда не было демократическим. Только в последние годы некоторое
распространение получили выборы координаторов территориальных сетей.
FidoNet и Международная Ассоциация FidoNet (IFNA)
В самом начале 1986 года, когда FidoNet «разбухла» до нескольких сотен сис-
тем, ее основатели Том Дженнингс, Бен Баркер (Ben Barker), Кен Каплан (Кеп
Kaplan) и Ренди Буш (Randy Bush) попробовали поставить дело на более серь-
езную, профессиональную основу. Решено было официально зарегистрировать
некоммерческую ассоциацию системных операторов FidoNet, что и было сдела-
но после немалого количества споров, часть которых нашла свое отражение в Fido-
News [1.2].
Предполагалось, что IFNA будет центром FidoNet. Деньги на работу ассоциа-
ции собирались в основном из добровольных пожертвований членов и оказания
платных услуг внешним организациям. Ассоциация успешно проработала в те-
чение трех лет, вплоть до конца 1989 года, и немало начинаний в становлении
FidoNet связано с IFNA. В эти годы IFNA стала как бы синонимом FidoNet, офи-
циальным представителем интересов сети. Утверждение новых стандартов, пуб-
ликация FidoNews, введение стандартных схем маршрутизации почты, ежегодные
очные сетевые конференции - все делалось с ведома и под патронажем IFNA, ко-
торая сыграла большую роль в развитии FidoNet в годы ее стремительного роста
и распространения по всему миру. Именно IFNA поддержала такие важные ини-
циативы, как создание FSC - комитета по стандартам FidoNet.
Однако, когда количество членов ассоциации приблизилось к 700, стало трудно
понять, что для чего существует: IFNA для FidoNet или FidoNet для IFNA.
Увеличившаяся численно администрация IFNA попыталась в 1989 году «взять
власть», установить еще более жесткий контроль над сетью, чем тот, который
существовал до этого. В результате проведенного всесетевого референдума она
была распущена и никогда больше не возрождалась. Сеть вернулась в привычное
анархическое русло.
FidoNet и ее торговая марка
На многих документах, имеющих хождение в FidoNet, стоит копирайт следующего
вида: © Fido and FidoNet are registered marks of Tom Jennings and Fido Software. Исто-
рия этой фразы такова: когда Том Дженнингс создал сеть FidoNet, ее программное
обеспечение исчерпывалось одноименной программой fido.exe, изготавливаемой
и поддерживаемой автором. Чтобы сохранить за собой и за другими членами право
на использование наименования «FidoNet», Том, недолго думая, зарегистрировал
на себя и на выдуманную фирму Fido Software торговую марку FidoNet. На рис. 1.4
приведен снимок патента, который получил Дженнингс в 1988 году.
Долгое время на все программы и документы FidoNet авторы ставили этот
копирайт, пока не выяснилось, что патент, полученный Дженнингсом, действу-
ет только на территории Соединенных Штатов Америки, да и за давностью лет
уже недействителен. Так что торговая марка FidoNet имеет только историчес-
кое значение, радуя участников сети замечательным изображением легендарной
собаки Fido.
Int. а.: 9
Prior U.S. С.: 38
Reg. No. 1,503,643
United States Patent and Trademark Office Registered Sep. 13, 1988
TRADEMARK
PRINCIPAL REGISTER
JENNINGS, THOMAS DANIEL (UNITED
STATES CITIZEN)
164 SHIPLEY STREET
SAN FRANCISCO, CA 94107
FOR COMPUTER PROGRAMS AND AC-
COMPANYING USER MANUALS, IN CLASS 9
(US CL 38)
FIRST USE 6-18-1984, IN COMMERCE
9-15-1984
OWNER OF U.S REG. NO. 1,452.977
NO CLAIM IS MADE TO THE EXCLUSIVE
RIGHT TO USE THE REPRESENTATION OF A
COMPUTER DISKETTE. APART FROM THE
MARK AS SHOWN
SER NO 665,098, FILED 6-8-1987.
CATHERINE PLAMBECK, EXAMINING AT-
TORNEY
Рис. 1.4. Снимок патента на использование торговой марки FidoNet
Устройство FidoNet
Направляющая своими цапфами с помощью
наметок крепится к лодыгам вертлюга.
Из наставления по устройству
пусковой установки тактического
ракетного комплекса
Сеть FidoNet, как и любая «большая» сеть, основана на наборе технических согла-
шений, обычно называемых стандартами. Это форматы данных, последователь-
ность обмена сигналами при установлении связи и многое другое. Подробно основ-
ные стандарты FidoNet рассмотрены в этой и во второй главах. Но не все можно
понять, читая стандарты, есть нечто, условно называемое «стилем» FidoNet, что
можно воспринять во всей полноте только подключившись к сети и узнав все тон-
кости ее работы, обычаи и предрассудки ее «населения», историю сети и жаргон.
Поэтому вместо традиционного сухого изложения неизвестно откуда взявшегося
устройства сети, начнем с того, как методом проб и ошибок, постепенно и не вдруг
создавалась FidoNet. К счастью, у нас есть любопытнейший документ, принадлежа-
щий перу самого Тома Дженнингса - известный текстовый файл fidohist.doc, в ко-
тором излагается история первых лет существования FidoNet. Итак, вашему вни-
манию предлагается знаменитое «Евангелие от Тома».
fidohist.doc, или «Евангелие от Тома»: история FidoNet-85/1
В начале этой главы мы описали устройство FidoNet-84 - сети, возникшей из по-
требности в обмене письмами между системными операторами BBS. Это была
простейшая структура с цифровой нумерацией узлов и циклическим установле-
нием связи каждого с каждым на основе вручную заполнявшегося списка членов
сети с их телефонными номерами.
Функции координатора сети, в круг обязанностей которого входило только за-
полнение и распространение нодлиста, выполнял сам Том Дженнингс. Однако
сеть росла и постепенно перестала удовлетворять нуждам своих создателей. Вот
как Том описывает возникшие вскоре проблемы:
«...В августе 1984 года количество узлов достигло тридцати; сеть, верите или
нет, засорялась на глазах. В ту пору FidoNet не была достаточно совершенна,
чтобы делать самостоятельно звонки. С тридцатью системами координация
становилась трудной задачей: вместо простого звонка и обычного голосового воп-
роса для устранения проблем вроде неотвечающих модемов, ошибочных номеров,
часов работы и т.п. теперь требовались дни. Тогда было шесть узлов в Сент-
Луисе, и Fido #1 был вынужден звонить каждому, хотя порой необходим был все-
го лишь один звонок.
«Первоначальная» FidoNet была очень простой и дружественной: вы сообщали
мне на Fido #1, что ваш FidoNet узел готов, я помещал вас в список с вашим теле-
фонным номером и люди звонили и скачивали список - дело сделано!
Ну, сначала «каждый знал каждого», все мы были в более или менее постоянном
контакте. Однако, когда количество узлов перевалило за два десятка, узлы получи-
ли и люди, которых никто из нас не знал. Это было хорошо, но это значило, что мы
не были больше в близком контакте. Работа сети начала ухудшаться: на каждую
неделю наверняка приходился один, а то и два ошибочных телефонных номера.
Чтобы понять всю серьезность проблемы, вообразите себя несчастной старой да-
мой, которую каждую ночь будят телефонные звонки (каждые две минуты с че-
тырехутра!), причем никто ничего не говорит, а сразу после соединения молча бро-
сает трубку. Это происходило на самом деле: я вынужден был отслеживать те
случаи, когда почта не уходила в течение недели или двух, потом не выдерживал,
хватал телефон после набора номера модемом и попадал в ужасную ситуацию из-
за необходимости объяснять, что такое BBS, чрезвычайно усталой и раздражен-
ной личности.
Случалось также, что новый узел в действительности еще не работал и этот
номер принадлежал домашнему телефону, используемому временно, но я забывал
об этом и включал его в нодлист. Или новый узел еще не работал, а мы все должны
были звонить на него - он не отвечал или, что еще хуже, модем отвечал, но про-
грамма не была запущена, и мы должны были платить за звонки».
Из процитированного отрывка следует, что основная часть изложенных Томом
затруднений не технического свойства. Так будет и в дальнейшем. Часть из проб-
лем FidoNet легко устраняются доработкой программного обеспечения, часть же
невозможно или очень трудно разрешить технически, их можно преодолеть, толь-
ко изменив или дополнив правила взаимодействия сисопов, по которым сущест-
вует сеть. Именно эта сторона деятельности FidoNet будет далее называться
административной или политической. Выход, в конце концов, был найден, что
подтверждает поучительный fidohist.doc:
«Так дальше не могло продолжаться. Мы должны были найти какой-то путь,
чтобы, по крайней мере, удостовериться в правильности телефонных номеров!
Я установил новые правила: перед выдачей узлового номера и помещением его в спи-
сок узлов я должен был получить FidoNet-письмо от нового узла директом [то есть
прямым соединением, не пользуясь передачей по сети. - Э. Ш.]. Это вселяло уве-
ренность, что новый участник Fido существует и работает. Тем самым [новый
участник. - Э. Ш.] Fido давал разрешение Fido #1 удаленно устанавливать номер
узла; я посылал в ответ сообщение, и готово! - есть новый узел».
Таким образом было найдено простое решение, действующее и по сию пору.
И сейчас запрос узлового адреса принято делать в письменной форме, посылая
сообщение на систему координатора местной сети, причем желательно исполь-
зовать непосредственное соединение, не прибегая к услугам сетевой маршрути-
зации почты.
Далее Том говорит, что на этом проблемы не кончились, поскольку у него про-
сто не хватало времени на то, чтобы тщательно следить за правильностью нодлис-
та и одновременно работать над усовершенствованием программного обеспечения
FidoNet. Требовалось распределение работы, разделение полномочий:
«Люди в Сент-Луисе (Тони Кларк, Бен Бекер, Кен Каплан, Джон Вихман, Майк
Меллингер) создали хорошо работающие узлы и прекрасно разобрались, в чем суть
FidoNet, как она работает, что это вообще такое. Они вызвались вести нодлист
и обрабатывать запросы новых узлов, что позволило мне заняться только рабо-
той с софтом. Они также упростили требования к сообщению FidoNet. Через не-
сколько месяцев имеющийся «коэффициент ошибок» (неверные номера и т.д.) сни-
зился практически до нуля, на этой отметке он находится и сегодня».
Распределение полномочий, поручение добровольцам выполнения части работ
координатора - практика, широко распространенная в FidoNet, и причину этого
подхода следует искать в том, что никто из координаторов не получает денег за
свою работу в FidoNet. Координаторы - обычные люди, у них есть работа помимо
FidoNet, выполняя которую они получают средства к существованию. Поэтому
поручение добровольцам части работы координатора позволяет уменьшить на-
грузку на него и улучшить качество предоставляемого сервиса. Например, в сети
TartarNet (Россия, Казань), несмотря на ее небольшой размер (около 80 узлов),
кроме обязательной должности NC (Net Coordinator) есть должности NEC (от
англ. Net Echo Coordinator - «координатор эхо-почты»), FEC (от англ. File-Echo
Coordinator - «координатор файл-эх»), Pointlist-Holder - составитель пойнтлис-
та и BBSlist-Holder - составитель списка казанских BBS.
fidohist.doc, или «Евангелие от Тома II»:
история FidoNet-85/2
Наше описание начальных месяцев существования сети было прервано на том
этапе, когда сеть представляла из себя единый организм с центральной админи-
страцией, занятой исключительно ведением быстро растущего нодлиста.
Вторая часть файла fidohist.doc написана Томом Дженнингсом через шесть
месяцев после первой. За это время в сети произошли значительные изменения.
Вот как описывает события автор:
«...В течение многих месяцев мы обсуждали, как бы нам найти решение много-
численных проблем. И если решение не было бы найдено в ближайшее время (в ав-
густе 1985 или чуть позже), то FidoNet погибла бы из-за огромного веса своего
нодлиста.
...Было много разногласий при обсуждении того, что мы могли бы сделать; у нас
не было денег, поэтому все нужно было делать бесплатно. Централизация явно
уступала место локализации [TJ имеет в виду появление локальных сетей
FidoNet. - Э. Ш.]. И как со всем этим справиться, нам было совершенно неизвест-
но». Решение было найдено на общем собрании всех участников, занимавшихся
развитием сети, и заключалось оно в создании локальных сетей (Nets), террито-
риальных объединений локальных сетей (Regions) и введении администраций со-
ответствующего уровня. Критерием разделения сети является телефонный код,
а не территориальная принадлежность, поскольку именно телефонный код оп-
ределяет стоимость звонков, a FidoNet использует для установления телефон-
ную сеть. Конечно, телефонный код обычно соответствует территориальному де-
лению, но иногда это правило нарушается, и тогда возникают территориально
распределенные сети.
Спустя несколько лет, когда FidoNet распространилась на весь земной шар, был
введен еще один уровень координации - зона (zone), объединяющая регионы
одного материка.
Командиры FidoNet: административное устройство сети
Над начальниками есть начальники,
и над ними - тоже начальники.
Китайская пословица
FidoNet управляется структурой координаторов, которых только очень условно
можно считать начальниками. Прав у координатора никаких нет, налицо одни
обязанности, которые при правильной организации и распределении полномочий
необременительны: обновлять нодлист своей сети, разрешать возникающие кон-
фликты, принимать почту для сети и доставлять ее адресатам. Когда-то Том Джен-
нингс был единственным «командиром» FidoNet. Постепенное развитие сети, ее
численный рост и распространение по всему миру потребовали создания иерар-
хической структуры координаторов. Далее в книге мы еще вернемся к описанию
и анализу института координаторов FidoNet, по-своему уникальному в сетевом
мире, а пока кратко перечислим основные ступени иерархии (табл. 1.1).
Таблица 1.1. Описание структуры координаторов FidoNet
Название должности Область ответственности
Сисоп FidoNet Узел (node)
Координатор сети (NC) Город, местность (network)
Координатор региона (RC) Одна или несколько стран (region)
Координатор зоны (ZC) Материк (zone)
Международный координатор (IC) Вся сеть FidoNet
На рис. 1.5 схематически изображена структура сети FidoNet. Здесь представ-
лены уровни координации сети от узла и его системного оператора, командира
пользователей своей BBS, далее через уровни сети (город), региона (страна)
и зоны (материк) к «начальнику» всей сети - международному координатору (IC).
Справедливости ради следует отметить, что должность IC порой подолгу пус-
тует и тогда руководство сетью осуществляет ZCC (от англ. Zone Coordinator’s
Counsil - «совет координаторов зон»). Цифры рядом с изображениями каждого
уровня иерархии - это телефонный код, на основании которого производится де-
ление сети на структурные единицы. Все узлы одной сети имеют единый код
страны или города, все сети одного региона имеют обыкновенно единый код
страны. Деление на зоны произведено по географическому принципу. Каждая
зона представляет в FidoNet тот или иной материк.
Адрес FidoNet
FidoNet имеет свою систему адресации, не совпадающую ни с какой другой. На-
пример, мой адрес в Fido: 2:5049/12.0@fidonet. Это так называемая 5-D запись -
в ней пять полей, разделенных спецсимволами.
Сначала адресация FidoNet была просто нумерацией - узел 1, 2 и т.д. Затем,
после организации локальных (местных) сетей и их объединений (регионов), ад-
рес был модифицирован и записывался так: 5049/12, где 5049 - номер сети, а 12 -
номер узла.
зона
Рис. 1.5. Структурная схема сети FidoNet
Как видно из приведенного выше написания, региональный уровень в нем ни-
как не отображается. Иногда принадлежность к данному региону можно опреде-
лить по номеру сети, например сеть 5049 во второй зоне принадлежит региону 50,
все сети в нем имеют четырехзначный номер и начинаются на 5 или 6. Но для
всей FidoNet это правило не является общим.
Концепция географического деления FidoNet на зоны, активно обсуждавша-
яся в течение 1986 года, была введена в употребление в конце 1987 года, в свя-
зи с чем к адресу слева через двоеточие был добавлен номер зоны. В настоящее
время адрес выглядит так: 2:5049/12. Цифра 2, отделенная двоеточием от ос-
тального адреса, означает номер зоны (вторая зона - Европа, включая страны
бывшего СССР).
На поверхности земного шара зоны распределены в соответствии с табл. 1.2.
В том же 1986 году участник сети, носивший псевдоним Килгор Траут (Kilgore
Trout) имевший адрес 107/7, предложил решение проблемы использования FidoNet
коммерческими пользователями, а также теми, кто хотел бы временно подклю-
читься к сети или просто пользоваться сервисом FidoNet, не включая сведения
о себе в нодлист. Предложение сводилось к предоставлению сервиса подобным си-
стемам через одного из участников сети. Последний выдавал адреса своим пользо-
вателям, взяв за основу свой адрес и добавляя к нему справа еще одно цифровое
поле - номер конкретного пользователя. В качестве разделителя была использова-
на точка (.), поэтому для такой системы используется термин «point» (пойнт, точ-
ка). Вот как выглядит мой домашний Fido-адрес: 2:5049/12.12. Завершающее число
«12» - номер домашней пойнт-системы. Таким образом, это адрес 12-го пойнта 12-
го узла сети 5049 второй зоны FidoNet.
Пойнт - это начальная стадия подключения к FidoNet, почти все начинают
с получения пойнтового адреса у какого-нибудь из узлов. Как правило, если
значение этого поля равно нулю, его просто опускают, то есть записывают ад-
рес в виде 2:5049/12@fidonet. Последнее символьное поле, отделенное от адре-
са знаком @, означает организационную принадлежность системы к адресному
пространству (домену) сети FidoNet. Есть и другие сети, работающие на техно-
логии FidoNet, и это поле применяется при маршрутизации почты между таки-
ми сетями. Дело в том, что к концу 80-х годов технология FidoNet стала популяр-
на, с ее использованием и на ее принципах были созданы и успешно работали
сети, организационно к FidoNet не принадлежащие. Появилась необходимость
Таблица 1.2. Географическое распределение зон FidoNet
Номер зоны Территория
1 Северная Америка
2 Европа и страны СНГ
3 Океания (Австралия и Новая Зеландия)
4 Южная Америка
5 Африка
6 Азия
передачи почты между этими сетями и FidoNet через специальные системы -
почтовые шлюзы (gateways).
Для того чтобы отличать адреса разных сетей, в 1989-1990 годах было введено
понятие домена (domain), родственное домену Internet, но отличное от него. При-
страивание обозначения домена справа к адресу FidoNet несколько нарушает по-
следовательность отраженной в нем иерархии построения сети, однако попытка
размещения обозначения домена слева (проект стандарта FidoNet FSC-0065) не
удалась. При использовании адреса изнутри FidoNet обозначение домена, как
правило, опускают. Внутри FidoNet все эти формы записи - 2:5049/12.0@fidonet,
2:5049/12@fidonet и 2:5049/12 - эквивалентны. В переписке для краткого указа-
ния адреса также часто используются и устаревшие «одномерные» (1-D), и «дву-
мерные» (2-D) формы вроде 12, /12 или 5049/12.
Три кита FidoNet: ZMH, nodelist, FidoNews
Есть несколько понятий, без которых существование FidoNet было бы невозмож-
ным, без них FidoNet была бы хаотическим набором BBS, изредка предпринимаю-
щих попытки (в основном неудачные) передать друг другу почтовые сообщения.
Эти важнейшие «краеугольные камни», на которых стоит сеть, перечислены в заго-
ловке данного раздела. Особое значения имеют первые два - ZMH (Zone Mail Hour,
зональный почтовый час) и nodelist (нодлист), или список узлов FidoNet. Третий,
FidoNews, официальный электронный журнал FidoNet, важен как объединяющий
сеть поток информации, но в основном для той части сети, где родным языком ее
участников является английский. Почтовый час, ставший с появлением структур-
ного деления сети на зоны зональным почтовым часом, - это время, когда все сис-
темы в сети приступают к передаче почты. Пересылать какую-либо информацию,
кроме личных сообщений (например, файлы, эхо-почту), во время ZMH запреще-
но. Чтобы попытки установить связь не заканчивались неудачей, вызывающая сис-
тема должна иметь сведения о времени работы системы, на которую она собирается
передать почту. Обеспечивая эту возможность, каждый системный оператор, под-
ключаясь к FidoNet, берет на себя обязательство раз в сутки в течение определенно-
го времени включать свою систему в ожидании звонка. Это время равно минимум
одному часу и установлено для каждой зоны так, чтобы на всей ее территории оно
по возможности приходилось на ночные часы (подробнее проблема ZMH рассмот-
рена далее в этой и второй главах).
Nodelist. Список узлов сети, в котором записаны адреса, телефоны, имена, гео-
графическое расположение и много другой полезной и бесполезной информации.
Нодлист с самого зарождения сети был ее основой. На протяжении 15-летнего су-
ществования FidoNet его формат менялся и соответственно модифицировалось
программное обеспечение. Своевременное распространение и правильное состав-
ление нодлиста имеют исключительно важное значение для существования сети;
можно сказать, что нодлист - это и есть FidoNet. Формат нодлиста, сборка его из
сегментов, способ распространения по сети подробно рассмотрены в главе 2, а из-
менения в формате, связанные с использованием TCP/IP технологии для нужд
FidoNet - в главе 10.
FidoNews. FidoNews - это текстовый электронный журнал, издаваемый с 1984
года каждую неделю. Долгое время редактором FidoNews был основатель сети Том
Дженнингс, FidoNews - его идея. Дело в том, что FidoNet образца 1985 года была
сетью для передачи личной почты, конференции еще не были изобретены. Поэто-
му периодическое электронное издание, в котором участники сети могли бы об-
суждать свои проблемы, было необходимо.
И сейчас еще большинство узлов FidoNet регулярно получают FidoNews,
хотя для России значение этого английского журнала невелико - читается и об-
суждается он мало. FidoNews будет подробно рассмотрен далее в этой и второй
главах.
Маршрутизация почты (netmail routing)
В первые годы существования FidoNet была очень проста и почта между система-
ми передавалась напрямую. Однако развитие сети, появление территориально
распределенных локальных сетей потребовали разработать такой механизм пере-
дачи почты, который позволил бы минимизировать затраты и время связи; таким
механизмом стала маршрутизация почты (netmail routing).
Для того чтобы сравнить новую схему передачи почты с прежней, обратимся
к рис. 1.6. Здесь изображены два возможных варианта передачи почты FidoNet
между удаленными сетями. Под удаленностью в данном случае понимается при-
надлежность этих сетей различным телефонным регионам, и, как следствие, -
существенная плата за телефонные звонки при установлении связи между ними.
Каждая сеть состоит из нескольких узлов (сеть А - пять узлов, сеть Б - четыре
узла), причем один из узлов в каждой сети помечен как Host и имеет адрес узла /0.
Этим термином (и адресом) в FidoNet обозначается система, сисопом которой
обычно является сетевой координатор (Net Coordinator, NC). Предположим, что
в первой сети системы с адресами А/2 и А/4 имеют почту для системы Б/1 вто-
рой сети, хост-система А/0 первой сети имеет почту для хост-системы Б/0 второй
сети, а во второй сети узел с адресом Б/2 жаждет передать почту на А/3.
При использовании директной прозвонки (вариант 1) системы обеих сетей сде-
лают в течение ZMH по крайней мере четыре телефонных междугородних звонка.
Оплата за каждый такой звонок будет включать не только время передачи почты,
но и время, в течение которого модемы устанавливают связь и, наконец, время
установления соединения между почтовыми программами. В сумме для всех си-
сопов обеих сетей это будут значительные затраты.
В варианте 2 узлы сетей А и Б пользуются ресурсами хост-компьютеров.
В каждой сети узел, желающий отправить почту вовне, отправляет ее на хост-
компьютер своей сети, а тот переправляет на хост-компьютер сети, где располо-
жена система, которой адресована почта. В данном примере системы А/2, А/3
и А/4 отправляют почту для сети Б на компьютер А/0. Система А/0 пересылает
всю эту почту одним пакетом на Б/0, который звонит на Б/1, доставляя почту
по адресу. Общее количество телефонных звонков в примере 2 равно семи, но
только один из них междугородний. И несмотря на то, что общее время на связи
в течение этого звонка несколько больше, чем в случае 1, поскольку больше сам
объем почты, все же выигрыш значителен. Вопрос оплаты междугородних звон-
ков в складчину (так называемый костшаринг, от англ, costsharing), обсуждает-
ся далее в главе 2.
Реальные схемы маршрутизации существенно более сложны, чем рассмотрен-
ная выше, и различаются в разных регионах FidoNet. В регионе 50 маршрутиза-
ция часто используется и в пределах одной сети из соображений удобства и ми-
нимизации времени связи. Подробное изложение особенностей передачи личной
почты по сети приведено в главе 7.
FidoNet Policy, или Как стать узлом
История Полиси
Personally, I consider «policy4»
to be a smelly old crock of shit...
Tom Jennings
Значение Полиси для существования FidoNet чрезвычайно велико. Каждый участ-
ник сети должен время от времени перечитывать Полиси, чтобы во взаимоотно-
шениях с другими участниками сети действовать в соответствии с духом и тради-
циями FidoNet. Первое, что вы должны сделать, чтобы подключиться к FidoNet
после того как настроите программное обеспечение, это изучить Полиси, которая
содержит подробнейшие инструкции по подключению к сети. Полный текст этого
документа на русском языке приведен в приложении 2. Для того чтобы лучше
осознать сущность Полиси, вновь обратимся к истории сети.
FidoNet долгое время оставалась в высшей степени неформальным, анархичес-
ким сообществом. Не существовало никакого соглашения, которое явно или не-
явно определяло бы правила существования сети. Сначала в нем действительно
не было необходимости, все знали друг друга лично; но вскоре потребовался хотя
бы какой-нибудь документ, чтобы сэкономить время, потраченное на объяснение
специфики сети новому ее участнику.
Таким документом в начале 1985 года стал знаменитый файл fidohist.doc, авто-
ром которого является Том Дженнингс (см. «Евангелие от Тома»). Документ озаг-
лавлен «История FidoNet под редакцией Тома Дженнингса», но на самом деле он
содержит не только изложение истории сети, а и сложившиеся к тому времени
правила и обычаи и является хорошим руководством для нового участника сети
FidoNet образца 1984 года. В файле fidohist.doc, расширенном и дополненном во
второй половине 1985 года, содержалась следующая информация:
□ история возникновения FidoNet;
□ цели FidoNet, ее некоммерческий характер;
□ правила получения узлового адреса, форма заявки;
□ правила поведения в сети (в основном это касалось правил обновления свое-
го адреса в нодлисте);
□ структура сети, маршрутизация почты;
□ правила выделения блоков адресов для частных сетей;
□ куда обращаться при затруднениях.
В то время, когда размер сети не превышал две сотни узлов, этих правил, ис-
полнение которых не считалось строго обязательным, было достаточно. Однако
с появлением местных сетей и дальнейшим увеличением FidoNet потребовалось
более связное, формализованное, точное и последовательное изложение правил
существования сети, чем мог предоставить fidohist.doc. В самом начале 1986 года
была составлена и распространена по сети первая версия файла policyl.doc,
содержавшего очень важный для судьбы FidoNet документ. Первая версия
Полиси (FidoNet Policy, или устава FidoNet) была для своего времени большим
достижением. Неоднократно дополняемая и изменяемая, Полиси играла и игра-
ет для FidoNet ту же роль, которую выполняет конституция в государственном
устройстве.
Соблюдение требований Полиси не всегда было обязательным. Полиси вер-
сий 1-3 носят наименование FidoNet Policy Guide, как бы подчеркивая, что это
всего лишь рекомендательное руководство. Начиная с 1989 года, когда была введе-
на в употребление ныне действующая Полиси версии 4.07, выполнение основных
ее положений стало обязательным требованием. Сейчас принадлежность к FidoNet
автоматически означает согласие с основными положениями Полиси, причем
при подключении к сети требуются письменные уверения в этом (разумеется,
речь идет об электронном документе).
В отличие от первых версий Полиси, действующая сейчас форма содержит гораз-
до больше слов типа «обязан», «должен» и т.д. Отчасти этим, вероятно, объясняется
вынесенное в эпиграф к разделу высказывание Тома Дженнингса, в котором он
выразил свое отношение к Полиси версии 4.
Несмотря на то, что некоторые положения Полиси обязательно должны соблю-
даться участниками сети, эти требования настолько же ограничивают свободу
личности, насколько предписание ехать по нужной стороне дороги сковывает
свободу передвижения автомобилиста. Основную идею сосуществования членов
сети, изложенную в Полиси 4.07, можно свести к простому правилу: «не раздра-
жайся слишком легко и старайся не задевать других». Подробный разбор основ-
ных положений Полиси содержится в главе 2.
Политика в FidoNet
Disagreement is actually necessary,
or we'd have to get in fights
or something to amuse ourselves
and create the requisite chaos.
Tom Jennings
Большие размеры FidoNet, наличие развитой структуры координаторов, амбиции
некоторых участников сети формируют то, что иногда называют «политикой
в FidoNet». Обычно под этим понимается участие в обсуждениях тех или иных
документов на уровне сети, региона или зоны, конкурентная борьба за занятие
должностей координатора того или иного уровня, выполнение работы координа-
тора высокого уровня (региона или зоны). Содержание политики FidoNet далеко
от того, что понимается под этим термином в реальной жизни. Должность коор-
динатора в FidoNet не приносит никаких выгод и не дает дополнительных прав,
только обязанности. Власть координатора эфемерна. Тем не менее столкновение
интересов, различные представления участников сетей о том, какими они долж-
ны руководствоваться правилами, порождает иногда настоящую конкуренцию за
занятие должности координатора. В последние несколько лет сетевые и регио-
нальные координаторы во второй зоне FidoNet выбираются общим голосовани-
ем участников координируемого сообщества. Классическая FidoNet, как она
постулирована в Полиси, практически не использует выборы для заполнения
вакантных должностей координаторов. Принятие на уровне второй зоны доку-
мента NC_ELECT вызвало к жизни выборную активность во многих сетях ре-
гионов зоны; сам документ представлен в приложении 12, а его обсуждение -
в конце этой главы.
Можно ли изменить Полиси?
Поскольку, начиная с 1989 года, Полиси является во многих своих положени-
ях обязательным к исполнению документом, то и принятие изменений к нему
строго регламентировано. Отдельные изменения не принимаются, голосуется
целиком новая версия. Голосование по новой версии Полиси производит уже
упоминавшийся ZCC по представлению большинства региональных коорди-
наторов.
Учитывая, что новая версия Полиси с момента вступления в действие (1989)
остается неизменной, такой подход следует считать неудачным.
Попытки изменения Полиси, подготовки новых ее версий делались неоднократ-
но, однако ни одна из них не была даже доведена до голосования. Текущая версия
во многом не отвечает требованиям времени, она просто устарела. В 1989 году, на-
пример, Internet для нужд FidoNet не использовался так широко, как сейчас, и сама
сеть была немногочисленна, выборы координаторов были редки и т.д. Многолет-
ние неудачные попытки изменения Полиси представляют собой одну из проблем
FidoNet, и эта проблема обязательно должна быть разрешена, иначе сеть обречена
на вымирание.
Стандарты FidoNet
Технология FTN (FidoNet Technology Network)
FidoNet росла как придорожный куст - сама собой. Никто не вкладывал в нее боль-
ших денег, не создавал ее как единый проект. Тем не менее к началу 90-х годов офор-
милось то, что теперь называют FTN-технологией. Это стандарты и рекомендации,
написанные участниками сети на основании их личного опыта и подвергнутые
чему-то вроде экспертной оценки в специальном комитете, работающем на обще-
ственных началах, - FidoNet Technical Standards Committee (FTSC). Большинство
стандартов используется при написании реальных программ. Есть стандарты уста-
ревшие, бесполезные и даже курьезные. Часть документов имеет статус действую-
щих стандартов и обязательна к исполнению разработчиками программного обес-
печения для FidoNet - FTS (FidoNet Technical Standards). Другие (их большинство)
существуют в виде рекомендаций. Они выпускаются упомянутым выше комитетом
и носят название предложений FSC. Все стандарты и рекомендации FidoNet можно
получить в Internet: http://ftsc.fidonet.org.
Это может пригодиться
Некоторые стандарты на форматы данных FTN окажутся необходимыми, если вы ре-
шите заняться разработкой программного обеспечения для FidoNet. Если же вы про-
сто используете сеть как средство коммуникации, большинство стандартов и предло-
жений (их всего около сотни, список приведен в приложении 1) вам совершенно не
нужны. Желательно ознакомиться только с наиболее важными стандартами:
□ описание формата нодлиста: FTS-0005, FSC-0062;
□ спецификация эхо-почты: FTS-0004 вместе с FSC-0057, FSC-0068 и FSC-0074;
□ описание доменной структуры и шлюзов в другие сети: FSC-0004 вместе
с FSC-0034, FSC-0038, FSC-0070. FSC-0078;
□ описание идентификатора сообщений FidoNet (MSGID): FTS-0009, FSC-0083.
Кроме того, ценная информация содержится и в других базовых документах
FidoNet, а именно: в Полиси и в нодлисте (в его начале и окончании). Перевод
и обсуждение наиболее важных стандартов вы найдете в главе 2.
«Вредные» советы: устаревшие и курьезные стандарты FTN
Среди стандартов и предложений FidoNet много устаревших и ненужных, неко-
торые из них мешают развитию сети, другие могут ввести в заблуждение при
разработке программного обеспечения. Примером устаревшего и тормозящего
развитие FidoNet стандарта отчасти является даже первый базовый стандарт -
FTS-0001. В нем подробнейшим образом описан открытый (без использования
парольной защиты) обмен почтой между двумя FTN-системами с использовани-
ем много раз модифицированного протокола передачи файла Xmodem, изобретен-
ного в конце 70-х создателем BBS Бардом Кристиансеном. Назначение стандарта
очевидно: две произвольные системы должны иметь простой протокол для обме-
на почтой, если все попытки соединения на более совершенных протоколах по-
терпели фиаско. Тем не менее выбор FTS-0001 неудачен; это плохой, устаревший
протокол, неустойчиво работающий на скоростях выше 2400 бод и при использо-
вании асимметричных протоколов соединения типа HST [1.3], к тому же он не
допускает обмена паролями, что позволяет атаковать любую систему, поддержи-
вающую FTS-0001. Однако до сих пор этот стандарт считается общепринятым,
хотя используется на практике редко, и даже слышатся голоса, предлагающие
утвердить его в качестве стандарта при соединении через Internet, где он совер-
шенно бесполезен.
Из основных семи действующих стандартов FidoNet еще три (FTS-0006, FTS-
007 и FTS-008) также малоинтересны и описывают редко используемые протоко-
лы передачи файлов.
Некоторые стандарты остались неиспользованными; идеи, высказанные в них,
не понадобились разработчикам программного обеспечения для FidoNet. Таковы
документы FSC-0007, FSC-0020, FSC-0055, также проект стандарта FSC-0069,
относящийся к 1992 году и содержащий предложение реализовать схему рас-
познавания имен (DNS service) аналогично работающей в TCP/IP сетях, но на
основе off-line сети FidoNet. Сейчас такое предложение может вызвать только
улыбку (описание Fido DNS в главе 10).
FidoNews 15 лет каждую неделю
Ранее уже упоминался электронный журнал FidoNews, который издается каждую
неделю в виде текстового файла и распространяется по сети, как правило, с ис-
пользованием механизма файловых конференций (file-echo FIDONEWS).
Полный архив всех FidoNews в Internet можно найти по адресу:
http://fidonews.org
FidoNews, как и эхо-конференции FidoNet, роль которых долгое время выполнял
этот журнал, не слишком официозное издание. Ниже приведены отрывки из редак-
ционной статьи Тома Дженнингса к первому выпуску FidoNews в декабре 1984 года:
fidonews.man - 04 Дек. 84 00.56:08 Стр. 1
Том 1, Номер 1 1 Дек. 84
Редактор: Tom Jennings
Издатель: Fido # 1
ГОРЯЧИЕ НОВОСТИ
ПЕРВОЕ ИЗДАНИЕ НОВОСТЕЙ FIDONET
Ну наконец-то оно сделано... Fido-новости, журнал группы пользователей FidoNet, стал реаль-
ностью. Он будет публиковаться раз в неделю, возможно, раз в две недели, если я буду занят.
Есть по крайней мере три постоянно выпускаемых издания: список узлов, список членов
сети и маршрутный лист. К счастью, самое интересное появилось напоследок. Сейчас у вас есть
причина получать Fido-новости.
Я, Том Дженнингс, случайно оказался редактором. Я НЕ хочу быть редактором; у меня есть
чем заняться кроме этого. См. раздел НУЖНА ПОМОЩЬ. (Без шуток.)
Мы (кгхм-м) также и издателя разыскиваем; пока им буду тоже я. Найти незагруженный раз-
дающий хост было бы замечательно. Это не сиюминутная проблема, думаю, как и поиск ответ-
ственного редактора.
*Любые* статьи и т.д. принимаются от пользователей: все и вся, как обычные документы
FidoNet, (коротко говоря) идеи, проблемы, вопросы, примеры, программы, аппаратное обеспе-
чение и т.д. - пожалуйста. См.: СТАТЬЯ (sic).
Распространение пока подвешено в воздухе. Новости будут разосланы по крайней мере на
шесть хостов по стране. Прямо сейчас они доступны на #1 и #51. Возможно, где-нибудь в них
вы (скоро) найдете статью про распространение.
Как видно из приведенного отрывка, стиль написания статей и писем в FidoNews
совершенно свободный. Язык FidoNews - английский, это обязательное условие.
В первые годы FidoNet, когда еще не существовало механизма эхо-конференций,
в FidoNews обсуждались не только и не столько проблемы сети; он служил мес-
том, где участники Fido обменивались мнениями по всем околокомпьютерным
темам. В старых выпусках FidoNews можно встретить описание приемов програм-
мирования, нового для тех лет компьютерного оборудования, карты прерываний
для операционной системы DOS и тому подобную «муть». С 1988 года, когда эхо-
почта решила проблему массовой коммуникации в FidoNet, этот журнал в боль-
шей степени посвящен проблемам сети. Традиционными для FidoNews являются
колонка редактора, анонсы новых стандартов, колонки постоянных авторов, рек-
лама эхо-конференций, BBS. Объем журнала небольшой: как правило, 40-50 Кбайт
(обычно 20-30 страниц).
Хотя по традиции FidoNews издается в первой зоне, то есть в Соединенных
Штатах, и большинство публикуемых материалов так или иначе связано с проб-
лемами североамериканского Fido, все же участникам FidoNet, если они хотят
быть в курсе происходящих в ней событий, обязательно нужно просматривать
FidoNews. К сожалению, не существует перевода FidoNews на русский язык (есть
выпуски на эстонском и шведском, но вам ведь они без надобности, не так ли?).
Разговоры о выпусках русскоязычной версии FidoNews, отражающих специфику
нашего региона, идут в течение уже нескольких лет, но пока не привели к долгож-
данному результату.
Как опубликовать свою статью в FidoNews
Публикация в FidoNews - это наилучший способ донести свое мнение до всей
сети. Правда, придется перевести текст на английский. Требования к статьям,
предлагаемым для публикации, подробно изложены в файле arrspec.doc, рас-
пространяемом время от времени вместе с потоком FidoNews, и вкратце тако-
вы (далее сокращенный пересказ artspec.doc):
Тема. Все, что, на ваш взгляд, может быть интересно участникам FidoNet. Это
не обязательно технические вопросы, преимущество отдается важным для
FidoNet статьям, технологиям и их использованию, другим сетям, социальным
аспектам коммуникаций, этническим выпускам и другим смежным темам.
Размер. Присылайте статьи покороче, лучше разбить большую статью на не-
сколько маленьких. Это связано с принятым ограничением на длину одного вы-
пуска - не более 100 000 байт.
Правила. Тема статьи должна быть ясна не только вам, но и читателям. Нужно
представиться, сообщить что-либо о себе. Если вам нужно срочно выпустить
статью, прямо сообщите об этом редактору. Если вы присылаете статью по элек-
тронной почте, то она должна включать все технически требуемые линии размет-
ки (см.: «Технические требования»); имя файла статьи должно быть указано в за-
головке (subject) письма. От вас могут запросить изменения и дополнения, так
что будьте к этому готовы.
Технические требования. Статья должна быть помещена в текстовый файл и по-
слана по адресу l:l/23@fidonet, имя файла соответствовать стандарту MS DOS
(8 символов - длина имени и 3 - расширения файла, только буквы латиницы или
цифры). Тип файла должен отражать содержимое статьи:
.LET Письма редактору
.ART Статья, комментарий, открытое письмо, новости
.COL Регулярно посылаемые статьи («колонки»)
.ANS Ответ на Вопрос Недели
.ВЮ Ваша биография
.HIS Исторические материалы FidoNet
.REV Сообщения о связанных с Fido продуктах, сервисах, программах
JOK Сетевой юмор
.СМХ Комиксы в ASCII
.AD Реклама бесплатного сервиса
.SAL Продаю
.WAN Куплю
.NOT Примечания в конце выпуска (лучше короче)
.INT Адреса Internet Web-страниц FidoNet
Если ваш файл не имеет расширения, он может просто потеряться.
Когда. FidoNews выходят каждую неделю по понедельникам. Статьи для теку-
щего номера принимаются до 6:00 московского времени предыдущей субботы.
Если вы опоздали с посылкой своей статьи, не волнуйтесь - она будет обработана
на будущей неделе.
Наборы символов. Левого поля в вашей статье делать не следует. Начинайте
текст с первого столбца. Правое поле не должно превышать 70 символов. Не встав-
ляйте лишних пробелов и специальных символов для выравнивания правой
границы текста. Каждая строка должна заканчиваться стандартно: CR/LF (стан-
дарт MS DOS) или LF (стандарт).
Формат. Ниже приводится пример гипотетической статьи, взятый из упомя-
нутого выше файла artcpec.doc:
*А Sample Article [this is in LINE 1 starting at COLUMN 1]
This is My Title
by Ivan I. Ivanoff, [2:5049/12.99/ivanoff@fidonet.kazan.ru]
And here is my article. Note that it is flush left (zero indent).
Also note that the right margin is at column seventy so that it
won't overflow «most» text windows. Each line has a newline.
Note the *'ed first line. My article will be listed in the table
of contents exactly as it appears after the * above.
Figure 1. Table 1.
+-----------+ ======
| A Box | Alpha
+-----------+ Bravo
Note that we am not using any funny-o characters. This ensures that the final article will look the
same to every user, no matter what sort of hardware he has.
This is the last sentence of our article.
Из образца видно, что строка, начинающаяся со знака *, является строкой для
оглавления FidoNews. Для отделения абзацев используется пустая строка. Необхо-
димо также проверить пунктуацию, грамматику и орфографию - пишите простым
языком, пользуйтесь программами проверки правописания. Не пытайтесь присы-
лать уже опубликованные материалы, особенно защищенные авторскими правами.
Приведенный выше образец, содержащий дополнительные сведения о прави-
лах оформления статей в FidoNews, сознательно не переведен на русский язык.
Если вы не владеете английским языком, то вряд ли вам удастся поместить свою
статью в FidoNews.
Что дает FidoNet
FidoNet возникла как сеть лично знакомых людей. Взаимный сервис обмена почтой,
который они предоставляли друг другу, не регламентировался никакими докумен-
тами и тем не менее оказался жизнеспособным и дал начало большой сети. Теперь
мало кто в огромной сети знает друг друга. Ваше письмо или файл, путешествуя по
FidoNet, проходит иногда десятки систем, сисопы которых вовсе не слыхали о ва-
шем существовании. Они работают, тратя свое личное время на обеспечение функ-
ционирования сети, не получая за это никакого вознаграждения. Несмотря на это,
все сервисы FidoNet работают надежно, а при потере почты и других затруднениях
вы почти всегда можете получить квалифицированный и подробный отчет или кон-
сультацию от всех сисопов, ответственных за прохождение вашей почты или полу-
чение почты от ваших корреспондентов.
Однако необходимо всегда помнить, что весь предоставляемый сервис бесплат-
ный, добровольный, что все это «от щедрот». Поэтому не стоит требовать якобы
причитающегося вам по праву немедленного ответа, срочного исправления и т.д. j
Будьте предельно вежливы и корректны, даже если вы убеждены, что кто-то из ;
членов сети допустил халатность в обращении с вашей почтой. Внимательно изу-
чите Полиси и эту книгу, чтобы лучше понимать обязанности узлов, хабов и хос-
тов сети и их ответственность по доставке почты, перлюстрации вашей коррес-
понденции, ее публикации в эхо-конференциях без вашей санкции и т.п. В случае
если у вас не получается взаимодействие с тем узлом, который предоставляет вам
сервис FidoNet, просто выберите другого аплинка или босса.
Передача личной почты
Личная почта - это именно тот сервис, ради которого в свое время и была создана
FidoNet, долгое время он был основным и единственным. Подобный сервис в мире
глобальных сетей получил название электронной почты (E-mail). В FidoNet эта
услуга называется сетевой почтой (netmail). Умение обращаться с нетмейлом -
первое, что вы должны освоить при подключении к FidoNet. Ближайшим анало-
гом нетмейла в обыденной жизни является письмо в незапечатанном конверте.
Именно незапечатанном, поскольку Полиси фактически разрешает перлюстра-
цию транзитного нетмейла; это делается с целью выявления попыток передачи
нежелательной информации, например коммерческого характера (сеть FidoNet
некоммерческая, и ее ресурсами нельзя пользоваться для получения выгоды), или
незаконной переписки (как вам понравится, если через вашу систему будет про-
ходить переписка террористических организаций?). По аналогичным причинам
Таблица 1.3. Основные компоненты почтового сообщения FidoNet
Название поля Примечания
Имя сисопа системы-отправителя Обычно соответствует нодлистовому имени сисопа, в общем случае произвольно
Адрес сисопа системы-отправителя Должен совпадать с нодлистовым адресом
Дата и время отправки Проставляется автоматически при отправке; может отсутствовать
Имя сисопа системы-получателя Обычно соответствует нодлистовому имени сисопа, в общем случае произвольно
Адрес сисопа системы-получателя Должен совпадать с нодлистовым адресом
Дата и время получения Проставляется автоматически при получении; может отсутствовать
Атрибуты сообщения Описание атрибутов см ниже в этом разделе и в главе 7
Текст Длина текста ограничена возможностями программного обеспечения. При невозможности обработки длинного сообщения оно автоматически разбивается на несколько сообщений меньшего объема либо отбрасывается
Служебные строки Предназначены для идентификации сообщения и устранения затруднений при передаче почты. См. описание в главе 7
Tearline Идентификационная строка редактора сообщений; может отсутствовать
Origin Идентификационная строка (может быть исправлена при настройке редактора сообщений) и адрес системы-источника сообщения; может отсутствовать
не стоит шифровать свою почту, обычно это рассматривается как некоррект-
ное поведение. (В главе 2 описываются правила использования шифрованной
почты в FidoNet.)
Сообщение FidoNet включает следующие поля (табл. 1.3):
Пример почтового сообщения FidoNet:
============================ Netmail Area ==============================
From: Amir Shabashvili 2:5049/12 11 Sep 98 10:09:34
To: Dima Balzer 2:5049/99.99 11 Sep 98 11:11:04
Subj: Hello!
Hello Dima!
Replying on message from Dima Balzer to Amir Shabashivili:
DB> Как поживаете, Amir?
Замечательно. Я договорился: тебя возьмет пойнтом /49. Можешь настраивать на адрес 5049/
49.99 и писать ему письмо с просьбой о линке.
Cheers,
Amir ashabash@mail.ru
— FleetStreet 1.18+
* Origin: Double Dozen [http://argus.zarech.ru/FidoNet/ashabash] (2:5049/12)
Программы подготовки сообщений
Для составления писем используются программы, называемые программами-ре-
дакторами сообщений (Mail Editors). Примеры подобных программ:
□ Gold Editor (DOS, Win32 и OS/2);
□ TimEd (DOS, OS/2);
□ MadMed (DOS, OS/2, Win32);*
□ Fleet Street (OS/2).
Программа составления сообщений - это основная программа, с которой вы
будете взаимодействовать; в каком-то смысле это и есть интерфейс пользователя
сети. Выбор программы-редактора сообщений во многом определяет удобство
использования FidoNet. Справиться с этим вам поможет глава 12, где описаны
наиболее популярные программы редакторов FTN почты.
При составлении сообщения вам не нужно будет мучительно соображать, куда
поставить адрес, а куда - имя сисопа, разбираться в атрибутах письма и служеб-
ных строках. Большая часть этих параметров проставляется автоматически или
же их набор автоматизирован. Вам нужно знать адрес пункта назначения письма
или имя сисопа станции. Правильно настроенная программа составления сооб-
щений с использованием нодлиста поможет вам быстро найти недостающую ад-
ресную информацию.
Атрибуты сообщения FidoNet
Атрибуты сообщения, проставляемые в его заголовке частью автоматически, по
умолчанию, а при необходимости от руки с помощью программы-редактора, по-
могают управлять следующими параметрами:
□ способом доставки письма (напрямую или через сеть);
□ срочностью доставки письма (немедленный звонок или ожидание почтовых
часов);
□ возможностью запроса дополнительных технических сообщений от транзит-
ных узлов о прохождении через них данного письма;
□ возможностью запроса от получателя письма извещения о его прочтении;
□ возможностью запроса файла с системы, на которую адресовано письмо;
□ содержанием информации о состоянии письма (Отправлено, Получено и т.д.);
□ возможностью «прикрепить» к сообщению файл;
□ содержанием диагностической информации.
Описание возможных атрибутов и особенностей их использования содержится
в главе 4.
Передача файлов с использованием личной почты
Для передачи файлов с использованием механизма транспортировки личной поч-
ты существует два способа. Оба они имеют широкое распространение, и исполь-
зование обоих существенно ограничено Полиси FidoNet.
File-attach
Атрибут FILE-ATTACH позволяет «прикрепить» к сообщению двоичный файл
и отправить его по сети вместе с сообщением. Это очень удобный, простой и эф-
фективный способ. В отличие от общепринятых в Internet способов алфавитно-
цифрового кодирования двоичного файла в тексте письма (MIME, UUENCODE,
BINHEX и др.), FILE-ATTACH не увеличивает размеров сообщения. Имя файла
помещается в поле заголовка (темы) письма.
При использовании транзитного (через несколько промежуточных узлов)
FILE-ATTACH доставка файла не гарантируется, так как в общем случае FidoNet
не поддерживает передачу файлов по сети; этот сервис не входит в число основ-
ных сервисов FidoNet.
Техническая возможность реализовать передачу двоичных файлов по сети вмес-
те с потоком нетмейла существует, и в некоторых случаях по договоренности си-
сопов этот сервис работает.
Никогда не посылайте FILE-ATTACH по сети, если только вы не уверены в под-
держке этого механизма транзитными узлами. Для пересылки файлов, если это
возможно, всегда используйте непосредственное соединение (direct connection).
Пример почтового сообщения с прикрепленным файлом:
================================ Netmail Area ==========================
From: Amir Shabashvili 2:5049/12 14 Sep 98 16:31:02
To: Evgeny Kurilny 2:5049/96 14 Sep 98 16:31:02
Subj: d:\archive\ALLFIX\KAZAN.OFF\N5049.ROU
Hello Evgeny!
Посылаю тебе файл co схемой маршрутизации почты для нашей сети.
Cheers,
Amir ashabash@mail.ru
— FleetStreet 1.18+
* Origin: Double Dozen [http://orgus.zarech.ru/FidoNet/oshabash] (2:5049/12)
Способ UUENCODE
UUENCODE - это старый, пришедший из мира UNIX способ ASCII-кодирова-
ния бинарных файлов в текст письма. FidoNet, в отличие от Internet, где обще-
принятым стандартом кодирования бинарных файлов в тело письма является
MIME, по старинке пользуется UUENCODE. Утилиты UUENCODE существу-
ют для всех операционных систем, при известном упорстве вы отыщете их. Для
того чтобы закодировать файл с помощью UUENCODE, нужно вызвать эту про-
грамму, поместив в командной строке вслед за именем вызываемой программы
имя двоичного файла, который вы кодируете, и имя файла, в котором программа
должна сохранить результат кодирования. Так работает множество утилит, вызы-
ваемых из командной строки. Подобные программы удобно вызывать непосред-
ственно из программ-редакторов сообщений. Есть также и утилиты с развитым
интерфейсом, например программа РМРгер позволяет использовать при кодиро-
вании и декодировании файлов традиционную для интерфейса OS/2 технологию
манипулирования объектами «Drag and Drop». На рис. 1.7 представлен внешний
вид рабочего окна этой программы.
Следует учитывать, что UUENCODE несколько увеличивает размер кодируе-
мого файла.
Хтобы вы могли себе представить, как выглядят файлы в кодировке UUEN-
CODE, я приведу пример почтового сообщения с закодированным методом UU-
ENCODE файлом (см. пример на следующей странице).
PMPrep 2.1
File Settings... Help
° □
c:\fido\FILE
□
D
D
D
5049ECHO.LST
ACREATE
BBS.LST
FILES.BBS
N5049.ROU
Q NOD&POIN.TXT
NODEL1FE.EXE
Q PNT5049.ZIP
а(ех
BOX
fake
FRQ
oldfiles
Outbound
RECOVER
TMP
00010001.Req
001F0044.MQ0
001F0044.TU1
0B666CE9.MO1
0B666CE9.MO2
ОВ666СЕ9.МОЗ
0B666CE9.MO4
0B666CE9.MO5
□
D
□
D
D
D
D
D
П
To decode or encode a selected file, drag and drop the file from one window to the other
Рис. 1.7. Пример кодирования файла
с использованием программы РМРгер для операционной системы OS/2
============================= Netmail Area =============================
From: Amir Shabashvili 2:5049/12 14 Sep 98 16:45:50
To: Evgeny Kurilny 2:5049/96 14 Sep 98 16:45:50
Subj: посылаю тебе файл co схемой маршрутизации почты для нашей сети:
begin 644 N5049.ROU
M.TYE=«'R.C4P-#D@<F]U=&EN9R!S8VAE;64-«CM!;6ER(%-H86)A<VAV:6QI
M+»*R.C4P-#DO/T*-3T2\Q(#@-«C4P-#DO/3(@-2"Y(#$S(#$U(#$W(#$X
M(#$Y(#zT(#zX(#zY(#0P(#0U(#0Y(#8T(#<Q(#<S(#$R/T*-3*T.2\Sz»*R
M(#8@zS(@-#$@-#(@-#@@-Czz@-SO-«C4P-#DOzS8@z2*S-R*T-BzzT-RW-2zzV
M-B"R-38@-3z/YzR]!;&P-«C4P-#DO.38@z38@-#0@-34@-3<@-3@@-Cz@-CD@
M-S*-«CXUz#0Y+S$R(#4PzCz'OzCzzT(#$Z06QL+T%L;»z'R.D%L;»]!;&P@-#l!
M;&PO06QL(#4Z06QL+T%L;»zzV.D%L;»]!;&P-«CXUz#0Y+S$R(#zZ-S<T+S8P
MHZ«EK:'@K:»LI7»EK:VN+@T*.TBEKW»NHJ5PI:VMH.\@J*WDKG»LH.:H[R»O
MKJREYZ6MH»»GK:»JKJP@(C\_/R(-«CM.970@,CHUz#0Y(&%D9&ET:6]N86P@
M<F]U=&EN9R!I;F9O<FUA=&EO;@T*.S4P-#DOZ3(@-3ZZRZ»\W.2ZZUZ#(P+S@P
M(#4PzC$Oz3$@-3U-2\T-24'Uz#@P+S@P(#$Zz38W+SzRzRz'Uz#DS+S(U(#4P
M.3ZO-C$@-3ZZYZR\RZZ'T*.S4P-#DO-#D@ZCHUZ#(P+SZP-C"@ZCHUZ#DW+SZR
M#0H[-3U.2\Sz»/zUz#DW+S$X#0H[/C4P-#DOzSzz@-3zzW-B\V(#4P-S8O06QL
M(z'T*.S\_/S(Z-3'T2\V(#(Z-3zzRz»\RzS@@#0H[/S\_zCHUz#0Y+S8@zCHU
2Z#4R+S8@ZCHUZ#4R+T%L;ZZT*
end
Cheers,
Amir ashabash@mail.ru
— FleetStreet 1.18+
* Origin: Double Dozen [http://argus.zarech.ru/FidoNet/ashabash] (2:5049/12)
Если вы ухитритесь воспроизвести приведенную выше последовательность
символов в любом текстовом редакторе, вам представится возможность восстано-
вить посланный мной некогда файл в его первоначальном виде. Делать это нужно
с помощью программы UUDECODE.
Посылать письма с UUENCODE по сети можно, но при этом доставка его
адресату также не гарантируется. Прежде всего, как отмечалось выше, FidoNet
не поддерживает передачу файлов, а UUENCODE - это именно транспорт
файлов. Далее, FidoNet не поддерживает передачу зашифрованной информа-
ции, а UUENCODE-фрагмент может быть истолкован как зашифрованное, не-
читаемое сообщение. Ниже приведен пример автоматически сгенерированного
письма-предупреждения в ответ на отправку UUE-кодированного сообщения.
============================ Netmail Area ==============================
From: ltrack+ 1.2 2:5011/13 11 Sep 98 19:06:10
To: Amir Shabashvili 2:5049/12 11 Sep 98 19:06:10
Subj: Warning: Bad UUE
Hiz Amir!
Warning! You are breaking the rules! Your message had exceeded UUE limit (8192 bytes). Never do
it again!
From: Amir Shabashvili2:5049/l 2
To: Timur Kulmukhametov 2:5011/73
Subj: выдвижение (2)
------------------------------------11 Sep 98 16:36:42
Signed: Itrack the Horrible
PS: Message was passed thru but next time it will be killed
* Origin: (2:5011/13)
В приведенном примере содержится явное указание на максимальный размер
пересылаемых UUE-кодированных сообщений (8192 байт) и пожелание более не
повторять попыток послать UUE-сообщения через этот адрес.
Никогда не пытайтесь послать по сети без согласования со всеми транзитными
узлами закодированный UUENCODE файл значительного размера - больше не-
скольких килобайт. Это может послужить поводом для вашей экскоммуникации
(отключения от сети, удаления из нодлиста).
Служебные строки
Служебные строки (kludge lines, или кладжи) обычно при чтении и написании пи-
сем невидимы; для того чтобы их просмотреть, надо включить специальный режим
отображения. На рис. 1.8 показано, как отображаются служебные строки в редакто-
ре сообщений Fleet Street для операционной системы OS/2.
Для вывода кладжей здесь использовано отдельное окно, на рисунке оно раз-
мещено на переднем плане. По имеющимся строкам можно однозначно иденти-
фицировать данное сообщение (кладж MSGID), получить информацию о редак-
торе, использованном при его создании (Gold Editor версии 3.03 beta 3), о наборе
символов (IBMPC 2), о маршруте следования письма (2:5049/57 - 2:5049/96 -
2:5049/12) и времени прохождения каждой станции. Использование служебных
строк для анализа пути прохождения письма и решения других диагностических
задач подробно изложено в главе 7.
Маршрутизация личной почты FidoNet
В самом начале появления FidoNet маршрутизация почты отсутствовала. Почта
передавалась непосредственно между системой-источником сообщения и его ад-
ресатом. Этот режим называется непосредственным (direct) соединением. Ди-
рект широко используется и сейчас, это самый простой способ связи, он удобен
для передачи файлов и больших объемов почты в пределах одной сети, когда не
нужно оплачивать междугородние или международные телефонные соединения.
Но для передачи почты на большие расстояния непосредственное соединение
слишком дорого и неэффективно. В этих случаях используется маршрутизация
почты.
Общая схема маршрута движения письма отражена в нодлисте иерархией сетей
и узлов специального назначения. Названия этих узлов - хост (host) и нетмейл-
хаб (hub) представляют собой широко используемые в области компьютерных
сетей термины и означают выделенные компьютеры, осуществляющие обработку
й-f LeetStt-eet 1.18 - SYSOP‘S_MAIL (N)______2________________________i"J5'
i File Edit Message Special Rexx Setup Windows Help
From: Adel diepckunov
To:Amir Shabashvili
Subj: diff
L Ircvcl reacJ
2:5049/57 W Sep 98 22:56:32
2:5049/12 10 Sep 98 22:56:32
ПризетА Эмир 1 Как дела? \\ А- '? > 7':
Л::
'вот' ' переезжаюИ ; на работё^с^ета^;,^; осенняя компания
опять:'.задерживается'*
Вот/такая пока-строчка: ; /Э :А//'/Э ф А*?'/;; ; А? А
<5 tel Additional message info
V3
И
@MSGID: 2:5049/57 35f85a5d
@PID: GED3 3.0. b3 2533
@CHRS: IBMPC 2
@Via UniMail/W32 0.41b 2:5049/57r 10 Sep 1998 19:57:58 UTC +0400
@Via UniMail/2 0.31/beta 2:5049/96, Thu 10 Sep 1998 20:10:10 UTC +0400
@Via 2:5049/12@FidoNet @19980911.001135.61.UTC [track- 1.3/G6
= Close
C2py I □Keep in ~ront
Рис. 1.8. Отображение служебных строк (kludge lines) в редакторе Fleet Street
и распределение информационных пакетов для сетей (хосты) или групп ком-
пьютеров (хабы).
Рис. 1.9 на примере второй зоны схематически изображает иерархию структур-
ных единиц сети, осуществляющих маршрутизацию почты FidoNet.
Сеть А имеет центральный узел, получающий почту для всей сети и имею-
щий статус «хост». Сисопом хоста сети чаще всего бывает действующий сете-
вой координатор, но иногда обязанности сисопа хоста и координатора выпол-
няют разные люди. Адрес хоста всегда /0, например в сети 2:5049 адрес хоста -
2:5049/0.
Большая часть почты сети, для доставки которой используется система марш-
рутизации почты, проходит через хост-систему. С хостом связаны один или не-
сколько сетевых хабов, которые собирают почту с узлов, конечных потребителей
системы маршрутизации. Все прилинкованные к данному хабу и получающие че-
рез него почту узлы обычно называются его подхабником.
Почту с хостов местных сетей собирает региональный нетмейл-хаб, как пра-
вило, непосредственно связанный с региональным шлюзом между сетью Internet
и FidoNet и с зональным нетмейл-хабом. Доставка сетевой почты в другие зоны
осуществляется посредством зональных шлюзов, напрямую связанных с зональ-
ным почтовым хабом.
Рис. 1.9. Иерархия структурных единиц FidoNet,
участвующих в маршрутизации сетевой почты (на примере второй зоны)
Первичным документом, отражающим схему маршрутизации почты, является
сам нодлист. Ниже приведен фрагмент сегмента нодлиста сети 2:5049 по состоя-
нию на сентябрь 1998 года (цифры телефонного номера в каждой строчке замене-
ны на символы хх:
Host,5049,Tartar_Net,Kazan_Russia,Amir_Shabashvili,xx,9600,XA,MO,V34,HST,CM
Hub,l 2,Double_Dozen,Kazan,Amir_Shabashvili,xx,9600,XW,MO,V34,HST,CM,U,NC
,5,Thinker,Kazan,Sergey_Lebedev,xx,9600,МО,ХА,V32B,V42B,U,TRE
,9,Rush_Station,Kazan,Nick_Pushkaryov,xx,9600,MO,XX,V34,U,TUF
, 13,1'Max,Kazan,Maxjwanow,xx,9600,XX,V32B,H 16,U,TTE
, 15,Silver,Kazan,Ruslan_Aglyamoff,xx,9600X,V34,V32B,U,TVE
, 16,Humpty-Dumpty,Kazan,Marat_Afanasyev,xx,9600,V32B,H 16,MO
,17,Linux_Home,Kazan,Andrew_Sherba,xx,9600,XW,MO,V34,V32B,V42B,U,TUd
, 18, Jack_the_Ripper,Kazan,Valery_Gusev,xx,9600,V34,MO,U,TSD
,34,Fat_Cat,Kazan,Serega_Grodzicky,xx,9600,V32B,MO
,38,Wily_Cat,Kazan,Alex_Pushkarev,xx,9600,MO,V34,HST,U,TOF
,39,ICL_Tech,Kazan,Vladimir_Dyatchin_Jr,xx,9600,MO,XA,ZYX
,40,Setuper,Kazan,Sergey_Nabiullin,xx,9600,XA,V32B,V42B,LO,U,TRF
,45,Haos_Zone,Kazan,Vasily_Tchekalkin,xx,9600,V34,V32B,XA,U,TUE
,49,Moon Road,Kazan,Timur_Hi-Rullin,xx,9600,V34,HST,XA,MO,CM
,73,Just_Station,Kazan,lwan_Tolok,xx,9600,V32B,V42B,XX,U,TWd
Hold,64,Flying_Dragon_Soft,Kazan,Alex_Bakhtin,xx,9600,V34,V32B,Hl 6,MO,U,NEC
, 128,TartarNet/lnternet_Gate,Kazan,Alex_Bakhtin,xx,9600,V34,V32B,H 16,MO
Hub,] 9zKremlin_WallzKazanzlldar_Shaimardanovzxxz9600zZYXzV34zMOzCM
z55z8BR_the_DELPHInzKazanzBulat_Sirazetdinovzxxz9600zXWzV32BzV42BzUzTXD
Hubz30zGuard_5tationzKazanzVlad_Spiridonovzxxz9600zXAzMOzV34zHSTzCM
Z2Z JesszKazanzMarat_Jackubovzxxz9600zV34zV32BzH 16ZMOZXA
z6zKazan_NTzKazanzNiaz_Tavabilovzxxz9600zMOzXAzV34zH5TzUzTOE
z32zThe_Evil_EmpirezKazanzStas_Batkovzxxz9600zXAzZYXzUzTPE
z41 zSynthesiszKazanzSerge_Tolstyhzxxz9600zV34zXXzllzTPe
z42zFool_On_The_HillzKazanzAndrew_Perwushinzxxz9600zXXzMOzZYXzllzTVF
z48zSCS_AdminzKazanzDani(i)l_St._Lasoukovzxxz9600zXXzV32BzV42BzMOzUzTBe
z60zHighTowerzKazanzOlegJJsichkinzxxz9600zMOzXXzV34zUzTwD
z72,MSVzKazanzSergei_Melikhovzxxz9600zV34zHSTzXXzUzTTe
z74zMystzKazanzRuslan_lsmagilovzxxz9600zXXzV32BzV42BzUzTVE
Hubz36zAutozKazanzAlex_Broninzxxz9600zV34zHSTzMOzXAzCM
Z1 zOrphan's_MemorialzKazanzVitali_Musinzxxz9600zMOzXAzV32BzV42BzllzTPG
z8/Black_Cloak,s/KazanzVasya_Porsevzxxz9600zXAzV32BzV42B
z37zTime_SliceszKazanzJalil_Gumerovzxxz9600zV34zMOzLOzUzTOE
z46zLiceum,KazanzAitugan_Hafizovzxxz9600zMOzV34zV32BzXAzCM
z47zEasyPlacezKazanzDenis_Tazetdinovzxx,9600zV34zV32BzMOzUzTWb
z65zDarkTown,KazanzAndrei_Sabantsevzxxz9600zV32BzV42BzXXzMOzUzTWE
z66zBaloozKazanzlldar_Ylyasowzxxz9600zV34zMOzXAzllzTVG
,256zTartarNet_Backbone_LinkzKazanzAlex_Bakhtinzxxz9600zMOzXAzV32BzUzTPG
Hubz96,SaigonzKazanzEvgeny_Kurilnyzxxz9600zXAzMOzCM
z44zPacificzKazanzJean-Marc_Gourierzxxz9600zXAzV32BzV42BzUzTVD
Holdz57zAnarchistzKazanzAdel_Chepckunovzxxz9600zV32BzV42BzMOzUzTcF
z58,$PRiTEzKazanzKonstantin_Boldyshevzxxz9600zV32BzV42BzXAzLOzUzTSG
,63zSherezKazanzAlex_V.Jvanovzxxz9600zV32B,V42BzMO
z69zATSzKazanzAndrey_Tsapovzxxz9600zXXzV32BzV34zUzTtD
z70zGoldenScorpionzKazanzAnton_Pirogovzxxz9600zV32BzV42BzUzTWC
Down,71 zReflectStationzKazanzRafik_Valievzxxz9600,V34zCM
Префиксами «Hub» в нодлисте помечены узлы, выполняющие функции ха-
бов. Это узлы 2:5049/12, 2:5049/19, 2:5049/30, 2:5049/36 и 2:5049/96.
Ниже строки хаба в порядке возрастания номеров записаны строки узлов,
входящих в его подхабник. Например, для 2:5049/96 это узлы 2:5049/44, 2:5049/
57, 2:5049/58, 2:5049/63, 2:5049/69, 2:5049/70 и 2:5049/71.
Центральный узел сети, ее хост, можно найти в первой строке нодлиста (не
нужно обращать внимания на префиксы «Hold» или «Down», они имеют отно-
шение к маршрутизации почты на неработающие или работающие по-особенно-
му узлы и описаны в главе 2).
Процитированному сегменту нодлиста соответствует схема маршрутизации
нетмейла, изображенная на рис. 1.10.
Система маршрутизации, как она отражена в нодлисте, не является исчерпы-
вающей и законченной; реальность сложнее.
Существуют также и дополнительные соединения между сетями, когда по-
чта для отдельных подхабников или для всей сети передается, минуя хост. Есть
Рис. 1.10. Схема маршрутизации нетмейла в сети 2:5049
и еще исключения, вроде многоуровневой структуры хабов в крупных сетях. Эти
и другие вопросы, связанные с маршрутизацией почты, подробно рассмотрены
в главе 7.
Кто и что вам должен
Если коротко ответить на вопрос данного заголовка, то прозвучит это так: ник-
то и ничего. Как же в таком случае может работать почта FidoNet? А ведь она
работает, и весьма устойчиво! Ответ заключается в следующем: функциониро-
вание сети FidoNet держится на добровольно взятых на себя обязательствах,
причем взаимных. Все должны друг другу, и никто никому ничего не должен.
Подобные взаимоотношения возможны только в условиях взаимного доверия
и внимательного отношения друг к другу. В чем-то это подобно отношениям
людей в небольшом анархическом сообществе, где свобода личности ограни-
чена только свободой других. Поэтому ставить вопрос об ответственности пе-
ред вами за доставку вашей почты в отрыве от ваших обязательств перед теми,
кто взялся ее доставлять, не имеет смысла.
Учитывая изложенное выше, перечислим основные обязательства участников
процесса роутинга (маршрутизации) почты FidoNet перед вами, рядовым участ-
ником сети. Обязанности эти существенно различаются в зависимости от вашего
статуса. Так, если вы имеете только пойнт-адрес, то единственное лицо в иерар-
хии FidoNet, доступное вам для выяснения любых проблем с доставкой почты, -
это ваш босс, то есть узел сети, выдавший вам адрес. Только он представляет вас
в сети, и только через его посредство вы должны общаться с координаторами
FidoNet по интересующим вас техническим вопросам. Если же вы имеете статус
узла, то выяснять вопросы потери почты, сбоев в ее доставке принято по цепочке:
вы задаете вопрос своему хабу, он выясняет обстоятельства происшествия на сво-
ем компьютере и транслирует вопрос дальше, на хост сети. Таким образом, по
шагам, удается восстановить путь письма и найти источник проблемы. Помогают
в этом файлы протоколов (log-files) работы всех программ, участвующих в про-
цессе обработки и передачи почты. На хостах и хабах файлы протоколов, как пра-
вило, хранятся достаточно долго - несколько месяцев и более.
Подробнее ритуал обращения с личной почтой на основании положений Поли-
си описан в главе 2.
Эхо-конференции FidoNet
До сих пор мы рассматривали FidoNet как сеть для передачи личной почты. Дейст-
вительно, FidoNet выросла из потребности в обмене сообщениями между двумя
операторами BBS. Однако с ростом сети на первый план выступила задача груп-
повой коммуникации. Ответом на нее была концепция эхо-почты, ставшей через
год после возникновения вторым основным сервисом FidoNet.
Именно эхо-почта обеспечила FidoNet столь долгую жизнь и такую всепланет-
ную популярность. Образ сети FidoNet, ее «стиль», создается благодаря существо-
ванию и активному использованию эхо-почты участниками сети.
Идея возникновения эхо-почты непосредственно связана и с FidoNet, и с сооб-
ществом BBS, для которого сначала FidoNet была всего лишь транспортом. Мно-
гие программы BBS того времени уже имели системы типа конференций или фо-
румов, разделенные на темы, где пользователи могли обмениваться мнениями
друг с другом. Но эти форумы были локальны, информация, помещаемая в них,
не передавалась от BBS к BBS, и использовать ее могли только пользователи дан-
ной BBS. Идея разделения баз конференций между различными BBS, выравни-
вания их содержимого, и привела к созданию эхо-почты.
История изобретения эхо-почты
Происхождение эхо-почты подробно изложено в документе, авторство которого
принадлежит Винну Вагнеру (Wynn Wagner), создателю почтовой системы Opus-
CBCS (второй после FIDO почтовой программы FidoNet). Вот что рассказывает
Винн (в моем сокращенном пересказе):
«Идея эхо-конференций возникла однажды на вечеринке системных операто-
ров BBS в городе Далласе. Предыстория идеи такова: в то время (1986 г.)
в Далласе жил человек, известный сисопам BBS как пользователь по прозвищу
Нил (Niel). Он был настоящим бичом для операторов BBS и успел “достать” всех
и каждого.
Однажды между пивом и пиццей Чак Лаусон (Chuck Lawson) высказал мысль,
что было бы здорово изобрести для всех сисопов в городе способ быстрого обмена
информацией о типах вроде Нила. Чак вообще любил предлагать и спорить, однако
для осуществления своих идей старался найти кого-нибудь. В данном случае
таковым оказался Джеф Руш. Во время встречи он делал какие-то пометки и спус-
тя несколько недель представил сисопам Далласа свою систему конференций, ко-
торую назвал “эхо-почта” (Echomail).
Эхо-почта - это система конференций, которая работает через систему
электронной почты FidoNet. В отличие от “списковрассылки”в Internet, которые
используют E-mail для передачи сообщений форума от места к месту, эхо-почта
также отличается от электронной почты во время чтения и написания писем.
Сообщения эхо-почты собираются в пакеты, архивируются и используют сис-
тему электронной почты FidoNet только как транспортную систему.
Сисопы Далласа начали форум, названный SYSOP, на котором очень немного по-
говорили о Ниле. Через день или два мы создали другой форум, названный нами
TECH, чтобы дать сисопам возможность обсуждать аппаратные проблемы.
Через неделю сисоп в Сан-Франциско - Харе Нехил (Haro Neghila) - попросил
о подключении. Началось распространение. Пару недель спустя эхо-почта уже
захватила Сан-Франциско, она работала от побережья до побережья [Соединен-
ных Штатов. - Э. Ш.]. Я начал форум, названный GAYNET, и другой - CLANG
(для обсуждения языка программирования С). Сисоп из Лос-Анжелеса (“Мики”)
начал форум BIBLE.»
Сейчас эхо-конференции FidoNet - один из известных и популярных сервисов
не только в самой FidoNet. Десятки тысяч пользователей Internet принимают
участие в дискуссиях эхо-форумов FidoNet через интерфейс Internet News. Это
стало возможным после запуска шлюзов между сетями FidoNet и Internet.
Однако эхо-конференции - это не только удобный и мощный инструмент об-
щения, но еще и достаточно сложный механизм, обращаться с которым нужно
грамотно и осторожно, в противном случае вы можете доставить неприятности
большому количеству системных операторов.
Краткое описание механизма работы эхо-почты и принципов управления им
приведено ниже. Подробное же руководство ищите в главе 8.
Как работает эхо-почта FidoNet
Для объяснения концепции эхо-почты введем предварительно несколько ба-
зовых понятий, без которых объяснение существа дела становится затруд-
нительным.
Эхотаг (echotag) - тема эхо-конференции, однозначно ее идентифицирующая.
Это символьная строка, которая может включать только символы ASCII. Приме-
ры: RU. FIDO . NEXTGEN, EUNET_SYSOP.
Подписка (subscription) - взаимодействие между двумя узлами FidoNet по по-
воду получения эхо-почты. Один узел может быть подписан у другого на одну
или несколько эхо-конференций. При этом один из узлов называется аплинком
(uplink) - узлом, поставляющим информацию, а другой по отношению к нему -
даунлинком (downlink) - узлом, получающим информацию. Деление на аплин-
ка и даунлинка производится в зависимости от того, какой объем эхо-почты при-
ходит с каждого из узлов. Если один узел поставляет другому большую часть
трафика данной эхо-конференции, а тот помещает в эхо-конференцию только
письма с одного (своего) узла, то первый узел можно считать аплинком, а вто-
рой - даунлинком.
Данный узел может быть по отношению к другому узлу аплинком в одной груп-
пе конференций и даунлинком - в другой.
AreaFix. Для получения писем эхо-почты узел-получатель должен сообщить
одному из узлов, распространяющих данную эхо-конференцию, о намерении по-
лучать ее. Для этого обычно используется личная почта (нетмейл). Письмо пи-
шется на имя AreaFix, на адрес узла-распространителя данной конференции. В поле
темы (subject) письма указывается заранее согласованный пароль, а в тело пись-
ма помещаются команды автоматическому обработчику запросов на подписку -
так называемому менеджеру подписки (AreaFix Manager). Команды для AreaFix
размещаются по одной в строке. С помощью этих команд можно получить спи-
сок эхо-конференций, доступных на узле-распространителе, подписаться на
выбранные конференции, отписаться от ненужных, сменить пароль для работы
с AreaFix и т.д.
Одним из результатов обработки AreaFix-запросов всегда должен быть нет-
мейл-отчет, посланный на адрес узла, написавшего запрос. В отчете содержится
информация о выполненном действии или указаны причины, по которой действие
не может быть выполнено.
Ниже в качестве примера приведено письмо с заданием вывести список всех
эхо-конференций, на которые подписан даунлинк (команда %QUERY) и подписать-
ся на эхо-конференцию WWB_SYSOP (команда +WWB_SYSOP):
============================== Netmail ================================
From. Amirko Shaab 2.5049/12.12 18 Sep 98 16 02.24
To. AreaFix 2:5049/12 18 Sep 98 17:04:06
Subj UNK1212
%QUERY
+WWB_SYSOP
— GoldED 2 50.B0822+
Далее приведен нетмейл-ответ программы-менеджера на запрос. Он состо-
ит из двух нетмейл-сообщений. В первом сообщается о выполнении запрошен-
ной команды подписки, во втором перечисляются все эхи, на которые подписан
даунлинк.
Первый ответ (сообщение о подписке на конференцию WWW_SYSOP):
=========================== Netmail ==================================
From. AreaFix 2:5049/12 18 Sep 98 17:04.06
To- Amirko Shaab 2:5049/12.12 18 Sep 98 1 7-04:06
Sub| Node change requests
Area Status
WWB_SYSOP.................. Added
— FastEcho's AreaFix
Второй ответ (реакция на команду %QUERY в виде списка эх, на которые подпи-
сан даунлинк):
============================== Netmail ================================
From: AreaFix 2'5049/12 18 Sep 98 17.04:06
To: Amirko Shaab 2:5049/12.12 18 Sep 98 17:04'06
Subj: Query request
Active areas for 2.5049/12.12
5049.INTERNET
5049.OS2
5049.SYSOP
5049HUB.INFO
KAZAN. 12.GENERAL
KAZAN.DEN-SOFT.TALK
KAZAN.ECHONEWS
KAZAN.EXCHANGE
KAZAN.GAME
KAZAN.GENERAL
KAZAN.HARD&SOFT
PVT KAZAN.PRICELIST
R50.SYSOP
RU.FIDO.NEXTGEN
RU.TECH VM
RU VM
RUSSIA_NZ
SU.FIDOTECH
SU.IP.SYSOP
SU.TRAVEL
WWB_SYSOP
21 areas linked
— FastEcho's AreaFix
Для первоначального ознакомления с принципом распространения эхо-поч-
ты, обратимся к рис. 1.11, где схематически изображена структура узлов участка
FidoNet. В него входят четыре местных сети. Сети А и С детализированы; в сети
А изображены два узла, в С - один, в остальных сетях узлы не показаны. Изоб-
ражен процесс распространения по сети эхо-письма, экспортированного с узла
А/1 сети А. Письмо распространяется в соответствии с подпиской: на узле А/1
подписаны узел А/2 сети А и узел С/1 сети С. Письмо с узла А1 экспортируется
на эти два узла. Узел А/2 экспортирует письмо двум своим пойнтам, а узел С/1
сети С - двум сетям, В и D (узлы в этих сетях не изображены), и своему аплин-
ку. Последний условно изображен как оставшаяся часть сети FidoNet, посколь-
ку именно через него письмо поступает к остальным подписчикам эхо-конфе-
ренции.
Описанная схема распространения эхо-почты чувствительна к ошибкам в кон-
фигурации программного обеспечения и нарушениям топологии распростра-
нения.
з*
Рис. 1.11. Схема раздачи эхо-почты FidoNet
На рис. 1.12 изображены возможные варианты схем распространения эхо-поч-
ты, при которых происходит многократное циклическое прохождение одного
Рис. 1.12. Ошибочные
конфигурации сети
при распространении эхо-почты
и того же письма через все или их часть узлы-
получатели данной эхо-конференции. Для того
чтобы устранить неприятные последствия по-
добных ошибок, были разработаны специаль-
ные механизмы контроля пути следования
эхо-сообщений. Основная идея заключается
во включении в состав служебной информа-
ции, передаваемой вместе с письмом, сведе-
ний о пути следования данного письма и об
узлах, на которые оно было экспортировано.
Более подробно все аспекты и механизмы
системы эхо-конференций FidoNet изложены
в главе 5.
Инерционность системы эхо-конференций
Эхо-почта проходит десятки, сотни, иногда тысячи систем. Каждая эхо-конферен-
ция описана в конфигурационном файле программы-эхопроцессора на каждой из
этих систем. Поскольку технически сеть FidoNet децентрализована и механизм
автоматического изменения настроек эхопроцессоров отсутствует, то вся система
эхо-почты оказывается чрезвычайно инерционной, когда возникает необходи-
мость изменить название (эхотаг) конференции или вовсе прекратить ее сущест-
вование. В этом случае для достижения желаемого результата просто необходи-
мы согласованные действия многих сисопов. Иногда, используя ресурсы самой
сети для информирования сисопов, этого удается добиться, но чаще координато-
ра постигает неудача.
Попытки что-либо изменить в популярной, хорошо известной эхо-конферен-
ции дают самые неожиданные результаты. Например, попытка изменения назва-
ния приводит, как правило, к появлению двух эхо-конференций с разными наиме-
нованиями, посвященным одной и той же тематике, и старая часто оказывается
более населенной, чем новая. Попытка же решительного удаления какой-нибудь
конференции иногда разбивает единую структуру ее распространения на несколь-
ко несвязанных колец. Правда, при должном упорстве координатор обычно со
временем добивается своей цели.
Какие бывают эхо-конференции
Поскольку общее количество известных эхо-конференций составляет несколько
тысяч, то способы их классификации вопрос далеко не праздный. В приложениях
5 и 6 вы найдете подробные справочники русскоязычных и некоторых известных
международных эхо-конференций FidoNet. Методика классификации сложилась
стихийно, тем не менее она общепринята в FidoNet. Это прежде всего классифи-
кация по области распространения эхо-конференции.
Локальная эхо-конференция - конференция, существующая в пределах одно-
го узла FidoNet. Полноправным хозяином такой конференции является, как пра-
вило, системный оператор узла, и подобные эхи служат для информирования
даунлинков о любых новостях, имеющих отношение к данной системе: новых
эхо-конференциях и файлах, появившихся на узле, об изменении времени рабо-
ты и т.д. Конечно же, бывают и тематические локальные конференции; каждый
волен заводить такие конференции, какие ему вздумается. Если тематическая
локальная конференция «расползлась» по многим системам, может потребо-
ваться изменение ее статуса, она постепенно перестанет восприниматься под-
писчиками как локальная. Именно так - из «локалок» - иногда «вырастают» по-
пулярные эхо-конференции. Область распространения конференции принято
так или иначе отображать в ее названии, при этом в качестве разделителя в кон-
ференциях второй зоны, а также 50-го и 46-го регионов (страны бывшего СССР),
принято использовать точку (например, RU. FIDO. NEXTGEN), а в остальной Fido-
Net вслед за первой зоной (Северная Америка) - знак подчеркивания (напри-
мер, WWW_SYSOP).
Локальная же конференция в эхотаге содержит явное указание на адрес систе-
мы. Например, на моем узле с адресом 2:5049/12 есть локальная эхо-конферен-
ция KAZAN . 12 . GENERAL.
Сетевая эхо-конференция предназначена для распространения в пределах дан-
ной территориальной сети. Обычно в эхотаге это состояние отражено фрагмен-
том сетевого адреса или наименованием местности, например 5 049 . SYSOP или
KAZAN. GENERAL. Иногда сетевые конференции широко распространяются по
всей сети, доставляются в пределах всего региона (страны), но при этом они все
равно остаются сетевыми, то есть основные участники их дискуссий проживают
в данном городе и являются членами территориальной сети, адрес которой выне-
сен в название эхи. Те же, кто издалека пишут в эту конференцию, либо связаны
дружбой с участниками данной сети, либо когда-то жили в этом городе, либо были
когда-то участниками именно этой территориальной сети. В каждой сети не так
уж много сетевых эхо-конференций, но обычно их все же не один десяток. В осо-
бенности много сетевых эх в таких больших сетях, как 5020 (Москва) или 5030
(Санкт-Петербург). В небольших сетях список будет короче. Вот, например, как
выглядит список сетевых эх в TartarNet (табл. 1.4).
Как видно из таблицы, в списке довольно много немодерируемых эх, причина
этого - в немногочисленности сети и как следствие - слабой «населенности» ме-
стных эхо-конференций. В крупных городах местных эх значительно больше: ска-
жем, эхо-конференций с префиксом «МО» (Москва) и «5020» (сеть 5020, также
расположенная в городе Москве) насчитывается порядка 150.
Региональная эхо-конференция распространяется в пределах данного региона
FidoNet. Присутствуют в ней в основном системные операторы региона, иногда -
Таблица 1.4. Список сетевых эхо-конференций TartarNet (Казань)
Эхотаг Тема Модератор
5049.BONE Обсуждение проблем Backbone 5049 NEC5049
5049.BONE.REQUESTS Сообщения о подписке на новые эхи NEC5049
5049.ECHOHUBS Net 5049 backbone-tech echo NEC5049
5049HUB.INF0 Информация от программ-роботов и хаб-мастеров сети 5049 Нет
5049.INTERNET Технология Интернет (сеть 5049) 2:5049/12
5049.0S2 OS/2 и все с ней связанное(5049) 2:5093/10
5049.POINT Разговоры пойнтов 5049 Нет
5049.SYSOP Официальная эха сети Tartar net NC5049
5049.WIN32 Обсуждение Windows NT/Windows95 в сети 5049 2:5049/49
5049.UNIX Разговоры про Unix в 5049 Нет
KAZAN.ECHONEWS Эхо-новости. Казанский выпуск 2:5049/96
KAZAN.EXCHANGE Приватный обмен, продажа, покупка 2:5049/60
KAZAN.GAME Компьютерные игры в сети 5049 Нет
KAZAN.GAME.MODEM Компьютерные игры через модем в 5049 Нет
KAZAN.131 Эха выпускников 131 школы 2:5049/49
KAZAN.CHAINIK Казанская эха для новичков 2:5049/37
KAZAN.GENERAL Основная казанская эха 2:5049/15
KAZAN.HARD&SOFT Аппаратное и программное обеспечение компьютеров, Казань 2:5049/37
Таблица 1.5. Список региональных эхо-конференций региона 50 сети FidoNet
Эхотаг Тема Модератор
R50.Bone Официальная конференция эхо-бекбона R50 R50ECz2:5058/l 3
R50.Bone.Echo Конференции эхо-бекбона R50 R50zR50ECz2:5058/l 3
R50.Bone.Hubs Хабы эхо-бекбона R50 R50ECz2:5058/l 3
R50.Sysop Официальная Сисопская эха Региона 2:50 R50Cz2:50/0
R50.Sysop.Club Для продолжения обсуждений из R50.SYSOP Alex Exlerz2:5020/443
R50.Sysop.Talk «Сисопский треп» региона 50 Robert Agababyanz2:5020/234
R50.TSC Разработка FTN софта Kirill Lebedevz2:5020/251
соседних регионов. Например, в региональных эхо-конференциях региона 50 порой
принимают участие системные операторы региона 46. Региональных конференций
немного; большая часть конференций - это национальные эхо-конференции, но
значение их как объединяющих регион технических и административных дискус-
сий чрезвычайно велико. В регионе 50 всего семь региональных эх (табл. 1.5).
Национальная эхо-конференция. Название «национальная» — условное, оно
означает прежде всего языковую принадлежность, а затем уже национальную.
Так, конференции на русском языке имеют распространение не только в Рос-
сии, но и на Украине, в Молдове, Белоруссии, Казахстане. Есть у них читатели
и за пределами бывшего СССР - в Канаде, Северной Америке, Израиле. Тем не
менее, мы будем называть их национальными. Национальные конференции
дают основной объем эхо-почты в регионах 50 и 46. Принадлежность таких
конференций отмечена, как правило, префиксом «RU» или «SU», например
SU. GENERAL. RU означает «Россия», «русский язык». Подавляющее большин-
ство этих эх русскоязычны, но допускается и английский язык - официальный
язык сети. Конференции SU - старые конференции, первоначально эта аббре-
виатура означала Южный Урал (South Ural) - колыбель российского Fido, за-
тем ее расшифровывали как Soviet Union и областью распространения этих эх
считались республики СССР. Подобное понимание действует и в настоящее вре-
мя, но новых SU-эх не создается. Все вновь создаваемые русскоязычные эхо-
конференции создаются с префиксом «RU». Всего на региональном бекбоне
(о бекбоне см. главу 8) присутствуют около 500 эх RU и 180 конференций SU.
Международные эхо-конференции не так многочисленны, как можно было бы
предположить, зная о всепланетной популярности FidoNet, однако они есть, и иг-
рают исключительно важную объединяющую роль, делая FidoNet единой сетью.
Основной язык общения в международных эхах FidoNet, как правило, английский.
По назначению международные эхи можно подразделить следующим образом:
Зональные эхо-конференции. Хорошими примерами таких эх служат ENET. SYSOP
(Зональная европейская сисопская конференция) и IP_CONNECT (обсуждение сис-
темными операторами второй зоны проблемы включения TCP/IP узлов в нодлист).
Тематические эхо-конференции. Эти многочисленные популярные конферен-
ции посвящены тем или иным животрепещущим вопросам; именно они читаются
Таблица 1.6. Международные конференции FidoNet, посвященные OS/2
Эхотаг Тема
0S2BBS Поддержка программного обеспечения BBS для OS/2
0S2D0S OS/2: DOS- и Windows- приложения
0S2D0SBBS Поддержка BBS программ для DOS под OS/2
0S2F0RSALE Форум для покупателей и продавцов О52-совместимой продукции
0S2GAMES Помощь в запуске игр под IBM OS/2
0S2HW Аппаратное обеспечение и OS/2
0S2INET Интернет и OS/2: использование и интеграция
0S2LAN OS/2 LAN эхо
0S2PR0G Программистская OS/2 эхо-конференция
0S2REXX Эхо-конференция по языку REXX
по всей FidoNet. Как правило, это старые конференции первой зоны, распрост-
ранившиеся по всему миру. Вот, например, конференции североамериканского
бекбона, посвященные обсуждению всех аспектов операционной системы OS/2
фирмы IBM (табл. 1.6).
Также международными, иногда всемирными, становятся конференции, посвя-
щенные поддержке программ, популярных в FidoNet. Каждый сисоп, использую-
щий ту или иную FTN-программу, считает своим долгом подписаться на эхо-кон-
ференцию по ней. Иногда это единственный способ получения свежей информации
о любимой программе, советов «знатоков», дружеской беседы с автором.
«Друзья по переписке» (penpals) - очень популярный тип конференций, особен-
но широко распространившийся в последнее время. Причина такого успеха -
в развитии низкостоимостных соединений Fido-систем через Internet. Основная
идея такой формы общения заключается в создании эхо-конференции, в которой
участвовали бы члены двух или более сетей FidoNet, как правило, чрезвычайно
географически удаленных. Разговоры в таких эхах крутятся вокруг погоды, сме-
ны сезонов (у вас холодно - а у нас жарко), цен, национальной специфики и т.д.
Универсальный язык общения - английский. Такова, например, популярная эхо-
конференция MOSCOW-OKLAHOMA. Она началась как penpal-эха для бесед сисопов
из России, с одной стороны, и участников сети 170 первой зоны FidoNet (город
Tulsa, штат Оклахома, США) - с другой. Сейчас в ней принимают участие сисопы
со всей России, из Латинской Америки (четвертая зона), многих сетей первой
зоны. Очень похожа на нее эхо-конференция RUSSIA_NZ, созданная усилиями эн-
тузиаста Барри Блекфорда (Barry Blackford, адрес 3:774/605) из Новой Зеландии
для общения между сисопами этой страны и участниками российского Fido.
«Тусовки» виртуального мира
Говорят, люди произошли от обезьян - животных стайных, любящих общество
своих родных и знакомых. Вероятно, если бы наши предки были бы мизантропа-
ми вроде снежных барсов или медведей, то не было бы этой толчеи, дискотек,
шумных свадеб, забитых пивных и пляжей. Но человек таков, каков он есть - нам
приятно общество себе подобных, только в нем мы ищем удовлетворения своим
амбициям, только здесь, среди людей, мы можем полностью реализовать себя.
Не так уж много прошло времени с появления мира компьютерных сетей, и с са-
мого начала все его возможности были поставлены на службу этой человеческой
страсти - страсти к общению. Сейчас, по прошествии пятнадцати лет, основные
инструменты для общения в электронных сетях устоялись, уже очевидно, что
некоторые из них будут использоваться, пока существуют компьютеры. Эхо-
конференции FidoNet тоже из этого ряда. Они появились независимо от news-
конференций сети USENet и их предшественниц - конференций ArpaNet, но
возникли практически одновременно, знаменуя собой рождение нового способа
общения людей.
Взглянем же со стороны на одну из «тусовок» виртуального мира, познакомим-
ся с ритуалами, со способами общения - они, являясь по форме произведениями
высочайшей технологии конца столетия, по сути, используются для той же цели,
что и деревенская площадь в средние века: «Поговорить охота!»
Основной ритуал и правила выживания
...Никто не владеет конечной истиной.
Следовательно, нам необходим
критический способ мышления,
нам необходимы организации
и правила, позволяющие людям
с различными мнениями и интересами
жить в мире друг с другом.
Джордж Сорос
Электронные конференции впервые появились в сети ArpaNet, предшественнице
Internet. Тогда же выяснилось, что без какого-то механизма управления содержа-
нием конференции, без чего-либо подобного цензуре обойтись трудно, а при воз-
растании количества участников конференции - просто невозможно.
USENet, а впоследствии и Internet, полностью восприняла положительный
опыт использования механизма модерирования электронных конференций, на-
копленный ArpaNet.
Традиции USENet включают понятие модерирования конференции как один из
обязательных ритуалов, поддержанных техническим решением. Конференции
делятся на модерируемые и немодерируемые. Модератором (председателем кон-
ференции) называется человек, через почтовый ящик которого проходят письма
всех участников конференции. Посланное участником модерируемой конферен-
ции письмо обязательно попадает в почтовый ящик модератора, который поме-
щает или не помещает это послание в конференцию.
Таким простым способом удается избежать ненужных дискуссий (люди, как
и их предки, любят выяснять отношения, не обращая внимания на место), и мно-
гие немодерируемые конференции буквально заливает мутная волна взаимной
грубости, хамства и пустословия. Модератор по своей сути - цензор, только в от-
личие от цензуры государственной он не представляет государственную машину
подавления. Его работа - это выражение частного мнения одного из участников
конференции (как правило, ее создателя) о том, в каком стиле и на какие темы
должны вестись в ней дискуссии.
Очень похожи на конференции USENet и в то же время существенно отличают-
ся от них по стилю модерирования эхо-конференции любительской сети FidoNet.
Отчасти эти отличия обязаны самому характеру децентрализованной сети, отчас-
ти - анархо-олигархическим традициям управления FidoNet. Так, и здесь есть мо-
дерируемые эхи, и их большинство, но модерирование в стиле FidoNet существен-
но отличается от используемого в USENet News. Модератор в FidoNet - просто
один из участников эхо-конференции, который постоянно следит за ее содержани-
ем, не имея технической возможности как-либо повлиять на него.
Вместо этого он вступает в переписку с нарушителями и теми, кто предоставляет
им доступ к системе распространения эх FidoNet, убеждая их либо прекратить на-
рушать правила конференции (которые сам модератор регулярно публикует), либо
покинуть данную конференцию. Руководящие документы FidoNet придают закон-
ный характер требованиям модератора.
Это достаточно действенный подход к управлению содержанием конферен-
ций, более человечный и более соответствующий характеру сети, чем модериро-
вание в стиле USENet, когда решение о помещении или непомещении письма
в конференцию принимает модератор.
Но у такого подхода есть и оборотная сторона: конфликтов вокруг решений
модераторов в FidoNet очень много и порой это довольно острые конфликты, пе-
реходящие в настоящую личную неприязнь и разрушающие сеть.
Чтобы «выжить» в многолюдной конференции, быть ее активным участником,
несмотря на попытки завзятых говорунов и хамов вступить с вами в бесконечные
прения, необходимо знать и соблюдать простые правила:
□ строго придерживайтесь главного закона FidoNet, который можно сформу-
лировать следующим образом: «Не раздражай других и сам старайся попус-
ту не впадать в раздражение»',
□ обязательно ознакомьтесь с правилами эхо-конференции перед тем как что-
либо написать в нее;
□ уважительно относитесь к требованиям модератора;
□ старайтесь не читать популярных немодерируемых конференций, если толь-
ко прилюдная ругань не доставляет вам наслаждения;
□ организовывайте свои эхо-конференции и устанавливайте в них свои поряд-
ки, если вас не устраивает то, что творится в известных вам эхах по аналогич-
ной тематике.
А вот что категорически запрещается делать:
□ вступать в пререкания с модератором эхо-конференции, особенно в самой эхе;
□ организовывать перевыборы модератора без консультаций с координатором
эхо-почты (о механизме координации эхо-почты рассказано в главе 6);
□ самовольно модерировать эхо-конференцию;
□ пытаться выяснить населенность конференции, задавая вопросы типа: «А сколь-
ко вас здесь? Напишите-ка поскорее!».
Что такое twit
Острый спор, как огонь пожирающий время и эмоции участников, в английском
языке обозначается как flame (пламя), а любитель подобного времяпрепровож-
дения - flamer. Справиться с настоящим флеймером невозможно: он гибок, груб,
неутомим и способен к замысловатым логическим построениям. Однако и в этом
случае есть возможность если не добиться результата, то, по крайней мере, уйти
от бесперспективной конфронтации: большинство FTN-редакторов сообщений
имеют возможность настройки списка авторов, письма которых вы просто не хо-
тите видеть, - это так называемый twit-list. Внесите имя раздражающего вас оппо-
нента в твит-лист, и вы никогда больше не увидите его писем. Учтите только, что
эта мера - крайность, делать это нужно только в том случае, если все другие сред-
ства наладить диалог или уйти от непрерывного спора исчерпаны.
Нетрадиционное модерирование в FidoNet
Участники сети осознают достоинства и недостатки традиционной организации
управления содержанием эхо-конференций в FidoNet. За время существования сети
предпринимались неоднократные попытки усовершенствовать систему модериро-
вания. Одна из таких попыток - это модерирование в стиле USENet, когда через
почтовый ящик модератора проходят письма всех участников конференции. Пре-
модерируемые эхи в FidoNet действительно существуют, однако поскольку до сих
пор подобный контроль в FidoNet не поддержан техническим решением, то и про-
водится он иначе, чем в USENet: в правила эхи вносится пункт о запрещении поме-
щения писем в эху, а также требование высылать нетмейлом модератору конферен-
ции все, что хочется опубликовать. Первой такой премодерируемой конференцией
в регионе 50 была HUMOR. FILTERED, живущая и по сию пору усилиями своего
модератора Михаила Лаврентьева (Mikel Lavrentiev, адрес 2:5020/35). Предло-
жения оформить технически премодерирование в стиле USENet звучат в тече-
ние уже нескольких лет, но до сих пор не опубликована ни одна реализация
эхопроцессора, в который была бы встроена эта функция. Возможным выходом из
ситуации, когда модератор явно перегружен борьбой за чистоту эхи, является раз-
работанное в сети TartarNet (казанский сегмент сети FidoNet) так называемое мо-
дерирование посредством голосования (Moderated by Vote System, M.V.S). M.V.S.
предоставляет возможность каждому подписчику участвовать в процессе модери-
рования конференции через посылку модерирующих сообщений, учитываемых
программой-исполнителем при принятии решения о модерировании. Большой рас-
пространенности этот подход пока не получил, и MVS-конференций еще очень
мало (подробнее об этом см. главу 8).
Эхи FidoNet и news-конференции USENet/Intemet
Эхо-конференции FidoNet и news-конференции USENet (в настоящее время пол-
ностью поглощенные Internet) возникли независимо, но тем не менее это род-
ственные системы. Десять лет назад различий между ними было еще меньше, так
как для распространения телеконференций USENet использовался не on-line
Internet-протокол NNTP, как сейчас, а давший начало USENet off-line протокол
UUCP, очень похожий на технологию передачи почты FidoNet. Многие участни-
ки эхо-конференций имели доступ к USENet и участвовали в телеконференциях
этой сети. Поэтому с самого зарождения эхо-конференций берет начало и идея
организации шлюза между двумя этими системами. Сначала шлюзы с USENet
были предназначены только для транспорта нетмейла, затем был реализован ме-
ханизм обмена конференциями.
Впервые такие шлюзы (gateways) были установлены в Соединенных Штатах
(первая зона FidoNet) в 1987 году. В России шлюз между FidoNet и Internet по
технологии UUCP был запущен в работу летом 1991 года усилиями Дмитрия За-
валишина, написавшего программу шлюза. Программа называлась UU2 и работа-
ла сначала под DOS, затем под OS/2. Для эхопроцессора Fido-системы UU2 вы-
глядел как внешняя программа-архиватор. Дмитрий стал администратором
шлюза и поддерживал его работу до 1997 года.
Впоследствии, когда подключение к Internet on-line перестало быть дорогой эк-
зотикой, многие узлы FidoNet установили программы между FidoNet и Internet
с использованием протокола NNTP. Одной из таких программ является разрабо-
танный Евгением Черкашиным (Eugene Grosser, адрес 2:5020/230) комплекс про-
грамм для операционной системы UNIX, называемый Ifmail. В его состав входит
программа Ifgate, реализующая функции шлюза между технологией FTN и про-
токолом распространения телеконференций, используемым в Internet (NNTP).
Ifmail является частью дистрибутива операционной системы Linux. Под Ifmail не-
сколько лет работает эхо-шлюз между FidoNet и Internet на компьютере с Internet-
адресом ddt.demos.su или news.fido7.ru (Fido-адрес 2:5020/400).
Многие эхо-конференции российского Fido доступны на NNTP-серверах
в Internet. Если у вас есть доступ к Internet, подключитесь к одному из них с помо-
щью news-клиента вашего любимого WEB-браузера. (Я читаю новости с адреса
ttp://wwwnews.online.ru, вам же удобнее это делать с ближайшего хоста - узнайте
у своего провайдера, какой news-хост предпочтителен для вас. Список публичных
news-хостов можно найти в Internet по адресу http://www.fido7.ru.)
Группы USENet News с самого начала были организованы тематически: снача-
ла вы получаете с сервера список имеющихся на нем тем, затем подписываетесь
на интересующие вас пункты и начинаете писать и читать. Несколько тысяч кон-
ференций разбиты на несколько десятков групп, которые в свою очередь иерар-
хически подразделяются на подгруппы, так что найти интересующую вас конфе-
ренцию довольно легко.
Телеконференции российского Fido в Internet сначала были представлены
группами новостей RELCOM. FIDO. * и частью конференций из иерархии
RELCOM. СОМР. * (некоторые эхо-конференции из SU. SOFTWARE.*). Эта иерар-
хия, существующая и сейчас, была результатом работы гейта Дмитрия Завали-
шина, сотрудничавшего в то время с провайдером АО «Редком» (ныне «Дело-
вая сеть»). После закрытия гейта Дмитрия эти конференции стали обычными
конференциями сети «Редком» и к FidoNet больше отношения не имеют. На
память об их происхождении осталось только слово «fido» в названии. Сейчас
эхо-конференции русского Fido в Internet представлены иерархией fido7.*.
Цифра семь - международный телефонный код России и некоторых других
Д Netscape News - [Ret "...сейчас нет других технологий" ] а □
File Edit View Message Go Options Window Help
iy ♦ I ИЙ ЙТЙ
NewsServer "" |S|jnread"|rotal
i [3) relcom. consumers Fj
Q relcom.cuit. ..underground ;_:6
Q relcom.currency [___i 6
| 37 Cj relcom.demos.*(2groups)
Q relcom.dtp 7j 7
...Q relcom.ecofogy Г~1 8
□удвоив»
...Q relcom.expo i 5
Sender |a| ^Subject |Date
Charlie R... • > Выездной семина... Sun05:11:20
P Sergey A.... - < ENGLISH-учите ... Sun21:00:35
Aleksey K... - • Новости сервера Mon 11 47 32
ig... < Re: "...сейчас нет ...Tue 10:57:59
kva % Re: "...сейчас нет ... Wed 18:09:46
•-/I nc@m... % Re: "...сейчас нет ...Mon 21:14:21
>Я все удивляюсь, как у нас народ умеет об одном и том же на разных язы
>говорить. И
>Вопрос-то изначально ИМХО ставился именно о технологии, а обсуждение о:
>свалилось на софт, грозя при этом уидти в сторону от темы.
Вообще-то софт и есть часть технологии, а вовсе не что-то
проклятое и низкое.
Другое дело, что есть еще педагогические технологии,
которые могут так или иначе кобинироваться с
компьютерными технологиями.
Шафрин говорил о компьютерных технологиях в образовании
-- это несомненно. И при этом он увидел только одну такую |
технологию (что вполне естественно, учитывая общую падкость ।
до нее нашего народа). Напомню, что в статье также - =
——r« пимл; иж.тлтл глхлл zr>. Д.гплт-1у^.тл.гх.<-> mrm.ntw,,,__________________________J—
Jr/<sl; Document: Done [ E3‘?
Рис. 1.13. Чтение news-конференций Internet с узла news.online.ru
стран бывшего СССР. Конференции fido7.* - это в основном результат работы
упоминавшегося выше шлюза на 2:5020/400 (провайдер Internet АО «Демос»).
На рис. 1.13 изображен процесс чтения телеконференций FidoNet с узла
news.online.ru.
В приведенном примере окно программы клиента разбито на три основных
информационных поля: слева вы видите часть списка наименований news-теле-
конференций (одна из них, relcom. education, выбрана курсором), справа виден
иерархически организованный список заголовков статей в выбранной конферен-
ции, нижнее поле содержит текст статьи. Помеченные знаком > строки являются
цитатой из предыдущего письма.
Более подробно поиск эхо-конференций FidoNet в Internet описан в главе 10.
Файл-эхи
Файловые конференции, или, как их в FidoNet чаще называют, файл-эхи - еще
один тип сервиса, чрезвычайно популярный наряду с эхо-почтой и личной почтой.
Подробно он описан в главе 9, в этой главе будут только коротко рассмотрены его
особенности.
Файловые конференции как самостоятельный сервис появились позже эхо-поч-
ты, в 1989 году. Идея их проста и очень похожа на идею эхо-почты: она проистекает
из необходимости «выравнивать» содержимое файловых областей нескольких
Рис. 1.14. Схема распространения файловых конференций
BBS или Fido-систем. На рис. 1.14 изображено пять узлов в двух сетях, обмениваю-
щихся почтой и эхо-почтой.
Предположим, системные операторы всех узлов используют почтовую програм-
му The Brake! для операционной системы OS/2 и узел А/1 получает файл brake.zip,
содержащий новую версию этой программы. В отсутствии механизма файл-эх рас-
пространение файла brake.zip выглядит следующим образом: сисоп узла А/1
объявляет о получении файла в одной из местных эхо-конференций. Систем-
ные операторы узлов, узнав о новинке, запрашивают файл brake.zip непосред-
ственно с системы А/1. В общей сложности требуется четыре соединения системы
А/1 с остальными системами, причем в трех из них файл brake.zip передается с ис-
пользованием дорогостоящего междугороднего соединения.
Механизм файл-эх предлагает простую организацию обмена файлами.
В описываемом случае все заинтересованные узлы должны установить про-
грамму обработки файл-конференций (файл-эхопроцессор) и описать в ее кон-
фигурационном файле файловую конференцию. Пусть она называется BRAKE
и предназначается только для распространения всего, что связано с этой про-
граммой. После этого узлы обеих сетей подписываются на эту конференцию,
узлы А/2 и В/1 - на узле А/1, а узлы В/2 и В/3 - на узле В/1.
Теперь процесс распространения файла brake.zip выглядит следующим образом
(рис. 1.15):
□ узел А/1 получает файл brake.zip извне от своего апл инка по файловой эхе BRAKE.
При распространении файла по системе файл-эх вместе с ним пересылается файл
Рис. 1.15. Распространение файловых конференций
с использованием файловых хабов
с расширением *.tic. Это информационный файл, содержащий информацию
об узлах, которые уже получили brake.zip, его контрольную сумму, позволяю-
щую проконтролировать целостность файла. Пример содержимого tic-файла
приведен на рис. 1.16;
□ узел А/1 экспортирует файл brake.zip своим непосредственным даунлинкам
А/2 и В/1. Для даунлинка А/1 включен режим распространения без сопрово-
дительного tic-файла, так как у А/2 нет даунлинков и он не распространяет
файл-эху BRAKE далее. Узлу В/1 передается файл brake.zip вместе с сопрово-
дительным tic-файлом, так как у В/2 есть даунлинки и информационный
файл ему понадобится;
□ узел В/1 экспортирует файл brake.zip на узлы В/2 и В/3.
Таким образом, для «раздачи» файла brake.zip потребовалось совершить четыре
телефонных звонка, из которых только один междугородний. Кроме того, удобно,
что нагрузка на узел А/1 снижена по сравнению с вариантом, изображенным на
рис. 1.15, и раздача файл-эх уже меньше мешает передаче эхо-почты и нетмейла.
К сказанному можно добавить, что если узел далее не раздает файл-эхи и не
намерен пользоваться сервисом файл-эхопроцессора (который может, например,
раскладывать полученные файлы по директориям и составлять для сисопа их
списки), то ему не нужны ни дополнительные программы, ни информационные
tic-файлы. В подобном случае можно обойтись и без этого. Конечно, при таком
способе получения файловых конференций придется ежедневно выгребать боль-
шое количество файлов из входного директория почтовой программы и разби-
раться с их происхождением.
OS/2 System Editor - C:\FIDO\aUfix\TIC\AF106956.TIC _ J
File Edit Options Help
Area KAZAN.OFFICIAL -
Origin 2:5049/30
From 2:5049/12
File PNT5049.ZIP
Desc Net 5049 official pointlist
Crc E3C26FBF
Created by ALLFIX/2+, vl.ll build 3 Copyright (c) 1992,96 Harms Software Engineering
Path 2:5049/30 948007213 Sun Jan 16 07:20:13 2000 UTC+0000 3822EC31
Path 2:5049/19«fidonet.org 948037163 SUN JAN 16 19:39:23 2000 UTC+-0400 84EFAA19
Path 2:5049/96 948052931 Sun Jan 16 20:02:11 2000 UTC+0000 BB2685AE
Path 2:5049/12 948100279 Mon Jan 17 09:11:19 2000 UTC+0000 7790490E
Seenby 2:5049/30
Seenby 2:5049/19
Seenby 2:5049/96
Seenby 2:5049/96.13
Seenby 2:5049/96.14
Seenby 2:5049/96.19
Seenby 2:5049/96.26
Seenby 2:5049/96.27
Seenby 2:5049/109
Seenby 2:5049/110
Seenby 2:5049/5
Seenby 2:5049/12.14
Seenby 2:5049/85
Seenby 2:5049/108
Seenby 2:5049/115 \ j
Seenby 2:5049/116 Г
Pw Password
ZlZ—
Рис. 1.16. Пример содержимого TIC-файла
FAQ-серверы
Аббревиатурой FAQ (Frequently Asked Questions), или ЧАВО (ответы на ЧАсто
задаваемые ВОпросы), обозначаются информационные файлы, содержащие спис-
ки заранее составленных ответов на постоянно задаваемые новичками вопросы.
Подобные файлы чрезвычайно распространенны в мире глобальных сетей. Есть
FAQ практически на любые темы, регулярно публикуемые в конференциях соот-
ветствующего направления, есть конференции, специально предназначенные для
сопровождения и (или) распространения тех или иных FAQ.
Для распространения FAQ в FidoNet часто используется механизм FAQ-сер-
веров. Это программа, обрабатывающая нетмейл-запросы, поступающие на ее
адрес, и отвечающая на них. С помощью такого простого интерфейса можно
получить нужную статью из нужного FAQ. В качестве примера хорошо органи-
зованного FAQ-сервера можно привести письма взятые из конференции
SU. CARS, посвященной автомобильной тематике, русскоязычной и чрезвычай-
но популярной в регионах 50 и 46 (на рис. 1.17 и рис. 1.18 представлены толь-
ко фрагменты писем, поскольку они слишком велики для полной публикации).
Подключаемся к FidoNet
Чтобы подключится к FidoNet, нужно немногое. Компьютер, модем, свободная
хотя бы на час в сутки телефонная линия, информация об узлах FidoNet в вашей
местности, чуть-чуть желания и упорства. В этом разделе приведены простые со-
веты: как лучше сконфигурировать и оттестировать свою систему до начала уста-
новки программы FidoNet и налаживания связи с сетью.
"yr Fleetstreet 1.24.1 - SU.CARS (Е) File Edit Message Special Rexx Setup Windows Help ° p.
<_|»-а|ч|>.| <m>>; m|h| ^|^j^|'fl|ia|ra|i&i c
From: FAQ Serve г 2:5028/299 31 Dec 1993 00.05-04
To: All 07 Jan 2000 14:5914
Subj: faqserver
8й1о' Alli . ' 7” ~
У меня работает PAQServex с небольшой базой по тематике ахи. База
преимущественно состоит ив писем, проходивших по ахам МО. CARS и SH.CARS. -
Основные темы.- технические характеристики, покупка,., продажа, эксплуатация
и ремонт автомобилей и запасных частей. - . , -
Сервер отвечает на запросы, направленные по адресу 2:5020/299.299 на имя
FAQServer (ВНИМАНИЕ 1 Все запросы, направленные на какой-либо другой адрес," ;
или другое имя, прибивается немедленно. и бея моего вмешательства). Чтобы '
получить краткую справку по командам сервера, направьте на указанный
ешй адрес письмо1 с командой ‘^heip1 (команда должна содержаться в
теле письма, и начинатся с. первого символа строки). чтобы получить
список тем, имежихся в базе ’CARS*, направьте на указанный выше адрес
письмо'со'Словом CARS в поле Subj, и командой 411st’, ' 7
У кого есть чем пополнить базу '« пишите мне лично, по адресу 2 *5020/299 '
(to Maxim. Volfconovsky), , -
Р.3. В регионе 50 работает несколько зеркал моего сервера. Если они
. находятся к вам ближе/ посылайте,' пожалуйста, ваши запросы им»
; В сети 2:5060 сервер имеет''адрес 2:5060/19 И имя FAQSERVER ' ' '
В сети 2:5011 сервер имеет адрес 2:5011/42.4 И имя FAQSERVER .
"В сети 2:5024 сервер имеет адрес 2:5024/12.1212 И ИМЯ FAQSERVER
7 ' В сетИ'2:5005 сервер имеет адрес 2:5005/41.41 и имя FAQSERVER
j '24010 of 24976 ; 25049/12
Рис. 1.17. Пример рекламно-информационного письма FAQ-сервера
-A Fleetstreet 1.24.1 - SU.CARS (Е) ° Л,
File Edit Message Special Rexx Setup Windows Help
From: FAQServer 2:5088/44 01 Mari999 000424
To: All 01 Mar 1999 07-31-36
Subj: All About Cars
Airnb /
; , ' List of FAQs on Sharfc Station (2:5080/44)
77/7 . ' - . :
060896 , ' О мерах по укреплению правопорядка на дорогах
BLAME * - /Об административной ответственности за нарушение правил
- дорожного движения (2 части) ' - ; ' ™
CARGO \ „ постановление N 118 от 26 февраля 1992 г. об утверждении по- -'
., ‘ _ поженил о лицензировании перевозочной и другой деятельности
' ;' связанной с перевозками. . " '
I / Положение о лицензировании' перевозочной,; транспортно-экспе-
''' \ ' диционной и другой деятельности, связанней с осуществлением
•. транспортного,процесса, ремонтом и техническим обслуживанием
' ' '' гтранспортных средств на 'автомобильном транспорте в Российской
Федерации.- <2 части)
CONST . -// ' О нарушениижжетитуционных прав сотрудников ГАИ по отношению
-./ '' к'владельцам транспортных средств , . , . ' . , <
CUSTOM' <- О порядке таможенного оформления транспортных средств , ' -
: ~- отдельных категорий юридических лиц. , . ; -
DOCTOR • ’ Приказ Министерства здравоохранения N 266 от 24 июня 1996 г.
г; " { “ Об учреждении аптечки первой пемсаци (автомобильной). ' . ' - . -
DOVER , " ,о доверенностях, написанных от'руки. (Статьи о сделках, совершав- ;
мых в простой письменной форме) (2 части) . - -
EXAM. ; .. постановление N 184 от зо августа 1993 г. об организации и
- ' проведении Государственного технического осмотра автомото- ' -
- - - транспортных средств и прицепов к ним в Российской Федерации v
.................-.......................--/..р.' [............25049/12.. j
Рис. 7.18. Информационное письмо по содержимому базы FAQ-сервера
Модем и телефон
Модем
Настоящий модем появился у меня в 1990 году. Все, что было до этого, - огром-
ный, как письменный стол, и железный, как танк, 300-бодный уродец из системы
компьютеров единой системы, монстры венгерского производства на 1200 бод,
размером и весом напоминавшие персональный компьютер, - не в счет. Все по-
блекло перед черной пластиковой коробочкой размером с книгу среднего форма-
та, произведенной, как гласила надпись на упаковке, фирмой US Robotics. Ско-
рость модема была 2400 бит в секунду - по тем временам неплохая. Итак, US
Robotics Courier 2400е, терминальная программа Procomm, компьютер IBM XT
и желание помочь своему знакомому, участвовавшему в детской образовательной
программе GreenPeace, заставили меня впервые шагнуть в мир компьютерных
коммуникаций. С тех пор прошло восемь лет, но, как и тогда, на моем столе стоит
модем фирмы US Robotics Courier, причем и внешний вид его точно такой же,
правда, максимальная скорость соединения несколько возросла.
За эти годы мне довелось устанавливать ежедневный обмен данными с систе-
мами на всех АТС Казани, городами Татарстана, России и республик бывшего
СССР. Несмотря на приверженность к изделиям фирмы US Robotics, пришлось
работать и с множеством других модемов. Zyxel, GVC, Sonix, Multitech, Motorola,
IDC - это далеко не полный список.
Не претендуя на полноту охвата и безошибочность суждений, мне хотелось бы
не столько поделиться опытом - опыт дело наживное, техника меняется быстро,
все устаревает, - сколько рассказать о том, что ожидает вас, пытливый читатель,
на пути от одного компьютера к другому. Этот путь, в сущности, все более стано-
вится дорогой от человека к человеку.
Телефон
Итак, телефон. Телефон в России всегда был предметом особенным, мечтой и при-
вилегией. На качество соединения внимания не обращали: можно докричаться -
и ладно. Но для модемного соединения эти «мелочи» играют решающее значение.
В табл. 1.7 приведен неполный список «особенностей», мешающих соединению,
и реакция модема на них.
Автоматические телефонные станции (АТС) ответственны за основную часть
перечисленных «прелестей». Оставшиеся помехи привносятся на пути от АТС до
вашего модема. Существенным фактором является и качество межстанционных
соединений. Хуже всего модемы работают на старых декадно-шаговых АТС, еще
сохранившихся в некоторых городах России. Для них гарантирован почти пол-
ный список перечисленных выше дефектов. Особенно тяжело бывает наладить
устойчивое соединение при прозвонке с одной старой АТС на другую.
Немногим лучше и более современные координатные станции, хотя в целом ка-
чество соединения, осуществляемое с их помощью, заметно выше.
Наивысшее качество обеспечивают цифровые электронные станции. Если вы
являетесь абонентом электронной АТС, обязательно включите тональный набор
для своего номера (это стандартная услуга ГТС), тем самым вы обеспечите более
Таблица 1.7. Виды помех при телефонном соединении
Описание помехи Реакция модема
Низкий уровень сигнала Соединение не устанавливается, соединение устанавливается на пониженной скорости; снижение скорости передачи
Нелинейные искажения сигнала Соединение не устанавливается, низкая скорость передачи; повторное установление соединения (retrain)
Трески в линии На протоколах V32, V34 соединение не устанавливается, разрыв установленного соединения, постоянные «ретрейны»
Посторонние звуки (разговоры, музыка, гудки, параллельный разговор) Замедленный набор номера Соединение не устанавливается, соединение устанавливается на пониженной скорости; снижение скорости передачи Необходимость установки задержек при наборе номера, увеличение времени набора номера, ошибки при наборе
Низкая надежность набора номера Периоды «молчания» Задержка появления гудка после подъема трубки Нестандартный тон гудка Низкий уровень звонкового напряжения Нестандартный сигнал «занято» Ошибки при наборе Разрыв соединения; «ретрейны» Модем выдает ответ «NO DIALTONE» при попытке набора номера Модем выдает ответ «NO DIALTONE» при попытке набора номера Модем не снимает трубку при ответе на звонок Модем не диагностирует занятость линии (не выдает ответ «BUSY»)
высокую скорость и надежность набора номера по сравнению с импульсным ре-
жимом.
Несколько лет моя Fido-система работала на телефонах декадно-шаговой 76-й
АТС Казани. Входные звонки следовали с частотой раз в две-три минуты. Один
раз в полчаса система принималась звонить в Москву, Симбирск, Ижевск. При
этом, несмотря на все перечисленные препятствия, мне удавалось обеспечить при-
ем и раздачу почты FidoNet в Казани.
Что делать?
Несколько простых советов, особенно актуальных для владельцев телефонов на
старых АТС:
□ обращайтесь за помощью к техническому персоналу вашей АТС, требуйте
улучшения качества соединения;
□ не старайтесь соединиться на высокой скорости. Скорость соединения, обыч-
но измеряемая в бодах (бит в секунду), - физическая характеристика соеди-
нения, совершенно не обязательно напрямую связана со скоростью передачи
данных. Все зависит от качества канала. Найдите способ измерения скорости
передачи, например определите время передачи файла известной длины.
Иногда скорость передачи данных (CPS, characters per second - не путайте
ее со скоростью соединения) в явном виде выводится на экран в процессе
передачи или записывается в файл протокола вашей коммуникационной
программы. Чаще всего для плохих линий оптимальной является скорость
соединения 9600, 7200 или 4800 бод (соответствующие АТ-команды: at&n6,
at&n5 и at&n4 для модема US Robotics);
□ подбирайте протокол передачи. Модем - многопротокольное устройство,
список всех протоколов вы найдете в руководстве к нему. Самым совершен-
ным и современным в настоящее время является протокол V34 (скорость от
2400 до 28800 бод), и его фирменные расширения - V34+ (до 33600). Это
хороший протокол, устойчиво работающий во всем диапазоне скоростей, по
крайней мере, он работает лучше, чем его предшественник V32/V32bis. На-
учитесь разрешать соединение на одном протоколе и запрещать на другом.
Научитесь на слух различать соединение на основных протоколах - V22bis,
V32bis, V34, это несложно и может пригодится на практике;
□ в состав протоколов популярного модема US Robotics Courier V.Everything
входит фирменный протокол HST, очень устойчиво работающий на плохих
зашумленных линиях. Пользуйтесь им, но учтите, что это асимметричный
протокол: он не подходит для соединения с интенсивным двунаправленным
трафиком, например его лучше не применять при использовании дуплекс-
ных протоколов передачи файлов, таких как Hydra или Janus, и при под-
ключении к Internet. В случае же однонаправленной передачи (как обычно
в FidoNet при использовании протокола ZModem) он предпочтительнее -
соединение на нем легко устанавливается (при этом используется скорость
2400, как и у V22bis). Вот конфигурационная строчка для USR Courier, ко-
торая запретит все, кроме HST: at&f lbls54 = 192s56 = 192;
□ очень устойчивыми, хотя и низкоскоростными, являются старые протоколы
V22 (1200 бод) и V22bis (2400 бод). Иногда их использование (at&п2 или
at&n3 для модемов US Robotics) остается единственным выходом;
□ обратите внимание на подключение вашего телефона к линии. Удалите кон-
денсатор из телефонной розетки старого образца (если таковой имеется), так
как он мешает модемному соединению. Отключите лишние параллельные те-
лефонные аппараты. Проследите весь маршрут вашей телефонной проводки,
обратив внимание на контактные соединения (здесь, возможно, вам придется
прибегнуть к услугам персонала вашей АТС). Подключите телефонный ап-
парат через модем. Не допускайте использования асимметричного экраниро-
ванного кабеля для проводки телефона (типа телевизионного) - он выполня-
ет роль антенны и на него легко «наводятся» посторонние сигналы;
□ попробуйте сменить направление прозвонки («от вас» и «к вам»), если это
возможно, - иногда таким образом можно добиться заметного улучшения ха-
рактеристик соединения;
□ если модем не распознает тональный сигнал вашей АТС из-за задержек, свя-
занных с его появлением (гудок раздается не сразу, а спустя некоторое время
после подъема трубки), увеличьте время, отведенное для его распознавания
(ats6 = 6 - такой командой оно увеличивается до 6 секунд, обычно этого дос-
таточно). Если же модем вовсе «не ловит» гудок и при попытке набора номе-
ра выдает NO DIALTONE (а гудок слышен), то отключите распознавание
dialtone (гудка) командой at&xO.
Ваш компьютер как станция FidoNet
На рис. 1.19 схематически изображен состав программного обеспечения простей-
шего однолинейного узла FidoNet. Как видно, даже в этом случае на узле должны
совместно функционировать шесть программ; в случае же обычного раздающего
узла их количество возрастает до десяти и более. Стрелками на рисунке показан
путь перемещения информации после ее экспорта из редактора сообщений.
Программное обеспечение FidoNet предназначено для работы в автоматичес-
ком режиме. Интерфейс пользователя минимален и представлен в основном про-
граммой составления сообщений (Message Editor). Хорошо настроенные узлы
FidoNet могут работать месяцами, не выключаясь, обеспечивая почтой сотни сис-
тем. Кроме того, с давних пор при работе на узле FidoNet использовался многоза-
дачный и многопользовательский (для случая BBS) режимы работы, поскольку
программное обеспечение узла сети составляют не одна, а несколько программ;
некоторые из этих программ могут, а некоторые должны работать одновременно
(например, в случае многолинейного узла).
Правильный выбор компьютера, операционной системы и тщательная ее на-
стройка имеют большое значение для успешного функционирования узла FidoNet.
Все эти вопросы подробно освещены ниже и в главе 12.
Три компьютера и четыре модема: ваш выбор
FidoNet родилась в то время, когда IBM PC с операционной системой DOS 1.0,
двумя дисководами 5” и оснащенный модемом на 1200 бит в секунду считался
Упаковщик
нетмейла
(FTN Tosser)
Утилиты:
компилятор
нодлиста,
обработчики
нетмейла и т.п.
Редактор писем
(Message Editor)
Почтовая ||
программа
Й
(FTN Mailer)
Драйвер
СОМ-портов
(FOSSIL driver)
Рис. 1.19. Состав программного обеспечения FidoNet
достаточно мощной системой. Программы, обеспечивающие работу сети, разра-
батывались из расчета устойчивого их функционирования на подобных компью-
терах. Поэтому вычислительная мощность и скоростные характеристики моде-
мов у системы, избранной в качестве базы для FidoNet узла, могут варьироваться
в очень широких пределах. Правильный выбор вам поможет сделать ориентиро-
вочная оценка объема перекачиваемой почты и количества соединений с другими
системами. Кроме того, не последнюю роль играют пристрастия к тому или ино-
му программному обеспечению. Например, если вам больше нравятся программы
с графическим интерфейсом пользователя, наилучшим выбором программы-ре-
дактора почты FidoNet будет Fleet Street, существующий только в версии для опе-
рационной системы OS/2 Warp. Ниже приведены некоторые типичные варианты
аппаратной и программной комплектации Fido-системы, в которых выбор опре-
деляется теми или иными из перечисленных выше параметров.
«Дедушкина РС-шка». Я использовал это название как собирательное. Имеется
в виду очень старый, бросовый, но еще работающий компьютер. Это может быть
и IBM PC XT первых выпусков с монохромным монитором, и IBM PC АТ-286
или IBM PC АТ-386 производства начала 90-х годов - все эти компьютеры сейчас
уже морально устарели и выработали свой ресурс. Но Fido-системы иногда уста-
навливаются на таких старых аппаратах, которые ни для чего другого уже непри-
годны. При подключении модема к подобному компьютеру нужно быть внима-
тельным - коммуникационные порты большинства старых PC не поддерживают
скорости выше 19200 или 38400 бит в секунду, и правильная настройка модема
может оказаться непростой задачей. Глава 6 и приложение 11 помогут выбрать
FTN-программы, успешно функционирующие на подобных компьютерах.
«IBM РС-486». Это тоже собирательное название. Под ним понимается любой
компьютер, на котором устойчиво и без «натуги» работает современная многоза-
дачная операционная система - OS/2, Windows 98 или UNIX с подсистемой X Win-
dows. Минимально это IBM РС-486 с 8-мегабайтной оперативной памятью. Мно-
жество систем FidoNet установлено именно на подобных компьютерах, мощность
которых позволяет использовать их в многозадачном режиме и допускает сосуще-
ствование активно используемой извне Fido-системы и обычной пользовательской
работы на том же компьютере.
«Не-PC». Как правило, есть возможность использования для FidoNet и несов-
местимого с IBM PC компьютера. По крайней мере программное обеспечение для
компьютеров Атари, MAC (Apple) и некоторых других (например, БК-0011 со-
ветского производства) существует, но достать его сложнее и выбор меньше.
Ссылки на адреса, по которым можно обратиться в Internet за FTN-программами
для этих компьютеров, вы найдете в приложениях 8 и 11.
Модем V.22/V.22bis (1200/2400 бод). Еще совсем недавно, каких-то пять лет на-
зад, модем с максимальной скоростью 2400 бит в секунду считался хорошим и сто-
ил достаточно дорого. Аппарат этот, как правило, надежный, и с тех лет накопи-
лось огромное количество подобных устройств. Иногда низкоскоростной модем -
это единственное, что есть под рукой, и в таком случае его волей-неволей прихо-
дится использовать. При небольшом объеме эхо-почты или при использовании
только нетмейла, его вполне хватает. Такой модем обеспечивает скорость передачи
информации до 250-280 байт/с (при использовании протоколов V42.bis). Если объем
ежедневно перекачиваемой информации не превышает нескольких сотен килобай-
тов и сисоп узла, предоставляющий вам сетевой сервис, не возражает против пере-
качки с использованием столь низкоскоростного соединения, то работать можно.
Модем V32bis (14400). Модем 14400, так же как и в свое время 2400-й, долго
был самым распространенным модемом в мире. Максимальная скорость, обес-
печиваемая им (до 1,5 Кб/с), до сих пор считается приемлемой. Поэтому, если
вы располагаете подобным устройством, можете быть спокойны: несмотря на то
что модемы этого типа уже не выпускаются, они вполне подходят для подклю-
чения к FidoNet; с таким модемом вас «возьмет» почти любой узел сети. Един-
ственным исключением являются модели без аппаратной коррекции ошибок -
от них сложно добиться нормальной работы. Примером подобного модема может
служить модем «Zoltrix High Speed Fax/modem 14400» образца 1994 года.
Модем V.34+ (33600). Модем, поддерживающий протокол передачи V.34+, яв-
ляется оптимальным выбором. Он обеспечивает максимальную скорость переда-
чи данных - 3,5 Кб/с, устойчиво работает в широком диапазоне скоростей, и цена
его невысока.
Модем V.90 (57600/33600). Для подключения к FidoNet вам не нужен модем,
поддерживающий современный асимметричный протокол V.90, поскольку сервер-
ные модемы, поддерживающие передачу данных по стандарту V.90, практически
отсутствуют на узлах FidoNet. Вы можете использовать подобный модем в том
случае, если он у вас уже есть, но при соединении с FidoNet он будет работать без
поддержки протокола V.90.
Операционная система
Выбор операционной системы чаще всего определяется вашими пристрастиями,
в большинстве случаев это будет просто самая распространенная программа.
В настоящий момент это операционные системы фирмы Microsoft - Windows 95,
Windows 98 и Windows NT. Однако в сети FidoNet широко используются и другие
операционные системы. Это объясняется прежде всего тем, что участники сети не
обычные пользователи компьютеров. Работа сисопа FidoNet гораздо ближе по
сути к работе администратора почтовой системы Internet, чем к обычным муче-
ниям рядового пользователя. Общаясь друг с другом, обмениваясь информацией,
участники сети имеют возможность выбрать операционную систему, которая наи-
более полно удовлетворит их нужды, раскроет все возможности их компьютер-
ных систем. Поэтому OS/2, Linux, Free BSD часто встречаются на узлах FidoNet.
На табл. 1.8 приведены данные о распространенности различных OS среди сис-
тем FidoNet, поддерживающих доступ по протоколу Binkp (такую статистику про-
ще всего собрать).
Как видно из таблицы, наиболее популярна среди Binkp-систем OS UNIX
(табл. 1.8 проясняет также и ситуацию с использованием различных версий этой
операционной системы), на втором месте - Windows NT, на третьем - IBM OS/2
и только на четвертом - общепринятая Windows 95/98.
Таблица 1.8. Характеристика распространенности различных ОС
среди систем FidoNet, доступных по протоколу Binkp через Internet
Операционная система Количество узлов FidoNet
Unix Windows NT OS/2 Windows 95 Другие ОС Соотношение различных версий ОС UNIX FreeBSD Linux Другие версии UNIX 86 82 69 25 2 43 31 12
Выбор операционной системы - это ответственный шаг. Он определяет весь
набор FTN-софта, с которым вам придется иметь дело. Поскольку выработать
какой-либо свод правил, как-либо формализовать процесс выбора операцион-
ной системы трудно, мы просто уделим некоторое внимание всем возможным
вариантам.
Почему DOS?
Дисковая операционная система MS DOS - это старая, проверенная однозадач-
ная система для компьютера IBM PC. MS DOS для FidoNet является «родной»,
так как FidoNet возникла и развивалась как сеть в основном домашних DOS-ком-
пьютеров. Большинство FTN-программ написаны под DOS и для выполнения под
ее управлением и подчас работают лучше, чем их новые аналоги для более совре-
менных операционных систем. MS DOS вне конкуренции на старых компьютерах
IBM PC XT и АТ, на них просто не работает ни одна из новых операционных сис-
тем. Она также вне конкуренции и на аппаратных конфигурациях с малым объ-
емом памяти. Таким образом, если все, что вы можете выделить для FidoNet, - это
старый дедушкин компьютер с монохромным экраном, неизвестно как отобража-
ющий русские символы, то кроме MS DOS версии 3.3 у вас просто нет другого
выбора.
Если предполагается работа однолинейной станции в автоматическом режиме
(unattended mode), то MS DOS также является неплохим вариантом.
Кратко преимущества MS DOS можно суммировать следующим образом:
□ лицензионная чистота, бесплатность (не составляет труда найти некогда уста-
новленную при продаже компьютера OEM версию системы MS DOS);
□ высокая скорость работы, нетребовательность к быстродействию компьюте-
ра, размеру оперативной памяти и объему жесткого диска;
□ обилие бесплатного программного обеспечения как специализированного для
FidoNet, так и общего назначения, и хорошее качество этого программного
обеспечения.
Почему DesqView?
Система DesqView фирмы Quart Desk - это многозадачная надстройка над MS
DOS, некогда широко использовавшаяся на многолинейных узлах FidoNet. Я сам
несколько лет работал под DesqView 2.60, сначала на IBM PC АТ-386, затем на
IBM PC 486SX с 4-мегабайтной оперативной памятью. Компьютер уверенно «тя-
нул» трехлинейный Fido-узел (три входных телефона, три одновременно работа-
ющих Fido-комплекта) и позволял работать сисопу в одном из DOS-окон.
Конечно, сейчас DesqView - экзотика, но для организации многолинейного
Fido-узла на маломощном компьютере с небольшим объемом оперативной памя-
ти это один из возможных вариантов. DesqView - это:
□ система исключительно компактная (умещается на одну дискету 3.5"), доста-
точно быстрая, удобная;
□ нетребовательна к мощности компьютера и объему жесткого диска;
□ имеет простой текстовый интерфейс, позволяет в широких пределах конфи-
гурировать запускаемые DOS-сеансы;
□ многие FTN-программы «знают» про DesqView и хорошо под ней работают.
Почему Windows 3.11?
Windows 3.11 по своим потребительским свойствам (с точки зрения сисопа узла
FidoNet) очень похожа на DesqView. Это, в сущности, тоже многозадачная над-
стройка над MS DOS, только с развитым графическим интерфейсом. В отличие
от DesqView под Windows 3.11 работает весь набор офисного программного обес-
печения фирмы Misrosoft, поэтому решение о выборе MS Windows 3.11 в качестве
базовой системы для FidoNet бывает вынужденным. В целом Windows 3.11 не
очень подходит для организации многолинейного узла, чаще она использовалась
для организации однолинейного узла на основе набора DOS-программ, работаю-
щих в окне MS DOS, и одновременной работе сисопа в приложениях Windows.
Система MS Windows 3.11, если рассматривать ее как многозадачную DOS-среду
(DOS-multitasker), не очень устойчива и не очень хорошо работает с СОМ-порта-
ми, но у нее есть и свои преимущества. В частности, эта система:
□ нетребовательна к мощности компьютера и объему жесткого диска;
□ позволяет использовать графические офисные приложения;
□ работает над MS DOS, и Fido-система может быть без дополнительной пере-
конфигурации компьютера переведена на работу из-под DOS, то есть в «род-
ной» для многих FTN-программ режим.
Почему OS/2?
OS/2 2.10 фирмы IBM, появившаяся в 1993 году, была первой и в то время един-
ственной персональной 32-битной многозадачной операционной системой. Она
в полной мере использовала все преимущества современных процессоров фир-
мы Intel (80386 и выше), обладала развитым графическим интерфейсом и по-
зволяла выполнять программы MS DOS под управлением так называемой вир-
туальной машины DOS (Virtual DOS Machine, VDM). VDM намного лучше
защищает операционную систему от сбоев, чем аналогичные DOS-сеансы под
управлением DesqView или Windows 3.11. Кроме того, сеансы DOS под OS/2
работают «мягче», чем под управлением упомянутых систем. Поэтому неудиви-
тельно, что внимание сисопов, поддерживающих многолинейные узлы FidoNet,
а также тех из них, кто предпочитал работать на своем компьютере одновремен-
но с работой Fido-системы, было обращено внимание на эту операционную сис-
тему, тем более что IBM имела (и имеет) обширную программу бесплатного рас-
пространения OS/2 для участников beta-тестирования.
OS/2 удобна и с точки зрения автоматизации работы узла FidoNet, столь необхо-
димой для многолинейной, непрерывно работающей Fido-системы, так как она
включает в качестве стандартного средства интерпретирующий язык REXX. Он
представляет собой старый язык автоматизации обработки текстов и программной
среды, использовавшийся еще на легендарных «больших» компьютерах IBM под
управлением OS 360/370. REXX (REstructered extended eXecutor) немного похож
на язык пакетных файлов MS DOS, но гораздо мощнее и обладает структурной
организацией. REXX включает большое количество функций для обработки, фор-
матирования и поиска текста, а также основные математические функции.
Дополнительным аргументом за использование OS/2 является возможность
работы под ее управлением «устанавливаемых» (Installable, IFS) файловых сис-
тем и наличие более эффективных по сравнению с FAT устанавливаемых файло-
вых систем HPFS и HPFS386, так как узел FidoNet при работе создает значитель-
ную нагрузку на дисковую подсистему компьютера.
Вот почему OS/2 в FidoNet - система известная и популярная, множество
многолинейных узлов FidoNet (и мой в том числе) и сейчас работают под ее уп-
равлением. К достоинствам OS/2 следует отнести и возможность функциони-
рования одновременно с работой Fido-системы, 16-битного офисного программ-
ного обеспечения фирмы Microsoft в сеансе Win-OS/2. Win-OS/2 - это сеанс
системы Windows 3.11, работающий под управлением OS/2.
Первое время для организации Fido-узла под управлением OS/2 использовал-
ся стандартный, привычный набор FTN-программ для DOS, но вскоре их автора-
ми были созданы версии непосредственно для OS/2, и сейчас можно «собрать»
много различных вариантов Fido-системы без использования VDM, причем, по
утверждениям многих сисопов, некоторые из этих программ являются лучшими
в своем классе.
Подводя итог, можно сказать, что и сейчас OS/2 является отличным выбором
современной операционной системы, которая позволит вам организовать много-
линейный, надежно функционирующий узел FidoNet и одновременно использо-
вать компьютер как офисную станцию или рабочее место разработчика программ-
ного обеспечения.
Почему Windows 95/98?
Windows 95 до своего официального появления на рынке программного обеспече-
ния в 1995 году носила название Chicago. Под кличкой «Чикага», «Чика» она из-
вестна в регионе 50, так как начиная с первых beta-версий эта система использу-
ется на многих узлах FidoNet, и сейчас это одна из самых распространенных в Fido
операционных систем. И неудивительно, ведь эта система благодаря успешной
маркетинговой политике Microsoft одержала безусловную победу на рынке персо-
нальных операционных систем для IBM PC. Поэтому вопрос о выборе Windows 95
или Windows 98 в качестве основы для построения FidoNet-системы во многих
случаях решается автоматически, так как эта система уже установлена на жест-
кий диск компьютера. И это неплохой выбор: хотя эксперты и отмечают боль-
шую устойчивость операционных систем OS/2, UNIX и Windows NT по сравне-
нию с Windows 95/98, все же правильно настроенная Windows 95 «падает»
вследствие работы Fido-программ чрезвычайно редко и может быть использована
и как базовая система для многолинейного узла, и как основа для создания персо-
нальной рабочей станции с одновременно работающим однолинейным Fido-уз-
лом. При этом у вас не будет проблем с использованием огромного количества
программ для Windows 95.
Почему Windows NT или Windows 2000?
OS Windows NT фирмы Microsoft (последняя ее версия распространяется под тор-
говой маркой Windows 2000) часто используется для организации Fido-станций,
поскольку это устойчивая, защищенная, многозадачная и многопользовательская
операционная система, которая помимо основного 32-разрядного режима способна
выполнять приложения, предназначенные для работы под управлением операци-
онных систем MS DOS, Windows 3.11, 16-разрядные приложения OS/2 и POSIX.
Кроме собственной эффективной файловой системы NTFS поддерживаются фай-
ловые системы FAT, VFAT, HPFS. Очень удобно также, что последние версии
Windows NT (начиная с четвертой версии) имеют привычный многим пользова-
телям компьютеров интерфейс Windows 95, упрощая таким образом первоначаль-
ное ее освоение. Windows NT более требовательна к ресурсам компьютера, чем
OS/2 или Windows 95. Для устойчивой работы Fido-системы ей необходимо
минимум 32 мегабайта оперативной памяти, процессор Pentium и жесткий
диск с малым временем доступа, однако сейчас это стандартные требования к ап-
паратной части персонального компьютера.
Есть программное обеспечение FidoNet, скомпилированное под Windows NT,
хотя полноценный комплект 32-разрядного FNT-софта под Win32 собрать труд-
но и для части программ приходится использовать 16-разрядные DOS-версии.
Чрезвычайно удобно, что под Windows NT без проблем работает весь набор
офисного программного обеспечения фирмы Microsoft.
В целом при выборе операционной системы для узла FidoNet можно рассмат-
ривать Windows NT как альтернативу Windows 95, более надежную и мощную.
Почему UNIX? (Linux? Free BSD?)
Участник сети FidoNet - это не рядовой пользователь, которому «наплевать, что
у компьютера внутри, лишь бы работал». Напротив, это, как правило, компью-
терный фанат, которого интересуют не только сетевые услуги, обеспечиваемые
FidoNet, но и сам процесс их получения. Он подходит к выбору и конфигурации
программного обеспечения совсем с других позиций, не жалеет времени и сил на
поиск и освоение именно того программного обеспечения, которое наиболее полно
соответствует его запросам. Иногда это происходит в ущерб использованию ком-
пьютера для других целей, например в качестве офисной рабочей станции, но сер-
дцу не прикажешь. И на этом трудном пути первой стоит OS UNIX - многозадач-
ная и многопользовательская операционная система с 30-летней историей. Очень
важным моментом является то, что сейчас доступны бесплатные и лицензионно
чистые версии этой операционной системы, прекрасно работающие на современ-
ных компьютерах. Из них наиболее популярной и распространенной в качестве
домашней системы является OS Linux. По этой операционной системе издано
несколько книг на русском языке, сама программа распространяется на CD, и до-
стать ее не составляет труда. Менее распространена OS FreeBSD, также бесплат-
ная, но приобрести программы для нее несколько сложнее. На FreeBSD можно
остановиться, если у вас есть подключение к Internet, так как все программное
обеспечение для этой OS (как, впрочем, и для OS Linux) доступно в Internet.
UNIX вполне подходит в качестве операционной системы для узла FidoNet
любой мощности; при этом требования к быстродействию компьютера, оператив-
ной памяти и дисковой подсистеме очень скромны: для выделенного Fido-узла
хватит и АТ 486 с 16-мегабайтной оперативной памятью, а на современных компь-
ютерах UNIX просто-таки «летает».
UNIX является отличным выбором и в том случае, если вы планируете исполь-
зовать Internet наряду с подключением к FidoNet, а также применять Internet для
проброса Fido-почты. Для всего этого есть программное обеспечение, его настрой-
ка и использование подробно описаны в главе 11.
Под UNIX можно собрать несколько законченных вариантов Fido-системы,
правда, качество некоторых компонентов (например, тоссеров и редакторов сооб-
щений) пока оставляет желать лучшего, и иногда Fido-система функционально
распределяется между несколькими компьютерами с различными операционны-
ми системами, соединенными локальной сетью.
Как...?
Когда возникает необходимость и желание реально подключиться к FidoNet, сра-
зу возникает и несколько стандартных затруднений - «порогов», которые прихо-
дится преодолевать каждому вступающему в сеть. Считайте, что вам повезло, если
один из ваших знакомых уже имеет адрес в FidoNet и согласен вам помочь, мы же
рассмотрим случай самостоятельного подключения. Итак, ваш компьютер вклю-
чен, лампочки на модеме мигают, он готов к работе. Что далее?
Как стать пользователем BBS
Самый простой способ начать свое путешествие по миру телекоммуникаций - это
позвонить на BBS. Большинство некоммерческих BBS связаны с сетью FidoNet,
и, подключившись к ним, можно получить самую свежую информацию о состоя-
нии сети и даже воспользоваться основным сервисом FidoNet.
Для этого вам понадобится терминальная программа. Подойдет любая: и древ-
ний Telix или Procomm, и Term95 из комплекта Norton Commander, и Hyper
Terminal из стандартной поставки Windows 95. Буквы кириллицы большинство
BBS поддерживают в кодировке 866 (так называемая «альтернативная» кодировка).
Поэтому лучше все же использовать терминальные программы, разработанные
для MS DOS или OS/2, в которых применяется именно эта кодировка.
Терминальная программа поможет вашему компьютеру превратиться в простое
устройство для работы с коммуникационным портом, имитирующее один из стан-
дартных терминалов, использовавшихся некогда для подключения к «большим»
компьютерам.
После этого следует раздобыть список телефонов местных BBS, работающих
в вашем населенном пункте, и времени их работы. Очень важно, чтобы список был
точен, иначе вы доставите много неприятных моментов тем, кому в настоящий мо-
мент принадлежат перечисленные в списке телефоны. Одним из простых спосо-
бов самостоятельного составления такого списка может быть обработка нодлиста
сети FidoNet. Нодлист FidoNet еженедельно обновляется и его легко достать. На-
пример в Internet он обычно доступен по ftp с адреса: ftp://ftp.z2.fidonet.org.
Вам нужен полный нодлист, содержащийся в файле с названием nodelist.z??,
где вместо «??» в расширении имени файла находятся две цифры. Найдите файл
с датой, наиболее близкой текущей, разархивируйте nodelist.z?? программой
pkunzip и найдите в нем сеть, расположенную в вашей местности. При этом удоб-
но руководствоваться справочником географического расположения сетей
FidoNet, приведенным в приложении 7, но можно и считывать название города
непосредственно из нодлиста. После этого среди описаний узлов найдите строки,
в которых отсутствуют флаги «МО» (Mail Only, описание флагов нодлиста при-
ведены в главе 2). Эти строки и будут с высокой степенью вероятности содержать
телефоны Fido BBS в вашей местности.
Вот пример подобной строки для узла с адресом 2:5049/32@fidonet:
, 32,The_Evil_Empire,Kazan,Stas_Batkov,7-843-255-
22xx,9600,XA,ZYX,U,ТРЕ
В приведенном примере Kazan — название города, а строка цифр, разделенных
тире, представляет телефонный номер системы FidoNet в международном форма-
те (хх заменяет последние две цифры номера).
Чтобы определить время работы BBS, используйте флаг времени U,TXY, где вме-
сто XY должны стоять две буквы, в которых закодировано время начала и конца
работы станции. Этот флаг всегда следует за флагом U. В приведенной выше стро-
ке использовано обозначение U,TPE, что расшифровывается как время работы
с 15.00 до 4.00 по Гринвичу или с 18.00 до 7.00 зимнего московского времени (под-
робное описание, как нужно расшифровывать флаги времени, есть в главе 2).
Не следует пытаться звонить на BBS, имеющую узловой адрес в сети FidoNet,
в зональный почтовый час, поскольку почтовый час предназначен только для свя-
зи Fido-систем между собой, обслуживать пользователей BBS в это время запре-
щается, так как это может помешать обмену почтой систем FidoNet. Во второй
зоне это период времени 5.30-6.30 зимой и 6.30-7.30 летом (время московское).
Описанный способ поиска информации о работающих в вашей местности BBS
имеет и недостатки. Например, с его помощью не удается найти сведения о BBS,
имеющих пойнтовый адрес в FidoNet, так как информация о системах, имеющих
пойнтовый адрес, не включается в нодлист. Тем не менее это хороший способ, так
как, найдя всего несколько телефонов BBS, вы затем сможете получить гораздо
больше информации, подключившись к ним.
Кроме нодлиста есть еще составленные добровольцами списки BBS, иногда
чрезвычайно пространные. Однако пользоваться ими я не рекомендую, посколь-
ку хорошего и еженедельно обновляемого списка нет, так как отсутствует меха-
низм обновления (вспомним, что у нодлиста FidoNet такой механизм есть,
и в этом его преимущество как источника свежей и более-менее достоверной ин-
формации).
Найти информацию о телефонах хотя бы одной-двух BBS, подключенных
к Fido, - задача сложная, но вполне разрешимая. Спрашивайте у знакомых, ищи-
те в рекламных листках компьютерных фирм (многие из них содержат BBS для
поддержки пользователей), посмотрите компьютерные журналы, издаваемые в ва-
шем городе, проявите ваши способности частного детектива. И вы обязательно
найдете то, что ищете.
Подробно останавливаться на использовании BBS мы не будем, так как есть
много книг, в деталях рассказывающих об этом (см. библиографию, помещенную
в конце книги, ссылки [1.4, 1.5]).
Как достать информацию о сети и программы FidoNet
Для того чтобы найти что-либо, нужно знать что искать. Чтобы начать работать
в сети, вам понадобятся описанные ниже документы и программное обеспечение.
FidoNet Policy. Этот важный документ, по которому живет сеть, вы найдете
в приложении 2. Кроме того, он есть на множестве BBS, его можно скачать из
Internet по адресам, указанным в приложении 8.
FidoNet Nodelist. Желательно иметь самый свежий нодлист. Полный мировой
нодлист можно найти в Internet по адресу: ftp://ftp.z2.fidonet.org.
Кроме мирового нодлиста получили распространение также и урезанные его
копии (зональный, например, нодлист второй зоны, обычно помещаемый в файл
с именем z21ist), региональный (нодлист региона 50 - r501ist) и сетевой (сегмент
сети 5049 - net5049.ndl). Все эти списки удобны, поскольку невелики по размеру,
но официальным документом FidoNet является только «большой» нодлист. Если
информация в «урезанном» списке противоречит информации из «большого»
нодлиста, то всегда прав последний. Следует также знать, что в настоящий мо-
мент, в связи с отсутствием IC (международного координатора) «большой» нод-
лист собирается координаторами зон независимо и в FidoNet используется шесть
(по числу зон) версий мирового нодлиста, не вполне эквивалентных друг другу.
Вам лучше всего использовать нодлист, скомпилированный координатором вто-
рой зоны. Именно его можно найти по указанному выше адресу: ftp://ftp.z2.fidonet.org
или по адресу ftp://ftp.sstar.com/fidonet/zone2.
Комплект программного обеспечения FidoNet. Комплект программ для организа-
ции узла FidoNet можно найти в Internet, скачать с BBS или переписать у знако-
мых. Существует множество версий минимальных комплектов программ FidoNet,
объединенных в единое целое с документацией специально для начинающих. Эти
комплекты созданы участниками сети, размер их, как правило, очень небольшой -
до 2 Мбайт. Установка и конфигурация подобного комплекта существенно проще,
Таблица 1.9. Список минимального набора программного обеспечения,
необходимого для организации узла FidoNet
Название модуля Назначение Примеры реализаций
Драйвер FOSSIL Интерфейс между почтовой программой и коммуникационным портом Х00, BNU, SIO, VMODEM
Почтовая программа (FTN Mailer) Обмен почтой и файлами между системами FidoNet Front Door, BinkleyTerm, D'Bridge, Bink+, T-mail, The Brake!, Santa Fox, Xenia
Почтовый редактор (FTN Mail Editor) Чтение и написание писем GoldEd, TimEd, Fleet Street, MsgEd
Обработчик эхо-почты (FTN Tosser) Программа обработки эхопочты FidoNet GEcho, FastEcho, Squish, ParToss, NiceTosser
Обработчик нодлиста (Nodediff processor) Сопровождение нодлиста Fdnd, Ndp, FastList
чем установка «с нуля». В сети TartarNet усилиями участников сети с адресами
2:5049/30 (Vlad Spiridonov), 2:5049/37 (Jalil Gumerov) подготовлен комплект про-
грамм и документации для начинающего пользователя сети, вы можете найти его
в Internet по адресу: ftp://ftp.n5049.z2.fidonet.org/fidonet/fidopnt.exe.
Аналогичные комплекты программ можно поискать и по другим адресам, ука-
занным в приложении 8, кроме того, такого рода информация широко распрост-
ранена на BBS.
Комплект обязательно должен включать независимые программные модули,
суммированные в табл. 1.9.
Как получить пойнт-адрес
...Ия считаю, что только лень, нежелание
что-то делать самому и патологическое
неумение общаться с людьми могут оказаться
непреодолимыми препятствиями к получению
пойнт-адреса, если в сети есть хотя бы один
узел и хотя бы одна ББС, телефон которой
известен кандидату.
Serge/ Qkowlew, 2:5020/122
Из переписки в R50.SYSOP
Итак, вы зарегистрировались на BBS, научились скачивать с нее файлы и писать
письма, нашли необходимое программное обеспечение FidoNet и настроили его.
Все, что вам теперь потребуется для получения пойнт-адреса на одном из узлов, -
это элементарное умение общаться с людьми (см. эпиграф), поскольку вам при-
дется обратиться с просьбой к сисопу узла FidoNet. Ничего необычного в такой
просьбе о предоставлении сервиса FidoNet нет; также нет ничего необычного
и в отказе. Узел FidoNet вправе не предоставлять свои ресурсы пойнт-станциям -
это личное дело его системного оператора. Но, как правило, такой сервис предостав-
ляется, и вам надо убедить сисопа, что он делает верный выбор. Для этого нужно
правильно составить письмо-запрос на получение пойнт-адреса. Вы можете, конеч-
но же, заявить о своем желании и иначе: например, иногда сисопы предлагают кон-
тактный голосовой телефон, или вы можете написать письмо с BBS, пользователем
которой успели стать. Но отправленное с использованием программного обеспече-
ния FidoNet правильно составленное письмо многое говорит сисопу узла FidoNet.
Оно означает, что вы знакомы с технологией FidoNet, основными правилами сущест-
вования сети и поведения в ней, что не потребуется слишком много времени и сил
на ваше обучение и «воспитание». Правила написания «хорошего» письма просты:
□ используйте адрес <номер узла>.999 как адрес вашей системы при написании
письма-запроса. Это общепринятый обычай в FidoNet: пойнты с адресами .999
или .9999 не выдаются. Эти адреса зарезервированы для адресных запросов.
Например, если система, у которой вы намерены запросить пойнт-адрес, имеет
узловой адрес 2:5049/12, то можно использовать адрес 2:5049/12.999;
□ сообщите ваше реальное имя и фамилию. Использование псевдонима при зап-
росе адреса - дурной тон;
□ сообщите максимум персональной информации о себе, если сочтете это воз-
можным, но не слишком много. Письмо должно быть компактным - десяток
предложений, не больше.
Вот пример правильно составленного запроса на получение пойнтового адреса:
============================= Netmail Area =============================
From: Igor Maximov 2:5049/12.99 30 Oct 98 11:27:04
To: Amir Shabashvili 2:5049/12 30 Oct 98 11:27:04
5иЬ|:запрос пойнт-адреса
Привет Amir!
Нельзя ли мне получить пойнт-адрес на твоей Fido-станции?
Немного о себе: я студент КГУ, станция у меня дома (домашний телефон:
3851 хх, звони, если что), модем - Спорт 14400, программы - T-mail,
Golded, Fastecho. С программами и прочим я уже немного разобрался,
надеюсь, сильно тебя доставать не буду:-) Если ты не можешь взять
меня пойнтом, может, подскажешь к кому лучше обратиться?
Всяческих благ-с,
Igor
— GoldED 2.50.В0822+
* Origin: HomeLan BBS (2:5049/12.99)
В заключение напомню, что получить пойнтовый адрес - еще не все. Это только
начало пути. Чтобы правильно использовать и не потерять его, вам придется
потрудиться.
Как получить узловой адрес
Получение узлового адреса - это обязательное условие членства в FidoNet. Толь-
ко узлы FidoNet имеют право голоса на различного рода сетевых выборах (в пер-
вую очередь на выборах координатора сети), их адреса входят в мировой список
узлов сети - нодлист, они могут предоставлять сервис пойнт-системам. Узлы
FidoNet и только они составляют сеть. Пойнт-системы всего этого лишены. По-
этому желание получить именно узловой адрес естественно.
Стать узлом FidoNet, не являясь какое-то время пойнтом, трудно. Такое случа-
ется редко, хотя бывало в начале проникновения FidoNet в Россию, но не сейчас.
Таким образом, пойнтовый стаж порой оказывается попросту необходимым усло-
вием получения узлового адреса.
В Полиси подробно описано, как нужно запрашивать узловой адрес, там же
приведена готовая к заполнению форма (см. приложение 2, пункт 2.2), которую
надо отправить на адрес сетевого координатора. Адрес сетевого координатора, как
правило, <адрес сети>/0. Например, для сети 5049 4Б-адрес сетевого координа-
тора можно записать как 2:5049/0. Полиси рекомендует установить запрашиваю-
щему узел традиционно необычный адрес -1/-1 или зарезервированный <сеть>/
9999 (например, в сети 5049 это будет адрес 2:5049/9999), но в условиях России
это не принято. Рекомендация Полиси относится к условиям FidoNet образца
1989 года, когда получение узлового адреса без пойнтового стажа было обычным
делом. Лучше использовать ваш основной пойнт-адрес.
Обязательным условием выдачи узлового адреса является знакомство с Полн-
ей, необходимо прямо об этом сообщить в письме координатору. При этом нужно
учитывать, что в соответствии с Полиси ваша станция должна поддерживать пе-
редачу почты в ZMH, то есть работать каждую ночь и отвечать на входящие звон-
ки во время почтового часа: с 6.30 до 7.30 летом, с 5.30 до 6.30 зимой (московское
время).
Хорошим тоном является правильно составленная строчка для нодлиста с ис-
пользованием пользовательских флагов времени работы, описанных в главе 2.
Следует также учитывать, что в территориальных сетях существуют различные
обычаи выдачи узловых адресов. Например, у вас могут попросить рекомендацию
от одного (или нескольких) участников сети, имеющих узловые адреса.
Желание предоставлять сервис другим системам является хорошим поводом
для запроса узлового адреса. Если вы намереваетесь делать это и ресурсы вашей
станции позволяют вам планировать активность вроде выдачи пойнтовых адре-
сов, получения почты из другого города и т.д., обязательно сообщите об этом ко-
ординатору - это может ускорить получение узлового адреса.
Программы FidoNet: тысяча маленьких медвежат
Программное обеспечение FidoNet составляют сотни больших и маленьких про-
грамм, написанных участниками сети на добровольных началах, часто для себя,
без расчета на широкое применение, но тем не менее широко используемых. Не-
которые из них совершенно непригодны для реальной работы, хотя имеют вид
вполне респектабельный, другие, несмотря на убогое оформление и полное отсут-
ствие документации, вполне функциональны. Разобраться в этом многообразии,
собрать законченный комплект программ и правильно его настроить не так-то
просто. В нескольких следующих главах разбирается установка и настройка не-
скольких типичных FTN-программ.
Сделано руками
Каких-либо особенных требований, стандартов и способов написания и докумен-
тирования программ для FidoNet не существует. Каждый программист создает их
в меру своих сил и возможностей и в соответствии со своими представлениями
о том, как должно выглядеть, конфигурироваться и работать его детище. Универ-
сального регулятора в виде рынка и его запросов здесь не существует, так как про-
граммы для FidoNet выпускаются авторами, как правило, с лицензией freeware
или shareware. Тем не менее у большинства программ FidoNet есть общие черты,
зная которые легче разобраться с новой программой, попавшей к вам в руки. Это
в первую очередь:
□ отсутствие программы установки;
□ наличие текстового конфигурационного файла с комментариями;
□ наличие файла (файлов) протоколов (лог-файлы) как обязательного или даже
основного интерфейса вывода любой информации о состоянии программы;
□ программа должна «знать» о расположении основных компонентов Fido-си-
стемы, поэтому будьте готовы описать их расположение на диске вашего
компьютера.
К компонентам, необходимым для работы почти любой Fido-программы, от-
носятся:
□ список узлов сети - нодлист;
□ основной почтовый директорий, где хранится личная почта в формате *.msg;
□ входной (inbound) и выходной (outbound) директории;
□ адресная информация;
□ многие другие параметры, специфичные для различных типов Fido-программ.
Необходимо отметить, что большинство программ FidoNet все же хорошо до-
кументированы и их удобно устанавливать и настраивать. Есть и такие, которые
снабжены программами установки и конфигурации, что, конечно же, значитель-
но облегчает их освоение.
Первые программы FidoNet
Прототипом традиционных FTN-программ была первая программа FidoNet,
fido.exe, некогда составлявшая все программное обеспечение сети. В моем распоря-
жении есть поздняя ее версия, выпущенная автором в 1990 году. Необходимо отме-
тить, что Том Дженнингс - отличный программист. Он автор программы BIOS для
компьютера с процессором Motorola, написанной им для фирмы Phoenix, в которой
он некогда работал. Однако версия, попавшая мне в руки, вовсе не имеет никакой
программы установки и довольно скромную документацию. Конфигурацию про-
граммы нужно производить, исправив с помощью текстового редактора несколь-
ко файлов конфигурации и запустив программу set_fido.exe. Программа fido.exe
рассчитана на использование FOSSIL-драйвера, который в комплект поставки не
входит. В то же время, несмотря на бедность документации и непрезентабельный
внешний вид, эта программа вполне работоспособна. Она является хорошим при-
мером типичной программы для FidoNet.
А где документация?
Редко, но бывает, что документация вовсе отсутствует в комплекте поставки FTN-
программы или ее непросто найти. Причины могут быть следующие:
□ до вас дошел не полный выпуск программы, а новая версия, распространяе-
мая как дополнение к основному архиву. Вам придется искать основной вы-
пуск, так как полученное дополнение, вернее всего, не работает без полного
комплекта файлов;
□ документация есть, но она спрятана в одном из файлов поставки с названием,
в котором трудно заподозрить имя файла описания программы. Например,
очень часто описание помещается в файл с именем readme. Иногда описание
прилагается в специфическом формате. Например, к одной из версий про-
граммы uu2.exe Дмитрия Завалишина (шлюз Fido-Internet) прилагалось опи-
сание в виде гипертекста с программой для просмотра. Есть также примеры
поставок программ с описаниями в таких экзотических для пользователя
Windows форматах, как PostScript или ТЕХ;
□ документации как отдельного законченного электронного документа нет, но
есть нечто ее заменяющее, например часто на эту роль претендует файл с на-
званием history, в котором автор последовательно, по мере разработки про-
граммы, описывал все возможности, которые он реализовывал в очередной
версии. Таким образом, прочитав, что «с версии 0.01 А в командной строке
можно использовать ключ /С для разрешения прерывания работы програм-
мы по Ctrl+Break», вы по крайней мере будете знать о существовании этого
ключа и сможете им воспользоваться. Конечно, это хуже, чем полноценная
документация, но лучше, чем ничего;
□ роль документации выполняет хорошо комментированный текстовый конфи-
гурационный файл программы. Это наиболее частый и наименее неприятный
случай; программу с такой «документацией» опытному пользователю FidoNet
легко настроить и запустить, но для новичка это трудно.
«Плохие» и «хорошие» программы
«Плохой» предпочтительно называть не ту FTN-программу, которая неважно до-
кументирована, не имеет программы установки или которую неудобно конфигу-
рировать. Все эти критерии приложимы к коммерческому программному обес-
печению. С программами для FidoNet положение иное: главный критерий -
безошибочное функционирование. Иногда участники сети даже готовы смирить-
ся с ошибками в программе, если они известны и описано, как избежать их воз-
никновения, лишь бы программа справлялась со своей задачей. Поэтому «хоро-
шая» программа для участников FidoNet - это программа, которая работает,
а «плохая» - та, которую трудно заставить что-либо делать.
В последнем случае не поможет ни подробная документация, ни совершенная
программа установки, ни красивый внешний вид. Все это бесполезно, если про-
грамма не выполняет своей основной функции. Причины выпуска в свет автором
неработающего программного обеспечения самые разные: программа, например,
4*
работает только при определенной конфигурации операционной системы, а ав-
тор, не имеющий в отличие от коммерческих производителей программ базы для
тестовых прогонов кроме своего рабочего компьютера, не заметил этого.
Еще одним важным параметром качества программы FidoNet является ее
компактность. Больших, занимающих много места на диске FNT-программ
мало, поскольку каждая такая программа предназначена для распространения
по сети, и распространение большой программы перегружает сеть.
Подводя итог, скажем, что, несмотря на такие невысокие, на первый взгляд,
требования участников сети к качеству программного обеспечения FidoNet
(описанный выше подход здесь скорее правило, чем исключение), подавляю-
щее большинство FTN-программ компактны, эффективны, неплохо документи-
рованы и работоспособны.
Shareware and Freeware
Уже неоднократно упоминалось, что FidoNet появилась как способ общения опе-
раторов BBS. Ко времени ее зарождения уже сформировались некоторые обычаи,
общепринятые в сообществе BBS на территории Соединенных Штатов, Канады,
воспринятые затем в Европе и остальном мире и далекие от реалий нашей стра-
ны. В частности, было общепринято выпускать программы для BBS с условно-бес-
платной (shareware) лицензией, которая давала право пользователю использовать
ее ограниченное время, а затем или прекратить ее использование, или заплатить
автору небольшую сумму за регистрацию программы. Образец такой лицензии
(это лицензия на использование программы FastList - компилятора нодлистов)
приведен ниже:
FASTLIST
ЛИЦЕНЗИЯ
И ПРАВИЛА ИСПОЛЬЗОВАНИЯ
Апрель 1995
Программное обеспечение FastList (программа и документация) принадлежат:
Copyright (с) 1992-1995 Alberto Pasquale, all rights reserved.
SHAREWARE
Программа FastList распространяется как ShareWare: вы имеете право использовать про-
грамму в течение оценочного периода максимум в 30 дней перед оплатой автору. После оце-
ночного периода вы должгны или зарегистриррваться (см. register.doc), или прекратить исполь-
зование программы.
Вы можете свободно распространять оригинальную и немодифицированную версию про-
граммы FastList в любой форме и на любом носителе, если вы не требуете вознаграждения за
саму программу.
Дистрибутив FastList может включаться в сборники CD-ROM, области файловой подписки,
сборники BBS, если он предоставляется в его полном и немодифицированном оригинальном
архиве.
В любом случае пользователь должен зарегистрироваться у автора после оценочного периода.
ОТКАЗ ОТ ПРЕТЕНЗИЙ
Программа FastList поставляется «как есть», без гарантий какого-либо рода, явных или неяв-
ных, включая но не ограничиваясь подразумеваемыми гарантиями коммерческой ценности
и пригодности к использованию для частных особенных целей.
Персона, использующая программу, принимает на себя все риски, связанные с качеством
и производительностью программы.
Автор не несет ответственности за любой особенный, случайный, важный, прямой, косвен-
ный или подобный ущерб вследствие утраты данных или любых других причин.
Проект FSF и FidoNet
FidoNet - бесплатная, любительская и некоммерческая сеть. Тем не менее так
сложилось, что программное обеспечение сети изначально было по преимуще-
ству платным, хотя и недорогим. Процент бесплатного программного обеспече-
ния для FidoNet долгое время был небольшим, и собрать полноценную FTN-
систему только на бесплатных программах было трудно. Однако к настоящему
времени положение изменилось, и здесь значительную роль сыграли усилия
многих энтузиастов, разрабатывающих программное обеспечение с использова-
нием бесплатных компиляторов GNU. Замечательный проект GNU (Gnu Not
UNIX, то есть «Гну не Юникс») ставит своей целью создание полностью бес-
платной программной среды разработчика, совместимой со стандартами UNIX
(прежде всего с Posix). Проект был начат в 1983 году с манифеста, автором ко-
торого был Ричард Столлман (Richard Stallman), основавший организацию FSF
(Free Software Foundation, или Фонд свободного программного обеспечения).
Английское слово «Free», используемое в названии FSF, означает не только и не
столько бесплатность разрабатываемых программ, но в первую очередь свободу
модификации и развития созданного программного обеспечения, что подробно
оговаривается в Манифесте [1.6], с которого началось существование FSF. Сей-
час в рамках проекта разработаны компиляторы со всех основных языков про-
граммирования, с использованием которых написано большое количество про-
граммного обеспечения (в том числе целые операционные системы, например
Linux). Особенностью GNU-программ является поставка исполняемых моду-
лей вкупе с исходными текстами под единой стандартной лицензией GNU
(размер самой лицензии около 20 Кбайт!), что позволяет организованно до-
полнять и изменять GNU-программы. Хорошими примерами GNU-программ
для FidoNet являются Ifmail (FTN-система для UNIX, в состав которой входят
мейлер, шлюз с Internet и процессор эхо-конференций, так называемый тоссер)
и Binkd (программа для передачи FTN-почты через Internet, портированная для
многих операционных систем).
Пиратство в FidoNet
Существует легенда о FidoNet как сети хакеров, злобно пишущих программы-
вирусы и программы-взломщики в свободное от разговоров друг с другом время.
На самом деле ничего общего с действительностью этот миф не имеет, криминаль-
ной активности подобного рода в FidoNet меньше, чем в любом другом сообществе
любителей компьютеров. Более того, деятельность, подобная описанной выше, -
с использованием ресурсов сети - явно запрещается FidoNet Policy (пункт 2.1.1),
и сисопы строго следят за соблюдением этого пункта.
Существующие конференции, посвященные взлому программ ($CRACK$,
$CRACK$.TALKS, PVT . CRACK, PVT . CRACK . WHERE и некоторые другие) не |
распространяются с использованием официального транспорта FidoNet и переда-
ются только по соглашению узлов.
Что же касается использования незарегистрированного программного обеспече-
ния, то до сих пор в российской части FidoNet это явление очень распространено
в силу материальных причин. Во-первых, участники сети люди небогатые, во-вто-
рых, такие формы оплаты, как электронные кредитные карточки, персональные
чеки и др., доступны не всем. В результате многие shareware-программы исполь-
зуются в FidoNet больший срок, чем испытательный период, указанный в их ли-
цензиях. Однако за последние несколько лет распространения FidoNet в России
многие системные операторы приобрели или зарегистрировали программное
обеспечение, которое используется для подключения к сети. Справочник по про-
граммному обеспечению FidoNet, приведенный в приложении 14, поможет вам
сделать верный выбор.
FidoNet over IP: сказка нового времени
Еще недавно, несколько лет назад, FidoNet стремительно росла. В ту пору это была
молодая, развивающаяся сеть. Сейчас рост продолжается только в нескольких ре-
гионах. Во всем остальном мире FidoNet быстро уменьшается. Особенно стреми-
тельно этот процесс протекает в Соединенных Штатах и в Европе.
Справедливости ради отметим, что регион 50 - один из немногих, где рост
FidoNet продолжается. Но уже очевидно, что явление это временное. Будет Internet,
будет повременная оплата телефонных переговоров - не будет FidoNet. Можно ли
что-либо сделать для сохранения этой уникальной компьютерной субкультуры, это-
го стиля общения? Многие задаются этим вопросом и находят ответ на него в ис-
пользовании возможностей Internet для транспорта почты FidoNet. В этом разделе
будет дано общее представление о технологии Fido-over-IP, как порой называют
использование Internet в Fido. За более точным описанием следует обратиться
к главе И.
Адреса FidoNet используются при написании двух основных типов писем. Лич-
ная почта (netmail) и письма в телеконференции (echomail) составляют ту среду
общения, ради которой существует FidoNet. Для того чтобы понять, как может
использоваться Internet в FTN-сетях, нужно иметь хотя бы самое общее представ-
ление о функционировании Fido-системы.
На рис. 1.20 показан путь письма в сети от одного компьютера до другого, при-
чем весь набор совместно функционирующих программ изображен только с од-
ной стороны, с другой он воспроизводится аналогично.
После написания письма системным оператором в программе-редакторе Fido-
почты оно попадает либо в базу личных писем (netmail message base), либо в базу
эхо-почты, если это письмо в эхо-конференцию.
Затем письмо подготавливается к отправке или упаковщиком личной почты
(netmail packer), или эхопроцессором в случае обработки эхо-почты. После этого
База данных
нетмейла
Редактор писем
База данных
эхо-почты
2^'
Упаковщик
нетмейла
Почтовая программа
(мейлер)
Процессор
эхо-почты
Исходящий
директорий
мейлера
Рис. 1.20. Стандартный набор программного обеспечения системы FidoNet
в дело вступает центральная программа FTN - почтовая программа, или Fido
Mailer (попросту «мейлер» на привычном Fido-жаргоне).
Это наиболее сложная программа во всем наборе FTN-программ (ее описание
содержится в главе 7). Необходимо отметить, что она взаимодействует с комму-
никационным портом компьютера (и через него - с модемом) через отдельную
программу - коммуникационный драйвер FOSSIL (глава 6).
Посредством этого драйвера устанавливается соединение с другой аналогичной
Fido-системой, через него проходит весь поток передаваемой информации. Аб-
бревиатура FOSSIL составлена из начальных букв некогда популярных FTN-про-
грамм.
Виртуальный модем Реймонда Гвина
...Несмотря на формальную правильность, это мне неприятно,
потому что я не люблю, когда из пушки стреляют по воробьям,
вне зависимости от того, насколько эффективно пушка может
справляться с такой работой
Э. Дейкстра
Счастливая мысль избавить авторов FTN-мейлеров от написания интерфейса вза-
имодействия с модемом оказалась плодотворной, и именно она подсказала не-
сколько лет назад автору популярного FOSSIL-драйвера идею замены FOSSIL
интерфейсным модулем взаимодействия с другим FTN-мейлером через Internet.
Действительно, пусть мейлер «думает», что он по-прежнему взаимодействует
с модемом и телефонной линией, при этом можно легко воспроизвести весь набор
функций FOSSIL-драйвера, имитировать стандартные ответы модема на выдава-
емые команды и ситуации, возникающие в процессе установления соединения.
Например, при обрыве связи передавать мейлеру NO CARRIER - стандартный
ответ модема при обрыве соединения и BUSY («занято»), если от противополож-
ной стороны приходит сигнал «перегрузка». На самом же деле соединение будет
устанавливать по одному из распространенных Internet-протоколов, и наиболее
удобным и простым в этом смысле является известный протокол TELNET, обра-
зующий прозрачный символьный канал от одной системы до другой. TELNET
использует в свою очередь протокол с устранением ошибок TCP и таким образом
не требует дополнительной их коррекции.
Так или приблизительно так рассуждал, вероятно, Реймонд Гвин (Raymond
Gwinn), создавая программу-драйвер, названную им Vmodem - Virtual Modem
Driver, надолго ставшую стандартом де-факто при передаче Fido-почты через
Internet. Многие FidoNet-системы и BBS до сих пор используют этот подход, од-
нако он, к сожалению, тоже не лишен недостатков:
□ прежде всего, не существует бесплатных программ с аналогичными Vmodem-
функциями (сам Vmodem распространяется автором как shareware, и бесплат-
ное использование его незаконно). Vmodem существует только в версии для
операционной системы OS/2. Драйверы, функционально ему аналогичные,
написаны для DOS (например, RLFOSSIL) и Windows (СОМТ и др.), но не
все они соответствуют стандарту FOSSIL и работают в целом хуже, чем
Vmodem;
□ Характеристики соединения через Internet часто очень существенно отлича-
ются от таковых для обычного прямого модемного соединения. Диапазон
скоростей, наличие ошибок соединения, скорость установления соединения -
все здесь иное. Кроме того, не надо забывать, что мейлер при использовании
Vmodem делает массу ненужной работы, например запускает протоколы
с коррекцией ошибок на «чистом» канале, что чаще всего только мешает соеди-
нению.
Поэтому нередко бывает, что Fido-мейлер отказывается устанавливать соеди-
нение через Vmodem или установленное соединение неустойчиво, быстро разры-
вается. Если вы подключены к Internet через proxy-шлюз, приготовьтесь - ваш
Fido-мейлер через Vmodem, вернее всего, работать не будет.
Поэтому, несмотря на широкую распространенность и известность в FidoNet,
Vmodem так и не стал основой Fido-over-IP.
FidoNet в мире UNIX
Тильки москаль кохае Паскаль,
Мы же у си пишем на Си!
Фольклор FidoNet
Если у вас есть Internet on-line, не поленитесь зайти на страничку http://
www.average.org/~crosser. Автор ее - человек разносторонний, и страничка интерес-
ная: авторская песня, глобальные сети и, конечно же, программирование. Евгений
Черкашин (Eugene Grosser) разработал и написал «с нуля» функционально полный
комплект программного обеспечения FidoNet - комплекс программ под общим
названием Ifmail.
От многих других программ FidoNet, продаваемых как shareware, эта програм-
ма отличается тем, что распространяется в соответствии со стандартной лицензи-
ей GNU (то есть бесплатно и вместе с исходными текстами).
Ifmail - большая программа, около 50 тыс. строк исходного текста. Она включает
в себя FTN-совместимый мейлер (Ifcico), работающий с модемом, и эхо-процессор
(Ifgate), использующий при обработке эхо-конференций FidoNet известный прото-
кол Internet, предназначенный для обработки телеконференций - NNTP.
Последняя особенность позволяет применять Ifmail как универсальный шлюз
между сетью FidoNet и Internet. Почти все эхо-конференции региона 50 FidoNet,
известные и популярные в Internet как иерархия Fido7, проходят через Ifmail.
С самого зарождения FidoNet стояла задача передачи почты в сети, основан-
ные на другой технологии, с другим форматом адреса - прежде всего в Internet.
С этой целью в сети установлены системы, называемые шлюзами, определены
правила преобразования адресов FidoNet в символьные адреса Internet и заре-
гистрирован специальный домен (выделенное адресное пространство) Internet -
fidonet.org.
Приведенный выше адрес 2:5049/12 однозначно преобразуется в символьный
адрес Internet как fl2.n5049.z2.fidonet.org. И если вы захотите написать письмо из
Internet на Fido-адрес автора этой книги, можете смело отправлять его сюда:
Amir.Shabashvili@fl2.n5049.z2.fidonet.org. Пройдя ряд межсетевых шлюзов, пись-
мо дойдет до моего компьютера. И, скорее всего, пройдет при этом через одну или
две системы, на которых установлен Ifmail.
Ifmail также позволяет организовывать соединения с другой аналогичной про-
граммой через Internet, используя стандартный Internet-протокол TCP, решая та-
ким образом задачу полноценного использования Internet для нужд Fido.
Последние версии Ifmail могут производить соединение и с системами, исполь-
зующими Vmodem.
Вы можете легко скачать Ifmail из Internet вместе с исходными текстами, на-
пример, с этого адреса: http://www.average.org/ifmail/ или получить его в составе
расширенного дистрибутива бесплатной операционной системы Linux, но необхо-
димо помнить, что эта прекрасная и действительно работоспособная почтовая си-
стема создана и оттестирована только для UNIX.
Перенести (или, как говорят, портировать) Ifmail под другие операционные
системы возможно - для того и существует проект GNU, для этого (в частности)
и распространяются программы в исходных текстах - да только вот пока никто
этого в полной мере не сделал. Есть попытки переноса Ifcico под OS/2, но распро-
страненного и широко используемого варианта нет.
Итак, Ifmail используется по всему миру немногочисленными энтузиастами,
пустившимися в рискованное плавание по могучей реке с названием UNIX. Но не
у всех хватает решимости на такое, по выражению Горького, «большое, важное, но
никому не нужное дело», как изучение и использование UNIX (шутка).
FidoNet - домашняя сеть. Дома удобно иметь что-нибудь поспокойнее UNIX.
Программа из Гипербореи
Магадан, Магадан, Магадан,
Давний символ беды и ненастья,
Может быть, не на горе - на счастье
Ты однажды судьбою мне дан?..
А. Жигулин
Почему-то считается, что настоящие программисты работают в определенных
местах нашей планеты: Северной Америке, Европе, в крайнем случае - Москве,
Петербурге или Киеве. Но не в Магадане. Город северный, надо бороться за жизнь,
жечь огонь.
Однако, как выясняется, исключения бывают и здесь. Приглашаю вас посетить
страничку по адресу: http://rat.tts.magadan.su/-maloff/, поддерживаемую про-
граммистом из Магадана Дмитрием Маловым. Им создана программа Binkd, все-
го за год после выпуска первой версии ставшая самой распространенной FTN-
программой, используемой для проброса Fido-прочты через Internet.
Binkd, как и Ifmail, написана и распространяется вместе с исходными текстами под
бесплатной лицензией GNU. Но, в отличие от Ifmail, программа эта не является заме-
ной всему набору FTN-софта, она берет на себя только почтовые функции. Поэтому
ее легче портировать под основные операционные системы (исходно Binkd, как и Ifmail,
создан для UNIX). Существуют работоспособные варианты Binkd для OS/2, Win-
dows 95, Windows NT. Есть вариант под DOS. Нет версии для Windows 3.11 - что ж,
рискните, попытайтесь перенести - программа небольшая (всего И тыс. строк). На
Binkd стоит остановиться подробнее, поскольку именно она, возможно, станет той
панацеей, которая спасет FidoNet от вымирания. Название программы - Binkd - под-
черкивает ее связь со старой, хорошо себя зарекомендовавшей программой - мейле-
ром Binkley Term, используемым в FidoNet много лет.
От большинства остальных программ Binkley Term отличалась тем, что распро-
странялась в исходных текстах и ввела новый стандарт на формат подготовлен-
ной к отправке информации - так называемый Binkley-style outbound (BSO).
С появлением Binkley Term почтовые программы FidoNet разделились на АМА
(Arc-Mail Attach) и Binkley-style мейлеры. Есть также мейлеры, поддерживающие
оба режима, например известный мейлер Т-маП, автором которого является
Андрей Елкин из Петербурга.
Итак, Binkd рассчитана на работу в паре с Binkley-совместимым мейлером
либо, если нужна только Internet-система, с Binkley-style упаковщиком почты.
Изображенная ниже на рис. 1.21 схема показывает, как встраивается Binkd в сис-
тему программного обеспечения узла FidoNet.
Обычный Fido-мейлер и Binkd имеют один общий исходящий BSO-директо-
рий. При появлении в нем почты для узла, описанного в конфигурационном фай-
ле Binkd, последний немедленно выставляет флаг «занято» для этого узла и дела-
ет попытку отправки почты через Internet. При отсутствии такого соединения
почта отправляется как обычно.
Отличительной особенностью Binkd является использование собственного
протокола установления соединения, названного автором Binkp. Этот протокол
Рис. 1.21. Набор программного обеспечения системы FidoNet для работы
через Internet с использованием почтовой программы Binkd
учитывает особенности среды передачи Internet и устойчиво работает на любых
скоростях передачи в отличие от связки Fido Mailer-Vmodem. Почтовая сессия
Binkd может тянуться сутками, если скорость соединения низка, и тем не менее
завершаться успешно или продолжаться пару секунд, если вы связываетесь с компь-
ютером в одной сети Ethernet.
Впечатляют и другие характеристики Binkd. Например, размер программы. Мы
привыкли к многомегабайтным текстовым редакторам, процессорам электронных
таблиц. Так вот, версия Binkd для OS/2, (так называемая ЕМХ-версия) имеет раз-
мер 35 Кбайт! К ней нужен только крошечный конфигурационный файл с описа-
ниями нескольких очевидных параметров и списком Internet-адресов систем, с ко-
торыми вы хотите установить соединение, и этого достаточно.
Binkd - истинно UNIX-программа. От привычных нам DOS/Windows монст-
ров ее отличает и полное отсутствие интерфейса взаимодействия с пользовате-
лем. Единственное, что вы можете сделать после запуска программы, нажать пару
раз Ctrl+Break для ее прерывания. Это программа из разряда тех, что в мире
UNIX называют «Демон» (Daemon) - невидимый дух, молча делающий свою ра-
боту. Вся необходимая отчетная информация записывается в файл протокола,
хотя при желании можно настроить Binkd и на одновременный вывод текста от-
чета на экран, но, как правило, это не делается - ни к чему.
Замечательной особенностью Binkd является его многопоточность. В конфигура-
ционном файле определяется количество серверных («вам звонят») и клиентских
(«звоните вы») соединений-нитей, и можно не заботиться, как прежде, о занятос-
ти вашего телефона - Binkd потянет столько сеансов связи, сколько вы описали
и сколько позволяет ваш Internet-канал.
Более подробное описание протокола Binkp приведено в конце главы 2, а са-
мой программы Binkd - в главе И.
FidoNet.net: Fido DNS
Появление описанных выше способов проброса Fido-over-Internet поставило до-
полнительную задачу распознавания Internet-адреса компьютера по его Fido-ад-
ресу Суть проблемы заключается в следующем. Вот как выглядит описание ад-
реса одной из систем, с которыми я обмениваюсь почтой, в конфигурационном
файле моего Binkd:
2:5049/64@fidonet 194.186.108.130 <пароль>
В строке сначала идет Fido-адрес системы, затем ее цифровой или символьный
Internet-адрес, далее пароль на почтовую сессию (последний может опускаться).
Неудобство этого описания заключается в том, что вам неоткуда взять Internet-
адреса своих корреспондентов, в отличие от FidoNet-адресов, список которых
(нодлист) есть на каждом узле сети.
Получить эту информацию можно только непосредственно у системных опера-
торов, что не слишком удобно. Кроме того, Internet-адреса иногда меняются, при-
ходится стороной узнавать об этом и вносить исправления.
Для решения этой проблемы системными операторами региона 50 FidoNet был
зарегистрирован Internet-домен fidonet.net. Теперь все компьютеры, использую-
щие технологию Binkd для передачи почты Fido, регистрируются в домене
fidonet.net стандартным образом, например компьютер автора как fl2.n5049.z2.
fidonet.net.
В последнюю версию Binkd встроено распознавание адресов в домене fidonet.net,
и строка, приведенная выше, упростилась:
2:5049/64@fidonet <пароль>
Теперь, когда Binkd пытается отправить почту для узла 2:5049/64, он самостоя-
тельно строит символьный Internet-адрес вида fl2.n5049.z2.fidonet.net и получает
через службу имен Internet (DNS) цифровой Internet-адрес, который и использует-
ся при установлении соединения. Появление Binkd и протокола Binkp вызвало
желание разработчиков почтовых программ использовать эту новую технологию.
Как минимум еще две почтовых shareware-программы (Argus и IRex) используют
протокол Binkp.
Как IP хотели прописать в нодлист
История появления в нодлисте FidoNet-узлов, подключенных только через
Internet, интересна и поучительна. Когда во второй половине 90-х годов в России
были созданы и получили распространение FTN-программы, предназначенные
для проброса Fido-почты через Internet (описанные выше Binkd и Ifmail), появи-
лись системы FidoNet, подключенные к сети только через Internet.
Желание операторов подобных систем получить не пойнт-адрес, а обычный уз-
ловой, было вполне оправдано, поскольку, получив статус узла, намного проще
представлять сервис другим системам FidoNet. Однако это долгое время казалось
совершенно невозможным, так как Полиси, основной документ, по которому суще-
ствует FidoNet, и базовые стандарты сети не предусматривают существования сис-
тем, составляющих сеть, на ином, не телефонном типе транспорта.
Единственным прецедентом, намекающим на возможность решения этой проб-
лемы, было существование в нодлисте ISDN-систем. Это также телефонные сис-
темы, имеющие телефонные номера, но позвонить на них с обычного телефона,
как правило, нельзя, нельзя и соединиться с системой ISDN с использованием
обычного модема. Тем не менее в Западной Европе такие системы цифровой теле-
фонии широко распространены и стандарт нодлиста был соответствующим обра-
зом доработан.
Для решения проблемы включения в нодлист Internet-систем координатором
второй зоны в 1997 году была создана конференция IP_CONNECT, и меньше чем
через год такие системы появились в нодлисте. Нашли очень простой выход, не со-
здающий противоречий с Полиси: все такие системы помещены в нодлист как при-
ватные узлы (PVT). Приватные системы использовались и ранее для тех случаев,
когда системный оператор по тем или иным причинам не мог разглашать номер
своего телефона, но существование его станции в качестве узла было важно для
местной территориальной сети. Такие PVT-узлы всегда были редкостью, исключе-
нием, так как большое их количество нарушило бы связность сети (прямое соеди-
нение с приватной системой без специальной договоренности невозможно).
Сейчас получение так называемого IP-only («только через Internet») адреса
несложно, нужно только представить сетевому координатору убедительное обо-
снование необходимости выдачи именно узлового адреса. Узлы IP-only дополни-
тельно авторизуются у регионального координатора, в остальном же процедура
их выдачи ничем не отличается от стандартной.
В настоящее время активно обсуждается включение в нодлист узлов, подклю-
ченных к сети только посредством электронной почты Internet (E-mail). Разрабо-
тано программное соответствующее обеспечение (почтовые программы TransX,
Voyager, IREX), утверждены соответствующие символы-флаги, описывающие про-
токолы E-mail в нодлисте. Уже появились первые приватные системы с узловыми
адресами, подключенные к сети только по E-mail протоколу Одним из известных
случаев, когда подключение по E-mail оказалось единственно возможным средством
коммуникации, был случай русского туриста во Вьетнаме. Бывалый «фидошник»,
имевший намерение сразу после приезда подключиться через Internet к Fido, нео-
жиданно обнаружил, что все сервисы Internet, кроме традиционных HTTP через
прокси-шлюз и E-mail, для него недоступны (так правительство этой страны конт-
ролирует Internet-доступ). Обычные программы вроде Binkd или Ifmail не работа-
ли, пришлось настраивать систему проброса почты FidoNet с использованием элек-
тронной почты.
Более подробное описание формата представления Internet-систем в нодлисте
и используемых протоколах можно найти в главах 2, 11 и в конце файла нодлиста.
Следует учитывать, что хотя сейчас IP-only системы в FidoNet не редкость,
все же считать их обычными узлами нельзя, это именно PVT-узлы, со всеми
ограничениями, налагаемыми на них Полиси. Полноправное существование
Internet-систем в Fido невозможно без коренной переделки Полиси.
Свобода Internet и закон FidoNet
Рассмотренные основные способы проброса FidoNet-почты через Internet доста-
точно удобны, широко используются членами сети, вот почему количество сис-
тем, подключенных через Internet, стремительно растет. Есть и участники сети,
подключенные (в порядке эксперимента) только через Internet.
Создан ряд эхо-конференций, в которых активно обсуждаются различные ас-
пекты использования Internet в FidoNet.
Так, популярная международная эхо-конференция IP_CONNECT посвящена об-
суждению проблемы включения Internet-систем в адресный список FidoNet
Nodelist. В конференциях SU. IP. SYSOP и RU. FIDO .NEXTGEN обсуждение ведет-
ся на русском языке.
Однако распространение Fido-over-IP породило проблему, решение которой до
сих пор не найдено. Вот она во всей своей неприглядности:
Fido-over-Internet противоречит основному закону FidoNet - Fido Policy.
Действующая редакция Полиси 4.07 принята в 1989 году. Десятилетие - огром-
ный срок, за это время многие положения Полиси устарели. Устарели даже в при-
ложении к FidoNet без использования Internet-транспорта. Что же говорить
о Fido-over-Internet - в 1989 году об этом никто не думал.
Так, например, Полиси устанавливает в качестве стандартного протокол соеди-
нения, который должен поддерживаться любой FidoNet-системой, так называе-
мый протокол FTS-0001, основанный на древнем протоколе передачи файлов
Xmodem. Xmodem не только старый, но и попросту плохой протокол. Он неважно
работает на обычных телефонных линиях, а уж использовать его при соединении
через Internet было бы верхом глупости.
И тем не менее дискуссия в IP_CONNECT то и дело возвращается к проблеме
Internet-реализации FTS-0001. Вот оно, желание «изменить, ничего не меняя» - де-
виз, под которым пока происходит внедрение Internet-транспорта в жизнь FidoNet.
Есть и другие положения Полиси, полностью теряющие смысл в Fido-over-
Internet. Пока эта проблема не будет решена, Internet так и останется в Fido «те-
невым» транспортом. Рано или поздно придется назвать вещи своими именами.
Либо FidoNet изменится формально, допустив преобразование основных поло-
жений своего основного закона - Полиси и разрешив полноправное подключе-
ние к системам, соединенным с сетью только через Internet, либо она так и будет
хиреть, вымирать, уподобляясь динозаврам, - былая мощь и сила, ныне архаика.
Судьба новых идей в FidoNet
FidoNet не так легко приемлет новые идеи и подходы, как это может показаться
на первый взгляд. На самом деле это довольно косная сеть: кому-то жаль свобод-
ного времени на настройку программы, другого вполне устраивает нынешнее
положение вещей. Так из десятков и сотен личных отношений складывается лицо
сети, не слишком расположенное к новациям. Механизм принятия новых стан-
дартов и правил тем не менее есть, и о нем уже упоминалось.
FidoNews. Электронный журнал FidoNews по традиции используется для анон-
сирования новых идей и предложений, и публикация в FidoNews является по су-
ществу необходимым этапом на пути внедрения идеи в практику FidoNet.
FTSC. FidoNet Standards Committee (FSC), впоследствии переименованный
в FidoNet Technical Standards Committee (FTSC) был учрежден в 1986 году [1.7],
после создания Международной Ассоциации FidoNet (IFNA) и под ее патрона-
жем, с целью создания (подобно RFC в Internet) стандартов и предложений.
В состав FSC входили авторы-разработчики программного обеспечения под
председательством известного и пользующегося большим авторитетом в FidoNet
сисопа Ренди Буша. Комитет по стандартам FidoNet существует и сейчас, это
единственная неформальная организация, которой по штату положено рассмат-
ривать и издавать новые стандарты FidoNet. Правда, FTSC уже очень давно не
издает новых стандартов (FTS), поскольку процедура их принятия включает об-
щесетевой референдум, для проведения которого требуются значительные уси-
лия, поэтому список принятых в последние годы документов состоит по большей
части из предложений (Proposals - необязательных стандартов) и новых версий
стандартов.
ZCC (Zone Coordinator’s Council, или совет координаторов зон) в отсутствие
персоны международного координатора (IC) должен принимать наиболее важные
для FidoNet решения. Однако ни одно такое решение так и не было принято.
Таким образом, можно сказать, что существующие механизмы развития сети
не работают, но это будет верно только отчасти. Действительно необходимые
идеи, в которых нуждается сеть, быстро становятся стандартами де-факто. Напри-
мер, так было с протоколом BINKP, который стал самым распространенным про-
токолом при соединении Fido-систем через Internet, несмотря на отсутствие со-
ответствующего FTS (недавно такой стандарт появился).
С другой стороны, отжившие стандарты практически не используются или
используются чрезвычайно редко, например такова судьба базового стандарта
FTS-0001, основанного на протоколе передачи файлов Xmodem.
Конечно, нет ничего хорошего в таком положении вещей, когда нарушаются
официальные стандарты и де-факто работают неофициальные, но это необходи-
мая плата за отсутствие действующих механизмов развития технологии сети.
Ниже рассмотрены наиболее интересные проекты, реализованные участниками
региона 50 FidoNet в последние годы. Некоторые из них были восприняты сетью,
их можно считать удачными, другие остались невостребованными, и труд их ав-
торов пропал даром, но каждый по-своему интересен и поучителен.
Программа Frip: FidoNet Routing Information Protocol
В FidoNet по традиции основным источником сведений о правилах маршрутиза-
ции личной почты является нодлист. Система хабов, сетевых и региональных хо-
стов и зональных шлюзов, приведенная в нодлисте, вполне достаточна для орга-
низации на ее основе простой и эффективной схемы передачи сетевой почты. Но
сейчас только почтой не исчерпывается информационное наполнение сети. Так,
из 6-10 Мбайт данных, приходящих в сеть 5049 ежедневно, только небольшую
часть (0,5-2 Мбайт) составляет сетевая почта, остальное - эхо-почта, файл-эхи,
передача которых никаким образом не связана со схемой роутинга, предоставляе-
мой нодлистом. Считается, что файлы и эхо-почта либо маршрутизируются от-
дельно от нодлистовой структуры, либо передаются директом с системы-отпра-
вителя на систему получателя. Тем не менее потребность в маршрутизации
файлов и эхо-почты возникает очень часто, и конфигурационные файлы про-
грамм-упаковщиков почты заполняются причудливыми периодами описаний
правил маршрутизации.
Основная идея системы FRIP, изобретенной Дмитрием Завалишиным, заключа-
ется в измерении скоростных характеристик всех имеющихся на данной системе
линков (устойчивых соединений с другими Fido-системами) и принятии решения
об отправке файлов по тому или иному пути в соответствии с установленными си-
сопом критериями. Измерение производится посредством рассылки информацион-
ных файлов специального формата.
Рассмотрим схему работы FRIP на примере системы из четырех узлов (именно
этот пример использует автор программы при описании ее функционирования):
д---------В
I I
I I
С--------D
Здесь буквами обозначены узлы FidoNet, а соединяющими линиями - линки.
Под линком в данном случае понимается «связь между парой узлов на регуляр-
ной основе. Например, прозвонка раз в час, день, неделю - главное, что регулярно»
(фрагмент из описания программы).
Упрощенно FRIP-система состоит из следующих частей:
□ конфигурационного файла описания линков (links.cfg);
□ исполнительного модуля, рассылающего и принимающего анонсы;
□ базы принятых анонсов;
□ построителя карты роутинга.
Далее предоставим слово автору программы:
«Каждый из узлов имеет работающий FRIP, и в links.cfg у него прописаны два его
соседа.
Действие первое: каждый из узлов запускает FRIP, и FRIP отрабатывает рас-
сылку анонсов. При этом генерируется анонс (от него к нему же), в котором сооб-
щается, что он сам знает, как добраться до него, причем очень быстро. В анонсе
указывается дата и время рождения.
Действие второе: FRIP находит сделанные им же анонсы и раздает их окружа-
ющим.
Действие третье: узлы обмениваются почтой. Анонсы с А проникают на Ви С,
сВнаАиР,сСнаАиВисОнаСиВ.
Действие четвертое: каждый из узлов запускает frip.cmd/frip.bat. Frip находит
анонс и раздает его окружающим. Кроме того, узел А из анонсов узнает, что он
умеет доставить почту на Си В, остальные - аналогично. Действие пятое: узлы
обмениваются почтой.
Действие шестое, интересное: узел А получил от В и С анонсы роутинга на узел
D. Поскольку один из них пришел раньше, он и попал в базу роутинга узла А. Более
поздний анонс был отвергнут, так как он шел дольше и, следовательно, хуже. Таким
образом, узел А узнал оптимальный путь роутинга нетмейла для узла D. Точно так
же узлы В, С и D узнали оптимальный путь роутинга для узла на противопо-
ложном углу нашего квадрата.
Действие седьмое, любопытное: узел В получил от D анонс роутинга на узел А.
Поскольку он пришел позже, чем аналогичный от узла А, он был отвергнут. Однако
если бы, скажем, у узлов АиВ связь была бы настолько плоха, что за все это время,
пока анонс шел от А через С и D, они ни разу бы не связались, роутинг переключил-
ся бы на D. Лучше через три хопа, чем никак».
Удобство системы FRIP в том, что после ее запуска отпадает необходимость в на-
стройке статической системы роутинга, отнимающей много сил и времени. FRIP
сам решает, по какому пути информация быстрее всего дойдет до адресата.
FRIP прошел beta-тестирование в регионе 50 и, хотя он не стал основой для
создания региональной схемы маршрутизации почты, его вполне можно исполь-
зовать для настройки схемы маршрутизации файлов.
Альтернативой использованию динамического децентрализованного протоко-
ла FRIP могут служить централизованные статические построители роутинга,
один из которых описан в следующем разделе.
Программа Safrouter: роутинг «по государевым запискам»
Идея программы Safrouter, автором которой является Юрий Сафронов (2:5020/204),
заключается в построении схемы маршрутизации почты на основе централизован-
но рассылаемых региональных карт роутинга. Safrouter знаком со структурой кон-
фигурационных файлов большинства программ-упаковщиков почты и резуль-
татом его работы будет правильная и точная схема маршрутизации для вашего
упаковщика.
Для обеспечения Safrouter свежей информацией о последних изменениях марш-
рутов почты в регионе, по файл-эхе R50ROUTE регулярно рассылается файл R50.rou,
содержащий правила вроде приведенных в табл. 1.10.
Таблица 1.10. Примеры правил маршрутизации в формате программы Safrouter
Правило маршрутизации Расшифровка правила маршрутизации
5007/1 50/913 Почту для независмого узла 2:50/913 отправлять на 2:5007/1
5020/238 5011/АП Почту для сети 2:501 1 (города Уфа и Стерлитамак) отправлять на 2:5020/238
>5020/204 5049/12 5049/AII Почту для сети 2:5049 (город Казань) отправлять на 2:5049/12 через 2:5020/204
2:5020/50 World Оставшуюся почту отправлять на 2:5020/50
Правила разбираются сверху вниз: более общие правила, записанные ниже,
дополняют, но не отменяют более частных, записанных выше, то есть последо-
вательность правил:
2:5020/888 999 555 5030/444 3-.А11/А11
2:5020/50 World
означает: отправить почту для 2:5020/999, 2:5020/555, 2:5030/444 и третьей зоны
на 2:5020/888, а все остальное - на 2:5020/50.
Строки, начинающиеся со значка >, имеют особый смысл: если это правило
начинается с узла, адрес которого приведен первым, то этот узел игнорируется.
Эта возможность служит для удобства записи роутинга на сети. Например, при-
веденная в качестве примера в табл. 1.10 строка:
>5020/204 5049/12 5049/А11
на самой системе 2:5020/204 упростится и будет выглядеть:
5049/12 5049/А11
Кроме файла *.rou, программа Safrouter обрабатывает файл *.tru, содержащий
информацию о дополнительных ветвях роутинга. Например, в сети 2:5049 наряду
с узлом 2:5049/12 еще несколько узлов могут принимать почту для всей сети. Эта
информация находит свое отражение в региональном файле доверительной мар-
шрутизации почты (trusted file-routing), формат которого похож на формат rou-
файла, записанного шиворот-навыворот, то есть строка
5049/А11 12 36 30
означает, что сеть 5049 доверяет узлам 2:5049/12, 2:5049/36 и 2:5049/30 получать
почту для всей сети. В том случае, если один из этих узлов окажется прямым лин-
ком системы, на которой в данный момент установлен Safrouter, на него будет от-
правляться вся почта для сети 2:5049, а также почта на узлы и сети, которые полу-
чают почту от этой сети. Если в линках оказывается два или больше таких узлов,
то предпочтение Safrouter отдает последнему.
Программа Safrouter широко используется в регионе 50 для построения устой-
чивой централизованной карты маршрутизации почты. Простым узлам, не имею-
щим много линков, Safrouter не нужен. Его используют крупные нетмейл-хабы
для упрощения работы по настройке системы маршрутизации почты.
Технология SENDME/IHAVE
Технология, принятая в FidoNet для распространения эхо-конференций и файло-
вых конференций (файл-эх), в процессе распространения чревата производством
дубликатов (дупов) передаваемых сообщений и файлов. Причины этого явления
рассмотрены здесь, к ним мы будем обращаться и дальше, как и к методам борьбы
с дупами (главы 8 и 9).
Однако в Internet давно используется простая технология передачи почты и фай-
лов, которая позволяет избежать опасности распространения дупов, известная как
технология Ihave/Sendme. Например, этот метод используется в online-протоколе
NNTP для передачи news-конференций между хостами в Internet (стандарт Inter-
net RFC 0977 [1.8]). При передаче сообщений по методу Ihave/Sendme стороны
используют идентификаторы сообщений (messageid) для определения наличия
такого сообщения на принимающей стороне. Команда IHAVE («у меня есть») ин-
формирует передающую сторону, что такое сообщение на принимающей стороне
уже есть и посылать его не имеет смысла. Напротив, команда SENDME («пошли
мне») явно запрашивает сообщение, идентификатор которого отсутствует в базе
идентификаторов принятых сообщений.
Использование технологии Ihave/Sendme в приложении к FidoNet давно обсуж-
дается в конференциях RU. FIDO. NEXTGEN, SU. FIDOTECH и других, однако един-
ственной программой, в которой сделана попытка использования этой технологии
для FTN, является файловый процессор UTIC, написанный Анатолием Гузеевым
из Оренбурга (адрес в FidoNet - 2:5054/16). Программа эта написана на языке Java
1.1 и большого распространения пока не получила.
История одного предложения
Выше мы уже рассказывали об идее модерирования посредством голосования
(Moderated by Vote System, M.V.S). Более подробно этот подход описан в главе 8.
При развитии его авторами были использованы все средства, предоставляемые
FidoNet:
□ написан проект стандарта FidoNet, сменивший в процессе разработки восемь
версий, последняя предоставлена на утверждение в FSC;
□ разработано программное обеспечение (Relax!) и проведено тестирование
системы в регионе 50 FidoNet. Программа распространяется вместе с исход-
ными текстами под стандартной лицензией GNU.
Все это позволило системе M.V.S получить некоторое распространение в сети,
однако до повсеместного ее использования еще далеко.
История седьмой зоны
Если нельзя, но очень хочется, то можно.
М. Жванецкий
В 1994-1995 годах в сисопских конференциях региона 50 FidoNet широко обсуж-
далась идея организации на основе региона еще одной зоны FidoNet. Зона - су-
щественно более самостоятельная структурная единица FidoNet, чем регион. Сто-
ронники проекта, получившего наименование Project zone 7, по номеру первой
свободной зоны, считали, что он поможет решению следующих задач:
□ даст региону большее адресное пространство;
□ решит проблему ZMH;
□ переместит исполнительный пост координатора зоны ближе к России;
□ повысит «вес» русскоязычной части FidoNet в мировом Fido;
□ будет содействовать реформированию устаревающей Fido-технологии.
Однако у идеи были и противники, и это не позволило ей выйти за пределы ре-
гиона. Официальных запросов в ZCC на образование седьмой зоны так и не посту-
пило. И хотя сторонниками проекта была организована тестовая зона с адресами
7:*.*, в которой имели хождение свои эхи, организован свой роутинг нетмейла и т.д.,
в целом проект потерпел неудачу, так что большинство перечисленных выше задач
решалось (и решилось!) другими способами:
□ координатор второй зоны выделил для региона 50 дополнительный диапазон
адресов (сети 6000-6099);
□ хорошим решением проблемы ZMH (подробно рассматривается в главе 2)
является предложение замены его сетевым почтовым часом (NMH), также об-
суждаемое в главе 2;
□ уменьшение общей численности FidoNet во всем мире, за исключением реги-
онов 50 и 46, позволило России занять лидирующее положение по численно-
сти узлов. Сейчас «вес» российских сисопов в FidoNet гораздо больше, чем
несколько лет назад. Основным же барьером между Востоком и Западом по-
прежнему остается незнание английского языка русскоязычными сисопами;
□ развитие FTN-технологии постепенно набирает обороты, и немалая заслуга
в этом принадлежит системным операторам из стран бывшего СССР.
Project zone 7 сыграл свою роль в становлении самостоятельного российского
Fido и является ярким примером совместных многолетних усилий большого ко-
личества участников сети по достижению цели, явно безнадежной, но благород-
ной и страстно желаемой.
Изменим Полиси
If you want someone to shut up,
tell him to change policy.;-/
Gisbert Rudolph, 2:2443/2161
Из письма в эхе WWB_SYSOP
Со времени утверждения ныне действующей Полиси версии 4.07 (1989) участни-
ками сети предпринимались неоднократные попытки принятия ее новых версий.
Наиболее современным и проработанным, на мой взгляд, является документ, подго-
товленный сисопом из Москвы Василием Долматовым (Basil Dolmatov, 2:5020/140).
Проект Policy 4.50 был распространен по FidoNet в 1994 году. В июньском выпус-
ке FidoNews за 1994 год [1.9] была опубликована статья автора с описанием особен-
ностей проекта. Большинство из поправок к нынешней версии Полиси актуальны
и сейчас. В частности, проект содержит следующие отличия от действующей вер-
сии Полиси:
□ единый мировой нодлист заменен шестью зональными сегментами, собирае-
мыми координаторами зон независимо;
□ зональный почтовый час (ZMH) заменяется сетевыми почтовыми часами
(МН), сведения о которых можно получить из нодлиста;
□ выборы постулируются как один из двух (наряду с традиционным назначе-
нием) путей для заполнения должностей координаторов FidoNet;
□ процедура импичмента распространяется на все уровни координаторов FidoNet;
□ с FidoNews снимается ярлык обязательности получения каждым узлом FidoNet.
Указывается на возможность распространения «локальных FidoNews»;
□ ослаблены требования к строгому соответствию телефонных кодов и геогра-
фического распределения территориальных сетей;
□ убраны прямые ссылки на используемые коммуникационные стандарты, те-
перь стандарты можно менять независимо от Полиси.
Однако обсуждения предложенного документа не получилось, и в результате
голосование по нему так и не было проведено. Причины этого связаны с самим
механизмом принятия новых версий, так как в самой Полиси постулирован
следующий способ ратификации версий этого важного для сети документа:
□ для принятия измененной версии Полиси используется метод референдума,
где право голоса имеют только координаторы FidoNet;
□ голосование объявляет IC (Международный координатор) по представлению
большинства региональных координаторов;
□ голосуется целиком новый документ, а не поправки к существующей версии;
□ для принятия документ должен набрать более 50% голосов из числа проголо-
совавших.
Как видно из этого списка требований, наличие действующего IC является не-
пременным условием принятия новой версии Полиси, а пост IC в последние годы,
как правило, пустует. Кроме того, необходимо убедить большинство региональ-
ных координаторов в необходимости изменения Полиси, а поскольку текущая
версия Полиси разработана координаторами первой зоны (Северная Америка),
долгое время бывшей самой многочисленной, то их голоса против изменения По-
лней оказываются решающими. Эти два момента до последнего времени делали
ратификацию новых версий Полиси делом почти безнадежным, и процесс агита-
ции и продвижения новой версии Полиси оказывался настолько трудоемок, а ре-
зультат настолько заранее очевиден, что никто из сисопов не хотел истратить на
него большую часть своих сил в течение длительного времени, необходимого для
проведения подобной кампании.
Вот, например, как распределились голоса при референдуме по версии проекта
Полиси, называемого WorldPol («Всемирная Полиси»), очень радикального и в от-
личие от проекта Долматова имевшего гораздо меньше общего с текущей версией
Полиси (WorldPol был подготовлен в 1990-1991 годах усилиями в основном си-
сопов четвертой зоны (табл. 1.11).
Таблица 1.11. Результаты голосования весной 1991 года
по проекту Полиси FidoNet «WorldPol»
Зона Да Нет Воздержались
0 — 1 — (международный координатор)
1 17 65 —
2 46 12 23
3 3 14 —
4 И — —
5 Z — 3 —
О Всего 77 95 23
% голосов 39.5 48.7 11.8
Данные голосования взяты из статьи в FidoNews за 20 мая 1991 года [1.10]. Из-
менение численного состава FidoNet в последние годы (увеличение доли второй
зоны в общем числе сисопов FidoNet) не меняет ситуацию, поскольку число реги-
онов практически не изменилось, а право голоса при ратификации новой версии
Полиси имеют только региональные координаторы.
FidoNet сегодня: антропологические заметки
FidoNet - это прежде всего социальный
механизм. Было совершенно очевидно
с самого начала, что она становится, скорее,
социальным чудовищем, чем технической
тварью.
Том Дженнингс
Современная сеть FidoNet - это не только техническое компьютерное образова-
ние, она имеет также и некоторые черты социального организма. Многое в сети
регулируется традициями и обычаями, складывавшимися в течение десятилетий.
Причина этого кроется в том, что в отличие от государства FidoNet не может себе
позволить создания пространного свода законов. Правила, по которым существу-
ет сеть, должны быть просты и компактны, ведь для участников FidoNet сеть -
это всего лишь хобби.
Поэтому все мыслимые и немыслимые ситуации, возникающие в жизни, в По-
лней предусмотреть невозможно; они отданы на откуп здравому смыслу участни-
ков сети (об этом прямо сказано в самой Полиси), а также традициям, обычаям
и предрассудкам, которые выступают на передний план всегда, когда пасует здра-
вый смысл. Сейчас мы уделим внимание некоторым из них.
Социальные стереотипы
Участники сети, как и члены реального общества, играют свои социальные роли.
Здесь нет привычных взаимоотношений «ребенок-родитель» или «работодатель-
служащий», но некий общественный институт, как, впрочем, и неписаные прави-
ла, его укрепляющие, уже сложились, и их нарушение может вызвать неприятные
последствия. В основном суть этих взаимоотношений определяется тем, кто из
двух сторон является поставщиком сервиса, а кто потребителем.
Сисоп BBS и его пользователи. Пользователи BBS прямого отношения к FidoNet
формально не имеют, но поскольку на многих станциях FidoNet есть BBS, и их
пользователи появляются в эхах сети (программное обеспечение BBS позволяет
им использовать эхо-конференции), то и взаимоотношения их со своим боссом,
системным оператором BBS, и с другими сисопами FidoNet, имеют прямое отно-
шение к FidoNet. BBS user (пользователь) - это обычно самое бесправное, заби-
тое и неопытное существо, какое только есть в FidoNet. Всю ответственность за
него принимает на себя сисоп BBS, поэтому сисоп BBS для пользователя есть пер-
вая и последняя инстанция для апелляции. При первом же нарушении правил
FidoNet пользователь может быть навсегда отключен от данной BBS, или же си-
соп отключит возможность использования сервиса FidoNet.
Boss/point. Пойнт уже является субъектом FidoNet, хотя за его поведение точно
так же отвечает его босс - сисоп узла FidoNet, выдавший ему пойнт-адрес. Этим
и определяются их взаимоотношения. Пойнт редко чего-либо требует от босса -
обычно все его желания облекаются в форму скромной просьбы. Некоторые узлы
сети доставляют почту десяткам пойнтов, и у них нет времени на пространные
ответы, поэтому чаще всего письма босса кратки, хотя и информативны, в проти-
воположность подробным, детальным изложениям пойнтом своих проблем. Вот,
например, очень характерное шуточное письмо-запрос пойнтового адреса:
**************** Образец прошения о пойнтовом адресе *****************
О дайте, дайте номер мне!
Нижайше прошу Тебя, о великий, да пусть стоит Твой кэриер, как пизанская башня, пусть
святой диалтон будет вечно в Твоем фоне, пусть подохнут все Твои враги (да умрут ламерооб-
разные в пучине бэдпакетов!) и их потроха растерзают толпы бешеных сквишей!
Выслушай меня, недостойнейшего из недостойных! Упавшего так низко, как только может
упасть борда у криворуких (да минует тебя чаша сия).
Не вели казнить, не спеши варить из меня ламерский суп, дай слово молвить волшебное:
«Плиииииииииззззззззз».
Возьми меня, мудрейший (да стошнит релкомовцев от твоего величия), к себе пойнтом.
Возьми!!! Не буду я тревожить Твой неприкосновенный модем тупыми крэшполами во внеуроч-
ное время, а только флоп на 3 дюйма. Возьми меня, мерзейшего, не имеющего телефона, но
имеющего тачку хилую дома (не сравнится она по крутости с твоей машиной). Возьми, ибо юзал
я софт ФИДОшный (да прославится это слово во веки веков), и не заработал ни одного плюса
от коварных модераторов (пусть трепещут они перед твоим могуществом, солнцеподобный).
Возьми меня, я только раз в день буду представать перед ликом Твоим сияющим и копиро-
вать пакеты, и уходить с тремя поклонами, открывая двери задом.
Возьми и воздастся Тебе святым Пивом по литру на каждый килограмм Твоего веса. С благо-
говением перед ЦПСом, нижайше кланяюсь.
С уважением, ~U.
Uplink/Downlink. Взаимоотношения аплинка (поставляющего сервис) и даун-
линка (получающего сервис) похожи в чем-то на описанные выше, но есть и су-
щественные отличия, в случае если и аплинк и даунлинк имеют в FidoNet узло-
вые адреса, то есть являются полноправными членами FidoNet. Аплинк в этом
случае не несет ответственности за поведение своих даунлинков. Они равноправ-
ны в сети. Однако личная неприязнь, если таковая возникает, почти всегда по-
буждает их разорвать линк, и это вполне понятно.
Координатор и его сеть. Взаимоотношения координатора с координируемым
им сообществом (территориальной сетью, регионом, зоной) очень важны для ус-
пешного функционирования FidoNet. Если координатор большой территориаль-
ной сети будет активно участвовать во внутрисетевых конфликтах, принимая
одну из сторон, сеть неминуемо расколется на два враждующих лагеря, и в конеч-
ном итоге координатор вынужден будет оставить свой пост. Несколько проще
координаторам небольших сетей, но проблемы у них те же. Поэтому правильно
выстроенные отношения координатора с сетью - это ключевой момент успешной
работы сети. В отличие от рассмотренных традиций взаимоотношений босс-
пойнт, сисоп-пользователь BBS, отношения сисопов с координаторами немногим
отличаются от взаимоотношений между равными по статусу участниками сети.
Авторитет института координаторства в большей степени основывается на лич-
ных качествах каждого из занимающих соответствующие должности, чем на фор-
мальном «авторитете кресла». Поэтому каждое решение координатора, которое он
принимает в острой конфликтной ситуации, может быть чревато началом дли-
тельной «сетевой войны», и работа координатора всегда есть балансирование на
грани, исполнение роли третейского судьи.
Стиль общения в FidoNet
Стиль письма в FidoNet, как правило, неофициальный; «ты» является привыч-
ным обращением к незнакомому человеку. Этим сеть FidoNet разительно отлича-
ется от традиций электронной почты в Internet, где знакомства заводятся обычно
со всем возможным пиететом. Здесь же вы сразу можете переходить к делу, не
тратя времени на излишнюю (с точки зрения среднестатистического участника
сети) вежливость.
FidoNet иногда называют сетью друзей, имея в виду именно этот легкий, дружес-
кий тон личных писем. Но не надо им обманываться - с той же легкостью, с ко-
торой вы встречаете дружеское участие, вы можете наткнуться и на грубость. Яв-
ление это не такое уж частое, но и не редкость. Такова жизнь.
Встречи и расставания
Я уже давно понял, что нормальному человеку не
место среди дегенератов, поэтому я окончательно
решил выйти из состава этой убогой сети.
Мое последнее письмо,
Igor Milonov, Ex. 2:5020/1 132
Хорошими примерами «критических» точек, где проявляется все лучшее и все
худшее, что есть в FidoNet, являются моменты вхождения в сеть и время расста-
вания с ней. Встреча с сетью - это почти всегда романтическое время узнавания,
время радостного заочного знакомства с «людьми и роботами», новыми концеп-
циями и новыми способами общения. Вхождение в этот мир без чьего-либо дру-
жеского участия невозможно. Вам как минимум должны выдать пойнтовый ад-
рес, чаще всего помочь с настройкой программного обеспечения. Все лучшее, что
есть в FidoNet, проявляется в начале знакомства с сетью. Зато время расставания
с сетью, уход из FidoNet - печальное время. Чаще всего добровольный или вы-
нужденный уход - это следствие затянувшегося конфликта, который «съедает»
все очарование сети, перечеркивает всю пользу, которую приносило вам общение
в FidoNet, и делает невозможным дальнейшее пребывание в сети.
«Наша» сеть
Образ сети как некоего компьютерного братства, компании хорошо знакомых,
связанных общим делом, постоянным фоном присутствует в конференциях
FidoNet. Этому способствует то, что сети, составляющие FidoNet, географически
компактны - это обычно один город, участники территориальной сети часто лично
знают друг друга. Наряду с этим постоянны и столь свойственные русским людям
отношения соперничества центр-провинция, Москва-Петербург и т.д. Существу-
ют, например, провинциальные эхо-конференции (эхи группы PROVINCE. *), пра-
вилами которых запрещены письма с адресов FidoNet, расположенных в столич-
ных городах, то есть из сетей 5020 (Москва) и 5030 (Санкт-Петербург).
Встречи виртуальные и реальные
Люди вносят в сеть все известные им способы общения, и личные встречи знако-
мых заочно участников сети не редкость. В большинстве сетей они проводятся
регулярно. Чаще всего это просто дружеские посиделки: «сисопки» (собрания
узлов территориальной сети), «пойнтовки» (собрания пойнтов узла FidoNet).
Более организованные встречи проводятся реже, так как они требуют слишком
много усилий от организаторов, особенно в таких больших сетях, как 5020 и 5030.
Примерами подобных собраний могут служить концерты и конкурсы, регулярно
организуемые сетевым литературным сообществом ОВЕС. РАСТЕТ (группа конфе-
ренций Fido ОВЕС.*), на которых присутствует несколько сотен зрителей.
Местом ежегодной встречи участников российского FidoNet является весенняя
московская компьютерная выставка Комтек.
В то же время существуют и прочные традиции заочного, виртуального знаком-
ства. Например, в сети TartarNet (Казань) первые два года ее существования не-
многочисленные участники были знакомы в основном заочно. Начало личному
знакомству положила сетевая конференция FidoNet, организованная и проведен-
ная в 1995 году в Казанском университете.
Значки и эмблемы
Изготовление значков и эмблем для участников сети - тема, которая, видимо,
никогда себя не изживет. Она обсуждалась создателем FidoNet Дженнингсом еще
в 1984 году, в первом выпуске FidoNews [1.11], и постоянно обсуждается в тыся-
чах писем, в десятках местных конференций, есть даже посвященные этому пуб-
ликации в прессе [1.12] - словом, это пример того, как пустяшный вопрос может
занимать умы и время тысяч людей просто потому, что им хочется как-то обозна-
чить в реальной жизни свою принадлежность к сети, оставить от виртуального
процесса общения нечто осязаемое, материальное.
«Тюрьма»
Сидишь? Ну сиди. Малюй на стенке
себе на здоровье.
2:5070/666, Руководство
к использованию сервера WALL
Виртуальная тюрьма - это эхо-конференция PRISON, предназначенная для «вос-
питания» пойнтов, нарушающих правила общежития в сети. Создатель и «Почет-
ный Гражданин Начальник» конференции Дмитрий Селезнев (2:5095/6). На кон-
ференцию PRISON подписываются пойнты, совершившие нарушения, при этом
они отписываются от всех остальных конференций и могут читать только ее
(что, откровенно говоря, довольно скучно). Здесь их собеседниками являются «на-
чальники бараков» (то есть узлы FidoNet, боссы провинившихся пойнтов) и другие
«заключенные». К услугам пользователей «тюрьмы» сервер «тюремная стена»
(WALL), управляемый по почте. Несколькими простыми командами можно доба-
вить свою надпись к содержимому СТЕНЫ, просмотреть имеющиеся надписи,
prison - это забавный пример подробной имитации социальных институтов в вир-
туальном пространстве сети. Только в России, вероятно, могла прийти в голову
идея построить тюрьму в свободной любительской сети FidoNet.
Как начинаются и чем заканчиваются конфликты
Конфликты - это непременное условие существования социальных сообществ,
потому что люди не могут бесконечно жить в мире и согласии. Обычным местом
развития конфликтов в FidoNet являются эхо-конференции. Острый спор, не-
спровоцированная грубость - все может служить поводом, все в начале конфлик-
та является горючим, все идет в ход. Отношения выясняются вплоть до вмеша-
тельства модератора, иногда и его вовлекая в ссору.
Если сцепившиеся участники конфликта сами не могут разрешить его - а так
оно, как правило, и случается, - они оба (или один из них) обращаются к сетевому
координатору с жалобой (complaint, или комплейн - в терминологии FidoNet).
В Полиси подробно описан порядок подачи и рассмотрения комплейнов. Пода-
че жалобы должна предшествовать попытка урегулирования отношений с ис-
пользованием личной почты и жалоба должна подаваться «по инстанции». То
есть вы не можете подать комплейн региональному координатору, если не пода-
вали сетевому координатору и не получили его решение.
Результатом удовлетворенного комплейна иногда является экскоммуникация
(удаление из нодлиста) виновной стороны. Удаление на бесконечный срок не
практикуется: как правило, срок обязательно оговаривается в решении координа-
тора и редко превышает полгода.
Выборы в FidoNet
FidoNet родилась как анархическая сеть, и во всех версиях Полиси очень неболь-
шое место занимают выборы координаторов. Выборы как основной механизм за-
полнения должностей координаторов сетей вообще отсутствуют в этом докумен-
те. Согласно Полиси координатор назначается вышестоящим координатором.
Исключение составляют пост международного координатора, избираемого абсо-
лютным большинством голосов координаторов зон, и пост координатора зоны,
избираемого региональными координаторами этой зоны.
В последние годы положение с выборами во второй зоне FidoNet претерпело су-
щественные изменения, и связано это с демократическими убеждениями последне-
го ZC2 Варда Доше (Ward Dossche, 2:292/84). Варду удалось внедрить выборы се-
тевых координаторов всех уровней в практику FidoNet второй зоны, в которую
входит и 50-й регион, и теперь то и дело проходящие выборы сетевых координато-
ров и связанные с ними конфликты и всплески активности - обычное дело.
Выборы сетевых координаторов производятся в соответствии с документом
nc_elect, переработанным для условий 50-го региона, вариант которого приведен
в приложении 9. Согласно nc_elect выборы осуществляет проводящий выборы
(Returning Officer, RO), назначаемый региональным координатором. Результаты
выборов проверяет также назначаемый региональным координатором проверяю-
щий (Vote Checker, VC). Победителем считается кандидат, набравший более по-
ловины голосов. Если число голосов, поданных против всех кандидатов, превы-
шает число голосов, поданных за каждого из кандидатов, победитель на выборах не
объявляется, результаты выборов направляются региональному координатору для
принятия решения о функционировании сети по его усмотрению. Несмотря на раз-
горающиеся порой в процессе выборов страсти, хорошая их организация не позво-
ляет оспорить результаты, и случаи повторных выборов редки, хотя и случаются.
Куда идет FidoNet
Я английский бы выучил только за то,
Что на нем разговаривал Дженнингс!
Фольклор FidoNet
Рассеет и закат
FidoNet - это архаика. Сеть, успешно работавшая на XT и модемах 1200, работает
сейчас на РП и модемах 33600, но идеологически она та же, как и ее Полиси об-
разца 1989 года, как убогий текстовый интерфейс ее программ. Та же доморощен-
ная, рукодельная технология, рассчитанная на использование только коммутируе-
мого соединения, те же протоколы передачи - Zmodem, Hydra, Janus. Где еще в мире
«персоналок» вы найдете примеры программ, успешно работающих и широко ис-
пользуемых на протяжении десятилетия? Только в FidoNet!
Сегодня сеть, так много давшая огромному количеству людей, бывшая притчей
во языцех и светочем в ночи, стремительно вымирает. Статистика убывания нод-
листа говорит сама за себя. На рис. 1.22 приведена кривая изменения численнос-
ти узлов сети, иллюстрирующая процессы стремительного уменьшения населен-
ности FidoNet, происходящие в последние четыре года.
В настоящее время численность сети опустилась приблизительно до уровня
1992 года. Ежемесячно вымирают сети (города), исчезают регионы (страны).
Исчезла из FidoNet Исландия. Вот письмо «последнего из могикан»:
Date: 10 Ноября 97 22:56:40
From: Jon Leosson 2:391/29 Men-At-Work BBS in Njardvik
To: Ward Dossche 2:292/854 Many Glacier in Mortsel
Subj: Отказ от должности
Привет, Вард!
У меня плохие новости. Обстоятельства складываются так, что у меня не будет больше времени
для FidoNet, поскольку моя жена родила нашего первенца несколько недель тому назад, и поэто-
му я хотел бы уйти с должности координатора Исландского региона FidoNet. Я вынужден попро-
сить тебя удалить регион 29 из нодлиста, так как здесь практически не осталось BBS и некому идти
по моим стопам.
Мне жаль.
Всего хорошего,
Jon Leosson jarl@islandia.is
Рис. 1.22. Изменение численности FidoNet в 1984-2000 годах
Что же заставляет FidoNet, сеть необычную, романтическую, разделить участь
Атлантиды? Причины лежат на поверхности. Все то, что некогда делало сеть при-
влекательной, сегодня отвращает от нее. Итак, по пунктам:
□ FidoNet была единственным источником свежей неофициальной компьютер-
ной информации. Два-три дня, максимум неделя - и вы получаете ответ на
свой вопрос. Сегодня уже Internet предоставляет нам поистине неограничен-
ные возможности для поиска и мгновенного получения такой информации;
□ FidoNet была самой дешевой сетью. За ее услуги не надо платить: телефон,
компьютер, модем - и все! Но быстрое падение цен на услуги Internet приве-
ло к тому, что пользоваться Всемирной паутиной гораздо выгоднее и дешев-
ле, чем часами «висеть» на телефоне, перекачивая Fido-почту из другого те-
лефонного региона.
FidoNet была сетью избранных, сетью анархической, всемирным компьютер-
ным братством. Сегодня же бесконечные споры и склоки раздирают местные сети
и регионы FidoNet, отсюда уходят люди, много для нее сделавшие, известные. Уже
очевидно, что в скором времени традиционная телефонная сеть разделит поле
чудес, на котором она царствовала безраздельно с информационными сетями, по-
строенными на иных принципах. Internet - одна из таких сетей. В этих условиях
FidoNet обречена на старение и увядание, поскольку крепко-накрепко связана
с обычной телефонной сетью. Сможет ли FidoNet существовать над этим новым
коммуникационным сервисом? Не использовать иногда, как это сейчас делается,
а именно «жить» над ним? Видимо, без коренной переработки всей технологии
FTN - нет. То, что технические основы построения FidoNet устарели, очевидно.
Вопрос в том, возможно ли их радикально реформировать.
FidoNet по происхождению не демократическое образование, ее политическое
устройство, скорее, олигархически-анархическое. «Центр тяжести» FidoNet до сих
пор находится в первой зоне (Северная Америка). Опыт наблюдения за принятием
решений в FidoNet подсказывает, что радикальные реформы здесь вряд ли пройдут.
Одним из возможных выходов является построение новой сети, независимой от
FidoNet организационно и технически. Есть несколько инициативных групп, раз-
рабатывающих спецификации «FidoNet следующего поколения» (FidoNet Next
Generation), но ни одна из них пока не добилась успеха. FidoNet все еще остается
единственной всемирной любительской сетью.
Умирание или возрождение?
Существует два полярных взгляда на проблему дальнейшего существования
FidoNet. Все сходятся во мнении, что основной причиной похудания нодлиста
является утрата сетью утилитарной ценности. FidoNet перестает быть самым де-
шевым коммуникационным сервисом. Но вот последствия этого непреложного
факта, нашедшего свое выражение в оттоке части населения из FidoNet в Internet,
истолковываются по-разному. Существуют крайние точки зрения.
Мнение I. Сеть FidoNet действительно вымирает. Еще год-два, возможно мень-
ше, и сеть потеряет мировой статус. Все нормальные люди покидают FidoNet, сеть
постепенно становится молодежной тусовкой, малоинтересной для настоящего
компьютерного фаната. FidoNet must die!
Мнение II. Сеть покидают люди случайные, те, кто рассматривал FidoNet толь-
ко как дешевый телекоммуникационный сервис. И слава Богу!
В сети остаются истинные компьютерные фанаты, те, кому сеть интересна сама
по себе. FidoNet never die!
На мой взгляд, последующие несколько лет должны стать судьбоносными для
FidoNet. Сеть должна измениться, чтобы отвечать реалиям сегодняшнего и зав-
трашнего дня.
Куда идет Fido в России
Не все так плохо с FidoNet, по крайней мере, не так безрадостно, как может пока-
заться после прочтения двух предыдущих разделов. Я намеренно драматизировал
ситуацию, чтобы показать направление развития сети, по которому движется и Fido
в России. Но есть и хорошая новость: FidoNet в регионе 50 (Россия) все время
растет. Сейчас российское Fido вместе с регионами русскоязычного Fido (страны
Прибалтики, Украина, Молдова и Беларусь) уже составляет значительную часть
второй зоны - более половины ее численного состава.
На рис. 1.23 приведена кривая изменения численности узлов в регионе 50
FidoNet (Россия и некоторые страны бывшего СССР), доказывающая этот тезис.
Именно в регионах 50 (Россия) и 46 (Украина) в последние годы были созданы
такие известные и новаторские для FidoNet программы, как T-mail, Bink+, The
Рис. 1.23. Изменение численности региона 50 второй зоны FidoNet
в 1990-2000 годах
Brake!, Frip, Ifmail, Binkd, Argus и многие другие. Можно сказать, что FidoNet раз-
вивается сейчас в значительной степени сисопами этих регионов. Общая эконо-
мическая ситуация в России, на Украине и в Белоруссии такова, что ожидать ско-
рого тотального удешевления услуг Internet и современного компьютерного
оборудования не приходится, поэтому можно предположить, что тенденция роста
FidoNet в этих регионах сохранится по крайней мере в течение нескольких лет.
Если к тому же учесть тенденцию уменьшения численности FidoNet в остальном
мире, это означает, что мировое Fido во все большей степени будет становиться
русскоязычным, и влияние русской части сети будет возрастать. Забавная при-
хоть эволюции переместила «центр тяжести» FidoNet с ее родины - Соединен-
ных Штатов Америки - на территорию его бывшего стратегического противника.
Очевидно, что динамика населенности FidoNet в России повторяет таковую
на Западе, только с разницей во времени, отражая специфику развития конку-
рирующих с FidoNet коммуникационных сервисов - прежде всего Internet. Тем
не менее у FidoNet в России все еще впереди, и сейчас это по-прежнему моло-
дая, развивающаяся сеть, об умирании FidoNet на просторах Fido7 говорить
пока рано.
Заключение
Прочитанная вами глава не является полноценным руководством по подключе-
нию к FidoNet. Для этой цели лучше использовать описания программ и краткие
руководства типа «курс молодого бойца», во множестве распространяемые по
сети. Цель этой главы в ином - подготовить читателя к прочтению остальных глав
книги, насыщенных специальной терминологией и другими реалиями FidoNet,
воспринять которые без прочтения данной главы для неподготовленного читате-
ля затруднительно. Надеюсь, что общее представление о FidoNet, полученное
вами, поможет вам и в дальнейшем, во время реального освоения сети.
Глава II
Введение в FidoNet
Полиси, FidoNews и нодлист - это клей,
который удерживает нас всех вместе!
Полиси FidoNet
О чем эта глава
В настоящей главе в сжатой форме изложены основы FidoNet на базе Полиси,
стандартов FidoNet и общепринятых организационных правил и технических со-
глашений, используемых де-факто.
Основным документом, обеспечивающим существование сети, является Поли-
си. Это свод правил или устав, достаточно пространный и подробный, но к насто-
ящему моменту вследствие развития сети уже заметно устаревший и не в полной
мере отражающий специфику FidoNet. Данная глава дает расширенное толкова-
ние устава с учетом произошедших в сети изменений и стандартов де-факто.
Полиси включает как технические правила и требования (в основном касаю-
щиеся времени работы систем, входящих в сеть), так и организационные (поря-
док запроса и получения номера в сети, как вести себя при временных трудностях,
как образовать сеть), а также «политические» (регламент разрешения конфликтов,
а также порядок назначения на должности координаторов, избрания координато-
ров, вынесения вотума недоверия и т.д.). Для полноценного восприятия материа-
ла может потребоваться знакомство с Полиси, поэтому рекомендуется сначала
просмотреть ее перевод, приведенный в приложении 2.
Язык FidoNet
Официальным языком FidoNet является английский. Все документы сети долж-
ны издаваться на английском языке. Некоторые документы региона 50 выпуска-
ются только на русском языке, что, строго говоря, противоречит Полиси FidoNet.
Некоммерческий характер сети
FidoNet - это некоммерческая сеть компьютерных энтузиастов. Ее участники тра-
тят свое личное время и средства на поддержание функционирования сети. По-
этому Полиси запрещает (п. 1.3.6) использовать ее для извлечения выгоды за счет
других ее участников. Полиси FidoNet не исключает деловую переписку и взаи-
мовыгодный обмен информацией, она просто ставит заслон попыткам выкачивать
деньги из других участников сети.
Структура и управление
Основным документом, описывающим структуру FidoNet, является список ее уз-
лов - нодлист, еженедельно обновляемый посредством механизма дополнений
к нодлисту (нодедиффов, nodediffs). В сети используется множество различных
нодлистов, соответствующих тем или иным уровням иерархии, однако только гло-
бальный мировой нодлист является тем документом, на основе которого сущест-
вует сеть. Остальные нодлисты используются из соображений удобства и опера-
тивности.
Структура FidoNet иерархическая, подобное построение вызвано необходимо-
стью удовлетворять требованиям простоты управления и дешевизны телефонных
звонков в пределах одной структурной единицы.
Под управлением в Полиси FidoNet понимается не всеобъемлющее руководство,
а минимально необходимая координация, ограниченная самой Полиси (пп. 1.2.3-
1.2.7, а также пп. 3,5, и 6). Слишком большая нагрузка на координаторов фактичес-
ки означала бы необходимость их профессиональной ориентации на исполнение
своих обязанностей в FidoNet как основного вида деятельности, что
в любительской сети совершенно неприемлемо.
Рассмотрим последовательно, сверху вниз, основные иерархические уровни
организации FidoNet, изображенные на рис. 2.1.
Зона
Уровень иерархии, объединяющий структурные единицы сети в пределах мате-
рика, называется зоной. Всего в FidoNet шесть зон, по числу населенных матери-
ков. Управление зоной осуществляет координатор зоны (ZC). Зона - это наибо-
лее крупное и независимое структурное образование FidoNet. На уровне зоны
могут вводиться (и вводятся) технические новшества и организационные прави-
ла, дополняющие Полиси и стандарты FidoNet. Россия входит во вторую зону
FidoNet (Европа). Зона имеет выделенные системы, называемые шлюзами (гей-
тами, gateways), для обмена почтой с другими зонами FidoNet. Зоны FidoNet су-
щественно различаются по численности, обычаям и т.д. Численность зон на де-
кабрь 1998 года представлена в табл. 2.1.
Рис. 2.1. Структура FidoNet
Таблица 2.1. Географическое распределение
и численность зон FidoNet на декабрь 1998 года (nodelist.338)
Номер зоны Территория Всего узлов % от численности FidoNet
1 Северная Америка 3752 20
2 Европа и страны ExUSSR 13116 71
3 Океания
(Австралия и Новая Зеландия) 352 2
4 Южная Америка 265 1
5 Африка 60 >1
6 Азия 913 5
Регион
Следующей ступенью иерархии является так называемый регион FidoNet.
При выборе границ региона существенное значение имеет телефонный код;
регион - это как правило уровень страны, так как телефонный код обычно опре-
деляется государственными границами. Сисопы региона объединены общностью
языка и культуры и поддерживают основной набор активно читаемых эхо-конфе-
ренций FidoNet на родном языке. Обмен информацией между сисопами разных
регионов существенно менее интенсивен, чем внутри регионов. Россия вместе
с некоторыми странами Средней Азии (Казахстаном, Туркменистаном, Узбекистаном
и Таджикистаном) образует во второй зоне FidoNet 50-й регион, управление ко-
торым осуществляет координатор (RC).
Сеть
Местные сети (local networks) составляют основу FidoNet. Для определения гра-
ниц сети используются, как правило, границы местной телефонной сети, и уро-
вень местной сети - это уровень города или нескольких городов. Поскольку теле-
фонные соединения в пределах местного телефонного кода, как правило,
бесплатны, то вследствие этого участники FidoNet получают преимущество при
звонках, не выходящих за пределы данной сети, и обмен информацией внутри
сетей, составляющих FidoNet, наиболее интенсивен. Сисопы местной сети часто
знакомы лично, имеют общие интересы. Поэтому сети FidoNet представляют со-
бой специфические сообщества со своими традициями и обычаями. Именно они
и формируют особые взаимоотношения, которые принято называть «стилем»
FidoNet. Руководство сетью осуществляет сетевой координатор (NC, Network
Coordinator).
Узел
Рис. 2.2. Схематическое
изображение взаимодействия
узловых систем FidoNet,
пойнт-систем и BBS
Минимальной структурной единицей сети считается узел (node). Он представлен
одной строкой в сетевом списке узлов - нодлисте, еженедельно обновляемом
с использованием файлов изменений - нодедиффов. Узлом управляет системный
оператор - сисоп, определяющий правила использования узла внешними пользо-
вателями. Сисоп обязан поддерживать связь с другими узлами FidoNet, быть
в состоянии отправлять и принимать личную почту FidoNet (netmail), и правила
работы и использования узла, которые он устанавливает, не должны противоре-
чить Полиси сети. Подключенные к узлу пойнт-системы, а также пользователи
BBS, работающие на узле и имеющие возможность взаимодействовать с FidoNet,
не считаются принадлежащими к сети и в некоторых ситуациях могут рассматри-
ваться как воплощения одного и того же сисопа. Иными словами, узел несет всю
полноту ответственности за действия своих
пойнтов и пользователей своей BBS. BBS и ее
пользователи не считаются частью FidoNet
и могут использоваться сисопом для своих
целей, в частности, для извлечения выгоды.
На рис. 2.2 изображена узловая система
FidoNet, включающая три подключенные
пойнт-системы, которые объединены с узло-
вой станцией, чтобы показать, что техничес-
ки пойнт-системы входят в FidoNet как часть
узла, при этом каждая пойнт-система должна
поддерживать весь набор стандартных для Fi-
doNet протоколов и соглашений. Напротив,
BBS технически и организационно отделена от
FidoNet и, несмотря на то, что размещается
она, как правило, на том же самом компьютере,
что и узловая станция, ее пользователи имеют только терминальный доступ к ре-
сурсам BBS и не могут напрямую взаимодействовать с FidoNet. BBS может быть
установлена и на пойнт-станции, что и продемонстрировано на рисунке.
Пойнт
Понятие пойнта и пойнтового адреса было введено для тех случаев, когда пользова-
тель хочет получать весь сервис FidoNet, но не может выполнять минимальные тре-
бования Полиси, предъявляемые к узлу - полноправному члену сети. Пойнт-адрес
выдается сисопом узла FidoNet и записывается через точку от адреса узла (отсю-
да и название - point, точка). Пойнт - полностью совместимая с FidoNet система.
На пойнт-станции может быть установлено программное обеспечение, ничем не
отличающееся по составу от установленного на узле FidoNet. Несмотря на это,
согласно Полиси (1.2.1.2) пойнт очень сильно отличается от узла, а именно:
□ пойнт-адреса не включаются в список участников сети (нодлист);
□ пойнт связан с FidoNet только через узел, выдавший ему пойнт-адрес и по
традиции называемый боссом (Boss-node);
□ пойнты не участвуют в голосованиях по избранию координаторов FidoNet;
□ пойнты не несут ответственности перед сетью за свои неправомерные с точки
зрения Полиси действия - все их обязанности исчерпываются ответственно-
стью перед боссом, выдавшим им пойнт-адрес;
□ пойнты могут связываться с другими узлами FidoNet и передавать им почту
без посредства Fido-станции своего босса, хотя это и не является распростра-
ненной практикой.
Во многих местных сетях используются списки пойнтов - пойнтлисгпы (point-
lists), аналогичные нодлистам. Иногда из них собираются региональные пойнт-
листы, однако по правилам FidoNet такие списки не требуются, и составляются
они добровольцами только из соображений удобства.
Формат адреса
FidoNet использует символьно-цифровой формат адреса, включающий четыре циф-
ровых поля (номер зоны, номер сети, номер узла и номер пойнта) и одно символь-
ное - наименование домена; поля идентифицируются по порядку следования и по
используемым разделителям в том случае, когда применяется неполная запись ад-
реса. Региональная структура FidoNet не отражается в адресе, отдельного поля для
региона нет. По общепринятым правилам региональная принадлежность учитыва-
ется выделением для тех или иных регионов фиксированных наборов номеров се-
тей. Например, для 50-го региона второй зоны FidoNet выделены номера сетей 5000-
5099 и 6000-6099. В общем виде адрес FidoNet можно записать следующим образом:
< N 3ohei>:<N сети>/<Ы узла>.<N пойнта>@<Наименование домена>
Пример: 2:5049/12.12@fidonet
При записи адреса действуют следующие правила:
□ номер зоны занимает крайнее левое поле и отделяется от остального адреса
двоеточием (: );
□ далее следует номер сети, отделяемый от следующего за ним номера узла на-
клонной чертой (/);
□ номер подузла («пойнта»), следующий за номером узла, отделяется от по-
следнего точкой (.);
□ вслед за номером пойнта идет поле, содержащее наименование домена.
Понятие домена было введено после появления сетей, отличных от FidoNet
организационно, но совпадающих с ней технологически, и используется при мар-
шрутизации почты между FidoNet и этими сетями. Наименования домена для са-
мой FidoNet совпадает с названием сети (@fidonet), однако есть и другие подоб-
ные FidoNet сети со своими названиями доменов. Внимательное рассмотрение
структуры адреса FidoNet позволяет сделать вывод, что домен FidoNet появился
в адресе достаточно поздно, так как по своему местоположению он противоречит
логике следования уровней иерархии, отраженных в адресе; если следовать этой
логике, обозначение домена должно предшествовать номеру зоны (и адрес в при-
веденном выше примере должен записываться как fidonet@2:5049/12.12). Однако
именно приведенное выше обозначение является стандартным.
Понятие домена в FidoNet не следует смешивать с доменной структурой адреса
Internet. Для представления FidoNet в Internet выделен Internet-домен fidonet.org,
подробно рассмотренный в главе 10 и не связанный как-либо с рассмотренным
выше FTN-доменом. Наименование домена в адресе FidoNet не должно быть
длиннее 8 символов. В табл. 2.2 приведены примеры адресов FidoNet как полных,
так и сокращенных. Для обозначения полных и сокращенных адресов использу-
ются термины, указывающие на количество используемых в адресе полей. Напри-
мер, полная запись - 5D addressing (D - размерность, dimension), сокращенная -
4D, 3D или 2D. Программное обеспечение FidoNet обычно может использовать
сокращенную форму записи адреса, она часто фигурирует в переписке участни-
ков сети, при этом действуют очевидные правила умолчания. Например, при
Таблица 2.2. Примеры написания адресов FidoNet
Запись адреса Пояснения
2:5049/12.12@fidonet 33:5049/12.12@bbsnet 2:5049/12.O@fidonet Полная (5D) запись адреса - домен fidonet, зона номер 2, сеть 5049, узел 12, пойнт 12 Полная запись адреса - домен bbsnet, зона номер 33, сеть 5049, узел 12, пойнт 12 Полная запись адреса - домен fidonet, зона 2, сеть 5049, узел 12 (нулевой адрес пойнта используется для указания на адрес узла)
2:5049/12.0 4Э-запись того же адреса без указания домена. Обычно однозначно распознается в пределах FidoNet
2:5049/12 Сокращенная (3D) запись приведенного выше адреса. Обычно нулевой номер пойнта опускается, поскольку это всего лишь ссылка на сам узел
5049/12 Сокращенная (2D) запись приведенного выше адреса. Обычно однозначно распознается в пределах данного региона (в приведенном примере - 50-го региона второй зоны)
/12 или 12 Сокращенная (1 D) запись, использовано только обозначение номера узла. Обычно однозначно распознается в пределах данной сети
/12.12 или 12.12 Сокращенная запись пойнт-адреса, с указанием адреса босса. Однозначно распознается в пределах данной сети
.12 Сокращенная запись пойнт-адреса, использован только номер пойнт-системы. Обычно однозначно распознается в пределах данного узлового адреса
Таблица 2.3. Примеры зарезервированных адресов FidoNet
Маска адреса Пример Источник Назначение адреса и пояснения
2:-1/-1 Полней Адрес зарезервирован для узловых запросов; в регионе 50 обычно не используется, вместо него используются адреса узла /9999
*:*/9999 2:5049/9999 Полнен Адрес зарезервирован для узловых запросов; его использование для этого является распространенной практикой
1:1/1 1:1/1 Полиен Адрес для отправки статей в FidoNews
*:*/0 2:5049/0 Полиен, FTS-0005 Адрес хоста местной сети. Хост - узел, доставляющий личную почту (нетмейл) узлам сети
2:2/1002 2:2/1002 Nodelist Адрес постмастера домена Internet z2.fidonet.org
*:<Номер зоны>/0 2:2/0 FTS-0005 Адрес координатора зоны
*.<Номер региона>/0 2:50/0 FTS-0005 Адрес коодинатора региона
*.<Номер региона>/* 2:50/605 FTS-0005 Адреса независимых узлов
*:*/999 2:50/999 - Входной почтовый шлюз сети или региона. Принят к использованию в регионе 50
2:50??/128, 2:60??/128 2:50/128, 2:5020/128, 2:5049/128 - Шлюз с сетью Internet, используется в R50 для обозначения регионального (2:50/128) и сетевых шлюзов.
использовании адреса внутри FidoNet обычно опускается обозначение домена,
внутри сети - номер сети и т.п.
Зарезервированные адреса
Во всем множестве адресов FidoNet есть адреса, специально зарезервированные для
тех или иных целей. Для некоторых случаев это непосредственно указано в Полиси
или стандартах и предложениях FidoNet, иногда же те или иные адреса используют-
ся для каких-то особенных случаев просто по традиции. В табл. 2.3 суммированы из-
вестные автору зарезервированные адреса и их назначение. Поскольку принятые
в регионе 50 (Россия) соглашения важны для читателей, наряду с общепринятыми
в FidoNet адресами в таблице приведены и общепринятые в R50.
Координирование
Функционирование каждого из структурных уровней FidoNet обеспечивается
соответствующими координаторами. На рис. 2.3 показана иерархия координато-
ров на примере сети 5049 региона 50 второй зоны FidoNet, с указанием адресов.
Рядового члена сети тоже можно считать координатором своей системы, и на-
личие большого количества пользователей BBS и пойнт-систем, подключенных
через данный узел, может сделать работу сисопа очень объемной, сравнимой под-
час с работой координатора небольшой сети.
Рис. 2.3. Пример иерархической структуры координирования
FidoNet на примере сети 5049 второй зоны
Общей для всех координаторов обязанностью является составление нодлиста
своего сегмента сети, передача его на следующий уровень иерархии и распростра-
нение на своем уровне полученного от координатора верхнего уровня сводного
нодлиста. Чем выше уровень координирования, тем меньше у координатора долж-
ностных обязанностей и больше работы (поскольку возрастает численность коор-
динируемого сообщества). Например, в обязанности регионального координато-
ра или координатора зоны не входит наблюдение за почтой, поступающей
в подведомственную им сеть, в отличие от сетевого координатора (NC), который
должен предоставить участникам своей сети возможность получения ее с хоста
сети. Меньше всего обязанностей у международного координатора, однако они
очень важны для FidoNet: это составление полного мирового нодлиста из сегмен-
тов, предоставляемых координаторами зон, внесение изменений в некоторые час-
ти Полиси и проведение референдума по эти поправкам, а также некоторые дру-
гие обязанности.
Важным требованием, постулированным в Полиси, является минимизация
числа занимаемых постов. Координаторам не рекомендуется выполнять работу
хаба эхо-почты или файл-эхо хаба, а также совмещать несколько должностей.
Последнее условие в большинстве случаев соблюдается строго, чего не скажешь
об обычной практике совмещения должности координатора и эхо-хаба. В таком
положении нет ничего хорошего, так как, если подобная система покидает FidoNet,
а такое сейчас случается, ее бывает трудно заменить. Тем не менее подобное со-
вмещение является, скорее, правилом, чем исключением.
Кроме обработки нодлиста и распространения файлов-дополнений к нему каж-
дый координатор обязан:
□ обеспечить доступность Полиси и FidoNews для участников подведомствен-
ного ему уровня FidoNet;
□ знать локальную Полиси (то есть те дополнения к основному уставу, которые
приняты в данной структурной единице FidoNet) и делать эти документы
доступными для вышестоящего уровня;
□ содействовать росту сети, поощрять вступление новых сисопов.
Каждый координатор не связан в своих действиях решениями своих предше-
ственников или других координаторов. Он вправе сам, консультируясь с Полиси,
решать те или иные вопросы и отменять решения прежних координаторов, если
они, с его точки зрения, не соответствуют Полиси.
Еще одним важным условием формирования «управляющей вертикали» FidoNet
является принцип рассмотрения всех вопросов «по команде». Иными словами,
пока вашу проблему не рассмотрел (или не отказал в рассмотрении) координатор
нижнего уровня, вы не можете обратиться к вышестоящему - он все равно воз-
вратит ее на предыдущий уровень. Такой подход, как правило, строго соблюдае-
мый всеми координаторами, призван минимизировать нагрузку на координато-
ров верхнего уровня и повысить автономность и управляемость каждого уровня
FidoNet.
Согласно Полиси большинство координаторов назначаются на должности вы-
шестоящими координаторами. Так, сетевых координаторов назначает региональ-
ный, который в свою очередь назначается координатором зоны. Последний изби-
рается большинством голосов региональных координаторов своей зоны и может
быть отстранен ими от должности.
Координаторы зон образуют специфическую управляющую структуру - ZCC
(совет координаторов зон), который функционирует под председательством меж-
дународного координатора, избираемого голосами координаторов зон из состава
ZCC. При определенных условиях этот совет может отменять решения междуна-
родного координатора и даже отстранить его от должности.
Постепенное возрастание влияния демократически настроенного большинства
участников FidoNet привело к тому, что сейчас чаще всего кандидатура на долж-
ность сетевого координатора выбирается не региональным координатором, а участ-
никами сети. Противоречия с Полиси здесь нет, так как RC подтверждает выбор
большинства проголосовавших, назначая новоизбранного NC на должность.
Деятельность системного оператора
Обязанности сисопа исчерпываются ежедневным поддержанием работоспособнос-
ти системы в течение ZMH (один час в день) и чтением почты, адресованной ему
и присланной на его систему. Несоблюдение зонального почтового часа или нера-
ботоспособность системы в течение этого промежутка времени является основа-
нием для исключения из FidoNet без предупреждения, поскольку уведомление
обычно передается нетмейлом, что в данном случае невозможно. Время ZMH за-
резервировано исключительно для нетмейла. Пересылка любой дополнительной
информации (эхо-почты, файлов, работа пользователей BBS) во время ZMH рас-
сматривается как некорректное поведение. Необходимо также знать Полиси
и время от времени освежать это знание, чтобы не проявить себя полным профа-
ном в изредка возникающих ситуациях, когда такое знание понадобится. Более
ничего от рядового участника сети не требуется. Поддержка BBS и ее пользовате-
лей, обеспечение почтой большого количества пойнтов, выполнение тех или иных
обязанностей (например, нетмейл-, эхо-, или файл-эхохаба, держателя пойнтлис-
та и т.п.) - это все не обязательно и выполняется только на добровольных нача-
лах. Однако если сисоп ведет «активный образ жизни», то есть переписывается
по FidoNet с использованием как личной почты, так и эхо-конференций, а также
исполняет добровольно взятые на себя обязательства, то круг его обязанностей
расширяется:
□ сисоп несет ответственность за всю корреспонденцию, попадающую в FidoNet
через его систему. При этом истинное происхождение этих писем значения не
имеет: посланы они пойнтами, пользователями BBS или детьми, случайно
подошедшими к клавиатуре, - все равно ответственность за них целиком ло-
жится на сисопа, чье имя стоит в нодлисте;
□ сисоп имеет право просматривать любую почту, проходящую через его систе-
му, даже если она не адресована ему. Кодированная и шифрованная коррес-
понденция при этом рассматривается как некорректное поведение;
□ не допускается внесение изменений в пересылаемую корреспонденцию, нет-
мейл или эхо-мейл, за исключением необходимых технических строк;
□ не допускается разглашение или использование информации, содержащейся
в личной переписке, транзитом проходящей через систему сисопа;
□ сисоп обязан использовать наиболее свежую версию нодлиста для исходящих
звонков, иначе его система, звонящая в ночное время по ошибочному телефо-
ну, может стать объектом повышенного внимания гражданских властей;
□ сисоп не обязан пересылать чью-либо почту, если он не давал на это согласия.
Пересылка почты через систему без согласия ее хозяина рассматривается как
некорректное поведение.
Деятельность сетевого координатора
Координатор локальной сети (NC) - это человек, с которым вы непосредственно
взаимодействуете при вступлении в FidoNet. Именно он принимает вашу заявку,
отвечает на вопросы и сообщает правила поведения в сети.
В обязанности NC входит:
□ получение и маршрутизация нетмейла;
□ присвоение номеров узлам сети и сопровождение нодлиста;
□ разбор конфликтов.
Получение и маршрутизация нетмейла. В обязанности сетевого координатора
кроме общих требований ко всем узлам (они описаны в предыдущем разделе) вхо-
дит также и маршрутизация почты для участников сети. Для успешного выполне-
ния этой задачи сетевой координатор должен обеспечить функционирование хос-
та сети - компьютера с адресом
<номер зоны>:<номер сети>/0
принимающего внешнюю почту (нетмейл), адресованную узлам данной сети. Се-
тевой Координатор должен организовать доставку полученной почты адресатам,
поставив их в известность о способе ее получения. Обычным подходом в FidoNet
является построение сетевой схемы маршрутизации почты, включающей кроме
хостового компьютера так называемые хаб-системы, получающие почту с хоста
сети и раздающие ее узлам.
Присвоение номеров новым узлам сети. Сетевой координатор принимает реше-
ние о включении в сеть новых систем и выдает им адреса (номера узлов). Сущест-
вуют различия между локальными сетями в правилах выдачи узлового адреса
(фактически это различия в правилах приема в FidoNet). У вас могут попросить
рекомендацию, NC может установить срок рассмотрения заявки, может совето-
ваться с другими узлами. Все это делается для того, чтобы полноправными участ-
никами сети не стали случайные, неквалифицированные люди или любители ис-
пользовать общедоступный бесплатный сервис в своих корыстных целях.
Несколько примеров отказа в выдаче узлового адреса приведены в самой По-
лней - см. «Поучительные истории» (п. 10). Иногда существующие в данной ме-
стной сети правила явно указаны в соответствующей локальной Полиси.
Чаще всего вместо локальной Полиси для информирования участников сети ис-
пользуется механизм эхо-конференций, в которых NC регулярно публикует инфор-
мацию о правилах и способах подключения к сети. В приложении 12 приведен при-
мер подобной информации. Этот FAQ (ответы на часто задаваемые вопросы)
предназначен для информирования участников сети TartarNet (2:5049), он регуляр-
но публикуется в эхо-конференциях 5 049 . SYSOP и KAZAN. GENERAL. Сетевой ко-
ординатор должен обязательно и в разумные сроки дать ответ на запрос узлового
адреса. Время, которое требуется для включения нового узла в мировой нодлист,
как правило, не превышает 2-3 недель.
Сетевой координатор также ответственен за составление и передачу на выше-
стоящий уровень (региональному координатору) сетевого сегмента нодлиста.
Разбор конфликтов. Сетевой координатор - это первая инстанция для приема
и разбора жалоб. Обычно вместо слова «жалоба» используют кальку с английс-
кого - комплейн {complaint), чтобы подчеркнуть, что речь идет о формальной
жалобе, порядок подачи которой подробно описан в Полиси (см. приложение 2,
пункты 2.6, 9). Результатом разбора конфликта может быть экскоммуникация
(исключение из нодлиста) провинившейся, с точки зрения NC, стороны. Исклю-
чение очень редко бывает бессрочным, чаще всего срок экскоммуникации не пре-
вышает нескольких месяцев. Правила подачи комплейнов подробно рассмотре-
ны далее в этой главе.
Деятельность регионального координатора
Региональный координатор (RC) ведает делами в территориальном объединении
местных сетей FidoNet, называемом регионом. Согласно Полиси RC назначается
координатором зоны, однако в последние годы утвердилась практика выборов пре-
тендента на этот пост. Выборы проводятся прямым голосованием всех узлов регио-
на. Более логичным и соответствующим традициям FidoNet было бы голосование
сетевых координаторов, тем не менее реальность именно такова, и выборы регио-
нального координатора выливаются в продолжительный марафон, напоминающий
привычную картину реальной жизни: множество кандидатов, большое количество
бесполезных писем в эхо-конференции, «разоблачительные» материалы, невысо-
кий процент принимающих участие в голосовании и т.д. Избранный сисопами
региона кандидат в полном соответствии с Полиси назначается на пост зональ-
ным координатором.
В обязанности RC входит:
□ присвоение номеров независимым узлам;
□ присвоение номеров местным сетям;
□ сопровождение нодлиста;
□ разбор конфликтов.
Присвоение номеров независимым узлам. Узел, не принадлежащий ни к одной
сети, называется независимым (independent node). Независимый узел выдается
тогда, когда местность, в которой располагается система FidoNet, не покрывается
ни одной сетью, а также в некоторых других случаях (см. Полиси, разделы 4.2,5.2,
п. 10.3.4). Управление системой независимых узлов, в своем большинстве пред-
ставляющих «зародыши» сетей, является обязанностью регионального координа-
тора, который, однако, в отличие от сетевого координатора, не обязан доставлять
почту узлам, они должны сами заботиться об этом.
Присвоение номеров местным сетям. Так же, как NC взаимодействует с сисопа-
ми свой сети, RC связан с сетевыми координаторами своего региона. Именно к ре-
гиональному координатору адресуются запросы на выделение номера для вновь
образованной сети. Он должен поощрять создание новых сетей в регионе и следить
за исполнением сетевыми координаторами своих обязанностей.
Сопровождение нодлиста. RC собирает региональный сегмент нодлиста из се-
тевых сегментов, присланных NC, и пересылает его координатору зоны. Полу-
ченный от координатора зоны полный нодлист FidoNet распространяется реги-
ональным координатором среди координаторов сетей региона.
Разбор конфликтов. Если одна из сторон остается неудовлетворенной решени-
ем, которое было принято сетевым координатором, то может быть подана апелля-
ция региональному координатору, и он должен в оговоренные Полиси сроки (не
более месяца - раздел 9.7) принять решение. Непосредственно RC жалобы не по-
даются, они должны следовать «по команде». Комплейны, нарушающие эту по-
следовательность, немедленно отклоняются. Максимальный срок, который отво-
дится на подачу жалобы, - 60 дней с момента инцидента.
Деятельность координатора зоны
Кроме основной задачи - составления и распространения нодлиста зоны, а также
распространения сводного нодлиста, Полиси и FidoNews среди региональных ко-
ординаторов зоны, в обязанности ZC входит также:
□ надзор за региональными координаторами;
□ определение географических границ регионов;
□ назначение времени ZMH;
□ обеспечение работы зональных шлюзов (почтовые зональные шлюзы созда-
ются для обмена нетмейлом с другими зонами).
Кроме того, координаторы зон образуют совет координаторов зон и выбирают
из своей среды международного координатора (IC).
ZC избирается абсолютным большинством голосов RC зоны.
На уровне зоны властью зонального координатора проводятся решения, допол-
няющие или даже изменяющие некоторые положения Полиси и стандартов FidoNet.
В качестве примера можно упомянуть дополнительные признаки (flags) нодлис-
та, авторизованные для второй зоны, а также узлы, подключенные к сети через
Internet (IP-only nodes), существование которых в нодлисте утверждено решени-
ем ZC второй зоны в конце 1998 года.
ZC также является «верховным судьей» при разрешении возникающих проб-
лем, подаче официальных жалоб, апелляций на решения RC и т.п.
Деятельность международного координатора
Международный координатор составляет главный нодлист FidoNet из сегментов,
присланных ему координаторами зон, отвечает за определение новых зон, обмен
почтой с другими сетями, организационно отличными от FidoNet.
Кроме того, IC отвечает за распространение Полиси и FidoNews среди координа-
торов зон. Только он имеет право издавать дополнения к Полиси, организует
и проводит референдум по изменению Полиси, а также по вотуму недоверия (im-
peachment) тому или иному координатору зоны. (Опрос по вотуму недоверия
проводится по требованию большинства Региональных Координаторов зоны.) IC
избирается координаторами зон из своей среды, ZCC вправе отменить решения
международного координатора.
IC - последняя инстанция при рассмотрении комплейнов (официальных жа-
лоб) и апелляций на решения координаторов зон.
В практике FidoNet бывали случаи, когда на пост международного координа-
тора избирался не действующий, а бывший координатор зоны (случай с Джорд-
жем Писом (George Peace), имеющим сейчас в FidoNet адреса 1:13/13, 1:270/
101, 1:270/102, 1:270/103 и 1:270/104). Бывали также периоды долговременного
отсутствия IC, что отрицательно сказывалось на «политическом климате» FidoNet:
автономия зон сети в такие моменты достигла всех мыслимых и немыслимых
пределов.
Принципы разрешения конфликтов
Разрешение конфликтов - это прерогатива координатора FidoNet. В отличие от
других, технических, обязанностей вроде составления нодлиста или маршрутиза-
ции нетмейла, выполнение которых можно передать добровольцам, разрешение
конфликтов на основе Полиси перепоручать нельзя - этим должен заниматься
лично координатор. Принять решение ему помогают понятия, определенные в По-
лней: «некорректное поведение» и «чрезмерно некорректное поведение» (см. ниже),
а также «поучительные истории» (Case Histories), приведенные в 10-м разделе
Полиси.
Все конфликты рассматриваются строго «по команде»: сначала координатором
сети, затем апелляция может быть подана региональному координатору и т.д. При
пропуске одного из этапов дело не принимается к рассмотрению.
Некорректное поведение
и чрезмерно некорректное поведение
Понятия «некорректное поведение» (Annoying Behavior, АВ) и «чрезмерно не-
корректное поведение» (exclusively Annoying Behavior, ХАВ) широко использу-
ются в FidoNet; их правильное толкование имеет огромное значение для любого
участника сети независимо от того, является ли он координатором или рядовым
членом FidoNet. Полиси не дает четкого определения этих терминов,
в нем содержатся только общие указания, позволяющие каждому члену сети
сформировать свое представление о том, что для него есть АВ и ХАВ (пп. 1.3.5,
1.4.8, 2.1.1, 2.1.4, 2.1.6-2.1.8, 2.1.11, разделы 2.3, 4.2, 4.3, 5.2 и пп. 9, 10 приложе-
ния 2). «Некорректное поведение» - это такое поведение, которое раздражает
или вредит кому-то. Не обязательно нарушать правила, чтобы вести себя некор-
ректно по отношению к другим. Большинство конфликтов в FidoNet рассмат-
ривается и разрешается координаторами исходя из их представления о том, что
в данном конкретном случае есть некорректное поведение. Отличие ХАВ от АВ
примерно такое же, как отличие случайного проступка (переход улицы в непо-
ложенном месте, неосторожное обращение с опасным предметом) от заранее
спланированного преступления. Чрезмерно некорректное поведение в некото-
рых случаях может сразу же привести к экскоммуникации виновного. Напри-
мер, ХАВ является умышленная фальсификация корреспонденции. В Полиси
есть и другие примеры АВ и ХАВ, все они чрезвычайно ценны и широко исполь-
зуются при разрешении реальных конфликтов.
Процедура подачи жалобы
Жалоба (Policy complaint) является необходимым условием принятия конфлик-
та к рассмотрению координатором любого уровня. Нет комплейна - нет конфликта.
Подаче жалобы должна предшествовать (хотя бы формальная) попытка урегули-
рования спорного вопроса нетмейлом. Неудача подобного шага и достаточно раз-
дражающее поведение вашего оппонента служат основанием для подачи комплей-
на координатору Вы должны быть готовы представить фрагменты протокольных
файлов своей почтовой программы, из которых бы однозначно следовало, что ваше
письмо достигло адресата, значит, он обязан был его прочитать и отреагировать.
Стандарты FidoNet
В Полиси стандарты FidoNet (FidoNet Technical Standards, FTS) только упомина-
ются. Ссылки на FTS можно найти в п. 2.1.8, разделе 2.4 Полиси. Обстоятельства,
указывающие на столь малое внимание в основном законе FidoNet такому важному
вопросу, как технические стандарты, симптоматичны и подчеркивают, что именно
в FidoNet первично (социальная структура на элементарном техническом базисе).
Несмотря на это, а также на неполноту, неточность, подчас эклектичность и неакту-
альность, FTS и FSP чрезвычайно важны для развития технологии FidoNet и само-
го существования сети как единого целого.
FidoNet Technical Standards Commitee
Принятие и электронная публикация FTS находится в ведении FTSC - комитета
по стандартам FidoNet.
Для поддержки работы комитета и для обсуждения новых стандартов создана
эхо-конференция FTSC_PUBLIC. Файловая конференция FTSC предназначена
для распространения документов и информационных материалов, так или иначе
связанных с FTSC.
Для поддержки деятельности комитета по стандартам кроме традиционного
для FidoNet механизма эхо-конференций используется Web-сайт:
http://www.ftsc.org.
С этого адреса, а также со многих других, так или иначе связанных с FidoNet,
можно получить полный архив стандартов и предложений FidoNet.
Дополнительная информация об FTSC находится в Internet по адресам:
□ ftp://ftp.piglets.com/FTSC/;
□ ftp://ftp.fidonet.org;
□ http://www.fidonet.org;
□ ftp://ftp.z2.fidonet.org;
□ http://www.z2.fidonet.org;
□ http://www.piglets.com/ftsc.
Здесь можно ознакомится со списком участников комитета, получить их адре-
са, просмотреть список действующих стандартов FidoNet и архива стандартов
и предложений.
По этим же адресам, а также на многих BBS и Fido-системах можно получить
набор файлов, содержащих стандарты FidoNet, полный список которых приведен
в приложении 1.
Для подробного ознакомления с функциями FTSC рекомендуется изучить до-
кументы FTA-1000, FTA-1001, FTA-1002 и FTA-1003 [2.1-2.4]. Это администра-
тивные документы комитета, в них подробно изложены структура и правила, по
которым работает FTSC, коротко суммированные в следующем разделе (также
см. табл. 2.4).
Структура и правила работы FTSC
Администратор FTSC. Комитет FTSC возглавляется администратором, избираемым
постоянными членами FTSC сроком на 4 года. Администратор FTSC отвечает:
□ за установление линков между членами FTSC;
□ за организацию линков для распространения документов FTSC;
□ за координирование выдвижения и голосования по членству в FTSC;
□ за создание рабочих групп;
□ за проверку того, что FTSC действительно принимает новые документы и от-
вечает на запросы участников FidoNet;
□ за назначение кодового номера новым FSP (проектам стандартов FidoNet).
Постоянные члены FTSC. Комитет по стандартам состоит из постоянных чле-
нов, которые избираются голосованием региональных координаторов сроком на
2 года. Все члены FTSC должны быть реальными участниками FidoNet (то есть
поддерживать работающую систему сети с узловым адресом). Все, кроме админи-
стратора, должны быть либо разработчиками программного обеспечения для
FidoNet, либо иметь опыт работы в качестве координатора или эхо-координатора
FidoNet, нетмейл-, файл-, или эхо-хаба.
Общее количество членов ограничивается числом не менее 7 и не более 30 че-
ловек.
Рабочие группы. Для объединения усилий по написанию стандартов из посто-
янных членов FTSC образуются постоянно действующие рабочие группы. Каж-
дая группа возглавляется одним из постоянных членов комитета. Всего в настоя-
щее время функционируют пять таких групп:
1. Рабочая группа А - передаваемые данные
Область ответственности (FTS-0001 и 0009):
□ нетмейл;
□ транспортный формат;
□ формат хранения;
□ контрольные строки сообщений (Message Control Lines).
2. Рабочая группа В - соединения и протоколы
Область ответственности (FTS-0006, 0007, 0008):
□ «рукопожатие» при установлении связи (Handshake);
□ протоколы передачи файлов;
□ взаимодействие почтовых программ.
3. Рабочая группа С - эхо-почта и маршрутизация
Область ответственности (FTS-0004):
□ эхо-почта;
□ кладжи (контрольные строки в эхо-сообщениях);
□ стандарты сообщений (Message Standards);
□ маршрутизация нетмейла и эхо-мейла.
4. Рабочая группа D - нодлист
Область ответственности (FTS-0005):
□ распространяемый нодлист;
□ формат нодедиффов;
□ откомпилированный нодлист.
5. Рабочая группа Е - шлюзование и другие сети
Область ответственности:
□ соединение через TCP/IP;
□ передача сообщений через Internet в FidoNet.
Кроме постоянно действующих рабочих групп дополнительно могут быть созда-
ны так называемые «специально назначенные рабочие группы» (Additional Special
Assignment Working Groups), если это необходимо для исследования документации
новых проектов стандартов. В настоящее время работает одна такая группа.
Рабочая группа Y - выпуски, связанные с 2000 годом
Область ответственности:
□ предупреждения в связи с проблемой 2000 года;
□ обзор существующего программного обеспечения;
□ обзоры по другим документам.
Product Codes. Для упрощения освоения нового программного обеспечения,
FTSC введены так называемые Product Codes - коды программ FidoNet. Они слу-
жат для идентификации тех программ FidoNet, которые имеют дело с почтовыми
пакетами («РКТ type 2», см. FTS-001, [2.5]). В документах FTSC подробно описа-
но, как получить подобный код для разрабатываемого программного обеспечения
и какой использовать в случае, когда специальный код для данной программы еще
не выделен FTSC. Сам список кодов находится в документе, называемом FTSC
product list, помещаемом в файл с именем ftscprod. Этот файл можно найти там же,
где находятся и все остальные стандарты FTSC.
Административные документы FTSC
Деятельность FTSC регламентируется документами FTA-I000-FTA-1007 (FTA -
сокращение от FTSC Administrative Document, или «административный документ
FTSC», см. табл. 2.4).
Таблица 2.4. Административные документы FTSC
Код документа Оригинальное название Перевод названия и содержание
FTA-1000 FTSC CHARTER «Хартия FTSC» - определения, администрирование, основные документы
FTA-1001 FTSC Operation «Работа FTSC» - определения, структура, ответственность каждого их участников, рабочие группы и их руководители, список рабочих групп, выборы и назначения, организация доступа к документам FTSC и способы взаимодействия с его участниками, список эхо-конференций, определения стандартов (FTS), предложений (FSP), кодов программ (Product Codes)
FTA-1002 Document submission and Publication Standard «Правила предоставления документов на рассмотрение в FTSC» - правила составления и оформления проектов стандартов
FTA-1003 Membership list «Список участников» FTSC (изменяется после проведения выборов)
FTA-1004 FTSC File List «Список файлов FTSC» - список действующих стандартов (FTS) и предложений (FSP) FidoNet, а также полный список когда-либо поданных и принятых стандартов FidoNet
FTA-1005 Product Codes «Коды программ FidoNet». Идентификационные коды FTN программ, работающих с почтовыми пакетами FidoNet (FTN PKT формат, тип 2)
FTA-1006 Key words to indicate requirement levels «Ключевые слова, определяющие уровень обязательности стандарта». Аналогично RFC2119 [2.6], определяет правила использования ключевых слов вроде «MUST» (должен), «МАУ» (может) и т.п. для описания уровня обязательности данного стандарта
FTA-1007 Intellectual Property Rights «Права интеллектуальной собственности». Документ содержит соглашение о правах на разрабатываемые стандарты, вслед за RFC2026 [2.7] защищает права авторов стандартов FidoNet
Список узлов сети
Nodelist или список узлов сети - это еженедельно обновляемый текстовый файл,
содержащий адреса и телефоны всех узлов FidoNet. Согласно Полиси этот файл
должен быть подготовлен координатором зоны не позднее ZMH каждой субботы
и сделан доступным для получения региональными координаторами.
Нодлист второй зоны и файл текущих дополнений к нему (такой файл позво-
ляет построить из имеющегося предпоследнего нодлиста текущий полный нод-
лист) можно получить по сети Internet с адреса: ftp://ftp.sstar.com/fidonet.
Для работы в FidoNet очень важно иметь правильный нодлист, так как исполь-
зование устаревшего или ошибочного списка чревато звонками по неверным те-
лефонам, потерей времени и денег. Исходя из сложившейся практики в качестве
мирового нодлиста используется скомпилированный координатором данной зоны
нодлист. Этот обычай противоречит FTS-005 и Полиси, так как в этих докумен-
тах основным нодлистом считается тот, который составляется IC из зональных
сегментов, присланных координаторами зон. Сейчас же каждый ZC составляет
свой мировой сегмент из сегмента своей зоны и сегментов, присланных другими
координаторами зон. Причинами, вызвавшими к жизни именно такой способ по-
зонного распространения нодлиста, были долговременное отсутствие избранного
международного координатора, а также желание как можно оперативнее получать
мировой нодлист.
Стандарты, описывающие формат нодлиста
Формат нодлиста зафиксирован в FTS-005 (сейчас заменен на FTS-5000 и FTS-5001),
кроме того, существует большое количество дополнительных флагов (флагами на-
зываются некоторые поля в нодлистовой строке), часть которых описана в допол-
нительных FSC и FSP, их список приведен в табл. 2.5.
Структура и формат файла нодлиста
(по FTS-0005, FTS-5000 и FTS-5001)
Нодлист представляет собой текстовый ASCII-файл, обычно с именем node-
list.nnn, где nnn - номер дня текущего года. Например, имя nodelist.015 означает,
что данный адресный список был сформирован 15 января текущего года,
a nodelist.324 - примерно 20 ноября. ASCII означает, что используются коды толь-
ко первой половины символьной таблицы, до FFh. Нодлист содержит два типа
строк: комментарии и данные. Признаком завершения строки служат два символа:
ODh и 0 Ah - возврат каретки и перевод строки.
Последнее является стандартом для MS DOS, которая долгое время была са-
мой распространенной операционной системой в FidoNet, а также для OS/2
и Windows, но не для UNIX. Строки данных не должны содержать пробелов, зна-
ков табуляции и других специальных символов, которые, как правило, отобража-
ются пробелом или не отображаются вовсе. Файл должен заканчиваться симво-
лом EOF (конец файла, код lAh). Строки комментариев должны начинаться
с символа ; (точка с запятой), стоящего в первой позиции строки, следующий за
ним символ - один или несколько - называется «флаг интереса», и значение его
следующее (приведен перевод фрагмента нодлиста):
;S этот комментарий может быть интересен для сисопов;
;U этот комментарий может быть интересен для пользователей BBS;
;F этот комментарий должен присутствовать в любом форматированном
;F Fido-списке;
;А этот комментарий может быть интересен для всех (сокращенная форма от
комментариев SUF);
;Е этот комментарий представляет собой сообщение об ошибке, вставленное про-
граммой генерации нодлистов MAKENL;
; этот комментарий может игнорироваться нодлист-процессором.
Первая строка нодлиста представляет собой особую строку комментария, со-
держащую идентификационные данные для этой редакции нодлиста, например:
;А FidoNet Nodelist for Friday, February 5, 1999 - Day number
036 : 31969
Как видно из примера, первая строка нодлиста содержит флаг общего интере-
са «А», полную дату (5 февраля 1999 года), и номер дня года (36-й), а также
Таблица 2.5. Стандарты FidoNet, посвященные описанию формата списка узлов сети
Код документа Оригинальное название Автор Перевод названия Содержание Статус
FTS-0005 The distribution nodelist B.Baker, R.Moore Распространя- емый нодлист Это основной стандарт, описывающий формат нодлиста и способ его распространения Используется
FTS-0009 Nodelist Flog Draft Document Gwinn, Dodell Черновой доку- мент о флагах в нодлисте Предложение о замене нескольких флагов в нодлисте Не используется
FSC-0020 Alternate Nodelist Flag Proposal M.Presnell Предложение по альтернативному флагу в нодлисте В данном документе содержится предложение об изменении всей системы флагов нодлиста Не используется
FSC-0055 Security passwords in nodelist updates LKolin Секретные пароли в файлах дополнения нодлиста Предложено усовершенствовать формат файлов изменений нодлиста, дополнив их простейшей парольной защитой Не используется
FSC-0062 Nodelist Flag Indicating Online Times D.Thomas Флаг описания времени работы Описывается флаг времени Используется работы (начала и конца периода в зоне 2 времени, когда система находится на связи)
FSC-0075 Proposal for ISDN capability flags in the nodelist J.Ceuleers Предложение по флагу совмести- мости с ISDN Предложен флаг для описания ISDN-систем, подключенных к FidoNet Заменено на FSC-0091
FSC-0085 Proposal for the NOZIP and ERX nodelist flags D.Bider Предложение по использованию в нодлисте флагов NOZIP и ERX Предложено использовать два дополнительных флага, определяющих формат принимаемого системой почтового пакета Не используется
FSC-0091 ISDN nodelist flags (rev.002), addendum to FTS-0005, superceding FSC-0075 A. Lentz Предложение по Дополняет FTS-0005, использованию заменяет FSC-0075 в нодлисте флагов, описывающих протоколы ISDN (Х75, VI00L, V110H, V120L, V120H и ISDN) Используется
FSP-1003 Suggested use of Nodelist Fields L.Kindness Предложения по использо- ванию полей в нодлистовых строках Содержит несколько пред- ложений по упорядочению использования стандартных полей нодлиста (например, длина некоторых полей явно ограничивается) Используется
FSP-1005 Zone 2 nodelist flags F.EIIermann Флаги нодлиста второй зоны Описание флагов нодлиста, принятых во второй зоне FidoNet решением Z2C (координатора второй зоны) Используется в зоне 2
FSP-1012 Integration of IP-Nodes in the nodelist (FTS-0005) LBehet Включение 1Р-узлов (Internet-узлов) в нодлист (FTS-0005) В данном FSP стандартизиро- ваны флаги нодлиста, описыва- ющие систему, подключенную к Fido через Internet Используется
проверочный 5-символьный код, который позволяет проконтролировать целост-
ность файла нодлиста. Необходимость последнего станет очевидна при обсужде-
нии системы распространения нодлиста с использованием файлов отличий - но-
дедиффов (см. далее в разделе).
Строки данных содержат восемь так называемых «полей» переменной длины,
разделенных запятыми (,). В строке данных запрещены пробелы и спецсимволы,
которые можно интерпретировать как пробелы. Разрешены только символы ко-
довой таблица ASCII с 2 Oh по 7Eh включительно. Рассмотрим стандартные поля
данных последовательно, в том порядке, в котором они встречаются в нодлисто-
вой строке.
Стандартные поля строк данных нодлиста
Поле 1: ключевое слово
Здесь ключевое слово может быть пустым или принимать одно из следующих зна-
чений:
Zone - строка данных, начинающаяся с описания географической зоны FidoNet
и определяющая ее координатора. Все строки, следующие за данной вплоть до
нового вхождения ключевого слова «Zone», есть строки описания регионов, сетей
и узлов данной зоны;
Region - строка данных, начинающая сегмент географического региона FidoNet
и определяющая ее координатора. Все строки, следующие за данной вплоть до
вхождения строки с ключевым словом «Zone», «Region» или «Host», есть строки
описания независимых узлов в данном регионе;
Host - строка данных с ключевым словом «Host», начинающая сегмент мест-
ной сети и определяющая ее хост-систему. Все строки, следующие за ней вплоть
до вхождения ключевого слова «Zone», «Region» или «Host», есть местные узлы,
члены определяемой местной сети. Хост сети принимает почту для всей сети и яв-
ляется важным элементом системы маршрутизации почты FidoNet;
Hub - строка данных с ключевым словом «Hub», начинает описание хаб-сег-
мента, определяя структуру маршрутизации почты в многоуровневой местной
сети. Хаб представляет собой систему, через которую осуществляется передача
почты на перечисленные вслед за ним узлы вплоть до следующего вхождения
ключевых слов «Zone», «Region», «Host» или «Hub». Хаб-строка должна быть
дополнительной строкой с уникальным номером для одного из узлов описанных
ниже в хаб-сегменте (это требование FTS-0005 не является обязательным, так как
оно вызвано использованием некогда популярных программ обработки нодлиста,
которые удаляли хаб-строки из результирующего списка. Такие программы сей-
час уже не используются, и зачастую номер узла в строке с ключевым словом
«Hub» является единственным адресом для данного узла);
Pvt - определяет приватный узел, телефонный номер которого по тем или иным
причинам не публикуется в нодлисте. Приватные узлы могут выдаваться только
в рамках местных сетей (то есть не могут быть, например, независимыми узлами).
Такие узлы являются исключением и встречаются редко. В последнее время воз-
росло количество узлов, подключенных к FidoNet через Internet (глава 10), также
маркируемых как Pvt;
Hold - определяет узел, который временно недоступен. Почту для него можно
пересылать через хост его сети или через его сетевого координатора;
Down - определяет неработоспособный узел. Почту на него посылать нельзя.
Максимальное время нахождения Down-узла в нодлисте - две недели, после ис-
течения этого срока такой узел должен быть удален из списка.
Отсутствие ключевого слова означает начало строки описания обычного узла
FidoNet.
Поле 2: номер зоны, региона, сети или узла
Это поле содержит только цифры от 0 до 9, составляющие десятичное число в ди-
апазоне от 0 до 32767. Если строка содержит одно из ключевых слов «Zone»,
«Region» или «Host», то это число есть номер соответствующей структурной еди-
ницы FidoNet (то есть зоны, региона или сети) и узел, описанный в строке, имеет
номер 0. В противном случае число означает номер узла. Номера зоны, региона
или сети и узла, вместе взятые, составляют адрес FidoNet.
Номер зоны должен быть уникальным, так же как номера регионов и сетей
в пределах своей зоны. Номера хабов должны быть уникальны в своей сети. Номера
узлов должны быть уникальны в пределах региона (для системы независимых узлов)
или в пределах сети (для обычных узлов, входящих в местные сети). Одинаковые
номера узлов под разными хабами в пределах одной территориальной сети запрещены.
Поле 3: наименование узла
Это поле должно содержать символьную последовательность без пробелов и за-
пятых. Если необходимо отобразить пробел, то для этой цели рекомендуется ис-
пользовать знак подчеркивания «_». Это то имя, под которым ваша система будет
известна в сети, например DOUBLE_DOZEN.
Поле 4: местоположение
Это поле также должно содержать символьную последовательность без пробелов
и запятых. Если необходимо отобразить пробел, то для этой цели рекомендуется
использовать знак подчеркивания «_». Смысловая интерпретация значения этого
поля - географическое местоположение системы (город, пригород, село и т.д.)
плюс идентификатор геополитической административной единицы (государство,
провинция, округ и т.п.). За рубежом обычно используются стандартные почто-
вые сокращения (например, IL - штат Иллинойс, DC - округ Колумбия), в Рос-
сии же, как правило, обозначается наименование страны: Kazan_Russia.
Поле 5: имя и фамилия сисопа
Символьное поле, содержащее имя и (или) фамилию. В качестве разделителя
используется знак подчеркивания. Пробелы и запятые запрещены.
Пример: Amir_Shabashvili
Поле 6: номер телефона
Это поле содержит по крайней мере три или (обычно) четыре цифровых блока, разде-
ленных знаком тире «-». Оно представляет собой стандартную запись телефонного
номера узла, включая коды страны, телефонной области внутри страны, допол-
нительный код и собственно номер телефона. Различные структурные составляю-
щие телефонного номера часто используются для оценки стоимости и планирова-
ния телефонных звонков. Например, типичный номер для условий Соединенных
Штатов (этот пример приведен в FTS-0005) выглядит как 1-800-555-1212, где зна-
чения блоков следующие: 1 - код страны (Соединенные Штаты), 800 - код теле-
фонной области, 555 - дополнительный код, 1212 - номер телефона.
Пример для России (использован несуществующий номер): 7-843-216-7856, где 7 -
международный код России, 843 - код города Казани. Остальная часть номера соот-
ветствует стандартному международному делению, но интерпретация ее в России
иная. Цифра 2 - добавочный код, 167856 - внутригородской телефонный номер.
Поле также может содержать вместо номера телефона строку «-Unpublished-»
в случае приватного узла. В этом случае строка должна начинаться с ключевого
слова «Pvt».
Поле 7: скорость соединения (baud rate)
Это поле содержит одно из значений: 300,1200, 2400,9600,19200 или 38400 и опре-
деляет максимальную скорость модемного соединения, поддерживаемую узлом
(скорость, с которой компьютер обменивается информацией с коммуникацион-
ным портом). Наиболее часто используемым значением из этого списка является
9600. Ранее это поле применялось для тарификации звонков, сейчас оно устарело
и используется только для совместимости с программным обеспечением. Неже-
лательно ставить в него реальную скорость.
Поле 8: флаги
Это необязательное поле содержит дополнительные сведения об узле, такие как
поддержка файловых запросов, используемые модемные протоколы и т.д.
Правом оперативного изменения флагов, описанных в стандарте FTS-0005, об-
ладает международный координатор FidoNet.
Любой текст, следующий за седьмой запятой в строке данных, считается при-
надлежащим полю флагов, которое состоит из подполей - собственно флагов, раз-
деленных запятыми. Каждое такое подполе содержит один флаг, иногда включа-
ющий значение параметра.
В FTS-0005 флаги стандартизованы (см. ниже). Описание разбито на блоки,
соответствующие функциям, которые выполняет данная группа флагов.
Особенности функционирования узла:
□ CM (Continuous Mail} - 24 часа в сутки принимает почту;
□ МО (Mail Only) - только почтовое соединение, то есть пользователи BBS не
поддерживаются;
□ LO (Listed Only) - поддерживается почтовое соединение только с присутству-
ющими в нодлисте системами.
Поддерживаемые модемные протоколы:
□ V21 - протокол ITU-T V.21, 300 бит/с, дуплекс (только для второй зоны,
в остальных зонах этот флаг означает Bell 212А на 300 бит/с);
□ V22 - протокол ITU-T V.22 (1200 бит/с, дуплекс) или ITU-T V.22 bis (2400
бит/с, дуплекс) в зависимости от значения поля скорости соединения (только
для второй зоны, в остальных зонах - Bell 212А на 1200 бит/с или 2400 бит/с);
□ V29 - протокол ITU-T V.29 (9,6 Кбит/с, полудуплекс);
□ V32 - протокол ITU-T V.32 (9,6 Кбит/с, дуплекс);
□ V32B - протокол ITU-T V.32 bis (14,4 Кбит/с, дуплекс);
□ V32T - модификация протокола V32 Terbo (19,2 Кбит/с, дуплекс);
□ V33 - протокол ITU-T V.33;
□ V34 - протокол ITU-T V.34 (33,6 Кбит/с, дуплекс);
□ Н96 - фирменный протокол Hayes V.9600;
□ HST - фирменный протокол USR (ЗСош) Courier HST;
□ Н14 - фирменный протокол US Robotics HST, модификация 14,4 Кбит/с;
□ Н16 - фирменный протокол US Robotics HST, модификация 16,8 Кбит/с;
□ МАХ - фирменный протокол Microcom АХ/96хх;
□ РЕР - фирменный протокол Telebit Packet Ensemble Protocol;
□ CSP - фирменный протокол Compucom Speedmodem;
□ VFC - фирменный протокол Rockwell’s V.Fast Class;
□ ZYX - фирменный протокол Zyxel 16,8 Кбит/с.
Примечание 1. Перечень модемных протоколов, которые могут быть описаны
в нодлистовой строке, существенно расширен за счет так называемых пользова-
тельских флагов (см. ниже их описание).
Примечание 2. Если модемные флаги опущены, предполагается поддержка про-
токола ITU-T V.22 на 1200 бит/с или ITU-T V.22 bis в зависимости от указанной
скорости соединения (для второй зоны, в остальных зонах предполагается исполь-
зование протокола Bell 212А на 1200 или 2400 бит/с).
Модемные протоколы коррекции ошибок:
□ MNP - коррекция ошибок по фирменному протоколу Microcom Networking
Protocol;
□ V42 - коррекция ошибок по протоколу LAP-M с возвратом к MNP 1-4;
□ V42B - коррекция ошибок по протоколу LAP-M с возвратом к MNP 1-5.
Примечание. Не обязательно декларировать все протоколы, поддерживаемые ва-
шим модемом. Достаточно указать основные; соединение на устаревших протоколах
вроде V21 или V22 и других в этом случае подразумевается, хотя и не гарантируется.
Флаги, определяющие поддерживаемый тип упакованных (то есть программно
сжатых) пакетов:
□ MN - сжатие не поддерживается.
Примечание. Единственный стандартный для FidoNet метод архивирования -
сжатие с использованием формата SEA ARC с именами, определенными в специ-
фикации для ARCMail 0.6. Отсутствие флага MN означает, что сжатие по
ARCMail 0.6 этим узлом поддерживается.
Флаги, определяющие поддерживаемые типы запросов на прием и/или посыл-
ку файла:
□ ХА - запрос на посылку/прием файла типа WaZOO, запрос на посылку/при-
ем файла типа Bark;
□ ХВ - запрос на посылку/прием файла типа Bark, запрос на прием типа
WaZOO;
□ ХС - запрос на посылку файла типа Bark, запрос на посылку/прием типа
WaZOO;
□ ХР - запрос на посылку/прием файла типа Bark;
□ XR - запрос на прием файла типа WaZOO и Bark;
□ XW - запрос на прием файла типа WaZOO;
□ XX - запрос на посылку/прием файла типа WaZOO.
Шлюзы в другие домены (сети):
□ Gx..x - шлюз в домен «х..х», где «х..х» есть алфавитно-цифровая строка. Раз-
решенные наименования для «х..х» назначаются международным координа-
тором. Текущие значения для «х..х» могут быть найдены в примечаниях
в конце нодлиста FidoNet. Для этой цели во второй зоне FidoNet использует-
ся аббревиатура UUCP GUUCP можно ставить только для систем, имеющих
MX-запись на сервере имен (DNS) Internet, в домене z2.fidonet.org.
Флаги, определяющие время поддерживаемых почтовых периодов:
□ #01 - зональный час пятой зоны (01.00-02.00 UTC);
□ #02 - зональный час второй зоны (02.30-03.30 UTC);
□ #08 - зональный час четвертой зоны (08.00-09.00 UTC);
□ #09 - зональный час первой зоны (09.00-10.00 UTC);
□ #18 - зональный час третьей зоны (18.00-19.00 UTC);
□ #20 - зональный час шестой зоны (20.00-21.00 UTC).
Примечание 1. Эти флаги имеют написание «#пп» или «!пп», где пп есть уни-
версальное (UTC) время в часах суток, имеющее смысл времени начала почтовых
периодов; «#» означает совместимость с модемным стандартом Bell 212А и «!» -
несовместимость с Bell 212А.
Примечание 2. При необходимости эти флаги можно давать в сочетании, что-
бы обозначить расширенные почтовые периоды, то есть написать «#02# 09». Эти
флаги можно использовать только для описания почтовых часов, отличающихся
от стандартных для данной зоны. Так как соблюдение зональных почтовых часов
обязательно для узлов в данной зоне, флагами #пп их отмечать не нужно.
Примечание 3. Координатором второй зоны принято решение, согласно кото-
рому в R50 (Россия) возможно использование флагов #пп как замены ZMH (это свя-
зано с трудностями поддержки текущего ZMH второй зоны в местностях восточ-
нее Москвы, где время ZMH приходится на утренние и дневные часы). Подробнее
об этом читайте далее в этой главе.
Флаги, определяемые пользователями:
□ Ux..x - открывает строку так называемых «пользовательских флагов» (User Flags),
которые могут содержать любую алфавитно-цифровую последовательность,
исключая пробелы. Всего строка User Flags может содержать от 1 до 32 сим-
волов для дополнения нодлистовой строки данными, определяемыми пользо-
вателем. Некоторые пользовательские флаги стандартизованы (см. следую-
щий раздел).
Примечание 1. Пользовательские флаги, если они присутствуют в строке, дол-
жны занимать в ней последнюю по порядку (слева направо) позицию.
Примечание 2. Некоторые флаги являются взаимоисключающими. Например,
пары MNP и HST, V32 и V32B или V42 и V42B недопустимы. Большинство таких
случаев описано в примечаниях к нодлисту. Краткая сводка дана ниже.
Взаимоисключающие флаги (флаги, совместное употребление которых в одной
и той же нодлистовой строке запрещено):
□ V32B - (протокол CCITT V.32 bis) включает V32;
□ V32T - (Turbo-модификация V.32B 19,2 Кбит/с) включает V32B;
□ ZYX - (фирменный протокол Zyxel 16,8 Кбит/с) включает V32B, V42B;
□ HST - (фирменный протокол USR (ЗСош) Courier HST) включает MNP;
□ V42B - (коррекция ошибок по LAP-M с возвратом к MNP 1-5) включает V42;
□ Н14 - (фирменный протокол US Robotics HST, модификация 14,4 Кбит/с)
включает HST, MNP;
□ Н14 - (фирменный протокол US Robotics HST, модификация 16,8 Кбит/с)
включает Н14, HST, V42B;
□ U,Z19 - (фирменный протокол Zyxel 19,2 Кбит/с) включает V32B, V42B, ZYX.
Соблюдение зонального почтового часа
на востоке России и флаг #пп
Как уже неоднократно отмечалось, соблюдение почтовых процедур в восточных
областях России (восточнее Урала) затруднено, так как там зональный почтовый
час (ZMH) приходится на утренние или даже дневные часы. Например, во Влади-
востоке (сеть 2:5045) местное время ZMH попадает в интервал 15.30-16.30, что
чрезвычайно неудобно. Поэтому координатором второй зоны FidoNet было при-
нято решение о возможности замены зонального почтового часа в сетях 50-го ре-
гиона (Россия) на сетевой почтовый час (NMH). Технически это выполняется
следующим образом. Для обеспечения максимальной совместимости с остальны-
ми системами FidoNet поддержка ZMH обязательна для хоста сети. Все осталь-
ные узлы сети используют флаг #пп (один и тот же для всех, например в том же
Владивостоке это #18), отмечая таким образом время начала NMH. Флаги #пп
(!пп) описаны выше.
Принятое решение формально противоречит FidoNet Policy, однако оно явля-
ется разумным выходом из сложившейся ситуации, когда целые сети не имеют
возможности соблюдать почтовые процедуры, составляющие фундамент FidoNet.
Примеры нодлистовых строк
В этом разделе приведено несколько примеров записи нодлистовых строчек, взя-
тых из текущего на момент написания книги нодлиста.
Рекомендуется научиться различать и интерпретировать основные информа-
ционные поля таких строк. Хотя при обычном использовании FidoNet, как прави-
ло, применяется та или иная программа просмотра нодлиста (обычно входит в сос-
тав редактора писем, см. рис. 2.4), все же умение «на глаз» интерпретировать
нодлистовые строчки может пригодиться.
Ниже приведены все нодлистовые строки международного координатора Боба
Сатти (Bob Satti), номера телефонов заменены на «хх». Только одна из этих строк -
третья - представляет собой официальный адрес IC, первая и вторая описывают
его же как зонального координатора и зонального эхо-координатора, четвертая
строка говорит о том, что Боб поддерживает также и Hub-систему. Остальные адре-
са предназначены для внутрисетевого употребления:
Zone,1, North_Amerlca, Surrey_BC, Bob.Satti, xx, 9600, CM, XA,H16,V32b,V42b,V34,VFC,V32T
, 200, Temp_Zone1_Echo_Coord,Surrey_BC,Bob_Satti, xx, 9600, CM,ХА,H16,V32b,V42b,V34,VFC,V32T
, 1000, International-Coordinator, Surrey.BC, Bob_Satti, xx, 9600, CM, ХА, H16, V32b, V42b, V34, VFC, V32T
Hub, 10,Basic’ly_Server,Surrey.BC,Bob.Satti, xx, 9600, XA, CM,H16, V32b, V42b, V34, VFC, V32T
, 1, Basic’ly_Computers_2,Surrey_BC,Bob_Satti, xx, 9600, XA, CM,H16,V32b, V42b, V34, VFC, V32T
,4,Basic’ly_Z1_Distrib,Surrey.BC,Bob_Satti, xx, 9600,XA,CM,V32b,V42b,V34,VFC
,5,Basic’ly.Vanmail,Surrey.BC,Bob.Satti, xx, 9600, XA, CM, H16,V32b,V42b, V34,VFC,V32T
, 6, Basic’ly.Manager,Surrey.BC,Bob.Satti, xx, 9600, XA,CM,H16,V32b,V42b,V34,VFC,V32T
,9,Basic’ly.BBS, Surrey.BC,Bob.Satti, xx, 9600, XA, CM,H16,V32b,V42b,V34,VFC,V32T
,14,Basic’ly.Outdial.Port, Surrey.BC, Bob.Satti, xx, 9600, XA, CM,МО,H16,V32b,V42b,V34,VFC,V32T
,104,Basic’ly.Computers, Surrey.BC, Bob.Satti, xx, 9600,XA,CM,H16,V32b,V42b,V34,VFC,V32T
Большое количество адресов, зарегистрированных на одного сисопа, не может
считаться распространенной практикой в FidoNet, но это и не редкость. Как прави-
ло, эти адреса действительно представляют собой отдельные системы с разными
телефонными номерами. Исключение составляют строки с префиксами «Zone»,
«Region», «Host» и «Hub», которые дублируют обычные узловые адреса своих хо-
зяев. Из приведенных строчек можно сделать вывод, что все описываемые системы
расположены в Канаде (Surrey - название города, а ВС - British Columbia, то есть
Британская Колумбия - юго-западная провинция Канады). Все системы имеют
круглосуточный график работы (флаг СМ), на всех установлены модемы Courier
V.Everything фирмы US Robotics (флаги Н16 и V34), все поддерживают запрос на
посылку/прием файла типа WaZOO.
Нодлисты, подготовленные зональными координаторами для своих зон, отли-
чаются друг от друга, в частности, по порядку следования зон. В нодлисте второй
зоны первой от начала файла идет вторая зона, а за ней уже следует первая и ос-
тальные четыре зоны. Это следует учитывать при «ручном» просмотре файла нод-
листа. Различаются они и набором комментариев, и фактической информацией;
как правило, каждый координатор зоны старается использовать наиболее свежий
сегмент зонального нодлиста при компиляции полного мирового списка. Именно
поэтому нодлист, скомпилированный во второй зоне, может отличаться от такого
же, созданного в первой, не только порядком следования зон и комментариями,
но и «свежестью» сегмента второй зоны. Отсюда следует, что для использования
следует выбирать полный нодлист своей зоны.
Система распространения нодлиста
Размер файла нодлиста определяется количеством узлов FidoNet; в настоящее
время это более 1,5 Мбайт:
C:\FIDO\NODELIST>dir *.043
The volume label in drive C is 0S2.
The Volume Serial Number is E707:4014.
Directory of C:\FIDO\NODELIST
12/02/99 0:04 1854093 0 NODELIST.043
1 file(s) 1854093 bytes used
357670912 bytes free.
Файл такого размера нельзя распространять каждую неделю (а нодлист обнов-
ляется еженедельно) по любительской сети, так как это может вызвать ее пере-
грузку Для решения этой проблемы была разработана система распространения
нодлиста, суть которой заключается в том, что по сети пересылается разностный
файл - нодедифф, содержащий полную информацию по изменениям, которые
необходимо внести в нодлист и команды редактирования. Имя файла, в который
помещается нодедифф, записывается как nodediff.nnn, где ппп - порядковый но-
мер дня выхода файла, считая от начала текущего года.
Преобразование нодлиста посредством разностного файла осуществляется с ис-
пользованием специальных программ - нодедифф-процессоров (nodediff processors),
обзор которых приведен далее в этом же разделе и в главе 7.
Формат разностного файла следующий:
□ первая строка файла nodediff.nnn является точной копией первой строки из
нодлиста за последнюю неделю. Эта строка используется как первый тест на
правильность используемой пары нодедифф/нодлист;
□ строки, следующие за первой, представляют собой команды редактирования
и данные для правки нодлиста.
Всего имеется три команды редактирования, и все они имеют сходный формат:
<КомандахНомер>, где <Команда> - однобуквенная команда - А, С или D.
<Номер> - есть десятичное число больше нуля, оно определяет номера строк, об-
рабатываемых командой.
Значения команд:
□ Ann - добавить следующие за командой пп строк к выходному файлу;
□ Спп - откопировать неизмененными пп строк из входного файла в выходной;
□ Dnn - удалить (то есть пропустить) пп строк из входного файла.
Рис. 2.4 иллюстрирует сказанное на примере нескольких начальных строк из
реального разностного файла.
Приведенный в качестве примера фрагмент иллюстрирует все три возможные
команды редактирования. Первая строка - nodediff.036 содержит имя файла, ко-
торый необходимо отредактировать с помощью данного разностного файла. Сле-
дующая строка содержит команду D15, которая приказывает удалить первые
15 строк из файла nodediff.036, содержащие идентификационную строку и 14
строк комментариев. Третьей строкой (командой А15) они замещаются идущими
OS/2 System Editor - C:\FIDO\NODELlST\nodediff.Q43________:____________________________ |°|D
File Edit Options Help
;A FidoNet Nodelist for Friday, February 5, 1999 -- Day number 036 : 32524
В1||||!1||!|||||||||в
oiie
;A FidoNet Nodelist for Friday, February 12, 1999 *• Day number 043 : 13533
;A The FidoNet Nodelist, a listing of the systems within FidoNet.
;A .. The FidoNet NodeList is compiled so that computer systems within FidoNet
;A may communicate with each other. Use and intra• FidoNet distribution
;A rights are granted to all FidoNet system operators for the purposes of
;A communication within FidoNet or applying for a FidoNet node number.
;А^|||||||||1|||||||||||И
;A .. This is a compilation of individual nodelist segments contributed by the
;A drafters and compilers of those segments. Contribution of these segments
;A to this compilation does not diminish the rights of the contributors.
Рис. 2.4. Содержимое разностного файла (нодедиффа)
непосредственно за этой командой 15 строками, содержащими новую идентифи-
кационную строку и новые комментарии.
Следующая далее команда С 8 6 копирует 86 строк из старого нодлиста в новый,
оставляя их неизменными.
Как уже было сказано, для обработки нодлиста разработаны специальные про-
граммы, так называемые нодедифф-процессоры. Внесение дополнений в нодлист
на основе разностного файла достаточно простая задача для программиста, поэто-
му программ, выполняющих эту процедуру, довольно много. Мы упомянем три из
них прежде всего потому, что они хорошо известны сисопам R50 и широко исполь-
зуются в течение нескольких лет:
□ nporpaMMafdnd.exe - Front Door Nodediff Processor, названная по имени очень
популярной некогда почтовой программы Front Door. Сейчас мало кто пользу-
ется fdnd.exe, но когда-то это была самая популярная программа, выполняв-
шая функцию воссоздания нодлиста из набора нодедиффов;
□ программа ndp.exe позволяет не только обновлять нодлист, но и создавать по
желанию его укороченные сегменты;
□ наиболее универсальна программа fastlist.exe; она распространяется в верси-
ях для нескольких операционных систем и кроме обработки нодедиффов мо-
жет создавать универсальные (так называемые V7) индексы к нодлисту, ис-
пользуемые некоторыми почтовыми программами и программами написания
писем. В частности, индексы V7 использует почтовый редактор Fleetstreet
для операционной системы OS/2. Подробно программы обработки нодлиста
описаны в главе 7.
Пользовательские флаги в нодлисте
Несмотря на то, что стандарт позволяет каждому сисопу самостоятельно изобре-
тать и помещать в строку описания узла любые пользовательские флаги, особого
смысла в подобной изобретательности нет, по крайней мере, широкого распростра-
нения подобная практика не получила. Пользовательские флаги описаны в несколь-
ких FSC (табл. 2.5) и в комментариях к нодлисту. Представленные ниже пользова-
тельские флаги - это по большей части флаги, авторизованные для второй зоны.
Наиболее часто применяемые флаги можно разделить на несколько групп.
Модемные протоколы. Некоторые модемные протоколы не предусмотрены
флагами, описанными в FTS-0005, поскольку во время написания этого стандар-
та таких протоколов еще не было. В табл. 2.6 приведены подобные флаги, исполь-
зуемые в текущем нодлисте (нодлист nodelist.043 от 12 февраля 1999 года).
Протоколы ISDN. С распространением в Америке и Западной Европе цифро-
вой телефонной сети стандарта ISDN появились и системы FidoNet, использую-
щие эту сеть как обычную телефонную для соединения между стандартными
FidoNet-системами, подключенными к ISDN. При этом набор поддерживаемых
модемных протоколов соединения существенно расширен за счет добавления спе-
цифических для ISDN протоколов Х75, VI ЮН и других. И хотя присутствие по-
добных систем в нодлисте противоречит букве Полиси FidoNet, так как ISDN-
система, как правило, недоступна из обычной телефонной сети, все же некоторые
зональные координаторы разрешили регистрировать узлы FidoNet на ISDN. Та-
ких узлов достаточно много, особенно в Западной Европе, принадлежащей к той
же зоне, что и Россия. В российском регионе FidoNet систем на ISDN нет. ISDN-
флаги описаны в FSC-0091, представляющем собой дополнение к FTS-0005, а так-
же приведены в комментариях к нодлисту. Они были включены в новую версию
стандарта FTS-0005 (FTS-5001). Описние основных ISDN-флагов приведено
в табл. 2.7.
Таблица 2.6. Пользовательские флаги для описания модемных протоколов
Флаг Протокол и комментарии Частота встречаемости в нодлисте
V90C Клиентский протокол ITU-T V.90, модем с V90C может соединяться с серверным модемом V.90S и потенциально способен обеспечивать скорость до 56 Кбит/с в направлении от сервера к клиенту (встречная скорость соответстсвует максимальной для протокола V.34) 64
V90S ITU-T V.90 Сервер. Устройство V90S должно быть подключено к АТС по цифровому интерфейсу (возможно ISDN) и может соединяться с другими У.90-совместимыми устройствами. V90S <-> V90S: может быть установлено симметричное соединение 64 Кбит/с. V90S <-> V90C: см. описание флага V90C 107
Х2С Фирменный клиентский протокол US Robotics (ЗСолт) Х2. Скоростные характеристики аналогичны описанным выше для флага V90C 187
X2S Фирменный серверный протокол US Robotics (ЗСот) Х2. Скоростные характеристики и способ подключения к телефонной сети аналогичны описанным выше для флага V90S 242
Z19 Фирменный протокол Zyxel 19.2 Кбит/с (подразумевает наличие протоколов V.32Bis, V.42Bis и ZYX). Может быть использован в комбинации с флагом V34 344
Примечание 1. Ни один из перечисленных ISDN-флагов не означает поддержку
других протоколов ISDN, как это бывает для модемных протоколов.
Примечание 2. Каждый протокол должен быть отмечен своим флагом. Если
модемное соединение с данным узлом невозможно (только ISDN), скорость должна
быть установлена в 300 бит/с.
Примечание 3. Для оценки частоты встречаемости использован нодлист
nodelist.043 от 12 февраля 1999 года.
Флаги, обозначающие системы координаторов FidoNet. Такие флаги обычно
используются для обозначения основной системы, на которой присутствует дан-
ный координатор (см. табл. 2.8).
Примечание 1. Флаг NC требуется только в тех случаях, когда местоположе-
ние сетевого координатора и хоста сети (адрес Сеть/0) различаются, что быва-
ет не так уж и часто. Следует учитывать, что флаги REC и NEC можно использо-
вать в данном регионе или сети только единожды.
Примечание 2. Для оценки частоты встречаемости использован нодлист
nodelist.043 от 12 февраля 1999 года.
Специальные флаги. Специальных флагов всего два. К12 идентифицирует дан-
ную систему как принадлежащую образовательной школьной сети К12 и сообщает
Таблица 2.7. Пользовательские флаги для описания ISDN-протоколов
Флаг Протокол Частота встречаемости в нодлисте
Х75 ITU-T Х.75 SLP протокол с В-каналом 64 Кбит/с 3398
V11OL ITU-T V. 110 19.2 Кбит/с асинхронный протокол 340
VI ЮН ITU-T V.110 38.4 Кбит/с асинхронный протокол 781
VI20L ITU-T V.120 56 Кбит/с асинхронный протокол 227
V120H ITU-T V.120 64 Кбит/с асинхронный протокол 303
ISDN Используется только в том случае, если не поддерживается ни один из перечисленных выше ISDN-протоколов 3
Таблица 2.8. Пользовательские флаги для описания систем,
которыми управляют координаторы FidoNet
Флаг Описание Частота встречаемости в нодлисте
NC Сетевой координатор; координация доставки личной почты в данной местной сети 90
REC Региональный Эхо-Координатор; координация эхо-почты в данном регионе FidoNet 29
NEC Сетевой Эхо-Координатор; координация эхо-почты в данной местной сети FidoNet 198
о том, что данная система поддерживает полный набор К12 эхо-конференций. К спе-
циальным относится и популярный флаг ENC, означающий, что узел принимает
зашифрованную личную почту
IP-флаги. Под сокращенным наименованием «1Р» обычно понимается поддерж-
ка Internet-протоколов TCP/IP. Таким образом, IP-флаги описывают доступность
системы через Internet. В последнее время эти флаги широко используются не толь-
ко для описания дополнительного Internet-сервиса существующих на обычных те-
лефонных линиях систем, но и для узлов, подключенных к FidoNet исключительно
через Internet. Для того чтобы соблюсти букву Полиси, подобные узлы оформля-
ются как приватные. Проект стандарта, описывающий эти флаги, был утвержден
в конце 1999 года и имеет индекс FTS-5001. IP-флаги сведены в табл. 2.9.
Примечание. Для оценки частоты встречаемости использован нодлист node-
list.043 от 12 февраля 1999 года.
Время работы системы. Этот флаг является наиболее широко применяемым из
пользовательских флагов. Многие почтовые программы анализируют наличие его
в нодлистовой строке системы, для которой необходимо передать почту, и производят
звонки только в указанные промежутки времени. Примерами подобных программ мо-
гут служить популярные мейлеры T-mail (DOS, OS/2, Windows) и The Brake! (OS/2).
Описываемый флаг указывает почтовые часы работы системы в дополнение
к ZMH, хотя указанные временные интервалы могут и перекрывать зональный
почтовый час. Флаг времени работы записывается как TXY, где XY представляет
собой двухбуквенный код времени начала и конца работы системы в соответствии
с табл. 2.10. При этом используется стандартное время (UTC или время по Гринвичу).
Таблица 2.9. Флаги нодлиста,
описывающие использование системой протоколов TCP/IP
Флаг Описание Частота встречаемости в нодлисте
IBN[:24554] Протокол Binkp (в скобках может быть указан номер порта; 24554 - стандартное для Binkp значение, используемое по умолчанию) 113
IFC[:60179] Протокол Ifcico TCP популярной почтовой программы ifmail (в скобках может быть указан номер порта; стандартное для Ifcico значение, используемое по умолчанию, равно 60179) 53
ITN[:23] Протокол TELNET (в скобках может указываться номер порта; стандартное для TELNET значение, используемое по умолчанию, - 23) 43
IVM[:2141] Протокол Vmodem из популярного условно-бесплатного набора коммуникационных драйверов для операционной системы OS/2 (SIO), авторство которого принадлежит Ramond Guinn. В скобках может указываться порт; стандартное значение номера порта равно 2141 18
IP Этот флаг используется, если ни один из перечисленных выше IP-флагов не описывает в точности протоколы, используемые на данной системе 19
Московское время отличается от UTC на +3 часа. Таким образом, если ваша сис-
тема работает с 20.00 до 8.00 часов московского времени, то флаг TXY будет выг-
лядеть как TRF (сверьтесь с табл. 2.10).
При использовании флага времени работы возникает проблема, связанная со
сменой шкалы времени в летний/зимний периоды (так называемое декретное
время). FSC-0062 [2.8] рекомендует устанавливать временной интервал с «запа-
сом» - так, чтобы не приходилось два раза в год менять нодлистовую строку.
Таблица 2.10. Буквенное кодирование времени работы в соответствии с FTS-0062
(пользовательский флаг TXY)
Буква Время Буква Время Буква Время Буква Время Буква Время
А 0:00 F 5:00 К 10:00 P 15:00 и 20:00
а 0:30 f 5:30 k 10:30 P 15:30 u 20:30
В 1:00 G 6:00 L 11:00 Q 16:00 V 21:00
b 1:30 g 6:30 I 11:30 q 16:30 V 21:30
С 2:00 н 7:00 M 12:00 R 17:00 W 22:00
с 2:30 h 7:30 m 12:30 r 17:30 w 22:30
D 3:00 I 8:00 N 13:00 S 18:00 X 23:00
d 3:30 i 8:30 n 13:30 s 18:30 X 23:30
Е 4:00 J 9:00 0 14:00 T 19:00
е 4:30 j 9:30 0 14:30 t 19:30
Личная почта FidoNet (netmail)
Личная почта - это именно тот сервис, для которого была создана FidoNet. Все
остальное - например, передача эхо-почты или файлов - формально считается
второстепенным относительно нетмейла сервисом.
Ваша почта, то есть та, которая адресована лично вам, - это ваше частное дело.
Вы можете поступать с ней, как душа пожелает. Иное дело почта, которая переда-
ется через ваш узел по договоренности с другими сисопами FidoNet. Будучи чле-
ном сети, вы не обязаны пересылать и обработывать не принадлежую вам почту,
но коль скоро вы согласились заниматься этой работой, выполнять ее надо в соот-
ветствии с принятыми в сети правилами и обычаями.
Ниже перечислены основные правила обращения с чужой личной почтой при
ее передаче по сети. Все они являются прямым следствием тех или иных положе-
ний Полиси FidoNet (см. приложение 2, пп. 2.1.3-2.1.7):
□ личная почта, адресованная участнику FidoNet, должна поступить на хост его
сети, с которого он может забрать ее. Никто не вправе уничтожать эти почтовые
сообщения или до бесконечности «мариновать» их, хотя на практике это иногда
случается. В уставе большое внимание уделяется ответственности за неиска-
женную передачу нетмейла; эхо-почта в конфликтных ситуациях интерпрети-
руется как разновидность личной почты;
□ письма, которые транзитный узел по тем или иным причинам не может доста-
вить, он обязан вернуть с объяснением причин, по которым доставка оказа-
лась невозможна. Единственное исключение составляет шифрованная или
коммерческая почта. Такие письма можно не возвращать, просто уведомлять
отправителя о невозможности пересылки;
□ перлюстрация (просмотр) нетмейла, не адресованного сисопу транзитного
узла, Полиси разрешается и даже рекомендуется. Аргументируется это необ-
ходимостью контроля за информацией, циркулирующей по сети. Сисопы
FidoNet обычно ревниво следят за тем, чтобы передаваемая информация не
носила коммерческий или противозаконный характер; по правилам FidoNet
такого рода почта с использованием адресации FidoNet передаче не подлежит;
□ передача личной почты напрямую адресату широко практикуется в местных
сетях, составляющих FidoNet. Это называется директной (непосредственной)
передачей почты. Однако если адресат находится в другом телефонном реги-
оне, то, как правило, используется маршрутизация почты, то есть передача
почты с применением других систем FidoNet в качестве посредников;
□ существуют зоны и регионы FidoNet, где в силу традиций, обусловленных
экономическими причинами, маршрутизация исходящего трафика личной
почты не распространена. Хорошим примером такого подхода к передаче поч-
ты может служить родина FidoNet - Северная Америка. В зоне R50 (Россия)
система маршрутизации нетмейла распространена повсеместно и широко ис-
пользуется даже внутри одного телефонного региона (то есть в пределах од-
ной сети).
Финансирование передачи сообщений. Костшаринг
Cost-sharing - финансирование в складчину передачи почты в другой телефонный
регион - широко практикуется во многих зонах FidoNet как основной способ под-
держки маршрутизации почты, существенно удешевляющей для хост- и хаб-узлов
передачу нетмейла вне данной сети. В России костшаринг не распространен.
Зональные шлюзы (ZoneGates)
Еще до того, как вся сеть была разделена на зоны, одним из ее участников Килго-
ром Траутом (Kilgore Trout, 107/7) было предложено создать зональные шлюзы
для
упрощения
и удешевления передачи
почты между ними.
Это предложение
было опубликовано в статье в FidoNews [2.9], затем появилась статья Ренди Буша
(Randy Bush), известная как проект стандарта FSC-0004 [2.10].
Суть системы зональных шлюзов заключается в создании в каждой зоне почто-
вых
шлюзов для
связи со всеми другими зонами
ции
НИИ
таких шлюзов. По традиции зональные
из зоны А в зону В имеют адрес:
FidoNet и стандартной адреса-
шлюзы,
или зон
гейты, при гейтова-
<номер зоны А>:<номер зоны А>/номер зоны В>
то есть шлюз между второй и первой зонами во второй зоне имеет адрес 2:2/1@
fidonet, а аналогичный шлюз в первой зоне - l:l/2@fidonet.
Большая часть программного обеспечения FidoNet «знает» о существовании зон-
гейтов и может маршрутизировать на них почту, при этом используется кладж
AaINTL, описанный в FTS-0001 и специально предназначенный для межзональной
адресации. В AaINTL помещается информация об адресе-получателе и адресе-отпра-
вителе. Например, при отправке письма от 2:5049/12 на адрес 44:567/56, не суще-
ствующий в FidoNet, оно все же может быть послано, если в поле «То:» заголовка
письма помещен адрес шлюза в 44-ю зону, а строка AaINTL выглядит как:
"alNTL 44:567/56 2:5049/12
При прохождении зон-гейта письмо дополняется несколькими контрольными
строками (кладжами):
AaORIG - адрес отправления;
AaROUTE - адрес маршрутизатора;
AaDEST - адрес назначения.
Все эти кладжи описаны в FSC-0058.
При межзональном шлюзовании эхо-почты обязательным условием является
«срезание» служебных строк SEEN-BY, так как в этих кладжах используется 2D-
представление адреса, что может привести к дублированию писем при совпаде-
нии номеров сетей и узлов в разных зонах.
Все вышеизложенное о межзональном гейтовании не должно заботить вас при
отправке письма в другую зону. Но эта информация может пригодиться, если вы
установите межзональный нетмейл-линк; она также не будет лишней при анализе
дефектной почты, прошедшей зон-гейт.
Маршрутизация почты по нодлисту
В нодлисте отражена двухуровневая структура маршрутизации личной почты,
поддерживаемая почти всем программным обеспечением FidoNet, которое имеет
отношение к маршрутизации нетмейла. Это так называемая хаб- и хост-маршру-
тизация или хаб(хост)-роутинг (от англ, route - «маршрут»). При использовании
стандартной системы маршрутизации следует учитывать, что речь идет только
о входящей почте, иными словами, гарантируется доставка письма, отправленно-
го вам. Никаких гарантий отправки вашей почты при этом не дается. Обычно
в условиях сетей 50-го региона такая система работает, то есть вы можете отпра-
вить письмо не напрямую адресату, а через ближайший хаб или хост своей сети,
но в других регионах и зонах FidoNet (например, в Северной Америке) маршру-
тизация исходящего нетмейла, как правило, отсутствует или работает только по
личной договоренности сисопов.
Структура узлов, ответственных за передачу личной почты, состоит из сетевых
хостов (может быть только один хост в каждой сети) и сетевых хабов (компьюте-
ров, доставляющих личную почту другим узлам, их в каждой местной сети, как пра-
вило, несколько).
Соответствующие системы выделены в нодлисте ключевыми словами «Host»
и «Hub».
К системе маршрутизации нетмейла относятся также входные региональные
почтовые шлюзы (адрес почтового шлюза 50-го региона - 2:50/999).
В глобальную схему маршрутизации личной почты FidoNet следует включить
и шлюзовые межзональные системы, так называемые зон-гейты (zonegates), от-
ветственные за передачу личной почты между зонами FidoNet. Каждый зональ-
ный координатор поддерживает полный набор зон-гейтов для обеспечения пере-
дачи почты во все зоны.
Сюда же относятся и зон-гейты, созданные для связи с FTN-сетями, организа-
ционно отличными от FidoNet.
Хаб- и хост-маршрутизация описана также в главах 1 и 7.
На рис. 2.5 схематически изображена система маршрутизации личной почты,
как она представлена в нодлисте (февраль 1999 года).
Наличие хост- и хаб-маршрутизации позволяет упростить файлы конфигурации
программ, ответственные за упаковку почты, - так называемые нетмейл-пакеры
(netmail-packers). Вместо перечисления всех узлов, доступных через данный хаб,
можно просто указать на хаб-статус этого узла, и система самостоятельно, с исполь-
зованием информации из нодлиста, построит список его даунлинков. Вот как, на-
пример, может быть записана директива «доставлять почту на узлы с адресами
2:5049/2, 2:5049/5, 2:5049/8, 2:5049/9, 2:5049/13, 2:5049/15, 2:5049/16, 2:5049/17,
2:5049/18, 2:5049/34, 2:5049/38, 2:5049/39, 2:5049/40, 2:5049/45, 2:5049/49, 2:5049/
64, 2:5049/73 через 2:5049/12 (при использовании нетмейл-пакера UniMail)»:
RouteNorm 2:5049/12 2.* 5.* 8.* 9.* 13.* 15.* 16.* 17.* 18.* 34.* 38.* 39.*
RouteNorm 2:5049/12 40.* 45.* 49.* 64.*
То же самое при использовании хаб-маршрутизации записывается как:
RouteNorm # 2:5049/*.*
Процитированная строчка означает буквально «использовать хаб-маршрутиза-
цию в сети 5049», и она работает эквивалентно первым двум строкам только в том
случае, если все перечисленные в первом примере узлы «входят в подхабник» узла
с адресом 2:5049/12, то есть в нодлисте их строки следуют непосредственно за стро-
кой 2:5049/12 (на момент написания главы это было именно так). Однако эффект
воздействия строчки с директивой использования хаб-роутинга не исчерпывается
маршрутизацией на 2:5049/12. После употребления этой директивы в конфигура-
ционном файле программы UniMail почта на узел с адресом 2:5049/16 упакуется
через 2:5049/12, на узел 2:5049/55 - через 2:5049/19, а на 2:5049/1 - через 2:5049/
36, в полном соответствии с хаб-структурой текущего нодлиста сети.
Аналогичный синтаксис используется и во многих других программах марш-
рутизации почты, например в многофункциональном обработчике нетмейла
Itrack или в популярной почтовой программе T-Mail.
Системы автоматической маршрутизации почты в FidoNet
Настройка системы маршрутизации нетмейла на узле FidoNet представляет
собой достаточно сложную процедуру, особенно на крупных хабах. Наличие
Й OS/2 System Editor - C:\HDO\zonegate.txt \ ; е ' =г- ' < |«? |Ю|
File Edit Options Help , / \ I
Зональные шлюзы , ' Zonegate' Европа-Сев.Америка , л ' '2->Г (2:2/1) Zonegate ЕвропауОкеания 2->3 Д2:2/3) Zonegate Европа*латинская Америка 2->4 (2:2/4) Zonegate ЕвропагАфрика . ;2->5 (2:2/5) Zonegate Европа*Азия 2->6 (2:2/6) Zonegate с VirtNet FidoNet->VirtNet (2:2/9) Zonegate с KolfNet FidoNet->WolfNet (2:2/602) ' / Региональные шлюзы 50-й регион 2.-й зоны ! Входной понтовый шлюз (2:50/999) / Шлюз FidoNet->InterNet (2:50/128) Шлюз для недоставленной почты (Holdgate) (2:50/9999) 51-й регион 2-й зоны , - Местные сети FidoNet . Сеть 5049 50-го региона 2-й зоны FidoNet .. Хост-система 5049 (2:5049/0) Хаб-1(5049/12) Хаб-2(5049/19) Хаб-3(5049/30) Хаб-4(5049/36) Хаб-5(5049/96) /2,/5,/8,/9, /55,/82 /32,/37,/41, :/1,/46,/47, /44,/57,/58, .. /13,/15,/16, /42,/48,/60, /63,/65,/66, /69 /17,/18,/34, /72,/74,/80, /70,/75,/76, /38,/39,/40, /81,/83 /78,/79,/85, : /45,/49,/64, /86,/88,/256 И^ВЙ1^^ИИИИИИИ^^ИИ^^^^^ИИИЦИЯИИ1111И1^В1ИИИИИИ1ВИ
Рис. 2.5: Схема маршрутизации личной почты FidoNet на примере второй зоны,
50-го региона и сети 5049 (февраль 1999 года)
хаб- и хост-маршрутизации позволяет несколько упросить ее, но все же объем руч-
ной работы остается значительным. Для сокращения объема рутинной ежеднев-
ной работы по исправлению настроек программ-упаковщиков нетмейла были раз-
работаны системы автоматической маршрутизации, две из которых, используемые
в 50-м регионе, упомянуты ниже. Подробное их описание ищите в главе 1.
Сафроутер
Программа Safrouter, разработанная и поддерживаемая Юрием Сафроновым из
Москвы (адрес в FidoNet - 2:5020/204), выражает идею централизованного
управления системой маршрутизации почты в иерархическом уровне FidoNet
(сети, регионе, зоне). Она уже в течение ряда лет используется в R50 для управле-
ния маршрутизацией нетмейла в масштабах региона. Для работы программе ну-
жен конфигурационный файл, составляемый координатором FidoNet (для сети
такой файл может составлять NC, в R50 за составление файла маршрутизации
отвечает REC). Конфигурационный файл маршрутизации составляется по заяв-
кам участников сети, перечисленных в нем - узлов, хабов, сетевых координато-
ров, в зависимости от структурного уровня FidoNet, для которого предназначен
данный файл.
Например, файл маршрутизации сети 5049 составляется по заявкам узлов
и хабов, а региональный файл R50 - по заявкам NC и независимых узлов.
На основании регулярно обновляемого конфигурационного файла программа
Safrouter автоматически строит конфигурационный файл той программы марш-
рутизации Fido-почты, которая используется на данном узле. Еженедельное об-
новление конфигурационного файла производится с использованием механизма
файл-эх, и системный оператор полностью освобождается от работы по настрой-
ке системы маршрутизации.
У системы централизованного построения маршрутизации наряду с несомнен-
ными достоинствами есть и недостатки: она не слишком оперативна, не всегда
оптимальна; ошибки, случайно закравшиеся в конфигурационный файл на этапе
его составления, исправляются только в следующем файле, который может пос-
ледовать через неделю и более; отправка испорченного файла маршрутизации
может вывести из строя всю систему передачи почты в данном структурном уров-
не FidoNet.
От этих «неприятностей» свободна описанная в следующем разделе программа
FRIP, представляющая собой динамический построитель оптимального маршру-
та передачи почты (FRIP, конечно же, обладает своим набором как достоинств,
так и недостатков).
Протокол FRIP
Аббревиатура FRIP расшифровывается как F(idoNet) R(outing) Information)
Protocol) вслед за широко известным протоколом RIP (Routing Information
Protocol), использовавшимся «старой» программой-демоном routed операцион-
ной системы UNIX при настройке маршрутизации TCP/IP пакетов. Каждые не-
сколько десятков секунд RIP рассылает по сети широковещательные информаци-
онные пакеты, измеряя с их помощью «стоимость» имеющихся направлений
передачи и выбирая оптимальный вариант. Аналогично работает и FRIP. При каж-
дом запуске он посылает всем имеющимся FRIP-линкам RIP-пакеты, представ-
ляющие собой небольшие информационные файлы. При получении такого паке-
та система дописывает в него свою информацию и отправляет назад адресату.
Полученная информация о наиболее «быстрых» линках затем используется для
построения оптимальной системы маршрутизации.
FRIP был разработан Дмитрием Завалишиным. Попытки использовать FRIP
в качестве глобального подхода к маршрутизации почты успеха не имели; вслед-
ствие ошибок конфигурации FRIP-систем и низкой оперативности их работы
почта не всегда шла по оптимальному маршруту. Тем не менее при построении
небольших систем маршрутизации файлов FRIP вне конкуренции.
Поддержка энтузиастов использования FRIP осуществляется в эхо-конфрен-
ции RU. FRIP.
Стандарты FidoNet о представлении и передаче нетмейла
Стандарты и предложения FidoNet, полный список которых приведен в приложе-
нии 1, описывают в основном формат писем FidoNet. В отличие от стандарта RFC-
822, принятого в Internet [2.11], формат хранения письма FidoNet не текстовый,
а бинарный. Это следствие стремления оптимизировать систему, ведь станции
FidoNet всегда устанавливались на маломощных домашних компьютерах и ресур-
сов (дисковой и оперативной памяти) вечно не хватало. Бинарный же формат эко-
номичнее текстового. Принятые в FidoNet форматы хранения писем, перечислен-
ные в табл. 2.11, более подробно описаны в главах 4 и 7.
Стандартом, который должен соблюдаться обязательно, является FTS-0001
[2.5]; в нем подробно и точно, в терминах многоуровневой сетевой модели OSI
описаны:
□ структура данных, в которой хранится письмо (MSG-файл);
□ формат описания «прикрепленного» к письму файла (это основной способ
транспорта бинарных файлов в FidoNet);
□ структура данных, в которую письмо упаковывается перед отправкой;
□ структура РКТ-файла, который используется для временного хранения пись-
ма при передаче информации от одной системы к другой;
□ способ маршрутизации нетмейла (включая механизм планировки посред-
ством «событий»);
□ протокол установления соединения между двумя FidoNet-системами и про-
токол передачи информации, основанный на протоколе передачи файлов
Xmodem.
Из дополнительных стандартов и предложений, не обязательных к использо-
ванию, но широко применяемых на практике, следует отметить FTS-009 [2.12],
где описывается формат служебной строки уникального идентификатора сообще-
ния - так называемый кладж MSGID. С помощью этого идентификатора можно
легко находить дублированные сообщения, возникающие при ошибочной конфи-
гурации маршрута передачи писем, и таким образом оптимизировать сеть.
Таблица 2.11. Стандарты FidoNet, посвященные описанию формата писем (*.msg)
и почтовых пакетов (*.pkt)
Код документа Оригинальное название Автор Перевод названия Статус
FTS-OOO1.016 Packet and *.msg format R.Bush Формат почтового пакета и файла *.msg Используется как стандарт
FTS-0009.001 MSGID format J.Nutt Формат служебной строки MSGID Используется как необязательный стандарт
FSP-1001.002 Timezone information in FTN messages O.Sorensen Информация о часовом поясе в сообщениях FidoNet Ограниченно используется
FSP-1002.002 Reply indication in FTN subject lines O.Sorensen Способ ответа на письмо FidoNet по содержимому строки «Тема» Ограниченно используется
FSP-1006.001 Kludge for specifying addition e-mail reply addresses R.v.d.Winkel Служебная строка для добавления e-mail адреса для ответа Ограниченно используется
Таблица 2.11. Стандарты FidoNet, посвященные описанию формата писем (*msg) и почтовых пакетов (*.pkt) (продолжение)
Код документа Оригинальное название Автор Перевод названия Статус
FSP-1007.001 Multiple recipient address specification to gateway R.v.d.Winkel Множественные адреса получателей для писем, отправляемых через шлюз Ограниченно используется
FSP-1008.002 New control lines for forwarded messages M.Hohner Новые служебные строки для пересылаемых сообщений Не используется
FSC-0007.002 RFC-822-style msg header proposal R.Heller Заголовок письма в стиле Интернет-стандарта RFC-822 Не используется
FSC-0014.001 Binary-style msg proposal W.Wagner Предложение по бинарному msg-формату (почтовый пакет типа 3) Не используется
FSC-0030.001 Proposal for message identification J.Cowan Предложение по идентификации сообщений Используется частично
FSC-0032.001 Proposed message quoting standard M.Ratledge Предложение по оформлению цитат в письмах FidoNet Используется
FSC-0035.001 Transparent Gateways to and from FidoNet M.Shiels Почтовые шлюзы из/в FidoNet Используется
FSC-0039.004 A Type-2 Packet Extension Proposal M. Howard Предложения по усовершенствованию формата почтового пакета «Туре-2» (см. также FSC-0045 и FSC-0048) Используется
FSC-0043.002 Some hints on recognizing control lines in FidoNet(r) message text R.Bush Некоторые способы распознавания служебных строк в тексте сообщений FidoNet Используется
FSC-0045.001 A Proposal for A New Packet Header Format T.Henderson Предложение по новому формату заголовка пакета Используется
FSC-0047.001 The GXSPLIT Kludge Line For Splitting Large Messages P.Terry Служебная строка "ASPLIT для расщепления больших сообщений Используется
FSC-0046.005 A Product Idenfifier for FidoNet Message Handlers J.Hom- righausen Идентификатор продукта для программ обработки сообщений Fidonet Используется
FSC-0048.002 A Proposed Type-2 Packet Extension J.Vroonhof Предложение по усовершенствованию формата почтового пакета «Туре-2» Используется
FSC-0053.002 Specifications for the "aFLAGS field J.Hom- righausen Спецификации служебной строки ~аFLAGS Используется
FSC-0064.007 InterDomain Message Identification, Gating, Reply Linking and Addressing J.Penner Междоменная идентификация сообщений, их шлюзование, ответ, линковка, адресация Используется
Таблица 2.11. Стандарты FidoNet, посвященные описанию формата писем (*.msg)
и почтовых пакетов (*.pkt) (окончание)
Код документа Оригинальное название Автор Перевод названия Статус
FSC-0065.001 Туре 3 ASCII: A proposal M.Kimes (Пакет) Тип-3 ASCII: Предложение Не используется
FSC-0066.002 Туре 3 BINARY: A proposal M.Kimes (Пакет) Тип-3 Бинарный: Предложение Не используется
FSC-0067.001 A Proposal For Sensible New Kludge Lines M.Kimes Предложение новых служебных строк Не используется
FSC-0073.001 Encrypted message identification for FidoNet J.Mudge Идентификация зашифрованных сообщений FidoNet Не используется
FSC-0077.001 Type-10 Packet Format J.Steck Формат пакета Тип-10 Не используется
Эхо-почта (echo-mail)
Система электронных конференций, известная в FidoNet как эхо-почта, была
впервые разработана в конце 1985 года. Правила и обычаи обработки эхо-почты,
ее передачи по сети во многом похожи на описанные выше в этой главе правила
обработки и передачи нетмейла, однако есть и существенные отличия.
Так, для нетмейла существует понятие обязательной доставки входящей почты
(маршрутизация входящей почты), и координатор вашей сети обязан предоста-
вить вам возможность ее получения с хоста сети. Для эхо-почты подобные прави-
ла отсутствуют; ее доставка целиком является результатом личной договореннос-
ти сисопов.
Если вы не знакомы с концепцией эхо-почты, лучше вернуться и прочитать ее
описание в главе 1 (раздел «Эхо-конференции FidoNet»).
Эхо-почта требует при передаче по сети специальной дополнительной обработ-
ки (в FidoNet используется термин toss, и программы обработки эхо-почты назы-
ваются тоссерами). Конфигурация программ обработки эхо-почты довольно
сложна (см. главу 8), и ошибки в конфигурации могут привести к образованию
большого количества дублированных писем - дупов, передача которых по сети
вызывает ее перегрузку. Вообще эхо-почта, в отличие от нетмейла, является дос-
таточно «тяжеловесным» сервисом, однако и выгоды велики, поэтому для боль-
шинства участников получение эхо-почты FidoNet - это основной и наиболее
привлекательный сервис сети.
Для успешного использования эхо-почты надо, с одной стороны, хорошо пред-
ставлять техническую суть процесса конфигурации эхо-системы и принципов рас-
пространения эхо-почты, с другой, хорошо знать правила обращения с этим мощ-
ным и одновременно опасным инструментом.
В регионе 50 существует система координации эхо-почты, почти в каждой сети
есть NEC - Net Echo Coordinator, к нему и адресуйте все свои вопросы, связанные
с эхо-почтой. (В нодлисте NEC обычно помечен флагом U,NEC.) Если у вас есть
только пойнт-адрес и весь сервис сети вы получаете с одного узла, лучше сначала
обратиться за разъяснениями к своему боссу.
Координацию эхо-почты на уровне региона осуществляет REC - региональный
эхо-координатор.
Кроме того, если вы намерены активно участвовать в тех или иных конферен-
циях, нужно знать обычаи управления и содержание эхо-конференций в FidoNet.
Имеется в виду так называемое модерирование в стиле FidoNet (глава 1, раздел
«Основной ритуал и правила выживания»).
Правила обращения с эхо-почтой
В Полиси эхо-почте уделяется мало внимания, несообразно ее значению в жизни
FidoNet. Это связано с тем, что к моменту выхода последней версии Полиси в 1989
году эхо-почта была еще достаточно «молода». Авторы текста Полиси понимали,
что эхо-почта требует более детального рассмотрения, и в разделе 9.9 указано, что:
«Эхо-почта есть важная и мощная сила FidoNet. С точки зрения рассмотрения
конфликтов в рамках Полиси эхо-почта есть просто несколько отличающаяся се-
тевая почта, и поэтому она подчиняется требованиям Полиси. По своей природе
эхо-почта налагает особые технические и социальные требования на сеть, кото-
рые превышают требования, установленные данной версией Полиси. Вследствие
этого существует EchoMail Полиси, расширяющая (не противореча ей) общую
Полиси, поддерживаемая эхо-координаторами и одобряемая с использованием про-
цедуры, аналогичной существующей для Полиси. EchoMail Полиси признается
координаторами FidoNet как база для разрешения конфликтов, связанных с эхо-
почтой. В будущем EchoMail Полиси может быть объединена с данной».
Таким образом, для полноценного понимания правил обращения с эхо-почтой
необходимо знакомство с Echomail Policy. Единой для всей FidoNet эхо-Полиси
до сих пор не существует; это объясняется значительными различиями в структу-
ре и обычаях распространения эхо-почты в разных зонах (например, в первой зоне
получение ее довольно часто бывает платным, хотя и недорогим сервисом). Одна-
ко существует много местных версий эхо-Полиси, принятых на различных струк-
турных уровнях FidoNet. Первой и самой известной из них является эхо-Полиси
первой зоны. Есть также документ, принятый во второй зоне, но настоящим рабо-
чим руководством в R50 служит приведенный в приложении 10 региональный
документ, так как система распространения эхо-почты (эхо-бекбон) существует
именно на уровне 50-го региона.
Более подробно правила обращения с эхо-почтой описаны в главе 8. Ниже при-
ведены пункты Полиси FidoNet, касающиеся эхо-почты:
□ пользователь не имеет права изменять текст транзитных эхо-сообщений, сле-
дующих через его систему (п. 2.1.5);
□ в отличие от нетмейла на эхо-почту не распространяется правило неразгла-
шения транзитной почты, так как эхо-письмо по определению является ши-
роковещательным (п. 2.1.6.1);
□ запрещается пересылка эхо-почты во время ZMH (п. 2.1.8);
□ ^...пересылка сообщений через узел, который не обязан делать это, без его раз-
решения может считаться “некорректным поведением”. Это включает в себя
и незапрашиваемую эхо-почту» (п. 2.1.7);
□ эхо-почта в Полней рассматривается как возможный источник перегрузки
сети (раздел 4.2, пп. 2.1.8, 10.3.7);
□ в конфликтных ситуациях, возникающих между участниками сети, эхо-поч-
та может рассматриваться как аналог нетмейла (см., например, п. 2.1.12).
Координация эхо-почты и эхо-бекбон
Координацию распространения эхо-почты осуществляет структура эхо-координато-
ров, включая сетевой, региональный и зональный уровень. Для понимания принци-
пов координации эхо-почты важным является понятие бекбона - опорной структу-
ры раздачи эх, составленной из узлов, называемых эхо-хабами и связанных прямыми
линками. Узлы, осуществляющие связь между разными бекбонами, называются лон-
глинками (longlinks). Более подробно понятие бекбона рассмотрено в главе 8 на при-
мере бекбона сети 5049 и регионального бекбона R50. Эхо-почта может распростра-
няться и без определения бекбона, но при его наличии надежность и оперативность
системы эхо-конференций существенно возрастает. Первым и самым известным
в FidoNet является Североамериканский бекбон (North American Backbone, NAB).
Кроме NAB сейчас существует и всемирный Internet-бекбон WWB (World-Wide Back-
bone). Бекбон и эхо-Полиси связаны неразрывно; эхо-Полиси обычно служит руко-
водством к управлению бекбоном соответствующего уровня.
При этом, как правило, действуют следующие соглашения:
□ получение требуемой эхо-конференции при отсутствии ее на непосредствен-
ном аплинке осуществляется цепочкой запросов от пойнта к узлу, от узла к эхо-
хабу, от эхо-хаба к NEC данной сети (вариант: к лонглинку сети), от NEC к хабу
регионального бекбона;
□ все конфликты, возникающие в эхах, рассматриваются, как правило, NC и RC.
Эхо-координаторы в эти процессы вовлекаются очень редко;
□ эхо-координаторы сотрудничают с так называемыми модераторами (предсе-
дателями) эхо-конференций, управляющими тематикой конференций и кон-
тролирующими их содержание.
Стандарты эхо-почты
FidoNet испытывает явный дефицит стандартов на эхо-почту. Этому предмету
посвящены всего два документа :
□ в стандарте FTS-0004 [2.13] (заменен предложением FSC-0074 [2.14]) опи-
сывается история, общая концепция эхо-почты и формат сообщений;
□ в предложении FSC-0057 [2.15] - формат управляющих писем, с помощью
которых производятся операции управления подпиской.
Также в формировании стандарта на эхо-почту участвуют и базовые стандарты
FidoNet на формат нетмейл-писем, перечисленные выше в разделе «Стандарты
FidoNet о представлении и передаче нетмейла» (см. табл. 2.10).
Формат эхо-писем аналогичен описанному в FTS-0001 (см. выше в этой и 7-й гла-
вах) формату нетмейл-сообщений. Для обеспечения большей надежности рассылки
эхо-сообщений и устранения последствий ошибочной подписки (почтовых «петель»
и т.д.) в поле текста сообщения добавляется несколько дополнительных кладжей -
управляющих строк (control lines). Подробно эти строки описаны в [2.13, 2.14]
и в главе 8. Назначение управляющих строк следующее:
□ AREA - этот кладж (от англ, cludge - «управляющая строка») определяет
наименование эхо-области, которой принадлежит данное письмо;
□ ORIGIN используется для идентификации адреса, с которого отправлено
данное письмо;
□ SEEN-BY - список систем, которые уже получили данное письмо в процессе
распространения эхо-почты;
□ PATH - список систем, через которые прошло данное письмо.
Кроме SEEN-BY и PATH для диагностики правильности настройки системы
раздачи эхо-почты используются и стандартные управляющие строки сообщений;
в частности, большое значение для правильного распространения письма играет
наличие кладжа MSGID, описанного в FTS-0009 [2.12].
Для более полного знакомства с системой обработки и передачи по сети эхо-
почты рекомендуется изучить описание одной из популярных программ обработ-
ки эхо-почты, например тоссера FastEcho.
Распространение файлов по сети
В технологию FidoNet изначально была заложена возможность передачи файлов
вместе с письмом. Этот механизм описан в стандарте FTS-0001 [2.5] и называется
файл-аттач (file-attach, или «прикрепление» файла к письму). Файл в FidoNet
передается без дополнительного преобразования. Этим технология передачи фай-
лов FidoNet отличается от принятого в Internet способа алфавитно-цифрового
кодирования файлов в тело письма (более подробно принятые в FidoNet стандар-
ты на передачу файлов по сети обсуждаются в главе 9).
Передача файлов по FidoNet в отличие от передачи личной почты не относится
к числу обязательных сервисов сети и в общем случае не поддерживается, хотя
технические возможности для этого есть. Единственным надежным способом пе-
редачи файла адресату является организация непосредственного соединения меж-
ду вашей системой и системой, на которую файл адресован. Однако по договорен-
ности сисопов работают несколько схем доставки файлов.
Кодирование файла в тело письма. При использовании специальных утилит тек-
стового кодирования бинарных файлов имеется возможность отправить по стан-
дартному маршруту нетмейл-сообщение с закодированным в тело письма файлом.
Рис. 2.6. Пример нетмейл-сообщения с прикрепленным файлом net5093.ndl
На приемной стороне файл должен быть раскодирован соответствующей програм-
мой (например, UUDECODE, MIME или BINHEX в зависимости от того, какой из
них файл был закодирован). В FidoNet для этих целей чаще всего используется
UUENCODE/UUDECODE. Хотя на первый взгляд посылка нетмейл-сообщения
и не является пересылкой файла, тем не менее, поскольку Полиси запрещает по-
сылку кодированных сообщений (см. приложение 2, п. 2.1.4), гарантий доставки
того, что вы послали, в этом случае нет. Более того, попытку пересылки подобным
образом больших объемов информации могут счесть раздражающим поведением.
Единственной гарантией доставки в этом случае может служить согласие всех тран-
зитных узлов на передачу. Однако UUE-кодирование считается самым надежным
способом пересылки файлов с использованием стандартной схемы доставки почты
FidoNet. Небольшие, в несколько килобайтов, файлы можно отправлять и без пред-
варительного согласования.
Использование file-attach. Применяя стандартную для FidoNet технологию «при-
крепления» файла к письму, вы отправляете файл путешествовать по сети в неиз-
меняемом виде. Для того чтобы это условие было выполнено, необходимо устано-
вить у письма атрибут FileAttached и указать в поле темы письма полный путь
и имя файла (рис. 2.6). При отправке файл появится во входном директории ваше-
го аплинка, и единственной информацией, которая поможет системе вашего босса
послать его в дальнейшее путешествие по сети, будет служить нетмейл-записочка
вроде той, что изображена на рис. 2.6.
Необходимо заметить, что эта информация имеет ценность только в том случае,
если система вашего аплинка поддерживает маршрутизацию файловых отправлений,
что является стандартом только для arcmail-attach (АМА) систем. Системы Binkley-
style обычно не поддерживают транзитную передачу файлов по сети, если только
сисоп специально не позаботится об этом. (Подробное описание АМА и Bink-style
почтовых программ приводится в главах 4 и 7.)
Использование механизма файл-эх. Файловые конференции (файл-эхи) предна-
значены для тематической рассылки файлов по сети по взаимной договоренности
сисопов. По реализации файл-эхи напоминают обычные эхо-конференции FidoNet;
они работают с использованием специальных программ - файл-эхо процессоров
(Allfix, Filin). В конфигурации каждой из таких программ содержится описание тем
файл-эх и списка подписчиков. Файл-эхи уменьшают загрузку сети в сравнении
с хаотичной рассылкой файлов, практиковавшейся до возникновения этого просто-
го и удобного механизма. Но их нельзя использовать для доставки ваших личных
файлов; это общественный механизм, и рассылка файл-эх подчиняется строгим пра-
вилам, соблюдение которых контролируется файл-эхокоординаторами различных
уровней. В регионе 50 существуют файл-эхокоординаторы на сетевом и региональ-
ном уровнях.
Специальные стандарты на способы передачи файлов по сети отсутствуют, есть
только несколько проектов стандартов, самый ранний из которых, FSC-0028 [2.16],
относится к 1988 году. В FSC-0028 достаточно пространно изложены существую-
щие способы рассылки файлов по сети и приведен формат информационного TIC-
файла, используемого при реализации транспорта файл-эх.
Подробное описание механизма файл-эх и практики их использования и коор-
динирования находится в главе 9.
Открытость и секретность в FidoNet
FidoNet - любительская система, и предоставлять условия для неконтролируемой
передачи почты по ее каналам было бы опрометчиво - могут возникнуть ситуации,
когда такая привлекательная возможность секретной передачи будет использована
во вред сети. Например, можно вообразить использование FidoNet для интенсив-
ной коммерческой деятельности (что запрещено Полиси) или незаконной деятель-
ности (что также запрещено). Поэтому FidoNet - открытая среда, где каждый си-
соп имеет право читать не предназначенные ему письма и Полиси даже рекомендует
время от времени поступать подобным образом.
Парольная защита соединения
Базовый стандарт FidoNet, FTS-0001, не подразумевает какой-либо защиты со-
единения. Прежде это считалось ненужным - это была сеть друзей и ее участники
были знакомы лично. В дальнейшем встала задача защиты FidoNet-системы от
несанкционированного доступа. Сейчас существует возможность организации
защищенного канала передачи информации с использованием FTN-технологии.
Ключевым элементом при этом является защищенность соединения между двумя
системами. (Действительно, если бы соединения почтовых программ FidoNet не
были никак защищены, то любой мог бы передать почту на вашу систему, пред-
ставившись при этом кем угодно, выдумав любые адреса и имена.)
Основой защиты почтового соединения FidoNet являются пароли, которые, как
правило, хранятся в конфигурационных файлах почтовых программ в открытом
виде. При передаче эхо-сообщения помещаются непосредственно в заголовок по-
чтового пакета (файл с расширением *.pkt) и проверяются программой-обработчи-
ком эхо-почты. Есть и другие элементы и сервисы FidoNet, защищенные паролями.
Нужно только обращать внимание на конфигурацию важных соединений с други-
ми системами - вашими прямыми линками, договариваться о паролях, передавая
их с системы на систему наиболее защищенным способом, то есть используя пря-
мое соединение. Ни в коем случае не следует передавать пароли с применением схе-
мы маршрутизации FidoNet, так как это сделает их доступными фактически всей сети
и дальнейшее их использование будет бессмысленным.
Шифрованная почта (encrypted mail) в FidoNet и PGP
Прямое соединение с использованием пароля является единственным «законным»
способом организации защищенного канала передачи информации в FidoNet. До-
полнительного шифрования здесь не требуется, ведь ваша система соединяется
непосредственно с системой вашего адресата. Но такой способ передачи дорог
и неудобен: приходится платить за междугородние звонки, обращать внимание
на время работы станции вашего адресата и т.д.
В FidoNet существует практика создания структур пересылки почты, в рамках
которых шифрование отправляемой информации является разрешенным серви-
сом. Есть даже специальный пользовательский флаг (ENC, см. раздел «Пользова-
тельские флаги в нодлисте») в нодлисте для отметки таких систем. Вы можете
выяснить, хотя это и непросто, поддерживают ли транзитные системы на всем
пути от вашей станции и до системы адресата передачу шифрованной почты,
и, если ответ будет положительным, воспользоваться услугой маршрутизации
личной почты по этой цепочке. При этом наиболее удобным и надежным способом
кодирования является использование одной из программ шифрования по двух-
ключевой схеме, например, популярной программы PGP, разработанной Филип-
пом Циммерманом (Philip Zimmerman). PGP - это бесплатная программа, кото-
рую легко найти в Internet. Начните поиск с адреса.
PGP использует два ключа для шифрования сообщения. Один, называемый
секретным, считается недоступным для посторонних и применяется для раскоди-
рования сообщения. Он хранится на вашем компьютере. Другой ключ для шиф-
рования называется открытым, его можно свободно передавать по незащищенным
сетям электронной почты, например по FidoNet. Обладания этим ключом недо-
статочно для того, чтобы расшифровать ваше сообщение. Для организации защи-
щенного канала вам нужно всего лишь обменяться открытыми ключами с вашим
корреспондентом (есть даже эхо-конференции для рассылки подобных ключей,
например LV. PGPKEYS). После этого можно быть спокойным за содержание ва-
шей личной переписки: если кто-то и попытается раскрыть сообщение, зашифро-
ванное с использованием PGP, то сделать это очень и очень непросто; мне, по край-
ней мере, такие случаи в FidoNet неизвестны. Подробное рассмотрение программ
шифрования выходит за рамки данной книги, для получения дополнительной
информации по этому важному вопросу лучше всего обратиться к опубликован-
ным работам [2.17] или поискать информацию в Internet. В FidoNet вопросам сек-
ретности посвящена эхо-конференция RU. SECURITY.
Заключение
Эта глава завершает знакомство с основами технического и организационного
устройства сети FidoNet; многие вопросы, подробно рассмотренные в главах 1 и 2,
далее мы уже не будем затрагивать. Внимательное изучение изложенного матери-
ала является необходимым условием для успешного продвижения по остальным
главам книги: предполагается, что каркас устройства FidoNet знаком уже не толь-
ко автору, но и читателю.
Глава III
Протоколы передачи
файлов
Протокол передачи файла - это программный способ безошибочной передачи
данных, организованных в виде файлов, от одного компьютера (источника) к компь-
ютеру-приемнику. В качестве способа соединения компьютеров обычно предпо-
лагается коммутируемое модемное соединение через последовательные порты
компьютеров, хотя возможно использование тех же протоколов и на других кана-
лах, например на TCP/IP.
Если бы эта книга была написана в самом начале существования FidoNet, то,
вероятно, большая ее часть была бы посвящена описанию протоколов передачи
файлов. Именно изобретение в конце 70-х годов способа безошибочной передачи
файлов по неустойчивым к помехам каналам (как раз такие каналы предоставля-
ли первые модемы, в которых отсутствовала коррекция ошибок) и привело спус-
тя пять лет к созданию FidoNet. Первым протоколом FidoNet стал тот самый
Xmodem (глава 1, раздел «BBS, Xmodem и FidoNet»), который был изобретен
Вардом Кристиансеном (Ward Christianson). С появлением скоростных модемов
выяснилось, что у этого замечательного протокола есть неустранимые недостат-
ки, поэтому в дополнение к нему были разработаны более совершенные протоко-
лы. Правильный выбор основного протокола передачи файла, который осуществ-
ляется соответствующей настройкой почтовой программы, порой критически
влияет на скорость передачи данных.
Все описанные протоколы передачи файлов реализуют тот или иной механизм
ARQ (Automatic Repeat reQuest - автоматический запрос повторной передачи),
используя сигналы подтверждения правильного приема блока (АСК) и запроса
на повторную передачу (NAK или NACK). Существуют три основных способа ре-
акции протокола на положительные и отрицательные сигналы:
□ старт-стопный, или передача с остановкой-ожиданием (SAW - Stop And
Wait). Этот метод называют также методом блочной передачи. Передавшая
блок система ждет отклика о его получении от принимающей системы. Имен-
но так работает Xmodem;
□ с возвращением на N кадров (GBN - Go Back N), называемый также потоко-
вым методом передачи;
□ метод выборочного повтора (SR - Selective Repeat).
Наиболее эффективен последний метод - ARQrana SR, наименее - ARQrnna
SAW. Для более подробного ознакомления со способами исправления ошибок пе-
редачи следует обратиться к специальной литературе [1.5, 3.1].
При всем многообразии протоколов передачи файлов не все они получили рас-
пространение в FidoNet. Произошло это по разным причинам. Старый, разрабо-
танный в Колумбийском университете для связи компьютеров различных типов
протокол Kermit, устойчиво работающий в 7-битной среде, оказался слишком
медленным, некоторые известные протоколы не были бесплатными и не подходи-
ли по этой причине. Поэтому мы рассмотрим только основные и наиболее широ-
ко используемые протоколы, описание остальных можно найти в книгах [1.5, 3.1].
Следует знать, что протоколы передачи файлов в технологии FidoNet входят
как составная часть в протокол обмена сообщениями (или протокол почтовой сес-
сии) между двумя системами сети. Рассматривать их как отдельную сущность,
в отрыве от FTN-сессии, было бы неправильно. Поэтому при описании использу-
емых в FidoNet протоколов передачи файлов делаются ссылки и на протокол
FTN-сессии, частью которого они являются.
Протоколы почтовой сессии FidoNet и два известных протокола передачи файлов
(Xmodem и Sealink) как часть протоколов сессии подробно описаны в главе 5.
Xmodem
Описание протокола основывается на авторской документации 1982 года, напи-
санной через 3 года после создания первой версии [3.2].
Протокол Xmodem исключительно прост. Суть его заключается в передаче ин-
формации, разбитой на 128-байтные блоки, каждый из которых завершается од-
нобайтной контрольной суммой, от системы-источника к системе-приемнику.
После каждой посылки система-источник ждет подтверждения о получении бло-
ка от системы-приемника. До тех пор пока подтверждение не получено, следую-
щий блок не посылается.
Система-приемник получает блок и проверяет правильность приема расчетом
контрольной суммы и сверкой ее с хранящейся в конце блока. После этого посы-
лается либо уведомление о получении блока (АСК), либо запрос повторной пере-
дачи (NAK). Вот собственно и все содержание протокола. Существенным в опи-
санном процессе является то, что в качестве сигнальных посылок, используемых
при установлении соединения и обмене блоками, используются односимвольные
сообщения и что пересылаемая информация может содержать любые символы.
Последнее не позволяет использовать Xmodem в условиях 7-битной среды пере-
дачи (в FidoNet это редкость). Автором протокола определены сигнальные одно-
символьные посылки (табл. 3.1).
Таблица 3. /. Сигнальные посылки протокола Xmodem
Принятое Код обозначение Полное наименование Перевод названия
SOH 01 h Send of header Посылка заголовка
EOT 04h End of transmission Конец передачи
АСК 06h Positive acknowledge Уведомление об удачном приеме
NAK 15h Negative acknowledge Уведомление о неудачном приеме
CAN 18h Cancel Завершение передачи
С 43h Символ «С» Выбор типа контрольной суммы
Каждый блок протокола Xmodem выглядит следующим образом:
<80Н><номер блока><255-номер блока><128 байт данныххконтрольная суммах
Общие параметры для передающей и принимающей сторон таковы:
□ в случае возникновения ошибки повторные попытки приема совершаются до
10 раз;
□ можно использовать символ CAN (43h) для обрыва передачи;
□ протокол управляется приемником, то есть передатчик не может послать
блок, не получив уведомления о приеме;
□ можно использовать как однобайтную контрольную сумму, так и двухбайт-
ный циклический проверочный код (упрощенный алгоритм расчета приво-
дится в [3.3], выбор типа контрольной суммы производится на начальном
этапе инициализации протокола).
Протокол со стороны приемника
Приемник выдерживает 10-секундную паузу и, если в течение этого времени ни-
чего не принято, посылает символ NAK. Первый NAK сигнализирует передатчи-
ку о разрешении начать передачу. Первая 10-секундная пауза может опускаться.
Синхронизация осуществляется по номеру блока:
□ если принят правильный (то есть следующий по порядку) номер блока, то
передается АСК для запроса следующего блока;
□ если принят тот же самый номер блока, то это значит, что переданный АСК
был принят передатчиком с искажениями и его следует повторить;
□ если номер принятого блока не укладывается в эти две альтернативы, то пе-
редачу следует оборвать, послав сигнал CAN.
Протокол со стороны передатчика
Вначале передатчик ожидает сигнала NAK со стороны приемника, чтобы начать
передачу. Допустимое время ожидания не должно быть более 1 мин.
Когда блоки для посылки исчерпались, передатчик посылает сигнал EOT
и ждет АСК, повторяя EOT, если ожидаемый АСК не появляется. Пример переда-
чи данных с использованием протокола Xmodem приведен в табл. 3.2.
Таблица 3.2. Пример передачи данных при использовании Xmodem
Номер шага передачи Данные - передатчик Направление Данные - приемник
1 < NAK
2 <SOH>01h FEh <данные> <CS> >
3 < ACK
4 <SOH>02h FDH <данные> <CS> > <ошибка приема>
5 < NAK
6 <SOH>02h FDh <данные> <CS> >
7 < ACK
8 <SOH>03h FCh <данные> <CS> >
9 <ACK принят с ошибкой> < ACK
10 <SOH>03h FCh <данные> <CS> >
11 < ACK
12 <EOT> >
13 < ACK
Из таблицы видно, как на шагах 4 и 9 обрабатываются возможные ошибки пе-
редачи (контрольная сумма обозначается как <CS>).
Более подробно протокол Xmodem в его реализации, принятой в FidoNet, рас-
смотрен в главе 4. Там же отмечаются основные недостатки протокола, вызвав-
шие к жизни его более совершенных собратьев.
Существуют модификации протокола Xmodem, позволяющие принимать более
одного файла (Modem? и Telink), и модификация с размером блока 1024 байт,
показывающая большее быстродействие, чем изначальная 128-байтная.
Развитием Xmodem являются протокол Sealink, который используется в Fido-
Net (глава 4), а также Ymodem и Ymodem-g (в FidoNet не используются). Для зна-
комства с ними рекомендуем обратиться к [3.1].
Протокол Kermit
Этот протокол был разработан в Колумбийском университете в рамках проекта
по созданию единой сети из компьютеров различных типов. По происхождению
это кросс-платформенный протокол, устойчиво работающие реализации кото-
рого существуют для всех операционных систем. Этот протокол использует еще
меньшие блоки, чем описанный выше Xmodem (размер блока Kermit - 96 байт).
Протокол предназначен для работы в 7-битной среде передачи, и символы, для
кодирования которых требуется 8-й бит, отображаются двухбайтной посылкой,
что существенно понижает эффективность протокола. Это очень медленный, но
надежный и распространенный протокол. Существует его более быстрая и со-
вершенная модификация SuperKermit. В FidoNet этот протокол почти не ис-
пользуется.
Zmodem
Zmodem в настоящее время является наиболее распространенным протоколом
передачи файлов. Почти все терминальные и почтовые программы, в том числе
подавляющее большинство почтовых программ FidoNet, могут использовать этот
протокол. Zmodem был разработан в 1985-1986 годах Чаком Форсбергом (Chuck
Forsberg) в рамках проекта, открытого компанией Telenet для нужд пользовате-
лей одноименной сети, недовольных низкой эффективностью применяемых про-
токолов, и выпущен в свет для общего использования. Описание протокола и ис-
ходные тексты на языке С для операционной системы UNIX (программы rz/sz)
относятся к public domain, иными словами, на них не распространяются какие-
либо лицензионные и иные ограничения (это было условием проекта Zmodem).
Все это вкупе с прекрасными эксплуатационными характеристиками Zmodem
и обеспечило ему долгую жизнь и распространенность. Коммуникационные сис-
темы, не использующие Zmodem, сейчас большая редкость.
Для детального знакомства с Zmodem можно обратиться к специальной лите-
ратуре [1.5, 3.1] ик исходным текстам соответствующих программ. Данное изло-
жение основано на нескольких популярных статьях автора протокола, Чака Фор-
сберга [3.4-3.6], которые можно найти в Internet по адресу:
http://www.rdrop.com/users/ caf/.
Zmodem был спроектрован как развитие протоколов Ymodem и Ymodem-g, раз-
работанных Форсбергом ранее (Ymodem - Yet another Modem). Протоколы семей-
ства Ymodem были основаны на все том же Xmodem и по существу мало чем от
него отличались. Ymodem использовал ARQ типа SAW (ждал подтверждение на
каждый переданный блок), мог использовать как стандартные для Xmodem блоки
в 128 байт, так и килобайтные, что, с одной стороны, обеспечивало совместимость
с Xmodem, с другой - повышало быстродействие в случае соединения Ymodem-
Ymodem.
Кроме того, Ymodem включал свою реализацию процедуры пакетной передачи
файлов (протокол пакетной передачи Modem? был признан автором неудовлет-
ворительным из-за его старт-стопной природы).
Однако быстродействие протокола было невысоким (хотя и выше, чем у Xmo-
dem), и автор разработал его модификацию Ymodem-g (где «g» означало «go-go-
go!», т.е. - «давай-давай!»). Ymodem-g не имел встроенной коррекции ошибок:
в случае их появления он просто разрывал соединение. Зато он поддерживал по-
токовый метод передачи, то есть не ждал от принимающей стороны подтвержде-
ния получения каждого посланного блока, и за счет этого быстродействие его
было наивысшим. По образному выражению автора, Ymodem-g - это «поездка на
наивысшей скорости, не обращая внимания на сигналы светофоров».
К сожалению, работа Ymodem-g была неустойчивой, и не только из-за плохой
связи. Задержки на дисковые или видеооперации из-за аппаратных прерываний -
все могло вызвать его сбой и, как следствие, разрыв соединения. Кроме того, про-
токолы семейства Ymodem были небесплатны. Когда в 1985 году Форсберг начал
разработку протокола, названного им Zmodem, он поставил перед собой следую-
щие задачи:
□ добиться высокой эффективности использования полосы пропускания кана-
ла связи (и, как следствие, высокой скорости передачи информации);
□ устойчиво работать при высоком коэффициенте ошибок в канале связи;
□ добиться, чтобы протокол коррекции ошибок был более надежным, чем Xmodem
(низкая надежность однобайтной контрольной суммы Xmodem была хорошо
известна, но и упрощенный расчет двухбайтной CRC в усовершенствованной его
модификации также не давал желаемого результата);
□ обеспечить восстановление информации при сбоях без повторной передачи
уже прошедшей информации (если скачано 90% большого файла и произо-
шел разрыв соединения, то Xmodem, Ymodem и многие другие протоколы на-
чинали передачу файла сначала);
□ обеспечить возможность устойчивой работы протокола в 7-битной среде пе-
редачи без существенного снижения скорости;
□ устойчиво работать в сетях коммутации пакетов, для которых характерны
большие задержки при малом числе ошибок.
Для выполнения этих противоречивых требований автор использовал описан-
ные ниже методы (по пунктам).
Быстродействие
Быстродействие протокола Zmodem достигается за счет совершенно другой (если
сравнивать с предшествующими протоколами) логики разбиения посылаемой
информации на блоки. Понятие блока как такового, в том смысле, в каком он су-
ществует в протоколах Xmodem или Ymodem, для Zmodem вовсе отсутствует.
Блок Zmodem может быть такого же размера, как и передаваемый файл, поэтому
блочная передача обеспечивается за счет следующих алгоритмов:
□ блоки Zmodem делятся на пакеты, которые передаются без старт-стопного
механизма ожидания ответа от приемника, характерного для Xmodem или
Ymodem;
□ размер пакета Zmodem переменный, он подстраивается под качество линии
и изменяет длину пакета от 128 до 1024 байт (в стандартной реализации про-
токола, во многих реализациях пороговые значения изменены от 64 байт ми-
нимально до 16 Кбайт максимально);
□ передаваемая в пакете информация предварительно архивируется на переда-
ющей стороне и разархивируется на приемной.
Эти методы делают Zmodem быстродействующим протоколом, хотя в услови-
ях, когда коэффициент ошибок в канале связи равен нулю и отсутствуют задерж-
ки при передаче данных, у поточных протоколов вроде Ymodem-g показатель бы-
стродействия выше, чем Zmodem.
Надежность
Zmodem реализует более надежную защиту данных от искажения в процессе пе-
редачи, чем Xmodem. Он не использует однобайтную контрольную сумму, харак-
терную для Xmodem, из-за ее низкой надежности. Циклический проверочный код,
используемый в Zmodem, может быть 16- или 32-битным, занимая 2 или 4 байта
и обеспечивая требуемую надежность.
Существенным моментом является и то, что Zmodem при передаче в качестве
скользящей метки использует не мифический номер блока, как многие другие
протоколы, а реальную длину переданного участка файла.
Привязка к реальному файлу упрощает и реализацию такой важной процеду-
ры, как восстановление связи после обрыва с докачкой оставшейся части файла.
Это также исключает появление «мусора» за логическим концом принятого фай-
ла, характерного для Xmodem и Ymodem.
Для устойчивой работы в сетях коммутации пакетов Zmodem, как и упомяну-
тый выше Kermit, использует маскирование, то есть часть символов заменяется
двухбайтным кодом. Однако в отличие от Kermit, маскирующего все без исклю-
чения 8-битные посылки, Zmodem делает только необходимый минимум, коди-
руя известные управляющие символы, и снижение эффективности протокола на
этой операции не превышает 3%.
Простота реализации
Zmodem поддерживает непрерывную передачу данных, прерываемую только сооб-
щением от приемника с запросом на повторную передачу с того места, где была об-
наружена ошибка. Фактически окно (или буфер) протокола равен по размеру пере-
даваемому файлу. Это упрощает логику работы и исключает процедуру обработки
переполнения буфера передачи, столь характерного для некоторых протоколов.
Логически Zmodem проще такого протокола, как, например, SuperKermit, и может
быть реализован очень компактно. Он хорошо работает на самых различных вы-
числительных системах, например, в условиях, когда компьютер не может одновре-
менно работать с диском и последовательным портом или когда одновременная
передача и прием данных невозможны.
Совместимость
Zmodem может эмулировать протокол передачи файлов Ymodem, если противо-
положная сторона не поддерживает Zmodem.
Zmodem включает около 20 команд (типов кадров) и позволяет сторонам обмени-
ваться дополнительными текстовыми командами (используя кадр ZCOMMAND).
Все это позволяет рекомендовать Zmodem в качестве основного протокола поч-
товой сессии FidoNet. Другие протоколы можно использовать, но в случае любых
затруднений при передаче лучше всего начинать изучение проблемы, включив
протокол Zmodem.
Более подробно ознакомиться с форматом кадров протокола и особенностями
его реализации можно в [3.1, 3.4-3.6].
Протокол Hydra
При обмене информацией между двумя системами довольно часто возникает си-
туация, когда обе стороны имеют информацию для передачи. Все протоколы, рас-
смотренные до сих пор, были так называемыми полудуплексными. Ни один из них
не реализовывал передачу сразу в обоих направлениях. Вместо этого системы
дважды запускали выбранный протокол, причем сначала в качестве отправителя
выступала одна система, а потом - другая. Так часто делается и в FidoNet: почто-
вая сессия между двумя системами FidoNet включает несколько соединений на
выбранном протоколе передачи файлов (обычно это Zmodem).
Вскоре после изобретения Zmodem были созданы протоколы передачи файлов,
передающие информацию сразу в обоих направлениях. При этом каждая из взаи-
модействующих систем выступает одновременно и приемником, и передатчиком.
Такие протоколы называются дуплексными (duplex) или двунаправленными (bidi-
rectional). Для успешной работы дуплексного протокола передачи файлов более
низкоуровневые модемные протоколы также должны быть дуплексными
и симметричными (то есть скорость в обоих направлениях должна быть пример-
но одинаковой). Большинство используемых модемных протоколов именно тако-
вы (табл. 3.3).
Но такие модемные протоколы, как, например, асимметричный протокол HST
фирмы US Robotics, не слишком подходят для запуска дуплексных протоколов
передачи файлов, поскольку каждая попытка встречной передачи информации
может вызывать процедуру разворота протокола, что сильно замедляет процесс.
В FidoNet довольно часто при установлении соединения обе стороны передают
информацию друг другу, но обычно передача с одной из сторон в несколько раз
больше (поскольку, как правило, одна из систем выступает в качестве аплинка, то
есть обеспечивает соединение другой со всей остальной сетью или ее частью).
Поэтому дуплексные протоколы не сразу получили распространение в FidoNet.
Первым таким протоколом был Janus, автором которого является Рик Хюбнер
Таблица 3.3. Классификация модемных протоколов
по направленности передачи данных
Название протокола Скорости в разных направлениях в бит/с Характеристика направленности (дуплекс или полудуплекс)
V.21 (Bell 103J) 300/300 Симметричный дуплекс
V.22 1200/1200 Симметричный дуплекс
V.22.bis 2400/2400, 1200/1200 Симметричный дуплекс
V.23 600/75, 1200/75 Полудуплекс с низкоскоростным обратным каналом
V.32 2400/2400, 4800/4800, 9600/9600 Симметричный дуплекс
V.32.bis 4800/4800, 7200/7200, 9600/9600 12000/12000, 14400/14400 Симметричный дуплекс
V.32.turbo Скорости V.32.bis и 16800/16800, 19200/19200 Симметричный дуплекс
V.34 (V.34+,V.Fast) 2400-28800/2400-28800 (с шагом 2400) Асимметричный дуплекс, скорости каналов определяются качеством соответствующих каналов (прямого и обратного)
HST 4800-21600/300-450 Асимметричный дуплекс
PEP (TurboPEP) до 23000/0 Полудуплекс
(Rick Huebner). Janus был реализован в почтовой программе Binkley Term в 1988
году. Однако наиболее надежным, удобным и скоростным двунаправленным про-
токолом, разработанным специально для использования в FidoNet, является прото-
кол передачи файлов Hydra, описанный в проекте стандарта FidoNet FSC-0072 [3.7]
его авторами И. Хомригхаузеном (J. Н. Homrighausen) и А. Ленцем (A. G. Lentz).
Прямые предки протокола Hydra - Zmodem и Janus. В известном смысле Hydra -
комбинация этих двух протоколов.
При ее разработке авторы ставили перед собой следующие задачи:
□ Hydra должна поддерживать передачу не только при использовании симмет-
ричных дуплексных модемных протоколов, но и асимметричных, вроде V.34
или HST;
□ Hydra должна быть нечувствительной к относительно длительным задерж-
кам передачи, обеспечивая тем не менее максимум надежности и производи-
тельности.
Как и Zmodem, Hydra представляет собой как бы контейнер для нескольких
протоколов с развитым командным языком, позволяющим в каждом конкретном
случае подобрать оптимальный вариант формата пакета и скорости передачи.
Протокол известен как устойчивый способ передачи файлов, достаточно ско-
ростной и хорошо работающий на линиях плохого качества. В FidoNet протокол
Hydra широко распространен, встроен во многие почтовые программы FidoNet.
Подробное описание формата пакетов и командного языка, а также других дета-
лей устройства протокола Hydra можно найти в [3.7].
Протокол Binkp
Binkp стоит особняком среди протоколов передачи файлов. Спецификация этого
протокола разработана программистом и системным администратором Дмитрием
Маловым для популярной почтовой FTN-программы Binkd, реализующей проброс
Fido-почты через TCP-соединение (то есть посредством стандартного протокола
сети Internet). Подробнее Binkd описан в главе 11. Поскольку он использует в каче-
стве транспорта протокол TCP, в который уже встроена коррекция ошибок, допол-
нительную коррекцию автор посчитал излишней, и в Binkp ее нет. Это делает про-
токол высокоэффективным, хорошо работающим на свободном от ошибок канале.
Binkp используется не только при соединении через TCP. Поддержка Binkp для
обычных модемных соединений встроена в почтовую программу ARGUS. Дело
в том, что программное обеспечение современных модемов содержит коррекцию
возникающих в процессе передачи ошибок и в большинстве случаев устанавливае-
мые соединения не требуют дополнительной проверки на безошибочность. Поэто-
му оказалось возможным использовать Binkp и в условиях обычного модемного
линка. Binkp оптимизирован для работы на соединениях с пропускной способнос-
тью, которая может варьироваться в исключительно широком диапазоне - от не-
скольких байтов в секунду (широко распространенная ситуация при загруженном
Internet-канале) и до нескольких мегабайтов в секунду (при соединении через ло-
кальную сеть).
Описание протокола Binkp
Описание Binkp, приведенное ниже, основывается на авторской документации,
поставляемой в комплекте с почтовой программой Binkd. Для более подробного
ознакомления с особенностями этого протокола рекомендуется изучить также
проект стандарта [3.8].
Для понимания функционирования Binkp следует знать, что из двух взаимо-
действующих при передаче данных сторон одна считается сервером, а другая -
клиентом. Количество одновременно устанавливаемых клиентских и серверных
соединений ограничивается при конфигурации почтовой программы.
Binkp работает через двунаправленный символьный канал, не допускающий
ошибок при передаче данных. Именно такие каналы предоставляет широко ис-
пользуемый в сети Internet протокол TCP, таковы и модемные соединения, уста-
новленные с использованием встроенных в программное обеспечение современ-
ных модемов протоколов коррекции ошибок.
Любые данные, записываемые в канал каждой из сторон, имеют общий формат,
изображенный на рис. 3.1.
Заголовок кадра - это два байта данных, определяющие тип и длину (в байтах)
данных, следующих за заголовком. Если старший бит заголовка сброшен (то есть
равен 0), то все данные, поступившие с кадром, следует дописать к текущему при-
нимаемому файлу (если такой файл уже открыт, иначе - отбросить). В противном
случае данные следует разобрать как команду, меняющую состояние протокола.
При этом первый байт данных, поступивших с кадром, интерпретируется как но-
мер команды. Оставшиеся - как аргумент. Аргументы команд представляют собой
произвольные наборы символов, не обязательно ограниченных \0. Команда без ар-
гументов (например, М_ОК) может выглядеть так, как показано на рис. 3.2.
Рис. 3.2. Пример фрейма Binkp, содержащего команду М_ОК
Ниже описаны некоторые команды Binkp версии 1.0 и примеры их аргументов
(через пробел от наименования команды записан ее номер, используемый для
идентификации команды):
□ M_NUL 0 - аргумент команды игнорируется (и, возможно, записывается
в протокольный файл). Именно так передается нодлистовая информация,
имя сисопа и т.д. Пример: Amir Shabashvili;
□ M_ADR 1 - список 5D адресов (через пробел).
Пример: 2 : 5049/12©fidonet 2 : 5049/0@f idonet;
□ M_PWD 2 - пароль: после успешной обработки пароля, принятого от удален-
ной системы, binkp-сервер пересканирует очередь. Пример: pAsSwOrD;
□ М_ОК 4 - ответ на правильный пароль: binkp-клиент при приеме этого сооб-
щения пересканирует очередь сообщений. Аргумент команды игнорируется;
□ M_FILE 3 - данные о следующем за этим фреймом файле. Через пробел:
- имя файла (без пробельных символов);
- размер;
- unix-time;
- смещение, с которого файл передается.
Числа записываются в десятичной системе счисления. Все следующие приня-
тые блоки данных относятся именно к этому файлу до поступления следующего
сообщения M_FILE. Специального признака конца файла нет, так как размер файла
известен заранее. Binkp допишет «лишние» блоки к концу текущего файла. Каждый
новый файл передается со смещения 0. Получение M_GET от удаленной системы
заставляет сделать операцию SEEK. Пример: config, sys 125 2476327846 0 или
при ответе на M_GET со смещения 100: config, sys 125 2476327846 100;
□ М_ЕОВ 5 - команда «End-of-Batch». ЕОВ передается после того, как посланы
все файлы. Если мы находимся в состоянии ЕОВ (все файлы посланы) и по-
лучаем от противоположной стороны ЕОВ (больше нет файлов для нас), то
это означает, что получены все подтверждения на все посланные файлы, по-
лучены все файлы, перезапрошенные по GET, и сессия считается успешно за-
вершенной;
□ M_GOT 6 - передается принимающей файл стороной как подтверждение после
получения последней порции данных файла. Аргументы копируют аргументы
команды FILE от противоположной стороны, за исключением последнего - сме-
щения, который не возвращается на систему, передавшую M_FILE. MGOT
может быть передан и в процессе приема файла. Реакцией на нее передающей
стороны в этом случае является разрушающий SKIP, то есть файл отбрасывает-
ся. Пример: conf ig. sys 125 2476327846;
□ M_ERR 7 - фатальная ошибка. Сторона, передавшая M_ERR, завершает сес-
сию. Аргумент (текст, объясняющий причину) пишется в файл протокола.
Binkp передает M_ERR в ответ на неверный пароль. Пример: Incorrect
password;
Таблица 3.4. Сессия между двумя почтовыми FTN-программами по протоколу Binkp
Binkp: вызывающая система посылает Binkp: вызываемая система посылает
M_NUL «SYS...» M_NUL «SYS ...»
M_NUL «ZYZ...» M_NUL «ZYZ ...»
M_NUL «LOC...» M_NUL «LOC ...»
M_NUL «VER ...» M_NUL «VER ...»
M_ADR «2:2/2.2@fidonet» M_ADR «3:3/3.3@fidonet»
M_PWD «password» (ждем пароль от remote)
M_OK «» или M_ERR «Bad password»
(ждем M_OK) M_FILE «file2 200 42342434 0»
M_FILE «filel 100 423424244 0» data
data data
data data
M_EOB (получили filel целиком, подтверждаем)
(получили file2 целиком, подтверждаем) M_GOT «filel 100 423424244»
M_GOT «file2 200 42342434» data
M_EOB
□ M_BSY 8 - передается, если система занята. Аргумент игнорируется прини-
мающей стороной (записывается в лог-файл). Пример: Too many servers
are running already;
□ M_GET 9 - с помощью M_GET делается повторная посылка. Аргументы
M_GET копируют аргументы команды M_FILE, которую желательно полу-
чить от противоположной стороны. Binkp посылает ее как ответ на M_FILE
в том случае, если его не устраивает смещение, с которого началась передача
файла. Пример: config, sys 125 2476327846 100. В текущей реализации
Binkp обрабатывает эту команду следующим образом: по первым полям (имя/
размер/unixtime) определяется, является ли аргумент M_GET текущим пе-
редаваемым для нас файлом (либо файл уже передан, и мы ждем для него
M_GOT), и если это так, делается SEEK на заданное смещение, после чего по-
сылается M_FILE. Для данного примера M_FILE будет иметь аргументы:
.config.sys 125 2476327846 100;
□ M_SKIP 10 - неразрушающий SKIP. Пример строки параметров:
config.sys 125 2476327846.
В табл. 3.4. приведен пример типичной сессии Binkp.
Протокол Binkp широко используется для установления соединений между
Fido-системами с помощью сети Internet, он также часто применяется при раз-
даче Fido-почты в локальной сети. Долгое время бывший стандартом де-факто,
этот протокол в 1999 году получил наконец и формальное описание в виде
проекта стандарта FidoNet - FSP-1011 [3.8]. Если вы имеете доступ к сети
Internet, то использование одной из почтовых программ, поддерживающих со-
единение по Binkp, - самый простой способ подключения к FidoNet через In-
ternet. Подробнее об использовании Internet для передачи почты FidoNet чи-
тайте в главах 10 и И.
Заключение
Материал этой небольшой главы пригодится вам при использовании и настройке
почтовых программ FidoNet, описание которых вы найдете в главе 7, и при изуче-
нии способов проброса Fido-почты через Internet (глава И).
Глава IV
Форматы данных FidolUet
Полиси 4 гласит, что официальный
язык FidoNet - английский. Полиси 4
ошибается. Официальный язык FidoNet -
пакет типа 2.
Lisa Gronke, 1:105/6
FidoNews 12-22/95
В этом разделе мы рассмотрим два основных способа организации данных
FidoNet: MSG-формат письма FidoNet, предназначенный для хранения и про-
смотра, и РКТ-формат почтового пакета, предназначенный для временного хра-
нения при обработке и пересылке. Кроме этих двух базовых форматов, многократ-
но изменяемых и дополняемых на протяжении пятнадцати лет существования
сети, есть и много других, хорошо известных и широко распространенных спосо-
бов хранения данных FidoNet. Однако значение двух первоначальных структур,
MSG- и РКТ-форматов, значительно превосходит все остальные.
Кроме этого, в конце главы описан формат исходящего директория - структу-
ры, имеющей важное значения для понимания принципов функционирования
почтовых программ FidoNet.
Формат MSG - структура хранения писем
FidoNet в файлах *.msg
Хранение писем в файлах с расширением .msg - это самый старый и простой спо-
соб организации базы писем FidoNet, используемой пользователями сети для чте-
ния и написания писем с помощью программ-редакторов сетевой почты. Подав-
ляющее большинство программ FidoNet умеет оперировать с MSG-файлами.
Сейчас, как правило, MSG-формат используется только для хранения личной
почты (нетмейла), хотя бывают и исключения: существует возможность хранить
в *.п^-файлах эхо-письма. На рис. 4.1 представлено окно файловой системы OS/2
Warp, содержащее часть основной базы личных писем стандарта MSG.
Рис. 4.1. Нетмейл-база в формате MSG
Каждое письмо хранится в отдельном файле с расширением .msg и именем,
представляющим собой порядковый номер письма согласно времени его появле-
ния в базе писем: последнее письмо получает следующий по порядку номер.
Внимательный читатель заметил в списке похожих пронумерованных файлов
*.msg и файл без расширения с именем lastread. Это файл-метка, оставленная ре-
дактором писем - по ней программа-редактор определяет, какое письмо было про-
читано последним.
Совершенно очевидно, что оперировать большим количеством файлов-писем
неудобно, имея в виду эффективную программную реализацию операций чтения,
удаления или поиска в базе писем. Поэтому были изобретены более совершенные
способы хранения писем, подробно рассмотренные в главе 8. Тем не менее для
личной почты возможности этого формата достаточны; база личной почты редко
раздувается до размера в десятки тысяч сообщений, как это бывает с базами попу-
лярных эхо-конференций. У MSG-формата есть и достоинства: он прост, поддер-
живается всем программным обеспечением FidoNet и, если не гнаться за скоростью
работы, легко встраивается в пользовательские программы с помощью популяр-
ных бесплатных API.
Приведенное ниже описание формата MSG позаимствовано из стандарта FTS-
0001 (см. табл. 4.1).
Как видно из табл. 4.1, MSG - формат бинарный, то есть в файле письма могут
(и должны!) встречаться нетекстовые символы. Это и хорошо (такой формат ком-
пактен, его легко обрабатывать в программе, он в сущности представляет собой
готовую структуру для языка программирования), и плохо, поскольку текстовый
формат письма является стандартом в Internet (стандарт Internet RFC-822 [2.11]),
текстовый файл просто просматривается с использованием любого текстового
редактора, обрабатывается с помощью скриптовых языков программирования,
вроде REXX или Perl. Попытки перехода на текстовый формат письма в FidoNet
были (например, проект стандарта FidoNet FSC-0007 [4.1]), но не прижились-
изменение требовало слишком большого объема работы от разработчиков про-
грамм для FidoNet.
Курсивом в табл. 4.1 обозначены поля, которые изменялись или добавлялись
за время после опубликования первой версии стандарта. Легко видеть, насколько
значительны эти изменения, но и сеть за это время радикально изменилась: по-
явились зоны, пойнт-адреса и многое другое, чего не существовало, когда основатель
Таблица 4. /. Хранимое сообщение (формат MSG)
Относительный адрес (Offset) Длина поля в байтах Описание поля
dec hex
0 0 36 Имя Отправителя
36 24 36 Имя Получателя
72 48 72 Тема письма
144 90 20 Дата и время
164 А4 2 Число прочтений
166 Аб 2 Узел назначения
168 А8 2 Узел происхождения
170 АА 2 Цена
172 АС 2 Сеть происхождения
174 АЕ 2 Сеть назначения
176 ВО 2 Зона назначения (необязательно)
178 В2 2 Зона происхождения (необязательно)
180 В4 2 Пойнт назначения (необязательно)
182 Вб 2 Пойнт происхождения (необязательно)
184 В8 2 Идентификатор письма, на которое отвечает данное письмо
186 ВА 2 Атрибут письма
188 ВС 2 Следующий ответ
190 BE 222 Текст письма неограниченной длины, завершается нулем
Таблица 4.2. Комментарии к полям стандарта MSG
Наименование поля Назначение поля
fromUserName(36) tollserName(36) subject(72) DateTime Имя отправителя, строка, ограниченная нулем Имя получателя - строка, ограниченная нулем Тема письма - см. ниже раздел «Спецификация файла» Дата и время момента, когда письмо было в последний раз изменено
times Read Число прочтений - сколько раз письмо было прочитано
destNode Узел назначения - куда адресовано письмо
origNode Узел происхождения - откуда письмо отправлено
cost Цена - в наименьших денежных едницах страны происхождения
origNet destNet Сеть происхождения письма Сеть назначения письма
destZone Зона назначения письма
origZone destPoint Зона происхождения письма Пойнт-адрес назначения письма
origPoint replyTo Пойнт-адрес происхождения письма Идентификатор письма, на которое отвечает данное письмо
AttributeWord Атрибуты письма - расшифровку см. ниже в тексте
nextReply Идентификатор письма, которое отвечает на данное письмо
text Текст письма, неограниченной длины, заканчивается нулем
сети и первый разработчик программ Том Дженнингс разослал текстовый файл,
озаглавленный «Внутренние структуры FidoNet» [4.2].
Приведем другой, привычный для программиста вариант записи стандарта
MSG, с английской нотацией полей и с комментариями из FTS-0001 (табл. 4.2,
курсивом выделены отличия от первых версий FTS-0001).
Ниже следуют дополнительные комментарии к некоторым важным полям.
Дата и время
Дата и время - важное поле, особенно учитывая состоявшийся переход через гра-
ницу тысячелетия. Поле DateTime представляет собой строку длиной 20 симво-
лов, например 01 Jan 86 02:34:56. Строка завершается нулем, разделитель
у даты - пробел, у времени - двоеточие.
Используемые обозначения номера дня, номера месяца, года и элементов под-
строки времени стандартны:
□ день: 01, 02, 03...31;
□ месяц: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec;
□ год: 01, 02...85, 86...Э9, 00;
□ часы: 00...23;
□ минуты и секунды: 00...60.
Атрибуты письма
Каждое письмо в FidoNet имеет специальные признаки, называемые атрибутами,
которые характеризуют его назначение. Всего атрибутов 16, поскольку для их хра-
нения в формате MSG выделено два байта , и значение каждого из атрибутов оп-
ределяется тем, установлен ли соответствующий бит в 0 (атрибут отсутствует)
или в 1 (атрибут присутствует).
Соответствие битов двухбайтового поля, называемого в программировании
словом, и названий соответствующих атрибутов, приведено в табл. 4.3 (возраста-
ние номеров битов соответствует их арифметической значимости).
Сисопом при написании письма в редакторе почты могут устанавливаться сле-
дующие атрибуты:
□ Private;
□ Crash;
□ FileAttached;
□ KillSent;
□ HoldForPickup;
□ FileRequest;
□ ReturnReceiptRequest;
Таблица 4.3. Атрибуты письма FidoNet
Бит Название Перевод названия Примечания
0 Private Частное Частное письмо
1 Crash Немедленно, с докачкой Отправить в режиме «Crash»
2 Reed Получено Это письмо получено
3 Sent Послано Это письмо послано
4 FileAttached Прикреплен файл К этому письму прикреплен файл
5 InTransit Транзитное письмо Письмо адресовано другой системе и должно быть послано далее по сети
6 Orphan Сирота Не хватает адреса назначения
7 KillSent Удалить отправив Удалить после отправки
8 Local Местное Письмо создано на данной системе
9 HoldForPickup Удерживать до связи Не отправлять, адресат сам заберет письмо
10 unused Не используется -
11 FileRequest Запрос файла Письмо содержит запрос файла (файлов)
12 ReturnReceiptRequest Запрос уведомления о получении -
13 IsReturnReceipt Уведомление о получении -
14 AuditRequest Запрос уведомления о пути прохождения -
15 FileUpdateReq Запрос на докачку файла -
□ IsReturnReceipt;
□ AuditRequest;
□ FileUpdateReq.
Остальные атрибуты обычно устанавливаются автоматически при написании
или обработке письма:
□ Received;
□ Sent;
□ Local;
□ InTransit;
□ Orphan.
Эхо-письмо может иметь лишь атрибуты Local, Sent И Private. Все остальные ат-
рибуты не имеют смысла при использовании в эхо-почте (хотя поставить их в эхо-
письмо можно).
Число атрибутов, описанных в FTS-0001, оказалось впоследствии совершенно
недостаточным для нужд сети, и в настоящее время список их существенно рас-
ширен применением в качестве стандарта де-факто документа FSC-0053 [4.3],
в соответствии с которым количество атрибутов значительно расширено приме-
нением специальной служебной строки AaFLAGS. Описание расширенных атри-
бутов можно найти в главе 7 и в соответствующем FSC.
Текст письма и служебные строки
Текст письма формально неограниченной длины и заканчивается 0 (нулевым бай-
том). Ограничения на размер текста вводятся программистом на этапе создания
программы. Почти все современное программное обеспечение FidoNet поддержи-
вает размер текста письма по крайней мере в 64 Кбайт, но, чтобы быть уверенным
в отсутствии проблем при прохождении его по сети, лучше всего не посылать со-
общения длиннее 12 Кбайт.
В тексте символ ODh (возврат каретки) отмечает конец параграфа и должен
быть сохранен. Все символы перевода строки (0Ah) должны быть проигнориро-
ваны; система, отображающая письмо, сама выравнивает строки в соответствии
со своими установками длины строки или размера видимой области экрана.
Если первый символ параграфа (то есть либо первый символ всего теста, либо
символ непосредственно следующий за символом «возврат каретки» - ODh) есть
Olh (обозначается как Ла или Control-а), то эта строка содержит дополнитель-
ную техническую информацию о данном письме. Такая строка не должна отобра-
жаться без специального запроса пользователя. Это уже упоминавшаяся в преды-
дущих главах кладж-строка (cludge-line).
Соглашения относительно служебных строк следующие:
□ они начинаются с 74а (код Olh);
□ они заканчиваются следующим символом «возврат каретки»;
□ они начинаются с ключевого слова и следующего за ним двоеточия;
□ каждое ключевое слово должно соответствовать своей программе, это ее
«след» в данном письме;
□ вслед за ключевым словом и двоеточием идет информация от соответствую-
щей программы.
В FTS-0001 специфицированы следующие ключевые слова:
□ ТОРТ сномер пойнта> - пойнт-адрес отправителя;
□ FMPT <номер пойнта> - пойнт-адрес отправителя;
□ INTL <назначение z:n/n> спроисхождение z : п/п> - используется
при межзональной адресации.
Примеры кладж-строк уже приводились ранее в главах 1 и 2. Использование
кладжей для анализа писем личной почты и эхо-почты подробно описано в гла-
вах 7 и 8.
Спецификация файла
Поскольку FidoNet зародилась как сеть BBS, то с самого начала в технологии об-
щения присутствовали операции с файлами (обмен файлами - один из основных
сервисов почти любой BBS). В FidoNet можно послать файл по сети, просто при-
крепив его к письму, запросить какой-либо файл с другой системы, позвонив на
нее и передав письмо специального формата (FileRequest - «запрос файла»). Для
обозначения этих операций используется поле атрибутов.
Если один из трех атрибутов: «прикреплен файл» (FileAttached), «запрос фай-
ла» (FileRequest) или «запрос на дополнение файла» (FileUpdateReq) встречает-
ся среди атрибутов письма, то это означает, что поле SUBJECT (тема) письма дол-
жно быть проинтерпретировано как список спецификаций файлов, которая может
включать метасимволы (wildcards) и другие зависящие от типа операционной
системы данные.
Список файлов представляет собой строку символов, состоящую из элементов,
обособленных символами-разделителями (пробел или запятая), и завершающуюся
кодом 0 Oh. Каждый из элементов списка представляет собой спецификацию фай-
ла (в контексте FTS-0001 это спецификация файла операционной системы СР/М
или MS DOS, однако каких-либо ограничений на правила записи не накладыва-
ется, предполагается, что она соответствует принятым для данной операционной
системы правилам).
На рис. 2.7 в главе 2 приведен пример письма, к которому прикреплен файл.
Если отправить это письмо, то одновременно с ним отправится и файл. Обычно
такие пересылки производятся директом, позвонив непосредственно на систему
назначения, но использовать и систему маршрутизации почты, хотя по правилам
пересылка файлов в FidoNet не является обязательной сетевой услугой и достав-
ка файлов не гарантируется, в отличие от доставки личной почты. Более подроб-
но сетевой этикет в части передачи файлов по сети был освещен в главах 1 и 2;
некоторую информацию на этот счет можно также найти в главах 7 и 9.
База писем формата MSG
Формат письма MSG создан с целью упростить организацию из отдельных фай-
лов-писем структуры базы писем, позволяющей составлять списки дискуссий,
производить поиск и удаление. Для этого предназначены поля DATETIME,
REPLYTO, NEXTREPLY, TIMESREAD. Несмотря на медленную работу, база
MSG проста и надежна - ее надежность фактически определяется надежностью
файловой системы используемой ОС.
Текстовый или бинарный?
Хранимые письма формата MSG имеют бинарный заголовок. Так сложилось ис-
торически, так есть до сих пор, и, видимо, такое положение сохранится и впослед-
ствии. К сожалению, бинарный формат не обладает гибкостью текстового формата.
Его трудно расширить или дополнить, сохраняя совместимость с уже написанным
программным обеспечением. Малейший сдвиг данных в заголовке письма портит
всю контрольную информацию. Иное дело текстовый формат. Обычно он задает-
ся таким образом, чтобы длину строки и количество разделителей между блока-
ми информации можно было варьировать. Поэтому все дополнения в формате
MSG, которые оказались необходимы, были помещены непосредственно в текст
письма в виде контрольных строк, начинающихся с кода Olh. Это так называе-
мые кладжи. Они привнесли в формат MSG гибкость и удобство текстового фор-
мата, и в настоящее время почти полностью заместили информацию из бинарно-
го заголовка письма.
Действует приоритет кладжей над бинарным заголовком: информация, встре-
чающаяся в кладжах, имеет преимущество над той, что есть в заголовке письма.
Подводя итог, можно сказать, что один из основных типов данных FidoNet име-
ет на самом деле смешанный, бинарно-текстовый формат, возникновение которо-
го обязано эволюции FidoNet, и является вынужденным решением, появившимся
как попытка, с одной стороны, сохранить совместимость с начальным бинарным
форматом, с другой, ввести в него достаточную гибкость, способность изменяться
и дополняться.
Дополнительные сведения о формате MSG можно найти в главе 7.
Формат РКТ - структура временного хранения
писем FidoNet в файлах *.pkt
Рассмотренный выше стандарт MSG используется для создания базы писем и их
долговременного хранения. В отличие от него назначение РКТ-формата заключа-
ется во временном хранении писем при их пересылке на другую систему. Часть
информации, существенной для формата MSG (все, что касается ссылок на дру-
гие письма), из формата РКТ исключена. Еще одним важным отличием РКТ от
MSG является то, что в один РКТ-файл может быть упаковано много писем.
В MSG-базе каждое письмо представлено отдельным файлом. Файл *.pkt и фор-
мат хранящихся в нем упакованных писем подробно описаны в базовом стандар-
те FidoNet FTS-0001, это так называемый «пакет тип 2».
Наиболее широко используемым стандартом де-факто является тип 2+, описа-
ние которого содержится в проекте стандарта FSC-0039 [4.4]. Можно применять
и прежний тип 2, однако на практике программное обеспечение, имеющее распро-
странение в FidoNet, поддерживает по умолчанию почтовый пакет стандарта 2+.
Кроме этих двух распространенных стандартов используется также и усовер-
шенствованный формат пакета с номером версии 2.2, описанный в FSC-0048 [4.5].
Основная идея вариантов 2+ и 2.2 - исправление недостатков стандарта типа 2
при сохранении обратной совместимости. К счастью, исходный формат, описан-
ный в FTS-0001, имеет достаточные резервы и позволяет реализовать это без боль-
ших затруднений. Существуют проекты стандартов на формат почтового пакета,
не совместимые с FTS-0001 - это документы FSC-0045, FSC-0065, FSC-0066,
FSC-0079, FSC-0081, FSC-0082, однако распространения описанные в них фор-
маты не получили.
Все *.pkt-файлы имеют следующую структуру:
□ заголовок пакета (58 байт);
□ упакованные письма (0 или больше);
□ псевдописьмо (2 байта 00), служащее признаком конца файла *.pkt.
Таким образом, размер пустого пакета равен 60 байт.
Каждое упакованное в пакете письмо представлено следующей структурой:
□ заголовок письма, который начинается с признака типа письма - 2 байта
(02 00);
□ шесть полей фиксированной длины (каждое по 2 байта);
□ одна строка фиксированной длины 20 байт, завершенная нулевым байтом;
□ три строки переменной длины, завершенные 0 (всего максимум 144 байт). На
этом заголовок завершается;
□ текст письма неограниченной длины, завершенный нулевым байтом.
Вся дополнительная контрольная информация, отличающая, например, эхо-
письмо от нетмейл-письма, рассматривается с точки зрения структуры пакета как
часть текста письма. Обычно пакет содержит либо нетмейл-письма, либо эхо-поч-
ту, но не допускает то и другое одновременно.
Настоящий текст эхо-письма начинается со строки area: наименование
эхи> и заканчивается стандартными для эхо-письма строками ORIGIN, SEEN-BY
и PATH, подробно описанными в главе 8.
Пакеты эхо-почты, как правило, упаковываются перед отправкой в файлы с рас-
ширениями, наименование которых связано с днями недели (МО - понедельник
(Monday), TU - вторник (Tuesday) и т. д.). Для упаковки используется один из
распространенных архиваторов, чаще всего PKZIP или RAR.
Пакеты с личной почтой (нетмейлом), как правило, не упаковываются, так как
их необходимо отделить от потока эхо-почты. В этом случае они отправляются
перед эхо-почтой (сортировкой почты при передаче занимается сама почтовая
программа), и таким образом обеспечивается правильное соответствие важности
передаваемой информации и последовательности ее отправки. Нетмейл считает-
ся более важным, чем эхо-почта, поскольку личная почта уникальна, а эхо-почта
продублирована на множестве систем сети.
Более подробно о формировании выходного директория почтовой программы
можно прочитать в следующем разделе.
В табл. 4.4-4.6 приведена точная структура пакетов типа 2.0, 2+, и 2.2. Эта ин-
формация взята из FTS-0001 [2.5], FSC-0039 [4.4], и FSC-0048 [4.5].
Таблица 4.4. Структура упакованного для отправки письма
(по материалами FTS-0001)
Наименование поля Размер поля в байтах Комментарии
PktType 2 Тип пакета, старый тип 1 устарел, значение поля =[02 00]
origNode 2 Узел происхождения письма
destNode 2 Узел назначения письма
origNet 2 Сеть происхождения письма
destNet 2 Сеть назначения письма
AttributeWord 2 Атрибуты письма
cost 2 Цена в минимальных денежных страны происхождения
DateTime 20 Дата и время, когда в последний раз было произведено
изменение текста письма
toUserName 36 Имя адресата
fromUserName 36 Имя отправителя
subject 72 Тема письма
text Неограничен© Текст письма
Таблица 4.5. Структура почтового пакета (файла *.pkt) типа 2.0
(по материалам FTS-0001)
Наименование поля Размер поля в байтах Тип Ожидаемые значения Комментарии
OrgNode 2 Word 0-65535 Номер узла отправителя
DstNode 2 Word 0-65535 Номер узла получателя
Year 2 Int 1922-2??? Год создания пакета
Month 2 Int 0-11 Месяц создания пакета (0 - январь)
Day 2 Int янв.31 День создания пакета
Hour 2 Int 0-23 Час создания пакета
Min 2 Int 0-59 Минута создания пакета
Sec 2 Int 0-59 Секунда создания пакета
Baud 2 Int - Скорость в бодах (не используется)
PktVer 2 Int Всегда=2 Версия пакета
OrgNet 2 Word 1-65535 Номер сети происхождения
DstNet 2 Word 1-65535 Номер сети назначения
PrdCodL 1 Byte 1-255 Код продукта FTSC (первая часть)
SerialNo 1 1-255 Byte Серийный номер
Password 8 Char A-Z,0-9 Пароль пакета (в некоторых реализациях)
Таблица 4.5. Структура почтового пакета (файла *.pkt) типа 2.0
(по материалам FTS-OOO1) (окончание)
Наименование поля ? Размер поля в байтах Тип Ожидаемые значения Комментарии
OrigZone 2 Int 1-65535 Зона происхождения
DestZone 2 Int 1-65535 Зона назначения
Filler 20 - - Зарезервировано
Packed Messages - - - Ноль или больше упакованных писем
Таблица 4.6. Структура почтового пакета типа 2+ (по материалами FTS-0039)
Наименование поля ! Размер поля в байтах Тип Ожидаемые значения Комментарии
OrgNode 2 Word 0-65535 Номер узла отправителя
DstNode 2 Word 0-65535 Номер узла получателя
Year 2 Int 19??-2??? Год создания пакета
Month 2 Int 0-11 Месяц создания пакета (0 - январь)
Day 2 Int янв.31 День создания пакета
Hour 2 Int 0-23 Час создания пакета
Min 2 Int 0-59 Минута создания пакета
Sec 2 Int 0-59 Секунда создания пакета
Baud 2 Int - Скорость в бодах (не используется)
PktVer 2 Int Всегда=2 Версия пакета
OrgNet 2 Word 1-65535 Номер сети происхождения
DstNet 2 Word 1-65535 Номер сети назначения
PrdCodL 1 Byte 1-255 Код продукта FTSC (первая часть)
PVMajor 1 Byte 1-255 Код продукта FTSC /вторая часть)
Password 8 Char А-40-9 Пароль пакета
QOrgZorie 2 Int 1-65535 Зона происхождения (для ZMailQ, QMail)
QDstZone 2 Int 1-65535 Зона назначения (для ZMailQ, QMail)
Filler 2 Byte - Зарезервировано
CapValid 2 Word Битовое поле Проверочная маска совместимости
PrdCodH 1 Byte 1-255 Код продукта FTSC (старший байт)
PVMinor 1 Byte 1-255 Код продукта FTSC (младший байт)
CapWord 2 Word Битовое поле Маска совместимости
OrigZone 2 Int 1-65535 Зона происхождения
DestZone 2 Int 1-65535 Зона назначения
OrigPoint 32 2 Int 1-65535 Пойнт происходения
DestPoint 34 2 Int 1-65535 Пойнт назначения
ProdData 36 4 Long любые значения Определяется программой
PktTerm 2 Word 0 Значения, завершающее заголовок
пакета
Таблица 4.7. Структура маски совместимости почтового пакета типа 2+
(по материалами FTS-0039)
Поддерживаемые системой типы пакетов Маска совместимости: типы пакетов FTSC
Старшие биты Младшие биты
и 16 15 14 13 12 И 10 9 8 7 6 5 4 3 2 -
2+, 3, and 7 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1
2+z 3, and 5 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1
2+ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
Каменный век:) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Таблица 4.8. Структура почтового пакета типа 2.2 (по материалами FSC-0048)
Наименование поля Размер поля в байтах Тип Ожидаемые значения Комментарии
OrgNode 2 Word 0-65535 Номер узла отправителя
DstNode 2 Word 0-65535 Номер узла получателя
Year 2 Int 1922-2??? Год создания пакета
Month 2 Int 0-11 Месяц создания пакета (0 - январь)
Day 2 Int янв.31 День создания пакета
Hour 2 Int 0-23 Час создания пакета
Min 2 Int 0-59 Минута создания пакета
Sec 2 Int 0-59 Секунда создания пакета
Baud 2 Int - Скорость в бодах (не используется)
PktVer 2 Int Всегда=2 Версия пакета
OrgNet 2 Word 1-65535 Номер сети происхождения (-1 для пакета от пойнта)
DstNet 2 Word 1-65535 Номер сети назначения (-1 для пакета от пойнта)
ProductCode / Byte 1-255 Код продукта FTSC
SerialNo 1 Byte 1-255 Двоичный серийный номер или нуль
Password 8 Char A-Z,0-9 Пароль пакета (завершен нулем)
OrgZone 2 Word 1-65535 Зона происхождения (как в QMail)
DstZone 2 Word 1-65535 Зона назначения (как в QMail)
AuxNet 2 Word 1-65535 Содержит номер
сети происхождения,
если пакет происходит
от пойнт-адреса
Таблица 4.8. Структура почтового пакета типа 2.2
(по материалами FSC-0048) (окончание)
Наименование поля Размер поля в байтах Тип Ожидаемые значения Комментарии
CWvalidCopy 2 Word Битовое поле Проверочная копия маски совместимости
ProductCode 1 Byte 1-255 Код продукта FTSC (старший байт)
Revision программы 1 Byte 1-255 Номер версии
CapWord 2 Word Битовое поле Маска совместимости
OrigZone 2 Int 1-65535 Зона происхождения
DestZone 2 Int 1-65535 Зона назначения
OrigPoint 2 Int 1-65535 Пойнт происходения
DestPoint 2 Int 1-65535 Пойнт назначения
ProdData 4 Long любые значения Зависит от программы
Packed messages - - - Ноль или больше упакованных писем
Как видно из структуры, приведенной в табл. 4.5, для возможных расширений
в заголовке пакета зарезервировано 20 байт, что вполне достаточно. Используя
это пространство, были разработаны варианты 2+ и 2.2, структура которых пока-
зана в табл. 4.6-4.8.
В структуре, описанной в FSC-0039, в заголовок пакета было введено новое
поле, имеющее битовую структуру и называемое маской совместимости
(compatibility mask). Если маска совместимости (табл. 4.6 и 4.7) установлена в 0,
то предполагается, что пакет имеет старый тип 2. Любая ошибка в обработке маски
совместимости также означает, что этот пакет должен быть обработан как тип 2.
Маска дает ценную информацию о типе пакета и позволяет и дальше расширять
возможный набор форматов пакетов.
Поле «U» маски (табл. 4.7) отвечает за определение совместимости почтовой
программы с Internet-стандартом на формат почтового сообщения RFC-822.
В табл. 4.6 курсивом выделены расширения относительно FTS-0001.
С точки зрения современного состояния сети, пакет 2+, описанный в FSC-0039,
имеет два недостатка:
□ важнейшим элементом этого формата является маска совместимости - поле
битовых переключателей, определяющее тип обрабатываемого пакета. Одна-
ко старые обработчики могут обнулять это поле и таким образом заставлять
обрабатывать весь пакет как тип 2.0. Для преодоления этого недостатка в вер-
сии 2.2 была введена дополнительная копия маски совместимости;
□ несмотря на то, что формат заголовка пакета 2+ содержит информацию о 4D ад-
ресе системы назначения (зона: сеть/узел. пойнт), она не может быть исполь-
зована обработчиками, поддерживающими только стандарт FTS-0001, и в этом
случае пакет от пойнта будет выглядеть как пакет от узла, что является ошибкой.
В версии 2.2 использована технология, позволяющая устранить этот недочет
(обратите внимание на комментарии к значениям полей OrgNet и DstNet
в табл. 4.8).
В табл. 4.8 курсивом помечены отличия от базового стандарта FTS-0001, а по-
лужирным шрифтом - от проекта стандарта FSC-0039.
Почтовая очередь и выходной директорий
системы FidoNet (Outbound directory)
Одним из важных элементов устройства почтовых программ FidoNet (и любых
почтовых программ вообще) является понятие почтовой очереди (mail queue).
Многие почтовые программы FidoNet значительную часть времени работы зани-
маются обслуживанием (сканированием, формированием, дополнением) почто-
вой очереди. Более подробно этот процесс освещен в главе 7, там же представлены
структуры данных, которые используются при формировании очереди - это так
называемый исходящий директорий (mailer outbound).
В FidoNet принято организовывать информацию, подготовленную к отправке,
в виде файловой структуры, состоящей из дерева (одного или больше) директо-
риев, содержащих файлы, подготовленные к передаче и сопровождающие их ин-
формационные файлы. Есть несколько отличных друг от друга схем организации
таких структур, но основных всего две - АМА (Arcmail-Attach) и BSO или Bink-
style (Bink-Style Outbound).
Под Attach (прикрепление) понимается активное использование в этой схеме
традиционного для FidoNet прикрепления файла (файлов) к письму. Как прави-
ло, исходящий АМ A-директорий формирует сама почтовая программа, обычно он
создается при ее запуске и затем время от времени «перестраивается». Для про-
смотра файлового содержимого почтовой очереди АМА-мейлера удобно исполь-
зовать возможности какой-либо многозадачной операционной системы. Стоит
отметить, что как такового стандарта на АМА-способ не существует, и каждая
почтовая программа формирует AMA-outbound по своему усмотрению. Поэтому
использовать почтовый директорий АМА-типа как средство коммуникации не-
скольких различных почтовых программ не получается.
Bink-style outbound был впервые введен в употребление авторами почтовой
программы Binkley Term Винсом Перриелло (Vince Perriello) и Бобом Гартманом
(Bob Hartman). В Bink-style директории вся информация об адресате файла
и способе его отправки зашифрована в названии самого файла и названии дирек-
тория, где он лежит. Bink-style outbound не удаляется при выходе из почтовой
программы и разработан так, что может служить удобным средством коммуника-
ции для нескольких почтовых программ, сосуществующих на одной системе. По
традиции использование BSO требует отдельной программы - упаковщика по-
чты, так как BSO-мейлеры не содержат, как правило, процедуры формирования
исходящего директория в отличие от АМА-почтовых программ.
Почти все современные почтовые программы FidoNet поддерживают либо АМА,
либо Bink-style outbound. Из популярных в R50 мейлеров примером АМА-мейлера
может служить FrontDoor всех версий, некогда бывший самой распространенной
почтовой программой в R50. Binkley-style программы - это, например Bink/+
Сергея Терехова, The Brake! Джона Гладких, Bink-style поддерживает и програм-
ма для проброса Fido-почты через Internet - Binkd. Очень популярная почтовая
программа Андрея Елкина T-Mail поддерживает оба способа организации исхо-
дящего директория, можно сконфигурировать эту программу либо для работы
в АМА, либо в BSO.
Архивированная почта (Arcmail)
В начале существования FidoNet информация между узлами сети передавалась
в неупакованном виде. Впоследствии, когда появилась эхо-почта, оказалось, что
объем ее быстро вырастает до таких масштабов, что передавать ее в неупакован-
ном виде - значит, обеспечить сети скорую смерть от перегрузки. Нужно было
выбрать тот или иной механизм архивирования почты и способ именования по-
лучающихся файлов.
Что касается архивирования, то тут все было просто: нужно было взять одну из
популярных бесплатных программ-архиваторов (в то время это был ARC, но
в дальнейшем использовались и LZH, и ZOO, и все другие известные архиваторы,
а самым популярным был и остается PKZIP).
Как это часто бывает, стандарт был введен де-факто удачной программной раз-
работкой - ArcMail 0.6 Тома Хендерсена (Tom Henderson). С его легкой руки
и отправились гулять по FidoNet забавные наименования файлов вроде
9d9dlcd3.fr9 или 131bflf0.mob. Эта популярная утилита делала очень простую, но
полезную работу - она искала в нетмейл-фолдере все письма, адресованные како-
му-либо одному узлу, упаковывала их все в *.pkt файлы, которые затем архивиро-
вала в один файл, удаляла все отправленные письма и создавала всего одно пись-
мо на этот узел, прикрепляя к нему созданный архивный файл. Суть способа
именования файлов-архивов заключается в следующем. Файлы *.pkt, один или
больше, архивируются в так называемые archived mail bundle (архивные почтовые
пакеты). Имя файла архива можно представить как
nnnnmmmm.dd#
где nnnn есть разность между сетью происхождения пакета и сетью назначения
(вспомним, что сеть в адресе FidoNet представлена четырехзначным числом),
а шштш - между номером узла, отправившего пакет, и номером узла-получателя.
Расширение же содержит информацию о дне недели создания файла, кодируемую
двумя символами:
□ МО - понедельник;
□ TU - вторник;
□ WE - среда;
□ TH - четверг;
□ FR - пятница;
□ SA - суббота;
□ SU - воскресенье.
За обозначением дня недели следует порядковый номер от 0 до 9. Таким обра-
зом, возможное количество пакетов для одного узла ограничивалось десятью в день.
Сейчас используются различные усовершенствованные вариации оригиналь-
ного ArcMail-способа именования, сводящиеся в основном к следующему:
□ в качестве последнего символа расширения используются не только цифры
0-9, но и буквы A-Z. Это позволяет увеличить «дневную норму» файлов для
одного узла с 10 до 36;
□ вместо разности номеров сетей и узлов отправителя и получателя, как описа-
но выше, используются просто номера сетей/узлов - так проще. Все равно
эта информация никак не используется, все данные берутся из самих почто-
вых пакетов.
Использование ArcMail-схемы именования файлов закреплено в стандарте
FidoNet FTS-0004, где описывается эхо-почта [2.12]. Есть также предложения усо-
вершенствовать схему именования, введя в нее номер зоны и увеличив число воз-
можных пакетов в день на каждый узел до 99 (см., например, FSC-0024 [4.6]), но
они пока не используются - видимо, хватает того, что есть.
Почтовый директорий типа Arcmail-Attach (АМА outbound)
Директорий Arcmail-Attach формируется на основании базы личных писем в фор-
мате *.msg, описанном выше. Упаковщик, входящий в состав почтовой програм-
мы, просматривает все неотправленные письма (то есть, у которых не установлен
атрибут SENT) и преобразует их в формат РКТ. Далее будем предполагать, что
речь идет о некогда популярном АМА-мейлере FrontDoor. Для каждого РКТ-фай-
ла, упакованного для определенного адресата, создается сопровождающий его
информационный файл с тем же именем и с расширением *.fdc, например, надис-
ке автора в исходящем АМА-директории в данный момент есть файлы:
□ 000cb2db.fdc - информационный файл (35 байт);
□ 000cb2db.pkt - пакет с почтой (1938 байт).
Весь набор подготовленных к отправке файлов состоит из таких пар. Вместе
с файлами *.pkt отправляются и другие прикрепленные к ним файлы, если тако-
вые найдутся, например файлы с архивированной почтой и т.п.
И FC/2: C:\FD\PACKET _____________________________ I ° Ы
jVieu: C:\FD\PfiCKET\0011C227.FDC СР866 100.0%;
00 00 00 00 80 ОО ОО 00
90 01 J 04 00 00 00 J 00 00
$0000 К 02 00 В9 13 ОС 00
$0010 00 00 00 00 I 00 00
00020 00 00 40 '
Рис. 4.2. Просмотр содержимого контрольного файла *.fdc почтового пакета,
подготовленного к отправке в исходящем АМА-директории почтовой программы
FrontDoor
Если заглянуть внутрь *.fdc файла с помощью любой программы, позволяю-
щей просматривать содержимое бинарных файлов, то увидим картину, представ-
ленную на рис. 4.2.
Первые 8 байт представляют собой номер зоны (2), сети (B913h -в десятичном
представлении это 5049), узла (0Ch=12) и пойнта (00). Получается 2:5049/12.0 -
адресат пакета, соответствующего данному информационному файлу. В случае
прикрепленного к письму файла информационный файл содержит его полную
спецификацию.
Достоинства и недостатки режима АМА
Способ АМА-Attach имеет ряд преимуществ:
□ он не требует применения отдельного упаковщика почты;
□ очередь может просматриваться, дополняться и изменяться самой почтовой
программой в процессе ее работы, что удобно для узлов, работающих под уп-
равлением однозадачных операционных систем;
□ обеспечивается очень высокий уровень гибкости управления очередью и воз-
можность реализации сложных схем маршрутизации непосредственно из по-
чтовой программы;
□ без дополнительных усилий осуществляется передача файлов по сети.
Особенно заметно различие АМА и Bink-style при переключении мейлера T-Mail
с режима АМА на Binkley. Сразу теряют смысл почти все правила маршрутиза-
ции - их заменяет настройка маршрутизации внешнего упаковщика.
К недостаткам АМА относят:
□ высокую загрузку почтовой программы работой по перепаковке почты, что
при большом объеме просматриваемого каждый раз нетмейл-директория за-
нимает много времени, и некоторые программы, например тот же FrontDoor,
в это время оказываются недоступны для установления соединения;
□ невозможность использования одного AMA-outbound несколькими различ-
ными программами.
Последнее, на мой взгляд, очень существенный недостаток, и я не рекомендую
использовать АМА-программы, если в ваши планы входит организация узла,
предоставляющего свои ресурсы большому количеству внешних пользователей.
Почтовый директорий типа Binkley Term
(Binkley-style outbound)
Созданием выходного почтового директория типа Binkley заведует отдельная от
мейлера программа - упаковщик почты. Именно он «знает» когда, на какой адрес
и через кого нужно отправлять почту, и он же осуществляет маршрутизацию. Сама
почтовая программа в случае использования Bink-style представляет собой только
коммуникационную подсистему, не имеющую дела с маршрутизацией сообщений.
Вся информация об адресате кодируется наименованием файла или директория.
Проще всего показать это на примере. Пусть наименование корневого директория,
Рис. 4.3. Дерево директориев
для Bink-style outbound
содержащего все остальные поддиректории
и файлы, подготовленные для отправки, будет
С: \FIDO\FIDOUT. В нем находятся директо-
рии, содержащие информацию для адресов во
второй, третьей и седьмой зонах FidoNet (для
остальных зон информации пока нет). Тогда
полная структура будет выглядеть так, как это
изображено на рис. 4.3.
Как видно из рисунка, номер зоны кодиру-
ется расширением в названии соответствую-
щего директория, кроме основной зоны, к ко-
торой принадлежит данная система. Почта для
пойнтов укладывается в директорий с расши-
рением .pnt и именем, первые четыре символа
которого представляют собой номер сети
в шестнадцатеричном коде, а остальные четы-
ре - номер узла. Таким образом, в приведенном на рис. 4.3 примере С: \FIDO\
OUTBOUND \ OUTBOUND \13b9000c.pnt содержит почту и файлы для пойнтов узла
2:5049/12, а директорий С : \FIDO\OUTBOUND\OUTBOUND\ со всеми поддиректо-
риями - почту для всей второй зоны сети FidoNet.
Правила именования файлов
Поддиректории содержат подготовленные для отправки файлы и сопровождаю-
щие их информационные и контрольные файлы. В отличие от AMA-style, все ин-
формационные файлы в Binkley-style имеют простой текстовый формат. Часть
информации об отправляемых файлах закодирована в имени и расширении ин-
формационных и контрольных файлов. Рассмотрим основные правила оформле-
ния различных типов посылаемой информации и сопровождающих информаци-
онных файлов. Для этого заглянем в исходящий директорий и посмотрим, какие
файлы там лежат. Вот список файлов исходящего директория на системе автора
(в сокращении, см. рис. 4.4).
Обратите внимание на имена и расширения файлов. Файлы с расширениями,
начинающимися на МО, TU, WE, TH, FR, SA или SU - это пакеты с архивиро-
ванной почтой, правила именования которых описаны выше в этой главе. Расши-
рение остальных файлов определяет тип файла (второй и третий символ расши-
рения) и способ его отправки (первый символ расширения). Используются
следующие символы для указания способа отправки:
□ «С» - отправка по способу CRASH, то есть немедленно, с докачкой нетмейл-
пакетов;
□ «I» IMMEDIATE - немедленно;
□ «D» DIRECT - звонок напрямую, без использования системы маршрутиза-
ции почты FidoNet;
□ «F» или «N» NORMAL - отправка обычным способом;
□ «Н» HOLD - не отправлять информацию, пока адресат сам не позвонит и не
заберет ее.
MtOUTBOUHD - Icon View
О... !□ □ □ “О □ □ О
99367022.WE0 99367022.TU0 99367022.5U1 99367022.MOO 91EEE371.WE3 91ЕЕЕ371.ТН0 902С8946.ТН2 7BCEFD13.TH9 7А0С9724.ТН5
DD DDDDDDD
7956B06A.We4 7956B06A.We3 7956B06A.We2 7956B06A.We1 7956B06A.We0 7956B06A.TU7 7956B06A.TU6 7956B06A.TU5 7956B06A.Tu4
DDDDDDDDD
7956B06A.TU3 7956B06A.TU2 7956B06A.TU1 7956B06A.TU0 7956B06A.Tha 7956B06A.Th9 7956B06A.Th8 7956B06A.SU4 7956B06A.5U3
DDDDDDDDD
7956B06A.SU2 7956B06A.Su1 7956B06A.Su0 7956B06A.Sa6 7956B06A.Sa5 7956B06A.Sa4 7956B06A.Sa3 7956B06A.Sa1 7956B06A.5a0
D D D □ □ D D D D
7956B06A.MO5 7956B06A.MO4 7956B06A.Mo3 7956B06A.Mo2 7956B06A.MO1 7956B06A.MO0 7956B06A.Fr6 7956B06A.Fr5 7956B06A.Fr4
DDDDD D DOD
7956B06A.Fr3 7956B06A.Fr2 7956B06A.FH 7956B06A.Fr0 7894DA5D.WE3 7894DA5D.WE2 7894DA5D.TH0 784A297D.TH7 74C135BC.TH0
D D D D D D 0
718E2339.TH0 5DF74E36.TH8 4FF59D14.TH6 3BE72BFA.THK 3A2541CD.TU5 3670AE2C.TH3 3670AE2C.TH2
D D □ D D D D
32FDD29E.TH2 317906F0.TH2 30BB6CC7.TH2 2D0AADA5.PKT 2CDC52EF.PKT 2CDC4630.PKT 2CDC30F1.PKT
D □ D □ D D D □
2CDC2214.PKT 2CDC184B.PKT 2CDC1257.PKT 2CDC0343.PKT 2CDBC7EB.PKT 2A6A7BC6.PKT 2A668DFA.pkt29B080F0.PKT
29B080E5.PKT 13E50020.CLO 13e5001b.tr) 13d80050.try 13C7003C.HUT 13C7003C.HLO 13B92069.HUT 13B913B9.HUT 13B90B0E.HUT
1ДВ9П627.НиТДЗВ9П5ПСН11Т 13R90474.H1JT 13R903F7.HUT 13R9nO9R.HUT_ 13В9ПП8П.О1ГГ 13В9ЛП8П.Е1л 13В9ПП76ЛШ 13h90073.trv
XI'I >.
Рис. 4.4. Список файлов в исходящем Bink-style директории для второй зоны FidoNet
Как видно из описания, возможные способы отправки (flavor - «флейворы»)
соответствуют основным атрибутам писем и формируются исходя из того, какие
атрибуты письма были установлены, и из конфигурации почтовой программы для
адресата, которому предназначены данные файлы.
Имена файлов, которые создает упаковщик в исходящем директории (как ин-
формационных файлов, так и других, например, файлов с личной почтой или кон-
трольных файлов, сигнализирующих о занятости данного узла) всегда оформля-
ются как шестнадцатеричное представление номера сети и номера узла (как
описано в предыдущем разделе).
Неупакованная сетевая почта (netmail)
В отличие от режима АМА, где неупакованная сетевая почта лежит в исходящем
директории в виде файлов с расширением .pkt, в режиме Binkley нетмейл имеет
расширение .?ut и не нуждается в дополнительных контрольных файлах для от-
правки (далее в тексте знак «?» означает знакоместо, которое должно быть заме-
нено на символ флейвора). Нетмейл, отправляемый с флейвором NORMAL, име-
ет расширение .out или .nut. Формат файлов с нетмейлом - самый обычный РКТ,
описанный выше в этой главе, и при отправке файл переименовывается мейлером
в РКТ-файл со случайным именем.
Информационные и контрольные файлы
Тип контрольных и информационных файлов определяют последние два или все
три символа расширения. Всего может быть четыре типа информационных и кон-
трольных файлов, они описаны ниже.
Файлы LO - списки отсылаемых файлов. .?1о - это информационные файлы,
содержащие списки файлов, которые должны быть отправлены на адрес, заданный:
□ местоположением файла в данном директории (используется для определе-
ния наименования домена, номера зоны и адреса босса, если это пойнт-адрес);
□ именем файла (номер сети и узла).
Например, информационный файл, содержащий сведения об эхо-почте и фай-
лах, адресованных узлу 2:5020/240, будет лежать в директории (рис. 4.3)
D: \FIDO\FIDOUT\OUTBOUND и называться, к примеру, 139c00f0.dlo (для случая
отправки директом).
Информационные файлы содержат список отправляемых на данный адрес фай-
лов с указанием полного пути к ним в формате используемой операционной сис-
темы. На запись информации об одном файле выделяется одна строка. Так, упо-
мянутый выше файл D:\FIDO\FIDOUT\OUTBOUND\139cOOf0.dlo может
содержать следующие строки:
#С:\FIDO\FIDOUT\OUTBOUND\5f4е9379.tha
#С:\FIDO\FIDOUT\OUTBOUND\5f4е9379.tuO
#С:\FIDO\FIDOUT\OUTBOUND\5f4е9379.frO
#С:\FIDO\FIDOUT\OUTBOUND\5f4е9379.moO
Первый символ «#» в каждой строке - это модификатор, определяющий
дополнительные правила отсылки файла. Всего модификаторов может быть три
(четыре, если считать модификатором его отсутствие):
□ «#» - отсылка по способу «обрезать» (Truncate). Полностью переданный
в режиме TRUNCATE файл даст в результате на системе-отправителе файл
с тем же именем, что и исходный, но нулевой длины;
□ «Л» - отсылка по способу KILL/SEND - посланный файл удаляется;
□ «~» - игнорировать эту строку;
□ отсутствующий модификатор означает распоряжение не трогать исходный
файл после передачи.
Файлы REQ - файловые запросы. Файлы REQ содержат список запрашивае-
мых файлов, по одному в строке. Такой формат соответствует правилам запроса
файла WaZOO, описанным в следующей главе. Например, если мы хотим запро-
сить с удаленной системы файлы nodelist.* и pntlist.ndl, то файл REQ будет со-
держать строки:
nodelist.*
pntlist.ndl
Файлы-семафоры (BSY и CSY). Контрольные файлы-семафоры с расшире-
нием .bsy (от англ, busy - «занят») имеют важное значение для использования
исходящего почтового директория в разделяемом режиме, когда информацией из
него пользуются несколько программных процессов. Это могут быть несколько
копий одной программы, запускаемых под управлением многозадачной операци-
онной системы для организации многолинейного узла, или несколько различных
почтовых программ, использующих один исходящий директорий. Файл *.bsy
с именем и местоположением, определяющим его принадлежность к тому или
иному адресу, означает, что данный адрес уже занят обменом почтой с одним из
запущенных процессов и что пытаться организовать с ним почтовый обмен или
производить иные операции с той частью почтовой очереди, которая принадле-
жит данному узлу, не нужно. Такие файлы создаются различными программами.
Создателем *.bsy (жаргонное «бзишка») может быть не только почтовая програм-
ма, но и программа-упаковщик почты, тоссер, и любая другая программа, опери-
рующая с почтовой очередью в режиме ее модификации.
Файлы *.csy используются совершенно аналогично файлам *.bsy, буква «С»
означает, что с данным узлом проводится сессия в режиме CRASH.
Для программиста, пишущего FTN-программы, нужно знать, что алгоритм со-
здания семафорного файла не должен допускать сбоев, вызванных одновремен-
ным созданием таких файлов различными процессами.
При создании семафора важно правильно продиагностировать наличие уже
существующего BSY-файла. Например, устойчиво работает следующий алгоритм:
1. Создать файл с необходимым именем и произвольным уникальным расши-
рением <имя=номер сети, номер узла>.<расширение1>.
2. Попытаться переименовать его в файл <имя=номер сети, номер узла>.
<bsy>.
3. Если после этого файл <имя=номер сети, номер узла> . расшире-
ние! > продолжает существовать, стереть его и считать адрес занятым.
Файлы - статистики соединения. Для сбора статистических данных о прове-
денных сессиях обмена почтой Bink-style допускает создание различных инфор-
мационных файлов, например *.try с информацией о последнем соединении. Не-
которые почтовые программы поддерживают свою модификацию аутбаунда
и создают дополнительные информационные файлы. Так, почтовая программа
The Brake! создает файлы *.sta, содержащие дополнительную информацию
о проведенной почтовой сессии (счетчики попыток дозвона, информацию о пос-
леднем наборе номера и т.п.). The Brake! также создает файлы *.hld, хранящие
в текстовом виде время в стиле UNIX, до наступления которого не стоит звонить
на данный адрес (например, от него был получен флаг HAT, описанный в главе 7).
Преимущества и недостатки BSO
Основные преимущества BSO-директория - это возможность использования его
как средства коммуникации между разнородным программным обеспечением
и простота управления содержимым почтовой очереди с помощью внешних про-
грамм. Недостатки же - требование наличия внешнего упаковщика почты, отсут-
ствие некоторой гибкости в маршрутизации передаваемой почты, присущей АМА-
мейлерам, связаны скорее с практикой использования и традициями реализации,
чем с внутренними свойствами стандарта. После многолетней работы с АМА-мей-
лерами автор рекомендует использовать именно BSO как основной способ пред-
ставления исходящей информации на вашей системе.
Другие разновидности почтового аутбаунда
Почти все почтовые программы поддерживают одну из двух описанных выше
файловых структур, а иногда и обе. Исключение составляют программы-комбай-
ны, объединяющие в себе большинство функций FidoNet-системы, в обычном
случае разнесенных по различным программам. Примером таких программ могут
служить FIPS - универсальная программа для подключения к сети с пойнт-адре-
сом, имеющая собственную структуру аутбаунда, или D’Bridge, поддерживающий
усложненную разновидность АМА-директория. Довольно часто для таких про-
грамм разрабатываются специальные утилиты, позволяющие конвертировать их
почтовый директорий в BSO.
Интересным решением является разработанный Дмитрием Завалишиным, Ки-
риллом Лебедевым и Джоном Гладких так называемый Long Bink-style Outbound -
почтовый директорий, происходящий от BSO, но использующий длинные имена
файлов («классический» Bink-style использует именование файлов в соответ-
ствии со стандартом MS DOS). Использование длинных имен файлов позволяет
улучшить читаемость структуры, она перестает быть «китайской грамотой», дос-
тупной лишь посвященным.
Общие правила именования файлов в случае Long-style таковы (по аналогии
со стандартными файлами BSO):
□ * . ?ut:domain.zone.net.node.point.<flavour>.Mail;
□ *.?lo: domain.zone.net.node.point.<flavour>.List;
□ * . req: domain.zone.net.node.point.Request;
□ * . bsy:domain.zone * net.node.point.Busy;
□ * .hid:domain.zone.net.node.point.Hold;
□ ★ . try:domain.zone.net.node.point.Status;
При этом используются следующие значения параметра flavour:
□ IMMEDIATE;
□ CRASH;
□ DIRECT;
□ NORMAL;
□ HOLD;
□ ONLINE;
□ REPORT.
Содержимое информационных файлов также существенно отличается от
«классического» варианта BSO.
Long-BSO представляет собой наиболее удобную структуру, единственным
и существенным недостатком которой является отсутствие совместимости с ар-
хаичными файловыми системами, не поддерживающими длинные имена файлов,
и старым программным обеспечением. На момент написания книги реализации
Long-BSO существуют только для мейлера TheBrake! (OS/2), файл-эхопроцессо-
ра CrazyTick (Win32), утилиты для отправки файлов Crazy Attach (Win32) и нет-
мейл-процессора Itrax (OS/2).
Заключение
Конечно, можно водить машину, ничего не зная о ее внутреннем устройстве. Мож-
но так же пользоваться и FidoNet, ничего или почти ничего не ведая о форматах
данных и других деталях конструкции сети. Однако рано или поздно все же при-
дется исследовать поврежденные почтовые пакеты, разбираться с дефектными
письмами, и тогда материал этой главы очень пригодится. В любом случае полу-
ченные знания будут полезны для дальнейшего изучения книги.
Глава V
Почтовая сессия между
двумя системами FidoNet
Большинство действующих стандартов FidoNet посвящены вопросам установле-
ния соединения и обмена данными между двумя системами сети. Подобная про-
цедура называется почтовой сессией, а протокол, в соответствии с которым она
осуществляется, - протоколом почтовой сессии FidoNet. Различные варианты
подобных протоколов описаны в стандартах FidoNet FTS-0001, FTS-0006, FTS-
0007, FTS-0008, а также в предложениях FSC-0056 и FSC-0072 (табл. 5.1). Важ-
нейшей составляющей протокола почтовой сессии FidoNet являются протоколы
передачи файлов, им уделено основное внимание в главе 3, однако и остальные
фрагменты почтовой сессии имеют важное значение для работоспособности
FidoNet-системы, например, такие, как способ установления соединения (hand-
shake), обмена паролями, выбор протокола передачи файла, условия разрыва со-
единения.
Таблица 5.1. Стандарты FidoNet, описывающие протокол почтовой сессии
между двумя системами FidoNet
Код документа Оригинальное название Автор Содержание Статус и комментарии
FTS-0001.016 Packet and *.msg format R. Bush Формат почтового пакета и файла *.msg, формат запроса файла. Описан протокол почтовой сессии, включающий протоколы XModem, Telink и Modem/ Используется как стандарт
FTS-0006.002 YOOHOO and YOOHOO/2U2 V. Perriello Установление соединения по протоколу YOOHOO и YOOHOO/2U2, запрос файла по протоколу WaZoo Используется как рекомендательный стандарт
Таблица 5. /. Стандарты FidoNet, описывающие протокол почтовой сессии между двумя системами FidoNet (окончание)
Код документа Оригинальное название Автор Содержание Статус и комментарии
FTS-0007.003 SEAIink protocol extension P. Becker Расширение протокола SEAIink Используется как рекомендател ьн ы й стандарт
FTS-0008.003 Bork file-request protocol extension P. Becker Расширение протокола запроса файла Bark Используется как рекомендательный стандарт
FSC-0049.001 Passing Domain Information During an FTS-0006 Session Bob Hartman Передача доменной информации во время сессии по FTS-0006 Используется как рекомендательный стандарт
FSC-0056.001 EMSI/IEMSI Protocol Definitions J. Homrighausen Определения протокола EMSI/IEMSI Используется как стандарт де-факто
FSC-0072.001 The HYDRA file transfer protocol J. Homrighausen и A. Lentz Протокол передачи файлов HYDRA Используется как рекомендател ьн ы й стандарт
FSC-0088.001 Compatibility and Link Qualifier Extensions for EMSI Sessions R. Williamson Дополнения к протоколу EMSI Используется как рекомендательный стандарт
FSP-1O11.001 Binkp - a protocol for transferring FidoNet mail over reliable connections D.Maloff, N.Soveiko, M.Masyutin Binkp - протокол для передачи почты FidoNet через свободное от ошибок соединение Используется как рекомендательный стандарт
Уровневая модель FidoNet
Описание компьютерной сети с помощью модели вертикально организованных
уровней, где каждый из слоев взаимодействует только со своими непосредствен-
ными соседями, представляет собой неизменный ритуал для любой книги, посвя-
щенной компьютерным сетям. Нельзя считать подобные описания совершенно
бесполезными и для FidoNet, хотя сеть и разрабатывалась без учета упомянутого
выше принципа, однако фактически сложившийся набор программного обеспече-
ния и организационных правил, составляющих технологию FidoNet, допускает
подобную декомпозицию и помогает лучше понять, как устроена сеть.
Наиболее известной и часто цитируемой (и реже всего используемой на прак-
тике) моделью сетевого устройства является OSI [5.1] - стандарт ISO на соедине-
ние открытых систем (Open System Interconnection, OSI). Попытка описания
FidoNet в соответствии с моделью OSI сделана в стандарте FidoNet FTS-0001
[2.5]. На рис. 5.1 представлена сетевая модель OSI с соответствующими уровнями
программных компонентов FidoNet, как она используется в стандарте FTS-0001.
Модель OSI в том виде, в каком она используется в FTS-0001, уже не отражает
современных реалий FidoNet. Конечно, соединения по FTS-0001 еще встречаются,
но они очень редки и могут возникать только в тех случаях, когда по той или иной
причине не удается провести обмен данными на более совершенных протоколах.
Рис. 5.1. Сетевая модель OSI в приложении к FidoNet
(по материалам стандарта FTS-OOO1)
Кроме того, хотя декомпозиция на уровни в FTS-0001 сделана строго в соответ-
ствии со стандартом OSI, все-таки искусственность подобного подхода к про-
граммному обеспечению любительской сети, разрабатывавшемуся (почти) без
оглядки на какие-либо модели и стандарты, очевидна.
Поэтому более полезной была бы попытка дать упрощенную уровневую модель
сети. Ее можно представить не только как функционально структурированное
описание технологии сети, но и как рекомендацию разработчикам программного
обеспечения FidoNet создавать свои варианты, разумно разделяя их на функцио-
нальные блоки с явно выделенными интерфейсами. Это позволило бы изменясь
один уровень, не затрагивая другие. Именно такая модель, или набросок модели,
приведен в проекте стандарта FSC-0080 [5.2] (рис. 5.2). Несмотря на внешнее
сходство в названиях уровней, эта модель построена без оглядки на OSI.
Локальная база писем, доступная для чтения и дополнения
(написания новых писем) пользователем сети
Внутренняя структура упакованного для отправки сообщения
(формат *.РКТ). При использовании старого формата
TYPE-2 этот уровень объединяется с нижележащим
Маршрутизация и передача сообщений FidoNet. Формат
пакета, исключая внутреннюю структуру упакованного
сообщения. Прием/передача данных и их помещение в базу
писем, сканирование базы на предмет неотправленных
писем, упаковка их для отправки
Протоколы установления связи (handshake) - например,
YooHoo и EMSL Этот уровень может надежно пересылать
файлы между двумя системами. Он не знает ничего о нетмейле,
эхо-почте, маршрутизации и тому подобных вещах
Протоколы передачи файлов (например, Zmodem),
обеспечивающие безошибочную передачу файлов
между принимающей и передающей системами.
Аппаратура, участвующая в процессе соединения двух
компьютеров: модемы и модемные протоколы; ком-порты;
протоколы коррекции ошибок и т.п.
Рис. 5.2. Уровневая модель FidoNet на основе FSC-0080
Диагностика почтовой сессии FidoNet
Под почтовой сессией (mail session) обычно понимается процесс установления со-
единения, обмена почтой и файлами и завершения соединения между двумя сис-
темами (почтовыми программами), работающими в соответствии со стандартами
сети FidoNet. Почтовая сессия начинается со следующих этапов:
□ обмена идентификационной информацией;
□ проверки разрешения на доступ к узлу с каждой из сторон;
□ обмену текстовой информацией о статусе каждого из узлов;
□ передачи запросов файлов между сторонами;
□ выбора протокола (протоколов) передачи информации.
Начальная стадия установления соединения, получившая название «рукопожа-
тие» (handshake), или «хендшейк», на этом заканчивается.
Далее производится:
□ обмен почтой и файлами с использованием выбранного протокола;
□ разрыв соединения.
ыа
Й OS/2 System Editor - CAFID0\L0GS\brake-1 Jog
File Edit Options Help__________ _____
01/07/99 09:06:37 [1,02] х: Incoming call from 27601ХХ:1: CONNECT 31200/ARQ/V34/LAPM/V42BIS
01/07/99 09:06:37 [1,02] я
01/07/99 09:06:38 [1,02] я Session with 2:5049/73®PidoNet
01/07/99 09:06:38 [1,02] я AKAs: 7:1330/73@FidoNet
01/07/99 09:06:38 [1,02] я Mailer: Т-Mail (EO) 2606.NT/Noncommrcial/1Jnregistered ;
•01/07/99 09:06:38 [1,02] я system: The Middle of Nowhere, Kazan, Tatarstan, Russia, Iwan ToloK
01/07/99 09:06:38 [1,023 я Flags: +7 -843 -276-01XX,38400,MO,V34,V32B,V42B
01/07/99 09:06:38 [1,02] я Time: Thu 01,Jul 09:06:39
01/07/99 09:06:38 [1,02] я Password protected session
\01/07/99 09t06:40 [1,02] я Using DirZap for transfer
01/07/99 09:06:41 [1,02] я ZS 131BflF0*Th6, DZA-16, 612538, 03:16, echo-mail
101/07/99. 09:08:10 [1,02] я Send stalled: er-0 bt«260/1024 oq-4095/4095, iq~0/4095
; 01/07/99 09:09:01 [1,02] я Send stalled: er=0 bt=662/1024 oq=4095/4095, iq=0/4095
01/07/99 09:09:02 [1,13] я Event 09:09 -> Poll 2:5020/238
01/07/99 09:09:13 [1,02] я Send Stalled: er~0 bt-1023/1024 oqM095/4095, iq-O/4095
01/07/99 09:09:25 [1,02] я Send stalled: er=0 bt=1023/1024 oq=4095/4095, iq=0/4095
01/07/99 09:09:37 [1,02] я Send stalled: er=0 bt=1023/1024 oq=4095/4095, iq=0/4095
01/07/99 09:09:49 [1,02] я Send Stalled: er-0 bt~1023/1024 oq==4095/4095, iq-0/4095
01/07/99 09:10:00 [1,02] я
01/07/99 09:10:00 [1,02] я SE 03:19, 280064/101888, 14*07 CPS 45% ' '
01/07/99 09:10:01 [1,02] я Done, 2:5049/73(^Fid0Net, 03:23, 0/1, 0/280064
J
Рис. 5.3. Протокол почтовой сессии FidoNet, почтовая программа The Brakel
Сессия, разрываемая по инициативе передающей программы при исчерпании
передаваемых данных, считается завершенной успешно. Если же разрыв произо-
шел досрочно, сессия обрывается с сообщением о той или иной ошибке, записы-
ваемом в файл протокола. Для диагностики неуспешных соединений всегда обра-
щайтесь к протокольному файлу почтовой программы, название которого, как
правило, составляется из названия почтовой программы, номера линии (системы
иногда бывают многолинейными) и слова «log» - «журнал». На рис. 5.3 приведен
фрагмент протокольного файла почтовой программы The Brake! с информацией
о неуспешном соединении по причине плохой связи.
Подробная диагностика начального этапа сессии, стадии установления соеди-
нения, в протокольный файл по умолчанию не записывается. Для того чтобы ее
включить, нужно, как правило, указать наименование соответствующего прото-
кольного файла. Например, в файле конфигурации почтовой программы T-Mail
необходимо раскомментировать строчку:
;EMSI_Log с:\fido\logs\t-mail.log
; Эта директива определяет имя log-файла для EMSI, в него
; записываются все удачно принятые ЕМ31_ЕАТ-посылки от
; узлов при соединениях. По умолчанию ; - не определено,
; то есть такой log-файл не ведется.
Подробное изучение протокольного файла, сопоставление имеющейся в нем
информации с текущей конфигурацией почтовой программы и протокольными
файлами других программ, участвующих в процессе обработки почты FidoNet,
помогает разрешить почти любую проблему, возникающую в процессе настройки
и работы почтовой системы FidoNet.
Xmodem в почтовой сессии FTS-0001
Протокол передачи файла - это программный способ безошибочной передачи
данных от одного компьютера (источника) к компьютеру-приемнику Подробно
основные протоколы передачи файлов, используемые в FidoNet, описаны в главе 4,
здесь же рассматривается только протокол Xmodem и его улучшенная модифика-
ция - протокол передачи файлов SeaLink (см. следующий раздел).
Протокол передачи файлов Xmodem неразрывно связан с сетью FidoNet, по-
скольку он входит в основной базовый стандарт FidoNet - FTS-0001 [2.5] как обя-
зательный протокол, который должна поддерживать каждая система FidoNet
в качестве единого для всей сети стандартного протокола передачи данных. На
практике не все почтовые программы FidoNet следуют этому правилу, так как
обычно используются более совершенные протоколы.
Подробное описание терминальной реализации протокола и его основных мо-
дификаций можно найти в главе 3.
Xmodem за годы использования претерпел несколько попыток модификации
и в настоящее время вполне подходит для передачи небольшого объема данных
на низких скоростях (протокол оптимизирован для работы на скорости 300 бод,
хотя Xmodem может работать и на более высоких скоростях). Основные недостат-
ки этого протокола следующие:
□ небольшой размер блока (прием каждого блока требует дополнительного
обмена сигналами, что увеличивает количество передаваемой служебной ин-
формации, вследствие чего замедляется прием);
□ обязательность уведомления о приеме каждого блока, отсутствие потокового
режима. Под потоковым режимом понимается непрерывная передача данных
в одном направлении до возникновения ошибки передачи, после чего от при-
нимающей стороны следует запрос на повторную передачу (ARQ типа SAW,
используя общепринятую терминологию из [3.1]);
□ отсутствие возможности изменения размеров блока в зависимости от коли-
чества ошибок в канале передачи;
□ большая вероятность необнаруженных ошибок при использовании однобай-
тной контрольной суммы;
□ недостаточно высокая защищенность от ошибок и в случае использования 16-
битной CRC (вследствие упрощенного алгоритма расчета контрольной суммы);
□ невозможность работы в 7-битной среде передачи ( в общем случае для
FidoNet это не имеет значения, так как стандартное модемное соединение
можно сконфигурировать как 8-битное, но бывают и исключения).
В число достоинств Xmodem входят относительная простота реализации, рас-
пространенность, и бесплатность.
Хотя Xmodem в настоящее время в качестве основного сетевого протокола при-
меняется редко, наличие его в составе используемых протоколов по-прежнему
важно, так как это обеспечивает связность сети, возможность установления со-
единения между произвольными системами FidoNet.
На рис. 5.4 приведен пример протокола почтовой сессии FidoNet с использова-
нием протокола FTS-0001.
'И OS/2 System Editor - C:\FiDO\LOGS\brake-Uog__________________________________________'________» [D
File Edit Options Help ; T /
17/05/99 14:33:16 [2,02] n Answering, АТА| Ы
* 17/05/99 14:33:27 [2,02] п Connected with ARQ, CONNECT 31200/ARQ/V34/БАРМ/V42BIS
* 17/05/99 14:33:27 [2,02] П *
* 17/05/99 14:33:27 [2,02] в Incoming call: CONNECT 31200/ARQ/V34/LAPM/V4 2BIS s
* 17/05/99 14 :33 : 27 [2,02] tt
=17/05/99 14:33:29 [2,02] в External connect *;
* 17/05/99 14:33:30 [2,02] tt REXX: Execute FTS-0001.Brk 7
* 17/05/99 14:33:30 [2,02] П FTS-0001 session *'
=17/05/99 14:34:13 [2,02] в Sending program: TIMS 1.1 к
Л7/05/99 14:34:14 [2,02] n Receiving 00500001.PKT (2245b) *-
=17/05/99 14:34:14 [2,02] в Execute: C:\OS2\CMD.EXE /с C:\FIDO\TOOLS\p.exe -type async
-share -device com2 -receive -clean -replace -protocol xmodem
-alternative -quiet -directory C:\FIDO\FILE\RECOVER 00500001.PKT i.
|17/05/99 14:34:20 [2,02] П Received C:\FIDQ\FILE\00500001.PKT I
*17/05/99 14:34:20 [2,02] tt Execute: C:\OS2\CMD.EXE /с DEL C:\FIDO\FILE\RECGVER\00500001.PKT R
Л7/05/99 14:34:26 [2,02] П End of FTS-0001 session Щ
Рис. 5.4. Протокол почтовой сессии с использованием FTS-0001
Как видно из рис. 5.4, для обеспечения совместимости с FTS-0001 почтовая
программа The Brake! запускает внешнюю программу (р.ехе), реализующую ос-
новные функции протокола FTS-0001. Записываемая при этом в файл протокола
информация весьма скудна, и единственный способ установить, что именно было
передано в процессе проведенной сессии, - это сопоставить приведенный на рис.
5.4 фрагмент протокольного файла с содержимым протокольных файлов других
программ FidoNet. Так, записанный несколько минут спустя фрагмент файла
traffic.log содержит следующую информацию:
Packed on Mon 1 7 May 1999 14:38:21 -----------
From:-------------------------------------------------David Rance, 2:252/110.1 17 May 99 10:39:32
To: Alex V. Ivanov, 2:5049/63 17 May 99 14:38:12
Subj: Re: E-mail class nodes.
Via: 2:5049/36
----------------------------------------------1П9-
Traffic.log представляет собой один из протокольных файлов программы - упа-
ковщика почты Unimail, и из его расшифровки следует, что в процессе сессии
Xmodem было принято письмо от системы с адресом 2:252/110.1 (согласно нодлис-
ту FidoNet, эта система находится в Англии) для адреса 2:5049/63 (сеть 2:5049, Ка-
зань). Очевидно, отправитель не смог добиться соединения с системой получателя
письма на приемлемых протоколах и был вынужден воспользоваться соединением
на FTS-0001 с хостом сети (2:5049/0) как последним, крайним средством.
Приведенное ниже описание Xmodem основано на FTS-0001 [2.5]. Следует учи-
тывать, что Fido-версия Xmodem отличается от стандартной терминальной реа-
лизации, описанной, в частности, в книге О. Лагутенко [3.1], поскольку Xmodem,
используемый в FidoNet, является лишь частью базового FTN-протокола обмена
данными и соответствующим образом переработан.
Блоки данныхXmodem-Telink
Xmodem некогда был очень популярным и достаточно эффективным методом пе-
редачи информации. Изобретенный во второй половине 70-х годов, он хорошо
работал на скорости 300 бит/с, обеспечивая эффективность до 90%. К достоин-
ствам Xmodem относились простота реализации, помехоустойчивость и бесплат-
ность (о недостатках уже сказано в предыдущих разделах).
В 1984-1986 годах этот протокол все еще оставался лидером, и базовый стан-
дарт FidoNet до сих пор использует Xmodem. Однако стандартный Xmodem не
поддерживал пересылку более одного файла за сессию. Поэтому появились вспо-
могательные протоколы Modem? и Telink, реализующие так называемый Хшо-
dem-batch - пакетный Xmodem, допускающий пересылку более одного файла за
сеанс. Возникла также редакция протокола Xmodem-1К с увеличенным размером
блока до 1024 байт, что повысило эффективность протокола на скоростях выше
300 бит/с.
FTS-0001 использует самую первую модификацию протокола Xmodem, объе-
диненного с информационными посылками протокола Telink. Описан также ва-
риант задания имени передаваемого файла по протоколу Modem? (с ним можно
ознакомиться в [2.5]).
Передача данных при использовании протокола Xmodem осуществляется по-
средством блоков длиной 128 байт, интерпретируемых как данные. Каждый блок
снабжен трехбайтным заголовком и заканчивается одно- или двухбайтной конт-
рольной суммой (CRC, Cyclic Redundancy Check), используемой на приемной
стороне для проверки правильности приема данного блока (табл. 5.2 и 5.3). В тек-
сте стандарта однобайтная контрольная сумма так и называется «контрольная
сумма», а двухбайтная - CRC.
Таблица 5.2. Блок данных Xmodem - вариант CRC
Относительный адрес Содержимое поля
Dec Нех
0 1 0 1 SOH (Start of Header или Начало Заголовка) - 01 h Номер блока
2 2 Зарезервировано
3 3 128 байт неинтерпретируемых данных
131 83 Старший байт CRC
132 84 Младший байт CRC
Xmodem не содержит специальной обработки потоков данных, которые не ук-
ладываются в целое число 128-байтных блоков и использует так называемый ин-
формационный блок файла Telink для определения реальной длины файла на при-
емном конце (табл. 5.4). Заголовки блоков содержат последовательные номера,
по которым приемник может проверить, принят ли нужный блок. Номера блоков
представляют собой последовательные беззнаковые целые 8-битные числа.
Таблица 5.3. Блок данных Xmodem - вариант контрольной суммы
Относительный адрес Содержимое поля
Dec Нех
0 0 SOH (Start of Header или Начало Заголовка) - Olh
1 1 Номер блока
2 2 Зарезервировано
3 3 128 байт неинтерпретируемых данных
131 83 Байт контрольной суммы
Для. прикрепленных к почтовому пакету файлов (не для самих почтовых паке-
тов) первый посылаемый блок Xmodem может содержать особый Telink-блок для
передачи информации о длине и атрибутах файла (табл. 5.4). Этот блок отличает-
ся тем, что первым его символом будет SYN (значение 16h), а не SOH (Olh), как
в обычном блоке, и заканчивается он всегда однобайтной контрольной суммой,
а не двухбайтным CRC. Если получатель не обрабатывает Telink-блок, то после
двух сигналов NAK (Negative AcKnowledge, код 15h) отправитель пропускает
этот блок и начинает передачу данных.
Таблица 5.4. Блок дескриптора файла Telink
Относительный адрес Содержимое поля
Dec Нех
0 0 SYN (Информационный заголовок файла) - 16Н
1 1 ООН
2 2 FFH
3 3 Длина файла, четвертый (младший) байт
4 4 Длина файла, третий байт
5 5 Длина файла, второй байт
6 6 Длина файла, первый (старший) байт
7 7 Время создания файла «DOS Формат»
9 9 Дата создания файла «DOS Формат»
И В Имя файла 16 символов выровнено влево, остаток заполнен пробелами
TJ 1В ООН
28 1С Имя посылающей программы 16 символов выровненных влево,
остаток заполнен кодом ООН
44 2С Признак контрольной суммы Olh (CRC) или ООН
45 2D Заполнение 86 байт ООН
132 84 Байт контрольной суммы
Заметим, что признак контрольной суммы (смещение от начала 44) всегда ус-
танавливается в Olh для текущих реализаций протокола, так как все они исполь-
зуют метод CRC. Поэтому это поле блока всегда устанавливается посылающей
стороной в Olh и игнорируется принимающей.
Протокол передачи: конечный автомат Xmodem/Telink
Протокол обмена информацией между двумя FTN-совместимыми системами на
основе Xmodem изложен в [2.5] в терминах конечного автомата. Такое изложение
позволяет до тонкостей понять особенности протокола и использовать его для
программной реализации.
Протокол управляется принимающей стороной (приемником), которая долж-
на запрашивать у посылающей (передатчика) каждый блок.
Если приемник запрашивает у передатчика первый блок, используя символ «С»
(43h), это означает, что он предпочитает использовать полиномиальную кон-
трольную сумму CRC-CCITT, помещаемую в конец каждого блока в виде двух-
байтного кода (табл. 5.2); в противном случае предполагается использование одно-
байтной беззнаковой контрольной суммы.
Передатчик отвечает посылкой блока с CRC в конце, если это возможно. Когда
передатчик решает выбрать метод однобайтной контрольной суммы, он должен
дождаться от приемника сигнала NAK (15h). Если метод контрольной суммы
предпочтителен для приемника, он сразу запрашивает первый блок посредством
передачи сигнала NAK.
Передатчик посылает сигнал EOT вместо блока данных, когда данные исчерпаны.
Ни передатчик, ни приемник не должны посылать новые блоки или сигналы
ACK/NAK, пока данные не приняты. Они должны ждать возобновления переда-
чи до истечения тайм-аута.
Предполагается, что приемный буфер очищается немедленно после посылки
блока или сигнала ACK/NAK, до получения ответа от другой стороны. Это устра-
няет помехи и мусор, которые обычно возникают во время передачи.
Следуя изложению, принятому в FTS-0001, обратимся к протоколу передачи
в терминах состояний конечного автомата (табл. 5.5 и 5.6).
Все проверки были введены в протокол для того, чтобы можно было удостове-
риться в неповрежденности принятого блока данных и в том, что нужный блок.
Для успешной работы протокола должны соблюдаться следующие требования:
□ физический уровень передачи не должен содержать ошибок (например, оши-
бок четности и т.п.);
□ длина блока не должна быть меньше, чем ожидаемая;
□ если последовательность блоков нарушается, то следует ответ NAK, и долж-
на быть сделана повторная попытка чтения блока;
□ если передается блок с меньшим, чем ожидаемый, номером, то необходимо
ответить сигналом NAK, и повторить попытку чтения блока;
□ если номер блока не отвечает описанным выше критериям и не соответствует
ожидаемому номеру блока, следует прервать прием;
□ выбор метода (контрольная сумма или CRC) должен быть сделан правильно.
Таблица 5.5. Протокол передачи Xmodem/Telink со стороны передатчика в терминах конечного автомата
Индекс состояния Название состояния Предикат(ы) Действия Следующее состояние
XS0 ЖдатьТе1пк 1. До 40-60 секунд 2. До 2 попыток 3. Принят NAK или «С» 4. Принят АСК Сообщение «таймаут передатчика» Сообщение «нет блока Telink» Послать Telink, прибав.попыт Telink принят, установить CRC/ контрольная сумма Выход XS1 XS0 XS2
XS1 ЖдатьСтарт 1. До 40-60 секунд 2. До 20 попыток 3. Принят NAK 4. Принят «С», CRC возможен 5. Принят «С», CRC невозможен Сообщение «таймаут передатчика» Сообщение «посылка неудачна» Установить режим конт.суммы Установить режим CRC Выход Выход XS2 XS2 XS1
XS2 ПослатьБлк 1. Есть еще данные 2. Послан последний блок Послать следующий блок данных Послать EOT XS3 XS4
XS3 ЖдатьАСК 1.10 попыток или 1 минута 2. Принят АСК 3. Принят NAK (или «С», если это первый блок) Сообщение «посылка неудачна» Перепослать последний блок Выход XS2 XS3
XS4 ЖдатьЕпб 1.10 попыток или 1 минута 2. Принят АСК 3. Принят NAK ‘ Сообщение «посылка неудачна» Сообщение «посылка успешна» Перепослать EOT Выход Выход XS4
Таблица 5.6. Протокол передачи Xmodem/Telink со стороны приемника
в терминах конечного автомата
Индекс состояния Название состояния Предикат(ы) Действия Следующее состояние
XR0 СтартПрием 1. Предпочтителен режим CRC Послать «С» XR1
2. Нужен режим Послать NAK XR1
контрольной суммы
XR1 ЖдатьПервого 1.10 попыток или 1 минута Сообщить «неудача приема» Выход
2. Более 3 попыток Установить XR0
или 30 секунд режим контрольной суммы
3. Принят сигнал EOT Задержка менее секунды, удалить принятое, послать АСК, сообщить «нет файла» Выход
Таблица 5.6. Протокол передачи Xmodem/Telink со стороны приемника
в терминах конечного автомата (окончание)
Индекс Название Предикат(ы) Действия Следующее
состояния состояния состояние
4. Принят блок Telink Послать АСК, установить режим CRC/ XR2
контрольная сумма
5. Принят блок данных Послать АСК, установить режим CRC/ контрольная сумма XR2
6. Плохой блок или 2-3 секунды Увеличить счетчик попыток XRO
XR2 ЖдатьБлок 1.10 попыток или 1 минута Сообщить «неудача приема» Выход
2. Принят сигнал EOT Послать АСК, сообщить «прием успешный» Выход
3. Принят блок данных Послать АСК XR2
4. Плохой блок или 2-10 секунд Послать NAK, увеличить счетчик попыток XR2
FTS-0007 и протокол SeaLink
Необходимость в усовершенствовании Xmodem возникла сразу после того, как по-
всеместно начали распространяться скоростные модемы (использующие скорос-
ти свыше 300 бит/с). Это произошло за рубежом во второй половине 80-х годов.
Протокол почтовой сессии FidoNet, основанный на протоколе передачи фай-
лов SeaLink, был разработан Филипом Бекером (Philip L. Becker) в 1989 году. Он
представляет собой дальнейшее развитие описанного в предыдущем разделе стан-
дарта FTS-0001. Этот протокол подробнейшим образом описан в пространном
документе FTS-0007 [5.3], частично включающем FTS-0001. При разработке FTS-
0007, который в отличие от FTS-0001 является не обязательным, а всего лишь ре-
комендательным стандартом, были поставлены следующие задачи:
□ полная совместимость с системой, поддерживающей стандартную реализа-
цию FTS-0001;
□ совместимость с вариантами FTS-0001, опускающими либо задание имени
файла по протоколу MODEM7, либо заголовок Telink (описаны в предыду-
щем разделе);
□ поддержка режима «скользящего окна», позволяющего послать более одного
блока Xmodem до получения уведомления о приеме от принимающей сторо-
ны. Этот метод позволяет значительно повысить надежность протокола
Xmodem, стандартная реализация которого чрезвычайно неэффективна
и «сбивается» при любых, даже очень кратких (менее секунды) задержках пе-
редачи;
□ поддержка потокового режима передачи, что существенно при использовании
асимметричного модемного соединения. Примером подобного протокола, ап-
паратно обеспечиваемого модемом, является известный протокол HST фир-
мы US Robotics (ныне собственность ЗСОМ), который эффективен только
при однонаправленной передаче данных;
□ поддержка режима докачки файла с того места, где передача была прервана
(стандартный Xmodem начинает в этом случае передачу заново).
В остальном FTS-0007 копирует FTS-0001, включая педантичную декомпози-
цию на функциональные уровни в соответствии с моделью OSI. Хотя протокол
SeaLink намного более надежен и совершенен, чем породивший его Xmodem, обя-
зательным стандартом остается пока именно FTS-0001 и Xmodem.
На смену SeaLink пришли еще более совершенные протоколы, и по этой при-
чине соединение по FTS-0007 сейчас редкость.
Запрос файла (File-Request)
в почтовой сессии FidoNet
Основное назначение почтовой сессии FidoNet - произвести обмен почтой меж-
ду двумя системами сети, включая обмен прикрепленными к письмам файлами,
если таковые имеются (способ «прикрепления» файла к письму обсуждался в гла-
ве 4, при описании формата почтового сообщения MSG). Кроме этого, можно
выполнить еще одно чрезвычайно полезное действие - запросить с удаленной
системы какой-либо файл или файлы. Это гораздо удобнее получения файлов при
доступе к BBS. В случае использования почтовой программы вам не нужно вво-
дить пароли и странствовать по меню удаленной системы - почтовая программа
все сделает сама, нужно только знать имена файлов, которые вы хотите получить.
Следует еще раз напомнить, что файловые запросы никак не связаны с основ-
ным назначением FidoNet - передачей по сети почты. Это всего лишь одно из
многих удобных и полезных усовершенствований. В качестве другого подобного
же примера можно привести беседу (chat) в процессе почтовой сессии FidoNet,
когда вы и ваш удаленный корреспондент можете посылать друг другу текстовые
строки, вступая таким образом в своеобразный «разговор».
В базовом стандарте FidoNet, FTS-0001 реализации запроса файла уделено
мало внимания. Описаны атрибуты письма FileRequest и FileUpdateReq (см. выше
описание формата MSG), при появлении которых поле SUBJECT (тема) письма
должно быть проинтерпретировано как спецификация запрашиваемого файла,
и дано описание правил составления такой спецификации. Решение всех осталь-
ных вопросов оставлено на усмотрение программиста.
Опыт первых почтовых программ послужил основой для создания формата
файловых запросов. Основных форматов всего два - файловый запрос типа Bark
(FTS-0008) и типа WaZOO (FTS-0006), описание которых дано ниже. Файловый
запрос формируется либо на основании письма с атрибутами FileRequest или
FileUpdateReq, либо на основании директивы оператора почтовой программы -
такая возможность есть в большинстве почтовых программ. На рис. 5.5 изображено
поле ввода имени файла, которое появляется после ввода адреса системы, с которой
запрашивается файл, для почтовой программы T-Mail (этот диалог вызывается при
нажатии комбинации клавиш Alt+R из основного экрана программы).
Два основных протокола передачи файловых запросов описаны ниже; при опи-
сании использованы соответствующие стандарты.
Рис. 5.5. Запрос файла из основного экрана почтовой программы T-Mail
Формат файлового запроса WaZOO
Файловый запрос представляет собой информационный пакет, передаваемый зап-
рашивающей (клиентской) стороной для отвечающей (серверной). На основании
содержащейся в пакете информации и в зависимости от настроек почтовой про-
граммы серверная сторона производит контроль доступа к файловому ресурсу си-
стемы. В результате либо формируется письмо с описанием причины отказа, либо
запрашиваемые файлы отправляются клиенту с использованием протокола пере-
дачи файлов, согласованного на более ранних этапах установления соединения.
Файловые запросы передаются в процессе почтовой сессии в виде файлов
с расширением .req. Имя файла представляет собой два четырехзначных шестнад-
цатиричных числа, соответствующих адресу вызывающей системы. Первое из
чисел описывает номер сети, второе - узла. Например, в случае посылки файло-
вого запроса с системы автора 2:5049/12 название файла будет выглядеть как
13b9000c.req, где 13Ь9000с есть шестнадцатиричное представление чисел 5049
и 12, составленное вместе. Автором такого способа идентификации передаваемых
файлов (не только файловых запросов) является Рик Хюбнер (Rick Hubner), пер-
вым адаптировавший протокол Zmodem для почтовой программы Opus. Он же
является одним из архитекторов протокола передачи файлов Janus.
Файл *.req представляет собой текстовый файл, содержащий спецификации
файлов, которые клиентская сторона запрашивает у серверной. Имена файлов
могут включать метасимволы «?» и «*», но не содержат полного пути (path) к зап-
рашиваемым файлам, так что их поиск серверная сторона осуществляет самосто-
ятельно.
Например, если мы желаем запросить с удаленной системы (пусть ее адрес бу-
дет 2:5049/12) файл с именем this.arc, а также все файлы с именем nodelist, то файл
13b9000c.req будет содержать следующую информацию:
this.arc
nodelist.*
Если же системный оператор станции с адресом 2:5049/12 защитил паролем
THAT доступ к файлам на своей системе, то содержимое файла 13b9000c.req дол-
жно быть следующим:
this.arc 'THAT
nodelist.*
Правила построения парольных запросов очевидны из примера, приведенного
выше:
<имя файлаходиночный пробел>! <парольхсимвол перевода строки>
Следует добавить, что пароль может состоять из шести или менее символов,
регистр значения не имеет.
Если используется вариант файлового запроса, называемый File Update Request
(запрос на дополнение), при котором запрашивающей стороне передаются толь-
ко файлы «младше» определенной даты (то есть созданные раньше, чем указан-
ная дата), или (в зависимости от типа запроса) отличающиеся от нее, то REQ-
файл должен содержать тип дополнения и время, выраженное числом в текстовом
представлении, соответствующем стилю операционной системы UNIX (время
в Unix выражается числом секунд, прошедших с 1-го января 1975 года). Выгля-
деть это может примерно так:
newopus.* +599634000
В приведенном примере запрашивается файлы, удовлетворяющие файловой
спецификации newopus.*, созданные позже 00.00 1-го января 1989 года. При этом
«+» перед числом означает тип запроса файла, при котором на вызывающую сто-
рону передаются все файлы, удовлетворяющие приведенной в запросе специфи-
кации и отличающиеся датой от приведенной в запросе; «-» запрашивает все фай-
лы с более ранним или таким же, как в запросе временем создания.
Полное описание формата строки запроса теперь выглядит следующим образом:
<имя_файла> [<пробел> ! <пароль>] [<пробелх + /-хвремя>] сперевод
строки>
Дополнительные сведения о механизме обработки файлового запроса при ус-
тановлении соединения по методу YOOHOO можно найти далее в этой главе
и в стандарте FTS-0006.
Формат файлового запроса Вагк
Файловый запрос типа Bark подробно, в стиле FTS-0001 (то есть с использовани-
ем терминологии OSI), изложен в документе FTS-0008, представляющем собой
расширение FTS-0001 для включения в него подробно специфицированного зап-
роса файла. Вспомним, что в самом FTS-0001 запросу файла уделено немного вни-
мания. FTS-0008 имеет статус необязательного стандарта. Автором его является
Филип Бекер (Р. Becker).
По сути запрос файла типа Bark мало чем отличается от описанного в предыду-
щем разделе WaZOO. Различие - в частностях. Точно так же, как и в стандарте
WaZOO, отвечающей стороне передается пакет запроса, содержащий имя запра-
шиваемого файла, дату, используемую при запросах на дополнение, и (необяза-
тельный) пароль. Запрос файлов типа Bark полностью контролируется вызывае-
мой (серверной) системой, выполняется он в два этапа. На первом отвечающая
система сообщает вызывающей, что та может запросить у нее файлы, на втором
вызывающей системе разрешается выполнить сам запрос.
Запрос на дополнение отличается от обычного тем, что в пакете присутствует
информация о дате модификации файла. Если имеющийся на серверной стороне
файл по времени создания равен или «старше» указанной в запросе даты, то он не
посылается.
Сам пакет в отличие от текстового REQ-файла WaZOO-формата содержит
и нетекстовые символы. Он состоит из заголовка, имени файла, даты (использу-
ется только при запросах на дополнение, в обычном запросе равна 0) и необяза-
тельного пароля. При этом разрешается посылать пароль даже если необходимос-
ти в этом нет, серверная сторона в этом случае должна его игнорировать. Конец
данных пакета обозначается байтом с кодом 03h. За ним следуют еще 2 байта цик-
лического проверочного кода (CRC), используемые для контроля целостности
данных, причем «старший» байт CRC следует за «младшим», в отличие от исполь-
зуемого в Xmodem. Структура пакета описана в табл. 5.7.
Таблица 5.7. Пакет запроса файла типа Bark
Относительный адрес Содержимое поля
Dec Нех
0 0 АСК - начало запроса Bark, код 06h
1 1 Имя файла - упакованный DOS-формат
п п Пробел - код 20Н
л п Дата (0 если это не запрос на дополнение)
п п Пробел - 20h (только если следует пароль)
п п Пароль (не обязателен)
п п ЕТХ - конец пакета - код ОЗН
п п Младший байт CRC
п п Старший байт CRC
Имя файла может занимать максимально 12 байт, дата - 11 байт, пароль - мак-
симально 6 или 8 байт (ограничение определяется используемыми почтовыми
программами).
Существенным является то, что файловый запрос типа Bark осуществляется
после того, как завершился процесс обмена почтой.
Почтовые сессии YOOHOO и EMSI
С появлением скоростных модемов во второй половине 80-х годов были изобрете-
ны и новые протоколы передачи файлов. Это были как прямые потомки Xmodem -
SeaLink, Telnet, Xmodem-1К, так и существенно отличающиеся от него - Ymodem,
Ymodem-G, Zmodem (со всем множеством его вариантов). Обмен почтой с исполь-
зованием всего лишь одного, не самого совершенного из протоколов, перестал
удовлетворять потребностям растущей сети. Теперь (в конце 80-х - начале 90-х
годов) расширением программного обеспечения для FidoNet занимался уже не
один Том Дженнингс. Многие участники сети взялись за разработку новых по-
чтовых программ FidoNet. Перед ними встала задача создания гибкого протокола
сессии, который позволил бы сделать выбор из множества протоколов передачи
файлов. Вскоре эта задача была решена.
Таким решением стали стандарт FidoNet FTS-0006 [5.4] и последовавшее за
ним предложение FSC-0056 [5.5]. Оба этих документа содержат рекомендатель-
ные стандарты, ни один не является обязательным в отличие от FTS-0001, тем не
менее де-факто именно эти два документа описывают протоколы почтовой сес-
сии, наиболее часто используемые в FidoNet.
Протокол почтовой сессии YOOHOO
Протокол установления соединения YOOHOO был разработан Винном Вагнером
(Wynn Wagner), создателем почтовой и BBS программы Opus-CBCS, а затем пе-
реработан Винсентом Перриелло (Vince Perriello) как универсальный протокол
установления соединения для почтовых программ FidoNet. Описание его содер-
жится в документе FTS-0006 [5.4].
YOOHOO, по замыслу автора, должен был служить протоколом установления
соединения для WaZOO, разработанной специально для Opus-CBCS системы об-
мена почтой между двумя Opus-совместимыми системами. WaZOO означает
«Warp-Zillion Opus-To-Opus» — нечто труднопереводимое, не будем даже и пы-
таться. По сути, WaZOO представляет собой набор протоколов передачи файлов
плюс протокол установления соединения, описанный в данном разделе.
Название протокола (yoohoo) - популярное приветственное восклицание вро-
де нашего «эгей!». Полное же название протокола переводится как «Установле-
ние соединения для обмена сетевой почтой, используемое Opus-CBCS и другими
почтовыми программами FidoNet».
Протокол YOOHOO служит начальной процедурой установления соединения
для протокола обмена электронной почтой WaZOO. При этом системы, не совме-
стимые со стандартом WaZOO (например, системы, поддерживающие обмен по-
чтой по FTS-0001), могут также устанавливать соединение по своим протоколам -
YOOHOO распознает их и позволяет им продолжать работать.
Процедура установления соединения по YOOHOO начинается с посылки вы-
зывающей системой одного байта с кодом Flh. Если система на другой стороне не
отвечает, дальнейшие попытки установить соединение на протоколах YOHOO
или WaZOO не производятся. Если же вызываемая система отвечает, вызываю-
щая система посылает пакет длиной 128 байт, содержащий такую информацию,
как наименование системы, имя оператора и маска совместимости (см. ниже).
Целостность пакета хранит передаваемый вместе с ним 16-битный циклический
код. В ответ вызываемая система передает аналогичный пакет. Это и есть в общих
чертах процедура установления соединения YOOHOO/2U2.
Основные свойства протокола следующие:
□ YOOHOO не мешает установлению соединения на других протоколах, не со-
вместимых с ним;
□ YOOHOO - это защищенный метод установления соединения и выбора об-
щего протокола из нескольких возможных;
□ YOOHOO имеет встроенные возможности расширения без коренной пере-
делки протокола.
В деталях начальная процедура YOOHOO выглядит так:
1. Вызывающая система использует процедуру, которая посылает как символ
запроса процедуры хендшейка YOOHOO (код Flh), так и символ TSYNC
(код AEh) - знак запроса почтовой сессии FTS-0001 (см. выше в этой главе
описание установления соединения по FTS-0001).
2. Если вызываемая система отвечает символом NAK (код 15h), то начинает-
ся сессия FTS-0001, если же принимается символ ENQ (05h), то вызываю-
щей стороной запускается процедура YooHoo_Sender(), инициирующая сес-
сию YOOHOO.
3. Вызываемая система может вызвать процедуру YooHoo_Receiver(), если
встречает во входном потоке старт-символ YOOHOO (Flh), либо перейти
на FTS-0001, получив TSYNC.
Этот простой метод позволяет почтовой программе устанавливать соединения
как по FTS-0001, так и YOOHOO.
Протоколы передачи файлов в сессии YOOHOO/WaZOO
YOOHOO позволяет «договориться» об использовании одного из четырех прото-
колов, включая два варианта описанного далее в этой главе протокола Zmodem.
ZedZap. Это один из вариантов протокола Zmodem, характеризуемый следую-
щими особенностями как самого протокола, так и способа его использования:
□ ZedZap допускает несколько «разворотов» в зависимости от запросов той или
иной системы на дополнительную передачу файлов (например, при выполне-
нии запроса файла);
□ в отличие от «правильного» варианта Zmodem, описанного Чаком Форсбер-
гом (Chuck Forsberg), ZedZap может провести сессию без передачи каких-
либо файлов (то есть сразу перейти к стадии ZFIN);
□ размер блока ZedZap зависит от скорости соединения, достигая максималь-
ного (8192 байт) на скоростях 9600 бод и выше. Это также значительное из-
менение относительно «строгой» реализации Zmodem;
□ почтовые пакеты передаются как файлы с именами вроде 12345678.pkt.
В течение сессии может быть послано несколько почтовых пакетов;
□ если вызывающая система передает .req файл, содержащий файловый запрос,
то отвечающая система может ответить на него (см. описание запроса файлов
стандарта WaZOO в предыдущем разделе).
ZedZip. Этот вариант протокола Zmodem в основном совпадает с ZedZap, но
размер используемого им буфера не превышает 1024 байта, как и у «правильно-
го» Zmodem. Также разрешено посылать Null- (пустой) пакет. Этот вариант про-
токола Zmodem позволяет участвовать в сессии WaZOO системам, имеющим
«строгую» реализацию Zmodem.
DietIFNA. Этот протокол сейчас практически не используется. Он работает
аналогично описанным выше в этой главе FTS-0001/FTS-0007 с небольшими
усовершенствованиями относительно протокола SeaLink.
Janus. Протокол Janus (глава 3) - полнодуплексный протокол, то есть инфор-
мация в Janus передается одновременно в двух направлениях. Протокол выбира-
ется по инициативе вызывающей системы. Для этого ей посылается маска совме-
стимости (compatibility mask), представляющая собой переменную типа word
(16-битное беззнаковое число), где каждый бит ответствен за тот или иной прото-
кол. Вызываемая система считывает маску совместимости и посылает в ответ
свою, с единственным битом протокола, который она предпочитает выбрать для
обмена. Значение битов маски совместимости показано на рис. 5.7. Если вызыва-
емая система пошлет в ответ маску совместимости более чем с одним установлен-
ным битом протокола, то это вызовет потенциальную проблему выбора, которая
разрешается заранее установленной последовательностью выбора протоколов.
Так, если вызываемая система не может сделать выбор, он осуществляется со-
гласованно обеими сторонами в следующей последовательности:
1. Janus.
2. ZedZap.
3. ZedZip.
4. DietIFNA.
Должен выбираться наиболее «предпочтительный» протокол из числа поддер-
живаемых обеими сторонами.
Правила именования файлов при обмене почтой WaZOO
В стандарте YOOHOO/WaZOO закреплены устоявшиеся де-факто правила име-
нования передаваемых в течение сессии файлов. Выше, при рассмотрении правил
запроса файлов, мы уже уделили внимание тому, как составляются имена фай-
лов-запросов (.req). Кроме этих файлов в процессе сессии передаются файлы се-
тевой почты и упакованной эхо-почты:
□ файлы сетевой почты описанного выше формата xxxxxxxx.pkt. Имя длиной
восемь символов (обозначено как хххххххх) должно состоять из шестнадца-
тиричных цифр в символьном представлении;
□ имена архивированных файлов эхо-почты и нетмейла составляются анало-
гично; расширение должно состоять из двухсимвольного кода, имеющего зна-
чение дня недели (МО, TU, WE, TH, FR, SA или SU), и числа 0-9.
В последние годы получил распространение подход, когда цифры 0-9 не исчерпы-
вают возможные значения последнего символа расширения файла архивированной
почты, вместо них можно использовать и другие символы алфавита. Это сделано для
расширения возможного количества хранимых на системе файлов с эхо-почтой.
Архивированная почта упаковывается с помощью одного из популярных архи-
ваторов. Пример наименования файла с эхо-почтой: c821a96f.su 0.
Последовательность операций при использовании Zmodem
При использовании ZedZap и ZedZip, вариантов протокола Zmodem, последова-
тельность обмена сигналами и информацией в сессии WaZOO складывается из
действий на вызывающей и на принимающей стороне.
На вызывающей стороне:
1. Послать символ внимания YOOHOO.
2. Принять ответ YOOHOO/2U2.
3. Последовательно, в одном сеансе Zmodem, послать пакеты с нетмейлом,
файлы архивированной почты, другие файлы, REQ-файлы файловых
запросов (именно в этом порядке).
4. Затем, в следующем сеансе Zmodem, принять пакеты почты, файлы, REQ-
файлы и запрошенные на предыдущем этапе файлы (все в перечисленном
порядке).
5. Если были получены файловые запросы (файлы .req), то послать все запро-
шенные файлы в отдельном сеансе Zmodem.
На принимающей стороне:
1. Принять символ внимания YOOHOO.
2. Послать ответ YOOHOO/2U2.
3. Последовательно, в одном сеансе Zmodem, принять пакеты с нетмейлом,
файлы архивированной почты, другие файлы, REQ-файлы файловых
запросов.
4. В следующем сеансе Zmodem послать пакеты почты, файлы, REQ-файлы
и ответить на запросы файлов, полученные на предыдущем этапе.
5. Если на предыдущем шаге были посланы файловые запросы (файлы .req),
то принять все запрошенные файлы в отдельном сеансе Zmodem.
Механизм ответа на файловые запросы
В сессии ZedZap или DietIFNA .req-файл просто передается на другую систему,
как любой другой, обычный файл. В сессии Janus .req-файл посылается по одной
строке (вспомним, что файловый запрос типа WaZOO использует простой тек-
стовый формат .req-файла). Каждая посланная строка на противоположной сто-
роне обслуживается отдельно.
Отметим, что удаленная система может проигнорировать файл-реквест или
послать только некоторые файлы. Строгого требования выполнения запроса фай-
ла не существует.
Если ваша реализация протокола YOOHOO не поддерживает файловый
запрос «на дополнение», то он должен обрабатываться как обычный запрос.
Заметим, что в информационном пакете YOOHOO присутствует информация
о том, поддерживаются ли удаленной системой файловые запросы или нет. Это по-
зволяет не посылать .req файлы на такую систему, экономя время сессии и деньги
системного оператора (см. листинги программных структур на рис. 5.6 и рис. 5.7).
^OS/2SystemEditor-C:\FIDO\UTILS\hello.c ...................... ZZ.2~...."Г.3ZZZZZLoЕ
File Edit Options Help
struct _Hello
I word signal; /♦ всегда ’o' (6Fh) */
word hello_version; /♦ сейчас равено 1 (Olp) */
word product; /♦ код программы ("product code") */
word product—maj; /* основная версия программы */
word product—min; /♦ вспомогательная версия программы */
char my_name [60] ; /♦ наименование системы и имя */
/* домена противоположной стороны, */
/* домен должен использоваться, если */
/♦ установлен переключатель DO_DOMAIN в */
/♦ маске совместимости */
char sysop [20] ; /* имя системного оператора */
word my_zone; /* номер зоны (0 - не поддерживается) */
word my_net; /♦ основной номер сети */
word my_node; /* основной номер узла */
word my_point; /♦ номер пойнта (0 - не поддерживается) */
byte my_password[8] ; /♦ пароль */
byte reserved2[8]; /♦ резерв для Opus */
word capabilities; /♦ см. рис.5.7 */
byte reserved3[12]; /* резерв для не-Opus систем */
); /* общий размер 128 байт */
Рис. 5.6. Информационный пакет YOOHOO
OS/2 System Editor - C:\FIDO\UTILS\cmask.h __________' .......... ................. о [□'
File Edit Options Help
/*..........................................................................................*/l^
/* МАСКА СОВМЕСТИМОСТИ YOOHOO */R
ftdefine Y-DIETIFNA 0x0001 /* Возможен быстрый "FTS-0001й 0000 0000 0000 0001 */|
ftdefine FTB—USER 0x0002 /♦ Резерв для Opus-CBCS 0000 0000 0000 0010 */i
ftdefine ZED_ZIPPER 0x0004 /♦ ZedZip, блоки IK 0000 0000 0000 0100 */!
ftdefine ZED_ZAPPER 0x0008 /♦ ZedZap 0000 0000 0000 1000 ♦/!
ftdefine DOES_IANUS 0x0010 /* Janus 0000 0000 0001 0000 */|
ftdefine Bit_5 0x0020 /♦ Резерв FTSC 0000 0000 0010 0000 */
ftdefine Bit_6 0x0040 /♦ Резерв FTSC 0000 0000 0100 0000 */
ftdefine Bit_7 0x0080 /* Резерв FTSC 0000 0000 1000 0000 ♦/
ftdefine Bit—8 0x0100 /♦ Резерв FTSC 0000 0001 0000 0000 ♦/
ftdefine Bit—9 0x0200 /* Резерв FTSC 0000 0010 0000 0000 */|
ftdef ine Bit_a 0x0400 /* Резерв FTSC 0000 0100 0000 0000 */|
ftdefine Bit—b 0x0800 /♦ Резерв FTSC 0000 1000 0000 0000 */| )
ftdefine Bit—c 0x1000 /♦ Резерв FTSC 0001 0000 0000 0000 */S I
ftdefine Bit—d 0x2000 /♦ Резерв FTSC 0010 0000 0000 0000 */И
ftdefine DO_DOMAIN 0x4000 /♦ Пакет,содержащий домен 0100 0000 0000 0000 */р
ftdefine WZ_FREQ 0x8000 /* Запрос файла WaZOO 1000 0000 0000 0000 */^
Рис. 5.7. Битовая структура маски совместимости протокола YOOHOO
Доменная адресация в информационном пакете YOOHOO
Со времени изобретения сессии WaZOO в FidoNet произошли существенные
изменения: появились зоны, пойнт-адреса, доменные адреса (в главах 1 и 2 под-
робно рассмотрена адресация FidoNet ). Соответственно этим изменениям был
модифицирован и информационный пакет YOOHOO. Что касается пойнт-адресов
и номера зоны, здесь все ясно; доменная же структура в FidoNet до сих пор
используется нечасто (поскольку FidoNet вся занимает один домен fidonet, и до-
менная информация бывает нужна при обмене почтой с другими FidoNet-подоб-
ными сетями).
YOOHOO может использовать доменную информацию. За это отвечает поле
MY_NAME в информационном пакете (рис. 5.6) и переключатель DO_DOMAIN
в маске совместимости (рис. 5.7).
Установленный переключатель DO_DOMAIN говорит противоположной сто-
роне, что в ее информационном YOOHOO-пакете ожидается имя домена.
Поле MY_NAME используется потому, что изначально в пакете YOOHOO не
было места для доменной информации, а это поле достаточно длинное, чтобы хра-
нить в нем и еще какую-то информацию, кроме названия системы. Поэтому на-
звание домена содержится в этом поле после основной информации. И имя систе-
мы, и наименование домена хранятся как строки в стандарте UNIX (строки,
завершенные нулем). Если общее число символов превышает 60 - максимум дли-
ны этого поля, то имя системы обрезается (справа налево). Но обычно 60 симво-
лов хватает.
Например, для системы DOUBLE_DOZEN с адресом 2:5049/12@fidonet, адрес-
ные поля и поле имени системы будут выглядеть примерно так:
hello. my_zone = 2
hello. my_net = 5049
hello. my_node = 12
hello. my_point = 0
hello.my_nome = "D"/O' ,'U'/В' ,'L' ,'E' / ,'D'/O',
z'Z''/E'/N',0/f'/i'/d'/o'/n',
"e"/t',0
Дополнительную информацию о протоколе сессии YOOHOO/WaZOO можно
почерпнуть из стандарта FTS-0006 [5.4].
Протокол почтовой сессии EMSI/IEMSI
Спецификации протоколов EMSI и IEMSI разработал автор известной почтовой
программы FrontDoor Иахим Хомригхаузен (Joaquim Н. Homrighausen) вместе
с Крисом Ирвином (Chris Irwin) и Андре Милнером (Andrew Milner). Они изло-
жены в проекте стандарта FTS-0054 [5.5]. Этот документ написан в свободном
стиле, отличающемся от почти ритуальной строгости FTS-0001, но сути дела это
не меняет, и EMSI по сей день остается наиболее распространенным протоколом
установления соединения в FidoNet.
EMSI (Electronic Mail Standard Identification - «стандарт идентификации элект-
ронной почты») - протокол, допускающий максимум гибкости и расширяемости
среди всех рассмотренных ранее протоколов установления соединения. В зависи-
мости от задач реализация EMSI может быть и сложной, и простой, без ущерба
совместимости.
Этот протокол отличается в лучшую сторону от рассмотренного выше YOOHOO,
который менее гибок, ресурс его расширения исчерпан, и он не работает в услови-
ях 7-битной среды передачи (изредка, но таковая встречается). YOOHOO требует
использования полной таблицы кодов, а не только первой ее половины.
EMSI/IEMSI использует пакеты переменной длины, данные кодируются
7-битными символами ASCII 1 (то есть первой половины символьной таблицы -
до кода 128). Символы, выходящие за границы диапазона таблицы ASCII 1, также
могут быть переданы с использованием дополнительного кодирования.
Сообщения EMSI
EMSI/IEMSI представляет собой протокол, основанный на многосимвольных
посылках, в отличие от YOOHOO или FTS-0001, где используются односимволь-
ные сигналы. У такого подхода есть несколько преимуществ, но есть и недостат-
ки. В частности, при очень плохой связи (а в нашей стране это не редкость) EMSI
иногда требует несколько повторных попыток для установления соединения на
логическом уровне, так как шум в линии портит часть пакетов с данными. В таких
условиях шанс установить соединение у протокола с односимвольными сигнала-
ми несколько выше.
Все EMSI-посылки завершаются одиночным символом «возврат каретки»
(ODh), это удобно, поскольку существует коммуникационное оборудование и про-
граммы, которые именно по получении этого символа освобождают свои буфера
и таким образом полностью завершают пересылку. При реализации протокола
EMSI использование символа ODh в качестве символа завершения сообщения
представляет собой обязательное требование.
Файловые запросы в сессии EMSI осуществляются только в формате WaZOO,
описанном выше. Другие механизмы запроса файлов не поддерживаются.
Для обозначения границ посылок EMSI используются специальные символы
начала и конца пакета - символы фигурных скобок. Каждый пакет начинается
с символа { и заканчивается }. Если такой символ встречается среди передавае-
мых данных, он должен быть продублирован. Внутри фигурных скобок могут
встречаться только символы кодовой таблицы ASCII 1 (коды 0Oh...7Eh). Если
в передаваемых данных встречаются поля, содержащие символы второй полови-
ны кодовой таблицы, иногда называемой ASCII2, то они выделяются аналогич-
ным образом, но в качестве символов-ограничителей используются символы квад-
ратных скобок - [(начало)и](конец).
Стандарт EMSI/IEMSI требует, чтобы программное обеспечение, реализующее
его спецификации, передавало в линию только 7-битные (от 0 Oh до 7Eh) посыл-
ки. Рекомендовано также «срезать» старший бит у всех принятых данных и толь-
ко потом их обрабатывать, рассчитывать CRC и т.п.
Так как среди посылок EMSI должны встречаться не только символьные дан-
ные, но и двоичные значения, например циклические проверочные коды (CRC)
или значения длины, они (чтобы не нарушать принципа 7-битности передавае-
мых данных) записываются четырьмя символами в виде шестнадцатеричной сим-
вольной записи. Единственным исключением является 32-битный CRC - он вы-
ражается восемью символами.
Что касается символьных данных из верхней половины полной таблицы ASCII,
то они записываются также в шестнадцатиричном представлении, признаком та-
кого значения является знак обратной косой черты, например \80 означает сим-
вол с кодом 128 (шестнадцатиричное значение 8 Oh). Для помещения самого
символа \ в текст приходится вставлять его дважды или использовать его код,
например \5с (5Ch - код символа \).
Основные этапы установления соединения EMSI
Предполагается, что модемное или иное соединение между двумя системами уже
установлено и никаких данных вызывающей системой пока не передавалось. От-
слеживание получения старт-символов других протоколов (например, описанных
выше YOOHOO или FTS-0001), возможно, но не является обязательным. Основ-
ные этапы установления соединения показаны в табл. 5.8-5.10. Далее в тексте под
обозначением <CR> понимается символ возврата каретки ODh.
Таблица 5.8. Этап 1 - EMSI IN IT (инициализация EMSI)
Номер состояния Вызывающая система Отвечающая система
1 Посылать <CR> Послать «EMSI_REQ» и, возможно,
пока не будет получен любой символ баннер (блок текстовой информации) и т.п.
2 Принять баннер и т.п.
Ждать появления в линии «EMSI_REQ» Ждать появления в линии «EMSIJNQ»
и если принято, передать в ответ и если принято,
«EMSIJNQ» и попытаться начать установление соелинения попытаться установить соединение
3 Если не принято «EMSI_REQ», Ожидать появления в линии «EMSIJNQ»,
то послать «EMSIJNQ» дважды, и, возможно, старт-символов
и, возможно, старт-символы других протоколов,
других протоколов попытаться установить соединение
За Передать <CR> Идти на шаг 3
4 Если принята последовательность EMSI_REQ, послать EMSIJNQ и попытаться установить соединение, иначе идти на шаг 3
Во время выполнения пунктов 1 и 2 (табл. 5.8) и отвечающая, и вызывающая
системы заканчивают все посылки символом <CR>. При выполнении пункта 3
вызывающая система не заканчивает посылки <CR>, так как он передается после
передачи возможных старт-символов протоколов. На шаге 4 вызывающая систе-
ма однажды заканчивает все посылки единственным знаком <CR>. Начиная со
второго этапа, все посылки заканчиваются <CR>.
Таблица 5.9. Этап 2А - процедура приема пакета установления соединения EMSI
Номер Состояние протокола и действие
шага
1 Счетчик попыток=0, параметры Т1 =20 секунд, Т2=60 секунд
2 Нарастить счетчик попыток на единицу
2а Если попыток больше 6, то завершить работу и сообщить о неудаче
2Ь Если система отвечающая, то передать EMSI_REQ, идти на п. 3
2с Если попыток больше одной, то передать EMSI_NAK, идти на п. 3
2d Идти на п.4
3 Т 1=20 секунд
4 Ожидать посылок EMSI - EMSI_HBT или EMSI_DAT,
или пока не истечет время одного из таймеров
4а Если истекло время Т2, то завершить работу и сообщить о неудаче
4Ь Если истекло время Т1, идти на п. 2
4с Если принято сообщение EMSI_HBT, идти на п. 3
4d Если принято сообщение EMSI_DAT, идти на п. 5
4е Идти на п. 4
5 Принять пакет EMSI_DAT
5а Если пакет принят нормально, то передать сообщение EMSI_ACK дважды и идти на п. 6
5Ь Идти на п. 2
6 Пакет EMSI DAT принят, выход из процедуры
Любая обработка данных принятого пакета EMSI_DAT должна делаться после
того, как на удаленную систему дважды отправлено сообщение EMSIACK. От-
правку предупреждения EMSIHBT рекомендуется делать раз в 7 с, пока обраба-
тывается пакет EMSI_DAT, чтобы избежать нежелательных задержек и коллизий.
Посылка EMSIHBT должна производиться только в том случае, если очевидно,
что удаленная система ожидает начала второго этапа установления соединения
EMSI.
Таблица 5.10. Этап 2Е> - процедура посылки пакета установления соединения EMSI
Номер Состояние протокола и действие
шага
1 Количество попыток=0, параметр Т1 =60 секунд
2 Послать пакет EMSI_DAT и нарастить число попыток на 1
2а Если попыток больше 6, то завершить работу и сообщить о неудаче
2Ь Идти на п. 3
3 Установить параметр Т2=20 секунд
4 Ожидать посылки EMSI пока не завершится время Т1
4а Если Т1 истекло, завершить работу и сообщить о неудаче
4Ь Если Т2 истекло, идти на п. 2
4с Если принято сообщение EMSI_REQ, идти на п. 4
Таблица 5.10. Этап 2В - процедура посылки пакета установления соединения EM5I
(окончание)
Номер Состояние протокола и действие
шага
4d Если принято сообщение EMSI_ACK, идти на п. 5
4е Если принято любое другое сообщение EMSI, идти на п. 2
5 Сообщение EMSI ACK принято, выход из процедуры
Сообщения EMSI
Ниже приведены используемые информационные последовательности, которыми
могут обмениваться EMSI-системы в процессе установления соединения. Дано
стандартное наименование последовательности, передаваемые данные, и далее сле-
дует краткое описание. Описания данных выражены в символьном представлении
(вспомним, что EMSI использует исключительно символы ASCII для коммуника-
ции), знак возврата каретки (ODh) отображается как <CR>, циклический провероч-
ный код как <сгс16>, пакет данных как <data_pkt>, длина пакета как <1еп1б>.
EMSI Inquiry
Данные:
**EMSI_INQ<crcl6xCR>
Описание:
EMSI Inquiry идентифицирует пославшую сообщение систему как EMSI-совмес-
тимую. Если в ответ система получает сообщение EMSIREQ (см. ниже), это зна-
чит, что отвечающая система также поддерживает EMSI-стандарт.
EMSI Request
Данные:
**EMSI_REQ<crcl6><CR>
Описание:
EMSI Request передается отвечающей системой, информируя вызывающую о сво-
ей EMSI-совместимости. Эта последовательность обязательно должна передавать-
ся до передачи любой другой информации, например имени системы или традици-
онного баннера - текста, предназначенного для чтения оператором и содержащим,
как правило, общую информацию о системе.
EMSI Client
Данные:
**EMSI_CLI<crcl6><CR>
Описание:
EMSI Client используется терминальными программами для сообщения вызыва-
емой стороне, что данной системой не поддерживается почтовая сессия FidoNet.
EMSI может с успехом использоваться не только для установления соединения двух
почтовых программ FidoNet, но и для автоматизации подключения пользователя
к системе BBS, и в этом случае со стороны пользователя передается последова-
тельность EMSI—CLI.
EMSI Heartbeat
Данные:
**EMSI_HBT<crcl6xCR>
Описание:
EMSI Heartbeat используется для предупреждения слишком больших пауз
(timeouts) в процессе установления соединения. Наиболее часто эта последова-
тельность используется, когда отвечающая система повторно присылает пакет
EMSIDAT.
EMSI Data
Данные:
* *EMSI_DAT<lenl6xdata_pktxcrcl6xCR>.
Описание:
EMSI Data передается обеими сторонами для обмена системной информацией.
EMSI Data - это пакет переменной длины. Следующие за заголовком 4 байта,
обозначенные выше как <1еп16>, определяют длину пакета данных, исключая
CRC и следующий за ним знак <CR>. Содержимое информационного пакета
<data_pkt> подробнее описано ниже в этом разделе.
EMSIACK
Данные:
* *EMSI_ACK<crcl6xCR>
Описание:
EMSI АСК передается обеими системами как подтверждение успешного приема
и пакета EMSI_DAT. Для подтверждения приема отличных от EMSI_DAT паке-
тов EMSI_ACK не используется. Лишние пакеты EMSI ACK должны быть про-
игнорированы.
EMSINAK
Данные:
**EMSI_NAK<crcl6xCR>
Описание:
EMSI NAK передается обеими системами как уведомление об отказе от принято-
го пакета EMSI_DAT. Для подтверждения приема отличных от EMSI_DAT паке-
тов EMSI_NAK не используется. Лишние пакеты EMSI_NAK должны быть про-
игнорированы.
Структура пакета EMSIJDAT
Пакет EMSI_DAT, входящий в описанную выше посылку EMSI Data, представ-
ляет собой «ядро» протокола EMSI. Он содержит информацию, необходимую для
проведения почтовой сессии. На рис. 5.8 приведена структура, описывающая со-
держимое пакета.
Дадим описание каждого поля изображенной на рис. 5.8 структуры пакета
EMSIJDAT.
Оттиск протокола (Fingerprint - «отпечаток пальца») содержит наименование
используемого протокола, то есть символы EMSI.
Список адресов (System address list). Это список всех адресов системы, раз-
деленных символом «пробел» (2 Oh). Для FidoNet это должен быть 4D или 5D
адрес в формате FidoNet. Для других сетей (EMSI разрабатывался как универ-
сальный стандарт) допускаются не-Fido адреса, например, символьные Internet-
адреса.
Пароль (Password). Пароль, передаваемый системой. Заметим, что сессия мо-
жет быть и беспарольной, в этом случае содержимое данного поля игнорируется.
Один пароль используется для всех предъявленных адресов. Регистр символов
пароля не имеет значения. Следующие за паролем поля заслуживают более под-
робного описания.
Строка флагов (link codes) - строка трехбуквенных параметров, обозначен-
ная в структуре пакета EMSI_DAT на рис. 5.8 как Link_codes (это обозначение
позаимствовано из FSC-0056), призвана описать желаемые условия соединения.
Флаги разделяются запятыми, новые флаги в списке допустимы. На момент
OS/2 System Editor - C:\FIDO\UTILS\emsLc □ □
File Edit Options Help
EMSI-DAT
fingerprint, “EMSI" /♦ "Оттиск" протокола (всегда "EMSI"; > ♦/
sy s t em_a ddre s s_li s t, /* Список адресов системы */
password, /* пароль */
link_codes, /* коды связи */
compa t ib i1i ty_codes, /♦ коды совместимости */
mailer_produc t_code, /* Код почтовой программы */
mailer_name, /♦ Название почтовой программы */
mailer_version, /* Версия почтовой программы */
mailer_serial_number: ASCII1; /* Серийный номер почтовой программы */
extra_f ield_l, /* Дополнительное поле 1 */
ex tr a_f i e 1 d_n: EMSI_addon;/* Дополнительное поле п */
end;
/* Дополнительное поле EMSI_addon представлено следующей структурой: */
EMSI_addon
product_lD, /♦ код продукта */
specific_data: ASCII1; /* Дополнительные текстовые данные */
end;
Рис. 5.8. Структура данных информационного пакета в посылке EMSI Data
& OS/2 System Editor - C:\FIDO\LOGS\emsi.log_______________ ;«
Fite Edit Options Help______ ___________
(EMSI) *
[2 :5049/12<®f idonet 2:5049/0®fidonet)
(pwdll)
(8N1)
(DZA,XMA, FNC)
(101)
(The Brake.1 (tm) Mailer)
(718.a8)
(9999)
(ТВJ REG)
([Beta test TEAM])
(TRX#)
([37babcld])
(TZ)
[[-240])
(TRAP)
(0 0)
(MOHft)
[[0])
(IDENT)
([Double Dozen]
[Kazan, Tatarstan, Russia]
[Amir Shabashvili]
[7 - 843 - 249-99xx]
[33600]
[V.34,HST,MO,XW,CM]')
Рис. 5.9. Пример данных, передаваемых как EMSI-DAT-пакет
написания стандарта использовались флаги, описанные ниже (по функциональ-
ным группам).
Флаги параметров вызова/ответа системы:
□ 8N1,7E1,7O2 и другие коммуникационные параметры. Первый символ озна-
чает количество бит (7 или 8), второй - четность (N, Е или О), третий -
количество стоп-битов. Это общепринятое обозначение параметров комму-
никационного порта.
Флаги параметров вызывающей системы:
□ PUA - «забираю почту для всех предъявленных адресов»;
□ PUP - «забираю почту только для основного адреса»;
□ NPU - «не забираю почту».
Флаги параметров отвечающей системы:
□ HAT - «не отдаю почту»;
□ НХТ - «не отдаю архивированную почту»;
□ HRQ - «не отдаю файловые запросы».
Коды совместимости (Compatibility codes). Коды совместимости представля-
ют собой строку флагов, которые определяют совместимость данной почтовой
системы с теми или иными протоколами. Флаги разделяются запятыми. Вызыва-
ющая системы должна перечислить в этом поле в первую очередь флаги протоко-
лов передачи файлов в порядке предпочтения (наиболее желательный должен
следовать первым). Отвечающая система должна вставить в это поле флаг только
одного протокола, выбранного для обмена, перед всеми остальными флагами.
Основные используемые флаги перечислены ниже, они разбиты по функцио-
нальным группам.
Флаги протоколов передачи файлов:
□ DZA - DirectZAP (вариант протокола Zmodem);
□ ZAP - ZedZap (вариант протокола Zmodem);
□ ZMO - Zmodem с блоками по 1 Кбайт;
□ JAN - протокол Janus;
□ KER - протокол Kermit.
Информационные флаги:
□ NCP - нет подходящих протоколов (неудача);
□ NRQ - файловые запросы не принимаются;
□ ARC - поддержка стандарта ARCmail 0.60;
□ ХМА - поддержка других способов сжатия почты;
□ FNC - преобразование имен файлов.
Последний флаг (FNC) означает, что все передаваемые протоколы должны со-
ответствовать стандарту MS DOS (максимум 8 символов имени и 3 символа рас-
ширения, то есть filename.ext).
Код почтовой программы (Mailer product code). Комитет по стандартам
FidoNet, FTSC устанавливает код для каждой программы, занимающейся обра-
боткой почтовых пакетов FidoNet. Почти все почтовые программы имеют такие
коды. В данное поле помещается шестнадцатиричное представление кода почто-
вой программы. Более подробно эти так называемые Product codes, уже упоми-
навшиеся в главе 2, описаны в стандарте FidoNet FSC-0046, а сами коды и форму
для заявки можно найти в FSC-0090.
Название почтовой программы (Mailer name). В этом поле помещается назва-
ние почтовой программы, которая посылает EMSI-пакет.
Версия почтовой программы (Mailer version). Здесь должен быть номер вер-
сии почтовой программы, то есть что-то вроде 1.0, 2.99 и т.п.
Серийный номер почтовой программы (Mailer serial number). Серийный но-
мер, дополнительная информация о версии и т.п. Это поле обычно выглядит как
Название<пробел>Версия/Серийный номер, то есть, например, так: AirMail
0.10/Beta-2.
Дополнительные поля данных (Extra fields). Дополнительные поля делают
протокол EMSI исключительно гибким. Авторы почтовых программ могут сво-
бодно создавать и использовать свои поля без нарушения общей совместимости
с уже имеющимся программным обеспечением, поддерживающим EMSI. Количе-
ство дополнительных полей не ограничено. Каждое такое поле содержит 2 строки
ASCII1:
□ PRODUCT-IDENTIFIER - идентификатор программы, уникальный при-
знак, определяющий программу, ответственную за обработку данного поля;
□ SPECIFIC—DATA - данные, представляющие собой произвольный текст, име-
ющий смысл для программы, описанной идентификатором в предыдущем
поле.
Есть несколько заранее определенных в стандарте EMSI дополнительных полей.
Мы опишем здесь поле IDENT. Назначение поля IDENT - общая идентификация
системы, включая информацию о поддерживаемом формате нодлиста и т.п. Струк-
тура данных выглядит следующим образом:
PRODUCT_IDENTIFIER: IDENT
SPECIFIC_DATA: имя_системы, город, имя_оператора, номер_те-
лефона, скорость_в_бодах, флаги: ASCII2
Используемые в поле SPECIFIC—DATA флаги представляют собой описанные
в главе 2 нодлистовые флаги. Пример использования поля IDENT можно видеть
на рис. 5.9.
Интерактивный стандарт EMSI (IEMSI)
Кроме описанного выше протокола EMSI, автором был разработан вариант IEMSI
(интерактивный EMSI), предназначенный для использования в терминальных сис-
темах, подключающихся к серверным системам типа BBS или хост-компьютеров.
Это типичный стандарт на установление соединения клиент-сервер. Он позволяет
при подключении к BBS или другой онлайновой системе сократить и упростить
процедуру подключения, выбрать желаемые установки используемых протоколов
передачи файлов, тип терминала и т.п.
Вводить все это вручную, как иногда делается, при использовании IEMSI не
нужно. IEMSI встроен в некоторые из терминальных программ, разработанных
под эгидой FidoNet (почти каждая почтовая программа имеет терминальную под-
систему). Подробное описание IEMSI выходит за рамки данной книги, при жела-
нии можно ознакомиться с особенностями этого стандарта (имеющего очень мно-
го общего с EMSI) в FSC-0056.
Заключение
На этом завершается знакомство с протоколами почтовой сессии FidoNet. Знание
материала этой главы пригодится для понимания тонкостей настройки почтовых
программ FidoNet, описанных в главе 7. Не обязательно запоминать детали уст-
ройства протоколов, последовательность передаваемых информационных паке-
тов - всего того, что так подробно описано выше. Но общее представление об ос-
новных протоколах почтовой сессии и понимание специфики каждого из них
совершенно необходимо, если вы хотите настроить выбранную вами почтовую
программу не кое-как, а с умом.
Глава VI
Аппаратное
и программное
обеспечение FidoNet
После прочтения этой главы у вас должно сложиться общее представление об
аппаратном и программном составе FidoNet-системы и основных принципах ее функ-
ционирования. Некоторые вопросы, например устройство порта RS-232, комму-
никационные драйверы FOSSIL, основы устройства и использования модемов,
изложены более подробно, так как эти знания потребуются вам в следующих гла-
вах книги.
Требования к компьютеру
Быстродействие
Требования, которые FidoNet предъявляет к компьютерной системе по современ-
ным меркам смехотворны. Поскольку большая часть программного обеспечения
сети была разработана во времена безраздельного господства операционной сис-
темы MS DOS, то по большей части оно чрезвычайно компактно и нетребователь-
но к оперативной памяти и быстродействию компьютера и модема.
Эти же DOS-программы, как правило, хорошо работают и под управлением мно-
гозадачных операционных систем Windows 95/98, IBM OS/2, Windows NT и UNIX,
если в состав ОС входит поддержка DOS-сеанса в качестве одной из задач. Для се-
мейства операционных систем фирмы Microsoft DOS-окна поддерживаются всегда,
операционная система OS/2 и некоторые версии UNIX могут быть сконфигуриро-
ваны для поддержки сеансов DOS (разумеется, есть и FTN-программы, разработан-
ные специально под многозадачные операционные системы).
Таким образом, аппаратная платформа, на которой устойчиво работает одна из
перечисленных операционных систем, является вполне достаточной для поддерж-
ки системы FidoNet. В приложении И классифицированы известные программы
FidoNet и для некоторых из них указаны минимальные требования к компьютеру,
предъявляемые данной программой. При составлении таблиц приложения 11 авто-
ром была использована информация из регулярно публикуемого в FidoNews «Спис-
ка программ FidoNet» Петера Поповича (Peter Popovich, адрес в FidoNet - 1:363/
264). Более подробно некоторые из упомянутых в списке программ описаны в сле-
дующих разделах книги.
Пользуясь таблицами из приложения И, вы можете «собрать» Fido-систему
почти под любой компьютер, который есть у вас под рукой.
Память
Большинство программ FidoNet нетребовательны к оперативной памяти компью-
тера, они превосходно чувствуют себя в пределах традиционных 640 Кбайт. Однако
это не означает, что дополнительная память FidoNet-Net системе совсем не нужна.
Существует множество программ Fido, которые «умеют» хорошо использовать па-
мять. Такие программы при увеличении объема оперативной памяти существенно
ускоряют работу.
Так, например, программа обработки эхо-конференций (тоссер), последова-
тельно обрабатывает большое количество файлов. Такого рода операции произ-
водятся значительно быстрее при наличии эффективного кеширования диска, что
требует дополнительной оперативной памяти или специального кеш-контролле-
ра. Некоторые из тоссеров (например, популярная программа FastEcho) имеют
в своем составе буферизацию обрабатываемой информации, существенно выиг-
рывающую в эффективности при использовании в качестве буфера расширенной
памяти DOS. В версии для OS/2 также автоматически захватывается потребное
количество памяти, повышая таким образом производительность всей Fido-сис-
темы. Измерения автора показывают, что при запуске под OS/2 этот тоссер мо-
жет «съесть» на пике нагрузки до 9 Мбайт памяти!
Другим примером FTN-программ, «пожирающих» память компьютера, являют-
ся редакторы эхо-почты, которые работают с большими архивами эхо-почты и нет-
мейла. Порой они также имеют развитый графический интерфейс пользователя.
Такие программы для эффективной работы тоже нуждаются в значительном объе-
ме памяти. Не случайно поэтому, что именно редакторы эхо-почты первыми из
программ, написанных для FidoNet, начали использовать расширенную память
DOS, как только появились спецификации на нее и вышли в свет первые мате-
ринские платы, поддерживающие XMS и EMS. Используемая автором програм-
ма редактирования почты FleetStreet для операционной системы OS/2 может по-
треблять в зависимости от режима и количества открытых окон до 4-5 Мбайт
оперативной памяти.
Почтовые программы, как правило, большой памяти не требуют. Но есть и ис-
ключения, например почтовая программа The Brake! Mailer, спроектированная
автором с использованием средств интерфейса OS/2; при загрузке она потребля-
ет до 3 Мбайт.
Кроме этих трех основных составляющих программного обеспечения FidoNet
многие другие вспомогательные программы и утилиты работают лучше и быстрее
при наличии дополнительной оперативной памяти. Например, обработчики нод-
листа, в функции которых входит дополнение текущего нодлиста с использова-
нием разностного файла - нодедиффа (глава 2) или составление индексных спра-
вочников к файлу нодлиста, существенно «тормозят» при нехватке оперативной
памяти.
Особняком стоит случай многолинейной системы, когда вы намереваетесь об-
служивать сразу несколько телефонных линий и/или соединений Internet. Тре-
бования к компонентам компьютерной системы в этом случае резко возрастают -
вам не только нужно добиться устойчивой работы многозадачной операционной
системы, как правило, чрезвычайно ресурсоемкой, но и запустить под ее управ-
лением несколько параллельно работающих задач, например почтовых про-
грамм и обработчиков принятой почты. Так, администрируемый сейчас автором
четырехлинейный узел FidoNet (две телефонные линии и две копии почтовых
Internet-FTN программ Binkd) требует для своей работы 32 Мбайт оперативной
памяти. При меньшем ее количестве система начинает ощутимо «тормозить».
Жесткий диск
Для системы FidoNet слишком большой жесткий диск не требуется. Узел FidoNet
вполне может существовать и на 20-30 Мбайт, и даже на меньшем объеме диска.
Все определяется вашим «аппетитом». База эхо-конференций, если не подвергать
ее регулярной упаковке с использованием соответствующих утилит, может за пол-
года вырасти в объеме до нескольких сотен мегабайт. А уж заведя скоростной мо-
дем и подписавшись на популярные файл-эхи, вы быстро обнаружите, что про-
странство на диске стремительно убывает.
Также обстоит дело и с быстродействием диска. В современных многозадачных
системах диск используется для организации пространства виртуальной памяти.
Ситуации, когда памяти не хватает по «вине» FidoNet-системы, хотя и не слиш-
ком часты, но случаются (см. предыдущий раздел). В подобных случаях вам как
раз и понадобится быстрый жесткий диск. Да и во всех остальных случаях работа
Fido-системы часто бывает связана с обработкой (архивацией, разархивацией,
чтением, записью) большого количества файлов. Тогда хорошая производитель-
ность дисковой подсистемы - важная составляющая эффективности вашего узла.
Коммуникационный порт
Необходимым требованием для успешной работы Fido-системы в ее традицион-
ном «телефонном» варианте является наличие у компьютера свободного комму-
никационного порта и подключенного к нему модема.
Любые конфликты коммуникационного порта с другим оборудованием, что яв-
ляется распространенным дефектом конфигурации компьютера, должны быть ис-
ключены. Необходимо хорошо представлять характеристики используемого вами
COM-порта. Стандарт RS-232, которому соответствует коммуникационный
порт самого распространенного в нашей стране компьютера IBM PC АТ, и его
общепринятая реализация подробно описаны в литературе [5. 27]. Далее будут
конспективно изложены основные сведения, которые могут потребоваться при
поиске свободного коммуникационного порта и его диагностике. Итак, вам пона-
добится следующая информация о выбранном для подключения модема СОМ-
порте вашего компьютера:
□ его номер;
□ тип разъема (9- или 25-штыревой);
□ максимальное быстродействие (тип UART);
□ наличие буферов FIFO;
□ используемые адрес и аппаратное прерывание (IRQ) (табл. 6.1).
Терминология
В стандарте RS-232 используется множество обозначений. Причем для наимено-
ваний сигналов интерфейса существует несколько эквивалентных систем таких
обозначений, утвержденных различными организациями по стандартизации. Что-
бы исключить путаницу, мы используем наиболее распространенные мнемоничес-
кие обозначения. Они приведены с необходимыми комментариями в табл. 6.2.
Разъемы и сигналы
Существует два стандарта на интерфейсный разъем RS-232: DB-25 и DB-9. Вне-
шний вид этих разъемов и нумерация контактов приведены на рис. 6.1.
Несмотря на значительное различие в количестве контактов, это один и тот же
интерфейс - можно использовать и DB-25, и DB-9. Иногда компьютер бывает
укомплектован обоими типами разъемов, реже применяется разьем одного и того
же типа. Вам обязательно нужно хорошо пред-
ставлять, какой именно разъем соответствует
коммуникационному порту, к которому намере-
ваетесь подключить модем, поскольку от этого
зависит выбор кабеля для его подключения.
В табл. 6.3 систематизированы стандартные
наименования выводов описанных выше разъе-
мов. При этом редко используемые или неис-
пользуемые вовсе контакты опущены; вы може-
те найти их полную таблицу, например, в [3.1].
Быстродействие и тип UART
Последовательный адаптер, или коммуникаци-
онный порт стандарта RS-232, впервые появился
в виде дополнительного модуля, вставляемого в слот расширения, в персональ-
ном компьютере фирмы IBM. Основой адаптера была микросхема асинхронно-
го приемопередатчика UART (в то время микросхема INS8250 фирмы National
Semiconductor). Эта микросхема работает следующим образом.
Передача:
1. Считывание передаваемого символа с системной шины компьютера (считы-
вание производится в параллельной форме, то есть все биты символа счи-
тываются одновременно).
13
ооооооооооооо
оооооооооооо
14
25
DB9
5
о о о о о
о о о о
6
9
Рис. 6.1. Внешний вид
разъемов RS-232 со стороны
компьютера
Таблица 6.1. Параметры коммуникационных портов компьютера IBM PC АТ
Имя порта MS-DOS Адрес ввода/вывода Линия прерывания IRQ
С0М1 3F8H IRQ4
COM2 2F8H IRQ3
COM3 ЗЕ8И IRQ3
COM4 2Е8Н IRQ4
Таблица 6.2. Сокращения, используемые в стандарте RS-232
Сокращенное Полное название название и его перевод Комментарии
Общая терминология
UART Universal Asyncronous Receiver Название основной микросхемы последовательного
Transiver (Универсальный асинхронный приемопередатчик) порта
DTE Data Terminal Equipment (Терминальное оборудование) Компьютер или терминал
DCE Data Communication Equipment (Коммуникационное оборудование Как правило, это модем )
Названия интерфейсных сигналов RS-232
RxD Received data (Принятые данные) «1» передается как низкий уровень, «0» как высокий
TxD Transmitted Data (Переданные данные) «1» передается как низкий уровень, «0» как высокий
DTR Data Terminal Ready Терминальное оборудование, в качестве которого
(готовность терминала) может выступать компьютер, сообщает, что оно включено и готово к обмену
DSR Data Send Ready DCE (то есть модем) сообщает о своей готовности
(готовность к передаче данных) к обмену, причем логический «0» на выводе DSR означает необходимость отключиться от телефонной линии
RTS Request То Send DTE (компьютер) запрашивает у DCE (модема)
(запрос на передачу) разрешения на передачу данных
CTS Clear То Send DCE (модем) отвечает компьютеру согласием
(Готовность к передаче) на сигнал RTS
RI Ring indicator Модем сигнализирует компьютеру
(индикатор вызова) о попытке установления соединения
DCD Data Carrier Detect (обнаружена несущая) Модем сообщает, что соединение установлено
Таблица 6.3. Основные сигналы интерфейса RS-232 для разъемов DB-25 и DB-9
Тип разъема Название сигнала Направление DTE-DCE Описание и комментарии
DB-25 Номер вывода DB-9 Номер вывода
1 FG — Защитное заземление (Frame Ground)
2 3 TD —> Передаваемые данные (Transmitted Data, TxD)
3 2 RD <— Принимаемые данные (Received Data, RxD)
4 7 RTS —> Запрос на посылку (Request То Send)
5 8 CTS <— Готовность к посылке (Clear То Send)
6 6 DSR <— Данные готовы к передаче (Data Set Ready)
7 5 SG — Сигнальная земля (Signal Ground, GND)
8 1 DCD <— Обнаружена несущая (Data Carrier Detect)
20 4 DTR —> Терминальное устройство готово (Data Terminal Ready)
22 9 RI <— Индикатор вызова (Ring Indicator)
2. Приведение полученных данных в последовательность битов путем выпол-
нения параллельно-последовательных преобразований.
3. Дополнение полученного кода стартовым битом, стоповым битом и (воз-
можно) проверочным битом четности.
4. Передача сформированного сигнала на внешний интерфейс с заданной ско-
ростью.
5. Сообщение о готовности к передаче следующего символа установкой соот-
ветствующего сигнала внешнего интерфейса.
Прием:
1. Прием данных со стороны внешнего интерфейса в последовательной форме.
2. Проверка принятых данных на соответствие ожидаемой структуре (старт-
бит, информационные биты, проверочный бит) и формирование сигнала об
ошибке при ее обнаружении.
3. Проверка правильности принятых данных на основании бита четности и вы-
дача сигнала при обнаружении ошибки.
4. Выполнение последовательно-параллельного преобразования и передача
данных в параллельной форме на шину компьютера.
5. Сообщение о приеме символа.
Микросхемы UART первых выпусков поддерживали следующие дискретные
скорости: 50, 75, 110, 150, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400 бит/с. За
прошедшие годы микросхема UART неоднократно модернизировалась. Микросхе-
мы INS8250 в настоящее время практически не используются, им на смену пришли
UART серии 16450 (при этом были добавлены скорости 57600 и 115200 бит/с),
а затем 16550. Эти микросхемы полностью совместимы с предшествующими 8250
и 16450; они могут работать в режиме совместимости под управлением программ-
ного обеспечения, разработанного для UART 8250 или 16450.
Буфер FIFO
Одним из отличий микросхем UART 16550 является наличие буферных регистров
FIFO (First In - First Out: «первым пришел - первым вышел»). Буфер FIFO имеет
размер от одного до шестнадцати байтов (размер буфера конфигурируется про-
граммно), позволяя осуществлять буферизацию передаваемой информации, резко
снижая вероятность потерь данных, столь характерных для микросхем без FIFO.
В новых версиях UART размер FIFO может быть увеличен (например, в мик-
росхеме UART 16650 размер буфера FIFO составляет 32 байта).
Правильная настройка FIFO входит в число базовых знаний, необходимых для
понимания принципов конфигурирования модемной подсистемы вашей Fido-стан-
ции. Конфигурация FIFO осуществляется настройкой как COM-порта, так и моде-
ма. Для настройки буфера FIFO COM-порта в операционной системе Windows 95
используйте приложение System (Система) из папки Control Panel (Панель Управ-
ления). Пример настройки изображен на рис. 6.2.
Диагностика
В настоящее время еще встречаются компьютеры с нестандартными СОМ-пор-
тами. Например, если в вашем распоряжении имеется какой-нибудь «реликт»,
г
gg
Общие Установка связи |
-Параметры связи---------- — -
Диты данных. [з
Четность: |не проверяется
Итоговые биты р
Общие | Диагностика |
Добавить., |
Параг)
Мех
[Дополнительная настройка порта
Дт
нал
г"Р Иатользреатьбуферы FIFO (требуется совместимость UART с 1655(fy
| Чтобыустранить ошибки, выбирайте минимальные знамения,
; Чтобы ускорить работу, выбирайте максимальные значения.
I ОК
Буфер приема: Меньше (1)
Больше 04)
Отмена [
Пополнению |
X
Буфер передами: Меньше (1)
J Больше (16)
Рис. 6.2. Настройка буфера FIFO с помощью приложения System
операционной системы Windows 95
максимальная скорость его COM-порта может быть не 115200 бод, как у любого
современного компьютера, а 19200. Эксплуатировать такой компьютер с модемом,
поддерживающим стандарт V.34, возможно только на скорости до 14400 бод. Да
и найти свободный коммуникационный порт часто бывает непросто. Лучше всего
для решения подобных проблем воспользоваться специализированными програм-
мами-тестерами. Например, для DOS написано множество тестирующих про-
грамм (Checklt, РССнеск, Norton Utilites и др.), и в их составе есть подсистемы,
работающие с коммуникационными портами. Но в первую очередь стоит обра-
тить внимание на утилиты, входящие в состав самой операционной системы, -
они-то всегда под рукой. Кое-что можно сделать и до момента загрузки операци-
онной системы. Так, распространенные программы загрузки для компьютеров
IBM PC АТ обыкновенно выводят на экран сообщения об имеющихся СОМ-пор-
тах и их адресах (графа «Serial Ports» на рис. 6.3).
После загрузки операционной системы можно воспользоваться «штатными»
средствами, которые существенно разнятся в зависимости от типа OS. Рассмот-
рим основные приемы диагностики последовательных портов компьютера для
всех популярных операционных систем.
DOS. Для операционной системы DOS самым простым способом проверки
«живости» коммуникационного порта является использование команды mode:
С: \FIDO>mode coml
Status for COM1 :
Retry-NONE
C: \FIDO>
Award Software, Inc.
System Configurations
CPU Туре Co-Processor PENTIUM-S Installed lOOMhz Base Memory : Extended Memory : Cache Memory 640K 15360K 256K
CPU Clock
Diskette Drive A : : 1.44M, 3.5 in. Display Type : EGA/VGA
Diskette Drive В : : None Serial Ports 3F8 2F8
Pr i . Master Disk : : LBA ,Mode 4, 1285 MB Parralel Port(s) : 378
Pr i . Slave Disk : None EDO DRAM at Row(s): 0
Sec . Master Disk : : None SDRAM at Row(s) : None
Sec . Slave Disk : None L2 Cache Type Pipeline Burst
Рис. 6.3. Вывод сводных результатов тестирования компьютера перед загрузкой
операционной системы (AWARD BIOS)
Реакция, подобная приведенной выше, означает, что порт за номером 1 сущест-
вует и активен. Если же он не работает, вас ожидает следующее сообщение:
С: \FIDO>mode com4
Illegal device name - COM4
C:\FIDO>
Можно также воспользоваться входящей во все версии DOS, начиная с пятой, ути-
литой MSD - Microsoft Diagnostics (в состав эмулятора DOS операционной системы
Windows 95 эта программа не входит). Рис. 6.4 представляет экранный вывод MSD.
Для полноценной проверки работоспособности COM-порта с использованием
тестирующих программ Checklt или РСснеск вам понадобится разъем-заглушка,
соединяющий выходные и входные сигналы RS-232. Для его изготовления нужно
взять соответствующий разъем и замкнуть выводы в соответствии с рис. 6.5.
Рис. 6.4. Диагностический экран программы Misrosoft Diagnostics, показывающий
характеристики коммуникационных портов
Рис. 6.5. Схема
тестовой заглушки
для СОМ-порта
Windows 95. В Windows 95 проще всего просмотреть
конфигурацию коммуникационных портов, открыв Па-
нель управления (Control Panel) и запустив утилиту
Система (System). Выбрав закладку Устройства (Devi-
ces), вы получите информацию о доступных СОМ-пор-
тах (рис. 6.6).
Можно также проверить работоспособность комму-
никационного порта и определить его номер в Windows,
подключив к проверяемому порту манипулятор «мышь»
и выполнив диагностику модема (Панель управления =>
Модемы). После чего, выбрав закладку Диагностика
(Diagnostics), можно получить информацию о портах
и подключенных к ним устройствах (рис. 6.7).
Под Windows 95 можно также использовать программу Microsoft Diagnostics,
упомянутую в предыдущем разделе. Для этого нужно скопировать файл msd.exe
из операционной системы DOS.
Windows NT. Для просмотра доступных COM-портов используйте приложение
Ports из папки Control Panel. Приложение позволяет просматривать параметры
свободных COM-портов (то есть если порт занят каким-либо устройством, напри-
мер мышью, то он в этом приложении не будет виден). Пример экранного вывода
программы Ports представлен на рис. 6.8.
IBM OS/2. Для операционной системы OS/2 существует множество спосо-
бов «исследования» свободных COM-портов. Самым простым из них является
* —- - - . ........-... —...-....... ййму'йшмГ)
r’*эпу .................{Свойства: Последовательный порт (СОМ1) ИЕЗ
Общие.. | Конфигурации 11 Общие ^Параметры порта | Драйвер Ресурсы |
' & Устройства по типам Г Устр<
Последовательный порт (СОМ1)'
Й за Аудио-, видео- и игровые кон
ЙВидеоадаптеры
Ей £3 Дисковые накопители
ЕЕ "У Другие устройства
ЕЙ Клавиатура
1+F* 3© Контроллеры гибких дисков 5
ЩКонтроллеры жестких дисков:;
SУЦВ Модем
Э- Монитор
ЕЙ Мышь
SПорты СОМ и LPT
1/ Порт принтера (LPT1)
Последовательный порт
У/ Последовательный порт
a KJ Сетевые платы
, ' Свойства | Обновить [
Перечень ресурсов:
Тип ресурса
J Значение
04
Диапазон ввода/вывода 03F8-03FF
кгрньи}' шинах, турация йООй
Изменить значение.,, Р Стоматическая настройка
Список кОНфликтуюшихустройств:
Конфликты не обнаружена.
Отмена
Рис. 6.6. Просмотр конфигурации доступных коммуникационных
устройств в операционной системе Windows 95
Свойства: Модемы
Общие Диагностика |
Дополнительные сведения...
В Windows были обнаружены еле
усталое ленные устройства:
Порт | Устройство
^С0М1Мышь для последовательно
Courier V.Everything
•Параметры порта——----------—....—
Порт. COM2
Прерывание: 3
Адрес: 2F8
UART: * NS16550AN
Максимальная скорость: 56 000 бод
Драйвер [ Сведения., |
|И||ИИИИ
- Courier V.Everything---------------
Идентификатор; USRCR_Modem23
Коман...| Отклик
ДТП ОК
ATI2 ОК
ATI3 ОК
ATM ОК
ATI5 ОК
ATI6 ОК
ATI7 ОК
AT+FCL... ОК
Рис. 6.7. Поиск и диагностика COM-порта с помощью манипулятора «мышь»
Cancel
Advanced.. |
Help |
Advanced Settings for COM2:
COM Port Number: RHBBEI I 0K I
Base I/O Port Address: [Default “rj Cancel |
Interrupt Request Line (IRQ): де|р |
f Default
P FIFO Enabled
Рис. 6.8. Отображение параметров свободного
COM-порта с помощью приложения Ports
операционной системы Windows NT 4.0
использование утилиты mode в ее OS/2 варианте. Экранный вывод mode/2 отли-
чается от того, что дает DOS-вариант. Под OS/2 mode намного информативнее:
С: \FIDO>mode coml
baud 57600 parity = NONE
databits 8 stopbits = 1
ТО = OFF XON = OFF
IDSR = OFF ODSR = OFF
OCTS = ON DTR OFF
RTS = HS BUFFER = ON
С:\FIDO>
Если COM-порт отсутствует либо неисправен:
С: \FIDO>mode com4
SYS 162 0 : The COM port specified is not installed.
C:\FIDO>
Более подробную информацию можно получить с использованием системной
утилиты rmview.exe (рис. 6.9).
Под OS/2 также можно с успехом воспользоваться программой msd.exe.
Модем
Модем совершенно необходим для организации подключения к FidoNet, случаи
участия в Fido без использования прямого подключения модема к компьютеру -
редкость. В нашем случае подойдет любой модем. В нодлисте до сих пор встреча-
ются узлы с модемами V22bis (2400 бод), но все же они безнадежно устарели.
Рис. 6.9. Фрагмент вывода системной утилиты RMVIEW
для операционной системы OS/2 Warp
Объем доступной информации в FidoNet таков, что с помощью модема V22bis
вы либо не сможете воспользоваться данными в полном объеме, либо создади-
те трудности для других участников сети, использующих для подключения тот
же узел.
Фактически минимальным стандартом сегодня является модем V32bis с мак-
симальной скоростью 14400 бод. Самые же распространенные в сети современ-
ные модемы поддерживают максимальную скорость 28800 (стандарт V34) или
33600 бит/с (стандарт V34+).
Конструктивно модем может быть изготовлен либо как отдельная плата, встав-
ляемая в слот на материнской плате компьютера (внутренний модем), либо в виде
отдельного корпуса с блоком питания, который подключается к последователь-
ному порту компьютера специальным кабелем (внешний модем).
Внутренний модем не занимает разъем коммуникационного порта, вместо
этого он создает дополнительный COM-порт, обычно COM3 или COM4, а вне-
шний модем намного удобнее в использовании, поскольку имеет органы управ-
ления и индикации.
Выбирая модем, следует также обратить внимание на такие характеристики,
как возможность программной замены основной управляющей программы моде-
ма (на жаргоне - «апгрейд»), разновидность исполнения - внутренний или вне-
шний. Дополнительные же возможности вроде приема факсов или использова-
ния в режиме автоответчика не нужны (с точки зрения использования модема для
передачи данных FidoNet).
Все имеющиеся сейчас на рынке модемы достаточно хороши для использования
в FidoNet. Для более подробного изучения вопроса рекомендуется обратиться к спе-
циальной литературе [1.5, 3.1] и, уже подключившись к FidoNet, к эхо-конферен-
циям RU . MODEM, RU. USR, RU. USR. CHAINIK, SU. INPRO и SU . HARDW. HSMODEM.
Минимум необходимой для понимания книги информации приведен в следую-
щих двух разделах.
Знакомство с модемом
Модем - это внешнее по отношению к компьютеру устройство. Даже если он из-
готовлен в виде платы расширения и вставлен внутрь компьютера, все равно это
внешнее устройство и подключено к компьютеру точно так же как и внешний
модем, через коммуникационный порт. В FidoNet модем обычно используется как
устройство с асинхронным интерфейсом, то есть внешний интерфейс модема и по-
следовательный порт компьютера при передаче данных часть из них интерпрети-
рует как управляющие сигналы (старт- и стоп-биты).
Режимы работы модема
У модема два основных режима работы: командный, когда модем интерпретирует
принимаемые через порт данные как команды и отвечает на них, и режим связи,
когда соединение установлено и модем принимает/передает данные, являясь как
бы удлинителем COM-порта и соединяя ваш компьютер с другим. Кроме этих
двух режимов, многие модемы способны работать в режиме выделенной линии,
а также поддерживать синхронный режим работы, но для наших целей вполне
достаточно использовать модем как асинхронное устройство в режиме команд или
установленной связи.
Командный режим модема устанавливается в следующих случаях:
□ при включении устройства;
□ при первой инициализации;
□ при обрыве соединения;
□ при выходе из режима передачи данных по команде «прерывание» (escape).
Режим передачи данных устанавливается всего в двух случаях:
□ при удачной попытке установления соединения;
□ при выполнении самотестирования.
Программы-эмуляторы терминала
Для изучения модема вам понадобится терминальная программа (терминал), ко-
торая превратит компьютер в интерфейсное устройство между вами и коммуни-
кационным портом. Терминальная программа имитирует текстовый терминал -
устройство, состоящее из текстового экрана, клавиатуры, последовательного пор-
та и небольшого блока управления. Некогда такие устройства были чрезвычайно
популярны и применялись для подключения к большим компьютерам, теперь для
этой цели используются терминальные программы. От забытых терминалов оста-
лось несколько стандартов на раскладку клавиатуры и способ представления ин-
формации на экране:
□ TTY. Это телетайп, самый простой текстовый терминал. Черно-белые буквы,
ничего лишнего;
□ ANSI. Стандарт ANSI предоставляет возможность выводить на экран цветные
символы и позиционировать курсор, ориентируясь по вкрапленным в текст так
называемым escape-последовательностям. Далее приведен пример данных, по-
ступающих на вход ANSI-терминала, при отображении в кодовой таблице
ASCII (см. рис. 6.10). На рис. 6.11 изображена картинка, которая выводится на
экран ANSI-терминалом при получении файла, содержащего процитирован-
ную выше последовательность символов. В состав MS DOS и OS/2 входит
ANSI-драйвер, позволяющий выводить на экран текст в ANSI-стандарте. Для
этого нужно использовать команду type <имя файла с текстом ANSI>. Кар-
тинка, изображенная на рис. 6.11, получена именно таким способом;
□ AVATAR. Это расширенный по сравнению с ANSI и усовершенствованный
стандарт на текстовый терминал. Как отдельное терминальное устройство
AVATAR никогда не существовал, он был создан участниками FidoNet как
более быстрый и удобный по сравнению с ANSI стандарт на эмуляцию тек-
стового терминала;
□ VT52, VT100, VT102, VT220. Терминалы серии VT - это стандарты фирмы
DEC, в свое время популярного производителя малых многотерминальных
компьютеров. Самый старый и самый примитивный стандарт - VT52. VT100,
VT102 и VT220 новее, они известны как стандарты для подключения к UNIX.
Все терминальные VT-системы совместимы снизу вверх.
И 03/2 System Editor - C:\FiDO\LOGS\adsi-data.txt_______- ,______________\ | ° | □
\ File Edit Options Неф_________________~_____«______________________ ____________
< -[Опь-[2 J«-[34Ш|------[7Cj--------1<- [ЗС|-|-[бС|-|-[6С|-------[6С|-----1
* - [ sH u+-[5C|-1
|-[31niHHHHB^[l;33i<-[0;34mH-[5CrJ-[31nf-[l;33ir®40;34mi-1 |-[31пЯ
I Hs4u-[34mL—j |^^[l;33n^[0;34ml1-[4cH-[31nOBBtlli^5f"[0;34mLl
| -[5c|-[31ire-[s-[u-[34mL|-[4c|-[l;33ir®-[0;34mL1 |-[31пИИИк Н^ЗЗпЩ
*-[0;32ro§*-[34mL|*-[3CrJ*-[31nij*-[l;33nffl^-[0;32in®-[34mL-|*-[s*-[u |*-[31п1ДД|
* - [ 3 4m I-1 *- [ 1; 3 ЗтЦЦЩ$Ц|*- [ 0; 3 2m^*- [ 3 4m i-j pi *- [ 3 [ 1 ; 3 ЗтУЦДЦр- [ s-^- [ u
[ 0; 34m I—j[4C |[31тДр-[3 2m$|*-[34тЦ r-i-<-[l;33m^h~ [0;32m^~ [34тЦ Ц
- [32пв-[31тЙЬ[32т^в-[1;ЗОп|0НО;34т| p«-[31п>- [1;ЗЗтЩ- [0;32i®
* -[ s*~ [u-*-[1; 3 Ontiyy*-[0; 34m | К [3 [ 1; ЗЗтЖИ|<- [ 0 ; 3 2mjg^- [ 1; 3 Omjjj
* -[0;34m| |-[31т|ЙН [s- [u*- £ 3 2 [l;33nflH^[0;34mL|-[3C|
4-[31m^H^[l;30njN<-[0;34m| ^"-[ХгЗЗпДМ-[ 0 r 3 2m§^- [ s*~ [u-*- [ 1,3 Ont:;*- [ 0; 34m |
Рис. 6.10. Пример данных, поступающих на вход ANSI-терминала
о«
: 2:5049/15
О» I Max BBS •
FiDO
aka
Phone:
work
SysOp
35-50-64
22:00-7:0
Max Iwano
2:5049/13
Рис. 6.11. Пример текстовой ANSI-графики
..
Мах Гыапоы *4ysOpj -J
2':ЙМ87Л‘3 i WBD/ ’
504ШI
В качестве терминальной программы подойдет любая из десятков распростра-
ненных бесплатных и условно-бесплатных (shareware) программ. Подойдет даже
входящий в состав Windows 95/98/NT Hyper Terminal (программа связи), хотя
это и не лучший выбор.
Система команд модема
Для начала запустите терминальную программу и настройте ее на СОМ-порт,
к которому подключен модем. В случае использования Hyper Terminal, откажи-
тесь от предложения создать новое соединение, которое обычно выводится при
его запуске, нажав Escape, наберите на клавиатуре латинские символы АТ и на-
жмите Enter. Если терминальная программа «видит» модем, то на экране появит-
ся его ответ в виде символов ОК. Если при наборе на клавиатуре на экране терми-
нала ничего не отображается или вместо ответа модема на экран выводится
символьный «мусор», это означает, что настройка выполнена неправильно. Пред-
положим, что у вас все получается и вы видите на экране ОК. Первый шаг сделан.
Самое время обратиться к руководству и изучить основные команды.
Вообще говоря, у большинства моделей модемов свой набор команд. Но сход-
ства больше, чем различий, так как все имеющиеся на рынке модемы Hayes-co-
вместимы, то есть они поддерживают минимальный набор команд, некогда вве-
денный как отраслевой стандарт для модемов фирмы Hayes Microcomputer
Product (модемы серии SmartModem). Иногда этот стандарт называют АТ-коман-
дами, так как почти все командные строки в этом стандарте начинаются с симво-
лов АТ (от англ, attention - «внимание»). При вводе командной строки она долж-
на начинаться с АТ, затем следует одна или несколько команд, при вводе они
попадают в командный буфер и посылаются на исполнение нажатием Enter.
На рис. 6.12 изображен диалог с модемом в программе Hyper Terminal, где опе-
ратор ввел сначала команду АТ (ответ ОК, то есть «готов к работе», сама команда
Fl Ml Q0 UI Х7
PARITY=N
ОМ
FARrn
file Edit View Call Transfer Help
&C1
&S0
B0 Cl El
BAUD=300
DIAL=PULSE
&A3 &B1
&P0 &R2
sou<
sov<
Mame
souaml.rtf
telegr.rtf
vacation.rtf
New Connection - HyperTerminal
Mame
micq
oldmail
OK
ati4
USRobotics Courier U.Everything Settings...
HOOK
U0RDLEM=8
TIMER
&D2
&T5
&G0 SHI &I0
5X0 8Y1 zN6
&K1 &L0
&M4 &N0
Hane
^tcut tG
hratat
Shorten
Cuttip*
SDUi
SOUf
300=000
308=002
316=000
324=150
332=009
340=000
348=000
356=000
301=000
309=006
317=000
325=005
333=000
341=000
S49=000
S57=000
302=043
310=007
318=000
326=001
334=000
342=126
350=000
303=013
311=070
319=000
327=000
335=000
343=200
351=000
S04=010
S12=050
SZ0=000
328=008
336=000
344=015
352=008
305=008
313=000
321=010
329=020
337=000
345=000
353=000
306=002
314=001
322=017
330=000
338=000
346=000
354=064
307=060
315=000
323=019
331=000
339=000
347=000
355=000
OK
LAST DIALED #:
Start | Connected 0:00:43
i Auto detect. [ЗЙ08-М-1
Рис. 6.12. Пример работы модема в командном режиме
с использованием программы Hyper Terminal
АТ не видна), а затем команду АТ 14, которая для модемов US Robotics означает
директиву выдачи текущего состояния модема, что и было сделано. Символьные
последовательности на экране - это основные параметры модема, выраженные
большей частью через соответствующие АТ-команды. Так, ответ модема на коман-
ду 14 начинается с ВО, и это значит, что модем находится в состоянии, которое
устанавливается при выполнении команды АТ ВО.
Существует два набора АТ-команд: основной и расширенный. Они приведены
в табл. 6.4 и 6.5 соответственно. Команды современных модемов существенно рас-
ширены относительно данных, приведенных в этих таблицах. Набор команд ва-
шего модема следует искать в руководстве к нему.
Таблица 6.4. Стандартный набор АТ-команд модема
Команда Назначение и комментарии
+++ Перейти из режима данных в режим команд, сохраняя соединение. Когда ваш модем находится
в режиме связи, ввод «+++» позволяет ему перейти в режим команд, сохраняя связь
с удаленным модемом.
Пример: +++
А Команда автоответа. Подключает модем к телефонной линии в режиме ответа.
Пример: АТ А
А/ Повторить последнюю команду. Не требует АТ-префикса и нажатия «Enter».
Пример: А/
АТ Префикс командной строки (Attention sequence). С АТ должна начинаться каждая строка команд
модема. По этим символам модем определяет скорость работы терминала, длину символа
и метод контроля четности.
Пример: АТ
Вп Протокол для работы на 1200 bps:
0 - протокол CCITT V.22 при работе на 1200 bps и протокол СОТТ V.21 при работе на 300 bps;
1 - протокол Bell 212А на 1200 bps и Bell 103 на 300 bps (по умолчанию);
2 - протокол CCITT V.23. Для отвечающего модема устанавливается скорость приема 75 bps,
передачи - 1200 bps;
3 - протокол СОТТ V.23. Для отвечающего модема устанавливается скорость приема 1200 bps,
передачи - 75 bps.
Пример: АТ ВО
Сп Управление несущей:
0 - запрещает передачу несущей;
1 - разрешает передачу несущей. Пример: АТ СО
D Команда набора номера. Инструктирует модем автоматически набрать телефонный номер.
За командой D может следовать телефонный номер, символы «#» и «*», модификаторы L,
Р, R», S=n, Т, W, @, I, (точка с запятой), (запятая). Назначение некоторых модификаторов:
S - набор хранимого номера;
W - ожидание гудка в линии;
@ - ожидание тишины в линии;
; - возврат в командный режим после набора номера;
/ - пауза 1 /8 секунды;
I - краткая временная задержка;
, - задержка (время - по содержимому регистра 58).
Пример: AT DT 8 (843) 249-9900.
(Модем тональным методом (Т) набирает телефонный номер 88432499900)
Таблица 6.4. Стандартный набор АТ-команд модема (продолжение)
Команда Назначение и комментарии
Еп Эхо команд модема (режим отображения символов на экране). Определяет, должен ли модем возвращать терминалу символы команд, которые вы набираете в командном режиме: 0 - эхо-отображение выключено; 1 - эхо-отображение включено (по умолчанию). Пример: AT ЕО
Нп Подключение модема к телефонной линии: 0 - Модем отключается от линии («кладет трубку»); 1 - модем подключается к линии («поднимает трубку»). Пример: АТ НО
In Информация о модеме: 0 - тип модема (трехбуквенный цифровой код); 1 - контрольная сумма ПЗУ; 2 - возвращает ОК, если контрольная сумма правильна ПЗУ, ERROR в случае ошибки; 3 - дата выпуска и номер версии ПЗУ и название модема; 4 - конфигурация аппаратуры модема. Пример: АТ 13
Ln Громкость встроенного динамика модема: 0 - минимальная; 1 - минимальная; 2 - средняя (по умолчанию); 3 - максимальная. Пример: AT L1
Мп Режим использования динамика: 0 - звук всегда отключен; 1 - звук включен до обнаружения несущей (по умолчанию); 2 - звук всегда включен; 3 - звук выключен во время набора номера и включен до тех пор, пока не обнаружена несущая. Пример: АТ М3
On Возврат в режим данных после использования escape-символов для переключения в командный режим: 0 - возврат в режим данных немедленно; 1 - выполнить перетренировку эквалайзера (retrain) перед возвратом в режим данных. Этот параметр работает на скоростях 2400 и выше. Пример: АТ О1
Р или Т Метод набора номера. Команда Р выбирает импульсный набор номера (заводская установка). Команда Т - тональный. Это установки, которые будут использованы в команде D по умолчанию. Пример: АТТ. ( После этого по команде ATD499961 модем будет набирать заданный тональными сигналами)
Qn Выдача сообщений модемом. Команда определяет, будет ли модем возвращать ответы после выполнения или попытки выполнения команды: 0 - возвращать ответы (по умолчанию); 1 - не возвращать ответы. Пример: AT Q1
Sn? Просмотр значения в регистре п. Современные модемы имеют несколько десятков регистров, содержимое которых может изменяться командой ATSn=x (описана ниже). На рисунке 6.9, в нижней его части, видны столбцы значений этих регистров, определяющих основные параметры модема. Пример: AT S0?. (Модем выдает значение регистра S0 - регистр автоответа)
260 Аппаратное и программное обеспечение FidoNet
Таблица 6.4. Стандартный набор АТ-команд модема (окончание)
Команда Назначение и комментарии
5п=у Изменение значения регистра п на у. Пример: АТ 50=2. (Устанавливает значение регистра автоответа 50 равное 2)
Vn Вид сообщений модема. Если сообщения модема разрешены (команда Q0), то Vn определяет вид, в котором они будут выводиться - числовой или текстовый: 0 - числовой формат; 1 - текстовый формат (по умолчанию). Пример: AT V0
Xn Метод набора номера, выбор разрешенных диагностических сообщений. Команда определяет типы выдаваемых сообщений при попытке установления соединения и метод набора номера: 0 - модем игнорирует непрерывный гудок телефона и сигналы «занято». Разрешены сообщения 0-4 или соответствующие текстовые; 1 - модем игнорирует непрерывный гудок телефона и сигналы «занято». Разрешены сообщения 0-5, 10 и выше, или соответствующие текстовые; 2 - модем игнорирует сигналы «занято». Разрешены сообщения 0-6 и 10, или соответствующие текстовые; 3 - модем игнорирует сигнал набора («непрерывный гудок»). Разрешены сообщения 0-5, 7, 10 и выше, или соответствующие текстовые; 4 - модем распознает сигнал набора («непрерывный гудок») и сигналы «занято». Разрешены все сообщения. Пример: AT Х0
Yn Разрыв соединения при получении непрерывного нуля. Определяет поведение модема при получении long space - то есть состояния сигнала «space» большего, чем длительность одиночного символа: 0 - разрыв соединения запрещен (по умолчанию); 1 - разрыв соединения разрешен. Пример: AT Y1
Z Сброс модема. Выполняет сброс и загрузку конфигурационного профиля, из энергонезависимой памяти. Пример: AT Z
Таблица 6.5. Расширенный набор АТ-команд модема
Команда Назначение и комментарии
&Сп Состояние сигнала DCD - Carrier Detect (обнаружение несущей): 0 - Сигнал DCD выдается постоянно; 1 - Состояние сигнала DCD отражает состояние модема (по умолчанию). Пример: AT &С0
&Dn Обработка сигнала DTR («терминал готов»). Команда &D определяет реакцию модема на переход Вкл/Выкл сигнала DTR: 0 - модем реагирует на изменение сигнала DTR так, как задано командой &Мп; 1 - модем переходит в командный режим без разрыва соединения (как при приеме Escape- последовательности); 2 - модем разрывает соединение (если оно установлено) и запрещает автоответ до тех пор, пока сигнал DTR не вернется в состояние On (по умолчанию); 3 - модем разрывает соединение и выполняет сброс, как при включении питания; Пример: AT &D3
Таблица 6.5. Расширенный набор АТ-команд модема (продолжение)
Команда Назначение и комментарии
&Fn Восстановление заводской установки (считывание из ПЗУ). Модем восстанавливает значения команд и S-регистров из ПЗУ. Пример: AT &F
&Gn Защитный тон. Команда управляет выдачей так называемого «защитного тона». Этот звуковой сигнал сообщает телефонной станции (АТС), что на линии работает модем. Телефонные станции, используемые в России, не опознают защитный тон, поэтому не рекомендуется включать его (установить &G0): 0 - защитный тон выключен (по умолчанию); 1 - использовать защитный тон частотой 550Hz; 2 - использовать защитный тон частотой 1800Hz. Пример: AT &G0
&Jn Тип телефонного разъема 0 - RJ-1 l/RJ-41 S/RJ45S; 1 - RJ-12/RJ-13. Пример: AT &J0
&Ln Выбор типа телефонной линии: 0 - режим коммутируемой телефонной линии (по умолчанию); 1 - режим 2-х проводной выделенной линии. Пример: AT &L0
&Mn Синхронный/асинхронный режим работы 0 - выбирается асинхронный режим (по умолчанию); 1 - выбирается синхронный режим 1 (асинхронный вызов и затем переход в синхронный режим); 2 - выбирается синхронный режим 2 (запоминание номера вызова); 3 - выбирается синхронный режим 3 (ручной вызов). Пример: AT &М0
&Pn Отношение импульс/пауза для импульсного набора номера: 0 - 39/61 - стандарт для США, Канады и России (по умолчанию); 1 - 33/67 - стандарт для некоторых европейских стран. Пример: AT &Р0
&Rn Состояние сигналов CTS/RTS (только для синхронного режима). Данная команда работает только в синхронном режиме, в асинхронном режиме игнорируется
&Sn Состояние сигнала DSR («Устройство передачи данных готово»). Команда определяет обработку модемом сигнала DSR: 0 - DSR всегда в состоянии On; 1 - DSR устанавливается в On во время установления соединения и Off в тестовых режимах, в режиме команд и при наборе номера. Пример: AT &S1
&Tn Тестовый режим: &Т0 - прекратить любой выполняемый тест при получении команды; &Т1 - запустить локальный аналоговый тест; &Т2 - запустить локальный цифровой тест; &ТЗ - подготовить модем к выполнению удаленного цифрового теста по запросу другого модема; &Т4 - запрет удаленного цифрового теста; &Т5 - разрешение удаленного цифрового теста; &Т6 - начать удаленный цифровой тест; &Т7 - начать удаленный цифровой тест с самодиагностикой. Пример: AT &Т1
Таблица 6.5. Расширенный набор АТ-команд модема (окончание)
Команда Назначение и комментарии
&Vn Просмотр сохраненного конфигурационного профиля и активного профиля. Эта команда не
входит в расширенный список команд Hyes, но используется в популярном наборе микросхем
ROCKWELL и потому приведена здесь.
Команда выдает текущий профиль и один из профилей, сохраненных в ППЗУ модема (NVRAM):
О - просмотр профиля 0;
1 - просмотр профиля 1.
Пример: AT &V0
&Wn Сохранение текущей конфигурации в энергонезависимой памяти. Впоследствии сохраненные
значения могут быть восстановлены командой AT Zn.
0 - запись значений в профиль 0;
] - запись значений в профиль 1.
Пример: AT &С1 &D2 S0=0 &W1
&Хп Источник частоты синхронизации. Команда работает только в синхронном режиме.
&Yn Выбор автоматически загружаемого конфигурационного профиля. Команда определяет номер
пользовательского профиля, из которого будут читаться значения команд и S-регистров при
включении модема или после его сброса переходом On-Off цепи DTR в режиме &D3:
0 - использовать профиль 0 (по умолчанию);
1 - использовать профиль 1.
Пример: AT &Y0
&Zn=s Запомнить телефонный номера s в ячейке п. Сохраняет заданный номер в одной из ячеек
ППЗУ. Здесь:
п - номер ячейки, куда будет записан телефон (обычно 0 - 3);
s - номер в формате, используемом командой D.
Сохраненный номер может использоваться для автоматического набора в синхронном режиме 3
или в асинхронном режиме с помощью команды DS=n.
Пример: AT &ZO8 843 2499900
(Сохраняет в ячейке 0 телефонный номер 88432499900, который будет автоматически
набираться модемом по команде ATDS=0).
Вы можете свободно экспериментировать в терминальной программе почти со
всеми командами, приведенными в таблицах. Не стоит только включать синхрон-
ные режимы, так как модем при этом становится автономным устройством и вы-
вести его из этого состояния непросто без внимательного изучения документации.
Для наблюдения непосредственной реакции модема удобны команды, оперирую-
щие с линией, например АТА, ATH0 и АТН1 и т.п.
Ответные коды и символьные последовательности
В ответ на введенные команды модем в большинстве случаев отвечает «ОК» («ко-
манда выполнена успешно») или «ERROR» («ошибка в команде»).
На некоторые команды предусмотрены многострочные ответы, например рас-
печатка конфигурации устройства, пример которой (в ответ на команду АТ 14)
приведен на рис. 6.12.
Наиболее интересны и важны ответы, характеризующие состояние линии и уста-
новленного соединения. Все стандартные ответы Hayes-модемов сведены в табл. 6.6.
На самом деле у современного модема ответов гораздо больше, они покрывают весь
диапазон скоростей. Вы найдете их список в описании своего модема.
Таблица 6.6. Ответные коды модема
Символьный код Цифровой КОД Набор команд Комментарии
ХО XI Х2 хз Х4
ОК 0 + + + + + Команда выполнена без ошибок
CONNECT 1 + + + + + Соединение установлено на скорости 300 бод. (При условии выполнения команды AT Х0 соединение на любой скорости отображается как CONNECT)
RING 2 + + + + + На линии обнаружен звонок
NO CARRIER 3 + + + + + Потеря несущей или попытка соединения потерпела неудачу
ERROR 4 + + + + + Неправильный формат команды, переполнен командный буфер, или ошибка контрольный суммы (в ответ на команду АТ 12)
CONNECT 1200 5 - + + + + Соединение установлено на скорости 1 200 бод
NO DIALTONE 6 - - + - + Нет гудка в телефонной линии, когда «трубка поднята»
BUSY 7 - - - + + Обнаружен сигнал «занято» после набора номера
NO ANSWER 8 - - + + + По команде «АТ @» производилось ожидание молчания в линии в течении 5 секунд, команда выполнена неудачно (молчание не обнаружено)
CONNECT 600 9 - + + + + Соединение установлено на скорости 600 бод
CONNECT 2400 10 - + + + + Соединение установлено на скорости 2400 бод
Ответы могут выдаваться модемом в символьном или цифровом виде, в зави-
симости от конфигурации (команда AT Vn). В FidoNet обычно используются сим-
вольные ответы.
Строка инициализации
Для того чтобы привести модем в требуемое состояние, нужно в командном ре-
жиме послать на него командную строку Одним из распространенных подходов
является предварительное конфигурирование модема в терминальной программе
с записью результатов командой AT &Wn в ячейку постоянной памяти модема,
после чего восстановление зафиксированного состояния производится командой
AT Zn (п - номер ячейки). Однако если записанная конфигурация «сбилась» (та-
кое порой тоже случается), бывает трудно восстановить по памяти нужную ко-
мандную строку, поэтому лучше записывать в конфигурацию программ полную
строку инициализации модема.
Дальнейшее знакомство с модемом
На этом обсуждение модемов завершается; оно очень конспективно и предназначе-
но только для понимания материала, приведенного в последующих главах. Количе-
ство опубликованной литературы и доступных в FidoNet и Internet электронных
текстов, связанных с модемами, таково, что всякому пользователю не составит тру-
да достать исчерпывающее пособие. В любом случае основным материалом для ра-
боты должно служить фирменное руководство для используемого вами модема
и практические экзерсисы с терминальной программой.
Программы узла FidoNet
В этом разделе дан обзор программного обеспечения для FidoNet. От того, какие
программы вы выберете для подключения к сети, в значительной степени будет
зависеть успех вашей работы в FidoNet.
Есть программы FidoNet, которые спроектированы авторами так, чтобы делать
сразу все, что только может потребоваться системному оператору, - редактировать
письма, упаковывать написанные для отправки, принимать и отправлять подготов-
ленные файлы, обрабатывать принятую почту и хранить ее в базе данных и т.д. Но
таких программ немного, и не они определяют «стиль» программного обеспечения
сети. FidoNet создавалась постепенно, шаг за шагом, программа за программой,
и для этой сети характерно наличие большого количества программ и утилит, со-
ставляющих вместе полноценный набор для построения системы FidoNet.
Именно среди набора специализированных мейлеров, тоссеров и редакторов
почты FidoNet и следует искать «свои» программы, поскольку специализирован-
ное программное обеспечение известно своей надежностью и богатыми возмож-
ностями, чего нельзя сказать о немногочисленных программах-«комбайнах».
Примерами универсальных программ могут служить F.I.P.S. - законченный
набор программ для запуска пойнт-системы под Windows, заслуженный и извест-
ный Terminate (вспоминается шуточное высказывание «злобный пойнт с Терми-
нейтом наперевес») или программа D’Bridge, включающая почтовую программу,
тоссер и редактор писем.
Примеры специализированных программ многочисленны, большинство из них
перечислены в таблице приложения 11.
В настоящем разделе выделены основные компоненты программного обеспече-
ния узла FidoNet. Эти компоненты в неявном виде присутствуют и в интегриро-
ванных Fido-оболочках вроде F.I.P.S; в случае специализированных программ они
выделены в отдельные программные модули.
Коммуникационный драйвер FOSSIL
Драйвер СОМ-порта - это системная программа, предоставляющая разработчи-
ку основные функции для управления интерфейсом RS-232. В составе програм-
мы BIOS компьютера IBM PC есть встроенный драйвер СОМ-порта, вызывае-
мый по прерыванию 14h. Это очень простая программа, реализующая четыре
базовые функции:
□ инициализация порта;
□ посылка символа;
□ прием символа;
□ считывание статуса линии.
Используемые стандартным для IBM PC драйвером скорости, для которых
можно инициализировать порт, не превышают 960 бод, буферизация передавае-
мой и принимаемой информации отсутствует (то есть данные могут теряться).
Драйвер устойчиво работает на скоростях до 300 бод, при более высоких скоростях
для обеспечения устойчивого приема нужны дополнительные усилия разработ-
чика программы.
Абсолютное большинство систем FidoNet всегда было установлено именно на
компьютерах IBM PC, и с самого начала развития сети, как только вошли в оби-
ход скоростные модемы, появилась необходимость замены коммуникационного
драйвера на более совершенный.
Хороший коммуникационный драйвер позволяет, кроме дополнительного
удобства и экономии времени разработчика почтовых и терминальных программ
для FidoNet, расширить возможности этих программ. Простой заменой драйвера
можно заставить программу, рассчитанную на использование обычного модема для
телефонных линий, работать в Internet, и примеры такого использования популяр-
ных почтовых программ есть, о них рассказано в главе 11. Использование драйвера
упрощает также перенос программ на отличные от IBM PC компьютеры.
В FidoNet устоялось название коммуникационного драйвера - FOSSIL. Это
слово представляет собой аббревиатуру, составленную из начальных букв попу-
лярных некогда почтовых программ FidoNet - F(ido) O(pus) S(eadog) S(tandard)
I(nterface) L(ayer). FOSSIL был создан в процессе работы над проблемой перено-
са почтовых Fido-программ на аппаратные платформы, имеющие мало общего
с IBM PC, исключая процессор Intel 808х (кстати, FOSSIL также означает «уста-
ревший», «допотопный»). Создание FOSSIL началось с написания основателем
сети Томом Дженнингсом универсального (generic) драйвера для его программы
fido.exe, первой программы FidoNet. Драйвер понадобился, поскольку Том запус-
кал программу на несовместимом с IBM PC компьютере DEC RAINBOW. Стан-
дарт на FOSSIL, FSC-0008 [6.1], был оформлен в 1987 году. Его автором является
Винсент Перриелло (Vincent Е. Perriello), участвовавший в разработке одной из
первых версий драйвера. К реализации идеи также приложили руку уже знако-
мый нам Винн Вагнер, автор программы Opus, Том Хендерсон и Боб Гартман (про-
грамма Seadog), а также многие другие разработчики FTN-программ.
Вскоре появились клоны FOSSIL для многих популярных в те годы компьюте-
ров - Tandy 2000, Heath/Zenith 100, Sanyo 555 и других «не РС-совместимых»
архитектур. Дополнения к первоначальному стандарту вышли в виде FSC-0015
[6.2]. Этот документ, представляющий собой рекомендательный стандарт, и был
использован при написании большинства современных реализаций FOSSIL. Ос-
новные функции FOSSIL представлены в табл. 6.7. Из таблицы видно, насколько
FOSSIL функционально превосходит стандартный коммуникационный драйвер
BIOS. Кроме обычных функций работы с коммуникационным портом, он также
предоставляет программисту простой интерфейс ввода с клавиатуры и вывода на
экран, что обеспечивает дополнительные удобства как при программировании,
так и при переносе на другую аппаратную платформу. Примеры популярных реа-
лизаций FOSSIL приведены в следующем разделе.
Примеры реализации и использования драйвера FOSSIL
Недостатки коммуникационного драйвера (прерывание 14h) IBM PC были успеш-
но исправлены при разработке многозадачных операционных систем Microsoft
Таблица 6.7. Основные функции драйвера FOSSIL (по материалам FSC-0015)
Код Название Перевод названия Комментарии
ООН Set BaudRate Задать скорость порта Позволяет устанавливать скорости до 38400 бод
01 h Transmit character Передать символ Ожидается освобождение буфера передачи. Могут возникать проблемы при использовании совместно с сигналами управления потоком
02Н Receive character Принять символ Выдается текущий символ из входного кольцевого буфера. При отсутствии символа ожидается его появление
ОЗН StatusRequest Запрос состояния порта В ответ выдается: состояние буферов, признак установления соединения (сигнал CD)
04Н Initialize driver Инициализация драйвера Инициализация драйвера обязательна перед началом использования порта
05Н Deinitialize Деинициализация driver (port) драйвера Должна выполняться после завершения операций с портом
06Н Raise/lower DTR Поднять/опустить сигнал DTR Изменение сигнала DTR оказывает влияние на состояние модема (большинство модемов разрывают соединение при низком уровне DTR)
07Н Return system Получить значение timer params системного таймера Позволяет запросить значение системного таймера, необходимое при операциях с СОМ-портом
08Н Flush output buffer Очистить буфер передачи Очищает выходной буфер, ожидает завершения передачи. Используется для завершения вывода
09Н Purge output buffer Обнулить буфер передачи Очищает выходной буфер, не ожидая завершения передачи. Все еще не переданные данные будут утеряны
OAh Purge input buffer Обнулить буфер приема Очищает входной буфер. Управление в программу возвращается немедленно. Реагирует на сигналы управления потоком
овн Transmit character Передать символ Ставит символ в очередь на передачу. Если в буфере передачи есть место, символ помещается в программу с соответствующим диагностическим кодом. Если буфер заполнен, возвращается диагностический код, символ отбрасывается
оси «Peek ahead» «Заглянуть» input buffer в приемный буфер Возвращается следующий символ во входном кольцевом буфере. При его отсутствии возвращается FFFFh. Это чтение не удаляет в символ из буфера
ODh «Peek ahead» «Заглянуть» KB buffer в клавиатурный буфер Возвращается следующий символ в буфере клавиатуры. При его отсутствии возвращается FFFFh. Это чтение не удаляет в символ из буфера
ОЕН Read Keyboard Прочитать символ с клавиатуры Возвращает символ из буфера клавиатуры. При пустом буфере ждет ввода строки
OFH Enable/Disable Вкл/Выкл управление flow control потоком Включает или выключает управление потоком данных СОМ-порта - программное (XON/XOFF) или аппаратное (RTS/CTS)
Windows 95, Windows NT, IBM OS/2 и UNIX. Каждая из этих систем имеет в сво-
ем составе достаточно совершенный драйвер, заменяющий BIOS-драйвер ком-
пьютера. Тем не менее и для этих систем оказалось удобным использование
FOSSIL. Поэтому для Windows и OS/2 были разработаны свои реализации драй-
вера. Мы остановимся подробнее на нескольких популярных версиях FOSSIL.
Таблица 6.7. Основные функции драйвера FOSSIL (по материалам FSC-0015) (окончание)
Код Название Перевод названия Комментарии
10h Enable/Disable Вкл/Выкл проверку нажатия Ctr-C/Ctr-K check, Ctr-C и Ctr-K, ЕпаЫе/Disable Вкл/Выкл передатчик transmitter нажатия Ctr-C Ctr-C/Ctr-K и Ctr-K, check, Enable/Disable Вкл/Выкл Включает или выключает проверку нажатия символов Ctr-C и Ctr-K Нажатия символов Ctr-C и Ctr-K Останавливает передачу или вновь включает прерванную ранее передачу. Последняя функция может быть использована для управления потоком
flh Set cursor location Установить курсор Устанавливает текстовый курсор в заданную позицию. Работает аналогично подфункции 02h прерывания 1 Oh IBM PC BIOS
12h Read cursor location Считать положение курсора Возвращает координаты текстового курсора. Работает аналогично подфункции 03h прерывания 10h IBM PC BIOS
13h Write char Вывести символ Вывести символ на экран в соответствии со спецификациями ANSI-терминала
14h Enable/Disable «watchdog» Вкл/Выкл «сторож» Если активен сторожевой режим, FOSSIL вызывает перезагрузку компьютера, когда разрывается соединение на заданном СОМ-порту
15h Write char (re-entrant) Вывести символ Выводит символ на экран с использованием кода, допускающего повторный вызов (можно вызывать эту функцию в драйверах DOS). ANSI-вывод не используется
16h Insert/delete function from timer tick Вставить/Удалить Реализует дополнительный механизм сохранения векторов прерывания, отличный от стандартного способа DOS
17h Reboot system Перезагрузка системы Вызывает «холодную» или «горячую» (на выбор) перезагрузку операционной системы
18h Read block Считать блок Считывает столько символов, сколько есть в указанном буфере. Не ожидает заполнения буфера. Возвращает количество переданных символов
19h Write block Записать блок Передает содержимое указанного пользовательского буфера в выходной буфер. Возвращает количество переданных символов
1AH Start/Stop sending break Вкл/Выкл посылку «break» Включает или выключает посылку сигнала «Break» в модем
IBh GetDriverlnfo Получить информацию о драйвере Возвращает полную информацию об используемом драйвере FOSSIL и его текущих установках
7Eh Install user appendage Установить обработчик пользователя Позволяет установить подпрограмму пользователя в качестве дополнительного обработчика прерывания 14h
7Fh Remove user appendage Удалить обработчик пользователя Позволяет удалить подпрограмму пользователя, установленную как дополнительный обработчик прерывания 14h с помощью функции 7Eh
Операционная система MS DOS
Для DOS разработано великое множество различных реализаций FOSSIL, одна-
ко в России наибольшее распространение получили программы Х00 и BNU. Ав-
тором Х00 является уже упоминавшийся в главе 1 Реймонд Гвинн, a BNU напи-
сал Дэвид Наджент (David Nugent).
Как Х00, так и BNU, поставляются с подробной документацией. Они могут
быть загружены как в виде драйвера DOS, с указанием строки вроде
DEVICES: \FIDO\TOOLS\х00 . sys
в системном файле config.sys, так и в качестве резидентных программ. В после-
днем случае FOSSIL должен быть загружен до запуска почтовой программы. На-
пример, пакетный файл вызова программы T-Mail может содержать следующие
строки:
С:\FIDO\TOOLS\х0О.ехе
С:\FIDO\T-MAIL\t-mail.ехе
Как правило, FOSSIL при запуске может быть сконфигурирован на использо-
вание желательной скорости работы коммуникационного порта, номеров, адресов
и количества используемых портов, размеров внутренних буферов на прием и на
передачу и т.п. В состав Х00 входит удобная утилита xu.exe для получения ин-
формации о состоянии портов и их дополнительной конфигурации в процессе
работы драйвера.
Конфигурация FOSSIL для DOS (на примере Х00)
Драйвер Х00 - достаточно «дружественная» программа, он будет работать, даже
если вы не сделаете никаких попыток установить его параметры в командной
строке вызова. В этом случае на экране в течение нескольких секунд будет ото-
бражаться информационная табличка (рис. 6.13), после чего драйвер запустится
как резидентная программа.
Для того чтобы убрать паузу при запуске драйвера, нужно вызвать Х00 с пара-
метром «Е» (Eliminate - «устранить»):
С:\FIDO\TOOLS\xOO.ехе Е
Используя ключи командной строки, можно добиться значительной гибкости
в конфигурации драйвера при его запуске. Все возможные команды, передавае-
мые драйверу Х00 в командной строке, разбираются ниже.
Количество обслуживаемых COM-портов. По умолчанию, если не указано
иное, Х00 обслуживает один коммуникационный порт (рис. 6.13). Для указания
количества COM-портов в командной строке ставится их число:
С:\FIDO\TOOLS\xOO.exe 2
Эта строка вызова инструктирует Х00 использовать два коммуникационных
порта. Если используется вариант загрузки драйвера xOO.sys, для обслужива-
ния двух портов в файле config.sys должна присутствовать строчка DEVICE=
С:\FIDO\TOOLS\х0О.sys 2
Максимальное количество обслуживаемых коммуникационных портов для IBM PC
составляет 4, а для ныне практически вышедших из употребления PS/2 систем - 8.
OREM С: \NETWARE\NETX. EXE
ОС:\CTCM\CTCU /S /W=C:\0S2\MD0S\WIN0S2
Creative Plug and Play Configuration Utility Version 1.04
Copyright(c) Creative Technology Ltd., 1995-1996. fill rights reserved.
Guinn’s Communications Controller, XOO.SVS Version V2.01+, installed.
Copyright 1990, 1991, 1992, 1993 by:
Raymond L. Guinn
12469 Cavalier Drive
Woodbridge, Virginia 22192
01 Communications port(s) will be supported.
All rights reserved. Unauthorized distribution prohibited.
Woodbridge, Virginia 22192
01 Communications port(s) will be supported.
All rights reserved. Unauthorized distribution prohibited.
Рис. 6.13. Запуск FOSSIL-драйвера x00.exe без параметров
Установка основных параметров COM-порта (опция «В»). Интерфейс RS-232
допускает два основных способа установления скорости обмена с внешним
устройством:
□ переменная скорость. В случае переменной скорости коммуникационный
порт и внешнее устройство (например, модем) сначала согласуют скорость
с использованием стандартной процедуры обмена сигналами, а затем произ-
водят передачу данных. Инициатива выбора скорости при этом принадлежит
внешнему устройству;
□ постоянная скорость, или Locking Baud, позволяет осуществлять более эффек-
тивный обмен данными, так как не тратится время на установление скорости
обмена. Однако при этом и порт, и внешнее устройство не должны менять ско-
рости работы, и скорость их должна совпадать. Иначе соединение окажется
неработоспособным.
И модем, и COM-порт могут быть сконфигурированы как для использования
постоянной скорости обмена, так и переменной. Однако наиболее распространен-
ным подходом при использовании современных скоростных модемов и современ-
ных UART является выбор постоянной скорости. Подключившись к сети, вы, ве-
роятно, не раз услышите из уст ее участников термин «скорость залочки» или
подобный. Имеется в виду именно выбранная постоянная скорость обмена моде-
ма с коммуникационным портом.
Для установления основных параметров порта при использовании драйвера
Х00 используется ключ командной строки, начинающийся с символа «В». За ним
следует строка параметров, в которой, разделенные запятыми, последовательно
перечисляются:
□ номер порта (первый - 0, второй - 1 и т.д.);
□ постоянная скорость работы порта (2400, 19200 и т.п.);
□ параметры порта - количество бит в посылке, наличие бита паритета и коли-
чество стоп-бит (пример: 8N1).
Таких строчек, начинающихся с символа «В», может быть несколько - по од-
ной на каждый используемый COM-порт. Порядок следования параметров в стро-
ке имеет значение, но последний можно опустить.
В качестве постоянных скоростей могут использоваться все возможные для мик-
росхемы UART скорости: от 75 до 115200 бод (75, 110, 135.5, 150, 300, 600, 1200,
1800, 2000, 2400, 3600, 4800, 7200, 9600, 19200, 28800, 38400, 57600, 115200).
Третий параметр допускает любую комбинацию своих трех элементов, возмож-
ные значения которых сведены в табл. 6.8.
Если программа пытается установить через Х00 скорость порта или другие его
параметры в процессе работы, драйвер всегда подставит значения, которые были
ему указаны в строке вызова командой «В».
Ниже даны примеры вызова x00.exe и xOO.sys с этим параметром.
x00.exe:
С: \FIDO\TOOLS\xOO.exe В,0,2400В,1,19200
(Используются порты 1 и 2, первый на постоянной скорости 2400 бод, второй -
на 19200.)
C:\FIDO\TOOLS\xOO.exe В , 1,192 00,8п1
(Используется СОМ-порт 2 на постоянной скорости 19200, параметры порта: 8
бит, нет бита четности, один стоп-бит.)
Для xOO.sys аналогичный эффект дадут строки:
DEVICE = C : \FIDO\TOOLS\х0 0 . sys В,0,2400 В,1,19200
DEVICES : \FIDO\TOOLS\xOO . sys В, 1,19200,8nl
Таблица 6.8. Возможные значения элементов конфигурации
коммуникационного порта драйвера Х00
Первый символ (количество информационных бит) Второй символ (бит четности) Третий символ (количество стоп-бит)
5 N (Нет) 1
6 Е (Четный) 2
7 О (Нечетный)
8 М (всегда 1) S (всегда 0)
Временный отказ от захвата прерываний (опция DEFER). Этот редко исполь-
зуемый ключ командной строки означает отказ от захвата прерываний процессо-
ра, необходимых для успешной работы драйвера. В дальнейшем драйвер можно
активировать программой xu.exe, вызвав ее с ключом CAPTURE. Если этого не
сделать, то Х00 нормально работать не будет. Примеры использования этой оп-
ции для драйверов хОО.ехе и xOO.sys:
C:\FIDO\TOOLS\xOO.exe DEFER
C:\FIDO\TOOLS\xOO.exe DE
DEVICE-C:\FIDO\TOOLS\x00.sys DEFER
DEVICES: \FIDO\TOOLS\xOO.sys DE
Как видно из примера, DEFER и DE являются синонимами.
Использование DesqView (опция DV). Параметр DV означает, что Х00 исполь-
зуется на компьютере, работающем под управлением многозадачной среды
DesqView. Сейчас эта программа применяется чрезвычайно редко. Примеры ис-
пользования:
С : \FIDO\TOOLS\xO0.ехе DV
DEVICES: \FIDO\TOOLS\xOO. sys DV
Настройка FIFO (опции F и NOFIFO). С помощью ключа командной строки
«F» указывается количество байтов буфера FIFO коммуникационного порта, ко-
торые должны быть использованы Х00 в его работе. Как правило, это значение
нужно установить на единицу меньше размера FIFO (например, для UART
16550А должно быть FIFO = 15). Примеры использования для хОО.ехе и xOO.sys
даны ниже.
хОО.ехе:
C:\FIDO\TOOLS\xOO. ехе FIFO=15
С : \FIDO\TOOLS\xOO . ехе F=10
xOO.sys:
DEVICE-C:\FIDO\TOOLS\х00.sys FIFO=10
DEVICE=C:\FIDO\TOOLS\x00.sys F = 10
Ключ NOFIFO, как нетрудно догадаться, запрещает использование FIFO.
Примеры:
DEVICES : \FIDO\TOOLS\xOO . sys NOFIFO
С : \FIDO\TOOLS\xOO . ехе NOFIFO
Не модифицировать BIOS (опция NOPOST). Обычно, когда Х00 запускается,
он замещает в памяти, отведенной под загрузку данных BIOS, аппаратные адреса
ввода-вывода коммуникационных портов на свои собственные, используемые
драйвером. Это полезная операция, обеспечивающая совместимость со многими
программами, работающими с COM-портами, но иногда ее использование неже-
лательно, и ключ командной строки NOPOST позволяет отменить модификацию
данных BIOS. Примеры:
С: \FIDO\TOOLS\xOO.exe NOPOST
DEVICE=C:\FIDO\TOOLS\х0О.sys NOPOST
Размеры буферов приема и передачи (опции R и Т). По умолчанию Х00 ре-
зервирует по 512 байт памяти буферов на прием и передачу Увеличение размера
буферов повышает эффективность работы всей коммуникационной подсистемы,
особенно на высоких скоростях передачи. Допустимые значения размеров буфе-
ров (в байтах): 256, 512, 1024, 2048, 4096, 8192, 16384, 32768. Слишком большой
размер буфера тоже не нужен, оптимальными (в зависимости от используемого
оборудования и качества связи) могут быть значения 2048, 4096 или 8192 байт.
Размеры приемного и передающего буферов обыкновенно выбираются одинако-
выми. Примеры использования:
C:\FIDO\TOOLS\xOO.exe R=102 4 Т=1024
DEVICE=C:\FIDO\TOOLS\xO0.sys R=2048 Т=2048
Переназначение номеров COM-портов, аппаратных адресов и IRQ. Нечасто,
но встречаются нестандартные конфигурации портов, когда сочетание адреса вво-
да-вывода порта, его номера и/или аппаратного прерывания IRQ не соответствует
общепринятому для IBM PC АТ (табл. 6.1). В этом случае приходится использо-
вать данную команду (ключ командной строки). Записывается она следующим об-
разом: необходимо указать номер порта в цифровом виде (СОМ1 - 0, COM2 - 1
и т.д.) и через знак «=» адрес порта ввода-вывода и номер прерывания IRQ в виде
IRQn, разделенные запятой. Вместо адреса порта ввода-вывода можно указать Х00
использовать стандартные для данного COM-порта значения, используя обычную
DOS-нотацию (СОМ1, COM2 и т.д.). При этом элементы командной строки могут
принимать следующие значения:
□ номер СОМ-порта - от 0 до 7;
□ СОМп - стандартная запись DOS: от СОМ1 до СОМ8;
□ IRQn - от IRQ1 до IRQ15;
□ адрес порта - стандартная шестнадцатиричная запись.
Можно использовать две формы команды:
сНомер порта>=СОМп, IRQn
<Номер порта>=<адрес>, IRQn
Обе этих записи эквивалентны, но первая удобнее, если нужно использовать
стандартные адреса COM-портов (не нужно вспоминать адреса ввода-вывода, со-
ответствующие тем или иным СОМ-портам).
По умолчанию Х00 ассоциирует IRQ для всех портов с IRQ3, исключая СОМ1,
для которого предполагается использование IRQ4. Указание IRQ является нео-
бязательным, если соответствие адресов портов и IRQ стандартно (табл. 6.1).
Ниже приведены примеры использования команд.
x00.exe:
C:\FIDO\TOOLS\xOO 0=СОМ4
С:\FIDO\TOOLS\xOO 0=СОМ4,IRQ5
С:\FIDO\TOOLS\х0О0=2E8,IRQ3
C:\FIDO\TOOLS\xOO 2-2Е8
xOO.sys:
DEVICES:\FIDO\TOOLS\х00.sys 0=СОМ4
DEVICES:\FIDO\TOOLS\х00.sys 0-СОМ4,IRQ5
DEVICE=C:\FIDO\TOOLS\xOO.sys 0 = 2Е8,IRQ3
DEVICE-C : \FIDO\TOOLS\xO0 . sys 2 = 2Е8
Автору неоднократно приходилось использовать эту команду когда по тем или
иным причинам стандартные IRQ коммуникационных портов были заняты. При-
менение этой команды представляет собой наиболее трудный момент в конфигу-
рировании Х00, при неудаче можно посоветовать поэкспериментировать и попро-
бовать различные сочетания адресов портов и IRQ, а также воспользоваться
диагностическими программами, упомянутыми ранее, для более точного опреде-
ления аппаратных параметров коммуникационных портов.
Деактивация Х00. Когда Х00 установлен как резидентная программа (то есть
запущен в работу файл хОО.ехе), то его можно деактивировать, удалив из списка
резидентных программ, простым запуском хОО.ехе без параметров.
Более подробную информацию об использовании Х00 можно почерпнуть из
подробной документации, поставляемой вместе с драйвером. В заключение отме-
тим, что все версии Х00 распространяются как shareware, и незарегистрирован-
ный вариант программы поддерживает только 2 COM-порта одновременно.
Windows 95 и Windows NT
В состав операционных систем Windows 95/98 и Windows NT входит 32-битный
драйвер коммуникационных портов, поддерживающий все возможности совре-
менных UART. Основной проблемой при запуске коммуникационных программ
FidoNet под управлением этих операционных систем является интерфейс меж-
ду стандартным для FidoNet FOSSIL-драйвером и драйвером RS-232, входящим
в упомянутые операционные системы. При этом распространенной практикой яв-
ляется использование почтовых программ FidoNet, разработанных для MS DOS,
запускаемых в DOS-окне этих операционных систем. В этом случае перед запус-
ком программы нужно в том же DOS-окне запустить и FOSSIL-драйвер. Полу-
ченный в результате «слоеный пирог» работает достаточно устойчиво, но нето-
ропливо: программа FidoNet запрашивает нужную функцию у FOSSIL-драйвера,
тот через стандартный интерфейс DOS-окна, предоставляемый Windows, обраща-
ется к коммуникационному драйверу операционной системы, который собствен-
но и делает всю работу.
Для упрощения среды выполнения коммуникационных задач и увеличения
производительности всей системы, специально для Windows разработан драйвер
WinFOSSIL. Он есть в версиях для Windows 95 и Windows NT. Этот драйвер пре-
доставляет 32-битный интерфейс с FOSSIL-стандартом, который могут исполь-
зовать большинство программ FidoNet. В составе установочного комплекта
WinFOSSIL есть удобная программа установки. После установки в папке Control
Configuration |
КЦ
Свойства: WinFOSSIL lor Windows NT
Tо run "Tweak UI”, double-click its icon in the
Control Panel.
"T weak UI" allows you to fine-tune ("tweak") the
Windows 95 and Windows NT 4.0 User Interface ("UI").
Fife Erffl: Bookmark Qptfens Help
About Tweak UI
-СП
.e>!
r 1
setup.exe ,
Port ID: 10000 3 Port1СОМ7
options:
This copy has not been restored.
Help Contents
Отмена
</. Don't release timeslice while carrier detected
Release timeslice when no port activity detected
"I Enable perfoimance statistics monitoring
< Automatically open port when use detected
-Port settings-------------------------------------------1
P Enable FOSSIL Locked baud rate: I
Rx buffer 2 lx buffer 3 *
28992 15.10.96 88:88
Tо learn more about "Tweak UI", click the
"Contents" button in the button bar at the top of this
window.
Tо uninstall "Tweak Ui", make sure to follow the
instructions in the "How to... Uninstall Tweak UI"
section of this help file.
For Help
teta,.exe
C:\ashabash\tmp>
ж
iiii
8
Рис. 6.14. Основное окно конфигурации коммуникационного драйвера WinFOSSIL
для операционной системы Windows NT 4
Panel (панель управления) появляется программа WinFossil, позволяющая скон-
фигурировать и активировать драйвер. «Моментальный снимок» основного окна
этой программы изображен на рис. 6.14.
Как видно из рисунка, программа позволяет настроить основные параметры
драйвера, такие как размеры приемных и передающих буферов, постоянная ско-
рость, на которой будет использоваться COM-порт и т.п. Для подробного озна-
комления с программой вполне подходит документация, составленная в виде
стандартного help-файла Windows и поставляемая вместе с программой.
WinFOSSIL для Windows NT предоставляет, кроме того, интерфейс виртуаль-
ного модема (Virtual Modem Interface), описанный в следующем разделе. Vmodem
позволяет использовать Internet как среду передачи для программ FidoNet, рас-
считанные на модемное соединение. Реализация Vmodem в WinFOSSIL очень
проста и содержит всего две команды:
□ ATZ - сброс виртуального модема;
□ ATD[T] <адрес Internet, где расположен telnet-сервис Vmodem>.
Адрес Internet может быть как в цифровой, так и в символьной форме, например:
□ 204.182.96.142 (цифровой адрес в стандартной нотации);
□ 204 182 96 142 (цифровой адрес в записи с пробелом в качестве разделителя);
□ bbs.woodruff-software.com (символьный адрес).
В состав Vmodem входит как клиентская, так и серверная части. Для актива-
ции Vmodem нужно в поле Port ID напечатать слово «TELNET».
Права на распространение этой shareware-программы принадлежат фирме
Woodruff Software Systems.
Кроме WinFOSSIL, есть еще ряд реализаций FOSSIL для Windows, например
свободно распространяемый Virtual Fossil Driver для Windows 95, автором кото-
рого является Павел Кингсеп из Москвы, NTFOSS - драйвер для Windows NT,
написанный Герхардом Визингером (Gerhard Wiesinger), и некоторые другие про-
граммы.
Операционная система IBM OS/2
Коммуникационный драйвер операционной системы OS/2 фирмы IBM com.sys
обеспечивает доступ к любым типам UART и поддерживает высокие скорости об-
мена. Это 32-битная программа, недостатков INT14, описанных в разделе «FOSSIL
для MS DOS», у нее нет. Тем не менее это не FOSSIL-драйвер, и он не в состоянии
предоставить стандартный для FidoNet коммуникационный интерфейс.
VFD. Первоначально при запуске под OS/2 программ FidoNet, разработанных для
MS DOS, использовался и FOSSIL-драйвер для DOS. Вскоре появился и быстро стал
популярен Virtual FOSSIL driver (VFD) для OS/2, созданный Иакимом Хернбергом
(Joakim В. Hernberg). Назначение этого драйвера аналогично описанному в предыду-
щем разделе WinFOSSIL: предоставлять интерфейс между Fido-программой, запу-
щенной в DOS-окне, и коммуникационным драйвером операционной системы. VFD
транслирует вызовы функций прерывания INT14, предоставляемого OS/2 для вир-
туальных машин DOS, в вызовы файловой системы, через которую в OS/2 обычно
осуществляется связь с коммуникационным драйвером. VFD обеспечивает высоко-
скоростную передачу файлов при использовании блочного метода передачи, под-
держивает до 8 портов, может использовать COM-порт совместно с другими про-
граммами OS/2 и обладает рядом других привлекательных характеристик. Плата
за использование VFD не взимается.
Сейчас VFD используется редко, на смену ему пришел более совершенный
драйвер, описанный в следующем разделе.
SIO. Пакет драйверов SIO/VSIO (Serial Input-Output - «последовательный
ввод-вывод») разработан автором описанного выше Х00, Реймондом Гвинном,
для операционной системы OS/2. Этот драйвер полностью заменяет стандартный
драйвер com.sys, обеспечивая FOSSIL-интерфейс как в среде виртуальных машин
ДОС (VDM), так и в OS/2-окнах. Кроме этого, в пакете SIO был впервые реали-
зован интерфейс Vmodem (Virtual Modem), позволяющий устанавливать соеди-
нения через Internet. К сожалению, SIO распространяется как shareware и неогра-
ниченное по времени его использование незаконно. Но установить программу на
компьютер и использовать ее в течение достаточно продолжительного срока пе-
ред покупкой можно - обычные для shareware лицензионные соглашения это до-
пускают. В Internet информацию о SIO можно найти по адресу:
http://www.gwinn.com/.
SIO - это большой пакет программ, поставляющийся с пространной докумен-
тацией хорошего качества. Полное описание его выходит за рамки настоящей кни-
ги. В этом разделе дан краткий список отличий SIO от стандартного драйвера OS/2,
com.sys, и приведено краткое описание возможностей Vmodem, входящего
в состав пакета.
Отличия между SIO и com.sys:
□ com.sys автоматически определяет и поддерживает четыре COM-порта, SIO -
только два. Дополнительные порты должны быть указаны в командной стро-
ке вызова, например, для обеспечения работы четырех COM-портов в файл
конфигурации OS/2 config.sys должна быть включена строчка device=sio. sys
(сотЗ) (сот4);
□ com.sys по умолчанию сканирует порты ввода-вывода 3F8h, 2F8h, 3E8h
и 2E8h. Первый найденный в этой последовательности порт получает логи-
ческое имя СОМ1, второй COM2 и т.д. Это означает, что соответствие логи-
ческих имен и адресов портов ввода-вывода может быть отличным от обще-
принятого (табл. 6.1), что может вызвать неправильную работу программного
обеспечения, разработанного из расчета стандартного соответствия имен пор-
тов и их адресов. SIO придерживается стандартной концепции: СОМ1 для
SIO по умолчанию всегда имеет адрес 3F8h, COM2 - 2F8h и т.д. Если СОМ-
порта на адресе 3F8h не обнаружено, значит, у вас не будет СОМ1;
□ VSIO (входящий в состав пакета SIO драйвер для виртуальной машины DOS)
открывает COM-порт в VDM в разделяемом режиме. VCOM (аналогичный
стандартный драйвер) монополизирует порт;
□ sio.sys допускает установку любой скорости от 50 бод и выше. Так, например,
с помощью sio.sys можно установить скорость передачи 9999 бит/с. com.sys
допускает установку только стандартных значений;
□ SIO работает быстрее com.sys, время его реакции меньше. Это означает, что
некоторые приложения, нормально работающие с com.sys, именно по этой
причине не смогут работать с sio.sys;
□ SIO/VSIO обеспечивает более надежное управление потоком при передаче
данных для DOS-сессий. Например, если используется аппаратное управле-
ние потоком сигналами RTS/CTS, VSIO виртуализует установки RTS для
DOS-программы, в то время как SIO полностью контролирует реальные зна-
чения RTS. COM/VCOM же просто передает сигнал RTS аппаратуре RS-232;
□ com.sys блокирует работу приложения до тех пор, пока не закончится запись
в порт. SIO возвращает управление приложению немедленно после того, как
данные поступят в его внутренний буфер.
Перечисленные отличия делают SIO хорошей заменой стандартному драйверу
OS/2, и если вы намереваетесь использовать для FidoNet эту операционную сис-
тему (в FidoNet OS/2 широко распространена), то, возможно, стоит начать с уста-
новки SIO. Справедливости ради отметим, что некоторые почтовые программы,
работающие под управлением OS/2, вообще не нуждаются в интерфейсе FOS-
SIL и могут работать непосредственно с com.sys, хотя, конечно же, использовать
их с SIO можно. Так, например, автор этой книги запускал почтовую программу
The Brake! Mailer для OS/2 как co стандартным com.sys, так и c sio.sys, и каких-
либо различий между этими двумя вариантами не обнаружил.
SIO и Vmodem
Основная идея полезной программы Vmodem заключается в следующем. С тех
самых пор как работа с коммуникационным портом начала проводиться только
с использованием драйвера FOSSIL, стало возможным написание виртуального
FOSSIL-драйвера, который предоставлял бы интерфейс доступа не к порту RS-
232 (и через него - к модему), а к какой-нибудь другой среде передачи. Все воз-
можные аппаратные и программные ответные сигналы модема й порта можно
было бы с легкостью имитировать программно. Так появился Vmodem, или Virtual
Modem Driver (драйвер виртуального модема), позволяющий использовать Inter-
net как среду передачи для FidoNet программ. Vmodem использует один из основ-
ных протоколов Internet - TCP. Система, в которой установлен Vmodem, может
выступать в качестве Telnet-сервера и/или Telnet-клиента (Telnet - высокоуров-
невый сервис Internet, ориентированный на установление соединения и ис-
пользующий протокол TCP). В дополнение Vmodem может использовать свой
собственный коммуникационный протокол, названный автором VMP или «про-
токол виртуального модема». Для использования VMP обе системы должны его
поддерживать, а Telnet-сервером Vmodem можно воспользоваться и без дополни-
тельных программ. Так, множество BBS подключены к Internet с использованием
Vmodem, и к ним можно подключиться посредством команды telnet, входящей
сейчас в стандартную поставку большинства операционных систем. Например,
если на компьютере, подключенном к Internet, вызвать программу Telnet с пара-
метром vmbbs.gwinn.com (это Internet-адрес BBS поддержки SIO), то на экране
появится приглашение к подключению, можно зарегистрироваться и воспользо-
ваться сервисом этой BBS. Пример подключения представлен на рис. 6.15.
М FC/2: telnet vmbbs.gwinn.com 1 1 ~
ппппп пп пппп пп ппппп пп пппп пп пп пп пп пп пп пп пп пп пл пппп
ппппп пп пппп пп ппппп пп пп пп ПП пп пп пп пп ппппп ппппп пп пп ппппп пп пп ппппп пп пп ппппп пп пп пппп пп пп пп пп пп пп пппп лппппп п п п п пппппп пп пп пп пп пппппп II п пп пп пп
ппппп пп пп ппппп пп пп ппппп ппппп пп пп ппппп пп пп ппппп ппппп пп пппп пп ппппп
What is your first What is your last Password (Dots wit name? name? 1 echo) Arn i г Shabashv ill ? ( )
Рис. 6.15. Подключение по протоколу Telnet к BBS, использующей драйвер VModem
Vmodem использует тот COM-порт, который указан в строке вызова драйвера
SIO, в файле config.sys, например, вот так:
device=sio.sys (coml) (com4,internet,none)
Указанная директива инструктирует SIO использовать для нужд Vmodem чет-
вертый коммуникационный порт. Слово попе, занимающее позицию, в которой
обычно размещается информация об используемом IRQ, означает, что IRQ не ис-
пользуется. Если желательно использовать Vmodem из DOS и/или Windows сес-
сий OS/2, то нужно более подробно описать порт, указав (фиктивные!) адреса
и прерывания, которые драйвер предъявит DOS/Windows программам (SIO спо-
собно имитировать COM-порт в соответствующей DOS или Windows сессии).
Так, например, строчка
device^sio.sys (coml) (com4,internet:2е8,none:3)
описывает COM-порт, используемый для Internet и видимый в сеансах DOS
и Windows как COM4 с адресом ввода-вывода 2E8h и использующий IRQ3.
Vmodem поддерживает пространный набор модемных АТ-команд и ответов на
них, предоставляя почтовой или терминальной программе привычную среду для
работы.
Некогда SIO был единственным пакетом, содержащим
Vmodem. С некоторых пор поддержка Vmodem была реа-
лизована в нескольких почтовых программах FidoNet, на-
пример в T-Mail и Ifmail, описанных в следующих главах,
простая реализация Vmodem есть в драйвере WinModem
для операционной системы Windows NT 4.0.
Введены соответствующие информационные флаги для
нодлиста (глава 2), обозначающие, что данная система до-
ступна по протоколу Vmodem. Другими словами, это дос-
таточно известный и популярный (хотя и не самый луч-
ший) способ организации соединения FidoNet-программ
через Internet. Преимущества и недостатки Vmodem до-
полнительно обсуждаются в главе 11.
Более подробную информацию об использовании Vmo-
dem можно почерпнуть из описания, которое распростра-
няется вместе с SIO.
Размещение файлов Fido-системы
и потоки данных
Просто перечислять программы, которые составляют
Fido-систему в отрыве от файловой структуры хранения
и размещения данных, которыми эта система оперирует,
мало смысла. Однако для того чтобы яснее представлять
назначение каждой программы FidoNet, это знание необ-
ходимо. На рис. 6.16 приведена файловая структура, со-
ответствующая размещенной на диске пойнт-системе. Не
Рис. 6.16. Структура
директориев
Fido-системы
все из приведенных на рисунке директориев являются обязательными, но неко-
торые есть почти всегда. Рассмотрим последовательно их назначение.
Системный директорий. Корневой, или системный директорий Fido-узла, -
это директорий, в котором размещаются все или почти все файлы, имеющие от-
ношение к вашей системе FidoNet. В случае, изображенном на рис. 6.16, это ди-
ректорий С : / PONT. Конечно, можно нарушить обычай и размещать Fido-систему
вразброс по всему диску, но это было бы очень неудобно.
Входной (inbound) директорий. Входной директорий - это директорий, в ко-
торый почтовая программа помещает принятую почту и файлы. Входных дирек-
ториев может быть несколько. Обыкновенно выделяется общедоступный входной
директорий (unsecure inbound), куда помещается информация, принятая по непа-
рольным линкам, и защищенный (secure inbound), где лежат файлы, пришедшие
во время сессий, защищенных паролем. Информация из общедоступного дирек-
тория обрабатывается под наблюдением самого сисопа, чтобы свести к минимуму
риск получения и запуска разнообразных программ - «троянских коней» и виру-
сов. На некоторых станциях информация из общедоступного входного директо-
рия также обрабатывается автоматически, чтобы упростить и ускорить процесс
передачи почты в сети.
На приведенном рисунке входной директорий только один - это С: \PONT\
INBOUND.
Выходной (outbound) директорий. Выходным директорием называется дирек-
торий, в котором программы FidoNet формируют подготовленные к отправке фай-
лы. Иногда outbound-директорий бывает дополнительно структурированным,
например в случае использования так называемого Binkley-style outbound (глава
4). На рис. 6.16 один выходной директорий - С : \ PONT \ OUTBOUND.
Директорий для размещения нодлиста. Нодлисты и справочники (индексы
к ним), как правило, размещаются в отдельном директории (С : /PONT/NODELIST
на рис. 6.16). Делается это для того, чтобы не запутаться в обилии файлов - нодли-
стов часто бывает несколько, и, как правило, несколько программ строят к ним ин-
дексы, размещая их также в нодлистовом директории.
Директорий личной почты. Нетмейл-директорий представляет собой обязатель-
ный элемент конфигурации каждой программы FidoNet, имеющей дело с личной
почтой (почти все программы так или иначе этого касаются). Для размещения нет-
мейла всегда выделяется отдельный директорий, так как письма в стандарте MSG
хранятся в отдельных файлах и их может быть очень много - до нескольких десят-
ков тысяч! На рисунке это С : \PONT\NETMAIL.
База эхо-почты. Эхо-почта также обычно хранится во множестве файлов, и для
нее выделяется отдельный директорий. На рис. 6.16 это С: \PONTXMSGBASE.
Иногда этот директорий дополнительно структурируется, чтобы разбить базу на
тематические группы с использованием средств файловой системы.
Директорий для файлов протоколов. Все программы FidoNet во время своей
работы записывают протокольные файлы. Обычно все они помещаются в один
директорий (С: XPONTXLOG на рис. 6.16) - так проще производить регулярные
операции чистки, архивирования и т.п.
Директорий для файлов-флагов. Сообщение о том или ином событии с помо-
щью создания или удаления пустых файлов с заранее согласованными именами
является обычным способом коммуникации в многозадачных системах. В FidoNet
такой способ используется очень часто, и для флаг-файлов обыкновенно выделя-
ется отдельный директорий. На рисунке это С: \PONT\FLAGS.
Директорий для временных файлов. Временные файлы следует хранить в от-
дельном директории, так гораздо легче разбираться с ними в случае внезапного
выключения питания или дисковой аварии.
Директорий почтовой программы. Как правило, он называется по имени выб-
ранной почтовой программы. В приведенном примере таких директориев два, по-
скольку при работе узла используются две почтовые программы - это популяр-
ная почтовая программа T-Mail (директорий С: /PONT/T-MAIL) и программа для
проброса Fido-почты через Internet — Binkd (С: /PONT/Binkd).
Директорий редактора писем. Программа для чтения и написания писем, на-
зываемая в FidoNet программой-редактором почты (Mail Editor), также обычно
помещается в отдельный директорий. На рисунке это С: \PONT\GED (использу-
ется редактор писем Gold Editor).
Остальные директории содержат дополнительные утилиты и программы, со-
став которых определяется вкусами системного оператора, а также той ролью,
которую данная система играет в структуре раздачи почты FidoNet, и меняется от
системы к системе.
Перемещение данных во время работы Fido-системы можно представить диа-
граммой, изображенной на рис. 6.17.
Входящая информация. Обмен с другими системами FidoNet осуществляет по-
чтовая программа FidoNet Mailer. Принятые файлы помещаются во входной дирек-
торий (inbound), откуда их забирают программы-обработчики. На данном рисунке
изображена одна из возможных программ - обработчик эхо-почты (эхо-процес-
сор, или тоссер, если воспользоваться популярной в российском Fido калькой
Рис. 6.17. Перемещение данных в процессе работы Fido-системы
с английского языка). Тоссер распаковывает принятые пакеты в зависимости от их
типа либо в базу эхо-почты, либо в нетмейл-директорий, выступая таким образом
еще и распаковщиком личной почты (нетмейла). В общем случае распаковывать
личную почту может и почтовая программа, и программа-упаковщик почты - боль-
шинство таких программ способны выполнять эту несложную, но важную функцию.
Теперь информация из базы эхо-почты и нетмейл-директория становится доступной
для чтения системным оператором с использованием программы-редактора почты.
Исходящая информация. Исходящая информация формируется сисопом в про-
грамме-редакторе почты FidoNet и помещается в зависимости от выбранной облас-
ти написания либо в базу эхо-почты, либо в нетмейл-директорий. Затем письма
экспортируются из базы программой-обработчиком эхо-почты (из нетмейл-дирек-
тория программой-упаковщиком нетмейла) и помещаются в выходной директорий
системы, откуда их забирает почтовая программа и отправляет по назначению.
Просто? Да, хотя это очень упрощенная схема. Реальная структура движения
данных может быть сложнее, однако для конечной системы-потребителя инфор-
мации (то есть для типичной пойнт-системы) описанная схема вполне адекватна
реальному положению дел.
Основной набор программ узла FidoNet
В этом разделе приведен список программ, более подробно описанных в последу-
ющих главах (драйвер FOSSIL был представлен ранее). Этот набор несколько
дополняет схему, изображенную на рис. 6.17. Каждый тип программ кратко оха-
рактеризован, также приведены примеры реализаций; список популярных про-
грамм FidoNet можно найти в приложении И.
Полный набор программ, работающих обычно на узле FidoNet, приведен на
рис. 6.18. Взаимосвязи между программами не указаны, это слишком усложни-
ло бы схему, но вертикальные ряды программ размещены в порядке движения
информации от пользователя к сети: те, что слева - «ближе» к пользователю,
справа - ближе к среде передачи, они «глубже» погружены в сеть. Рассмотрим
последовательно все возможные типы FTN-программ.
Планировщик
Все программы на рис. 6.18 охвачены рамкой «Планировщик». Эта графическая
аналогия отражает тот факт, что все программы узла FidoNet, настроенного для
работы без участия человека - а большинство узлов именно таковы, - функцио-
нируют под управлением служебной программы-планировщика, или шедулера
(от англ, scheduler - «планировщик»). В качестве планировщика может выступать
и простой пакетный файл, запускающий циклически и поочередно необходимые
программы, и развитые программы-планировщики, часто входящие в состав поч-
товых программ, по своей природе нуждающихся в таких возможностях, или и то
и другое. Заранее настроенный шедулер «знает», когда и кому должна звонить си-
стема, в какие часы можно принимать почту и файлы, а в какие - только почту, ког-
да запускать эхо и файл-эхопроцессор и другие обработчики принятой информа-
ции, - словом, планировщик командует всей вашей армией, замещая сисопа в его
Рис. 6.18. Набор программ, используемых на узле FidoNet
отсутствие и делая его жизнь приятнее и спокойнее в тот момент, когда он вжи-
вую присутствует за компьютером. Сейчас, когда я пишу этот текст, на моем ком-
пьютере идет обработка принятых по сети данных, по обеим модемным линиям
перекачивается почта, и не кто иной, как шедулер заведует этими процессами.
Ниже в качестве примера приведен фрагмент настроечного файла программы-
планировщика, встроенного в почтовую программу The Brake! Mailer (рис. 6.19).
Блоки #For выделяют списки событий для разных линий (в данном случае их
две). Директива POLL означает распоряжение почтовой программе позвонить по
указанному адресу и произвести обмен почтой. Директива Run - запустить внеш-
нюю программу. Таким образом, первая строчка в блоке для первой линии
event "Poll 5049/30" 0:00 Every 0:31 Poll Normal 2:5049/30
каждые полчаса формирует Poll (распоряжение позвонить) с атрибутом NORMAL
(«обычный») на адрес 2:5049/30, а первая строка в блоке для второй линии
event "Run Allfix File" 0:00 Every 12:01 Run c : \ fido \ all fix \
filelist, and
каждые 12 часов запускает программу Allfix, обработчик файл-эх. Более подробно
возможные подходы к построению системы планировки работы узла FidoNet осве-
щены в главе 12.
Коммуникационные программы
Типов коммуникационных программ на узле FidoNet может быть несколько, и каж-
дая из разновидностей может быть представлена в различных версиях и запущена
OS/2 System Editor - C:\FIDO\BRAKEl\brakeLsch ' '
; File Edit Options Help
j Version 1.0.g629 £
Copyright (c) 1995, 96 by John Gladkih.
; All rights reserved.
; Schedule list.
^Event "Clear try" 0:00 Reset
iftFor 1
| event "Poll 5049/30" 0:00 Every 0:31 Poll Normal 2:5049/30
event "Poll 5049/36" 0:00 Every 0:32 Poll Normal 2:5049/36
event "Poll 5049/64" 0:00 Every 0:34 Poll Normal 2:5049/64
event "Poll 5049/1" 0:00 Every 6:06 Poll Normal 2:5049/1 _
event "Poll 5049/16" 0:00 Every 2:06 Poll Normal 2:5049/16 »
event "Poll 5049/116" 3:00 Poll Normal 2:5049/116
#EndFor
#For 2 I
event "Run Allfix File" 0:00 Every 12:01 Run c:\fido\allfix\filelist.cmd \
event "Run Statistics" 0:00 Every 23:59 Run c:\fido\stat.cmd ?
event "Generate echolist" 0:00 Every 23:58 Run c:\fido\faste\echolist.cmd
; polls for IP-links =
event "Poll 2:5020/269" 0:00 Every 23:07 Poll Normal 2:5020/269
event "Poll 2:5020/238" 0:00 Every 1:01 Poll Normal 2:5020/238
event "Poll 2:5020/204" 0:00 Every 0:15 Poll Normal 2:5020/204 ?
event "Poll 2:5021/11" 0:00 Every 3:02 Poll Normal 2:5021/11
event "Poll 2:5030/115" 0:00 Every 1:03 Poll Normal 2:5030/115
event "Poll 3:774/605" 0:00 Every 6:07 Poll Normal 3:774/605
ftEndFor Г i
Рис. 6.19. Фрагмент конфигурационного файла brake.sch
(файл настройки планировщика мейлера The Brake!)
в нескольких копиях. Все это возможно, но обычно системные операторы старают-
ся унифицировать коммуникационную подсистему и не перегружают ее разномас-
тными программами. Как правило, используются три типа программ.
Драйвер FOSSIL. Очень подробно описанный в начале этой главы, пришед-
ший из эпохи MS DOS FOSSIL до сих пор является непременным атрибутом
большинства FTN-систем. Он обеспечивает интерфейс с модемом для коммуни-
кационных программ FidoNet и порой используется также для организации со-
единения через Internet. Однако есть и программы, не использующие FOSSIL. Это
почтовые программы (например, ARGUS или Ifmail), изначально написанные для
современных операционных систем, в состав которых входят совершенные драй-
веры RS-232, и некоторые программы проброса почты Fido через Internet.
Почтовая программа (Mailer). Центральная и самая сложная программа любого
Fido-узла, мейлер представляет собой систему обмена почтой FidoNet по коммути-
руемым телефонным каналам с использованием модема. Как правило, для обеспе-
чения работы нескольких телефонных линий мейлер запускается в нескольких
копиях под управлением какой-либо многозадачной операционной системы (есть
и многозадачные мейлеры, например ARGUS или The Brake! Mailer). Интер-
фейс пользователя используется для отображения текущего состояния очереди
отправки, состояния модема и текущей почтовой сессии, если таковая случится.
Возможности управления поведением программы с клавиатуры, как правило,
невелики - для серьезного изменения требуется исправить конфигурационный
файл и перезапустить программу. Для работы почтовой программе нужен спи-
сок узлов сети - нодлист либо какой-нибудь его заменитель и упакованная для
отправки на представленные в нодлисте адреса почта. Очень часто почтовая про-
грамма включает в себя и подсистему первичной обработки личной почты, то
есть она может распаковывать принятые РКТ-файлы и упаковывать почту для
отправки в соответствии с заданными правилами маршрутизации почты. При-
мерами таких программ могут служить T-Mail Андрея Елкина или заслуженная
программа FrontDoor Иахима Хомригхаузена. Почти всегда почтовая програм-
ма включает в себя терминальную подсистему и может быть использована для
доступа к BBS. Подробное описание архитектуры и принципов конфигурации
популярных мейлеров содержится в главе 7.
Программа BBS. FidoNet родилась как сеть операторов BBS. Первые почтовые
программы FidoNet - FIDO Тома Дженнингса, OPUS Вина Вагнера - были одно-
временно и программами BBS. Предполагалось, что BBS должна быть установле-
на на каждом узле FidoNet. Так было когда-то, такое положение и сейчас суще-
ствует в странах, куда FidoNet пришла в середине 80-х годов: США, Англии,
Канаде, Австралии, где системы с флагом МО (Mail Only - «только почта», без
терминального BBS-доступа) - редкость.
В Россию FidoNet пришла в начале 90-х годов уже сложившейся сетью, со сво-
им уставом - Полиси, в котором требование наличия BBS на узле сети отсутство-
вало. Поэтому, а также по ряду других причин, BBS не стали доминирующим сер-
висом в русскоязычном Fido. Но все же BBS в R50 много, они установлены как на
узловых, так и на пойнт-станциях.
Программа BBS работает, как правило, в кооперации с драйвером FOSSIL, че-
рез который она получает доступ к модему, и с почтовой FTN-программой, кото-
рая передает управление модемом к BBS, если определяет текущий входной зво-
нок как терминальный вызов.
Популярные программы BBS - Tornado, Maximus, Remote Access - взаимодей-
ствуют co многими компонентами Fido-системы. Они позволяют своим пользова-
телям скачивать файлы, предоставляют доступ в режиме чтения/записи к базам
эхо-почты и личной почты, позволяют устраивать многосторонние совещания
пользователей (если BBS многолинейная), использовать нодлист FidoNet. Неко-
торые BBS способны предоставлять ограниченный сервис Internet (при наличии
доступа к Internet на узле, где установлена BBS).
Для удобства использования BBS были разработаны так называемые offline
readers - программы пакетного скачивания и чтения почты и эхо-почты с BBS,
позволяющие использовать BBS почти как Fido-узел, то есть в качестве удобно-
го средства доступа к ресурсам сети. Вообще говоря, терминальный доступ, ха-
рактерный для BBS, несовершенен, и при плохой связи чтение почты в режиме
on-line может кого угодно свести с ума. Off-line readers скрашивают жизнь поль-
зователей BBS.
Однако BBS не является обязательным сервисом в FidoNet и подробное описание
этой программы выходит за рамки нашей книги. Желающим узнать больше о BBS
рекомендуем прочитать замечательную книгу «BBS без проблем», вышедшую в из-
дательстве «Питер» в 1996 году (кстати, один из авторов этой книги, Георг Пис, неко-
торое время выполнял обязанности международного координатора FidoNet).
Процессор эхо-почты (тоссер). Программа обработки эхо-почты не является
необходимым компонентом Fido-системы. Чтобы быть участником сети, доста-
точно установить почтовую программу и научиться отправлять и получать лич-
ную почту. Однако систем без поддержки эхо-почты в FidoNet практически нет,
поскольку это самый популярный наряду с нетмейлом сервис, ради которого, соб-
ственно, и существует сеть. Быть подключенным к Fido и не читать Fido-эхи не
имеет смысла. Хотя такие случаи известны, но они исключение из правила. По-
этому можно сказать, что тоссер является обязательным компонентом программ-
ного обеспечения FidoNet, конфигурированию и настройке которого вам придет-
ся уделить немало времени.
На станции FidoNet тоссер работает, с одной стороны, с информацией из входно-
го директория системы, которую он распаковывает в базу эхо-почты и распределя-
ет по подписчикам (если таковые есть), формируя для них пакеты в выходном ди-
ректории; с другой стороны, тоссер экспортирует написанные сисопом письма из
базы эхо-почты и также раскладывает их по линкам в выходном директории.
Для общего знакомства с тоссером этой информации пока достаточно, мы к это-
му вопросу вернемся в главе 8 и рассмотрим его в деталях.
Процессор файл-эх (файл-эхопроцессор). Файл-эхи тоже популярный сер-
вис, но не в такой степени, как эхо-конференции. Далеко не все узлы сети, а тем
более пойнт-станции поддерживают файловые конференции, поскольку это тре-
бует значительных ресурсов как от коммуникационной подсистемы (приходится
перекачивать очень большие объемы информации), так и от жесткого диска ком-
пьютера (полученное надо где-то хранить). Логика работы файл-эхопроцессора
аналогична работе тоссера, только в качестве базы сообщений здесь выступает
файловая база, распределенная по директориям и организованная тематически.
При получении файла он автоматически помещается в нужный директорий и над-
писывается в информационном файле. Информационные файлы лежат в тех же
директориях и именуются по традиции files.bbs.
На рис. 6.20 в качестве примера приведено содержимое одного из таких файлов,
отражающего наполнение файловой конференции, посвященной архиватору RAR.
Получая большое количество файловых конференций, вы в скором времени
сформируете значительную по объему файловую базу. Далее, на основании ин-
формационных файлов files.bbs, с помощью специальных программ - составите-
лей файл-листов - можно составить единый список ваших файлов - файл-лист,
после чего поиск в вашей файловой базе упростится. Наличие хорошо организо-
ванного файл-листа - отличительный признак раздающей файлы Fido-системы.
Файловые конференции и программы файл-эхопроцессоров заслуживают под-
робного знакомства, которое состоится в главе 9.
Редактор почты. Через редактор почты вы в основном и взаимодействуете с FidoNet.
Выбор и настройка редактора очень важны - для вас это лицо сети: если вы выбе-
рете неудачную программу, то испортите все удовольствие от пользования ресур-
сами Fido. Самым распространенным редактором почты FidoNet в R50 является
OS/2 System Editor - D:\ARCHiVE\ALLFIX\rar\FILES.BBS р ]□
File Edit Options Help
BERAR260.ZIP RAR for BeOS v2.60 release
BRAR26B7.SFX RAR for BeOS v2.60 beta 7
BRAR26B8.ZIP RAR for BeOS v2.60 beta 8
RAR201.EXE RAR 2.01 DOS release
RAR201P.EXE RAR 2.01 OS/2 release
RAR205.EXE RAR V2.05
RAR205P.EXE RAR/2 v2.05
RAR2O6.EXE Rar for DOS v2.06
RAR206P.EXE RAR for OS/2 V2.06
RAR250.EXE RAR v2.50 (release)
RAR250P.EXE RAR v2.50 for OS/2 (release)
RAR250RU.EXE RAR V2.50 Russian for DOS
RARLNX25.SFX RARLinux v2.50 (release)
RARLNX26.SFX RAR for Linux v2.60 release
RARX260.EXE RAR for DOS32 v2.60 release
RARX26B5.EXE RAR v2.60 beta5 for DOS32
RARX26B6.EXE RAR for DOS/32 v2.60 beta 6
RARX26B7.EXE RAR for DOS/32 v2.60 beta 7
RARX26B8.EXE RAR for DOS/32 v2.6 0 beta 8
RLNX26B.SFX RAR for Linux v2.6O beta 1
RLNX26B2.SFX RAR for Linux v2.6 beta 2
RLNX26B5.SFX RAR v2.6 0 beta5 for Linux
RLNX26B6.SFX RAR for Linux v2.6 0 beta 6
RLNX26B7.SFX RAR for Linux v2.60 beta 7
RLNX26B8.SFX RAR for Linux v2.6 0 beta 8
UNPSFX.RAR UnpSFX
UNRARDLL.RAR UnRARDll
UNRARSRC.RAR UnRARsrc
WR260B6R.EXE WinRAR v2.60 beta 6 Russian
WR26B2R.EXE WinRAR v2.60 Russian Beta 2
WRAR205.EXE WinRaR v2.05
WRAR206.EXE RAR for Win v2.06
Рис. 6.20. Содержимое информационного файла files, bbs
Gold Editor, автор которого, Один Соренсен (Odin Sorensen), не так давно выпустил
бесплатную версию в исходных текстах (ранее программа распространялась как
shareware). С него и рекомендуется начать. Дальше вы можете попытаться подобрать
программу по вкусу. Например, автор книги остановился на редакторе Fleet Street
для OS/2. Это замечательная программа, также распространяемая бесплатно, но вер-
сии для других операционных систем отсутствуют.
Настройка редактора почты и основные секреты его использования подробно
рассматриваются в главе И.
Вспомогательные утилиты. Перечисленные выше программы составляют ос-
нову Fido-системы. Но кроме них на каждом узле Fido используются и другие
программы. Некоторые из них являются обязательными, без них трудно обойтись,
например программы ведения нодлиста. Другие предоставляют дополнительный
сервис пользователям узла, упрощают администрирование системы, выполняют
автоматические процедуры обработки нетмейла и т.п. Вряд ли удастся просто пе-
речислить все подобные утилиты: уж слишком они многочисленны, слишком под-
час мелки задачи, которые они решают. Ниже дан краткий обзор наиболее рас-
пространенных типов вспомогательных FTN-программ:
□ программы ведения нодлиста. В главе 2 достаточно подробно описана систе-
ма распространения нодлиста, основанная на рассылке файлов дополнения -
нодедиффов. Для получения текущего нодлиста из предыдущей версии и пос-
леднего нодедиффа служат программы, называемые нодлист-процессорами,
или нодедифф-процессорами. Они, как правило, просты в настройке и требу-
ют только указания местоположения нодлистов и файлов дополнений. Со-
вершенные нодедифф-процессоры могут изготовлять частичные нодлисты,
урезанные по структурным единицам FidoNet - зонам, регионам или сетям.
Это подчас очень удобно. Примером таких программ могут служить NDP, со-
вместное творение Владимира Копьева (2:5080/7) и Сергея Викулова
(2:5080/5) из Екатеринбурга. Программа существует в версии для DOS. Для
DOS и OS/2 есть программа FastList, которая кроме выполнения функций
нодедифф-процессора может также индексировать нодлист. Полученные
в результате стандартные индексные файлы могут быть использованы неко-
торыми программами, например уже упоминавшимся редактором Fido-почты
FleetStreet. Автором программы FastList является ныне покинувший FidoNet
Альберто Паскаль (Alberto Pasquale). Все эти программы описаны в главе 7;
□ обработчики почты (Netmail Trackers). Программы для автоматической об-
работки личной почты используются на хаб-узлах FidoNet, где обработка
вручную требует слишком много усилий. Есть простые обработчики, выпол-
няющие заранее определенные операции, есть и конструкторы, позволяю-
щие строить почти любые схемы преобразования писем и даже писать про-
граммы-роботы. Такова, например, программа Itrack, автором которой
является Франк Прейд (Frank Prade) из Германии. Нетмейл-трекеры доста-
точно сложны в настройке, нужно хорошо понимать, чего вы хотите достичь
и знать в деталях структуру сообщений и способы хранения нетмейл-базы.
Но результат их использования впечатляет: вместо ежедневно разгребаемой
горы писем вас встречает разложенная «по полочкам» корреспонденция. Не-
нужная уже выкинута в мусорную корзину, возвращена отправителям, пере-
правлена адресатам, а нужная лежит в том месте, где вы привыкли ее видеть
и готова к прочтению. Настройка подобных программ описана в главе 7;
□ программы составления файл-листов. Список файлов, или файл-лист, - это
лицо BBS. Чем еще можно завлечь пользователя, как не возможностью ска-
чивать и скачивать файлы? Для изготовления файл-листов служат десятки
различных программ: от простейших, написанных на языках-интерпретато-
рах вроде REXX, до сложных многофункциональных программ, которые не
только объединяют все информационные files.bbs в один большой список, но
и анализируют протокольные файлы почтовых программ, подводя статисти-
ку скачивания каждого файла, выявляют «рекордсменов», скачавших наи-
большее количество байт, выстраивают рейтинг популярности файлов и по-
мещают всю эту (интересную, но не слишком-то нужную) информацию
в конец файл-листа. Настройка программы изготовления файл-листа, как
правило, несложна, но утомительна. Например, на узловой станции автора
в конфигурации программы файл-листера описано около 200 файловых об-
ластей, и каждая снабжена соответствующей ее тематике надписью, указан
директорий, в котором хранятся файлы. Вас должно утешить только то, что
изготовление файл-листа - сервис желательный, но не обязательный. Даже
будучи узлом или хабом, можно не заниматься составлением файл-листа. Для
более подробного ознакомления с подобными программами загляните в главу 9;
□ программы управления протокольными файлами. Каждая из FTN-npo-
грамм записывает свои протокольные файлы, или лог-файлы. И если на ин-
дивидуальной пойнт-системе эти файлы можно просто время от времени
удалять, то на узле такие файлы являются ценным источником информа-
ции, по ним часто предпринимаются «расследования» по поводу пропавшей
почты, плохой связи и т.д., и выбрасывать их было бы опрометчиво. Как
правило, выбирается та или иная схема ротации файлов: по истечении оп-
ределенного срока файлы архивируются, затем перемещаются на устрой-
ство долговременного хранения и только затем удаляются. Для реализации
подобных схем администрирования были разработаны программы-менед-
жеры протокольных файлов;
□ программы-«роботы». Программа-робот - это программа, которая работает на
вашей Fido-станции сама, без вашего участия, дополняя и/или расширяя фун-
кции стандартных FTN-программ, описанных выше. Многие роботы взаимо-
действуют с пользователями станции, отвечают на их запросы. Менеджеры
подписки в файл- и эхопроцессорах, обработчики нетмейла и многие другие -
тоже роботы. В следующих главах описаны некоторые программы-роботы,
принципы их настройки и функционирования.
Заключение
Прочитанная вами глава - последняя из числа обзорных. Все остальные посвя-
щены конкретным аспектам устройства сети. Этот же материал пригодится при
выборе аппаратной платформы и операционной системы для работы в FidoNet
и при изучении главы 7 (описание драйвера FOSSIL).
Глава VII
Обработка и передача
по сети личной почты
Личная почта заслуживает особенного внимания. Транспорт личной почты - основ-
ной сервис FidoNet. Остальные сервисы, такие как передача файлов, распростране-
ние эхо-конференций, могут быть очень популярны, но они по своей природе явля-
ются дополнительными услугами. Можно быть участником сети и не получать
файл-эх, не читать эхо-конференций, только принимать личную почту и отвечать
на письма - этого достаточно.
Обращение с личной почтой тщательно регламентировано Полиси. Вы не не
имеете права просто так удалять чужую почту, даже если не в состоянии доста-
вить ее адресату. Это легко объяснимо: если эхо-почта не является уникальной,
она продублирована на десятках, а обычно на сотнях и тысячах систем, то личная
почта путешествует по сети в единственном экземпляре и с ее уничтожением со-
общение уже никогда не достигнет адресата. Поэтому возврат недоставленной
почты или извещение о невозможности ее пересылки по тем или иным причи-
нам - обычная практика в FidoNet.
Чтобы соблюдать основной ритуал обращения с личной почтой, надо прежде
всего хорошо представлять себе все тонкости ее технического устройства и транс-
портировки, поскольку только так можно избежать грубейших ошибок, сделан-
ных иногда просто по незнанию.
Кроме форматов данных и способов преобразования почты в процессе ее дви-
жения по сети, в настоящей главе рассмотрены также основные программы для
передачи и обработки нетмейла. Именно здесь вы найдете описание функциони-
рования и примеры конфигурации почтовых программ, программ-обработчиков
нетмейла (трекеров), программ-упаковщиков и процедур маршрутизации.
Для понимания вопроса и составления полной картины системы передачи лич-
ной почты в FidoNet необходимо ознакомиться с уже изложенным материалом,
прежде всего с главой 1 («Неформальное введение в FidoNet», раздел «Личная
почта FidoNet»), главой 2 («Формальное введение в FidoNet», раздел «Передача
личной почты») и главой 4 («Форматы данных FidoNet»).
Вводные замечания
Основное внимание в этой главе уделено практическим вопросам выбора, на-
стройки и администрирования программ, которые используются для передачи по
сети нетмейла. Все, что было уже прочитано вами на эту тему ранее, пригодится
сейчас для понимания сути. Далее мы остановимся на нескольких важных момен-
тах, уже затрагивавшихся ранее, но освещенных недостаточно подробно.
Атрибуты почтовых сообщений
Параметр с названием Attribute word, обычно называемый атрибутом письма,
описан в главах 2 и 4. Это элемент бинарного заголовка письма. Он имеет важное
значение как один из параметров всей системы электронной почты FidoNet.
Атрибуты письма FidoNet, числом 16, определяют способ доставки письма,
срочность его отправки, запрашивают у транзитных узлов информацию о прохож-
дении письма по сети, позволяют запросить файл с другой системы или прикре-
пить к сообщению файл и т.п. Перечень возможных атрибутов приведен в главе 4,
табл. 4.1. Поскольку количество атрибутов оказалось недостаточным для разра-
ботчиков почтовых программ FidoNet, через несколько лет после утверждения
первого стандарта FidoNet автором популярной почтовой программы FrontDoor,
И. Хомригхаузеном, был написан проект стандарта FSC-0053 [4.4], в котором он
ввел большое количество дополнительных атрибутов. Так как место в заголовке
письма было исчерпано, им был использован специальный кладж AaFLAGS . Фла-
ги FSC-0053 активно используются, хотя документ и не имеет статуса действую-
щего стандарта. Синтаксис кладжа AaFLAGS простой: вслед за признаком кладжа
(число Olh, обычно изображаемое как ла)и ключевым словом «FLAGS» следует
строка флагов (трехбуквенные сокращения в соответствии с FSC-0053, разделен-
ные пробелами), например: ^aFLAGS IMM FIL K/S.
Описывая атрибуты писем, мы чаще всего будем иметь в виду атрибуты сооб-
щений, сохраненных в формате *.msg. Существуют также атрибуты упакованной
для отправки почты (письма, упакованные в файлы с расширением .pkt). Ранее
они упоминались в главе 4. Наконец, с описываемыми атрибутами прямо связаны
признаки способа отправки (BSO-флейворы), подробно рассмотренные в главе 4.
Флейворы формируются, в частности, на основании атрибутов писем в процессе
упаковки почты в Binkley style outbound для отправки.
Разберем подробнее функции некоторых важных атрибутов, используемых при
передаче личной почты и при обращении с полученной почтой. При этом отметим,
что иногда некоторые атрибуты дублируются и в заголовке сообщения (где они
ставятся в соответствии со стандартом FSC-0001), и в теле письма, в служебной
строке AaFLAGS. Приоритет при этом имеет строка в теле письма. Обычно
программа «собирает» полный набор атрибутов, читая как бинарный заголовок
письма, так и строку AaFLAGS.
Ниже приведено описание основных (не всех!) атрибутов, причем в скобках
после названия каждого атрибута приведено общеупотребительное сокращение,
используемое либо в кладже AaFLAGS, либо при любых других ссылках на данный
атрибут (например, в редакторе писем). Если не указано иное, то считается, что
атрибут проставляется вручную при составлении письма в редакторе сообщений.
Большинство описанных атрибутов могут встречаться как в заголовке письма,
так и в строке AaFLAGS. Некоторые, напротив, специфичны только для одного
способа хранения. Описание сгруппировано по назначению атрибутов (информа-
ционное, способ отправки и т.п.).
Информационные атрибуты:
□ Private (PVT). Атрибут Private («частный») часто автоматически ставится
многими сисопами, для этого достаточно соответствующим образом сконфи-
гурировать редактор сообщений. Исходно атрибут использовался на BBS для
того, чтобы пользователи BBS, не являющиеся адресатами письма, не могли
прочитать его. Сейчас наличие этого атрибута означает, что письмо носит
приватный характер и не может быть процитировано в переписке с третьими
лицами. Именно такое толкование приведено, например, в FSC-0053;
□ Received (RCV) - письмо получено. Этот атрибут проставляется автомати-
чески при получении письма, вручную его ставить не нужно;
□ Sent (SNT) - письмо успешно послано (атрибут используется, если не уста-
новлен атрибут Kill/Send, описанный ниже). Проставляется автоматически;
□ InTransit (TRS) - письмо транзитное и хранится на станции временно. Про-
ставляется автоматически;
□ Read (RED) - письмо прочитано. Проставляется при чтении редактором со-
общений;
□ Local (LOC) - письмо написано на данной системе. Проставляется автомати-
чески редактором писем;
□ IsReturnReceipt (RPT, RECPT) - письмо представляет собой уведомление
о получении другого письма (послано в ответ на письмо с атрибутом RRQ).
Атрибуты, определяющие способ отправки:
□ Hold (HLD) - не отправлять письмо, пока адресат сам не заберет его, позво-
нив на систему отправителя директом. Это один из наиболее часто использу-
емых атрибутов;
□ Crash (CRA) - отправить письмо в режиме Crash. Этот атрибут прямо связан
со способом посылки письма. Письмо с Crash отправляется, во-первых, с наи-
высшим приоритетом, немедленно, во-вторых, нетмейл-пакеты при обрыве
соединения передаются с докачкой. Иногда перекрывает действие атрибута
Hold (зависит от реализации и настройки почтовой программы). Обычно
проставляется вручную;
□ Immediate (IMM) - немедленная отправка. Как правило, отменяет действие
Hold, может отменять время работы станции отправителя/получателя, может
подразумевать директную отправку - в зависимости от реализации. Может
также рассматриваться как Crash или Crash+Direct;
□ ForcePickup (FPU) - немедленная отправка вне любых ограничений. Отме-
няет Hold, время работы, подразумевает Direct;
□ Direct (DIR) - отправлять напрямую, используя непосредственное соедине-
ние со станцией получателя;
□ Kill/Sent (К/S) - удалить письмо после отправки. Этот атрибут чрезвычай-
но популярен: вся транзитная почта, как правило, автоматически приобрета-
ет К/S статус. Однако достаточно часто он проставляется и вручную.
Файловые атрибуты:
□ FileAttach (FIL, иногда отображается как F/A). К письму прикреплен(ы)
файл(ы). Спецификация файла(ов) при этом помещается в поле темы (subject)
письма;
□ KillFile/Sent (KFS) - удалить после успешной отсылки файл(ы), прикреплен-
ный ые) к письму. Этот атрибут действует только в том случае, если к письму
прикреплен(ы) файл(ы);
□ FileRequest (FRQ) - письмо содержит запрос файла(ов), спецификации ука-
заны в поле темы письма;
□ TruncateFile/Sent (TFS) - усекать посланный(ые) файл(ы) до нулевой дли-
ны, но не удалять его (их).
Контрольные атрибуты:
□ ReturnReceiptRequest (RRQ) - запрос уведомления о получении письма от
системы адресата. Уведомление должно генерироваться автоматически про-
граммой приема (мейлером) или программой обработки (нетмейл-пакером
или трекером) и посылаться отправителю;
□ AuditRequest (ARQ) - обычно трактуется как запрос уведомления о пути
прохождения письма, ответы на него присылают все транзитные узлы;
□ ConfirmationRequest (CFM) - запрос на уведомление о прочтении. Ответ на
этот атрибут генерируется автоматически или полуавтоматически (то есть
под контролем сисопа) редактором сообщений и высылается автору ориги-
нального письма. Используя этот атрибут, вы получаете шанс узнать, было
ли прочитано ваше письмо адресатом, даже если он и не успел еще на него
ответить.
Служебные строки сообщений (kludge lines)
Служебные строки, или кладжи, - это символьные строки в тексте сообщения,
начинающиеся с признака ла (код Olh). Исключение составляют кладжи AREA:
и SEEN-BY, подробно описанные в главе 8. В этом разделе описаны кладжи, зна-
ние которых необходимо для анализа маршрута движения нетмейла, способа его
отправки и т.п.
MSGID. Служебная строка AaMSGID содержит уникальный идентификатор
сообщения. Согласно FTS-0009, где впервые был описан MSGID, алгоритм его
генерации должен обеспечивать уникальность MSG в течение трех лет. MSGID
используется для исключения дублированных писем при образовании петель в мар-
шрутах распространения нетмейла и эхо-почты.
Синтаксис:
^aMSGID <адрес системы происхождения письма> <идентификатор>
Пример:
AaMSGID: 2:5049/12 37f49c8a
VIA. AaVIA содержит адресную и временную информацию и вставляется в пись-
мо при упаковке письма на отправку Последовательные кладжи транзитных уз-
лов AAVIA позволяют получить представление о маршруте следования письма.
Синтаксис:
AaVI А не имеет строгого синтаксиса, поскольку этот кладж не предназначен для
автоматической обработки, а только для анализа с привлечением самого сисопа.
В строке AaVIA в символьном представлении указываются:
□ наименование и номер версии программы, поставившей метку;
□ адрес системы, через которую проходит письмо;
□ дата и время в UTC (то есть стандартное время, «по Гринвичу»).
Пример:
AaVia Squish/386 1.11 1:270/211, Sun Apr 18 1999 at 14:58 UTC
AaVia FLAME 1:270/101, Sun Apr 18 16:30 UTC (vl.l/bll)
AaVia MsgTrack+ 1:396/1, Sun Apr 18 1999 at 16:19 UTC
AaVia Squish/386 1.11 1:396/1, Sun Apr 18 1999 at 16:28 UTC
AaVia 2:5020/278 FTrack 2.02/W32 18 Apr 1999 21:03:54
AaVia 2:5020/204 FTrack 2.01.b7/W32 18 Apr 1999 21:07:40
AaVia 2:5049/12@FidoNet @19990418.211655.22.UTC Itrack- 1.3/G6
Приведенный пример однозначно свидетельствует, что маршрут письма, содер-
жащего эти кладжи, был таким:
1:270/211 => 1:270/101 1:396/1 ==> 2:5020/278 2:5020/
204 2:5049/12
DOMAIN. Содержит информацию о домене и адресе отправителя и адресата
письма. Введен в FSC-0038 [7.1] для поддержки междоменной адресации. Наряду
с кладжами INTL, ТОРТ и FMPT может быть использован для получения адрес-
ной информации.
Синтаксис:
AaDOMAIN <Н-домен> <Н-адрес> <0-домен> <О-адрес>
где использованы обозначения:
□ <Н-домен> - домен назначения;
□ <Н-адрес> - адрес системы назначения;
□ <0-домен> - домен отправителя;
□ <О-адрес> - адрес системы-отправителя.
Пример:
AaDOMAIN FidoNet 2:5049/12.0 FidoNet 2:5020/251.0
INTL. Первоначально AaINTL был введен для обеспечения межзональной ад-
ресации (согласно FTS-0001), однако теперь часто используется просто для опре-
деления адресной информации.
Синтаксис:
^alNTL <адрес системы назначения> <адрес системы-отправителя>
Пример:
"alNTL 2:5049/19 2:5049/12
ТОРТ. Содержит пойнт-адрес системы назначения письма.
Синтаксис:
аТОРТ <номер пойнта системы-адресата>
Пример:
"аТОРТ 19
FMPT. Пойнт-адрес системы-отправителя письма.
Синтаксис:
^аТОРТ <номер пойнта системы-отправителя>
Пример:
"aFMPT 19
Кладжи AaDOMAIN, aAINTL, АаТОРТ и AaFMPT используются программами,
имеющими дело с нетмейлом, для определения адресной информации.
Существует множество других кладжей, большинство из них описаны в FSC,
некоторые используются только каким-либо одним типом программного обеспе-
чения или не используются совсем. Далее, по мере необходимости, мы будем воз-
вращаться к описанию тех или иных контрольных строк.
Почтовые программы FidoNet
FTN-мейлеры, осуществляющие обмен почтой и файлами между системами
FidoNet в автоматическом режиме, относятся к наиболее сложным и совершен-
ным программным продуктам, разработанным под эгидой FidoNet. Не случайно,
что именно мейлеры составляют основу многих коммерческих FTN-сетей. При их
описании мы будем различать два основных типа мейлеров - АМА (ArcMail-
Attach) и BSO (Binkley-style outbound), различающихся подходом к формирова-
нию исходящего почтового директория (глава 4).
Как правило, FTN-мейлер выполняет следующую работу:
□ подготавливает информацию к отправке (справедливо только для АМА);
□ обрабатывает принятую информацию (АМА);
□ принимает входящие звонки, производит обмен почтой или передает управ-
ление BBS (либо иной коммуникационной системе);
□ производит звонки на другие системы для совершения обмена почтой и фай-
лами;
□ предоставляет в распоряжение сисопа терминальную программу;
□ осуществляет управление внешними (по отношению к мейлеру) программами;
□ выполняет дополнительные сервисные функции (например, принимает фак-
сы, работает в качестве автоответчика, осуществляет обмен почтой в локаль-
ной сети или через Internet и т.п.).
Правильно настроенная программа выполняет свои функции автоматически,
работая круглосуточно без необходимости присутствия оператора на узле. Конеч-
но, большинство станций регулярно посещаются своими «хозяевами», но многие
работают в unattended («безлюдном») режиме месяцами.
Дать исчерпывающее описание всех почтовых программ, которые часто разли-
чаются концептуально, в рамках одной книги невозможно. Вместо этого мы со-
средоточимся на типичных чертах распространенных в настоящее время мейлеров
и настройке ключевых параметров, рассмотрев в качестве примера три популяр-
ных в R50 программы - FrontDoor (АМА, DOS и OS/2), Т-Mail (AMA/BSO,
DOS/Windows95/NT/OS2), The Brake! (BSO, OS/2).
Структура и состав типичной почтовой программы FidoNet
Структура типичной почтовой программы FidoNet представлена на рис. 7.1.
Изображенные модули иногда выполняются в виде отдельных программ, порой
входят в один исполняемый файл, но функционально они существуют всегда.
Рассмотрим последовательно изображенные на рисунке модули и отметим спе-
цифические черты каждого.
Подсистема конфигурации
Многие почтовые программы FidoNet и вообще многие любительские (или, точ-
нее, некоммерческие) программы имеют в качестве основного интерфейса для
конфигурирования системы один или несколько текстовых файлов, где в соответ-
ствии с разработанным автором синтаксисом располагается описание конфигура-
ции мейлера. Примером подобного файла может служить конфигурационный
файл программы The Brake!, изображеный на рис. 7.2. Здесь видна только малая
часть файла brake!.ctl, полный размер которого превышает 60 Кбайт.
Несмотря на кажущиеся трудность и неудобство такого подхода к настройке
программ, для человека, привычного к графическим меню стандартного интер-
фейса Windows или OS/2, он оказывается прост и удобен, поскольку, во-первых,
все директивы конфигурационного файла хорошо документированы в нем самом
и в описании программы, во-вторых, исправлять обычно приходится очень не-
большую их часть; для остальных, как правило, подходят стандартные значения.
Для создателя программы такой простой интерфейс также очень удобен, по-
скольку при модификации программы не нужно каждый раз править настроеч-
ную утилиту и файл подсказки.
При запуске программы конфигурационные файлы обрабатываются и на их
основе обычно создается двоичный конфигурационный файл (или файлы), кото-
рые и используются в дальнейшем.
Как правило, выделяются следующие структурные единицы в файле конфигу-
рации, иногда помещаемые в отдельные конфигурационные файлы (вниматель-
ный читатель заметит их соответствие структуре, изображенной на рис. 7.1).
Рис. 7.1. Схематическое изображение структуры почтовой программы FidoNet
Рис. 7.2. Отрывок конфигурационного файла brake!.ctl мейлера The Brake!
Основной конфигурационный файл:
□ адресная и доменная информация;
□ нодлистовая информация - список используемых нодлистов, их местополо-
жение;
□ определение структуры директориев INBOUND/OUTBOUND;
□ параметры «поведения» почтовой программы (интервалы совершения звон-
ков, периоды времени, когда можно отвечать на звонки, звонить на другие
узлы, время ZMH и т.п.);
□ параметры почтовой сессии (максимальная длительность входящей/исходящей
сессии, текстовая информация, передаваемая во время сессии в составе EMSI);
□ параметры коммуникационной подсистемы (определение используемых про-
токолов, другие параметры);
□ параметры внешнего интерфейса (цвет и положение окон программы, деталь-
ность и состав выводимой информации);
□ параметры протокольных файлов - их местоположение и детальность вывода;
□ правила трансляции телефонных номеров;
□ секция определения правил запроса файлов с данной системы (в какие часы
и для каких типов узлов возможны запросы файлов, какой максимальный
объем может быть передан в течение сессии, дня, и т.п.);
□ отдельные описания параметров для нескольких линий, если таковые имеют-
ся в наличии (иногда это несколько похожих конфигурационных файлов, по
одному для каждой линии).
Конфигурационный файл линков - соединений с другими системами:
□ описание линков с указанием паролей;
□ описание оверрайдов (от англ, «override» - перекрывать) - блоков информа-
ции для некоторых систем, перекрывающих информацию о них, взятую из
нодлиста.
Конфигурационный файл модема:
□ настройка модема и драйвера FOSSIL;
□ возможные ответные сообщения модема.
Конфигурационный файл настройки планировщика.
Здесь приводится список событий с указанием времени и характера выполняе-
мых действий.
Файл правил маршрутизации почты. В этом файле указываются правила
маршрутизации сетевой почты.
Далее мы будем неоднократно возвращаться к описанию элементов подсисте-
мы конфигурации на примере трех популярных программ - FrontDoor, T-Mail
и The Brake!.
T-Mail и The Brake! имеют традиционные текстовые подсистемы конфигура-
ции, a FrontDoor начиная с первых версий снабжена настроечной утилитой
fdsetup.exe, создающей бинарный файл конфигурации (внешний вид этой про-
граммы представлен на рис. 7.3).
Существенным элементом конфигурации являются также два популярных ме-
ханизма оперативного изменения настройки программы:
□ параметры, передаваемые программе в командной строке вызова;
□ параметры, передаваемые через переменные окружения (environment).
Эти два способа позволяют вносить изменения в конфигурацию системы без
правки самого конфигурационного файла. Используются они часто (их описания
приведены в разделе «Примеры настройки почтовых программ»).
Подсистема управления очередью
Мейлеры Arcmail-Attach отличаются развитой подсистемой формирования и сле-
жения за почтовой очередью; все сказанное в этом разделе в полной мере относит-
ся именно к АМА-программам, таким как FrontDoor или T-Mail (когда последний
используется в АМА-режиме).
При запуске входящий в состав АМА-мейлера упаковщик почты просматривает
указанную в конфигурации базу NetMail (базу формата *.msg) и создает на ее ос-
нове очередь почты на отправку, состоящую из писем, упакованных в файлы *.pkt,
и сопровождающих информационных файлов. Создаваемые файлы *.pkt получа-
ют определенный статус, определяющий его место в очереди, в зависимости от
Рис. 7.3. Программа конфигурации мейлера FrontDoor (fdsetup.exe)
настройки правил маршрутизации, служебных атрибутов писем и настроек почто-
вой программы. Каждый элемент очереди, ассоциированный с определенным ад-
ресом, содержит:
□ директные нетмейл-письма для этого адреса (если используется система марш-
рутизации почты FidoNet, то письма отправляются не напрямую, а через по-
средство других систем и там входят в элементы очереди, принадлежащие
этим системам);
□ письма, которые маршрутизируются через этот адрес;
□ прикрепленные к письмам файлы;
□ файловые запросы на этот узел.
В процессе работы мейлер время от времени сканирует нетмейл-директорий
и вносит в очередь изменения. Изменения также вносятся после каждой почто-
вой сессии. АМА-мейлер большую часть времени работы занимается обслужива-
нием очереди.
Несколько проще работа у BSO-мейлеров, очередь для которых готовит вне-
шний упаковщик и мейлер только время от времени сканирует очередь на пред-
мет произошедших изменений.
При описании очереди «статусом» элемента очереди мы будем называть характе-
ристику способа отправки, как она видна из почтовой программы. Статус формиру-
ется на основании атрибутов письма, данных нодлиста, настроек почтовой програм-
мы и директив управления очередью, поданных с клавиатуры. Обычно количество
возможных статус-состояний меньше или равно числу допустимых флейворов, на-
пример для T-Mail это Н - HOLD, I - IMMEDIATE и Р - PRIORITY.
Почтовая очередь отображается на экране в процессе работы программы, и, как пра-
вило, мейлер предоставляет сисопу простейший интерфейс для манипулирования
g Une 1, Call, 2:5049/30@FidoNet i « had
2: 5049712QFidoNet~~l The ^В?а1<^ЦЪпГ Ma iier 718. a8 /9999 Г"01: 40: 35 T~37*
p® LOG
15:31 Using DirZap for transfer
15:31 2S 3Be72Bfa.Moq, DZA16, 3297, 90:04,
echo-mail
15:31 SE 00:01, 3297, 3297 CPS 457$
15:31 Gone, 2:5049/199FidoNet, 09:05, 0/1, 0/3297,
free
15:31
15:33 Calling normal 2:5049Z30@FidoNet,
64-50321P], Guard station, Vlad Spiridonov
— Queue: Normal
Mode: Call 59 sec
Call: 2:5049/19
Used: 7299, 99:95
Event: Poll 2:5020/294
Time: 15:45
। Address ***“
**Node Con/Bad Mail Files г^т Ни гЩ гЖ & State
b►2:5949/3O0F i doNe t 35/9 IMF” ...,X«. 21600/ARQZ
h 2:5049/30.18@FidoNet 0/0 iiim .F. Hold
h 2:5049/34@FidoNet 0/0 250K ............ .X.. Hold
n 2:5649/36.320FidoNet 9/9 3.2K вив .M...... Not worked
h 2:5049/389FidoNet 9/9 14K 760K Hold
n 2:5049/390FidoNet 0/0 eilil 957b Not worked
h 2:5O49/400FidoNet 0/0 ввив Hold
id 2:5049/45@FidoNet 88/0 вея® H * Not worked
n 2:5649/46,790FidoNet 0/0 Ч-. .......... <F., ., Not worked
n 2:5049/486FidoNet 0Z0 194K 15K X.M... Not worked
TfsMTHonWiQ 15ТзТ1^ | | ИЕЗЁйЕ RI CD RQ SO | C0M1 57600
Рис. 7.4. Отображение почтовой очереди в окне мейлера The Brake!
очередью. Ha рис. 7.4 изображен «моментальный снимок» работы мейлера The Brake!,
список в нижней части окна программы - это почтовая очередь.
Для каждого элемента очереди, помещенного в отдельной строке, указаны сле-
дующие данные:
□ способ отправки почты или флейвор (N - NORMAL, D - DIRECT, В - BUSY,
Н - HOLD, I - IMMEDIATE, С - CRASH);
□ 5D FTN-адрес;
□ счетчик попыток (всего коннектов/всего неудачных попыток);
□ количество почты (нетмейла) в Кбайт для данного адреса;
□ количество файлов в Кбайт для данного адреса;
□ список всех имеющихся для данного адреса флейворов (их может быть не-
сколько, например нетмейл может быть упакован с одним флейвором, а фай-
лы или эхо-почта - с другим);
□ состояние очереди для данного узла в настоящий момент - здесь могут быть
указаны параметры соединения, если узел только что закончил обмен почтой,
или указано состояние HOLD (почта дожидается звонка адресата), NOT
WORKED (узел сейчас не работает согласно нодлисту), ^NOTHING* (ответ
от узла при попытке соединения не получен), DISABLE (почтовая програм-
ма не должна звонить на этот узел).
Аналогичное представление очереди обеспечивают T-Mail и FrontDoor и дру-
гие почтовые программы. Можно получить расширенную информацию по выде-
ленному элементу почтовой очереди - пример для мейлера The Brake! приведен
на рис. 7.5.
Интересным и важным моментом является алгоритм совершения звонков, ос-
нованный на настройке программы и на состоянии элементов почтовой очереди.
Рис. 7.5. Отображение информации о выделенном элементе почтовой очереди
мейлера The Brake!
Само по себе попадание какого-либо узла в очередь не гарантирует звонка на него.
Примерный алгоритм задается следующей последовательностью логических за-
ключений (в приложении к мейлеру T-Mail, для произвольного элемента очереди):
1. В первую очередь обслуживаются узлы, имеющие статус Priority; если дан-
ный элемент не имеет этого статуса, звонок на него будет произведен только
после совершения звонка на узлы с PRIORITY-статусом.
2. Допускает ли настройка программы звонки в данное время? Если да, то мож-
но перейти к следующему пункту; если нет, то выходим.
3. Далее следует анализ возможности звонка на данный узел:
- известен ли телефон узла? Если нет, переходим к следующему элементу
очереди;
- нет ли директивы Freeze для данного узла? Если есть, переходим
к следующему элементу очереди (директива Freeze встречается в конфи-
гурационном файле T-Mail, она отличается от Hold тем, что ее действие
не перекрывается никакими другими директивами. Аналог Freeze есть
и в конфигурации The Brake! (секция Define Calls);
- принимает ли данный узел звонки в настоящее время? Анализ произво-
дится по нодлистовым флагам (см. FSC-0062 и его описание в главе 2)
и по дополнительным настройкам мейлера (в T-Mail это информация из
файла подстановок, subst.lst, для The Brake! аналогичная информация по-
мещается в основной конфигурационный файл, FrontDoor определение
времени работы по FSC-0062 не поддерживает);
- если узел звонки не принимает, но для него установлен статус IMMEDIATE,
звонок будет произведен;
- если для узла есть директива HOLD, звонок не производится (в T-Mail
можно указать максимальное количество почты и файлов, при достиже-
нии которого звонок все же производится, несмотря на статус HOLD);
- не был ли задан статус HOLD с клавиатуры? Если нет, звонок произво-
дится;
- если почта содержит только файловые запросы, то проверяется, в какой
момент данный узел поддерживает файловые запросы. Если время не сов-
падает, звонок не производится;
- если число попыток превысило максимальное значение, заданное в кон-
фигурации программы, звонок не производится, система помечается как
UNDIALABLE - «неотвечающая»;
- в многолинейной системе анализируется, не звонит ли другая линия на
этот узел. Если да, звонок не производится.
При этом для T-Mail справедливы дополнительные условия:
□ если хотя бы одно письмо имеет атрибут CRASH или IMMEDIATE, то лю-
бые директивы HOLD будут проигнорированы;
□ если все письма в пакете имеют атрибут HOLD, то звонок не производится.
Для более удобного управления очередью в процессе работы почтовой програм-
мы созданы дополнительные утилиты - менеджеры почтовой очереди. Примером
таких программ могут служить t-queue.exe кисти Александра Ведякина (2:5020/540),
предназначенный для использования совместно с T-Mail, или написанный на
REXX скрипт для управления очередью из мейлера The Brake! неизвестного ав-
тора. Как правило, такие программы предоставляют более широкие возможности
для просмотра и редактирования содержимого почтовой очереди, чем встроенные
процедуры мейлера.
Коммуникационная подсистема
Коммуникационная подсистема почтовой программы FidoNet может быть услов-
но разделена на следующие взаимосвязанные блоки:
□ взаимодействие с COM-портом через драйвер FOSSIL, который очень часто
используется как основной интерфейс взаимодействия почтовой программы
с коммуникационными портами. Для корректной работы параметры драйве-
ра FOSSIL и соответствующие настройки мейлера должны соответствовать
друг другу. Если, например, FOSSIL не использует фиксированную скорость
СОМ-порта, а в настройках мейлера указано LockBaud 3 84 0 0, то, вернее
всего, мейлер «не увидит» модем;
□ работа с модемом. Мейлер инициализирует модем в соответствии со своими
настройками. Строки инициализации модема, которые вы поместили в кон-
фигурацию программы, и номер соответствующего порта должны соответство-
вать используемому модему и порту, иначе мейлер также не сможет распоз-
нать модем. Как правило, возможные ответы модема помещаются в качестве
необходимых элементов конфигурации мейлера, их можно редактировать
и таким образом определять реакцию программы на любые экзотические со-
стояния современных модемов;
□ протоколы почтовой сессии и протоколы передачи файлов. Протоколы поч-
товой сессии (FTS-0001, EMSI, YOOHOO) и ассоциированные с ними про-
токолы передачи файлов были описаны в главах 3 и 5; современные почтовые
программы поддерживают все описанные протоколы почтовой сессии (иног-
да FTS-0001 поддерживается за счет внешней утилиты). The Brake! и T-Mail
поддерживают и двунаправленный протокол передачи файлов Hydra, в отли-
чие от FrontDoor, список допустимых протоколов которого заканчивается на
Zmodem. Мейлеры предоставляют широкие возможности конфигурирования
протоколов почтовой сессии и протоколов передачи файлов;
□ эмулятор терминала. Терминальная программа входит как вспомогательный
элемент во многие почтовые программы FidoNet, в частности, она поддержи-
вается всеми тремя описываемыми мейлерами. В основном входящий в со-
став мейлера терминал используется для тестовых целей, для настройки мо-
дема и т.п. Как правило, терминал может вызываться из основного окна
почтовой программы в процессе ее работы.
Интерфейс пользователя
Обычно почтовые программы снабжены самым
минимальным текстовым интерфейсом пользо-
вателя в стиле начала 90-х годов, исключение
составляют некоторые разработки последних лет
(например, Argus или FIPS). Однако, несмотря на
внешнюю простоту, возможностей, предоставля-
емых этим интерфейсом, оказывается вполне
достаточно для управления программой и ана-
лиза ее состояния. Традиционно информацион-
ное поле основного окна мейлера разделено на
три или более секторов, как это изображено на
рис. 7.6.
Назначение этих секторов следующее:
□ сектор 1 - сообщения, записываемые в протокольный файл;
□ сектор 2 - почтовая очередь;
□ сектор 3 - сообщения о событиях и/или сообщения модема.
Примеры такого подхода к внешнему виду основного экрана мейлера можно ви-
деть на большинстве иллюстраций к этой главе.
Во время сессии внешний вид экрана меняется, добавляется отображение дина-
мики сессии: информация о соединении, объемы передаваемой и принимаемой поч-
ты, текущие счетчики времени, переданные/принятые байты и т.п. Пример такого
отображения для почтовой программы The Brake! можно видеть на рис. 7.7.
Назначение секторов, на которые поделено окно The Brake! во время проведе-
ния почтовой сессии, остается прежним только для сектора 1 и меняется для сек-
торов 2 и 3. Теперь в секторе 2 выводится не почтовая очередь, а информация
Сектор 1 Сектор 3
Сектор 2
Рис. 7.6. Схематичное
изображение интерфейсного
окна почтовой программы
FidoNet
fa' Line 1, In, 2:5049/30.23@FidoNet, Send I = |O|
2:5049/12@FidoNet | The Brake!(tm) Mailer 718.a8/9999 I 01:56:44 1 33%
X Oo t Ж ОО-
1:17 ZS Мау.МрЗ, Z8P*16, 4293404, 22:56, file
:23 Send stalled: er*0 ht«792/W24 o<r 4895/4895,
iqs»0/4095
:24 Event 14:24 -> Poll 5849/36
224 Generate poll for 2:5849/368FidoHet (normal)
:28 Event 14:28 -> Poll 5849/30
:28 Generate poll for 2:5849/306FidoHet (normal)
:30 Event 14:38 *> Poll 2:5828/204
:30 Generate poll for 2:5820/2048FidoHet (normal)
Session ———--------——»_-----------------------
Send ZedZap*16
File : Нау.НрЗ
Size : 4293404
Gone : 4210246, 98$
Block x 0192
CPS : 3644, 116$
Time : 19:15 / 88:23
1Address ~
♦ Incoming call from 2682111:7: CORRECT 31200/ARO/V34/IAPH/V42BIS 4
2:5849/38,238FidoNet uses SF*Mail 1,87y0604/8081017
Iron’s Hall System, Kazan, Russia, Sergey F, Geleznov, .♦7*843*268*2111, 3360
Hon*protected session
1 AKAS: 2:5949/6,3 IWidoHet, ( 2:5063/17 U28FidoHet 1
Я Mail Files Total CPS 1
l“s 20 1/20 100$ 1/17568 >100$ Sil
1 19:26 | Wed 06/10 14: :36:57 | [ | | COMl 57600
Рис. 7.7. Отображение почтовой сессии но экране компьютера при использовании
мейлера The Brake!
о соединении, а в секторе 3 постоянно, по мере отправления, печатаются данные
о передаваемом в данный момент файле.
T-Mail в процессе сессии делит основное окно программы на шесть (!) секто-
ров, хотя состав и количество выводимой информации не слишком отличается от
того, что предлагает The Brake!.
Как правило, кроме этого простейшего информационного сервиса, возможен
доступ к интерактивному меню, позволяющему изменять характер отображения,
переключать режимы (например, выйти временно в операционную систему или
запустить эмулятор терминала). Работа в подобном меню для FrontDoor и The Brake!
изображена на рис. 7.8 и 7.9 соответственно.
Большинство или даже все функции меню можно, как правило, вызвать и с по-
мощью нажатия соответствующих клавиш на клавиатуре. T-Mail, например, вов-
се не имеет встроенного меню, нисколько не теряя от этого в функциональности,
так как все необходимые функции доступны по нажатию «горячих клавиш».
Список функций, вызываемых из этого меню (или по нажатию клавиш), зави-
сит от конкретной почтовой программы. FrontDoor, например, представляет со-
бой интегрированный пакет Fido-программ, и из меню мейлера вызывается и ре-
дактор писем, и терминальная программа, и компилятор нодлиста. T-Mail имеет
в некоторых вариантах поставки простой редактор почты и тоссер, но обычно эти
модули не конфигурируются для вызова из основного экрана программы, хотя
сделать это можно. The Brake! интересен возможностью написания скриптов на
расширенном варианте языка REXX для операционной системы OS/2, очень
удобных для создания служебных процедур.
Наиболее часто встречающиеся функции, вызываемые из основного экрана
мейлера, приведены в табл. 7.1 вместе со ссылками на соответствующие «горячие
FD/2 Mailer j ° jlffi
Programs Utilities J# ч--лай...й#нгс.> 1 Mail Your profile Wed 06 Oct 99, 8 42 I 1
Modem transmit
Alt- T
8:41 No (if
8:41
8:41
8:41
8:41
8:41
8:41
8:41
8:41
8:41;
8:41
8:41
8:41
8:41
Si t|||
Flag! И
Phon! Ц
sTyp
Sent! И
Proc! Il
Mai 1|H
From! Il
СгеаЦ
No rues
Modem disconnect
Lock keyboard
Transmit files
Request files
Send mail
Force poll (dynamic)
Force poll (static)
User exit .
Alt-X
Alt-L
Alt-Fl
Alt-F2
Alt-F3
Alt-F4
Alt-F5
Alt-D
sages to send in thi^even£
Waiting for a call
Initializing the modem (1)
Waiting for a call >
CONNECT- 21600;
’ 7nO/£ARRIEA :
- - / '
From:
6. 10,99 8:41
Kazan, Russia
Event;"0 /© '
i
$
Transmit string to modem
gl Line 1, Wait
LOG
17:34
17:34
17:34
17:35
17:36
17:36
17:36
17:36
Рис. 7.8. Меню почтовой программы FrontDoor 2.26
Node
Gene
Event
Gene
Send
iq-0/
Event
SE 0
Done
Send file(s)
Wait 82 sec
Mode:
Nf R
Dolt I
cancel
Poll 2:5020/204
17:45
9/30OFidoNet (normal)
9/64
9/640FidoNet (normal)
98/1024 oq-4G95/4095t
2:5049/30
24O00, 03:10
Immed
Crash
Direct
Normal
Hold
Addr:2:5049/49
File: net5049.ndl
Act ion
Answer:
Used:
2:5049
— Oueue: Hold
’•'Node
n>2:5020/790FidoNe
d
n
d
h
2:5020/2400FidoN
2:5020/269@FidoN
2:5020/549@FidoN
2:5032/15@FidoNe
h 2:5049/0BFidoNet
h
h
n
h
2:5049/20FidoNet
2:5049/50FidoNet
2:5049/60FidoNet
2:5G49/70FidoNet
0/0
0/0
0/0
0/0
1,4K
3.6K
1,7K
- 1, ,
234K . «
- 1» «
- i/«
. , .X. .
.,м...
,.M.,.
..,X..
M. . « . . .
...M...
1Address —
State
Disable
Disable
Disable
Disable
Disable
Ours
Disable
Hold
Disable
Hold
--------------j--------------------------
Рис. 7.9. Меню почтовой программы The Brake! 0.718
клавиши». В таблице, если в комментариях не указано другое, клавиша действует
в режиме ожидания звонка.
Кроме описанных, у каждого мейлера есть свои собственные команды. Те, кото-
рые приведены выше, представляют собой наиболее часто употребляемое подмно-
жество из большого числа используемых команд. Как видно из табл. 7.1, FrontDoor
несколько уступает более современным мейлерам в функциональной насыщеннос-
ти интерфейса, однако следует знать, что значение интерфейса пользователя для
почтовых программ не так уж и велико, без него можно обойтись. Существуют про-
граммы, например Binkd - почтовая программа для связи между Fido-системами
через Internet, в которых интерфейс пользователя почти полностью отсутствует, что
не мешает их успешному использованию на тысячах систем.
Таблица 7. /. Функции, вызываемые из основного экрана почтовой программы
(на примере FrontDoor, T-Mail и The Brake!)
Описание функции Клавиши выбора Комментарии
FrontDoor T-Mail Brake!
Вывести подсказку Alt-H Fl Fl
Вызвать меню Alt-H — F10 для Т-Mail отсутствует
Выйти из программы Alt-Q Alt-X Alt-X
Вызвать терминальную подсистему Alt-T Alt-T Alt-T
Сформировать Poll на заданный узел Alt-F4, Alt-F5 Alt-P Alt-P
Послать строку в модем Alt-T Alt-Z Alt-M
Ускорить совершение звонка Пробел Пробел Пробел звонок совершается на узел, выбранный курсором в почтовой очереди
Послать файл по заданному адресу Alt-Fl Alt-S Alt-S
Запросить файл с заданного адреса (создать Freq-файл) Alt-F2 Alt-R Alt-G
Немедленно ответить на звонок Alt-A Alt-A для FrontDoor отсутствует, можно воспользоваться Alt-T послать в модем команду «АТА|» («поднять трубку»)
Перепаковать всю почту, или пересканировать очередь для BSO Alt-Y Alt-Q для FrontDoor отсутствует
Получить расширенную информацию об элементе почтовой очереди 2 2 для FrontDoor эта функция доступна через менеджер очереди (Alt-M)
Пропустить текущий принимаемый файл — — Ctrl-X эта полезная функция поддерживается только T-Mail и действует во время приема файла
Изменить атрибуты элемента почтовой очереди Alt-C Ctrl-C Ctrl-H, Ctrl-U, Ctrl-B, Ctrl-1, Ctrl-R, Ctrl-O, Ctrl-D, Alt-C, Alt-U, Ctrl-F, H, C, 1, P, U Front Door и Brake! имеют в меню отдельные подсистемы для редактирования атрибутов элементов очереди; для T-Mail управление атрибутами осуществляется нажатием соответствующих клавиш.
Протокольные файлы
Интерфейс протокольных файлов, или, как их часто называют, лог-файлов (fog -
«журнал»), - это тот элемент почтовой программы, без которого трудно обойтись.
Всю информацию о любых событиях, случившихся в процессе работы програм-
мы, мейлер помещает в протокольный файл. Обработка протокольных файлов,
умение их читать и анализировать, слежение за размером логов, их периодичес-
кая чистка и архивирование или удаление представляют собой необходимые для
сисопа FidoNet навыки. Существует несколько стандартов де-факто на содержи-
мое протокольных файлов, и разработчики стараются их придерживаться, так как
при этом удается использовать для только что написанной программы большое
количество программ-обработчиков лог-файлов, собирателей статистических дан-
ных и других утилит, обычно называемых лог-менеджерами.
Детальность протокольного файла, как правило, конфигурируется. Каждая
строка лога снабжена временной меткой, например:
07/10/99 12:49:34 [2z02] S Session with 2:5049/12.15@FidoNet
где 07/10/99 - дата, а12:49:34 - время. Эта строчка взята из текстового про-
токольного файла мейлера The Brake!. Очень популярен формат протокольного
файла FrontDoor, послуживший образцом для многих программ. FrontDoor пер-
вым символом каждой строчки протокольного файла ставит символ-модифика-
тор, классифицирующий сообщение, помещенное далее в строке, как:
□ ! - фатальная ошибка;
□ ? - другие ошибки;
□ $ - информация по подсчету цены доступа к узлу;
□ * - связано с приемом или посылкой файла;
□ + - краткое сообщение;
□ — тривиальное сообщение;
□ : - информация о транзакции;
□ % - сообщение о процессе передачи данных;
□ # - неожидаемые пароли;
□ ~ - информация о сессии:
- ~ - альтернативные адреса (АКА) удаленной системы;
- ~ - информация, предоставленная удаленной системой;
□ = - ответы модема;
□ ' - тривиальный запрос файла.
Для FrontDoor-стиля лог-файла дата из строки убирается и помещается отдель-
ной строкой, например:
---- Wed 06 Oct 99, FD/2 2.26.SW
+ 08:40:35 Event 0-@
= 08:41:18 RING
- 08:41:32 CONNECT 21600/ARQ/V34/LAPM
# 08:41:35 Unexpected password, "forward", from 2:5049/30
+ 08:41:35 Guard Station line I, 2:5049/30
Содержимое протокольных файлов предназначено прежде всего для чтения
и анализа человеком, такие файлы занимают много места и очень хорошо архиви-
руются. Вам нужно регулярно либо удалять, либо архивировать и обрезать все
протокольные файлы. Приходится также просматривать протокольные файлы на
предмет поиска возможных ошибок, неверных паролей и т.д. Полезно получать
ежедневные отчеты, построенные на основании протокольных файлов и в сжатой
форме описывающие работу программы. Для автоматизации процесса можно вос-
пользоваться одной из многочисленных утилит, например программой Logman
Федора Павлова (2:5020/28.47), умеющей как удалять и архивировать протоколь-
ные файлы, так и усекать их до нужного размера.
Множество утилит написано для анализа содержимого протокольных файлов.
Такие утилиты не всегда бывают универсальными, поскольку формат файлов для
различных почтовых программ порой сильно отличается. Поэтому вам понадо-
бится утилита, которая точно может работать с протокольными файлами вашего
мейлера.
Для T-Mail это может быть:
□ Logmaker (Игорь Муравьев, 2:5030/415);
□ Analog (Михаил Кузнецов, 2:5080/68.17);
□ Winlog (Дмитрий Джемеров (Dmitry Jemerov), 2:5030/654);
□ T-Log (это просмотрщик, автор Мишель Мик (Mishael Mik), 2:5030/422).
Для The Brake!:
□ Abla (Ярослав Комаров, 2:5093/7);
□ Bia (Ex 2:5020/278);
□ Statmaker (Алексей Сорокин, 2:5058/17);
□ Bigview (просмотрщик бинарного лога, автор Павел Гульчук, 2:463/68).
Для FrontDoor подойдет универсальный генератор статистики UNILOG (Игорь
Суворов, 2:5020/1046).
Стандартным способом получения статистической информации от таких про-
грамм является почтовый интерфейс; результат их работы, который обычно полу-
чается в виде текстового файла, тем или иным способом посылается письмом си-
сопу или помещается в эху (последнее характерно для хаба, работой которого
могут интересоваться его линки). Для отправки можно воспользоваться одной из
утилит генерации письма из текстового файла (например, можно воспользовать-
ся утилитой feutil.exe из поставки популярного тоссера FastEcho). Пример выво-
да сводных результатов обработки лог-файла на примере обработчика ABLA для
мейлера The Brake! изображен на рис. 7.10.
Планировщик
Программа-планировщик, или шедулер (scheduler), входит в состав всех почтовых
FTN-программ. Мейлер всегда был «сердцем» почтовой системы FidoNet, и ло-
гично было сосредоточить все функции планирования работы именно в этой
программе прежде всего потому, что мейлер обычно активен при работе Fido-
узла. Конечно, мейлер нуждается в хорошем планировщике и для собственных
е.ехе - daystat1.log_______________, _:_______________________________________________________________Шо
________________________1_________________________:________________________________L.I.
♦ Abla reports. From 14 Feb 2000 00:00 to 14 Feb 2000 23:59 i&
♦ Session statistic. Answers: 21 Dials: 98
Success: 17(80%) Success: 15(15%)
f-Countq ।—Online—। ।---Traffic----1 CPS
In Out In Out Recv Sent Files
2:5049/5.0 2 0 04:14 00:00 0 354K 38.IK 1397
2:5049/12.42 1 0 01:32 00:00 0 68.IK 0 740
2:5049/19.0 1 7 00:05 09:38 643 1.8M 0 3091
2:5049/36.0 0 8 00:00 01:22:00 6.9M 984K 0 1612 —
2:5049/38.0 4 0 01:13:43 00:00 0 9.6M 5.8M 2191
2:5049/39.0 1 0 05:47 00:00 930 276K 0 800
2:5049/48.0 1 0 00:31 00:00 0 29 .9K 0 967
2:5049/49.0 1 0 00:09 00:00 0 0 0 0
Рис. 7.10. Статистический отчет о работе почтовой программы The Brake!,
оформленный с помощью программы ABLA
нужд - все мейлеры рассчитаны на круглосуточный автоматический режим рабо-
ты, и для периодического выполнения тех или иных задач (сканирования очере-
ди, звонков на заданные адреса и т.д.) нужна надежная и удобная в использова-
нии и настройке подсистема. Когда же подобный инструмент в наличии, грех не
использовать его и для других нужд, даже не всегда связанных непосредственно
с работой узла FidoNet.
Планировщик обычно руководит следующими процессами:
□ созданием полла на заданный адрес (POLL - «опрос», так именуют директи-
ву «позвонить»);
□ удалением полла на заданный адрес;
□ посылкой файла в заданное время на один или более адресов;
□ формированием файловых запросов на один или более адресов;
□ выходом из программы с установленным заранее параметром (например,
с заданным Errorlevel);
□ изменением правила маршрутизации почты (для АМА);
□ перепаковкой всей почты (для АМА) или пересканированием очереди;
□ перепаковкой почты для заданного адреса (АМА);
□ созданием/удалением файла-семафора;
□ выполнением внешней программы.
Ключевым элементом конфигурации планировщика служит такое понятие, как
событие. Его можно определить как соотнесенное с определенным моментом вре-
мени действие, которое при определенных условиях должно совершиться в ука-
занный момент времени или после него (или не выполниться вовсе).
Как правило, планировщик поддерживает задание времени в виде относитель-
ной даты в пределах недели (6.00 в понедельник). Легко реализуются процедуры
вроде «начиная с 12:00 каждые 5 минут выполнить данную программу» и т.п.
В основном окне программы обычно отображается информация о текущем
и следующем событии и времени, оставшемся до его наступления. Например, на
рис. 7.4 в правом верхнем секторе окна программы The Brake! можно разглядеть
строку:
Mode Call 59 sec
(означающую буквально «режим звонка, осталось 59 секунд») - относящуюся к те-
кущему событию. Ниже следуют строки:
Call: 2:5049/19
Used: 7200, 00:05
(«вызов 2:5049/19 завершен, скорость 7200, время на связи 5 секунд»), относящи-
еся к прошедшему событию, и далее следует:
Event: Poll 2:5020/204
Time: 15:45
(«событие: позвонить на 2:5020/204 в 15:45») - эти строки описывают грядущее
событие.
Широко распространенным приемом организации взаимодействия других про-
грамм с планировщиком является создание семафорных (флажковых) файлов.
Планировщик умеет правильно создавать и удалять такие файлы.
Правильная настройка планировщика позволяет запустить полностью автома-
тизированную систему, которая в течение очень длительного времени может ра-
ботать в автономном режиме, выполняя при этом все почтовые и административ-
ные функции без вмешательства человека.
Описание некоторых команд планировщиков, встроенных в АМА-мейлеры,
приведено в разделе «Маршрутизация почты и программы-упаковщики». А при-
меры полной настройки приведены в разделе «Примеры настройки почтовых про-
грамм».
Установка переменной TZ (зона локального времени)
Правильное определение текущего времени представляет собой важный момент
в конфигурации многих типов программного обеспечения, однако для почтовых
программ FidoNet этот параметр приобретает исключительное значение. Невер-
ное определение времени может привести к несоблюдению ZMH, к звонкам в не-
урочное время, отправке почты по неправильному маршруту, и в итоге доставит
сисопу множество мелких и крупных неприятностей.
При указании времени в FidoNet в качестве точки отсчета используется UTC
или GMT (универсальное время, или время по Гринвичу). Время в нодлисте зада-
ется именно в UTC (см. описанный в главе 2 флаг времени работы станции
U,TXY), в UTC определяется время ZMH, программа-планировщик тоже исполь-
зует UTC.
Для определения сдвига локального времени от стандартного вводится особая
переменная TZ (Time Zone, или «часовой пояс»). Это стандартный подход, пере-
менная TZ используется и устанавливается на уровне конфигурации операцион-
ной системы, но программы FidoNet часто используют ее расширенный синтак-
сис. Наиболее просто TZ задается как сдвиг в ту или иную сторону от UTC.
Например, летнее время для московской временной зоны (MSK) отличается от
UTC в меньшую сторону на 3 часа и обычно записывается как MSK+3.
Для задания TZ в DOS и OS/2 используется команда SET, позволяющая вво-
дить переменные окружения (environment variables) и присваивать им значения.
Нужно поместить в командный файл запуска или в основной конфигурационный
файл системы, config.sys, следующую команду:
SET TZ=MSK+3
Для Windows 95 и Windows NT воспользуйтесь стандартной утилитой установ-
ки даты и времени для выбора часового пояса (закладка TimeZone утилиты Date/
Time из папки Control Panel). Можно также выбрать TZ на этапе установки опе-
рационной системы.
Для нужд почтовой программы FidoNet может потребоваться измененная, бо-
лее сложная запись переменной TZ, определяющая даты перехода на летнее и зим-
нее время. Например, для мейлера The Brake! справедлива такая запись:
SET TZ=MSK-3MSD,3,-1,0,7200,10,-1,0,7200,3600
Иногда часовой пояс задается непосредственно в файле конфигурации почто-
вой программы и только в случае отсутствия берется из переменной окружения.
Например, для T-Mail можно написать в файле конфигурации:
UTC +3 ; Time Zone
и эта директива будет иметь приоритет перед переменной окружения.
Ищите инструкцию по конфигурации времени часового пояса в руководстве
к вашей почтовой программе.
Всегда проверяйте установку часового пояса и правильность хода часов на компью-
тере. «Сбившиеся» часы на одном узле могут испортить установку времени на всех
его линках, так как почтовые программы могут синхронизировать время при со-
единении, и эта возможность часто используется.
Маршрутизация почты и программы-упаковщики
В предыдущих главах уже обращалось внимание на вопрос маршрутизации поч-
ты в FidoNet. Именно этому посвящены разделы «Маршрутизация личной поч-
ты FidoNet» и «Маршрутизация почты (netmail routing)» в главе 1 и разделы
«Маршрутизация почты по нодлисту» и «Системы автоматической маршрутиза-
ции почты в FidoNet» в главе 2. В этой главе будут рассмотрены практические
вопросы конфигурирования почтовых программ, синтаксис записи правил марш-
рутизации.
В смысле настройки систем маршрутизации сеть FidoNet сложнее многих дру-
гих сетей. Ситуация, когда узел бывает связан постоянными или периодически
возникающими линками с десятками и даже сотнями других систем, многие из
которых в свою очередь являются маршрутизаторами, то есть принимают почту
для своих линков, не такая уж редкость.
Дело осложняется еще и тем, что общепринятого стандарта на описание марш-
рутов писем в FidoNet не существует, каждая программа использует свою моди-
фикацию синтаксиса. Ранняя попытка Бена Баркера (FSC-0003, [7-2]) как-то
стандартизировать эту область оказала некоторое влияние на авторов программ-
ного обеспечения (например, синтаксис route-файлов FrontDoor сформировался
явно под влиянием FSC-0003), но более современные программы используют
иной, более простой и удобный формат.
Администрировать такую сложную систему трудно, и системные операторы
иногда используют систему централизованного построения маршрутов почты,
описанную в главе 2 и далее в этой главе. Но для узла, который не предоставляет
или почти не предоставляет услугу маршрутизации почты другим системам, или
для пойнт-системы, все обстоит гораздо проще.
Если вы недавно подключились к FidoNet и у вас есть пойнт-адрес, то, скорее
всего, всю свою почту вы должны отправлять на станцию босса - узла, выдавшего
вам пойнт-адрес. В этом случае вся маршрутизация сводится к одной строчке вроде
Mail All 2:5049/12
означающей распоряжение всю почту отсылать через один адрес - адрес вашего
босса (для примера в качестве такого адреса взят 2:5049/12). Но не всегда прави-
ла маршрутизации бывают так просты. Поэтому вы можете пока только бегло про-
смотреть дальнейшее описание настройки систем маршрутизации почты и свя-
занных настроек событий планировщика и вернуться к этим страницам, когда ваша
система начнет доставлять почту другим участникам сети.
Как уже отмечалось в главе 4, существуют два основных способа подготовки ин-
формации к отправке - АМА (Arcmail-Attach) и BSO (Binkley-style outbound). Раз-
личаются они не только структурой исходящего директория, но и обычаем его под-
готовки: для АМА характерно использование встроенного в мейлер упаковщика
почты и все правила маршрутизации в случае АМА нужно помещать в один из фай-
лов конфигурации почтовой программы. Например, для FrontDoor это будет файл
route.fd, а для T-Mail - events.ctl. BSO-программы почту упаковывать не умеют, для
них необходимо достать и настроить отдельную программу - упаковщик почты в сти-
ле BSO. Это может быть, например, Itrack - автор Франк Прейд (Frank Prade) из
Германии, или Unimail - автор Вадим Румянцев (2:5030/301).
Еще одним возможным случаем является использование упаковщика почты,
встроенного в тоссер. Например, Fastecho умеет готовить BSO для почтовых про-
грамм и ее можно использовать как основное средство маршрутизации почты.
В этом случае все правила нужно описывать в меню настройки линков програм-
мы конфигурации Fesetup. Правда, при этом придется паковать нетмейл вместе
с эхами, что не всегда удобно.
Наконец, достаточно удобно пользоваться универсальным построителем фай-
лов маршрутизации, один из которых (Safrouter) описан в главе 2.
Остановимся теперь на конкретных примерах всех возможных систем описа-
ния маршрутов передачи почты. Наша цель - дать общее представление о спосо-
бах описания маршрутов, которое позволит вам с легкостью сориентироваться
при конфигурации любой программы, имеющей дело с маршрутизацией почты.
Перед началом описания программ, отметим, что записи любых правил марш-
рутизации присущ общий формат:
сспособ отправки> <что отсылать> <для адресов> <через адрео
Иногда позиции меняются местами, порой к правилу добавляется специфика-
тор, означающий распоряжение использовать для указанных адресов трехуровне-
вую (узел - хаб - хост) или четырехуровневую (узел - хаб - хост - региональный
хост) маршрутизацию, имеющуюся в нодлисте. Так что по своей сути правила
маршрутизации очень просты.
Правила записи адресов и групп адресов
Вопрос удобной записи адресов и их групп важен для записи правил маршрути-
зации. Довольно часто здесь приходится ссылаться на большую группу адресов,
и существуют общепринятые, хотя и различающиеся от программы к программе
(сказывается отсутствие стандарта), правила записи, которые в основном сводят-
ся к следующему:
□ при использовании сокращенной записи адреса вместо опущенных элемен-
тов подставляются значения из адреса данного узла или узла, полный адрес
которого указан в этой же строке. Так, например, запись 2:5049/12 16 36
эквивалентна записи 2:5049/12 2:5049/16 2:5049/3 6. Другой пример:
5049/12 .1 .12 эквивалентно 2:5049/12 2:5049/12.1 2:5049/12.12
(подставляется номер зоны, взятый из адреса станции);
□ для описания групп адресов используются метасимволы * и #. Значение их
в зависимости от использования в том или ином поле адреса может быть сле-
дующим (с вариациями от программы к программе, приведенные ниже пра-
вила полностью справедливы для Unimail):
- * эквивалентно *:*/*.* (любые адреса формата FidoNet);
- # эквивалентно *:*/#. 0 (все узловые адреса);
- zone : * эквивалентно zone: * / * . * (все адреса в данной зоне);
- zone: # эквивалентно zone: # / 0 (все координаторы данной зоны);
- zone: net/node эквивалентно zone: net/node. 0 (узловой адрес);
- zone: # / 0 означает адрес регионального шлюза адресата;
- zone : net / # означает хаб адресата;
- zone : region/# означает все узлы региона <region>;
- zone : net/node . # означает подхабник данного узла <node>.
Обычно все правила умолчания подробно описаны в документации на програм-
му, которая занимается упаковкой почты.
Последовательность учета правил маршрутизации
Как правило, файл маршрутизации считывается и обрабатывается программой от
начала к концу, так что более поздние правила перекрывают встречавшиеся ранее
(распространенный вариант: дополняют, но не отменяют). Поэтому более общие
правила следует располагать в конце файла.
Правила маршрутизации для АМА-мейлеров
Мейлеры ArcMail-Attach обладают возможностью маршрутизировать не только
личную почту (нетмейла), но и файлы. Как правило, описание маршрутизации
в них объединено с описанием событий планировщика, поскольку упаковщик поч-
ты тесно интегрирован с почтовой программой и грех этим не воспользоваться,
сделав маршрутизацию почты более гибкой.
Маршрутизации почты и файлов в мейлере FrontDoor
Файл описания маршрутов почты для мейлера FrontDoor называется route.fd.
Язык описания унаследован от FTS-0003, он многословен, но довольно удобен,
понятен и гибок. В целом синтаксис соответствует описанному в FSC-0003. В до-
кументации его описанию отводится двенадцать страниц, мы постараемся умес-
тить на двух. Для FrontDoor существует понятие «маршрут по умолчанию», кото-
рый действует, когда не указаны другие правила маршрутизации. Маршрутизация
по умолчанию сводится к трем позициям:
□ если почта адресована за пределы территориальной сети, она упаковывается
на хост данной сети (так называемая хост-маршрутизация);
□ если почта адресована на один из адресов данной территориальной сети, она
упаковывается на хаб, в подхабник которого входит данный узел (так назы-
ваемая хаб-маршрутизация);
□ если система, на которую адресована почта, помечена как Down или отсут-
ствует в нодлисте, почта для нее по умолчанию не маршрутизируется (то есть
вообще не упаковывается на отправку).
Понятие хоста и хаба описано в главе 2.
Далее рассмотрим основные директивы, которые могут встретиться в route.fd.
SCHEDULE
Все описания в route.fd заключаются в «скобки» директивы SCHEDULE, они оп-
ределяют название события, в рамках которого нужно применить данные правила
маршрутизации. События в конфигурации FrontDoor изображаются буквами латин-
ского алфавита, за исключением основного события, существующего всегда и обо-
значаемого знаком @. Поэтому правильным будет обозначение SCHEDULE А,
означающее, что все идущие вслед за этой строкой директивы, вплоть до следую-
щего слова SCHEDULE, принадлежат событию А.
Можно также привести список адресов, для которых предназначено данное
событие, например: SCHEDULE А 2:5049/12 19 30 3 6. Эта запись означает,
что данное событие описывает маршруты для систем 2:5049/12, 2:5049/19,
2:5049/30 и 2:5049/36 (действуют правила записи адресов, уже разобранные
выше).
Другой пример: SCHEDULE А 2:5049/* 2:5020/* - означает, что все адре-
са - в сетях 2:5049 и 2:5020.
HOLD <список адресов> или UNHOLD <список адресов>
Директива HOLD с последующим списком адресов запрещает звонить на опреде-
ленные в списке системы. UNHOLD отменяет действие директивы HOLD. При-
меры HOLD 2 : 5049/* и UNHOLD 2:5049/19 30 3 6 означают распоряжение не.
звонить на системы сети 2:5049, кроме 19-го, 30-го и 36-го узлов.
Строго говоря, это не команды маршрутизации. Эти команды соответствую-
щим образом конфигурируют почтовую программу и к маршрутизации имеют
косвенное отношение. Но для АМА-мейлера, каким является FrontDoor, коман-
ды такого типа входят в синтаксис правил маршрутизации.
ROUTE-ТО <адрес> <список адресов>
Эта команда означает, что вся почта для систем, перечисленных в списке адресов,
будет отправлена на указанный адрес. При этом в список адресов автоматически
добавляются и все пойнты узла <адрес> и все пойнты перечисленных в списке
адресов узлов.
Например: ROUTE-ТО 2:5020/204 *,то есть отправлять всю почту через
2:5020/204 (по описанным выше правилам записи адресов; значок * означает лю-
бые адреса).
ROUTE-FILES <адрес> <список адресов>
Действие этой команды аналогично описанной выше, за исключением того, что она
работает только с письмами, содержащими прикрепленные файлы. Заметим, что для
BSO понятия «машрутизация файлов» не существует и подобной команды там нет.
HUB-ROUTE <список адресов>
Это означает «использовать хаб-маршрутизацию для узлов из списка адресов». Хаб-
маршрутизация обычно не действует на письма с прикрепленными файлами. По
умолчанию, если хаб у узла отсутствует, используется его хост. Если содержащаяся
в списке система отсутствует в нодлисте, то почта пакуется на нее директом.
HOST-ROUTE <список адресов>
Аналогична предыдущей команде, только в качестве маршрутизатора использу-
ется хост (адрес /0). Если содержащийся в списке адрес отсутствует в нодлисте,
почта на него пакуется директом. Также не поддерживается случай передачи
файлов.
NO-ROUTE <список адресов>
Эта команда инструктирует FrontDoor отправлять почту для перечисленных
в списке адресов систем, используя директную отсылку Единственное исклю-
чение составляют Private и Hold-системы (формально недоступные для непо-
средственного соединения). Почта в этом случае пакуется на их хаб или хост.
Аналогично, если в нодлисте нет ссылок на пойнт-адреса, почта упаковывается
на соответствующий босс-адрес. Эта команда, так же как и две предыдущие, не
касается писем с прикрепленными файлами.
DIRECT <список адресов>
Команда DIRECT приказывает паковать почту для систем из списка адресов на-
прямую. В отличие от предыдущей команды, хаб- и хост-маршрутизация не ис-
пользуются. Почта для пойнтов пакуется на соответствующие босс-адреса. Пись-
ма с прикрепленными файлами игнорируются.
FORWARD-ТО <список адресов>
Обеспечивает автоматическую пересылку писем через данную систему для спис-
ка адресов. Если адрес назначения письма входит в указанный список адресов,
оно будет переслано в соответствии с правилами маршрутизации (описанными
в других строках), без участия сисопа. Письма с прикрепленными файлами иг-
норируются.
FORWARD-FOR <список адресов>
Обеспечивает автоматическую пересылку писем через данную систему от указан-
ного списка адресов. Если адрес отправителя письма входит в этот список, оно бу-
дет переслано в соответствии с правилами маршрутизации (описанными в других
строках), без участия сисопа. Письма с прикрепленными файлами игнорируются.
FILES-ТО <список адресов>
Обеспечивает автоматическую пересылку писем с прикрепленными файлами через
данную систему для списка адресов. Если адрес назначения письма входит в этот
список, оно будет переслано в соответствии с правилами маршрутизации вмес-
те с прикрепленным файлом, без участия сисопа. Эта команда действует только на
письма с прикрепленными файлами.
FILES-FOR <список адресов>
Обеспечивает автоматическую пересылку писем с прикрепленными файлами че-
рез данную систему от списка адресов. Если адрес отправителя письма входит
в этот список, оно будет переслано в соответствии с правилами маршрутизации,
вместе с прикрепленным файлом, без участия сисопа. Эта команда действует толь-
ко на письма с прикрепленными файлами.
POLL <список адресов>
Заставляет почтовую программу позвонить на системы, входящие в список адре-
сов. Эта команда имеет косвенное отношение к маршрутизации, однако она обычно
входит в синтаксис возможных команд файла маршрутизации АМА-мейлера. Как
правило, эта команда не используется в общей (@) секции route.fd. Она помещает-
ся внутрь какого-либо события и срабатывает в точно определенное время.
DENY <список адресов>
Не отдавать почту при входящих звонках от систем из списка адресов, только при-
нимать то, что они посылают на данную систему
SCRIPT <скрипт-файл> <список адресов >, NO-SCRIPT <список адресов>
Эти команды приказывают использовать (не использовать) определенный
скрипт-файл при звонках на узлы из списка адресов, обеспечивая чрезвычайную
гибкость настройке исходящих звонков FrontDoor.
EXCEPT <список адресов>
Эта полезная команда используется совместно с другими, описанными выше; она
позволяет исключить приведенный в ней список адресов из списка адресов ко-
манды, предшествующей команде EXCEPT, например:
NO-ROUTE 5049/*
EXCEPT 5049/12 5049/19 5049/30 5049/36
что означает: «исключить из маршрутизации все узлы сети 5049, кроме узлов 12,
19, 30 и 36».
Примеры файлов маршрутизации route.fd
Приведенный ниже простой пример может быть полезен при описании маршру-
тов писем для пойнт-станции (рис. 7.11).
Настройка файла событий и маршрутизации почты T-Mail
Файл маршрутизации почты T-Mail совмещен с файлом настройки событий
и называется events.ctl. Синтаксис языка описания более совершенен, сложнее
и компактнее, чем рассмотренный выше для мейлера FrontDoor. При этом исполь-
зуется большое количество параметров и модификаторов. Объединение описания
правил маршрутизации и настройки планировщика (описания событий) являет-
ся общей практикой для всех АМА-мейлеров, и мы вслед за автором документа-
ции к T-Mail (Петр Сучков, 2:5030/51) совместим описание этих двух связанных
сущностей. Общий синтаксис конструкций файла events.ctl таков:
[<task_ident>] [<modifier>] <keyword> <parameters> <time
period>
или
[<task_ident>] [<modifier>] <keyword> <parameters> <time>
где <task_ident> определяет номер задачи (T-Mail - это многолинейный мей-
лер, несколько экземпляров задачи могут работать одновременно, используя ин-
формацию из одного набора конфигурационных файлов).
<modif ier> представляет собой ключевое слово-префикс и может иметь только
одно из следующих значений:
□ Critical: описывает событие как критическое. Такое событие имеет минимум
шансов быть пропущенным по какой-либо причине (продолжительного се-
анса связи, выполнения внешней программы и т.п.);
gj е.ехе - route.fd ........... ..................... 1
File Edit Options Help ~ [
; ROUTE.FD
HOLD *
no-route *
|; ЭТА СЕКЦИЯ КВАЛИФИЦИРУЕТ ВСЕ СИСТЕМЫ КАК УЧАСТВУЮЩИЕ В МАРШРУТИЗАЦИИ |
| SCHEDULE ® *
ОТПРАВЛЯТЬ ВСЮ ПОЧТУ ЧЕРЕЗ 2:5049/1
jROUTE-TO 5049/1 *
|; ПОЗВОНИТЬ НА 2:5049/1
| POLL 1
|; ПОЗВОНИТЬ НА 2:5049/12
(POLL 12
КОНЕЦ ФАЙЛА ROUTE.FD J
Т 7 ..............."Г"..'.......7Г""~7"7'~7'"7."7'.Л.
Рис. 7.11. Пример настройки системы маршрутизации почты
в мейлере FrontDoor (содержимое файла route.fd)
□ Start: событие будет выполнено только однажды, в начале работы T-MaiL Для
такого события не может быть задан временной параметр в конце строки
в виде исключения;
□ Relative означает, что временной параметр, указанный в конце строки, до-
бавляется к текущему времени. Это действие совершается в момент чтения
файла events.ctl, при начале работы T-Mail, при выполнении действия
Control или перечитывании events.ctl после его изменения. Например, стро-
ка: Relative Hold All 0 :10-4 : 00 в 3.00 будет эквивалентна строке
Hold All 3:10-7:00.
В конце каждой строки может стоять интервал времени <time period>, опреде-
ляющий, когда действует данное правило или происходит данное событие либо про-
сто указано время <time> данного события, в этом случае интервал подразумевает-
ся равным одному часу, начиная с времени <t ime>. Не выполненное в течение этого
периода событие будет пропущено, если только оно не имеет префикса «Critical».
В некоторых директивах можно задавать в качестве дополнительного парамет-
ра атрибуты формируемых пакетов: (IMM), (CRASH), (HOLD), (DIR), причем
одновременно можно задавать несколько атрибутов, тогда они помещаются в одни
скобки и разделяются пробелом, например, (DIR IMM). При задании атрибута
вместе с номером задачи <task_ident> атрибут будет действителен только для
указанной задачи.
Очень удобен и широко используется на практике так называемый «указатель
периодического события». Этот указатель задается вместо <time period> и мо-
жет выглядеть, например, так:
Р.01:00
Символ «Р» вместо дня недели означает, что событие периодическое, а время
после точки задает интервал периодичности выполнения события. Отсчет интер-
вала начинается, после запуска T-Mail (или когда T-Mail перечитает файлы кон-
фигурации). Указатель периодического события можно использовать в файле
events.ctl только для директив POLL, SEND, POST, FREQ, UPDFREQ, DROP,
SET, EXEC, EXIT, REPACK, FLAVOR, BREAK.
В табл. 7.2, 7.3 и 7.4 приведена сводка директив файла events.ctl с краткими
комментариями. Более подробные описания некоторых правил маршрутизации
даны после таблиц.
Далее опишем некоторые директивы, которые важны для понимания специфи-
ки механизма настройки событий и системы маршрутизации почты в T-Mail. Бо-
лее подробное изложение материала следует искать в документации к T-Mail, ко-
торая существует на русском языке и, на наш взгляд, написана очень хорошо.
Следует обратить внимание на то, что T-Mail представляет собой универсаль-
ный мейлер, он может работать как в АМА, так и в BSO режимах, и многие дирек-
тивы планировщика меняют свой смысл при смене режима подготовки исходя-
щего директория.
Repack
Синтаксис:
[task ident] Repack [All] <time period>
[task ident] Repack <address list> <time period>
Таблица 7.2. Директивы описания событий (настройка планировщика)
в файле events.ctl почтовой программы T-Mail
Директива и параметры Комментарии
Poll [(attr)] <addr list> Инициировать опрос (poll) систем из <addres list>
Send [(attr)]<fname><addr Iist> Послать файл <fname> системам из <addres list>
Post [(attr)]<fname><addr list> Послать текстовый файл <fname> в виде письма системам из <addres list>
Freq [(attr)]<fname><addr list> Сформировать файловые запросы на файл <fname> для систем с адресами из <addres list>
UpdFreq [(attr)]<fname> <addr list> То же, что и Freq, файл будет принят только при том условии, что он более новый (по дате и времени создания или модификации), чем имеющийся
Exit <errorlevel> Выход из программы с кодом завершения <errorlevel>
Repack <addr list> Пересоздание очереди (всей или для адресов <addr list>)
Drop <addr list> Удалить служебные письма для адресов <addr list> и перепаковать для них почту
Exec <action> Выполнение внешней программы, запуск задачи в DesqView или выполнение действий по ключевому слову
Break <addr list> Прерывает сеанс связи в указанный момент времени
Flavor (<type> <flag>) <addr list> Изменяет в заданное время атрибуты определенных писем и файлов Bink-Style Outbound
Set <parameter>=<value> или Set @<filename> Замена значения параметра <parameter> из файла t-mail.ctl на <value> или замена с использованием файла <filename>
Таблица 7.3. Директивы наложения ограничений в файле events.ctl
почтовой программы T-Mail
Директива и параметры Комментарии
Limitin <limit> <addr list> Задает ограничение для входящих сеансов связи в минутах
LimitOut <limit> <addr list> Задает ограничение для исходящих сеансов в минутах
MailOnly <addr list> Запрещает обмен файлами с заданными системами, отправляется только почта (файлы *.РКТ)
SendOnly <addr list> Запрещает принимать файлы и почту при сеансах с указанными системами
Hold [(NN)] <addr list> Запрещает вызывать заданные системы
Таблица 7.4. Директивы маршрутизации в файле events.ctl
почтовой программы T-Mail
Директива и параметры Комментарии
* Mail-For <addr list><address> Задание правила маршрутизации почты по адресу получателя
* Mail-From <addr list><address> * Files-For <addr list><address> Задание правила маршрутизации почты по адресу отправителя Задание правила маршрутизации файлов по адресу получателя
* Files-From <addr list><address> * Direct <addr list> Задание правила маршрутизации файлов по адресу отправителя Отменяет всякую маршрутизацию почты и файлов для заданных адресов
* Deny <addr list> Запрещает формировать пакеты (АМА), сканировать Bink-Style Outbound и файловые ящики для заданных систем
Share <addr list><address> Добавление АКА к адресам удаленной системы
RestoreOut <addr list> Формирует служебное письмо (poll) в случае обрыва приема нетмейла и файлов при сеансах связи с системами, описанными в <addr list> Для исходящих сеансов связи
Restorein <addr list> Аналогично RestoreOut, но для входящих сеансов связи
Эта директива заставляет T-Mail в указанное время создать очередь (или ее
часть) заново. Если параметр <address list> не задан или задано REPACK
ALL, то заново пересканируется весь нетмейл, а также, если используются, то фай-
ловые ящики, персональные почтовые ящики и Bink-Style outbound, и очередь
формируется заново. Если задан список адресов <addr list> (включая *: */
*. *), то производятся те же действия, но только для адресов, входящих в этот
список, при этом не сканируются почтовые ящики.
Примеры:
Critical Repack 1:00
Repack /36 /30 5020/204 1:00
Drop
Синтаксис:
[task ident] Drop <addr list> ctime period>
Эта директива заставляет T-Mail в указанное время уничтожить все служебные
письма, которые были сформированы им самим на заданный адрес (адреса), то есть
письма от T-Mail Robot. Такие письма формируются при выполнении событий
POLL, FREQ, POST, SEND, UPDFREQ, заданных в events.ctl, а также если такие
письма были сформированы T-Mail при нажатии пользователем клавиш Alt+R
(File Request), Alt+S, Alt+D (SEND, DIRSEND), Alt+P (POLL). После уничтоже-
ния служебных писем почта для этого адреса (адресов) будет перепакована.
Примеры:
Critical Drop /2 1:00
Drop 5020/4 1:00
Flavor
Синтаксис:
[task ident] Flavor (<type> <flag>) <address list> <time
period>
Эта директива в указанный момент времени для определенной группы писем
изменяет их атрибуты (для Bink-Style outbound - изменяет расширение файлов
.?1о и .?ut). Допустимые значения:
□ <type> - тип письма:
- Mail - обрабатываются только обычные письма и файлы ?UT;
- Files - обрабатываются только письма с атрибутом FileAttached (с при-
соединенными файлами) и файлы .?1о;
- АП - обрабатывается все;
□ <f lag> - устанавливаемый атрибут:
- Hold - устанавливается атрибут HOLD;
- Crash - устанавливается атрибут CRASH;
- Normal - сбрасываются установленные атрибуты HOLD и CRASH.
Примеры:
Flavor (Mail Hold) 5020/*.* 15020/204 12:00
Flavor (Mail Normal) All 12:30
Flavor (Files Crash) /19 10:00
Flavor (All Hold) ZYX15:00
Mail-For и Files-For
Синтаксис:
[task ident] Mail-For <address list> <dest_address> [<time
period>]
[task ident] Files-For <address listxdest_address> [<time
period>]
Назначение: задает правила маршрутизации почты или файлов. Письма (или
файлы) для систем, перечисленных в <address list>, будут отправляться через
систему <dest_address>. Эти директивы похожи на аналогичные директивы
FrontDoor.
11 - 431
Примеры:
Mail-For 5020/* 15020/549 5020/204; Действует круглосуточно
Mail-For 5049/19 30 96 5049/36 4:00-9:00; Время действия
указано
Mail-For 5030/1 5030/6 3.4:00-6.9:00; Время действия указано
Files-For 5030/* 5030/6 6.4:00-6.23:59; Время действия 4:00-
23:59; По субботам
Mail-For All 5030/2; Действует круглосуточно
Mail-For @net5049.ndl 5030/6; Адреса из списка
Files-For 5049/* 5049/%; Через боссов
Files-or 50*/* 5049/36;Весь регион через 5030/2
Mail-For 5049/* 5020/* Hub; Хаб-маршрутизация
Mail-From и Files-From
Синтаксис:
[task ident] Mail-From <address list> <dest_address> [ctime
period>]
[task ident] Files-From <address list> <dest__address> [ctime
period>]
Эти директивы также задают правила маршрутизации почты или файлов. Их
использование и функции абсолютно идентичны описанным выше директивам
MAIL-FOR и FILE-FOR, за исключением того, что анализируется не адрес назна-
чения маршрутизируемых писем (файлов), а адрес их отправителя. В остальном
функции этих директив совпадают.
Примеры:
Mail-From 5049/30 15030/12.96 5049/36
Files-From 5049/* 5049/36 6.4:00-6.23:59
Priority
Синтаксис:
[task ident] Priority <address list> [ctime period>]
Данная директива придает некоторым системам на заданное время статус PRI-
ORITY. Это означает, что если есть почта или файлы для <address list>, то
T-Mail будет вызывать их и пытаться отправить эту почту, невзирая на всю осталь-
ную очередь. Когда вся почта для таких систем будет отправлена, T-Mail начнет
вызывать и другие системы.
Примеры:
Priority 5049/19 30 36 3:00-4:00
Priority @net5049.ndl 7:00-9:00
Пример файла events.ctl см. на рис. 7.12.
Рис. 7.12. Настройка маршрутизации почты и файлов в мейлере T-Mail
(содержимое файла events.ctl)
Дополнительные замечания о маршрутизации
почты и файлов в T-Mail
T-Mail, как и FrontDoor, поддерживает маршрутизацию по умолчанию. Но смысл
ее здесь несколько иной. Маршрутизация по умолчанию означает (в том случае,
если соответствующий адрес не указан явно в одной из директив MAIL-FOR,
FILES-FOR, DIRECT и не встречается в адресах, указанных в директивах MAIL-
FROM или FILES-FROM):
□ если это point вашей системы (то есть ваша система является узлом и номера
зоны, сети и узла совпадают с адресом вашего узла), то вся почта отправляет-
ся напрямую;
□ вся почта (без атрибутов HOLD, DIR, HUB, CRASH, FREQ, RECEIVED,
SENT, LOCK) и файлы для других пойнтовых систем будут маршрутизиро-
ваться через их боссов.
Прежде всего мы рассматриваем работу T-Mail в качестве АМА-мейлера. Рабо-
та внешнего BSO-упаковщика описана ниже.
н*
В режиме ArcMail-Attach T-Mail, как и FrontDoor, сам готовит себе почтовую
очередь, просматривая письма в нетмейл-фолдере. Для каждого письма T-Mail
анализирует адрес назначения и атрибуты писем. Если письмо не имеет атрибу-
тов DIRECT, CRASH, HOLD, FREQ, HUB, RECEIVED, SENT, LOCK, то далее
T-Mail просматривает правила маршрутизации, основными параметрами которых
являются:
□ <address list> - список адресов, для которых действует данное правило;
□ <dest address> - адрес системы-маршрутизатора.
T-Mail выбирает правила, действующие на данный момент времени и, если на-
ходит адрес назначения в <address list>, прибавляет письмо к пакету для
<dest address>. Наличие перечисленных выше атрибутов изменяет последо-
вательность действий (атрибуты CRASH, DIRECT, HUB и в отдельных случаях
FREQ для оказания воздействия на правила маршрутизации должны сопровож-
даться атрибутом LOCAL, то есть преимущество могут получить только «свои»
данные).
Если письмо имеет атрибут File Attached, то просматриваются правила марш-
рутизации с ключевыми словами FILES-FOR, FILES-FROM, DIRECT, в против-
ном случае - MAIL-FOR, MAIL-FROM, DIRECT.
T-Mail, как и FrontDoor, просматривает правила сверху вниз (то есть в том по-
рядке, в котором они встречаются в файле конфигурации), пока не встретит под-
ходящее. Поэтому более общие правила следует располагать в конце.
Если письмо имеет хотя бы один из атрибутов RECEIVED, SENT, LOCK, то
оно не пакуется вообще. Если письмо имеет атрибут HOLD, то оно упаковывает-
ся в Hold-пакет, который будет отправлен только при входящем вызове. Если
письмо имеет атрибуты HUB и LOCAL (и отсутствуют атрибуты HOLD, CRASH,
DIR, FREQ), то оно маршрутизируется через хаб (хост) системы адресата. Если
письмо имеет хотя бы один из атрибутов CRASH, DIRECT или FREQ, а также
атрибут LOCAL, то оно маршрутизируется напрямую на систему адресата.
В качестве параметра <address> директив MAIL-FOR, FILES-FOR, MAIL-
FROM и FILES-FROM может использоваться обозначение HUB, например:
Mail-For 5020/* Hub
При этом почта будет упакована для отправки на соответствующий хаб.
Если Hub для системы не определен, то хабом считается нулевой узел соответ-
ствующей сети (Host). Для независимых узлов в регионе (зоне) хабом считается
нулевой узел региона (зоны).
Упаковка почты для Binkley-style мейлеров
Конфигурирование упаковщика почты для Binkley-style проще, чем для АМА, так
как в этом случае механизм событий почтовой программы и правила маршрути-
зации упаковщика разнесены по двум конфигурационным файлам и никак друг
с другом не связаны. В составе BSO-упаковщика обычно имеется свой планиров-
щик, но он, во-первых, гораздо проще планировщика АМА-мейлера, и, во-вторых,
его можно вовсе не использовать. Причина этого в том, что упаковщик не работа-
ет постоянно, как мейлер, он только время от времени запускается основным пла-
нировщиком системы для упаковки почты. Обычно встроенный планировщик ис-
пользуется для изменения маршрутизации в зависимости от времени, например,
если пакет почты не ушел по основному пути днем, он уйдет ночью по резервному
пути.
В качестве BSO-упаковщика может работать специализированная программа,
такая как UniMail; может использоваться «комбайн» вроде Itrack (универсальный
обработчик нетмейла, который среди прочего работает и как BSO-упаковщик);
можно также использовать тоссер, поскольку он упаковывает эхи, как правило,
и в АМА-, и в BSO-режимах на выбор и может вместе с эхами паковать и нетмейл.
Это не всегда удобно, но применяется часто. В качестве примера рассмотрим кон-
фигурирование упаковщика UniMail.
Упаковка почты с использованием UniMail
UniMail, созданный программистом из города Петербурга (сеть 5030) Вадимом
Румянцевым, представляет собой очень компактный и надежно работающий упа-
ковщик нетмейла для BSO-мейлеров. Он есть в версии для DOS, Windows, OS/2.
Конфигурационных файлов UniMail обычно два - основной файл и файл описа-
ния маршрутизации route.cfg. Рассмотрим правила его заполнения.
Route.cfg можно условно разделить на две части: описание правил маршрути-
зации (статическая секция) и описание блоков событий. В каждом таком блоке
могут быть указаны дополнительные правила маршрутизации, справедливые
только во время данного события (динамическая секция).
При этом используются следующие правила записи сокращенных адресов
и групп адресов - адресных масок (табл. 7.5). Использованные в таблице ссылки
на типы адресных масок объяснены ниже.
При написании правил маршрутизации UniMail могут быть использованы ад-
ресные маски трех типов.
Таблица 7.5. Правила составления адресных масок для UniMail
Запись адресной маски Область покрываемых адресов Комментарии
* *.*у* * Любые адреса
# *:*/#.0 Любые узловые адреса
зона:* зона:*/*.* Любые адреса данной зоны
зона:# зона:#/0 Адреса координаторов данной зоны
зона:сеть/узел зона:сеть/узел.О Узловой адрес
зона:#/0 региональный шлюз Используется только в адресной маске «тип!»
адреса назначения>
зона:сеть/# <хаб адреса назначения> Используется только в адресной маске «тип1»
зона:регион/# <узлы в указанном регионе Используется только в адресной маске «тип2»
данной зоны>
зона:сеть/узел.# <подхабник адреса зона:сеть/узел> Используется только в в адресной маске «тип2»
Адресная маска ТипО
Маска этого типа представляет собой адресную запись в сокращении, отсутству-
ющие поля дополняются автоматически в соответствии с настройкой адресной
информации в основном конфигурационном файле UniMail.
Синтаксис:
[<номер>:]<номер>/]]<номер>[.<номер>]
или:
.<номер>
Примеры:
2 : 5049/12.12
. 12
5049/12
12
Адресная маска Тип1
В этой маске вместо номера могут быть использованы обозначения # и *, имею-
щие смысл «хаб (хост)-маршрутизация» и «любой адрес». Там, где допустима за-
мена на *, указано обозначение «номер 1»; где допустима замена на #, - «номер2».
Синтаксис:
[<номер1>:]<номер1>/]]<номер2>[.<номер1>]
или:
.<номер!>
или:
<номер1>:*
или:
Примеры:
2:5049/#.0
2 : *
Адресная маска Тип2
Маска этого типа используется при задании хаб-маршрутизации для групп адресов.
Синтаксис:
<Тип1>
или:
[<номер1>:[<номер1>/]]#
или:
[<номер1>:[<номер!>/]]<номер1>.#
или
.#
Примеры:
#
2:5049/#
5049/12 . #
В конфигурационном файле могут также встречаться описанные ниже команды.
NoBundle
Синтаксис:
NoBundle <маска адреса Тип2>...
Эта команда означает, что адреса, удовлетворяющие правилу <маска адре-
са>, должны быть проигнорированы при упаковке почты.
Пример:
NoBundle 2:5093/* ; (не паковать почту для сети 2:5093)
NoSend
Синтаксис:
NoSend [<условия>] <маска адреса Тип2>
Эта директива означает распоряжение не паковать почту для адресов, удовле-
творяющих правилу <маска_адреса>, при соблюдении условий <условия>,
если таковые описаны.
Условия, используемые при составлении команд конфигурационного файла
UniMail, сводятся к определению активности узла и его флагов (атрибутов, или
флейворов).
Пример:
NoSend .12 ; (не паковать почту для 12-го пойнта)
SendNul
Синтаксис:
SendNul [<условия>] <маска адреса Тип2>...
Эта директива означает распоряжение удалить почту для адресов, удовлетво-
ряющих правилу <маска_адреса>, при соблюдении условий <условия>, если
таковые описаны.
Пример:
SendNul 7:* ;(удалить почту для 7-й зоны)
Send
Синтаксис:
Send<flavor> [<условия>] <маска адреса Тип2>...
Эта директива приказывает упаковать почту для узлов, удовлетворяющих ус-
ловию <маска адреса>, при соблюдении условий <условия>, с флейвором
<f lavor>. Упаковка производится непосредственно на указанные адреса, без до-
полнительной маршрутизации.
Допустимы следующие значения параметра <flavor>:
□ HOLD;
□ NORM;
□ NORMAL;
□ DIRECT;
□ CM;
□ CRASH;
□ IMM.
Подробно возможные флейворы рассмотрены в главе 4 при описании BSO.
На параметр <маска адреса> могут быть наложены ограничения в зависи-
мости от типа команды. Подробности см. в образце конфигурационного файла,
поставляемого вместе с программой.
Пример:
SendHold .*
;(паковать почту на всех пойнтов директом, с флейвором "Hold")
Route
Синтаксис:
Route<flavor> [<условия>] <адрес или маска адреса Тип2> <мас-
ка адреса Тип1>
Эта директива приказывает упаковать почту для узлов, удовлетворяющих ус-
ловию <маска адреса Тип1>, при соблюдении условий <условия>, с флей-
вором <f lavor>. Упаковка производится на адрес <адрес> или в соответствии
с правилом <маска адреса Тип2>.
Примеры:
RouteDirect 2:5049/12 12.*
; (паковать директом на узел 2:5049/12 почту для него и для
его пойнтов)
RouteCrash *:*/* 106.* 272.*
;(паковать с флейвором Crash почту для узлов 106.* и 272.*)
RouteNorm 27 27.#
;(паковать с флейвором Norm на 27 узел почту для его подхаб-
ника)
Routelmm 0 2:50/#
;(паковать на хост с флейвором Norm почту систем 50-го реги-
она второй зоны)
RouteNorm ?А 2:5049/* 2:5049/*.*
;(паковать почту с флейвором Normal для пойнтов сети 5049
через их боссов,
если они активны и имеют коннекты с нашей системой)
RouteNorm 9Р5020/204 36 66.*
; (паковать почту с флейвором Normal для узла 66 и его пойнтов
через узел
;/36, если не работает узел 5020/204)
Poll
Синтаксис:
Poll<flavor> <маска адреса Тип0>
Сформировать POLL на адреса, удовлетворяющие правилу <маска адреса>.
Пример:
PollCrash 2:5049/*; (позвонить на все узлы сети 2:5049)
Schedule
Синтаксис:
Sched <Имя события> [<время> <время> <дни недели>]
Это ключевое слово описания событий. Механизм событий используется
встроенным планировщиком UniMail для изменения маршрутизации в те или
иные промежутки времени. При этом время задается как
[*]<hour>[ :<min>] (* означает UTC-время)
День недели записывается как:
□ АП (все);
□ Wkd (суббота и воскресенье);
□ Wke (суббота и воскресенье);
□ Sun, Mon, Tue, Wed, Thu, Fri или Sat (стандартный набор дней недели от по-
недельника до воскресенья).
Может быть указано несколько дней недели через символ |, имеющий смысл
логического оператора AND.
При использовании UniMail следует учитывать, что написание 2:5049/* экви-
валентно 2:5049/*.0, то есть набору узловых адресов. Все возможные (и пойнт-,
и узловые) адреса записываются как 2:5049/*.*.
Иллюстрацией к описанным правилам может служить реальный пример кон-
фигурации UniMail (рис. 7.13).
Упаковка почты с использованием эхо-процессора
Тоссер может быть использован для упаковки личной почты. Это даже удобно:
тоссер архивирует посылаемые пакеты, и если вы передаете большие объемы лич-
ной почты (например, на вашей системе работает сервер рассылки новостей или
FAQ-сервер), то это поможет существенно снизить загрузку линии. Тем не менее
е.ехе - route.cfg СТ
File Edit Options Help
NoSend .1 SendHold . * 48.400 RouteNorm ?A *:*/* 30. RouteNorm 96 6.# 96.# RouteNorm # *.* RouteCrash 0 O.ft 50/ft RouteNorm 36 1:* 2:* 3 * 36.* 19.* : * 4 : * 5 : ♦ 6 : z z f f z z z z z СТАТИЧЕСКАЯ СЕКЦИЯ Не паковать почту на фиктивного пойнта Использовать флейвор Hold для пойнтов данного узлаи пойнта 48.400 маршрутизировать почту для прямых линков и их пойнтов через них же (когда они активны) Ноды и пойнты под хабами /6 и /96 отправлять на /96 Для остальных узлоав в нашей сети использовать хаб-роутинг Для узлов под хостом для региона 50 - на хост Все остальное на /36
; Сначала идет описание Sched ZMH *02:30 *03:30 All RouteCrash ?A 2:5049/* 2:5049/*.* RouteCrash # 2:5049/*.* ; В остальное время Sched 00 00:00 01:00 All PollNorm 19 PollNorm 36 Sched 01 01:00 02:00 All PollNorm 30 Sched 02 02:00 03:00 All PollNorm 30 Sched 05 05:00 06:00 All RouteNorm 36 57.* 48.* 64.* • - --ДИНАМИЧЕСКАЯ СЕКЦИЯ правил для времени ZMH ; CrashMail для активных узлов ; CrashMail для остальных на их хабы ; Сформировать Poll на /19 и /36 ; с часу до двух ночи ; Сформировать Poll на /30 ; с двух до трех ночи ; Сформировать Poll на /30 ; с пяти до шести утра ; изменить правила маршрутизации: ; для /57, /48 и /64 - все через /36
Рис. 7.13. Пример конфигурации программы упаковщика почты UniMail
такое решение не используется на большинстве раздающих узлов, так как в этом
случае нетмейл начинает распространяться (на линке от вашей станции и до сле-
дующей по маршруту следования почты) вместе с потоком эхо-почты, что пони-
жает надежность доставки нетмейла.
Настройка маршрутизации почты в этом случае производится в конфигурации
тоссера и обычно очень проста. Мы рассмотрим ее на примере эхо-процессора
Fastecho. Для настройки маршрутизации нетмейла нужно в утилите настройки
тоссера fesetup.exe открыть меню описания линков, выбрать нужный узел
и в карточке настройки параметров линка нажать F2 вызова окна конфигурации
для маршрута для данного узла (рис. 7.14).
При этом можно использовать изложенные ниже правила составления адрес-
ных масок.
Используйте обычную запись адреса (зона:сеть/узел.пойнт), причем все струк-
турные единицы могут заменяться на символ * (означающее «любой»), или на
АН (имеющее аналогичный смысл). Существует пять уровней адресных масок:
*
Zone: *
Zone:Net/*
Уровень 1
Уровень 2
Уровень 3
Import
Fl Help
Рис. 7.14. Окно конфигурации маршрута в утилите fesefup.exe
2/8/
Addresses
Main:
ARCmail:
Name:
Your AKA:
Passwords
Packet:
AreaF ix:
Status
ARCmail:
AreaFix:
Packer:
Groups:
Security;
Group area defaults
Area configuration
Carbon Copies
AreaFix options
2:468/57.*
4D/Type 2+:
T osScan:
ARCmail 0.60:
Pack priority:
Convert Umlaut:
Alex Goldb
R15049/12
None
None
PKZIPl
Max
Al
re
low Area-Create:
a Default Group:
Export By Name:
AreaFix flags:
Send Noti
Send He
Passive
natic Passive:
Zone:Net/Node.*
Zone:Net/Node.Point
Уровень 4
Уровень 5 (Point=0 для узлов)
Причем уровни с большим номером имеют преимущество перед уровнями с мень-
шим, то есть если в окне настройки дана запись 2:* для одного узла и 2:5049/* - для
другого, то весь нетмейл для узлов и пойнтов сети 5049 будет маршрутизировать-
ся через второй узел, так как использованная маска адреса имеет уровень 3, имею-
щий приоритет перед уровнем 2 маски, использованной при описании правил
маршрутизации для первого узла.
Можно также использовать отдельный файл маршрутизации, заполненный
в соответствии с описанными выше правилами. В этом случае при запуске надо
указать тоссеру путь к нему.
После настройки маршрутизации нужно запустить fastecho.exe с ключом РАСК,
при этом возможны следующие варианты, управляемые дополнительными клю-
чами из командной строки:
FASTECHO PACK [-Р] [-1] [-F] [Adr [Adr ...] [via Adr]]
или:
FASTECHO PACK [-P] [-R<file>]
где [Adr [Adr ...] имеет смысл списка адресов, для которых необходимо произ-
вести упаковку, а обозначение [via Adr] - адреса, через который нужно напра-
вить почту
Значение дополнительных переключателей следующее:
□ -Р - упаковать «приоритетную» почту для BSO;
□ -I - упаковать только транзитную почту;
□ -R - использовать таблицу маршрутизации в файле <f ile>;
□ -F - не создавать файл-аттачей.
Создание конфигурационного файла маршрутизации
с использованием программы Safrouter
Запомнить правила построения маршрутных выражений для различных программ
нелегко, но иногда это бывает необходимо, скажем, если вы поддерживаете несколь-
ко различных по составу систем. И в этом случае вам может помочь Safrouter, опи-
санный ранее в главе 1 (раздел «Safrouter: роутинг по государевым запискам»)
и в главе 2 (раздел «Сафроутер»). Основным назначением этой программы являет-
ся организация централизованной системы маршрутизации почты в масштабах сети
или региона. Однако она с успехом может быть использована и как универсальный
построитель конфигурационного файла маршрутизации для многих других про-
грамм; на сегодняшний день поддерживаются Squish, T-Mail, Itrack, Bpack, ImBink,
Xmail, Ifmail, UniMail, Bip. Правила конфигурации самого Safrouter достаточно прос-
ты и понятны. Построенный с помощью Safrouter файл не обладает гибкостью «род-
ных», составленных вручную правил, но вполне годится для использования.
Использование нодлиста
Почтовые программы FidoNet совершают звонки на другие системы сети, исполь-
зуя информацию из текстовой базы данных - нодлиста, описанного ранее в главах
1 и 2. Кроме номера телефона почтовая программа берет из нодлиста данные о вре-
мени работы станции, поддерживаемых протоколах, отображает на экране и в про-
токольном файле наименование вызываемой станции и имя ее сисопа. Зачастую
при входящих звонках производится проверка на наличие вызывающей системы
в нодлисте. Словом, без нодлиста мейлер не работает. Правда, большинство почто-
вых программ может как-то существовать и на заменителях нодлиста вроде различ-
ных файлов подстановок, оверрайдов и т.п., то есть на введенных вручную отрыв-
ках информации о нескольких или даже только об одной системе FidoNet, с которой
только вы и связываетесь.
Это возможно, но это не означает, что такое использование мейлеров является
правильным и именно так и нужно поступать. Для успешной работы нужно до-
стать свежий нодлист, добиться, чтобы мейлер его «увидел», организовать перио-
дическое обновление нодлиста, и только тогда почтовая программа будет рабо-
тать так, как задумывал ее автор.
В этом разделе мы рассмотрим основные способы использования нодлиста
в почтовых программах, а также уделим внимание вопросам поддержки его в ак-
туальном состоянии.
Обработка нодлиста
для использования в почтовых программах FidoNet
Для того чтобы мейлер или упаковщик почты мог эффективно использовать нод-
лист, к нему создаются индексные файлы, обеспечивающие быстрый доступ к не-
обходимой информации. Эту работы выполняет программный компонент, назы-
ваемый компилятором нодлиста. Иногда компилятор встраивается в почтовую
программу (так сделал автор The Brake!), чаще он поставляется в виде отдельного
модуля (fdnc.exe для FrontDoor и tnc.exe для T-Mail).
Общепринятого стандарта на формат индексных файлов к нодлисту не сущест-
вует, но есть несколько распространенных форматов, из которых наиболее извес-
тны формат почтовой программы FrontDoor (формат Frodo) и так называемые
форматы Version? и Version 7 Plus (V7 и V7+), используемые мейлером Binkley,
а вслед за ним и многими другими мейлерами, редакторами почты и иными Fido-
программами. К примеру, V7 или V7+ поддерживают все версии Binkley Term
и модифицированный Binkley ХЕ, мейлеры MCMail, Portal of Power, редакторы
GoldED, TimEd и FleetStreet, обработчики нодлиста FastList и FastV7.
Большинство же программ используют или могут использовать свой собствен-
ный формат, иногда наряду со «стандартным».
В качестве примера рассмотрим форматы V7 и V7+ подробнее.
Форматы индексных файлов V7 и V7+
Подробную информацию об индексных файлах V7 можно почерпнуть из доку-
ментации к программе BinkleyTerm ХЕ, принадлежащей перу Альберто Паскаля
(2:332/504) и Томаса Вальдмана (Thomas Waldman, 2:2474/400) [7.3].
V7 представляет собой общепринятый стандарт для нодлистовой базы данных
(до сих пор мы называли V7 «индексом к нодлисту», поскольку такой термин
чаще всего используется, но на самом деле V7 - именно база данных). V7 состоит
из файлов с расширением *.ndx, это индексные файлы, и *.dat, файлы данных.
V7 использует известный метод доступа В-Tree для имен сисопов и адресов,
взятых из текстового нодлиста, и обеспечивает достаточную скорость доступа.
Однако исходный стандарт V7 не сохраняет в базе данных некоторые относи-
тельно недавно введенные элементы нодлистовой строки, в частности флаги време-
ни работы (U,TXY) и другие новые флаги, которые сейчас широко используются.
Стандарт V7+, совместимый снизу вверх с V7, обеспечивает следующие пре-
имущества:
□ вся информация, имеющаяся в нодлисте, помещается в файл базы данных V7+;
□ создается отдельный индексный файл для номеров телефонов;
□ используется метод семафоров для избежания конфликтов между другими
приложениями и компилятором V7+.
В остальном V7+ похож на V7. Файлы, созданные компилятором V7, могут
быть использованы и программами, поддерживающими V7+.
V 7/V7+ база содержит файлы:
□ nodex.dat- основной файл данных V7/V7+. V7+ остается совместимым
с V7, но добавляет новые данные;
□ nodex.ndx - традиционный В-Tree индекс (V7/V7+);
□ nodex.sdx - также традиционный В-Tree индекс, но созданный с приведени-
ем символов к верхнему регистру Большинство программ может использо-
вать nodex.ndx (V7/V7+);
□ nodex.dtp - файл данных, специфичный для V7+, содержит полную нодлис-
товую информацию;
□ nodex.pdx - В-Tree индекс телефонных номеров (только V7+).
Создание индексов к нодлисту
Перед тем как вы запустите мейлер, для него необходимо создать индексные нод-
листовые файлы (файлы базы данных в случае использования V7). Рассмотрим
этот процесс на примере трех уже знакомых почтовых программ и опишем по-
следовательность действий при создании базы V7/V7+. Для начала достаньте
актуальный файл нодлиста (как это сделать раассмотрено следующем разделе)
и скопируйте его в отдельный директорий своей Fido-системы. Предположим,
что это С : \FIDO\nodelist.
FrontDoor
Для использования нодлиста с FrontDoor укажите путь к нодлисту в утилите кон-
фигурации fdsetup.exe (Global => Filenames => Nodelist). Затем создайте в указанном
директории файл fdnode.ctl, содержащий основные конфигурационные директивы
для компилятора нодлиста FrontDoor. Пример такого файла приведен на рис. 7.15.
В этом файле перечисляются дополнительные пойнтлисты и нодлисты: основ-
ной по умолчанию имеет имя nodelist, далее приведена таблица преобразования
е.ехе - FDNC.CTL ........... | □
File Edit Options Help
j;компилировать только вторую зону
use zone 2
;использовать местные пойнтлисты и нодлисты
nodelist c:\fido\nodelist\net5049.ndl
nodelist c:\fido\nodelist\net5093.ndl
pointlist c:\fido\nodelist\pnt5049.ndl
pointlist c:\fido\nodelist\pnt5020.ndl
;ценовая таблица
;цена разговора до Москвы в копейках
Cost 400 60
7-095 3400 ; Москва
End
;таблица трансляции телефонных номеров
Dial /
7- 8w-
7-8432
7-843-2 J
End
Рис. 7.15. Пример конфигурационного файла fdnode.ctl
компилятора нодлиста fdnode.exe
Compile Nodelist
+ Compiling point list
Help
- Processing
- Processing
- Processing
- Processing
- Processing
- Processing
Zone
Zone
Zone
Zone
Zone
Zone
2
1
3
4
5
6
+ 20436 node(s) processed
-- Any key --
System Nodelist
Create a new nodelist database input files
Рис. 7.16. Компиляция нодлиста в программе fdnc.exe
+ Processing control file
- Incorporating C:\FID0\N0DELIST\PNT5049.NDL
+ Compiling raw nodelist (C:\FID0\N0DELIST\nodelist.281)
+ Reading userlist.. Sorting.. Writing.. Done.
Esc-Abort
**•*» 4***»*****-* • "**’> *!*„**# ****<!««*'* *0*.*л
4 ’ Л « Л Ш & Ж & -ч» '& Я»4-,» * Л tt' 4
телефонных номеров (код Казани - 8432, он может быть записан в нодлисте как
7-8432 или как 7-843-2, поэтому приведена и та, и другая запись). Цифра «7» -
международный код России. В файл включается также ценовая таблица, эта ин-
формация может быть использована при тарификации работы станции.
Формат пойнтлиста несколько отличается от формата нодлиста - в нем хранит-
ся информация о пойнт-адресах. Наличие пойнтлистов не является обязательным.
Теперь запустите программу fdnc.exe (FrontDoor Nodelist Compiler), и выбери-
те в меню Nodelist позицию Compile Nodelist. При компиляции вы получите от-
чет, изображенный на рис. 7.16.
Можно также запустить fdnc.exe в автоматическом режиме, используя ключи
командной строки -с (компилировать) или -f (компилировать, не анализируя
наличие уже имеющихся индексов); результат будет аналогичный.
После этой операции создаются индексные файлы nodelist.fdx и userlist.fdx,
позволяющие программам из комплекта FrontDoor пользоваться информацией из
нодлиста.
Почтовая программа T-Mail
T-Mail похож на FrontDoor в части компилятора нодлиста. Здесь также есть отдель-
ная программа tnc.exe, отдельный конфигурационный файл tnc.ctl, размещаемый
Рис. 7.17. Пример файла конфигурации tnc.ctl компилятора нодлиста tnc.exe
в корневом директории T-Mail. Однако в сравнении с FrontDoor возможностей
у этого компилятора существенно больше: с его помощью можно создавать уре-
занные по структурным единицам FidoNet индексные файлы.
На рис. 7.17 приведен пример конфигурационного файла из поставки T-Mail,
он достаточно хорошо комментирован; строки, начинающиеся с «;» представля-
ют собой строки комментариев.
Компилятор нодлиста запускается с помощью команды TNC и может иметь
в командной строке следующие ключи:
□ -С - компилировать нодлисты при необходимости (при изменении даты);
□ -F - компилировать нодлисты принудительно;
□ -R - создавать файлы rxx.net, содержащие списки сетей по регионам;
□ -S - нет вывода на экран (несколько ускоряет работу);
□ -? - подсказка.
При запуске TNC с ключом -С на экране компьютера должно изображаться:
С:\FIDO\t-mail>TNC.EXE -С
T-Mail nodelist compiler ver 4.1 (С) 1992-96 Andy Elkin.
Reading setup from C:\FIDO\T-MAIL\tnc.ctl
Incorporating list nodelist.281
Creating index list C:\FIDO\NODELIST\ndxlist.t-m
Compiling nodelist.281
Total nodes in this list: 19645, elapsed time: 0:25
Total nodes: 19645
Writing (disk) ........................
Done. (0:00)
После чего в директории С: \FIDO\NODELIST будет создан индексный файл
ndxlist.t-m.
T-Mail, в отличие от FrontDoor, может работать и без нодлистов. Для этого нуж-
но записать основные параметры всех нужных вам систем в файле подстановок
subst.lst (подробнее об этом смотрите в документации к T-Mail).
The Brake!
Мейлер The Brake! имеет встроенный компилятор нодлиста, запускающийся ав-
томатически из основного окна мейлера при изменении одного из описанных
в конфигурации нодлистов. На рис. 7.18 изображен этот процесс. Для того чтобы
мейлер «увидел» нодлисты, в файл Brakel.ctl нужно вставить строки, представ-
ленные на рис. 7.19, пример взят из рабочей конфигурации The Brake!, коммента-
рии принадлежат автору программы.
Обозначения #outbound# и tnodelist#, приведенные на рисунках, - это
макропеременные, замещаемые при интерпретации конфигурационного файла со-
ответствующими символьными строками из числа переменных окружения, кото-
рые задаются в командном файле перед запуском самой программы:
SET FidoPath=C:\FIDO\
SET PATH=%PATH%;%FidoPath%BRAKE!\APICMD;%FidoPath%PKTMAKER;
Д Line 1, Wait_______
2:5049/12@FidoNet | The Brake!(tm) Mailer 718.a8/9999
= LOG
09:43
09:43 :
Ив
P 00.30| QQ%
09:43
09:43
Start of The Brake! (tm) Mailer 718.a8/9999,
PID 254e
Operating System/2 20.30.00. boot drive C:
System up 19:33:52 with 66715648 bytes of
Mode:
Wait 90 sec
09:43
09:43
09:43
— Queue: 0
Node
memory and 1 CPU(s)|
MMPM/2 sound device
The Brake’(tm) Mail
Event 08:47 -> Poll
Compile
Answer:
Used:
2:5049/108
21600, 00:07
NodeList:
Done:
Zone :
egion:
Net:
Total:
R50Pnt.023
00:00, 0%
0
0
0
14550
Event:
T ime:
None
None
r-------------- 1 Address —
It r^-T r*h |TM state
Empty queue ***
189M | Fri 15/10 09:44:03 |
R | 5П5 Ян@ BUS RI CD RQ SQ I C0M1 57600
Рис. 7.18. Процесс компиляции нодлиста в почтовой программе The Brake!
Рис. 7.19. Отрывок из конфигурационного файла brake!.ctl,
отвечающий за настройку подсистемы управления нодлистами
SET Messages=%FidoPath%BRAKE’\MESSAGES
SET Nodelist=%FidoPath%NODELIST
SET Outbound=%FidoPATH%outbound
SET FreqTree-%FidoPATH%FILE\FRQ
SET InBound=%FidoPath%FILE
SET Protected=%FidoPath%FILE
SET LogPath=%FidoPath%LOGS
SET LongBoxes=%FidoPath%FILES\LONG.BX
SET TBoxes=%FidoPath%FILES\BOXES
SET FlagDir=%FidoPath%FLAGS
SET RexxPath=%FidoPath%BRAKE!\BRAKE-RX
SET RexxDialPath=%FidoPath%BRAKE!\DIAL
SET WavePath=%FidoPath%BRAKE!\MULTIMED
SET LocPath=%FidoPath%BRAKE!
SET Line=%l
Такой подход обеспечивает дополнительную гибкость конфигурации: исполь-
зуя несколько различных командных файлов, можно существенно варьировать
любые параметры конфигурации. Вместо переменной #Line# подставляется но-
мер линии.
Конфигурация системы нодл истов в мейл ере The Brake! имеет особенности,
отличающие ее от таковой для FrontDoor или T-Mail, а именно:
□ используемые нодлисты прямо связаны с определением исходящего директо-
рия (outbound). Это характерная черта любых BSO-мейлеров (см. описание
BSO в конце главы 4);
□ при описании нодлистов для Brake! используются модификаторы Replace
и Add, позволяющие установить режим использования названного дополни-
тельного нодлиста - либо он замещает существующие в других нодлистах
строки с тем же адресом (Replace), либо дополняет (Add);
□ списки нодлистов могут быть по-разному распределены по линиям мейлера,
для каждой линии можно установить свой список.
Описанные особенности обеспечивают удобство и гибкость использования
нодлистов в мейлере The Brake!.
FastList и FastV7
Когда самым популярным компьютером был IBM PC XT, некоторые операции по
обслуживанию узла FidoNet занимали очень много времени. В частности, подолгу
работали программы создания индексов к нодлистам. И если сейчас работа компиля-
тора нодлиста продолжается пару десятков секунд, то тогда под управлением DOS
3.3 те же самые операции могли продолжаться час и более. Поэтому вас не должна
удивлять приставка «Fast» в названии программы, имеющей дело с нодлистом; это не
желание выделиться, просто программу писал участник сети, раздраженный нетороп-
ливой работой имеющегося в его распоряжении компилятора нодлиста.
Программы FastList и FastV7 работают действительно быстро, кроме того, эти
программы поддерживают распространенный формат Version? и его усовершен-
ствованный вариант Version 7 Plus, используемый многими программами, и пото-
му заслуживают внимания.
Обе этих программы представляют собой утилиты, управляемые ключами ко-
мандной строки. FastList имеет текстовый конфигурационный файл, а для FastV7
существует утилита конфигурации, внешне напоминающая таковую для мейлера
FrontDoor.
К сожалению, обе эти программы поставляются как условно-бесплатные
(shareware), и их использование без регистрации после окончания испытательно-
го периода, срок которого оговорен в лицензии, распространяемой вместе с про-
граммой, незаконно.
Возможности программы FastList, существующей в версиях для DOS16, DOS32,
Windows32, OS/2 таковы:
□ компилирует в формат V7;
□ поддерживает «старый» список fidouser.lst;
□ не только создает индексы V7, но и дополняет существующий нодлист с ис-
пользованием разностного файла;
□ может создавать сразу несколько нодлистов и V7 индексов;
□ может автоматически архивировать используемые нодлисты;
□ использует файл определения архиваторов compress.cfg в стиле тоссера Squish;
□ производит компиляцию только если найдены измененные файлы;
□ поддерживает многозадачность;
□ может автоматически послать в виде письма по FidoNet отчет о компиляции;
□ поддерживает 4О-адресацию с использованием в нодлисте (пойнтлисте) клю-
чевых слов «Point»/«Boss»;
□ использует дополнительные нодлисты в формате Node, address...
Fast V7 существует в версиях для DOS и OS/2, и предоставляет возможности:
□ создавать конфигурационный файл в формате (на выбор) FrontDoor,
D’Bridge или Binkley Term;
□ создавать индексные нодлистовые файлы для Maindoor, FrontDoor, Version?,
McMail, OT-Track, Termail, Remote Access и GoldED;
□ поддерживать нестандартные форматы нодлистов вроде fidouser.lst, различ-
ные форматы пойнтлистов;
□ прикомпилировать нодедиффы к нодлисту;
□ поддерживать все популярные программы-архиваторы, включая ARC, ARJ,
РАК, LZH, RAR, ZIP, SQZ и даже UC2.
Конфигурирование компиляторов нодлиста несложно и аналогично описанно-
му выше для случая встроенного компилятора мейлера; нужно указать адресную
информацию, задать директории для хранения и поиска нодлистов.
Преобразование нодлиста с использованием разностного файла
Основные принципы системы распространения нодлиста были рассмотрены в гла-
вах 1 и 2. Их суть кратко сводится к еженедельному распространению по сети раз-
ностного файла - нодедиффа (nodediff) и поддержке с его использованием нод-
листа в актуальном состоянии. Формат разностного файла описан в главе 2.
Преобразование нодлиста посредством разностного файла осуществляется с ис-
пользованием специальных программ - нодедифф-процессоров (nodediff processors),
обзор которых приведен ниже.
Как нодедифф-процессоры могут использоваться многие компиляторы нодлис-
та (например, FastList). В качестве примера рассмотрим три специализированных
популярных процессора:
□ FDND, разработанный автором мейлера FrontDoor, Иахимом Хомригхаузе-
ном. Это старая заслуженная DOS-программа, некогда использовавшаяся
очень широко, как и сам мейлер FrontDoor;
□ NodeLife Сергея Терехова, автора Bink/+, почтовой программы для DOS.
Этот процессор работает в версиях для DOS и OS/2;
□ NDP - универсальная DOS-программа с интерфейсом а-ля a TurboVision,
разработанная участниками сети из Екатеринбурга Владимиром Копыловым
(2:5080/7) и Сергеем Викуловым (2:5080/5).
Программа FDND
Эта shareware-утилита расшифровывается как FrontDoor NodeDiff Processor, версия
1.10 и разработана специально для FrontDoor, но может также применяться и без дан-
ной почтовой программы. FDND может использовать внешний нодлист-процессор
мейлеров FrontDoor или InterMail (ключи командной строки /F и /Т соответ-
ственно). Другие ключи применяются для указания, как обращаться со старыми
нодлистами - удалять их после создания нового или сохранять, проверять ли со-
хранность нодлиста по CRC и т.п. Программа за один запуск обрабатывает до 10
нодлистов. Других примечательных особенностей, кроме странного оконного ин-
терфейса и назойливых предложений зарегистрировать экземпляр программы
(опоздавших на 5 лет) у программы нет, и пользоваться ей можно только в том
случае, если вам не удастся достать что-нибудь получше.
Программа NodeLife (версия 1.5)
NodeLife рекомендуется использовать в качестве основной программы тем, кто не
любит излишние украшения. Эта утилита проста, эффективна и работает очень
быстро. Она позволяет добавлять до 16 диффов к старому нодлисту и генериро-
вать новый без промежуточных стадий. NodeLife разрешает держать на диске не-
полный нодлист (только выбранные вами зоны/регионы/сети) и обновлять его
с помощью обычных общедоступных диффов полного нодлиста. Также в процес-
се работы производится полный контроль целостности создаваемых файлов (про-
верка по CRC и соответствие FTS-0005) и комплектности диффов, выдается пол-
ная диагностика.
NodeLife сам распаковывает необходимые для работы нодедиффы и «понима-
ет» форматы архивов ARC, РАК, ZIP, LZH, ZOO, LIM, НРК, SQZ или ARJ. Под
OS/2 количество распаковываемых архивов меньше - ZIP, ARJ и LHA (при этом
требуются unzip.exe, lh.exe, и unarj.exe).
Отметим также, что большинство нодедифф-процессоров производит поиск
последнего нодлиста и нодедиффов упрощенно: если есть один нодлист - берется
именно он, если два - берется нодлист с большим номером. NodeLife же узнает
день недели генерации нодлиста из первой строки, строит таблицу всех этих дней
недели за прошлый год и на основании полученной информации производит по-
иск нужных файлов.
Формат командной строки вызова NodeLife таков:
NODELIFE [ключи] [nodelist/nodediff]
По команде NODELIFE -h (или -?) вы увидите краткую инструкцию.
Программа NDP - NodeDiff(tm) Processor, версия 3-15
Эта красивая программа делает все, что нужно, и даже немного больше, сопро-
вождая свои действия цветными окнами, ползунками и т.д. в стиле текстовой гра-
фики Turbo-Vision. К сожалению, программа существует только в версии для
DOS. Всего в пакет NDP входит четыре утилиты:
□ ndputil.exe - конфигурирование NDP;
□ ndpcut.exe - создание урезанных нодлистов;
□ ndp.exe - собственно nodediff-processor;
□ пкнеск.ехе - утилита проверки CRC-кода нодлиста.
NDP автоматически ищет, подключает все имеющиеся нодедиффы и делает это
достаточно быстро. Особенно удобна утилита ndpcut.exe, «мгновенный снимок»
ее работы изображен на рис. 7.20.
Рис. 7.20. Интерактивная утилита ndpcut.exe
используется для создания усеченных нодлистов
NDP может урезать нодлисты по структурным единицам - зонам, регионам, се-
тям, что бывает очень удобно при организации пойнт-станций, где большой нод-
лист не всегда нужен, а достать удалось именно его. Вместе с программой постав-
ляется детальное описание на русском языке, и после его прочтения трудностей
в освоении программы у вас возникнуть не должно.
Примеры настройки почтовых программ
Правильная настройка почтовой программы не является тривиальной задачей не
столько из-за формальной сложности устройства мейлера, сколько по причине
большого количества и разнородности настроечных параметров. В этом разделе
будет приведена настройка основных параметров трех уже упоминавшихся почто-
вых программ. В примере показаны некоторые (не все, но наиболее важные, на
взгляд автора) элементы конфигурации мейлеров, разбитые по темам:
□ системная информация;
□ время работы станции и ZMH;
□ дополнительные настройки - поведение мейлера до, после и во время почто-
вой сессии;
□ настройка модема и коммуникационной подсистемы;
□ сигналы и семафоры.
Системная информация
Первое, что вы должны заполнить при настройке мейлера, ~ это ваши данные: ос-
новной адрес и все альтернативные адреса, название станции, принадлежность к сети
(FidoNet не единственная сеть, поддерживающая FTN-технологию).
В качестве примера используется следующая информация:
□ название системы: Double Dozen;
□ имя сисопа: Amir Shabashvili;
□ основной адрес: 2:5049/12;
□ альтернативные адреса: 2:5049/0, 2:5049/12.12;
□ домен: FidoNet.
Вот как записывается это для FrontDoor, T-Mail и The Brake!:
FrontDoor. В утилите fdsetup.exe выберите в меню Global позицию Address =>
Address и установите основной адрес (Main) и АКА. Затем, последовательно вы-
бирая Global => Address => Site Info, запишите информацию о названии станции
и об используемом домене. Дополнительная информация, запрашиваемая в раз-
деле Site Info, включает телефон станции, ее местоположение, скорость модема
и нодлистовые флаги. Точность этой информации решающего значения не имеет:
она предъявляется на этапе установления соединения и записывается в прото-
кольный файл на другой системе - более никак не используется. В отличие от
этого, адресная информация очень важна, и ошибки здесь недопустимы, так как
при неверно указанном адресе вы можете не получить свою почту или даже заб-
рать чужую;
T-Mail. В текстовом конфигурационном файле T-Mail необходимо указать ана-
логичную информацию (см. рис. 7.21).
The Brake!. Аналогично T-Mail, заполните в Brake!.ctl блок EMSI (на рис.
7.22 приведен пример многолинейного узла, указаны параметры для каждой
линии в отдельности).
Отметим, что первым блоком в Brake.Lctl идет нодлистовая информация.
Определение нодлиста, netmail,
outbound и inbound директориев
Определение путей к необходимым для работы мейлера файлам, входящим и ис-
ходящим директориям имеет важное значение для его работоспособности.
Эта часть имеет некоторые различия для АМА- и BSO-мейлеров, например нет-
мейл-директорий не нужен для конфигурации BSO-мейлера, так как такие мейле-
ры используют внешний упаковщик, который и занимается просмотром сетевой
Ш е.ехе - t-mailctl
Rie Edit Options Help
Address 2:5049/12.0®fidonet основной адрес
AKA 2:5049/0.(№ fidonet первый AKA
AKA 2:5049/12.12®fidonet второй AKA
SysOp Amir Shabashvili имя Сисопа
BBSname Double Dozen название станции
Phone 7-812-Pri-Vate телефонный номер станции
Country 7 i телефонный код страны
Place Kazan, Russia i местоположение
Рис. 7.21. Отрывок конфигурационного файла T-Mail.ctl почтовой программы
T-Mail, отвечающий за настройку системной информации
е.ехе - Brake Lett j ° ]□
Be Edit Options Help
Define EMSI ; Блок EMSI информации
Address 2:5049/12 Address 2:5049/0 Address 2:5049/12.12 SysOp "Amir Shabashvili" Place "Kazan, Tatarstan, Russia" ; Основной адрес ; Хост-AKA ; ПОЙНТ-AKA ; Имя сисопа ; Место расположения
#For 1 System Phone Speed Flags ftEndFor "Double Dozen" 7-843-249-9994 33600 V.34,HST,MO,XW,CM ; Наименование ; Телефон ; Максимальная ; Флаги станции скорость
#For 2 System Phone Speed Flags ftEndFor "Double Dozen Line ] [" 7-843-249-9994 33600 V.34,HST,MO,XW,CM ; Наименование ; Телефон ; Максимальная ; Флаги станции скорость
End «У*
„.J
Рис. 7.22. Отрывок конфигурационного файла Brake Let/
почтовой программы The Brake!, отвечающий за настройку системной информации
|И..FC/2: fdsetupZ....
File
loba I
Mailer Editor Terminal Modem Printer Manager
! ° 1П1
Address
NetMail
Files
SecFiles
Packets
Log file
Banner
Modelist
No BBS
C:\FIDO\FDX
C:\FIDO\MAILXFDMAILX
C:XFIDDXFILEX
C:\FIDO\FILE\
C:XFIDOXFDXTMPX
C: XFIDOXLOGSXFD.LOG
C:\FIDOXNODELISTX
Bad
HMB
HMB
JAM
BPS
files
extra
extra
TempPath
Semaphore
MailExit
D:XFIDOXMSGBASEX
D:\riDO\MSGBASEX
C:XFTDOXALLFIXX
Inhere FrontDoor*s system files are located
Рис. 7.23. Пример заполнения наименований директориев в утилите
конфигурации fdsetup.exe почтовой программы FrontDoor
почты перед ее упаковкой. В АМА упаковщик встроенный, и там этот параметр
необходим.
FrontDoor. Необходимо заполнить форму: fdsetup.exe, Global => FileNames
(рис. 7.23).
Опущенные поля не являются обязательными (они описаны в документации,
поставляемой с программой), а заполненные имеют следующее значение:
□ SYSTEM - основной директорий системы;
□ NETMAIL - Netmail-директорий, содержащий письма в формате *.msg;
□ FILES - директорий для входящей и исходящей почты;
□ SECFILES - «секретный» INBOUND/OUTBOUND директорий;
□ PACKETS - временный директорий для *.рк!-файлов;
□ LOG FILE - основной протокольный файл;
□ NODELIST - директорий, где хранятся нодлисты;
□ TEMPPATH - директорий для временных файлов.
T-Mail. Отрывок конфигурационного файла см. на рис. 7.24.
The Brake!. Исходящие директории системы, используемый домен и нодлист
для BSO-мейлера связаны. Пример их конфигурации для The Brake! уже был рас-
смотрен в этой главе. Что же касается остального, то пример из конфигурацион-
ного файла Brakel.ctl с использованием макропеременных (они уже рассматрива-
лись) представлен на рис. 7.25.
е.ехе - t~rnail.ctl Fite Edit Options Help [•]□!
Sys_path C:\FIDO\T-MAIL\ системный директорий
Inbound C:\FIDO\FILES\ ; директорий для входящих файлов iInboundUnProtected C:\FIDO\T-MAIL\uncheck\ ; входящий "несекретный" ; директорий - здесь хранится информация, ; полученная по непарольнгым сессиям. Log Tm.log ; имя основного протокольного файла iChat_Log chat.log ; имя протокольного файла для Chat-режима Packets C:\FIDO\T-MAIL\PACKETS\ ; здесь хранятся исходящие пакеты FileBoxes C:\FIDO\T-MAIL\FBOXES\ ; здесь создаются "файлбоксы" - исходящие ; директории, упрощающие доставку файлов ; на некоторые адреса. Для каждого адреса ; может быть создан отдельный файлбокс, и ; все файлы в этом директории доставляются ; определенному адресату. BinkOutbound C:\FIDO\OUTBOUND\OUTBOUND ; Основной исходящий директорий ; для BSO-режима. Mail_In C:\FIDO\T-MAIL\MAIL\ ; Сюда помещается входящая почта Mail_Out C:\FIDO\T-MAIL\MAIL\ ; Это исходящий NetMail-директорий
NodelistPath C:\FIDO\NODELIST\ Пусть к нодлистам iO
Рис. 7.24. Отрывок конфигурационного файла T-Mail.ctl, отвечающий
за настройку нодлистовой информации и основных директориев
"Й е.ехе - brakel.ctl Но
File Edit Options Help 1
InBound ftlnBound# Protected ^Protected# TBoxes #TBoxes# LongBoxes #LongBoxes# Flags ftFlagDir# RexxPath ftRexxPath# ; Приемный каталог для непарольных сессий ; Приемный каталог для парольных сессий ; (по умолчанию совпадает с InBound) ; файловые боксы T-Mail ; файловые боксы с длинными именами (hpfs) ; Директорий файлов-флагов ; Директорий REXX процедур
1 а
Рис. 7.25. Отрывок конфигурационного файла Brakel.ctl, отвечающий
за настройку нодлистовой информации и основных директориев
Время работы станции и ZMH
Время работы станции обычно определяется в нодлисте с помощью символьных
флагов. Отсутствие всяких флагов в нодлистовой строке означает работу в режи-
ме ZMH-only (только в зональный почтовый час), наличие флага СМ - круглосу-
точную работу, а при имеющемся пользовательском флаге U,TXY можно точно
определить время работы станции. Все это имеет отношение к тому, как сисоп счи-
тает нужным представить время ответа станции на внешние звонки других
пользователей сети. На самом деле время работы станции более сложный пара-
метр, чем это может показаться на первый взгляд. Его составляющими являются:
□ время ответа на звонки;
□ время, когда возможно совершение исходящих звонков;
□ время, когда разрешены звонки от пользователей BBS;
□ дополнительное определение ZMH (это время, когда станция ведет себя осо-
бенным образом, и иногда требуется изменение описанного в нодлисте вре-
мени, обычно в сторону увеличения).
Необходимо также отметить, что истинное время работы и обозначенное в нод-
листе могут радикально различаться. Например, по нодлисту станция может быть
ZMH-only (то есть работать только в ZMH), на самом же деле работать в режиме
СМ (круглосуточно). Гибкость конфигурирования временных параметров мейле-
ра в значительной степени определяет удобство его использования.
FrontDoor. Для FrontDoor время работы станции определяется при описании
событий встроенного планировщика. Каждое событие имеет время начала и кон-
ца, а в свойствах события указывается, является ли оно inbound only (система рабо-
тает только на ответ, сама никуда не звонит), разрешено ли ей отвечать на звонки
и могут ли приниматься звонки от пользователей BBS (пример из fdsetup.exe,
Manager => Events, изображен на рис. 7.26).
В приведенном примере описываемыми параметрами являются:
□ [Answer inbound calls] - «отвечать на входящие звонки»;
□ [Inbound only] - «самим не звонить»;
□ [Allow users during event] - «разрешен доступ пользователям BBS».
FrontDoor не имеет возможности устанавливать время ZMH, вместо этого мож-
но соответствующим образом настроить одно из событий. Такой подход не слиш-
ком удобен, хорошо было бы в дополнение иметь возможность задать глобальные
параметры с определением времен ответа на звонки и совершения исходящих
звонков, но за неимением другого для работы вполне годится и этот способ.
Отметим, что FrontDoor не поддерживает широко используемые флаги време-
ни работы U,TXY, в отличие от The Brake!, T-Mail и многих других современных
почтовых программ, что само по себе свидетельствует о почтенном возрасте этого
мейлера.
T-Mail. В T-Mail все нужные параметры устанавливаются удобнее, в виде гло-
бальных параметров, вне механизма событий (рис. 7.27).
The Brake!. У The Brake! описание параметров времени ответа и вызова чрез-
вычайно удобно и предусматривает все возможные случаи, включая переопреде-
ление ZMH и задание времени звонков на узлы с нужным флейвором, с определе-
нием глобальных параметров и параметров для каждой линии, что иллюстрирует
пример на рис. 7.28.
Дополнительные настройки - поведение мейлера
до, после и во время почтовой сессии
Дополнительных настроек, определяющих поведение мейлера до, после и во вре-
мя сессии с другими системами, очень много. Перечислим только главные из них:
□ принимать ли почту от систем, отсутствующих в нодлисте;
□ принимать ли почту во время сессий, не защищенных паролем;
□ запускать ли BBS по требованию пользователя;
FC/2: fdsetup2
| ° |о
й Т Days
М Start Length Lev Min Max Delay Last run
Behavior
Days -------ft
Modifier Ignore eventbase
Start time 00:0ft
Length 00:01
Errorlevel 0
Min.cost 0
Max.cost
Retry delay
Busy retries
Completed today
0
0
n/a
Yes
Exit when mail is received Ha
High priority (Crash/IMM) mail only No
Allow file requests Yog
Pickup file requests No
Don’t send file requests No
Don’t send non~mail file attachments No
Don’t send mail file attachments No
Attempt to pickup waiting mail Yes
Allow nodes to pickup waiting mail Yes
Prioritize outbound calls No
Delay before placing first call No
Inbound only No
End event when no more mail to send No
Send to CM systems only No
Send to non-CM systems only No
Send to systems once only Йо
Answer inbound calls Yes
Miscellaneous options
Space-Toggle
Рис. 7.26. Настройка времени работы станции и времени ZMH
в конфигурационной программе fdsetup.exe
е.ехе - t-mail.ctl____________________________________________________________________________________| ° |Р
File Edit Options Help
Call_Time 0:00-00:01
Answer 0:00-24:00
EMSI—OH 3:00-8:00
BBS_Time 0:00-24:00
; Время, когда разрешены исходящие звонки
; Время ответа на звонки
; Информация о времени ответа, помещаемая в
; блок данных EMSI
; Время, когда разрешен доступ пользователям
; BBS
Рис. 7.27. Настройка времени работы станции и времени ZMH
в почтовой программе T-Mail
Рис. 7.28. Настройка времени работы станции и времени ZMH
в почтовой программе The Brake! (файл Brakel.ctl)
□ какие AKA предъявлять удаленной системе;
□ сколько делать попыток прозвониться на удаленную систему (и какие при
этом использовать временные задержки);
□ разрешено ли синхронизировать время с удаленной системой;
□ распаковывать ли принятую почту
А также многие подобные перечисленным настройки. Количество и продуман-
ность дополнительных настроек, некоторые из которых бывают совершенно необ-
ходимы, определяют удобство использования данной почтовой программы и в ко-
нечном итоге прямо влияют на ее распространенность.
FrontDoor. FrontDoor не блещет обилием возможных настроек, но есть все не-
обходимые (рис. 7.29).
T-Mail. В приведенном ниже примере (рис. 7.30) приведены не все возможные
для T-Mail настройки, а только основные, дающие представление о возможностях
этой программы.
The Brake!. Этот мейлер похож на T-Mail в части определения многих парамет-
ров, но что касается задания адресов, которым можно звонить и от которых мож-
но принимать звонки, The Brake! оригинален. Для определения этих параметров
в The Brake! используются так называемые «регулярные выражения», широко
известные по UNIX-утилите egrep версии 8 и позволяющие достаточно компакт-
но строить чрезвычайно замысловатые логические конструкции (рис. 7.31).
Настройка модема и коммуникационной подсистемы
Настройка модема в почтовой программе должна соответствовать настройке ком-
муникационного драйвера (обычно это FOSSIL, для OS/2 и UNIX возможно ис-
пользование драйверов операционной системы) - в этом основной секрет пра-
вильной настройки коммуникационной подсистемы Fido-станции. Кроме этого,
Рис. 7.29. Дополнительные настройки почтовой программы FrontDoor
(утилита fdsetup.exe)
gj е.ехе - t-maitxtt
File Edit Options Help
;Unpack No ; He распаковывать файлы *.PKT
Unpack_Size 2048 ; Максимальный размер *.РКТ, который разрешено распаковывать
Kill—Empty Yes ; Удалять пустые письма
Kill_Transit Yes ; Удалять транзтные сообщения после посылки
;Transit_Files_From 5049/* ; Разрешение пересылать файлы для систем из списка
;Transit_Files_For All ; Разрешение пересылать файлы системам из списка
; Другие примеры (" 1 " означает отрицание):
; Transit— FileS—From V32B 1/12.19
; Transit—FileS—From 2:5049/12.12 50/*.* 137 /96.1
; Transit—Files—For Фtrlist.txt ; trlist.txt - список адресов
;Audit_Send—Msg Yes ; Разрешено ли автоматически отвечать на
;Audit—RRQ_Msg Yes ; флаг ARQ (запрос ответа на прохождение ; письма через Ваш узел). При ответе ; используется файл-шаблон AUDIT.TPL ; То же самое, но для атрибута
Accept—Nodes All ; RRQ (Шаблон RETREQ.TPL). ; Список систем, с которыми возможна связь
; Другие примеры: ; Формат списка см. в описании T-Mail
; Accept—Nodes 5049/*.* 1СМ 15049/37
; Accept—Nodes <8>C:\FIDO\T-MAIL\in_list.txt
Accept—AKAs *:*/*.* ; Какие AKA удаленной системы будут
; использованы при приеме/отправке почты.
; Другие примеры:
; Accept—AKAs 2:*/*.* 1:*/*.* 3:*/*.* 12:5049/999.999
Рис. 7.30. Дополнительные настройки почтовой программы T-Mail
(файл T-Mail.ctl)
Рис. 7.31. Дополнительные настройки почтовой программы
The Brakel (файл Brakel.ctl)
нужно правильно инициализировать модем, описать его возможные отклики, за-
дать соответствие символьных строк, выдаваемых модемом, реакции на них со
стороны мейлера и поведение в режиме ответа.
FrontDoor. В утилите fdsetup.exe для конфигурации модема выделено отдель-
ное меню Modem из пяти позиций:
□ Hardware - задание номера порта, режима его использования (фиксирован-
ная скорость или нет), максимальной скорости порта, способа использования
сигнала DTR (рис. 7.32);
□ Connect Messages - определение нестандартных ответов модема при уста-
новлении соединения (обозначение N/A- «недоступно» - вызвано исполь-
зованием некоммерческой версии, в которую включены не все возможности
программы, см. рис. 7.33);
□ Status messages - задание диагностических сообщений модема (рис. 7.34);
□ Command strings - задание строки инициализации и других командных
строк модема (символ | имеет смысл перевода строки). Правильная строка
инициализации - непременное условие работоспособности почтовой про-
граммы. Если в строке сделана ошибка, на которую модем отвечает ERROR,
то даже в том случае, когда модем после посылки такой строки сохраняет ра-
ботоспособность, программа работать не будет (рис. 7.35);
Рис. 7.32. Настройка аппаратных параметров модема в утилите fdsetup.exe
| « |1О11
FDSETUP2.EXE
[Modeml
Printer Manager
File Global Mailer Editor Terminal
'Custom connect message and the appropriate DCE speed (BPS)
Рис. 7.33. Определение ответов модема в утилите fdsetup.exe
□ Answer control - управление ответом мейлера на внешний звонок. Задается,
разрешен ли «ручной» ответ (так автор FrontDoor называет ответ по появле-
нию символьной строки RING, а не по наличию аппаратного сигнала RI. Это
достигается установкой в 0 регистра SO модема, командой ATS 0 = 0. После это-
го модем перестает снимать трубку в ответ на звонки, и делает это только по
команде АТА, поступающей от почтовой программы). Также определяется, на
Рис. 7.34. Задание диагностических сообщений модема в утилите fdsetup.exe
IS FDSETUP2.EXE
File Global Mailer Editor Terminal ЗЕЕИ Printer Manager
;' Command strings'
AT
AT
ATSO~0MOU1E0QGX4S7"55|
athg)
"'ATH1|
0
ATDT
Рис. 7.35. Задание командных строк для инициализации модема в утилите fdsetup.exe
Return on-line
On-hook
Off-hook
RingingAbort
Dial
tPrefix
Suffix
Delay
Init-1
Init-2
Init-3
Termlnit
Down
Attention.
какой по счету звонок необходимо отвечать, нужно ли сохранять дополни-
тельную символьную информацию, поступающую в промежутках между сиг-
налами RING (пункт Enable LDFRS) и т.п. (рис. 7.36).
T-Mail. T-Mail иногда использует отдельный файл конфигурации модема с именем
modem.ctl (включенный в основной файл командой INCLUDE). Часть информации
d FDSETUP2.EXE
File Global Mailer Editor Terminal
Modem
Printer Manager
ва^пмваЛМИг
Abswe r о I;
f-
Force answer
Force answer
Answer after
Enable LOFAS
“NO DIALTONE
command-1
command-2
ring tt
is “BUSY
ATfil
1
No
No
Answer calls during init No
*
|opgright 1999 Definite Solutions HB; fill rights reserved.
ВИ
* л
« >
*
¥
If enabled, the Mailer will instruct the modem to answer incoming calls -
Рис. 7.36. Задание командных строк для управления ответом
на внешний звонок в утилите fdsetup.exe
е.ехе ~ t-mailctl i о ]□
FHe Edit Options Help
;============================== Определение порта ============================
; Параметры, определяющие коммуникационный порт (порты)
Port 2 ; Номер порта (1, 2, 3, ...) О используется для безмодемной линии.
Baud 33б00 ; Максимальная скорость модема
Lock_Baud 57600 ; Скорость "залочки" порта
;============================== Контроль модема ==============================
;.............................Управление модемом.............................
Init_Interval 10 ; Время цикла инициализации модема (в минутах)
Busy_Hang_Off Yes ; Держать трубку снятой, если мейлер занят
;=== T-MAIL ==================== Конфигурация модема ========================
Командные строки
Initl "ATZ|" ; Строка инициализации модема
Init2 "ATE0&D2&C1M1S7=255SO=O|~ ; Дополнительная строка инициализации модема
Modem_OK АТ| ; Команда модема "Внимание". Модем должен ответить"ОК"
Dial_Prefix Default ATDT
Dial_Suffix |
Dial_Terminate " |
Onhook v“ ATH0|
Of fhook "ATH1|
Modem_Answer ~ "ATA |
Statistics ~ATI6 |
Команда набора номера
; Команда, выдаваемая после набора номера
; Команда завершения строки набора номера
; Команда "Положить трубку"
; Команда "Снять трубку"
; Команда "ответить на, звонок"
; Команда построения статистики для USR
Ответы модема
Busy BUSY ; "ЗАНЯТО"
No_Dial NO DIAL ; "НЕТ ГУДКА"
Ring RING ; "ЗВОНОК"
Ringing RINGING ; "Вызывной гудок"
AttemptOn BUSY NO CARRIER NO ANSWER ; Счетчик попыток дозвона
AnswerOn RING NO DIALTONE ; Строки ответа
;========================= Управление исходящими вызовами =================
Time_Dial 50 ; Время ожидания соединения
Call_Tries 25 ; Число попыток дозвона
Max_Rings 8 ; Прекратить ожидание соединения после заданого количества гудков
Circle 45 ; Цикл ожидания звонка
__ _
Рис. 7.37. Отрывок файла конфигурации модемов modem.ctl
для почтовой программы T-Mail
12 - 431
(иногда вся) находится и в T-Mail.ctl. T-Mail имеет исключительно развитую подсис-
тему конфигурирования модема и ответного поведения мейлера. Для ее конфигури-
рования откройте с помощью текстового редактора файл modem.ctl, отрывок которо-
го изображен на рис. 7.37, и исправьте его в соответствии с особенностями вашего
модема (на рисунке modem.ctl представлен в сокращении относительно поставляемо-
го вместе с T-Mail, последний снабжен подробными комментариями).
The Brake!. Этот мейлер похож на T-Mail по обилию разнообразных регулиро-
вок и параметров, которые можно устанавливать для оптимизации работы ком-
муникационной подсистемы. Комментированный отрывок реального конфигура-
ционного файла двухлинейной системы приведен на рис. 7.38 и 7.39.
Сигналы и семафоры
Почтовая программа представляет собой только часть Fido-системы. Она взаимо-
действует с несколькими другими программами, работа которых зависит от при-
нятой почты. Для автоматизации процесса взаимодействия этих программ с мей-
лером служит система файлов-семафоров или других программных сигналов,
которые мейлер подает при различных событиях, таких, как, например, прием
нетмейла или эхо-почты.
е.ехе - brake Lett | °
File Edit Options Help
Define Modem
ftFor 1
Port 1
ftEndFor
ftFor 2
Port 2
ftEndFor
ftFor 1 2
Baud 57600
ftEndFor
Waitcall 90
WaitAnswer 50
Autolnit 300
Monitor 3
; Параметры модема
; Для первой линии
; установлен СОМ1
; Для второй линии
; установлен COM2
; Фиксированная скорость порта для
; обеих линий
; Время ожидания соединения после набора номера
; Продолжительность цикла ожидания звонка
; Время в секундах от последней инициализации до переинициализации
; "Безопасное" время пропадания DCD в сек.
Flowcontrol Hardware ; Хэндшейк Hardware ( cts/rts ) или software ( XON/XOFF ) умолчание
BreakMode No ; Будет ли использоваться сигнал BREAK
ftFor 1 2
HardWareRing Yes ; определять наличие звонка как аппаратного или символьного
ftEndFor
Ring Busy Ok Connect NoDialTone RRing NoCarrier Error Voice NoAnswer NoConnect RING ; переопределение BUSY OK "CONNECT" "NO DIAL TONE" RRING "NO CARRIER" ERROR VOICE "NO ANSWER" "NO CONNECT" строк от модема
BadCounter RRING ; Строки от модема
BadCounter ERROR ; по получении которых при
BadCounter VOICE ; наборе номера
CallersID "CallerID: " i*
Init AT&Fl+SFQ0+S34=10+SAl+SBl+S64=lS58.0=l+s3=3+s4=3| ; строка инициализации модема
Answer ATA ; Команда ответа на строку "RING"
Hangup v +++~АТН| ; Положить трубку (" это 500 мсек.)
#For 1
DialPrefix ATDT8 ftEndFor #For 2 DialPrefix ATDT #EndFor Dialsuffix | AfterDial Префикс набора номера для линии 1 Префикс набора номера для линии 2 Суффикс набора номера (' | 1 ‘ <сг>) При неудачном наборе номера
AbortDial v | Collision No MinlnBound 1200 MinOutBound 300 #For 2 Window yes #EndFor Window no WindowAt 3 3 WindowOff 10 QueueStats NO ARQ /HST Ha IfDuplex FAST MaxRRing 50 RingCount 1 RingWait 10 End Circle 120 80 Redial 12 Maxincoming 120 MaxOutGoing 200 Строка, посылаемая в модем, чтобы прервать набор номера попытаться ответить и при "RING" и т.п. мин. скорость соединения при ответе мин. скорость соединения при наборе Показывать ли модемное окно (по умолчанию - No) Аналогичная глобальная команда X & Y позиция окна модема на экране время неактивности модема до закрытия окна (секунд) окно статистики модемной input очереди Если встроке CONNECT есть подстрока /HST, то исп. коррекция ошибок Если встроке CONNECT есть подстрока FAST, то полудуплекс Прервать ожидание соединения после получения 50 звонковых строк Будем отвечать после 1-го RING (как по умолчанию) Макс, интервалы (сек.) между двумя RING ; Интервал между звонками, max и min (сек) ; Интервал между звонками в терминале (сек) ; максимальная длительность входящей сессии в минутах ; максимальная длительность исходящей сессии в минутах |
Рис. 7.39. Отрывок файла конфигурации Brake!, ctl с описанием конфигурации
модемной подсистемы для почтовой программы The Brake! (часть вторая)
Под файлом-семафором понимается файл, само создание которого с заданным
именем в нужном директории представляет собой сигнал для других программ.
Содержимое такого файла также иногда имеет значение, однако в большинстве
случаев он может быть пустым.
Если вы хотите хотя бы в самой малой степени автоматизировать работу вашей
Fido-системы, к примеру добиться автоматической обработки эхо-почты при ее
приеме, то вам совершенно необходимо правильно настроить передачу нужных
сигналов.
FrontDoor. Эта почтовая программа создает большое количество флажковых
файлов-семафоров. Какое-либо их конфигурирование, за исключением местопо-
ложения, отсутствует. Единственный семафор, имя которого вы сами можете опре-
делить в программе fdsetup.exe (Global => FileNames => MailExit) - это сигналь-
ный файл, создаваемый по приему почты. Вот несколько основных стандартных
семафоров FrontDoor:
□ fdinsess.nnn - FrontDoor находится в состоянии почтовой сессии с другой
системой (ппп - номер линии);
□ fdfreeze.nnn - приказание «заморозить» линию nnn. FrontDoor ищет этот файл
и, если обнаруживает его, останавливает работу соответствующей линии;
□ fdfreeze.all - действует аналогично описанному выше, но останавливает сразу
все линии;
□ fdfrozen.nnn - сообщает, что работа линии ппп остановлена;
□ fdcanses.nnn - наличие этого семафора заставляет FrontDoor прервать почто-
вую сессию, после чего семафор удаляется;
□ fdrenum.nnn - сообщает FrontDoor, что письма в нетмейл-директории были
перенумерованы (или как-то иначе изменены);
□ fdscan.nnn - сообщает, что FrontDoor обрабатывает нетмейл-директорий;
□ fdinexit.nnn - FrontDoor выгружена, поскольку из нее была запущена вне-
шняя программа (например, BBS);
□ fdnoexit.now - запрещает запуск внешних программ из FrontDoor;
□ fdnoscan.now - запрещает сканирование нетмейл-директория;
□ fdrescan.now - заставляет FrontDoor пересканировать нетмейл-директорий;
□ fdxitnnn.nnn - заставляет FrontDoor прервать работу и выйти с ErrorLevel,
равным ппп.
T-Mail. В T-Mail флаги и семафоры определяются в конфигурационном файле
T-Mail.ctl. В отличие от FrontDoor, T-Mail может создавать не только файлы-фла-
ги, но и системные семафоры (при запуске версий для Windows NT и OS/2). Фла-
ги, появлении или исчезновении которых выполняется какое-либо действие, на-
зываются в T-Mail process flags, и алгоритм их использования и создания более
сложен и совершенен, чем в описанном выше случае FrontDoor. С использовани-
ем флагов можно радикально менять поведение T-Mail, заменять значения кон-
фигурационных параметров и т.п.
Приведенное ниже описание Process_Flags позаимствовано из документации
к T-Mail (в сокращении). Здесь определены переменные Process—Flag, то есть
имена флагов и соответствующие программы или действия, которые T-Mail выпол-
нит при появлении, исчезновении или изменении соответствующего флага. Для их
использования в T-MAIL. CTL нужно описать переменную Process_Flag:
Process—Flag [префикс] <имя_флага> <действие1>
[# <действие2>]
[# <действиеЗ>]
[. . .]
Параметры здесь имеют следующий смысл:
□ <имя_флага> - имя флага, на который надо реагировать. Если не опреде-
лен полный путь, то флаг ищется в каталоге для флагов (значение перемен-
ной Flag_Dir). Если имя флага начинается со строки \SEM32\, то в вер-
сиях для OS/2 и Windows NT это означает не файл-флаг, а системный
семафор в памяти;
□ [префикс] - перед именем флага может быть указан один из символов ! или
+. Если перед именем флага никакого префикса нет, то действие (или несколь-
ко действий) будет выполнено при появлении этого флага. Непосредственно
перед выполнением <действие> флаг, заданный как <имя_флага>, будет
удален. Исключением является действие Sleep. В этом случае T-Mail ожида-
ет создания флага <имя_Д>лага>. Если перед именем флага стоит префикс +,
то флаг после обработки не будет удален. Эту возможность можно использо-
вать только для файлов-флагов (нельзя для системных семафоров) и только
для неинверсных флагов (то есть нельзя задавать префиксы + и ! для одного
и того же флага). T-Mail реагирует на такой неудаляемый флаг один раз, за-
поминая дату и время его создания. После этого T-Mail отреагирует на этот
флаг только тогда, когда изменятся дата или время его создания либо после
выполнения действия Control;
□ <действие> - одно из следующих действий, которое будет выполнено:
- <KeyWord> - одно из ключевых слов, определяющих действие по флагу.
Кроме того, в переменной Process_Flag можно использовать действие
Sleep - ожидание исчезновения флага (или появления, если флаг задан
с префиксом «!»). В этом состоянии T-Mail не выполняет исходящие вызо-
вы и не отвечает на входящие, однако обрабатывает флаги, события, пакует
почту и реагирует на нажатия клавиш;
- < [! ] command> - это имя программы, командного файла или команды опе-
рационной системы, которую нужно запустить, и ее параметры;
- <dvpname> - при работе с DeskView здесь можно задать имя DeskView-
программы, то есть имя dvp-файла, определяющее окно, которое нужно от-
крыть.
При задании значения <действие> в Process_Flag можно использовать мак-
росы, которые будут заменены на соответствующие параметры:
□ *А - полный адрес системы, которая является текущей в очереди. Если оче-
редь пуста, подставляется адрес
□ *D - файловый ящик «по умолчанию» для системы, которая является теку-
щей в очереди;
□ *Х - полное имя файла *.?1о или *.?ut в Bink-Style outbound (без расширения)
для системы, которая является текущей в очереди, например для 5049/12
-C:\FIDO\OUTBOUND\OUTBOUND\13b9000c;
□ *1 - PID (идентификатор процесса) текущей задачи;
□ *В - скорость соединения (DCE baudrate);
□ *L - скорость фиксации порта (locked port), или 0;
□ *Р - номер СОМ-порта;
□ *Т - номер задачи (task ident);
□ *О (только для OS/2 и NT-версии) - handle открытого СОМ-порта;
□ *М - текущее системное время компьютера (в формате ЧЧ:ММ);
□ *С - текущая системная дата компьютера (в формате ДД/ММ/ГГ).
Примеры:
Process_Flag anyarc.t-m c:\fido\faste\fastech2 toss
Process_Flag c:\anytic.000 anytic.bat -Debug
Process—Flag doswap.t-m doswap.bat
Process_Flag sleep.t-m Sleep ;(перейти в режим "Sleep")
Process—Flag exit.t-m Exit 99 ; (выйти из программы
; c Error Level 99)
Process—Flag repack.t-m Repack /(перепаковать нетмейл)
Process—Flag alive.t-m Kill flags\alive.t-m /(удалить файл)
Process—Flag !alivel.t-m Nothing /(используется для создания
/ флаг-файла)
Process—Flag keyl.t-m KeyMacro <Alt-D>c:\command.com<ret>/
124<ret>
Process_Flag poll.t-m Poll /2 /100 /6 /(создание поллов)
Process—Flag \SEM32\setl Set Freq—Size=1000 /(задание парамет-
ра)
Process—Flag test.t-m test.bat *A *P *B -debug
Process—Flag ex.t-m Exit 99 bbs.exe -d -p*P -b*B -y*N
Process—Flag arcmail.t-m echotoss.bat /(флаг для тоссера)
Может быть определено несколько действий, соответствующих одному флагу
При этом каждое следующее действие должно начинаться с новой строки и пред-
варяться символом «#». Такие действия будут выполняться последовательно. Не
поддерживается выполнение нескольких действий только для Process—Flag ...
Sleep. Действия Control и Exit должны быть последними. Если после Control или
Exit заданы еще какие-либо действия, то такие действия выполнены не будут.
Пример:
Process—Flag flag.t-m Create myflag.t-m
# Sound sndl.wav
# doproc.cmd -T -D
# Sound end.wav
# Kill myflag.t-m
Process—Flag Control.%TASKNO% Control
Максимальное число переменных Process—Flag неограничено. Ниже следует
пример в виде части конфигурационного файла, определяющий основные свойства
подсистемы управления флагами и семафорами (до секции Process—Flag, рис. 7.40).
The Brake!. У The Brake! механизм флагов и семафоров не так изощрен, как
у T-Mail, но The Brake! имеет в своем составе подсистему интерпретатора REXX,
основанную на интерпретаторе REXX операционной систмы OS/2. REXX-подсис-
тема The Brake! удачно дополняет сигнальную систему флагов, позволяя выполнять
почти любые действия, не выходя из The Brake!, и расширять возможности програм-
мы, не изменяя ее кода. Ниже следует отрывок Brake!.ctl, дающий общее представ-
ление о средствах межпрограммной коммуникации The Brake! (см. рис. 7.41).
Дополнительная пост-обработка личной почты
Принятая почта должна быть распакована и помещена в нетмейл-директорий для
последующего чтения; но может и подвергнуться дополнительной обработке, цели
которой могут быть самыми разнообразными:
е.ехе - t-mail.ctl □ □
File Edit Options Help
; Секция определения флагов (семафоров) и функций работы с ними i
Flag_Dir c:\t-mail\flags\ ; Каталог для файлов-флагов
; По умолчанию - корневой каталог T-Mail.
; Нельзя указывать корневой каталог диска.
Flag_Session busy^TASKNO^.t-m ; Флаг "занято". Создается в начале
; сессии и удаляется после окончания.
; Вместо %TASKNO% подставляется номер линии. ;
; Flag_NoScan nosean.t-m ; обычное использование (при появлении)
; Flag_NoScan J scan.t-m ; инверсное использование (при исчезновении)
; Flag_NoScan nosca*.t-m ; с использованием метасимволов s
этот флаг запрещает сканирование нетмэйла, mailboxes, fileboxes. В i
; качестве флага можно использовать маску файлов (wildcard) . i
Busy_Flags_Create Normal Semaphore Bink ; Создание busy-флагов i <
; В этой переменной указывается, какие флаги занятости (busy-флаги) будет ь \
\; создавать T-Mail при установлении сеанса связи, а также будет ли он i.j
; создавать их вообще. Значения совпадают со значениями переменной I
; Busy_Flags_Scan (см. ниже). Значение по умолчанию - No, то есть флаги г I
; занятости не создаются. В многозадачных и многолинейных системах б]
; использование этой переменной обязательно. ч
Busy_Flags_Scan Normal Semaphore Bink ; Сканирование busy-флагов ! j
; В этой переменной указывается, какие флаги занятости (busy-флаги) будет ы
; анализировать T-Mail перед попыткой установления сеанса связи и при i
; формировании/модификации очереди, а также будет ли он анализировать их hi
; вообще. В многозадачных и многолинейных системах использование этой м
; переменной обязательно.
; Возможные значения (ключевые слова): j i
; Normal - обычные флаги, совместимые с мэйлером FrontDoor; i \
; Bink - флаги, совместимые с мэйлером BinkleyTerm (файлы *.BSY);
; Semaphore - системные семафоры (для OS/2 и Windows NT);
; No - флаги создаваться и анализироваться не будут.
; Можно задавать несколько ключевых слов вместе (через пробел), однако г
; слово No должно быть задано единственным. Значение по умолчанию - No, L
; то есть флаги занятости не анализируются. U
Рис. 7.40. Отрывок файла T-Mail.ctl, определяющий основные свойства
подсистемы управления флагами и семафорами почтовой программы T-Mail
□ сортировка принятой почты и распределение ее по разным нетмейл-папкам
в зависимости от тех или иных параметров;
□ автоматическая диагностика, обработка и возврат запрещенной к передаче
почты;
□ выявление «зацикленной» почты;
□ автоматическая обработка писем, адресованных программам-роботам;
□ ведение файла-журнала транзитной почты, а также многие другие операции.
В настоящем разделе дано общее описание совершаемых при пост-обработке
личной почты действий и используемых при этом программ.
Распаковка нетмейла
После приема личная почта хранится в файлах *.pkt, формат которых был рас-
смотрен в главе 4. Следующей операцией является распаковка принятых пакетов.
АМА-мейлеры могут выполнять ее самостоятельно, а в случае BSO распаковкой
занимается либо отдельная программа-распаковщик, либо универсальный обра-
ботчик личной почты - нешмейл-трекер (netmail tracker), либо тоссер. Распаковка
Рис. 7.41. Описание подсистемы управления флагами и семафорами
в конфигурационном файле Brake!.ctl почтовой программы The Brake!
пакетов - это преобразование писем из формата *.pkt в формат *.msg и помещение
полученных файлов в каталог личной почты. Операция эта несложная, однако очень
ответственная и необходимо уделить ей самое пристальное внимание.
Здесь мы рассмотрим несколько возможных вариантов выполнения этой опе-
рации:
□ распаковка АМА-мейлером. Если в вашем распоряжении находится Front-
Door, T-Mail или любой другой АМА-мейлер, проблему распаковки прихо-
дящих пакетов можно считать решенной. По умолчанию такие почтовые про-
граммы всегда распаковывают нетмейл. Однако если вы хотите использовать
внешний распаковщик, то нужно явно указать мейлеру, что распаковывать
нетмейл нет нужды. Для FrontDoor это делается ключом командной строки
nounpack при запуске программы, для T-Mail нужно указать в конфигураци-
онном файле:
Unpack No ; Не распаковывать файлы *.РКТ
□ распаковка обработчиком нетмейла. Все обработчики нетмейла, такие как
Itrack, Itrax, NetMgr, FTrack и др., могут распаковывать принятые *.pkt- файлы.
Для этого нужно их соответствующим образом настроить и запускать пос-
ле приема почты (например, после появления соответствующих файлов-
флагов);
□ распаковка с использованием тоссера. Тоссер по умолчанию также настро-
ен на распаковку встретившихся *.pkt-файлов. Поэтому если вы не хотите до-
верять ему эту операцию, то перед запуском тоссера необходимо либо спря-
тать от него принятые *.pkt-файлы, либо распаковать их какой-либо другой
программой.
Обработка почты с использованием нетмейл-трекеров
Есть два различных подхода к написанию программ обработки нетмейла. Пер-
вый - «традиционный» - нашел свое выражение в таких известных программах,
KaKNetMgr, O/T-Track, MN-Track или FTrack. Заключается он в выполнении про-
граммой-обработчиком (нетмейл-трекером) ограниченного набора процедур об-
работки, который пользователь программы включает (или не включает) в пакет
обработки посредством соответствующего конфигурирования программы.
Второй подход представлен программами Itrack и Itrax (REXX-клон Itrack).
Itrack предоставляет пользователю набор элементарных директив, из которых
посредством составления специальной программы собирается рабочая конфигу-
рация трекера. Фактически Itrack представляет собой язык программирования,
специализированный язык-интерпретатор.
Далее в разделе «Основные функции нетмейл-обработчика» представлен об-
зор «обычных» трекеров и функций, выполняемых с их помощью, а затем, в раз-
деле «Itrack», дано общее представление о способах использования языка Itrack.
Конфигурирование нетмейл-обработчика
Нетмейл трекер (Netmail-tracker) - это программа, которая сканирует одну или
несколько указанных нетмейл-баз (это может быть база стандарта MSG - см. гла-
ву 4, а также и базы других форматов - см. главу 8). Под сканированием пони-
мается последовательное чтение и анализ заголовков писем. Сканируются, как
правило, только нетмейл-письма. Запуск трекера на эхо-почте может дать непред-
сказуемые результаты.
Трекер проверяет заголовки сообщений на соответствие заранее определенным
критериям, и, если обнаруживается совпадение, над этим сообщением может быть
выполнено то или иное действие (оно может быть удалено, скопировано, переад-
ресовано и т.д.).
Дальнейшее изложение по необходимости должно быть конкретным. Нужно
дать определение способам анализа заголовков писем (адресным маскам) и спо-
собам обработки. Однако следует учесть, что единого стандарта записи правил
фильтрации писем и их обработки не существует, в записи таких правил у раз-
личных трекеров много общего, но есть различия в частностях. Поэтому выберем
один из наиболее популярных трекеров NetMgr. Для того, кто имеет опыт конфи-
гурирования этой программы, не составит труда сконфигурировать и любой дру-
гой трекер (возможно, кроме Itrack).
Итак, рассмотрим базовые элементы конфигурации трекера.
Маска адреса (Mask). Для обработки нетмейл-сообщений нужно создать пра-
вила, по которым трекер будет выбирать интересующие нас письма из общего
потока почты. Эти правила называют записью адресной маски (символьная за-
пись, имеющая смысл некоторого множества адресов). Обычно маска состоит из
шести частей-критериев, соответствующих полям заголовка письма:
□ FROMNAME - имя сисопа, пославшего письмо;
□ FROMADDRESS - адрес, с которого было послано данное письмо;
□ TONAME - имя, на которое письмо адресовано;
□ TOADDRESS - адрес назначения письма;
□ SUBJECT - тема письма;
□ ATTRIBUTES - атрибуты письма.
Для NetMgr эти шесть полей записываются последовательно, через запятую,
в конфигурационном файле, образуя вместе адресную маску, причем для обо-
значения понятия «любой» используется по традиции символ *, например:
Mask *, ★, ★, 2:*/*.*, ★, * ; (все письма, адресованные во 2-ю зону)
Mask *, *, *, ★, ★, +г ; (все полученные (received) письма)
Другие используемые специальные символы:
□ ~ (тильда) - перед символьной строкой означает приказание искать включе-
ние следующей за ней символьной строки в данный элемент заголовка пись-
ма, например, Mask -bashvili, 2:5049/12.0, *, *, *, * означает
любые письма с адреса 2:5049/12.0, у которых в поле имени сисопа встреча-
ется символьная строка bashvili;
□ ! (восклицательный знак) означает отрицание. Например, рассмотрим маску
следующего вида: Mask ’-bashvili, ’2:5049/12.0, *, *, *, *. Это
означает любые письма, не происходящие с адреса 2:5049/12.0, у которых
в поле имени сисопа не встречается символьная строка bashvili.
Дополнительных пояснений требует поле ATTRIBUTES, которое (для NetMgr)
может принимать значения в соответствии с табл. 7.6.
Кроме приведенных в табл. 7.6, есть еще два специальных атрибута, определя-
ющих режим использования нодлиста:
□ @ - проверять адрес назначения по нодлисту;
□ # - проверять адрес происхождения письма.
Каждый атрибут может предваряться символом + (плюс) или - (минус); первый
означает «должен присутствовать», второй - «этого атрибута не должно быть»; на-
пример, + 1+р означает, что письмо должно иметь атрибуты LOCAL и PRIVATE.
Остальные атрибуты при этом неважны. Если же установить +c + l+p-s, то это
будет иметь смысл «письмо с атрибутами CRASH, LOCAL, PRIVATE, но без ат-
рибута SENT» (то есть пока не послано).
Таблица 7.6. Обозначения поля Attribute в программе NetMgr
Запись поля Attribute Общепринятое обозначение атрибута Комментарии
Р Priv (Private) Приватное письмо
с Crash Отправить в режиме «Crash»
г Rev (Received) Письмо получено
S Snt (Sent) Письмо послано
а Att (FileAttached) К письму прикреплен файл
i Itr (InTransit) Транзитное письмо
о Orp (Orphan) Отсутствует адрес назначения
к Kill Письмо должно быть удалено
1 Lac (Local) Письмо происходит с данной системы
h Hid (Hold) Отправить в режиме «Hold»
f Frq (File Request) Письмо содержит запрос файла
n Scanned Письмо уже было обработано
d Dir (Direct) Отправить в режиме «Direct»
и UReq (UpdateRequest) Запрос файла типа «Update»
q RRQ (ReturnReceiptRequest) Запрос извещения о прохождении письма
У RPT (ReturnReceipt) Запрос извещение о получении
m Imm (Immediate) Отправить в режиме «Immediate»
t TFS (TruncateFileSent) Послать файл в режиме «Truncate»
e KFS (KillFile/Sent) Удалить файл после отсылки
z Arc (ArchiveSent) Послать как arcmail
b Recpt (IsReturnReceipt) Извещение о получении
g CFM (Confirmation ReceiptRequest) Запрос подтверждения о прочтении
$ Locked Сообщение заблокировано
Ниже следуют еще несколько примеров адресных масок:
□ Mask Amir Shabashvili, *, *, *, *, + s
означает любые письма от Amir Shabashvili, с любого адреса, кому угодно и на
какой угодно адрес, с любой темой, уже отмеченные как посланные (то есть
упакованные для отсылки или отосланные);
□ Mask *, 2:5049/12.*, UUCP, 2:50/128.0, *, +l-h-p-k
означает сообщения от кого угодно (любое имя: *), от узла 2:5049/12 и его
пойнтов, написанные на имя типа по имени UUCP (так адресуются письма
на шлюз Fido-Internet), с адресом 2:50/128 (это как раз адрес регионального
шлюза с Internet), с установленным атрибутом LOCAL и отсутствующими
HOLD, PRIVATE, KILL. Тема письма не имеет значения;
□ Mask *, 2:5049/12.*, Postmaster, 2:5049/12.0, *, *
означает сообщения от кого угодно (любое имя: *), от узла 2:5049/12 и его
пойнтов, написанные на имя Postmaster и на адрес 2:5049/12.0. Тема и атрибуты
письма не имеют значения;
□Mask *, *, AllFix, 2:5049/12.0, *, *
означает любые письма, адресованные AllFix на адрес 2:5049/12.0;
□Mask *, *, -bashvili, 2:5049/12.0, -сисопка, *
означает любые письма, адресованные человеку с сочетанием bashvili в имени
или фамилии, на адрес 2:5049/12.0, и со словом «сисопка» в строке темы письма;
□Mask *, 12:5049/12.0, *, *, *,-@-1
означает любые письма, не происходящие с узла 2:5049/12, имеющие адрес
назначения, отсутствующий в текущем нодлисте и не имеющие установленного
атрибута LOCAL;
□ Mask *, *, *, *, *, -#
означает любые письма от систем, отсутствующих в нодлисте.
Действие (Action). Само по себе выделение тех или иных писем с использова-
нием маски адреса не имеет смысла; использование маски всегда сопровождается
действием (Action). Подробно обо всех директивах Action сообщается в описа-
нии программ-трекеров. Далее приведены краткие сведения о некоторых основ-
ных директивах, используемых при автоматической обработке почты в програм-
ме NetMgr. При этом под параметром <область назначения> понимается либо
нетмейл-директорий формата MSG, либо нетмейл-область одного из популяр-
ных FTN-форматов баз данных (Squish/JAM/Hudson). Для обозначения формата
базы используется модификатор перед описанием директория или файла базы
данных. Отсутствие модификатора означает обычный MSG-формат, ! означает
JAM, $ - SQUISH, # - HUDSON. Далее следует описание основных директив-
действий:
COPY <областъ назначения>
Копирует письмо в другую нетмейл-область.
Пример:
Action Сору C:\FIDO\MAIL\sysop
MOVE <область назначения>
Перемещает письмо в другую нетмейл-область.
Пример:
Action Сору C:\FIDO\MAIL\sysop
DELETE
Удаляет письмо. Не имеет параметров.
DELETEATTACH
Эта директива удаляет письмо и прикрепленный к нему файл, если таковой най-
дется. При этом удаление файла осуществляется только в том случае, если уста-
новлены атрибуты KillFilesent или TruncateFileSent.
FILE <имя файла>
Записывает письмо в текстовый файл.
Пример:
Action FILE C:\FIDO\LOGS\msgtext.log
HDRFILE <имя файла>
Записывает заголовок письма в текстовый файл.
SEMAPHORE <путь к файлу+имя файла>
Создает или меняет дату и время файла-семафора.
REWRITE <маска адреса>
Переписывает заголовок письма в соответствии с параметром <маска адреса>
(меняет только указанные в маске поля). Это очень мощная и часто используемая
команда.
Пример:
Action Rewrite *, *, Amir Shabasvili, *, *, *
В этом примере письмо меняет имя адресата на «Amir Shabashvili». Остальные
элементы заголовка письма остаются без изменения.
BOUNCE <адрес> <тпекстовый файл>
Возвратить письмо отправителю, подставив адрес отправителя в соответствии
с параметром <адрес> и добавив в начало письма текст из параметра «^тексто-
вый файл>. В файле можно использовать большое количество макропеременных,
позволяющих вводить в текст ссылки на адрес возвращаемого письма, имя сисопа
и т.п. Есть также команды EPTYBOUNCE и HRDBOUNCE, позволяющие воз-
вратить только содержимое текстового файла или только заголовок письма, соот-
ветственно.
ADDNOTE <имя файла>
Эта команда добавляет содержимое <имя файла> в начало письма.
FOR WARD <mask>
Эта директива переправляет письмо кому-либо еще. Заголовок письма будет скон-
струирован с использованием <mask>.
MAKEMSG <имя файла> <mask>
Создает сообщение с текстом из файла, заданного параметром <имя файла>, за-
головок конструируется по маске <mask>, например:
Action MakeMsg c:\warning.txt Amirko, 2:5049/12.0, SysOp,
2:5049/12.34
Здесь создается письмо от Amirko, 2:5049/12, на имя Sysop, адрес 2:5049/12.34,
с текстом из указанного файла.
Кроме описанных, возможны также команды:
□ BOUNCEIN;
□ HDRBOUNCEIN;
□ EMPTYBOUNCEIN;
□ XBOUNCEIN;
□ XHDRBOUNCEIN;
□ XEMPTYBOUNCEIN;
□ FORWARDIN;
□ MAKEMSGIN.
Все эти команды аналогичны описанным выше действиям, но вместо посылки
письма по сети они просто перемещают его в другую нетмейл-область.
CHANGEPATH <новый путь к файлам>
Заменяет путь к файлам, указанный в поле темы письма (если таковой найдется),
на <новый путь к файлам>.
CHANGEPATHMOVE <новый путь к файлам>
Действует аналогично описанной выше команде, но кроме замены строки переме-
щает также и указанные файлы в новый директорий.
ECHOCOPY <адрес> <область> <Seen-By>
Копирует нетмейл-сообщение в указанную эхо-область. Добавляет техническую
информацию в Seen-By строку эхо-письма.
Пример:
Action EchoCopy 2:5049/12.0 !d:\fido\msgbase\kazang 5049/12 0
PACKMAIL <адрес происхождения> <адрес назначения> [<пароль>]
Упаковывает письмо в BSO-директорий (в файл *.?ut).
RUNEXTERNAL <название программы> <параметры>
Позволяет запустить внешнюю программу, передав ей через <параметры>
любую информацию об обрабатываемом письме (подробности см. в описании
NetMgr).
Построение конфигурации нетмейл-трекера NetMgr
Общая логика конфигурирования NetMgr сводится к выделению нужных писем
из общего потока нетмейла в соответствии с критериями, задаваемыми указанием
соответствующих масок, и определению действий, которые необходимо выпол-
нить с выделенными письмами. Каждая маска обязательно должна сопровождать-
ся каким-либо действием. Пример использования директив в файле конфигура-
ции приведен на рис. 7.42. Показанная на рисунке последовательность действий
состоит из следующих пунктов:
1. Выделение почты, адресованной на имя VaskaPu, адрес 2:5049/1.0.
2. Отсылка ее отправителю с добавлением в начало письма файла С: \FIDO\
LOGS\MSGS\vaska.log.
е.ехе - netmgr.cfg 01
Mask *, *, Vaska Pu, *, *, *
Action Delete
; Удалить все письма от Сисопа с именем Vaska Pu
Mask *, *, *, 7:*/*.*, *, *
Action Move Jd:\fido\msgbase\z7mail
; Переместить все письма для седьмой зоны в указанную облать (модификатор "" в данном
; случае определяет формат базы данных, к которой относится указанная область (JAM)).
Mask *, *, *, *, *, +r
Mask Move $c:\fido\msgbase\received
; Переместить все принятые письма в указанную Squish-область (" $" это признак базы Squish)
Mask *, 2:5049/12.0, *, *, *, +f
Action Packmail 2:5049/12 *
; Эта директива выделяет все письма от 2:5049/12, содержащие запросы файлов, и создает на
; основе них правильные файлы запросов в BSO-директории.
Mask *, 2:5049/12.0, *, 3:*/*.*, *, +1
Action Packmail 2:5049/12.0 3:774/605.0
; Отправлять все письма для третьей зоны через узел с адресом 3:774/605.
Mask *, 2:5049/12.99, *, ♦, *, +1-c-h-d-a-f-u
Action Packmail 2:5049/12.99 2:5049/12.0
; Взять все письма, идущие от 2:5049/12.99, которые имею атрибут Local, и не имеют
; атрибутов Crash, Direct, FileAttach, FileRequest или FileUpdateRequest, - иными
; словами, все "нормальные" письма, и упаковать их на 2:5049/12.0
; Возможно также совершить несколько действий с использованием одной маски:
Mask *, *, Vaska Pu, 2:5049/1.0, ♦, *
Action Bounce 2:5049/12.0, c:\fido\txt\newaddr.txt
Action File c:\fido\logs\msgs\vaska.log
Action Forward Amirko, 2:5049/12.0, Vaska Pu, 2:5049/12.13, Readdressed mail, +1
Action Delete
Рис. 7.42. Использование директив обработки в конфигурационном файле
программы NetMgr
3. Сохранение письма в файле.
4. Пересылка его на новый адрес для Vaska Pu, 2:5049/12.13.
5. Удаление письма.
Построенная описанным выше способом конфигурация NetMgr представляет
собой что-то вроде программы или пакетной процедуры обработки почты. Для каж-
дого письма в указанной нетмейл-области NetMgr проверяет все возможные адрес-
ные маски и, как только находит подходящую, выполняет все действия, ассоцииро-
ванные с данной маской. После того как работа выполнена, другие маски уже не
используются, и NetMgr переходит к следующему письму. Поэтому если у вас опре-
делены две маски, которым удовлетворяет данное письмо, то только первая из них
будет использована и действия, ассоциированные с ней, будут выполнены.
Itrack u Itrax
Itrack (автор Франк Прейд, Германия) и его REXX-клон Itrax (автор Игорь
Швырков, Москва) представляют собой специализированные языки-интерпрета-
торы, служащие для обработки личной почты. Itrack славится трудностью на-
стройки и зубодробительным синтаксисом, на самом же деле его директивы не
сложнее рассмотренных выше директив NetMgr, просто в описании Itrack и в при-
мерах программ использована характерная для немецкого языка запись составных
слов без выделения начальных букв, например DELTRUNCATTACH или LENG-
THADDRESS. Структура программы Itrack больше похожа на программу, чем
конфигурационный файл NetMgr, и если у вас есть самый минимальный опыт
программирования, то вам будет несложно модифицировать имеющиеся в постав-
ке примеры программ под свои нужды.
Программа на языке Itrack состоит из определения файлов конфигурации
и протокольных файлов (файл itrack.cfg), данных (обычно помещаются в файл
data.cfg), файлов, содержащих процедуры обработки (у автора книги это mailpack.cfg,
managers.cfg, tracking.cfg, zone7.cfg, req_mgr.cfg, other.cfg), и основной программы,
чаще всего помещаемой в файл с названием scan.cfg или подобным.
Среди элементов языка Itrack есть определение многих типов данных, например,
DATA NODELIST <имя блока> определяет набор нодлистов, a DATA ADDRESS
<имя блока> - список адресов. Вот как может быть записан блок DATA ADDRESS:
DATA ADDRESS MyPoints
2:5049/12.1
2:5049/12.12
2:5049/12.13
2:5049/12.14
2:5049/12.16
2:5049/12.17
2:5049/12.18
2:5049/12.34
2:5049/12.36
#END# DATA
Кроме данных, есть ключевые слова общего назначения, конфигурирующие
систему в целом или выполняющие какие-либо действия, не имеющие прямого
отношения к обработке личной почты, команды описания нетмейл- и эхо-облас-
тей и функции для обработки писем по типам:
□ функции для работы с областями сообщений;
□ функции для работы с файлами;
□ функции для выбора сообщений по заданному критерию;
□ функции для манипуляции сообщениями;
□ функции для работы с архивами и пр.
Кроме того, программы Itrack могут использовать так называемые (Temp-
late шаблоны) - заготовки писем, в которых можно использовать большое коли-
чество зарезервированных макропеременных.
Вот как выглядит фрагмент программы на языке Itrack:
Block Loop_Msgs
Select ©Attribute Loop
CopyGroup ©Addressname 2:5049/12 Amir Shabashvili
SetAttribute ©Attribute
#End# CopyGroup
AddHeader LoopDest
SetAttribute ©Attribute DIR HOLD
#End# Select
#End# Block
Общее количество ключевых слов языка выше ста. Если вы решитесь исполь-
зовать Itrack, то к вашим услугам будет пространное описание, поставляемое вме-
сте с программой.
Координация доставки личной почты
Вопросы доставки личной почты, стандартной схемы маршрутизации (зональный
шлюз => региональный шлюз => хост => хаб), отраженной в структуре нодлиста,
уже обсуждались конспективно в главе 1 и подробно в главе 2. Здесь же мы ак-
центируем внимание на структуре координирования при доставке личной почты.
Согласно Полиси и общепринятой в FidoNet практике, ответственность за до-
ставку личной почты лежит:
□ на узлах, выдавших адреса пойнтам. При этом правила FidoNet никак не рег-
ламентируют такую доставку, она целиком основана на личной договореннос-
ти между узлом-боссом и его пойнтом. Босс-узел несет всю полноту ответ-
ственности за переписку своих пойнтов, с точки зрения правил FidoNet все
письма от пойнтов рассматриваются в конфликтных ситуациях как письма
от их босс-узлов;
□ на нетмейл-хабах: если в сети есть структура нетмейл-хабов, то почта для под-
хабников передается на соответствующие хабы и ответственность по достав-
ке личной почты перекладывается с сетевого координатора на них;
□ на сетевых координаторах: в обязанность NC входит организация работы се-
тевого хоста (системы с адресом /0). Принятая извне почта должна быть до-
ступной для получения адресатами внутри сети;
□ на региональном координаторе, который предоставляет возможность незави-
симым узлам обмениваться почтой с его системой - маршрутизация почты
на независимые узлы по умолчанию проходит через систему регионального
координатора;
□ на зональном координаторе, который предоставляет возможность региональ-
ным координаторам обмениваться почтой с его системой.
Этими немногими правилами, из которых простого участника сети прямо каса-
ются только первые три, исчерпывается поле ответственности по доставке лич-
ной почты. Еще раз напомним, что строго регламентирован только прием нетмей-
ла, отправка же его с использованием обычно хорошо работающей структуры
маршрутизации исходящей почты представляет собой добровольно поддержива-
емый сервис, который обязательным не является и которого, вообще говоря, мо-
жет и не быть.
В случае отсутствия системы маршрутизации исходящего нетмейла отправка
должна производиться директом на узел-получатель или на его хаб/хост. Исходя
из этих предпосылок и нужно подходить к анализу любых затруднений при до-
ставке личной почты с использованием FidoNet.
Возможные трудности в доставке почты FidoNet
и их устранение
Для анализа «плохой» почты и поиска потерянной понадобится знание несколь-
ких служебных строк, которые помещаются в письмо при его создании и пересыл-
ке программами-обработчиками, - это так называемые кладж-строки, начинаю-
щиеся с кода Olh (ла) (см., например, главу 4, раздел «Текст письма и служебные
строки»).
При анализе личной почты наиболее полезны и часто применяемы следующие
кладжи:
□ ^aMSGID. Кладж MSGID - это уникальный идентификатор сообщения, по
которому его можно отличить от любого другого; совпадающий MSGID сви-
детельствует о получении дублированной почты. Кроме того, в MSGID поме-
щается также и адрес системы, на которой письмо было создано;
□ AaVIA. Служебные строки VIA вставляются в тело письма различными про-
граммами при его упаковке или обработке, наличие этой строки помогает
определить маршрут следования письма с определением точного времени
прохождения каждого этапа;
□ ORIGIN. Строго говоря, Origin - это не кладж и вообще не служебная стро-
ка; обязательным Origin является только для эхо-письма. Но если в письме
есть Origin, то в него обязательно помещается адрес системы, отправившей
письмо.
Ни один из упомянутых кладжей не является обязательным, но их отсутствие
является редчайшим исключением и свидетельствует о необычности, «неправиль-
ности» письма.
Для просмотра кладжей используются редакторы сообщений; обычно по умол-
чанию кладжи не отображаются, но абсолютное большинство редакторов имеют
режимы для отображения всей служебной информации письма. К примеру, в ре-
дакторе GoldEditor такой режим включается нажатием клавиши К или Alt+K из
режима просмотра писем в нетмейл-области; в редакторе FleetStreet нужно на-
брать Ctrl+K или выбрать соответствующий пункт меню либо иконку, при этом,
в отличие от GoldEditor, кладжи не появляются в тексте письма, а отображаются
в отдельном окне.
В завершение рассмотрим основные разновидности «плохой» почты и стандарт-
ные методы ее выявления и обработки. Всего можно выделить четыре основных
разновидности такой почты:
□ петли (loops);
□ дубли (dupes);
□ дефектные письма (badmail);
□ нетмейл-бомбы (netmail-bombs).
Loops (петли)
Петли представляют собой одну из наиболее часто встречающихся проблем
FidoNet. Происхождение их обязано ошибкам в системе маршрутизации почты.
Наиболее просто разобраться с «короткими» петлями, возникающими между дву-
мя узлами, связанными регулярным обменом почтой. «Длинные» петли анализи-
ровать и распутывать сложнее. Основным источником информации при анализе
петель являются кладжи AaVIA. Ниже показаны кладжи реального письма, путе-
шествующего по замкнутому кругу, - это случай «короткой» петли:
~aMSGID: 2:5049/12@FidoNet 2772393D
~aPID: ITR1.3/G6
~aCHRS: IBMPC 2
~aVia 2:5049/19.38@fidonet @19990907.124234.UTC+4 T-Mail 2606.NT
~aVia 2:5049/19@fidonet @19990907.084309.UTC O/T-Track [unreg] 2.70a
"aVia 2:5049/19@fidonet @19990907.124314.UTC+4 T-Mail 2606.NT/TCP/IP
"aVia 2:5049/36@fidonet @19990907.084632.43.UTC Itrack+ 2.0 DB876437
"aVia 2:5049/12@FidoNet @19990907.131234.54.UTC Itrack- 1.3/G6
"aVia 2:5049/36@fidonet @19990907.091607.72.UTC Itrack+ 2.0 DB876437
~aVia 2:5049/12@FidoNet @19990907.132104.98.UTC Itrack- 1.3/G6
"aVia 2:5049/36@fidonet @19990907.092553.34.UTC Itrack+ 2.0 DB876437
"aVia 2:5049/12@FidoNet @19990907.135018.55.UTC Itrack- 1.3/G6
~aVia 2:5049/36@fidonet @19990907.095724.55.UTC Itrack+ 2.0 DB876437
"aVia 2:5049/12@FidoNet @19990907.141749.42.UTC Itrack- 1.3/G6
Из приведенного отрывка следует, что письмо, отправленное с адреса 2:5049/19.38
на адрес 2:5049/99, попало в петлю на линке между 2:5049/12 и 2:5049/36, об этом
свидетельствуют периодически повторяющиеся строки VIA с метками нетмейл-
обработчика Itrack. Причина этой петли была в несогласованном с узлом 2:5049/36
изменении правил маршрутизации для адреса 2:5049/99 на узле 2:5049/12.
Анализ петель производится автоматически с использованием специальных
программ - нетмейл-трекеров. При конфигурации нетмейл-трекера важно пра-
вильно задать количество петель, начиная с которого срабатывает диагностика
и письмо удаляется из потока пересылаемых по маршруту писем. Если задать
количество петель слишком малым, возможны ложные срабатывания (некоторые
системы вставляют в письмо несколько строк AaVIA, по числу обрабатывающих
программ). Слишком большое количество петель ведет к неоправданной нагрузке
на сеть. Обычным является количество в 4-5 циклов, как в изображенном выше
письме.
Стандартной реакцией на обнаружение закольцованного письма является воз-
врат его отправителю с дополнительным сообщением о невозможности пересыл-
ки и указанием причины (как правило, это цитата из последовательности клад-
жей, свидетельствующих о петлевом пути следования письма).
Дублированная почта, или дупы (Dupes)
Дублированная почта возникает, когда образуются несколько копий одного пись-
ма, путешествующих далее по одному или нескольким маршрутам. Нетмейл-
дубль не такое частое явление, как дубль эхо-письма, но и не редкость. Основная
причина образования нетмейл-дублей - это плохая связь, в результате чего не-
сколько раз передается одна и та же информация. Конечно, правильно настроен-
ные почтовые программы дублей не производят, но, например, программа пробро-
са почты через Internet, Binkd, с легкостью плодит дубли на «плохом» канале.
Отлавливаются дубли по совпадающему кладжу MSGID. Ниже следует при-
мер служебных строк нетмейл-дупа, взятых из реальных писем:
--------------------------------Кладжи—Письмо-1-------------------------
@MSGID: 2:5093/12 37f8fa2a
©REPLY: 2:5049/12 37f31 cff
©P1D: GEDW32 3.0.b4 7206OS7
@CHRS: +7JIDO2
@Via 2:5093/12@fidonet @19991004.190524.UTC+3 Т-Mail 2604.NT
@Via 2:5093/21 @fidonet @19991004.202154.UTC+3 Т-Mail 2604.NT
@Via 2:5049/36@fidonet @19991004.164659.47.UTC ltrack+ 1.3/G6 DB876437
@Via 2:5049/12@FidoNet @19991004.204845.20.UTC Itrack- 1.3/G6
--------------------------------Кладжи—Письмо-2-------------------------
@MSGID: 2:5093/12 37f8fa2a
@REPLY: 2:5049/12 37f3left
©PID: GEDW32 3.0.b4 7206057
@CHRS:+7_FIDO 2
@Via 2:5093/12@fidonet @19991004.191947.UTC+3 Т-Mail 2604.NT
@Via 2:5093/2 l@fidonet @19991004.202154.UTC+3 Т-Mail 2604.NT
@Via 2:5049/36@fidonet @19991004.164659.70.UTC ltrack+ 1.3/G6 DB876437
@Via 2:5049/12@FidoNet @19991004.204845.26.UTC Itrack- 1.3/G6
Как видно из приведенного примера, эти два письма имеют почти полностью
совпадающие кладж-строки. Различия наблюдаются только в последней строке
AaVIА, на 6 секунд в большую сторону отличается время получения второго пись-
ма относительно первого. Значит, проблему следует искать здесь, на линке между
2:5049/36 и 2:5049/12.
BadMail (дефектные письма) и нетмейл-бомбы
Бывает, что почта портится при передаче по сети. Причины порчи могут быть са-
мые разные: и сбои при передаче между системами, и дисковые аварии, и порча
файловых систем.
Совсем испорченная почта распознается программами, обрабатывающими нет-
мейл, и автоматически помещается в нетмейл-директорий BADMAIL. Но письмо
может выглядеть вполне респектабельно, нести всю адресную и служебную ин-
формацию и тем не менее быть дефектным. Так, довольно часто приходящие эхо-
пакеты интерпретируются как нетмейл-письма и делается попытка отправки их по
роутингу. Такие путешествующие по сети в неизвестном направлении «уродцы»
съедают ресурсы транзитных систем, их нужно выявлять и останавливать их рас-
пространение.
При анализе «плохой» почты очень помогает то, что FidoNet - это сеть с извест-
ным адресным списком. Если настроить трекер так, чтобы он отсеивал письма на
несуществующие в нодлисте узлы и производные от них пойнт-адреса, а также
письма от несуществующих в нодлисте адресов, то большая часть «плохой» поч-
ты осядет на вашей системе. Однако у такого простого решения есть и недостат-
ки: иногда реальная, на законных основаниях существующая система, по ошибке
выпадает из нодлиста и все письма от/для нее обрабатываются как дефектные.
В другом случае имеющийся на вашей системе набор нодлистов может оказаться
неактуальным или испорченным. Здесь вам предстоит сделать выбор. Если вы ре-
шитесь пропускать через свою систему только письма от/для существующих
в нодлисте систем, то вам нужно позаботиться о своевременном получении до-
полнений к нодлистам. Однако это не дает гарантии от ошибок.
Есть и промежуточный вариант. Можно отсеивать почту по маске адреса. Нап-
ример, известно, что в FidoNet только шесть зон. Все письма с номером зоны, вы-
ходящим за этот диапазон, можно считать дефектными. Анализируя нодлист
и типичные случаи дефектного нетмейла, можно выделить и другие адреса, почту
на которые отправлять не следует. Так, адреса 2:0/0 в FidoNet не существует,
и именно этот адрес обычно подставляет тоссер FastEcho как адрес назначения
при сбое, когда эхо-письмо вываливается в поток нетмейл-писем.
Существуют и другие, более «мягкие» случаи: письма с прикрепленными фай-
лами, которые были утрачены (ссылка в заголовке письма на файл есть, а самого
файла нет или он испорчен).
Диагностировать нужно и так называемые нетмейл-бомбы. Нетмейл-бомбой
называется архивированное письмо огромного размера. Например, вам прислали
пакет с архивированной личной почтой. Не составляет труда создать файл разме-
ром в несколько десятков мегабайтов, заголовок которого формально удовлетво-
ряет требованиям, предъявляемым к хранящемуся в файле *.pkt письму. Запако-
ванный файл-архив может быть очень небольшим, но при распаковке может
оказаться, что он займет все свободное пространство дисковой подсистемы ваше-
го компьютера и вызовет остановку работы Fido-станции. Для правильной диаг-
ностики нетмейл-бомб нужно перед распаковкой проверять размер запакованных
файлов и при превышении порога не распаковывать их. Для обычного участника
сети или для пойнта такие предосторожности не нужны, но для крупного хаба или
хоста они не будут лишними.
Диагностика и обработка дефектной почты обычно производится с помощью
нетмейл-трекеров.
Поиск потерянной почты
Розыск неполученной или недошедшей почты - самое обычное занятие в FidoNet.
Поскольку надежность любительской сети и поддерживающих ее систем не всег-
да бывает высокой, почта пропадает или останавливается в пути. Для выясне-
ния обстоятельств исчезновения почты в FidoNet разработаны простые способы
диагностики, и вы вполне можете ими воспользоваться.
Первое, что нужно сделать, когда есть подозрение на то, что ваши письма не
доходят, - это воспользоваться соответствующими тестовыми атрибутами пись-
ма (см. раздел «Контрольные атрибуты письма»). Всего их три, и все могут ока-
заться чрезвычайно полезны:
□ AuditRequest (ARQ) - запрос извещения о прохождении письма от всех тран-
зитных систем;
□ ConfirmationReceipt (CFM) - запрос извещения о прочтении письма;
□ ReturnReceiptRequest (RRQ) - запрос извещения о получении письма.
Помечая письмо этими атрибутами, вы после его отправки обычно получаете
письма-извещения. В ответ на атрибут ARQ приходят письма от транзитных
узлов-хабов, эти ответы формируются автоматически. По ним можно определить
маршрут движения письма и найти станцию, за которую письмо пройти не может.
Не нужно ставить атрибут ARQ на все письма, многочисленные ответы перегру-
жают сеть. Ставьте ARQ только на тестовые письма, специально посланные для
выяснения маршрута прохождения письма.
Пример извещения, полученного в ответ на письмо с атрибутом ARQ, изобра-
жен на рис. 7.43.
Рис. 7.43. Письмо-извещение в ответ на письмо с атрибутом ARQ
Письмо с RRQ - это более «мягкий» тип запроса, ответ на него генерирует толь-
ко станция-получатель. Но если вы его получили, а ответа от хозяина станции нет,
значит, ваше письмо, скорее всего, просто лежит нечитаным на станции получате-
ля (рис. 7.44).
Наконец, полученное в ответ на атрибут CFM извещение сообщает вам, что
ваше письмо было прочитано адресатом. Если на него все еще нет ответа, то это
означает, что ваш корреспондент просто не пишет его. Пример подобного письма-
извещения приведен на рис. 7.45.
25 Мау 1993 04.0514
25 Мау 1999 04:05:14
: Fite Edit Message Special Rexx Setup Windows Help______________\
: From: GEcho
To:Amir Shabashvi 11
Subj: Return receipt
; Attrib : privrcvd sent read recpt
Original message:.
24 May 99 10:19:58
By: Amir Shabashvili, 2:5049/12 ' ' - y
To: Sergey Top, 2:5084/0 ' ' z
Re: Опрос по поводу образования зоны FidoNet на основе региона'50 ' , ; 1
Scanning RUJNTERNET... ~ ~~ ' f Г Г" "" 629 of 1023 ~ [ 2:5049/12
Рис. 7.44. Письмо-извещение в ответ на письмо с атрибутом RRQ
Fleetstreet 1.24.1 - RECEIVED_TECHMAIL_ARCHIVE (L)
File Edit Message Special Rexx Setup Windows Help
From: Kirill Lebedev
To:Amir Shabashvili
Subj:*** Confirmation Receipt Message ***
Attrib ~' priv rcvd sent read recpt
Helio Amiri
2:5649/12
24 May 1999 13:31:16
24 May 1999 13:31:18
This is a confirmation that your message to Kirill; Lebedev, written on 24/May/99 -
at 10:19 regarding ’Опрос по поводу образования зоны FidoNet на основе региона
50has been read at 13:31 on 24/May/99. ' / *
Х£ your message'requires an answer,/Kirill will respond when time permits
With best ; regards,
Kirill .-Lebedev
--- MadMED vO.431/082 (Jan 12 1999 16:42:22)
* Origin: Swan Lake/2 *** http://kirill.rptb.ru/ (2:5020/251)
мадамв
/ z,, ,<i -/ is
| 5570(1023 [
2:5049/12-
Рис. 7.45. Письмо-извещение в ответ на письмо с атрибутом CFM
Форма письма-извещения бывает самой разнообразной, поскольку оно может
быть сгенерировано самыми различными программами и текст ответа отредакти-
рован сисопом по своему усмотрению. Но разобраться в нем всегда можно.
Заключение
Материал прочитанной главы не предназначен непосредственно для изучения
программ, примеры которых использовались для иллюстрации основных пара-
метров конфигурации почтовой системы, а представлен только для общего зна-
комства с принципами ее настройки. Информация из тех разделов главы, которые
не связаны с конфигурированием конкретных программ, еще понадобятся вам при
чтении других глав. Что же касается используемых вами программ, то при настрой-
ке и запуске мейлеров, трекеров и др., имеющих отношение к системе передачи лич-
ной почты FidoNet, пользуйтесь прежде всего их авторскими описаниями.
Глава VIII
Обработка и передача
по сети эхо-конференций
FidoNet
Эхо-конференции FidoNet представляют собой самый популярный сервис сети;
именно благодаря им постоянно формируется ее «дух» или «климат».
В главе 1, разделе «Эхо-конференции FidoNet», приведен обзор истории их
возникновения, правила и традиции управления, примерная классификация
и практика шлюзования в Internet.
В главе 2, разделе «Эхо-почта (echo-mail)», рассмотрены основные правила об-
ращения с эхо-почтой, рассказано о традициях координации эхо-почты, введено
понятие эхо-бекбона - схемы раздачи эхо-почты. Кроме того, приведены ссылки
на основные стандарты FidoNet, касающиеся эхо-почты.
В настоящей главе внимание, главным образом, будет уделено техническим
моментам: форматам сообщений и базам данных, программам, используемым при
обработке эх, и принципам их конфигурации, а также рассмотрены схемы постро-
ения эхо-бекбонов.
Основные понятия
В основе эхо-почты лежит идея обмена содержимым между локальными базами
конференций BBS. Письмо, отправленное пользователем в конференцию на од-
ной BBS, копировалось на несколько других и попадало в локальные базы конфе-
ренций, где его могли читать пользователи этих BBS. Именно из подобной при-
митивной схемы и выросла нынешняя система эхо-почты, которая намного
сложнее в реализации, но немногим более совершенна по сути, чем эта первона-
чальная схема.
Рассмотрим еще раз основные элементы системы эхо-почты:
□ общий алгоритм работы эхо-почты;
□ форматы писем;
□ форматы баз данных, в которых хранятся эхо-письма;
□ программы-обработчики эхо-почты;
□ способы передачи эхо-почты.
Алгоритм работы эхо-системы
Алгоритм работы эхо-процессора изложен в стандартах FTS-0004 и FSC-0074
[2.13, 2.14]. Предположим, что рассматривается некий узел FidoNet, подключен-
ный к системе распространения эхо-почты. Это означает, что существует непус-
тое множество других узлов, получающих эхо-почту от данной системы. Эти узлы
называются эхо-линками. В общих чертах механизм работы эхо-почты сводится
к приведенной ниже последовательности:
1. В соответствующей области или эхо-конференции, то есть в именованном раз-
деле базы данных на рассматриваемой системе FidoNet, создается письмо.
2. Созданное письмо «экспортируется» с добавлением контрольной информа-
ции в выбранную сетевую конференцию. Это означает, что письмо копиру-
ется каждому эхо-линку.
3. Каждая система, принявшая эхо-письмо, «импортирует» его в соответствую-
щую эхо-область, то есть помещает в соответствующий раздел базы данных.
4. Каждая из систем затем «экспортирует» письмо, добавляя свою контроль-
ную информацию, всем своим эхо-линкам.
Контрольная информация, помещаемая в письмо, предотвращает его экспорт
на системы, уже получившие данное сообщение.
Взаимодействие пользователей, получающих эхи, с тоссером, формирующим
пакеты, может быть организовано и без участия сисопа, на узле которого работа-
ет тоссер. Для этого используется почтовый интерфейс, через него осущест-
вляется управление списком эхо-конференций, на которые произведена подпис-
ка, и другими параметрами для данного линка. Подпиской заведует программный
компонент, называемый менеджером подписки (AreaFix Manager).
Как видно, идея эхо-почты и ее механизм исключительно просты, чего, к сожа-
лению, нельзя сказать о реализации. За десять лет существования эхо-почта пре-
терпела множество «косметических» изменений и усовершенствований, но для
правильного ее использования по-прежнему требуется внимательное изучение ее
технологии.
Формат эхо-письма
Базовым форматом хранения писем FidoNet считается *.msg, используемый при дол-
говременном хранении писем и их редактировании, а также формат *.pkt, применя-
емый для временного хранения при пересылке. Они рассмотрены в главе 4. Эхо-
почта использует те же форматы, *.msg и *.pkt, правда, слегка модифицированные,
чтобы можно было отличить эхо-письмо от обычного нетмейл-письма. Фор-
мально, при беглом взгляде, *.msg-файл с только что введенным в редакторе эхо-
письмом ничем не отличается от обычного нетмейл-сообщения. В качестве ад-
реса отправителя в нем присутствует основной адрес системы, на которой
письмо было создано; адрес назначения пустой, но место для него в бинарном
заголовке есть, поэтому если представить такое эхо-письмо просмотрщику нет-
мейла, то он отобразит его как письмо на адрес 0/0 или NZone:0/0, подставив
вместо NZone значение номера зоны по умолчанию. В нашем случае это будет
2:0/0 (рис. 8.1).
------- Netmail -------------------------------------------------------
Msg : 1 - 1 (2.msg) Data/Time: 26 Oct 99 13:53:48
From: Amir Shabashvili 2:5049/12
To : All 0/0
Subj: test
----- 345 xesessssses Pvt LlOC------жаааааяаяви",./issassssssssasagasas.;—u-
@INTL 0:0/0 2:5049/12
@MSGID: 2:5049/12 3815b27a
Hello All!
Это тестовое эхо-письмо
Всех благ,
Amir.
--- Fleetstreet 1.24.1
* Origin: Double Dozen Station (2:5049/12)
Рис. 8.1. Отображение эхо-письма в программе просмотра файлов *.msg
Во время осуществления экспорта письмо из формата MSG переводится в фор-
мат РКТ и в него добавляется контрольная информация, по которой оно одно-
значно может быть распознано как эхо-письмо. Эта информация помещается не
в бинарный заголовок письма, который сохраняет прежний вид, но целиком зано-
сится в кладжи (их описание будет приведено далее). В бинарный же заголовок
пакета при экспорте в качестве адреса-отправителя записывается адрес системы,
где был произведен данный пакет, а в качестве адреса-получателя - адрес, на ко-
торый упаковывается почтовый пакет. На рис. 8.2 приведен заголовок пакета,
куда было упаковано письмо при его экспорте на адрес 2:5049/12.12.
На рис. 8.3 изображено то же самое письмо, что и на рис. 8.1. Именно так оно
выглядит внутри почтового пакета. Его бинарный заголовок, так же как и заголо-
вок почтового пакета, содержит адрес системы, упаковавшей письмо, и адрес, на
который письмо было упаковано (2:5049/96). Легко заметить, что в остальном
письмо мало изменилось, только в его текст добавлено несколько служебных
строк.
Й pktview.exe - 5B9E1BE3.TH0 ' ' ' < ° И
Hie Edit Options Help
Packet from: 2:5049/12 Packet to : 2:5049/96 Data/Time: 26 Oct 1999 14:23:08 Password : XXXXXXX
1 Amir Shabashvili All KAZAN. TEST ... J
: '
Рис. 8.2. Заголовок пакета после экспорта письма на адрес 2:5049/96
pktview.exe - 36ВАВ4А8.РКТ | ° Ю
File Edit Options Help
----- FILEATTACH -----------------------------------------------
Msg : 1 - 1 (30D70915.PKT) Data/Time: 26 Oct 99 13:53:48
| From: Amir Shabashvili 2:5049/12
| To : All 5049/96
| Subj: test
I---- 213 —— Pvt ............................... -....... -...
AREA:KAZAN.TEST
@INTL 0:0/0 2:5049/12
©MSGID: 2:5049/12 3815b27a |
@TID: FastEcho 1.46 128740098
Hello All!
Это тестовое эхо-письмо
Всех благ,
Amir. \
★ Origin: Double Dozen Station (2:5049/12)
SEEN-BY: 5049/12 J
PATH: 5049/12
:t ............................................................ ::Г
Рис. 8.3. Эхо-письмо после экспорта на адрес 2:5049/96
Служебные строки сообщений эхо-почты
Служебные строки, вставляемые в эхо-письмо при его экспорте, несут информацию:
□ о наименовании эхо-области, которой письмо принадлежит (кладж AREA);
□ о пути следования письма (PATH);
□ о системах, на которые письмо уже было экспортировано (SEEN-BY);
□ об адресе, на котором письмо было создано (ORIGIN).
AREA. Кладж AREA, введенный в FTS-0004, особенный. Это обязательный
кладж-признак эхо-письма. Он всегда идет первым по порядку в теле письма, сразу
после бинарного заголовка, и не имеет стандартного кодового префикса Olh, как
большинство остальных кладжей. Это хорошо видно на рис. 8.3. Текст эхо-пись-
ма должен начинаться с AREA - это условие является обязательным, и его нару-
шение может привести к неприятным последствиям. В частности, программы об-
работки могут счесть письмо не эхо-, а нетмейл-сообщением и отправить его
путешествовать по сети в потоке личной почты.
Синтаксис:
AREA:сстандартное наименование эхо-конференции>
Пример:
AREA:KAZAN.GENERAL
ORIGIN. Служебная строка ORIGIN служит для определения адреса систе-
мы, с которой происходит данное эхо-письмо. В письме может быть только одна
строка ORIGIN. Она помещается в сообщении непосредственно после введенно-
го пользователем текста и перед остальными контрольными строками.
Синтаксис:
<npo6en>*<npo6en>0rigin:<пробел>[строка, задаваемая пользо-
вателем] <(адрес)>
Пример:
* Origin: Double Dozen Station (2:5049/12fidonet)
Помещаемый в скобки в конце строки адрес может быть дан в сокращении,
то есть и 5049/12, и 2:5049/12, и 2:5049/12.0fidonet являются допустимыми вари-
антами, однако указание по крайней мере номеров сети и узла обязательно. Со-
гласно стандарту, информационная строка должна состоять из символов первой
половины таблицы ASCII (от кода 32 до 126). Общая длина ORIGIN не должна
превышать 79 символов. ORIGIN вставляется в письмо только на системе, где оно
было создано. Зачастую строка ORIGIN рассматривается сисопами как некий
элемент оформления письма (в отличие от многих других кладжей, ORIGIN все-
гда по умолчанию отображается в редакторе сообщений). На самом деле это не
только и не столько часть оформления. Без строки ORIGIN возникало бы много
ошибок при попытках определения адреса системы, отправившей письмо в сеть.
PATH. В строке PATH перечисляются 2В-адреса систем, через которые про-
шло данное письмо. Строка PATH должна следовать за последней строкой SEEN-
BY (см. ниже). Строк PATH может быть много.
Синтаксис:
aPATH:<список систем через пробел>
Пример:
"aPATH 5049/36 12 96
Для экономии места первый в данной сети адрес приводится в 2Э-формате
(номер сети и узла), а остальные - в 1D (только номер узла), например:
aPATH 5045/68 50 7 5020/204 238 5049/36
означает, что письмо вошло в сеть с системы 5045/68, затем шло по пути 5045/50 =>
5045/7 =ч> 5020/204 ==> 5020/238 => 5049/36. Номер зоны в PATH не указывается,
поэтому при использовании PATH для диагностики петель в распространении эхо-
почты могут быть ложные срабатывания, если в разных зонах есть сети с одинако-
выми номерами и письмо прошло по крайней мере два узла, отличающиеся только
номерами зон. Такая ситуация маловероятна, но вполне реальна, и это один из мел-
ких, но неприятных недостатков технологии распространения эхо-почты.
SEEN-BY. Каждая из систем, через которые проходит эхо-письмо, экспорти-
рует его всем своим линкам, подписанным на данную конференцию. Информа-
ция об этом может быть сохранена в самом письме и в дальнейшем использована
на других системах для предотвращения экспорта на те системы сети, которые
уже получили данное письмо. Кладж SEEN-BY используется как раз для этого.
Конечно, информация в SEEN-BY очень объемна - подчас на конференцию
подписаны сотни и тысячи систем и, хотя в каждое письмо не вставляется ин-
формация о всех этих системах (это становится очевидно, если нарисовать путь
отдельного эхо-письма на любой простой модели сети), размер информации, по-
мещаемой в кладж SEEN-BY, исключительно велик. Однако без него оказывает-
ся невозможным использовать систему эхо-почты, так как из-за ошибок в то-
пологии подписки, которые трудно проконтролировать, в эхо-конференции
начинает поступать настоящий вал дублированных писем. SEEN-BY использу-
ются для исключения повторного экспорта, и на их использовании основаны сис-
темы ускоренной раздачи больших объемов эхо-почты.
Синтаксис:
SEEN-BY: <пробелхсписок систем через пробел>
Пример:
SEEN-BY: 5049/12 84 87 96 98 101 102
Иногда перед SEEN-BY вставляется символ Olh С а). Строк SEEN-BY может
быть много, и первая из них должна следовать непосредственно за строкой
ORIGIN. Длина одной строки SEEN-BY не должна превышать 80 символов.
Правила составления адресного списка аналогичны описанным выше для клад-
жа PATH. И недостатки (при использовании на межзональном линке) те же са-
мые, то есть при появлении в SEEN-BY адресов, отличающихся только номера-
ми зон, обязательно следует ждать ложных срабатываний контрольных систем,
в результате чего письмо не будет экспортировано. Для борьбы с этим феноменом
нужно при перемещении эхо-письма из одной зоны в другую удалять все SEEN-
BY, имеющие отношение к другой зоне. Такое письмо выглядит как происходя-
щее с системы, имеющей линк с другой зоной. Это обычная операция на межзо-
нальном линке, и все тоссеры выполняют ее при соответствующей настройке.
MSGID. Кроме описанных кладжей, специфичных для эхо-писем, встречают-
ся и другие, описанные ранее для нетмейл-сообщений. Самым «ценным» из них,
видимо, является MSGID, содержащий уникальный идентификатор сообщения
и адрес системы, на которой письмо было создано (кстати, это не обязательно ад-
рес в формате FidoNet: может встретиться и Internet-адрес - этим адрес в MSGID
ORIGIN отличается от адреса в ORIGIN MSGID). Обычно оба этих адреса ис-
пользуются программами при определении места происхождения письма, но ад-
рес в MSGID считается более верным.
MSGID широко используется также при определении дублированной почты,
когда не срабатывают остальные механизмы контроля, описанные выше.
Форматы баз эхо-почты
Когда эхо-почта только возникла, большого различия между нетмейлом и эхо-
мейлом не было. Для хранения эхо-мейла использовался тот же формат базы пи-
сем MSG, что и для нетмейла. При очевидных достоинствах у этого формата есть
и существенные недостатки, уже отмеченные в главе 4. Это прежде всего невоз-
можность написания быстро и эффективно работающих программ-редакторов.
Оперировать большим количеством мелких файлов (каждое письмо в формате
MSG помещается в отдельный файл) с высокой скоростью затруднительно. Фак-
тически вся работа перекладывается на файловую систему, и скорость обработки
эхо-почты зависит от ее эффективности.
Поэтому были разработаны более совершенные методы хранения и индекси-
рования сообщений, обычно называемые почтовыми базами данных (Message
Base). Подробная информация об их внутреннем устройстве может понадобить-
ся только при создании программ, использующих такие форматы. Здесь же дано
общее описание четырех основных форматов и приведены рекомендации по их
использованию.
MSG. Формат MSG подробно представлен в главе 4. Он, как правило, исполь-
зуется для хранения нетмейла. Каждая нетмейл-область при этом должна разме-
щаться в отдельном директории. К достоинствам формата относятся надежность
(определяется надежностью самой файловой системы) и простота. Поскольку
нетмейл считается самым важным сервисом, хранение нетмейл-писем в формате
MSG вполне оправдано. Кроме того, многие программы могут обрабатывать нет-
мейл только тогда, когда он хранится в формате MSG. Структура базы данных
MSG заключается, кроме простого набора файлов-сообщений, в некотором ко-
личестве дополнительной информации, хранящейся в самих сообщениях. Это
поля заголовка DATETIME, REPLYTO, NEXTREPLY, TIMESREAD, позволяю-
щие связывать письма в цепочки ответов и сортировать/удалять их по возрасту.
Н MSGBASE - Details View '
Icon Title 1 Real name Size | Last write date j Last write time
в users.bbs 474 1-8-1996 4:37:04 »
DD msgtxt.bbs msgtoidx.bbs msgtxt.bbs msgtoidx.bbs 425,216 8,676 1-8-1996 1-8-1996 4:37:00 E 4:37:04 E
D msginfo.bbs msginfo.bbs 406 1-8-1996 4:37:04 E.
D msgidx.bbs msgidx.bbs 723 1-8-1996 4:37:04 E'
D msghdr.bbs msghdr.bbs 45,067 1-8-1996 4:37:04 E
D mbunlock.now mbunlock.now 0 23-10-1994 2:00:48 Г
D lastread.bbs lastread.bbs 1,200 13-1-2000 2:33:18 E
$ 1/: ' ' X *<*&$**±&S^ f *' XL,
Рис. 8.4. Файлы почтовой FTN-базы типа HUDSON
HUDSON. Этот формат (Hudson Message Base) впервые разработал Адам Хад-
сон (Adam Hudson), автор программы QuickBBS. Сейчас его поддерживают мно-
гие программы BBS и эхо-процессоры. HUDSON основан на пакете TurboAccess,
библиотеке подпрограмм для языка Turbo-Pascal, предназначенной для построе-
ния простой и очень быстрой В+Tree базы данных. Система файлов HUDSON
хранит тексты всех сообщений в одном файле, индексы - в другом, есть отдель-
ный файл для заголовков и т.п. Набор HUDSON-файлов для небольшой базы
эхо-конференций в файловом окне операционной системы OS/2 показан на рис. 8.4.
К сожалению, у формата HUDSON есть и крайне неприятные недостатки. Хра-
нение всей информации в небольшом количестве файлов понижает надежность;
даже при небольших сбоях база может быть непоправимо испорчена. Однако
главный изъян этого формата в другом. Дело в том, что код HUDSON написан
для файловой системы FAT, и увеличение размера любого из файлов свыше
16 Мбайт («естественное» ограничение для DOS-версии FAT) недопустимо. По-
следствия могут быть непредсказуемыми, самое меньшее, что вас ожидает - это
потеря работоспособности по крайней мере до упаковки базы. В худшем же слу-
чае «осколки» вашей базы разлетятся по сети в виде фрагментов текста, нарезан-
ных самым причудливым образом.
Подведем итог: использовать формат HUDSON можно, если только вы не пла-
нируете держать большой архив сообщений. При обширной подписке на популяр-
ные эхи 16 Мбайт текста может накопиться в течение недели-двух, поэтому ис-
пользуйте HUDSON в том случае, если вы подписаны на 3-5 эх, не больше, либо
организуйте ежедневную упаковку базы сообщений.
В остальном формат HUDSON превосходен. Это исключительно быстрый
и компактный способ хранения эхо-почты.
SQUISH. Формат SQUISH называется так по одноименному эхо-процессору,
созданному Скоттом Дадли (Scott J. Dudley), который и ввел его в употребление.
Сейчас это стандартный, широко распространенный формат, поддерживаемый
многими программами BBS и тоссерами.
SQUlSH-формат можно рассматривать как некий компромисс между надеж-
ностью MSG-базы и эффективностью формата HUDSON. В этом формате каждая
конференция хранится в трех файлах: в основном с расширением *.sqd - письма
данной эхи, во вспомогательных - индексы и информация о MSGID принятых
писем (так называемая дупо-база, используемая для исключения повторной об-
работки дублированной почты).
Редакторы обычно создают еще один файл, в котором хранится информация
о последнем прочитанном письме.
Формат SQUISH достаточно надежен, он быстрее MSG, но медленнее HUD-
SON. Этот формат поддерживают некоторые тоссеры, разработанные в R50, на-
пример Parma Tosser (DOS и OS/2) - автор Сергей Кожин (Serge Koghin) из Пе-
тербурга (2:5030/177fidonet).
JAM. JAM - аббревиатура, образованная из первых букв имен его разработчи-
ков: (J)oaquim Homrighausen, (A)ndrew Milner, (M)ats Birch, (Ma)ts Wallin. Этот
формат похож на SQUISH, но работает он обычно быстрее. Каждая область рас-
полагается в четырех файлах:
□ *.jhr - файл заголовков писем;
□ *.jdt - текст писем;
□ *.jdx - индексный файл;
□ *.jlr - информация о последнем прочитанном письме (LASTREAD).
JAM, как и SQUISH, можно использовать для многопользовательского досту-
па, в нем решены вопросы захвата записи и т.п. JAM, так же как и SQUISH, мож-
но рекомендовать в качестве основного формата для хранения эхо-почты.
Интерфейс пользователя
Тоссер обычно работает в автоматическом режиме и обращает на себя внимание
только тогда, когда с ним что-либо происходит. При этом взаимодействие с про-
граммой организовано через три возможных интерфейса:
□ вывод на экран в процессе работы - это самый оперативный и наиболее ред-
ко используемый интерфейс. Заметить что-либо в промелькнувших на экра-
не текстовых сообщениях довольно сложно;
□ интерфейс протокольных файлов - наиболее часто используется для анали-
за возникающих проблем. В программе установки тоссера, как правило, на-
страивается детальность вывода информации в 1о§-файл(ы);
□ почтовый интерфейс - тоссер представляет собой программу по обработке
почты, и по этой причине почтовый интерфейс ему всегда доступен. Посыл-
ка писем от имени тоссера своему «хозяину», сисопу, является стандартным
способом сообщения о возникающих по ходу работы проблемах. Этот интер-
фейс очень удобен и полезен.
Настройка эхо-процессора
Конфигурирование эхо-процессора, как и настройка почтовых программ, - нетри-
виальная задача. Ваша система может быть подписана на сотни эхо-конференций,
каждая из которых должна иметь свои дополнительные настройки, включая спо-
соб хранения, уровень разрешения доступа и многое другое. С вашей системы мо-
гут получать почту десятки других Fido-станций, у каждой из которых будет свой
список подписки, свои пароли и уровни доступа. Поэтому настройка тоссера тре-
бует тщательности, продуманности и немалых затрат времени. Цена ошибки мо-
жет оказаться чрезвычайно высокой - неправильно настроенный тоссер способен
забросать сеть большим количеством дублированной эхо-почты.
Чтобы успокоить читателя, озадаченного этим мрачным вступлением, замечу,
что в случае пойнт-конфигурации, когда система подписана на все эхи только
у одного узла (босса), ситуация радикально упрощается и настройка тоссера не-
сложна, однако понимание того, что и почему следует настраивать, не помешает.
Условно можно произвести декомпозицию системы конфигурации тоссера на
следующие основные элементы:
□ системная информация, определение директориев;
□ общие параметры тоссера;
□ подсистема настройки архиваторов и разархиваторов;
□ подсистема настройки эхо-областей;
□ подсистема настройки линков;
□ подсистема менеджера подписки (AreaFix Manager).
Рассмотрим примеры настройки перечисленных подсистем на примере двух
популярных тоссеров - FastEcho и Squish. FastEcho имеет удобную утилиту
настройки, быстро работает и чрезвычайно широко распространен в R50. К со-
жалению, это классическая shareware-программа, и в незарегистрированной вер-
сии многие дополнительные возможности настройки не работают. Для конфигу-
рации FastEcho используется утилита fesetup.exe. Получающийся в результате
конфигурационный файл имеет нетекстовый формат, просматривать и редакти-
ровать его можно только с помощью fesetup.exe.
Squish также популярен, кроме того, эта программа послужила прообразом для
многих других тоссеров, поскольку автор предоставил в распоряжение разработ-
чиков программ бесплатный API в исходных текстах (MSGAPI) и основанный
на нем пакет разработчика Squish Developers Kit. Squish бесплатен для некоммер-
ческого использования. Его конфигурация размещена в нескольких текстовых
файлах, которые можно просматривать и редактировать с помощью текстового
редактора. Называются эти файлы так:
□ squish.cfg - основной конфигурационный файл;
□ route.cfg - описание маршрутизации исходящей почты и файлов;
□ compress.cfg - настройки архиваторов, этот файл подходит и к BBS Maximus;
□ areas.bbs - настройки эхо-областей (этот файл необязательный, настройки
можно поместить и в файл squish.cfg).
Системная информация и определение директориев
Эта часть настройки тоссера подобна описанной в главе 7 для случая настройки
мейлеров. Здесь задается адресная информация (основной адрес системы и все
ее альтернативные адреса), определяются входной и выходной директорий, тип
мейлера, для которого будет производиться упаковка исходящей почты (АМА
или BSO, в случае FastEcho предлагается меню для выбора из нескольких конк-
ретных мейлеров), и другие общие данные.
SQUISH. Все описываемые в этом разделе параметры должны быть заданы
в файле squish.cfg. На рис. 8.5-8.7 приведены примеры из конфигурационного
файла squish.cfg с исчерпывающими комментариями. На рис. 8.5 представлено
определение адресной информации об узле, на рис. 8.6 и 8.7 - определение типа
и местоположения исходящего и приемного директориев, а также некоторых
файлов и параметров, существенных для работы всей системы.
FASTECHO. Этот тоссер настраивается с использованием утилиты fesetup.exe,
«мгновенные снимки» ее внешнего вида при настройке описываемых параметров
представлены на рис. 8.9-8.13.
Адресная информация. Настраивается выбором System => Network Address.
Всего может быть задано до 31 АКА (рис. 8.9).
Рис. 8.5. Пример настройки адресной информации
в конфигурационном файле эхо-процессора Squish
Рис. 8.6. Пример настройки информации о местоположении входящих директориев
в конфигурационном файле эхр-процессора Squish
е.ехе - squish.cfg ! a .□
File Edit Options Help
3. Тип исходящего директория
|; Задание типа используемой почтовой программы - ключевое слово
'ArcmailAttach* для АМА мейлеров - таких, как T-Mail или FrontDoor.
|; В случае Binkley Style данное ключевое слово должно быть закомментировано.
|; (для BSO-мейлеров - таких, как BinkleyTerm, Brake J, T-Mail в BSO-режиме
J; или Binkd).
Это ключевое слово также отменяет действие большинства команд
маршрутизации почты в файле Route.cfg, хотя он по-прежнему должен
использоваться и содержать правильные команды
маршрутизации, но большую
часть работы в случае АМА-режима выполняет не
Для упаковки исходящей почты в стиле
ключом командной строки 'Squash', то
АМА ужно
тоссер, а мейлер.
вызвать тоссер с
есть написать: [SQUISH.EXE SQUASH]
Пример:
Аг ста i 1A t ta ch
4. Определение
исходящего директория
Если используется BSO мейлер (то есть ключевое слово ArcMailAttach
закомментировано) , ключевое слово 'Outbound' задает корневой исходящий
директорий в стиле Binkley Term. У наименования этого директория не должно
быть расширения.
Если используется ключевое слово 'ArcmailAttach', то определение исходящего
директория с использованием директивы 'Outbound' также необходимо.
В этом директории Squish будет хранить исходящие пакеты с архивированной
эхо-почтой.
Пример:
Outbound
С: \f ido\Ou tbound\Ou tbound
Рис. 8.7. Пример настройки информации о типе и местоположении
исходящего директория в конфигурационном файле эхо-процессора Squish
Имена пользователей. Для FastEcho можно задать имена пользователей, кото-
рые имеют доступ к тоссеру. Первое из заданных имен - это ваше основное имя,
остальные также могут использоваться. Для этих имен можно задать особые пра-
вила обработки при приеме почты, упаковке базы сообщений и подобных дейст-
вий. Настройка производится выбором в меню System позиции User names. Все-
го может быть задано до 11 имен (рис. 8.10).
Тип исходящего директория (тип почтовой программы). В конфигурации
FastEcho тип используемого мейлера задается через выбор меню System =>
Miscellaneous => Mailer, где представлены следующие наименования: Binkley/
Xenia, Portal of Power, McMail, FrontDoor, InterMail и D’Bridge. Если ваш мейлер
не попадает в этот список, что вполне вероятно, так как пик популярности боль-
шинства из перечисленных мейлеров уже в прошлом, то для ArcMail-Attach мей-
лера нужно выбрать FrontDoor, а для Binkley-Style - Binkley/Xenia. Остальные
выборы подменю Miscellaneous задают тип BBS, которая может быть установ-
лена на узле (также в виде выбора из нескольких наименований популярных
программ), способ организации виртуальной памяти (swapping) и вывода на
Рис. 8.8. Пример настройки информации о местоположении дополнительных
системных файлов и директориев в конфигурационном файле
эхо-процессора Squish
экран для программ, запускаемых из-под FastEcho. Пример настройки показан
на рис. 8.11.
Определение директориев. В форме ввода, которая вызывается в утилите
fesetup при выборе меню System => Pathnames задается местоположение вход-
ных директориев:
□ Inbound - основной;
□ Unprot. Inbound - для почты и файлов, полученных по непарольным соеди-
нениям;
□ Temp. Inbound - для хранения *.pkt файлов при тоссинге;
□ Local Inbound - пакеты из этого директория не проверяются на соответствие
пароля.
Кроме того, здесь также определяются:
□ NetMail - основной нетмейл-директорий;
□ Messagebase - местоположение HUDSON-базы писем;
jg FC/2: fosetup2_____ _ ______ _ _____
FESetup System? Data ~ Export Import
? Network „Addresses'
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2:5049/12@fidonet
2:5049/B@fidonet
2:5049/256@fidonet
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
Aka
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
' , |«|o|
Fl Help
>1
И
й^ва
Рис, 8.9. Пример настройки адресной информации в утилите fesetup.exe
Рис. 8.10. Пример настройки имен пользователей в утилите fesetup.exe
Я
□ Outbound и Temp. Outbound - положение исходящего директория и его времен-
ного собрата, предназначенного для хранения *.pkt файлов во время экспорта;
□ Semaphores - директорий для файлов-семафоров;
□ Swapping - директорий для создания временного файла подкачки и некото-
рые другие директории.
й FC/2:Tesetup2
FESetup
Data Export Import
JD j!5L'
Fl Help
Copyrigh
Network addresses
--------- Miscellaneous
BBS Software
Swapping
Be ‘quiet’
аНВВИВИшНВНН
FEUTIL parameters
Compression programs
Decompression programs
External programs
Group names
Origin lines
Burchhardt. All rights reserved
Running under OS/2 3.00
Рис. 8.11. Пример настройки типа почтовой программы в утилите fesetup.exe
L -C/2: Iesetup2_________________________________'
FESetup Data Export Import
Network addresses
User names
I ° |lCTt|
Fl Help
NetMail:
Messagebase:
c:\fido\ma:
Unprot.
Temp.
Local
Inbound
Inbound
Inbound
Inbound
Outbound
D:\FIOO\MSL.
C:\FIOO\FIM
C:\FIOO\FI
Temp, Outbound:
Semaphores:
BBS Config:
Static queue:
Swapping:
Rules:
C:\FIDO\OU
|C:\FIDO\FL1
Press <F10> to save or <ESC> to abort editing...
Рис. 8.12. Пример настройки системы директориев в утилите fesetup.exe
Пример формы ввода изображен на рис. 8.12. Отметим, что большое количе-
ство директориев введено просто для удобства и из любви к порядку. Ничего
страшного не произойдет, если первые два входных директория имеют одно и то
же наименование (если только вы не опасаетесь атаки на вашу систему с использо-
ванием почтовой бомбы) или временные директории не указаны вовсе: FastEcho
в этом случае будет хранить свои временные файлы в текущем директории, где
хранятся файлы тоссера.
Наименование протокольных файлов. Имена протокольных файлов задаются
в форме ввода, появляющейся при выборе System => Filenames из основного меню
fesetup.exe. Здесь определяются: протокольный файл тоссера (выбор Log file),
менеджер подписки (выбор AreaFix Log) и файл статистики (выбор Statistics).
Пример внешнего вида программы fesetup.exe при настройке этих параметров
представлен на рис. 8.13.
Рис. 8.13. Пример настройки наименований протокольных файлов
в утилите fesetup.exe
Общие параметры эхо-процессора
Общими (или глобальными) параметрами эхо-процессора мы будем называть те
настроечные директивы, которые оказывают влияние на поведение программы
в любой ситуации, а не специфичные для отдельного линка/эхо-области и т.п.
Таких глобальных параметров много, и они порой не полностью совпадают у раз-
ных эхо-процессоров. В этой главе внимание будет уделено только основным,
наиболее важным, расшифровку остальных можно найти в руководстве к исполь-
зуемому вами тоссеру. Описание сопровождается примерами из конфигурации
двух эхо-процессоров, FastEcho и Squish.
База идентификаторов сообщений (дупобаза)
Передача дублированной эхо-почты является бичом FidoNet. Этот бессмысленный
процесс съедает ресурсы сети и перегружает ее. Для того чтобы исключить дубли-
рованные письма, было разработано несколько механизмов. Один из них, так на-
зываемая «дупобаза», представляет собой «последний бастион», сражающийся,
когда рухнули все остальные. Дупобаза - это упорядоченный список уникаль-
ных идентификаторов сообщений, MSGID, взятых из писем, проходящих через
узел. Конечно, размер такой базы не может быть безграничным и хранить все
сообщения «от начала времен» невозможно. Вместо этого указывается предель-
ный размер дупобазы, от которого прямо зависит надежность этого защитного
механизма («дуполовка»).
На рис. 8.14 показано, как устанавливается этот параметр (Dupe records)
у FastEcho. В примере выставлено максимальное значение - 524 тыс. записей. На
первый взгляд это очень много, однако опыт показывает, что иногда и этого боль-
шого значения не хватает: дупобаза тоссера «пробивается» и в сеть «вываливает-
ся» пачка дублированной почты, уже когда-то прошедшей по ней, вызывая все-
общее справедливое раздражение ее участников.
Несколько лучше дупобаза организована в тоссере Squish. Здесь список MSGID
ведется отдельно для каждой эхо-области, и поэтому суммарно он может удержи-
вать намного больше записей, чем единый файл тоссера FastEcho. На рис. 8.15 при-
веден фрагмент squish.cfg, относящийся к конфигурации дуполовки.
Число Duplicates, определяющее размер (и надежность) дуполовки, нужно уста-
навливать исходя из объема трафика самой популярной эхи, проходящей через ваш
узел. Скажем, если в день по такой эхе проходит 100 писем, то размер дупобазы
в 1000 записей защитит вас от дубликатов, возраст которых не превышает 10 дней.
Уровень секретности при тоссинге
В заголовке почтового пакета есть место для пароля. Тоссер можно настроить так,
что обрабатываться будут только пакеты, предъявляющие правильный пароль.
Для каждого линка пароль свой, он устанавливается при настройке параметров
Number of records to be kept in duplicates database; 0 = no dupe-checking
Рис. 8.14. Пример настройки глобальных параметров тоссера FastEcho
в утилите fesetup.exe
е^хе --squish.cfg____________________________________________ _ | °
File Edit Options Help j
=; количество хранимых для каждой эхо-области уникальных идентификаторов
Duplicates 1000
; Squish может проверять дублированность как по совпадению MSGID, так
; и по совпадению остальной информации в заголовке сообщения. Модификаторы
; 'MSGID' и 'Header' директивы 'DupeCheck' позволяют выбрать тот или иной
; механизм, или использовать оба.
DupeCheck Header MSGID
; Ключевое слово 'DupeLongHeader' заставляет тоссер использовать все
; поле Subject заголовока письма при анализе на дублированное сообщение.
; По умолчанию, если эта директива не используется, во внимание принимаются
; только первые 24 символа.
DupeLongHeader bj
; Ключевое слово 'KillDupes' инструктирует Squish удалять обнаруженные И
; дублированные письма сразу после обработки. Если директива не используется, и
; такие письма помещаются в базу сообщений. Это удобно, но при таком способе |
; становится невозможным дальнейший анализ происхождения дупов. | .
;KillDupes М
77ZZZZZ:ZZZZZ:ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ^ZZZZZZZZZ;Z'ZZZZZZZzZfZ
Рис. 8.15. Настройка параметров для определения дублированных сообщений
при обработке эхо-почты в конфигурационном файле
эхо-процессора Squish (squish.cfg)
данного линка. Но использовать ли этот пароль при тоссинге (то есть при обработ-
ке входных пакетов от этого линка) или нет - обычно устанавливается глобаль-
ным переключателем. Для хабов или узлов, имеющих много пойнтов, настройка
секретности - обычное дело. Так удается избежать случайностей, которые могут
на время вывести станцию из строя.
Для FastEcho этот параметр устанавливается в утилите fesetup.exe, в меню Sys-
tem => Advanced options => Security (рис. 8.16) и может принимать три значения:
□ None - будут обрабатываться пакеты от любых систем, даже не описанных
в конфигурации тоссера, и притом без какой-либо проверки;
□ Normal - будут обрабатываться пакеты только от систем, описанных в кон-
фигурации тоссера, проверка на совпадение пароля производиться не будет;
□ Full - будут обрабатываться пакеты только от известных систем, при этом
будет производиться проверка на совпадение пароля в заголовке пакета с па-
ролем, установленным для данного линка в конфигурации тоссера.
Для тоссера Squish настройка секретности выполняется в squish.cfg (рис. 8.17).
Параметров здесь меньше - всего один.
К FC/2: fesetup2
| р ||ш|
Fl Help
111
me
Advanced options
Г
Copyr igh
Export Import
Retear L—Tearline Auto-Area-Create No Yes
LyUpdate mailer config n/a
H-Update BBS config n/a
•-New area defaults n/a
Kill empty NetMail No
Kill duplicates No
Share HMB Yes
Force mailer rescan No
Respond to RRO No
Use EMS for buffering No
Check .PKT destination Yes
Security Norm
Logging Full
Graphical tossing None
Toss buffers Temp. Outb. type Large n/a
3.00
ir>1 и , 1Л
ви
chhardt. All rights reserved
................................................................
Always strip unwanted texts from the tearlines of exported messages
Рис. 8.16. Пример настройки дополнительных глобальных параметров
тоссера FastEcho в утилите fesetup.exe
: File Edit Options Help_____________________________'___________________________
*; Ключевое слово 'Secure1 инструктирует тоссер проверять наличие Z
= ; адреса, с которого пришел пакет, в списке адресов линков системы
; (в файле AREAS.BBS или после ключевого слова EchoArea). Если в
; описании линка встречается определение пароля, то выполняется
; и проверка на совпадение пароля.
; При нарушении одного из условий пакет перемещается в область
; "плохих" писем (BAD AREA) .
iSecure ы
^ZZZZZZZZZZZZZZ'ZZZZZZZZZZZZZZZZZZZZZZZZlZZZZZZIZEZlBZZZZEZg
Рис. 8.17. Настройка режима секретности в конфигурационном файле
squish.cfg эхо-процессора Squish
Правила упаковки баз сообщений
Чтобы база писем не росла безгранично, ее нужно регулярно упаковывать, уда-
ляя устаревшие сообщения. В тоссере FastEcho эту работу выполняет утилита
feutil.exe, в тоссере Squish - сам тоссер и утилита sqpack.exe. Общепринятыми
являются следующие параметры упаковки:
□ упаковка по количеству писем в данной эхо-области (при достижении ука-
занного количества старые письма удаляются);
□ упаковка по дате (письма, присланные и полученные раньше определенной
даты удаляются).
Также возможно при упаковке разделять принятую почту и почту, происходя-
щую с данного узла (фактически, ваши личные письма в эхи) - это реализовано
для FastEcho, но отсутствует в Squish. Зато в Squish можно защитить заданное
количество старых писем от удаления.
Глобальная конфигурация правил упаковки есть в FastEcho, но отсутствует
в Squish. Для обоих тоссеров есть возможность описать правила для каждой об-
ласти отдельно. При этом для FastEcho это описание будет иметь преимущество
перед глобальными параметрами. Настройка глобальных параметров упаковки
находится в утилите fesetup.exe по адресу: System => FEUTIL parameters =>
PURGE (рис. 8.18).
Для Squish правила упаковки баз помещаются в список эхо-конференций
(ключевое слово ECHOAREA в файле squish.cfg), описанный далее в этой главе.
Рис. 8.18. Пример настройки глобальных параметров упаковки базы писем
для утилиты feutil.exe в программе fesetup.exe
Настройка архиваторов
Тоссер активно использует архивацию и разархивацию, при этом запускаются
внешние программы, встроенные архиваторы в известных автору тоссерах не
используются. Зато, как правило, есть возможность автоматического определе-
ния типа архива и использования подходящего разархиватора. Метод архивиро-
вания настраивается для каждого линка отдельно, а список архиваторов и коман-
дных строк их вызова представляет собой глобальные параметры. В FastEcho
настройка списка архиваторов производится все в той же утилите feutil.exe
(рис. 8.19-8.21), а для Squish используется отдельный конфигурационный файл,
compress.cfg, подходящий и для BBS Maximus (Squish и Maximus - «братские»
программы, они разработаны одним автором и рассчитаны на работу «в паре»).
На рис. 8.19 дан пример части этого конфигурационного файла с описанием архи-
ватора ARC.
Отметим, что архиватор ARC, один из старых архиваторов, долгое время был
самым распространенным и общепринятым в FidoNet и до сих пор его описание
включается в стандартную конфигурацию тоссеров. Однако наиболее популярен
ZIP, постепенно уступающий позиции архиватору RAR.
Конфигурация подсистемы архиваторов для тоссера FastEcho изображена на
рис. 8.20-8.22. Формы ввода находятся в системе меню Fesetup по следующим
адресам (рис. 8.20):
□ System => Compression programs => DOS/OS2;
□ System => Decompression programs => DOS/OS2.
На рис. 8.21 приведена форма для ввода строк вызова архиваторов при архи-
вации пакетов (для операционной системы OS/2); параметр Rt (Ratio - «коэф-
фициент») имеет смысл ориентировочного коэффициента упаковки, используе-
мого тоссером при ограничении размеров выходного пакета. Rt указан в десятых
долях, то есть 35 означает 1:3.5. По умолчанию используется коэффициент 3.2.
е.ехе - compress.cfg____________________________________________________________________________________\ ° ;□
File Edit Options Help „ „ „_________________
; Описание каждого архиватора начинается с директивы: Archiver <narcie> да
i; где <name> представляет собой сокращеннок название архиватора, которое может быть использовано в
b Файле SQUISH.CFG.
\} Порядок описания архиваторов имеет важное значение, первый архиватор используется по умолчанию, если
\} иное не указано для данного узла в описании линка в файле SQUISH.CFG. Однако, когда делается попытка
распаковки, список архиваторов используется с конца к началу.
^Archiver ARC
; Ключевое слово 'Extension' определяет расширение файла, которое архиватор использует по умолчанию.
Extension ARC
; Ключевое слово 'Ident' используется для задания строки символов, по которой производится
; идентификация данного архива. Если в файле обнаружена такая строка, то он считается упакованным
; данным архиватором. Число после 'Ident' имеет смысл смещения от начала файла, после которого
; находится искомая строка. Если перед числом стоит знак "минус", то ищется смещение от конца файла,
; а сама строка считывается в обратной последовательности. Строка-идентификатор записывается после
; запятой, либо последовательностью 16-ричных двузначных цифр, либо в виде символьной строки в
;двойных кавычках.
Ident 0,1а
; Команда 'Add* представляет командные строки, которые Squish использует при вызове данного
; архиватора для упаковки информации в почтовые пакеты. Вместо "%а" и "W подставляются имя
; архива и в имя добавляемого файла, соответственно. Описание делается отдельно для разных
; операционных систем, при этом могут использоваться модификаторы 'DOS' или 'OS2*.
DOS Add pkpak -oct a %a %f
OS2 Add arc2 aS %a %f
; Команда 'Extract' представляет командные строки, которые Squish использует при вызове данного
; архиватора для извлечения информации из пакета аркмейла. Вместо "%а" и "%f" подставляются имя
; архива и имя извлекаемого файла, соответственно ("%f" может транслироваться
; в метасимволы, то есть в строку типа или "*.М0?").
DOS Extract pkunpak /г %а
OS2 Extract arc2 xw %a —
End Archiver
Рис. 8.19. Пример настройки параметров для архиватора ARC
в конфигурационном файле compress.cfg эхо-процессора Squish
Рис. 8.20. Выбор типа операционной системы при определении архиваторов
в утилите fesetup.exe
Рис. 8.21. Форма ввода строк вызова архиваторов в утилите fesetup.exe
Ha рис. 8.22 приведена форма для ввода строк вызова программ разархивации
(кстати, при архивации и разархивации не всегда используются одни и те же про-
граммы). Это вариант для операционной системы OS/2. Для каждого архивато-
ра, кроме строки описания ключей вызова, может быть сделан выбор (из допол-
нительного меню, изображенного на рисунке) параметров, которые передаются
программе, включая расширение извлекаемых файлов (*.pkt), и путь к директо-
рию, куда они должны извлекаться. Дополнительное меню вызывается из пози-
ции, названной Calling convention.
gf FC/2:7esetup2
FESetup
Command
Network addresses
User names
Data Export ; Import
Type
Unknown
ARC
PKARC
PAK
ARC+Plus
ZOO
PKZip
LHarc
ART
SQZ
RAR
UC2
ARC.EXE xwb ,
Fl Hei
Calling convention
ZOO.'EXE xG
c:\fido\tools4pkunzip> cmd
LH.EXE x /1 /о
UNARJ.EXE e
Press <F10> to save or <ESC> to abort editing...
RAR.EXE e -y -std
cd <path>
<path> *.PKT
fc.PKT <path>
*. PKT tt<path>
*.PKT -d <path>
d Running under OS/2 3.00
Рис. 8.22. Форма ввода строк вызова разархиваторов в утилите fesetup.exe
Подсистема описания эхо-конференций
Узел FidoNet бывает подписан на множество конференций. Например, узел ав-
тора этой книги обслуживает список из 1115 конференций. Управлять таким
количеством сущностей, определять доступ к ним узлов-подписчиков трудно
и неудобно, и любое усовершенствование здесь будет полезно. Ниже приведе-
ны стандартные способы управления доступом и задание параметров сразу для
многих эхо-конференций.
Механизм групповой классификации. Позволяет описать несколько так назы-
ваемых групп, и отнести каждую эху к той или иной группе. Обычно для этого
используется режим автосоздания эх от узла, поставляющего вашему узлу боль-
шую часть эх. Автосоздание производится в соответствии с шаблоном той или
иной группы. Пример заполнения такого шаблона для тоссера FastEcho приведен
на рис. 8.23 (вызывается из меню Data => Group area defaults настроечной утили-
ты fesetup.exe).
Уровень доступа. Это число, которое определяет секретность данной эхо-кон-
ференции. Каждый подписчик имеет свой уровень доступа, при превышении или
совпадении его с уровнем, заданным для данной эхо-конференции, он получает
к ней доступ (на рис. 8.23 для определения секретности на чтение и запись служат
поля ввода Security Read:_Write:_, где установлено значение 100 для чтения
и 101 - для записи).
И FC/2: fesetupZ__________ -_____________________- -
FESetup System НИМ Export Import
Comment:
Origin:
Type:
Storage:
Path:
Use Aka:
Backbone 5049 (/64 /36 /30) links
EchoMail
Pass t h г оиоиИиИЯМиМ
2:5049/12 ИМИШИД
Fl Help
Mandatory:|J
Convert Umlaut: yj
Remote changes: JJ
Keep SEEN-BY: Щ
Keep users: Щ
/ Hide area: Д
Tiny SEEN-BY: Щ
Kill read: В
Keep NetMail: щ
СРВ: Ш '
Disable Passive: Ш
Purging tt Msgs:
Security Read:
0
100
8 Days: EML
Write: ПиМ
it Rcvd Days: EH
Seen-by:
Export to:
2:5049/12
2:5020/238 5049/30 36 96
!аИввВ13И^ИИИШвв§ЯЯИ»111Ийв1ИИЕИ8И1^ШЯИ1ЯИ1
Press <F10> to save or <ESC> to abort editing,<.
Рис. 8.23. Пример описания шаблона группы эхо-конференций для тоссера FastEcho
(утилита fesetup.exe)
Подсистема описания эхо-конференций позволяет:
□ определить стандартное наименование, строку ORIGIN и дать текстовый
комментарий каждой конференции;
□ определить тип области (эхо-конференция, локальная область, нетмейл-об-
ласть), кроме того, есть две специфические технические области с зарезерви-
рованными типами DupeMail (для эхо-почты, квалифицированной как дуб-
лированная) и BadMail (для дефектной эхо-почты);
□ классифицировать все эхи по их доступности, используя механизмы уровней
доступа (отдельно для режима чтения и для записи), и групповой классифи-
кации;
□ задать параметры упаковки базы эхо-конференций для каждой эхо-области;
□ задать список узлов, на которые производится экспорт эхо-конференции;
□ задать содержимое строки SEEN-BY, которое вставляется в этот кладж при
экспорте конференции на другие узлы;
□ задать путь к файлам базы данных, в которых будут храниться сообщения
данной области.
Форма описания параметров конференции на примере тоссера FastEcho дана
на рис. 8.24. Такая форма вызывается из меню Data => Area configuration => Спи-
сок эхо-конференций => наименование нужной эхо-конференции.
В приведенном на рисунке примере описана эхо-область KAZAN. GENERAL, ко-
торая, судя по текстовому комментарию, является основной разговорной эхой се-
ти 5049. База данных конференции имеет тип JAM и хранится в файлах с именем
kazang, в директории D: \FIDO\MSGBASE\. Конференция относится к группе В.
i FC/2: fesetupg
i ° iini
Name:
Comment:
Origin:
Type:
Storage:
Path:
Use AKA:
KAZAN,GENERAL
Main Kazan (5049) echo area
EchoMail
JAM
Board: ИИВ
D:\FIDO\MSGBASE\KAZANG
2:5049/12
Group: Ц
Mandatory:
Convert Umlaut:
Remote changes:
Keep SEEN-BY:
Keep users:
Hide area:
Tiny SEEN-BY:
Kill read:
Keep NetMail:
СРВ: [J Passive:
Disable Passive:
Purging tt
Security
Msgs:
Read:
Seen-by:
Export to:
2:5049/12
2:5020/240 549 5032/15 5049/2 5 8 9 13 15 17 18 19 30 34 36 38 39
2:5049/40 45 64 73 85 96 106 107 108 114 115 116 12.2 .12 .14 .15
2:5049/12.16 .22 ,32 .44 .45 .46 .51 .66 .67 .77 .98 .4646
2:5063/60 5093/27 32
Press F10 to save or ESC to abort editing...
Рис. 8.24. Форма описания параметров конференции на примере тоссера FastEcho
(утилита конфигурации FESETUP)
Упаковка сообщений в базе данных производится через 100 дней после приема
(все сообщения старше этого времени удаляются), кроме того, удаление произво-
дится по числу сообщений в базе данных - не более 15 тыс. Приведен простран-
ный список подписчиков, где многие адреса даны в сокращенной форме (этот
список заполняется преимущественно автоматически, то есть без участия сисопа,
при актах подписки и отписки с использованием менеджера подписки, управля-
емого письмами подписчиков).
Важные параметры TINY SEEN-BY (сокращенный кладж SEEN-BY) и KEEP
SEEN-BY управляют обработкой кладжа SEEN-BY, описанного выше в этой главе.
Кладж SEEN-BY используется как один из основных механизмов предотвращения
появления дублированных писем. Параметр KEEP SEEN-BY определяет, нужно
ли помещать информацию об этом кладже в базу данных сообщений при импор-
те, a TINY SEEN-BY позволяет удалить все SEEN-BY, которые не входят в список
линков вашей станции. Последний переключатель нужно использовать с осторож-
ностью - он предназначен только для систем, которые выполняют роль шлюзов
между сетями. Обрезание SEEN-BY повышает вероятность образования дупов.
Информацию о назначении остальных параметров можно найти в документа-
ции на тоссер.
Описание эхо-конференций в тоссере Squish не так удобно для использования.
Это просто текстовый список, в каждой строке которого определяются парамет-
ры для одной эхо-области. Общий синтаксис такой строки следующий:
<тип почтовой области> <название> <путь к базе> [флаги] [ад-
ресный список]
где <тип почтовой области> принимает одно из значений:
□ EchoArea - эхо-мейл;
□ NetArea - нетмейл;
□ BadArea - дефектная почта;
□ DupeArea - дублированная почта.
<название> - стандартное название области (EchoTag).
<флаги> - необязательные специальные признаки, которые могут принимать
следующие значения:
□ [-f ] - использовать тип хранения *.msg (по умолчанию);
□ [ -р<адрес>] - менять основной адрес системы для данной эхи на <адрес>;
□ [-s] - удалять атрибут PRIVATE из всех проходящих сообщений;
□ [-h] - выставлять атрибут PRIVATE для всех проходящих сообщений;
□ [-х<адрес>] - не разрешать принимать почту в данную эху от <адрес>;
□ [ -и<адрес>] - разрешать принимать широковещательные сообщения и ди-
рективы удаления и добавления от <адрес>;
□ [-0] - не создавать базу данных для данной области («проходной» режим,
или passthrough}',
□ [-+<адрес>] - добавить (исключить) <адрес> в/из списка SEEN-BY для
сообщений в данной области;
^E.EXE-squishcfg ...
File Edit Captions Help !
Основная нетмейл-область; она используется для упаковки почты при Й
АМА-режиме, здесь ищутся письма для Менеджера подписки, и т.п. [
NetArea NETMAIL C:\FIDO\MAIL [
=; Область для дефектной почты. Обязательно должна быть описана. I
BadArea BAD_MSGS C:\FIDO\MAIL\BADMAIL
Область для дублированной почты. Если эта область не описана, то все |
;; дубли помещаются в BadArea.
; DupeArea DUPES C:\FIDO\MAIL\DUPES J
; Далее описана эхо-область KAZAN. TEST, котороая хранится в формате
; *.MSG. Экспорт этой эхо-области производится на адреса:
2:5049/13, 2:5049/19, 2:5049/30, 2:5049/96, 2:5049/12.34,
\; 2:5049/12.42, 2:5049/12.52 и 5093/32 (используется совращенная запись):
EchoArea KAZAN.TEST C:\FIDO\MSGBASE\TEST 2:5049/13 19 30 12.34 .42 .52 5093/32 bl
; Следующая область называется 5049.SYSOP. Она хранится в формате Ы
; Squish (используется ключ *-$'), в файлах с именем
D:\FIDO\MSGBASE\5049SYS.SQ?: Р
(EchoArea 5049.SYSOP D:\FIDO\MSGBASE\5049SYS -$ 2:5049/30 36 96 108 .12 11
Lj.. ............... .............. "............
Рис. 8.25. Пример описания параметров нескольких эхо-конференций
в файле squish.cfg
□ [ — $]— использовать для данной области формат Squish;
□ [-$т<число>] - хранить максимально <число> сообщений при упаковке
данной эхо-области;
□ [ - $ з<число> ] - пропускать первые <число> сообщений при упаковке дан-
ной эхо-области;
□ [-$а<дней>] - при упаковке удалять сообщения, чей возраст превышает
указанное количество <дней>.
Далее следует пример описания нескольких почтовых областей в файле кон-
фигурации squish.cfg тоссера Squish (рис. 8.25).
Подсистема описания линков
В подсистеме описания линков вы должны описать все узлы сети, с которыми
ваша система обменивается эхо-почтой. Основные задаваемые параметры при
этом следующие:
□ основной адрес узла - на него отсылаются письма для данного узла от менед-
жера подписки, этот адрес проставляется в *.pkt-файлы как адрес системы
назначения;
□ arcmail-адрес - на него отправляются архивы с эхо-почтой;
□ адрес вашей системы - под ним ваш тоссер представляется описываемому
линку при любых коммуникациях с последним;
□ имя сисопа - имя системного оператора описываемого узла. Оно будет ис-
пользовано при любых попытках коммуникации с узлом, например в пись-
мах от AreaFix;
□ пароль для почтовых пакетов - пароль, который проверяется при распаков-
ке *.pkt файлов от описываемого узла (как правило, 8 символов, регистр не
имеет значения);
□ пароль для менеджера подписки - пароль, который проверяется при приеме
писем на имя AreaFix, должен помещаться в поле SUBJECT письма (8 симво-
лов, регистр не имеет значения);
□ используемый архиватор - внешний архиватор, который применяется при
упаковке файлов для описываемого узла;
□ максимальный размер архивов - для улучшения почтового обмена при пло-
хой связи имеет смысл ограничить размер формируемых архивов. Это позво-
лит избежать формирования очень больших файлов, которые надолго блоки-
руют узел для доступа всех остальных узлов и не позволяют прочитать
эхо-почту до полного выкачивания файла. Если информация разбита на не-
большие архивы, то можно прервать сессию и обработать те архивы, кото-
рые уже были приняты;
□ уровень доступа - число, определяющее уровень доступа к ресурсам тоссера.
Обычно каждой группе эхо-конференций присваивается свой уровень досту-
па, таким образом можно ранжировать эхо-конференции по их доступности
для линков;
□ список доступных групп - список групп эхо-конференций, к которым имеет
доступ описываемый узел;
□ переключатель пассивный/активный - положение этого переключателя, уп-
равляемого дистанционно, с использованием команд менеджеру подписки оп-
ределяет, производится ли упаковка эхо-конференций на данный адрес. С по-
мощью этого параметра можно временно приостановить подписку, например
на время отпуска;
□ переключатель автосоздания эхо-конференций - разрешать или нет автосоз-
дание эхо-конференций от данного линка. Обычно также указывается шаб-
лон, в соответствии с которым устанавливаются все параметры создаваемой
эхи. Очень удобно конфигурировать автосоздание от аплинков, то есть узлов,
поставляющих вам эхи, - тогда не придется заботиться об описании их пара-
метров вручную;
□ тип формируемого почтового пакета - обычно используется тип 2+, описан-
ный в главе 4.
FastEcho имеет исключительно удобную подсистему конфигурации линков,
вызываемую из пункта меню Data => Node configuration утилиты Fesetup. На-
личие меню выбора линка (рис. 8.26) и меню отметки эх, активных для выбран-
ного линка (рис. 8.27), позволяет достаточно быстро и удобно исправлять конфи-
гурацию подсистемы. Сама форма описания линка, пример заполнения которой
приведен на рис. 8.28, содержит все рассмотренные выше параметры и также до-
статочно удобна для заполнения (часть ее полей заполняется с использованием
встроенных подменю).
Поскольку Squish конфигурируется вручную, с использованием текстового
конфигурационного файла, то подсистема описания линков у него размещена по
2:468/57
{Alex Goldberg]
2:5011/13
2:5020/180
2:5020/204
2:5020/238
2:5020/240
2:5020/549
2:5820/1301
2:5020/1507
2:5021/11
2:5030/115
2:5032/15
2:5045/45
2:5049/1
2:5049/2
2:5049/5
2:5049/8
2:5049/9
2:5049/12.2
2:5949/12.12
2:5049/12.13
2:5049/12.14
[Damir Bikmuhametov]
[Dmitry Baronov]
[Yury Safronov]
[Sergey Gubanov]
[Dima Rumancev]
[Alexey Khoroshikh]
[Dmitry Bredikhin]
[Dennis Sulimov]
[Alexander Kalyazin]
[Andrey Podkolzin]
[Alexey Peshehonov]
[Edward Bikhovets]
[Vitaly Musin]
[Marat Jackupoy]
[Sergey Lebedev]
[Vasya Porsev]
[Wadim Kudrijvcev]
[Alex Smirnoff]
[Amirko Shaab]
[Vitaly Musin]
[Alex Mikheev]
Рис. 8.26. Меню выбора линка подсистемы описания линков тоссера FastEcho
в утилите конфигурации feutil.exe
FC/2: fesetupZ ,
FESetup S
74/100
Addresses
- Main:
ARCmail:
2:5049/48
2:5049/48
Import
Name г
Your AKA
Passwords
Packet:
AreaFix:
Status
ARCmail:
AreaFix:
Packer:
Groups
Security
lDani(i)l St. Lasoukov
2:5049/1?
size: MM
’ВС IК
|1000
; Allow Area--Create
New Area 'Default Group
Export By Name
40/Type 2*
' TosScan
ARCmail 0,60
Pack priority
Convert Umlaut
AreaFix/ flags: [J
Send Notify: Й
<7; , , Send Help: Ц:'
:\ ' Passive:^] J
Automatic Passive: 0И
Enter-Edit Ins-Add Del-Delete F2-Routing F3-Browse F4-AreaListF5-CQpy
Рис. 8.27. Форма описания линка для тоссера FastEcho
в утилите конфигурации feutil.exe
Name:
Your AKA:
Packer
Passwords
Packet:
AreaFix:
Status
ARCmail:
Groups:
Security:
Addresses
Main:
ARCmail;
FC/2: fesetup2______' . ' .
FESetup System Exp
2:5049/2
2:5049/2
Sarat Jackupov
2:5049/12
size
BCK
101
KAZAN.BIM.RADIO
KA2AN.BLACK.LOG
KAZAN.CARS
KAZAN.CARS;EXCHANGE
"KAZAN.CHAINIK
KAZAN.CHAINIK.FAO
KAZAN.DEN-SOFT.TALK
KAZAN.ECHONEWS
• KAZAN.EXCHANGE;
KAZAN.EXCHANGE.TALK
KAZAN.FANTASTICA
KAZAN.FLAME
KAZAN.FM.RADIO
KAZAN.GAME *,"<
KAZAN.GAME.MODEM
KAZAN.GAME*TRADE
« KAZAN.GENERAL
• KAZAN.HARD&SOFT
Enter-Edit Ins-Add Del-Delete
KAZAN.JOB /
KAZAN.KINGSJOKER ;
KAZAN.LICEUM.LOCAL
KAZAN.LICEUM.REPORT
&
t
1
Рис. 8.28. Меню выбора эхо-областей для описываемого линка тоссера FastEcho
в утилите конфигурации feutil.exe
всему конфигурационному файлу, отдельно описываются пароли (в areas.bbs
или в строках EchoArea), дается подписка на эхи и т.д. При описании специфич-
ных для линков параметров в squish.cfg используется универсальный подход: пос-
ле ключевого слова, задающего то или иное конфигурационное значение, идет
ijM Е.ЕХЕ - squish.cfg о и
File Edit Options Help
; Ключевое слово 'Pack' приказывает Squish использовать тот или иной ; метод архивации для приведенного в данной строке списка адресов Pack Zip 2:5049/А11 2:5020/204 Pack Rar 2:5049/16 64 108 Pack Lharc 2:5020/238 1507 Pack Arj 2:5049/57 48 Pack Zoo 2:5049/1
I ' 1
Рис. 8.29. Фрагмент файла squish.cfg,
определяющий соответствие архиваторов и линков
список узлов-подписчиков, для которых это значение имеет силу (см. фрагмент
файла squish.cfg на рис. 8.29).
К счастью, в адресных списках, используемых в squish.cfg, можно применять
обычные правила сокращенной записи адресов, что несколько упрощает работу,
но следует признать, что использовать Feutil при администрировании работы
крупного Fido-узла намного удобнее.
Подписываемся на эхи
Подсистема подписки - это одна из самых привлекательных возможностей эхо-
процессоров. С одной стороны, она снимает с сисопа заботу о подписке его лин-
ков, так как они выполняют все действия сами, с другой - подписчикам также
удобнее управлять списком своих эх, не беспокоя сисопа. Заведует подпиской
программный компонент (менеджер подписки, или AreaFix Manager). Для Squish
прижилось имя SqaFix, поскольку именно так называется утилита, с помощью
которой для Squish выполняются все функции менеджера подписки.
Взаимодействие с менеджером подписки организовано через почтовый интер-
фейс с помощью писем специального формата, описанного в FSC-0057 [2.15]. Мы
уже рассматривали эту процедуру в главе 1 (раздел «Как работает эхо-почта
FidoNet»), здесь же будут приведены примеры настройки самого менеджера под-
писки и перечислены возможные команды, которые может использовать подпис-
чик. Мы рассмотрим подписку на примере тоссера FastEcho, поскольку именно
у этого тоссера AreaFix Manager поддерживает исключительно развитую систему
команд.
На рис. 8.30 приведен фрагмент образца письма от автора тоссера FastEcho ме-
неджеру подписки, установленному по адресу 2:2448/4000, в котором использова-
ны буквально все возможные директивы, которые FastEcho разрешает использовать
в подобных письмах-запросах. Строки, начинающиеся с символа <, представляют
собой комментарии, в настоящем письме-запросе их быть не должно.
Вместо команд %QUERY, % INFO, %LIST, % UNLINKED, %AVAIL и %RESCAN можно
также использовать переключатели после указанного в поле SUBJECT пароля: -
Q, -I, -L, -U, -А и -R соответственно.
Е.ЕХЕ - areafix.hlp \ О |о
File Edit Options Help
Msg : 13 of 23 Uns Pvt Log K/s From : Tobias Burchhardt 2:2448/400 Tue 01 Apr 97 01:46 To : AreaFix 2:2448/4000 Subj : PASSWORD <- Ваш пароль RA_UTIL <- подписаться на эху RU_UTIL +DFUE.GER <- подписаться на эху DFUE.GER -SYSOPS.024 <- Отписаться от эхи SYSOPS.24
U.ENG.* < -F.???♦COMP.* < * < Подписаться на все эхи, название которых начинается с "U.ENG." Удалить все эхи, соответствующие шаблону ("?" замещает один символ,"*" - любое количество) Подписаться на все доступные эхи Отписаться от всего
%RESCAN < Выполнить RESCAN (то есть экспортировать все, что есть у аплинка в базе)
FASTECHO.GER %DAYS 7 SHAREWRE %MSGS 100 FE_HELP FDECHO, R FDECHO.GER, R=30( для указанной эхо-области, и подписаться на нее, если подписка еще не выполнена <- Выпонить RESCAN только для писем, полученных в последние 7 дней <- Выполнить RESCAN, экспортируя не более 100 сообщений из каждой указанной области <- Альтернативный способ ресказа указанной эхи. ) <- То же, не более 300 сообщений.
=* ~245_31.ECHO &DOOM.GER SPIELE. <- RESCAN всех эх, на которые есть подписка (требует предварительной команды %RESCAN) <- Удалить указанную эху ив конфигурации тоссера .DOOM.GER <- Переименовать эху DOOM.GER В SPIELE.DOOM.GER
%FROM 2:2448/48 %QUERY %INFO %LIST %UNLINKED %AVAIL %PAUSE %RESUME ' <- Выпонить изменения как если бы они были сделаны от имени указанного узла (удаленное управление). Эта команда должна быть первой в письме <- Запросить список имеющейся подписки <- Получить общую информацию <- Запросить полный список доступных эх <- Запросить список эх, на которые подписки нет <- Запросить список эх, доступных с аплинка системы, на которую посылается запрос. <- Временно выключить подписку <- Включить подписку, если она была выключена командой % PAUSE
%EXPORT <- Установить режим "Экспорт по имени". Все, что приходит на Ваше имя, независимо от
%NOEXPORT %NOTE ^COMPRESS LHA использованных адресов и текущей активности подписки, будет экспортироваться на ваш узел <- Выключает режим "Экспорт по имени" <- Послать строчку сисопу <- сменить поогоамму-аохиватоо на LHA
Рис. 8.30. Образец запроса к менеджеру подписки тоссера FastEcho
с комментариями автора программы (содержимое файла area fix. hip)
Например:
<ВАШ ПАРОЛЬ» -Q -L -А
Пусть вас не пугает обилие команд запроса к AreaFix: из всего этого многообра-
зия вам понадобится всего несколько команд. Опыт показывает, что постоянно
используются, кроме команд подписки и отписки, команды %LIST и %QUERY. При
временном прекращении работы вашей системы не забывайте остановить под-
писку командой % PAUSE, а при возвращении из отпуска восстанавливайте ее ко-
мандой %AVAIL.
Конфигурация менеджера подписки с «серверной стороны» заключается в раз-
решении или запрещении использования тех или иных команд AreaFix. Так, Fast-
Echo настройке подлежат следующие параметры (как правило, можно использо-
вать значение, которое установлено по умолчанию):
□ разрешить/запретить команды %RESCAN (с выбором дополнительных пара-
метров);
□ разрешить/запретить команды смены AreaFix-пароля %PWD;
□ разрешить/запретить команды смены РКТ-пароля %PKTPWD;
□ разрешить/запретить команды смены архиватора %COMPRESS;
□ удаление/сохранение обработанных писем-запросов;
□ удаление/сохранение письма-извещения самого AreaFix после отсылки;
□ детальность вывода команды %LIST.
Также проверяются и некоторые другие параметры.
Пример меню конфигурации AreaFix изображен на рис. 8.31, оно доступно
в утилите fesetup.exe при выборе позиций Data => AreaFix options.
И FC/2: fesetup?______________________________________
FESetup System пшшг Export Import
' -i 5 -i "I 1X '1 ' I?" - I 'J < I'" •1 * J" - U1 ’11 .......
tl H'S РЧ
ГА.'И
.la'..,,
mi, »
%”' B(|E>
Node configuration
Group area defaults
Area configuration
----- AreaFix options
E , ,f r.l, H J
ШУ
'SeEi'J'^ ri!Q >'*' Л ,‘Н<е'еЧ Ц'
•JpVj Copyright 1991-97;
‘—Rescan defaults
Allow *PWD
Allow 2PKTPWD
Allow ^COMPRESS
Keep requests
Keep receipts
Scan before tossing
Detailed ^LIST
Add list to receipt
Passwords in %INFO
Send conference rules
L—Rulefile area tag prefix
Max. receipt size 16000
AreaFix %HELP file
Forward requests
Allow ^RESCAN meta command in AreaFix requests
Fl Help
Yes
Yes
Yes
Yes
No
No
Yes
Yes
No
No
1 >
Рис. 8.31. Пример меню конфигурации AreaFix в программе fesetup.exe
Координация распространения эхо-почты
Полиси не регламентирует в какой-либо форме координацию эхо-почты, ссылаясь
на необходимость принятия и использования для этой цели специального докумен-
та, называемого Эхо-Полиси, или правил использования эхо-почты. Такой доку-
мент в FidoNet так и не был принят, и координации эхо-почты на уровне всей сети
не существует, а значит и не существует централизованной системы распростране-
ния эхо-конференций FidoNet. Это и хорошо, и плохо. Хорошо, поскольку оставля-
ет максимум свободы для управления эхо-конференциями на местах. Плохо, потому
что при создании межсетевых, международных конференций возникают трудности
в организации их распространения, формирования шлюзов в другие сети и т.п.
Тем не менее механизмы управления эхо-конференциями в FidoNet существу-
ют и действуют они в достаточно больших структурных единицах - сетях, регио-
нах и отчасти в некоторых зонах. Эти механизмы основываются на документах
соответствующего уровня, принятых либо всеобщим голосованием, либо голо-
сованием на уровне координаторов. Все эти документы носят наименование
ECHOPOL, или Эхо-Полиси, и генеалогически восходят к Эхо-Полиси первой
зоны, действующей с 22 октября 1990 года [8.1]. Вы можете получить экземпляр
FidoNews с текстом Эхо-Полиси в Internet по адресу http://fidonews.org. Сейчас
этот документ интересен только с исторической точки зрения, поскольку в регио-
не 50 принята и действует своя Эхо-Полиси, только отчасти основанная на поло-
жениях первого документа.
Во второй зоне, к которой относится и Россия, действует зональная Эхо-Поли-
си, разработанная на основе Эхо-Полиси первой зоны и имеющая с ней очень
много общего. Этот документ был опубликован в FidoNews в 1996 году [8.2].
К сожалению, региональный документ появился раньше зонального и по этой
причине совершенно с ним не согласован. Регион 50 живет по своим внутренним
правилам, регламентируемым региональной Эхо-Полиси (см. приложение 10).
При дальнейшем изложении мы в основном будем иметь в виду региональный
документ, за исключением тех случаев, когда речь пойдет о зональных или сете-
вых структурах.
Эхо-Полиси представляет собой добровольное соглашение между частью уз-
лов FidoNet по поводу распространения эхо-почты. Никто не может запретить вам
заниматься распространением эхо-почты помимо Эхо-Полиси, но в этом случае
вы остаетесь наедине с проблемой управления и координации распространяемой
вами системы эхо-конференций.
Эхо-Полиси также вводит определения и терминологию, сложившуюся в Fido-
Net de-facto, переводя систему распространения эхо-почты из разряда обычая
или традиции, всегда страдающего некоторой расплывчатостью, в область чет-
кости и определенности. Вслед за Эхо-Полиси введем основные понятия, кото-
рые понадобятся при анализе системы управления эхо-конференциями.
Эхо-бекбон, или скелетная сеть. Эхо-бекбоном называют часть сети, попадаю-
щую под юрисдикцию Эхо-Полиси вследствие того, что все узлы, составляющие
бекбон, согласились поддерживать его функционирование, руководствуясь дан-
ным документом. Эхо-Полиси, если рассматривать ее в отрыве от концепции бек-
бона, регулирует только очень небольшую часть взаимоотношений узлов по по-
воду распространения эхо-почты. Основная суть Эхо-Полиси связана с бекбоном
и управлением его работой. Отсюда понятно, что каждый конкретный бекбон на-
мертво связан с Эхо-Полиси, регламентирующей его работу, и относится к той
же части FidoNet, что и эта Эхо-Полиси.
Примерами подобных бекбонов могут служить NAB (North American Backbone,
первая зона FidoNet), WWB (World-Wide Backbone, международный бекбон),
бекбон региона 50 (регион 50 FidoNet, Россия) и бекбон сети TartarNet (сеть
5049).
Кроме организационного, формального определения бекбона, существует так-
же представление о бекбоне как о технической структуре по распространению
эхо-конференций. Варианты технической реализации бекбонов рассмотрены
далее в этой главе.
Не стоит путать и смешивать понятия, относящиеся к организационной и тех-
нической областям. Конечно, у них имеются общие черты, но по сути они описы-
вают разные сферы функционирования бекбона.
Эхо-координаторы. Эхо-Полиси вводит понятие эхо-координатора. Эхо-коор-
динатор занимается управлением бекбона соответствующего его компетенции уров-
ня, и в некоторых случаях разрешает конфликты, возникающие в эхах. В FidoNet
существуют следующие посты эхо-координаторов:
□ ZEC (Zone Echomail Coordinator) - координатор зонального уровня, в обязан-
ности которого входит поддержание списка эх зонального бекбона в актуаль-
ном состоянии, другие процедуры управления бекбоном зонального уровня,
а также взаимодействие с региональными эхо-координаторами (REC). ZEC
выбирается большинством при голосовании структуры координаторов зоны;
□ REC (Regional Echomail Coordinator) - координатор регионального уровня,
в обязанности которого входит поддержание списка эх регионального бекбо-
на, другие процедуры управления бекбоном регионального уровня, а также вза-
имодействие с сетевыми эхо-координаторами (NEC). Региональный коорди-
натор выбирается голосованием координаторов данного региона;
□ NEC (Net Echomail Coordinator) - координатор уровня сети, который на-
значается соответствующим сетевым координатором (NC).
Для описания узлов, сисопы которых выполняют обязанности эхо-координа-
торов, в нодлисте введены специальные флаги (глава 2).
Модераторы эхо-конференций. Под юрисдикцию Эхо-Полиси обычно попада-
ют только модерируемые конференции. Институт модераторов уже рассматривал-
ся конспективно в главе 1 (раздел «Основной ритуал и правила выживания»). Мо-
дератор председательствует в эхо-конференции, устанавливает правила поведения
в ней, отключает нарушителей и т.п. Согласно сложившейся практике он является
полноправным хозяином эхо-конференции и не может быть смещен. Модератор
может назначить одного или нескольких помощников - ко-модераторов.
Важным моментом является то, что модератор не обязан быть участником
FidoNet (это положение связано с тем, что многие конференции модерируются
с пойнт-адресов или адресов Internet). Эхо-Полиси устанавливает правила при-
знания модераторов для бекбонных эхо-конференций. (Бекбонными называют
эхи, распространяемые с использованием данного бекбона.) Как правило, права
модератора конференции признаются при следующих условиях:
□ при создании конференции человек, создавший ее, считается модератором;
□ при отставке или замене существующего модератора выбор нового коорди-
натора определяется объявленными правилами конференции.
Модераторы и ко-модераторы (если таковые существуют) перечисляются
в списке конференций бекбона, что служит для хабов руководством при получе-
нии необходимой для них информации.
Модератор отвечает как минимум за следующее:
□ ежемесячную публикацию правил в конференции;
□ соответствие содержимого конференции требованиям Полиси (отсутствие
нелегальной информации или содействия нелегальной деятельности);
□ просмотр содержимого конференции на предмет соответствия правилам
и принятие мер к нарушителям (этот процесс обычно и называют модериро-
ванием).
Эхо-хабы. Бекбон составлен из структуры раздающих эхо-конференции узлов,
называемых эхо-хабами. Эхо-координатор соответствующего уровня определяет
список хабов для образования бекбона. Региональные эхо-хабы поставляют эхо-
конференции для сетей региона, сетевые хабы, образующие сетевой эхо-бекбон, -
узлам сети, конечным потребителям сервиса. Как правило, эхо-хаб делает до-
ступными для подписки все конференции данного эхо-бекбона.
Эхо-координаторы и координаторы FidoNet. Эхо-координаторы и сисопы ха-
бов бекбона являются узлами FidoNet и по этой причине выполняют все реше-
ния координаторов FidoNet. Обычно координаторы FidoNet (NC, RC) не вмеши-
ваются в деятельность эхо-координаторов и сисопов хабов бекбона, пока эта
деятельность не нарушает функционирование сети или региона. Возникающие
конфликтные ситуации между обычными и эхо-координаторами разрешает вы-
шестоящий координатор FidoNet.
Добавление конференции на бекбон и удаление с него
Для того чтобы конференция могла распространяться средствами бекбона, необ-
ходимо выполнить следующие два условия:
□ модератор должен отправить нетмейлом запрос о принятии конференции на
бекбон эхо-координатору. В запрос обычно входит стандартное наименова-
ние конференции, строка комментария, адрес и имя модератора конферен-
ции и ее правила;
□ конференция должна быть физически создана на одном из хабов бекбона.
Порядок разрешения конфликтов
Обычно все конфликты в конференции разрешает ее модератор. В особых слу-
чаях допустима апелляция в адрес NEC или REC. Перед подачей жалобы ре-
комендуется сначала связаться нетмейлом с лицом, допустившим нарушение,
и попытаться урегулировать конфликт. Не принимаются апелляции на санк-
ции, налагаемые модераторами эхо-конференций, если они:
□ являются внутренним делом конференции;
□ не нарушают объявленных правил конференции;
□ не затрагивают других конференций бекбона.
В случае обнаружения потока дублированных сообщений REC или NEC впра-
ве разорвать эхо-линк с виновным узлом. Такое требование REC или NEC обяза-
тельно для выполнения любым узлом, получающим почту с данного бекбона.
Все конфликты, касающиеся соблюдения Полиси FidoNet, разрешаются вне
Эхо-Полиси, как это описано в главе 2.
Схемы технической реализации эхо-бекбона
Первоначально связи между узлами, распространяющими эхо-почту, устанавлива-
лись хаотически. Однако полная бесперспективность такого подхода стала очевид-
ной после появления первой пачки дублированной почты. Поэтому уже на заре
«бекбоностроительства» было очевидно, что необходимо придерживаться той или
иной топологической схемы построения, позволяющей, с одной стороны, убыстрить
передачу эхо-конференций от одного узла бекбона к другому, с другой - повысить
надежность распространения эх и уменьшить вероятность появления дупов. Будут
рассмотрены три популярные топологические схемы устройства бекбонов, каждая
из которых получила распространение в регионе 50.
«Звезда»
Схема бекбона типа «звезда» изображена на рис. 8.32. В центре структуры нахо-
дится центральный хаб, или хаб нулевого уровня. С ним связана группа хабов
первого уровня, которые обычно и составляют основу бекбона. Хаб нулевого уров-
ня не имеет других эхо-линков, кроме линков с хабами первого уровня. Хабы пер-
вого уровня уже являются раздающими, с них получают почту сетевые лонглин-
ки (если рассматриваемый бекбон имеет статус регионального) или простые узлы,
рядовые участники сети (если речь идет о сетевом бекбоне). В случае очень боль-
шой сети могут вводиться и хабы второго уровня (рис. 8.33).
Схема типа «звезда» обеспечивает устойчивое, без дупов и потерь, распростра-
нение эхо-конференций. Недостатками этой схемы являются относительно низ-
кая скорость раздачи трафика и зависимость всей системы от функционирования
нулевого хаба. На случай его неработоспособности желательно иметь «запасной»
хаб, который может взять на себя функции «нулевика».
Рис. 8.32. Схема эхо-бекбона
типа «звезда»
Рис. 8.33. Вариант схемы эхо-бекбона
типа «звезда» с хабами второго уровня
«Блин»
«Блином» называется структура хабов, подписанных друг у друга на весь набор
бекбонных эх по принципу «каждый с каждым». Схематически такая структура
из пяти узлов (с адресами, условно обозначенными как А, В, С, D и Е) изображе-
на на рис. 8.34. На первый взгляд «блин» является настоящим дупотроном, одна-
ко при использовании механизма SEEN-BY дупов удается избежать.
Для примера рассмотрим письмо, экспортированное с узла А. Поскольку А свя-
зан эхо-линками со всеми остальными узлами «блина», при экспорте письма на
каждый из них в контрольную информацию будет вставлена такая строка:
SEEN-BY: А В С D Е
Теперь каждый из узлов, получив письмо, не будет экспортировать его на дру-
гие узлы бекбона, так как наличие их адресов в SEEN-BY препятствует этому
(см. описание механизма контроля по SEEN-BY в начале этой главы). Экспорт
пойдет только на даунлинков, не входящих в состав хабов бекбона.
К достоинствам «блинной» схемы относится очень высокая (видимо, мак-
симально возможная) скорость раздачи эхо-трафика. Поэтому такие структу-
ры часто используются как центральные в сетевых и региональном бекбонах.
Так, например, бекбон сети TartarNet построен именно по описанной схеме.
Другой пример: три хаба нулевого уровня регионального бекбона также объе-
денены в «блин»-структуру.
При использовании «блина» очень удобно обслуживать большой массив эх.
Тоссеры хабов легко настраиваются на автосоздание эх от любого из хабов с ав-
томатической подпиской на эху всех остальных хабов бекбона (это делается оп-
ределением соответствующего шаблона группы эх и разрешением автосоздания
для хабов в соответствии с описанным шаблоном, см. описание конфигурации
тоссеров в этой главе). После этого, если эха создается на одном из хабов, она
автоматически появляется и на всех остальных.
К недостаткам этой схемы относится ее чрезвычайная неустойчивость к возмож-
ным ошибкам в конфигурации, например, если один из хабов «забывает» подпи-
сать другого на ту или иную конференцию, то оборачивается это большим коли-
чеством дублированной почты. Также необходимо обеспечить хорошую связь
Рис. 8.34. Схема эхо-бекбона
типа «блин»
«каждого с каждым», при ее отсутствии «блин»
работает «рывками».
Следует отметить, что «блин» нужно состав-
лять из узлов, которые имеют приблизительно
равный объем входной почты, иначе он факти-
чески вырождается в обычную «звезду». Чтобы
убедиться в этом, достаточно проанализировать
работу схемы, изображенной на рис. 8.34, для
случая, когда «накачка» бекбона эхами осуще-
ствляется только с узла А. Очевидно, что в этом
случае распространение эх будет происходить
от центрального узла (А) ко всем остальным -
случай классической «звезды».
Количество узлов в «блине» не должно быть слишком большим - не более 3-5,
так как надежность системы зависит от бесперебойного функционирования каж-
дого элемента, а на большой схеме это обеспечить очень трудно.
Комбинированная схема: «звезда» с «блином» в центре
Реальный бекбон всегда строится либо как «звезда звезд», либо по комбиниро-
ванной схеме: в центре - «блин», от каждого из хабов - «звезда», на следующем
уровне структура может повторяться. На рис. 8.35 изображена структура реаль-
ного регионального бекбона 50-го региона. Здесь показана центральная структу-
ра: полносвязный треугольник узлов 2:5020/115, 2:5020/204, 2:5020/238 и при-
линкованный к узлу 2:5020/238 бекбон сети 5049. Также от каждого из хабов
отходят линки к другим сетям региона.
Рис. 8.35. Фрагмент схемы регионального бекбона региона 50 второй зоны FidoNet
Бекбон и лонглинки
Один или несколько узлов поставляют эхи на бекбон, осуществляя связь бекбона
с внешним миром; такие узлы обычно называют лонглинками (от англ, long-link -
«дальняя связь»). Схема «блина» позволяет осуществить удобную процедуру при-
ема эх извне с резервированием. Рассмотрим пример, приведенный на рис. 8.36.
Здесь изображена реальная ситуация, имеющая место в действительности.
Узлы 2:5049/12, 2:5049/30 и 2:5049/36 составляют бекбон сети 2:5049 (бекбон
типа «блин»). Два из них: /12 и /36 - связаны постоянным эхо-линком с одним
из хабов регионального бекбона, 2:5020/238. При соединении оба узла подставля-
ют один и тот же адрес, 2:5049/256, и забирают почту с 2:5020/238 на конкурент-
ной основе - «кто успел, тот и съел». Если один из узлов, /12 или /36, испытыва-
ет затруднения при связи с 2:5020/238 (вполне реальные, так как 5020/238
Рис. 8.36. Схема работы эхо-бекбона сети 2:5049
находится в другом городе и связь с ним осуществляется через Internet - /12, /36,
или обычной прозвонкой - /36), то оставшийся линк вполне достаточен для «на-
качки» бекбона эхами; в этом случае другой лонглинк получит свою порцию не от
5020/238, а от своего соседа-лонглинка.
В рассмотренной выше ситуации речь идет о получении эх, отправка же их
обычно осуществляется через одно соединение.
Возможные трудности в доставке эхо-почты
FidoNet и их устранение
Трудности в доставке эхо-почты можно разделить на проблемы, возникающие
вследствие неверной конфигурации тоссеров на вовлеченных в процесс узлах,
и на ошибки в топологии взаимной подписки.
Чрезвычайно распространенными являются следующие ошибки конфигурации:
□ ошибки секретности (пароли). Неверно заданные пароли, которые ставятся
в файлы *.pkt (поле PACKET: на рис. 8.27), могут помешать отправке или по-
лучению эхо-почты. Пароль для общения с AreaFix также важен: если он не-
верный, то вы не сможете управлять своей подпиской. К счастью, при ошиб-
ке обнаруживший ее тоссер известит вас письмом о ее причине и вы сможете
выяснить, каков же верный пароль - как правило, это делается директным
нетмейлом;
□ ошибки секретности (уровень доступа). Эти ошибки не так очевидны, но
не менее опасны. Если уровень доступа - ваш, вашего линка либо какой-
нибудь конференции или группы конференций задан неверно, то вы или не
получите эхо-конференции, для которых ваш уровень доступа на чтение не-
достаточен, либо не сможете отправить письма в конференции, для которых
установлен слишком высокий уровень доступа, либо и то и другое. Список
конференций, доступных для чтения, можно получить, послав команду
%LIST менеджеру подписки вашего аплинка;
□ обрезание строк SEEN-BY. Многие тоссеры имеют возможность срезать слу-
жебные строки SEEN-BY, и это действительно нужно делать на межзональ-
ных линках (по причинам, объясненным выше в этой главе). Для FastEcho
эта возможность реализуется установкой в YES-поля TINY SEEN-BY уста-
новок эхо-конференции в форме описания (рис. 8.16). Но в тех случаях, ког-
да вы передаете эхи еще кому-то, делать этого ни в коем случае нельзя, по-
скольку срезание SEEN-BY лишает тоссер одного из основных способов
контроля за дублированной эхо-почтой;
□ размер дуполовки. Установка слишком малого количества записей базы
идентификаторов прошедших через узел эхо-писем (поле DUPE RECORDS
на рис. 8.9) практически выключает основной механизм контроля дупов. Все-
гда ставьте максимально возможный размер;
□ «письма из прошлого». Если по ошибке кто-либо «вываливает» в сеть ста-
рые письма, уже когда-то давно прошедшие по сети, то обычные механизмы
отлова дублей не срабатывают, и этот пакет распространяется по всей сети,
вызывая раздражение сисопов.
Как правило, продиагностировать ошибки конфигурации эхо-линка можно
только при сотрудничестве сисопов с обеих его сторон. При этом часто использу-
ются тестовые эхи, специально созданные для проверки хождения эхо-почты.
Ошибки топологии распространения эх анализируются с использованием ин-
формации из служебных строк PATH эхо-писем. В этих строках явным образом
отображен путь полученного письма. Сами по себе ошибки топологии не страш-
ны, так как имеющиеся механизмы контроля, описанные выше, вполне справля-
ются с отловом дублированной почты. Но при одновременных ошибках в конфи-
гурации тоссера, например при срезании PATH, или при отсутствии в письмах
MSGID, ошибки топологии распространения сразу же проявляются огромным
числом дублированных эхо-писем. Но даже и в том случае, когда вся дублирован-
ная почта благополучно отлавливается на первом же линке, все равно ничего хо-
рошего в подобной ситуации нет, так как она передается по крайней мере между
двумя станциями FidoNet, отнимая драгоценное время и (иногда) деньги сисо-
пов, «съедая» пространство на устройствах хранения данных.
Если дублированной почты очень много, то дуполовка может не выдержать,
поскольку размер базы данных, где хранятся MSGID, хотя и велик, но не бесконе-
чен. Например, для FastEcho максимальный размер дуполовки равен 524000 за-
писей, но не всегда это значение используется. По умолчанию установлено зна-
чение в 32000 записей, а это не так уж и много.
Заключение
Итак, вы познакомились с тем, как нужно настраивать систему работы с эхо-по-
чтой на узле FidoNet. Правильно, без единой ошибки и посторонней помощи на-
строить эхо-процессор удается далеко не сразу. Надеюсь, что материал, изложен-
ный в данной главе, поможет вам преодолеть этот «барьер» с наименьшими
затратами времени и нервов.
ГжапсС L
Обработка и передача
файлов по сети
Ранее, в главах первой, второй и шестой, мы уже кратко рассматривали файловые
конференции.
Тематическая рассылка файлов по сети называется в FidoNet файл-эхами, или
файловыми конференциями. Названия эти неточны. Но у файловых эх и у обыч-
ных эхо-конференций есть общие черты, что и определило название. Иногда
процесс передачи файл-эх именуют более точно file-foiaearding («пересылка фай-
лов»), но это обозначение в качестве основного не прижилось.
Файловые конференции представляют собой «тяжеловесный» сервис; подпи-
савшись на большое количество файл-эх, можно с легкостью исчерпать пропуск-
ную способность линка, поэтому относиться к нему следует с осторожностью, ис-
ходя из возможного, а не из желаемого.
Файловые конференции, как и обычные эхо-конференции, не страдают излиш-
ней эффективностью. Подписавшись на файл-эху, вы получите все файлы, прохо-
дящие по ней, независимо от того, нужны они вам или нет. Для пропуска файлов
можно воспользоваться функцией SKIP, реализованной в некоторых почтовых
программах (например, в T-Mail).
Основные понятия
Идея файловых конференций чрезвычайно проста и заключается в следующем:
вместе с файлом, который сисоп намерен распространить по сети, посылается
информационный файл с расширением *.tic. Этот файл используется специаль-
ными программами - файл-эхопроцессорами, или тик-процессорами, для даль-
нейшей рассылки файла. Непосредственно при посылке файла используется
обычный механизм директной отправки, так называемый file-attach, подробно
описанный в главе 2.
На развитие механизма файловых конференций большое влияние оказали про-
граммы TICK - старая программа Барри Геллера (Barry Geller) и AllFix, написан-
ная Гаральдом Гармсом (Harald Harms). Последняя программа и сейчас является
одной из самых популярных.
Что касается вопросов управления подпиской на файл-эхи, то и тут аналогия
с эхами полная: используется механизм менеджера подписки, аналогичный опи-
санному в предыдущей главе. Имя такого менеджера может быть AllFix, FileFix
или что-нибудь подобное. Конечно, команды менеджера подписки файл-эхопро-
цессора несколько отличаются от команд эхо-менеджера AreaFix, но среди них
есть и схожие.
Кроме рассылки файлов, файл-эхопроцессор обычно выполняет еще дополни-
тельные обязанности, например ведет файловый архив (каждый принятый файл
помещается в файловую базу, надписывается, составляется список всех файлов),
отвечает на нетмейловые запросы о наличии тех или иных файлов, отправляет в ту
или иную эхо-конференцию извещения о полученных файлах и т.п.
Стандарты на пересылку файлов по FidoNet
Правила пересылки и форматы данных для реализации механизма файл-эх описа-
ны в документах FSC-0028 [9.1], FSC-0061 [9.2] и FSC-0087 [9.3]. Самым важным
из них является последний проект стандарта, остальные интересны, скорее, с исто-
рической, чем с практической точки зрения. Дальнейшее изложение основывается
на стандарте FSC-0087 [9.3] и опыте использования программ типа AllFix,
TicManager, Filin.
Терминология
Основные термины описания процесса распространения файл-эх уже использо-
вались и разъяснялись ранее, например: FTN, FQDN, UTC, CRC и некоторые дру-
гие. Если же что-то осталось непонятным, загляните в словарь терминов в прило-
жении 3. Дополнительно к уже известным терминам необходимо ввести еще
несколько:
□ ASSOCIATED FILE («ассоциированный файл», или основной файл) - это
собственно и есть файл, рассылаемый по файл-эхе. Далее будет использовать-
ся термин «основной файл»]
□ TIC («тик», тик-файл) - это информационный файл, сопровождающий каж-
дый рассылаемый по файл-эхе основной файл. Формат тик-файла описан
ниже. Наименование «Т1С» придумал Барри Геллер, автор программы TICK,
которая долгое время была стандартом де-факто для организации файл-эх;
□ HATCH - так называется утилита отправки файла в файл-эху. Она создает
тик-файл и формирует исходящий директорий, ставя нужные файлы (основ-
ной и сопутствующий информационный тик-файл) на отправку. Сам процесс
обычно называют «хатч», «хатчить», «хатчинг» (Hatching);
□ FNC - (F)iIe(N)ame (C)onversion, или преобразование имени файла. Имеет-
ся в виду преобразование на основе стандарта 8.3 MS DOS (8 символов име-
ни и 3 символа расширения). При передаче файл-эх такое преобразование
выполняется автоматически, так как многие узлы в сети не поддерживают
файловые системы, допускающие длинные имена файлов, а минимальный
стандарт (8.3) устраивает всех;
□ PASSTHROUGH - так обозначается режим использования файл-эх, переда-
ваемых даунлинкам без сохранения файлов в локальной файловой базе. Час-
то можно встретить фонетическую кальку «пассру». В данной книге будет
применяться термин «транзитная файл-эха».
Локальная файловая база
Формат файловой базы унаследован еще с тех времен, когда на каждой системе
FidoNet была установлена BBS. Под «базой» в данном случае подразумевается про-
стой способ хранения больших массивов файлов, сопровождаемых минимальной
информацией (обычно не более одной-двух строк описания на каждый хранящийся
файл).
Файловая база устроена следующим образом. Каждая файловая область раз-
мещается в отдельном директории. Наименование директория и строка описания
области хранится в конфигурации программ, используемых для ведения файло-
вой базы (например, того же файл-эхопроцессора). Файлы внутри именованной
файловой области описываются в информационном файле со стандартным назва-
нием files.bbs, лежащим в том же директории, что и сама файловая область, причем
формат описания таков:
<имя файла> <пробел(ы)> <строка описания файла>
Например, строка в files.bbs может выглядеть следующим образом:
NETG4P.ZIP Net Manager (netmail tracker) 1.00 G4
В главе 6, разделе «Процессор файл-эх (файл-эхопроцессор)», был приведен
пример, более подробно описывающий содержимое подобного файла.
Для составления полных списков файловой базы применяют программы, на-
зываемые файл-листерами, а файл-эхопроцессор используется для заполнения
файловой базы, и сам в свою очередь применяет файловую базу при раздаче файл-
эх и для поиска файлов при ответе на поисковые запросы. Под заполнением фай-
ловой базы понимается автоматическое помещение принятых файлов в соответ-
ствующие директории файловой базы и дополнение files.bbs.
Формат Т1С-файла
Прежде чем перейти к описанию ключевых слов, которые могут встретиться в тик-
файле, следует сделать несколько замечаний, необходимых для правильного по-
нимания их возможных значений и смысла:
□ в тик-файле используется адресация в формате от 3D (зона:сеть/узел) и до
5D, а также FQDN вида Йп#зона:сеть/узел.пойнт, где ftn представляет наи-
менование FTN-домена.
Примеры:
-2:5049/12 (3D);
- 2:5049/12@fidonet (5D - предполагается пойнт = 0);
- 2:5049/12.12@fidonet (5D);
- fidonet#2:5049/12.12 (FQDN);
□ все даты в тик-файле должны быть проставлены в UTC;
□ временные метки (дата+время) проставляются в UNIX Time (количество се-
кунд от 1 января 1960 года) в шестнадцатеричном представлении;
□ порядок следования ключевых слов не имеет значения;
□ регистр символов в тик-файле не имеет значения;
□ транзитная система может модифицировать адрес в любом ключевом слове,
чтобы обеспечить соответствие механизму распознавания адреса у своих да-
унлинков;
□ в ключевых словах не должно быть двоеточий;
□ нераспознанные ключевые слова пропускаются;
□ распознанные ключевые слова не должны пропускаться далее по сети: либо
должны обрабатываться, либо (если обработка невозможна) удаляться;
□ большинство ключевых слов при обработке оставляют без изменений, но
некоторые могут заменяться. Ключевые слова, которые должны оставаться
неизменными, отмечены символом л;
□ ключевые слова, наличие которых обязательно, отмечены символом *. Тик-
файл без таких директив помечается как BAD (дефектный), и ассоцииро-
ванный с ним файл не экспортируется даунлинкам;
□ ключевые слова, отмеченные символом #, создаются во время процесса хат-
чинга или форвардинга.
Основные ключевые слова, используемые в TIC-файлах, сведены в табл. 9.1.
На рис. 9.1 приведен пример TIC-файла, использующий некоторые из рассмот-
ренных выше директив (строки SEEN-BY несколько сокращены). По содержимому
можно сказать, что передаваемый файл 5049echo.lst содержит эхо-лист бекбона сети
5049, что он был экспортирован с адреса 2:5049/36 с применением программы
AllFix, что ближайшей системой, с которой файл был получен, оказался узел 2:5049/
96, до которого файл шел по пути 2:5049/36 => 2:5049/30 => 2:5049/19. Полный спи-
сок систем, на которые файл был экспортирован, можно найти в строках SEEN-BY.
Правила передачи файлов при транспорте файл-эх
Для того чтобы избежать появления файлов-«сирот», то есть основных файлов,
TIC-файлы которых утрачены, программное обеспечение при передаче файл-эх
должно выполнять следующие условия:
□ ассоциированный файл, записанный в поле FILE соответствующего TIC-
файла, должен всегда передаваться прежде своего TIC-файла. В противном
случае возможна ситуация, когда переданный в первую очередь TIC-файл бу-
дет квалифицирован как дефектный именно вследствие отсутствия ассоци-
зированного с ним основного файла и перемещен в BADAREA, после чего
дальнейшее распространение по сети файла становится невозможным;
Таблица 9.1. Ключевые слова Т1С-файла
Стандартное написание ключевого слова Параметры Признаки использования Комментарии
AREA [Имя файл-эхи] *# Стандартное название файл-эхи
AREADESC [Описание] Краткое (80 символов) описание файл-эхи
FILE [Имя основного файла] *# Имя посылаемого файла, как правило без пути (РАТИ) и в формате 8.3 MSDOS
FULLNAME [Имя файла до FNC] Л # Оригинальное имя файла до FNC (без PATH)
CRC [CRC-32 в шестнад- цатеричном коде] *# CRC, всего 8 символов
MAGIC [«Магическое» имя] Имя, под которым файл может быть запрошен последством Freq
REPLACES [Имя файла] Имя файла, который необходимо заменить
DESC [Описание файла] # Описание файла (несколько строк), 80 симв. на строку; строка завершается символами ODh OAh
LDESC [Длинное описание файла] # «Длинное» описание файла (не замещает DESC, используется в дополнение к нему)
SIZE [Количество байтов] # Длина файла в байтах
DATE [Временная метка] Дата создания файла
RELEASE [Временная метка] Дата отправки файла
AUTHOR [Имя автора] Имя автора программы, использовавшейся для посылки файла
SOURCE [Адрес автора] Адрес автора программы, использовавшейся при посылке файла. Не обязательно должен совпадать с адресом в ORIGIN. Не обязательно должен быть FTN-адресом
APP [Программа] Это ключевое слово предназначается
[Доп. строка] для программ-обработчиков. [Доп.строка] содержит информацию для этих программ
ORIGIN [FTN Адрес] *# FTN-адрес системы, откуда происходит файл
FROM [Адрес] [Пароль] Л*# Адрес системы, отправившей файл на данную систему. Пароль используется редко, но если есть, то его нельзя отправлять далее
TO [Адрес] л Адрес системы, на которую отправлен данный TIC- и основной файл
CREATED [Кем создан] [Доп. строка] Л*# Программа, создавшая Т1С-файл, и дополнительная информация о ней
VIA [Информация из CREATED] [Доп. информация] Копия информации из CREATED. VIA должно всегда пропускаться неизменным. VIA никогда не создается при хатчинге, только на транзитных станциях
Path [Адрес] [Временная метка] [Дата и время] *# Адрес системы, переправившей файл. Дата и время соответствуют моменту отправки файла
422 Обработка и передача файлов по сети
Таблица 9.1. Ключевые слова TIC-файла (окончание)
Стандартное Параметры написание ключевого слова Признаки Комментарии использования
SEENBY [Адрес] *# Адрес системы,на которую файл был экспортирован. Может быть много строк SEENBY, и они не упорядочены
PW [Пароль] * Пароль системы или файловой области. Регистр не имеет значения, длина по крайней мере 5 символов
е.ехе - AF954023.TIC....... ~ _____ _______________ ___________ _........................ ° □
File Edit Options Help
Area KAZAN.OFFICIAL H
Origin 2:5049/36
From 2:5049/96
File 5049ECHO.LST
Desc Net 5049 backbone echolist
Crc A3CE12D2 [ =1
Created by ALLFIX/2+, v1.11 build 3 Copyright (C) 1992,96 Harms Software Engineering (2:281/415)
Path 2:5049/36 940831878 Mon Oct 25 10:11:18 1999 UTC+0300 HTick/NT v0.02
Path 2:5049/30 940965642 Tue Oct 26 19:20:42 1999 UTC+0000 3822EC31
Path 2:5049/19@fidonet.org 940953096 TUE OCT 26 19:51:36 1999 UTC+0400 84EFAA19
Path 2:5049/96 940968128 Tue Oct 26 20:02:08 1999 UTC+0000 BB2685AE
Seenby 2:5049/36
Seenby 2:5049/30
Seenby 2:5049/19
Seenby 2:5049/78
Seenby 2:5049/47
Seenby 2:5093/20
Seenby 2:5049/70
Seenby 2:5049/63
Seenby 2:5049/80
Seenby 2:5049/36.4
Seenby 2:5049/79
Seenby 2:5049/85
Seenby 2:5049/86
Seenby 2:5049/1
Seenby 2:5049/83
Seenby 2:5049/103
Seenby 2:5049/19.6
Seenby 2:5049/48
Seenby 2:5049/55
Seenby 2:5049/58 ;
Seenby 2:5049/105 p
Pw PassWORD Q
Рис. 9. /. Пример содержимого TIC-файла
из файл-эхи KAZAN. OFFICIAL
□ файл-эхопроцессор должен распознавать переименованные почтовыми програм-
мами ассоциированные файлы (это случается при передаче, если на приемной
стороне уже есть файл с таким именем). В случае обнаружения такого файла при
неизменной его длине и CRC должны вноситься изменения в TIC-файл (обычно
переименование касается только последнего символа расширения);
□ файл-эхопроцессор должен всегда удалять неотосланные TIC-файлы, если
взамен них в очередь отправки ставится тот же самый файл или его новая
версия. Возможные исключения (например, периодическая посылка ноде-
диффов не допускает подобной замены) должны специально конфигуриро-
ваться сисопом.
Функции файл-эхопроцессора
Кроме своего основного назначения - распространения файлов по сети - файл-
эхопроцессор обычно выполняет и много других обязанностей. Разные файл-
эхопроцессоры имеют различные наборы таких функций; из известных программ
наибольшее количество приходится на долю AllFix, у которого «всеохватность»
закреплена даже в названии (all - «все»). Основные же функции можно свести
к следующим:
□ посылка файлов даунлинкам с формированием соответствующих Т1С-файлов;
□ передача даунлинкам файлов, принимаемых от аплинка(ов), с модификаци-
ей принятых Т1С-файлов;
□ заполнение локальной файловой базы на основе файл-эх;
□ работа менеджера подписки, ответы на запросы даунлинков по управлению
подпиской;
□ выполнение транзитной подписки (при отсутствии запрашиваемой файл-эхи
на данной системе производится автоматический запрос ее у аплинка);
□ выполнение поиска файлов в локальной файловой базе в ответ на запросы в эхах,
сконфигурированных как поисковые, и посылка ответных писем (нетмейлом
или в те же эхи);
□ извещение даунлинков нетмейлом и в эхах о новых файлах, появляющихся
на системе.
Настройка и использование
файл-эхопроцессора
Настройка файл-эхопроцессора имеет много общего с настройкой тоссера: логика
совершенно такая же. Если не обращать внимание на детали, вся процедура со-
стоит из следующих этапов:
1. Настройка адресной информации.
2. Указание используемых директориев (inbound/outbound и т.п.).
3. Заполнение списка линков, определение паролей, прав доступа.
4. Заполнение списка файл-эх с указанием директориев для хранения файлов
(если файл-эха нетранзитная).
5. Определение подписки для каждой файл-эхи (если это необходимо, обычно
линки подписываются сами).
6. Настройка анонсов о новых эхах, сервера поиска файлов и т.п.
Сам процесс настройки здесь будет рассмотрен конспективно на примере двух
программ, кардинально различающихся в подходе к конфигурации. AllFix сущест-
вует в версиях для MS DOS и OS/2 и предоставляет пользователю развитый меню-
интерфейс для конфигурирования. Она очень популярна и применяется на мно-
жестве систем, но это условно-бесплатная (shareware) программа и использование
ее без регистрации и оплаты незаконно.
Существует много бесплатных файл-эхопроцессоров, имеющих подсистему
конфигурации, основанную на текстовых конфигурационных файлах. Конфигу-
рировать их не сложнее, чем AllFix, и обычно они гораздо компактнее и неплохо
работают. Представителем этого класса файл-эхопроцессоров является TicMana-
ger, разработанный Александром Токаревым из Тюмени (2:5077/27@fidonet).
Системная информация и определение директориев
В этом разделе конфигурации нужно определить:
□ основной адрес системы (он будет использоваться для выделения писем менед-
жеру подписки, с него будут рассылаться сообщения об ошибках и анонсы но-
вых файлов и т.д). Этот адрес проставляется в строки PATH и VIA TIC-файлов;
□ информацию о системе (название, местоположение и т.п.) - может исполь-
зоваться в шаблонах писем, которые, в свою очередь, применяются для гене-
рации нетмейл-ответов;
□ все необходимые директории, включая входной (inbound) и выходной (out-
bound);
□ список аплинков - с их помощью будет производиться автоматическая под-
писка на файловые конференции, отсутствующие на узле (при запросах да-
унлинков).
При конфигурации списка директориев, кроме уже привычных NETMAIL/
INBOUND/OUTBOUND и т.п., нужно задать директорий для хранения Т1С-файлов,
директорий для хранения TIC-файлов, распознанных как дефектные (BAD-
TICS), и связанных с ними файлов.
Общие параметры эхо-процессора
Глобальные параметры определяются для каждого файл-эхопроцессора, но раз-
личий здесь больше, чем сходства. Обычно определяются следующие общие па-
раметры:
□ минимальный размер свободного места на диске, при котором обработыва-
ется входной поток файл-эх;
□ формат выходного директория (АМА или BSO) и/или тип используемого
мейлера;
□ формат формируемых нетмейл-сообщений (тип почтового пакета);
□ формат даты;
□ максимальный размер обрабатываемых *.msg файлов;
□ формат лог-файла и детальность вывода в него;
□ сдвиг от UTC (если не используется переменная окружения TZ);
□ список наименований файлов, которые необходимо исключить из отчетнос-
ти (это могут быть, например, files.bbs);
□ список эхо-областей, откуда принимаются запросы на поиск файлов.
Группы файл-эх
Концепция групп, используемая при администрировании больших массивов
пользователей или конференций, уже знакома по группам эхо-конференций, опи-
санным в предыдущей главе. При описании файловых эхо-конференций также
часто используются подобный метод.
На рис. 9.2 изображена форма описания группы в программе asetup.exe, приме-
няемой при конфигурации AllFix. Она вызывается выбором из основного меню
asetup.exe позиций Fileecho system => Group manager.
Здесь GROUP - цифровой идентификатор группы, NAME - название группы,
MASK - маска, которая используется для определения, к какой группе отнести
новую файл-эху. Определение принадлезжности производится по наименова-
нию файл-эхи. В описанном случае все новые файл-эхи, эхотаг которых начина-
ется с kazan, будут отнесены к данной группе.
Параметр UNIQUE определяет, будет ли создаваться новый директорий для
каждой добавляемой файл-эхи или же все файл-эхи данной группы должны нахо-
диться в одном директории.
Параметры ADD BBS и BBS MASK позволяют производить добавление файл-
эх с учетом структуры файловых областей конкретных BBS-программ.
Параметры в нижней части формы описаны в следующем разделе, они исполь-
зуются при автосоздании файл-эх.
MiBBiiiiiiiiiiiiiiiiiiiiiiiiiB
ALLFIX/2 for OS/2 Warp, vl.ll build 3 setup program 2:5049/12
Name
Mask
Oesc
Best
Keep й
Template
Banner
Advanced
Max days
Systems
0
Kazan file echoes
KAZAN*
[defaults for auto-added fileechos in this group]
Kazan file echo , '
D:\ARCHIVE\ALLFIXXKAZAN\ <
BANNER
Use aka
LongDesc
Cost
2:5049/12
Normal
o HUH
2:5049/49
Max size
[0
Max file
Unique
Add BBS
BBS Mask
0
0
Enter-edit Insert Delete F2-global F3-advanced F4-find F5-browse F6-copy
Рис. 9.2. Форма редактирования параметров группы файл-эх
в программе asetup.exe
При конфигурации TicManager применяется отдельный файл конфигурации
групп с названием group.cfg. На рис. 9.3 приведен пример описания с коммен-
тариями группы в этом файле.
В конфигурации TicManager под флагами понимаются расширенные атрибуты
или флейворы, которые используются при посылке файлов.
Необходимо отметить, что TicManager имеет значительно расширенный спи-
сок возможных атрибутов (стилей) отправки файлов и писем, описание которых
в документации программы занимает не одну страницу и не вполне соответствует
описанным ранее (например, почтовым атрибутам, приведенным в начале главы 7).
Но большиство стандартных атрибутов (таких как, например, HOLD, DIRECT,
CRASH, IMMEDIATE и т.п.) входит в состав возможных флагов TicManager.
Подсистема описания файл-эх
Описание файл-эх для систем с текстовыми конфигурационными файлами вроде
TicManager обычно помещается в отдельный файл, а в меню-управляемых кон-
фигурационных программах (такая используется в AllFix и называется asetup.exe)
для этого выделяется отдельная система меню. На рис. 9.4 изображена форма
редактирования параметров отдельной файловой эхо-конференции, вызываемая
из основного меню Asetup.
е.ехе -GROUP,CFG
File Edit Options Help
111И
Определения групп областей (Area groups definitions)
Каждое определение группы представляет из себя список параметров,
расположенных в произвольном порядке. Примерный вид определения:
Group GROUP_LETTER <- Буква-идентификатор группы.
Directory GROUP_DIR <- Путь к директории, где будут создаваться поддиректории с областями
Description Echo description <- Описание области, которое будет подставлено в случае отсутствия такового в Т1С-файле
Uplinks 2:5077/28.0
Downlinks 2:5077/27.10
AKA 2:5077/27
Flags
В
Transi tFlags
►В
ReceiveSecurity 100
PostSecurity 1000
Semaphore echo_name.flg
LongDirNames Yes|No
EndGroup
< - Список аплинков по умолчанию для областей этой группы
< - Список даунлинков по умолчанию для областей данной группы
< - Адрес, используемый в областях данной группы.
< - Флаги областей данной группы.
< - Флаги для областей, создающихся транзитом при запросах даунлинков
< - Приоритет узла, необходимый для получения файлов в области этой группы
< - Приоритет узла, необходимый для отправления файлов в область этой группы
< - Необязательный параметр, указывающий имя флаг-файла, создаваемого при приходе файлов
в области этой группы
< - Переключатель, определяющий имя директории при создании новой области в этой группе
По умолчанию (если отсутствует) выключено
< - Каждое определение должно заканчиваться так
Группа 'DEFAULT' обязательно
должна быть первой !
Group Default
Directory D:XARCHIVE
Description Description not available
Uplinks
Downlinks 2:5049/30.0 2:5049/36.0 2:5049/96.0 2:5049/19.0 2:5049/8.0
AKA
Flags
В + L
TransitFlags +H +B
ReceiveSecurity 100
PostSecurity 1000
Semaphore
LongDirNames No
EndGroup
Group A
Directory D:\ARCHIVEXTICMANXKAZAN
> Description Kazan fillechos
: Uplinks 2: 5049/19. 0
: Downlinks 2:5049/30.0 2:5049/36.0 2:5049/96.0 2:5049/19.0 2:5049/8.0
AKA 2:5049/12
Flags +H +B +L +A +U +J
TransitFlags +H +B +L +A +U +J
ReceiveSecurity 100
PostSecurity 1000
Semaphore
LongDirNames Yes
EndGroup
Д. asetup.exe
ALLFIX/2 for OS/2 Warp, vl.ll build 3 setup program
Copyright
2:5049/12
(C) 1992,96 by Harms Software Eng., All rights reserved. Fl=Help
Bl
Tag
Deso
Dest
Group
Keep it
Template
Banner
Advanced
Max days
Systems
[KAZAN. FI LES
Kazan file echo
D:\ARCHIVE\ALLFIX\KAZAN.INF\
Kazan file echoes
BANNER
Use aka
LongDesc
Cost
2:5049/12
Normal
о имтаижмямиг
2:5049/2 8 12.14 .22
Max size
40 *43
.46
Max file
P
.52 .98 17 18 38 40 96 108
0
0
P
Enter-edit Insert Delete F2-global F3-advanced F4-find F5-browse F6-copy
Рис. 9.4. Форма для ввода параметров отдельной файловой эхо-конференции
в программе asetup.exe
Здесь, кроме основных параметров: стандартного наименования файл-эхи
(поле TAG), ее описания (DESC), директория для хранения файлов, приходящих
по файл-эхе (DEST); группы, к которой принадлежит данная файл-эха (GROUP);
используемого адреса (USE AKA), - есть и менее очевидные:
□ KEEP # - количество файлов, которые могут находиться в данном директории
(О - не обращать внимания);
□ LONGDESC - определяет формат Long Description (см. описание формата
Т1С-файла);
□ TEMPLATE - определяет какой файл-шаблон использовать с данной файл-
эхой при посылке файлов даунлинкам (на рис. 9.5 показано меню, которое
появляется при выборе этого пункта);
□ BANNER - название файла-шаблона, который допаковывается в пересыла-
емые по файл-эхе архивы в качестве заголовка архива;
□ MAX DAYS/MAX SIZE/МАХ FILE - максимальный возраст, размер в кило-
байтах, количество файлов, которое может содержать данная файл-эха;
□ SYSTEMS - список подписки даунлинков на данную файл-эху. На рис. 9.6
изображено подменю редактирования этого списка, а на рис. 9.7 - форма для
редактирования параметров даунлинка, вызываемая из этого меню. Здесь
определяется, можно ли посылать даунлинку файлы или принимать их от него,
не остановлена ли для него подписка (Pause), а также другие параметры.
Следует также обратить внимание на дополнительные удобства, предоставля-
емые интерфейсом asetup.exe (нижняя строка-подсказка на экране, рис. 9.4). С его
помощью можно выводить список файл-эх, производить глобальную замену, поиск
ft' asetup.exe| о |о|
ALLFIX/2 for OS/2 Warp, vl.ll build 3 setup program
2:5049/12
Copyright (C) 1992,96 by Harms Software Eng., All rights reserved. Fl^Help
Template
Size
(None)
Kazan fi
jBANNER
0
0
0
2:5049/2 8 12
|KAZAN»FILES
iKazan file ech
D:\ARCHIVE\ALL
E-Edit View Insert Delete 11
Рис. 9.5. Подменю Template формы для ввода параметров файл-конференции
в программе asetup.exe
T ag
Desc
Dest
Group
Keep Й
Template
Banner
Advanced
Max days
Systems
AREAMGR
BANNER
BILL
FILEFIND
LIST
MESSAGE
NOTIFY
OUERY
REPORTS
STATUS
STOP
UNLINKED
WARNING
1972
1668
1674
761
1239
796
3047
2434
1051
873
372
1668
413
149/12
al
Max file
98 17 18 38 40 96 108
0
asetup.exe j ° jo
ALLFIX/2 for OS/2 Warp, vl.ll build 3 setup program 2:5049/12
Copyright (C) 1992,96 by Harms Software Eng., All rights reserved. Fl=Help
Insert Delete 11
Рис. 9.6. Подменю Systems формы для ввода параметров файл-конференции
в программе asetup.exe
и т.п., что значительно упрощает непростую задачу администрирования файл-эх
для AllFix.
Описание областей файловых эхо-конференций в программе TicManager
организовано иначе; здесь вся информация помещается в один текстовый файл
с именем areas.cfg, примерный вид которого приведен на рис. 9.8 с комментариями
автора программы (подробнее см. в поставке программы).
S asetup.exe| q |iai|
ALLFIX/2 for OS/2 Warp, vl.ll build 3 setup program 2:5049/12
Copyright (C) 1992,96 by Harms Software Eng., All rights reserved. Fl=Help
Desc
Best
Group
Keep й
Template
Banner
Advanced
Max days
Systems
Й Status Node address
SysOp
Send files
Receive files
PreRelease
Mandatory
Msg status
2:5049/96
Eugene Kurilny
YesiiieiSiS
13 S—S-- 2:5049/40
14 SR-S-- 2:5049/96
15 S—2:5649/108
96 108
The Address of for this system
Рис. 9.7. Форма редактирования параметров даунлинка в программе asetup.exe
5£J е.ехе - AREAS.CFG
File Edit Options Help
- □
=============== Определения областей (Areas definition) =====================
Каждое определение области представляет из себя список параметров, расположенных
в произвольном порядке. Примерный вид определения:
FileEcho ECHO_NAME
Directory ECHO_DIR <-
Description Echo description <-
Uplinks 2:5077/28.0 <-
Downlinks 2:5077/27.10 <-
AKA 2:5077/27.0 <-
Group N <-
Flags +H +B +P +A <_
ReceiveSecurity 100 <-
PostSecurity 1000 <-
Semaphore echo_name.flg <-
EndFileEcho
Имя области.
Путь к директории, где расположены файлы.
Описание области.
Список аплинков для данной области.
Список даунлинков для данной области.
Адрес, используемый в данной области.
Группа, к которой принадлежит данная область.
Флаги области.
Приоритет узла, необходимый для получения
файлов в этой области.
Приоритет узла, необходимый для отправления
файлов в эту область.
Необязательный параметр, указывающий имя
флаг-файла, создаваемого при приходе файлов
в эту область.
Каждое определение должно заканчиваться так.
================ TicManager/2 Filearea entry ==
FileEcho KAZAN.OFFICIAL
Directory D:\ARCHIVE\TICMAN\KAZAN\KAZAN.OFF
Description Kazan official info
Uplinks 2:5049/19 2:5049/96
Downlinks 2:5049/30.0 2:5049/36.0 2:5049/96.0 2:5049/19.0 2:5049/8.0
AKA 2:5049/12
Group A
Flags +H +0 +P +H +A +L +U
ReceiveSecurity 100
PostSecurity 1000
EndFileEcho
Рис. 9.8. Пример файла описания областей areas.cfg программы TicManager
Магические имена файлов
Магические имена (Magic Names) используются в настройке мейлеров для удоб-
ства запроса файлов с системы. Например, вместо того чтобы запрашивать спи-
сок файлов (таких, как файл ddall233.zip, в котором содержится список файлов,
хранящихся на моем узле), пользователь может запросить тот же файл по маги-
ческому имени FILES, что, конечно же, очень удобно.
Файл эхо-процессор может автоматически дополнять базу магических имен, по-
скольку с каждым файлом в TIC-файле может быть передано и его магическое имя.
Иногда термин магическое имя используется при вызове внешних программ для
обработки полученных файлов, например, такая возможность есть в AllFix.
На рис. 9.9 изображена форма ввода для описания действия по получению фай-
ла в менеджере магических имен, вызываемого из основного меню asetup.exe при
выборе Fileecho system Magic file names. На рисунке изображено также подме-
ню выбора действия, которое необходимо произвести над файлом. Это меню вызы-
вается при выборе позиции TYPE в форме ввода.
В изображенной на рисунке ситуации при получении любого файла, имя ко-
торого начинается с nodediff, он скопируется в указанный директорий.
Подсистема описания линков
В подсистеме описания линков файл-эхопроцессора нет ничего необычного и но-
вого; она напоминает ту, которая используется для эхо-процессора (его конфи-
гурирование подробно рассматривалось в предыдущей главе). Остановимся на
отличиях, специфичных именно для файл-эхопроцессора. На рис. 9.10 изобра-
жена форма ввода описания линка в программе asetup.exe.
Рис. 9.9. Форма ввода данных в менеджере магических имен программы asetup.exe
Д asetup.exe
ALLFIX/2 for OS/2 Warp, vl.ll build 3 setup program
ДДД||Д1||Д|Д
System
Sysop
Holding directory
Route via
Authorized groups
Fileecho password
AreaMgr password
Use aka
File attach status
Other mail status
TIC file mode
Packing mode
Compression type
Advanced options
Cost sharing options
2:5049/12
Fl=Help
Enter-edit Insert Delete F2-global edit F3-defaults F4-find F5-browse F6-copy
Рис. 9.10. Форма ввода для описания линка в программе asetup.exe
В форме, кроме имени сисопа и его адреса, указываются:
□ Authorized Groups - группы, доступ к которым разрешен для данного линка
(в приведенном на рисунке случае разрешен доступ к группам 0, 1,2, 3);
□ Holding Directory - директорий, в который копируются все файлы для
данного линка (это сделано для локальной, без использования FidoNet,
раздачи файл-эх. Например, все файлы могут копироваться на файл-сервер
в директорий данного пользователя. В этом случае на отправку мейлером
они не ставятся);
□ Fileecho Pass word/ Areamgr Password - пароли для получения файл-эх и для
управления подпиской, соответственно;
□ Use AKA - адрес, используемый при работе с данным линком (в изобра-
женном на рисунке случае используется глобальный параметр);
□ File Attach Status - атрибут письма с прикрепленным файлом (или флейвор,
в случае Bink-Style outbound);
□ Other Mail Status - аналогичный параметр для всей остальной переписки
с данным линком;
□ TIC File Mode - режим использования TIC-файлов, принимает значения:
- Normal TIC File (обычный TIC-файл);
- Advanced TIC File (новый формат TIC-файла, этот формат был предложен
автором AllFix);
- None - не посылать Т1С-файл;
□ Packing Mode - режим упаковки TIC-файлов с использованием внешних
архиваторов (можно паковать TIC-файлы, паковать все файлы или не пако-
вать ничего);
□ Compression Туре - тип внешнего архиватора, используемый при упаковке
Т1С-файлов;
□ Costsharing Options - используется при совместной оплате транспорта файл-эх.
Отдельно на рис. 9.11 изображено меню, появляющееся при выборе Advanced
options.
В этом меню можно включить/выключить подписку для данного линка (позиция
INACTIVE), позволить создавать файл-эхи от него (Allow Auto-Add), разрешить уда-
ленное управление (Remote Maintenance) и задать некоторые другие параметры.
Следует обратить внимание на дополнительные удобства, которые предоста-
вляет меню-интерфейс при редактировании списка линков (см. нижнюю строку-
подсказку на рис. 9.10). Можно выбирать нужный узел из списка (клавиша F5,
режим BROWSE), копировать карточку линка (F6), выполнять поиск (F4), задавать
значения по умолчанию для всех параметров формы (F3) и производить глобаль-
ную замену параметров сразу для всех линков (F2), что чрезвычайно удобно в ис-
пользовании и серьезно упрощает администрирование системы файл-эх для AllFix.
В программе TicManager список линков и их параметры определяются в фай-
ле links.cfg. Содержимое этого файла с авторскими комментариями приведено на
рис. 9.12. Смысл используемых параметров следующий (использованы опреде-
ления из описания программы):
□ NodeDef- адрес узла, желательно 4D;
□ SysopName - имя сисопа. Используется для создания извещений и справок
при вызове из командной строки;
asetup.exe \ ° Ы
ALLFIX/2 for OS/2 Warp, vl.ll build 3 setup program 2:5049/12
If this system is temporarily inactive
Рис. 9.11. Подменю Advanced options в форме описания линка
программы asetup.exe
е.ехе - links.cfg
File Edit Options Help
; NodeDef <адрес>
; [SysopName:
; [Password:
; [MgrPassword:
; Groups:
; Flags:
; AKA:
; [Robot:
; [Arealist:
; [CreateGroup:
; [Archiver:
; PackType:
; [PackExtension:
; [MaxBundle:
; Security:
; EndNodeDef
[имя сисопа]]
[пароль]]
[пароль]]
<группа(ы)>
[флаги]
[адрес]
[имя робота]]
[путь и/или имя файла -- списка областей]]
<группа>]
[архиватор]]
<None| ТIС1 АН>
<AllfixNew|AllfixOldlTicMan|маска>]
<наибольший размер архива>]
<приоритет узла>
• ВНИМАНИЕ! В LINKS.CFG ВСЕГДА НА ПЕРВОМ МЕСТЕ ДОЛЖНО НАХОДИТЬСЯ ОПРЕДЕЛЕНИЕ УЗЛА DEFAULT!
NodeDeF DEFAULT
SysopName: System Operator
Password:
Groups: NLT
Flags: +H +B +R +V
Robot: Filemgr
Arealist:
CreateGroup: A
Archiver: ZIP
PackType: None
PackExtension: TicMan
MaxBundle: О
Security: 100
PersonalBox:
EndNodeDeF
NodeDeF 2:5049/12.12
SysopName:
Password:
Groups:
Flags:
Robot:
Arealist:
CreateGroup: A
PackType: None
Security: 65535
EndNodeDef
Amirko Shaab
PASSBOPD
ABC
+C +B +A -0 -L +W -P +E +V
Allfix
D:\ARCHIVE\TICMAN\1212.FILES
Complete.
Рис. 9.12. Пример конфигурационного файла links.cfg
с описанием линков для программы TicManager
□ Password - необязательный пароль. Используется в Т1С-файлах;
□ MgrPassword - необязательный пароль. Используется при обработке писем
к менеджеру подписки FileMgr. Если поле Password задано, a MgrPassword -
нет, то будет считаться, что пароль один и совпадает с Password;
□ Groups - список групп, разрешенных узлу для подписки. Если в этом списке
есть символ *, то вместо него при обработке подставится поле Groups узла
Default;
□ Flags - список флагов узла (см. ниже);
□ АКА - адрес, который будет использован для данного узла. Если отсутствует,
то используемый адрес определяется по настройкам области;
□ Robot - имя файлового робота, стоящего на этом узле. Имеет смысл в том
случае, если для этого узла разрешена транзитная подписка;
□ AreaList - путь и/или имя файла со списком областей. Список должен быть
в формате <areaname> <areadesc>. Имеет смысл в том случае, если для
узла разрешена транзитная подписка; используется для выполнения такой
подписки;
□ CreateGroup - группа, которая будет присвоена каждой области, автомати-
чески созданной с этого узла;
□ Archiver - архиватор, используемый для упаковки файлов для этого узла.
Должен быть одним из пунктов списка, определенного в compress.cfg;
□ PACKTYPE - метод упаковки, применяемый для данного узла. Используют-
ся значения:
- NONE - не пакуется вообще ничего;
- TIC - пакуются только Т1С-файлы;
- ALL - пакуется все подряд;
□ PackExtension - расширение, присваиваемое архивам с файлами для данного
узла. Представляет собой маску вида ABCD##, где ABCD - символы, оста-
ющиеся неизменными, и # - символы, вместо которых будет подставлен
порядковый номер. Длина расширения не ограничена, количество # не огра-
ничено, ограничений на позиции # нет, нумерация идет по принципу 0-9,
А-Z. Вместо маски можно использовать жестко определенные слова:
- ALLFIXNEW - маска С##;
- ALLFIXOLD - маска Z#C;
- TICMAN - маска ТМ#;
□ MaxBundle - максимальный размер одного архива с файлами для данного
узла. Файлы пакуются по одному. Если размер архива превышает данное зна-
чение, создается новый архив. При MaxBundle равном 0 проверка размера
архива не производится и все файлы пакуются за один раз в один архив;
□ Security - приоритет узла;
□ EndNodeDef- обязательное слово, означающее конец определения.
Подписываемся на файл-эхи
Менеджер подписки («откликающийся» по сетевой почте на имя FileFix, AllFix
и т.п.) представляет собой программный компонент, обычно интегрированный
в основной модуль программы. Он используется для управления подпиской по-
средством нетмейл-писем специального формата. В этом разделе будут при-
ведены синтаксис запросов к менеджеру и его конфигурирование.
Ниже перечислен комментированный список команд менеджера подписки
программы AllFix (имя самого менеджера, по которому к нему следует обра-
щаться в письмах, также AllFix, если иное не указано в конфигурации).
AllFix обрабатывает письма, адресованные на основной адрес, указанный в кон-
фигурации, для AllFix или для любого другого имени, определенного в строках
формы ввода AreaMgr options под заголовком AreaMgr recognition strings
(рис. 9.13). Эта форма вызывается из корневого меню программы Asetup выбором:
System Data => Miscellaneous => AreaMgr options
Обрабатываемые письма должны происходить с одного из адресов, указанных
в подсистеме конфигурации линков (выбор основного меню asetup.exe Node
Manager). В поле SUBJECT письма должен присутствовать пароль, указанный
в конфигурационной карточке для данного линка.
В теле письма могут встречаться команды, сведенные в табл. 9.2.
asetup.exe____ , - ': ' \ \ : ,< '''
ALLFIX/2 for OS/2 Warp, vl'11 build 3 setup program
Copyright J
„ Allow
Allow
Allow
Allow
String
String
String
String
String
Keep receipts
Auto-add nodes
Public groups
[AreaMgr
1
2
3
4
5
^NOTIFY
^PASSWORD
^ECHOPASSWORD
&PACK
No .
No L
0. .3
Allow ^MESSAGE
Allow ^COMPRESSION
Allow VICK
Allow fcPAUSE
, Keep requests :
recognition strings]
RAID
FILEMGR
FILEFIX
2:5049/12
d. Fl=Help
If nodes are allowed to use VALL to connect all available areas
Рис. 9.13. Форма ввода параметров менеджера подписки
Вместо размещения команд в теле письма, можно писать их однобуквенные
эквиваленты в поле SUBJECT непосредственно после пароля, предваряя симво-
лом - (тире). Здесь можно использовать -Q, -L, -Н, или -U, что соответственно
эквивалентно %QUERY, %LIST, %HELP, %UNLINKED.
Пример такого письма изображен на рис. 9.14.
Конфигурирование менеджера подписки осуществляется заполнением формы
ввода, изображенной на рис. 9.13. Здесь можно разрешить или запретить для поль-
зователей те или иные команды менеджера, подписку на группы файл-эх и т.п.
Дополнительно для каждого даунлинка конфигурируются отдельные парамет-
ры в его персональной карточке (рис. 9.10 и 9.11).
Рис. 9.14. Пример письма-запроса с размещением команд
менеджеру подписки в заголовке письма
436 Обработка и передача файлов по сети
Команда Описание
+ <Наименование файл-эхи> - <Наименование файл-эхи> %H[ELP] %L[IST] %Q[UERY] %U[NLINKED] %P[ASSWORD] %-[ALL] %+[ALL] %+[GROUP] %-[GROUP] %C[OMPRESSION]= %NOTIFY=[On/Off] Подписаться на указанную файл-эху Отписаться от указанной файл-эхи Получить подсказку по командам менеджера подписки AllFix Запросить список всех возможных для подписки файл-эх Запросить список подписки Запросить список файл-эх, на которые нет подписки Сменить пароль менеджера подписки Отписаться сразу от всех файл-эх Подписаться сразу на все файл-эхи Подписаться на файл-эхи группы GROUP Отписаться от файл-эх группы GROUP Выбрать тип архиватора (ARC, ARJ, LZH, РАК, ZIP, или SQZ) Включить (On) или выключить (Off) функцию посылки извещений (Notifications) для вашей системы
%MESSAGE=[On/Off] Включить (On) или выключить (Off) функцию посылки сообщений (Messages) для вашей системы
%TICK=[On/Off] Включить (On) или выключить (Off) функцию посылки Tic-файлов для вашей системы
%STATUS Запросить отчет о конфигурации вашей системы (состояние переключателей Notify, Message и т.п.)
%RESEND [имя файла] %PAUSE %RESUME %FROM [адрес] Заново послать вам файл [имя файла] Временно (до подачи команды %RESUME) приостановить подписку Включить подписку для всех неактивных файловых областей Удаленное управление (все команды воспринимаются как посланные от имени системы с адресом [адрес]. Эта команда доступна только в зарегистрированной версии)
[-] Ниже Tearline все будет пропущено
Команды менеджера подписки файл-эхопроцессора TicManager аналогичны
описанным для AllFix. Добавлена команда %AVAIL, по которой выдается список
файл-конференций, доступных по запросам с аплинков данной системы. Менеджер
подписки для TicManager по умолчанию называется filemgr. В отличие от AllFix
здесь очень гибко, с использованием специальных шаблонов, конфигурируются
ответы на письма менеджеру подписки.
«Плохие» файлы и их Т1С-файлы
При задании директориев для файл-эхопроцессора нужно указать местоположе-
ние директория, предназначенного для дефектных файлов и сопровождающих их
Т1С-файлов.
Позаботьтесь, чтобы на диске, где располагаются эти директории, было достаточ-
но места, для чего время от времени проверяйте, не забиты ли они Т1С-файлами
и ассоциированными с ними бинарными архивами. Если это случилось, значит,
необходимо разобраться, почему так произошло. В этом вам поможет файл bad-
tics.log, находящийся в том же директории, что и «плохие» тик-файлы. В нем ука-
заны причины, по которым файлы признаны дефектными - чаще всего это изме-
ненный CRC. Это не всегда означает, что основные файлы были испорчены, CRC
(и файл) может быть изменен и без порчи самого архива. Для исправления лучше
всего пересчитать новый CRC с использованием специальной утилиты (утилиту
для расчета CRC-32 нетрудно найти для любой операционной системы), записать
новый CRC в соответствующий TIC-файл и обработать badtics-директорий, вы-
звав файл-эхопроцессор в режиме обработки badtics. Для AllFix это делается так:
AllFix.exe File -TossBad
Для TicManager соответствующая командная строка может выглядеть так:
Ticman.exe Toss -В
Менее трудоемкий способ заключается в вызове тик-процессора в режиме без
контроля CRC:
AllFix.exe File -NoCrc
или для TicManager:
Ticman.exe Toss -С
Однако этот путь таит скрытые опасности, так как вполне возможно отправить
таким образом даунлинкам дефектные файлы.
Использование шаблонов писем
Файл-эхопроцессор может генерировать большое количество различных нет-
мейл-писем. Это и анонсы новых файл-эх, и ответы менеджера подписки, и пись-
ма-ответы на поисковые запросы, и многое другое. Чтобы сисоп мог оформить
свои варианты таких писем-ответов, была разработана система шаблонов писем,
называемых темплейтами (template). Шаблон представляет собой текстовый
файл, который вставляется в письмо перед его отсылкой. В шаблоне могут исполь-
зоваться макропеременные, которые при формировании письма заменяются на те
или иные параметры, взятые из конфигурации файл-эхопроцессора. Это могут
быть и наименования файл-эх, и адрес, и имя сисопа, которому предназначено
письмо, и другая аналогичная информация.
AllFix в своей утилите конфигурации, asetup.exe, имеет отдельную подсистему со-
здания файлов-шаблонов, хотя это можно делать с использованием любого тексто-
вого редактора, который не вставляет в текст ненужную техническую информацию.
На рис. 9.15 приведен «моментальный снимок» меню вызова редактора шаб-
лонов, находящееся в меню asetup.exe, по пути:
Utilites => Template editor
На рис. 9.16 изображен примерный вид содержимого файла шаблона; данный
шаблон называется filefind и предназначен для ответа на поисковое письмо,
в котором содержится запрос на поиск файла. Для этого нужно адресовать пись-
мо на имя AllFix и в поле SUBJECT письма поместить поисковую строчку с име-
нем файла (или с частью имени, с использованием метасимволов * или ?, на-
пример: NODEDIFF*.2??)
Рис. 9.15. Меню вызова редактора шаблонов писем в программе asetup.exe
Используемые в этом шаблоне макропеременные (они все начинаются с сим-
вола @) при посылке письма будут заменены именем сисопа, названием станции,
подставлены нужные адреса и т.п. Все эти мелочи хорошо описаны в документации
на AllFix. Заметим, что тщательная разработка теста шаблонов позволяет улучшить
взаимодействие пользователей с файл-эхопроцессором. Использование только
входящих в поставку англоязычных шаблонов без какой-либо их модификации
вполне возможно, но не является общепринятой практикой.
TicManager также имеет развитую подсистему файлов-шаблонов, модифици-
руемых с помощью любого текстового редактора, выдающего «чистый» текст без
символов форматирования.
Запуск процессора файл-эх
По традиции нужный режим при запуске процессора файл-эх выбирается клю-
чами командной строки. Это самый удобный и простой способ.
Параметры командной строки можно условно разделить на основные, опреде-
ляющие режим, в котором будет работать программа (TOSS, STAT, SEND и тому
подобные), и вспомогательные, в функцию которых входит дополнительное кон-
фигурирование программы при вызове (проверять ли CRC файлов, обрабатывать
ли директорий BADTICS и т.п.). Обычно основные параметры записываются
в командной строке сразу после названия программы, а вспомогательные - вслед
за основными через дефис, например:
C:\FIDO\TICM\Ticman.exe TOSS -В -D
Рассмотрим основные режимы запуска на примере TicManager (у AllFix они
в основном аналогичны).
® е.ехе - FILEFIND. APL ]*]□
File Edit Options Help
; Template file: FILEFIND.APL ; Type : FileFind ; This template generates a list of files matching a FileFind request Found at : ©systemname Telephone : ©phonelinel Address : ©akatouse @setofIimit (4) ©areabegin Area : ©fileecho
@filebegin @j ust (©filename,L,13)@j ust(@fiI esize, R, 9) ©copy(@filedesc, 1, 53) ©overflow @end
@just (@blockbytes,L,11) bytes in @just (@blockfiles,L,3) file(s) @end | Total of ©totalbytes in ©totalfiles file(s) This list was created with the macro language in ALLFIX/2 ©prgversion Cheers, ©copy (©sysopname,1,@pos (@sysopname," ")) J
U J Ju
Рис. 9.16. Файл-шаблон письма для создания ответа на поисковый запрос
TOSS. Эта директива заставляет TicManager искать во входном директории
пришедшие файлы и обрабатывать их.
Синтаксис:
Ticman.exe TOSS <параметры>
Параметры:
В - обработать заново TIC-файлы из BADTICS;
S - запретить любые проверки паролей, уровней доступа и т.п.;
С - запретить проверку CRC32 пришедших файлов;
U - запретить проверку на дупы;
N - отменить сортировку тиков при тоссинге;
D - проверять наличие в директориях dir.bbs и создавать их, если потребуется;
F - проверять наличие в директориях files.bbs и создавать их, если потребуется;
А - создавать отчет об обработанных файлах сразу после обработки команды;
Q - запретить вывод на экран любых сообщений.
Пример:
Ticman.exe TOSS -В -F
SEND. Эта директива дает распоряжение послать файл в нужную область. Мож-
но указывать имена файлов, содержащие пробелы. В таком случае имя файла не-
обходимо заключать в двойные кавычки. То есть, например, можно написать:
"С:\мой любимый файл"
Синтаксис:
Ticman.exe SEND <NAME> <AREA> <параметры>
где:
NAME - путь и имя файла. Путь обязателен. Можно указывать имена файлов,
содержащие пробелы. В таком случае имя файла необходимо заключать в двой-
ные кавычки;
AREA - куда файл отсылается.
Эти два параметра обязательны и выполняются только, в такой последователь-
ности.
Параметры:
DDSC - описание файла, одна строка с пробелами, замененными на символ
подчеркивания _. Если строка начинается с @ (-D© [...] ) считаем, что указано имя
текстового файла, откуда надо читать описание;
MMGC - магическое имя файла;
RRPL - маска замены файлов. Используйте осторожно!
N - не помещать файл в файл-базу;
F - брать описания файлов из files.bbs. В этом случае также можно указать аль-
тернативное имя списка файлов, если задать его ключом -0@<имя>;
Е - удалить оригинальный файл после посылки его в файл-эху;
А - создавать отчет об обработанных файлах сразу после отработки команды;
U - запретить проверку на дупы;
Q - запретить вывод на экран любых сообщений.
Пример:
Ticman.exe SEND C:\FIDO\NODELIST\NET5049.NDL KAZAN.OFFICIAL
-E -U
FMGR. Распоряжение запустить менеджер подписки (FileMgr - так он назы-
вается для TicManager) на обработку нетмейла.
Синтаксис:
Ticman.exe FMGR <параметры>
Параметры:
NNUM - явно указывается число писем, которое надо обработать;
К - письма будут удаляться после обработки независимо от настроек;
Q - запретить вывод на экран любых сообщений.
Пример:
Ticman.exe FMGR -К
NOTIFY. При вызове TicManager с этим параметром создаются письма
с уведомлениями для линков.
Синтаксис:
Ticman.exe NOTIFY <адрес(а)> <-Q>
Параметры:
Адрес(а) - один или более адресов, для которых будут созданы письма с уве-
домлениями;
Q - запретить вывод на экран любых сообщений.
Пример:
Ticman.exe NOTIFY 2:5049/12.12 2:5049/96
HELP. Разослать справку об использовании FileMgr нужным узлам.
Синтаксис:
Ticman.exe HELP <адрес(а)> [—Q]
Параметры:
Адрес(а) - один или более адресов, для которых будут созданы письма с руко-
водством по использованию менеджера подписки;
Q - запретить вывод на экран любых сообщений.
Пример:
Ticman.exe HELP 2:5049/12.12 2:5049/96
CLEAN. Это распоряжение очистить исходящий директорий (outbound) от от-
правленных файлов.
Синтаксис:
Ticman.exe CLEAN [-Q]
Параметры:
Q - запретить вывод на экран любых сообщений.
STAT. Эта команда создает, используя темплейт stat.tpl, развернутый отчет по
всем статистическим данным, накопленным со времени прихода первого файла.
Синтаксис:
Ticman.exe STAT <параметры>
Параметры:
R - удалить накопленную статистику по областям после создания отчета;
RN - удалить накопленную статистику по областям и по узлам после создания
отчета;
GGRP - создать статистику только для группы grp;
N - включать в отчет области, по которым не проходили файлы;
А - не включать в отчет статистику по узлам, показать только области;
О - перезаписать файл с отчетом вместо добавления в конец;
Q - запретить вывод на экран любых сообщений.
Пример:
Ticman.exe STAT -GKAZAN -N -0 -R
REPORT. Команда создания отчета о пришедших/отправленных файлах.
Синтаксис:
Ticman.exe REPORT <параметры>
Параметры:
А - создавать отчет только об автосозданных областях;
F - создавать отчет только о полученных файлах;
Q - запретить вывод на экран любых сообщений.
Пример:
Ticman.exe REPORT -F
Процессор файловых запросов
В состав AllFix входит так называемый реквест-процессор (request-processor) -
обработчик файловых запросов. У большинства файл-эхопроцессоров (например,
у TicManager) подобного обработчика нет, потому что прямого отношения к файл-
эхам он не имеет, но достаточно удобен для использования, особенно если ваш
мейлер не поддерживает обработку файловых запросов (таков, например, binkd).
Реквест-процессор предназначен для обработки файловых реквестов (запросов
файлов). Он делает это лучше любого мейлера. Реквест-процессор полностью
интегрирован с другими возможностями AllFix: при запросе файла от даунлинка
вашей системы, присутствующего в Node Manager, он пошлет TIC-файл с полным
описанием запрошенного файла, что позволит принимающей стороне автомати-
чески обработать его, поместив в файловую базу и дополнив соответствующий
files.bbs. Конфигурация реквест-процессора вызывается из корневого меню про-
граммы asetup.exe выбором позиции Request processor (рис. 9.17).
Составление файл-листа
Файловая база, которая формируется на узле при содействии файл-эхопроцес-
сора и дополнительных усилий сисопа по заполнению локальных файловых об-
ластей и соответствующих files.bbs, должна иметь общий справочник, позволя-
ющий производить ее просмотр и поиск нужных файлов. По традиции таким
справочником служит текстовый файл (файл-лист, или filelst), включающий
информацию из всех files.bbs базы и название каждой области. Для составления
файл-листов используются специальные утилиты - так называемые файл-листеры,
доступные в большом выборе для всех операционных систем. В качестве примера
можно упомянуть BFL (BBS Files Lister, автор Дмитрий Апухтин, 2:5010/13), на-
писанный для MS DOS. BFL позволяет работать как из командной строки, в авто-
матическом режиме, так и интерактивно, предоставляя удобный режим поиска
и редактирования files.bbs (рис. 9.18).
Одной из популярных функций программ-построителей файл-листов является
создание статистических отчетов по файловой базе, при этом часто используется
счетчик скачанных файлов (download counter), который устанавливается в ин-
формационных файлах files.bbs для каждого описанного файла на основе анали-
за протокольных файлов почтовых программ. Иногда для этой цели также приме-
няются специальные утилиты.
Рис. 9.17. Форма конфигурации реквест-процессора All Fix в утилите asetup.exe
fa"1:.:
a bflexe
Double Dozen Station, SysOp Rmir Shabashvili
: Edit FILES.BBS
5 Append neu
Build list
View/edi t
DL counter
Config
Informal ion
Fx i t
Written
b BFL,„2.10Ц
BFL menu
'Edit descript ionsv' Delete' Tiles
Select area
1 ~ FIDONET FILES Я INFO
2 FIDO NEWSLETTERS P'
3,' FI DQ ' NODE LI ST sWOOED IFF. BO I NT U
' л 4 '
' 5'1
. 6;
7 7 1
,87
9;
"1'0
-11'
'12
'13;
'14'''
15Л
16'"'
NET '5049 SEGMENT/NEWS/INFO 7- ''
' Db'ublel 'DOZEN. NEWS ;FI it LISTS
'MSDOS UTILITIES 7 .
'MSOOS^ANTI VIRUSES' STUFF ' !, 7,
HSDOSvNEtWORK'STUFF'7 / " 7',"
•□JONIS Д1Г/Х25' SYSTEM) DEMO ' '
SOUND Г MUSIC' STUFF " / ' '/ : I
HARDWARE'DOCS DRIVERS СЕГвД
iOtHER BBS I FTP'FILELTSTS
'SOF'T-CRACK INFO 7, 2 I ; C / '
' 0S2 ANTIVIRUS'SOFWARE'7 7
' 0S2' COMMUNICATrONS-'RELhTED .SOF
OS/2' DOCUMENTATION'' :. ; ; j / ; V '
by Dmitry Apuchtin. Use FREE! Sorry for buys
Moipry yM&zjl
Рис. 9.18. Использование построителя файл-листов В FL. Режим выбора files.bbs
для редактирования
Пример подобного отчета, помещаемого, как правило, в конец файл-листа, при-
веден на рис. 9.19 (в сокращении).
Верхняя часть отчета как раз содержит список файлов, наиболее часто загру-
жаемых с системы, далее перечисляются файловые области с указанием количе-
ства и объема хранящихся файлов. Этот отчет построен с использованием файл-
листера BLST-BBS для операционной системы OS/2 (программа существует
также в версиях для DOS, DOS DPMI, Win32), автором программы является
Александр Ведякин из Москвы, адрес в FidoNet - 2:5020/540.
Рис. 9.19. Отчет по файловой базе, построенный файл-листером BLST-BBS
Заключение
На этом заканчивается рассмотрение основных подходов к передаче файлов по
сети FidoNet. При работе с этим сервисом следует учитывать, что FidoNet - сеть
любительская и использование ее ресурсов для передачи больших объемов ин-
формации (а файл-эхи всегда сильно «нагружают» сеть) является потенциаль-
ным источником конфликтов. Всегда помните, что при всей популярности файл-
эх, это не обязательный сервис.
Глава Ж
Почтовые шлюзы FidoMet
Взаимодействие между FidoNet и Internet можно разделить на две слабо связан-
ные между собой области: построение шлюзов между упомянутыми сетями и ис-
пользование Internet взамен телефонного соединения, как универсального транс-
порта для передачи информации FidoNet.
Использование Internet как транспорта подробно обсуждается в следующей
главе, здесь же основное внимание будет уделено системе шлюзов между FidoNet
и Internet. В первой главе, в разделе «Эхи FidoNet и news-конференции UseNet/
Internet» многократно упоминается система почтовых шлюзов между сетями Fido-
Net и Internet. Вопросы построения шлюзов между FidoNet и другими сетями,
в первую очередь между FidoNet и Internet, присутствует в стандартах и предложе-
ниях FTSC очень давно, и можно сказать, что эта сторона использования Internet
хорошо освоена FidoNet.
Далее рассказывается, в основном, о принципах устройства шлюзов между FidoNet
и Internet, поскольку именно эти шлюзы представляют собой наиболее интенсив-
но используемый почтовый сервис и делают FidoNet частью пространства Internet,
выводя ее из самоизоляции. Существуют также шлюзы между FidoNet и другими
сетями, в частности, построенными на родственной FidoNet FTN-технологии. Им
уделено некоторое внимание в конце настоящей главы.
Шлюзы между FidoNet и Internet
Идея создания шлюзов между FidoNet и другими сетями возникла практически
одновременно с образованием FidoNet, как только последняя стала чем-то, напо-
минающим компьютерную сеть. В середине 80-х годов самым дешевым и распрос-
траненным способом подключения к электронной почте Internet было установле-
ние соединения с сетью UNIX-компьютеров, так называемой UseNet (в настоящее
время UseNet полностью поглощена Internet). Для передачи информации между
удаленными UNIX-компьютерами использовался протокол UUCP (UNIX-
to-UNIX Сору), в общих чертах очень похожий на протоколы FidoNet. Таким об-
разом, задача построения шлюза между FidoNet и UseNet состояла в написании
программы преобразования формата между нетмейл-письмами FidoNet и фор-
матом, применяемым в UUCP (RFC-822 и RFC-1036), а так же обмене информа-
цией между исходящими фолдерами Fido и UUCP-систем.
Сейчас многие участники FidoNet воспринимают возможность отправки пи-
сем в Internet через шлюз как нечто само собой разумеющееся, как непремен-
ный атрибут сети Fido. На самом деле такие шлюзы - дополнительный сервис,
который держится только на воле и усилиях небольшой части членов сети,
и относиться к нему надо соответственно, пусть даже ситуация, когда он станет
платным или вовсе исчезнет, представляется маловероятной. На протяжении
уже почти 10 лет существования FidoNet в России почтовые шлюзы с Internet
работают исправно и совершенно бесплатны.
История возникновения шлюзов с UseNet (Internet)
Первым реализовал описанную выше схему обмена письмами между Fido и UUCP
один из основателей сети Боб Гартман (Bob Hartman), сисоп UN*X Gateway BBS
(в то время, в сентябре 1985 года, имевший адрес 132/101, впоследствии - 101/101,
затем - 1:101/101).
Ключевым словом, по которому распознавались письма, предназначенные для
отправки через шлюз, было UUCP в поле ТО: заголовка письма (эта традиция
сохранилась до сих пор). Если программа-обработчик на Fido-системе Боба встре-
чала письмо, адресованное на его узел пользователю по имени UUCP, то оно об-
рабатывалось для отправки по UseNet. Истинный адрес, по которому нужно
было отправить письмо, помещался в первую строку текста письма и выглядел
примерно так:
encore’decvax!ucb
При этом использовалась обычная для UseNet запись, когда через восклица-
тельный знак в качестве разделителя записывались UNIX-компьютеры, пропус-
кающие письмо. Таким образом, маршрут письма присутствует в адресе, что
очень удобно для системных администраторов UseNet и неудобно для пользова-
телей. В приведенном выше примере письмо получал пользователь ucb на ма-
шине DECVAX.
При посылке из UseNet в FidoNet писался адрес вроде приведенного ниже:
decvax’encore!vaxine1 spark!<сеть>!<узел>’<Имя_Фамилия>
где <сеть> и <узел> составляли FidoNet-адрес (зон в FidoNet в то время еще не
было), а <Имя_Фамилия> (именно так - через подчеркивание) содержали имя
и фамилию адресата.
Например, адрес автора книги тогда мог быть записан (будь компьютер с ус-
тановленной на нем шлюзовой программой и с именем ARGUS подключен
к Internet по UUCP через компьютер по имени HECTOR) как
hectorlargus!5049!12’Amir_Shabashvili
Сам шлюз представлял собой набор скриптов для операционной системы UNIX
и поддерживался в рабочем состоянии несколько лет.
Вслед за шлюзом на UN*X Gateway BBS была написана программа UFGATE,
включавшая MS DOS реализацию UUCP и программы конвертирования форма-
тов с разумным преобразованием адресной информации. Автором UFGATE был
Тим Позар (Tim Pozar, в 1988 году имевший Fido-адрес 1:125/555). UFGATE пре-
доставлял возможность шлюзования между Fido и UseNet не только электронной
почты, но и конференций (эхо-конференций FidoNet в news-конференции UseNet
и обратно). Вскоре UFGATE стал самой популярной программой для организации
шлюза, и в течение короткого времени между FidoNet и UseNet появилось боль-
шое количество шлюзов (к 1990 году только в первой зоне более двух десятков).
Ситуация быстро начала выходить из-под контроля, впереди замаячил полный
хаос: с удешевлением услуг Internet/UseNet гейтовать начали все, кому было не
лень настроить программу, и дублированные письма волнами странствовали по
FidoNet. Положение усугублялось еще и появлением программ вроде GATEWAY,
написанной Дениэлом Тобиасом (Daniel Tobias, тогда 1:380/2) и позволявшей
производить обмен почтой и конференциями с популярными в те годы коммер-
ческими системами on-line вроде CompuServe, The Source или GEnie.
Наконец в апрельском номере FidoNews за 1989 год вышла статья Ренди Буша
(Randy Bush) [10.1], содержащая достаточно полное и конструктивное описание
правил построения шлюзов между FidoNet и Internet. Вскоре эта статья была
оформлена в качестве проекта стандарта FSC-0034 [10.2] и послужила руковод-
ством к действию для многих гейт-мастеров Fido-Internet шлюзов.
В 1990 году решением международного координатора Матта Веллана (Matt
Whellan) в качестве официального рекомендательного стандарта были приняты
административные правила построения и регистрации шлюзов с другими сетями
(FidoNet Internetwork Gateway Policy) [10.3], к сожалению, полузабытые и прак-
тически неиспользуемые в настоящее время.
Одним из важных компонентов успеха была также регистрация в Internet соб-
ственного домена fidonet.org. Для того чтобы понять значение этого достижения,
следует обратиться к концепции адресации Internet.
Система распознавания имен Internet
(Domain Name System)
Этот небольшой раздел предназначен для тех читателей, кому внове система ад-
ресации, используемая в Internet.
Internet использует цифровой адрес, однозначно идентифицирующий тот или
иной сетевой интерфейс. Компьютер в Internet может иметь несколько адресов,
в зависимости от числа интерфейсов, которые соединяют его с сетью. Цифровой
адрес Internet представляет собой двоичное 32-разрядное число, уникальное
в пределах всей сети. Для удобства при записи цифрового адреса обычно исполь-
зуется так называемая десятично-точечная нотация, например:
194.67.27.194
Старшие разряды (194.67.27) определяют номер сети, а младшие (194) - номер
машины в данной сети. Количество разрядов для идентификатора сети и узла
может варьироваться, и в зависимости от этого изменяется возможное количество
узлов в сети.
Такие адреса очень удобно использовать при автоматической обработке, прав-
да, они с трудом запоминаются и напрямую не связаны с истинной иерархией
построения реальной сети. Поэтому для удобства запоминания и использования
имени как универсального элемента, характеризующего структуру сети, была
разработана система DNS (Domain Name Sistem), предназначенная для опреде-
ления цифрового адреса по символьному имени, и наоборот. Основным элемен-
том символьного имени является так называемый домен. Имя состоит из разде-
ленных точками наименований доменов, каждый из которых является уровнем
иерархии сети.
Технически DNS представляет собой распределенную базу данных, в кото-
рой содержатся сведения о соответствии символьных имен и цифровых адре-
сов Internet, а также некоторая дополнительная информация (информация о мар-
шрутизации почты, контактные данные для связи с персоной, ответственной за
поддержку данного домена, и т.п.).
Например, приведенный выше адрес 194.67.27.194 может быть распознан как
компьютер с символьным адресом:
argus.zarech.ru
что означает компьютер по имени argus в сети (домене второго уровня) zarech
домена .ru.
Система символьных имен Internet организована иерархически, с убыванием
уровня иерархии справа налево, то есть в приведенном примере .ru означает до-
мен первого уровня, a .zarech -домен второго уровня. Количество подчиненных
доменов не ограничено. В качестве иллюстрации на рис. 10.1 изображена часть
Рис. 10.1. Иерархия доменов Internet
структуры домена .ru, включающая и поддомен .zarech. Все домены имеют в ка-
честве домена-прародителя корневой домен (находящийся в вершине изобра-
женной на рисунке структуры). Далее следуют домены .mil (военные США), .gov
(правительственные учреждения США), .сот (компании), .edu (образователь-
ные учреждения США), .net (сетевые сообщества), .org (организации) и множе-
ство географических доменов, представляющих отдельные страны. Домен .ru
принадлежит России. На рисунке также изображены домены второго уровня
fidonet.org и fidonet.net, ассоциированные с FidoNet, и поддомены z2.fidonet.org
и z2.fidonet.net, относящиеся ко второй зоне FidoNet.
В Internet работает взаимодействующая система серверов DNS, производящая
быстрое распознавание цифровых адресов по символьным именам. Символьные
имена, предоставляемые DNS, были использованы при задании почтовых адресов
в Internet.
Почтовый адрес в Internet строится как соединение адреса компьютера и име-'
ни пользователя, например: ashabash@mail. ru. Это так называемый адрес в сти-
ле ArpaNet (описанный в начале главы UseNet-формат считается устаревшим).
Здесь ashabash - имя пользователя, а mail.ru - имя компьютера.
Взаимоподчиненность доменов отражает в основном административную иерар-
хию (то есть кто ответствен за ведение соответствующего адресного простран-
ства). Очевидно, что при маршрутизации почты в Internet можно было бы ис-
пользовать иерархическое строение символьных имен; например, почту для
argus.zarech.ru можно было бы направить в почтовый домен .ru, который в свою
очередь переправил бы ее в соответствии с правилом маршрутизации для до-
мена второго уровня .zarech.ru, однако на практике принята другая схема.
Правила маршрутизации почты записываются в конфигурации почтовых про-
грамм Internet - SMTP-мейлеров, но основная информация о точке приема поч-
ты для каждого домена добывается из DNS. Ключевым параметром при передаче
почты в Internet является адрес сервера MX (Mail eXchanger), назначенного для
приема почты данным доменом или компьютером и получаемого SMTP-мейле-
ром из DNS-запроса.
Вот как выглядят MX-записи для доменов zarech.ru и домена третьего уровня
mail.zarech.ru (использован протокол работы программы nslookup, рис. 10.2).
Из рис. 10.2 видно, что MX-имя для домена zarech.ru выглядит как relay2.za-
rech.ru, а для mail.zarech.ru почту принимает relay3.zarech.ru. Благодаря использо-
ванию MX маршрутизация в Internet существенно сокращается, так как письмо
передается непосредственно на MX-адрес, ближайший к получателю, так что в ре-
альности почта, отправленная пользователю домена zarech.ru, будет передана непос-
редственно на входной почтовый компьютер данного домена (relay2.zarech.ru) без
какого-либо участия компьютеров корневого домена .ru.
FidoNet or$: Fido из Internet
Пока у FidoNet не было своего доменного имени, вся почта для каждого шлюза
направлялась на его Internet-адрес, или UUCP-адрес. Это было неудобно, так как
шлюзов было много и адреса они имели разные.
T:\etc\named>ns lookup
Default Server: abaddon.zarech.ru
Address: 194.67.27.210
> set q=mx
> zarech.ru
Server: abaddon.zarech.ru
Address: 194.67.27.210
zarech.ru preference = 10, mail exchanger = relay2.zarech.ru
relay2.zarech.ru internet address = 194.67.27.199
> mail.zarech.ru
Server: abaddon. zarech. ru
Address: 194.67.27.210
mail.zarech.ru preference = 10, mail exchanger = relay3.zarech.ru
relay3.zarech.ru internet address = 194.67.27.54
Рис. 10.2. Протокол работы программы nslookup, показывающий MX-адреса
для доменов zarech.ru и mail.zarech.ru
В 1989 году в INTERNIC было зарегистрировано доменное имя fidonet.org, ис-
пользуемое с тех пор для организации шлюзования между Internet и FidoNet. Для
удобства было предложено использовать следующее преобразование FidoNet-
адреса в Internet-адрес:
<Имя>[.<Фамилия>]@[р<пойнт>].f<узел>.п<сеть>.г<зона>.fidonet.org
Например, адрес пользователя по имени Amir Shabashvili с fido-адресом 2:5049/
12@fidonet преобразуется в почтовый Internet-адрес:
Amir.Shabashvili@f12.n5049.z2.fidonet.org\
А пойнт-адрес 2:5049/12.12 сисопа по имени Amirko в Internet выглядит следу-
ющим образом:
Amirko@pl2.fl2.n5049.z2.fidonet.org
Теперь проблема нахождения адреса шлюза при отправке письма из Internet
отпала сама собой: письмо, содержащее правильно написанный в Internet-форме
адрес FidoNet, всегда достигало шлюзовой машины. Региональные и сетевые
шлюзы в Internet при этом также могли существовать в рамках единой системы
шлюзов FidoNet; постмастер домена fidonet.org мог передоверять ведение части
сетевых адресов другим постмастерам. Например, в настоящее время сети, при-
надлежащие региону 50 второй зоны FidoNet (адреса 2:50??/*.* и 2:60??/*.*, если
использовать метасимволы для описания групп адресов), обслуживаются
шлюзом 2:50/128@fidonet или Internet-сервером fido.corbina.net (Цифровой адрес
195.14.50.21), территориально расположенным в Москве. Письмо, отправленное
на адреса 50-го региона, сразу же будет переправлено на этот компьютер, так как
запись в DNS для этих адресов идентифицирует его как основной Relay (почтовый
gj; ВЕХБ- maiUogу ' /у \ - '"А \
Де$; Bfft; Options, Help Л ' ?/-, чХ. ; \/<
Nov 11 11:20:40 hector sendmail[22358]: LAA22356:
to=<Amir.Shabashvili@f12.n5049.z2.fidonet.org>,
ctladdr=<ashabash@zarech.ru> (1002/1001),
delay=00:00:16, xdelay=00:00:15, mailer=esmtp,
relaysfido.corbina.net. [195.14.50.21],
stat=Sent (Ok: queued as C26A7DB6E5)
Рис. 10.3. Протокол работы программы SMTPD
при отправке письма на адрес
Amir. Sh abash vili@f 12.n5049.z2. fidonet, org
сервер). На рис. 10.3 приведен протокол отправки письма SMTP-мейл ером, ил-
люстрирующий этот тезис.
История организации почтовых шлюзов между FidoNet и Internet в России
была рассказана в главе 1 («Фидо в России», «Эхи FidoNet и news-конференции
UseNet/Internet»). При организации шлюзов использовались в основном про-
граммы, написанные в России: рассчитанная на UUCP программа UU2 (DOS,
OS/2) Дмитрия Завалишина, FTN-IP шлюз Ifgate Евгения Черкашина (Ifgate вхо-
дит в состав ifmail, fido-системы для UNIX). Сейчас шлюзов в России очень мно-
го. Несмотря на то, что по-прежнему самым крупным является 2:50/128, почти
каждая сеть имеет свой шлюз, который следует знать и использовать, так как путь
письма по FidoNet в этом случае будет намного короче.
Правила использования почтовых шлюзов
Общих для всей FidoNet правил использования шлюзов с Internet не существует,
кроме соглашений о преобразовании адресов, но есть правила использования кон-
кретных общедоступных шлюзов, например шлюза по адресу 2:50/128. Практи-
чески все распространенные программы шлюзов применяют аналогичный описан-
ному ниже способ адресации письма из FidoNet в Internet.
Как написать письмо из FidoNet в Internet
При отправлении письма на адрес 2:50/128 вместо имени пользователя укажите
адрес в Internet. Например, заголовок письма может быть таким, как изображено
на рис. 10.4.
Если длина Internet-адреса превышает разрешенную для поля имени получа-
теля (это порой случается), то напишите UUCP в этом поле, а сам Internet-адрес
получателя поставьте в первой строчке письма после символов ТО: через пробел.
Требование пробела после ТО: является обязательным. (
При этом вторая строчка должна быть пустой, как это изображено на рис. 10.5.
Способ посылки с полем ТО:, перенесенным в тело письма, предпочтительнее,
так как некоторые трекеры заменяют E-mail адрес в заголовке на слово UUCP, не
перенося его в тело письма.
-Л Fleetstreet 1.24.1 - S¥SOI>,S_MAIL (H)__________________j
File Edit Message Special Rexx Setup Windows Help
From: Amirko 2:5049/12.12
To: president@whitehouse.gov 2:50/128
Subj: test (тест)
j Attrib: | priv local read
Hello mr; President 1 . •
21 Feb 2000 15:57:48
This is' test' (тест) , ignore gt. . .
a shaba sh@zarech.ru
| /320^ pNS [
? Й049/12 |
Рис. 10.4. Пример письма из FidoNet в Internet
с использованием почтового шлюза на 2:50/128
И Fleetstreet 1.24.1 - SYSOP'SJiAIL (N) __________________' | a [gj
j File Edit Message Special Rexx Setup Windows Help |
Ш йИаВ Б№! Ss
From: Amirko 2:5049/12.12 21 Feb 2000 15 57 48
To: UUCP 2:50/128
Subj: test (тест)^
I Attrib; I priv local read
To; vice-president@whitehouse.gov , L
Hello jnrh Vice-President I ' • ; ' • -n ; v |
This, js'test (тест) ignore it/.. '/ > , [
™ . p. ^5^ |
Рис. 10.5. Пример письма из FidoNet в Internet
с использованием почтового шлюза на 2:50/128
Как написать письмо из Internet в FidoNet
Напишите письмо по адресу, полученному из Fido-адреса преобразованием, указан-
ным в разделе «FidoNet.org: Fido из Internet». Письмо, посланное на адреса 50-го
региона второй зоны FidoNet, должно попасть на региональный шлюз (2:50/128),
или на шлюз сети адресата, если таковой имеется. Письмо, посланное из Internet
на адреса других регионов и зон FidoNet, попадет на их почтовые шлюзы, и до-
ставка его адресату будет определяться практикой использования этих шлюзов,
в частности, письмо может и не дойти до адресата, такое тоже случается. Шлюз
же на 2:50/128 обычно работает очень надежно.
Как отказаться от использования гейта
Желание отказаться от услуг получения почты из Internet вполне законно, и гейт-
мастеры шлюзов с пониманием реагируют на подобные просьбы. На региональ-
ном шлюзе 2:50/128 эта процедура автоматизирована. Действовать необходимо сле-
дующим образом: напишите письмо любого содержания на stop-gating@corbina.net
(оформив его по правилам, описанным выше для писем из Fido в Internet). Такое
письмо выключит гейтование для адреса, с которого оно написано. Письмо от пойн-
та выключит гейтование только на него, письмо от узла (точнее, от нулевого пойн-
та) выключит гейтование и на всех его пойнтов.
Гейтмастер также может оказать содействие в борьбе со спамом - навязчивой
рекламой из Internet. Текущий список фильтрации шлюза 2:50/128 (это список
адресов, с которых запрещено принимать почту) размером около 400 Кбайт мож-
но посмотреть в Internet по адресу:
http://www.corbina.net/antispam
Полученный раздражающий вас спам можно выслать гейтмастеру шлюза для
дополнения спам-фильтра.
Вся текущая информация, касающаяся правил использования регионального
шлюза, адреса гейтмастеров и т.п., регулярно публикуется в эхах R5 0 . SYSOP. *.
Требования, предъявляемые к почтовым шлюзам
FidoNet и Internet имеют разные стандарты на форматы почтовых сообщений,
и необходимым условием перемещения электронной почты из одной сети в дру-
гую является ее преобразование. При этом со стороны FidoNet должны соблю-
даться следующие условия:
• формат писем, помещаемых в FidoNet со стороны шлюза, должен соответ-
ствовать стандартам FidoNet;
• заголовок письма, отправляемого в FidoNet, должен содержать правильный
адрес FidoNet, входящий в текущий нодлист;
• сообщение должно содержать достаточно информации для однозначной иден-
тификации его отправителя;
• формирование писем для шлюза не должно требовать особого программно-
го обеспечения; для этого должны быть пригодны используемые редакторы
и почтовые программы FidoNet;
• контрольная информация, пришедшая с письмом из Internet, не должна
уничтожаться; она может инкапсулироваться в специальные строки (клад-
жи) в теле письма, начинающиеся с символа Olh Са). Обычно это кладжи,
начинающиеся с RFC (рис. 10.6).
Примеры писем, прошедших почтовый шлюз Fido-lnternet
Приведенный на рис. 10.6 пример иллюстрирует случай с письмом, пришедшим
в FidoNet из Internet через шлюз. Весь текст письма исчерпывается нижней его
строкой test (тест), а все, что идет выше, представляет собой либо служебные
строки (кладжи), обозначенные символом @, которые в обычном режиме просмот-
ра письма не отображаются на экране, либо адресную информацию.
Из заголовка письма следует, что получено оно от пользователя с адресом
2:50/128 (адрес шлюза) и именем ashabash@zarech.ru (на самом деле это Internet-
адрес отправителя).
Из кладжей, представленных в нижнем окне программы, стоит обратить вни-
мание на первый, содержащий уникальный идентификатор сообщения MSGID.
Этот кладж был сгенерирован программным обеспечением шлюза, и, кроме иден-
тификатора 4abf0e6c, представляющего собой 32-битное шестнадцатиричное чис-
ло - собственно MSGID, он содержит также Internet-адрес отправителя.
Обычно на этом месте стоит FidoNet-адрес, но согласно стандарту на MSGID,
FTS-0009 [2.10], в MSGID должен проставляться истинный адрес компьютера
отправителя, и не обязательно это должен быть Fido-адрес. Если в заголовке пись-
ма вдруг окажется неверный адрес, загляните в кладж MSGID - вдруг там уцелел
правильный адрес отправителя. Приведенный адрес hector.zarech.ru - это адрес
^"ReetStr'eeFL24[»[Q^
! File Edit Message Special Rexx Setup Windows Help , J
! From: ash.abash@zarech. ru 2:5020/128 21 Feb2000 16:10:36
To: Amir Sh.abash.vili , 2:5049/12
iiliiM
! Altrib privrcvd local read
Thu,,';il\Noy11:20:24 *ОЗОррМЖ\\,; ' ,7 * ... > ,< / ' '
Beply-To: /*Am£rphaba^hviii’t <a3h^bash^arech. ru> ’ ' / ' ; p'/p
* Origin: Double Dozen [http: //ashabash. zarsch. ruj (2:5020/128)
;h&i Additional message info
@MSGID: hector.zaiech.ru 4abf0e6c *•
@REPLYADDR: ashabash@zaiech.ru
j @REPLYTO: 2:5020/128@ fido net
@ RFC-Received: from hector.zaiech.ru (hector.zaiech.ru [194.67.27.100]) by earth.corbina.net (Postfix)
@ RFC-Received: fromargus.zaiech.ru (ashabash@argus.zaiech.ru [104.67.27.104]) by hector.zaiech.n
@RFC-Message-Id: <100011110820.LAA22356@hector.zaiech.ru>
@Via ifmail 2:5020/128@fidonetr Thu Nov 11 1000 at 11:18 (2.10dev)
i @Via 2:5020/204 FTrack 2.04.M/W32 11 Nov 1000 11:26:56 P
@Via 2:5040/12@FidoNet @10001111.124735.02.UTC Itrack- 1.3/G6
Close | Copy 11 Help | □ Keep in front
if i I ржет? ; 2swi2
Рис. 10.6. Пример письма, пришедшего через почтовый шлюз из Internet в FidoNet
ближайшего к компьютеру автора почтового сервера Internet. Именно через него
была произведена отправка данного письма.
Кладжи Reply Addr и Reply То, следующие за MSGID, содержат информацию
об истинном адресе отправителя письма и об адресе шлюза; эти кладжи описаны
в FSC-0035 [10.4].
Далее следуют несколько кладжей, начинающихся со строки RFC-. Это ин-
капсулированные служебные строки исходного письма в формате RFC-822
[2.9], полученного шлюзом по Internet. По ним можно определить маршрут
письма в Internet (строки RFC-Received). Судя по информации, содержащейся
в них, маршрут данного письма был следующим:
argus.zarech.ru => hector.zarech.ru earth.corbina.net.
По этим же кладжам можно узнать идентификатор Internet-письма (кладж RFC-
Message-Id), а иногда и другую полезную информацию (например, способ кодиро-
вания или наименование программы, использовавшейся при создании письма).
Затем следуют обычные FTN-кладжи VIA, рассказывающие о маршруте следо-
вания письма по FidoNet, и текстовый заголовок, помещаемый программой шлю-
за непосредственно в текст письма.
На рис. 10.7 представлено письмо, полученное по системе электронной почты
в Internet. Оно прислано из FidoNet и прошло через тот же шлюз Fido-Internet,
что и предыдущее, но только в обратном направлении.
Обратите внимание на служебные строки. В стандарте RFC-822, используемом
в Internet для электронной почты, служебные строки отличаются от обычных по
начальному ключевому слову. Обычно эти строки не отображаются на экране,
однако можно включить специальный режим, чтобы они стали видимыми.
В приведенном примере сначала идут три строки, начинающиеся с ключевого
слова Received и рассказывающие нам о маршруте следования письма по Internet:
earth.corbina.net hector.zarech.ru => zarech.ru
Среди других, обычных для электронной почты Internet служебных строк это-
го письма, встречаются также загадочные строки, начинающиеся с X-FTN-. Эти
строки содержат инкапсулированные служебные строки исходного сообщения,
пришедшего по FidoNet. Такой подход к передаче всех служебных строк был впер-
вые введен Евгением Черкашиным в его программе Ifmail.
Суммарно анализ и тех и других служебных строк дает нам полное представ-
ление о маршруте следования сообщения как по Internet, так и по FidoNet, а так-
же и другую ценную информацию, которая во многих случаях бывает необходима
при анализе дефектной почты и почты непонятного происхождения.
Так, из приведенных FTN-кладжей можно сделать вывод:
• в FidoNet письмо следовало по пути: 2:5049/12 => 2:5049/36 => 2:5049/204
(кладжи X-FTN Via);
• оно происходит с адреса 2:5049/12 (кладжи X-FTN-Origin и X-FTN-MSGID;
• письмо было написано в программе FleetStreet, версии 1.24.1 (X-FTN-
Tearline);
• письмо имеет атрибут PVT (приватное), что следует из содержимого кладжа
X-FTN-FLAGS.
Заслуживает внимания и заголовок письма, содержащий поля ТО:, FROM:,
DATE:, и SUBJECT:.
Преобразование нетмейл-письма в формат RFC-822, используемый в Internet,
сводится к следующему (на примере программы-шлюза Ifgate):
□ содержимое полей FROM: и ТО: заголовка нетмейл-письма помещается в соот-
ветствующие заголовки письма формата RFC-822, а также в заголовок письма
(envelope) в описанном выше формате: Name. [LastName] @ [р*] . f * .п* .
z* . fidonet. огд. При формировании заголовков Internet-письма может
использоваться и информация из кладжей AaINTL, AaDOMAIN, AaFMPT
и АаТОРТ, поскольку ее приоритет выше информации из двоичного заголов-
ка нетмейл-письма;
□ FTN-кладжи переходят в одноименные служебные строки с префиксом
X-FTN- (X-FTN-Via, X-FTN-MSGID, X-FTN-REPLY и т.д.). Исключение со-
ставляют вышеупомянутые кладжи, участвующие в формировании адресов;
□ флаги (атрибуты) нетмейл-письма попадают в служебные строки с префик-
сом X-FTN-FLAGS в виде символьных имен (RRQ, CFM и т.п.);
□ строка-подпись редактора (Tearline) помещается в X-FTN-Tearline, строка Origin
попадает в X-FTN-Origin, а также в Organization (без FTN-адреса в конце);
Oj "test (т ес т) n From: Ami г Shabashvi 1 i ___________ ____________________ | *"[□
i Message Edit Attachments Tools Window | Help
|^^Amir Shabashvili <Amix.ShabashviliGf Date<;Thu, 11 Nov 99 13;02;02 4-0300________|
Тол ^Mi^hiTzad^ cc; Q ”
.Subject itest (тест)
Received: from hector.zarech.ru by zarech.ru with SMTP; Thu, 11 Nov 1999
13:31:15 +0400 (MSK) Г"
Received: from earth.corbina.net (postfixGearth.corbina.net [195.14.50.21])
by hector.zarech.ru (8.9.3/8.9.3) with ESMTP id NAA23399
for <ashabash@zarech.ru>; Thu, 11 Nov 1999 13:32:39 +0300 (MSK)
Received: by earth.corbina.net (Postfix, from userid 69)
id EAD26DB684; Thu, 11 Nov 1999 13:30:06 +0300 (MSK)
Received: from fl2.n5049.z2.fidonet.org by fl28.n5020.z2.fidonet.org
with FTN (ifmail v.2.10dev) id AA2913; Thu, 11 Nov 99 13:30:06 +0300
Apparently-То: ashabashGzarech.ru
To; "ashabashGzarech.ru" <ashabash%zarech.ru0f128.n5020.z2.fidonet.org>
From: Amir Shabashvili <Amir.ShabashviliGf12.n5049.z2.fidonet.org>
Date; Thu, 11 Nov 99 13:02:02 +0300
Subject: test (тест)
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
Message-ID: <9423253490f12.П5049.z2.ftn>
Organization: Double Dozen [http://ashabash.zarech.ru]
X-FTN-FLAGS: PVT
X-FTN-MSGID: 2:5049/12 382abe65
X-FTN-Tearline: Fleetstreet 1.24.1
X-FTN-Origin: Double Dozen [http;//ashabash.zarech.ru] (2:5049/12)
X-FTN-Via: 2:5O49/120FidoNet Q19991111.130306.45.UTC Itrack- 1.3/G6
X-FTN-Via: UniMail/2 o.31/beta 2:5049/12, Thu 11 Nov 1999 10:03:12 UTC +0300
X-FTN-Via: 2:5O49/360fidonet 019991111.092041.07.UTC Itrack+ 1.3/G6 DB876437
X-FTN-Via; 2:5020/204 FTrack 2.04.bl/W32 11 Nov 1999 13:24:41
Hello ashabash0zarech.ru!
test (тест) j||
Cheers, ...
Amir
ashabashGzarech.ru
| Weicome To The"Message
□ Message-ID гейтованного в Internet письма образуется следующим образом:
число из кладжа AaMSGID преобразуется в десятичное представление и ста-
вится перед а адрес из AaMSGID ставится после © в виде [р* ] . f * . п* .
z*. ftn, если это FTN-адрес, в противном случае он переносится, как есть.
Возможные ошибки и диагностика
работоспособности шлюза
Проверить функционирование того или иного шлюза проще всего, послав сооб-
щение самому себе на адрес в другой сети, например, если у вас есть E-mail адрес
в Internet, пошлите тестовое сообщение на него из FidoNet и, получив его, ответь-
те аналогичным тестовым письмом на Fido-адрес. Если все ожидаемые письма
были успешно получены, то шлюз работает.
Если же получено сообщение об отказе в доставке или об ошибке, следует ра-
зобраться, является ли отказ симптомом неработоспособности шлюза, или же
следствием ошибки в адресе, а может, все дело в неверном оформлении письма.
Рассмотрим теперь случай отказа в доставке письма, и научимся диагностиро-
вать причину отказа.
Из Internet в FidoNet
Допустим, письмо отправлено по несуществующему в FidoNet адресу:
fl012.n5049.z2.fidonet.org,
который представляет собой Internet-запись fido-адреса: 2:5049/1012@fidonet,
отсутствующего в нодлисте.
Кроме того, послано аналогичное письмо на адрес:
fl012.n5049.z2.fidonet.net,
который нельзя использовать для целей шлюзования в FidoNet, так как домен
fidonet.net не предназначен для передачи почты.
На рис. 10.8 и 10.9 процитированы полученные ответы от программ, заведую-
щих отправкой письма (рис. 10.8) и обработкой (10.9) почты на шлюзе. Для того
чтобы квалифицировать письмо, изображенное на рис. 10.8, как техническое со-
общение (не обязательно отказ, это может быть и сообщение о временных затруд-
нениях при попытке связаться с компьютером шлюза, и другая информация об
ошибке), не нужно внимательно изучать его содержимое. Достаточно обратить
внимание на наименование отправителя. Обычно технические письма отправля-
ются от имени пользователя программы MAILER-DAEMON (мейлер-демон), бо-
лее подробно именованного в строчке FROM: как «служба почтовой доставки»
(Mail Delivery Subsystem).
В данном случае ответ был сформирован на стороне отправителя ближайшим
к нему компьютером hector.zarech.ru на основании ошибки, выданной при поис-
ке в DNS адреса почтового сервера для домена fidonet.net. Хотя домен fidonet.net
и существует, он не предназначен для передачи почты по протоколу SMTP, в от-
личие от домена fidonet.org, и MX-записей в нем нет. Поэтому пришло сообще-
ние о невозможности доставки. Само сообщение об ошибке содержится в после-
дней строке письма:
Host unknown (Name server: fl012.n5049.z2.fidonet.net: host
not found)
Это означает:
«хост неизвестен (сообщение от сервера имен: <указанный выше неверный ад-
рес^ хост не найден)».
Это был пример отказа на несуществующий адрес от сервера Internet (не от шлюзо-
вой машины). Теперь отправим письмо из Internet в Fido через тот же шлюз на несу-
ществующий в FidoNet адрес 2:5049/1012@fidonet или, в Internet-представлении, на:
Amirko@fl012.n5049.z2.fidonet.org
Ответ, полученный при попытке отправить письмо на правильно написанный,
но несуществующий в Fido адрес, приведен на рис. 10.9. Причина ошибки указана
в тексте письма:
Recepient of this message (2:5049/1012) not listed on my
nodelists. Please not send this message via standart routing
что означает:
«получатель этого письма (2:5049/1012) отсутствует в используемых нодлис-
тах. Пожалуйста, не посылайте это письмо по стандартному маршруту».
ф’ „ From: Mail Delivery Subsys... j => ] Dj
Message Edit Attachments Tools Window [Help
^1 gl gl M *1 «1*1 ~l £l •
i Toi jashabash@zarech. ru <ashabash@zaj [ Cc; f j =
Iect [Returned mail г Host unknown, (Name server t pl2. f 12, n5049. fidonet, xuj
Received: from hector.zarech.ru by zarech.ru with SMTP; Mon, 15 Nov 1999 13:32:00 +0400 (MSK) Received: from localhost (localhost) by hector.zarech.ru (8.9.3/8.9.3) with internal id NAA05481; Mon, 15 Nov 1999 13:32:28+0300 (MSK) Date: Mon, 15 NOV 1999 13:32:28 +0300 (MSK) From: Mail Delivery Subsystem <MAILER-DAEMON@hector.zarech.ru> Message-Id: <199911151032.NAA05481@hector.zarech.ru> To: <ashabash@zarech.ru> MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="NAA05481.942661948/hector.zarech.ru" Subject: Returned mail: Host unknown (Name server: pl2.fl2.n5049.z2.fidonet.net: host not found) Auto-Submitted: auto-generated (failure) The original message was received at Mon, 15 Nov 1999 13:32:26 +0300 (MSK) fromwww.zarech.ru [194.67.27.224] The following addresses had permanent fatal errors <amirko@pl2.fl2.n5049.z2.fidonet.net> Transcript of session follows 550 <amirko@pi2.f12.n5049.z2.fidonet.net>... Host unknown (Name server: pl2.fl2.n5049.z2.fidonet.net: host not found) id
PI w Test for MIME incapsulation
J Welcome To The Messaqe Read Window 3=
Письмо послано от имени программы FTrack (это нетмейл-трекер, установлен-
ный на шлюзе). В конце письма-ответа заботливо процитирован заголовок и вся
служебная информация оригинального письма, из формы которого понятно, что
ответ был сформирован на Fido-стороне шлюза - чего и следовало ожидать, так
как речь идет об адресной проверке по нодлистам, которая является стандартной
для FidoNet (но не для Internet) процедурой.
Из FidoNet в Internet
В этом случае письмо отправлено на имя несуществующего пользователя (unknown)
действующего в Internet компьютера (zarech.ru). Ответ с сообщением о невозмож-
ности доставки приведен на рис. 10.10. Отправлено это письмо от имени старого
знакомца, MAILER-DAEMON, живущего в данном случае на Internet-стороне
почтового шлюза Fido-Internet (на компьютере с адресом earth.corbina.net). Этот
возврат пришел по FidoNet в виде стандартного нетмейл-сообщения. В начале
текста письма идут кладжи, отмеченные символом @ (см. выше), а сам ответ зак-
лючен в строчках:
“Bad destination address" From: Ftrack_______________________________| ° О
Message Edit Attachments Toots Window___________________________________[ Help
F&hbN «•! I * I
^rom:|FtraeK <FtrackQ£204. П5020. , fide 0а<е=|рг1, 12 Hoy 99 13i06;43 4-0300 ~|
p^^b^h^zarech. ru^ashaMsh%zar7 Co: * : । ’
^Subject ^Bad destination address , ]
I Received: from hector.zarech.ru by zarech.ru with SMTP; Fri, 12 Nov 1999 i
13:16:24 +0400 (MSK) ""j
Received: from earth.corbina.net (postfix@earth.corbina.net [195.14.50.21])
by hector.zarech.ru ( 8.9.3/8.9.3) with ESMTP id NAA05029 Ы
for <ashabash@zarech.ru>; Fri, 12 Nov 1999 13:17:33 +0300 (MSK)
Received: by earth.corbina.net (Postfix, from userid 69) i
I id DFFE8DB693; Fri, 12 Nov 1999 13:15:06 +0300 (MSK) !
Received: from f204.n5020.z2.fidonet.org by fl28.n5020.z2.fidonet.org i
with FTN (ifmail v.2.10dev) id AA15329; Fri, 12 Nov 99 13:15:06 I
+0300 ;
Apparently-То: ashabash@zarech.ru I
To: "ashabash@zarech.ru" <ashabash%zarech.ru@fl28.n5020.z2.fidonet.org>
From; Ftrack <Ftrack@f204.n5020.z2.fidonet.org>
Date: Fri, 12 Nov 99 13:06:43 +0300 Ы
Subject: Bad destination address \
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
Message-ID: <3244472728@f204.П5020.z2.ftn>
X-FTN-FLAGS; LOC
X-FTN-MSGID: 2:5020/204 C162B998
X-FTN-Via; 2:5020/204 FTrack 2.04.bl/W32 12 Nov 1999 13:08:44
Hi, ashabashQzarech.ru!
Recepient of this message (2:5049/1012) not listed on my nodelists.
Please not send this message via standart routing.
Cheers,
Yuri
= = s:=: = = = = = s = = =: = s = = =: = = = =:=:s: = = = = = sss==: = = = = = = = = = = = = = s = = = = =: = = = = =5 = = =:ss = = = = = = =
From: ashabash@zarech.ru (2:5020/128)
To ; Amirko (2:5049/1012)
Subj: test
Date: 12 Nov 99 12:58:28
Attr; Pvt Trn
[Welcome To The Message Read Window
This is the Postfix program at host earth.corbina.net.
I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.
For further assistance, please contact
<postmaster@earth.corbina.net>
If you do so, please include this problem report. You can
delete your own text from the message returned below.
The Postfix program
<unknown@zarech.ru>: host relay2.zarech.ru said: 550
<unknown@zarech. ru>... User unknown
Что примерно означает следующее: «Это говорит программа Postfix на ком-
пьютере earth.corbina.net. Сожалею, но должна проинформировать вас, что проци-
тированное письмо не может быть доставлено по одному или более адресов. За
разъяснениями обращайтесь по адресу postmaster@earth.corbina.net>. Если вы ре-
шите поступить подобным образом, пожалуйста, перешлите и это сообщение
о возникшей проблеме. Вы можете удалить ваш собственный текст из возвращен-
ного письма.
Программа PostFix
Рис. 10.10. Пример письма-отказа при отправке письма из FidoNet через шлюз
на несуществующий в Internet-адрес
<unknown@zarech.ru>: хост relay2.zarech.ru сказал:
550 <unknown@zarech.ru>... Пользователь неизвестен»
Самая последняя процитированная строка содержит собственно сообщение об
ошибке - а именно, об отсутствии на компьютере zarech.ru пользователя по име-
ни unknown, которому адресовано письмо.
Как видно из приведенных примеров, нет ничего сложного в чтении и анализе
«проблемных» сообщений. Нужно только не бояться больших писем, почти цели-
ком составленных из ритуальных английских фраз, и научиться быстро выделять
ключевые блоки текста. Иногда можно воспользоваться и англо-русским слова-
рем, если смысл написанного все еще остается туманным. Использование анг-
лийского языка в сообщениях об ошибках - общепринятый обычай. Связано это
с тем, что электронная почта не знает границ, и английский язык, как самый рас-
пространенный^ понятен многим пользователям и помогает избежать путаницы,
возникающей при использовании различных кодовых таблиц для букв кириллицы.
Проблемы с чтением русских текстов
Проблемы, возникающие при передаче русскоязычных фрагментов текста, возни-
кают по нескольким причинам:
□ несовпадение кодировок букв кириллицы;
□ нераспознанная 7-битная инкапсуляция (MIME, UUENCODE) 8-битного
текста в теле письма;
□ многократно перекодированный текст.
Подробное описание всех возможных затруднений и способов их преодоления
выходит за рамки данной книги, но основные моменты необходимо знать. Ниже
приведен краткий обзор проблем, возникающих, когда вместо понятного текста
вы видите на экране нечто, что в русскоязычной части FidoNet обычно называют
«крокозябы».
Кодировка букв кириллицы
Отсутствие единого стандарта на кодировку кириллицы представляет собой
первопричину всех трудностей, возникающих при путешествии русского чело-
века с модемом и компьютером в качестве средства передвижения. Так уж сложи-
лось, что распространение получили три варианта кодировки русских букв (есть
еще несколько менее распространенных вариантов!):
□ СР866. FidoNet по происхождению - сеть MS DOS-компьютеров. Для MS DOS
и OS/2 (и для DOS-окна Windows) стандартной является так называемая
«альтернативная» кодировка, или кодовая страница 866. Все русскоязыч-
ные письма FidoNet пишутся и передаются, как правило, в этой кодовой
странице;
□ KOI8. Эта кодировка (кодовая страница 878) пришла из мира UNIX. До сих
пор она остается одной из двух основных кодировок русских букв в Internet,
где UNIX как хостовая система чрезвычайно распространена. Получить зако-
дированное в КО 18 письмо - обычное дело. В этом случае текст выглядит
(при отображении в кодовой странице 866, стандартной для FidoNet) как на-
бор псевдографических символов (рис. 10.11);
□ СР1251. Эта кодировка Windows, введенная как фирменный стандарт
Microsoft, в силу популярности упомянутой ОС (операционной системы)
стала чрезвычайно распространенной, в том числе и в Internet. Пример
внешнего вида письма в кодовой странице 1251 приведен на рис. 10.12. Так
оно выглядит при отображении в альтернативной кодировке.
Для раскодирования полученного в KOI8 или Windows 1251 письма обычно
используются утилиты-перекодировщики. Нетрудно найти подходящий переко-
дировщик, например, автор использует DOS-утилиты или универсальный пере-
кодировщик PMCLICO для OS/2, работающий непосредственно с содержимым
буфера обмена операционной системы. Количество возможных вариантов подоб-
ных программ велико. Следует отметить, что, как правило, для перекодировки со-
общение должно быть предварительно записано в файл (как это делается при про-
смотре писем в редакторах сообщений - см. главу 12). Под Windows для чтения
текстов, полученных в кодировке СР 1251, можно использовать системный буфер
обмена (Clipboard) и любой редактор текстов, например Notepad (при отображе-
нии теста должны использоваться стандартные для Windows кириллические шриф-
ты в кодировке СР1251).
. Удобным средством перекодирования для любой операционной системы мо-
жет служить HTML-браузер (Internet Explorer, Netscape Navigator и т.п.), так как
в браузере обычно есть средства для перекодирования между популярными для
русского языка кодовыми страницами. Нужно записать текст в файл и затем от-
крыть этот файл из браузера, выбрав желаемую кодировку в меню.
7-битная инкапсуляция в тексте письма
На заре развития глобальных сетей многие каналы передачи данных поддержива-
ли только 7-битную передачу, которой вполне хватало для работы в текстовом
режиме с использованием букв латиницы (для их кодирования используются пер-
вые 7 бит каждого байта). При попытке передать 8-битный код по таким каналам
информация неминуемо портилась. Для того чтобы обеспечить передачу 8-бит-
ной информации по 7-битным каналам, были изобретены протоколы передачи
файлов, поддерживающие 7-битную инкапсуляцию (Kermit, Zmodem), а также
методы 7-битной инкапсуляции в текст письма двоичных файлов (то есть таких
блоков информации, где нет ограничений на диапазон используемых битов). Это
уже неоднократно упоминавшиеся стандарты UUENCODE, BINHEX, MIME, из
которых наиболее распространенным в Internet является MIME [10.5].
При посылке электронного письма в Internet нельзя заранее сказать, будет оно
закодировано в MIME или нет, так как многие почтовые программы в Internet
автоматически кодируют 8-битный текст (а буквы русского алфавита требуют для
представления 8 бит). Поэтому получение MIME-письма из Internet через шлюз
Internet<=>Fido - самое обычное дело, и надо уметь раскодировать его. Иногда
к письму бывает прикреплен файл, который всегда кодируется MIME или (реже)
UUENCODE, так как в Internet не поддерживается передача файлов, прикреп-
ленных к письму, иначе как посредством инкапсуляции (в отличие от FidoNet).
2? .Fleetstreet J24.1- SYSOP'S „MAIL (N) _ _ _ □ □ j
File Edit Message Special Rexx Setup Windows Help
From: Amir Shabashvili 2:5049/12 24Feb2000 n oo32
To:Amirko 2:5049/12.12
_,Subj:№M. Lfbu хр-^ртг ^гр^г
Attnb' I pnv local read
^“•Ч+rr4 .u-i- Чтч- -It тЧЧ^Ь WH“lr т^г₽Чтг p^W тгЯ-
Щг “ЯР^* Unix T^“ 1гРЧНН* &OI8 h'r~ ^МРт ^PHrlrP" 87$) • <H= Llr^ ^P *
AILLLf LU X_jpi rr - b ^HP+F * f »#Це+К IH Unix ILULUXl^ 1
IL«IlLl~X |pi.jJJ |14IJLL pXU-p=LILLpljL|^L4 gX|L|-||-I-L А|-И==Ц p^l^^pJ=|J^UU=L K0I8 -
адЖ;
7*? 5 ;б'7'7 '=' 7 7', 77'7'7 /7'72'77^7; 7 77\ \';77? 'У;':-^"^? ;7Й "%FF^;':a
* Origin: Double Dozen [http://ashabash.zarech. ru] (2:5049/12)
|||i|||i|f|j||J||||||JJ|j|||^
Рис. 10.11. Отображение русского текста в кодировке КО 18
при просмотре в Fido-интерфейсе
-^Я Fleetstreet 1.24.1 - SYSOP‘S_MAIL (Н)_______________________________________________;_______, UjDi
File Edit Message Special Rexx Setup Windows Help
2:5849/12
2:5049/12.12
From:Amir Slxabashvili
To:Amirko
24 Feb 2000 11:00:32
B| €к> €хё£ фы ярютхр-ьш ярртшы№эк>ё€ш -ыофшрк>т-ьш
priv local read
Hello Amirkol
/7 ;'7''V,f' U\, '''"''''' '''',' ' ' / " . ' ' ' ,'У''^'' >'7' Y '"' i- ''''"У^,Г'' "6'''',
Iею ъюфшрютър Windows/ ттхфхээр ъръ Хшрьхээ/щ ёСрэфррв Microsoft, ею т
ёшые яюяеы рэюёвш Windows ёСрт^р урхчт^урщзю ррёярюёвррэхээющ, т €юь ушёых
ш т ^eGxpsxe. ipnibxp тэх°зхую ппфр яшёК^ьр т ъюфютющ ёбррош^х 1251, ъръ юэю
ashabash@zarech. ru
^7Й^ЖЖ?^:Рр,?7'>Г/''и;7Р 7' / .7Р7'?7; 7'^/5777, .77/р 'Р;/Чр
* origin: Double Dozen [http://asbabash.zarech.ru] (2:5049/12)
^8
рв»и
Г 10:1
2:5043/12
Рис. 10.12. Отображение русского текста в кодировке Win 1251
при просмотре в Fido-интерфейсе
На рис. 10.13 приведен пример подобного письма. MIME-инкапсуляция рас-
познается по строке:
Content-Transfer-Encoding: base64
Иногда встречается также служебная строчка вроде
X-MIME-Autoconverted; from 8bit to base64 by hector.zarech.ru
id GAA01066
где прямо указан адрес сервера, перекодировавшего ваше письмо из 8-битной ко-
дировки в MIME. На рис. 10.13 такой'строчки нет. Это письмо пришло в 8-бит-
ной кодировке, a MIME в нем использован для кодирования бинарного файла,
имя которого можно прочитать в строке:
Content-Type: image/jpeg; name="znak.JPG"
В Internet декодер MIME обычно встроен в программу чтенця электронной
почты, в FidoNet вам придется найти и использовать какую-либо внешнюю
утилиту для декодирования: MIME, UUENCODE и BINHEX существуют для
всех операционных систем. Для декодирования понадобится записать текст
письма в файл на диске и «натравить» на него одну из таких утилит. Так, для
У? Fleetstreet 1.24.1 - SYSOP'S_MAIL (N) i ° iai
File Edit Message Special Rexx Setup Windows Help
о^|н1Ыи|№| 9 IwlitlEbl a|
From: ashabash@zarech. ru
To: Amir Shabashvili
2:5029/128
2:5849/12
24 Feb 2000 11:09.20
Subj: Test for MIME encapsulation
t J P1^rcvc* 'oca^гв^
Tue/ U NOV 19$$ 11:'2$:Й +0300 (MSK) ' . J ' L
From: Amir Shabashvili’* <ashabash@zarech.ru>, . ' J
Reply-To:: x«Amir/ShabashviXi'’*^ <ashabash^zarech. ru> ' -t ' A . AA>p
Content ’Type: \text /plain; "chars et ==H ko 18’X« ' . , - : , ' Il
Contenb’Transfer’Encoding^ Bbit ' Д ' Xddhional message info ..................................." "To]
' " — hj;:' ' - . ©MSGID: hector.zarech.ru 4d2ddl9f Ы.
ПрИВвТ, Amiri . - ©RFC-Received: fromhector.zarech.ru (hector.zarech.ru [A
~ A; ; 4 ' . > ©RFC-Received: from argus.zarech.ru (ashabash©argus.zare \
Это' тест .MIME-инкапсуляции - ' orfc-mime- :
-A ... 5 A ‘ ©RFC-Content-Type: multipart/mixed; boundary="_=_=_=IMA. \
> ' '' Wia ifmail 2:5020/128©fidonetz Tue Nov 16 1999 at 11:26 .
inoe здоровье, ' г ' Г ' ©Via 2:5020/204 FTrack 2.04.bl/W32 16 Nov 1999 11:37:18 A
Amirko '> " - ©via 2:5049/12@FidONet ©19991116.115243.60.UTC Itrack-
’BOUNDARY. FbAWlJ87............................- , h .............. . '
Cont ent - Type: * 'image/j peg; name- H znak. JPG :• [ Close 11 Copy [ Help j □ Keep in front
Cont ent '-Transfer ’Encoding; base64 > L,____________________________ _____
/$j/4AAQSkZJRgABAgEASABiAAD//gAmRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Kvc2hvcKggr J / A
NS4w/t4AI0Fkb2^1AGSAAAAAAQMAEAMeAwYAAAAAAAAAAAAAAAD/2^CEAAwICAgJCA^JCQwRCwoL . :
ERteAwPFRgTExVTWW3A^A^EQW^Aw№AvWAi^A^Ai«)A^№AwMDAv«AwBI)QsU)Q4N ' .
EA40EBQ0I)g4UFA40Dg4UEQw^Ai^lE^AwI®AwlDAW0AvM)A^©A^MDAv«)AwMDAi^AwMDAwM
DP/CABEI^BXgMBIgACEaEDEQH/xADmAAABBQEBAAAAAAAAAAAAAAADAQIEBQYHAAEAAgMBAQEA ' м
| [™1953of2513 I 23049/12
Еис. 10.13. Заголовок, служебные строки и часть текста письма, содержащего
бинарный файл, инкапсулированный с использованием MIME-кодирования
декодирования письма, изображенного на рис. 10.13, была использована DOS-
утилита munpack.exe:
С:\FIDO\TMP>munpack mime.msg znak.JPG
Довольно часто при больших размерах (больше 10 Кбайт) письмо, идущее из
Internet, автоматически разбивается на несколько частей. На рис. 10.14 приведе-
на вторая часть письма, начало которого изображено на рис. 10.13. В FidoNet эта
часть пришла отдельным письмом, заголовок и фрагмент текста которого пред-
ставлен на рис. 10.14.
Как видно из приведенного примера, никакой информации о М1МЕ-кодирова-
нии, кроме самого кода, в этом письме уже нет. Для «сборки» исходного письма
нужно записать все полученные части последовательно в один файл и удалить
с помощью текстового редактора незначащие с точки зрения MIME-кода симво-
лы (адресную информацию, заголовок письма и т.п.). Тогда можно будет восполь-
зоваться утилитой раскодирования MIME.
Очень часто используется простой тип кодирования, когда каждая буква, код ко-
торой не укладывается в 8 бит, кодируется двумя символами: код этой буквы в шест-
надцатеричном представлении и знак = в качестве разделителя, что делает русский
текст письма абсолютно нечитаемым. Вот как, например, выглядит текст данного аб-
заца в таком кодировании, называемом обычно Quoted-printable (рис. 10.15).
FteetStreet 1.24.1 - SYSOP’S^MAiL (Ю________________________р jo
File Edit Message Special Rexx Setup Windows Help
4—|ка| .^[►1 :®®|Г&Н1-о|Д|вЫа1НГ9
.; ------ . .. ...... . ‘ . . ... . ‘. ‘ ' ' . . ' ... _i ' " >
From: ashabash@zarech . ru ,
To:Amir Shabashvili
Subj: Lpart 3j Test far MIME encapsulation
Altnb J priv rcvd read
Versions 1.0 a <' . - 4 , ' г - v
From:' «Amir Shabashvili»'<ashabash@2^rech.ru> . /
Reply;To: «Amir Shabashvili’* <ashabash(&zarech.ru>/
2:5020/128
2:5049/12
16Nov1993 ИВИ
16 Nov 1333 11:26:14
1
* Continuation 2 of,a'split ____'____
\ ' .|й: Additional message info
SQr ZoGyHGdl 11 u J* 2 /y£ ecdRrNJOqCH'
/ УоуЖСде AI GmQXp 9 в Jc i LOuRHWSt1Tb
MRcMQvt3 ZVj 8 jU8*4hkaVzdm7oJbgtp
1 wraMj HVk8D8eS/sVhHoNVRNbAD^Y/x'
F2UtADre69₽lpmxa4IA5DhrypFgFyI Z
W5a9 XlWpQCS Ni VUA2 OAs tGRolPTdsbk.
Ш2 NqvlFAQFFuPogUPl FmR2 Ra4 J9 LezW
mi8jTS9Xtt+Zll58a6TBc07-tIouxg
s 9 j c j j qB j+4KRYx 14 wj Z IBpZ j pmP ixo.
@MSGID: hector.zareoh.ru 03412788
@RFC - Received: f r om hec tor .zarech.ru (hec tor .zarech.ru [ i
@RFC-Received: from argus.zarech.ru (ashabash@argus.zars
©RFC-MIME-
@RFC-Content-Type: multipart/mixed; boundary;
@Via
=IMA.
ifmail 2:5020/128@fidonetz Tue Nov 16 1999 at 11:26
@Via 2:5020/204 FTrack 2.04.bl/W32 16 Nov 1999 11:37:18 },
©Via 2:5049/12@FidoNet @19991116.115243.61.UTC Itrack- 11
@Via
Close ] j Copy 11 Help | □ Keep in front
LjUAcRYej3aAwgxFWsdTah0b£XRdAeGgxdhk3'4JlIlA^^£E2/5v2;V0x7agb3’AF^6algscBa3Tb
r 8qNo4QBx00FdCQ6 SGwvRBi iA5 9 PhRB j i tbmvKs WO9 tQB£hRG№ry43BFACJDj 4Lel £dx/mo4omv
Gw8K6VQHiQBrevIm^jSgGW03IWvxqzql7AitY4yo0Nxp6qACRn84Fre£9Gg00iio,ge£,H6KYmNLNx
OJ/TpQtGmPNceXla/9k=
BOUNDARY,. FIAW138764*
Г ШБоГгЬз’ j............2:5049/12
Рис. 10.14. Пример разрезанного на части письма с кодированным MIME-файлом
£1>;ASЛ
AsC/а-х Т</ТТа
=8E=E7=A5=AD=EC =Е7=А0=Е1=Е2=АЕ =A8=E1=AF=AE=AB=EOA7=E3=A5=E2=E1=EF =Е2= |
=А0=АА=А6=А5 =AFp=AE=El=E2=AE=A9 =E2=A8=AF =AA=AE=A4=A8p=AE=A2=A0=AD=A8=EF= J;
, =AA=AE=A3=A4=A0 =AA=A0=A6=A4=A0=EF R
=A1=E3=AA=A2==AO, =AA=AE=A4 =AA=AE=E2=AEp=AE=A9 =AD=A5 =E3=AA=AB=A0=A4=EB= B?
=A2=AO=A5=E2=E1=EF =A2 8 =A1=A8=E2, =AA=AE=A4=A8p=E3=A5=E2=El=EF =A4=A2=E3= J
=AC=EF =El=A8=AC=A2=AE=AB=A0=AC=A8r ||
=AFp=A5=A4=El=E2=A0=A2=AB=EF=EE=E9=A8=AC=A8 =AA=AE=A4 =ED=E2=AE=A9 =A1=E3= g
=AA=A2=EB =A2 16-p=A8=E7=AD=AE=AC =AFp=A5=A4=El=E2=A0=A2=AB=A5=AD=A8=A8, =A8=S
=A7=AD=A0=AA=AE=AC "=" «
=A2 =AA=AO=E7=A5=E1=E2=A2=A5 p=A0=A7=A4=A5=AB=A8=E2=A5=AB=EF, =E7=E2=AE =A4= <
=A5=AB=A0=A5=E2 p=E3=El=El=AA=A8=A9 =E2=A5=AA=E1=E2 =AF=A8=E1=EC=AC=AO =A0= P
=A1=E1=AE=AB=EE=E2=AD=AE
=AD=A5=E7=A8=E2=A0=A5=AC=EB=AC. =82=AE=E2 =E2=A0=AA, =AA =AFp=A8=AC=A5p=E3=
, =A2=EB=A3=AB=EF=A4=A8=E2 =E2=A5=AA=E1=E2 =ED=E2=AE=A3=AE =A0=Al=A7=A0=E6= [S
=A0 =A2 =E2=A0=AA=AE=AC У
=AA=AE=A4=A8p=AE=A2=A0=AD=A8=A8, =AD=AO=A7=EB=A2=AO=A5=AO=AE=AC =AE=A1=EB= I?
=E7=AD=AE "Quoted-printable" (=E1=AC. =9O=A8=E1=E3=AD=AE=AA 10.12) : b
Рис. 10.15. Отрывок текста в кодировке Quoted-printable
Ничего сложного в раскодировании такого текста нет, это делают многочислен-
ные утилиты, и если вы не чужды программированию, можете написать на любом
языке программирования собственный декодер. Необходимо подчеркнуть, что
MIME-инкапсуляция не снимает проблему кодирования текста. Раскодирован-
ный текст может быть в любой из описанных выше кодировок и его необходимо
преобразовать в вид, понятный для чтения.
Стандарты на шлюзование почты между FidoNet и Internet
Утвержденного Fido-стандарта на шлюзование с Internet не существует, но есть
несколько предложений (FSC), которые полезно прочитать. Это уже упоминав-
шийся FSC-0034 [10.2], содержащий полный (на то время) обзор всех проблем
и подходов к организации шлюза Fido-Internet, а также FSC-0035 [10.4], где опи-
саны важные и используемые кладжи Reply Addr и Reply То (они предназначены
для обеспечения гейтования между FidoNet и подобными ей сетями). Полезное
обсуждение кладжа MSGID содержится в FSC-0083 [10.6]. Также вопросам межсе-
тевого взаимодействия посвящен документ FSC-0064 [10.7], где введены дополни-
тельные кладжи (о практике их использования мне ничего не известно, но сам до-
кумент очень интересен).
Шлюзы между эхо-почтой FidoNet
и news-конференциями Internet
До сих пор, говоря о передаче почты между FidoNet и Internet, мы имели в виду
передачу личной почты, E-mail в терминологии Internet или netmail в FidoNet.
Шлюзы между системами news-конференций UseNet/Internet и эхо-конференция-
ми FidoNet возникли почти одновременно с почтовыми. В начале существования
FidoNet, когда эхо-почта еще не была распространена, это были односторонние
шлюзы из UseNet в локальные базы на BBS, затем с развитием эхо-почты были
созданы полноценные программы шлюзов для конференций.
Это те же UFGATE (MS DOS) и UU2 (MS DOS, OS/2), использовавшие UUCP
как протокол доступа к Internet, и более новые Ifmail (UNIX) и Fidogate (UNIX,
OS/2, DOS, Win32). Благодаря работе множества шлюзов эхо-конференции FidoNet
хорошо представлены в Internet в качестве news-конференций; российские эхи
гейтуются сейчас в иерархию fido7. Вы можете попробовать получить их с news-
сайта провайдера, с бесплатного открытого news-сервера news.fido7.ru или почи-
тать через WгEB-интepфeйc на сайте dejanews (http://dejanews.com).
Практическая работа постмастеров таких шлюзов выявила основные пробле-
мы, которые постоянно возникают при их (шлюзов) интенсивном использовании.
Проблемы можно разделить на технические и административные, основные пути
разрешения которых будут указаны далее.
Технические аспекты шлюзования между эхо-конференциями
FidoNet и news-конференциями Internet
Основные проблемы при передаче конференций между Fido и Internet заключа-
ются в неадекватном преобразовании адресной и контрольной информации гей-
ту емых писем. Технология передачи news-конференций Internet, а именно распро-
страненный сейчас повсеместно протокол NNTP [10.8], использует уникальные
идентификаторы сообщений и технологию SENDME/IHAVE для исключения
дублированных сообщений. Суть технологии SENDME/IHAVE заключается
в предъявлении принимающей стороне идентификатора каждого сообщения, под-
готовленного к передаче (команда IHAVE <msgid>), на основании чего принима-
ющая сторона либо получает сообщение, либо отказывается от него.
Такой подход к передаче news-конференций практически исключает дублиро-
ванные письма. Однако, как известно, в Fido был выбран другой путь: архивиро-
ванный пакет эхо-почты принимается и уже на месте, на основании контрольной
информации о квалифицировании некоторых писем как дублированных, решается
вопрос об их дальнейшем распространении. Этот способ эффективнее SENDME/
IHAVE-технологии, в особенности при правильном построении топологии рас-
пространения эх. Однако при ошибках в построении эхо-линков (а они случают-
ся) FidoNet способна производить огромное количество дупов, если не использо-
вать разработанные для исключения этого контрольные механизмы - MSGID-,
SEEN-BY- и РАТН-кладжи.
Опасность искажения контрольной информации при гейтовании несуществен-
на, пока письмо, прошедшее шлюз, не возвращается в FidoNet. Но если прошед-
шее гейт письмо снова попадает в FidoNet (a Ifgate, например, использует именно
такой подход к тоссингу Fido-почты), то последствия могут быть самыми непри-
ятными. Единственное, что можно посоветовать, - внимательно подходить к кон-
фигурации подобных программ.
Что же касается news-сообщений, попадающих в FidoNet из Internet, то в этом
случае программа шлюза должна обеспечить генерацию правильных служебных
строк - уникального MSGID, PATH и SEEN-BY.
Подводя итог, можно сказать, что шлюзование эхо-конференций должно обес-
печивать:
□ соответствие посылаемых в FidoNet сообщений стандартам FidoNet (глава 4);
□ соответствие посылаемых в Internet сообщений стандартам Internet (см. [2.9]);
□ сохранять служебные строки эхо-сообщений и обеспечивать их восстановле-
ние при вторичном попадании гейтованного письма в FidoNet;
□ сохранять служебные строки news-сообщений и обеспечивать их восстанов-
ление при вторичном попадании гейтованного письма в Internet.
Административные аспекты шлюзования между
эхо-конференциями FidoNet и news-конференциями Internet
News-конференции Internet и эхи FidoNet, хотя и представляют собой «родствен-
ные» системы, однако их развитие происходило независимо друг от друга, поэто-
му и обычаи координирования, оформления писем, модерирования конференции
у них абсолютно разные.
Для Internet характерно пренебрежение объемом цитирования: очень часто все
письмо, на которое ссылается в своем ответе автор, целиком помещается в конце
сообщения. Для FidoNet такая «роскошь» неприемлема, чаще всего избыточное
цитирование в правилах конференции запрещается явно. К тому же характерные
для news-конференций обильные многострочные подписи с перечислением всех ти-
тулов пишущего и его полных координат вызывают у участников Fido-конферен-
ции, пересылающих за свой счет по сети весь этот «мусор», только раздражение.
Стиль модерирования FidoNet, подробно описанный в главе 7, в Internet не
используется; здесь под модерированием понимается так называемое пре-моде-
рирование: письмо помещается (или не помещается) в конференцию по указанию
модератора. Поэтому для пользователя Internet получение письма от модератора
FidoNet-эхи (модераториала) - нечто совершенно новое и непонятное.
Искажение кодировки письма, прежде всего кодировки букв кириллицы, дела-
ет письмо нечитаемым для FidoNet-части конференции. Этот случай при прохож-
дении шлюза из Internet в FidoNet встречается достаточно часто.
Все названные проблемы на сегодняшний день полноценного и окончательно-
го решения не имеют, поэтому на практике используются следующие простые
подходы:
□ запрещение гейтования конференции - крайняя мера, которая нередко при-
меняется в Internet, например, не гейтуются эхи иерархии R5 0 . SYSOP. *
и некоторые другие;
□ запрещение гейтования из Internet - полумера, так как в Internet, в отли-
чие от FidoNet, все письма будут видны, в том числе ответы пользователей
Internet на письма из Fido;
□ запрещение гейтования для какого-либо пользователя или домена - способ,
применяемый при вызывающем поведении какого-либо пользователя из
Internet или при спам-атаке с нескольких адресов какого-либо домена Internet.
Все перечисленные меры реализуются с помощью гейтмастера шлюза. Нали-
чие «живого» гейтмастера.является необходимым условием работоспособности
шлюза; даже очень хорошо настроенная гейт-программа не способна порой спра-
виться с простейшей проблемой без его участия.
Популярные программы
Доступных программ для организации шлюзов с Internet не так много, как, на-
пример, почтовых программ FidoNet, поскольку они не столь часто бывают нуж-
ны. Большинство из них написаны не для MS DOS и Windows, так как эти опе-
рационные системы никогда не были основными в Internet. Самые известные
и совершенные шлюзовые программы созданы для UNIX и OS/2.
Документирование настройки и работы таких программ оставляет желать луч-
шего: подчас документация исчерпывается файлом Readme и примером конфигу-
рации. Тем не менее все перечисленные в этом разделе программы работоспособ-
ны и могут с успехом применяться, что подтверждает практика их использования.
Существует два основных типа программ-шлюзов. В первую очередь это про-
граммы, рассчитанные на UUCP-соединение. С UUCP начиналось взаимодей-
ствие Fido и Internet, и такие программы есть под MS DOS и под OS/2, они
документированы и достаточно удобны в настройке, но в настоящее время
UUCP-доступ к Internet - чрезвычайная редкость. Программы, использующие
протокол NNTP и средства обработки конференций операционной системы UNIX
для гейтования эхо-конференций FidoNet, представляют другой класс шлюзов.
Эти шлюзы сейчас в основном и используются. Почти все программы такого типа
написаны под UNIX (могут быть портированы под OS/2 и Windows NT). При на-
личии on-line соединения с Internet использовать следует именно их.
Особняком стоит программа IGATOR, реализующая персональный почтовый
шлюз с использованием клиентского подключения к Internet.
Шлюзы UUCP (UU2, UFGATE, LuckyGate)
К программам, предназначенным для создания шлюза с Internet на основе UUCP-
соединения, относятся такие пакеты, как UFGATE (MS DOS), уже упоминавший-
ся в этом разделе, UU2 (MS DOS, OS/2) Дмитрия Завалишина, а также LuckyGate
(OS/2), автором которого является Павел Гульчук.
Примером работы программ этого типа может служить пакет UU2, долгое вре-
мя использовавшийся для организации шлюза с Internet в регионе 50. Получить
эту программу можно в Internet с адреса:
http://www.kiarchive.ru/pub/os2/fido/
Все программы, рассчитанные на UUCP (и UU2 не исключение), работают как
преобразователи форматов/перекладыватели файлов между входными и выход-
ными директориями Fido-системы и пакета, реализующего UUCP-соединение.
Делается это либо на одном компьютере, в пределах его системы локальных уст-
ройств хранения (жестких дисков), либо используется соединение через локаль-
ную сеть. Получается удобная, простая, легко контролируемая система. Схемати-
чески описанный процесс изображен на рис. 10.16.
Ниже дан более подробный обзор работы программы UU2.
Рис. 10.16. Схема работы Fido <=> UUCP
Работа UU2: передача нетмейла из Fido системы в UUCP
Для выполнения этой задачи предназначена утилита fido2uu.exe.
Алгоритм ее работы следующий:
1. Просматривается нетмейл-фолдер на предмет наличия писем, которые име-
ют в качестве адреса назначения адрес, обозначенный в конфигурации UU2
как собственный адрес UUCP-шлюза, а в имени пользователя встречается
символ @ (то есть это Internet-адрес, вроде ashabash@ksu.ru). Есть также воз-
можность задать «магическое имя пользователя» (обычно UUCP), которое
также будет сигналом к обработке.
2. Каждое найденное сообщение преобразуется в UUCP-формат следующим об-
разом:
- адрес, с которого отправлено письмо, отыскивается в конфигурационном
файле программы (в файле users) и заменяется соответствующим UUCP-ад-
ресом, если таковой имеется. Если находятся совпадения, то используется
первое. Если адреса отправителя нет в списке пользователей users, то сооб-
щение обрабатывается как письмо от незарегистрированного пользователя
(возможно, с некоторыми ограничениями). В этом случае адрес преобразует-
ся в описанный цыше fidonet.org-формат:
< Имя> [. <Фамилия>] @ [р<пойнт>] . f<узел>. п<сеть>. г<зона>. fidonet. огд;
- если имя пользователя, которому предназначено письмо, содержит @, то
оно используется как UUCP-адрес назначения. В противном случае в пись-
ме выбирается строка вида То: <ииСР-адрес>, и UUCP-адрес из нее ис-
пользуется как адрес назначения;
- письмо сканируется на предмет наличия СС-строк (дополнительных ад-
ресов назначения в Fido-стиле), которые преобразуются в формат RFC-822
и добавляются к результирующему письму как информация о том, кому
еще было послано данное письмо;
- письмо сканируется на предмет наличия специальных (распознаваемых
только UU2) строк вида ХСС: <UUCP-адрес >. Это тоже дополнительные
адреса назначения, но в стиле Internet. Эти строки также становятся СС-
строками результирующего сообщения, и, кроме того, письмо рассылается
по всем этим UUCP-адресам;
- перед посылкой по любому из адресов, если пользователь не является заре-
гистрированным, производится проверка на правильность во всех элемен-
тах, кроме имени пользователя (правила проверки задаются в конфигура-
ции программы);
- письмо просматривается далее, отыскиваются все другие служебные стро-
ки и конвертируются в UUCP-заголовки.
Работа UU2: передача нетмейла из Internet в Fido
За процедуру пересылки почты из Internet в FidoNet отвечает утилита
uu2fido.exe. Эта программа запускается вместо обычной утилиты доставки поч-
ты (rmail или sendmail). Проще всего переименовать uu2fido.exe в sendmail.exe
или rmail.exe в соответствии с названием имеющейся утилиты. Оригинальную
программу нужно при этом сохранить - она понадобится для посылки почты
по UUCP.
Если ваша система UUCP поддерживает вызов внешнего мейлера для отдель-
ных доменов, то uu2fido.exe может выступать в качестве такого мейлера.
Конвертирование формата RFC-822 в Fido-формат достаточно очевидно
и в общих чертах соответствует приведенным выше в этой главе примерам. Правда,
UU2 ставит в кладж MSGID не истинный Internet-адрес, а Fido-адрес гейта.
Работа UU2: передачу эхо-мейла из Fido системы в UUCP
Задача построения шлюза между news-системой Internet и эхо-конференциями
FidoNet сложнее, чем создание шлюза только нетмейл <=> E-mail. Для этой цели
в пакете UU2 используется несколько утилит: rnews.exe и unbatch.exe для преоб-
разования news-конференций в эхи и snews.exe и batch.exe - для обратного пре-
образования. Вот как работает система UU2 при передаче эх в Internet:
□ эхо-процессор создает пакет с письмами в формате *.pkt, как это описано
в главе 8. Архивация при этом использоваться не должна. Возможность
создавать сархивированные пакеты есть во многих эхо-процессорах.
Такой пакет должен быть направлен на адрес, заданный в конфигурации
шлюза;
□ утилита snews.exe, запущенная с ключом -s (scan), ищет прикрепленные
к письмам эхо-пакеты, преобразует их в формат RFC-822 и удаляет исходные
файлы *.pkt. Можно также вызывать snews.exe как внешний архиватор в эхо-
процессоре, так чаще всего и делается;
□ из директория, где snews сохраняет свои выходные пакеты, их забирает утили-
та batch.exe и преобразует в news-пакеты для своих UUCP-даунлинков.
Работа UU2: передача эхо-мейла из Internet в Fido
Если один из адресов, на которые послано данное Fido-письмо, совпадает с задан-
ным в конфигурации именем (обычно это newsmaster), то программа шлюза, заве-
дующая передачей электронной почты из Internet в Fido batch.exe пошлет это
письмо и как эхо-мейл (фактически, письмо будет помещено во входной news-
директорий). Конвертирование news-конференций в эхо-пакеты выполняет ути-
лита unbatch.exe.
Полностью процедура конвертирования News-Echomail выглядит так:
1. uu2fido или rnews принимают news-пакеты и помещают во входной дирек-
торий.
2. uu2fido рассматривает как news-информацию все, что послано на Newsmaster.
3. Содержимое этого директория обрабатывается программой unbatch.exe, кон-
вертирующей news-пакеты в *.pkt эхо-пакеты, адресованные на ваш узел, где
они помещаются во входной директорий вашей Fido системы.
Так в общих чертах работает UU2, аналогично работают и другие Fido-UUCP
шлюзы. У них много достоинств, а недостаток всего один, зато существенный -
редкость UUCP-доступа в наше время, мало кто из провайдеров Internet его пре-
доставляет своим клиентам. Зато Internet on-line популярен и общедоступен,
и если он у вас есть и существует намерение создать шлюз между Fido и Internet,
то самое время задуматься об установке одной из описанных в следующем разде-
ле программ.
Шлюзы NNTP (Ifgate и FidoGate)
Эти программы представляют собой пакеты, написанные на компиляторах GNU
(описание проекта - в главе 1) для UNIX и в стиле UNIX. Они доступны в исход-
ных текстах и могут свободно распространяться, дополняться и изменяться, вклю-
чая перенос (портирование) под любые операционные системы.
Известны порты FidoGate под OS/2, MS DOS, Windows 95 и Windows NT.
О существовании портов Ifgate под UNIX-несовместимые операционные сис-
темы мне ничего не известно.
Программа шлюза из пакета Ifmail (Ifgate)
Ifgate является частью набора программ Ifmail Евгения Черкашина, уже упоми-
навшегося в предыдущих главах. Кроме Ifgate, в пакет входит также Ifcico, пред-
ставляющий собой полнофункциональный Fido-мейлер.
Одним из недостатков Ifmail является почти полное отсутствие документации.
Сама программа является вполне работоспособной и широко используется для
организации Fido-систем под UNIX в России и по всему мировому Fido-сообще-
ству. Для первоначального ознакомления с системой достаточно прочитать статью
автора [10.9], представленную в 1998 году на конференции ассоциации USENIX.
Ее можно загрузить в формате PostScript с официального сайта Ifmail:
http://www.average.org/ifmail/
На этом же сайте доступна и другая информация об Ifmail, а также исходные
тексты и исполняемые модули программы. Можно также получить их по прото-
колу FTP:
ftp://ftp.average.org/pub/ifmail/
Автором поддерживается в Internet регулярный список рассылки, посвящен-
ный Ifmail. Для подключения к списку нужно послать письмо на адрес:
ifmail-request@online.ru
поместив слово subscribe в поле SUBJECT письма. Архив списка рассылки нахо-
дится по адресу:
http://www.average.org/ifmail/maillist/
Идеология Ifmail соответствует базовой концепции UNIX; каждый элемент за-
дачи построения шлюза Fido-Internet решается в нем с помощью отдельной про-
граммы. Названием Ifgate объединяются утилиты Fnews (или Ifmail), занимаю-
щиеся преобразованием news-писем в формате RFC-1036 и E-mail-писем формата
RFC-822 в формат FTS-0001, используемый в FidoNet. Программа Iftoss выпол-
няет обратное преобразование.
Какая-либо другая обработка (например, тоссинг по линкам) и маршрутизация
в Ifmail не осуществляется. Для этого используются стандартные UNIX-програм-
мы, занимающиеся почтой и конференциями, например sendmail и inn. Именно
они осуществляют маршрутизацию почты (sendmail) и «раскладывают» эхи по
линкам, или, другими словами, раздают news-конференции (inn).
Такой подход вполне оправдан, так как UNIX-программы - это хорошо ра-
ботающие и оттестированные утилиты, используемые на тысячах компьютеров
в течение многих лет, и на них можно положиться. Благодаря этому Ifmail как
тоссер и нетмейл-роутер представляет собой очень надежную и устойчивую си-
стему, хотя и проигрывающую в эффективности (при одинаковой аппаратуре)
аналогичному по функциям Fido-узлу.
Схема работы Ifgate изображена на рис. 10.17 (этот рисунок позаимствован из
упомянутой выше статьи автора программы). Здесь МТА - Mail Transport Agent
(например, sendmail), NEWS - агент доставки news-конференций, например, inn.
Рис. 10.17. Структурная схема шлюза Ifgate
Алгоритм преобразования писем при шлюзовании в Ifgate уже был рассмотрен
в этой главе. Подчеркнем еще раз его особенность: в отличие от многих других
программ-шлюзов Ifgate реализует такое преобразование форматов, которое по-
зволяет сохранить всю возможную служебную информацию, используя инкапсу-
ляцию типа Х-FTN- для помещения текста кладжей в письмо формата RFC-1036
или RFC-822, и RFC- для Internet-хидеров при преобразовании в FTS-0001 сооб-
щение. Поэтому письмо при двукратном - из Fido в Internet и обратно - прохож-
дении шлюза Ifgate совершенно не искажается, благодаря чему Ifgate может ис-
пользоваться, например, как Fido-тоссер.
Программа шлюза Fido Gate
Автором FidoGate является Мартин Джуниус (Martin Junius) из Германии. По
сравнению с Ifmail FidoGate лучше документирован, но, к сожалению, большая
часть самой полезной документации поставляется на немецком языке. Как
и Ifmail, FidoGate это не только шлюз Internet <=> Fido, но также и Fido-тоссер,
шлюз FTNUFTN, и файл эхо-процессор. Всего в состав FidoGate входит более
тридцати различных программ и скриптов. Отметим только некоторые из них,
чтобы дать читателю представление о функциональной насыщенности пакета:
□ Ftn2ftn - FTN<=>FTN нетмейл шлюз (предназначен для организации нет-
мейл-шлюза между FidoNet-подобными сетями);
□ Ftn2rfc - FTN<=>Internet шлюз (почта/конференции);
□ Ftnaf- Агеайх-менеджер;
□ Ftnbounce - утилита для возврата почты, адресованной на неизвестный FTN-
адрес;
□ Ftnconfig - утилита для чтения конфигурационных файлов;
□ Ftnlog - утилита для записи сообщения в протокольный файл;
□ Ftnpack - утилита упаковки ArcMail-пакетов (FTN);
□ Ftnroute - утилита маршрутизации почтовых пакетов (FTN);
□ Ftntoss - FTN-тоссер;
□ Rfc2ftn - Internet <=> FTN шлюз;
□ Runin - скрипт для обработки входных пакетов;
□ Runout - скрипт для обработки исходящих пакетов шлюза;
□ Runtoss - скрипт для запуска тоссера.
FidoGate можно получить в Internet с адресов:
□ http://www.fido.de/pub/fidogate/;
□ http://sunsite.unc.edu/pub/Linux/system/fido/;
□ http://www.fido.de/fidogate/;
□ ftp://ftp.fido.de/pub/fidogate/;
□ ftp://sunsite.unc.edu/pub/Linux/system/fido/.
Можно рекомендовать использовать FidoGate, если в ваши планы не входит
установка полностью функционального FTN-мейлера на UNIX; доставка почты
до шлюза может при этом производиться либо средствами локальной сети, либо
с использованием FTN IP-мейлера, например Binkd.
Программа IGATOR
I GATOR отличается от вышеописанных шлюзовых программ тем, что это персо-
нальный шлюз, использующий для соединения с Internet-системой электронной
почты персональный почтовый аккаунт. Все упомянутые выше программы-шлю-
зы работают в условиях серверного подключения к Internet и выглядят со сторо-
ны Internet как сервер электронной почты, IGATOR же представлен как один ад-
рес - и со стороны Internet, и FidoNet. Автором IGATOR является Максим
Масютин, автор почтовой Fido-программы Аргус и популярной программы The
Bat, предназначенной для приема электронной почты Internet. IGATOR суще-
ствует только в версии Win32 (Windows95/98, Windows NT).
IGATOR предназначен для двустороннего шлюзования персональной почты,
конференциями он не занимается. Говоря словами автора программы, «IGATOR
обеспечивает возможность участникам FidoNet работать с Internet-адресами
(полученными у провайдеров почтовых услуг), а для написания почты - использо-
вать обычные почтовые средства, используемые в FidoNet, что избавляет их от
необходимости иметь дополнительные программы для работы с Internet-сооб-
щениями и прямое подключение в Internet через SLIP, PPP, UUCP».
Программа поддерживает многопользовательский режим работы и осуществ-
ляет шлюзование почты для описанных в ее конфигурации адресов. При этом вза-
имодействие с FidoNet осуществляется через каталог, в котором хранятся почто-
вые сообщения в формате *.msg (FTS-0001). Если к сообщению из FidoNet
прилагаются файлы, то они посылаются в Internet в виде MIME-сообщения или
кодируются в формате UUENCODE (это устанавливается персонально для каж-
дого пользователя программы).
Требования для работы IGATOR:
□ наличие соединения TCP/IP на машине, где установлен IGATOR;
□ наличие доступа к серверу SMTP, через который будут посылаться E-mail-
сообщения.
Имеет смысл использовать IGATOR, если ваша Fido-система установлена под
Windows и вы используете электронную почту Internet с этой же машины. Про-
грамма хорошо документирована, легко устанавливается, очень компактна, по-
ставляется вместе с исходными текстами (распространяется как Freeware). Полу-
чить ее можно в Internet с адреса:
http://www.ritlabs.com/igator
Шлюзы между FidoNet и другими FTN-сетями
Кроме FidoNet существует и существовало большое количество сетей, работаю-
щих на той же FTN-технологии, что и FidoNet, но отличных от нее организацион-
но. Эти сети никогда не были так велики и популярны, как FidoNet, но многие из
них широко известны. В качестве примера можно привести AlterNet (зона 7), су-
ществовавшую более 10 лет, а также GoodEggNet (зона 99), BBSNet (зона 83)
и многие другие. Возникли первые такие сети в 1987 году после введения строгих
правил существования FidoNet и появления международной ассоциации IFNA,
некоторое время (до ее роспуска в 1989 году) контролировавшей FidoNet.
Все старые FTN-сети прекратили свое существование в 1996-1997 годах, одно-
временно с появлением тенденций по сокращению самой FidoNet. В России су-
ществует множество небольших FTN-сетей. Как правило, они организуются са-
мими участниками FidoNet, чтобы более свободно, не оглядываясь на Полиси
FidoNet и традиции этой сети, вести обмен информацией. Одной из самых боль-
ших FTN-подобных сетей в России является так называемая «седьмая зона», остав-
шаяся от проекта организации новой (седьмой) зоны FidoNet на базе 50-го региона
второй зоны. В сеть Z7 входят около 300 узлов, она покрывает все пространство
России, обеспечивает транспорт нетмейла, эх и файл-эх.
Обычно нет нужды организовывать шлюз между FidoNet и сетью с другим ад-
ресным пространством, поскольку все программное обеспечение FidoNet рассчи-
тано на работу в мультидоменной среде, и вся почта и файлы для разных сетей
будут посылаться по двум сетям независимо (в соответствии с правилами марш-
рутизации).
Однако если такая нужда все же возникнет, то для организации подобных шлю-
зов используются стандартные средства. Суть вопроса изложена в проекте стан-
дарта FidoNet FSC-0004 [2.10] и описана ранее в главе 2 (раздел «Зональные шлю-
зы (ZoneGates)». Есть и специальные программы для организации почтовых
шлюзов между FTN-сетями, например Ftn2ftn, входящая в состав пакета FidoGate.
Заключение
Нет ничего особенно сложного в установке и настройке почтового шлюза между
сетью FidoNet и какой-либо другой сетью. Основные проблемы возникают впо-
следствии, в процессе эксплуатации шлюза, и связаны они, как правило, не с тех-
ническими моментами шлюзования, а с правильной организацией доступа участ-
ников сети к ресурсам шлюза и с заботливым, ежедневным администрированием
его работы. Нужно помнить, что установка общедоступного шлюза между
FidoNet и другой глобальной сетью, существенно отличающейся от нее по тра-
дициям и обычаям, всегда создает потенциальный источник проблем для участ-
ников FidoNet. Через такой шлюз постоянным потоком пересылается реклама
(так называемый спам), бесконечной чередой идут письма с запросами бесплат-
ного сервиса и т.п. Собственно личная переписка, для которой подобные шлюзы
создаются, составляет обычно меньше половины его загрузки.
Поэтому установка публичного шлюза представляет собой очень ответствен-
ный шаг, его поддержка может потребовать много времени и нервов. Помните об
этом, и не говорите что вас не предупреждали.
Глава XI
Передача почты
и файлов FidoNet
с помощью Internet
Перед знакомством с этой главой желательно просмотреть материал по Fido-over-
IP (так обычно называют передачу Fido-информации посредством Internet), из-
ложенный в первой главе, в разделе «FidoNet over IP: сказка нового времени»,
и включающий достаточный для понимания предмета обзор.
В настоящей главе содержится более подробное и точное (и менее эмоциональ-
ное) изложение того же материала. Хорошим введением в технологию Fido-over-
IP может служить статья, написанная Лотаром Бехетом (Lothar Behet) и опубли-
кованная в двух (июль, август) номерах FidoNews за 1998 год [11.1], [11.2].
Основные понятия
Работать в Internet, почти ничего не зная о его внутреннем устройстве (системе
адресации, названиях протоколов и их назначении и т.п.), можно только в том
случае, если вы пользуетесь стандартным клиентским программным обеспечени-
ем для доступа к стандартным же ресурсам Internet, например HTML-браузером
для просмотра WEB-страниц. К тому же кто-то должен установить и настроить
TCP/IP на вашем компьютере.
Применение Internet для проброса Fido-почты и файлов стандартным сервисом
Internet не является, и для настройки используемых программ крайне желательно
понимание сути происходящего. В этом разделе приведены минимально необходи-
мые для этого сведения; рекомендуется также прочитать раздел «Система распоз-
навания имен Internet (Domain Name System)» в предыдущей главе. Для более
подробного знакомства с основами устройства Internet лучше всего обратиться
к специальной литературе, например, можно рекомендовать книги [11.3], [11.4].
Здесь также не рассматриваются вопросы настройки TCP/IP под различными
операционными системами, используемыми для FidoNet. С этим вы должны спра-
виться самостоятельно. Времена, когда настройка TCP/IP была сродни шаман-
ству и право священнодействовать принадлежало исключительно профессиона-
лам, прошли. Сейчас это несложная стандартная процедура, подробно описанная
на страницах руководства к используемой вами операционной системе.
Адреса TCP/IP
В начале предыдущей главы обсуждался формат цифрового и символьного адресов
Internet и говорилось о том, что цифровой адрес в семействе TCP/IP протоколов -
это адрес не компьютера, а интерфейса, то есть канала связи, по которому проис-
ходит соединение компьютера с сетью. У одного компьютера может быть несколь-
ко адресов (по числу интерфейсов), и один интерфейс может иметь несколько ад-
ресов-синонимов. Например, компьютер с адресом 194.67.27.224, известный
в Internet как proxy.zarech.ru, имеет также адрес 194.67.27.54, который является не
просто синонимом: его можно использовать для построения независимых схем
маршрутизации и т.п.
Символьные адреса, которые через систему DNS преобразуются в цифровые,
могут ссылаться на один и тот же интерфейс, но каждое имя должно быть уни-
кальным в пределах всего Internet.
Например, argus.zarech.ru и fl2.n5049.z2.fidonet.net ссылаются на адрес
194.67.27.194. Первое имя используется для адресации компьютера в системе до-
мена DNS zarech.ru, а второе - для проброса Fido-почты через Internet с исполь-
зованием DNS fidonet.net, описанного ниже.
Порты и протокол TCP
Важным параметром TCP-протокола является понятие порта (PORT). ТСР-пор-
том в системе протоколов TCP/IP называется нумерованный логический канал,
через который может производиться обмен информацией между TCP и более вы-
сокоуровневыми протоколами. Всего портов у каждого адреса может быть 65535
(так как для определения порта используется 16-битное беззнаковое целое чис-
ло), и, соответственно, с каждым адресом может быть установлено 65535 одно-
временных TCP-соединений. Все стандартные протоколы Internet, основанные на
TCP, имеют закрепленные за ними порты, через которые они устанавливают со-
единения, если иное не указано в конфигурации соответствующих программ.
Например, популярный высокоуровневый протокол TELNET, предназначенный
для установления свободного от ошибок символьного соединения с удаленным
TELNET-сервером, использует по умолчанию порт 23, а протокол FTP передачи
файлов - порт 21, хотя на практике можно использовать для этих протоколов
и другие входы. Когда нужно указать номер порта, он обычно записывается после
адреса через пробел или (чаще) через двоеточие: 194.67.27.194:21.
Специальные протоколы, разработанные для проброса Fido-почты через Internet,
также имеют порты, выбранные для организации соединений на этих протоколах.
Эти порты не являются (пока) стандартными в Internet, но выбраны так, чтобы не
пересекаться с другими известными портами.
Протоколы
Выше мы часто использовали термин «протокол», теперь введем точное и под-
робное его определение. Протокол представляет собой способ передачи информа-
ции между программами в сети компьютеров и включает соглашение о форматах
данных, способах установления соединения и т.п.
Протоколом в сети Internet называют и низкоуровневые протоколы, аналогич-
ные тем, что используются в локальных сетях и которые почти никогда не «со-
прикасаются» с пользователем (за исключением конфигурирования системы при
инициализации сети), и высокоуровневые протоколы вроде TELNET, FTP или
SMTP, которые по существу представляют собой законченные приложения с ми-
нимальным интерфейсом пользователя.
С серверной стороны такие протоколы обычно называют сервисами.
При передаче Fido-почты через Internet используется протокол TCP и основан-
ные на нем высокоуровневые протоколы (сервисы) TELNET, SMTP, и FTP, кроме
того, есть и специализированные для Fido протоколы IFC, Vmodem и Binkp, так-
же использующие TCP.
TCP известен как протокол, ориентированный на установление соединения.
Этим он отличается от дейтаграммных протоколов, не предполагающих установ-
ления соединения (например, таков протокол UDP). Отдельные блоки информа-
ции (пакеты, датаграммы), передаваемые с использованием таких протоколов, мо-
гут теряться, дублироваться или приходить в неверном порядке - все равно на
приемной стороне программа «соберет» правильный блок данных. Именно так
устроен протокол IP, реализующий межсетевую маршрутизацию и часто исполь-
зуемый как синоним сети Internet (в смысле ее технической реализации). «Бес-
связные» протоколы порой оказываются удобнее для построения сети, так они
пользуются большей свободой в выборе маршрута соединения. Однако для целей
Fido-over-IP применяются, как правило, ТСР-соединения.
Характеристики ТСР-соединения очень удобны для обмена информацией, по-
скольку TCP предоставляет двунаправленный, свободный от ошибок, прозрач-
ный символьный канал, не требующий какой-либо дополнительной коррекции
ошибок. Он использует механизм подтверждений в приеме пакета и при обнару-
жении сбоя запускает повторную передачу, избавляя пользователей от необходи-
мости встраивания в свои программы дополнительной коррекции ошибок, вроде
той, что есть в протоколах Xmodem или Zmodem (тем не менее, эти протоколы
часто применяются и в Internet, и прежде всего из соображений совместимости
с программным обеспечением. FidoNet).
При всех положительных сторонах ТСР-соединения эффект от его примене-
ния отличается от тех результатов, которых можно добиться при обычном для
FidoNet соединении по телефонной линии с помощью модема со встроенной кор-
рекцией ошибок.
Internet-соединение часто непредсказуемо меняет качество связи, задержки
передачи на нем могут оказаться чрезвычайно длительными. В результате ско-
рость скачет в исключительно широких пределах - от нескольких байтов (при
соединении с удаленным сервером) до нескольких мегабайтов в секунду (при
соединении по локальной сети). От этого стандартные протоколы передачи фай-
лов порой могут просто «сходить с ума». В Internet они требуют как минимум до-
полнительной настройки.
Эти особенности должны учитываться при настройке системы для туннелиро-
вания Fido-почты через Internet.
Нодлист и Fido-over-IP
Fido-системы, подключенные к сети только через Internet, с недавних пор могут быть
включены в нодлист со статусом приватных (PVT) систем. Все подробности приве-
дены в стандартах FTS-5000 [11.5] и FTS-5001 [11.6], пришедших на смену FTS-
0005. Так, в способ описания узла были внесены следующие дополнения (см. [11.5]):
□ префиксом HOLD теперь могут обозначаться и независимые узлы, подклю-
ченные к сети только по TCP/IP;
□ третье по счету поле в нодлистовой строчке (название станции) для 1Р-узла
при использовании программ туннелирования через электронную почту мо-
жет содержать его доменный адрес или почтовый адрес E-mail;
□ поле телефонного номера (шестое от начала строки) для приватного 1Р-узла
также может содержать цифровой IP-адрес с кодом ООО -, который является
специальным признаком такого использования поля.
Примеры из текущего нодлиста:
,5492,GRAFT,Hamburg,Andreasjiensel,000-212-121-159-
30,300,CM,MO,IBN
,15,rootOvko.kz,East_Kazakhstn,Evgeny_Leonoff,000-212-19-
142-2,300,MO,CM,ITN
Флаги, используемые для описания поддерживаемых узлом протоколов, отра-
жены в FTS-5001. Они соответствуют ранее применявшимся пользовательским
IP-флагам, которые были представлены в главе 2.
Системы передачи почты Fido через Internet
В этом разделе будет дана примерная классификация способов передачи Fido-
почты в сетях TCP/IP (далее термин «Internet» означает любые сети, где работа-
ет протокольный стек TCP/IP).
Первые системы передачи Fido-почты через Internet использовались для уде-
шевления межзональных линков FidoNet. Со стороны FidoNet на таких системах
устанавливалось UUCP-соединение по коммутируемой линии с UNIX-компью-
тером, и на него передавались (и принимались) упакованные файлы эхо-почты
и нетмейла. Файлы между UNIX-компьютерами также пересылались по UUCP.
Например, такая схема описана в статье Ренди Буша [11.7]. На всех этапах подоб-
ной системы транспорта Fido-почты использовалось off-line соединение, что, во-
обще говоря, противоречит общей идеологии FidoNet, где всегда используется
непосредственное (on-line) соединение между двумя системами сети. Посланные
«в никуда» файлы могли дойти до адресата, а могли задержаться или вовсе не
найти адресата - механизмы контроля доставки отсутствовали, и проверить это
было невозможно. Поэтому, как только получило распространение on-line под-
ключение к Internet (а в 1992 году, когда Ренди Буш написал свою статью, оно
еще было экзотикой), были разработаны другие способы передачи Fido-почты,
в которых использовались как стандартных протоколы и сервисы Internet, так
и протоколы, специально разработанных для этой цели.
Богатый опыт, накопленный за последние годы в построении IP-линков между
Fido-системами, позволил оформить процедуру включения в нодлист IP-узлов со
статусом приватных (PVT) систем.
Однако, несмотря на широкую распространенность и освоенность Internet для
нужд Fido, все же общего и универсального подхода к этой проблеме пока нет.
В настоящее время наиболее распространенный способ - применение протокола
Binkp (см. главы 3 и данную).
Кроме этого популярного протокола широко применяются и другие способы:
□ раздача эхо-конференций по протоколу FTP (в первой зоне есть даже плат-
ный FTP-сервис по раздаче эх);
□ туннелирование через электронную почту;
□ соединение обычных FTN-программ через Internet с использованием Vmodem-
версий драйвера FOSSIL (глава 1, раздел «Виртуальный модем Реймонда
Гвинна»);
□ использование почтовых программ, имеющих встроенную поддержку
ТСР-соединений (Т-Mail, Ifmail).
В следующих разделах все эти способы рассмотрены с той степенью подробно-
сти, какую они заслуживают. Здесь же приведена общая классификация исполь-
зуемых протоколов:
□ SMTP Туннелирование через электронную почту Internet используется доста-
точно широко, особенно в последнее время, когда с развитием услуг Internet
появилась возможность передавать значительные объемы Fido-почты. Этот
способ иногда является единственным выходом, но по причине своей off-line
природы в большинстве случаев может рассматриваться только как вспомога-
тельный, как средство для выдачи пойнт-адреса Internet-пользователю. В этом
смысле он родствен, например, раздаче Fido-почты на дискетах (floppy-net);
□ FTP Передача почты по FTP также в большинстве случаев работает в off-line
режиме, и все сказанное относительно электронной почты относится и к FTP;
□ TELNET. Первоначально именно TELNET был использован как основной
способ для on-line проброса Fido-почты и для доступа к ресурсам BBS через
Internet. TELNET - это высокоуровневый протокол, разработанный для тер-
минального доступа пользователей через сети TCP/IP к ресурсам удаленных
компьютеров. Вообще говоря, TELNET не предназначен для передачи боль-
ших объемов информации, это приоритетный протокол, стандартно работаю-
щий на порту 23, и активное использование его как транспортного протокола
для передачи файлов не вызывает восторга у системных администраторов, так
как ведет к перегрузкам канала. Поэтому рекомендуется применять нестандар-
тные (для TELNET) номера портов. Так, для TELNET в Fido-over-IP обычно
используют порт 60177. TELNET используется известной программой-драй-
вером виртуального модема (Vmodem), описанной в следующих разделах;
□ VMP. Кроме протокола TELNET Vmodem может использовать и свой соб-
ственный протокол VMP, основанный также на TCP-соединении. Это позво-
ляет отказаться от применения высокоуровнего протокола TELNET. Стан-
дартный порт протокола VMP имеет номер 3141;
□ RAW И (IFC). Мейлер Ifcico из состава пакета Ifmail имеет встроенный прото-
кол для организации соединения через Internet. Стандартный порт этого про-
токола 60179, протокол также основан на TCP. Этот протокол, как и TELNET,
поддерживает мейлер T-Mail/IP;
□ Binkp. Протокол Binkp был разработан в качестве специализированного
протокола Fido-over-IP для почтовой программы Binkd Дмитрия Малова.
Надежный и экономичный Binkp не требует использования дополнитель-
ных протоколов передачи файлов, так как является одновременно протоко-
лом Fido-сессии. Сейчас Binkp поддерживают многие почтовые программы
FidoNet.
Большинство используемых протоколов могут обозначаться в нодлисте соот-
ветствующими флагами. В табл. 11.1 сведена информация об используемых для
Fido-over-IP протоколах, портах и нодлистовых флагах.
Таблица 11.1. Протоколы, используемые для on-line проброса
Fido-почты через Internet
Стандартное название протокола Стандартный порт(ы) Флаг нодлиста Примеры программ, использующих данный протокол
VMP 3141 IVM VMODEM (SIO)
TELNET 23(60177) ITN VMODEM, T-MAIL/IP, IFCICO
RAW TCP 60179 IFC IFCICO, T-Mail/IP
BINKP 24554/24555 IBN ARGUS, BINKD, IREX, BEEMAIL
Туннелирование FidoNet
через электронную почту и FTP
Электронную почту можно использовать для пересылки файлов. Современные
системы передачи почты в Internet, как правило, поддерживают пересылку доста-
точно больших объемов - до 1-2 Мбайт на одно письмо. При этом применяется
кодирование бинарных файлов в тело письма по стандарту MIME [10.5] или
UUENCODE. Конечно, электронная почта предоставляет off-line сервис, что
и обусловило (с точки зрения срочности и достоверности доставки данных FidoNet)
ее неустранимые недостатки. Однако в то же время это очень простой, отлажен-
ный и надежный механизм, имеющий самое широкое распространение и «выжи-
вающий» там, где не могут существовать другие популярные сервисы Internet,
например при наличии специфических схем подключения к Internet с использо-
ванием защитных шлюзов-брандмауэров и т.п.
Меньшую универсальность, но и большее удобство с точки зрения применения
для проброса Fido-почты предоставляет популярный в Internet FTP-сервис. FTP
(File Transfer Protocol) - простой и эффективный способ предачи файлов. Уста-
новка и конфигурация FTP-сервера несложна и не требует высокой квалифика-
ции; клиентские утилиты доступа к FTP имеются в составе всех распространен-
ных операционных систем.
FTP также может быть использован для передачи Fido-почты, но для этого нуж-
но иметь доступ на запись к FTP-серверу, с которого ваш корреспондент будет
забирать информацию.
Первоначально для установления линка через электронную почту и FTP исполь-
зовались стандартные утилиты посылки/приема файлов, управляемые из команд-
ной строки, но затем были разработаны специальные программы, позволяющие
организовать разумное взаимодействие с входящим и исходящим директориями
Fido-системы, проконтролировать «отмирание» линка, использовать систему уве-
домлений о приеме очередной порции и не посылать следующую, пока не принята
данная и т.п. Одним словом, они значительно усовершенствуют и упрощают работу
сисопа по поддержанию E-mail или FTP-линка в рабочем состоянии.
К сожалению, единого протокола для совместной реализации подобных проце-
дур пока не существует, поэтому желательно установление на обеих сторонах лин-
ка одной и той же программы. Ниже следует обзор двух наиболее известных из
применяемых программ.
Программа TransX
TnansX (Internet/FidoNet Transporter) распространяется от имени фирмы Multi-
board Communications, и получить последнюю версию можно с WEB-сайта ком-
пании, который находится в Internet по адресу: http://www.multiboard.com.
Программа TransX написана для DOS и Windows 95, но может использоваться
также и под OS/2. Для этой цели отдельно поставляется OS/2-модуль для работы
с почтовым сервером. Основной модуль программы при этом может работать из-
под OS/2 в DOS-окне.
TransX хорошо документирован, имеет установочную программу, работает на-
дежно, и поэтому широко используется (в основном за рубежом) для раздачи
Fido-почты пользователям Internet. Правда, часто этот сервис бывает платным.
TransX выполняет следующие функции:
□ работает как FTN-тоссер;
□ кодирует информацию для отсылки через Internet в одном из следующих
стандартов: MIME, UUENCODE, собственный стандарт TransX, а также рас-
кодирует пакеты, полученные по электронной почте через Internet;
□ использует различные способы и сервисы для подключения к Internet:
- SMTP/POP3 (протокол POP3 применяется обычно для получения элект-
ронной почты с минимальной идентификацией, а протокол SMTP - для от-
правки без какой-либо идентификации);
- UUCP;
- FTN-Internet шлюзы;
- FTP;
□ обеспечивает безошибочную доставку пакетов до адресата, используя служеб-
ные письма-сигналы;
□ имеет в составе утилиты для отправки и приема электронной почты по про-
токолам SMTP и POP3 соответственно;
□ настраивается на работу совместно с большим количеством различных Fido-
программ, мейлеров и тоссеров (например, с GEcho, FastEcho, iServer,
FrontDoor, D’Bridge, Binkley Term, Platinum Xpress, PCBoard, QFront и мно-
гими другими).
Работает TransX следующим образом: при запуске основного исполняемого
файла tx.exe просматривается исходящий директорий Fido-системы на предмет
наличия почтовых пакетов для узлов, адреса которых указаны в конфигурации
программы; найденные пакеты кодируются в Internet-формат RFC-822 и отправ-
ляются через имеющееся соединение с Internet, например, на SMTP-сервер. Да-
лее опрашивается указанный в конфигурации Internet-сервер (POP3, UUCP, FTP).
Полученные письма раскодируются, из них извлекаются пакеты с Fido-почтой
и помещаются во входной директорий Fido-системы. На этом работа программы
завершается.
К сожалению, программа TransX распространяется как условно-бесплатная
(shareware) и использование ее дольше испытательного 30-дневного срока счита-
ется незаконным.
Программа Internet REX (IRex)
IRex еще более универсальная программа, чем TransX. Автором ее является Чарльз
Круден (Charles Cruden) из Канады (адрес в FidoNet - 1:342/806). Программу мож-
но загрузить из Internet с адреса:
http://plaza.v-wave.com/InternetRex/
IRex существует в версиях для DOS, Windows 95/98/NT, OS/2 и Linux. Про-
грамма способна:
□ использовать для проброса Fido-почты E-Mail, FTP, BINKP;
□ работать как Fido-тоссер;
□ может отправлять/принимать почту через SMTP/POP3 сервер, UUCP, ис-
пользовать для этой цели Fido-Internet шлюзы, напрямую взаимодействовать
с такими известными клиентскими программами Internet, как K9Q, Eudora,
MR/2 Ice, Nettamer, и некоторыми другими;
□ поддерживать одновременно множественные входные и выходные E-mail-
адреса и множественные очереди на прием/отправку;
□ использовать кодирование MIME, UUENCODE, XXencode, TransX;
□ отсылать и принимать письма от многих программ, например от Fido2Int,
TransX, Allfix 5.0+, GI GO, Water Gate и других;
□ работать совместно с TransX;
□ работать совместно с FrontDoor, Binkley Term и другими совместимыми с ними
мейлерами, с D’Bridge, AdeptX, Platinum Xpress, PCBoard 15.22+, ViaMail,
QFront и другими аналогичными программами.
Дополнительные возможности программы позволяют:
□ шифровать передаваемые файлы для повышения секретности;
□ как и в TransX, использовать механизмы оповещения о приеме для предотв-
ращения потери почты;
□ рассылать сообщения сразу на несколько адресов;
□ использовать IRex как шлюз между нетмейл-почтой FidoNet и E-mail-почтой
Internet;
□ выполнять запросы файлов (File Request) через электронную почту Internet.
Все это делает IRex чрезвычайно привлекательной программой, широко ис-
пользуемой вне R50. Ограниченное применение в России объясняется высокой
ценой зарегистрированной версии (в свободно распространяемом варианте воз-
можно описание только одного соединения).
Строки-флаги для обозначения в нодлисте
E-mail- и FTP-систем
Недавно принятый стандарт FTS-5001 на флаги нодлиста ввел в обращение не-
сколько новых флагов, специально предназначенных для определения систем
с E-mail и/или FTP-доступом к FidoNet: 1
□ IFT - обозначает системы, разрешающие FTP-доступ;
□ ITX - обозначает системы, использующие кодирование TransX при передаче
Fido-данных через электронную почту;
□ IUC - обозначает использование кодирования UUENCODE при передаче
Fido-данных через электронную почту;
□ IMI - обозначает использование кодирования MIME при передаче Fido-дан-
ных через электронную почту;
□ IEM - используется для задания (через двоеточие) контактного E-mail адреса.
В нодлисте можно найти многочисленные примеры использования таких фла-
гов, например:
Pvt, 161, Black__.Sun , Bristol, Paul_WaIker , -Unpublished- ,300, IMI,
ISE,ITX,IUC,EMA,IEM:fido@black-sun.demon.co.uk
Соединение Fido-программ через Internet
с использованием протокола TCP/IP
Использование on-line соединения двух программ через Internet соответствует
идеологии FidoNet: всегда есть возможность убедиться, что на противоположной
стороне получили (или не получили) посланную информацию, и если что-то не
так, своевременно принять меры. Этим рассматриваемые в данном разделе про-
граммы в корне отличаются от описанных выше off-line способов соединения вро-
де E-mail или FTP, в которых тоже есть подобие сессии, уведомления о получении
и т.п., но все это работает неторопливо и не всегда надежно.
Как правило, для организации on-line соединения разработчиками программ
выбирается протокол TCP, так как его свойства позволяют не заботиться о кор-
рекции ошибок и состоянии канала - все выполняется автоматически на уровне
протокола.
Использование драйвера Vmodem
Первоначально в качестве основной программы, реализующей ТСР-соединение,
в FidoNet использовался драйвер Vmodem, автором которого является Реймонд
Гвинн, создатель популярных пакетов коммуникационных драйверов Х00 и SIO.
Vmodem (или драйвер «Виртуальный модем») позволяет использовать обычный
FTN-мейлер или любую другую коммуникационную программу, рассчитанную на
работу совместно с драйвером FOSSIL, для соединений посредством Internet,
имитируя для программы модемное соединение, а на самом деле TCP-канал с дру-
гим аналогичным Vmodem-драйвером. При этом используется протокол VMP
(Virtual Modem Protocol), разработанный автором специально для Vmodem. Мо-
жет использоваться также и стандартный протокол TELNET. Одновременно
Vmodem выступает как обычный TELNET-сервер и принимает соединения от
любого TELNET-клиента. Так что если оснастить драйвером Vmodem программу
BBS, то пользователи через Internet с помощью протокола TELNET смогут к ней
подключаться.
Vmodem входит в состав пакета SIO для OS/2, работает совместно с драйвером
SIO, и для обслуживания всех Internet-линий (определенных в строке запуска
SIO) достаточно запуска одной копии драйвера Vmodem.
Настройка и запуск Vmodem
Для запуска Vmodem используется возможность (предоставляемая SIO) создания
под OS/2 так называемых виртуальных коммуникационных портов, воспринимае-
мых программным обеспечением в DOS-окне OS/2 так же, как и обычные порты.
Например, установка SIO с помощью следующей строки в основном конфигу-
рационном файле OS/2, config.sys:
DEVICE=SIO (COM4,INTERNET:2Е8,NONE:3)
создает для DOS-сеансов OS/2 виртуальный коммуникационный порт с адре-
сом 2E8h и аппаратным прерыванием IRQ3. Теперь программы, работающие
в DOS-окне OS/2, «увидят» COM4 и смогут работать с ним как с обычным ком-
муникационным портом. В сеансе OS/2 Vmodem также создает «виртуальный
модем» на коммуникационном порту, который эмулирует SIO, но здесь нет нуж-
ды имитировать адрес и IRQ, и строчка для использования Vmodem с OS/2-про-
граммами может быть такой:
DEVICE=SIO (COM4,INTERNET,NONE)
Теперь, запустив Vmodem в сеансе OS/2, получим поддержку виртуального
модема во всех OS/2 и DOS-сессиях. При этом запущенный драйвер имитирует
модем, изображая активность стандартных сигнальных линий порта RS-232 обыч-
ным для модема способом (подмигивая «лампочками»-сигналами DCD, DSR
и т.п.) в том окне, в котором он был запущен, и отображая в нижней части экрана
протокол передаваемой информации (рис. 11.1). Vmodem также поддерживает
большинство стандартных команд модема и имитирует ответы на них.
Почтовая сессия, которая проходит на протоколе Vmodem, принципиально ни-
чем не отличается от обычной почтовой сессии. «Моментальный снимок» такой
сессии приведен на рис. 11.2, где представлено окно мейлера The Brake! для опе-
рационной системы OS/2. При этом вместо номера телефона при наборе исполь-
зуется символьный или цифровой Internet-адрес нужного узла. Обеспечить под-
становку Internet-адреса вместо номера телефона способны многие почтовые
программы. В приведенном на рис. 11.2 примере пришлось в конфигурационном
файле программы The Brake! описывать узел l:2604/105@fidonet, которому
надо «позвонить» через Internet, следующим образом:
#For 3
Define 1:2604/105@FidoNet
Mode Normal
Phone 207.242.245.149
Dial ATDT#
Time CM
End
#EndFor
Блок #For 3 - #EndFor означает, что приведенные для узла 1:2604/105@fidonet
данные должны быть использованы только на третьей линии мейлера (это как раз
Internet-линия), а указанная как номер телефона последовательность цифр пред-
ставляет собой цифровой 1Р-адрес.
Virtual Modem Status Information
VMOO = COM4 S0=00 DCD RI OH RD SD DTR DSR CTS
11-24 11-24 11-24 11-24 11-24 13:02 VMODEM, Version VI.20 is alive and seems well. 13:02 Outgoing to 207.242.245.149 from COM4 on port/socket 3141 13:02 We are negotiating with the remote 13:02 Received connect 13:03 COM4 disconnected
Рис. 11.1. Рабочее окно драйвера Vmodem
Конечно, делать такие описания для каждого из узлов неудобно, но другого
механизма пока нет, правда, большинство узлов (не все!) указывают Internet-ад-
рес в поле имени системы. С использованием дополнительных возможностей по
обработке нодлистовых строк, предоставляемых некоторыми мейлерами, не со-
ставляет труда извлечь и использовать этот адрес, но так как единого подхода нет,
то обычно применяется метод ручного прописывания адресов всех нужных узлов.
На рис. 11.3 приведен протокол, записанный во время сессии, изображенной на
рис. 11.2.
Строка CONNECT 57600 / ARQ/VMP, приведенная в начале записанного протоко-
ла, была сформирована драйвером Vmodem. Она представляет собой имитацию
стандартного сообщения модема о состоявшемся соединении. Символы / VMP озна-
чают соединение на протоколе VMP - собственном протоколе Vmodem. Драйвер
способен также производить соединение на стандартном протоколе TELNET,
в этом случае сообщение о соединении будет содержать символы /TEL.
Недостатки драйвера Vmodem являются продолжением его достоинств. Со-
зданный для операционной системы OS/2, он активно использует предоставляе-
мые ей возможности, поэтому перенести его под другую операционную систему
каким-либо простым образом не удается. Менее очевидным, но существенным
недостатком является то, что сама идея использования стандартного FTN-мейле-
ра для соединений через Internet уязвима, так как Internet-соединение порой
очень существенно отличается от соединения по обычным телефонным линиям
с использованием модема. Качество Internet-соединения заранее предсказать невоз-
можно, его скоростные характеристики варьируются в очень широких пределах.
2:5049/12@FidoNet | The Brake! (tm) Mailer 718.a8/9999 i n n о n „ * ; ~~ | 01 :07:45 | 02%
C++/i586 14:09 System: TFP/2 - Internet Node I, Garfield, NJ, Jim McLaughlin 14:09 Flags: 1-973-478-8476,33600,CM,XA,TEL 14:09 Time: Wed 24 Nov 07:02:52 14:09 Using Hydra for transfer, RH1 mode 14:09 Using Hydra link options: ASC,UUE,C32 14:10 HS 0A2C0069.Cut -> 00001027.Pkt, CRC-32, 348, 00:00, mail HSend : Done : T ime : HRecv : Done : T ime : CPS : 00001027.Pkt 348, 100% 00:02 / 00:00 None None None 174 / None :
nuu1
TFP/2 AKAs: * Outgoing call: CONNECT 57600/ARQ/VMP TO 207.242.245.149 * 1:2604/105@FidoNet uses ВТ 2.60XE/Gamma9612240000/IBM C++/i586 : - Internet Node I, Garfield, NJ, Jim McLaughlin, 1-973-478-8476, 33600 Non-protected session 1:l/3000@FidoNet, 1:2604/104@FidoNet, 1:2604/100@FidoNet, l:2604/101@F
For From Mail Files Total us 0 0 0/0 us 348 0 0/0 0% 0% CPS 0 0 0% 0%
00:20 | Wed 24/11 14:10:04 | | | DTR CTS RTS RI CD RQ SQ | COM4 57600
Рис. 11.2. Соединение через Internet на протоколе Vmodem (The Brake! mailer)
File Edit Options Неф________________________________________________________________________
124/11/99 14:09:37 [3,02] и Calling normal 1:2604/105®FidoNet, 207.242.245.149
124/11/99 14:09:44 [3,02] и Connected with ARQ, CONNECT 57600/ARQ/VMP TO 207.242.245.149
24/11/99 14:09:44 [3,02] н
24/11/99 14:09:44 [3,02] и Outgoing call: CONNECT 57600/ARQ/VMP TO 207.242.245.149
24/11/99 14:09:44 [3,02] и
24/11/99 14:09:49 [3,02] и Session with 1:2604/105®FidoNet
24/11/99 14:09:49 [3,02] н AKAs: 1:l/3000®FidoNet, 1:2604/104®FidoNet
24/11/99 14:09:49 [3,02] Д AKAs: 1:2604/100®FidoNet, 1:2604/101®FidoNet
24/11/99 14:09:49 [3,02] и AKAs: 1:2604/106®FidoNet, 1:2604/0®FidoNet
24/11/99 14:09:49 [3,02] и AKAs: 1:13/23®FidoNet, 1:13/3®FidoNet, 93:9710/105®FidoNet
24/11/99 14:09:49 [3,02] и AKAs: 93:9700/0®FidoNet, 93:9710/0®FidoNet
24/11/99 14:09:49 [3,02] и AKAs: 666:4130/20®FidoNet
24/11/99 14:09:49 [3,02] и Mailer: ВТ (IB) 2.60XE/Gamma9612240000/lBM C++/i586
24/11/99 14:09:49 [3,02] д System: TFP/2 - Internet Node I, Garfield, NJ, Jim McLaughlin
24/11/99 14:09:49 [3,02] Д Flags: 1-973-478-8476,33600,CM,XA,TEL
24/11/99 14:09:49 [3,02] и Time: Wed 24 Nov 07:02:52
24/11/99 14:09:49 [3,02] a Using Hydra for transfer, RH1 mode
24/11/99 14:09:51 [3,02] n Using Hydra link options: ASC,UUE,C32
24/11/99 14:10:03 [3,02] a HS 0A2C0069.Cut -> 00001027.Pkt, CRC-32, 348, 00:00, mail
24/11/99 14:10:07 [3,02] Д SE 00:04, 348, 87 CPS 1% J
24/11/99 14:10:09 [3,02] д Done, 1:2604/105®FidoNet, 00:24, 0/1, 0/348, free Й
24/11/99 14:10:10 [3,02] Д ________ __________ _ __ ____ ________ _ ___M
Рис. 11.3. Фрагмент протокольного файла с информацией о почтовой сессии,
проведенной с использованием протокола Vmodem
Это приводит к тому, что обычный мейлер, оптимизированный под параметры мо-
демного соединения, оказывается неэффективным при использовании Vmodem,
а иногда соединение просто не удается установить. Заметим также, что мейлер за-
пускает протоколы передачи файлов, включающие коррекцию ошибок, на «чистом»
канале, предоставляемом TCP-соединением, что является лишней процедурой, но
без чего обойтись (при использовании стандартных программ) нельзя.
Существуют драйверы, аналогичные Vmodem, и для других операционных сис-
тем. Это, например, RL-FOSSIL для DOS и драйвер COMt для Windows, но ни
один из них не сравнится по функциональной насыщенности с Vmodem.
Программа Ifcico/IP
Ifcico - это FTN-почтовая программа (мейлер), входящая в состав пакета Ifmail
для операционной системы UNIX. Сначала Ifcico поддерживал только модемные
соединения, но впоследствии автор дополнил его возможностью установления
соединения через Internet. Ifcico использует свой протокол соединения, обычно
называемый автором RAW TCP и основанный, как следует из названия, на стан-
дартном протоколе TCP Этот протокол использует по умолчанию порт 60179.
Поскольку Ifmail поставляется с исходными текстами, существует несколько
его доработанных версий, содержащих отсутствующие в авторском варианте воз-
можности (и, конечно же, дополнительные ошибки). В версии Ifmail-TX, автором
которой является Пабло Саратага (Pablo Saratxaga, 2:292/2219@fidonet), добав-
лена возможность соединения на протоколе TELNET (используется порт 60177).
Есть также дополнение от Вадима Заливы. При компиляции этого дополнения
совместно с Ifmail последний приобретает возможность связываться с системами,
оснащенными SIO/Vmodem.
Таким образом, Ifcico сейчас предоставляет возможности связи со всеми рас-
пространенными on-line протоколами Fido-over-IP. Исключение составляет про-
токол Binkp, для использования которого проще всего параллельно с Ifcico запус-
тить почтовую программу Binkd Дмитрия Малова, также существующую в версии
для UNIX.
Подробные инструкции по конфигурации Ifmail не приводятся прежде всего
потому, что этот замечательный мейлер существует только в версии для UNIX
и не слишком распространен. Тем же, кто освоил «плавание» по бурным водам
UNIX-подобных операционных систем, установка и настройка Ifmail покажется
детской игрой. Напротив, описанный в следующем разделе мейлер чрезвычайно
популярен, поэтому настройке его IP-подсистемы будет уделено самое присталь-
ное внимание.
Программа Т-Mail для сетей TCP/IP
Андрей Елкин, автор универсального FTN-мейлера T-Mail, недавно добавил
к обширному списку возможностей своей программы способность устанавливать
соединение через Internet. С этой целью он выпустил отдельную версию, называ-
емую «Версия T-Mail для сетей TCP/IP». Она поставляется в составе расширен-
ного дистрибутива программы, который можно получить в Internet с адреса:
http://www.t-mail.spb.ru
Существует версия T-Mail/IP для операционных систем OS/2 и Windows NT.
T-Mail и T-Mail/IP могут работать совместно на одной системе, при этом функ-
ции задачи выделенного упаковщика (Master) может выполнять как обычный
T-Mail, так и T-Mail/IP Версия T-Mail/IP не может работать со стандартным
коммуникационным портом и модемом. Для ее функционирования необходимо,
чтобы на компьютере была установлена поддержка протокола TCP/IP.
При проведении сессии через Internet T-Mail/IP может использовать два транс-
портных протокола: стандартный TELNET и RAW TCP или IFC, который под-
держивает мейлер Ifcico, входящий в состав пакета Ifmail. При передаче данных
могут применяться любые из поддерживаемых T-Mail протоколов передачи фай-
лов. В качестве идентификатора удаленной системы (CALLER ID) используется
ее цифровой IP-адрес (например, 194.67.27.194).
При дальнейшем изложении нами была использована документация на T-Mail/IP,
поставляемая вместе с программой.
Настройка Т-mail/IP
Настройка T-Mail/IP мало отличается от настройки обычного T-Mail. Для кон-
фигурации специальных функций T-Mail/IP введен ряд дополнительных пере-
менных в файле t-mail.ctl.
Для выполнения задач, стоящих перед T-Mail/IP, соответствующая перемен-
ная Port в файле t-mail.ctl должна иметь нулевое значение. T-Mail/IP будет иг-
норировать значения некоторых переменных из файла t-mail.ctl, имеющих от-
ношение к настройкам обычного коммуникационного порта. Так, игнорируются
следующие директивы:
□ Baud;
□ Init_Interval;
□ Process No;
□ Modem;
□ Busy_Hang_Off;
□ Init 1, Init2;
□ Dial_Prefix, Dial_Suffix, Dial_Terminate;
□ Onhook, Offhook;
□ Modem_Answer;
□ Statistics;
□ Valid;
□ Connect;
□ Freepoll;
□ Modem_Reject_Answer;
□ Dial;
□ Answer_Ring;
□ Min_Baud_In, Min_Baud_Out;
□ YOOHOO_Enable.
Кроме того, игнорируются все команды, имеющие отношение к факсовым
и голосовым функциям, присутствующим в коммерческой версии (существует
версия T-Mail для свободного распространения и коммерческая версия, где есть
некоторые дополнительные возможности и убраны ограничения на количество
линий и т.п.).
Для осуществления T-Mail/IP исходящего вызова необходимо, чтобы удален-
ная система имела один из флагов нодлиста ITN (для TELNET) или IFC (для
Ifcico). Если номер телефона удаленной системы в нодлисте начинается с ООО-, то
он будет интерпретирован как ее IP-адрес. Следует отметить, что только очень
немногие системы поддерживают подобное обозначение IP-адреса в нодлисте
(в текущем нодлисте подобных систем менее 20), поэтому, вероятно, придется на-
писать свой небольшой нодлист и описать в нем всех своих линков, для связи
с которыми вы используете T-Mail/IP.
Альтернативным решением является использование файла подстановки subst.lst.
В этом случае можно не начинать IP-адрес с ООО-, а использовать либо числовой
(пример: 194.67.27.194), либо символьный (например, argus.zarech.ru) вид.
Для задания IP-адреса системы в subst.lst вместо параметра PHONE нужно ис-
пользовать IPADDR. Чтобы определить дополнительные IP-линии системы, вме-
сто параметра HIDDEN используется IPHIDDEN. После IP-адреса системы мож-
но через двоеточие указать порт, на который будет осуществляться исходящий
вызов. По умолчанию применяются стандартные значения (23 - для TELNET
и 60179 - для Ifcico). Если для системы указаны оба флага (ITN и IFC), то T-Mail
в первую очередь использует порт Ifcico.
Например, содержимое файла subst.lst может быть следующим:
2:5049/96 ipAddr 194.067.027.196
# Flags ITN,IFC
2:5049/49 ipAddr timson.zarech.ru:23 flags ITN
# ipHidden 194.067.027.249:60179 flags IFC
Если качество соединения TCP/IP невысокое (а так обычно и бывает, если
только узлы не находятся в одной локальной сети), то нужно изменить пара-
метры протокола Zmodem. Сделать это можно следующим образом: в файле
t-mail.ctl для T-Mail/IP определяется фиктивная строка CONNECT вида:
Connect 57600 CONNECT TCP/IP
При этом скорость соединения (в примере 57600) задается произвольно и опре-
деляет соответствующие ей по умолчанию параметры протокола Zmodem (см.
описание конфигурации T-Mail в главе 7).
Общие рекомендации по настройке любого протокола передачи файлов при его
использовании в Internet сводятся к выставлению максимально возможных зна-
чений тайм-аутов, а длительность тайм-аута, после которого наступает разрыв
соединения, не должна превышать нескольких минут. Это значение должно быть
меньше, чем длительность обычного тайм-аута. Такие настройки необходимы -
задержки при передаче через TCP-соединение без разрыва соединения могут быть
чрезвычайно длительными (до нескольких минут и более), а вот какие-либо ре-
трансмиссии смысла не имеют, так как потерь на TCP-канале быть не может:
единственным нарушением может оказаться только полный разрыв соединения.
Описанная настройка никак не уменьшает производительность предачи данных
и гарантирует от излишней загрузки канала.
На рис. 11.4 приводится фрагмент файла t-mail.ctl, в котором описаны коман-
ды настройки специальных функций T-Mail/IP Приведенный пример взят из
документации, поставляемой вместе с T-Mail/IP
Запуск T-Mail/IP
Одновременно может быть запущено несколько копий T-Mail/IP Кроме того,
при конфигурации системы с помощью переменных StartableTasks и Process
IPAnswer можно задать список из нескольких так называемых «дополнитель-
ных» задач T-Mail/IP. Они будут запускаться в ответ на входящий вызов в том
случае, если все действующие в настоящий момент задачи T-Mail/IP заняты. Пос-
ле окончания сеанса связи дополнительные задачи немедленно завершают свою
работу. Подобным образом можно сэкономить ресурсы компьютера. Следует
отметить, что в этом T-Mail/IP удобнее стандартного использования драйвера
Vmodem, так как в случае Vmodem количество одновременно проходящих сессий
ограничено количеством запущенных IP-линий мейлера.
Запускается T-Mail/IP аналогично обычной версии T-Mail. Обработка входя-
щих вызовов через TCP/IP выполняется следующим образом. Одна из специаль-
ных задач T-Mail/IP постоянно «слушает» входные порты и при обнаружении
попытки входящего IP-вызова передает его одной из свободных задач T-Mail/IP
(либо отвечает сама). Если в данный момент таких свободных задач нет, запуска-
ется дополнительная задача T-Mail/IP (если это определено в настройке про-
граммы так, как описано выше). При условии, что список дополнительных задач
Е.ЕХЕ - T-Mail.ctl « □
File Edit Options Help ___________ ___________________
;; Переменные данной секции u,
} определяют работу T-Mail/IP г-.
:Answer_Telnet 23 у Telnet port number '
iAnswer_IFC 60179 у Ifcico port number j
\y Эти переменные определяют номера IP-портов, с использованием которых осуществляются !
соединения при входящем вызове (соответственно для протоколов Telnet и Ifcico). i
:у Если эти переменные не определены или равны 0, то входящие IP-сеансы связи не проводятся. !
:у Значения по умолчанию - соответственно 23 и 60179. Эти значения являются стандартными.
iPingTimeout 2000 у Ping timeout i
\у Перед проведением исходящего сеанса связи T-Mail/IP пытается проверить существование !
системы-адресата с помощью стандартной IP-процедуры PING. Если полученное значение i
у менее заданного в переменной PingTimeout, или удаленная система вообще не отвечает, i
у то попытка установления сеанса связи не производится. При ©том не изменяются значения i
.у счетчиков попыток и не заносится никакой информации в лог-файлы. Если значение ©той *
у переменной равно 0, то такая проверка не производится вообще. :
у Значение по умолчанию - 1000 миллисекунд. <
StartableTasks 0,7,8 у Startable IP tasks i
; Эта переменная определяет номера задач T-Mail/IP, которые разрешается запускать в i
у качестве дополнительных, если все запущенные задачи T-Mail/IP в данный момент заняты. i
у В качестве параметра используется список номеров задач по правилам, описанным в
у документации T-Mail (Глава 7 руководства,"Номер задачи"). По умолчанию ©та переменная i
у не определена, в ©том случае дополнительные задачи не запускаются. i
Process IPAnswer start c:\t-mail\t-mipnt.exe -N*N -A*F i
у Эта переменная определяет строку запуска дополнительной задачи T-Mail/IP в случае, i
у если все запущенные задачи T-Mail/IP в настоящий момент заняты. В этой строке можно >
у использовать стандартный набор макросов T-Mail. По умолчанию ©та переменная не :
; определена, в этом случае дополнительные задачи не запускаются. Использование системной
у команды start в этой переменной обязательно. i;
Рис. 11.4. Пример настройки специальных функций T-Mail/IP в файле t-mail.ctl
исчерпан (или переменные StartableTasks и Process IPAnswer не определены), вы-
зывающей системе передается сигнал BUSY.
T-Mail/IP завершает свою работу с теми же кодами завершения (ERRORLEVELS),
что и обычная версия T-Mail.
От Vmodem, T-Mail/IP и Ifcico - к Binkp!
T-Mail/IP можно считать развитием идеи Vmodem. Фактически это аналогичный
драйвер, но интегрированный в саму почтовую программу и потому допускающий
более гибкое конфигурирование и использование. Следующим шагом по пути
более эффективного использования TCP/IP для организации Fido-соединений
могла бы стать разработка специального протокола FTN-сессии для использова-
ния в сетях TCP/IP. Таким протоколом стал Binkp, ранее подробно описанный
в главе 3. Следующий раздел предоставляет дополнительную информацию об
этом замечательном протоколе и программах, использующих его.
Протокол Binkp и мейлер Binkd
Протокол Binkp специально разработан для организации проброса Fido-почты с ис-
пользованием протокольного стека TCP/IP. В отличие от остальных протоколов,
выступающих относительно протоколов FTN-сессии как протоколы нижнего
уровня, Binkp является одновременно протоколом FTN-сессии, избавляя мейлер
от необходимости запускать над транспортным протоколом еще и дополнительные
Fido-протоколы (см. описание протоколов передачи файлов и протоколов Fido-сес-
сии в главах 3 и 5). Это замечательное свойство позволило оптимизировать
Binkp для использования на каналах со скоростными характеристиками, варьи-
рующими в очень широких пределах и в то же время свободных от ошибок и по-
терь кадров - именно такие каналы предоставляет протокол TCP, используемый
Binkp.
Популярность Binkp обеспечило также и то обстоятельство, что автор протоко-
ла Дмитрий Малов (некогда житель Магадана, а теперь москвич) реализовал его
как часть своей почтовой программы Binkd. Она поставляется в исходных тек-
стах и реализована для всех распространенных операционных систем, включая
популярные версии UNIX, OS/2, Windows 95, Windows NT и DOS.
С точки зрения FTN-технологии Binkd представляет собой очень простой
Binkley-Style мейлер. Такой мейлер легко интегрируется в одну систему с лю-
бым обычным FTN-мейлером, поддерживающим Bink-Style формат исходящего
директория, при этом обмен информацией между компонентами системы осу-
ществляется через разделяемый исходящий Binkley-Style директорий. Так, Binkd
легко сочетается с такими мейлерами, как The Brake!, Binkley Term, Xenia, T-Mail
(в Binkley-режиме), Ifcico и многими другими. Можно также использовать Binkd
и с АМА-мейлерами, если запускать одну из имеющихся утилит конвертации,
предназначенной для преобразования «Binkd-части» исходящего АМА директо-
рия в Binkley-Style.
Мейлер Binkd и домен fidonet.net
В главе 1, разделе «FidoNet.net: Fido DNS», описан способ получения цифрового
или символьного IP-адреса Fido-системы по ее FidoNet-адресу. Подобная проце-
дура возможна, если необходимая информация занесена в конфигурационный
файл DNS-сервера Internet-домена fidonet.net, зарегистрированного специально
для построения системы распознавания [FidoNet-адрес => Internet-адрес] для си-
стем FidoNet, использующих Binkd при соединении посредством Internet.
С использованием fidonet.net поиск информации об истинном IP-адресе систе-
мы существенно упрощается: не нужно искать ее в нодлисте (где ее обычно и не
бывает) или запрашивать у системного оператора в нетмейл-письме. Необходимо
только использовать соответствующую запись в конфигурационном файле мей-
лера Binkd, где кроме Fido-адреса не используются другие указания на 1Р-адрес.
Binkd автоматически выполнит запрос к DNS-серверу и, основываясь на данном
FTN-адресе, получит цифровой или символьный 1Р-адрес.
Удобство системы DNS заключается также и в оперативности ее обновления
(по сравнению, например, с обновлением нодлиста). Ведение сетевых сегментов
DNS-домена fidonet.net делегировано (если это возможно) непосредственно на
места, в локальные сети, и внесенные изменения в течение самого короткого вре-
мени (столько, сколько требуется для обновления буферов DNS-системы) стано-
вятся актуальными для внешних пользователей.
На рис. 11.5 приведен пример заполнения конфигурационного файла DNS-сер-
вера (сервер named для операционной системы SUN OS), используемого для под-
держки домена четвертого уровня n5049.z2.fidonet.net, содержащего информацию
об IP-системах сети 2:5049.
Заголовок файла (запись SOA) определяет общие параметры DNS-системы:
адрес сервера имен, правила кеширования, дату последнего изменения. Дополни-
тельные имена серверов имен определяются в строчках IN NS. Далее идут описа-
ния адресов отдельных систем, причем, большинство из них использует цифро-
вую запись, а два адреса заданы как дополнительные ссылки на другое доменное
имя. Для получения их цифровых адресов требуется выполнить еще один DNS-
запрос на указанный после слова CNAME адрес (обратите внимание на точку пос-
ле каждого символьного имени - ее наличие в файле конфигурации DNS являет-
ся обязательным).
Условие описания адреса узла в fidonet.net является необходимым для получе-
ния IP-only (то есть подключенного только через Internet) адреса в нодлисте (это
положение действует сейчас в регионе 50). Такие узлы выдаются с префиксом
PVT в полном соответствии с Полиси FidoNet.
Для того чтобы попасть в Fido-DNS, нужно связаться с координатором вашего
сегмента. Обычно информацию о том, кто ведет сетевой сегмент Fido-DNS для
вашей сети, можно получить у своего сетевого координатора, но Internet-адрес
е.ехе - T:\etc\named\fido5049.hosts___________________________________~ ___\ ° □
М|||Д||||ДИ|||1||||[||||||Д||Д
Ф IN SOA ns.n5049.z2.fidonet.net. root.hector.zarech.ru. (
J 20002501001; Serial i
86400 1800 604800 86400 ) ; Refresh ; Retry ; Expire ; Minimum
IN NS ns.n5049.z2 .fidonet.net.
IN NS ns.fidonet. net.
ns 86400 IN A 194.67.27.210
WWW 86400 IN A 194.67.27.199
ftp 86400 IN A 194.67.27.199
wwwl 86400 IN CNAME aliaswww.kbst.ru
^fO 86400 IN A 194.67.27.194
Sfl 86400 IN A 212.22.77.58
If 12 86400 IN A 194.67.27.194
jf36 86400 IN A 212.22.67.12
f45 86400 IN CNAME vmk-701.ksu.ru.
f46 86400 IN A 194.186.108.151
f49 86400 IN A 194.67.27.249
f92 86400 IN A 195.161.74.194
f96 86400 IN A 194.67.27.196
f99 86400 IN A 195.239.131.14
fll5 86400 IN A 195.161.75.18
www.f115 86400 IN A 195.161.75.18
ftp.fll5 86400 IN A 195.161.75.18
f256 86400 IN A 212.22.67.12
Рис. 11.5. Пример конфигурационного файла DNS-сервера для домена fidonet.net
DNS-мастера - непосредственно из DNS. В приведенном выше примере это
root@hector.zarech.ru (записывается как root.hector.zarech.ru, но письмо надо от-
правлять на root@hector.zarech.ru).
Вот как можно получить эту информацию с использованием программы
nslookup, входящую в список стандартных IP-утилит всех известных операцион-
ных систем (см. рис. 11.6). (Здесь использован вариант nslookup для SUN OS, опе-
рационной системы UNIX-типа.)
В примере на рис. 11.6 запускается программа nslookup, выбирается желае-
мый тип записи для просмотра (set q=soa), после чего вводится название под-
домена, о котором нужно получить информацию (n5049.z2.fidonet.net). Правила
формирования названия домена аналогичны рассмотренным в главе 10 для слу-
чая преобразования Fido-адресов в доменные Internet-адреса, только название
домена не fidonet.org, а fidonet.net. Полученный в результате запроса адрес нахо-
дится в строке, начинающейся со слов MAIL ADDR, и при отправке письма он
должен записываться как sfy@corbina.net.
Варианты поставки мейлера Binkd
Binkd поставляется как в виде набора исходных текстов, готовых к использованию
после компиляции, так и в виде исполняемых модулей, скомпилированных под раз-
личные операционные системы. Под некоторые операционные системы поставля-
ется несколько исполняемых модулей, различающихся типом компилятора, кото-
рый был использован для сборки программы. Binkd имеет хорошую документацию
в HTML-формате. Какая-либо программа установки отсутствует, да и того, что
обычно называют «установочный пакет», у Binkd нет. Ниже на рис. 11.7 приведен
полный список файлов, прошедших в разное время по файл-эхе XFTNBINKD.
Last login: Mon Nov 22 10:30:52 from argus
SunOS Release 4.1.3 (GENERIC) ЙЗ: Mon Jul 27 16:43:54 PDT 1992
10:46am up 25 days, 2:25, 1 user, load average: 0.08, 0.02, 0.01
User tty login@ idle JCPU PCPU what
root ttypO 10:46am w
abaddontt nslookup
Default Server: ns.zarech.ru
Address: 194.67.27.210
> set q=soa
> n5020.z2.fidonet.net
Server: ns.zarech.ru
Address: 194.67.27.210
n5020.z2.fidonet.net origin = ns.n5020.z2.fidonet.net
mail addr = sfy.corbina.net
serial=943005795, refresh=43200, retry=7200,
expire=1209600, min=172800
ns.n5020.z2.fidonet.net inet address = 195.14.50.1
ns.fidonet.net inet address = 195.98.32.193
ns.rinet.ru inet address = 195.54.192.33
>
Рис. 11.6. Определение почтового адреса координатора домена
n5049.fidonet.net с использованием программы nslookup
И е.ехе - E:\ARCHIVE\FIDO\binkd\fUes.bbs ’ _ j ° :Р.
File Edit Options Help__________________________________________
092BIN.ZIP Binkd for DOS
092SRC.ZIP binkd for DOS (source)
BDLAZIP Binkd Log Analyzer v0.14 (DOS/OS2) by 5020/269
BINKD.CFG Binkd 0.9.2 - sample config
BINKD.TXT binkd links
BINKD091.ZIP Binkd 0.9.1 sources
BINKD092.ZIP Binkd 0.9.2 sources
BINKD09U.ZIP Binkd 0.9.0 sources (real)
BINKD087.ZIP Binkd 0.8.7 sources
BINKD068.ZIP Binkd 0.8.8d sources
BINKD2.EXE Binkd 0.9.1 OS/2 version
BINKD2.ZIP Binkd 0.9.2 OS/2 binary (Watcom C)
BINKD2E.EXE Binkd 0.9.1 OS/2 EMX version
BINKD2E.ZIP Binkd 0.9.2 OS/2 binary (EMX)
BINKD95.EXE Binkd 0.9.1 Win95 version
BINKD95U.EXE Binkd 0.9.0 Win95 version (real)
BINKDNT.EXE Binkd 0.9.1 NT version
BINKDNTU.EXE
BND092NT.RAR
BNDMAN01.ZIP
Binkd 0.9.0 NT version (real)
BinkD 0.9.2/NT
Binkd 0.9.1 User's Guide
BNDMAN02.ZIP Binkd 0.9.2 docs
BSTAT002.ZIP Simple BinkD log analyser written on AWK,*v.0.02
BSTAT003.ZIP Simple BinkD log analyser written on AWK,*v.0.03 (bug fix!)
LOOKCUT.RAR Т-Mail Binary Log support v.0.02g1
RAS_UPNT.ZIP RAS dialer for Win32
SBF.EXE
SBF210.RAR
SBF220.RAR
SBF230.RAR
SBF240.RAR
Тулза для запуска батников по флагам
SBFby copah 2:5080/7
SBFby copah 2:5080/7
SBFby copah 2:5060/7
SBFby copah 2:5080/7
SBFSETUP.EXE Конфигуратор.
STATD.RAR Kleine_Statistiker/BINKD_ver.0.60a
BINKDLE Binkd 0.8.7 Linux ELF binaries
BINKDF Binkd 0.8.7 FreeBSD binaries
binkd2-S.zip скомпилированная под OS/2 c EMX версия BINKD 0.9.2:
- встроенная поддержка SOCKS v4 и SYSLOG.
-возможность задавать пароли на сессию в отдельном файле
-средство автоматического конфигурирования BINKP-узлов,
представленных в DNS (в домене 'fidonet.net').
BINKD2-S.FAQ Binkd FAQ
BINKDND-OS2-WATCOM.ZIP BINKD ND Watcom binaiy
BINKDND-OS2.ZIP BINKD ND/2
BINKDND.ZIP BINKD ND
Рис. 11.7. Список файлов, прошедших по файл-эхе XFTNBINKD
Как видно из списка, под названием Binkd выпущено большое количество про-
грамм, документации и сопутствующих утилит. Почти все эти файлы или ссылки
на них можно найти в Internet на сайте автора:
http://www.corbina.net/~maloff/binkd/
Установка и настройка Binkd заключается в правильном заполнении конфигу-
рационного файла. Запущенная программа выводит информацию о выполненных
соединениях на экран и в протокольный файл; какой-либо иной интерфейс
пользователя отсутствует. На рис. 11.8 показано, как выглядит окно с работаю-
щим мейлером Binkd. Для прерывания программы можно нажать комбинацию
клавиш Ctrl+Break.
«Философия» Binkd
Протокол, на котором основан Binkd, подробно описан в главе 3. В отличие от дру-
гих протоколов FTN-сессии (например, в отличие от EMSI) Binkp при установле-
нии соединения имеет только одну точку синхронизации (а именно, обмен пароля-
ми), что гарантирует быстрое соединение с минимальной нагрузкой на канал.
BINKD-Main-Configuration ___ _ _______________ _____________° iD
Г fJ 2:5049"/^ ... .................
fm 2:5049/16@fidonet
f- 2:5049/39@fidonet busy
dm 2:5049/45@fidonet
fm 2:5049/48@fidonet
hm 2:5049/73@fidonet
h- 2:5049/115@fidonet busy
hm 2:5063/60@fidonet
c- 2:5093/27@fidonet
c- 2:5093/32@fidonet
|+ 15:39 [1344] sent: C:\FID0\0UTB0UND\0UTB0UND\7A0C9724.THl (80869, 367.59 CPS,
^2: 5049/12.36@f idonet)
- 15:39 [1342] incoming from 194.87.72.4
<- 15:39 [1412] session with 194.87.72.4
- 15:39 [1412] SYS I REB,0-level_province_backbone_hub,Вinkd(64k)
I- 15:39 [1412] ZYZ IREB'Sysop
H 15:39 [1412] LOC Tver,„Russia
H 15:39 [1412] NDL 115200,TCP,BINKP
- 15:39 [1412] TIME 1999/11/25 15:55:53
- 15:39 [1412] VER binkd/0.9.2/NT binkp/1.1
+ 15:39 [1412] addr: 2:5021/1l@fidonet
* 15:39 [1412] addr: 190:100/lOtgbnet (n/a or busy)
+ 15:39 [1412] pwd protected session
I- 15:39 [1412] receiving 93F8F0B9.TH6 (6916 byte(s), off 0)
I 45%
Рис. 11.8. Рабочее окно программы Binkd
Binkd представляет собой продукт, выполненный в идеологии клиент-сервера,
причем один и тот же исполняемый модуль обеспечивает работу всех клиентских
и серверных нитей. Благодаря этому Binkd является многолинейным мейлером:
он может одновременно устанавливать столько клиентских («звонит» ваш Binkd)
и серверных (вам «звонят») связей, сколько позволяет объем свободной памяти
вашего компьютера и «толщина» Internet-канала. Алгоритм работы Binkd сле-
дующий:
1. Модуль программы, управляющий клиентскими соединениями, прочитыва-
ет исходящий директорий, создает очередь почты на отправку и делает по-
пытки установить соединения с адресами, для которых есть почта и которые
описаны в конфигурации программы. Для каждого соединения запускается
отдельная клиент-сессия. Максимальное количество одновременно запу-
щенных процессов-клиентов может быть задано в конфигурационном фай-
ле. Управляющий модуль пересканирует очередь, как только количество ак-
тивных клиентских соединений достигнет нуля.
2. Сервер-менеджер отслеживает попытки соединения с системой и запускает
для каждого соединения серверный процесс. Максимальное количество сер-
верных процессов задается в конфигурационном файле. При достижении
количественного предела серверных нитей в ответ на каждую новую попыт-
ку соединения посылается сообщение ТОО MANY SERVERS («слишком
много серверов»).
Этим исчерпываются функции Binkd. В отличие от многих других мейлеров,
он не упаковывает почту, не поддерживает запросы файлов, не имеет встроенного
планировщика, не использует нодлист, и т.д. И многие находят в этом основное
преимущество этой «маленькой, но гордой» программы. Binkd- программа не-
большая и простая, но очень эффективная.
Конфигурация Binkd
Часть директив конфигурации Binkd аналогична описанным в главе 7 директи-
вам конфигурации обычных FTN-мейлеров, часть характерна только для Binkd.
Им и следует уделить особое внимание.
Формат файла конфигурации. Формат файла конфигурации Binkd достаточ-
но прост. Все, что начинается с символа #, рассматривается как комментарий.
Остальные непустые строки должны содержать директивы конфигурации. Мак-
симальная длина каждой строки не должна превышать 1024 символа. Большин-
ство ключевых слов может сопровождаться дополнительными параметрами, ко-
торые отделяются друг от друга и от ключевого слова символами пробела или
табуляции. Те символы пробела и табуляции, которые необходимы как часть са-
мого параметра, заключаются в двойные кавычки, например: "Double Dozen".
Каждое ключевое слово может многократно встречаться в файле конфигурации.
При этом те ключевые слова, которое используются для задания списка значений
(например, адресов системы) при каждом употреблении дополняют список, а те,
которые содержит уникальный параметр, заново определяют его, если данный
параметр уже был определен ранее.
Регистр ключевых слов и параметров не имеет значения.
Переменные окружения. Binkd может распознавать в конфигурационном
файле и использовать переменные окружения, которые задаются командой опе-
рационной системы и сохраняются ее средствами. Переменные окружения в кон-
фигурационном файле Binkd должны быть взяты в символы-ограничители %, на-
пример: % I PORT %, и их максимальная длина не должна превышать 256 символов.
В качестве примера рассмотрим задание переменной окружения OUTBOUND. Так,
например, если в командном файле запуска Binkd для операционной системы OS/2
перед строкой запуска самой программы указать:
SET OUTBOUND=C:\FIDO\OUTBOUND\OUTBOUND
а в конфигурационном файле написать:
domain fidonet %OUTBOUND% 2
то при чтении этого файла вместо %OUTBOUND% будет подставлено значение, за-
писанное в команде SET.
Ключевые слова. Ниже описаны основные ключевые слова, которые могут
встретиться в файле конфигурации Binkd.
Domain
Это ключевое слово встречалось в описании конфигурации Bink-Style мейлера
The Brake! (глава 7). Оно определяет FTN-домен, его название, номер зоны, ассо-
циированной с данным доменом по умолчанию, и исходящий директорий.
Синтаксис:
domain <имя> <исх.директорий> <зона> I сновое имя> alias-for <имя>
Пример:
domain fidonet с:\\bbs\\outbound 2
domain fido alias-for fidonet
domain fidonet.org alias-for fidonet
В этом примере определяется домен с именем fidonet, задается его корневой
директорий (С: \BBS\0UTB0UND; двойная наклонная черта всегда используется
при обозначении директориев в binkd.cfg) и номер зоны по умолчанию для дан-
ного домена (вторая зона). Далее находятся два синонима к наименованию доме-
на - fido и fidonet.org.
Большое количество примеров употребления этого ключевого слова приведено
в документации по Binkd.
Address
Этим ключевым словом задаются 4D или 5D адреса системы. Основным является
первый в списке.
Синтаксис:
address сосновной адрео [адрес2 ... [адресп] ]
Пример:
address 2 : 5049/12@fidonet 2 : 5049/12.12@fidonet
Root-domain
С помощью root-domain задается наименование домена, который будет использо-
ваться при попытках найти через систему DNS IP-адрес хоста по его FTN-адресу
(см. ниже описание ключевого слова Node). Сейчас для этой цели используется
домен fidonet.net.
Синтаксис:
root-domain наименование домена>
Пример:
root-domain fidonet.net
Sysname, location, sysop и nodeinfo
Эти ключевые слова служат для описания системы. Во время сессии введенная
вслед за ними информация передается как блок текста. Синтаксис очевиден (см.
пример).
Пример:
# Нодлистовая информация
address 2:5049/12@fidonet
address 2 : 5049/0.0@fidonet
sysname "Double_Dozen"
location Kazan, Russia
sysop Amir Shabashvili
nodeinfo 115200,TCP,BND,NOSMTP
Iport и oport
Ключевые слова Iport и Oport служат для определения номера входящего и исхо-
дящего TCP-портов, которые будут использоваться для входящих и исходящих
соединений, соответственно. Значение по умолчанию равно 24554. Можно также
применять зарезервированное слово Binkp, которое интерпретируется как номер
24554.
Синтаксис:
iport <номер порта> | сназвание сервиса>
Пример:
iport .24554
oport 60179
iport binkp
oport binkp
Maxservers и maxclients
Ключевые слова maxservers и maxclients служат для задания максимального ко-
личества одновременных серверных и клиентских соединений соответственно.
Пример:
maxservers 5
maxclients 5
Node
Ключевое слово Node начинает строку описания линка. Таких строк в конфигура-
ционном файле может быть много, и в сумме они образуют полный список лин-
ков вашей системы, заменяющий для Binkd нодлист.
Если какой-либо параметр в записи отсутствует, его нужно заменить на сим-
вол - (тире). Если описание узла встречается в конфигурационном файле не-
сколько раз, то последующие вхождения тех или иных параметров переопреде-
ляют предыдущие.
Можно, например, включить распространяемый кем-либо список Binkd-узлов
в свой конфигурационный файл и переопределить для своих линков пароли,
флейворы и т.п.
Синтаксис:
node [[zone:]net/]node[.point][©domain]
[-nr]
[hostlist I -
[password I -
[flavour
[oboxI - [iboxI-]]]]]
Примечания по параметрам:
Адрес используется в форме: [ zone :] net /] node [ .point ] [©domain].
Пропущенные элементы адреса (например, опущенный номер зоны или номе-
ра зоны и сети) подставляются из основного адреса системы.
Остальные параметры имеют следующий смысл:
□ [NR] - расшифровывается как Non-Reliable link - «ненадежная связь»; рабо-
тает только на исходящих звонках на другую Binkd-систему поддерживаю-
щую этот режим (то есть на Binkd/0.9+). Этот параметр используется только
в том случае, когда Binkd не может инициировать передачу из-за плохого ка-
чества связи;
□ [HOSTLIST] - этот параметр должен содержать список разделенных зна-
ком ; (точка с запятой) блоков, содержащих Internet-адреса (возможно, с
записанным через двоеточие номером порта). При отсутствии номера порта
предполагается значение по умолчанию. Internet-адрес может быть в одной
из следующих форм:
- цифровой IP-адрес, то есть что-то вроде 194.67.27.194;
- хост-адрес, то есть сокращенное символьное наименование компьютера.
Binkd постарается разрешить эту ссылку, используя информацию о вашем
Internet-домене, в полное доменное Internet-имя, и на этом основании вы-
яснить цифровой 1Р-адрес;
- символ *. В этом случае Binkd выполнит через систему Fido-DNS в доме-
не fidonet.net поиск цифрового или символьного IP-адреса, преобразовав
Fido-адрес системы в ее доменный Internet-адрес вида [р<номер
пойнта>.]fсномер узла>.псномер сети>.з<номер зоны>.<до-
мен>, где <домен> совпадает с указанным в директиве root-domain (сей-
час для этой цели используется домен fidonet.net). Binkd сделает попытку
получить адресную ссылку и соединиться с первым слева из указанных
в списке адресов. Если соединение установить не удается (или не удается
разрешить адресную ссылку), то Binkd переходит к следующему адресу
в списке и повторяет процедуру. Если сессия не может быть установлена ни
для одного из перечисленных в. списке адресов, то клиент-процесс сообща-
ет об ошибке и самоуничтожается;
□ [PASSWORD] - задает пароль, которым защищается соединение с удаленной
системой. Может быть указан только один пароль. Он обрабатывается Binkd
с учетом символов верхнего и нижнего регистров. При передаче по сети па-
роль не шифруется;
□ [FLAVOUR] - обозначается одним символом и задает флейвор, определяю-
щий способ вызова удаленной системы при передачи информации из файл-
бокса: i(mmediate), c(rash), d(irect), - (none), h(old).
□ [FILEBOXES (OBOX И IBOX)] - файл-боксы представляют собой уже зна-
комый по конфигурации мейлеров (глава 7) механизм персональных входя-
щих и исходящих директориев. Для каждой системы-линка может быть задан
свой исходящий и входящий директорий. Как только в исходящем файл-боксе
для данной системы появляется какой-либо файл, он ставится на отправку
с указанным флейвором и будет передан на данный адрес во время ближайшей
сессии. Если указан входящий файл-бокс, то все принятые во время сессии
с данным узлом файлы будут складываться в этот директорий. Если входя-
щий файл-бокс не указан, то используется основной входящий директорий.
Далее следуют примеры, взятые из документации по Binkd:
node 888 - - # по-настоящему минималистское описание
node 9999/888 host.domain.com super_password
node 777:9999/888.66@nichego.net 123.45.67.89:666 -
node 777:9999/888.66@nichego.net - another_super_password
# этот пароль замещает пароль из предыдущей строчки
node 5047/999 * - i с:\\bbs\\boxes\\to999 с:\\bbs\\boxes\\
from999
node 2:5020/118 *;comp.chem.msu.su;158.250.32.97:binkp;
158.250.32.40:24554 -
На этом завершается описание директив конфигурационного файла Binkd.
Полная информация о них представлена в документации, составленной Нико-
лаем Совейко, и доступна с его сайта в Internet:
http://www.doe.carleton.ca/~nsoveiko
Установка и запуск Binkd
Получив исполняемый модуль Binkd, скопируйте его в один из директориев ва-
шей Fido-системы (напомним, что исходящий директорий должен быть в стиле
Binkley Term; обычно для его создания используются выделенные программы-
упаковщики). Вложите куда-либо (лучше в тот же директорий, где расположен
исполняемый файл Binkd) заполненный конфигурационный файл и запустите
программу командой:
binkd [параметры] <имя конфигурационного файла>
Например, Binkd из-под OS/2 можно запустить следующей командой:
С:\FIDO\BINKD\binkd.exe binkd.cfg
Здесь binkd.cfg - имя конфигурационного файла. Необязательные парамет-
ры в командной строке запуска программы, обозначенные выше как [пара-
метры] , используются для изменения работы программы. Они подробно опи-
саны далее.
При запуске Binkd можно использовать следующие параметры:
□ [— i] - запускать Binkd посредством сервера inetd (только для OS/2 и UNIX);
□ [~т] ~ режим «молчания». Минимизирует вывод на экран и обычно исполь-
зуется вместе с ключом -i;
□ [-с] - запустить в режиме «только клиенты» (не отвечать на входящие вы-
зовы);
□ [-С] - проверять, не изменился ли конфигурационный файл перед каждым
соединением, и выходить с кодом ошибки 3, если такое изменение обнаружено.
Используется для автоматического перезапуска при изменении конфигура-
ционного файла;
□ [~р] ~ запустить в режиме «только клиенты» и, если отправка успешно вы-
полнена, завершить работу;
□ [-s] - запустить в режиме «только сервер».
После запуска, если не обнаружена ошибка в конфигурационном файле, Binkd
сразу начинает работать. Процесс установления соединения можно наблюдать
в окне того сеанса, где запущен Binkd, и соответствующем протокольном файле.
Поскольку в одно и то же время может проходить несколько входящих и исходя-
щих сессий, то информация представляет собой порой трудночитаемую смесь из
строк, имеющих отношение к разным сессиям. Сессии различаются цифровым
идентификатором, который печатается в начале каждой строки после временной
метки. Например, такие идентификаторы можно увидеть на рис. 11.8 (обозначе-
ния [1342] и [1412]). Проценты внизу экрана отображают процесс приема файла.
Для анализа протокольных файлов Binkd есть несколько утилит, часть которых
Fleetstreet 1.24.1 - КAZAN.12.GENERAL (Е) j ° | □ >
File Edit Message Special Rexx Setup Windows Help
From: Stat Robot 2:5049/12 29 Feb 2000 23-51 56
To: All
Subj: Statistics for Binkd Main Line
Г Attrib: | sent local read
Statistics For 28 February 2688 \
Total 22119/4223,1.7/13.9 8(2£6/3.349
1—5—Fl— n £q 'b
.................................................... [.... |....41.... [' INS Г 999 of 1000' |....2.5049/12’
Рис. 11.9. Письмо, сформированное утилитой BSTAT(автор Андрей Сухоруков),
содержащее суточный анализ протокольных файлов программы Binkd на узле
2:5049/12@fidonet
приведена в списке на рис. 11.7 (BDLA, BSTAT). Образец работы одной из таких
утилит представлен на рис. 11.9.
Заключение
Использование Internet как универсального транспорта, наравне с модемным со-
единением, описанное в этой главе, очень важно для FidoNet, поскольку исполь-
зование технологии Internet имеет решающее значение для выживания FidoNet
как единого целого.
Кроме того, эта же технология может быть с успехом применена даже в том слу-
чае, когда пользователь сети не имеет соединения с Internet.
Дело в том, что технология передачи почты по сетям TCP/IP не привязана
к Internet. Можно использовать ее в локальной сети, настроив соответствующим
образом протокольный стек. Так, технология Binkd считается наиболее удобной
для раздачи Fido-почты в локальной сети (это может быть и офисная локальная
сеть, и домашняя сеть на 2-3 компьютера).
Точно так же с успехом можно применять и коммутируемое соединение по
TCP/IP, не будучи подключенным к Internet, для передачи почты FidoNet. Доста-
точно настроить Dial-In сервер, принимающий звонки по телефонной линии от
внешних компьютеров и выдающий им адреса TCP/IP, и появится возможность
одновременно с передачей Fido-почты использовать и другие ресурсы хостового
компьютера, например BBS или такие сервисы TCP/IP, как WEB и FTP.
Глава XII
Интерфейс пользователя:
редакторы Fido-почты
Редакторы сообщений FTN предоставляют интерфейс, с помощью которого
пользователь получает возможность взаимодействовать с сетью. Именно эти про-
граммы образуют видимое лицо сети и от их качества зависит привлекательность
и удобство использования FidoNet. Поэтому популярные программы-редакторы
FidoNet представляют собой сложные системы с развитым интерфейсом пользо-
вателя и обширными возможностями по редактированию, просмотру и поиску
сообщений. Они по существу являются интерфейсом пользователя к базам дан-
ных нетмейла и эхо-сообщений, хранящихся на локальном или сетевом диске.
Общий размер такой базы данных может быть большим, до нескольких сотен ме-
габайтов (сотни тысяч сообщений), и FTN-редакторы обеспечивают быстрый,
структурированный по почтовым областям доступ к этой информации.
В данной главе будут рассмотрены основные возможности программ-редакто-
ров сообщений на примере нескольких наиболее известных и популярных паке-
тов. Почти все программы-редакторы достаточно хорошо документированы, и пос-
ле прочтения настоящей главы их настройка и использование не должны вызывать
каких-либо затруднений.
Основные понятия
Рассматриваемые в этом разделе программы имеют мало общего с такими извест-
ными программами-редакторами текстов, как, например, Misrosoft Word или ему
подобными. Такие возможности, как WYSIWYG (совпадение того, что отобра-
жается на экране, с тем, что будет напечатано на принтере), интеграция графи-
ческих файлов и файлов других приложений (например, файлов электронных
таблиц) в текст документа, хранение истории редактирования и т.п., здесь не
слишком нужны и потому не используются. Зато представляемые здесь про-
граммы-редакторы сообщений обладают такими возможностями, которые от-
сутствуют у традиционных текстовых редакторов.
В этом разделе будут описаны основные режимы работы и традиционные под-
ходы к организации интерфейса FTN-редакторов сообщений на примере двух
популярных программ - редактора Gold Editor, автором которого является Один
Соренсен (Odinn Sorensen), и редактора Fleet Street, созданного Мишелем Хойе-
ром (Mihael Hohner).
GoldEd на протяжении многих лет был и остается самой популярной програм-
мой-редактором писем в FidoNet, это старая (первая версия 1990 года) програм-
ма, имеющая классический для MS DOS внешний вид.
Fleet Street создана гораздо позднее и обладает развитым графическим интер-
фейсом, что повышает удобство использования программы, но и предъявляет бо-
лее высокие требования к мощности компьютера. Fleet Street работает под управ-
лением оконного менеджера операционной системы OS/2.
Далее будут последовательно рассмотрены основные режимы и возможности
FTN-редакторов. Следует иметь в виду, что другие программы-редакторы подоб-
ного рода, отличные от GoldEd и Fleet Street (а их десятки), тоже включают ана-
логичные режимы и возможности, однако вышеназванные являются своего рода
«чемпионами» по всем параметрам.
Типы почтовых областей (Message Areas)
Почтовые области в FTN-редакторе сообщений различаются как по типу хранимой
информации, так и по способу хранения. Следует хорошо представлять все тонкос-
ти описания почтовых областей, чтобы случайная ошибка не привела к искажению
технической информации и, как следствие, к невозможности использования дан-
ной почтовой области. Примерная классификация областей приведена ниже.
Классификация по типу хранимой информации
Обычно различаются следующие типы хранимых сообщений:
□ нетмейл. В данной области хранится личная почта. Обычно хранение нетмей-
ла осуществляется в формате MSG (см. описание формата MSG в главе 4), но
можно хранить нетмейл и в базах других форматов;
□ эхо-конференции. Письма в данной области представляют собой письма в эхо-
конференцию. Хранение может осуществляться в любом из популярных фор-
матов, но формат MSG для хранения эх сейчас используется очень редко;
□ локальная область. Письма этой области не должны отправляться по сети
и хранятся только на данном компьютере. Для хранения может использовать-
ся любой формат;
□ область дефектной почты (badmail). Это разновидность локальной области,
предназначенная для хранения почты, квалифицированной программным
обеспечением (тоссером, трекером) как дефектная;
□ область дублированной почты (dupemail). Еще одна разновидность локаль-
ной области, предназначенной для хранения дублированной почты.
Классификация по способу хранения
Используются следующие форматы хранения базы сообщений (ранее были рас-
смотрены в главах 4 и 8):
□ MSG или FTS-001. Нетмейл-области чаще всего хранятся в этом формате,
причем основная нетмейл-область всегда содержится в MSG-базе. Дополни-
тельные нетмейл-области иногда хранятся и в базах других форматов, более
быстрых и эффективных при поиске и просмотре. Подробное описание фор-
мата MSG приведено в главе 4, а замечания по его использованию можно най-
ти в главах 7 и 8;
□ SQUISH. Большинство редакторов писем «понимают» этот формат, так как
разработчик одноименного тоссера в 1991 году выпустил в свет инструмент
для разработки (MSGAPI), предоставляющий программисту удобный про-
граммный интерфейс для манипулирования MSG- и SQUISH-базами. Фор-
мат SQUISH описан в 8 главе;
□ HUDSON. Этот формат уже устарел, так как его реализация ориентирована
на файловую систему DOS и не поддерживает хранение больших (более 16 ме-
габайтов и/или более 200 областей) объемов почты. Однако многие редакто-
ры сообщений по традиции еще поддерживают этот формат. HUDSON-база
описана в главе 8. Формат HUDSON самый быстрый, по этому параметру ему
нет равных;
□ JAM. Этот формат разработан несколько лет назад для BBS Remote Access и сей-
час очень популярен, многие редакторы (в частности, Gold Editor и Fleet Street)
его поддерживают. Есть бесплатный API, упрощающий работу с JAM-форматом.
Более подробные сведения о почтовых базах JAM представлены в главе 8.
Операции и функции
Редакторы сообщений включают такие возможности, которые отсутствуют в стан-
дартных редакторах текста и поначалу могут показаться непривычными или лиш-
ними, но после освоения становятся удобными и настолько же необходимыми, как
и сама возможность печатать на клавиатуре.
Так, для FTN-редакторов общепринят и широко используется описанный ниже
набор операций и функций.
Templates. Темплейты писем, или шаблоны, - это механизм создания стандарт-
ных стилей оформления. Шаблоны позволяют значительно ускорить и упростить
создание писем, избавляя пользователя от необходимости искать в нодлисте адрес
или имя, формировать приветственные заголовки, подписывать письмо и т.д.
Многоязыковая поддержка. Использование различных раскладок клавиатуры
и возможность внесения изменений в интерфейс самой программы - одна из важ-
ных сторон работы FTN-редакторов, существенно упрощающая их локализацию.
Обычно эта возможность реализуется за счет вынесения всех языковых констант
интерфейса в специальные языковые файлы, допускающие редактирование и за-
мену
Способы ответа и создания письма. Разнообразие способов, которыми можно
создать письмо в FTN-редакторе, включает следующие механизмы:
□ New Message. Режим создания нового письма присутствует во всех без ис-
ключения редакторах сообщений. При создании письма поддерживаются
стили оформления письма (templates), для заполения заголовка использует-
ся нодлист;
□ Quote Reply. Квотинг - это создание нового письма в режиме ответа с цити-
рованием оригинала. Цитата обычно выделяется шрифтом или цветом. Ци-
тирование является исключительно удобной особенностью, формирующей
стиль писем FidoNet. Редакторы сообщений позволяют сформировать ответ
с цитированием оригинала или без;
□ Reply (Reply-То и Reply-From). При ответе на то или иное письмо, как прави-
ло, можно выбрать адрес, по которому этот ответ будет послан. Это может
быть адрес, с которого было отправлено исходное письмо (режим Reply-
From), или адрес, на который письмо адресовано (Reply-То). Причем можно
отказаться от цитирования оригинала, ответить на письмо корреспондента
в другой почтовой области и т.п.;
□ Copy/Move/Forward. Можно создать новое письмо, используя операции ко-
пирования (Сору), перемещения (Move) в другую область уже существую-
щего письма, или пересылки (Forward). Необходимо только помнить, что
в случае использования операций копирования и перемещения полученное
в результате сообщение будет содержать те же самые служебные строки,
включая идентификатор письма (MSGID), что и оригинал, и может на осно-
вании этой информации сочтено его дубликатом и отфильтровано, несмотря
на то, что содержание такого письма порой существенно отличается от исход-
ного сообщения.
Операции с письмами. Операции с письмами входят в обязательный перечень
функций любого редактора сообщений и, как правило, обеспечивают следующий
минимальный набор:
□ копирование (Сору) в ту же самую или другую область;
□ перемещение (Move) в другую область;
□ экспорт (Export), то есть запись на устройства хранения;
□ удаление (Delete) обычно с возможностью восстановления;
□ пересылка (Forward) в ту же самую или другую область;
□ изменение (Change) после того, как письмо уже было написано;
□ печать (Print);
□ рассылка по многим адресам (Carbon Сору);
□ рассылка в несколько почтовых областей (Cross-Post).
Навигация по базам писем. Способы навигации по базам писем включают вы-
бор нужной области и перемещение в ней по списку писем, обычно позволяющее
быстро и удобно выполнять следующие операции:
□ сдвиг на одно письмо в направлении начала или конца области;
□ сдвиг в начало и конец списка. Позволяет выбрать в качестве текущего пер-
вое или последнее письмо в данной области;
□ «перелистывание». Под этим понимается перемещение на фиксированное чис-
ло писем. Обычно эта услуга начинает действовать в режиме вывода списка
писем на экран. Выполняется с использованием клавиш PageUp/PageDown;
□ создание цепочки ответов (Thread lists). Навигация по цепочкам писем-отве-
тов в эхо-дискуссиях является одной из самых необходимых операций, обыч-
но поддерживаемых редактором писем.
Контекстный поиск. Эта операция позволяет найти указанную строку среди
писем данной области или нескольких указанных областей.
Сканирование. При запуске программы редактора, а также в процессе работы
по команде оператора либо автоматически выполняется так называемое сканиро-
вание (Scan) всех или некоторых областей. При сканировании выясняется общее
количество писем в области, количество прочитанных писем и выбирается теку-
щее сообщение, которое будет выведено на экран при выборе данной области. Не
нужно путать сканирование, выполняемое редактором сообщений, со сканирова-
нием, выполняемым тоссером при экспорте писем из базы данных. Это совершен-
но разные операции, хотя и называются они одинаково, поскольку и в том и в дру-
гом случае имеет место просмотр (сканирование) базы данных с чтением заголовков
всех писем.
Существует также множество других, не столь необходимых операций, некото-
рые из них рассмотрены ниже.
Режимы работы
Как правило, у редактора писем всего два основных режима работы.
Режим просмотра сообщений
В этом режиме пользователь может просматривать текущее письмо. Кроме того,
здесь обычно также возможны:
□ навигация по списку писем в выбранной области;
□ навигация по списку областей;
□ навигация по цепочкам дискуссий;
□ копирование и перемещение сообщений между областями;
□ удаление писем;
□ запись писем в дисковый файл;
□ просмотр нодлиста;
□ просмотр файла подсказки;
□ поиск текстовой строки в письмах в одной или более областях;
□ отметка писем и групповые операции;
□ фильтрация отображаемых сообщений по списку Twit-list (описано ниже),
а также некоторые другие операции.
Режим редактирования сообщения
В этом режиме пользователь производит набор текста письма. Это может быть
редактирование (дополнение или изменение) уже имеющегося на диске сообще-
ния, или создание нового письма, или написание ответа на какое-либо письмо
(с цитированием или без цитирования оригинала) с помещением ответа в ту же
область, где находится оригинал, или в другую выбранную область.
Стандартными клавиатурными командами при редактировании являются ко-
манды реликтового DOS-редактора WordStar (например, удаление строки -
Ctrl+Y и т.п. - описание набора команд WordStar можно найти в литературе).
При редактировании доступен просмотр Help-страниц по командам и режимам
редактирования.
Ввод адресной информации при правильном подключении нодлиста может
быть автоматизирован. Также обычно автоматически, с использованием механиз-
ма шаблонов, формируются заголовок тектста письма и подписи.
При наборе текста используется тот или иной способ блочного копирования.
Все эти возможности делают редактор сообщений очень удобным средством
работы в сети, гораздо более подходящим для коммуникации с FidoNet, чем обыч-
ный текстовый редактор. Поэтому, несмотря на внешне устаревший текстовый
интерфейс, хаотичный по составу help-файл и множество других «странностей»,
Gold Editor остается самым популярным FTN-редактором, по крайней мере, в R50.
Что же касается Fleet Street, то его распространению мешает отсутствие DOS-
и Win32-BepcH& По всем внешним параметрам эта программа вполне отвечает
требованиям сегодняшнего дня.
Следует отметить, что обе программы, выбранные в качестве примера, с недав-
них пор распространяются бесплатно и доступны в исходных текстах. Уже появи-
лись переделки Gold Editor, в которые внесены те или иные усовершенствования.
В следующих разделах будут рассмотрены примеры использования основных
режимов и возможностей FTN-редакторов.
Примеры использования
GoldEd и Fleet Street представляют собой в некотором смысле полярные подходы
к формированию интерфейса пользователя. Каждый из них имеет своих привер-
женцев.
Gold Editor демонстрирует минималистский подход. Одноуровневые меню,
упрощенная система выделения/копирования блоков текста, очень скромная, не-
гипертекстовая help-система создают впечатление, что при создании интерфейса
этой программы автор приницпиально не использовал какие-либо API. В сущнос-
ти, так оно и было - Gold Editor первоначально был написан для DOS, когда по-
добный стиль создания программ был общепринятым.
Fleet Street же в полной мере использует возможности, которые предоставляет
объектный интерфейс OS/2 Presentation Manager. Drag&Drop-onepa4HH для сме-
ны шрифтов, многооконный интерфейс, применение кнопок-пиктограмм, иерар-
хическое (в стиле файлового интерфейса РМ OS/2) построение списка областей,
подключение внешних обработчиков, написанных на REXX, и т.д. - все это дела-
ет Fleet Street исключительно удобной программой, но, к сожалению, не перено-
симой под другие операционные системы.
В этом разделе мы, стараясь не заострять, внимания на отличиях и отмечая об-
щие черты, рассмотрим основные доступные в обоих редакторах операции.
Навигация по базе сообщений
Навигация по базе писем включает в себя:
□ выбор нужной области (то есть навигацию по списку областей, максималь-
ный размер которого может достигать тысячи записей);
□ выбор нужного письма в данной области;
□ просмотр цепочек дискуссий.
Выбор области
Обычно после вызова программы и сканирования всех или части почтовых облас-
тей инициализируется навигация по списку областей (так делает GoldEd, рис. 12.1)
или вызывается на экран текущее письмо в области, которая была выбрана послед-
ней во время предыдущего запуска программы (так поступает Fleet Street). Нави-
гационное окно областей (AreaList) в этой программе появляется при нажатии
клавиш Ctrl+A, выборе иконки на панели инструментов (ToolBar) или соответ-
ствующего пункта в меню Windows. Окно AreaList программы Fleet Street изоб-
ражено на рис. 12.2. Отметим, что все окна в этой программе запускаются как от-
дельные процессы и работают одновременно с основным окном редактирования
(это существенный момент, например, для режима контекстного поиска, который
отнимает много времени, в случае Fleet Street можно продолжать работу в основ-
ном окне редактора, не дожидаясь окончания этой операции).
GoldEd и Fleet Street демонстрируют различные подходы к системе навигации
по списку областей. У GoldEd набор отображаемых в списке параметров фикси-
рован, а правила сортировки списка гибко настраиваются в конфигурационном
файле. Сам же список представляет собой линейное меню, при выборе с помощью
>>[ FC/2: ged2.exe | ° jioij
^ick New Area: Л КЛ . r*
ньуь" new luiuiu u i ^related e 1140 1140 RU. CDROM К Q Ип IT rela 122 122 RU. CERT I FI CAT I ON К ent (new 1838 1838 RU.HARDW.CHECK К hardware 3108 3108* RU.CISCO К Hussion (R 438 438 RU.CRYPT К home area 2112 2112 KAZAN. 12. GENERAL В 367 367 SU.TOST К ysop's ec 1661 1661 ENET. SYSOP К fflsop gener 710 710 SU.IP.SYSOP К згу tales 1793 1793 FIDONET.HI STORY К :y discussio 0 О P5DRAFT К '-fidonet di 195 195 RU.FI DO.NEXTGEN I ation echo f 0 0 F-BONE-NZ К | artarNet and 1329 1329* TARTAR.FI SHI NG К К - exellent m 1194 1194* RU.FLEETSTREET К 1 texts (ExUSS 1595 1595 SU.KSP.TEXTS К J jests in 504 113 113 5049.BONE.REQUESTS В | t points 843 843 5049.POINT В ing 6 6 KAZAN.12.WEBTEST C from 5049 118 118 FREE.TALK В
1 Scan fill 1
Scan Marked Scan Current Scan Matching Scan Unscanned Scan Group No Scan / ESC
74k Fidonet hist( 75 FidoNet polic 76k Fidonet-after 77 File notifies 78k Fishing in T< 79k Fleetstreet - 80k Folks-songs 1 81k For echo reqi 82k for TartarNel 83k For WEB-testi 84k Free talking
III 85> FRIP (dz'z ftndinamic г 1' я
86k FTN soft developer area 94 94 R50.TSC К Я 87k FTSC discussion (readonl 1439 1439 FTSC_PUBLIC К 88k General (ExUSSR) fido te 1255 1255 SU.FIDOTECH К 89k General car-related area 21300 21300* SU.CARS К 90k General echopocessor-rel 636 636* RU.ECHOPROCESSORS К 91> General internet tech di 2759 2759 RU.INTERNET.TECHNOLOGY К 92k General mailer discussio 901 901 SU.MAILER К 93k General MV echo 229 229 RU.GENERAL.MV К 94k General network discussi 1497 1497* SU.NET К 95k General r50 WAN-related 2510 2510* RU.NETWORKS К 96k General sysop discussion 478 478 SU.SYSOP К 97k Gladkin's brake support 3552 3552 BRAKE'S.MAILER.SUPPORT К ф
17:31 М2
GoldED/2 3.0.1 | RU.FRIP: 1 msg, 1 unread, 0 personal
Рис. 12.1. Окно выбора области в FTN-редакторе писем GoldEd
(версия 3.01 для операционной системы OS/2)
[д}: Area list
SO
Area
MVS-bone
General
Netmail
My
Netmail/Echoes
FidoSysop
Local
Hardware
Networking
" TRANSX..........
: 1072 COMPNEWS
1072 COMPNEWS.TALK
ELABUGAGENERAL
: F-BONE-NZ
FIDONET.HISTORY
N5020 SYSOP.INFO
, ОВЕС ЗВОН
ОВЕС РАСТЕТ
PRISON
Tartar Echoes
= PVT.VIRII
' R50 BONE.ECHO
RUBUG
' RUCDROM
RU CRYPT
RU GUITAR
RU HACKER
; RU MIGRATION
’ RUOSCMP
RU PHREAKS
RU SECURITY
RUUNIX
RU.UNIX.BSD
RU.WEAPON
RUSSIAN.Z1
SU.CARS
SU.HAM RADIO
SUKSP
SU.KSP.TEXTS
SU.TOST
SU.TRAVEL.
TEST1
General Echoes
new
754
761
204
1292
1125
5876
1358
378
665
30
1132
421
3182
2958
1992
9688
497
2409
9831
1208
2523
5883
18
11
365
555
total
830
1069
697
0
1788
1173
5876
1358
378
1036
30
1132
421
3182
2958
553
1992
9688
497
2409
9832
1466
5964
21183
100
300
1590
365
558
0
Рис. 12.2. Система навигации по списку областей
(AreaList) в редакторе писем Fleet Street
клавиши одной из позиций которого Enter активизируется данная область. Это
удобно, когда областей в списке не больше 20-30, но когда их десятки или сотни,
сразу возникает необходимость в иерархической организации списка. Справед-
ливости ради следует отметить, что такое большое количество активных (то есть
хранящихся на локальном диске) областей встречается редко. Единственное до-
полнительное меню, доступное из меню списка областей, - это меню выбора спо-
соба сканирования (оно изображено в верхнем левом углу списка). Можно скани-
ровать либо все области, либо только отмеченные, либо только текущую и т.п.
Fleet Street предлагает удобную утилиту навигации AreaList, включающую
иерархический список папок-контейнеров для областей, который изображен в ле-
вой части окна программы на рис. 12.2. Красные «язычки» отмечают наличие
непрочитанных писем в одной или нескольких областях, хранящихся в данной пап-
ке. Свертывание и раскрытие ветвей списка производится обычным для интер-
фейса OS/2 способом. В правой части окна выводится список областей в вы-
бранной папке, область, отмеченная курсором, считается текущей.
Указав на нужный объект (папку, область, выделенную группу областей) и щелк-
нув правой кнопкой мыши, можно вызвать контекстное меню, которое позволит
изменить основные параметры выделенного объекта. Кроме контекстного меню
17 - 431
в нижней части окна программы есть несколько кнопок для вызова процедуры
сканирования и подсказки.
Распределение списков областей по папкам, создание новых областей и т.п. осу-
ществляются стандартными для OS/2 средствами - Drag&Drop, вызовом кон-
текстных меню и т.п.
Все эти средства делают AreaList исключительно удобным средством для нави-
гации по списку областей.
Навигация по списку писем в выбранной области
Почти все редакторы, не только GoldEd и Fleet Street, используют одинаковый под-
ход к навигации по списку писем в пределах одной выбранной почтовой области.
Он заключается, во-первых, в использовании клавиатурных команд, приведенных
в табл. 12.1, которые удобны для быстрого перемещения по почтовой области. Дуб-
лирующие их пиктограммы, находящиеся в редакторе Fleet Street, на практике ис-
пользуются очень редко. Во-вторых, почти во всех редакторах есть возможность
вызвать список сообщений со своей системой клавиатурной навигации.
Такие списки сообщений, очень удобные для быстрого поиска нужного письма
по его заголовку или адресной информации, показаны на рис. 12.3 и 12.4 для
GoldEd и Fleet Street соответственно.
В представленном на рис. 12.3 списке построчно выводятся краткие сведения
о каждом письме: порядковый номер в базе сообщений, имена отправителя и ад-
ресата, заголовок письма и дата его получения. В подвале списка выводится пол-
ностью заголовок текущего письма, выбранного курсором. Возможна навигация
по списку с помощью команд, набранных с клавиатуры:
Таблица 12.1. Клавиатурные команды перемещения по почтовой области
для FTN-редакторов Fleet Street и GoldEd
Клавиатурная последовательность Выполняемое действие
—> (стрелка вправо) Перемещение на одно письмо к концу области
<— (стрелка влево) Перемещение на одно письмо к началу области
Enter (только GoldEd) Если письмо полностью умещается на экране - то переход к следующему, если нет - просмотр (как клавиша PgDn)
Control+Home Перемещение к первому письму
Control+End Перемещение к последнему письму
Control+-> Перемещение к ответному письму, находящемуся ближе к концу области относительно данного
Control+<— Перемещение к ответному письму, находящемуся ближе к началу области относительно данного
T, 4, Page Down, Page Up Просмотр письма, если оно не помещается на экране целиком (перемещение на одну строку или на страницу вверх/вниз по тексту письма)
Control+N, Control+P Перейти в следующую по списку (N) или в предыдущую (Р) область. Эта команда только для GoldEd, у Fleet Street есть аналогичная по функциям кнопка- пиктограмма, можно также вызвать AreaList командой Control+A
□ Esc - выйти из режима списка писем;
□ Ноте - выбрать курсором первое сообщение;
□ End - выбрать курсором последнее сообщение;
□ Стрелка вправо (-») - выбрать курсором следующее сообщение;
□ Стрелка влево (<—) - выбрать курсором предыдущее сообщение;
□ Alt+S - вызвать меню отметки (оно изображено на рисунке);
□ Ctrl+B - переключиться между «широким» (40 символов) и «узким» (20 сим-
волов) режимами отображения поля темы (subject) писем;
□ Enter - перейти в режим просмотра, остановиться на выбранном письме;
□ Пробел - поставить/снять отметку с текущего письма;
□ Tab - поставить/снять BookMark-отметку с текущего сообщения (BookMark-
отметка позволяет поставить метку на каком-либо письме в данной области
и позже вернуться на эту позицию);
□ Shift+Tab, Backspace - перейти к BookMark-метке.
Единственное меню, вызываемое в данном режиме, - это меню отметки, пока-
занное в верхней левой части рис. 12.3. Оно позволяет быстро и удобно отмечать
письма для совершения затем над отмеченными наборами групповых операций
удаления, экспорта и т.п.
I- Fidonet history tales (2;50 49/12) - FIDONE
Msg From 197 Ilya Grachenkov 198 Ilya Grachenkov 199 Ilya Grachenkov 200 Sergey Dizhur To Subj , Written Kit Pavlowsky Я плакалъ 11 Oct 99 Ц Kit Pavlowsky Win95 11 Oct 99 Aleksey Podchufarov Win95 11 Oct 99 Viktor Zabelin (aka FAQ, revision 19, (1 14 Oct 99
Your personal mail II all плохо доходит почта 13 Oct 99
Header (From/To/Subj) Text and header Reply thread New msgs >current Old msgs <current All msgs Unmark all msgs Msg range (bookm-curr) Toggle all marks Quit / ESC All FAQ, revision 19, (1 14 Oct 99 f Denis V. Semenov Вопрос... 14 Oct 99 All Анекдот про курочку 14 Oct 99 Denis V Semenov Вопрос... 15 Oct 99 Denis V. Semenov Re: Вопрос... 15 Oct 99 All байты 15 Oct 99 Ilya Grachenkov Я плакалъ 16 Oct 99 Alexey Urmanov Re: байты 16 Oct 99 Ilya Grachenkov Я плакалъ 18 Oct 99 Alexey Urmanov ' Re: байты 18 Oct 99 Denis V. Semenov Вопрос... 16 Oct 99 Serguei Trouchelle плохо доходит почта 16 Oct 99
215 Igor V. Pol 216 Alexey Surba 217 Viktor Zabelin (ak 218 Viktor Zabelin (ak. 219 Oleg Lopatin 220 Alex Kulikov 221 Sergei Shelukhin 222 Denis Anciferov 223 Lena Petrenko 224 Moderator of FIDONI 225 Serg Ershov 226 Ilya Grachenkov 227 Ilya Grachenkov 228 Viktor Zabelin (ak< 229 Cyrill Vakhneyev All . Как дурят нашего бра 16 Oct 99 All /98 AKA Sergey Sinya 16 Oct 99 a Sergey Dizhur Re: FAQ, revision 19 16 Oct 99 a Ilya Grachenkov Re: FAQ, revision 19 16 Oct 99 All Дмитрий Орел 17 Oct 99 Viktor Zabelin (aka FAQ, revision 19, (1 17 Oct 99 Dmitry Zyazikov байты 18 Oct 99 Alexey Urmanov байты 18 Oct 99 Oleg Lopatin Дмитрий Орел 19 Oct 99 E All Rules of FIDONET.HIS 19 Oct 99. Alexey Urmanov Re: байты 19 Oct 99 Viktor Zabelin (aka FAQ, revision 19, (1 19 Oct 99 Kit Pavlowsky Я плакалъ 19 Oct 99 a Alex Kulikov FAQ, revision 19, (1 20 Oct 99 Alexey Urmanov байты 19 Oct 99 Д
Вопрос...
Gold£D/2«3,d71 | Message Marking | 17:38:93
j ° iQ
g Message Ust
4853;Viet Bo
4854 Yevgeny Poluektov
4 855: Yuri PQ
4856-Yuri Safronov
i Konstantin Mihai: iRej вопрос
Щ1 ^Спасибо (Вики Свершилось •)
Nick Noadrunov |ФАК-сервера
^TempNS076C ^вопрос
4857
4858
4859
4860
4861
№r Suvorov
Peter Didenko
Co’jaoderator
serg Borodin
Sergey titkin
Yuri Safronov
e-mail only node
08 Nov ; 09 Nov 1999 03;'^
08 Nov j 09 Nov 199$ 12 Г
09 NOV 109 NOV 1999 15;
09 Nov i09 NOV 1999 16 J
20
ШЗ Konstantin Mimilov
4863
4864
4865
4866
4867
4868
4869
Oleg Chechulin
Reyner Dmitry
Yuri Safronov
Dmitry Baronov
Igor Suvorov
Anton sunomlinov
Andrey Rookin
487C* Alexander Brictikin
4871 Ssrgey Utkin
4872 Co-шбerator
4873 Yuri Safronov
4874
4 $75
4876
4877
victor butry
Igor Suvorov
Co-moderator
Alexander Brichkin
4878 Victor bUtty
4 879 Sergey Utkin
4880 Bulat Ziganshin
4881:Bulat Ziganshin
4882,Igor Suvorov
4883;co-moderator
4884 Andrey Rookin
i File
File name
File type
j<All Files>.....
Files
- add10
add 14
add2
add9
BIBLIO
epigraphs
2J
У? with header
У separator line
Drive
V C: [0S2]
Directories
• j Г<3 ARCHIVE2 ....... ~
J; f3 fidonet I ,
человек с компьюте j
«text
£3 print
О tmp
•? append to file
□ overwrite file
j OK j j Cancel | < Help
89 Nov G9 Nov 1999 20
09 Nov 0$ NOV 1999
09 NOV 09 Nov 199$
21
23
;Andrey Rookin ;RU. KRAPIVIN - официальное ваявле.1 11
П 89 MOV 18 NOV 1999 80
IC* Nov 10 NOV 1999 07 ,
10 Nov 10 NOV 1999 IO
18 Nov 10 Nov 1999 IS
10 NOV 10 NOV 1999 17
10 Nov 18 Nov 1999 17
IC* Nov id Nov 1999 20
03 NOV IO NOV 1999 29
4 10 Nov 11 Nov 1999 00
10 Nov 11 NOV 1999 *)0
10 Nov 11 Nov 1999 08
11 Nov 11 NOV 1999 IO
11 NOV 11 NOV 1999 15
11 NOV 11 NOV 1999 20
11 Nov 11 NOV 1999 2?
11 Nov 12 Nov 1999 00
11 Nov 13 Nov 1999 12
12 NOV 12 NOV 1999 15
• RC
REC
Victor Butry
Bulat Ziganshin
Alexander Brichk.
j Осень
*Осень
e-aail only node
Re: осень
Питерский бекбон
12
12
12
12
13
Nov ,12 Nov 1999
NOV -12 NOV 199$
Nov U2 Nov 1999
Nov |12 Nov 1999
NOV J13 NOV 1999
Nov :12 Nov 1999
IS-
IS
18,
20 f
20 Г
23>
,ris11.9.txt
Рис. 12.4. Вызов функции экспорта для отмеченных в списке писем
(FTN-редактор Fleet Street)
Рис. 12.4 показывает, как использовать контекстное меню, которое вызывается
из списка писем в программе Fleet Street щелчком правой кнопки мыши по объек-
ту (письму или отмеченной группе писем, как изображено на рисунке).
В приведенном примере текст выбранных писем экспортируется в файл на дис-
ке. Из контекстного меню, кроме функции экспорта, вызываются также функции
удаления, печати, копирования, перемещения и выделения.
Удобство списка, предоставляемого Fleet Street, заключается в свободном кон-
фигурировании длины отображаемых полей и размера используемых для этого
шрифтов, что позволяет выводить максимум полезной информации. Клавиатур-
ные команды навигации по списку в основном аналогичны используемым в GoldEd
(описаны выше).
Навигация по цепочкам дискуссий
Работа с цепочками взаимосвязанных писем, представляющих собой взаимные от-
веты и обычно называемые дискуссиями, является тем, что наиболее ярко отличает
FTN-редакторы от обычных текстовых редакторов и роднит их с другими система-
ми просмотра конференций, например, с распространенными в Internet ньюс-риде-
рами. Чем лучше в редакторе сообщений организована работа с дискуссиями (или
тред-листами, или списками взаимных ссылок), тем удобнее им пользоваться для
просмотра эхо-конференций, а это, без сомнения, самый популярный сервис
FidoNet. Взаимные ссылки идентифицируются по кладжам, в которых обычно ука-
зывается идентификатор письма, на которое отвечает данное письмо. Это кладж
AaREPLY, ранее описанный в этой книге. Вот пример его использования:
©REPLY: 2:5020/758.12 3843са2е
Здесь видно, что письмо, из которого взят данный кладж, служит ответом на пись-
мо с адреса 2:5020/758.12, которое имеет уникальный идентификатор 3843са2е.
Есть и другие механизмы связывания (линковки) писем. Например, обычно
в качестве признака связывания используется содержимое поле темы (subject)
письма. Письма, у которых заголовки совпадают, считаются принадлежащими
одной дискуссии.
Вся информация о взаимных ссылках предоставляется FTN-редактору други-
ми программами (например, тоссером), собирающими ее и помещающими в ин-
дексные файлы базы сообщений.
GoldEd демонстрирует традиционный подход к навигации по цепочкам ссылок.
При нажатии клавиш Ctrl+—э и Ctrl+<— (табл. 12.1) в цепочке ответов происходит
перемещение либо к следующему, либо к предыдущему письму, соответственно.
Если ответов несколько, то выводится меню, из которого можно выбрать нужное
письмо и перейти к нему, как это изображено на рис. 12.5.
'eated
/С/2: gedZexe^
Ж
1"з""1 : А1 ekse i Pogor i ly (2:5020/1504) III lllllllli— 07 МИВ 00 13:57:41 1
+ 132 Aleksei Pogorily (2:5020/1504) 07 Feb 00 14:21:25
+ 135 Dave Asatrian (2:5020/2550) 07 Feb 00 17;10:13 Шена
+ 136 Dmitry Serov (2:5020/2496) 07 Feb 00 17:18:02
+ 140 Uadim Lisovsky (2:5020/2200. 1) 07 Feb 00 17:50:42
+ 142 Denis V. Semenov (2:5020/961.1) 07 Feb 00 16:02:06
+ 146 Maxim Mazepa (2:5020/1392) 07 Feb 00 19:05:59
+ 149 Serg Kolesnikov (2:5020/1714) 07 Feb 00 17:38:49
+ 150 Dmitry Rechkin (2:5020/336) 07 Feb 00 21:25:34
+ 155 Nicolas Strochkov (2:5020/1493. 1) 08 Feb 00 00:10:47
+ 156 Andrew Khokhlushin (2:5020/1349. 132) 07 Feb 00 23:49:11
+ 161 Mikel Lavrentyev (2:5020/35.1) 08 Feb 00 00:51:14
+ 162 Boris Zamansky (2:5020/1253. 1) 08 Feb 00 01:28:09
+ 167 Vladimir Generalov (2:5020/227) 07 Feb 00 21:45:16
+ 171 Sergey Fadeyev (2:5020/877) 07 Feb 00 19:11:24
+ 226 Oleg Strakhov (2:5020/2320) 08 Feb 00 17:41:10
+ 240 Vladimir Jarmish (2:5020/2003) 08 Feb 00 22:04:39
+ 308 Boris Ivanov (2:5020/1779) 09 Feb 00 18:12:31 12/БМ
4- 347 Vladimir Trigubov (2:5020/874) 09 Feb 00 17:43:15
5.К
а)
ситуацией, рекомендовать N5020EC.-
создать списки конференций, распространяемых хабами всех уровней на
правах локальных конференций, и не поднимаемых на бэкбон по техническим
или любым другим причинам и не рассматривать заявки о приеме данных
эх на бэкбон.
прием конференций, отсутствующих в этом списке осуществлять в порядке
очередности поданных заявок независимо от физического нахождения их на
бэкбоне.
б)
0
GoldED/2 3.0.1 | Select the
17:43:30
Рис. 12.5. Меню ответов на письмо, вызываемое нажатием клавиш навигации
по цепочкам ответов в режиме просмотра писем FTN-редактора GoldEd 3.01
На этом возможности GoldEd по работе с цепочками дискуссий заканчивают-
ся. Fleet Street демонстрирует более совершенный подход к задаче навигации дис-
куссий; для каждой эхо-конференции или нетмейл-области возможно построение
так называемого тред-списка (Thread-list), предоставляющего удобный интер-
фейс для доступа к дереву дискуссий, как это изображено на рис. 12.6. В Thread-
list возможно отображение либо всех дискуссий, либо только непрочитанных,
либо только непрочитанных писем (устанавливается соответствующим выбором
из меню, изображенного на рис. 12.6 слева вверху: Settings ==> View).
Контекстное меню, появляющееся при выборе мышью нужной «ветви» дискус-
сии, позволяет удалить, скопировать, переместить, экспортировать в файл или
напечатать все письма данной «ветви». Кроме того, есть перемещение по цепочке
дискуссии в режиме просмотра писем с помощью клавиатурных команд, как опи-
сано выше для GoldEd, или кнопки-пиктограммы.
Операции с письмами
Все FTN-редакторы предоставляют инструментарий для операций с письмами,
поскольку нужда в таких операциях возникает постоянно. Письма нужно пересы-
лать или «форвардить» (от англ, «forwarding»), копировать и перемещать в дру-
гую почтовую область, удалять, экспортировать текст писем во внешние файлы.
Очень удобно, если доступны групповые операции, то есть выполнение перечис-
ленных действий можно производить одновременно над множеством писем.
-f Fleetstreet 1.24.1 - RU.MIGRAT1ON (Е)
File Edit Message Special Rexx Setup Windows Help
2:5020/499
01 Dec 1999 06:50:1
30 Nov 1999 08:45:2
From: Timur Bankov
To: All
Subj: Re: Russian Plastic Card in USA
F ,hb Thread list
R':
Unread messages
&
L+J Rules & URL FAQ
Russian Plastic Card in USA
- -j Russian Plastic Card in USA (Arcady Schekochikhin)
'---Russian Plastic Card in USA. (Denis Loginov)
I---Russian Plastic Card in USA (Ostap)
---Russian Plastic Card in USA (Alexander Pankratov)
---Russian Plastic Card in USA (Vladimir Kozin)
--j Russian Plastic Card in USA (Timur Bankov)
O’
>
Russian Plastic Card in USA (Michael I),)
Russian Plastic Card in USA (Sergey Ivanov)
-----Russian Plastic Card in USA (Alexander Pankratov)
-----Russian Plastic Card in USA. (Kirill Peskov)
-----Russian Plastic Card in USA (Timur Bankov)
+J Tekmetrics sertification
+ The other landing place
, Д’ +. US Embassy in Kiev
>• + АГЕНТЫ авиакомпаний?
Будут ли чыг-нибудь комментарии?
+J Влияет-ли работа в МВД на процесс выезда за бугор?
№ +' Возраст
Рис. 12.6. Окно Tread-list (список дискуссий) в FTN-редакторе сообщений Fleet Street
П
К
Ч4'
Копирование, перемещение и пересылка. И GoldEd, и Fleet Street предостав-
ляют удобные средства для копирования, перемещения и пересылки сообщений.
При выборе этих операций выводится список областей для выбора области, в ко-
торую должно быть помещено результирующее письмо. В GoldEd соответствую-
щее меню вызывается нажатием Alt+M, во Fleet Street такое меню вызывается
аналогично, можно также использовать обычные для интерфейса оконного менед-
жера OS/2 способы вызова контекстного меню
Удаление. Для удаления письма нужно выбрать его в списке писем (см. раздел
«Навигация по списку писем в выбранной области») или вывести нужное письмо
на экран в режиме просмотра и нажать клавишу Delete или Alt+D (последнее
только GoldEd). Результатом будет запрос на подтверждение удаления.
Экспорт. Экспортом письма называется запись его текста во внешний файл на
диске. Во Fleet Street экспорт вызывается из режима просмотра либо нажатием
Ctrl+X, либо выбором нужного пункта из меню Message. При этом выводится
стандартное файловое окно OS/2, позволяющее задать имя файла, в который над-
лежит экспортировать текст, и указать режим экспорта - создание нового файла
или дополнение существующего с заголовком или без него, с разграничительной
линией или без нее. Пример такого файлового окна приведен на рис. 12.4.
Меню экспорта вызывается в GoldEd нажатием на клавиши: W, F7 или Alt+W
и позволяет экспортировать текст письма с заголовком в файл на диске (выводит-
ся строка для указания пути и имени файла), на принтер или в системный буфер
обмена. Можно также указать, нужно ли экспортировать заголовок и текст пись-
ма или только текст.
Отметка писем и групповые операции. Без групповых операций использова-
ние FTN-редактора в качестве удобного средства для работы с базой сообщений
было бы невозможно. Поэтому во всяком мало-мальски развитом редакторе та-
кие возможности должны присутствовать. Имеются они и в GoldEd, и во Fleet
Street. В последнем удобно использовать контекстное меню списка писем, как
описано в разделе «Навигация по списку писем в выбранной области». Из этого
меню можно запустить для отмеченных писем групповые операции удаления, экс-
порта, печати, копирования или перемещения.
В GoldEd отметку удобно также производить в списке писем, при наличии от-
меченных писем операции перемещения, копирования, экспорта и удаления мо-
гут быть выполнены как групповые (при их вызове выводится соответствующий
запрос).
Поиск в базе писем. Хороший интерфейс для организации контекстного поис-
ка в базе писем и эффективность самого поиска очень важны. И FTN-редактор
Fleet Street здесь вне конкуренции. Fleet Street позволяет производить поиск не
только в текущей области, но и в любых выбранных областях (для выбора нуж-
ных областей используется окно AreaList). Также можно задавать сложные зап-
росы (используя синтаксис регулярных выражений, аналогичный синтаксису
известной утилиты grep) или ранжировать поиск по дополнительным критериям
(искать только в определенных типах областей, только в поле FROM:, ТО:, SUBJECT:
заголовка письма и т.п.) Форма ввода задания на поиск приведена на рис. 12.7.
Результаты поиска сводятся в таблицу, оформленную в качестве отдельного окна,
х j Search for
। What.............
| нодлист
Which areas— ~
Ф Current area
,ДДВ||М|||1||||[1||[|
QArea types
X Hetmall areas
^fchomall areas
Local areas
• j Private areas
О Custom.
•|||И|||||Н1НИ
QCase sensitive
Ignore case
Q Fuzzy, level
□ Regular expression
□ Personal mall =
Q Unsent messages
□ Unread messages only
•Where.....T
J| Й Jlftlliilj
Start
Cancel
lHelp'/::-|.
Рис. 12.7. Форма ввода задания на поиск в FTN-редакторе Fleet Street
в котором также возможны отметка и групповые операции, что предоставляет
пользователю дополнительные удобства. Пример такой таблицы, полученной
после выполнения поиска по заданию, изображенному на рис. 12.7, приведен на
рис. 12.8.
По сравнению с Fleet Street, GoldEd предоставляет более скромные возможнос-
ти поиска. Нажав Alt+F или Shift+F6 в режиме просмотра писем, здесь можно
ввести строку и осуществить поиск ее включения в заголовок и текст писем в дан-
ной области. При этом письма в области просматриваются начиная от текущего
с, 1 ~ Bookmarks < ЙЙЙЙЙЙЙЙЙЙЙЙЙ^
Area: ... . г-——"-—
Find results
Subject
NodedifF43: /S3
nodediff.015
Area 1 No.
i From
SYSOP’S_MAIL 135 Sevka Bashkirev
SYSOP'S.MAIL 1 154 Ai.hw Sheri a
SYSOP'S_MA1L : 466 в Dmitry В agri anov
SYSOP'S_MAIL i 472 Dmitry В agri anov
SYSOP'S_MA1L i 473 n Vasily Tchekalkin
SYSOP'S_MAIL 1 504 u Sergei Yaroslavsky
Go to message > Close
Маленько help rny :)
/36.22
/36.22
Flags
нода
Clear j Help [
сообщения и до конца базы, и просмотр останавливается на первом же найденном
включении. Затем можно продолжить поиск. По нажатию Z, Alt+Z или F6 осуще-
ствляется аналогичный поиск, но вхождения отыскиваются только в заголовках
писем.
Фильтрация отображаемых сообщений (Twit-list). Бывает так, что вы не хо-
тите видеть некоторые письма, несмотря на их наличие в базе сообщений. Как
может возникнуть такое странное желание и что такое твит (twit), разъясняется
в главе 1, в разделе «Что такое твит». Стоит также познакомиться с пунктом 10.3.6
приложения 2 (FidoNet Полиси). Здесь же пойдет речь о технической стороне воп-
роса. Некоторые редакторы имеют возможность не отображать письма с адресов,
помещенных в так называемый твит-список (twit-list). В частности, такой инст-
рументарий, и достаточно развитый, есть в GoldEd. При конфигурации этого ре-
дактора доступны следующие команды:
□ TWITMODE <режим> - позволяет определить режим использования твит-
списка. Параметр <режим> может принимать следующие значения:
- show - отображать все твит-письма;
- blank - показывать твит-письма пустыми;
- skip - пропускать твит-письма, если только они не адресованы вам;
- ignore - пропускать твит-письма в любом случае;
- kill - удалять твит-письма без предупреждения;
□ TWITNAME <имя/адрес> - задает имя или адрес, который используется как
критерий для определения твит-писем;
□ TWITSUBJ <" строка" > - задает строку заголовка письма, которая исполь-
зуется как критерий для определения твит-писем;
□ TWITTO <yes/no> - определяет, нужно ли проверять поле ТО: заголовка
письма на совпадение с параметром, определенным в директиве TWITNAME
(по умолчанию установлено «по»).
Во Fleet Street какая-либо обработка твит-листов отсутствует, хотя механизм
для создания такой системы (встроенный интерпретатор REXX) в этом редакто-
ре есть.
Режим ввода письма
FTN-редакторы отличаются большим разнообразием способов создания письма
и предлагают удобные механизмы по автоматическому набору некоторых его эле-
ментов: адресной и другой служебной информации, заголовков, подписей и т.п.
Основные возможности этого режима рассмотрены ниже.
Ввод нового письма
Существует два основных способа, с помощью которых в FTN-редакторе можно
создавать письма. Первый позволяет создать новое письмо, второй - написать
ответ на письмо, полученное от кого-то. Выбрав первый режим (обычно вызыва-
ется нажатием клавиш Insert) и введя адрес назначения и заголовок письма,
пользователь получает «чистый лист» (возможно, с заданными в текущем шабло-
не подписями и заголовками). Именно такой режим изображен на рис. 12.9
Д FC/2: ged2
- Fa s t E cho N e t m a il(2:' 5649712 )
Msg : 6 of 6
From : Amirko Shaab
To : Larissa Smolyakova
Subj : nodelist update
Hello Larissa!
: O hat
т ..
Uns Loc
2:5049/12 Thu 02 Mar 00 11:10 1
2:5049/85
fliiiiiiillBSIl
Amirko
--- GoldED/2 3.0.1
Рис. 12.9. Режим создания нового письма в FTN-редакторе GoldEd
на примере FTN-редактора GoldEd. Способ создания письма посредством ответа
на какое-либо уже существующее письмо будет описан далее. Сейчас же подроб-
но будут рассмотрены основные инструменты и услуги, которые FTN-редакторы
предлагают при создании нового письма.
Ввод адресной информации
В самом начале набора нового письма пользователю предоставляется возмож-
ность редактирования его заголовка. Для этой цели традиционно служит форма
ввода, содержащая пять полей, два из которых обозначаются как FROM:, то есть
«от кого», и служат для ввода имени и адреса создателя письма. Обычно эти поля
заполняются автоматически на основании информации, взятой из конфигурации
программы, но их всегда можно изменить. Другие два поля, обозначенные как ТО:,
то есть «кому», содержат имя и адрес получателя письма. Для их заполнения
обычно используется нодлистовая информация. В эхо-письме адрес в поле ТО:
отсутствует. Последнее поле, называемое SUBJECT, служит для ввода заголовка
письма. Пример подобной формы ввода для FTN-редактора Fleet Street изобра-
жен на рис. 12.10.
2? Fleetstreet 1.24.1 - SYSOP’S_MAJL (H)
File Edit Message Special Rexx Setup Windows Help
From: Amir Shabashvili 2:5049/12 02Dec1999 0939:00
To: Vasily Tchekalkin 2:5049/45
Subj: рекомендация
Attrib J pw local read
IBIilllllllllil
p—T/—: pT: f j" jNS'-“T""CГУД Г7~£5Й9/1TWI
Рис. 12.10. Форма ввода адресной информации и строки заголовка
в FTN-редакторе Fleet Street
При наборе имени и адреса назначения возможно использование нодлиста для
автоматизации поиска нужного адреса по имени сисопа и наоборот, имени по ад-
ресу. Адрес можно вводить в любой возможной форме (от 5D до 1D или непол-
ный пойнт-адрес, начинающийся с точки), недостающие поля подставятся из те-
кущего адреса системы, определенного в конфигурации программы-редактора.
На рис. 12.11 изображен процесс поиска адреса по имени пользователя в редак-
торе Fleet Street. Чтобы инициализировать этот процес, нужно соответствующим
образом сконфигурировать программу редактора для использования нодлистовых
файлов (Fleet Street использует нодлистовый индекс формата V7, описанный
в главе 7, в разделе «Форматы индексных файлов V7 и V7+») и ввести имя адре-
сата (или его часть) в поле ТО: так, как это изображено на рисунке. В приведен-
ном примере была введена часть фамилии адресата (Smol) и в ответ выведен спи-
сок имен, построенный на основе текущего нодлиста. Теперь из этого списка
можно выбрать нужное имя и соответствующий ему адрес будет проставлен в за-
головке письма. Если же известен адрес и неизвестно имя, нужно ввести адрес или
его часть в поле, предназначенное для ввода адреса назначения, и соответствую-
щее этому адресу имя сисопа будет подставлено автоматически.
GoldEd работает аналогично, с той только разницей, что эта программа, во-пер-
вых, использует свой формат нодлистовых индексов и, во-вторых, адрес можно
вводить не в поле для его хранения, а в поле имени сразу после символов ТО:. Это
не слишком логично, но довольно удобно. Кроме того, GoldEd предоставляет
Fleetstreet 1.24.1 - SYSOP’S_MAIL (N)
File Edit Message Special Rexx Setup Windows Help
° □
From:Amir Shabashvili
To: Smol
Subj:
i Attrib; | priv local read . ___
-------г----------“lx Nodelist
2:5849/12
8:0/8
30 Nov 1999 13-34.38
Addresses for Smol
4 Sysop
: I v rauresrav •onivieirsKy
j Viacheslav Smolensky
I Vova Smoley
\ Oleg Smolianoy
< Oleg Smolianoy
i Alexey Smoliany
4 Viktor Smolienko
id Denis Smolin
Denis Smolin
। Dmitry Smolin
он Igor Smolokurov
3 Oleg Smolov
4 Leonid Smolyakov
’; Larissa Smolyakova
- \ Larissa Smolyakova
Address
2:5024/14 H
2 5029/17
2 4657/0
2:4657/10 ;=
2 5063/22
2 468/33
2 5049/87 2
2:5049/105^
2 5020/949=:
2 5035/17
2:460/54 b
2 452/15
2:5049/42 £
2 5049/46
System name I Modem type
csteve••avnrraanTurrarotw“- | .........
Nuclear Base ;
Svm-Station s
Mariupol Network i
Maverick Station i
Old Station
Nbu Net Kherson j
Butch !
Butch i
Daybreak i
- Cum Laude - i
Mf Station i.
Fantasy 2 i
Small Lark ।
Small Lark i
Flags
CM, Host
Hub
CM
CM
Lexey Smolyanov
2:5030/31 2p Children's Station
j OK j * Cancel | Help | V; Brief
: INS
2.5049/12
Рис. 12.11. Поиск адреса сисопа по его частичному имени
(при вводе нового письма в FTN-редакторе Fleet Street)
возможность использования дополнительной адресной книги, определяемой
пользователем.
Установка атрибутов письма
Вслед за вводом адресной информации пользователю предоставляется возмож-
ность установить почтовые атрибуты формируемого сообщения в дополнение
к нескольким, проставляемым автоматически в соответствии с конфигурацией
программы (обычно это атрибуты LOCAL и READ, а для нетмейл-областей - еще
атрибут PRIVATE). На рис. 12.12 изображено меню ввода атрибутов редактора
GoldEd. Fleet Street предоставляет аналогичное меню, которое в отличие от
GoldEd активизируется не автоматически, а нажатием кнопки Attribute в заго-
ловке письма.
Аналогичная процедура для редактора Fleet Street изображена на рис. 12.13;
отличия в списке атрибутов обусловлены отсутствием стандартов на некоторые
широко используемые расширенные атрибуты писем (см. описание расширенных
атрибутов нетмейл-сообщений в начале главы 7).
й FC/2: ged2 J »JD]
- Fa s t E cho Net m a i I ( 2:5049/12) - ——•--."——” NET MA IL -
Msg : 6 of 6 Uns Loc
From : Amirko Shaab 2:5049/12
To : Larissa Smolyakova 2:5049/85
Subj : Nodelist ираа1^ИИВИИ1ИИИ1ЯИ11в1ИИИМИ1И1И1В^ИИЯИИ>
---------------------------------------------- F10: Addressbook — 8F10: Nodelist —
Attributes
Private <Alt-P> Archive/Sent <Alt-B> Crash <Alt-C> Direct <Alt-D> Received <Alt-R> Zonegate <Alt-G> Sent * <Alt-S> Hub/Host~Route <Alt-V> File Attach <Alt-A> Immediate <Alt-I> Transit <Alt-J> Xmail <Alt-X> Orphan <Alt-0> Erase File/Sent <Alt-E> Kill/Sent <Alt-K> Trunc File/Sent <Alt-T> Local <Alt-W> Locked <Alt-L> Hold <Alt-H> Confirm Rcpt Request <Alt-Y> File Request <Alt-F> FTS1 Reserved <Alt-l> Return Rcpt Request <Alt-M> QBBS Reserved, Net <Alt-2> Return Rcpt <Alt-N> QBBS Reserved, Echo <Alt-3> Audit Request <Alt~Q> Squish Scanned <Alt-4> File Update Request <Alt-U> Zap all attribs <Alt-Z>
Press Alt-Fl to turn off this window
GoldED/2 3.0Л Edit Header Data
11:15:13
FleetstreetJ.241 - SYSOP'S J4AIL (Ю J ° П
file Edit Message Special Rexx Setup Windows Help '
From: Ami r Shabashvi 1 i 2:5049/12 30 Nov 1399 1 2:32
To: Larissa Smolyakova 2:5049/85
Subj: Nadel is t update
I Attrib: J priv local reed
Attributes
i ^Private
I О Crash
= CjReceived
I LjSent
: О File Attached
: [ tinTransit
; LJCiphan
i CjKill/Serrt
; .ViLncd
:; . j Hold For Pickup..
Ж Read
CjFite Request
Return Receipt Request
_Jls Return Receipt
Y| Audit Re quest
._JFile Update Request
; t Scwfed
’ __lArChh/e/Sent
□ Direct
fjTruncateffle
□ Kill file
□ Immediate
J G&te
T&ce pickup
[J Hub route
__I Monospaced
j OK
Cancel | i Help |
Рис. 12.13. Меню выбора атрибутов письма в режиме ввода сообщения
FTN-редактора Fleet Street
Заполнение поля темы письма (subject)
После определения списка атрибутов письма нужно написать его название, для
чего в заголовке выделено специальное поле. Кроме своей основной информаци-
онной функции, это поле также используется для прикрепления к письму файлов
и формирования файловых запросов, как это описано ниже.
«Прикрепление» файлов к письму. Чтобы прикрепить файл к письму, устано-
вите атрибут File Attached. Как это сделать, описано в предыдущем разделе. Пос-
ле ввода этого атрибута нужно либо ввести имя файла и путь к нему в поле
SUBJECT:, либо выбрать нужный файл с помощью файлового меню, предлагае-
мого (GoldEd) в ответ на ввод имени файла с использованием метасимволов (*)
и/или (?), как это изображено на рис. 12.14. Нажатием клавиши Пробел можно
отметить файлы, которые необходимо «прикрепить» (на рис. 12.14 выбранные
файлы отмечены указателями ►), и, нажав Enter, ввести их в заголовок письма.
В отличие от GoldEd, Fleet Street сразу после установки атрибута File Attached
предлагает выбрать нужные файлы с помощью стандартного для OS/2 файлового
окна (рис. 12.15).
Формирование файлового запроса (File Request). Если необходимо сформи-
ровать файловый запрос на указанный в заголовке письма адрес, это также дела-
ется с помощью установки соответствующего атрибута письма (FileRequest) и по-
мещения имен файлов или строки поиска файла в поле SUBJECT:. Пример такого
письма для редактора GoldEd приведен на рис. 12.16. Когда почтовая программа
liflliilie
- FastEcho Netmail (2:5049/12) —: Msg : 9 of 9 From : Amirko Shaab To : Larissa Smolyakova Uns Loc Att 2:5049/12 2:5049/85 - NETMAIL -
File : E: \ARCHI VE\FIDO\NODELISTXlIllllItl F10: Addressbook — ttFlO: ЯИв1! Nodelist ~
Е: \АЙСН IVE\FI DO\NODELI ST gg=
FILES.BBS 7683 1-03-00 0:00 FILES.FIX 4096 1-03-00 0:00 KILLCOMM.ZIP 5128 29-05-97 22:04 NODEDIFF.Z07 13883 7-01-00 5:03 NODEDIFF.Z14 14008 17-01-00 17:03 NODEDIFF.Z21 40588 21-01-00 6:03 NODEDIFF.Z28 24766 28-01-00 6:03 NODEDIFF.Z35 16163 25-02-00 0:03 BNODEDIFF.Z42 14572 11-02-00 6:03 BNODEDIFF.Z49 14894 21-02-00 13:03 JNODEDIFF.Z56 22394 29-02-00 13:16
PNT5020.ZIP 484959 25-02-08 2:31
Selected Files 3 Bytes 51.860 Total Files 13
pntchk_l.zip 87851 6-04-98 11:18
| 11:27:55
GoldED/2%3 О.1 | Select Filesj
Рис. 12.14. Использование файлового меню редактора GoldEd
для «прикрепления» файлов к нетмейл-письму
2:5049/12 30Nov1999 15.0S:48
2:5049/85
liiM
? NODEDIFF.Z09 * t ' J
nodediff.z13 ; I
H ; nodediff.z15 |
-, !
, N0DEDIFF.Z18 I
k; : nodediff.z20 s i
' I:
-f Fleetstreet 1.24.1 - SYSOP'S_MAIL (N) а >□
File Edit Message Special Rexx Setup Windows Help
>M«440C^-M00WU><4^ Z ' % Z z K
From: Amir Shabashvili
To: Lari s s a Smo 1yakova
__ Subj: ..
Attrib- | pri V t/a io cal re ad Attach files
Open filename
NODEDIFF.Z11
Type of file:
<All Files>
; Drive:
I D: [SYSTEM 0
i Directory:
। Snodelist
i : О 1991
i 0 1992
* 0 1993
; 0 1994
OK I Cancel | Help
"Ins " '............... "“2:5049/12”
Рис. 12.15. Использование файлового меню OS/2 в редакторе Fleet Street
для «прикрепления» файлов к нетмейл-письму
Ь ged2.exe iiiilliill
- FastEcho Netmail (2:5049/12) Msg : 9 of 9 Uns Loc Frq From : Amirko Shaab 2:5049/12 To : Alex Bronin 2:5049/36 File NODELIST.* NODEDIFF. «аНШМИШМЮ NETMAIL - 111И — IttFlO : Node list n
Private <Alt-P> Archive/Sent <Alt-B> Crash <Alt-C> Direct <Alt-D> Received <Alt-R> Zonegate <Alt-G> Sent <Alt-S> Hub/Host-Route <Alt-V> File Attach <Alt-A> Immediate <Alt-I> Transit <Alt-J> Xmail <Alt-X> Orphan <Alt-O> Erase File/Sent <Alt-E> Kill/Sent <Alt-K> Trunc File/Sent . <Alt~T> Local <Alt-W> Locked <Alt-L> Hold <Alt-H> Confirm Rcpt Request <Alt-Y> File Request <Alt-F> FTS1 Reserved <Alt-l> Return Rcpt Request <Alt-M> QBBS Reserved, Net <Alt-2> Return Rcpt <Alt-N> QBBS Reserved, Echo <Alt~3> Audit Request <Alt~Q> Squish Scanned <Alt-4> File Update Request <Alt-U> ^ap all attribs <Alt-Z> Ять его сам Яло Яерное дело Як смаку или Яак требует Я у меня И кстати на экранчике
Рис. 12.16. Формирование файлового запроса в программе GoldEd 3.01
или упаковщик почты встречает подобное нетмейл-сообщение, то на основании
его формируется запрос файла (создается файл *.req), как это описано в главе 5.
Создание и использование шаблонов
Для автоматизации набора письма в FTN-редакторах писем используется широко
известный механизм шаблонов (Templates). Шаблоны представляют собой состав-
ленные вручную (обычно примеры входят в поставку) файлы, содержащие инфор-
мацию, а также макропеременные, на основании которых программа-редактор про-
изводит оформление нового письма, включая автоматический ввод заголовков,
имени и адреса отправителя или адресата, подписей, служебных строк и т.п.
В пакете Fleet Street есть отдельная подсистема создания шаблонов, вызывае-
мая из основного меню программы (Setup Message Templates). При выборе
этого пункта открывается папка (обладающая всеми свойствами файловой папки
операционной системы OS/2). В папке можно создать либо выбрать для просмот-
ра и редактирования нужный шаблон. На рис. 12.17 изображено окно редактиро-
вания шаблона (редактируемый шаблон называется English with Geeks).
Удобное меню (ярлыки-закладки в стиле OS/2) позволяют задать:
□ стиль цитирования и символ для отметки процитированных строк;
□ содержимое приветственного заголовка письма;
□ многострочную подпись;
□ дополнительный заголовок, вставляемый при формировании письма-ответа;
□ дополнительный заголовок, вставляемый при формировании ответа в другой
области, отличной от той, где расположен оригинал письма, на которое фор-
мируется ответ;
Рис. 12.17. Форма редактирования шаблона письма в FTN-редакторе Fleet Street
□ дополнительный заголовок, вставляемый при выполнении операции пере-
сылки (Forwarding);
□ дополнительная подпись, вставляемая при выполнении операции пересылки
(Forwarding);
□ место формируемого письма, куда вставляется пересылаемое письмо (до или
после текста);
□ дополнительный заголовок, используемый при рассылке в несколько почто-
вых областей (Cross-posting);
□ дополнительный заголовок, вставляемый в письмо при его рассылке по мно-
гим адресам (Carbon Сору);
□ содержимое поля ORIGIN письма (либо одно и то же для всей области, либо
случайный выбор из файла).
В тексте шаблонов можно использовать макропеременные для обозначения тех
или иных элементов письма, адресной информации и т.п. Возможные макропере-
менные (Tokens) приведены в табл. 12.2.
Редактор GoldEd также имеет развитую подсистему шаблонов. В качестве шаб-
лонов здесь используются текстовые файлы с расширением *.tpl. В конфигура-
ции GoldEd указано, какой именно файл используется в качестве основного
файла шаблонов. Обычно это golded.tpl, но можно определять несколько таких
файлов, они вставляются в меню шаблонов, вызываемое в режиме просмотра пи-
сем комбинацией Ctrl+T. Если вы хотите настроить систему шаблонов «под себя»,
то нужно исправить текст файла golded.tpl, содержащего директивы, ключевые
слова и макропеременные, управляющие стандартной частью текста создаваемого
письма. Полное описание языка шаблонов есть в документации GoldEd. Здесь же
оно приведено в сокращении, чтобы дать представление о его возможностях и удоб-
ствах, которыми обладает этот язык.
Сам автор GoldEd считает механизм шаблонов одной из наиболее привлекатель-
ных сторон своей программы. Действительно, язык шаблонов GoldEd очень развит,
он существенно более гибок, чем тот, что предоставляет своим пользователям Fleet
Street (но некоторая «сухость» последнего восполняется возможностью непосред-
ственного вызова из редактора программ обработки текста, написанных на соб-
ственном варианте командного языка обработки текстов REXX). Основные макро-
переменные языка шаблонов GoldEd приведены в табл. 12.3, 12.4 и 12.5.
В табл. 12.3 приведены макропеременные, являющиеся по существу ключевы-
ми словами (автор называет их conditional tokens - «условные макропеременные»).
Их действие заключается не в замене на фрагменты текста или какие-либо
Таблица 12.2. Макропеременные, используемые в шаблонах
FTN-редактора сообщений Fleet Street
Обозначение Подстановка
макропеременной
%Т Полное имя пользователя письма, на которое отвечает данное письмо
%z Первое имя пользователя письма, на которое отвечает данное письмо
%R Адрес письма, на которое отвечает данное письмо (в случае ответа на эхо-письмо эта макропеременная игнорируется)
%О Полное имя сисопа, которому адресовано данное письмо (в случае создания нового письма)
%Р Первое имя сисопа, которому адресовано данное письмо (в случае создания нового письма)
%F Полное имя сисопа, создавшего данное письмо
%G Первое имя сисопа, создавшего данное письмо
%J Адрес автора письма
%А Название почтовой области (Areatag). Используется при рассылке в несколько почтовых областей (кросспостинге), при ответе на письмо в другой области и при пересылке письма
%Е Описание почтовой области. Используется при рассылке в несколько почтовых областей (кросспостинге), при ответе на письмо в другой области и при пересылке письма
%и Ваше полное имя (имя и фамилия)
%1 Ваше первое имя
%W Ваш адрес
%с Имена пользователей в списке рассылки (при рассылке письма по многим адресам)
%D Дата письма, на которое вы отвечаете
%М Время написания письма, на которое вы отвечаете
%5 Название (Subject) письма, на которое вы отвечаете
%% Символ «%»
Обозначение Назначение
макропеременной
Таблица 12.3. Условные макропеременные языка шаблонов Gold Ed
changed Строка вставляется только при редактировании чужого сообщения
comment Строка вставляется только при ответе на письмо в режиме Reply-Comments (при ответе на адрес ТО: исходного письма)
echo Строка вставляется только в эхо-письме
forward Строка вставляется только при пересылке (forwarding)
local Строка вставляется только в локальном письме
moved Строка вставляется только при написании ответа в режиме Reply-Moved (ответ в другой почтовой области)
net Строка вставляется только в нетмейл
new Строка вставляется, только если создается новое письмо (не является ответом на другое письмо)
position quotebuf Определяет строку, в которую позиционируется курсор редактора Строка вставляется, только если письмо создается в режиме Quotebuffered (с использованием специального файла для хранения текста оригинального письма)
quoted Строка вставляется только в ответах с цитированием письма-оригинала
reply Строка вставляется только в письмах-ответах без цитирования
Таблица 12.4. Макропеременные вставки (Insert tokens) языка шаблонов Gold Ed
Обозначение макропеременной Дополнительные ключевые слова Назначение и комментарии
attrib <атрибуты> Добавляет специфицированные атрибуты
include <имя файла> Вставляет указанный файл
forcefrom <"from"> Вставляет указанный текст в поле заголовка FROM:, даже если оно непустое (см. @setfrom)
forcesubj <"subject"> Вставляет указанный текст в поле заголовка SUBJECT:, даже если оно непустое (см. @setsubj)
forceto <"to"> Вставляет указанный текст в поле заголовка ТО:, даже если оно непустое (см. @setto)
loadlanguage Загружает языковой конфигурационный файл
message Вставляет текст оригинального письма (в режимах пересылки и изменения)
quote Вставляет текст оригинального письма в виде цитаты
random [random.txt] Вставляет случайный текст из указанного файла
setfrom <"from"> Устанавливает поле FROM: заголовка, если оно пустое
setsubj <"subject"> Устанавливает поле SUBJECT: заголовка, если оно пустое
setto <"to"> Устанавливает поле ТО: заголовка, если оно пустое
xlatexport <charset> Уставливает кодировку при экспорте
элементы из заголовков писем, как обычно действуют макропеременные шабло-
нов, а в совершении действия, которое определяется вслед за ними при выполне-
нии каких-либо условий. Например, слово ©changed означает необходимость
вставить следующую за ним строку только в том случае, если выполняемой опе-
рацией является редактирование уже существующего письма.
Табл. 12.4 описывает макропеременные, с помощью которых в текст и заголо-
вок формируемого письма вставляются какие-либо элементы независимо от его
содержания или каких-либо других условий. Это так называемые Insert tokens.
Табл. 12.5 содержит обычные макропеременные, которые замещаются теми или
иными элементами заголовков цитируемых писем, именем пользователя и т.п.
В тексте таблиц под «оригинальным» письмом имеется в виду письмо, на которое
отвечает данное письмо.
Если необходимо ввести в текст письма символ @, который представляет собой
признак макропеременной, и есть опасность совпадения слова, следующего за @,
с названием одной из макропеременных (например, такое может случиться при
написании почтового Internet-адреса), то этот символ нужно употребить дважды,
например: ashabash@@mail. ru .
Таблица 12.5. Макропеременные замены (Replacement tokens) языка шаблонов GoldEd
Обозначение Элемент замены
макропеременной
caddr Текущий адрес пользователя
cdate Текущая дата
cdesc Описание текущей почтовой области
cecho Название текущей эхо-области
cfname Текущее первое имя пользователя (то есть Andrey, Ivan и т.п.)
ciname Текущее второе имя пользователя (то есть Ivanov, Sidorov и т.п.)
слоте Текущее полное имя пользователя (то есть Andrey Ivanov и т.п.)
ctime Текущее время
daddr Адрес назначения
dfname Первое имя адресата
dlname Второе имя адресата
dname Полное имя адресата
gif Имя файла из кладжа GIF (в таком файле обычно хранится фотография сисопа)
longpid «Длинный» идентификатор программы (то есть «GoldEd», «GoldEd/2» или
«GoldEd/386»)
oaddr Адрес оригинального письма
odate Дата оригинального письма
odesc Описание области, в которой находилось оригинальное письмо (если при ответе
область не была изменена, то подставляется описание текущей)
oecho Название эхи, в которой находилось оригинальное письмо (если при ответе область
не была изменена, то подставляется название текущей)
ofname Первое имя сисопа оригинального письма
ofrom RFC-заголовок FROM письма-оригинала
Таблица 12.5. Макропеременные замены (Replacement tokens)
языка шаблонов GoldEd (окончание)
Обозначение Элемент замены
макропеременной
olname omessageid omsgid Второе имя из письма-оригинала RFC-заголовок Message-ID письма-оригинала Содержимое кладжа MSGID письма-оригинала
oname Полное имя из письма-оригинала
origin os2slash Текущее значение ORIGIN /2, если запущен GoldEd для OS/2. В противном случае - оставить место свободным (или) оставить поле пустым
otime Время из оригинального письма
oto pid RFC-заголовок ТО письма-оригинала Короткий идентификатор программы (то есть «GED», «GED/2» или «GED386»)
rev subject taddr tagline tearline tfname tlname Номер версии письма (в форме <месяц><день>) Заголовок (Subject) письма Адрес назначения из поля ТО: письма-оригинала Текущая строка tagline (дополнительная строка подписи) Текущая строка tearline (дополнительная строка подписи программы-редактора) Первое имя адресата из поля ТО: письма-оригинала Второе имя адресата из поля ТО: письма-оригинала
tname Полное имя адресата из поля ТО: письма-оригинала
ver Простой номер версии письма (в форме X.YY, например 1.19)
version _caddr Полное написание номера версии GoldEd Текущий адрес пользователя (фиксированной длины: 19 символов)
_cname _daddr _dname _oaddr Текущее имя пользователя (фиксированной длины: 34 символа) Адрес назначения (фиксированной длины: 19 символов) Имя адресата (фиксированной длины: 34 символа) Адрес оригинального письма (фиксированной длины: 19 символов)
_oname _taddr _tname Имя оригинального письма (фиксированной длины: 34 символа) Адрес назначения (фиксированной длины: 19 символов) Имя назначения (фиксированной длины: 34 символа)
Ввод текста письма
При наборе текста после того, как введена вся служебная информация и отрабо-
тали все шаблоны, FTN-редактор мало отличается от обычного простого тексто-
вого редактора вроде Notepad. Все особенности, которые стоит отметить, заклю-
чаются в следующем:
□ и GoldEd, и Fleet Street позволяют определять клавиатурные макрокоманды;
□ при написании букв кириллицы прописная «Н» и строчная «р» должны быть
заменены на аналогичные по написанию буквы латиницы;
□ поддерживается стандартная для FidoNet 866 кодовая страница для кодиров-
ки букв кириллицы;
□ блочные операции, позволяющие выделить часть текста и скопировать его
в буфер обмена, как правило, рудиментарны. Исключение составляет Fleet
Street, где блочные операции связаны с системным буфером и реализованы
в стандартном для OS/2 стиле.
Просмотр нодлиста и компилятор нодлиста
Использование нодлиста для автоматизации набора адресной информации при
вводе письма уже обсуждалось выше. Кроме этого, и GoldEd, и Fleet Street имеют
в своем составе программу просмотра нодлиста.
Особенно удобен просмотрщик Fleet Street, рабочее окно которого изображено
на рис. 12.18. Эта утилита, которую автор назвал Nodelist Browser, позволяет
с удобством путешествовать по нодлисту. Можно отсортировать нодлист либо по
именам сисопов, либо по их адресам.
В GoldEd режим просмотра нодлиста включается из режима ввода письма на-
жатием клавиши Enter в поле ввода адреса назначения, если поле пустое. Список
узлов отсортирован по адресам, можно проводить контекстный поиск (рис. 12.19).
Для того чтобы можно было удобно и быстро пользоваться нодлистами, нужно
построить индексные файлы к уже имеющимся нодлистам (которые сами по себе
малопригодны для организации быстрого поиска). Формат таких индексных фай-
лов может быть различным. GoldEd поддерживает свой формат индексных фай-
лов и имеет в составе пакета отдельную утилиту компиляции нодлиста
goldnode.exe (для OS/2 она называется gn2.exe). На рис. 12.20 изображен экран-
ный вывод, полученный в процессе работы этой утилиты.
Fleet Street не имеет в своем составе построителя индексных файлов для нод-
листа; вместо этого нужно использовать один из компиляторов, способных созда-
вать индексы в формате V7 (см. раздел «Форматы индексных файлов V7 и V7+»
в главе 7). Например, это может быть компилятор нодлиста FastList или FastV7,
которые также описаны в главе 7.
Nodelist Browser
19-157 Nodes
' Address Sysop в System name Location Phone# i Mod
19 I Europe 323 '. - '
i 2 2/1 Ward Dossche в Zonegate Eur Northam Be ’ 0032-3-4480880 ; \
i! . 2 2/3 Ward Dossche в Zonegate Eur Oceania Be 0032-3-4480880 ! |
i 2 2/4 Ward Dossche в Zonegate Eur Americalatina Be 0032-3-4480880
‘ 2.2/5 Egons Bush в Zonegate Eur Africa Latvia 00371-7-508020
J 2 2/6 Egons Bush в Zonegate Eur Asia Latvia 00371-7-508020
f 2 2/7 David De Grave в Multinet Gateway Brussels В 0032-2-5205739 , :
/ 2 2/9 Sven Dueker в Virnet Gate D 0049-571-9520097
- 2 2/15 Matthias Wirnmer в Youngsternet Gate D 0049-7132-69076 “
i 22/16 Sven Dueker в ZyxelnetGate D 0049-571-9520097 ;
{ 2.2/20 Colin Turner в Ftsc Chair Bangor Uk ; 0044-1247-475791 ‘
| 2 2/24 Uwe Schikowski в Mediagate D 0049-7141-26304-2
? 2 2/25 Uwe Schikowski в Mediagate Isdn D 0049-7141-26311
L 2.2/27 Mikael Karlsson в Signet Gate Settle Se 0046-533-689386 i
; 2 2/37 Rail Schnele в TreknetTng Gate ; Bondorf 0049-7457-91158 ;
J
Domain fidonet Й Node numbers
Picons hONo Points Q Sysop names
Рис. 12.18. Работа утилиты просмотра нодлиста пакета Fleet Street
Bl FC/2: ged2
Valery Shabaev, The Flying Sorcerer Station Tyumen, ,2:5077/60 Phone 7-3452-390260 9600 Bps, V34,MO,XA,CM,120
Nickolay Sevastyanov Olga Sevastyanova Sergey H.Sevelev Leonid Severov Basil Sevostianov Vasiliy Sevostianov Vladimir .Sevrinovski Vladimir Sevrinovski Mike Sexton Basile ft* Sey Dmitry Seybanov Anatol Sgonnov Johnson Sh Sergey Sh Sergey Sh Osama Shaaban Shabaev? Andrew Shabalin Sany Shabalin Alexander Shabanov Eugeny Shabanov Sergey Shabanov Alex Shabarshoff Amir Shabashvili Amir Shabashvili Amir, Shabashvili Amir Shabashvili Amir Shabashvili Dmitry Shabeko Sergey Shabeko Sergey Shabetia Serj Shabetia 2:5020/711.41 2:5049/19.7 2:5020/605.26 2:5030/345 2:5020/1321.12 2:5020/1784 2:5020/630.23 2:5020/902.13 1:170/206 2:5030/635 2:5020/1822.29 2:5001/9 6:721/138 2:5020/388.7 2:5020/2424.5 2:542/850 2:5077/60 2:5020/344.23 2:5050/89 2:5053/16 2:5058/1 2:5020/350,9 2:5020/599.605 2:5049/0 2:5049/0 2:5049/12 2:5049/12 2:5049/12.12 2:463/138 2:464/608 2:5020/1651,7 2:5020/1194,12 rm ПМЛПС PVM z Acid Burn Bandersnatch’s Forest SNS LSD Station Robot Mad Cat Station Innuendo Й1 Innuendo The Monster Factory Basilica Dmitry At Home KIMNET Station RED PIG BBS No BBS Negativ BBS line 7 The Flying Sorcerer Station г Untitled The MAX-FRAI BBS CMDI Ltd MicroPulse Sequestr Point GPF Generator Tartar Net Tartar Net Double Dozen Double Dozen Amir’s hole No Fun Lighthouse BBS Sheamus Peace&Love
UULUPiUUtz . uXn z Best inat ion Mode I ist * 3^0 * **
Рис. 12.19. Режим просмотра нодлиста в пакете GoldEd 3.01
GoldNODE/2 3.0.1 Nodelist Compiler. Copyright CO 1990-98 Odinn Sorensen
* Forced compile. * The nodelist files are up-to-date. * Compiling nodelists:
* |--nodelist.330 Nodes read: 19120 Total read: 19120
* |--PNT5049.NDL Nodes read: 849 Total read: 19969
* |--NET5049.NDL Nodes read: 76 Total read: 20045
* \--PNT5020.NDL Nodes read: 18279 * Reading unsorted nodelist index. * Total length of all names: 576046. * Sorting by name, writing goldnode.gxn * Sorting by node, writing goldnode.gxa * Writing goldnode.gxl Total read: 38324
* Nodelist compile completed. Compile t C:\FIDO\GED\_ ime: 0 mi n, 4 sec.
Специальные возможности
Каждый из FTN-редакторов имеет дополнительные функции и возможности, ко-
торые отличают его от других. Например, в GoldEd 3.01 присутствует режим,
в котором возможен просмотр сообщений в двоичном формате. Иногда подобная
операция бывает полезна. На рис. 12.21 приведен пример просмотра письма в та-
ком режиме (на экране уместился только код двоичного заголовка). Также GoldEd
отличается тем, что эту программу можно использовать и для чтения почты
в SOUP-формате, применяемом в Internet для хранения электронной почты и news-
конферениций.
Fleet Street имеет в своем составе расширенный вариант поставляемого с OS/2
языка REXX. Расширения, добавляемые в REXX, включают 17 новых перемен-
ных и 6 функций, специфичных для Fleet Street. Вызвать REXX-процедуру мож-
но непосредственно из работающего редактора, передав ей на обработку текст те-
кущего письма, что позволяет как угодно надстраивать программу.
Общеприняты также такие полезные усовершенствования, как декодирование
инкапсулированных в текст письма с помощью UUENCODE файлов, шифрование
Щ FC/2: ged2.exe ]«]□{
- p^-J<--s-o'ng- texts —— §икsp/ffxfs'~
Msg : 1168 of 1170 -1158
From : Konstantin Prosekov 2:5010/74.10 02 Mar 00 02:50:46
To : Boris Ababin 02 Mar 00 03:43:44
Subj : Очень срочно ищутся тексты следующих песен:
Hexdump of JAM message header, subfields and text
Msgbase : D:\FID0\MSGBASE\FEEC3175
[Signature : JAM
[Revision : 1
ReservedWord : 0
SubfieldLen : 227
TimesRead : 0
MSGIDcrc : 7B2ED91Eh
REPLYcrc : 70FD6AFCh
ReplyTo : 9593
Replylst : 0
ReplyNext : 0
DateWritten : 2000-03-02 02:50:46 (38BDD706h)
bateReceived : 1970-01-01 00:00:60 (GOGOGOOOh)
DateProcessed : 2OO0-03-O2 03:43:44 (38BDE370h)
MessageNumber : 9603
Attribute : O100O0O0h (00000001000000000000000000000000b)
Attribute2 : 00000000b (00000000000000000000000000000000b)
Offset : 1756767
TxtLen : 903
PasswordCRC : FFFFFFFFh
iilililie
Index Record:
UserCrc : 9AD78F07h
Headeroffset : O0O56219h (352793)
0 1 | Read Al I - Msg 1168 of 1170 ' (2 lef t) ' [Tb J..--7: ?7..|11:38: 46
и дешифровка писем, кодированных популярной программой PGP - соответству-
ющие расширения есть почти для всех FTN-редакторов. Описание всех таких воз-
можностей выходит за рамки книги, однако знать о них нужно. Поэтому сле-
дует обязательно изучить описание своего FTN-редактора и использовать все
предоставляемые им средства.
Конфигурирование FTN-редакторов
На процессе настройки FTN-редакторов мы здесь подробно останавливаться не
будем, так как для тех, кто конфигурировал, например, FTN-мейлер (глава 7) или
FTN-тоссер (глава 8), ничего сложного в этом процессе нет. Так же, как и для поч-
товой программы или тоссера, здесь вводится адресная информация, определя-
ются пути поиска нодлистовых индексов, описываются нетмейл- и эхо-области.
Удобным способом конфигурации почтовых областей является возможность, под-
держиваемая многими редакторами (например, GoldEd и Fleet Street) и позволяю-
щая считывать информацию из файла конфигурации тоссера. Описывать несколь-
ко десятков (иногда до сотни) конференций и почтовых областей затруднительно
и заменить все эти строки единственной ссылкой вида (к примеру, для GoldEd)
FastEcho С: \FIDO\FASTECHO\
чрезвычайно удобно. Fleet Street - это один из немногих FTN-редакторов, имею-
щий очень удобную утилиту установки и конфигурации. После установки про-
граммы она вызывается из меню Setup. Внешний вид этой утилиты изображен на
рис. 12.22. В приведенном примере как раз определяется местоположение файла
конфигурации тоссера, по которому будет построен список почтовых областей.
Остальные почтовые FTN-редакторы, описанные ниже, конфигурируются одним
и тем же, традиционным для FidoNet способом - нужно внести исправления в по-
ставляемый вместе с программой образец текстового конфигурационного файла.
si! Fleet Street Setup
[BBToss
[Fastecho
3
FMail
[GEcho
[iMail
[LoraBBS
[NewsWave PM
[Shotgun BBS
[Squish, ParToss
’Tp.rMail
Path & name
[C:\FIDO\FASTE\FASTECHO.CFG
Locate
I
Help
User names J
Addresses J
Origin J
Tosser ]
Paths )
Macros 1 I
Macros 2 |
Macros 3 I
Domains j
Modem types I
Options
Startup area )
Рис. 12.22. Утилита конфигурации FTN-редактора Fleet Street
Другие известные FTN-редакторы
Кроме уже упоминавшихся популярных редакторов (Fleet Street и GoldEd), есть
и другие, многие из которых широко известны и распространены.
FM от FrontDoor. В состав почтовой программы FrontDoor входит компакт-
ный редактор сообщений FM. У этой небольшой программы многолетняя исто-
рия, и, хотя она была разработана как вспомогательная утилита в составе пакета
FrontDoor, сейчас FM поддерживает все основные форматы баз данных (MSG/
HUDSON/JAM), использует нодлист, мышь и т.п. Конечно, эта программа не мо-
жет сравниться с полнофункциональными FTN-редакторами вроде GoldEd, но
применять ее можно (некогда FM была первой программой, с помощью которой
автор этой книги набивал свое первое письмо в FidoNet:-)).
FM есть в версиях для DOS и для OS/2, имеет хорошее описание и утилиту
конфигурации fdsetup.exe, общую для всего пакета. Получить FM и его описание
можно в Internet на сайте автора, в составе пакета FrontDoor, по адресу:
http://www.defsol.se
TimEd. Первая beta-версия этого популярного FTN-редактора сообщений появи-
лась в 1992 году. Автором редактора является Джерард ван Эссен (Gerard van Essen).
Сейчас редактор поддерживает *.msg, форматы баз данных SQUISH, HUDSON
и JAM, и существует в версиях для DOS (16 бит), DOS (32 бит) и OS/2. В отли-
чие от всех остальных программ, рассмотренных в этом разделе, TimEd распрост-
раняется автором как shareware, и его незарегистрированная версия через некото-
рое время перестает работать.
Для российских условий это существенный недостаток, и поэтому у нас TimEd
не слишком распространен (хотя и встречается). TimEd является полнофункцио-
нальным FTN-редактором, по набору возможностей приблизительно эквивалент-
ным GoldEd, но с менее удобным интерфейсом (хотя это дело вкуса). Вообще же
GoldEd и TimEd (да и описанный далее MSGEd) внешне схожи как братья-близ-
нецы. Это и понятно: программы разрабатывались практически одновременно,
под операционной системой MS DOS, с оглядкой друг на друга, авторы их часто
были в непосредственном контакте.
Кратко основные возможности TimEd сводятся к следующему:
□ поддержка всех основных форматов баз данных сообщений;
□ поддержка нодлистовых индексов V7 и FrontDoor;
□ автоматическое конфигурирование подсистемы баз сообщений по конфигу-
рации тоссера (поддерживаемые тоссеры - Squish, Fastecho, GEcho, Email,
Watergate и Xmail). Кроме того, поддерживается формат описания областей
areas.bbs, генерируемый почти всеми эхо-процессорами;
□ высококачественный встроенный редактор текста с функциями автоматичес-
кого форматирования и блочными командами;
□ возможность вызова внешнего редактора текстов;
□ групповые операции с использованием отметки в режиме списка писем;
□ система контекстного поиска с логическими функциями (превосходящая по
качеству ту, что входит в состав GoldEd!);
□ автоматизированные запросы файлов (с выделением имен файлов из текста
письма);
□ поддержка писем, прошедших через шлюз с Internet (по FSC-0035, глава 10);
□ переопределение клавиш на клавиатуре и определение клавиатурных макросов;
□ поддержка шифрования/дешифрования с использованием PGP;
□ возможность запуска внешних программ непосредственно из редактора (для
обработки текста, например, для проверки правописания, шифрования и т.п.);
□ полная поддержка расширенных кодовых страниц (то есть, нет проблем с бук-
вами кириллицы) и многое другое.
Загрузить TimEd из Internet можно с адреса:
ftp: //ftp .gigo. со m/pub/art ware /
MadMed. Автором редактора MadMed является Петр Квитек (Peter Kvitek),
один из зачинателей FidoNet в России. Есть версии MadMed для DOS, DOS32,
Win32, OS/2. Этот редактор поддерживает MSG и SQUISH-форматы базы сооб-
щений (в планах автора встроить поддержку JAM) и представляет собой доброт-
ную программу со всеми основными возможностями, присущими развитым FTN-
редакторам, с несколько архаичным многооконным интерфейсом, напоминающим
о некогда популярном пакете Turbo Vision. В состав редактора входит программа
установки. MadMed существует уже много лет (1992 год - время выхода первой
версии, 1999 год - последней) и имеет своих поклонников. Получить эту програм-
му, распространяемую бесплатно, можно в Internet по адресу:
http://www.kvitek.com/fido/
MSGEd и MSGEd ТЕ. Этот FTN-редактор был первоначально разработан Джи-
мом Наттом (Jim Nutt) в 1990 году и выпущен в свет как freeware вместе с исход-
ными текстами.
С тех пор множество участников сети создали свои версии MSGEd, среди них
Джон Деннис (John Dennis), Поль Эдвардс (Paul Edwards), Андре Кларк (Andrew
Clarke) и Тобиас Эрнст (Tobias Ernst). Текущая «стандартная» версия MSGEd
имеет номер 4.30, она доработана и поддерживается Кимом Ликкегардом (Kim
Lykkegaard). Эта версия доступна для DOS (16- и 32-битный вариант) и Windows
(32 бит). Предыдущая версия, 4.10, скомпилирована также для OS/2 и Windows
NT. MSGEd представляет собой программу со стандартным для FTN-редактора
интерфейсом (похож на GoldEd), но выделяющуюся хорошим набором функций
и отсутствием ограничений на размер письма, количество писем в области и т.п.
Эта программа:
□ распространяется как Public Domain, то есть без каких-либо лицензионных
ограничений, с исходными текстами;
□ поддерживает форматы почтовых баз MSG, SQUISH и HUDSON;
□ длина редактируемого и просматриваемого сообщения ограничена только
объемом оперативной памяти (протестировано до 512 Кбайт);
□ 32-битная версия не имеет ограничений на количество сообщений в области,
оно ограничено только объемом свободной оперативной памяти. Протести-
ровано до 107000 сообщений;
□ поддерживает посылку писем через зональные шлюзы, автоматически отра-
батывает хост-роутинг и междоменное шлюзование;
□ полностью переопределяет клавиши на клавиатуре;
□ поддерживает работу в многосетевой среде;
□ использует V7 стандарт на нодлистовые индексы;
□ осуществляет поиск персональной почты в выбранных областях.
В начале 1998 года Тобиас Эрнст на основе кода MSGEd версии 4.10 и в со-
трудничестве с Кимом Ликкегардом, разработчиком «основной» версии редакто-
ра, создал свой вариант, названный MSGEd ТЕ. Этот вариант существует в верси-
ях для Linux, FreeBSD, в нескольких коммерческих версиях UNIX (AIX, Digital
UNIX и др.), Windows NT, DOS, и DOS/DPMI. и обеспечивает дополнительные
возможности, а именно:
□ поддерживает национальные символы некоторых европейских языков в со-
ответствии с FSC 0054 (кладж CHARSET);
□ поддерживает Internet адресацию (UUCP) в теле сообщения (в главе 10 опи-
сана адресация при посылке писем через шлюз в Internet). Поэтому MSGEd
ТЕ удобно использовать при посылке писем в Internet;
□ позволяет вручную редактировать строки ORIGIN и TEARLINE;
□ имеет удобный интерфейс групповых операций для перемещения, копирова-
ния или пересылки сообщений;
□ обладает высоким качеством исходного текста, устойчивостью в работе;
□ имеет высокое качество документации, доступной как в ASCII, так и в PDF,
HTML, OS/2 INF и GNU info-форматах.
Существуют и другие версии MSGEd, среди них наиболее известны MSGEdsq
и MSGEdsqPlus (автор Рон Солдайни - Roan Soldaini). Получить MSGEd можно
в Internet по адресу:
http://home8.inet.tele.dk/lykkegaa/fido/
MSGEd ТЕ также доступен в Internet:
http://www.physcip.uni-stuttgart.de/tobi/msged/index.html
MSGEdsqPlus можно получить по адресу:
http://www.geocities.com/SiliconValley/Lab/2255/msged.html
Также большое количество различных версий MSGEd можно найти:
http://www.juge.com/bbs/msged.html
Заключение
Приведенное в данной главе описание основных ресурсов популярных программ-
редакторов сообщения FidoNet не претендует на полноту и не может служить пол-
ноценным руководством при изучении какого-либо конкретного редактора. Од-
нако, ознакомившись с материалом главы, читателям будет намного легче освоить
любой FTN-редактор, даже не описанный здесь. Очень часто пользователи сети
работают в редакторе сообщений, используя его как обычный текстовый редак-
тор и не имея представления о всем богатстве возможностей, специфичных для
FidoNet. Все рассмотренные в данной главе программы-редакторы поставляются
с полноценной документацией, с помощью которой освоение всех возможностей
не представляет большого труда.
Эпилог
Мир FidoNet велик и убог, странен и обычен, устремлен в будущее и обречен на
вымирание - все одновременно, как в жизни. Эта книга - всего лишь дверь.
Только открыв ее и войдя внутрь, то есть только прочитав книгу и подключив-
шись к сети, используя еженедельно, месяц за месяцем, ее основные сервисы, об-
мениваясь информацией с ее участниками, можно по-настоящему понять FidoNet
и получить истинное, не книжное знание. Сейчас вы прочитали, вероятно, самую
полную книгу о FidoNet. Это не означает, что в ней есть все сведения, полностью
характеризующие сеть.
Во-первых, просто невозможно свести в разумный объем все то, что было на-
коплено тысячами участников сети в течение пятнадцати лет ее существования.
Так, здесь отсутствует глава, описывающая работу с системами BBS, имеющи-
ми самое непосредственное отношение к FidoNet, нет и главы о программировании
для FidoNet. Возможно, когда-нибудь мне удастся восполнить эти пробелы.
Во-вторых, сеть очень быстро изменяется. Перемены, произошедшие в период
с 1997 по 2000 годы, потребовали существенной переработки и дополнения уже
написанного текста. Все, что касается использования Internet для нужд FidoNet
уже в том или ином виде существовало и в 1997 году, но еще не использовалось
в полной мере, как сейчас.
Автор будет чрезвычайно благодарен читателям, которые укажут на возмож-
ные неточности и огрехи в книге. Сведения о всех возможных дополнениях
и исправлениях, а также адреса для связи с автором можно найти на Web-сайте по
адресу: http://www.dmk.ru/FidoNet. Сейчас это ashabash@mail.ru (в Internet)
и 2:5049/12 (в FidoNet). Можно также написать письмо из Internet на Fido-адрес:
Amir.Shabashvili@fl2.n5049.z2.fidonet.net.
Благодарности
В заключение хотелось бы поблагодарить всех, кто так или иначе содействовал
созданию книги, и особенно Дмитрия Завалишина за ценные замечания по ее
содержанию.
Казань, 1997-2000
Приложение “
Справочник стандартов
и предложений FidoNet
Стандарты FidoNet издаются FTSC, комитетом по стандартам FidoNet, деятель-
ность которого подробно описана в главе 2.
Документы, издаваемые FTSC, можно условно разделить на следующие
группы:
□ административные документы, регламентирующие деятельность самого ко-
митета по стандартам и содержащие правила оформления документов;
□ действующие стандарты FidoNet, как обязательные к исполнению в FidoNet,
так и носящие рекомендательный характер;
□ новые проекты стандартов FidoNet, еще не принятые в качестве стандартов;
□ библиотека проектов и стандартов FidoNet, содержащая большое количество
проектов стандартов, когда-либо поданных в FTSC. Некоторые из этих доку-
ментов уже устарели, многие используются и сейчас, несмотря на то, что срок
их рассмотрения давно истек и они так и не были приняты в качестве стан-
дартов сети.
Все стандарты FidoNet можно получить в Internet по адресам:
http://www.ftsc.org
ftp://ftp.ftsc.org
Все стандарты и предложения FTSC сведены в таблицы П1.1-П1.4. Для
облегчения поиска текстов стандартов сохранено исходное написание имен
авторов.
Таблица П1.1. Административные документы FTSC
Код Номер версии Название
FTA-1 ООО 2 Положение о FTSC
FTA-1001 4 Правила работы FTSC
FTA-1002 2 Правила оформления проектов стандартов и порядок их подачи в FTSC
FTA-1003 5 Список членов FTSC
ЯГА-1004 3 Список файлов
ЯГА-1005 2 Коды продуктов
ЯГА-1006 2 Ключевые слова для использования в стандартах
FTA-1007 2 Права интеллектуальной собственности
FTSCPROD 1 Список кодов продуктов
Таблица П1.2. Действующие стандарты FidoNet
Код Номер версии Название Автор
FTS-0001 16 Формат почтового пакета и файла *.msg R.Bush
FTS-0004 1 Базовый формат эхо-почты , В.Hartman
FTS-0005 3 ** Заменено на FTS-5000 В.Baker, R.Moore, D.Nugent
FTS-0006 2 Протоколы YOOHOO and YOOHOO/2U2 V.Perriello
FTS-0007 3 Рисширение протокола SEAIink P.Becker
FTS-0008 3 Расширение протокола запроса фала типа Bark P.Becker
FTS-0009 1 Формат MSGID J.Nutt
FTS-5000 1 Распространяемый нодлист D.Hallford и др.
FTS-5001 1 Флаги нодлиста и пользовательские флаги D.Hallford и др.
Таблица П1.3. Проекты стандартов FidoNet
Код Номер версии Название Автор
FSP-1001 2 Информация о часовом поясе в сообщениях FTN О.Sorensen
FSP-1002 2 Поиск ответного письма по содержимому поля SUBJECT FTN-сообщений О.Sorensen
FSP-1003 1 ** Заменено на FRL-1001 L.Kindness
FSP-1004 1 ** Заменено на FRL-1002 L.Kindness
FSP-1005 6 Нодлистовые флаги для Зоны 2 F.EIIermann
FSP-1006 1 Служебная строка определения e-mail адреса для ответа R.v.d.Winkel
FSP-1007 1 Множественные адреса получателей при посылке через шлюз R.v.d.Winkel
FSP-1008 2 Новые служебные строки для пересылаемых сообщений M.Hohner
FSP-1009 1 Программы FidoNet и 2000 год M.Hohner
Таблица П1.3. Проекты стандартов FidoNet (окончание)
Код Номер версии Название Автор
FSP-1010 1 Спецификации служебной строки Via С.Тигпег, J.Homrighausen
FSP-1011 2 Протокол передачи файлов Binkp D.Maloff, N.Soveiko, M.Masyutin
FSP-1012 3 Включение Internet узлов в нодлист LBehet
FSP-1013 1 Определение набора символов в сообщениях Fidonet P.Karlsson
FSP-1014 1 Система модерирования голосованием при распространении эхо-почты A.Shabashvili, A.Chepckunov
Таблица П1.4. Библиотека проектов и стандартов FidoNet
Код Номер версии Название Автор
FSC-0001 - ** Заменено на FTS-0001 -
FSC-0002 - ** Заменено на FTS-0005 -
FSC-0003 1 Объяснение файлов маршрутизации FidoNet В.Baker
FSC-0004 1 Примитивное объяснение зон и зональных шлюзов R.Bush
FSC-0005 • 1 Схема нетмейл-паролей, используемая Opus 1.01 W.Wagner
FSC-0006 - ** Заменено на FTS-0006 -
FSC-0007 2 Проект стандарта на заголовок письма в стиле RFC-822 R.Heller
FSC-0008 - ** Заменено на FSC-0015 -
FSC-0009 1 Черновой документ стандарта на нодлистовые флаги R.Gwinn, •D.Dodell
FSC-0010 1 RESYNC-расширение протокола SEAIink в программе Dutchie 2.80 H.Wevers
FSC-0011 1 Дополнения и исправления к стандарту FSC-0001 B.Hartman
FSC-0012 - ** Заменено на FTS-0004 -
FSC-0013 - ** Заменено на FTS-0008 -
FSC-0014 1 Проект стандарта на нетекстовый формат заголовка MSG-сообщения W.Wagner
FSC-0015 1 Документация на FOSSIL 5.0 R.Moore
FSC-0016 1 Начало почтовой сессии FidoNet R.Hartman
FSC-0017 1 Правила архивирования и наименования документов R.Bush
FSC-0018 - ** Заменено на FTSCLIST -
FSC-0019 - ** Заменено на FTS-0007 -
FSC-0020 1 Альтернативный проект стандарта на флаги нодлиста M.Presnell
FSC-0021 1 VFOSSIL, дополнение к OS/2 видео-FOSSIL R.Moore
FSC-0022 - ** Заменено на FSC-0090 -
FSC-0023 1 Соглашение об именовании почтовых пакетов R.Meyer
Таблица П1.4. Библиотека проектов и стандартов FidoNet (продолжение)
Код Номер версии Название Автор
FSC-0024 1 Формат нетекстового почтового пакета О.McDonald
FSC-0025 1 Видеоспецификация AVATAR G.Stanislav
FSC-0026 - ** Заменено на FTSCLIST -
FSC-0027 - ** Заменено на FTS-0005 -
FSC-0028 1 Проект стандарта на пересылку файлов H.Lee
FSC-0029 - ** Не используется -
FSC-0030 1 Проект стандарта на идентификацию сообщений J.Cowan
FSC-0031 1 Проект стандарта на идентификатор и взаимные ссылки сообщений M.Ratledge
FSC-0032 1 Проект стандарта на правила цитирования сообщений M.Ratledge
FSC-0033 1 Предложение по идентификации сообщений T. Ko ver
FSC-0034 2 Шлюзы из Fidonet и в FidoNet R.Bush
FSC-0035 1 Прозрачные шлюзы из FidoNet и в FidoNet M.Shiels
FSC-0036 1 Спецификация групповой почты D.Lovell
FSC-0037 1 Видео спецификация AVATAR 04- G.Stanislav
FSC-0038 1 Проект стандарта протокола для междоменного шлюзования J.Nutt
FSC-0039 4 Проект стандарта на расширенный «Тип-2» почтового пакета M.Howard
FSC-0040 1 Предложение дополнения по управлению модемом M.Shiels
FSC-0041 - ** Заменено на FTS-0009 -
FSC-0042 1 Модифицированное соглашение о шлюзовании S.Furber
FSC-0043 2 Некоторые особенности по распознаванию контрольных строк в тексте писем FidoNet R.Bush
FSC-0044 2 Усовершенствованное распознавание дублированной почты J.Decker
FSC-0045 1 Предложение нового заголовка пакета T.Henderson
FSC-0046 5 Предложение идентификатора продукта J.Homrighausen
FSC-0047 1 Контрольная строка ^ASPLIT P.Terry
FSC-0048 2 Предложение по расширению формата пакета «Тип-2» J.Vroonhof
FSC-0049 1 Предложение по передаче доменной информации во время сессии по FTS-0006 B.Hartman
FSC-0050 1 Идентификатор набора символов для почтовых редакторов FidoNet T.Sundblom
FSC-0051 3 Независимый от системы способ передачи T.Gradin
специальных символов
FSC-0052 1 Предолжение по введению служебной строки PATH, сохраняющей информацию о зонах FidoNet G.van der Land
FSC-0053 2 Спецификации служебной строки /'aFLAGS J.Homrighausen
Таблица П1.4. Библиотека проектов и стандартов FidoNet (продолжение)
Код Номер версии Название Автор
FSC-0054 4 Предложение по независимому от системы способу передачи специальных символов D.McNutt
FSC-0055 1 Секретные пароли в дополнениях нодлиста L.Kolin
FSC-0056 1 Определения протокола EMSI/IEMSI J.Homrighausen
FSC-0057 3 Эхо-менеджеры подписки - спецификация для запросов F.Fabris, J.Homrighausen
FSC-0058 2 Новый способ адресации в FidoNet W.Van Sebroeck, J.Spooren
FSC-0059 1 Обмен группами новостей с FidoNet J.Decker
FSC-0060 1 Расчет и использование CRC F.van der Loos
FSC-0061 1 Предложение; руководство для файл-бона E.VanRiper
FSC-0062 3 Предложение по нодлистовому флагу для определения времени работы системы D.Thomas
FSC-0063 1 Предложение нового формата сообщений в стиле FidoNet J.Miller
FSC-0064 7 Междоменный идентификатор сообщений, шлюзование, связывание и адресация J.Penner
FSC-0065 1 Предложение: ASCII пакет «Тип-3» M.Kimes
FSC-0066 2 Предложение: нетекстовый пакет «Тип-3» M.Kimes
FSC-0067 1 Предложение по новым служебным строкам M.Kimes
FSC-0068 1 Предложение по замене для FTS-0004 M.Kimes
FSC-0069 1 Служба распознавания имен (DNS) для FidoNet R.Heller, F.Arnaud
FSC-0070 2 Усовершенствованное шлюзование между FidoNet и UseNet; проверка дублированных писем F.Arnaud
FSC-007] 1 Спецификации распределенного запроса файла (DFREQ) B.Auclair
FSC-0072 1 Протокол передачи файлов HYDRA J.Homrighausen, A.Lentz
FSC-0073 1 Шифрованние при идентификации сообщений для FidoNet J.Mudge
FSC-0074 1 Предложение по спецификации эхопочты J.Souvestre, D.Troendle, B.Davis, G.Peace
FSC-0075 1 Предложение по флагам совместимости с ISDN в нодлисте J.Ceuleers
FSC-0076 1 Предложение по наименованиям нетмейл-областей S.Gove
FSC-0077 1 Предложение формата почтового пакета «Тип-10» J.Steck
FSC-0078 1 Шлюз между FidoNet-совместимыми сетями C.Lacerda
FSC-0079 2 Почта RTF: предложение по форматированию сообщений в пакете «Тип-2» K.Axon
Таблица П1.4. Библиотека проектов и стандартов FidoNet (окончание)
Код Номер версии Название Автор
FSC-0080 2 Описание Fidonet в терминах уровневой модели M.Steldal
FSC-0081 1 Предложение формата почтового пакета «Тип-3» M.Steldal
FSC-0082 1 Предложение нового типа почтового пакета S.SIabihoud
FSC-0083 1 Предложение стандарта для идентификаторов сообщений на FTN-системах J.de Boyne Pollard
FSC-0084 1 EDX1: первый уровень стандарта Электронного Обмена Данными D.Bider
FSC-0085 1 Предложение: нодлистовые флаги «NOZIP» и «ERX» D.Bider
FSC-0086 1 SRIF: Описание нового стандарта на файл для запроса информации M.Mucko
FSC-0087 1 Пересылка файлов в FTN-сетях R.Williamson
FSC-0088 1 Совместимость и расширения в способах определения типа сессии для почтовых сессий EMSI R.Williamson
FSC-0089 1 INTL: адресная служебная строка нетмейл-сообщений R.Williamson
FSC-0090 1 Коды продукта FTSC и форма заявки -
FSC-0091 1 Предложение для нодлистовых флагов ISDN A. Lentz
FSC-0092 1 Новые служебные строки для пересылаемых сообщений M.Hohner
FSC-0093 2 Урезанные строки SEEN-BY F.EIIermann
FRL-1001 1 Предложение по использованию полей нодлистовой строки L.Kindness
FRL-1002 1 Стандартная адресация FidoNet L.Kindness
Приложение II
Полиси FidoNet
При переводе данного документа использовались различные варианты перево-
дов Полиси, в частности проект Полиси версии 4.1 в переводе Василия Долма-
това, по большей части совпадающий с канонической версией 4.07, а также пе-
ревод 1991 года Максима Легостаева.
FidoNet Полиси, версия 4.07
9 июня 1989
Настоящие правила (Полиси) приняты голосованием структуры координаторов
FidoNet и являются текущим документом Полиси FidoNet до его замены. (За исклю-
чением данного абзаца никаких различий между этой версией и 4.06 не существует.)
1. Общая часть
Этот документ устанавливает правила (Полиси) для системных операторов (си-
сопов), являющихся членами организации систем электронной почты FidoNet.
Состав FidoNet определяется нодлистом, обновляемым еженедельно международ-
ным координатором.
Отдельные правила (Полиси) могут устанавливаться на уровне зоны, региона
или сети для детализации местных особенностей и процедур. Как правило, доку-
менты Полиси нижних уровней не должны противоречить данному.
Однако с одобрения международного координатора местные Полиси могут
включать отличия, необходимые в местных условиях. Эти местные Полиси не
могут устанавливать дополнительные ограничения на членов FidoNet, не пре-
дусмотренные данным документом, кроме установления локальных почтовых
периодов.
1.0. Язык
Официальным языком FidoNet является английский. Все документы должны су-
ществовать на английском языке. Перевод на другие языки приветствуется.
1.1. Введение
FidoNet является любительской системой электронной почты. Как следствие все
участники и операторы являются неоплачиваемыми добровольцами. Начавшись
как объединение нескольких человек, обменивающихся сообщениями (1984), сей-
час (1989) сеть включает в себя более 5000 систем на шести континентах.
FidoNet не является общедоступной системой или дополнительным сетевым сер-
висом и становится доступной окружающим тогда, когда независимые составляю-
щие ее узлы предоставляют доступ к сети через свою систему. FidoNet настолько
велика, что очень быстро погибла бы под тяжестью собственного веса, если бы в ней
не присутствовали некоторая структура и средства управления. Многосетевое фун-
кционирование обеспечивает структуру. Управление сетью децентрализовано. Дан-
ный документ описывает процедуры, разработанные для управления сетью.
1.2. Организационная структура
FidoNet-системы сгруппированы по нескольким уровням, и администрирование
децентрализовано так, чтобы соответствовать этому принципу построения. На-
стоящий обзор показывает структуру в общем, обязанности координаторов даны
далее в документе.
1.2.1. Индивидуальные системы и системные операторы (сисопы)
Наименьшим подразделением FidoNet является индивидуальная система, соот-
ветствующая одной строке в нодлисте. Системный оператор (сисоп) формулиру-
ет правила работы системы и доступа пользователей. Сисоп обязан иметь связь
с остальными узлами FidoNet для приема и передачи почты, а местные правила
должны соответствовать правилам других уровней FidoNet.
1.2.1.1. Пользователи
Сисоп несет ответственность за действия любого пользователя, если они оказы-
вают влияние на сеть FidoNet. (Если пользователь некорректен, то некорректен
и сисоп.) Любое сообщение, входящее в FidoNet через данную систему (узел),
если автором его не является сисоп, рассматривается как сообщение от пользова-
теля, и сисоп несет за него ответственность (см. раздел 2.1.3).
1.2.1.2. Пойнты
Пойнт есть FidoNet-совместимая система, не присутствующая в нодлисте, но свя-
занная с FidoNet через узел, называемый боссом. Пойнт рассматривается так же,
как и пользователь BBS, например, босс несет ответственность за почту, исходя-
щую от пойнта (см. раздел 2.1.3). Пойнты адресуются через адрес босса, напри-
мер, пойнт босса 114/15 может быть известен как 114/15.12. Почта, адресуемая
пойнту, направляется его боссу, который передает ее пойнту.
Для работы с пойнтами босс может использовать номер приватной сети, кото-
рый, как правило, не должен быть виден за пределами взаимодействия босс -
пойнт. К сожалению, в случае если пойнт связывается с другой системой напря-
мую (например, выполняя файл-реквест), номер приватной сети будет фигуриро-
вать как адрес вызывающей системы. В этом смысле пойнты отличаются от
пользователей, поскольку они используют FidoNet-совместимые мейлеры, кото-
рые способны связываться не только с босс-узлом, но и с другими системами.
1.2.3. Сети и сетевые координаторы
Сеть - это объединение узлов в локальной географической области, обычно опре-
деляемой областью удобной телефонной связи. Сети координируют свою деятель-
ность с целью снижения расходов.
Сетевой координатор ответствен за поддержание списка узлов сети и за пере-
сылку почты членам сети, поступающей от других FidoNet-узлов. Сетевой коор-
динатор может организовывать прохождение исходящей почты, но правила от
него этого не требуют.
Сетевой координатор назначается региональным координатором.
1.2.3.1. Хабы сети
Сетевые хабы существуют только в некоторых сетях. Они могут быть образова-
ны сетевым координатором для поддержания большой сети. Точные обязанности
и процедуры устанавливаются по договоренности между сетевым координатором
и хабами и не будут здесь обсуждаться, за исключением того, что сетевой коорди-
натор не может передать им права по разрешению конфликтов.
1.2.4. Регионы и региональные координаторы
Регионом является четко определенная географическая область, содержащая
узлы, которые могут быть, а могут и не быть объединены в сети. Типичный регион
содержит множество объединенных в сети узлов и ряд независимых узлов, не яв-
ляющихся частью какой-либо сети.
Региональный координатор поддерживает список независимых узлов в регио-
не и получает нодлисты от сетевых координаторов региона. Нодлисты объединя-
ются и образуют региональный нодлист, который посылается координатору зоны.
Региональный координатор не обязан пересылать транзитные сообщения каким-
либо узлам в регионе.
Региональный координатор назначается координатором зоны.
1.2.5. Зоны и координаторы зон
Зона - большая географическая область, содержащая несколько регионов, покры-
вающая одну или более стран и/или континентов.
Координатор зоны объединяет нодлисты всех регионов зоны и создает главный
нодлист, а также файл изменений, которые затем распространяются по FidoNet
в данной зоне. Координатор зоны не обязан пересылать транзитные сообщения
для каких-либо узлов в зоне.
Координаторы зон избираются региональными координаторами своей зоны.
1.2.6. Совет координаторов зон
В определенных случаях координаторы зон работают как совет при междуна-
родном координаторе. Взаимоотношения их аналогичны отношениям между пре-
зидентом и советниками. Этот совет рассматривает, в частности, межзональные
проблемы. Это включает в себя по крайней мере следующее: разработку процеду-
ры выпуска нодлиста, урегулирование межзональных споров, а также проблемы,
не отнесенные к ведению более низких уровней FidoNet.
1.2.7. Международный координатор
Международный координатор - это «первый среди равных» зональный коорди-
натор, который координирует выпуск основного нодлиста координаторами зон.
Международный координатор действует как председатель совета координато-
ров зон и как наблюдатель на выборах: организует объявление о референдуме,
сбор и подсчет голосов и объявление результатов по тем вопросам, которые влия-
ют на FidoNet в целом.
Международный координатор избирается координаторами зон.
1.2.8. Вертикальная организация. Контроль и равновесие
Уровни сети распределяют администрирование и управление FidoNet на самый
низший уровень, обеспечивая скоординированные действия всей системы. Адми-
нистрирование становится возможным за счет распределения ответственности
сверху вниз, то есть лицо на данном уровне ответственно перед высшим уровнем
за деятельность низшего.
Например, региональный координатор ответствен перед координатором зоны
за все, что происходит в регионе. С точки зрения координатора зоны, региональ-
ный координатор несет полную ответственность за нормальную деятельность ре-
гиона. Аналогично, с точки зрения регионального координатора, сетевой коорди-
натор полностью ответствен за нормальное функционирование сети.
Если участник сети на любом уровне координации выше сисопа не в состоянии
выполнять свои обязанности, его может заменить вышестоящий координатор.
Допустим, если региональный координатор не может правильно выполнять ка-
кие-либо свои обязанности, то в этом случае его может заменить зональный коор-
динатор.
Чтобы обеспечить контроль и равновесие на высшем уровне координации
FidoNet, из правила вертикальной организации сделаны два исключения. Коор-
динаторы зон и международный координатор избираются большинством голо-
сов координаторов более низкого уровня. Решения, принятые международным
координатором, аналогично могут быть отменены советом координаторов зон,
а решения, принятые координатором зоны, - региональными координаторами
(см. детальное описание в разделах 6 и 7). Решения, принятые координаторами
других уровней, не могут быть отменены голосованием на нижних уровнях, но
могут быть обжалованы (порядок обжалования описан в разделе 9.5).
1.3. Определения
1.3.1. FidoNews
FidoNews - еженедельный бюллетень, распространяемый в электронной форме по
сети. Это важное средство коммуникации сисопов FidoNet между собой. FidoNews
создает ощущение общности людей и интересов. Соответственно, помещение
статей в FidoNews сисопами и пользователями приветствуется. Статьи следует
представлять на узел 1:1/1, файл с описанием формата статей доступен на 1:1/1
и на многих других системах.
1.3.2. География
Каждый уровень FidoNet географически содержится в вышестоящем уровне. Кон-
кретное географическое место покрывается одной зоной и одним регионом внут-
ри этой зоны и может покрываться или не покрываться сетью. Недопустимо на-
личие двух зон, двух регионов или двух сетей, которые покрывают одну и ту же
географическую область.
Если узел находится внутри географической области сети, он не может быть
независимым узлом в регионе и должен быть указан в этой сети. Единственное
исключение - это узел, получающий большое количество почты через хост (см.
раздел 4.2). Границы сети определяются границами локальной телефонной сети.
Даже в случае, когда плотность узлов в географической области настолько вели-
ка, что необходимо более одной сети для обслуживания одной локальной теле-
фонной области, то географические границы используются для определения того,
какие узлы к какой сети принадлежат. Членство в сети основывается на геогра-
фических или других чисто технических причинах. Оно не может базироваться
на личных или социальных интересах.
Существуют случаи, когда расположение области локальных телефонных звон-
ков приводит к ситуации, при которой узел, физически находящийся в одном ре-
гионе, должен быть приписан к другому. В этих случаях возможны исключения
по соглашению соответствующих региональных координаторов с участием коор-
динатора зоны. Такие исключения описаны в разделе 5.6.
1.3.3. Зональный почтовый час (ZMH)
ZMH (Zone Mail Hour) - это определенное время, в которое все узлы в зоне долж-
ны быть готовы принять почту. Каждая зона FidoNet определяет ZMH и сообща-
ет время ZMH всем остальным зонам (см. разделы 2.1.8 и 10.2).
ZMH ранее назывался национальным почтовым часом (National Mail Hour) и се-
тевым почтовым часом (Network Mail Hour). Термин ZMH является более точным.
1.3.4. Нодлист
Нодлист - еженедельно обновляемый файл, содержащий адреса всех известных
узлов FidoNet. Этот файл предоставляется координатором зоны участникам сети
не позже ZMH каждой субботы для скачивания или получения посредством фай-
лового запроса, без какой-либо оплаты. Чтобы быть включенной в нодлист, систе-
ма должна удовлетворять только требованиям данного документа.
Частичные нодлисты (например, одной зоны) могут быть сделаны доступными
на различных уровнях FidoNet. Полный нодлист, образованный под наблюдени-
ем международного координатора, рассматривается как официальный нодлист
FidoNet и используется для определения права подачи голоса при голосовании.
Все части, которые составляют полный нодлист, доступны у каждого координато-
ра зоны и каждого регионального координатора.
13.5 . Чрезмерно некорректное поведение
В данном документе встречается термин «чрезмерно некорректное поведение»,
особенно в главе 9, «Разрешение конфликтов». Это понятие трудно определить,
поскольку оно базируется на мнении структуры координаторов. Вообще говоря,
некорректное поведение - это то, что раздражает, беспокоит или приносит вред
кому-либо. Чтобы быть некорректным, необязательно нарушать закон.
Существует разграничение между чрезмерно некорректным поведением и про-
сто некорректным поведением. Например, существует период обучения, который
должен пройти каждый сисоп как в технических аспектах (настройка программ-
ного обеспечения), так и социальных (принципы общения в FidoNet). Редкий си-
соп в процессе обучения не «достает» других. Если такое поведение продолжается
и после того, как на него указано сисопу, оно становится чрезмерно некорректным.
Это не означает, что чрезмерно некорректное поведение определяется повторнос-
тью (например, сознательная подделка почты будет чрезмерно некорректной с пер-
вого раза), но показывает, что существует некоторый предел терпимости.
Дополнительно см. главу 9 и иллюстративные примеры (раздел 10.3).
13.6 . Коммерческое использование
FidoNet - это любительская сеть. Участники сети тратят свое время и деньги, что-
бы обеспечить ее работу на благо всех пользователей. Не годится коммерческому
предприятию пользоваться этой добровольной помощью для удовлетворения сво-
их деловых потребностей. С другой стороны, FidoNet предоставляет компаниям
и пользователям удобные и эффективные средства для обмена информацией к вза-
имной выгоде всех.
Сетевые координаторы иногда вынуждены тратить свои средства на коммер-
ческие операции других участников сети, отсылая их почту как хост; они даже
могут привлекаться к судебной ответственности, если пообещают какие-либо га-
рантии в доставке почты. Именно поэтому правило FidoNet утверждает, что ком-
мерческая почта не пересылается. Термин «коммерческая почта» включает пись-
ма, удовлетворяющие чьи-либо деловые потребности без выгоды для сети в целом
(например, это может быть внутрифирменная и межфирменная почта, запросы на
продукцию - в частности, прайс-листы, - заказы и последующая переписка
и все другие темы, специфические для бизнеса).
2. Процедуры сисопа
2.1. Общая часть
2.1.1. Основы
Как сисоп индивидуального узла вы можете делать все, что хотите, пока соблюда-
ете почтовые часы, не ведете себя чрезмерно некорректно по отношению к другим
узлам в FidoNet и не участвуете в распространении пиратского программного обес-
печения или другой противозаконной деятельности с использованием FidoNet.
2.1.2. Знакомство с Полиси
Чтобы понимать, что означает понятие «чрезвычайная некорректность», на
всех сисопов возлагается обязанность иногда перечитывать Полиси FidoNet.
Новые сисопы должны ознакомиться с Полиси до просьбы о включении в со-
став сети.
2.1.3. Ответственность за весь трафик, входящий в FidoNet
с данного узла
Сисоп, указанный в нодлисте, ответствен за все, что входит в FidoNet с данной
системы. Это включает в себя (но не ограничивается этим) весь трафик от пользо-
вателей, пойнтов, а также любых других сетей, для которых система может вы-
ступать в качестве шлюза. Если сисоп позволяет внешним сообщениям поступать
в Fido Net через свою систему, шлюзовая система должна быть четко обозначена
номером узла FidoNet, как точки прохождения данного сообщения и обеспечи-
вать передачу сообщений в обратном направлении.
В том случае, если результатом такой передачи становится нарушение Полиси,
сисоп обязан исправить ситуацию.
2.1.4. Шифрование и просмотр почты
FidoNet - это любительская система. Наша технология такова, что тайна перепис-
ки не может быть гарантирована. Как сисоп, вы имеете право просматривать со-
общения, проходящие через вашу систему, хотя бы для того, чтобы убедиться, что
система не используется для незаконной или коммерческой деятельности.
Шифрование сообщений делает такой надзор невозможным. Таким образом,
шифрованный и/или коммерческий трафик, посылаемый без разрешения всех
промежуточных узлов, является некорректным поведением (см. пункт 1.3.6 для
определения коммерческой переписки).
2.1.5. Невозможность изменения транзитных сообщений
Вы не можете видоизменять, кроме как в пределах необходимых для пересылки
или других технических целей, никакое сообщение сетевой или эхо-почты, про-
ходящее через вашу систему с одного узла FidoNet на другой. Если содержание
письма задевает вас, должна использоваться процедура, описанная в разделе 2.1.7.
2.1.6. Частная переписка
Слово «частный» должно использоваться очень осторожно, особенно в отноше-
нии пользователей BBS. В некоторых странах существуют законы, регулирующие
обращение с частной перепиской, поэтому необходимо разъяснять, что понятие
«частная» предполагает, что никто, кроме получателя, не сможет прочесть сооб-
щение. Сисопы, не обеспечивающие такие разъяснения, должны обдумать воз-
можность не предлагать пользователям доступа к частной почте.
Если пользователь BBS посылает частное письмо, то он не имеет возможности
управлять числом промежуточных систем, через которые это письмо пройдет.
Сисоп, посылающий письмо другому сисопу, может управлять этим, посылая со-
общение непосредственно системе-получателю и таким образом гарантируя, что
только адресат или кто-то другой, кому предоставлено такое право, сможет про-
читать сообщение. Таким образом, сисоп может ожидать большего, чем обычный
пользователь.
2.1.6.1. Неразглашение транзитной почты
Разглашение или любое другое использование информации, содержащейся
в частной переписке, не адресованной вам или не написанной вами, считается не-
коррректным поведением, если сообщение не распространяется автором или ад-
ресатом как часть официальной жалобы. Это неприменимо к эхо-почте, которая
по определению является широковещательной и где флаг частной переписки час-
то используется для ограничения доступа к областям, предназначенным только
для сисопов.
2.1.6.2. Частная почта, адресованная вам
Публикация частной переписки, адресованной лично вам, является более труд-
ным случаем, чем аналогичный вопрос, связанный с транзитной почтой, рассмот-
ренный в предыдущем разделе. С юридической точки зрения полученное вами
сообщение становится вашей личной собственностью, и вы имеете законное пра-
во делать с ним все, что захотите. Данное законное право не может служить
оправданием вашей некорректности по отношению к другим.
Как правило, важные материалы не следует посылать, используя FidoNet. Это
правило часто нарушается, так как FidoNet является основным средством нашей
коммуникации. Как правило, если автор сообщения специально отмечает в тек-
сте, что сообщение является конфиденциальным, публикация его в общедоступ-
ной конференции может рассматриваться как некорректное поведение.
Имеются исключения. Если некто публично заявляет одно, а в частной пере-
писке - другое, получатель частного послания не должен беспокоиться при его
разглашении только потому, что отправитель просил не распространять содер-
жание сообщения. В данном случае следует руководствоваться здравым смыслом,
как и во всех других аспектах поведения в FidoNet.
2.1.7. Пересылка почты
От вас не требуется пересылать сообщения, если вы не дали на это своего согла-
сия. Если вы не занимаете должность сетевого координатора или хаба, вы также
не обязаны пересылать сообщения для всех, когда делаете это для кого-либо. Пе-
ресылка сообщений через узел, который не обязан этого делать, без его разреше-
ния может считаться некорректным поведением. Это требование включает в себя
и передачу незапрашиваемой эхо-почты.
Если вы не переслали сообщение, предварительно обещав это сделать, оно
должно быть возвращено сисопу узла, с которого вошло в FidoNet, с объяснени-
ем причины. (Нет необходимости возвращать сообщения узлу, который отсут-
ствует в текущем нодлисте.) Намеренная задержка транзитных сообщений
является некорректным поведением, если не соблюдается вышеописанная проце-
дура. Случай, когда пересылка не состоялась по техническим причинам, не рас-
сматривается как некорректный, однако будет считаться таковым, когда ситуа-
ция повторится после указания на нее сисопу.
2.1.8. Исключительность ZMH
ZMH - это сердце FidoNet. В ZMH между системами передается почта. Любая
система, которая желает состоять в FidoNet, должна иметь возможность прини-
мать почту в это время, используя протокол, определенный текущим техничес-
ким стандартом FidoNet (в настоящее время - FTS-0001). Разрешается иметь
более широкие возможности (например, поддерживать дополнительные прото-
колы или почтовые часы), но минимальным требованием является возможность
поддержки FTS-0001 в течение одного часа в сутки.
Это время резервируется исключительно для передачи нетмейла. Многие теле-
фонные системы берут плату за звонок независимо от того, произошло соедине-
ние или было «занято». По этой причине любая деятельность, которой система
занимается в ZMH, кроме передачи сетевой почты, считается некорректным по-
ведением. Во время ZMH запрещается пересылка эхо-почты и доступ пользовате-
лей к BBS.
От системы, являющейся членом локальной сети, может также требоваться со-
блюдение дополнительных почтовых часов, определенных сетевым координа-
тором. Ограничения на функционирование систем в локальные почтовые часы
устанавливаются сетевым координатором.
2.1.9. Приватные узлы
Редким исключением из правила соблюдения ZMH являются приватные (pri-
vate) узлы.
Лица, запрашивающие статус приватного узла должны, если возможно, под-
держиваться как пойнты. Приватный статус оправдан, когда система должна
взаимодействовать со многими другими, например в качестве распространите-
ля эхо-почты. В этих случаях способ и расписание доставки почты определяются
соглашением между таким узлом и другими системами. При смене хаба соглаше-
ние между приватным узлом и предыдущим хабом не обязательно для выполне-
ния новым хабом. Приватный узел должен быть частью какой-либо сети (не мо-
жет быть независимым узлом в регионе).
Строчки PRIVATE влияют на каждого члена сети, поскольку они занимают
место во всех копиях нодлиста. Эти строки, удобные одному из сисопов (за счет
всех остальных сисопов FidoNet), являются роскошью, которая уже недопустима.
Ненужные дополнительные строки (более одной с тем же номером телефона, кро-
ме случаев, предусмотренных FTSC-стандартами) также попадают в эту катего-
рию. Сисопы, запрашивающие приватный узел или дополнительные строки в нод-
листе, должны обосновать, какая от этого будет польза местной сети или FidoNet
в целом. Координаторы сети, региона или зоны в любой момент могут пересмот-
реть это обоснование, и неоправданные строки будут удалены.
2.1.10. Соблюдение почтовых периодов
Несоблюдение предписанных почтовых периодов является основанием для ис-
ключения любого узла из FidoNet без предупреждения (поскольку предупрежде-
ние, как правило, пересылается сетевой почтой).
2.1.11. Использование последней версии нодлиста
Системы, как правило, передают почту автоматически и звонят по телефону позд-
ней ночью. Если система использует неверный или устаревший номер, это может
привести к звонкам бедным гражданам на заре и вызвать возмущение невинных
жертв и власть предержащих. По этой причине пересылающий почту сисоп обя-
зан иметь и использовать наиболее свежую версию нодлиста.
2.1.12. Исключение (экскоммуникация)
Система, исключенная из сети, называется экскоммуницированной (excommuni-
cated), то есть связь с ней запрещена.
Если это произошло без предупреждения, то, скорее всего, ваш координатор не
смог вас известить, поэтому, устранив неполадки, следует с ним связаться.
Система также может быть исключена из нодлиста по какой-либо другой при-
чине (см. главу 9, разделы 4.3 и 5.2).
Некорректным поведением считается оказание содействия исключенной сис-
теме для избежания последствий экскоммуникации. Например, если вы решите
снабжать эхо-почтой вашего друга, попавшего в такую ситуацию, то, вероятнее
всего, вы также будете исключены.
2.1.13. Время ZMH
Точное время ZMH для каждой зоны устанавливается координатором зоны (раз-
дел 10.2).
2.1.14. Отсутствие перехода на летнее время
FidoNet не соблюдает переход на летнее время. На территориях, где такая практи-
ка существует, расписания передачи почты FidoNet должны быть скорректирова-
ны в соответствии со сменой времени. Или же можно продолжать работать, ис-
пользуя стандартное время.
2.2. Как стать узлом сети
Прежде всего вам следует получить текущий нодлист, чтобы можно было посы-
лать почту. Для отправки почты адрес FidoNet не нужен, но он необходим, чтобы
другие системы могли посылать почту вам.
Первый шаг в получении текущего нодлиста - это поиск узла FidoNet. Многие
списки BBS включают как минимум несколько систем FidoNet и обычно отмеча-
ют, является ли данная система узлом FidoNet. Для получения информации луч-
ше использовать местные источники, поскольку многие сети имеют детальную
информацию о границах своего распространения и всех необходимых при вступ-
лении требованиях и процедурах.
Получив нодлист, вы должны выяснить, в какую сеть или регион вы входите
территориально. Регионы имеют номера 1-99; сети нумеруются числами, боль-
шими 99.
Географически сети более ограничены, чем регионы, но они предпочтительнее,
поскольку предоставляют для своих участников более быструю передачу почты
и другие возможности. Если вы не можете обнаружить сеть, к которой территори-
ально принадлежите, выберите необходимый регион.
Обнаружив сеть или регион, пошлите запрос узлу с адресом /0, расположенно-
му в этой сети или регионе, на получение номера узла. Запрос должен быть по-
слан нетмейлом, что свидетельствует о совместимости вашей системы с FidoNet.
Вы должны установить свой адрес таким образом, чтобы не создавать проблем
для координатора, который получит ваше сообщение: дублирование уже суще-
ствующего в системе адреса вызовет очевидные сложности. Если ваше программ-
ное обеспечение поддерживает адрес -1/-1, то это традиционный адрес, приме-
няемый потенциальными сисопами. Если нет, то используется сеть/9999 (то есть
при включении в сеть 123 установите адрес вашей системы 123/9999). Многие
сети имеют специальные инструкции для потенциальных сисопов, и там может
быть указан адрес, который следует использовать.
В посланном вами сообщении должна содержаться как минимум следующая
информация:
□ ваше имя;
□ ваш телефон (голосовой);
□ название вашей системы;
□ город и государство, где расположена ваша система;
□ номер телефона вашей системы (модем);
□ время работы системы, почтовые периоды, время работы BBS;
□ максимальная скорость модема;
□ тип мейлера и модема, который вы используете.
Ваш координатор может связаться с вами для получения дополнительной ин-
формации. Вся представленная информация будет считаться конфиденциальной
и никому не будет передана, кроме нового координатора, в случае администра-
тивных изменений.
Вы должны указать, что знакомы и согласны соблюдать данный документ и все
действующие правила FidoNet.
Пожалуйста, оставьте координатору по крайней мере две недели на обработку
вашего запроса. Если вы послали запрос к региональному координатору, он мо-
жет быть переслан соответствующему сетевому координатору.
2.3. Если вы прекращаете работу
Если ваш узел окажется неработоспособным в течение длительного времени (бо-
лее чем 1-2 дня), немедленно проинформируйте вашего координатора. В задачи
координатора не входит выяснение состояния вашей системы, поэтому, как толь-
ко она перестанет принимать почту, ее удалят из нодлиста.
При неработающей системе не следует надеяться на автоответчик или другой
аппарат для ответа на телефонные звонки, так как вызывающие системы будут по-
вторно пытаться связаться с вами, что приведет к большим материальным затра-
там. Такие действия классифицируются как чрезвычайно некорректное поведение.
Единственное, что должно отвечать на телефонные звонки в периоды, когда соглас-
но нодлисту ваш узел принимает почту, - это FidoNet-совместимая программа.
Если вы оставляете свою систему без присмотра на длительный период време-
ни (отпуск и т.п.), вы должны уведомить вашего координатора. Системы имеют
тенденцию к «крахам», поэтому, вероятно, вы захотите, чтобы координатор знал,
что это временное явление, если это случится в период вашего отсутствия.
2.4. Как образовать сеть
Если на какой-либо территории имеется неколько узлов, но нет сети, то можно
организовать новую сеть. Это благоприятно для всех участников FidoNet: вы при-
обретаете лучшие возможности для получения изменений к нодлисту и FidoNews,
а все остальные могут направлять почту для узлов в сети сетевому координатору.
В качестве первого шага свяжитесь с ближайшими сисопами, решите, из каких
узлов будет состоять сеть, и определите сетевого координатора. Затем прокон-
сультируйтесь с региональным координатором. Вам следует послать на его адрес
следующую информацию:
1. Номер (номера) регионов или номер (номера) сетей, если производится де-
ление существующей сети в связи с образованием вашей сети. Региональ-
ный координатор проинформирует координатора зоны и координаторов всех
сетей, на которые влияет появление новой сети, о знаменательном событии.
2. Предполагаемый сегмент нодлиста для сети. Этот файл должен быть отправ-
лен совместно с запросом на номер сети и выполняться в текущем формате
нодлиста, определенном действующими FTSC. Выберите название, которое
отражает расположение сети, например SoCalNet для узлов в Южной Кали-
форнии или MassNet_West для Западного Массачусетса. Учтите: если сеть
будет названа DogNet, то ее расположение останется неясным.
Выделение номера сети не может производиться автоматически. Даже если за-
прос удовлетворен, сеть может не быть структурирована точно так, как вы проси-
ли. Ваш региональный координатор рассмотрит запрос и сообщит свое решение.
Не направляйте запрос на номер сети координатору зоны. Все запросы на обра-
зование сетей должны адресоваться региональному координатору.
3. Общие обязанности для всех координаторов
3.1. Распространение файлов изменений к нодлисту
и FidoNews
Каждый координатор ответствен за еженедельное получение изменений к нод-
листу и FidoNews и предоставление доступа к ним.
3.2. Обработка изменений в нодлисте
и передача их вышестоящим уровням
Каждый координатор ответствен за получение информации для нодлиста с ниж-
него уровня FidoNet, ее обработку и передачу результатов на вышестоящий уро-
вень. Расписание этих действий определяется вышестоящим уровнем.
3.3. Доступность Полиси
Координатор ответствен за доступность текущей версии данного документа ниж-
нему уровню FidoNet и должен поощрять ознакомление с ним.
Кроме того, координатору следует направлять все полученные локальные По-
лней на вышестоящий уровень, а также изучать их самому.
Хотя это и не обязательно, но обычная вежливость требует, чтобы к формули-
рованию локальной Полиси был привлечен и вышестоящий уровень.
3.4. Минимизация числа занимаемых постов
Координаторам рекомендуется ограничивать число функций, которые они вы-
полняют в FidoNet. Координатор, совмещающий два различных поста, нарушает
нормальный ход жалоб. Например, если сетевой координатор одновременно яв-
ляется и региональным, сисопы этой сети оказываются лишены одного уровня
апелляций.
Координаторам не рекомендуется выполнять функции хабов эхо-почты и рас-
пространителей программного обеспечения. Если же они это делают, они должны
распространять эхо-почту (или другие большие объемы информации) на системе,
не совпадающей с административной. Система координатора должна быть легко
доступна с ближайших нижнего и высшего уровней.
Еще одной причиной, по которой совмещение не приветствуется, является
трудность замены, когда такая станция покидает сеть. Например, если координа-
тор является эхо-хабом и хабом-распространителем программного обеспечения,
эти сервисы трудно будет восстановить, если он уйдет в отставку.
3.5. Принадлежность к управляемой области
Координатор сам должен принадлежать к области, в которой он управляет. То
есть, сетевой координатор должен быть членом данной сети по своему географи-
ческому положению, региональный - либо участником одной из сетей региона,
либо независимым узлом в регионе.
3.6. Поощрение вступления в FidoNet новых сисопов
Приветствуется поддержание координатором общедоступной BBS с целью рас-
пространения Полиси, FidoNews, нодлистов для потенциальных сисопов. Рас-
пространение данной информации среди тех, кто является потенциальными
сисопами FidoNet, существенно для роста FidoNet. Координаторы должны
приветствовать появление новых систем.
3.7. Традиции и прецеденты
Координатор не связан в своих действиях практикой предшественника или дру-
гих координаторов, если она выходила за рамки данного документа.
Кроме того, новый координатор имеет право пересмотреть любое решение
предшественников на предмет соответствия их Полиси и предпринять любые не-
обходимые действия для устранения обнаруженных расхождений.
3.8. Техническое обеспечение
Основной задачей любого координатора является техническое обеспечение функ-
ционирования сети. Принимаемые решения должны опираться в первую очередь
на технические соображения.
4. Деятельность сетевого координатора
4.1. Обязанности
На сетевого координатора возлагаются следующие обязанности:
1. Получение входящей почты для узлов сети и организация ее доставки по-
лучателям.
2. Присвоение номеров узлам в сети.
3. Поддержка нодлиста сети и пересылка его региональному координатору
при наличии изменений.
4. Обеспечение узлов сети файлами изменений нодлиста, новыми выпусками
FidoNews, новыми Полиси (по получении), а также периодическая провер-
ка использования узлами соответствующего нодлиста.
4.2. Маршрутизация входящей почты
Ваша обязанность как сетевого координатора - обеспечивать прием и передачу
входящей почты. Способ выполнения оставляется на ваше усмотрение.
Если узел в сети получает большие объемы почты, вы можете попросить, что-
бы данный сисоп связался с отправителями и предложил им не отправлять почту
через хост сети. Если проблема не устранена, следует обратиться к регионально-
му координатору с запросом о предоставлении данному узлу независимого адре-
са и исключении его из сети.
Иногда узел «бомбардирует» сеть письмами (посылает одно и то же письмо на
многие узлы). Если узел другой сети направляет такой поток писем на ваши узлы
сети через хост, вы можете обратиться с жалобой к сетевому координатору той
сети, к которой он принадлежит (для независимого узла обращайтесь к регио-
нальному координатору). Такая бомбардировка рассматривается как некоррект-
ное поведение.
Еще одним источником перегрузки сети является эхо-почта. Эхо-почта не дол-
жна снижать способность FidoNet к нормальной передаче сообщений. Если узел
в вашей сети посылает через сеть большие объемы эхо-почты, вы можете попро-
сить сисопа либо ограничить ее количество, либо прекратить ее пересылку.
От вас не требуется пересылать шифрованные, коммерческие или незаконные
сообщения. Однако вы должны следовать процедуре пункта 2.1.7, если вы не пе-
ресылаете какое-либо сообщение.
4.3. Присвоение номеров узлам сети
Вы обязаны присваивать номера новым узлам в вашей сети. Вы также можете
изменять номера существующих узлов, хотя прежде чем это делать, необходимо
согласовать это с узлами. Вы можете присваивать любые номера, главное - каж-
дый узел в сети должен иметь уникальный номер.
Вы не должны присваивать номер узла системе до тех пор, пока не получите
официальный запрос от этой системы через почту FidoNet. Это дает возможность
убедиться как минимум в работоспособности системы. Строгое соблюдение этого
правила составляет одно из главных условий, обеспечивающих жизнеспособность
FidoNet.
Также рекомендуется, хотя и не требуется, чтобы вы связались с системой, ко-
торая запрашивает номер узла, перед присвоением ей номера. Вы не можете при-
своить номер узлу, находящемуся в области, покрываемой уже существующей се-
тью. Более того, если у вас есть узлы в области, покрываемой вновь образующейся
сетью, они должны быть переданы в новую сеть.
Следует использовать сетевую почту для информирования нового сисопа
о присвоенном его узлу номере. Это позволяет убедиться, что система способна
принимать сетевую почту.
Если узел вашей сети действует достаточно некорректным образом, координатор
может предпринимать любые необходимые в данных обстоятельствах действия.
4.4. Поддержка нодлиста
Вы должны вносить изменения в названия, номера телефонов и т.п. в ваш сег-
мент нодлиста сразу же после получения информации от соответствующего узла.
Также вам следует иногда посылать сообщения каждому узлу сети, чтобы убе-
диться в его работоспособности. Если узел «исчезает» без предварительного уве-
домления, вы можете либо установить флаг DOWN в нодлисте, либо удалить его
из нодлиста. (Узел может быть отмечен как DOWN максимум в течение двух не-
дель, после чего он подлежит удалению из нодлиста.)
По вашему усмотрению часть работы распределяется по хабам. В этом случае
обязательно получение нодлистов от хаб-координаторов вашей сети. При этом
необходимо поддерживать набор нодлистов для каждого хаба в сети, поскольку
вы не можете рассчитывать на получение изменений каждую неделю от каждого
хаб-координатора. Вы должны создавать нодлист своей сети каждую неделю
и отсылать его региональному координатору в обусловленное время. Предпола-
гается, что вы делаете это в самый последний момент, чтобы в него попало макси-
мальное количество изменений, учитывая риск не передать его вовремя регио-
нальному координатору и потерять таким образом целую неделю.
4.5. Распространение Полиси, нодлистов и FidoNews
Будучи сетевым координатором, вы должны еженедельно получать свежие выпус-
ки FidoNews и новые файлы изменений нодлиста от регионального координато-
ра. Файлы изменений выпускаются каждую субботу, a FidoNews - каждый поне-
дельник. Вы должны предоставлять доступ к этим файлам для всех узлов сети.
Также приветствуется выкладывание их для файловой загрузки (download).
Также вы должны получать наиболее свежие версии Полиси, объединяющих
членов вашей сети, и делать их доступными для узлов вашей сети. Полиси выпус-
каются нерегулярно, поэтому следует информировать узлы сети о появлении до-
кумента и затем убедиться, что они знакомы с изменениями.
Полиси, FidoNews и нодлист - это клей, который держит нас вместе.
Без них мы бы перестали существовать как сообщество
И СТАЛИ БЫ ПРОСТО СЛУЧАЙНЫМ НАБОРОМ BBS.
5. Деятельность регионального координатора
5.1. Обязанности
Региональный координатор обязан:
1. Присваивать номера независимым узлам в регионе.
2. Поощрять присоединение независимых узлов к сетям или образование ими
новых сетей.
3. Устанавливать номера сетей в регионе и определять их границы.
4. Составлять объединенный нодлист всех сетей региона и независимых узлов
и при всяком изменении посылать его копию координатору зоны.
5. Проверять нормальное функционирование сетей в регионе.
6. Обеспечивать с максимальной оперативностью доступ сетевых координато-
ров региона к файлам изменений нодлиста, Полиси и выпускам FidoNews.
5.2. Присвоение номеров узлам в регионе
Вашей обязанностью является присвоение номеров независимым узлам региона.
Вы также можете изменять номера существующих узлов в регионе, хотя следует
согласовать эти действия с соответствующими узлами. Вы можете присваивать
любые номера, однако при этом следует учитывать, что каждый узел должен иметь
уникальный номер в регионе.
Вы не должны присваивать номер узлу, пока не получите официальный запрос
от этой системы посредством почты FidoNet. Это позволяет убедиться, что систе-
ма как минимум работоспособна. Строгое соблюдение этого правила составляет
одно из главных условий, обеспечивающих жизнеспособность FidoNet.
Также рекомендуется, хотя и не требуется, перед присвоением номера связать-
ся с системой, которая запрашивает номер узла.
Следует использовать сетевую почту для информирования нового сисопа о но-
мере, присвоенном его узлу, что свидетельствует о способности системы прини-
мать сетевую почту
Если узел в вашем регионе действует достаточно некорректно, вы можете пред-
принять любые действия, которые необходимы в соответствии с обстоятельства-
ми дела.
Когда запрос на номер узла приходит из-за границ вашего региона, следует от-
править его соответствующему координатору самого нижнего (какой можете оп-
ределить) уровня. Если же запрос на номер узла приходит из области, покрывае-
мой существующей сетью, вы должны, не присваивая номер, отправить запрос
соответствующему сетевому координатору.
При образовании сети в области с независимыми узлами последние необходи-
мо как можно быстрее передать в эту сеть.
5.3. Поощрение образования и роста сетей
Одной из ваших основных обязанностей как регионального координатора является
поддержка роста сетей в регионе. В области, где действуют сети, следует избегать
поддержки независимых узлов. Однако встречаются случаи, когда узел можно не
включать в сеть, например при большом количестве входящей почты (раздел 4.2).
Если несколько независимых узлов находятся в пределах одной области, сле-
дует поощрять, а если необходимо, и потребовать образования сети (раздел 2.4).
Стоит отметить, что это не подразумевает поощрение образования тривиальных
сетей. Очевидно, что один узел не в состоянии образовать сеть. Точное число уз-
лов, необходимых для сети, должно определяться в зависимости от ситуации
и оставляется на ваше усмотрение.
5.4. Присвоение номеров сетей
Вашей обязанностью является назначение номеров сетей новым сетям, образую-
щимся в вашем регионе.Для этого координатором зоны вам выделяется набор
номеров сетей. Также в обязанности регионального координатора входит опреде-
ление границ сетей в регионе.
5.5. Поддержка нодлиста
Как региональный координатор, вы выполняете двойную функцию в поддержке
нодлиста для вашего региона.
Во-первых, вы должны поддерживать список независимых узлов в регионе. Вы
должны пытаться максимально быстро учитывать в этом нодлисте изменения
в названиях станций, телефонах и т.п. Вам также следует при случае посылать со-
общение каждому независимому узлу региона, чтобы убедиться, что он работос-
пособен. Если узел исчезает без предупреждения, вы можете либо пометить его
как неработающий (DOWN), либо исключить из нодлиста. (Узел может быть от-
мечен как неработающий в течение максимум двух недель, после этого он должен
быть исключен из нодлиста.)
Во-вторых, вы должны получать нодлисты от сетевых координаторов вашего ре-
гиона. Необходимо хранить набор нодлистов для каждой сети вашего региона, по-
скольку не следует рассчитывать на получение обновленного варианта от каждого
сетевого координатора каждую неделю. Вы должны создавать общий нодлист реги-
она еженедельно и посылать его координатору зоны в обусловленное время. Пред-
полагается, что это делается так поздно, как это практически возможно, учитывая
риск не связаться вовремя с координатором зоны и, таким образом, потерять неделю.
5.6. Географические исключения
Существуют ситуации, когда география телефонной сети не соответствует располо-
жению регионов FidoNet. В этих случаях допускаются исключения из географичес-
кого принципа по соглашению координатора зоны и региональных координаторов,
которых это затрагивает. Такие исключения неправильны и не должны быть посто-
янными. Как только в соответствующем регионе образуется сеть, обеспечивающая
доступ местными телефонными звонками к такому узлу, он более не может рассмат-
риваться как исключительный. Отступления от общего правила могут быть пере-
смотрены и отменены в любое время любым координатором, которого это касается.
5.7. Наблюдение за функционированием сети
Назначение координаторов сетей в вашем регионе входит в ваши обязанности.
Если сетевой координатор, покидая пост, предлагает замену, вы не обязаны согла-
шаться с указанной кандидатурой, хотя подобный выбор является обычной прак-
тикой. Аналогично вы не обязаны назначать на пост сетевого координатора избран-
ного голосованием членов сети кандидата, хотя обычно делается именно так.
В ваши обязанности как регионального координатора входит контроль и от-
слежевание функционирования сети, однако это не предполагает обязательного
личного участия в ее работе. Такая задача возложена на сетевых координаторов.
Региональный же координатор ответствен за добросовестную работу в регионе
сетевых координаторов.
Если вы обнаружили, что сетевой координатор в вашем регионе не исполняет
верно свои обязанности, отмеченные в разделе 4, вы должны предпринять любые
действия, которые считаете необходимыми для исправления ситуации.
Если сеть разрастается настолько, что уже не может обеспечивать передачу по-
чты в ZMH, региональный координатор может предложить узлам рассмотреть
возможность образования из данной сети двух или более сетей. Новые сети, даже
находясь внутри действия одного телефонного междугороднего кода, должны по-
прежнему использовать географический принцип для определения членства.
В круг обязанностей, возложенных на регионального координатора, входит
поддержка прямого и (в разумных пределах) частого контакта с сетями в регио-
не. Метод достижения этого оставляется на ваше усмотрение.
5.8. Распространение Полиси, нодлиста и FidoNews
Вашей обязанностью как регионального координатора является получение свежих
выпусков FidoNews, Полиси, новых файлов изменений нодлиста и предоставление
к ним доступа сетевым координаторам региона. Нодлист посылается каждую суб-
боту координатором зоны, FidoNews выпускаются еженедельно по понедельникам
узлом 1/1. Узнайте у них, как получать свежие копии еженедельно.
В ваши обязанности входит предоставление сетевым координаторам доступа
к вышеозначенным материалам в удобное время. Способ распространения остав-
ляется на ваше усмотрение. Рекомендуется делать все эти документы общедо-
ступными.
6. Деятельность координатора зоны
6.1. Общие задачи
Основные задачи координатора зоны FidoNet - создание нодлиста зоны, обмен
нодлистами с другими координаторами зон, и обеспечение распространения объ-
единенного нодлиста (или файлов изменений к нему) по регионам зоны. Ко-
ординатор зоны также ответствен за организацию распространения Полиси
и FidoNews среди региональных координаторов зоны.
Координатор зоны ответствен за ведение нодлиста административного региона.
Административный регион имеет тот же номер, что и зона, и состоит из узлов, вы-
полняющих административные функции, не связанные с приемом/передачей почты.
На координатора зоны возлагается обязанность обеспечивать беспроблемное
функционирования зоны, что выполняется назначением и надзором за деятель-
ностью региональных координаторов.
Если координатор зоны определяет, что региональный координатор не испол-
няет своих обязанностей, установленных в разделе 5, должна быть найдена замена.
Координатор зоны определяет географические границы регионов в зоне и уста-
навливает время ZMH.
Координатор зоны ответствен за рассмотрение и одобрение исключений
в расположении узлов, описанных в разделе 5.6.
Координатор зоны ответствен за обеспечение нормального функционирования
почтовых шлюзов (гейтов) между своей зоной и всеми другими зонами для пере-
дачи межзональной почты.
Координаторы зон ответственны за выбор международного координатора из
своей среды.
6.2. Выборы координатора зоны
Координатор зоны избирается абсолютным большинством голосов региональных
координаторов данной зоны.
7. Деятельность международного координатора
7.1. Общие задачи
Международный координатор - «первый среди равных» зональный координатор.
Его основной задачей является координация создания основного нодлиста путем
обеспечения распространения нодлистов зон между зонами. Международный ко-
ординатор образует новые зоны и ведет переговоры о связях с другими сетями.
(«Другая сеть» в данном контексте означает другие сети, с которыми может быть
связана FidoNet, а не «сеть» в смысле уровня организации FidoNet.)
Международный координатор также ответствен за координацию рапростране-
ния сетевых Полиси и FidoNews координаторам зон.
Международный координатор ответствен за координацию деятельности сове-
та координаторов зон. Международный координатор является председателем
совета координаторов зон.
Для случаев, не предусмотренных данным документом, международный коор-
динатор может издавать толкования и дополнения к Полиси. Совет координато-
ров зон вправе отменить эти документы большинством голосов.
7.2. Выборы международного координатора
Международный координатор избирается (или смещается) абсолютным боль-
шинством голосов зональных координаторов.
8. Референдум
Процедуры, описанные в данном разделе, используются для ратификации новых
версий FidoNet Полиси, то есть описывают механизм изменения Полиси. Эта про-
цедура также используется для импичмента координатора зоны.
8.1. Начало референдума
Референдум по изменению Полиси назначается, когда большинство региональ-
ных координаторов информируют международного координатора о желании рас-
смотреть предложенную новую версию Полиси.
8.2. Объявление о референдуме
и обнародование результатов
Предлагаемые изменения в Полиси распространяются посредством той же самой
структуры, которая используется для распространения файлов изменений нод-
листа и FidoNews. Информация, касающаяся референдума, распространяется ко-
ординаторами как часть файла изменений нодлиста. Международный коорди-
натор передает редактору копии материалов для включения в FidoNews, хотя
официальные объявления и даты голосования сообщаются при рассылке нодлиста.
Если изменения принимаются, международный координатор устанавливает
дату введения новой Полиси в действие, помещая объявление в файле измене-
ний нодлиста. Дата введения в действие не может быть позже, чем через один
месяц после окончания голосования.
8.3. Право голоса
Каждый член структуры координаторов FidoNet на уровне сетевого координа-
тора и выше имеет один голос (хаб-координаторы не голосуют). Если во время
процедуры голосования пост координатора меняет хозяина, то голосовать должен
или новый, или прежний координатор, но не оба. Если координатор занимает бо-
лее одного поста, он имеет только один голос.
Ожидается, что сетевые координаторы выясняют мнение членов своей сети
и голосуют в соответствии с этим. Нет необходимости проводить формальное го-
лосование, но координатор должен проинформировать участников сети о постав-
ленных на голосование документах и собрать их мнения. Координатор сети дей-
ствует как представитель рядовых членов FidoNet.
8.4. Механизм голосования
Действующий механизм голосования, включая тайность или открытость, сбор
голосов, их проверку, подсчет результатов, оставляется на усмотрение междуна-
родного координатора. В идеале голосование должно проводиться через некото-
рую систему передачи защищенных сообщений, с использованием самой FidoNet.
Для выделения достаточного времени на обсуждение объявить о голосовании
следует не менее чем за две недели до начала процедуры. Продолжительность го-
лосования должна быть не менее двух недель.
8.5. Голосование Полиси как единого документа
Поскольку все в Полиси переплетено и взаимосвязано, относительно простое из-
менение может потребовать внесения нескольких исправлений в текст документа.
Чтобы упростить процесс, голосование проводится по документу в целом, отдель-
ные изменения не рассматриваются. В простейшем случае это означает голосо-
вание «за» или «против» нового документа. Если предлагается несколько альтер-
натив, они должны быть представлены как целостные документы, из которых
необходимо выбрать один.
8.6. Результаты голосования
Изменение Полиси вступает в силу, если по окончании периода голосования оно
получило большинство поданных голосов. Например, если из 350 имеющих право
голоса проголосовало 100, то для принятия изменений необходим 51 голос «за».
В случае голосования по нескольким вариантам изменений Полиси одобрен-
ный и принятый должен получить более 50% поданных голосов. В этом случае
возможно «воздержаться», что на самом деле является голосованием за оставле-
ние в силе текущего документа, так как просто увеличивает необходимое число
голосов для принятия изменений.
8.7. Отстранение от должности (импичмент)
координатора зоны
8.7.1. Проведение
В исключительных случаях координатор зоны может быть отстранен от должности
по результатам референдума. Импичмент не обязательно назначается в результате
нарушения Полиси. Вотум недоверия объявляется, когда большинство региональ-
ных координаторов зоны требуют его проведения от международного координатора.
8.7.2. Процедура проведения референдума по импичменту
При проведении референдума по импичменту применяются положения разделов
8.2 и 8.3 Полиси, а также используется определение понятия «большинство», при-
веденное в разделе 8.6. Право голоса имеют только координаторы данной зоны
(даже если координатор зоны является также международным координатором).
8.7.3. Механизм голосования
Региональный координатор, выбранный координатором зоны, которому выно-
сится вотум недоверия, устанавливает процедуры голосования, проводит сбор го-
лосов и объявляет результаты. Смещение координатора зоны производится в те-
чение двух недель после окончания голосования, если решение об импичменте
было принято.
8.7.4. Ограничение количества импичментов одним в год
Смещение координатора зоны является в первую очередь механизмом, с помо-
щью которого сеть в целом выражает неудовольствие тем, как истолковывается
Полиси. Время от времени каждый из участников сети бывает недоволен тем, как
толкуется Полиси. Для того, чтобы координаторы зон все же толковали Полиси,
а не занимались бы только тем, что защищали себя, между вотумами должен про-
ходить как минимум один календарный год (независимо от того, как много чело-
век занимает пост координатора зоны в течение этого года.) Если координатор
зоны уходит в отставку во время импичмента, процесс считается недействитель-
ным и не входит в квоту «один в год».
9. Разрешение конфликтов
9.1. Общая часть
«Судебная философия» FidoNet заключена в двух правилах:
1. Не вызывай крайнего раздражения у окружающих.
2. Сам не будь слишком раздражительным.
Другими словами, суровых и простых законов в сети не существует, но от каж-
дого ждут разумно вежливого поведения. В каждом конфликте изучается пози-
ция обеих сторон, и репрессивные меры могут быть приняты против любой сто-
роны либо против обеих («Не судите и да не судимы будете!»).
Координаторы ответственны за определение понятия «чрезмерно некорректный».
Так же как и в случае с порнографией («я не могу дать словесное определение, но
узнаю, когда увижу»), точное и краткое толкование допустимого поведения в FidoNet
невозможно. Указания в Полиси намеренно оставлены расплывчатыми, чтобы пре-
доставить свободу принятия решения структуре координаторов, необходимую для
того, чтобы соответствовать нуждам растущего и изменяющегося сообщества. В лю-
бом конфликте между сисопами первым шагом должна быть попытка прямого
контакта, по крайней мере, посредством сетевой почты, предпочтительнее же го-
лосом. Любая поданная жалоба, поданная без этого минимального контакта, бу-
дет отвергнута.
Обращение с формальной жалобой не должно быть легковесным. Расследова-
ние и ответ на жалобы требует времени, которое координаторы предпочли бы по-
тратить на что-нибудь более конструктивное. Лица, которые постоянно посы-
лают тривиальные жалобы, сами могут оказаться «чрезмерно некорректными».
Жалоба должна сопровождаться доказательствами (в основном копиями сообще-
ний). Неаргументированная жалоба не рассматривается.
Отказ следовать изложенному здесь порядку действий (в частности, обраще-
ние «через голову» соответствующего координатора или к координатору, не нахо-
дящемуся в «цепочке апелляций»), само по себе является некорректным.
9.2. Конфликты между сисопами
В случае возникновения проблем во взаимоотношениях с другим сисопом, сна-
чала конфликт необходимо попытаться разрешить с помощью почты или при
личной беседе.
Если взаимоприемлемое решение найти не удалось, вам следует обратиться
с жалобой к своему сетевому координатору и сетевому координатору другого си-
сопа. Если кто-то из вас (или оба) не принадлежит к локальной сети, обращай-
тесь к соответствующему региональному координатору. Если и после этого вы не
получите удовлетворения, то имеете право на апелляции в соответствии с после-
довательностью, описанной в разделе 9.5.
9.3. Конфликты с сетевым координатором
Если у вас возникли проблемы с вашим сетевым координатором и вы считаете,
что с вами обращаются несправедливо, то вам следует обдумать ситуацию еще раз.
Как и во всех конфликтах, первый шаг - это прямой контакт.
Следующий шаг - связаться с вашим региональным координатором. Если ваша
позиция будет признана верной, возможны несколько вариантов действий, вклю-
чая замену сетевых координаторов и даже роспуск вашей сети. Если вы исключе-
ны из сети сетевым координатором, решение может быть отменено, и вы будете
восстановлены.
Если же и обращение к региональному координатору не дало результата, вы
имеете право на подачу апелляции в соответствии с правилами, описанными
в разделе 9.5.
9.4. Конфликты с другими координаторами
Жалобы на некорректное поведение координаторов рассматриваются на осно-
вании правил, изложенных в разделе 9.2, соответствующим координатором выс-
шего уровня. Например, если региональный координатор, по вашему мнению,
виновен в «некорректном поведении» (не имеется в виду невыполнение им функ-
ций координатора), вы можете подать жалобу координатору зоны.
Жалобы по поводу плохого исполнения функций, возложенных Полиси на ко-
ординаторов, принимаются непосредственно с нижележащего уровня. Например,
жалобы на деятельность регионального координатора будут приниматься только
от сетевых координаторов и независимых узлов данного региона. Они должны
быть адресованы координатору зоны после предписанной попытки устранить про-
блему непосредственно с данным координатором.
9.5. Апелляционный процесс
Решение координатора может быть обжаловано на следующем уровне. Апелля-
ции должны подаваться в течение двух недель после принятия решения. Все апел-
ляции должны идти «по команде»; если какой-либо уровень пропущен, апелля-
ция рассматриваться не будет.
Полное расследование по апелляциям не проводится. Решение принимается на
основе материалов, представленных с нижнего уровня. Например, апелляция на
решение сетевого координатора будет рассматриваться региональным координа-
тором на основании информации, представленной координатором и соответству-
ющим сисопом. От регионального координатора не требуется предпринимать по-
пытки по сбору дополнительной информации.
Иерархия апелляций следующая:
□ решение сетевого координатора может быть обжаловано у соответствующе-
го регионального координатора;
□ решение регионального координатора может быть обжаловано у соответ-
ствующего координатора зоны. На этом этапе координатор зоны выносит ре-
шение и доводит его до сведения региональных координаторов данной зоны.
Это решение может быть пересмотрено большинством голосов региональных
координаторов;
□ решение координатора зоны может быть обжаловано у международного ко-
ординатора, который в свою очередь выносит и доводит заключение до све-
дения совета координаторов зон (ZCC), который вправе пересмотреть его
большинством голосов.
Если ваша проблема связана с координатором зоны, нарушившим в отноше-
нии вас требования Полиси, жалоба должна быть подана международному коор-
динатору, который примет и представит решение на совет координаторов зон для
возможной отмены, как описано выше.
9.6. Ограничения
Жалоба может быть подана не позднее 60 дней с момента обнаружения источника
нарушения либо по его признанию, либо на основании технических доказательств.
Жалоба может быть подана не позднее 120 дней после самого события, если
только задержка не связана с явно незаконным поведением.
9.7. Время рассмотрения жалобы
Координатор обязан вынести окончательное решение и уведомить заинтересо-
ванные стороны в течение 30 дней после получения жалобы или апелляции.
9.8. Возвращение в сеть
После разрешения конфликта все узлы, восстановленные в результате апелляции,
возвращаются в сеть или регион, к которому они относятся географически или
технически.
9.9. Эхо-почта
Эхо-почта - важная и мощная сила FidoNet. С точки зрения рассмотрения кон-
фликтов в рамках Полиси эхо-почта рассматривается как несколько отличающа-
яся сетевая почта, подчиненная требованиям Полиси. По своей природе эхо-поч-
та предъявляет особые технические и социальные требования к сети, которые
превышают требования, установленные данной версией Полиси. Вследствие это-
го существует Полиси эхо-почты, расширяющая (не противореча ей) общую По-
лней, поддерживаемая эхо-координаторами и одобряемая с использованием
процедуры, аналогичной описанной для Полиси. Полиси эхо-почты признается
координаторами FidoNet как база для разрешения конфликтов, связанных с эхо-
почтой. В будущем Полиси эхо-почты может быть объединена с данной.
9.10. Поучительные истории
Большая часть FidoNet Полиси по своей природе носит разъяснительный харак-
тер. Никто не может предвидеть, что ждет нас в быстро меняющемся мире. Полиси
сама представляет собой лишь часть тех требований, которые используются как
правила при разрешении конфликтов. Наряду с ней используются и не менее важ-
ны прецеденты.
В соответствии с требованиями времени некоторые поучительные истории мо-
гут добавляться или убираться из этого документа международным координато-
ром, что, в свою очередь, может быть изменено советом координаторов зон. Если
Полиси изменяется таким образом, что указанный прецедент становится недей-
ствительным, то Полиси замещает вышеупомянутый прецедент. (Тщательно под-
готовленное изменение должно указывать на это через удаление ссылки на преце-
дент как часть самого изменения.)
Хотя пример может быть удален, текст его не может быть изменен никаким
способом. Исторический пример составлен в то же время, что и принятое по нему
решение, и включает его. Изменение текста - это то же самое, что и изменение
истории. Подобный подход совершенно не приемлем для организации, занятой
передачей информации.
10. Приложения
10.1. Общие замечания
Приложения к данному документу не могут быть подвергнуты обычному процессу
ратификации. Раздел 10.2 может быть изменен соответствующим координатором
зоны, раздел 10.3 может быть модифицирован международным координатором
(см. раздел 9.10).
10.2. Время ZMH
ZMH соблюдается ежедневно, включая выходные дни и праздники. Время ZMH
устанавливается по шкале UTC (Universal Coordinated Time), известной также
как GMT (Greenwich Mean Time, или «время по Гринвичу»). В областях, где про-
изводится переход на летнее время, местное время ZMH будет изменяться, так
как FidoNet не соблюдает летнее время. Время ZMH в каждой зоне устанавлива-
ется координатором зоны.
В первой зоне FidoNet время ZMH соблюдается с 9.00 до 10.00 UTC. В других
временных зонах оно назначается следующим образом:
EST (Eastern Standard Time) c 4 до 5 утра
CST (Central Standard Time) с 3 до 4 утра
MST (Mountain Standard Time) с 2 до 3 утра
PST (Pacific Standard Time) с 1 до 2 утра
HST (Hawaii Standard Time) с 23 до полуночи
Во второй зоне FidoNet ZMH соблюдается с 2.30 до 3.30 UTC.
В третьей зоне FidoNet ZMH соблюдается с 18.00 до 19.00 UTC.
В других временных зонах время назначается так:
Временная Зона GMT +12
(Новая Зеландия);
Временная Зона GMT +10
(Восточная Австралия),
(Папуа и Новая Гвинея),
(Микронезия);
Временная Зона GMT +9.5
(Центральная Австралия);
Временная Зона GMT +9
(Япония),
(Корея),
(Восточная Индонезия);
Временная Зона GMT +8
(Гонконг),
(Тайвань),
(Центральная Индонезия),
(Филиппины),
(Восточная Австралия);
Временная Зона GMT +7
(Малайзия),
(Сингапур),
(Таиланд),
(Западная Индонезия)
с 6.00 до 7.00 утра
с 4.00 до 5.00 утра
с 3.30 до 4.30 утра
с 3.00 до 4.00 утра
с 2.00 до 3.00 утра
с 1:00 до 2:00 утра
10.3. Поучительные истории
Поучительные истории, связанные с конфликтами, случившимися в прошлом,
сделаны в виде инструкций с той целью, чтобы показать способы и методы их
разрешения. Любые решения могут быть включены в этот документ большин-
ством голосов либо совета зональных координаторов, либо региональных коор-
динаторов.
Полиси версии 4 значительно изменяет функции зоны и международных коор-
динаторов. В следующих случаях, которые были разрешены с использованием
Полиси версии 3, необходимо вместо обозначения «международный координа-
тор^)» подставить «координатор зоны».
10.3.1. Узел-обманщик
Сисоп местного узла использовал сетевую почту для занятий неэтичной коммер-
ческой деятельностью. Сетевой координатор, будучи чрезвычайно раздосадован
этим, удалил сведения о нем из нодлиста.
Сисоп подал апелляцию региональному координатору для получения статуса
независимого узла. Региональный координатор после консультации с сетевым
координатором решил, что сетевой координатор был прав в своем негодовании.
В статусе независимого узла подателю жалобы было отказано.
Международный координатор^) не вмешивался.
10.3.2. Хакерское использование почтовой программы
Сисоп местного узла научился использовать файл-аттачи для внешних пользо-
вателей таким образом, чтобы посылать самому себе файл user.bbs с нескольких
местных BBS. Сисопы этих BBS почувствовали себя оскорбленными и подали
жалобу сетевому координатору, который согласился с ними и удалил узел-нару-
шитель из нодлиста.
Консультации с региональным координатором не проводились.
Международный координатор^) не вмешивался.
10.3.3. Назойливый доставала
Местный узел был недоволен уровнем сервиса, который обеспечивал сетевой ко-
ординатор. Ответы на жалобы в адрес сетевого координатора не удовлетворили
его, поэтому он обратился с жалобой к международному координатору^).
Тот отклонил жалобу, поскольку консультации с региональным координатором
не проводились.
Местный узел подал жалобу региональному координатору, который расследо-
вал случай и нашел, что некоторые основания для претензий есть. Он посовето-
вал и помог сетевому координатору в конфигурировании его системы, чтобы обес-
печить более высокий уровень сервиса для узлов его сети.
Региональный координатор также нашел, что местный узел был «слишком лег-
ко раздражим», поскольку требовал предоставления услуг, которые обычно сете-
вой координатор не оказывает. Местный узел был проинформирован о действи-
тельных обязанностях сетевого координатора и получил совет умерить свои
притязания.
10.3.4. Занятый трудяга
Местный узел, который управлялся розничным торговцем, занимался производст-
вом «почтовых бомб», то есть массовой рассылкой писем по FidoNet, содержащих
его частную рекламу. Сетевой координатор, будучи раздосадован необходимостью
обслуживать поток коммерческих писем, попросил местный узел покинуть сеть.
Тот обратился с жалобой к региональному координатору и получил статус не-
зависимого узла в регионе.
10.3.5. Метка дьявола
Местный узел, чья BBS использовалась для отправления колдовских ритуалов
Вуду, занятий хакерством, а также для нелегального подключения к телефонным
системам и распространения непристойных материалов, обратился к сетевому
координатору с запросом о выделении номера узла. Тот посчитал эту BBS исклю-
чительно некорректной и отказал.
Консультации с региональным координатором не проводились.
Международный координатор^), обнаружив, что региональный координатор не
в курсе дела, отказал в рассмотрении конфликта. Дальнейшие жалобы не подавались.
10.3.6. «Сисоп-твит»
Посетитель нескольких местных узлов постоянно квалифицировался всеми сисо-
пами как твит. Пользователь установил свою собственную систему, стал сисопом
и подал запрос на узловой номер. Сетевой координатор отказал в выдаче узла.
Жалобы не подавались.
10.3.7. Любитель эхо-почты
Локальный узел был очарован эхо-почтой и подключился к нескольким конфе-
ренциям, маршрутизируя почту через свою сеть. Затем он открыл свою собствен-
ную эхо-конференцию и начал распространять эхо-почту между несколькими
системами, вновь маршрутизируя ее через сеть.
Его сетевой, координатор обнаружил, что производительность сети серьезно
пострадала. Узлу-нарушителю было сообщено о необходимости прекратить свои
действия. Компромисс был достигнут переключением большей части потока эхо-
почты вне сети, при этом объем маршрутизируемой эхо-почты был ограничен
двадцатью письмами за ночь. Жалобы не подавались.
10.3.8. Узел-попрыгунчик
Локальный пользователь из самых лучших побуждений решил установить свой
личный узел. Машина в течение дня использовалась также для других целей, по-
этому сисопу часто приходилось оставлять машину. В его отсутствие товарищ час-
то забывал в конце дня включить BBS, так что узел подолгу не работал. Сетевой
координатор, обнаружив, что узел не принимает почту, пометил его как DOWN.
Сисоп вернулся, запустил BBS и попросил восстановить его.
Наконец, сетевой координатор решил, что сисоп не в силах создать надежную
систему и совсем удалил его из нодлиста. Последующие запросы узлового адреса
от того же сисопа были отвергнуты. Жалобы не подавались.
10.4. Благодарности и пр.
Fido и FidoNet - зарегистрированные торговые марки Fido Software, Inc.
Приложение III
Справочник сокращений
и аббревиатур
Вашему вниманию предлагается краткий справочник широко используемых
в FidoNet сокращений и аббревиатур. Все сокращения, представленные в этом
приложении, английские. Порой также используются их русские эквиваленты,
но они скорее относятся к жаргонным выражениям, поэтому приведены в при-
ложении 4.
Таблица ПЗ. 1. Сокращения и аббревиатуры, используемые в FidoNet
Сокращенное наименование Полное английское наименование Перевод полного наименования Примечания
Ю, 2D, 3D, 4D, 5D 1D (2D, 3D, 4D, 5D) addressing Одно- (двух-, ..., пятимерная) адресация в FidoNet См. главы 1,2
BBS Bulletin Board System Электронная доска объявлений Компьютер, предоставляющий через модем простейший терминальный on-line сервис
СС Carbon Copy Множественная рассылка нетмейла Рассылка одного письма по многим адресам с использованием специальных директив
ECHOPOL Echo Policy Эхо-Полиси Общей для всей FidoNet Эхо-Полиси не существует; есть зональные, региональные и сетевые документы
FPD FidoNet Policy Document Документ Полиси FidoNet Текущая версия 4.07
FREQ File Request Запрос файла Стандартная операция по запросу файлов с другой станции FidoNet
FTN FidoNet Technology Network Сеть, построенная по технологии FidoNet См. главы 1, 2
Таблица ПЗ. 1. Сокращения и аббревиатуры, используемые в FidoNet (продолжение)
Сокращенное наименование Полное английское наименование Перевод полного наименования Примечания
FTSC FidoNet Technical Standards Committee Комитет по стандартам FidoNet Организован в 1987 г. под патронажем IFNA. Ответствен за принятие и публикацию стандартов FidoNet
FTS Standard FidoNet Technical FidoNet Технический стандарт Документ, имеющий статус официального стандарта FidoNet
FTA FidoNet Technical Administrative document Административный документ FTSC Документ, имеющий статус административного правила FTSC
FSP FidoNet Standard Proposal Проект технического стандарта FidoNet Документ, имеющий статус проекта официального стандарта FidoNet
IC International Coordinator Международный координатор FidoNet Верховный координатор, обязанности которого оговорены в Полиси FidoNet
IFNA International FidoNet Association Международная Ассоциация FidoNet Существовала в 1986-1989 гг. Единственная организация, официально представлявшая интересы FidoNet. Распущена после проведенного в 1989 г. референдума
KI 2 KI 2 Network СетьК12 Система школьных эхо-конференций, иногда называемая сетью К12
MVS Moderated by Vote System Система модерирования голосованием Вариант технической и организационной реализации механизма эхо-конференций, когда содержание конференции управляется голосами подписчиков
NC Net Coordinator Сетевой координатор См. главы 1, 2
NC_ELECT NC Election Document Правила проведения выборов сетевых координаторов Принят на уровне зоны 2 и доработан в регионе 50
NEC Net EchoMail Coordinator Сетевой координатор эхо-почты См. главы 1, 2
NFEC Net FileEcho Coordinator Сетевой файл-эхо координатор См. главы 1, 2
NMH Net Mail Hour Сетевой почтовый час Дополнительное время для передачи личной почты в больших сетях
R50C Region 50 Coordinator Координатор 50-го региона FidoNet Вместо цифры 50 может стоять номер любого из существующих регионов выбранной зоны. Сокращение будет обозначать координатора соответствующего региона
RC Regional Coordinator Региональный координатор См. главы 1, 2
Таблица ПЗ. 1 . Сокращения и аббревиатуры, используемые в FidoNet (окончание)
Сокращенное наименование Полное английское наименование Перевод полного наименования Примечания
REC Regional EchoMail Coordinator Региональный координатор эхо-почты См. главы 1, 2
RO Returning Officer Проводящий выборы Временная должность проводящего выборы введена в правилах выборов сетевых координаторов - NC_ELECT
VC Vote Checker Проверяющий голоса Временная должность проверяющего голоса на выборах введена в правилах выборов сетевых координаторов - NC_ELECT
ХСС Crossposting Множественная рассылка писем в конференции Рассылка одного письма в несколько конференций с использованием специальных директив
Z2C Zone 2 Coordinator Координатор второй зоны Вместо цифры 2 может стоять номер любой зоны, от первой до шестой, то есть Z1C, Z2C и т.п. Сокращение будет обозначать координатора соответствующей зоны
ZC Zone Coordinator Координатор зоны См. главы 1, 2
ZCC Zone Coordinators Council Совет Координаторов зон Административный совет координаторов зон. В отсутстсвие IC (Международного координатора FidoNet) представляет собой верховный координирующий орган сети
ZEC Zone Echo-Mail Coordinator Зональный координатор эхо-почты См. главы 1, 2
ZMH Zone Mail Hour Зональный почтовый час Время для передачи личной почты (см. описание в главах 1,2)
Приложение IV
Английский и русский
жаргон, используемый
в переписке FidoNet
В данном приложении представлен жаргонный словарь русского компьютерного
диалекта, используемого в FidoNet. Всего словарь содержит описание более 500 слов
и выражений и составлен на основе словаря Никиты Зыкова, в прошлом пойнта
московской сети. За время, прошедшее после выхода в свет первой версии (бо-
лее 4 лет), в жаргоне и реалиях FidoNet произошли значительные изменения. По
возможности они учтены в публикуемой версии. Обратите внимание на текст, пред-
варяющий основную часть словаря билингв на общепринятом русском языке и на
так называемом хакеризе - компьютерном диалекте. Хакериз-версия компактна.
Почти все жаргонные слова представляют собой фонетические кальки с анг-
лийских оригиналов, даже в том случае, когда однокоренное слово уже существу-
ет в русском языке. Наиболее вероятным способом образования термина являет-
ся транслитерация английского варианта. Во всех случаях, где это имеет смысл,
приводится исходное написание слова-предка.
В значительной степени данный словарь отражает не только жаргон, использу-
емый в русской части FidoNet, но и во всем русском околокомпьютерном и сете-
вом сообществе.
Следует также отметить, что узла с адресом 2:5020/338, о котором упоминает
автор в предисловии к словарю, давно уже не существует в FidoNet.
Часть I. Грамматика и фонетика
Как было отмечено в предисловии, русский компьютерный диалект в силу своего
недавнего зарождения еще недостаточно устоялся, поэтому большинство слов име-
ет множество вариантов написания. Обычно произношение слова соответствует
либо английскому прочтению american-hackerese-аналога, либо русской трансли-
терации. В любом случае произношение стилизовано под разговорный русский.
Довольно часто в письмах, которыми участники сети обмениваются между со-
бой, для передачи сленговых и технических терминов используется латиница,
причем написание заимствованного слова далеко не всегда соответствует исход-
ному В то же время кириллица употребляется для написания английских слов,
еще окончательно не вошедших в диалект.
Вообще, грамматика писем достаточно свободна, что однако не означает по-
ощрения безграмотных сообщений - искажения написания обычно употребля-
ются для придания тексту дополнительной эмоциональной окраски.
Часть II. Особенности синтаксиса
Сетевой компьютерный диалект используется в основном для неформального об-
щения, поэтому и возникла необходимость передачи эмоций и (отчасти) мимики
пишущего, что в обычном тексте сделать достаточно сложно; в результате появи-
лись специфические сочетания символов, так называемые «смайлики» (от англ,
smile - «улыбка»). Наиболее употребительные из них приведены ниже. Для чте-
ния знака лучше всего немного наклонить голову влево - тогда можно увидеть
стилизованный портрет абстрактного компьютерщика в соответствующем состо-
янии духа.
Смайлик обычно располагается сразу после высказывания, к которому он от-
носится, либо в конце фразы. Он также употребляется отдельно, выражая реак-
цию на процитированную фразу. Большинство смайликов может писаться в со-
кращенной форме - без серединной черточки, «носа». В последнее время этот
вариант стал применяться чаще.
Основные смайлики:
-Е
-]
-I
-\
-Р
_ *
-О ИЛИ : - ( )
*)
обычная улыбка. Хорошее настроение или смешная фраза;
грустно;
очень грустно;
сарказм, насмешка;
резкая или злая насмешка, иногда на грани оскорбления;
огрызнуться, показать зубы;
тупая улыбка;
озадаченность или нерешительность;
нерешительность или сильное удивление;
показать язык;
поцелуй;
открыть рот от удивления;
пишущий пьян.
Варианты первого символа («глаз»):
8 -) или 8-0
%-)
I-)
подмигивающая улыбка.
Вариант интерпретации: «Не обижайся, это шутка»;
вытаращить глаза. Чаще употребляется в последнем варианте;
после 16 часов сидения за компьютером;
закрыты глаза (вариант: «китаец»).
Существует множество вариаций смайликов, но они употребляются значи-
тельно реже вышеприведенных и чаще всего являются изобретением того или
иного пользователя.
Кроме смайликов существует еще несколько особых синтаксических согла-
шений. Текст между двумя символами подчеркивания (_) считается подчерк-
нутым^ а между символами «звездочка» (*) - набранным ^курсивом*. Слово,
набранное прописными буквами (если это не заголовок), воспринимается как
КРИК. Квадратными скобками выделяются комментарии, никак не относящие-
ся к основному содержанию сообщения.
Если это необходимо, ударение в слове может выделяться прописнОй буквой.
Набор слов с бЕСпОрЯдоЧнОЙ СМеНоЙ регистра традиционно употребляется
в краткой информации (подписях) программистских «пиратских» групп.
Употребление подобного написания в сообщениях и личных подписях являет-
ся признаком крайнего пижонства на грани ламерства (см. ЛАМЕР в части IV).
Часть III. Наиболее употребительные
аббревиатуры (сокращения)
Некоторые распространенные словосочетания американского компьютерного
диалекта, записываемые в сокращенной форме, вошли в русский сленг как само-
стоятельные слова, иногда частично теряющие первоначальный смысл. Кроме
того, в англоязычных фразах часто употребляются сокращения, которые с тру-
дом понимаются начинающими. Интересно отметить, что из словосочетаний рус-
ского происхождения аббревиатуры почти никогда не формируются.
В письмах используются следующие сокращения:
□ 2 - to (по направлению к; для). Употребляется, равно как и нижеследующие
однобуквенные сокращения, только в англоязычных фразах и словосочета-
ниях. Например: 2You, что означает (в зависимости от контекста) «для тебя»
или «к тебе»;
□ 4 - for (для);
□ | - or (или);
□ ~ или А - not (нет);
□ В - be (быть). Употребляется в основном в сочетании 2В|~2В («быть или не
быть»);
□ U - you (ты). Пишется прописной буквой даже в середине фразы. Употреб-
ляется чаще всего в сочетании 2U, то есть «для тебя»;
□ @#$!@%$!&$ и т.п. - символьный «мусор» может заменять любое грубое или
неприличное выражение или высказывание на любом языке, а также исполь-
зоваться для замены только части букв в слове;
□ BTW - by the way (кстати). В русскоязычной среде используется относи-
тельно редко;
□ FAQ- frequently asked questions (часто задаваемые вопросы). Справочник, со-
ставленный из ответов на наиболее часто задаваемые вопросы по определенной
теме. Иногда употребляется в смысле «банальность». См. ЧАВО в части IV;
□ FYI - for your information (к сведению);
□ IMHO - in my humble opinion (по моему скромному мнению). Одно из наи-
более употребительных сокращений в Fido. Единственная аббревиатура, упо-
требляемая в русской транслитерации (ИМХО). Давно потеряла первона-
чальное значение, чаще всего употребляется в значении «по-моему» или «мне
кажется». В то же время обязательно употребление этого слова при спорных
заявлениях. Признаком крайнего занудства считается выделение IMHO за-
пятыми;
□ IMNSHO - in my not so humble opinion (по моему не столь уж скромному
мнению). Значительно жестче, чем IMHO. Употребляется в сочетании с утверж-
дениями, кажущимися пишущему очевидными;
□ IYO - in your opinion (вы считаете, что...). Употребляется часто в вопроси-
тельных фразах типа «значит, IYO, так и надо делать?»;
□ отон - on the other hand (с другой стороны). Употребляется редко;
□ ROFL или ROTFL - rolling on (the) floor laughing (co смехом катаюсь по
полу). Употребляется достаточно часто;
□ RTFM - read the f!@#$% manual (прочитай же, наконец, это чертово руко-
водство!). Второе по употребительности после IMHO выражение. Означа-
ет: «прежде чем спрашивать, прочитайте руководство по использованию».
Сокращение почти утратило первоначальный оттенок грубости. Употреб-
ляется часто.
Часть IV. Толковый словарь Fido-диалекта
Термины располагаются в алфавитном порядке. ВОТ ТАК (полужирным шриф-
том, прописными буквами) выделены словарные статьи и прямые ссылки на них.
А
АБОРТ (от ABnORmal Termination) - аварийное завершение программы.
АВТОКРИЭЙТ (от autocreate) - автоматическое создание чего-либо (например,
области эхо-почты).
АВТОСЕЙВИНГ (от autosaving) - автоматическое сохранение программой вво-
димых данных (например, текста) через определенные промежутки времени.
АИПИ(от1Р - Internet Protocol) - 1. Способ подключения к FidoNet через Internet.
2. Синоним слова «Internet». 3. Обозначение семейства протоколов TCP/IP
АКА (от also known as) - 1. Один из сетевых адресов человека, у которого их не-
сколько. 2. Псевдоним.
АЛИАС (от alias) - псевдоним или прозвище, употребляемые при переписке или
при пользовании BBS. В FIDO использование А. не является общераспростра-
ненной практикой.
АЛЬФА - первый пробный выпуск программы. Обычно без документации и не
для широкого распространения. См. БЕТА и ГАММА.
АНДЕДОВКА (от undead) - любой безалкогольный напиток. Для трезвенников
(есть в FidoNet и такие) - заменитель пыва. См. ПЕПСИ.
АНТИВИРУС - см. ЛЕЧИЛКА.
АПГРЕЙД (от upgrade) - дистрибутив новой версии программы, требующий для
нормальной установки обязательного присутствия на диске старой версии.
АПДЕЙТ (от update) - 1. Новая версия программы, распространяемая только для
пользователей предыдущих версий. 2. Дополнение к любой информации.
АПЛИНК (от uplink) - вышестоящая нода в иерархической структуре рассылки
почты, основной поставщик информации для данного узла.
АППЕНД (от append) - добавление, обычно о дописывании информации в ко-
нец файла.
АРВИД - популярное устройство, разработанное российскими специалистами.
Позволяет записывать большие объемы компьютерных данных на видеокассеты
с использованием бытового видеомагнитофона.
АРКМЕЙЛ (от arcmail) - архивированная почта.
АРИЯ (от area) - «область» на BBS, в которой собраны файлы или сообщения
по определенной тематике. Физически это, как правило, каталог на диске или раз-
дел в БАЗЕ сообщений.
АСМ - 1. Язык ассемблера (точнее, один из языков - у каждого семейства про-
цессоров свой ассемблер). Команды этого языка прямо соответствуют инструк-
циям процессора, таким образом программист имеет полный контроль над ис-
полнением программы. 2. Летнее сборище демомейкеров в Финляндии.
АТЕЭС (от АТС) - телефонная станция.
АТТАЧ (от attach) - специальное письмо, при отсылке которого мейлер посыла-
ет вместе с ним файл, имя которого содержится в субже (см. СУБЖ).
Б
БАГ или БАГА (от англ, bug - «насекомое») - странность или ошибка в работе
программы. Именно так называли некогда сбои, вызванные попаданием насеко-
мых в реле первых компьютеров.
БАГЛАНД или БУГЛАНД - народное название фирмы Borland.
БАГФИКС (от bugfix) - дополнение к программе, исправляющее ту или иную
ошибку. См. ФИКС.
БАЙ (от bye} - обычная форма прощания.
БАЗА - почтовая база данных.
БАНДЛ (от handle) - пакет с архивированной почтой.
БАТНИК, ВАТНИЧЕК или БАТЧ - файл с расширением *.bat или *.cmd, па-
кетный файл операционной системы.
ББС (читается «бибиэс», от амер. BBS - Bulletin Board System) - система, об-
служивающая абонентов через модем (см. ЮЗЕР) и предоставляющая позвонив-
шему возможность читать получаемые на этой станции эхи, обмениваться инфор-
мацией с другими юзерами и сисопом BBS. См. БОРДА.
БЕЙСИК - известный язык программирования. См. ВАСИК.
БЕЛЫЙ - 1. Устройство (чаще всего компьютер), собранное в Америке, Япо-
нии или Европейском Союзе. Синоним слова «качественный». См. ЖЕЛТЫЙ
и КРАСНЫЙ. 2. Человек, в силу своей квалификации или положения имею-
щий возможность не заниматься «черной» работой типа набивки больших тек-
стов или ввода информации в базы данных.
БЕТА - 1. Пробная версия программы, распространяемая для тестирования и вы-
явления ошибок. 2. Любой продукт, не доведенный до товарного вида.
БЕКБОН (от backbone network, «скелетная сеть») - структура из хабов, через
которую распределяется местная и входящая почта и эхи в крупных местных се-
тях и регионах. См. БЛИН, БОН, ЗВЕЗДА, ТРЕУГОЛЬНИК.
БИЗИ или БИЗЯ (от busy) - телефонный сигнал «занято».
БИНК - распространенный мейлер Binkley Term. Название происходит от име-
ни персонажа популярного мультсериала.
БИНКД- популярный айпи-мейлер binkd.
БИНКОПЛЮС - популярный российский клон бинка.
БИОС (от Basic Input-Output System) - система, обеспечивающая взаимодей-
ствие программ (в частности, ОСов) с аппаратурой стандартными средствами.
БИППЕР (от internal speaker) - внутренний динамик компьютера. На большин-
стве IBM-совместимых машин производит звук, мягко говоря, невысокого ка-
чества. См. ХАСБУЛАТОВ.
БИТМАП (от bitmap) - 1. Рисунок, сохраненный в популярном, но не очень ком-
пактном формате BMP. 2. В программировании - матрица с бинарными элемен-
тами. Другими словами, каждый элемент может иметь только два возможных зна-
чения и, следовательно, представлен одним битом.
БЛИН - 1. Один из дисков винта. 2. Разновидность бекбона. 3. Любой более-ме-
нее плоский девайс. 4. Распространенное ругательство.
БОБИК - интерпретирующий язык REXX фирмы IBM.
БОЛД (от bold) - полужирный шрифт.
БОМБА - 1. Очень большой пакет сообщений или одно большое сообщение.
2. (Аркмейловая Б.) Специальным образом составленный пакет сообщений, ко-
торый при распаковке занимает очень много места на диске и выводит из строя
систему обработки почты, а иногда и весь компьютер. Обычно высылается в от-
вет на попытку «фрекнуть» со станции все файлы или при звонке в неположен-
ное время.
БОМБАРДИРОВКА - 1. Посылка большого количества одинаковых сообщений
по одному или нескольким адресам. 2. Пересылка большого объема информации
через международный или междугородний гейт без согласия его администратора.
БОН - сокращение от бекбона.
БОРДА (от Bulletin Board System) - система, через модем обслуживающая або-
нентов (см. ЮЗЕР) и предоставляющая позвонившему возможность читать по-
лучаемые на этой станции эхи и обмениваться информацией с другими юзерами
и сисопом. См. ББС.
БОРОТЬ - справляться с неисправностью в программе или компьютере.
БОСС (от boss node) - нода, через которую пойнт пересылает сетевую почту
и получает эхи.
БРАКА (от Brake) - популярный мейлер The Brake Mailer Джона Гладких.
БУК (от book) - книга (применительно к техническим изданиям или к книгам
в файлах).
БУМАЖНЫЙ - издаваемый на бумаге (как противопоставление электронным
публикациям).
БЭД (от bad) - 1. Испорченный сектор на винте или на дискете. 2. Почта, отбра-
кованная тоссером (обычно во мн. ч.).
В
ВАРЕЗ (от warez) - синоним софта, но обычно употребляется в отношении взло-
манных или нелегально используемых программ.
ВАРНИНГ (от warning) - предупреждение о возможной ошибке программы
(в процессе компиления) или об исключительной ситуации (в процессе исполне-
ния программы).
ВАСИК (от basic) - 1. Семейство языкоподобных примитивных систем. 2. Лю-
бой язык программирования, кажущийся говорящему слишком простым и недо-
статочно мощным. См. БЕЙСИК.
ВАЯТЬ - создавать что-либо требующее достаточно длительной работы. Напри-
мер, «ваять программу».
ВИДЕОАДАПТЕР (от video adapter) - карта, обеспечивающая работу экрана.
Может быть частью материнской платы (см. МАМА).
ВИДЕОКАРТА (от video card) - см. ВИДЕОАДАПТЕР.
ВИНДЫ (от Windows) - одна из популярных операционных систем фирмы Mic-
rosoft - Windows 3.1, Windows 95/98, реже Windows NT. См. ОКОШКИ.
ВИНТ - жесткий диск компьютера. См. ВИНЧЕСТЕР и ХАРД.
ВИНЧЕСТЕР (от winchester) - жесткий диск компьютера. См. ВИНТ и ХАРД.
ВИРТУАЛЬНЫЙ (от virtual) - 1. Воображаемый или имитируемый. 2. (О функ-
ции.) Изменяющий поведение в зависимости от контекста.
ВИРУС - 1. Саморазмножающаяся программа, записывающая свои копии в тела
других программ и загрузочные сектора дискет и жестких дисков. Иногда в В.
бывают заложены деструктивные функции - вплоть до полного стирания содер-
жимого жесткого диска. 2. Повод отлынивания от работы компьютерщиков, име-
ющих некомпетентного шефа. См. ТРОЯН.
ВИС- полная остановка функционирования компьютера или другого устрой-
ства. См. ЗАВИС.
ВИСНУТЬ - 1. (О компьютере или другом устройстве, например о модеме или
принтере.) Прекращать реагировать на внешние воздействия - нажатие клавиш
или кнопок мыши, - часто (но не всегда) сопровождаемое прекращением испол-
нения программ. 2. Находиться в затруднительном положении. 3. Напиться до
полной потери мобильности.
ВОЛКОВ (от Volcov Commander) - один из популярных клонов программы Nor-
ton Commander, написанный программером из Киева Всеволодом Волковым.
ВЬЮЕР (от viewer) - программа, предназначенная для просмотра (но не для из-
менения) файлов в определенном формате.
Г
ГАДСОН или ХАДСОН - компактная и быстрая, но не очень надежная база со-
общений Hudson.
ГАМА (от game) - компьютерная игра, обычно используется во мн. ч. См. ГЕЙМ.
ГАМЕСЫ (от games) - компьютерные игры, мн. ч.
ГАММА - предшествующая релизу версия программы. См. ПРЕРЕЛИЗ.
ГЕНЕРИТЬ (от generate) - создавать что-либо (обычно программу или стандарт-
ные сообщения) с помощью полуавтоматических средств - имеется в виду, что
совершающий это действие задает только общий вид или тип создаваемого объек-
та, а его заполнение идет в автоматическом режиме. Иногда употребляется как
синоним слова «компилить».
ГЕЙМ (от game) - компьютерная игра. См. ГАМА. Обычно используется во мн. ч.
ГЕЙТ (от gate) - 1. Нода, через которую идет передача информации в другие сети
(например, в Internet) или другие города, шлюз. 2. Сисоп шлюза.
ГЕНЕРАЛ (от general) - общесетевая эха, например SU. GENERAL или KAZAN. GE-
NERAL.
ГЕРКУЛЕС - устаревший, но кое-где еще сохранившийся черно-белый (а чаще
черно-желтый) монитор или соответствующий видеоадаптер фирмы Hercules.
ГИГ - 1 Гбайт или 1024 мега.
ГИДРА (от hydra) - быстрый двунаправленный протокол передачи данных по
модему.
ГИПЕРТЕКСТ (от hypertext) - система, где слово в тексте может быть ссылкой
на другой текст, вызываемый на экран при «выборе» (например, отметке мышью)
данного слова.
ГИФ - 1. Изображение, хранящееся в файле в формате CompuServe GIE 2. Лю-
бая хранящаяся в файле картинка.
ГЛЮК (заимств. у хиппи) - 1. Странность или ошибка в работе программы. 2.
Странность в поведении человека. 3. Галлюцинация (исх. знач.). 4. Одна треть
трабла (см. ТРАБЛ).
ГЛЮКАВЫЙ (о программе) - содержащий много ошибок.
ГОЛДЕД или ДЕД, ГОЛЫЙ ДЕДУШКА, ОБНАЖЕННЫЙ СТАРИК и т.п. -
народное название наиболее популярного в FidoNet редактора сообщений Gold-
Editor.
ГРАБЛИ - программа, фильтрующая нетмейл, проходящий через ноду и выреза-
ющая оттуда нестандартную информацию (например, недопустимые символы
или неприличные выражения) или не пропускающая некоторые сообщения (на-
пример, нестандартного формата или бомбы). См. ТРЕКЕР.
ГРУППА - небольшая команда программеров, создающая собственные програм-
мы, обычно демы, или занимающаяся пиратством. Не является формальной орга-
низацией. Начиная создавать коммерческие продукты, может постепенно пере-
расти в компьютерную фирму.
ГУРУ (устаревающ.) - синоним программиста, но применяется чаще всего к ши-
роко известным личностям, обычно к авторам книг.
ГУСЬ - музыкальная карта Gravis UltraSound.
д
ДАЛЬНОБОЙЩИК - человек, звонящий на станцию по модему из другого го-
рода. См лонглинк.
ДАУН (от down) - прекращение работы станции, иногда временное.
ДАУНЛИНК (от downlink) - нода, стоящая в иерархической системе пересыл-
ки почты ниже аплинка, то есть получатель сервиса FidoNet.
ДВУШКА - компьютер с процессором класса Intel 80286.
ДЕБУГЕР или ДЕБАГЕР (от debugger) - программа, позволяющая просматри-
вать код экзешников в ассемблерном виде (см. АСМ, ЛОМ). Применяется как
для отладки своих программ, так и для хака чужих.
ДЕВАЙС (от device) - любой механизм или его функциональная часть: от мы-
шеловки до компьютера.
ДЕД - редактор писем GoldEd. См. ГОЛДЕД.
ДЕКРИПТ (от decript) - 1. Процесс расшифровки. 2. Расшифрованная инфор-
мация.
ДЕМА (от demo) - 1. Урезанная копия программы, предназначенная для демон-
страции ее возможностей, но не для эксплуатации. 2. Специально написанная не-
большая программа, демонстрирующая способность ее создателей к реализации
(в частности, к созданию алгоритмов расчета в реалтайме) сочетания динамичес-
кой (подвижной) графики с музыкой и более или менее остроумными текстами.
ДЕМОМЕЙКЕР (от demomaker) - программер (или любой околокомпьютерный
пипл), занимающийся написанием дем (2 знач.) или созданием для них музыки
либо графики.
ДЕРЕВО - иерархическая структура данных, в которой каждая запись может
быть владельцем (родительским узлом) нескольких других подобных записей.
ДЕФИНИШН (от definition) - определение, объяснение, установка (логическая).
ДЕФАУЛТ (от default) - действие, выполняемое программой, если альтернатив-
ное не задано специально.
ДЕФОЛТ (от default) - синоним «дефаулт». Наиболее распространено среди
других синонимов - см. ДЕФАУЛТ и УМОЛЧАНИЕ.
ДЖАМБА (от jumbo) - некогда наиболее распространенный тип стримаков, ча-
сто употребляется просто как синоним стриммера.
ДЖЕМ (от jam) - наименование популярного формата базы сообщений.
ДИАЛИТЬ (от dial) - 1. Звонить по модему на станцию. 2. Звонить или гово-
рить по телефону.
ДИЗАСТЕР (от disaster) - бедствие, ТРАБЛ.
ДИРЕКТ (от direct) - пересылка письма адресату непосредственным звонком, а не
по роутингу.
ДОБИТЬ - закончить написание программы и привести ее в более-менее товар-
ный вид.
ДОКА - документация к любой программе, техническая книга.
ДОЛБИТЬ - многократно звонить куда-либо по модему.
ДОС - операционная система MS DOS.
ДОСКА - 1. Операционная система MS DOS. 2. Клавиатура. 3. ББС.
ДРАЙВ - дисковод. Обычно не применяется в отношении сидюшников.
ДУМАТЬ - 1. Проводить время за некогда популярной компьютерной игрой
DOOM. 2. Играть в любую игру, аналогичную DOOM. 3. Размышлять.
ДУПЫ (от dupes) - копии одного и того же письма, посылаемые либо «для надеж-
ности» (крайне редко), либо в результате ошибки в схеме распространения почты.
Е
ЕЛИТА - разновидность ламеров, имеющих преувеличенное представление
о собственной значимости и своем программерском искусстве. Обычно очень
разговорчивы.
ЕЛЛИТЬ (от yell) - вызывать сисопа ББС для чата.
ЕНКОД (от encode) - файл, преобразованный в формат, в котором он может
быть непосредственно включен в сообщение для пересылки. Примеры енкода -
MIME, UUENCODE.
ЕРРОРЛЕВЕЛ (от errorlevel) - число, возвращаемое программой операционной
системе при завершении работы и обычно сообщающее о причине завершения.
Чаще всего используется в батчах.
Ж
ЖЕЛЕЗО - 1. Любая компьютерная аппаратура. 2. «Внутренности» компьютера
(например, «у меня опять проблемы с железом»). См. ХАРДВЕР.
ЖЕЛТЫЙ - 1. Сделанный в одной из стран Юго-Восточной Азии. 2. Некаче-
ственный.
3
ЗААРДЖЕННЫЙ или ЗААРЖЕВАННЫЙ (о файле) - сжатый архиватором
ARJ.
ЗАВЕСИТЬ - совершить действия, в результате которых компьютер виснет.
ЗАВИС ИЛИ вис - полная остановка функционирования компьютера.
ЗАДАЧА - 1. Любая программа в процессе исполнения. 2. Любой процесс в про-
грамме (например, поиск слова в тексте), выполняемый параллельно с другими
процессами. См. ТАСК, ТРЕД.
ЗАЕНКОДИТЬ или ЗАУУЕНКОДИТЬ (от encode) - послать в сообщении по
сети енкод-образ файла.
ЗАЗИПОВАННЫЙ - 1. Файл, сжатый архиватором ZIP. 2. Файл, архивирован-
ный любым архиватором.
ЗАЗИПСОВАННЫЙ (укр.) - файл, не вынимающийся из испорченного архива
в формате ZIP.
ЗАЛИТЬ - закачать (отправить) файл или несколько файлов на ББС.
ЗАЛОЧИТЬ (от lock) - 1. Установить фиксированное значение для какого-нибудь
параметра функционирования программы или устройства. 2. Залочить порт -
установить одну определенную скорость передачи данных от модема к компьюте-
ру, не зависящую от скорости коннекта, что позволяет увеличить фактическую ско-
рость передачи, если связь установлена со сжатием передаваемых данных.
ЗАОФФЛАЙНИТЬ (от offline) - сделать файл недоступным на борде, оставив
его в файл-листе.
ЗАРЕСТРИКЧЕННЫЙ (от restricted) - объект (файл, директорий, эхо-конфе-
ренция и т.п.), доступ к которому запрещен для данного пользователя. Обычно
употребляется в отношении конференций, имеющихся на ноде, доступ к которым
закрыт для пойнтов.
ЗАУУЕНКОДИТЬ (от UUENCODE) - см. заенкодить.
ЗАФИКСИТЬ (от fix) - 1. Исправить ошибку в программе. 2. Изменить пара-
метры системы, заставив ее тем самым лучше работать. См. ФИКСИТЬ, ОТ-
ФИКСИТЬ и ПОФИКСИТЬ.
ЗАЮЗАННЫЙ (от use) - потерявший товарный вид в результате длительного
использования. См. ЮЗАНЫЙ, ПОЮЗАННЫЙ.
ЗВЕЗДА - 1. Предупреждение, посылаемое модератором участнику эхи, допус-
тившему мелкое нарушение ее правил. Получение трех 3. обычно эквивалентно
получению плюса. 2. Структура сети, при которой все узлы передают почту через
один центральный - разновидность бекбона.
ЗУХЕЛЬ или ЗЮХ, ЗЮКСЕЛЬ, ЗИКСЕЛЬ - модем фирмы ZyXEL.
И
ИЗЯ (от ISA) - устаревший, но пока еще встречающийся тип передачи внутрен-
него компьютерного интерфейса (тип шины).
ИНСТАЛЛИТЬ (от install) - 1. Устанавливать программу, то есть переписывать
ее файлы на жесткий диск и настраивать в соответствии с конкретными парамет-
рами машины. Иногда эти действия производятся специальной программой -
инсталлятором. 2. Устраивать кого-либо или что-либо на новом месте.
ИНТЕРАПТ (от interrupt) - прерывание работы программ в системе для обслу-
живания запроса на определенные действия, посланного аппаратурой или одной
из программ.
ИНТЕРНЫЙ (от internal) - внутренний, монтируемый внутри компьютера.
ИНТЕРПРЕТАТОР - программа, последовательно выполняющая действия, за-
кодированные командами языков типа «васик» или «бобик».
ИНТЕРФЕЙС ИЛИ МЕЖДУМОРДИЕ- 1. Внешний вид программы и способ ее
взаимодействия с пользователем. 2. Набор доступных программисту процедур,
обеспечивающих взаимодействие программ с операционной системой или другой
программой. 3. Разъем для подключения внешнего устройства и карта, обслужи-
вающая этот разъем. Может употребляться применительно к любым соединени-
ям вплоть до электрической розетки.
ИНТРА - 1. Небольшая дема, обычно не содержащая сложных видеоэффектов
и предназначенная чаще всего для распространения информации о группе.
2. «Мультфильм», прокручиваемый в начале некоторых игр.
ИНФА (от information) - данные, информация.
ИСКЛЮЖН (от exclusion) - исключение из правил или редко возникающая си-
туация.
К
КАКТУС - 1. Растение, по народному поверью уменьшающее вредное влияние
излучения электронной трубки монитора. 2. Пожелание удачи. Например: «Вся-
ких вам кактусов».
КАРБОН (от carbon сору) - копии письма, рассылаемые по нескольким адресам
по специальному запросу.
КАРТА (от card) - синоним платы, но применительно к СИММам не употреб-
ляется.
КАРЬЕР (от carrier) - 1. Наличие связи между двумя модемами. Например, луч-
шее пожелание сисопу: «Чтоб всегда карьер стоял...». 2. Несущий тон при пере-
даче данных модемом.
КАЧАТЬ - передавать данные по модему.
КВОТА или КВОТИНГ (от quote) - цитата из письма вашего адресата. В FidoNet
К. при ответе на письмо считается обязательным. В то же время нежелательно
цитировать больше, чем это необходимо для осмысленности диалога.
КИЛ - 1 килобайт (равняется 1024 байтам).
КИЛОМЕТР - 1024 м
КЛАВА - клавиатура компьютера. См. ДОСКА.
КЛАДЖ или КЛУДЖ (от kludge) - служебные строки в мессагах.
КЛОН (от clone) - функционально идентичная или близкая разновидность, соз-
данная путем копирования или имитации элементов и принципов работы ори-
гинала.
КЛЮЧ - 1. Пароль, необходимый для доступа к конкретной информации (на-
пример, для распаковки архива). 2. Специальный код, позволяющий запустить
полную версию шарварной программы.
КОВЫРЯТЬ - просматривать и, возможно, изменять непосредственно машин-
ный код программы.
КОД (от code) - исходный текст программы.
КОДЕР (от coder) - программер, занимающийся написанием кода программ
в программерской группе.
КОЛДБУТ (от coldboot) - «холодный» перезапуск машины (имитация выклю-
чения и включения питания), при котором производится полная переинициали-
зация и тестирование компьютера.
КОЛЕСА - 1. Автомобиль. 2. Таблетки транквилизатора.
КОМАНДЛАЙН (от command line - командная строка) - способ запуска про-
грамм путем простого ввода с клавиатуры их имени и (иногда) дополнительных
параметров.
КОММЫ (от СОМ) - коммуникационные (последовательные) порты компьюте-
ра, через которые подключаются модемы и некоторые крысы (см. КРЫСА, 2 знач.).
КОМОД (от comoderator) - комодератор, назначаемый модератором замести-
тель.
КОМП (от comp.) - компьютер. См. ТАЧКА.
КОМПИЛИТЬ или КОМПИЛЯТЬ (от compile) - 1. Переводить с помощью спе-
циальной программы-компилятора исходный текст своей программы в исполни-
мый код (экзешник). 2. Собирать что-либо из кусков.
КОМПЛЕЙН (от complaint) - официальная жалоба координатору. Может посы-
латься только нодом.
КОНВЕРТИТЬ (от convert) - преобразовывать из одного (обычно графическо-
го) формата в другой.
КОННЕКТ (от connect) - 1. Связь по модему на определенной скорости. Ее вели-
чина (выражающаяся в бодах или битах в секунду) отражает только потенциаль-
ную возможность передачи информации с такой скоростью, реальная же из-за по-
мех обычно ниже. См. ЦЕПЕЭС. 2. Просто встреча или телефонный разговор.
КОНТОРА - место работы.
КОНФИГ (от config) - 1. Текстовый файл, определяющий конфигурацию (на-
стройку) программы. 2. Характер человека.
КООРДИНАТОР (от coordinator) - координатор FidoNet. См. НЦ и РЦ.
КОСИСОП (от co-sysop) - заместитель и помощник сисопа.
КОСИСОПКА - 1. Косисоп женского пола (редко). 2. Жена и/или подруга сисопа.
КОСЫЕ ФЛОПЫ (устар.) - дисководы на 3,5 и 5,25 дюймов, установленные на
одном компьютере.
КРАКАТЬ (от crack) - взламывать программы. См. ЛОМАТЬ.
КРАКЕР или КРЕКЕР - 1. Пользователь незаконных копий программ. 2. Хакер,
профессионально занимающийся снятием с программ защиты от копирования
и нелегальным копированием программ с закрытых серверов. Самоназвание
представителей этой категории. См. ПИРАТ.
КРАСНЫЙ - сделанный в России или другой стране СНГ.
КРЕАТИТЬ или КРИЭЙТИТЬ (от create) - 1. Однократно создавать что-либо,
обычно каталог на диске или область эхо-почты. 2. Процесс создания чего-ни-
будь «крупного». См. ВАЯТЬ.
КРИВОЙ - плохо сделанный или работающий не так, как ожидалось (например,
«кривое железо»).
КРИПТОВАТЬ (от cript) - шифровать, кодировать. В обществе русских хаке-
ров занятие практически бессмысленное.
КУРЬЕР (от Courier) - популярный модем фирмы US Robotics (ныне ЗСОМ).
КРОКОЗЯБЫ - нечитаемый набор символов, обычно появляется в результате
выбора ошибочной кодировки букв кириллицы при отображении текста.
КРЫСА - 1. См. ТЕХНОКРЫСА. 2. Манипулятор «мышь».
КРЫША - 1. Контора, необходимая для создания внешнего впечатления занято-
сти важным делом. 2. Институт, позволяющий не идти в армию. 3. Дом, в котором
можно переночевать. 4. Соображалка (типичный пример употребления - «кры-
ша поехала»).
Л
ЛАЗЕР - лазерный принтер.
ЛАЙТ (от light) - неполный или минимальный вариант программы либо базы
данных.
ЛАМЕР или ЛЕЙМЕР (от lamer, презрит.) - 1. Агрессивный и/или абсолютно
неисправимый чайник. 2. Малокомпетентный пижон, нахватавшийся азов в не-
скольких околокомпьютерных областях, гордящийся этим и презирающий всех
окружающих. Легко узнается по частому употреблению данного термина в отно-
шении третьих лиц.
ЛАУНЧЕР или ЛАНЧЕР (от launcher) - программа, предназначенная для при-
нудительного запуска программ, защищенных от копирования, или запуска игр
«с середины».
ЛЕВЫЙ - неудобный, малоприятный, странный (например, «левый фейс»). Иног-
да употребляется как синоним слова «желтый» или «красный».
ЛЕЙБЛ (от label) - 1. Наклейка. 2. Специальный «невидимый» файл, задающий
11-символьную «метку» любого диска и иногда служащий для его идентификации.
ЛЕНТА - 1. Широкий и плоский кабель, применяемый для соединений устройств
внутри компьютера. 2. Кассета для стримака или арвида.
ЛЕТАТЬ - работать очень быстро. Например, «база теперь просто летает».
ЛЕЧИЛКА - антивирус, программа, предназначенная для обнаружения и уничто-
жения вирусов.
ЛИНК (от link) - станция, с которой установлена постоянная связь по передаче
почты.
ЛИНУКС или ЛИНУХ (от Linux) - наименование популярного клона Униха.
ЛИСТ (от list) - любой список.
ЛИСТИНГ (от listing) - 1. Текст программы в удобочитаемом виде. 2. (Устар.)
Распечатка.
ЛОГИН (от login) - процедура входа пользователя в ББС, сеть, сложную про-
грамму либо процедуру, обеспечивающая процесс идентификации и защиту от
несанкционированного доступа.
ЛОКАЛКА - 1. Локальная компьютерная сеть. 2. Конференция, имеющая хожде-
ние в основном среди линков определенного узла и обычно предназначенная для
распространения технической информации об этом узле и просто для болтовни.
ЛОМ - 1. Крайнее нежелание что-либо делать. 2. Дебугер. 3. Свалка.
ЛОМАЛКА - 1. Программа, специально предназначенная для снятия защиты от
копирования или другого несанкционированного изменения кода конкретной
программы. 2. Дебугер.
ЛОМАТЬ - 1. Снимать с программы защиту от копирования. 2. Изменять вруч-
ную машинный код программы. См. ХАК. 3. Нежелание делать что-либо (напри-
мер, «ломает меня это»).
ЛОНГЛИНК (от long-link) - линк, предназначенный для установления обмена
информацией с удаленной станцией, расположенной в другом городе или стра-
не. Обычно Л. называется нода, соединяющая местную сеть с хабом региональ-
ного бона.
ЛОХМАТЫЙ - интересный, разнообразный, удачно сделанный.
м
МАСКА (от mask) - набор специальных символов, задающих возможное пред-
ставление данных при выводе или поиске.
МАСТ ДАЙ (от mast die) - 1. Выражение крайней степени отвращения, отрица-
ния или раздражения в отношении чего-либо. 2. Операционная система Windows
(Windows 95, Windows 98...) фирмы Misrosoft.
МАШИНА - см. ТАЧКА.
МАК (от Macintosh) - персональный компьютер фирмы Apple.
МАКОВЫЙ - относящийся к Маку или созданный для него.
МАМА (от MotherBoard) - материнская плата компьютера или девайс, делаю-
щий его единой системой.
МАП (от тар) - схема или карта. Чаще всего употребляется в значении «карта
памяти», то есть схема расположения программ в оперативке.
МАСМ (от MASM) - макроассемблер - транслятор Асма, выпускаемый фирмой
Microsoft со времен появления доски (в 1 знач.).
МЕГ - 1. Мегабайт. 2. (Устар.) Симм объемом 1 Мбайт.
МЕЖДУМОРДИЕ - синоним интерфейса.
МЕЖДУНАРОДНА - 1. Эха, распространяемая в нескольких странах. 2. Меж-
дународная телефонная связь.
МЕЙЛЕР (от mailer) - см. МЭЙЛЕР.
МЕЛКОСОФТ или МЕЛКОМЯГКИЕ - фирма Microsoft.
МЕРИН или МЕРЛИН (от Merlin) - операционная система IBM OS/2, версия 4.
МЕССАГ- см. НЕТМЫЛ (1 знач.).
МНОГОЛИНЕЙКА - ББС или станция, подключенная одновременно к несколь-
ким телефонным линиям.
МОБИЛЬ - журнал объявлений о купле-продаже, в том числе и компьютерной
техники. Выпускается в бумажном виде и форме гипертекста.
МОД (от наименования файлов *.mod) - 1. Музыка, созданная в старой версии
одного из популярных трекеров (в 1 знач.). 2. Модератор.
МОДА (от mode) - режим работы (например, «текстовая скрин-мода»).
МОДЕРАТОР (от moderator) - участник эхи, следящий за соблюдением в ней
правил поведения участниками. Часто является создателем конференции.
МОДЕРАТОРИАЛ (от moderator) - официальное сообщение от модератора кон-
ференции. Обычно содержит правила (см. РУЛЕСЫ) или дисциплинарное взыс-
кание («плюс» или «звезда») одному из участников.
МОДЕРИРУЕМЫЙ (от moderated) - контролируемый модератором (о конфе-
ренции).
МОЗГИ - 1. Плата оперативной памяти компьютера. 2. Оперативная память как
измеряемая величина (например, «пять мегов мозгов»). 3. Процессор компьюте-
ра (редко).
МОТАЛКА - Московская сетевая конференция mo.talk - разговоры обо всем и ни
о чем...
МОЭХА - немодерируемая (см. МОДЕРИРУЕМЫЙ) сетевая конференция
МО. ECHO. Применительно к эхе - синоним свалки.
МПЕГ (от mpeg) - популярный формат сжатия видео- и аудиоданных.
МУЗЫКИ - оцифрованные или синтезированные музыкальные или музыкопо-
добные отрывки, сохраненные в файлах специальных форматов (*.mod, *.mp3).
МУЛЬТИАКАШНИК (от multi aka) - человек, имеющий несколько альтерна-
тивных адресов (АКА) в FidoNet.
МУЛЬТИТАСК или МУЛЬТИТАСКЕР - система, позволяющая одновременно
на одном компьютере исполнять несколько программ.
МУСИК (от music) - любая эха, связанная с музыкой.
МЫЛИТЬ (от mail) - писать и передавать сообщение по сети с использованием
личной почты (например, «отмыль мне, что у вас происходит»).
МЫЛО или мыл - см. НЕТМЕЙЛ.
МЭЙЛ-ОНЛИ (от mail-only) - режим работы станции, в котором она принимает
только звонки от мейлера для передачи почты или файлов; доступ для юзеров
отсутствует.
МЭЙЛЕР, МЕЙЛЕР или МАЙЛЕР (от mailer) - программа, занимающаяся ав-
томатической рассылкой почты по телефонной линии через модем.
МЭН (от man) - любой человек, не принадлежащий к компьютерной тусовке.
н
НАЕЗД - личный выпад, оскорбление.
НЕТВАРЬ - сетевая операционная система Novell NetWare.
НЕТМЕЙЛ (от NetMail) или НЕТМЫЛ, НЕТ МЫЛА - 1. Личное письмо (сооб-
щение), посылаемое по сети. 2. Способ пересылки сообщения (например, «слать
нетмейлом»).
НОГИ - способ передачи файла: нуждающийся сам приходит к тому, кто имеет
необходимый софт, и переписывает на дискеты вместо того, чтобы качать моде-
мом. Обычно употребляется в сочетании «забрать ногами». См. ФЛОППИНЕТ.
НОД (от node) - 1. Сисоп узла FidoNet. 2. Станция FidoNet (узел).
НОДА или нод (от node, станция) - полноправный член FidoNet (узел), вклю-
ченная в официальный мировой список (нодлист), с правом раздачи пойнтов.
НОДМЕЙКЕР (от nodemaker) - помощник, назначаемый сетевым координато-
ром с целью облегчения работы по выдаче новых узловых адресов. Используется
в самых крупных сетях (например, в 2:5020).
НОДЛИСТ (от nodelist) - список узлов сети. См. НОДА.
НОРТОН - широко известный файловый шелл Norton Commander.
НОТБУК или НОУТБУК - 1. Переносной компьютер класса Notebook. 2. Про-
стейший текстовый редактор Notepad в системе Windows.
НЦ (от NC - Net Coordinator) - координатор местной сети.
О
ОБОЛОЧКА - см. ШЕЛЛ.
ОБОИ - картинка, отображаемая на заднем плане в графической операционной
среде и служащая фоном.
ОКОШКИ или ОКНА - графическая операционная оболочка Windows 3.1
фирмы Misrosoft и другие операционные системы семейства Windows (95, 98...).
См. ВИНДЫ, МАСТДАЙ (2 знач.).
ОНЛАЙНОВЫЙ (от on-line) - 1. Происходящий в непосредственном контакте
(не по телефону и не посредством чата). Например, «онлайновая тусопка».
2. (Применительно к файлу.) Выложенный на борду и доступный для скачива-
ния модемом. 3. Реально существующий.
ОЛЛ (от all) - общество подписчиков определенной конференции. Употребля-
ется в основном в обращениях.
ОЛФИКС - файл-эхоменеджер AllFix.
ОЛЯ (от OLE) - технология Object Linking and Embedding, позволяющая редакти-
ровать данные, созданные в другой программе, не выходя из основного редактора.
ОПЕРАТИВКА - оперативная память компьютера.
ОПЕРАЦИОНКА - операционная система, программа, занимающаяся обеспече-
нием работы других программ и организацией их взаимодействия друг с другом
и аппаратурой компьютера.
ОПЦИЯ (от option) - 1. Одна из возможностей программы, которой можно по
желанию воспользоваться. 2. Необязательный параметр или возможность.
ОПЦИОНАЛЬНЫЙ (от optional) - необязательный, но возможный.
ОРИГИН или ОРИДЖИН (от origin) - строка, прибавляемая автоматически
в конце письма. В ней содержится информация об адресе отправителя, другие
данные (например, координаты его ББС) или просто афоризм, используемый как
дополнительная подпись.
ОС (от Operating System) - операционная система. См. ОПЕРАЦИОНКА.
ОТКВОТИТЬ (от quote) - процитировать письмо или его часть при ответе,
отстой - синоним свалки, но имеет оттенок грубости.
ОТФИКСИТЬ (от fixing) - 1. Исправить мелкую ошибку в программе. 2. Изме-
нить один из множества параметров системы, заставив ее тем самым лучше рабо-
тать См ФИКСИТЬ, ПОФИКСИТЬ, ЗАФИКСИТЬ.
п
ПАБЛИК ДОМЕЙН (от Public Domain) - программа, бесплатно распространяе-
мая вместе с исходными текстами.
ПАКЕТ - несколько однородных единиц информации (например, мыла), пред-
назначенные для передачи по сети в одном файле.
ПАРТИ (от party) - прогулка, собрание, тусопка (малоупотр.). 2. Сборище демо-
мейкеров зимой в Дании.
ПАССВОРД (от password) - пароль, необходимый для доступа к сетевым службам.
ПАСКАКАЛЬ - язык программирования Pascal.
ПАСКВИЛЬ - народное название языка Pascal. См. ПАСКАКАЛЬ.
ПАССРУ (от passthrough) - экономичный способ передачи эх или файл-эх, при
котором получаемые сообщения или файлы не хранятся в локальной базе и уда-
ляются сразу после отправки даунлинкам.
ПАТЧИТЬ (от patch) - изменять часть кода программы, обычно для исправле-
ния мелких ошибок или снятия защиты от копирования.
ПЕН или ПЕН-НОТБУК — компьютер с «рукописным» вводом.
ПЕНТЮХ или ПЕНЬ - компьютер с процессором класса Intel Pentium.
ПЕПСИ - любой безалкогольный напиток. См. АНДЕДОВКА.
ПЕРЕЛИНКОВЫВАТЬСЯ или ПЕРЕПОЛЗАТЬ (под кого-либо) — для пойн-
та - менять босса, для нода - менять основного аплинка.
ПЕРЕРУБИТЬ - 1. Выключить и через некоторое время снова включить пита-
ние компьютера для его перезапуска. При определенного рода зависах - единст-
венный способ «оживить» компьютер. 2. Переключить в другую электрическую
розетку или слот (малоупотр.).
ПИВО - см. ПЫВО.
ПИВТОВКА - см. ТУСОПКА.
ПИМПОЧКА - клавиша или кнопка.
пипл или ПИПЛЗ (от people, заимств. у хиппи) - участники любой компании
или сообщества. Чаще всего эквивалент «олл». В варианте ПИПЛ употребляется
применительно к одному человеку.
ПИРАТ - 1. Пользователь незаконных копий программ. 2. То же, что КРАКЕР
или КРЕКЕР (см.).
ПИРАТСТВО - целенаправленная деятельность по добыче и хаку коммерческих
программных продуктов.
ПИСЮК или ПИСИШКА (от PC) - компьютер IBM PC. См. ТАЧКА.
ПИХНУТЬ - опубликовать в эхе или бумажном издании.
ПЛАТА (от plate) - электронное устройство (обычно собранное на печатной пла-
те без корпуса), вставляемое в слот внутри компьютера.
ПЛЮС - дисциплинарное взыскание, накладываемое модератором эхи на участ-
ника, грубо нарушившего ее правила. Выражается в посылке нетмейлом прови-
нившемуся письма, содержащего символ «+» и объяснение, за что он поставлен.
ПЛЮСЫ - компилятор C++ (например, «писано на плюсах»).
ПЛЮСОМЕТ - виртуальное оружие модератора.
ПОЙНТ или ТОЧКА (от point) - 1. Станция, общающаяся с FidoNet через босса
и формально не являющаяся членом сети. 2. Владелец точки в FidoNet. 3. Адрес
точки в сети. Выдается боссом.
ПОЙНТЛИСТ (от pointlist) - официальный список пойнтов местной сети. Не
является обязательным документом сети в отличие от нодлиста.
ПОЙНТОВКА - ТУСОПКА, на которую собираются пойнты определенной но-
ды для общения с другими пойнтами, боссом и пывом.
ПОКАЗАТЬ РЕГИСТРЫ - (о программе или компьютере) - перестать функ-
ционировать, выдав предварительно на экран информацию о состоянии системы
(в том числе о содержимом регистров) в момент критической ошибки. См. ТРАП.
ПОКОЦАННЫЙ (о файле) - испорченный в результате технической неисправ-
ности при хранении или передаче.
ПОЛИСИ (от Policy) - «конституция» FidoNet, свод правил, определяющий
структуру и принципы функционирования сети, а также правила поведения ее
участников.
ПОРОШОК - тонер, «чернила» для лазерного принтера или ксерокса.
ПОФИКСИТЬ - 1. Исправить мелкую ошибку в программе. 2. Изменить один из
множества параметров системы, заставив ее тем самым лучше работать. См. ОТ-
ФИКСИТЬ, ЗАФИКСИТЬ.
ПОЮЗАННЫЙ (от use) - бывший в употреблении, но еще годный к использо-
ванию. См. ЗАЮЗАННЫЙ, ЮЗАНЫЙ.
ПРЕРЕЛИЗ или ГАММА (от pre-release, gamma) - последний перед офици-
альным выпуском вариант программы. Обычно бывает почему-то наиболее
надежным.
ПРИАТТАЧИТЬ (от attach) - послать файл на другую станцию традиционным
для FidoNet способом. См. АТТАЧ.
ПРИЛИНКОВАТЬ (от link) - установить постоянный линк с системой, находя-
щейся ниже данной в иерархической структуре распределения почты.
ПРИНТОВАТЬ - 1. Распечатывать на принтере. 2. Просто печатать.
ПРИПЛЮСНУТЫЙ - получивший плюс в сетевой конференции.
ПРИПОЙНТОВАТЬ - выделить пойнт на своей ноде.
ПРОЛОГ - 1. Начало, предисловие, введение. 2. Специальный код, помещаемый
в точке входа программ для некоторых операционных систем. 3. Язык логическо-
го программирования Prolog. Широко известен, но в настоящее время мало рас-
пространен.
ПРОГРАММЕР (от programmer) - компьютерщик, умеющий создавать свои про-
граммы. Синонимом слова «программист» не является. Иногда к П. ошибочно
причисляют пользователей, умеющих обращаться с языкоподобными средства-
ми типа «васика».
ПРОГРАММИСТ - художник, в совершенстве владеющий искусством создания
программ и понимающий работу компьютера на интуитивном уровне. Обычно
владеет не меньше чем десятью языками программирования, из которых активно
использует три-четыре, но в любом случае создает подъязыки для более изящ-
ного выражения своих идей. П. - вершина эволюции ХАКЕРА. Вопреки распро-
страненному мнению, настоящий П. далеко не всегда является хорошим мате-
матиком. Иногда употребляется чайниками как аналог слова «программер».
ПОЛЛ (от poll) - стандартная директива мейлера, указание позвонить на ноду
босса или аплинка при отсутствии исходящей корреспонденции только для того,
чтобы забрать пришедшую почту.
ПОЛЛИТЬ (от polling) - непрерывно звонить мейлером на ноду босса или ап-
линка при отсутствии исходящей корреспонденции только для того, чтобы за-
брать пришедшую почту.
ПОЛНОЦВЕТНЫЙ - воспроизводящий или воспринимающий (если речь идет
о сканере) цвет, кодируемый в 24-битном формате, иначе говоря, различающий
16777216 разных цветов.
ПОЛУМУХ - см. ПОЛУОСЬ.
ПОЛУОСЬ или ПОЛУМУХ, ПОЛШМЕЛЯ, ОС ПОПОЛАМ, ПОПОЛАМ - опе-
рационная система OS/2.
ПОЛШМЕЛЯ - см. ПОЛУОСЬ.
ПОПОЛАМ - см. ПОЛУОСЬ.
ПРИВАТНЫЙ (от private) - характеристика объекта, информация о котором не
распространяется. Обычно имеется в виду номер телефона.
ПСОВЫЙ или писюковый - относящийся к IBM-совместимым персональ-
ным компьютерам. Употребляется обычно как антоним слова МАКОВЫЙ (см).
ПУЛЬС - 1. Пульсовый набор телефонного номера, при котором цифра опреде-
ляется количеством щелчков реле. Способ устарел, но пока еще используется
большинством «атеэсок» России. 2. Программа, показывающая степень загрузки
процессора в ПОЛУОСИ (см.).
пыво (от beer) - национальный напиток FidoNet. На тусопках выпивается
ящиками.
Р
РАМ (от RAM - Random Access Memory) - см. ОПЕРАТИВКА.
РЕАЛТАЙМ (от realtime) - реальное время, применяется обычно к вычислени-
ям, позволяющим либо параллельно выполнять несколько заданий, либо быстро
воссоздавать сложные (в частности, динамические) графические изображения.
РЕБУТ (от reboot) - перезагрузка (реинициализация) компьютера.
РЕВИЗИЯ (от revision) - модификация программы. В полном номере версии
номером Р. считается число, стоящее после точки.
РЕИНИТИТЬ (от reinit) - синоним «ресетить», но применительно к про-
граммам.
РЕЛИЗ (от release) - версия программы, прошедшая тестирование и официально
выпущенная автором для распространения или продажи. Часто употребляется как
антоним беты.
РЕЛИЗИТЬ (от release) - выпускать программу (чаще всего имеется в виду за-
конченная новая версия) или книгу в файле.
РЕМАПИТЬ (от remapping) - переводить структурированный объект (напри-
мер, карту) из одной системы кодирования в другую, менять структуру в соот-
ветствии с новыми условиями или изменять масштаб.
РЕНДЕРИТЬ (от rendering) - создавать трехмерное (обычно движущееся) изоб-
ражение в редакторе типа 3D Studio.
РЕПЛАЙ (от reply) - ответ на письмо.
РЕСЕНД (от resend) - 1. Повторная посылка модемом блока данных при полу-
чении сигнала об ошибке приема. 2. Повторная посылка письма адресату.
РЕСЕТИТЬ (от reset) - перезапускать компьютер или другое устройство, нуж-
дающееся в инициализации.
РЕСТРИКТЕД (от restricted) - ограниченный (доступ). См. ЗАРЕСТРИК-
ЧЕННЫЙ.
РЕСУРСЫ - потенциальная мощность компьютера: скорость процессора, па-
мять, объем жесткого диска, возможности расширения.
РЕТРАЙ (от retry) - 1. Повторная попытка считать испорченный блок инфор-
мации с дискеты. 2. Повторная посылка по модему блока данных, не принятого
из-за помех в линии.
РЕТРЕЙН (от retrain) - процедура переустановления связи модемами без раз-
рыва соединения.
РИП (от R.I.P.) - 1. Аварийное завершение программы. 2. Состояние перед от-
правкой в крематорий.
РИС. 1 (фолькл.) - изображение жеста, выражающего презрение к адресату и обыч-
но не воспроизводимого при дамах.
РОМ (от read-only memory) - диск (обычно сидюшник) или область памяти
(обычно биос адаптеров), доступная в режиме «только для чтения».
РОУТИНГ (от routing) - маршрут, путь письма от отправителя к адресату через
транзитных хабов.
РУЛЕЗ (от амер, rulez) - восклицание (обычно выделенное на письме восклица-
тельным знаком), выражающее крайнюю степень одобрения, поддержки и т.п., на-
пример: «Уних рулез!».
РУЛЕСЫ (от rules) - правила поведения в эхе. Устанавливаются и публикуются
модератором.
РЦ (от RC - Region Coordinator) - координатор региона FidoNet.
С
САБСЕТ (от subset) - часть, подмножество. Употребляется в основном при об-
суждении технических вопросов.
САВТОКРЕАЧЕННЫЙ (от autocreate) - созданный автоматически. Обычно
употребляется применительно к области эхо-почты. См. АВТОКРИЭЙТ.
САКС или СУКСЬ (от амер, sucks - «плохой») - выражение крайней степени
отвращения и недовольства (например, «кстати, модем оказался суксь!»).
САНИТАРЫ ЛЕСА - старушки, во время пивтовок собирающие пустые бутыл-
ки из-под пива.
САУНД (от sound) - 1. Звуки (в частности, музыка), воспроизводимые компью-
тером. В отношении писка, издаваемого ХАСБУЛАТОВЫМ, данный термин не
применяется. 2. Синоним слова «музыка».
СВАЛИТЬСЯ (о почтовых пакетах или файлах) - прийти директом по модему.
Обычно употребляется, когда речь идет о больших объемах информации.
СВАЛКА - 1. Эха, загаженная большим количеством бессодержательных разгово-
ров и флейма. 2. Неотсортированный склад файлов на жестком диске. 3. Архив.
СВОП или СВОПФАЙЛ (от swap-file) - файл на жестком диске, который ОС
использует для создания виртуальной памяти, временно «сбрасывая» туда редко
используемые области.
СВЕЖИЙ (о программе) - недавно написанный.
СВИЧ или СВИТЧЕР (от switch) - любой переключатель. Исходное значение -
замыкатель контактов на карте, позволяющий производить первичную аппарат-
ную настройку.
СГЕНЕРЕННЫЙ - созданный специальной программой. См. ГЕНЕРИТЬ.
СЕЙВЕР или СКРИНСЕЙВЕР (от ScreenSaver) - программа, по прошествии
определенного времени, в течение которого пользователь «неактивен» (не нажи-
мает клавиши и не двигает мышь), стирающая содержимое экрана и отображаю-
щая на нем движущуюся картинку. Раньше предназначалась для предохранения
экрана от выгорания люминофора; сейчас используется для развлечения или для
блокирования работы компьютера при отсутствии «хозяина» на рабочем месте.
СЕМАФОР (от semaphore) - флаг-файл, используемый для передачи программе
информации о необходимости совершения определенного действия.
СЕРВЕР (от server) - 1. Компьютер, жесткий диск которого совместно исполь-
зуется несколькими другими машинами, объединенными в локальную сеть.
2. Компьютер, на котором установлена ББС. 3. Программа, предоставляющая
собственный код и/или данные другим программам.
СЕТТИНГИ (от settings) - постоянные параметры конфигурации программы,
сидюшник - дисковод для компакт-дисков с данными (CD-ROM) или сам
компакт-диск. В последнее время употребляется и для обозначения звуковых CD.
СИММ (от SIMM) - плата оперативной памяти компьютера.
СИНБАЙ ИЛИ СИНБАЙЧИК (от seen-by) - служебная строка SEEN-BY эхо-
письма, содержащая информацию о том, какие узлы ее получают. Создается ав-
томатически и не всегда видна пользователю.
СИСОП (от sysop) - 1. «Хозяин» ББС, контролирующий ее содержимое и дос-
туп к ней ЮЗЕРОВ. 2. Владелец узла в FidoNet, имя которого содержится в нод-
листе. 3. В широком смысле - человек, контролирующий станцию независимо от
ее статуса.
СИСОПКА - I. Съезд нодов сети для обсуждения вопросов ее функционирова-
ния. 2. Сборище СИСОПОВ, обычно сопровождающееся совместной попойкой.
СИСТЕМЩИК (устаревающ.) - программист, знающий один или несколько
языков ассемблера и умеющий писать программы, работающие ниже уровня ин-
терфейса операционной системы. Иногда употребляется в более узком смысле:
программист, непосредственно пишущий операционные системы. Иногда С. не-
правильно называют всех хакеров.
сиэм или ЦМ (от СМ - Continuous Mail) - круглосуточно работающая станция.
СКАЗЕВЫЙ (о девайсе) - общающийся с компьютером через интерфейс SCSI.
СКАНЕРИТЬ (от scanner) - 1. Вводить картинку в компьютер с помощью ска-
нера. 2. Рассматривать, просматривать.
СКАЧАТЬ - см. СЛИТЬ.
СКВИШ или (реже) СКВИШЬ (от squish) - 1. Эхо-процессор Squish, исполь-
зуемый многими нодами. 2. База в формате Squish. 3. Собака дворовой породы
(шутл.).
СКРИН (от screen) - экран компьютера.
СЛИТЬ - получить с ББС некоторое количество файла.
СЛОТ (от slot) - разъем для подключения устройства (обычно внутри ком-
пьютера).
СМАЙЛИК (от smile) - специальное сочетание символов, «улыбка». См. часть II.
СНЕСТИ (о больших системах, например осах или других программных систе-
мах) - удалить с компьютера или отключить.
СОВКОВЫЙ - 1. Русский, российский, советский. 2. Синоним КРАСНОГО (см.).
СОЛЮШН (от solution) - 1. Инструкция по прохождению компьютерной игры.
2. Решение любой проблемы.
СОПР (от co-processor) - математический сопроцессор (с аппаратно реализован-
ной работой с нецелыми числами и расчетом математических функций), необхо-
димый для ускорения работы процессора.
СОФТ или СОФТВЕР (от software) - любое программное обеспечение.
СОФТИНА (от software) - конкретная программа.
СПЕЙС (от space) - свободное место, чаще всего на диске.
СПЕЦИФИКАЦИЯ (от specification) - список параметров, определяющий не-
обходимый тип оборудования или программного обеспечения.
СПОРТ или СПОРТСТЕР (от Sportster) - популярный модем фирмы US Robotics
(в настоящее время фирма ЗСОМ).
СС или СИСИ (от Carbon Сору) - директива рассылки копий одного письма по
многим адресам. См. КАРБОН.
ССАНКС (от thanks) - выражение благодарности.
СТАВИТЬ - устанавливать и налаживать компьютерную технику.
СТАНЦИЯ (от station) - компьютер с модемом, принимающий входящие звонки
и оборудованный соответствующим программным обеспечением для обслужива-
ния этих звонков. Обычно под С. подразумевается узел или пойнт-система FidoNet.
СТАФФ (от stuff) - любое приспособление, дока или полезная программа.
СТРИМАК (от streamer) - стример, устройство записи для хранения информа-
ции на магнитной ленте. См. ДЖАМБА.
СТРИПИТЬ (от stripping) - 1. Делать значение переменной или флага равным
нулю. 2. Снимать с компьютера какую-либо маловажную деталь.
СТРУЙНИК - струйный («чернильный») принтер. Почти бесшумный, но очень
медленный (по сравнению с лазерным, конечно).
СУБЖ или САБЖ (от subj) - служебная строка заголовка письма, в которой по-
мещается его «тема» или просто слово или выражение, которое автор считает
уместным присовокупить к письму. При длинных дискуссиях обычно полностью
теряет отношение к текущей теме разговора.
СУХУМОР (от названия эхи SU. HUMOR) - неостроумные высказывания с пре-
тензиями на оригинальность, производимые в большом количестве.
СЫРЦЫ (от source) - исходный текст программы на одном из языков.
СЯО (кит.) - бред, дезинформация, бессмысленное сообщение.
т
ТАЙМ (от time) - время. Термин применяется почти исключительно для обозна-
чения свободного времени человека.
ТАСК (от task) - см. задача.
ТАСМ (от TASM) - транслятор АСМА фирмы Borland.
ТАЧКА или МАШИНА, КОМП - компьютер.
ТАЩИТЬ - получать по модему данные со станции.
ТЕЛЕМАРКЕТ (в зависимости от контекста) - «все в норме» или «очень плохо».
Например, «все телемаркет» эквивалентно выражению «все хорошо»; «это пол-
ный телемаркет» означает «ничего не получается».
ТЕМП-ДАУН (от temporary down) - временное прекращение работы станции.
ТЕМПЛЕЙТ (от template) - образец, шаблон.
ТЕХНОКРЫСА или КРЫСА - 1. Программист, занимающийся написанием
и распространением компьютерных вирусов. Одна из наименее уважаемых в ком-
пьютерном обществе категорий. 2. Пират, профессионально занимающийся про-
никновением в закрытые компьютерные сети с целью шпионажа, блокирования
сети или нанесения участникам материального ущерба. 3. Манипулятор «мышь».
ТИК (от tick) - 1. Файл, содержащий информацию о другом файле, посылаемом
вместе с ним по файл-эхе. 2. «Квант времени» процессора - длительность, опре-
деляемая тактовой частотой. Например, при частоте 233 МГц - 233 млн. тиков
в секунду.
ТИРЛАЙН (от tearline) - «линия отреза», означающая конец сообщения, строка
обычно содержит информацию о редакторе, в котором создано сообщение.
ТМЫЛ - популярный российский мейлер Андрея Елкина T-Mail.
ТОН - тоновый набор номера - каждой набираемой цифре соответствует звук опре-
деленной высоты. Используется современными цифровыми АТЕЭСАМИ (см.).
ТОПТАТЬ (кнопки) - набирать что-либо на клавиатуре компьютера.
ТОССЕР (от Tosser) - программа, выполняющая распаковку и распределение по
конференциям (областям) почтовых пакетов, принятых мейлером, а также под-
готавливающая исходящие пакеты для рассылки. Также распространен образо-
ванный от Т. глагол «тоссить».
ТОЧКА - см ПОЙНТ.
ТРАБЛ (от trouble) - техническая неполадка, приведшая к мелким неприятнос-
тям, например к темп-дауну станции.
ТРАНСЛЯТОР (от translator) - программа, переводящая исходный текст, напи-
санный на одном из языков программирования, в машинный код.
ТРАП или ТРЭП (от trap) - аварийное прерывание работы ОСа (чаще всего «по-
луоси», поскольку термин происходит от наименования сообщения о критичес-
кой ошибке OS/2, хотя может применяться в отношении любого программного
процесса). Например: «И после этого она не выдержала и трапнулась». См. ЭК-
СЕПШН
ТРАСИТЬ или ТРЕЙСИТЬ (от trace) - 1. Изучать программу, наблюдая после-
довательность исполнения команд. 2. Следить за любым процессом.
ТРАФИК - 1. Поток писем в эхе. Употребляется в основном применительно
к объему этого потока. 2. Объем пакетов почты и файлов, регулярно проходящих
по сети.
ТРЕД (от thread) - в многозадачных осах - дополнительная подзадача, выпол-
няемая в составе основной задачи или процесса. См. ЗАДАЧА, ТАСК.
ТРЕКЕР (от tracker) - 1. Программа, предназначенная для написания много-
голосных мелодий с использованием заранее оцифрованного звука («инструмен-
тов»). 2. Программа, дополнительно обрабатывающая личную почту См. ГРАБЛИ.
ТРЕТПК А - устаревший, но еще встречающийся компьютер IBM PC с процессо-
ром класса Intel 80386.
ТРЕУГОЛЬНИК - разновидность бекбона.
ТРОЯН (от «троянский конь») - программа с деструктивными функциями,
маскирующаяся под полезную общедоступную программу.
ТРУНКЕЙТИТЬ (от truncate) - не стирая файл, уничтожать все содержащиеся
там данные, делая длину файла нулевой.
ТУГРИК - российский рубль, украинский карбованец или другая валюта стран СНГ.
ТУРБА (от turbo) - 1. Режим работы компьютера без «торможения» процессо-
ра - отключается обычно только для запуска старых, неприспособленных к быст-
рым машинам игр. 2. Кнопка переключения в турбо-режим. 3. Повышенная ско-
рость любого процесса.
ТУСОПКА - см. СИСОПКА (2 знач.).
У
УБЛИСТ или УБЕЙЛИСТ - официальный список (с параметрами и телефона-
ми) всех ББС, работающих в странах СНГ и Прибалтики. В настоящее время не
выпускается. Термин может применяться к любому списку ББС.
УБИТЬ - 1. Стереть файл. 2. Аварийно завершить процесс или программу.
3. Оборвать связь с юзером на ББС.
УЕЗЖАТЬ - веселиться до потери ориентации в пространстве.
УЗЕЛ - см. НОД, НОДА.
УМОЛЧАНИЕ - действие, выполняемое программой, если альтернативное не за-
дано специально. См. ДЕФОЛТ, ДЕФАУЛТ.
УНИХ - семейство операционных систем Unix.
УПАСТЬ (о станции) - перестать функционировать, например в результате от-
ключения телефона.
УПС (от UPS) - источник и стабилизатор бесперебойного питания для компью-
теров, позволяющий нормально работать даже в условиях нестабильного элек-
троснабжения.
Ф
ФАЙЛ-ЛИСТ (от file list) - список файлов, доступный для сливания с ББС.
ФАЙЛО - любое количество файлов. Чаще всего термин употребляется приме-
нительно к двунаправленному потоку информации.
ФАЙЛ-ЭХА (от file echo) - наименование сервиса тематических файловых рас-
сылок.
ФАЙЛ-ЭХОМЕНЕДЖЕР или ФАЙЛ-ЭХОПРОЦЕССОР (от File Echo-Mana
ger, File Echo-Processor) - программа, обрабатывающая информацию, проходя-
щую по файл-эхам и в определенных случаях выполняющая специфические за-
просы по поиску файлов.
ФЕЙС (заимств. у хиппи) - лицо, внешний вид, состояние.
ФИДОПОЙКА - см. ПИВТОВКА. Местом регулярных Ф. служит ежегодное
собрание фидошников на весенней компьютерной выставке КОМТЕК в Москве.
ФИДОШНИК - член сети FidoNet. В более узком смысле - достаточно актив-
ный участник сетевых конференций и онлайновых тусовок (тусопок).
ФИДОШНЫЙ - относящийся к сети FidoNet или (о программе) поддерживаю-
щий ее стандарты. Например, «фидошный мейлер».
ФИКС (от fix) - исправление ошибок в публично распространяемой программе.
Применяется, в частности, для обозначения новых отфиксенных версий.
ФИКСИТЬ - 1. Исправлять ошибку в программе. 2. Изменять параметры систе-
мы, заставляя ее тем самым лучше работать. См. ПОФИКСИТЬ, ЗАФИКСИТЬ,
ОТФИКСИТЬ
ФИЛЕ или ФИЛЕС (от files) - синоним файла, но область применения значи-
тельно шире. Иногда употребляется для обозначения файл-листа.
ФИФА - КОММ, имеющий буфер данных, организованный в виде очереди типа
FIFO (First In - First Out: «первый пришел - первый ушел»).
ФИЧА (от feature) - 1. Удобная опция в программе. 2. Маленькая полезная ути-
лита. 3. Несложное, но облегчающее жизнь приспособление. 4. Антоним слова
БАГА (см.).
ФЛАГ (от flag) - специальный файл, переменная или бит в специальном регист-
ре, определяющий поведение программы или процессора. Флаги по определению
бинарны, то есть имеют два возможных значения: есть/нет.
ФЛЕЙМ (от flame) - малосодержательные, но объемные споры, постепенно пе-
реходящие с предмета спора на личности.
ФЛОП или ФЛОПИК (от floppy disk) - дискета или дисковод (иногда в этом
значении употребляется слово «флопповод»). В ед. ч. употребляется редко.
ФЛОППИНЕТ (от FloppyNet) - способ передачи файлов (в частности, почты)
«ногами».
ФЛЭТ (от flat) - 1. Односегментная модель памяти в программах для процессо-
ров класса не ниже 386. 2. (Заимств. у хиппи.) Квартира, обычно свободная от не
принадлежащих к фидошной тусовке.
ФОНА (от phone) - телефон или номер телефона.
ФОРВАРДИТЬ (от forward) - помещать полный текст письма (с заголовком
и технической информацией) в эху. Обычно употребляется для цитирования
важной информации, пришедшей мылом или в другую эху.
ФОРТОЧКИ, ФОРТКИ - см. ОКОШКИ.
ФОССИЛ (от FOSSIL) - специальная резидентная программа, обеспечивающая
работу с модемом. Ее присутствия в памяти требуют многие мейлеры.
ФРЕК (от freq, File Request) - способ запроса файла со станции.
ФРЕКАБЕЛЬНО (от freq-able) - доступно для фрека.
ФРЕКЕР - человек, часто посылающий файловые запросы. Ф., пытающийся
сразу взять со станции все, что там лежит, рискует получить бомбу.
ФРЕКНУТЬ - послать фрек и получить по нему файл(ы).
ФРИВАР или ФРИВОР (от freeware) - программа, распространяемая бесплатно.
ФРИСТОЛ (от freestole) - нелегально копируемая программа.
ФРЯ (от Free BSD) - именование популярного клона Униха.
ФРОМ (от from) - 1. Отправитель мыла. 2. Адрес, с которого отправлено данное
сообщение. 3. Иностранец.
ФРОНДА или ФРОНТ ДУРА - распространенный мейлер Front Door.
ФУЛСКРИН (от Full Screen) - полноэкранная текстовая сессия программы.
X
ХАБ (от hub) - «буферная» нода, накапливающая почту для дальнейшего рас-
пределения по даунлинкам в сети.
ХАДСОН (от hudson) - популярный формат базы сообщений. См. ГАДСОН.
ХАК (от hack) - 1. Модификация работы программы (например, снятие защиты
от копирования) путем непосредственного изменения ее машинного кода. 2. Хак-
нутая программа или хакерская подделка фирменной программы.
ХАКНУТЫЙ - измененный посредством хака.
ХАКЕР (от амер, hacker) - 1. Опытный программер, хорошо знакомый с тонко-
стями работы компьютера. Обычно (но не всегда) является системщиком. 2. (Исх.
знач.) Программер, способный сломать защиту от переписывания либо от до-
ступа программы или информационного комплекса, например сети. См. ПИРАТ.
3. Самоназвание ТЕХНОКРЫС.
ХАРД (от hard) - 1. Жесткий диск компьютера. 2. Железо. 3. Тяжелый рок.
ХАРДВЕР (от hardware) - см. ЖЕЛЕЗО.
ХАСБУЛАТОВ - внутренний динамик компьютера. См. БИППЕР.
ХАЮШКИ - см. ХИ.
ХВОСТ - кабель, соединяющий манипулятор «мышь» с компьютером.
ХЕДЕР (от header) - 1. Специальный заголовок (несколько байтов, содержащих
служебную информацию), записываемый в начало файла. 2. Специальный файл,
содержащий определения переменных и функций программы на языке Си. 3. За-
головок в газете или журнале.
ХЕЛП (от help) - 1. Система подсказок в программе. 2. Помощь.
ХИ или ХАЙ (от hi) - «русскоязычная» форма общепринятого в сети при-
ветствия.
ХИДДЕН (от hidden) - непубликуемый или спрятанный, скрытый.
ХИНТ (от hint) - совет, рекомендация, инструкция.
ХОЛД (от hold) - 1. Указание мейлеру отправить файлы по определенному сете-
вому адресу, причем только по прямому звонку с этого адреса, без попыток позво-
нить туда. 2. Жесткий диск станции. Значение возникло из-за неверной интер-
претации чайниками выражения «выложить на холд». 3. Режим работы ноды, при
котором она доступна по нетмейлу только через сетевой хост.
ХОСТ (от host) - 1. Станция, готовая к приему звонка модемом. 2. Центральный
узел сети.
ХЭКЕРИЗ или ХАКЕРИЗ (от hackeris) - самоназвание многих компьютерных
диалектов.
ц
ЦЕПЕЭС или ЦЕПЕЭСЫ (от CPS - characters per second) - скорость передачи
данных по модему. Имеется в виду фактическая скорость (в отличие от номиналь-
ной скорости коннекта).
ЦИФРОВАТЬ - 1. Вводить в компьютер схему в виде последовательности ко-
ординат точек с помощью дигитайзера. 2. Вводить любые аналоговые данные
(например, звук) в цифровом виде с помощью специальных периферийных
устройств.
ЦМ (от СМ - Continious Mail) - станция с непрерывным режимом работы. См.
сиэм.
цмос (от CMOS) - «постоянная» память компьютера, в которой при выклю-
чении сохраняются основные настройки и поддерживается ход внутренних ча-
сов. В СОВКОВОЙ (см.) литературе употреблялась аббревиатура КМОП.
Ч
ЧАВО - ответы на ЧАсто задаваемые ВОпросы. См. FAQ (часть III).
ЧАТ (от chat) - «разговор» сисопа с юзером на ББС, когда все вводимое с кла-
виатуры отображается на экране компьютера собеседника.
ЧАЙНИК - 1. Начинающий юзер. 2. Человек, не умеющий или плохо умеющий
обращаться с компьютером и/или не знающий правил поведения в сети. 3. Не-
компетентный в каком-либо вопросе человек (например: «В экономике я полный
чайник»).
ЧЕЙН (от chain) - несколько устройств, включенных последовательно через один
и тот же, чаще всего сказевый, интерфейс.
ЧЕТВЕРКА - компьютер класса Intel 80486.
ЧИП (от chip) - микросхема. Не путать с платой.
ш
ШАР ВАР (от shareware) - условно бесплатная программа, пользователь которой
по истечении некоторого срока эксплуатации должен заплатить за нее создателю
или отказаться от использования.
ШАРВАРНЫЙ или ШАРОВАРНЫЙ - распространяемый на принципах шар-
вара. Термин обычно применяется к программам, требующим регистрации для
разблокирования некоторых фич или продолжения нормальной работы по исте-
чении определенного срока.
ШЕЙП (от shape) - внешний вид человека или компьютера.
ШЕЛЛ (от shell) или ОБОЛОЧКА - программа, упрощающая взаимодействие
с ОСом и (иногда) добавляющая к нему новые возможности.
ШНУР - принтерный или модемный кабель.
э
ЭДИТОР (от editor) - текстовый редактор.
ЭКЗЕШНИК (от execute) - 1. Файл-программа с расширением *.ехе. 2. Любая
исполняемая программа или модуль. Файл Э. содержит коды, непосредственно
воспринимаемые и исполняемые процессором.
ЭКСЕПШН (от exception) - 1. Аварийная ситуация при работе обычной про-
граммы или ОСа, иногда приводящая к аборту. См. ТРАП. 2. Специальный ин-
терапт в мультитасках, позволяющий системе отследить некоторые особые си-
туации в работе.
ЭКСКЛЮЖН (от exclusion) - см. ИСКЛЮЖН.
20 - 431
ЭКСТЕНДЕР (от Extender) - программа, расширяющая возможности других
программ - например, предоставляющая доступ к большему объему памяти.
ЭКСЧЕНЧ (от exchange) - «торговая» эха, в которой разрешены мелкие коммер-
ческие объявления.
ЭЛЕКТРОНЩИК - человек, умеющий работать с «внутренностями» компьюте-
ра, в том числе определять и исправлять неполадки.
ЭНКОД (от encode) - см. ЕНКОД.
ЭНТЯ (от NT) - операционная система Windows NT фирмы Microsoft.
ЭХА (от echo) - сетевая конференция, в которой каждое публикуемое сообще-
ние может быть прочитано любым из ее участников. Таким образом создается
эффект общей беседы.
ю
ЮЗАБЕЛЬНЫЙ (от usable) - полезный, годный; реже - удобный.
ЮЗАТЬ (от use) - использовать; в определенном контексте - бить.
ЮЗАНЫЙ (от use) - бывший в употреблении. См. ЗАЮЗАННЫЙ, ПО-
ЮЗАННЫЙ.
ЮЗЕР (от амер, user) - 1. Пользователь компьютера, не умеющий писать про-
граммы. 2. Пользователь ББС. Обычно имеется в виду не член FidoNet.
Я
ЯБЛОКО - фирма Apple или компьютер этой фирмы.
ЯБЛОЧНЫЙ - см. МАКОВЫЙ.
ЯЗЫК - 1. Собственно язык программирования. 2. Система программирования,
компилятор, переводящий программу на одном из языков в машинные коды.
Приложение V
Справочник
русскоязычных
конференций FidoNet
Настоящий справочник составлен на основании тематического списка эхо-кон-
ференций русскоязычной части FidoNet, регулярно выпускаемого Дмитрием Дон-
цовым. Справочник составлен на базе основного списка конференций московско-
го эхо-бона и содержит большое количество ссылок на внутримосковские или
московского происхождения эхи.
При использовании списка следует иметь в виду, что у каждой эхо-конференции
своя история, свое «время жизни»: периодически появляются новые, исчезают ста-
рые. И хотя некоторые из перечисленных ниже эх существуют уже около 10 лет,
вполне вероятно, что часть из них вы не застанете, когда подключитесь к FidoNet.
Свежий тематический эхо-лист, послуживший основой для данного справочника,
можно найти в эхе RU. ECHOMAIL и файл-эхе DDFECH.
Наименование эхо-конференции (так называемый эхотаг, например, SU.GE-
NERAL) является стандартным, по этой последовательности символов и следует
искать конференцию в FidoNet. В Internet конференции русскоязычной части
FidoNet можно найти по адресу:
http://www.dejanews.com
При этом следует учитывать, что конференцию в Internet можно найти толь-
ко в том случае, если она является межсетевой и проходит шлюз между FidoNet
и Internet.
Темы основных разделов списка выделены прописными буквами, например:
INTERNET И СЕТЕВЫЕ ТЕХНОЛОГИИ.
Всего в справочнике 33 основных раздела:
1. ТРАНСПОРТ: АВИАЦИЯ, АВТОМОБИЛИ, МОТОЦИКЛЫ, другие виды.
2. АВТОРСКИЙ: эхи авторов программ, поддержки Fido-софта.
3. АРМИЯ. МИЛИЦИЯ. ОРУЖИЕ. ОХРАННЫЕ СИСТЕМЫ. СПЕЦТЕХ-
НИКА.
4. ББС И FIDO: Fido-жизнь, альтернативные и локальные сети, АТС.
5. ВОЛШЕБСТВО. МАГИЯ. ФОКУСЫ.
6. ЕДА. НАПИТКИ: обсуждение вопросов, связанных с различными продук-
тами потребления.
7. ПРИРОДА. ЖИВОТНЫЙ И РАСТИТЕЛЬНЫЙ МИР.
8. ЖИЗНЬ (что такое счастье, как справляться с кризисами; другие ее прояв-
ления).
9. ИГРОВОЙ: компьютерные, некомпьютерные игры, эхи знатоков, интеллек-
туалов.
10. INTERNET И СЕТЕВЫЕ ТЕХНОЛОГИИ.
11. КЛУБНЫЙ: разговоры обо всем, клубы по интересам, любовь, одиночество.
12. КОММЕРЧЕСКИЙ: эхи объявлений и обмена, халява.
13. ЛОКАЛКИ: Москва, районы Москвы, Подмосковье, студенты, вузы, техни-
кумы, школы.
14. МУЗЫКАЛЬНЫЙ: музыкальные направления, фэн-клубы, музыкальное
творчество.
15. НАУЧНЫЙ: научные, околонаучные специализированные эхи.
16. НОВОСТИ. ОБСУЖДЕНИЕ НОВОСТЕЙ.
17. ОПЕРАЦИОННЫЕ СИСТЕМЫ. ОБОЛОЧКИ. ФИРМЫ-СОЗДАТЕЛИ ОС.
18. ПРЕДПРИНИМАТЕЛЬСТВО И ПРАВО.
19. ПРОГРАММИРОВАНИЕ.
20. ПУТЕШЕСТВИЯ. СТРАНОВЕДЕНИЕ. ТУРИЗМ.
21. РАБОТА.
22. РЕЛИГИИ. КУЛЬТЫ. АТЕИЗМ. МИРОВОЗЗРЕНЧЕСКИЕ ВОПРОСЫ.
ФИЛОСОФСКИЕ УСТАНОВКИ.
23. СЕКС ВО ВСЕХ ПРОЯВЛЕНИЯХ. АНТИСЕКС.
24. СЕМЬЯ. ДЕТИ. ДОМАШНЕЕ ОБРАЗОВАНИЕ. ШКОЛА.
25. СОЦИУМ: общество, политика.
26. СПОРТ.
27. СРЕДСТВА МАССОВОЙ ИНФОРМАЦИИ. МОДА. ТЕАТРЫ. ВЫСТАВ-
КИ. ФОТОГРАФИЯ. ТАТУ.
28. ТВОРЧЕСТВО. ЛИТЕРАТУРА. ИСКУССТВО. КУЛЬТУРА.
29. ТЕХНИЧЕСКИЙ: эхи о функционировании сети.
30. ТЕХНОЛОГИЧЕСКИЙ: изделия, права потребителя.
31. ЭМИГРАЦИЯ. ИММИГРАЦИЯ. ПРОЖИВАНИЕ В НЕТРАДИЦИОН-
НОЙ ОБСТАНОВКЕ.
32. ЮМОР.
33. ЯЗЫКОВОЙ: иностранные языки, лингвистика.
ТРАНСПОРТ: АВИАЦИЯ, АВТОМОБИЛИ,
МОТОЦИКЛЫ, другие виды
Автомобиль, автомобильная аппаратура, ремонт
автомобиля
МО. CARS - эха московских автомобилистов;
МО. CARS. AUDIO - все об автоаудиоаппаратуре;
МО. CARS . AZLK - все об автомобилях от АЗЛК;
МО. CARS . REPAIR - ремонт автомобилей;
RU. CARS. 4X4 - Offroad: 4x4 (для владельцев джипов);
RU. CARS . CHAINIK - вопросы начинающих;
RU. CARS. CUSTOM - переделка автомобилей;
RU. CARS. FROM. USA - автомобили из Америки;
RU. CARS. FORD - клуб любителей автомобилей «Форд»;
RU. CARS . FOREIGN - для владельцев иномарок;
RU. CARS . GAS - автомобили на газе;
RU. CARS’. LADA - автомобили ВАЗ;
RU. CARS. MOSCVICH - обсуждение автомобилей «Москвич»;
SU. CARS - основная автомобильная эха;
SU. CARS . BMW - все об автомобилях BMW.
Общественный транспорт
МО. PROEZDNOY - проездные и единые билеты в Москве;
МО. TRANSPORT - общественный транспорт;
RU. BUS - все об автобусах;
RU. RAILWAYS - все о железных дорогах;
RU. SUBWAY - все вопросы о метрополитене;
RU. TRAMWAY - не только о трамваях - обо всем.
Авиация, автомобильные трассы,
летательные аппараты, мотоциклы
МО. BIKE - все о мотоциклах;
RU. AVIA. TALKS - обсуждение авиационных тем;
RU. AVIATION - летательные аппараты и все, связанное с ними;
RU. МОТО - все, связанное с мотоциклами;
RU. ROAD - все об автомобильных дорогах.
АВТОРСКИЙ: эхи авторов программ,
поддержки Fido-софта
Антивирусная поддержка
ADINF. SUPPORT - об антивирусах ADinf/Dr.Web/Aidstest;
AVP. SUPPORT - Antiviral Toolkit Pro.
Программы BBS, терминальные программы:
BBSList, Maximus, PCBoard, РРЕ, Remote Access
BBSLIST. SUPPORT - BBSList-Beta и файл-листы;
RU. BBS . PCBOARD - все про PCBoard и PPE;
RU. TERMINATE - о программе Terminate;
SU.CBCS - все, что связано c BBS Maximus-CBCS;
SU. RA - вопросы использования BBS Remote Access;
TORNADO. SUPPORT - поддержка BBS-программы Tornado.
Мейлеры
BINK. PLUS - поддержка мейлера Bink/+;
BINK. PLUS. E - поддержка мейлера Bink/+ (англоязычная);
BRAKE' S. MAILER. SUPPORT - поддержка мейлера The Brake!;
RU. ARGUS - поддержкамейлера Argus (Win32 FidoNet Dialup/IP Mailer);
RU. GPMAIL - поддержка General Purpose Mailer;
T-MAIL. CHAINIK - вопросы начинающих пользователей T-Mail;
T-MAIL. NT. RUS - вопросы использования T-Mail для Windows NT;
T-MAIL. RU - обсуждение мейлера T-Mail.
Почтовые системы, редакторы
RU. FLEETSTREET - лучший в мире почтовый редактор;
RU. GOLDED - редактор сообщений GoldED;
RU. GOLDED. BETA - обсуждение бета-версий GoldED;
RU. LEXICON - текстовый процессор Лексикон;
RU. MULTI EDIT - все про Multiedit;
RU. PORTAL - почтовая система Portal Of Power;
RU. XENIA - почтовая система Xenia;
WINED. SUPPORT - поддержка редактора WinED-X;
Техническая поддержка, эхи разработчиков программного
обеспечения
GCREATE. SUPPORT - обсуждение программы Gcreate;
GROUP - разговоры разработчиков и пользователей программ Group;
GROUP. SOFTMARKET - анонсы новых программ от Group;
ITASM. SUPPORT - поддержка ITASM и других программ;
МО. BERKUT - конференция технической поддержки фирмы «Беркут»;
MNTRACK. SUPPORT - нетмейловый трекер MNTrack;
MULTILOG. SUPPORT - обсуждение программы Multilog;
QVIEW. SUPPORT - поддержка программы QView;
RAR. SUPPORT - общение пользователей архиватора RAR;
RU. IC SOFT - эха по продуктам фирмы IC;
RU. ACAD - разговоры о работе в AutoCAD-аналогах;
RU. ADV_FTNSOFT. INFO - конференция группы AFS;
RU. ADV—FTNSOFT. MI SC - поддержка AFS-продуктов;
RU. ADV—FTNSOFT. RKM - поддержка RKM;
RU. ASD-TRACK. SUPPORT - поддержка продуктов ASD-track;
RU. BEST - поддержка программ фирмы Intellect-Service;
RU. CRAZY. SUPPORT - программные продукты Кирилла Лебедева;
RU. CROSSTOOLS - обсуждение кросс-систем;
RU. CUBASE - поддержка программ CUBASE;
RU.D!Р. SOFTWARE - обсуждение программ DIP Group;
RU. DVMMAIL - обсуждение программ от Владимира Добрачева;
RU. FASTUUE - поддержка и новые версии FastUUE;
RU. FHMAIL - для пользователей FhMail;
RU. IPEX - техническая поддержка шрифтов Ipex MODEL;
RU. NETMGR - NetMgr и другие обработчики нетмейла;
RU. PNTNODE - поддержка проекта PNTNODE;
RU. YTALK32 . SUP - поддержка YTALK32 от Максима Подорова;
SU. HARDW. SUPPORT. ARVID - АРВИД (поддержка разработчиков);
SU. SOFTW - поддержка и разработка программ.
Файл- и эхо-процессоры
RU. ALLFIX - файл-эхопроцессор AllFix;
RU. ALLFIX. MAIL - поисковые файловые запросы к AllFix и его аналогам;
RU. ECHOPROCESSORS - обсуждение эхо-процессоров и т.п.;
RU. ECHOPROCESSORS . NICE. TOSSER - эха поддержки тоссера NiceTosser;
RU. FASTECHO - все о мэйл- и эхо-процессоре FastEcho;
RU. FASTFIX - обсуждение файл-эхопроцессора FastFIX;
RU. IMAIL - все о эхо-процессоре IMail;
RU.MNTIC - файл эхо-процессор MNTic;
RU. QECHO - обсуждение эхо-процессора QEecho;
RU. SQUISH - сквиш-формат базы и одноименный эхо-процессор;
RU. TICMANAGER - обсуждение файл-эхопроцессора TicManager.
Файл-эхи, поддержка файл-эх
EVIL.MP3 - эха поддержки файл эхи EVIL.MP3;
KHIMKI.MP3 . TALK - поддержка группы файл эх KHIMKI. MP3;
LEGEND.MP3 - поддержка файл-эхи LEGEND.MP3;
МО. MUS IC. MP3 - поддержка файл-эхи MUSIC .MP3;
PVT. MP3 - поддержка файл-эхи ALL .MUSIC .MP3;
RU . 3D . SUPPORT - поддержка файл-эх 3D . LW, 3D .МАХ и 3D . OTHER;
SU. ANNOUNCE. MP3 - анонсы Mp3 файл-эх;
SU. MUSIC . PICTURES - сопровождение XPICMUSIC.
Прочие программы
RU.FIPS - поинтовая система FIPS;
RU. FRIP - система автороутинга FRIP;
RU. FTN. WINSOFT - интегрированные FTN-программы для Windows;
RU. GNU - для обсуждения программ проекта Free Software Foundation;
RU. PCCTS - о программе Purdue Compiler-Construction Tool Set;
XSU. VENTAFAX. SUPPORT - программа VentaFax.
АРМИЯ, МИЛИЦИЯ, ОРУЖИЕ, ОХРАННЫЕ
СИСТЕМЫ, СПЕЦТЕХНИКА
Армия, милиция
RU. ARMY - вопросы, связанные с армией;
RU. ANTI-MENT - законные методы борьбы с «органами»;
RU. MILITIA - все о милиции и про милицию.
Оружие
RU.MISSILE - обсуждение современой ракетной техники;
RU. WEAPON - оружие: свойства и возможности;
RU. WEAPON. COLD - все о холодном оружии;
RU. WEAPON. HEAVY - все о тяжелом оружии.
Охранные системы, спецтехника
RU. GUARD - охранные системы;
RU. SPECIAL . TECHNICS - обсуждение спецтехники;
SU. SPY - тонкости шпионской работы.
BBS И FIDONET: Fido-жизнь,
альтернативные и локальные сети, АТС
АТС. Проблемы связи в Москве,
противостояние телефонным компаниям
МО. CONNECT - проблемы связи в Москве;
RU.ANTI .ATS - противостояние телефонным компаниям.
BBS-новости, обсуждение работы узлов
RU. BBSNEWS - новости BBS;
RU. BBSNEWS . TALK - обсуждения работы BBS и т.д.
Для начинающих
SU. CHAINIK - вопросы начинающих пользователей сети;
SU. CHAINIK. FAQ - FAQ на «околофидошные» темы;
SU. CHAINIK. GENERAL - вопросы новичков на любую тему и ответы на них.
Альтернативные компьютерные сети:
общая, адрес в сети, Искра-2
ISKRA.SYSOP - телефонная сеть Искра-2 и FidoNet;
МО. OTHERNET - все об альтернативных сетях Москвы;
RU. POINT. OTHERNET - адреса в альтернативных FTN-сетях.
Fido как культурное явление: история, мероприятия
FIDONET. HISTORY - вопросы истории FidoNet;
МО. BAR - элитные фидошные сборы;
МО. FIDOPOIKA - московская фидопойка;
МО. PARTY - организация фидошных тусовок;
МО. PARTY. CLUB - обсуждение мероприятий в Fido;
МО. POVREMENKA - FidoNet в условиях повременки;
RU. AUTOPILOT - автономная работа FTN-систем;
RU. FIDO&FSB - ФСБ в компьютерных сетях;
RU. FIDO-PICKUP - обсуждения Fido-знакомства с девушками;
RU. FIDO. CONFLICT - обсуждение сетевых конфликтов;
RU. FIDO . FOOTBALL - футбол И фидошники;
RU. FIDO. NEXTGEN - будущее FidoNet и FTN; '
RU. FIDONET. TODAY - как поживает Fido сегодня;
RU. FIDONEWS - FidoNews Russia Echo;
RU. POLICY - обсуждение Полиси FidoNet;
SPB. FIDO. PRESS - публикации о Fido и их обсуждение;
ZONE7 - обсуждение деталей реализации проекта Z7.
ВОЛШЕБСТВО, МАГИЯ, ФОКУСЫ
Иллюзия, миф, смерть, сон, фантазия
PVT. WORLD. OF. DREAM - фантазирование и его истоки;
RU. DEATH - поговорим о смерти;
RU. DREAM - о снах и сновидении;
RU. ILLUSION - иллюзия... сплошная иллюзия;
RU. LITURGICA - литургическое предание;
RU.MYTHOLOGY - «миф» означает «предание», «сказание».
Магия
RU.MAGIC - альтернативная магическая эха;
SU. MAGIC - разговоры о магии и магическая помощь;
SU. SIMORON - школа волшебников «Симорон».
ЕДА, НАПИТКИ: обсуждение вопросов,
связанных с различными продуктами
потребления
Пельмени
МО. PELMENI - пельмени и все, связанное с ними.
Напитки алкогольные
RU. GOOD. DRINK - достоинства алкогольных напитков;
RU.WINE - алкогольные напитки;
SU. ALKO - спиртные напитки.
Напитки безалкогольные
PEPSI - о безалкогольных напитках;
RU. COCA-COLA - разговоры о кока-коле;
RU. TEAM .'KEFIR - клуб любителей кефира.
Антиалкогольная кампания, вегетарианство, курение, яд
RU. ANTIALCOHOL - для всех противников спиртного;
RU. POISON - яды иФротивоядия - все о них;
RU. TOBACCO - курение и все о нем;
RU. VEGETARIAN - вегетарианство.
ПРИРОДА, ЖИВОТНЫЙ И РАСТИТЕЛЬНЫЙ МИР
Аквариум, кошки, лошади, порода собак «афган»,
другие животные
PVT. CAT. CLUB - разговоры о котах и кошках;
PVT. DOG. AFGAN - порода собак «афган»;
PVT. HORSES . CLUB - клуб любителей лошадей;
RU. AQUARIA - аквариум и террариум;
RU. CAT&DOG - для тех, кто подобрал домашнее животное;
RU. HORSE - лошади и все, связанное с ними;
RUS . PETS - о домашних животных;
RUS . PETS . EXOTIC - для любителей животных.
Лес, растения
RU.LES - лес как он есть;
RUS . FLORA - растительный мир.
ЖИЗНЬ ЧЕЛОВЕКА (что такое счастье,
как справляться с кризисами;
другие ее проявления)
Обеспечение безопасности, образ жизни инвалидов,
жизненные проблемы. Советы, помощь
HELP! - информация о спасении жизни человека;
МО. ADVICE - вопросы и ответы;
RU. ABOUT .LIFE - разговоры про жизнь;
RU. INVALIFE - все о жизни инвалидов в России и СНГ;
МО. KRIK - обсуждение работы службы КРИК;
RU. PROBLEM - о жизненных проблемах;
SURVIVAL. GUIDE - личная безопасность и выживание;
SU. SPASATEL - «спасательские» дела.
Любовь, одиночество, романтика
RU. FEELINGS - чувства и взаимоотношения;
RU. LOVE - все, что тебе нужно, - это любовь;
RU. LOVELAND - Лавлэнд. Страна Любви;
RU. ODINOKOE . SERDCE - клуб одиноких сердец;
RU. ROMANTIC - любовь и романтика;
ХРЕНОВО. МНЕ - о том, как вам плохо.
ИГРОВОЙ МИР:
компьютерные, некомпьютерные игры,
эхи знатоков, интеллектуалов
Компьютерные игры (общие эхи)
RU. ANIME. GAMES - приставочные и компьютерные игры из Японии;
RU . GAME. BLIZZARD - игры «Blizzard games»;
RU. GAME . CDROM - игры на CD-ROM;
RU. GAME. EMULATOR - обсуждения эмуляторных игр;
RU. GAME. WORMS - обсуждение игр про любых червей;
SU. GAME - компьютерные игры, общая эха;
SU.GAME.MULTIPLAYER - многопользовательские компьютерные игры;
SU. WIN9 5 . GAMES - игры для/под Windows 95.
Компьютерные Action-игры
RU. GAME. DOOM - все об игре DOOM и ей подобных;
RU. GAME. DUKE - обсуждение игры Duke Nukem3D;
RU. GAME. FORTRESS - обсуждение игры Team Fortress;
RU. GAME. FROZEN - обсуждение, доработка (русификация) 3D action-игр;
RU. GAME. HALF-LIFE - игры Half-Life и TeamFortress II;
RU. GAME. QUAKE - обсуждение Quake;
RU. GAME. UNREAL - обсуждение Unreal.
Компьютерные игры-квесты (общие эхи)
RU. GAME. QUEST - разговоры об играх стиля «квест»;
SU. GAME. QUEST. TALKS - обсуждение игр стиля «квест».
Ролевые компьютерные игры
RU. GAME. ADOM - игра ADOM NetHack и другие подобные RPG;
RU. GAME. ALLODS - для фэнов мира аллодов;
RU. GAME. DIABLO - игры Diablo/Hellfire/Diablo II;
RU. GAME. FALLOUT - игры, подобные игре Fallout;
RU. GAME. RPG - компьютерные ролевые игры.
Игры-симуляторы
RU. GAME. FLIGHT - компьютерные «леталки»;
RU. GAME. FLIGHT. DYNAMIX - симуляторы фирмы Dynamix;
RU. SPORT. GAMES - спортивные компьютерные игры;
SU. GAME. AUTO - автомобильные игры. .
Игры-стратегии
RU. GAME. HEROES - игра «Heroes Of Might & Magic»;
RU. GAME. STRATEGY - пошаговые стратегии;
RU. GAME. STRATEGY. RT - Real-Time стратегия;
RU. GAME. VANGERS - обсуждение игры «Vangers»;
SU. GAME. STRATEGY - обсуждение стратегических игр.
Игры по сети
RU. ALKASHI. OFFLINE - поиграем прямо в эхе;
RU. GAME. ACTION. INTERNET - игры по сети Internet;
RU. GAME. MODEM - игры через модем;
RU. GAME. MUD - многопользовательские ролевые игры в глобальных сетях (WAN);
RU. GAME. MUD. GALAXY - MUD-игра «Galaxy»;
RU. GAME. MUD. RUSSIAN MUD - игры на русском языке;
RU. STARS ’ - обсуждение игры «Stars!»;
VGA. PLANETS - для любителей «VGA Planets».
Тетрис
RU.TETRIS - тетрисоподобные игры и соревнования.
Некомпьютерные ролевые настольные игры
МО. D&D. AD&D - игра «Adv. Dungeons & Dragons» без компьютера;
RU. RPGT. CYBERPUNK - игры в стиле dark future;
RU. RPGT. GAMING - играть здесь;
RU. RPGT. GURPS - настольные ролевые игры no GURPS;
RU. RPGT. OTHER - о настольных ролевых играх.
Некомпьютерные ролевые полевые игры
RU. RPG. BAZAR - разговоры вокруг ролевых игр;
RU. RPG. COMBAT - боевая составляющая ролевых игр;
RU. RPG. DUNE - ролевая игра «Дюна-99»;
RU. RPG. MYSTERIAL - мистериальные LARPG;
RU. RPG. STRUGATSKIE - игры по мотивам произведений писателей-фантастов
Аркадия и Бориса Стругацких;
RU. RPG. TEXT - ролевые игры. Тексты и зарисовки.
Другие некомпьютерные ролевые игры
PVT. NIICHAVO - для общения сотрудников НИИЧАВО;
RU. RPGT. PLAY - ролевые игры по переписке.
Прочие некомпьютерные игры
МО. ZNATOK - общение московских знатоков;
RU. CASINO - казино и азартные игры;
RU. CROSSWORD - отгадывание кроссвордов;
RU. DESKS . GAMES - настольные игры;
RU. GAME . BRIDGE - для любителей игры «бридж»;
RU. GAME. РВМ - игры по почте (Play By Mail);
RU. GOLOVOLOMKA - головоломки, шарады, ребусы, и т.п.;
RU. INTELLECTUAL . GAMES - интеллектуальные игры;
RU. MAGIC. THE. GATHERING - карточная игра «Magic The Gathering»;
RU. PAINTBALL - спортивная игра «PaintBall»;
RU. ZNATOK - любителям игр «Что? Где? Когда?» и ее аналогов.
Смешанные игры, содержащие компьютерные
и некомпьютерные составляющие
RU. BABYLON5 . GAME - ролевая игра по телесериалу «Вавилон 5»;
RU. BATTLETECH - для любителей «Battletech Universe»;
RU. STAR. WARS. GAMES - звездные войны в играх.
INTERNET И СЕТЕВЫЕ ТЕХНОЛОГИИ
Internet (общие эхи)
RU. COMPUTER. CLUB - компьютерные клубы;
RU. INTERNET - крупнейшая сеть мира;
RU. INTERNET.BUSINESS - бизнес Bdnternet;
RU. INTERNET. CAFE - посидим в Internet-кафе?;
RU. INTERNET. CHAINIK - «чайникам» об Internet;
RU. INTERNET. CONNECTION - СВЯЗЬ C Internet;
RU. INTERNET. FILTERED - избранное об Internet;
RU. INTERNET. HALYAVA - здесь вся халява в Internet;
RU. INTERNET. HALYAVA. HTML - халява в html-формате;
RU. INTERNET. IRC - обсуждение Internet Relay Chat (IRC);
RU. INTERNET. MONEY - деньги в Internet;
RU. INTERNET. MOSCOW - провайдеры и проекты в сети;
RU. INTERNET. NETSCAPE - Web-браузеры от Netscape;
RU. INTERNET. PROVIDER - все о провайдерах Internet;
RU. INTERNET. SEARCH - как искать и найти в Internet;
RU. INTERNET. SOFT - обсуждение софта для Internet;
RU. INTERNET . TECHNOLOGY - технологии Internet;
RU . INTERNET . WWW - WWW и около;
RU. INTERNET . WWW. NEWS - анонсы Web-узлов;
RU. IP. EXCHANGE - поиск программ в Internet;
RU. UUCP - протокол UUCP и off-line доступ в Internet;
RU. WWW. FAVORITES - заслуживающие внимания WWW-сайты.
Технологии Internet и сети
МО. LAN. CONSTRUCTION - построение локальных сетей;
RU. FIDO. INTERNET - связь FidoNet и Internet;
RU. HOME. LAN - домашние локальные сети;
RU. INTRANET - технологии Internet;
RU.MIS - информационные технологии в организации;
RU. NET. HARD - оборудование для WAN/LAN;
RU. NET. SOFT - сетевой софт;
RU. NET. TECH - сетевые технологии;
RU. NET. UNION - организационные проекты сетевиков;
RU. NETWORKS - сети и гейты: новые технологии;
RU. NMS - обсуждение систем управления сетью (Network Management Systems);
RU. WIRELESS . NET - беспроводные сети;
SU. HARDW. PC. NET - сети компьютеров IBM PC;
SU. NET - локальные сети (межсетевая эха);
SU. WIN9 5 . NETW - локальные сети под Windows 95;
UU2 - программа UU2 Дмитрия Завалишина для создания шлюза Internet-
FidoNet.
КЛУБНЫЙ: разговоры обо всем,
клубы по интересам, любовь, одиночество
Обсуждение личных проблем, общение (общие эхи)
СТРАННОЕ. МЕСТО - здесь можно все, но вежливо;
LAYDER.FREEDOM - жизнь... секс... юмор;
LOTSMAN. LOCAL - разговоры детей и взрослых обо всем;
МО. GOOD. PEOPLE. TALKS - общение хороших людей;
МО. POSIDELKI - посиделки друзей - и этим все сказано;
МО. TALK - московский эхо-клуб;
РЕНЕССАНС - свободная беседа свободных людей;
PVT. CLUB - шутки, каламбуры, анекдоты, забавные фразы;
PVT .FLIRT - искусство флирта;
PVT. FREEDOM - свободные мнения, комментарии, интервью;
RU. CASTLE. СМ - исключительно вежливые разговоры;
RU. FASTUUE. TALK - разговоры обо всем;
RU. KEEN - для личного общения;
RU. KROVATKA - любовь, секс, флирт, знакомства и чат;
RU. REAL .LIFE - беседы обо всем, что вам интересно;
SU. GENERAL - почти обо всём;
SU.NAEZD - дружеские «наезды» на окружающих;
SU. TALKS - разговоры обо всем.
Клубы и беседы
HELL. FIRE. CLUB - клуб адского огня;
МО. МАКЕТ. TALKS - конференция поддержки сети MaketNet;
PVT. GIRLS - женский клуб;
PVT. KAM-NH - огонь камина греет душу;
PVT. МАХ. CLUB - добро пожаловать в Макс-клуб;
PVT. MOUSE . CLUB - о «мышах» и людях;
PVT. NIMNULL - интеллектуальное общение друзей;
PVT. RUSAR. TALKS - эха интеллектуалов и острословов;
PVT. SOVA. CLUB - «совы», или кому ночью не спится;
RU. BACHELORS - эха принципиальных холостяков;
RU. BARDAK - Бардак Господ Гусаров;
RU. BEER - пейте пиво пенное!;
RU. COFFEE . CLUB - клуб интеллектуалов;
RU. FIGHT. FOR. PEACE - приведет ли к войне драка за мир;
RU. GAMENET - разговоры пользователей сети GameNet;
RU. HATE - клуб ненавидящих;
RU. MACHO - мужчина - лидер, женщина - ведомая;
RU. MIXED. ALCOHOL - алкогольные коктейли, байки, разговоры;
RU. PAGERS . OPERATOR - общение операторов пэйджинговых компаний;
RU. TEAM - создание, поиск и обсуждение тимов (team);
RU. VIRTUAL .LIFE - виртуальное общение: добро иль зло;
RU. WARHAMMER. CLUB - Вархаммер-клуб;
SU. BOOKS. CLEVER - литературные разговоры эстетов;
SU. GAZ . LINK - конференция линков на Газсвязи (телефонной сети Газпром);
SU. MN. CULTURE-LIFE - клуб MN (культура);
SU.MN. POLITICS - клуб MN (политика);
SU.MN. SOCIETY - клуб MN (общество);
SU. RENDER. PROFI - элитный клуб читателей SU. RENDER;
SU. UNDERGROUND - разговоры про андерграунд-группы;
ТАВЕРНА - беседы за кружкой эля.
Клуб коллекционеров, нумизматика
RU. COLLECTORS - клуб коллекционеров;
RU. NUMISMATICS - нумизматика и все, связанное с нею.
Личностные локалки ББС Бочарова, Экслера,
«Белый медведь»
BOCHAROFF . UNPLUGGED - фильтрация бреда;
BOCHAROFF. MUST. DIE - радикальный юмор и антиюмор;
PVT. EXLER - татаро-еврейское иго кошерных птеродактилей;
PVT. EXLER. FILTERED - избранное из PVT. EXLER (только для чтения!);
WHITE. BEAR. CLUB - локалка ББС «Белый Медведь» (White Bear BBS).
КОММЕРЧЕСКИЙ: эхи объявлений и обмена,
халява
Общие эхи
МО. WANTED - Где? Что? Почем?;
PVT. ЕХСН. OTHER - купля-продажа всего остального, что не покрывается
специализированными PVT. ЕХСН. * эхами;
PVT. ЕХСН. SERVICE - поиск и предоставление услуг.
Автомобили, автотехника, мототехника, мотоциклы
МОТО. MAGAZIN - купля-продажа мотоциклов и запчастей к ним;
PVT. CAR. ЕХСН - купля-продажа автомобилей и запчастей к ним;
PVT. ЕХСН. CARS - продажа автомобилей и запчастей к ним.
Компьютеры, ноутбуки
PVT. ЕХСН. COMPUTER - купля-продажа компьютеров и т.п.;
PVT. ЕХСН. PC - купля-продажа компьютеров и ноутбуков.
Музыка, кино, рынок «Горбушка», тексты песен,
аудио- и видеотехника, MP3
МО. GORBUSHKA - все об этом музыкальном рынке;
МО. MUSIC . EXCHANGE - околомузыкальная возня, обмен, купля и продажа;
МО. TAGANKA .MP3 - новая музыка на Таганке;
PVT. ЕХСН. AUDIOVIDEO - обмен аудио- и видеотехники;
PVT. ЕХСН. CD - купля-продажа любых компакт-дисков;
RU. MP3 . WANTED - поиск файлов в формате MP3;
RU. MUSIC. WANTED - поиск музыкальных произведений;
RU. VIDEO. ЕХСН - обмен, купля и продажа видеофильмов;
SU. MUSIC. LYRICS - поиск и публикация текстов песен.
Софт
МО. LEGAL. SOFT - легальная купля и продажа софта;
МО. MITINKA - все о радиорынке в Митине;
МО. SOFTEXCHANGE - поиск и предложение софта, информации;
МО. SOFTEXCHANGE. ARVID - обмен арвидовскими архивами;
МО. SOFTMARKET - продажа и покупка программных разработок;
RU. WINDOWS . NT. WANTED - поиск и обмен программ для Windows NT;
SU. FILEECHO - поиск программ и объявления о релизах;
SU. OS2 . WANTED - поиск и предложения программ для OS/2;
SU. WINDOWS . WANTED - поиск и обмен программ для MS Windows.
Халява
МО. HALYAVA - обсуждение халявы;
МО . HALYAVA. WANTED - поиск халявы;
МО. PARTY. HALYAVA - где на халяву оторваться;
RU. HALYAVA - халява везде и всюду.
Игры, дом (квартиры), книги, люди, радиодетали,
рефераты, сотовая телефония
МО. BOOKS . WANTED - поиск и продажа книг;
PVT. ЕХСН. CELLULAR - обмен всем, что совместимо с сотовой телефонией;
PVT. ЕХСН. APARTMENT - квартиры - народу;
PVT. ЕХСН. СОММ - купля и продажа средств коммуникации;
PVT. ЕХСН. EL. PARTS - покупка и продажа радиодеталей;
RU. REFERAT - различные услуги для студентов;
RU. SEARCH . PEOPLE - поиск людей;
SU. GAME . TRADE - поиск, обмен и торговля компьютерными играми;
SU. REFERAT - обсуждение и поиск рефератов.
ЛОКАЛКИ: Москва, районы Москвы,
Подмосковье, студенты, вузы, школы
Москва (общие)
МОСКВА - события и памятные места;
RU. MOSCOW - город Москва в вопросах и ответах.
Районы города Москвы
МО. ВАВКА - Бабушкинский район и его окрестности;
МО.BELYAEVO - Беляевская «локалка».
Подмосковье (общие эхи)
RU. PODMOSKOVIE. TALKS - подмосковные разговоры;
МО. ZGRAD - разговоры на Зеленоградские темы;
МО. ZHUKOVSKY - город Жуковский;
PODOLSK. TALK - разговоры «подольских рабочих»;
PVT. LYUBERTSY - Люберы;
PVT. ODINTSOVO - все об Одинцове и окрестностях;
RU. KOGALYM - эха жителей Когалыма;
RU. KOROLEV - эха для жителей Королева;
TROITSK.TALK - разговоры в городе Троицке.
Студенты (общие эхи)
RU. STUDENT. TALKS - студенческий фольклор;
SU. STUDENT - для общения студентов;
MADI. TU - эха МАДИ;
МО. BABY. MGSU - эха МГСУ;
МО. GANG - эха для студентов ГАНГ;
МО. GAU - кто не может учить - управляет;
МО. МАЕР - для студентов МАЭП;
МО. MAI - для студентов МАИ;
МО. MAMI - все об институте МАМИ;
MO.MBI - общение студентов МБИ;
МО. MEDIC. STUDENT - для московских студентов-медиков;
MO.MEI - для студентов и преподавателей МЭИ;
МО. MEPHI - есть ли жизнь в МИФИ?;
MO.MGALP - разговоры студентов МГАЛП;
MO.MGAPI - для студентов МГАПИ;
MO.MGATU - для студентов МГАТУ;
МО . MGGA. TALK - МГГА;
MO.MGGU - разговоры студентов МГГУ;
МО.MGIMO - для студентов и преподавателей МГИМО;
МО.MGIU - для фидошников МГИУ;
МО. MGUP - для учащихся в МГУП;
МО. MGUPP - МГУПП;
МО. MIEM. TALK - МИЭМ-ные разговоры;
МО. MIIGAIK - эха для студентов МИИГАиК;
MO.MIREA - для студентов и преподавателей МИРЭА;
МО .MISIS - разговоры студентов МИСиС;
МО. MITXT - эхо-конференция института МИТХТ;
МО. MKIP - для студентов МКИП;
МО. MSOU - разговоры студентов и преподавателей МГОУ;
МО. MSU. PHYS - разговоры московских физиков;
MO.MSUC - МГУК;
МО. MTUSI - про МТУСИ;
МО. PLESHKA - жизнь студентов РЭА;
МО. PHYSTECH - эхо-конференция МФТИ;
МО. PXTY - для разговоров студентов РХТУ (МХТИ);
МО. RSUH - для студентов РГГУ;
МО. RUDN - эха для студентов РУДН;
МО. STANK IN - для студентов СТАН КИН;
МО. UNIVERSITY - МГУ им. М.В. Ломоносова;
MSTU. TALKS - МГТУ имени Баумана;
PVT. MIEM. TALK - для отключенных от МО .MIEM. TALK;
PVT.MIES - МЭСИ;
RU. GANG - официальная эха ГАНГ им И.М. Губкина;
RU.MIIT - для общения студентов МИИТ;
RU. SGU - Современный гуманитарный университет;
SU.HSE - эха ВШЭ.
Школьники, подростки; школы, техникумы
MO.AESC - ФМШ #18 при МГУ;
МО. ММК - для студентов ММ К;
МО. SCHOOL .799 - общение народа из школы № 799 Москвы;
RU. TEENAGERS - общение молодежи.
МУЗЫКАЛЬНЫЙ: музыкальные направления,
фэн-клубы, музыкальное творчество
Общие эхи
IV.MUSIC - все о музыке;
PVT. THE_LIFE_&_REAL_MUSIC - о музыке, роке и жизни;
RU. INTERLINK. ESSAY - творчество рок-групп;
SU.MUSIC - музыка.
Музыкальный шоу-бизнес, лейблы, «Утекай-звукозапись»
RU. D J - музыкальный шоу-бизнес;
RU.UTEKAY - «Мумий Тролль» и «Утекай-звукозапись».
Создание музыки, сочинение песен, музыкальные
форматы
GUITAR. SONGS - тексты песен с аккордами;
GUITAR. SONGS . FILTERED - песни из GUITAR. SONGS (только для чтения!);
PVT. SOUND. PRO - проблемы студийной звукозаписи;
RU. CAKEWALK - создание миди-музыки в Cakewalk;
RU. GUITAR - гитара и все, связанное с ней;
RU. DJ. PC - эха, посвященная Dj-ингу на PC;
RU. MIDI - все о музыке в формате Midi;
RU. STRACK - ScreamTracker и прочие музыкальные эксперименты;
RU. ТЕКСТА - напиши свою песню;
SU. KSP. TECH - технические аспекты КСП;
SU. KSP. TEXTS - тексты и аккорды песен КСП;
SU. MUSIC . DRUMS - все об ударных инструментах;
SU. MUSIC . CREATION - как делать музыку
Стили, направления, музыкальные тусовки
HIPPY. TALKS - хиппи и все, связанное с ними;
LEARNING.ТО. SWIM - поддержка альтернативного движения «Учитесь пла-
вать»;
МО. NEFORMAL. CLUB - жизнь московских неформалов;
МО. BRAKEDANCE - стиль танцев брейк-данс;
PVT. METAL. CLUB - о «металлической» культуре;
PVT . METAL . CLUB. SUPPORT - поддержка клуба «металлистов»;
RU. BLUES - блюз;
RU.HIP-HOP - все о хип-хоп культуре;
RU. MUSIC . DRUM&BASS - Jungle/Drum’n’Bass и все подобное;
RU. MUSIC . ETHNIC - беседы об этнической музыке;
RU. PROGRESSIVE - все о прогрессив-культуре;
RU. PSYCHEDELIC - все о транс-музыке;
RU. ROCK. CLUB - обсуждение классической рок-музыки;
RU. ROCKABILLY - обсуждение музыки в стиле «рокабилли»;
SPB . RUSSIAN. ROCK - русский рок;
SU. CULTURE . UNDERGROUND - андеграундная культура;
SU. DA_BOOGE_CREW - все о брейке;
SU. KSP - авторская и самодеятельная песня;
. SU. MUSIC . ALTER&PUNK - альтернатива и панк-рок;
SU. MUSIC . ART . ROCK - арт-рок;
SU. MUSIC . CLASSIC - обсуждение классической музыки;
SU.MUSIC.GOTHIC - дискуссия о музыкальных стилях gothic rock и gothic
ambitent;
SU. MUSIC . JAZZ - джаз;
SU. MUSIC . HEAVY&DEATH - музыка в стиле «тяжелый металл»;
SU.MUSIC. LEGION - экстремальная музыка;
SU. MUS IC .METAL - «металл» и близкие стили;
SU. MUSIC. POP - танцевальная и коммерческая музыка;
SU. MUS IC . RAP - о рэпе;
SU. MUSIC . SOUNDTRACK - обсуждение саундтрэков к фильмам;
SU. MUSIC. TECHNO - звуки в стиле техно;
SU. RUSSIAN. ROCK - обсуждение русского рока.
Фэн-клубы, эхи, специализированные
по определенным исполнителям
BONG - «Depeche Mode» и все, связанное с ним;
KWACHI. PRILETELI - все о группе «Тайм-аут»;
МО. BLUSYS_MODTALK - клуб любителей Дитера Болена;
МО. METAL ICA - для фэнов heavy metal;
PVT. MELODIC . METAL - клуб любителей «Helloween&Co.»;
ROZENBAUM. DA. RU - поддержка сайтов о Розенбауме;
RU. BEATLE . CLUB - клуб любителей «The Beatles»;
RU. DAVID. BOWIE - жизнь и творчество Дэвида Боуи;
RU. DPG - Death Power Group - будущее стиля техно;
RU. DURAN-DURAN. FANS - все о группе «Duran Duran»;
RU. KREM - все о рок-группе «Крематорий»;
RU. MUMIY. TROLL - тусовка фэнов группы «Мумий Тролль»;
RU.MUSIC. AGATA. KRISTI - рок-группа «Агата Кристи»;
RU. MUSIC .ALISA - эха для «алисоманов»;
RU. MUSIC .ARIA - обсуждение рок-группы «Ария»;
RU. MUSIC. DDT - обсуждение российской рок-группы «ДДТ»;
RU. MUSIC. HANDSUP - обсуждение группы «Руки вверх!»;
RU.MUSIC. К&J - про группу «Король и Шут»;
RU. MUSIC. LAC RI МО SA - обсуждение группы «Lacrimosa»;
RU.MUSIC.MIXEY&JUMANGEE - «Михей и Джуманджи»;
RU. MUSIC . NIRVANA - разговоры о группе «NIRVANA»;
RU. RAMMSTEIN - все о «Rammstein»;
RU. MUSIC . SCORPIONS - творчество группы «Scorpions»;
RU. MYLENE. CLUB - для поклонников Милен Фармер;
RU.NAUTILUS - про рок-группу «Наутилус Помпилиус»;
RU. OFFSPRING - все об группе «Offspring»;
RU. PINK. FLOYD - все о группе «Pink Floyd»;
RU. SECTOR_GAZA. ETC - «Сектор газа» и им подобные;
RU. SPICE . GIRLS - о группе «Spice girls»;
RU. VYSOTSKY - творчество Владимира Высоцкого;
SU. HANSON - клуб любителей группы «Hanson»;
SU. KALINOV- MOST - про группу «Калинов мост»;
SU. MAIDEN - обсуждение группы «Iron Maidon»;
SU.MANOWAR - обсуждение группы «Manowar»;
SU.MUSIC.MICHAEL__JACKSON. MJ - все о Майкле Джексоне;
SU.MUSIC. PRODIGY - творчество группы «The Prodigy»;
SU. QUEEN - клуб любителей группы «Queen».
НАУЧНЫЙ: научные, околонаучные,
специализированные эхи
Аномальные явления, необъяснимое, непознанное, НЛО
RU. UFO - НЛО и необъяснимые явления;
RU. UFO. TALKS - разговоры о НЛО и необъяснимом;
RU. UFO. THEORY - гипотезы об аномальных явлениях.
Археология, биология, ветеринария, геология, медицина,
палеонтология, химия
RU. BIOLOGY - биология и палеонтология;
RU. BIOMECH - биомеханика и смежные с ней области;
RU.BIOTECH - моральные аспекты клонирования и т.п.;
RU. CHEMISTRY.UNLIMITED - химия без границ;
RU. GEOLOGY - все о геологии;
RU.MEDIC . PROFY - вопросы лечения различных заболеваний;
RU. PHARMACY - фармацевтическая наука и практика;
RU. SEXUAL. DIFFERENCE - половое многообразие;
RU. VETERINARY - ветеринария;
SU. AN&CR. CARE - для анестезиологов-реаниматологов;
SU. ARCHAEOLOGY - обсуждение проблем археологии;
SU.MEDIC - медицина, проблемы и достижения;
SU. PALEONTOLOGY - палеонтология и эволюция;
SU. SCIENCE . CHEMISTRY - все о химии.
Астрономия, космонавтика, математика, физика,
энергетика
МО. PHYSICS - все о физике и обо всем, что с ней связано;
PVT. MOON - прикладная селенология;
RU. CYBORG - достижения киборгизации;
RU. MATH - математическая эха;
RU. METALLURGY - все о металлургии;
RU. NANOTECH - эха о нанотехнологии;
RU.NUCLEAR - проблемы ядерной физики и энергетики;
RU. SPACE - космическое пространство и орбитальные станции;
SU.ASTRONOMY - профессиональная и любительская астрономия;
SU. ENERGETIC - проблемы энергетики;
SU. HITECH - высокие технологии.
История: общие вопросы, битвы, боевые корабли, войны,
фальсификация истории
RU.MILITARY - войны и военная история;
RU. MILITARY. NAVY - о морских битвах и боевых кораблях;
RU. WORLD. WAR .II- история Второй мировой войны;
SU. HISTORY - вопросы истории;
SU.HISTORY.REVISIONS - фальсификации истории.
Менеджмент, экономика
МО. ECONOMICS - экономика и экономисты;
RU. MANAGER - обсуждение проблем управления.
Психология, социология, философия
RU. GREGORY. KLIMOV - проблемы высшей социологии;
RU. NLP - программисты душ. Хакерам не входить!;
RU. PSYCHOLOGY - психология;
RU. PSYCHOLOGY . PROFY - психология о психологии;
SU. PHILOSOPHY - философия.
НОВОСТИ, ОБСУЖДЕНИЕ НОВОСТЕЙ
Новости, обсуждение
PVT. NEWSPAPER - информация из газет и для газет;
RU. NEWS - свежие новости обо всем;
RU. NEWS . TALK - обсуждение новостей из RU. NEWS.
Компьютерные новости
1072 . COMPNEWS - новости компьютерного мира (только для чтения!);
1072. COMPNEWS . TALK - обсуждение компьютерных новостей;
RU. GAME. NEWS - новости компьютерных игр;
RU. WINDOWS . NT. NEWS - новости Windows NT;
SU. GAME . NEWS - игровые новости;
SU. WIN9 5 . NEWS - новости и анонсы мира Windows95.
Новости астрономии, «Времечко», погода в Москве,
политика
МО. WEATHER - погода и климат в Москве;
RU. DJATLOV - postnews программы ATV «Времечко»;
RU . SAT. TV. GUIDE - анонсы спутниковой информации;
RU. SPACE . NEWS - новости астрономии и космонавтики;
SU. POL.NEWS - политические новости.
ОПЕРАЦИОННЫЕ СИСТЕМЫ, ОБОЛОЧКИ,
ФИРМЫ - СОЗДАТЕЛИ ОС
Выбор, инсталляция, несколько ОС на одном компьютере,
сравнение ОС (общие эхи)
RU. MULTIOS . CONFIG - много ОС на одном компьютере;
RU. OS . CHANGE - выбор операционной системы;
RU. OS . CMP - дискуссия о сравнении различных операционных систем;
RU. OS. SETUP - проблемы инсталляции ОС.
Операционные системы MS DOS, MS Windows
(Windows 95/98, Windows NT)
RU. DOS - работа в MS DOS;
RU. SEX. WIN9 5 - секс c Windows 95;
RU. WINDOWS . NT - использование Windows NT;
RU. WINDOWS . NT. ADMIN - администрирование NT;
RU. WINDOWS . NT. BACKOFFICE - Windows NT и BackOffice;
RU. WINDOWS . NT. BETA - бета-версии Windows NT;
RU. WINDOWS . NT. CHAINIK - вопросы начинающих no NT;
RU. WINDOWS . NT. FAQ - FAQ-лист no Windows NT;
RU. WINDOWS. NT. FIDO - FidoNet и Windows NT;
RU. WINDOWS. NT. HARDWARE - аппаратное обеспечение и Windows NT;
RU. WINDOWS . NT. HATCH - поддержка файл эх no Windows NT;
RU. WINDOWS . NT. INTERNET - Windows NT и работа в WAN;
RU. WINDOWS . NT. UG - российская группа пользователей Windows NT;
SU.WIN95 - общие вопросы no Windows 95;
SU. WIN9 5 . CHAINIK - помощь начинающим no Windows 95;
SU. WIN9 5 . COMM - коммуникации в Windows 95;
SU. WIN9 5 . FAQ - FAQ no Windows 95;
SU. WIN9 5 . HARDW - аппаратное обеспечение и Windows 95;
SU. WIN9 5 . RUS__TEAM - эха Russian Team Windows 95;
SU. WIN95 . SOFTW - программное обеспечение Windows 95;
SU. WINDOWS - общие вопросы MS Windows.
Операционная система OS/2
SU.OS2 - общая конференция по OS/2;
SU. OS2 . APPS - прикладные программы для OS/2;
SU. OS2 . СОММ - коммуникации и сети в среде OS/2;
SU. OS2 . DRV - драйвера устройств для OS/2;
SU. OS2 . FAQ - FAQ по OS/2 (только для чтения!);
SU. 0S2 . FAQ. D - обсуждение FAQ по OS/2;
SU.OS2 .MARGINAL - косвенно относящиеся к OS/2 разговоры;
SU. OS2 . SRC - исходные тексты и фрагменты программ;
SU. OS2 . TEAM - Team OS/2 в Fido7.
Операционная система UNIX и ее клоны
RU. UNIX. AIX - операционная система IBM AIX;
RU. UNIX. BSD - BSD-подобные юниксы;
RU. UNIX. SOLARIS - операционная система Solaris;
DIG. LINUX - дайджест эх, посвященных ОС Linux;
RU. LINUX - операционная система Linux;
RU. LINUX. CHAINIK - Linux для начинающих.
Прочие ОС. Обсуждение BeOS, фирмы Microsoft, Qnx
RU. QNX - самая маленькая ОС в мире;
SU. BEOS - операционная система BeOS;
SU. MICROSOFT. TALK - дискуссии вокруг Microsoft.
Программы-оболочки (shell), файловые менеджеры
FAR. SUPPORT - общение пользователей файл-менеджера FAR;
RU. SHELL - обсуждение программ-оболочек (shell);
RU. SHELL . DN - поддержка программы Dos Navigator;
RU. VC - обсуждение программы Volkov Commander.
ПРЕДПРИНИМАТЕЛЬСТВО И ПРАВО
Право (общие эхи)
PVT. LAW - юридические вопросы;
SU. CIVIL_LAW - обсуждение законодательства;
SU. HUMAN. RIGHTS - эха по правам человека.
Предпринимательство и право
RU. ANTI-NALOGI - защита от фискальных органов;
RU. ARBITRAGE - защита прав предпринимателей.
Предпринимательство
PVT. FOREX - все о валютном рынке Forex;
RU. ACCOUNTING - проблемы бухгатерского учета в РФ;
RU. ADVERTISEMENT - рекламная деятельность;
RU. BANK_TECHNOLOGY - автоматизация банков;
RU. PLASTIC . CARDS - пластиковые карточки;
RU. VENTURE - предпринимательство и сопутствующие проблемы;
SU. PD&CO - предпринимательская деятельность и коммерция.
ПРОГРАММИРОВАНИЕ
Документация, компиляторы, интерпретаторы,
исходные тексты, сравнение языков (общие эхи)
NICE. SOURCES - эха для программистов. Исходные тексты, документация;
NICE. SOURCES. D - эха для программистов. Обсуждения из эхи NICE. SOURCES;
RU.COMPILER&INTERP - компиляторы и интерпретаторы;
RU. DEVTECH - технологии программирования;
RU. LANG. PROG. CMP - сравнение языков программирования.
Вирусы, антивирусы
SU. СМ - компьютерные вирусы;
SU. VIRUS - вирусы и антивирусы, обсуждение и поиск.
Программирование в конкретных операционных системах
RU. VP - язык программирования Virtual Pascal для OS/2 фирмы fPrint;
SU. OS2 . PROG - программирование в среде OS/2;
SU.WIN32 . PROG - программирование Win 32-систем с API;
SU.WIN9 5 . PROG - программирование в ОС Windows95;
SU.WINDOWS . PROG - программирование для MS Windows.
Специализированное программирование
НОТ. BAZAAR - «горячее» программирование;
SU. NET. PROG - программирование в сетях;
RU . PROGRAM. GAMES - пишем игры вместе.
Среды разработки и языки программирования.
Базы данных, системы управления базами данных (СУБД)
RU. CLARION - работа на СУБД Clarion;
RU. CLIPPER - обсуждение СУБД Clipper;
RU. DBVISTA - дискуссия по СУБД DBVista фирмы Raima;
RU. FOXPRO - все версии FoxPro и все, связанное с ними;
RU.MSACCESS - программирование на MS Access;
RU. PERVASIVE - СУБД Btrieve и Pervasive.SQL;
RU. VISUAL. FOXPRO - работа c Misrosoft Visual FoxPro;
SU. DBMS - СУБД и все, связанное с ними;
SU. DBMS . CRONOS - СУБД «Кронос»;
SU. DBMS . CASE - CASE: методологии и средства;
SU. DBMS . BORLAND -- все борландовские DBMS-продукты;
SU. DBMS . DB2 - обсуждение СУБД DB2 от IBM;
SU. DBMS . HYTECH - обсуждение СУБД HyTech;
SU. DBMS . INTERBASE - обсуждение Borland Interbase;
SU. DBMS . SQL - SQL: язык и сервера.
Среды разработки и языки программирования.
Вычислительные языки высокого уровня: Basic, Visual Basic
RU. DOS . BASIC - программирование на Basic для DOS;
RU. OCX - работа с интерфейсом OLE;
RU. VBSCRIPT - язык программирования VBScript;
RU. VISUAL. BASIC - Basic простой и Visual.
Среды разработки и языки программирования.
Вычислительные языки высокого уровня:
Delphi от фирмы Borland
RU. DELPHI - работа в среде Delphi;
RU. DELPHI. DB - работа с БД в Borland Delphi;
RU. DELPHI. INFO - информация о Delphi;
RU. DELPHI. MASTER - клуб мастеров Borland Delphi.
Среды разработки и языки программирования.
Вычислительные языки высокого уровня: Pascal
RU. FREE. PASCAL - GNU-компилятор Free Pascal;
RU. TMT - программирование на TMT Pascal;
SU. PASCAL. MODULA. ADA - Pascal и подобные ему языки;
XSU. РИА. FAQ - FAQ по языку Pascal.
Среды разработки и языки программирования.
Вычислительные языки высокого уровня: Си, Си++
RU. С— все о языке программирования SPHINX С-;
SU. С-СРР - программирование на Си и Си++;
RU. С_СРР. MARKET - обмен программными средствами для Си;
RU. CBUILDER - программирование на C++ Builder;
RU. POWERBUILDER - программирование в Power Builder;
RU.VISUAL.CPP - все о Visual C++, MFC ATL;
RU. VISUALAGE. CPP - дискуссия no IBM VisualAge C++.
Среды разработки и языки программирования.
Вычислительный язык низкого уровня Assembler
МО. PC—HAWK - низкоуровневое программирование в DOS;
PC . CODING - низкоуровневое программирование для IBM PC;
RU. ASM. CHAINIK - Assembler для начинающих;
RU. VAC - разработка Visual Assembler;
TALKS. ASM - низкоуровневое программирование.
Среды разработки и языки программирования. Языки
обработки символьной информации и представления
знаний: VRML - язык для реализации 3-D реальности, Java,
Javascript, Perl, HTML, LISP
RU. JAVA - язык программирования Java;
RU. JAVASCRIPT - язык программирования Javascript;
RU. VRML - обсуждение языка VRML;
RU. CGI. PERL - программирование на Perl;
RU. PERL - язык программирования Perl;
RU. HTML. CHAINIK - HTML для всех;
RU. HTML. PROFY - HTML для профессионалов;
RU. WEB. CONSTRUCTION - создание Web-страниц;
RU.LISP - программирование на LISP
Среды разработки и языки программирования. Теория
программирования (алгоритмы, архивирование данных)
RU. AI - искуственный интелект;
RU. ALGORITHMS - алгоритмы: поиск и обсуждение;
RU. COMPRESS - сжатие и архивирование данных;
RU. CRYPT - обсуждения любых аспектов шифрования и защиты инфор-
мации;
RU. XYZ - математика и программирование.
Среды разработки и языки программирования. Технологии
защиты информации и информационных систем
LV. PGPKEYS - распространение публичных PGP-ключей;
RU. HACKER - хакерские технологии;
RU. SOFT. PROTECT - защита программного обеспечения.
Среды разработки и языки программирования.
М, SmallTalk, Flash, Forth, OWL
RU. FLASH - обсуждение технологии Flash;
RU. MUMPS - М-технология и программа на языке М;
RU. SCADA - разработки систем АСУТП и систем реального времени;
RU. SMALLTALK - язык программирования SmallTalk;
SU. FORTH - язык Forth;
SU.OWL - программирование с использованием OWL.
ПУТЕШЕСТВИЯ, СТРАНОВЕДЕНИЕ, ТУРИЗМ
Общие эхи, турклуб, FAQ
CRAZY. TRAVELS - походы выходного дня;
МО. INTER. TOURISM - для искателей приключений;
МО. TOURISM - все про туризм;
RU. TOURCLUB . TALKS - турклубы будут говорить;
RU. TOURISM - самодеятельный туризм;
RU. TOURISM. FAQ - FAQ по туризму;
RU. TOURISM. TEXTS - туристские отчеты;
RU. TRACKERS - прогулки и путешествия трэкеров;
SU. RUS . TRAVELS - путешествия по России и бывшему СССР;
SU. TRAVEL - путешествия и туризм.
Специализированные способы путешествий
(на автомобилях, с помощью автостопа, RAKA)
RU. AUTOSTOP - автостоп - мир для свободных людей;
RU. AUTOSTOP. FILTERED - информационная поддержка автостопа;
RU. CARS . TRAVEL - путешествия на автомобилях;
RU. RAKA - Российская ассоциация клубов автостопа.
Специализированные виды туризма: грибы, ягоды, охота,
рыбалка
RU. FISHING - рыбалка и все, что с ней связано;
RU. HUNTER - все об охоте;
RU. РО . GRIBI. РО . YAGODI - ПО грибы-ягоды И ПОХОДЫ.
Места стоянок
RU. HOTEL - гостиницы и все, связанное с ними.
Страноведение
RUSSIAN. Z3 - все об Австралии;
RU. CELTIC - кельты и все, связанное с ними;
RU. SCANDINAVIAN - страны северной Европы;
RU. SUOMI - Суоми-Финляндия;
RU. USA - все-все-все о США;
SU. ISR&JEWS - евреи и Израиль.
РАБОТА
МО. JOB - поиск и предложения работы;
МО. JOB. HALTURA - дополнительные виды зароботка помимо основного места
работы;
МО. JOB. SERVICE - поиск и предложение услуг;
МО. JOB. TALK - «околоджобные» разговоры;
МО. МАКЕ. MONEY - как сделать деньги.
РЕЛИГИИ, КУЛЬТЫ, АТЕИЗМ,
МИРОВОЗЗРЕНЧЕСКИЕ ВОПРОСЫ,
ФИЛОСОФСКИЕ УСТАНОВКИ
Атеизм
RU. ANTI-RELIGION - атеизм во всех проявлениях.
Религии
RU.AGNI - философия, религия, оккультизм.
Обсуждение религий и источников
(Библия, буддизм, монотеизм)
CHRISTIANOS - христианская эха для всех;
МО. ONEGOD - дискуссия монотеистов;
RU. ANTICHRIST - о негативной роли христианства;
RU. BIBLE - о чем говорит Библия;
RU. BUDDHISM - буддизм и его практика;
RU.CHRISTIANITY - разговоры о христианстве;
RU. DHARMA - буддизм для всех;
RU. JAH. RASTAFARI - растафарианская культура;
RU. PRAVOSLAVIE . TALK - разговоры о религиях.
Эхи околодуховные и околопсихологические
(Веда, Дух, йога, магия, саентология)
PVT. ESOTERIC . CLUB - путь к себе;
RU. ENERGETIKA - энергетика человека - белая магия;
RU. NEW. THOUGHT - духовная психология;
RU. NO_WAY - мы знаем, что ты идешь не туда;
RU. SYNTONE. CLUB - клуб психологии «Синтон»;
RU. THELEMA - церемониальная магия и йога;
RU. THEOLOGY. GENERAL - теологические дискуссии;
SU. KASCHENKO. LOCAL - душевное оздоровление;
SU. SCIENTOLOGIE - саентология;
SU. SOUL - душа, Дух, сознание;
XSU. ТМ - трансцендентальная медитация и Веда.
Философские установки и течения
RU. ANARCHY - об анархии и не только;
RU. ANTI FASCISM - обсуждение фашизма;
RU. WHITE . POWER - разговоры о белой расе.
СЕКС ВО ВСЕХ ПРОЯВЛЕНИЯХ, АНТИСЕКС
Обсуждение секса (общие эхи)
RU. FREELOVE - любить всех и уважать свободу;
RU.SEX - люди и немного секса.
Знакомства, объявления на тему секса и их обсуждение
RU. PICKUP - знакомства и соблазнение девушек;
RU. PICKUP. GURU - элитарный ПИКАП-клуб;
RU. SEX. ADV - объявления на темы секса;
RU. SEX. ADV. TALK - обсуждение объявлений из RU. SEX. ADV.
Нетрадиционная секс-ориентация
RU.BISEXUALS - бисексуалы и бисексуалки;
RU.GAY_CLUB - Russian Gay Club;
RU. GAY. TALK - Russian gays’ talks;
RU. LESBIAN - эха для лесбиянок;
RU. ONANIZM - в прямом и переносном смысле;
RU. SEX. GAY - обсуждение всех сторон однополой любви;
RU. SEX. SADO&MAZO - садизм и мазохизм.
Сексуальная литература
RU. SEX. SUPPORT - сексуальное просвещение;
RU. SEX. TEXT - художественные эротические произведения.
Эхи «против» секса (общая),
против нетрадиционных ориентаций
RU. ANTI SEX - для всех противников секса;
RU. REMONT - за мир без гомосексуализма.
СЕМЬЯ, ДЕТИ, ДОМ, ОБРАЗОВАНИЕ, ШКОЛА
Внутрисемейные отношения
MISTRESS . RUS - разговоры сисопских жен;
PVT . HUSBAND. CLUB - клуб мужей;
RU. FAMILY - обсуждение семейных проблем.
Дети: воспитание, здоровье, образование, общение,
педагогика, учеба, школа
BABY. MAIL. PVT - разговоры детей и подростков;
RU. BABY - посвящена детям;
RU. BABY. EDUCATION - воспитание детей;
RU. BABY. MAIL - детская эха;
RU. BABY. MEDIC - здоровье детей;
RU. EDUCATOR - проблемы негосударственного образования;
RU.FIDOSCHOOL - виртуальная школа;
RU. PUPILS - разговоры учеников об учебе и т.п.;
RU. SCHOOL - обучение и воспитание в школе;
SU. KOMANDOR - неформальная педагогика;
TEACH. PRO - вопросы обучения.
Дом, дача, квартира
МО. HOUSE - все, связанное с нашим домом;
RU. НОМЕ - все о квартире;
SU. DACHA - дачные проблемы и радости.
Семейный быт
МО. CONSTRUCTION - все о строительстве и ремонте;
МО. REPAIR - обсуждение и помощь в ремонте любых вещей;
RU. SELFMAKE - самоделки и Самоделкины;
SU. KITCHEN - кухня и все, относящееся к ней.
СОЦИУМ: общество, политика
Выборы президента, политика, соционика, GreenPeace
RU.GREENPEACE - Россия, GreenPeace, экология;
RU. OPINION. POLL - опросы общественного мнения;
RU. SOCIONIC - соционика и социальные технологии;
SU. POL - политика и около;
SU. POL. FREE - свободное общение на политические темы;
SU. POL. THEORY - обсуждение политических теорий;
SU. SOCIAL. GROWTH - продвижение в обществе.
СПОРТ
Общие вопросы
RU. FITNESS - спорт и методы оздоровления;
RU. NATURE . HEALTH. HARMONY - здоровый образ жизни;
RU. NATURISM - натуризм и движение натуристов;
RU. SPORT. OTHER - спорт вообще.
Автоспорт: Формула-1
PVT. FORMULA1 - разговоры о королеве автоспорта;
RU. FORMULA. RACING - все о гонках Формулы-1;
SU. FORMULAl - разговоры о Формуле-1;
• SU. F0RMULA1. AROUND - дискуссия вокруг Формулы-1;
SU. F0RMULA1. INFO - новости Формулы-1.
Восточные единоборства, культуризм, силовая подготовка,
тэйквондо
МО. COMBAT. ARTS - боевые искусства;
RU. BODYBUILDING - бодибилдинг и силовая подготовка;
RU. TAEKWON-DO - тэйквондо и боевые искусства;
RU. VD.MARTIAL. ARTS - развитие боевых единоборств.
Спортивные игры в закрытых помещениях
МО. POOL - все о бильярде, боулинге и т.п.;
SU. CHESS - все о шахматах;
SU. CHESS. PLAY - игра по переписке.
Футбол и прогнозы
МО. FIFA - все о футболе и футбольных играх;
МО. FOOTBALL - московский футбол;
МО. FOOTBALL. PORTER - футбольная команда «Портер»;
МО . FOOTBALL . REALPLAY - фидошный футбол;
RU. SPORT. FANS - фанаты и рассказы о них;
RU. SPORT. FOOTBALL - для футбольных болельщиков;
RU. SPORT . SOCCER - разговоры о футболе;
SU. FOOTBALL . FUNS . NEWS - новости для фанатов;
SU. FOOTBALL. PROGNOZ - эха для футбол-прогноза;
SU. ULTRAS - разговоры футбольных фанатов.
Экстремальные виды спорта. Общая эха
RU. DANGER. SPORT - виды спорта, опасные для жизни.
RU. JUMP - парашюты, парапланы, дельтапланы;
RU. PARAGLIDING - все о парапланеризме;
RU. SCUBA - подводное плавание и снаряжение для него;
RU. SKYDIVING - парашютный спорт.
Экстремальные виды спорта на твердом покрытии и на снегу
МО. EXTREME. BOARDS - про сноуборд и винсерфинг;
RU. CRAZY_ROLLERS - экстремальное катание на роликах;
SU. SKATE - все связанное со скейтами и скейтбордингом.
Летние виды спорта
МО. BICYCLE - велосипеды и велоспорт;
МО. SAILS - все о парусах;
RU.MODELISM - стендовый и спортивный моделизм;
RU. DANCE - о танцах;
RU. SPORT. BASKETBALL - баскетбол;
SU. TENNIS - большой теннис и все о нем;
RU. YACHTING - яхтинг и все, относящееся к нему.
Зимние виды спорта
МО. SKI - все о горных лыжах;
RU. NHLHOCKEY - НХЛ (Национальная хоккейная лига);
RU. SPORT. HOCKEY - разговоры про хоккей.
СРЕДСТВА МАССОВОЙ ИНФОРМАЦИИ, МОДА,
ТЕАТРЫ, ВЫСТАВКИ, ФОТОГРАФИЯ, ТАТУ
Мода
RU. PRETTY. GIRLS - как стать и быть красивой;
RU. STYLE - о моде и вокруг нее;
RU. TATTOO - все о татуировке;
RU. TATTOO&PIERSING - обсуждение тату и пирсинга.
Средства массовой информации
SU. JURNALIST - эха для журналистов;
RU. CAMCORDER - любительская видеосъемка;
RU. PHOTO - фотография;
МО. VIDEOMOVIES - все о видеофильмах;.
PVT. SERIALS - все про молодежные сериалы;
RU. FILM - Фильм. Фильм? Фильм!;
RU. KINO-NOT-FOR-ALL - кино не для всех;
RU. TOON - все о мультфильмах;
RU. VIDEO - обсуждение всего связанного с видео;
RU. VIDEO. FILMS - разговоры о кино и не только;
RU. VIDEO. SERIES - беседы о телесериалах;
SU. COOL. STARS - все о красивых актрисах и певицах.
Радиовещание, радиостанция. Общие эхи
МО. NASHE. RADIO - «Наше радио» и радиослушатели;
МО. RADIOSTAT - обсуждение музыкальных радиостанций;
RADIOMAX. ALL - для фанатов радио «Maximum»;
RU. FM. RADIO - музыкальные радиостанции УКВ и FM.
Театр, выставки. Комтек
МО. COMTEK - ежегодная компьютерная выставка КОМТЕК;
RU.EXPO - выставки и семинары в Москве и не только;
RU. THEATRE - театры.
Телевидение
МО. TV - телевидение в Москве и других городах России;
RU. HOME_CINEMA - системы «домашний кинотеатр»;
RU. SAT. CHAINIK - для начинающих в SAT TV;
RU. SATELLITE. TV. CRYPT - кодированные спутниковые каналы.
Телеканалы;, телепрограммы, телесериалы, журналы,
газеты (специализированные эхи)
RU. BABYLON5 - фэн-клуб телесериала «Вавилон 5»;
RU.MTV - MTV-Россия. Музыкальное телевидение;
RU. ОМ - журнал «Ом»;
RU. STAR. WARS - звездные войны - фантастическая техника;
RU. STS - телеканал СТС;
RU. TARANTINO - обсуждение творчества Квентина Тарантино;
RU. TV6 . OTCHEVID - о программе и для программы «Вы - очевидец»;
RU. VIDEO. LEXX - фэн-клуб телесериала «ЬЕХХ»;
RU.VIDEO.X_FILES - сериал «Секретные материалы»;
SU. GAME. MAGAZINES - поддержка журнала «Магазин игрушек».
ТВОРЧЕСТВО, ЛИТЕРАТУРА, ИСКУССТВО,
КУЛЬТУРА
Творчество, искусство. Общие эхи
MADNESS . ART - искусство безумия;
RU. ART - дискуссия по искусству;
RU. MINSTREL - менестрели всякие и разные.
Web-дизайн, компьютерные арт и графика
RU. ANIME - эха любителей японской анимации;
RU. ANIME. CHAINIK - «чайникам» о Японии и ее анимации;
RU. ANIME. RANMA - клуб RAnMA и другие аниме-клубы;
RU. ANIME. SAILOR - «Sailor Moon» и другие аниме-школьники;
RU. CORELDRAW! - программа Corel Draw и векторная графика;
RU. HRG. SCENE - art-, music-, demo-, warez- и т.п. сцены;
RU. PICTURES . PSEVDO. GRAF - картинки с выставки;
RU. PICTURES . TALKS - обсуждение картинок;
RU. TEXTMODE. ART - о текстовых ANSI и ASCII картинках;
SU. 3DS .MAX - все о системе трехмерного моделирования 3D Studio MAX;
SU.GRAPHICS - компьютерная графика.
Литература (общие эхи)
RU. BOOKS . TALK - обсуждение книг и авторов;
SU. BOOKS - беседы о книгах;
SU. BOOKS . FOR. CHILDREN - детская литература.
Литература: авторы и их произведения
МО .WHIRLPOOL - творчество и материалы «Водоворота»;
RU. AN-CLUB - обсуждение творчества Александра Непомнящего;
RU. KRAPIVIN - творчество Владислава Крапивина;
RU. KRAPIVIN. CLUB - клуб почитателей книг Владислава Крапивина;
RU. LOLITA - «Лолита» Владимира Набокова: нимфетки и поклонники;
RU. LUDENY - исследование творчества братьев Стругацких;
RU. MONTY. PYTHON - клуб любителей скетчей Monty Python;
SU.NIENNAH - против Ниэннах и Иллет;
RU. PELEVIN - обсуждение творчества Виктора Пелевина;
RU. SCHERBAKOV - эха о творчестве Михаила Щербакова;
RU. STEPHENKING - разговоры о Стивене Кинге;
SU. AMBER - творчество Роджера Желязны;
SU. DRAGONLANCE - книжный сериал DragonLance;
SU. JRRT. CLUB - толкинисты и их разговоры;
SU. PERN - творчество Энн Маккеффри и мир Перна;
SU. SUVOROV - творчество Виктора Суворова (Резуна);
SU. TOLKIEN - разговоры вокруг Джона Р. Р Толкиена;
SU. TOLKIEN. TEXTS - тексты вокруг Джона Р Р Толкиена.
Литература: литературные направления
RU. BOOKS . COMPUTING - о компьютерной литературе;
RU. FANTASY - литература в жанре фэнтези;
RU. FANTASY. ALT - литература в жанре фэнтези;
RU. JORDAN - Роберт Джордан и фэнтези в целом;
SU. SF&F. FANDOM - научная фантастика и фэнтези;
RU. SF. NEWS - фантастика: новые книги, события, мнения.
Литература. Вопросы самодеятельного творчества
и его обсуждение
ОВЕС . ЗВОН - беседы участников эхи ОВЕС . РАСТЕТ;
ОВЕС. РАСТЕТ - литературное творчество и юмор;
ОВЕС . FILTERED - фильтрованные литературные произведения;
RU. COMPUTER .LIFE - ЭВМ в литературном творчестве;
SU. ABSOLUTE. TEXT - совместное литературное творчество;
RU. BOMOND. RHYME - светские беседы в стихах;
RU. DUEL . RHYME - дуэли в стихах;
RU. NICE . AND. FUNNY. RHYME - остроумные стихи;
RU. PARNAS - «гнездилище» поэзии и поэтов;
RU. РОЕТ - стихи и их обсуждение;
RU. РОЕТ. TALKS - разговор о стихах.
Нелитературное творчество
МО. GRAFFITI - все о граффити;
PVT. ЕХО - обсуждение творчества Макса Фрая.
Культура (общие эхи)
RU. COOLTURE - культура и молодежь;
RU. CULTURE - культура и искусство.
ТЕХНИЧЕСКИЙ: эхи о функционировании сети
Московские эхи
MFE. INFO - информация о работе файл эхо-бона MFE;
MFE. SYSOP - разговоры участников MFE;
МО. SYSOP - серьезные сисопские обсуждения в 2:5020;
N5 02 0 . BACKBONE . INFO - новые эхи бекбона;
N502 0 . BONE - официальная конференция эхо-бона сети 5020;
N502 0 . COMPLAINT - жалобы и апелляции в 5020;
N5 02 0 . COORD - координирование 5020 и нетмейл-бон;
N5 02 0 . CRISIS - сообщения о кризисах в сети 5020 (N502 0 . CRISIS не долж-
на распространяться через бекбон и не рекомендована к получению у аплинка.
Предназначена для обмена информацией с частями сети, недоступными традици-
онным путем в случае поломки бекбона);
N5020. FILES - эха московского файл-эхо бекбона;
N502 0 . FILES . TALK - обсуждение файл-эхо бекбона;
N5 02 0 . HUBS - техническая конференция только для эхо-хабов;
N5 02 0 . NEW. NODES - для начинающих нодов;
N502 0 .NODEMAKER - нодмейкинг в сети 5020;
N5 02 0 . POINT - пойнтовые проблемы;
N502 0 . POINT. TALK - пойнтовые разговоры;
N5 02 0 . SYSOP - технические беседы сисопов;
N502 0 . SYSOP. CLUB - беседы сисопов 5020;
N5 02 0 . SYSOP. INFO - техническая информация для сисопов 5020;
N5 02 0 . SYSOP. TALK - вольные речи сисопов в сети 5020.
Региональные эхи
R50 . BONE - официальная конференция эхо-бекбона R50;
R50 . BONE. ECHO - конференции эхо-бекбона R50;
R5 0 . BONE. HUBS - хабы эхо-бекбона R50;
R5 0 . SYSOP - официальная техническая эха сисопов 50-го региона;
R50 . SYSOP . CLUB - для обсуждений из R5 0 . SYSOP;
R50 . SYSOP . TALK - болтовня сисопов региона 50;
R5 0 . TSC - разработка FTN-стандартов в R50.
RU и SU эхи о функционировании сети
RU.ECHOLIST - создание списка эхо-конференций;
RU. ECHOMAIL - официальная эхо-конференция тематического эхо-листа;
RU. MODERATOR - вопросы модерирования и правила эх;
RU. NETMAIL - для личной переписки;
SU. CRISIS. SITUATION - кризисные ситуации (только для чтения!);
SU. CRISIS . SITUATION. TALKS - обсуждение кризисных ситуаций;
SU. IP. POINT - пойнтам об IP-технологиях в Fido;
SU. IP. SYSOP - координация действий IP-сисопов;
SU. SYSOP - общесисопская эха для русскоязычных регионов.
ТЕХНОЛОГИЧЕСКИЙ (изделия, права
потребителя)
Технологические стандарты и изделия, (аудио-, видео-,
бытовая техника, аудио- и видеоизделия, игровые
приставки)
МО. HI -FI - все, связанное с Hi-End и Hi-Fi звуком;
RU. HI-FI. CHAINIK - Hi-Fi аппаратура для новичков;
RU. PLAYSTATION - все о Sony PlayStation;
RU.VIDEO.LASERDISC - аппаратура высококачественного воспроизведения
фильмов;
SU.HARDW. AUDIO - обсуждение Hi-End и Hi-Fi аппаратуры;
SU. HARDW. PHOTO. DIGITAL - цифровые камеры;
SU. HARDW. TV. VIDEO - телевизоры и видеомагнитофоны.
Бытовая техника
SU. HARDW. MICROWAVE - бытовые СВЧ-устройства.
Компьютерные и околокомпьютерные технологии
ELF. СА - Control Agent (Win32) и т.д.;
RU. CD. RECORD - вопросы записи CD-дисков;
RU. DSP - обработка сигналов;
RU. EMULATORS . ALL - все об эмуляторах;
RU. IDA - интерактивный дизассемблер IDA.
Компьютеры и компьютерные аксессуары
МО. DEC - эха о компьютерах фирмы DEC;
RU. AMIGA - все про Amiga;
RU. AMIGA. PVT - обсуждение компьютера Amiga;
RU. BAYNETWORKS - все о продукции Bay Networks;
RU. CISCO - обсуждение оборудования фирмы Cisco systems;
RU. COPYER - копировальные аппараты;
RU. DVD - аппаратура и носители DVD;
RU.MACROMEDIA - обсуждение продуктов Macromedia;
RU.MINIDISC - мини-дисковая аппаратура;
RU. NOTEBOOKS - эхо-конференция по ноутбукам;
RU. PALMTOP - все о карманных компьютерах;
SU . HARDW. GAME . DEVICES - ДЖОЙСТИКИ;
SU. HARDW. NOTEBOOK - ноутбуки и все, что с ними связано;
SU. HARDW. PC. CPU - эха по центральным процессорам IBM PC;
SU. HARDW. PC. MEDIA - носители информации для IBM PC;
SU. HARDW. PC. MOTHERBOARD - материнские платы;
SU. HARDW. PC . PERI PHERAL - периферийные устройства;
SU. HARDW. PC. VIDEO - видеокарты и мониторы для IBM PC;
SU. HARDW. SCHEMES - схемные решения;
SU. HARDW. CDROM - о приводах CD-ROM.
Звуковые карты
PVT. SOUND. TURTLEBEACH - звуковые карты Turtle Beach;
RU. STRACK. GUS - о звуковых картах Gravis UltraSound (GUS);
RU. ULTRASOUND - эха пользователей платы GUS;
SU. HARDW. PC. SOUND - звуковые карты для IBM PC.
Модемы
ROCKWELL. MODEM - вопросы no Rockwell-модемам;
RU. USR - модемы USRobotics и их upgrade;
RU. USR. CHAINIK - вопросы начинающих по модемам USR;
RU. USR. FIRMWARE - Firmware для модемов USR(3COM);
RU. ZYXEL - модемы ZyXEL и все о них;
SU. HARDW. HSMODEM - высокоскоростные модемы;
SU. INPRO - поддержка пользователей модемов ИНПРО;
SU. MODEM. ALL - о модемах любых марок.
Прикладные программы, пакеты прикладных программ,
дистрибутивы
RU. DISTRIB - дистрибутивы и их распространение;
RU.MATLAB&SIMULINK - обсуждение Matlab и Simulink;
RU. NOTES - все о Lotus Notes;
SU. ADOBE - продукция Adobe;
SU. ADOBE. PHOTOSHOP - о программе Photoshop;
WATCOM. С - обсуждение Watcom C/C++;
WATCOM. GENERAL - прочие продукты Watcom.
Технология мультимедиа
RU. 3DFX - о технологии 3DFX VooDoo;
RU. 3DS&LW - обсуждение 3DS LW МАХ;
RU. DIRECTX - разговоры про DirectX и его аналоги;
RU.MULTIMEDIA - мультимедийные приложения;
RU. OPENGL - стандарт визуализации OpenGL;
RU. WRAPPED .GLIDE - поддержка DirectX wrapper;
SU. HARDW. PC . VIDEO. 3DFX - разговоры об аппаратуре 3DFX.
Связь, телефония, пейджер, АОН
RU. AON - об автоматичеческом определении номера (АОН);
RU. AON. ROM - рассылка прошивок и их исходников для АОН;
RU. DX. RADIO - разговоры о радиосвязи (СВ, КВ, УКВ);
RU. LINK. ALT - альтернативные системы цифровой связи;
RU. PAGERS - пейджеры и все, связанное с ними;
RU. PHREAKS - тонкости телефонии;
SU. HARDW. PHONES - телефоны и АТС;
XSU. CELLULAR - сотовая телефония.
Шрифты, издательские системы
RU. DTP - настольные издательские системы;
RU. DTP. FONTS - обсуждение шрифтов;
RU. PAGE. MAKING - верстка печатных изданий и соответствующее программ-
ное обеспечение.
Права потребителя, фидошная репутация фирм и
изделий - черный и белый списки (black- и whitelog)
PVT. ЕХСН. BLACK. LOG - информация о «плохих» фирмах и товарах;
PVT. ЕХСН. BLACK. LOG. TALK - защита прав потребителей;
PVT. ЕХСН. TALK - достоинства и недостатки товаров.
Техническое консультирование, техническая поддержка
МО. TECH. SUPPORT - техническая поддержка;
RU. AUDIO. SPECIFICATION - техническая информация по вопросам компью-
терного звука;
RU. HARDW. CHECK - тестирование и диагностика аппаратуры;
SU. HARDW - проблемы и новости аппаратуры, «разгон» процессоров;
SU. HARDW. CHAINIK - для неспециалистов по аппаратуре;
SU. HARDW. OTHER - конференция аппаратчиков.
Эксплуатация систем
RU. ADMIN - компьютеризация государственных учреждений;
RU. ELECTIONS - эксплуатация ГАС «Выборы»;
Юмор 649
RU. EMBEDDED - встроенные системы;
RU. GEOSYSTEM - геоинформационные системы и технологии;
RU. TRADESOFT - системы автоматизации торговли;
RU. TRIZ - вопросы решения изобретательских задач и ТРИЗ.
ЭМИГРАЦИЯ, ИММИГРАЦИЯ, ПРОЖИВАНИЕ
В НЕТРАДИЦИОННОЙ ОБСТАНОВКЕ
Вопросы эмиграции
RU. MIGRATION - все об эмиграции и миграции;
SU. EMIGRATION - вопросы, связанные с эмиграцией.
Вопросы и проблемы проживания в иной культурной среде
GERMAN .RUS - русскоязычные в Германии;
RUSSIAN. Z1 - клуб русских в Америке и по всему миру;
SU. JEWS - национальность - Да!
ЮМОР
Анекдоты и юмор
PVT. ANEKDOT. ALT - только приличные анекдоты;
RU. ANEKDOT - анекдоты;
RU. ANEKDOT. THE . BEST - самые лучшие анекдоты;
RU. COMPUTER. HUMOR - юмор на компьютерную тематику;
RU. SATIRE - законченные литературные формы юмора;
RU. SEX. HOTEL - Дворец развлечений и юмора;
SU. HUMOR - разные шутки и приколы;
SU. HUMOR. ANSWER - отвечайте сегодня и здесь.
Отфильтрованные шутки и анекдоты
HUMOR. FILTERED - отфильтрованные шутки (только для чтения!);
RU. ANEKDOT. FILTERED - фильтрованные анекдоты (только для чтения!);
RU. HUTOR. FILTERED - для смешных форвардов (только для чтения!);
SPB. SYSOP. FILTERED - перлы питерских сисопов (только для чтения!).
Байки, глум, прикол, смешные фразы, торможение, тост,
чудачество
МО. PHRASES - смешные или интересные слова, фразы, изречения;
МО. TEACHERS . PHRASES - каламбуры преподавателей;
RU. ARMY. PHRASES - высказывания армейских офицеров;
RU. BAIKA - рассказывание баек и историй;
RU. BEAVIS&BUTTHEAD - общение в стиле Beavis&Butt-head;
RU. CHUD IKS - чудики и околочудиковские разговоры;
RU. GLUM - всероссийсский глум над всем на свете;
RU. PRIKOL - приколы и приколисты;
RU. SHTETL - назад - в Бердичев!;
SU. TORMOZ - эха для настоящих «тормозов»;
SU. TOST - только тосты.
ЯЗЫКОВОЙ: иностранные языки, лингвистика
Общие лингвистические эхи
RU. GEEK - эха любителей ГИК-кода, используемого для передачи дополни-
тельной персональной информации в электронном письме;
RU. LINGUIST - языки, языкознание, переводчики;
RU. SPELLING - язык и правописание.
Иноязычные эхи, совместное изучение языка
DR. ESPERANTO - обучение языку эсперанто;
ESPERANTO. RUS - все о и на языке эсперанто;
RU. AD&D. TRANSLATE - перевод документов AD&D;
RU. ENGLISH - английский для всех;
RU. FRANCE - для любителей французского языка;
RU. ITALIA - Италия и все итальянское.
Англоязычная, германоязычная, испаноязычная эхи
PVT. CRAZY. ENGLISH. TALKS - бредовые идеи (англоязычная);
RU. ESPANOL - общение по-испански;
RU. TALK. DEUTSCH - разговоры на немецком в R50;
RU. TALK. ENGLISH - разговоры на английском в R50.
Приложение VI
Справочник популярных
международных
эхо-конференций FidoNet
Настоящий справочник составлен на основе списка эхо-конференций Всемирного
международного бекбона FidoNet (World-Wide Backbone, WWB). В большинстве
своем представленные в списке конференции не что иное, как старые эхи североа-
мериканского бекбона FidoNet (North American Backbone, NAB). Языком всех этих
эх является английский. Наряду с основным списком эх, приведенным ниже, по
WWB во множестве распространяются и национальные конференции на языках,
отличных от английского (существуют соответствующие списки). Многие из опи-
санных эх в последнее время опустели в связи с уменьшением численности FidoNet
во всех зонах, кроме второй. Однако это не означает, что они окончательно «умер-
ли». Каждая такая конференция имеет шанс возродиться с появлением в ней хотя
бы нескольких участников, и это время от времени происходит.
10TH_AMD - эха 10-й поправки (имеется в виду известная поправка к конститу-
ции США);
2 0 0 0 - тестирование программ на соответствие 2000 году;
4DOS - поддержка файл-процессора 4DOS;
4x4 - эха, посвященная автомобилям-внедорожникам;
_60S 7 0S_PROGROCK - прогрессивный рок 60-х и 70-х;
80ХХХ - программирование на Assembler для процессоров семейства Intel.
А
ABLED - обмен информацией между пользователями-инвалидами;
ABLENEWS - медицинские новости, новости для инвалидов, обозрения, ссылки на
ресурсы;
ABORTION - дискуссия об абортах;
AD&D - обсуждение игр в стиле Advanced Dungeons and Dragons;
ADAM - компьютерная конференция Adam International;
ADAPTER - обсуждение адаптивной технологии для нужд инвалидов;
ADLIB - эха, посвященная компьютерным звуковым картам;
ADOPTEES - обмен информацией по вопросам приемных детей;
ADSL - поддержка модемной технологии ADSL;
AIDS-HIV - проблемы СПИДА;
AIDS/ARC - проблемы СПИДА;
AIRGUN - обмен информацией между любителями пневматического оружия;
ALASKA—CHAT - разговоры про Аляску;
ALL-POLITICS - только политика;
ALLFIX_FILE - анонсы файлов файл-менеджера AllFix;
ALLFIX_HELP - поддержка файл-менеджера AllFix;
ALTMED - обсуждение альтернативной медицины;
ALT_DOS - обсуждение альтернативных версий DOS - OPENDOS, FREEDOS
и т. п.;
AMATEUR—RADIO - радиолюбительская эха;
AMIGA - международная эха по компьютерам Amiga;
AMIGAGAMES - игры для компьютеров Amiga;
AMI GAS ALE - программы и оборудование для компьютеров Amiga на продажу;
AMIGA_FILEFIND - поиск файлов для компьютеров Amiga;
AMIGA_INT - всемирная Amiga-конференция;
AMIGA—LC - программирование на Си и Си++ для компьютеров Amiga;
AMIGA_MUSIC - музыкальная эхо-конференция для компьютеров Amiga;
AMIGA—PROG - эха для Amiga-программистов;
AMIGA_SYSOP - эхо-конференция операторов BBS компьютеров Amiga;
AMIGA—VIDEO - видеоэха для компьютеров Amiga;
AMY_POINT - 'программы для пойнт-систем, установленных на компьютерах
Amiga;
AMY_TECH - техническая эха по компьютерам Amiga;
ANEWS - новости США и по всему миру;
ANIMAL—DOC - дискуссия о животных с участием ветеринаров;
ANIMAL-RIGHTS - эхо-конференция по правам животных;
ANIME - эхо-конференция по японской анимации;
ANIMED - медицина для животных;
ANYTHING—GOES - открытые, дружеские беседы;
АОР - эха Ассоциации on-line профессионалов (АОП);
APOGEE - эха поддержки программы Apogee;
APPLE - международная эха поддержки компьютеров фирмы APPLE;
APWORKS - международная эха поддержки программ Альберта Паскаля (Alberto
Pasquale);
AQUARIUM - эха аквариумистов;
ARCADE - обсуждение «аркадных» компьютерных игр;
AREXX - обсуждение и поддержка любителей языка AREXX;
ARGUS - эха поддержки почтовой программы «Argus»;
ARJ - эха поддержки программы архиватора ARJ;
ARROWBRIDGE - эха BBS-игры Arrowbridge Марка Синклера (Mark Sinclair);
ARTWARE - эха поддержки Fido-программ: TimEd, NetMgr, WIMM;
ASCII—ART - эха для картинок, выполненных текстовыми символами;
ASIAN-LINK - международная разговорная эха - участники с шести континентов;
ASKACOP - здесь можно задавать вопросы служителям закона о их работе;
ASKACOP2 - еще один форум для общения с полицейскими;
ASK—А_NURSE - для запросов по уходу за больными;
ASTRONET - эхо-конференция по астрономии;
ASTRONOMY - эхо-конференция по астрономии;
ATARI - эха по 8-битным компьютерам Atari;
ATARI_ST - эха по компьютерам Atari ST, Jaguar и другим темам, связанным с этим
вопросами;
ATHEISM - атеистическое образование и дискуссии на тему атеизма;
ATM - эха по изготовлению телескопов своими руками;
AUDIO - международная аудиоконференция FidoNet;
AUTOMOBILE—RACING - дискуссия по всем разновидностям, авто- и мотоспорта;
AUTOMOTIVE - авто- и мотолюбительская эхо-конференция;
AUTORACE - международная эха по автогонкам;
AVIATION - международная авиационная эха;
A_CAD - международная эха по системам проектирования AutoCAD и другим
подобным система;
A—THEIST - эха по отделению церкви от государства и атеистическая информация.
В
BABYLON5 - обсуждение популярного сериала «Вавилон 5»;
BAD—COPS - разговоры о плохих полицейских;
BASSGTR - эха по бас-гитарам;
BATPOWER - эха по программированию на пакетных языках;
BBBS. BZ - обсуждение языка скриптов BZ программы BBBS;
BBBS. CHAT - основная эха для разговоров о BBBS;
BBBS. ENGLISH - основная эха поддержки для BBBS;
BBBS. SYSOP - эхо-конференция сисопов BBBS;
BBBS. UTIL - анонсы и обсуждения утилит для BBBS;
BBSDOORS - обсуждение любых BBS-игр;
BBSDOOR_DISCUSSION - обсуждение BBS-игр и других BBS-утилит;
BBS_ADS - рекламируйте здесь вашу BBS;
BBS_CARNIVAL - обсуждение программ BBS и сопутствующих утилит;
BBS_DOORS - обсуждение всех типов BBS on-line утилит;
BBS_INTERNET - обсуждение программ для подключения DOS, Win, OS/2 или
UNIX BBS к Internet;
BEACH_BOYS для любителей музыки ансамбля «Beach Boys»;
BEATLES - эхо-конференция для обсуждения группы «The Beatles»;
BEEMAIL - обсуждение почтовой программы с графическим интерфейсом Beemail
для Windows 3.1 и Win32;
BGFAX - эха поддержки программы BGFAX;
BIBLE - международная эхо-конференция по Библии;
BIBLE-STUDY - премодерируемая эхо-конференция по изучению Библии;
BIG_SMOKE - эха для любителей курения сигар;
BIKE-N-RIDER - эха для любителей езды на мотоциклах;
BINKLEY - эха для пользователей мейлера Binkley Term;
BIRDING - эха для любителей наблюдать за птицами;
BLINDTLK - обсуждение проблем, связанных с потерей зрения;
BLINKTALK - эха для инвалидов по зрению;
BLUEWAVE - эха поддержки почтовой системы Blue Wave;
BNU - помощь для пользователей и обсуждение FOSSIL-драйвера BNU;
BOATING - эха для любителей лодок и катеров;
BODYART - эха по пирсингу, тату и т.п.;
BODYWORK - работа над телом и массажная терапия;
BROADCAST - разговоры профессионалов радио- и телевещания;
BURL - электронные книги-романы с продолжениями;
BUSINESS - для деловых разговоров.
С
С&С - эха по играм в стиле Command & Conquer;
CABLE_MODEMS - эха для обсуждения технологии кабельных модемов;
CALLSIGN - обсуждение серверов выдачи извещений о проведенных радиолюби-
тельских соединениях;
CANACHAT - разговоры канадцев;
CANPOL - политика в Канаде;
CAN_FREECHAT - свободные разговоры канадцев;
CAN_.MIL ITARY - канадская военная эхо-конференция;
CAN_SYSLAW - информация о законах для канадских сисопов;
CARCINOMA - эха по выживанию больных раком;
CARDIAC - международная кардиоконференция;
CARPENTERS - эха для любителей музыки группы «Karen & Richard Carpenter»;
CBM - эха по компьютерам Commodore;
CBM-12 8 - обсуждение компьютеров Commodore-128;
CBM-GEOS - обсуждение программ для Commodore-GEOS;
CB_RADIO - разговоры пользователей СВ-радио;
CDRECORD - записывающие CD - обсуждение записи на устройства CD-R, CD-
RW, DVD;
CDROM - обсуждение устройств CD-ROM;
CDROM_SALE - CD-ROM на продажу;
CD_ECHO - FidoNet CD-эхо;
CELLULAR - эха для разговоров о сотовой телефонии;
CFL - эха, посвященная разговорам о Канадской футбольной лиге;
CFORSALE - коммерческая эха для продаж через FidoNet;
CFS - обсуждение синдрома хронической усталости;
CHAMELEON - эха для владельцев экзотических животных;
CHANNELLING - передача сообщений из Королевства Духа;
CHAOS_LANDING - эха для свободных разговоров;
CHAT - общая эха для бесед в FidoNet;
CHATTER - эха для дурацких разговоров;
CHESS - международная шахматная эхо-конференция FidoNet;
CHILD_ABUSE - сообщения о плохом обращении с детьми;
CHRONIC_PAIN - обсуждение синдрома хронической боли;
CHURCH&STATE -- эха об отделении церкви от государства;
CIVIL_WAR - эха по истории гражданской войны в США;
CIVLIB - обсуждение гражданских свобод;
CLASSICAL - эха по обсуждению классической музыки;
CLIPPER - эха по СУБД и по языку программирования CA-Clipper;
CMX4SALE - комиксы на продажу;
CNET_BBS - поддержка программы BBS CNET;
COCO - эхо-конференция по компьютерам Tandy;
COFFEE_KLATSCH - эха для передачи слухов и болтовни;
COLLECTABLES - эха для коллекционеров;
COLLEGE - международная колледж-эха;
COMICS - эха для обсуждения книг комиксов;
COMPRESS - эха по сжатию файлов и архиваторам;
COMPUSALE - эха для продажи компьютеров;
CONCORD - эха поддержки программы Concord BBS;
CONS PRC Y - обсуждение конспирации;
CONSTITUTIONAL - эха для обсуждения конституции;
CONSUMER_REPORT - сообщения от потребителей;
COOKING - национальная (США) кухонная эха;
CORELDRAW - обсуждение графического пакета Corel Draw;
COUNTRY - дискуссия по музыке в стиле «кантри»;
СРМТЕСН - техническое обсуждение операционной системы СР/М;
CREATIVE_ARTS - для любителей изготавливать резиновые печати;
CRICKET_ECHO - новости и обсуждение для любителей игры в крикет;
CWL - эха для международных контактов;
CYBER_AUCTION - эха-аукцион в киберпространстве;
С_ЕСНО - международная эха по языку программирования Си;
C_PLUSPLUS - международная эха по языку программирования Си++.
D
DAGGER - обсуждение игры Daggerfall и других RPG-игр;
DBASE - эха по базам данных (СУБД), обсуждение технических моментов и советы;
DBRIDGE - поддержка почтовой программы D’Bridge;
DEBATE - эхо-конференция для споров;
DELPHI - эха для разработчиков, использующих CASE-систему Delphi фирмы
Borland;
DEMOCRATS - обсуждение политики и стратегии демократической партии США;
DESQVIEW - международная эхо-конференция по программным продуктам фир-
мы Quarterdeck: DESQview, QEMM, DESQview-X;
DEUTSCH - для разговоров на немецком языке;
DIABETES - дискуссия и поддержка для больных сахарным диабетом;
DIABETIC—RECIPES - рецепты для людей, больных сахарным диабетом;
DIETING - эхо-конференция по диетпитанию;
DIRTY_DOZEN - предупреждение сисопов о компьютерных вирусах, «троянских
конях», «почтовых бомбах» и т.п.;
DISASTERS - эха по чрезвычайным происшествиям;
DISNEY - обсуждения продукции компании «Дисней»;
DLG - эха для пользователей DLG Pro BBS;
DLG_SUPPORT - эха для пользователей DLG Pro BBS (вопросы и ответы);
DND - фантастические ролевые игры в стиле D&D;
DOGHOUSE - международная эхо-конференция FidoNet для любителей собак;
DOOM - обсуждение и поддержка пользователей игры DOOM и ей подобных;
DOORGAMES - дискуссия по on-lineBBS-играм;
DOORWARE - общий форум по созданию on-line утилит для BBS;
DOS_INTERNET - приложения Internet для DOS и BBS: KA9Q, SLIPIT и т.д.;
DTP - дискуссия по DTP-системам (настольное издательство).
Е
ECHOLIST - эхо-конференция для распространения списка эх (эхо-листа);
ЕСНОМАС - международная эхо-конференция по обсуждению компьютеров
Macintosh;
ECHOREVIEWS - форум для обзоров эхо-конференций FidoNet;
ECHO—ADS - эха для рекламы эхо-конференций FidoNet;
ECHO—REQ - для запросов эхо-конференций;
ЕС—SUPPORT - эха поддержки для сисопов Ezycom BBS;
EDUCATOR - обсуждение проблем обучения и образования;
ELEBBS—SUPPORT - официальная эха поддержки программы EleBBS;
ELECTRONICS - обсуждение домашней электроники и электроприборов;
EMBEDDED - эха для обсуждения встроенных систем;
ENGLISH—TUTOR - обучение аглийскому языку;
ENTREPRENEUR - эхо-конференция для предпринимателей;
ENVIRON - разговоры об окружающей среде;
EQUUS - разговоры любителей лошадей;
ESPRIT - Электронный Дух - новая эра думания и действия;
EVOLUTION - эха для обсуждения теории эволюционного механизма.
F
FCC - эха по государственным правилам регулирования радио- и телекоммуни-
кационной деятельности;
FDECHO - эхо-конференция для поддержки программ Front Door и TosScan;
FDN_ANNOUNCE - системы распространения файлов - файлы, информация, и линки;
FEED__CUT - для информирования участников сети о состоянии эхо-трафика;
FEMINISM - эха по феминизму и гендерным вопросам;
FE_HELP - поддержка почтового процессора FastEcho;
FIDO-REQ - эха для анонсов файл-менеджера AllFix;
FIDOBBS - только для сисопов - поддержка программы FidoBBS;
FIDOECHOPOL - обсуждение Эхо-Полиси FidoNet;
FIDOGEN - эха для обсуждений генеалогии;
FIDONEWS - эха для обсуждения электронного журнала FidoNews;
FIDO„UTIL - обсуждение программ и утилит для FidoNet;
FILEFIND - международная эха для поиска файлов с помощью программ AllFix;
FILEJREQ - эха для информации о новых файлах и файл эхах;
FILK - для любителей народных научно-фантастических песен;
FILM - обзоры фильмов и видеофильмов;
FIPS - обсуждение интегрированных пойнт-систем FidoNet типа программы
FIPS;
FIREARMS - техническая эха по обсуждению огнестрельного оружия;
FIRENET - эха для пожарников;
FISHING - эха для разговоров о рыболовстве;
FLAME - национальная (США) флейм-эха;
FLAT__TAX - эха для обсуждения всего, что связано с налогами;
FLEETSTREET - эха для обсуждения и поддержки пользователей редактора сооб-
щений FleetStreet;
FLYING - международная эха любителей полетов;
FMAIL_HELP - поддержка программы тоссера Fmail;
FNOS_HELP - поддержка программы FNOS (одна из версий ТСР/1Р-системы
КА9(2для DOS);
FN_SYSOP - эха только для сисопов FidoNet;
FOR-SALE - продажа в сети;
FOXPRO - обсуждение СУБД FoxPro;
FREEMAIL - эха поддержки почтовых программ FreeMail и A/Mail;
FREEMASON - масонская эха;
FREE—SPEECH - эха для свободных речей и высказываний;
FRONTDOOR—АРХ - эхо-конференция поддержки почтовой программы Front Door
АРХ;
FRUGAL - эхо-конференция для обсуждения бережливого стиля жизни;
FS - обсуждение компьютерных авиасимуляторов;
FTN— INTERNET - обсуждение использования Internet в FidoNet;
FTP—FIDO - обсуждение использования протокола FTP в Internet для получения
эхо-почты FidoNet;
FTSC—PUBLIC - публичная эхо-конференция комитета по стандартам FidoNet
(FTSC);
FUNNY - смешные шутки и истории.
G
GAF. CHAT - разговоры на тему американо-немецкой дружбы;
GAMEDEV - эха для разработчиков компьютерных игр;
GAMES4SALE - игры на продажу;
GAMING - международная эха по играм для персональных компьютеров;
GAYLINK - разговоры гомосексуалистов;
GAYNEWS - новости мира гомосексуалистов и лесбиянок;
GECHO—HELP - международная эха поддержки тоссера Gecho;
GENEALOGY - национальная (США) генеалогическая эхо-конференция;
GENEALOGY. CDN - эхо-конференция по канадской генеалогии;
GENEALOGY. EUR - международная эхо-конференция по генеалогии и истории
семьи;
GENSOFT - программное обеспечение для генеалогии;
GENSYSOP - генеалогическая эха для сисопов;
GEOWORKS - эхо-конференция по программному обеспечнию для геосистем;
GIGO - поддержка программы-шлюза GIGO;
GOLDED - обсуждение публичных выпусков почтового редактора GoldED;
GOLDED. BETA - обсуждение альфа-, бета-, и гамма-выпусков почтового редакто-
ра GoldED;
GRAPHICS - обсуждение работы с графикой - программирование, приемы, и т.п.;
GUITAR - для любителей гитары и бас-гитары;
GUNS - огнестрельное оружие и средства защиты;
GUN_CONTROL - эха по контролю над распространением огнестрельного оружия
и контролю преступности.
Н
НАМ - дискуссия по радиолюбительству;
НАМ-ECHO - открытая дискуссия радиолюбителей;
НАМ-SALE - радиолюбительское оборудование для продажи, покупки и обмена;
HAM__REQ - анонсы файлов для радиолюбителей и запросы файлов;
НАМ_ТЕСН - техническая эхо-конференция радиолюбителей;
HARLEY_DAVIDSON — эха по обсуждению культового мотоцикла «Harley Da-
vidson»;
HAYES - обсуждение модемов фирмы Hayes;
HDCONF - эхо-конференция по жестким дискам компьютеров;
HDSALE - продажа и покупка жестких дисков и принадлежностей;
HDTV- обсуждение цифрового телевидения форматов DTV (Digital TeleVision)
и HDTV (High Definition TV);
HEINLEIN - обсуждение творений фантаста Роберта Хайнлайна;
HERBS-N-SUCH - эхо-конференция для травников;
HISTORY - историческая эхо-конференция FidoNet;
HOBBIES - обсуждения различных хобби;
HOCKEY - международная эхо-конференция, посвященная хоккею;
HOLYSMOKE - дебаты о религии;
HOLY_BIBLE_FCS - обсуждение Священного Писания христианами;
HOME-N-GRDN - дом и сад;
HOMEPOWR - использование альтернативных источников энергии в домашнем хо-
зяйстве;
HOMESCHL - поддержка обучения на дому;
НОМЕ_AUTOMATION - эхо-конференция по автоматизации домашнего хозяйства
и защите жилища;
HOME_COOKING - приготовление пищи и все, что с ней связано;
HOME_OFFICE - коллекционирование и т.п.;
HOME_REPAIR - домашний ремонт и переделка строений;
НОТ—SITES - обсуждение хороших Web-серверов Internet;
HS_MODEMS - обсуждение высокоскоростных модемов;
HTMLEDIT - обсуждение редактирования документов, написанных на языке
HTML, инструментарий и все, что с этим связано;
HUMOR - эхо-конференция для «семейного» юмора.
I
I&UK_GENE - ирланская и английская генеалогия;
IBBSDOOR - обсуждение on-line игр для InterBBS;
ICGAL - обсуждения, связанные с гомосексуалистами и лесбиянками;
IEEE - эхо-конференция по обсуждению деятельности IEEE (института инжене-
ров электроники и электичества);
IFTP_SUPPORT - поддержка программы iFTP, используемой для проброса Fido-
почты через Internet;
IMAIL_HELP - международная эхо-конференция поддержки почтовой програм-
мы IMAIL;
IM—USER - эхо-конференция для обсуждения почтовой программы InterMail
и тоссера InterEcho;
INDIAN_AFFAIRS - дискуссия для коренных жителей Америки и индейцев;
INET—NODELIST - списки Internet-узлов в FidoNet;
INJOY - эха, посвященная программе InJoy, используемой под OS/2 для установ-
ления соединения с Internet;
INK - эха поддержки настольных издательств и программ текстовых процессоров;
INTERCOOK - международная эха по приготовлению пищи;
INTERFAITH - религиозная дискуссия между приверженцами различных религий;
INTERGREEK - международная греческая эхо-конференция (на английском
языке);
INTERNET - для обсуждений, как нужно использовать Internet;
INTERUSER - международный форум для разговоров пользователей BBS;
INVEST - международный форум инвесторов;
IP_CONNECT - соединение с InterNet с использованием Fido-технологии;
IREX - эха поддержки программы Internet Rex (соединение FidoNet и Internet);
ISDN - эха для обсуждения вопросов технологии ISDN;
ITALIANO. GEN - итальянская эхо-конференция по генеалогии;
ITRACK - обсуждение программы обработки почты ITRACK;
I_UFO - наука об НЛО, контакт с инопланетянами.
J
JAVA__LANGUAGE - эха для обсуждения языка Java;
JUDAICA - еврейская эха.
К
KATTY_KORNER - эха для любителей кошек;
KIDS - международная детская эхо-конференция;
KLINGON - обсуждение телесериала «Star Trek».
L
LAN - обсуждение LAN (локальных компьютерных сетей);
LANTASTIC - эхо-конференция поддержки сетевых систем фирмы Artisoft
(LANtastic и LANNET);
LAW - обсуждение законов и права;
LAW_&_ORDER - обсуждение способов исполнения законов;
LAW_DISORDER - обсуждение под девизом «Закон и беспорядок»;
LE/SECURITY - разговоры на тему исполнения законов, соблюдения порядка
и связанной с этим тематики;
LINUX - эхо-конференция по обсуждению операционной системы Linux;
LINUX_BBS - обсуждение использования программ BBS под операционной сис-
темой Linux;
LORA - официальная эха поддержки BBS Lora;
LORD - эха для обсуждения on-line BBS-игры LORD;
LORD2_CHAT - эха для обсуждения программы LORD2;
LOVE_&_MARRIAGE - эхо-конференция для поиска знакомств (назначение свида-
ний, любовь и женитьба);
LOW-FAT - диетические рецепты;
LUNATICS - эхо-конференция лунатиков;
LYRICS - международная поэтическая эхо-конференция FidoNet.
м
МАС4 SALE - компьютеры Macintosh: продажа, покупка и поиск;
МАССОММ - компьютеры Macintosh: телекоммуникации и сети;
MACHW - компьютеры Macintosh: обсуждение оборудования и поддержка пользо-
вателей;
MACSW - компьютеры Macintosh: поддержка пользователей программного обеспе-
чения;
MAC SYSOP - компьютеры Macintosh: конференция сисопов;
MAC_GAMES - компьютеры Macintosh: игры;
MAC_TELEFINDER - компьютеры Macintosh: поддержка BBS TeleFinder;
MAGICK - магическая эха;
MATH - математическая эха;
MAXDEV - эхо-конференция разработчиков программ и утилит для BBS Maximus;
МСС_SUPPORT - поддержка программ фирмы Multiboard Communications;
MCMAIL - международная эхо-конференция поддержки почтовой программы
McMail;
MDOOR_HELP - эхо-конференция поддержки почтовой программы MainDoor;
MEADOW - эхо-конференция поддержки сисопов почтовой системы Opus CBCS;
MEAL-MASTER - эхо-конференция поддержки программы Meal-Master;
МЕССА - официальная эхо-конференция поддержки скриптовых языков МЕХ
и МЕССА для BBS Maximus;
MEDIEVAL - эхо-конференция, посвященная средневековью: искусство, воссозда-
ние жизни, и т.д.;
MED_MOANS - медицинские разговоры пациентов;
MEMORIES - ностальгия;
MEMPHIS - эхо-конференция по Windows 97/98 (Memphis);
MENS—ISSUES - разговоры мужчин;
MENTAL_HEALTH - духовное здоровье;
METALSMITH - дискуссия по всем разновидностям металлообработки;
META_UFO - метафизика, НЛО и взаимосвязанные обсуждения;
MEXICAN_LINK - многоязыковая эхо-конференция по взаимосвязям с Мексикой;
MIDI-NET - международная MIDI-конференция;
MILHISTORY - военная история;
MILITARY - общая эхо-конференция по всем военным вопросам;
MILITARY_PEOPLE - эхо-конференция для обсуждения любых вопросов между
профессионалами в военном деле;
MILITIA - государственная милиция, общая дискуссия;
MILLENNIUM - обсуждение телевизионного шоу «Millennium»;
MISSING - национальная (США) эхо-конференция для поиска людей;
MISSING_CHILD - коференция для поиска потерянных детей;
ML-BASEBALL - эхо-конференция Лиги бейсбола;
MLM - эхо-конференция по многоуровневому маркетингу;
MGD10 0 0 - конференция, посвященная персональным компьютерам модели
Tandy 1000;
MODEMS - разговоры о модемах и обо всем, связанном с ними;
MODERATOR - эхо-конференция модераторов;
MODR8TR - эхо-конференция FidoNet для модераторов и ко-модераторов;
MONTE - эхо-конференция для фэнов скетчей Monty Python;
MOORCOCK - обсуждение творчества Майкла Муркока;
MORMON - открытая эхо-конференция мормонов;
MOSCOW_OKLAHOMA - эхо-конференция линк между США и Россией;
MOTORBIKES - эхо-конференция по мотоциклам;
MOTORCYCLE - эхо-конференция обо всем, связанном с мотоциклами;
MOTOR_SPORTS_RESULTS - различные результаты из мира мотоспорта;
MP3 - международная эха по всему, связанному с форматом MP3;
MSGED_ECHO - поддержка и обсуждение редактора сообщений MSGED;
MS_EXCEL - эхо-конференция по процессору электронных таблиц Microsoft Excel;
MS_SUPPORT - поддержка программ от MatrixSoft;
MS_WORD - эхо-конференция поддержки пользователей текстового редактора
Microsoft Word;
MTG_WOC - разговоры про игру Magic the Gathering и другим аналогичным играм;
MTN_BIKE - дискуссия по горным велосипедам;
MUFFIN - поддержка программ Maximus BBS (только для сисопов);
MULT-SCLEROSIS - эхо-конференция по множественному склерозу;
MUSIC - дискуссия по музыке любых жанров;
MYSTERY - эхо-конференция по мистической литературе;
MYTHOLOGY - мифологическая эхо-конференция.
N
NAB_POLICY - эхо-конференция по обсуждению и формированию правил рабо-
ты североамериканского бекбона FidoNet; •
NANFE - североамериканская рыболовная эха;
NASCAR - обсуждение автогонок NASCAR;
NATURE - дискуссия о природе и о науках, посвященных природе;
NATURIST - дискуссия по натуризму и нудизму;
NAVY - эхо-конференция для любителей военно-морского флота США;
NBA_ECHO - разговоры о Национальной баскетбольной ассоциации США (НБА);
NCSSA - эхо-конференция национальной (США) коалиции сисопов и системных
администраторов;
NEEDLES_THREADS - ненужные обсуждения;
NETSCAPE - поддержка и обсуждения программы-браузера Netscape;
U_DEV - эхо-конференция FidoNet по разработке сетей;
NET_WIDE_CHATTER - общая эхо-конференция для разговоров членов всей
FidoNet;
NEUROLOGY - эхо-конференция по неврологии;
NEWAGE_THOUGHT - мысли и дискуссии о новой эре;
NEWSCHAT - чтение и обсуждение статей из FidoNews и только их;
NEW__SYSOP - поддержка сисопов-новичков;
NFL - эхо-конференция любителей Национальной лиги футбола США;
NOPIRACY - эхо-конференция по компьютерному пиратству;
NOVELL - техническая поддержка пользователей сетевой ОС Novell;
NT4__UK - обсуждение операционной системы Microsoft Windows NT4;
NU_SUPPORT - поддержка системы распространения нодлиста.
О
OCCULT_CHAT - разговоры на оккультные темы;
OFFLINE - форум по обсуждению off-line почты;
OKLAHOMA - общая эхо-конференция для жителей штата Оклахома;
OLDCARS - старые автомобили и все, связанное с ними;
ON_LINE__GAMES - разговоры о самых лучших on-line BBS-играх;
OPEN_BIBLE - международный открытый библейский форум;
OPTOMETRY - эхо-конференция по сбережению зрения;
OS-DEBATE - разговоры об операционных системах;
0S2 - международная эхо-конференция FidoNet по операционной системе OS/2;
OS2BBS - поддержка для любых OS/2-BBS;
OS2COMM - коммуникации для OS/2;
OS2DOS - обсуждение DOS и Windows-приложений под OS/2;
OS2DOSBBS - поддержка для программ MS DOS BBS, работающих под управле-
нием OS/2;
OS2FORSALE - форум для покупателей и продавцов продуктов, связанных с OS/2;
OS2GAMES - помощь по запуску игр под OS/2;
OS2HW - аппаратное обеспечение и OS/2;
OS2INET - интеграция OS/2 в Internet и использование Internet под OS/2;
OS2LAN - локальные сети и OS/2;
OS2PROG - программирование под OS/2;
OS2REXX - эхо-конференция FidoNet по языку программирования OS2REXX;
OS 9 - эхо-конференция по операционной системе OS-9;
OSDEBATE - дебаты по операционным системам;
OTHERNETS - другие сети: эхо-конференция по FTN-сетям, отличным от FidoNet;
OT_SUPPORT - поддержка обработчика почты О/Т.
Р
P5DRAFT - эхо-конференция по обсуждению проекта создания FidoNet Полиси
версии 5;
PACKET - эхо-конференция радиолюбителей по пакетному радио;
PARANORMAL - паранормальные дискуссии;
PARENTS - эхо-конференция для родителей;
PASCAL - эхо-конференция по языку программирования Pascal;
PASCAL—LESSONS - уроки программирования на языке Pascal;
PCBNET - поддержка пользователей программы BBS PCBoard;
PCBOARD - поддержка пользователей программы BBS PCBoard непосредственно
от фирмы Clark Development Со., Inc.;
PCBPPL - поддержка пользователей встроенного языка программирования BBS
PCBoard;
PCWRITE - программа PCWrite и кросс-платформенные расчеты;
РС_ADDICT - эхо-конференция о компьютерной наркомании;
PDNECHO - эхо-конференция для распространения исходных текстов программ;
PENNSYLVANIA - общая разговорная эха штата Пенсильвания;
PENPAL - эха «друзья по переписке» - обсуждение и поддержка;
PERL - эха по языку программирования Perl;
РЕТ_СНАТ - разговоры про домашних животных;
PHARMACY - обсуждение медицинских и фармацептических вопросов;
PHIL - эхо-конференция по философии;
PHONES - эхо-конференция по новостям телефонной индустрии;
PHOTO - международная фото-конференция;
PHYSICS - эхо-конференция FidoNet по физике;
PINK - обсуждение творчества группы «Pink Floyd»;
PKEY—DROP - эхо-конференция для распространения публичных ключей;
PLANET—CONNECT - поиск и разговоры друзей по переписке;
PLATINUM—XPRESS - обсуждение программы почтового сервера Platinum Xpress
для BBS WildCat!;
POINTS - использование пойнт-систем и поддержка пользователей-пойнтов;
POLITICS - политические дискуссии;
РООН - Винни Пух и его друзья;
PORTAL - поддержка почтовой программы Portal of Power;
POWERPC - обсуждение всего, имеющего отношение к компьютерам PowerPC
и PowerMAC;
POWERJBAS - эхо-конференция для программирующих на языке PowerBasic;
PROBOARD - официальная эха поддержки BBS ProBoard;
PROWRITE - эхо-конференция профессиональных писателей;
PRO_AUDIO - профессиональная аудиодискуссия;
PRO_LIFE - вопросы и ответы «за жизнь»;
PRO_WRESTLING - профессиональная борцовская эха;
PUBLIC—KEYS - эха по шифрованию и распространению публичных ключей;
PYRO - национальная (США) пиротехническая эха.
Q
QFRONT - эха поддержки почтовой программы QFront;
QMODEM_USER - эхо-конференция пользователей терминальной программы
Qmodem;
QM_ECHO - обсуждение программы эхо-тоссера QM и связанных программ;
QUAKE - обсуждение игры Quake фирмы id Software;
QUICKBBS - поддержка BBS QuickBBS;
QUICKEN - поддержка программ фирмы Quicken Software;
QU IKUT ILS - официальная эха поддержки программ Matrix Technologies;
QUIK_BAS - эха по программированию на языке QuickBasic.
R
RADIO—HOBBY-ALL - любительское радио всех видов: FM низкой мощности, СВ
и т.п.;
RAILFANS - эха для любителей железных дорог;
RAR - международная эхо-конференция поддержки архиватора RAR;
RA_32BIT - обсуждение 32-битной программы BBS RemoteAccess;
RA_MULTI - эха сисопов многолинейных BBS RemoteAccess;
RA_SUPPORT - эха поддержки BBS RemoteAccess;
RA_UTIL - эха по утилитам для BBS RemoteAccess;
RBBS-PC - эха поддержки BBS RBBS-PC;
REAL—FREE—SPEECH - эхо-конференция для по-настоящему свободных разговоров;
RECFRP - обсуждение ролевых игр;
RECIPES - эха для рецептов;
RELOAD - обсуждение многозарядных винтовок, пистолетов и карабинов;
RENEGADE - официальная эха поддержки BBS Renegade;
RENEGADE_UTILS - обсуждение утилит для Renegade BBS;
RIBBS - поддержка сисопов BBS RiBBS;
ROOTS_MUSIC - дискуссия по основам музыки;
RPG_GENERAL - общая дискуссия и информация по ролевым играм;
RTKBA - дискуссия по правам на использование оружия и контролю над ним;
RTTY - любительская и коммерческая радио-телетайпная технология;
R_CATHOLIC - романский католицизм: вопросы и ответы.
S
SACRED_MAGICK - дискуссия о магии, ее мифах и духе;
SAILING - эха по парусному спорту;
SAILOR_MOON - обсуждение творчества Сейлора Муна;
SB-NASA—NEWS - космическая станция: новости NASA и пресс-релизы (только
для чтения);
SB-NASA_TECH - космическая станция: новости NASA, отчеты по работе косми-
ческих зондов (только для чтения);
SB-QUESTIONS - космическая станция: дискуссионная эха по новостям космо-
навтики;
SB-SAT_TRACK - космическая станция: обсуждение любительского слежения за
искуственными спутниками Земли;
SB-SYSOPS - космическая станция: эхо-конференция только для сисопов;
SB-WORLD_NWS - космическая станция: мировые космические новости (только
для чтения);
SCANRADIO - международная эхо-конференция по приемникам диапазонов VHF-
UHF;
SCI&TECH - эхо-конференция по технологии и науке;
SCI-FI_TV - эхо-конференция по обсуждению телевизионных научно-фантасти-
ческих шоу;
SCIENCE - национальная (США) научная эха;
SCN-CHEAT - подсказки и решения для компьютерных игр;
SCOUTER - международная эха по скутерам;
SCUBA - эха для любителей подводного плавания;
SEMWARE - эха поддержки для программ - текстовых редакторов от SemWare -
TSE Pro, TSE Jr;
SET - Сетианская дискуссия (Храм Сета, ранее называемый Основанием Сета);
SEW_&_QUILT - эха по шитью и вышиванию вручную и на машине;
SF - научно-фантастическая литература и фэнтези;
SHAREWARE_SUPPORT - эхо-конференция поддержки условно бесплатного про-
граммного обеспечения;
SHAREWRE - форум по обсуждению условно бесплатных продуктов;
SHORTWAVE - эхо-конференция по программе Shortwave;
SILENTTALK - эхо-конференция для глухих или людей с пониженным слухом;
SILVER_XPRESS - эхо-конференция по почтовой системе для пользователей BBS
Silver Xpress OPX/QWK;
SIMPSONS - эха по телевизионному сериалу «Семья Симпсонов»;
SINGLE_DADS - информация и обсуждения для отцов-одиночек;
SINGLE—PARENT - обмен информацией для одиноких родителей;
SIP_AA - о сознательном одиночестве и анонимных алкоголиках;
SIP_ACA - анонимная эхо-конференция для взрослых детей;
SKEPTIC - эхо-конференция для скептических разговоров;
SKYREADER - обсуждение почтовой системы пользователя SkyReader для систе-
мы BBBS;
SLIDERS - обсуждение телесериала «Скользящие»;
SMOKERS—RIGHTS - разговоры о правах курящих на курение;
SOAPS - рассказы про мыльные оперы, беседы и сплетни;
SPACE - эха по исследованию космического пространства внутри Солнечной си-
стемы;
SPINAL_INJURY - обсуждение вопросов, связанных с травмами позвоночника;
SPIRITUAL - духовность и мир во всем мире;
SPORTS - общая дискуссия по спорту;
SQAFIX - помощь и информация по менеджеру подписки SqaFix;
STAMPS - эха о коллекционировании печатей и обсуждение тем, связанных с этим;
STARTREK - эха по ролевой игре «Star Trek»;
STARTREK—CCG - новости карточной игры «Star Trek»;
STARWARS - эха для любителей «Звездных войн»;
STATS - статистика и информация по эхо-почте;
STEP_PARENT - дискуссия, связанная с проблемами сводных детей и сводных
родителей;
STOCK-MARKET - рынок акций и инвестиций;
STOP_SMOKING - эха поддержки для желающих бросить курить;
STRESS_MGMT - управление стрессом;
ST—PROG - программирование персональных компьютеров Atari ST, Jaguar, и дру-
гих аналогичных систем;
SUPERBBS - поддержка пользователей программы BBS SuperBBS;
SUPRAFAX - эха для обсуждения модемов Supra Modems;
SURVIVOR - эха для обсуждения проблем рака, лейкемии, нарушений иммунной
системы и т.п.;
SYS4SALE - сисопская барахолка: продажа и обмен;
SYSOP - международная сисопская эхо-конференция;
SYSOPS - эхо-конференция FidoNet для обсуждения вопросов развития техноло-
гии и изменения Полиси (только для сисопов);
SYSOPS_CORNER - эха только для сисопов;
SYSTEM? - эхо-конференция поддержки пользователей операционной системы
Macintosh System 7;
S_KING - обсуждение творчества писателя Стивена Кинга.
т
T-MAIL. SUPPORT - международная эхо-конференция поддержки почтовой про-
граммы T-Mail;
TABLATURE - эха для обмена гитарными аккордами в табулированной записи;
TAG - национальная эхо-конференция по поддержке программы BBS T.A.G.;
TAGLINES - эха для распространения забавных фраз, используемых для украше-
ния подписи;
TBBS - эха поддержки BBS Bread Board System (TBBS);
TCPIP - обсуждение вопросов использования протокола TCP/IP;
TEAMOS2 - эха участников группы пользователей OS/2;
TECH - техническая эхо-конференция;
TECH-CHAT - эхо-конференция для разговоров на тему техники;
TEEN - международная подростковая эха;
TEEN_SYSOP - национальная эхо-конференция сисопов-подростков;
TELEMATE - эхо-конференция для обсуждения коммуникационной программы
Telemate;
TEL IX - обмен информацией между пользователями коммуникационной про-
граммы Telix;
TENNIS - эхо-конференция по теннису и аналогичным видам спорта;
TENN__GEN - генеалогическая эхо-конференция обитателей штата Теннеси;
TERMINAT - глобальная эхо-конференция поддержки интегрированной коммуни-
кационной FTN-программы Terminate;
TG_SUPPORT - поддержка программы BBS Telegard;
THDPRO - поддержка программы THD ProScan;
THE-BIBLE - традиционная дискуссия по Священному Писанию;
THEIST_WATCH - эха для рассуждений американских атеистов о религиозной че-
пухе;
THERAPY_SERVICE_DOG - разговоры о терапии, больничном обслуживании;
THE_CURE_NETWORK - разговоры на тему политики и новости для жителей шта-
та Орегон;
TI-ECHO - все, связанное с фирмой «Техас инструменте»;
TOONS - основная анимационная эха;
TORNADO. SUPPORT - эха поддержки программы BBS Tornado;
TRADEWARS - эхо-конференция по обсуждению игр типа «Торговые войны»;
TRADE_WARS - «Торговые войны» и аналогичные on-line BBS-игры;
TRAINS - эха для любителей железнодорожных моделей;
TRANSAMIGA - дискуссия по программам TransAmiga и BBS TransComm;
TRANSCAN - общеканадская эха для болтовни;
TRAPDOOR - поддержка программы TrapDoor;
TRAVEL - национальная и международная эха для путешественников и туристов;
TREK - Star Trek: общее обсуждение;
TREKTECH - Star Trek: техническая дискуссия;
TREK_CREATIVE - международная эха по творениям научной фантастики;
TREK_HUMOR_FILK - Star Trek: юмор и народные песни;
TRIBBS - эха поддержки программы TriBBS;
TRIUS - эха для поддержки и информирования пользователей программ от
Trius, Inc;
TRS-MOD134 - национальная эха по компьютерам Tandy TRS-80;
TUB - помощь и поддержка пользователей эхо-тоссера Squish;
TV - общая дискуссия о телевидении;
TVRO - эха по вопросам приема программ спутникового телевидения.
и
UFGATE - обсуждение методов шлюзования между Usenet и FidoNet;
UFO - эха на тему НЛО;
UNIX - международная UNIX-конференция FidoNet;
USA_EURLINK - эха-линк между США и Европой;
USR_MODEMS - эха по модемам фирмы US Robotics (ныне ЗСОМ);
USR_SPORTSTERS - технические обсуждения модемов USR Sportster.
V
VBBS - поддержка пользователей программы BBS VADV/VBBS;
VEGAN - эха для вегетарианцев;
VEGETARIAN - еще одна эха для вегетарианцев;
VFIDO - техническая поддержка программ VADV/VBBS и VFIDO;
VGA. PLANETS - обсуждения сетевой игры VGA Planets;
VIA_SOFT - обсуждения и поддержка пользователей программ фирмы Via
Software;
VIDEO - эха по видеоиграм;
VID—GAME - эха по домашним консольным видеоиграм;
VIETNAM—VETS - разговоры ветеранов вьетнамской войны;
VIN_MAISON - эха для любителей хорошего вина;
VIRUS - антивирусная дискуссия: способы диагностики, решения;
VIRUS—INFO - еще одна антивирусная дискуссия;
VIRUS_NFO - еще одна альтернативная эхо-конференция, связанная с компьютер-
ными вирусами;
VISUAL_BASIC - международная эхо-конференция по системе программирова-
ния Visual Basic.
w
WATERGATE - поддержка Watergate - почтового тоссера и шлюза между FidoNet
и Internet;
WC4DOS - обсуждение и поддержка BBS WildCat;
WC_TECH - техническая дискуссия по всему, связанному с WildCat BBS, инфор-
мация для сисопов;
WEATHER - национальная погодная эха;
WEB-CONSTRUCT - эха по созданию и дизайну Web-страниц на языке HTML;
WEBUTIL - международная эха по программам для Web;
WELFARE - дебаты о системе социальной поддержки (велфера);
WGW - генеалогический форум «Кто от кого произошел»;
WHAT' S_НОТ! - «Что интересного?»: тематические новости и их обсуждение;
WHITEHOUSE - пресс-релизы Белого дома (только для чтения);
WHITEHOUSE—TALK - обсуждение последних пресс-релизов Белого дома;
WHOLLY—BIBLE - дискуссии по Библии и все, связанное с ней;
WILDCAT - эхо-конференция для сисопов WildCat BBS;
WILDCAT!—SUPPORT - поддержка разработчиков утилит для WildCat BBS и ин-
формация для сисопов;
WILDCAT4 - обсуждение MS DOS версий WildCat BBS до 4-й версии включительно;
WILDCATS - форум для обсуждения и поддержки BBS WildCat BBS версий 5.x;
WIN. SYSOP - поддержка программ BBS для операционной системы MS Windows;
WIN32 - эха по операционным системам Microsoft Win32;
WIN9 5 - эха по операционной системе Windows 95;
WINDOWS - международная эха по Microsoft Windows;
WINDOWS-NT - форум для обсуждения и поддержки пользователей операционной
системы Windows NT;
WINDOWS-NT_BBS - обсуждение и поддержка BBS, работающих под Windows NT;
WIN_ACCESS - помощь пользователям Microsoft Access для Windows;
WNFOSSIL - поддержка пользователей драйвера WinFOSSIL;
WORDS_WORDS - эхо-конференция FidoNet по любым версиям текстового редак-
тора Word;
WORLDTLK - разговоры про текстовый редактор World;
WP-CRAFT - поддержка пользователей редактора WordPerfect;
WPERFECT - обсуждение продуктов семейства WordPerfect;
WRESTLING - борцовская Fido-эха;
WRESTLING_CHAT - эха для разговоров о борьбе;
WRITING - писательская эхо-конференция FidoNet;
WUNDERMENT - анахронизмы, научная фантастика, анархия, фантазия и т.п.;
WWB_SYSOP - эхо-конференция сисопов Всемирного бекбона;
WWB_TECH - техническая эхо-конференция Всемирного бекбона;
WWIV - эха о программе BBS WWIV.
X
X-FILES - обсуждение телесериала «Секретные материалы»;
X00__USER - эха по FOSSIL-драйверу Х00;
XENIA - поддержка почтовой программы Xenia.
Y
YOUNG_ADULT - место для душевных разговоров молодежи.
Z
Z1C - эхо-конференция для связи с координатором первой зоны FidoNet;
Z1_BACKBONE - эхо-конференция для пользователей почтового бекбона первой
зоны;
Z1_CHAT - общий разговор сисопов первой зоны;
ZINFLECTION - эхо-конференция по текущим выборам в первой зоне FidoNet;
Z1_FIDONET - обсуждения системы распространения эх в FidoNet;
22 - 431
Z1_POLITICAL - форум для политических дискуссий в первой зоне FidoNet;
ZCC-DISCUSSION - закрытая эхо-конференция для разговоров членов совета
координаторов зон FidoNet (ZCC);
ZCC-PUBLIC - письма из конференции ZCC;
ZEC - эхо-конференция эхо-координатора первой зоны FidoNet;
ZOOM - поддержка продукции фирмы Zoom Telephonies;
ZYMURGY - эха по приготовлению пива в домашних условиях;
ZYXEL - поддержка модемов фирмы ZyXEL;
{COMMO} - эха по коммуникационной программе Commo.
Приложение VII
Справочник
географического
распределения адресов
FidolUet
Цель настоящего справочника - познакомить читателей с распределением адре-
сов FidoNet по планете и численностью локальных сетей. В приведенной ниже
таблице даны списки местных сетей внутри регионов (стран), упорядоченные по
номеру сети.
Необходимо отметить, что разделить FidoNet в США и Канаде непросто, так
как по историческим причинам образование сети шло в этих странах одновре-
менно и номера местных сетей выдавались вперемешку. Объединены и многие
другие страны. Например, регион 47 второй зоны (Литва) включает Калинин-
градскую область России, а регион 50 (Россия) - некоторые страны Средней
Азии.
Порядок следования зон в справочнике соответствует версии нодлиста второй
зоны, то есть сначала идет вторая зона, а затем первая, третья и далее по порядку.
В таблице не указан полный FidoNet-адрес каждой сети. Для образования та-
кого адреса нужно дополнить номер сети номером зоны. Так, например, для
сети Host__Skaneland, приведенной в табл. П7.1 первой, адрес будет выглядеть как
2:200.
Таблица П7.1. Географическое распределение адресов и численность местных сетей FidoNet
Зона номер 2, Европа и Россия
Регион номер 20 Номер сети , Швеция Всего узлов Название сети Город или местность
200 17 Host_Skaneland Ландскрона
201 39 Capital_Net Стокгольм
203 33 West_Net Западная Швеция
204 25 Central_Net Центральная Швеция
205 21 North_Net Северная Швеция
Регион номер 21 Номер сети , Норвегия Всего узлов Название сети Город или местность
206 23 Host_Malardalen Arboga_Sweden
210 2 Norway_East Bergen_NO
211 2 Norway_West Bergen_NO
212 7 Norway_North Tromsoe_NO
Регион номер 22, Финляндия Номер сети Всего узлов Название сети Город или местность
220 22 GS Хельсинки
221 5 Southern_Finland Южная Финляндия
222 14 Southwest_Fin[and_Net Турку
223 2 East_Net Миккели
224 6 Ostrobothnia_Net Центральная Финляндия
228 12 Northern_Finland Северная Финляндия
Регион номер 23, Дания Номер сети Всего узлов Название сети Город или местность
234 36 Mosquito_Network_Ass. Denmark
236 42 SeaNet_NC Denmark
237 13 FynNet Funen_Denmark
238 87 NC238 Continental_Denmark
Регион номер 24, Германия Номер сети Всего узлов Название сети Город или местность
240 192 Nordnetz Гамбург
241 111 NDS/HB-NET Германия
2410 70 TempHost-Berlin Берлин
2411 61 Brandenburg-NetzJRD] Берлин
244 131 Host_Fidonet_Hessen_ Гессен
245 62 RHEINLAND- Рейн
246 146 PFALZ-SAARLAND_NET United_Network_of_Germany Германия
248 39 FidoNet_Thueringen Эрфурт
249 82 SoxNet Саксония
2426 77 Weser_Ems_Netz Олденбург
2432 101 Ostwestfalen-Lippe-Net Восточная Вестфалия
2433 118 Niederrhein-Net Германия
2435 25 Lahn_Netz Штадталлендорф
2437 109 Netz_2437 Ганновер
2442 33 Westfalen-Netz Вестфалия
2443 66 BGL-Net Германия
2444 62 DO*NET_Ruhr_Ost Восток Рурской области
2446 30 Nieder(st)rhein-NET Удем
2448 131 Ruhr-West Запад Рурской области
2449 58 MS_OS-Network Германия
2450 44 CCAA_Net_Cologne Кельн
2452 29 Host_Altiplex_West Дурен
2453 60 Rhein/Sieg_Net Бонн
2454 74 Host_Mittelrhein-Netz Германия
2455 46 Mostly_Harmless Германия
2457 52 Sued_Westfalen_Net Южная Вестфалия
2461 62 MittelhessenNet_2461 Германия
2464 44 Area_Net_BERGSTRASSE Германия
2465 16 Main-Umland-Net Германия
2468 52 HOST_Rhein-Neckar_Connection Германия
2471 68 WARP-NET Людвигсбург
2474 23 Net_2474 Германия
2476 88 Oberrhein_Net Германия
2480 185 Bavaria_Munich_Net_2480 Мюнхен, Бавария
2483 19 RoNetJR) Германия
2487 82 Schwaben-Netz Ульм
2490 99 Franken_Network Германия
2494 39 Ostbayernnetz Германия
Регион номер 25, Великобритания
Номер сети Всего узлов Название сети Город или местность
250 28 Northern_Net Манчестер
251 3 Solent_Net Англия
252 10 South_Central_Temp_Host Ценральный юг
253 5 South_West_Midlands Англия
254 21 London_Net Лондон
255 15 South West_Net_U К Юго-запад Англии
256 4 Tyne_Tees_&_North-East_UK Северо-восток Англии
257 12 Herts_&_Essex_Net Эссекс
258 7 Net_258 Глазго
259 15 NET259_Host Абердин
440 9 Kent/Surrey/Sussex Кент
442 16 -={Network_Cymru}=- Англия
443 8 —[Northern Jreland]=- Белфаст
2500 4 West_Midlands_&_Welsh_Borders Телфорд
2501 5 Norfolk_&_Suffolk Англия
2502 19 Net2502_Temp_NC Англия
2503 20 The_East_Midlands_Net Восточная Англия
Регион номер 26, Ирландия
Номер сети Всего узлов Название сети Город или местность
263 6 NC Дублин
Регион номер 27, Люксембург
Номер сети Всего узлов Название сети Город или местность
270 19 Luxembourg Люксембург
Регион номер 28, Нидерланды
Номер сети Всего узлов Название сети Город или местность
280 133 Netherlands_Net Северная Голландия
281 35 West_Nederland_Net Западная Голландия
282 30 Temporary_Host Голландия
283 61 NC_Holland_Mid/East Восточная Голландия
284 29 Те m po ra ry_H ost_2 8 4 Голландия
285 36 The_Netherlands_(South/West) Roosendaal
286 26 Temporary_Host Роттердам
500 56 HCC_net Гронинген
2801 13 TotaalNet_Host Amersfoort
2802 17 FreeNet_is_Down Wormerveer
Регион номер 29, Бельгия
Номер сети Всего узлов Название сети Город или местность
292 119 Belgium Бельгия
Регион номер 30, Швейцария
Номер сети Всего узлов Название сети Город или местность
301 131 United_Nets Базель
Регион номер 31, Австрия
Номер сети Всего узлов Название сети Город или местность
310 51 ViennaNet_V.90_Host Вена
313 18 Lower-Austria_Net Клостернбург
314 22 Upper-Austria_Net Линц
315 9 Salzburg_Net_(351) Хален
316 6 Styria Net Баенбах
318 9 FarWest-Austria_Net Люстенау
Регион номер 32, Франция
Номер сети Всего узлов Название сети Город или местность
320 24 Net_Paris_Host_NEC Париж
321 8 Net_Centre Центральная Франция
323 10 Net_Sud-Est Франция
325 10 Net_Est_NC Белфорт
326 14 Net_OUEST Брест
Регион номер 33, Италия
Номер сети Всего узлов Название сети Город или местность
331 39 Alberto_Network Италия
332 63 ltalia_Centro_Nord Болонья
333 40 North-Eastjtaly Северо-восток Италии
334 14 North-Westjtaly Северо-запад Италии
335 74 ltalia_Centro_Sud Центральная Италия
Регион номер 34, Испания
Номер сети Всего узлов Название сети Город или местность
340 5 lslands_Net Испания
341 39 Castilla_Centro Мадрид
342 2 Aragon_NC_temporal Сарагоса
343 7 Xarxa_Catalana Каталония
344 8 Norte_Verde Тудела
345 21 Andalucia_Net Андалузия
346 7 Uevant_net Левант
347 4 llles_Balears Балеарские острова
348 7 Galicia_Net Галиция
349 12 Asturias_Net Астурия
Регион номер 35, Болгария
Номер сети Всего узлов Название сети Город или местность
350 42 SofiaNet София
353 8 North_Net Северная Болгария
356 И Central_Net Центральная Болгария
359 18 VarnaNet Варна
Регион номер 36, Португалия
Номер сети Всего узлов Название сети Город или местность
362 6 NC_362_Centro Португалия
363 7 Douro_&_Minho Португалия
Регион номер 37, Венгрия
Номер сети 370 371 372 Всего узлов 23 47 15 Название сети Tisza_.NET Budapest_NET West_Hungary_.NET Город или местность Венгрия Будапешт Западная Венгрия
Регион номер 38, страны бывшей Югославии
Номер сети Всего узлов Название сети Город или местность
380 64 INES Словения
381 18 CroatiaNet Хорватия
382 31 FIDO_Yugoslavia Югославия
387 5 Bosnia_and_Herzegovina_ Net Босния и Герцеговина
Регион номер 40, Израиль
Номер сети Всего узлов Название сети Город или местность
402 8 DialCode_(02) Иерусалим
403 18 DialCode_(03) Израиль
404 5 DialCode_(04) Северо-запад Израиля
405 12 DialCode_(09) Израиль
406 4 DialCode_(06) Северо-восток Израиля
407 2 DialCodeJ07) Юг Израиля
408 11 DialCode_(08) Средний юг Израиля
Регион номер 41,Греция
Номер сети Всего узлов Название сети Город или местность
411 28 Southem_Hellas Афины
413 21 Macedonia&Thrace_Net Македония
4162 5 SouthWestern_Hellas Юго-западная Эллада
Регион номер 42, Чехия и Словакия
Номер сети Всего узлов Название сети Город или местность
420 29 Prague_Net Прага
421 31 Morava_Net Моравия
422 55 Slava k_NET Братислава
423 50 Czech_NET Чехия
Регион номер 43, Турция
Номер сети Всего узлов Название сети Город или местность
430 3 Link430_Net Стамбул
431 31 Ankara_Net Анкара
432 7 Ege_Net Турция
433 23 Marmara_Net Мармара
Регион номер 45, Беларусь
Номер сети Всего узлов Название сети Город или местность
450 142 Central_Belarus_Net Минск
451 23 Garodnya_Net Гродно
452 57 Gomel_Net Гомель
4521 14 Mozyr__Net Мозырь
4522 6 Svetlogorsk_Net Светлогорск
453 9 Presence_Net Новополоцк
454 22 Fortress_Net Брест
455 16 Mogilev_Net Могилев
457 19 7Hills_Net Витебск
Регион номер 46, Украина и Молдова
Номер сети Всего узлов Название сети Город или местность
460 29 Crimea_Net Ялта, Крым
4600 31 Sebastopol_Net Севастополь, Крым
461 172 Kharkov_Net Харьков
4613 18 Poltava_Net Полтава
4614 15 Sumy_Net Сумы
4615 71 Lugansk_Net Луганск
4616 13 Severodonetsk/Lisitchansk/ Rubezhnoje Северодонецк
462 32 West_Ukraine Львов
4621 27 RivNet Ровны
4623 14 Precarpathian Ивано-Франковск
4624 26 Khmelnitsky_Net Хмельницкий
4625 41 PodolNet Винница
4626 13 Bukovina_Net Черновцы
463 432 Ukraine_Capital[358] Киев
4631 25 North_West_Ukraine Луцк
4632 7 Alexandria_NET Александрия
4633 8 Belaya_Tserkov_Net Белая Церковь
4634 4 Chernigov_Net Чернигов
4635 45 Cherkassy_Net Черкассы
464 133 Dniepr_Net Днепропетровск
4641 35 Zaporozhye_Net Запорожье
4648 10 Meotida_Net Бердянск
4642 31 Krivbcss_Net Кривой Рог
4643 19' Central_Ukraine_NET Кировоград
4646 12 В rezh n evG rad_N et Днепродзержинск
4647 И West_Donbass_Net Павлоград
465 203 EastJJkraine Донецк
4651 16 KramNet Краматорск
4652 14 Makeevka_Net Макеевка
4653 26 Network_Of_Gorlovka Горловка
4654 6 TorNet Славянск
4655 10 Enakievo_Net Енакиево
4656 8 San-Khartcyzsk_Net Харьцизск
4657 20 Mariupol_Network Мариуполь
4658 9 Shakhtersk_Net Шахтерск
466 21 Nikolaev_Net Николаев
4666 16 Transcarpathia Ужгород
467 58 Odessa_Net Одесса
468 29 Kherson_Net Херсон
469 87 Moldova_Net Молдова
Регион номер 47, Литва и Калининград
Номер сети Всего узлов Название сети Город или местность
477 7 IP-net.fidonet.lt Латвия
478 46 West_Russia Калиниград
Регион номер 48 , Польша
Номер сети Всего узлов Название сети Город или местность
480 62 Mazovia_Net Варшава
481 29 WE_PS_[ 1700-0800] Щецин
482 29 West_Net Западная Польша
484 41 Silesia_Net Силезия
Регион номер 49, Эстония
Номер сети Всего узлов Название сети Город или местность
490 50 North_Estonian_Net Таллинн
491 82 Tartu_NET Тарту
Регион номер 50, Россия и страны Средней Азии
Номер сети Всего узлов Название сети Город или местность
5000 94 West_Siberian_Net(323) Новосибирск
5001 34 Kuzbass_Net Кемерово
5002 64 Altai_United_Group Барнаул (Алтай)
5003 81 Komi_Net Сыктывкар (Респ. Коми)
5004 49 Omsk_Net Омск
5005 75 Tomsk_Net Томск
5006 19 Nkz_Net Новокузнецк
5007 15 Khakasian_Net Абакан (Хакассия)
5008 10 Buryatia Улан-Уде (Бурятия)
5009 8 Tambov_NET Тамбов
5010 144 SouthJJral Челябинск
5011 93 Bashkiria Уфа (Башкирия)
5012 35 Kurgan_Net Курган
5013 15 Magnitogorsk_NET Магнитогорск
5014 12 Vologda_Net Вологда
5015 153 NiNoNet Нижний Новгород
5016 6 Kolomna_Net Коломна
5017 17 Sergiev_Posad_NET Сергиев Посад
5018 10 lstra_Net Дедовск (Подмосковье)
5019 23 SkifNet Смоленск
5020 1513 f0.n5020.z2.fidonet.net Москва
5021 30 Tiver_Net Тверь
5022 70 Tula_Net Тула
5023 33 Kaluga_Net Калуга
5024 23 Vladimir_Net Владимир
5025 77 Chernozem_Net Воронеж
5026 51 lvanovo_NET Иваново
5027 22 Orel_Net Орел
5028 26 Goiden_Ring_Net Рыбинск
5029 36 Ryazan_Net Рязань
5030 987 NorthWest_Net Санкт-Петербург
5031 38 Murmansk_Net Мурманск
5032 16 Novgorod_NET Новгород
5033 33 Pskov_Net Псков
5034 6 KosNet Кострома
5035 50 Kursk_Net Курск
5036 34 Lipetsk_Net Липецк
5037 31 Belgorod_Net Белгород
5038 12 Karelia_Net Петрозаводск
5039 5 ArkhNET Архангельск
5040 61 Khabarovsk_Net Хабаровск
5041 17 JAR_Net Биробиджан
5042 10 AmurNet Благовещенск
5043 13 Sakhalin_Net Южно-Сахалинск
5044 4 Klyazma_Net Менделеева
5045 54 Vladivostok-Net Владивосток
5046 12 Pushkino_Net Пушкино
5047 22 Magadan_Net Магадан
5048 14 Syzran_Net Сызрань
5049 77 Tartar_Net Казань (Татарстан)
5050 79 Kama_river_net Ижевск (Удмуртия)
5051 30 Simbirsk_Net Симбирск (Ульяновск)
5052 28 Joshkar-Ola_Net Йошкар-Ола (Мари-Эл)
5053 32 Saratov_Net Саратов
5054 63 West_Ural_Net Пермь
5055 120 Volga_River_Net Волгоград
5056 39 Vyatka_Net Вятка
5057 37 Samara_Net Самара
5058 56 Orenburg JUTC+5h] Оренбург
5059 27 Penza_Net Пенза
5060 24 South_Russia_Net Таганрог
5061 75 Rostov_Net Ростов-на-Дону
5062 15 N ET_Volgodonsk_Russia Волгодонск
5063 60 Kuban_Net Краснодар
5064 30 StavNet Ставрополь
5065 23 Hermit's_Cave Сочи
5066 39 Chuvashia_Net Чебоксары (Чувашия)
5067 12 Adygeya_Net Майкоп
5068 8 CherNet Череповец
5069 16 Astrakhan_Net Астрахань
5070 114 EastSibNet Иркутск
5071 30 Bratsk_Net Братск
5072 7 Aston a_net Астана (Казахстан)
5073 7 Kachkanar_NET Качканар (Россия)
5074 17 Kalm_Net Элиста (Калмыкия)
5075 27 Net_Togliatti Тольятти
5076 15 NadymNet Надым
5077 52 Power_of_Siberia Тюмень
5078 16 TagilNet Нижний Тагил
5079 39 Surgut_Net_(205) Сургут
5080 167 Middle_Ural_NET Екатеринбург
5081 5 North_Kaz_Net(314) Кустанай (Казахстан)
5082 13 Vost_Kaz_Net Восточный Казахстан
5083 40 Kozakstan_NET Алма-Ата (Казахстан)
5084 35 Karaganda_Net Караганда (Казахстан)
5085 50 Uzbekistan_Net Ташкент (Узбекистан)
5086 16 Turkmenistan_Net Ашхабад (Туркменистан)
5087 И Tajikistan_Net Душанбе (Таджикистан)
5088 13 Pavlodar_HAM's_Net Павлодар (Казахстан)
5089 7 South_Kazakhstan_Net Чимкент (Казахстан)
5090 100 CenterSibNet Красноярск
5091 14 Zhezkazgan_NET Джезказган (Казахстан)
5092 7 Pyt-YAkh_Net Пыть-Ях (Тюменская обл.)
5093 47 East_Tartar_Net Набережные Челны (Татарстан)
5094 14 Tyva_Net Кызыл (Тува)
5095 30 Podolsk_Net Троицк
5096 18 Electrostal_Net Электросталь
5097 33 Ukhta_Net Ухта
5098 10 Kirovsk_Net_SPbReg Кировск (СПБ-область)
5099 21 Zhukovsky-Ramenskoe_Net Жуковский (Подмосковье)
6002 6 South_Altai Рубцовск (Алтай)
6033 10 Velikie_Luky_Net Великие Луки
6053 6 Balakovo_Net Балаково
6063 17 Dagestan_Net Махачкала (Дагестан)
Регион номер 51, Латвия
Номер сети Всего узлов Название сети Город или местность
5100 84 Riga_Net Рига
Регион номер 53, Румыния
Номер сети Всего узлов Название сети Город или местность
530 17 Bucharest_Net Бухарест
Регион номер 54, Саудовская Аравия
Номер сети Всего узлов Название сети Город или местность
541 6 Riyadh_Net Эр-Рияд
542 22 Jeddah_Net Джидда
543 8 Dhahran_Net Дахра
Регион номер 55, Internet-регион зоны 2
Номер сети Всего узлов Название сети Город или местность
550 65 fido.nrh.de Internet-сеть зоны 2
Зона номер 1, Северная Амери 1ка
Регион номер 10, Калифорния и Невада (Сан-Диего)
Номер сети Всего узлов Название сети Город или местность
102 57 SoCalNet Лос-Анжелес
103 14 Orange_Co_CA Оранж (Калифорния)
143 18 Silicon_Valley Сан-Хосе
161 6 SF_EAST_BAY Беркли
202 40 San_Diego_Area_Net202_NC Сан-Диего
203 25 Sacramento_Metro_NC Сакраменто
205 13 Fresno/Central_Valley Фресно
208 5 Stockton_Modesto_Area Трейси (Калифорния)
209 9 Vegas_Net Лас-Вегас
211 12 IPNET_NC Сан-Диего (Internet-сеть)
213 8 Northern_Nevada Северная Невада
214 7 San_Joaquin_Valley_Net Висалия
216 4 Monterrey_Bay_Net Монтеррей (Калифорния)
218 19 Pomona_Valley_Net Даймонд-Бар (Калифорния)
219 6 High_Desert_Net Барстоу (Калифорния)
345 26 Pacific_Fido_Region Гонолулу
Регион номер 11, Центр США (Иллинойс, Милуоки, Висконсин и др.)
Номер сети Всего узлов Название сети Город или местность
110 11 DAYTON_Area Дейтон
115 46 Chicagoland_Coordinator Чикаго
120 20 MetroNet Соусфилд
121 6 Madison_Area Медисон
139 16 N.E._WI_&_U.P._MI Эпплтон
154 10 SE_Wisconsin_LATA Милуоки
157 44 Northeast_OH Кливленд
226 8 Buckeye-Net . Колумбус (Индиана)
227 15 Michiana_Net_227 Южная Индиана
228 31 West_Michigan_Fido_Net Западный Мичиган
231 10 Central_lndiana_FidoNet Индианаполис
232 25 CentralJL Пеория (Иллинойс)
233 8 Chambana_Net Урбана (Иллинойс)
236 24 North_Eastern_IN Северо-Вост. Иллинойс
237 13 State_Line_OH/PA Янгстоун
238 7 NC_238_Central_WI Центральный Висконсин
2200 4 Washtenaw_County_MI Япсиланти
2210 5 NET2210 Мериетта
2215 22 Rubber_City/Stark_Net Акрон
2222 6 NE-IL_&_S._Chicago_Suburbs_NC Пригород Чикаго
2231 6 White_River_Valley_Net_NC Округ Колумбуса в Индиане
2255 6 EAST_CENTRAL_IN_NET Андерсон (Индиана)
2320 И Derby_City_Net Луисвилль (Индиана)
2330 7 Jackson_Area_FidoNet Джексон (Милуоки)
2370 5 Lexington_Area Николасвилль
2410 18 Detroit/Wayne_County Округ Детройт
2450 6 Gold_City_Net Редклиф
2470 11 Lenawee_County Адриан (Милуоки)
Регион номер 12, Восточная Канада
Номер сети Всего узлов Название сети Город или местность
163 43 Ottawa_l 63 Оттава
167 29 Ouest_Quebec_West_NC Монреаль
221 6 South_Western_Ontario Ватерлоо
224 3 Sudbury_and_Area__Net Садбюри (Онтарио)
225 13 Near_North_Net Север Онтарио
229 24 Durham_Net Дурхам (Онтарио)
242 4 Laurentides_et_ Mauricie_Qc close_31 -12-99 Лафонтен (Онтарио)
244 18 Hamilton J//entworth_NC Гамильтон (Онтарио)
245 5 Lake_Erie_North_Shore_Net Район севера озера Эри
246 8 Great_Lakes_Central Эссекс и Кент
247 18 Net_247_Coordinator Велланд (Онтарио)
249 23 La ke_O n ta ri o_N et Кингстон (Онтарио)
250 34 Greater_Toronto_Area_Network Торонто
251 8 Nova_Scotia_Net Новая Шотландия
252 5 GTA Коллингвуд (Онтарио)
255 4 NB_PEI_Canada Север Онтарио
2401 6 London_&_Area_Net Лондон (Онтарио)
2404 12 Antelope_Valley_Sanctuary Ланкастер
Регион номер 13, США, Атлантическое побережье (Округ Колумбия и др. штаты)
Номер сети Всего узлов Название сети Город или местность
107 10 MetroNet_of_New_Jersey Итон (Нью-Джерси)
109 52 National_Capital_Area_Net_l 09 Вашингтон
129 26 PittNet Питтсбург
150 4 Delaware_North Глеймонт
260 41 EmpireStateNet Видспорт
261 17 Chesapeake_MetroNet Балтимор и окрестности
262 15 WV_OH_KY_Net Хантингтон
264 15 Mid_Virginia_Net Средняя Вирджиния
265 12 NoVa_SouthWest_Counties Манассас
266 41 51 st_State Нью-Джерси
267 7 Adirondack_Net Квинсбери
268 8 Pocono_Net Каммал
270 28 Central_PA_Net Харрисбург
271 14 Tidewater__VA Хамптон
273 32 Philadelphia_NC Филадельфия
274 9 Central_Virginia_Net Стаффорд (Вирджиния)
275 12 South_Tidewater Вирджиния
278 25 lnterim_NYCnet_Network_Coordinator Бронкс
2600 7 Central_DE Литтл-Крик
2601 6 Northwest_Penn Шарон
2604 22 Net_2604_Coordinator Север Нью-Джерси
2605 И Northern_&_Central_NJ Север и центр Нью-Джерси
2610 6 Indiana/ Westmoreland_County__Host Блайрсвилль
2613 18 Greater_Rochester_Net Рочестер
2619 6 Long_lsland_Network Вестхамптон
2621 3 Southern_VA_Net Денвил
2624 20 Mid_Hudson_Valley_NY Рейнбек
2625 10 Mount_Vernon_NET Маунт-Вернон
2629 3 Shenandoah_Valley_Net Сандерсвилль
2630 13 Eastern_New_Jersey_Net Элизабет (Нью-Джерси)
2700 17 South_Central_PA_Net Йорк
Регион номер 14, средний запад США (Дакота и др.)
Номер сети Всего узлов Название сети Город или местность
100 18 St_Louis_Area Сент-Луис
280 23 Kansas__City_Area_Net Канзас-Сити
282 29 Twi n_Ci ti es_Metro n et Миннеаполис
284 11 Springfield_Area_Net Спрингфилд
285 22 Omaha_Ne_Vicinity_Net Омаха
286 6 The_Far_SW_MO_Net Джоплин
288 7 Dakotas'_Net Кастл вуд
289 12 Mid_Missouri_Net Колумбия (Сред. Миссури)
290 5 Midwest_Xpress Ньютон
292 3 South_Minnesota_Net Рочестер (Миннесота)
293 6 Western_Dakota_Net Северная Дакота
297 6 South_West_Missouri Бренсон (Юг Миссури)
298 6 Hutch_Net Хатчинсон (Канзас)
299 5 JayhawkNET Рассел (Канзас)
2800 4 Mid_Kansas_Net Манхэттен (Канзас)
2808 6 NoDakNet Северная Дакота
2809 12 South_Mid_Missouri_Net Джефферсон (Миссури)
2810 18 Lincoln_Area_Network Линкольн
Регион номер 15, Аризона, Юта, Колорадо
Номер сети Всего узлов Название сети Город или местность
104 Т1 Mile_High_Net_NC Колорадо
114 48 Phoenix_Area Глендейл (Аризона)
128 13 Pikes_Peak_Net Колорадо-Спрингс
300 И Pueblo.NET Тусон (Аризона)
306 4 Northem_CO Север Колорадо
307 5 Pueblo_County_Net Пуэбло (Колорадо)
311 6 NET_311JJTAH Холидей (Юта)
315 10 Weld_County_Net Грили (Колорадо)
Регион номер 16, Новая Англия (Массачусетс, Нью-Гемпшир и др.)
Номер сети Всего узлов Название сети Город или местность
101 10 Metro_Boston_Area Веймут (Массачусетс)
132 11 New_Hampshire_Net Нашуа (Нью-Хэмпшир)
141 36 SW_ConnCentral Сосберри
142 11 Heart_of_CT Везерфилд
320 10 CT_conNEcTions Восток
321 3 MassNet_West Венделл
322 14 MassNet_Central Вебстер
323 10 RI_&_SE_MA__FidoNet_GroupJ226) Варвик
324 3 MassNet_NE_Coord Ловелл
325 2 Green_Mountain_Net Эссекс
326 51 MA1NE_NET Йорк
329 6 SE_Mass_Net Рейнхам
333 19 MA_MetroWest Фрамингам
Регион номер 17, Западная Канада и США
Номер сети Всего узлов Название сети Город или местность
105 31 VanPort_Net Венпорт(Канада)
134 16 Southern_Alberta Калгари (Канада)
138 20 Rainier_Net Округ Пирс (Канада)
140 14 Sask_Net Саскетчеван (Канада)
152 7 Willamette_Valley_Network Канада
153 57 Pacific_Rim_Host Нью-Венсмистер (Канада)
340 11 South_Vancouver_lsland Южный Ванкувер (Канада)
342 20 Central_Alberta Эдмонтон (Канада)
343 15 Lesser_Seattle_Opera Сиэттл (США)
346 5 l.nland_Northwest_Fidonet Срокен (Канада)
348 28 Manitoba_Net Манитоба (Канада)
349 5 Southern_Oregon_Net Южный Орегон (США)
351 7 Central_Vancouver_ls. Центр. Ванкувер (Канада)
353 16 Southem_Jnterior_Net Камлупс(Канада)
357 6 Mid-Willamette_Valley_Net Олбани (США)
3402 3 Oil_Sands_Country Мак-Муррей (США)
3407 6 SE_Washington_Net Вашингтон (США)
3413 18 MidWest_Border_NC Вермилион (США)
Регион номер 18, Юго-Восток США
Номер сети Всего узлов Название сети Город или местность
112 15 Florida's_First_Coast_Net Джексонвилл (Флорида)
116 14 Middle_Tennessee_Net Нэшвилл (Теннесси)
123 12 Mid-South_Net Мемфис (Теннесси)
133 11 Atlanta_Net_NC Куммингс
135 14 South_Florida_Net Майами (Флорида)
137 5 Florida_Suncoast_Net Брадентон (Флорида)
151 4 NC_Net Роли (Северная Каролина)
360 4 Augusta_Net Августа (Джорджия)
361 8 Florida _lndependents_Net Васау (Флорида)
362 17 Chatta-NET_METRO Чаттануга (Теннеси)
363 28 Orlando_DataJnformation_Network Орланде (Флорида)
365 4 North_Central_Fla_Net Окала (Флорида)
366 4 NW_Florida Валтон-Бич (Флорида)
369 15 Treasure_Coast_Net Флорида
371 4 SW_Florida_Coast_Net Форт-Майерс (Флорида)
372 5 Charleston_SC_Net Чарльстон (Юж. Каролина)
374 14 Space_Coast_Net Мельбурн (Флорида)
375 5 Central_Alabama_Net Монтгомери (Алабама)
376 7 Cola_Net Колумбия (Юж. Каролина)
377 20 Temporary_NC_Tampa_Bay_Net Стартанбург (Юж.Каролина)
379 12 CHARLOTTE_AREA_NET Пин-Харбор (Сев. Каролина)
3601 12 Florida_Gator_Net Гайнсвилл (Флорида)
3602 3 Birmingham_Net Бирмингем (Алабама)
3603 9 PinellasNET_3603_Host Глеуотер (Флорида)
3607 3 North_Alabama_Net Куллман (Алабама)
3608 4 Panama_City_Net_Coordinator Линн-Хавен (Флорида)
3609 7 Gator_Net Уэст-Палм-Бич (Флорида)
3612 6 Net_3612__Pensacola_FL_NC Пенсакола (Флорида)
3613 8 Georgia-Alabama_Consolidated_Net Гуссета (Алабама)
3614 6 Jacksonville_NC_Net Джексонвилл (Сев. Каролина)
3615 14 TN_Valley_Net Кноксвилл (Теннесси)
3618 6 West_Vo!usia_FI_Net Делтона (Флорида)
3619 6 West_Pasco_Net Нью-Порт-Ричи (Флорида)
3621 4 Clarksville_Net Вудлав (Теннесси)
3632 6 Jackson_Metro Клинтон (Миссисипи)
3634 12 Fayetteville_Net Санфорд (Сев. Каролина)
3639 4 RI 8JP_&_Orphan_Net_FL Гринвилл (Юж. Каролина)
3651 3 Pee_Dee_NET_&_Rl 8_IP__AL_MI Хартсвилл (Юж. Каролина)
3661 15 Winston-Salem_NET Уистон-Салем (Сев. Каролина)
Регион номер 19, Техас, Оклахома, Аризона, Луизиана
Номер сети Всего узлов Название сети Город или местность
106 36 Houston_Area Хьюстон (Техас)
117 9 Brazos_Valley_Area Центральный Техас
124 27 N124C3P0_Dallas_Metroplex Маккини (Техас)
130 33 The_Cowtown_Net Форт-Уэрт (Техас)
147 11 OKC_MetroNET Оклахома-Сити (Оклахома)
170 30 Tulsa_Area Талса (Оклахома)
380 5 S'port/Bossier_Net Шривпорт (Луизиана)
381 4 West_Texas_Net Эль-Пасо (Техас)
382 16 Capitol_of_Texas_Gerbils Остин (Техас)
385 6 SW_Oklahoma Лаутон (Оклахома)
387 15 San_Antonio_Net Сан-Антонио (Техас)
388 4 Heart_of_Texas_Net_Waco Уэйко (Техас)
393 6 Golden_Triangle_Net Джастин (Техас)
395 9 NC_Central_Texas_&_Fort_Hood Киллин (Техас)
396 14 New_Orleans_Area Нью-Орлеан (Луизиана)
397 10 South_TX/Rio_Grande_Valley_Net Мак-Аллен (Техас)
398 4 Piney_Woods_Net Лонгвью (Техас)
3800 4 Baton_Rouge_Area Батон-Руж (Луизиана)
3802 2 Crossroads_Net Виктория (Техас)
3803 3 Acadiana_Area Лафайет (Луизиана)
3804 3 LubbockNet Лаббок (Техас)
3807 3 LakeArea_Net Вестлейк (Луизиана)
3812 4 Brazoria_County_Net Ричвуд (Техас)
3821 11 Little_Rock_Metro Джексонвилл (Аризона)
3828 16 Causeway_North_Net Мендвилл (Луизиана)
Зона номер 3, Австралия, Новая Зеландия и Полинезия
Регион номер 50, Австралия, Виктория и Тасмания
Номер сети Всего узлов Название сети Город или местность
633 TJ Eastern/Outer_Eastern_Suburbs Мельбурн (Виктория)
634 13 Melbourne's_Friendliest_Net Мельбурн (Виктория)
638 5 Outer_Sth-Eastern_Melbourne Мельбурн (Виктория)
Регион номер 51, Центральная Австралия
Номер сети Всего узлов Название сети Город или местность
800 22 SOUTH_AUSTRALI AN_NET Хампстед-Гаден (Юж. Авст.)
801 11 FLEURIEU_NET Морфетт-Вейл (Юж. Авст.)
850 12 Northern_Territory_Net Дарвин (Сев. Австралия)
Регион номер 54, Тихоокеанское побережье Австралии
Номер сети Всего узлов Название сети Город или местность
712 21 SYDNEY_NET Сидней
713 И SYDNEY_WEST Кернс (Западный Сидней)
714 13 Warringah_Net Ди-Вай (Новый Южный Уэльс)
620 5 Canberra_Net Канберра
623 7 NSW_Country_Net Даббо (Новый Южный Уэльс)
624 13 ILLAWARRA_NET Альбион-Парк (Нов. Юж. Уэльс)
625 3 South_Coast Бейтменс-Бей (Нов. Юж. Уэльс)
626 5 Far_North_Coast_NSW Гуньеллаба (Нов. Юж. Уэльс)
640 26 Northern_Net Брисбен (Квинсленд)
Регион номер 55, Западная Австралия
Номер сети Всего узлов Название сети Город или местность
690 9 The_Golden_State Перт
Регион номер 57, Новая Зеландия
Номер сети Всего узлов Название сети Город или местность
770 20 Christchurch_NET Крайстчерч (Южный Остров)
771 15 Wellington_NET Веллингтон (Сев. Остров)
772 14 AUCKLAND_NET Окленд (Сев. Остров)
774 12 glonet.co.nz Северный Остров
775 15 Taranaki_Net Округ Таранаки
Зона номер 4, Латинская Америка
Регион номер 80, Бразилия
Номер сети Всего узлов Название сети Город или местность
801 6 Rede_Sao_Paulo Сан-Паулу
802 4 Rede_Rio_de__Janeiro Нитерой
804 3 Rede_Santa_Catarina Блюменау
805 5 Rede_Rio_Grande_do_Sul Ново-Гамбурго
806 8 Rede_Brasilia Бразилиа
Регион номер 85, Уругвай
Номер сети Всего узлов Название сети Город или местность
850 И FidoNet_Montevideo Монтевидео
851 9 Regional_Este Мальдонадо
Регион номер 88, Чили
Номер сети Всего узлов Название сети Город или местность
880 12 [NC-880]_Fido-SANTIAGO Сантьяго
881 19 FidoNet-Valparaiso Вальпараисо
Регион номер 90, Аргентина
Номер сети Всего узлов Название сети Город или местность
900 73 TangoNet Буэнос-Айрес
901 39 Red_Gran_Buenos_Aires Темперли (Буэнос-Айрес)
902 11 Red_La_Plata Ла Плата (Буэнос-Айрес)
903 13 NC_Net903 Мар-дель-Плата (Буэнос-Айрес)
904 9 Red_Rosario_y_Zona_de_lnfluencia Росарио (Санта-Фе)
905 16 Red_Litoral Санта-Фе
906 10 Red_Patagonica Патагония
907 4 Red_Mendoza Мендоза
908 6 Red_Cordoba Кордоба
909 5 Red_Punta_Alta Пунта-Альта (Буэнос-Айрес)
Регион номер 97, Мексика
Номер сети Всего узлов Название сети Город или местность
970 3 Red_Mexico_Centro_y_Occidente Мехико
972 13 Red_Mexico_Noroeste Мехико
Зона номер 5, Африка
Регион номер 71, Южно-Африкаская Республика
Номер сети Всего узлов Название сети Город или местность
7102 5 West_Cape_Net Кейптаун
7106 9 Gauteng_Net Претория
Регион номер 72, Зимбабве, Мозамбик, Малави и Маврикий
Номер сети Всего узлов Название сети Город или местность
7211 4 Zimbabwe Хараре (Зимбабве)
7221 3 Mozambique Мапуто (Мозамбик)
7231 3 Malawi Зомба (Малави)
726 4 Mauritius Редут (Маврикий)
Регион номер 73, Кения и Уганда
Номер сети Всего узлов Название сети Город или местность
7311 6 Kenya Найроби (Кения)
7321 7 Uganda Кампала (Уганда)
Регион номер 74, Объединенные Арабские Эмираты
Номер сети Всего узлов Название сети Город или местность
7411 4 United_Arab_Emirates Абу Даби
Регион номер 75, Эфиопия
Номер сети Всего узлов Название сети Город или местность
751 3 Ethiopia Аддис-Абеба
7551 4 Eritrea Асмэра (Эритрея)
Регион номер 76, Замбия
Номер сети Всего узлов Название сети Город или местность
761 4 Zambia Лусака (Замбия)
Регион номер 77, Сенегал, Кот-д'Ивуар, Мали, Камерун, Бенин, Чад
Номер сети Всего узлов Название сети Город или местность
7711 2 Senegal Дакар (Сенегал)
7721 2 Cote_D'lvoire Абиджан (Кот-д'Ивуар)
7741 2 Mali Бамако (Мали)
7751 2 Yaounde Камерун
7781 2 Benin Котону(Бенин)
7791 4 Ndjamena Чад
Регион номер 78, Нигерия, Сьерра-Леоне, Гана
Номер сети Всего узлов Название сети Город или местность
7811 5 GHANA Аккра (Гана)
7831 2 Sierra_Leone Фритаун (Сьерра-Леоне)
7861 7 Lagos_Net Лагос (Нигерия)
Регион номер 79, Французская западная Африка (Тунис, Марокко)
Номер сети Всего узлов Название сети Город или местность
7911 2 Tunisia Тунис
7951 19 Morocco Рабат (Марокко)
Зона номер 6, Азия
Регион номер 60, Сингапур, Индия, Вьетнам, Малайзия, Таиланд
Номер сети Всего узлов Название сети Город или местность
600 131 SINGAPORE_Net Сингапур
609 10 NET_Host Куала-Лумпур (Малайзия)
608 13 Thailand_Net Бангкок (Таиланд)
606 20 lndia_Net Бомбей (Индия)
770 4 Vietnam_Net Ханой (Вьетнам)
Регион номер 61, Гонконг и Макао
Номер сети Всего узлов Название сети Город или местность
700 177 Hong_Kong_Net Гон-Конг
701 29 MACAU_NET Макао
Регион номер 62,Тайвань
Номер сети Всего узлов Название сети Город или местность
720 224 TAIPEI_Net Тайпей
721 39 Tainan_Net Тайнань
722 96 Mid_TAlWAN_Net Тайчунг
723 41 Taoyuan_HUB Чунг-Ли
724 31 Hsin_Chu_Net Цзи-Чу
725 18 Miaoli_Net Майоли
727 25 Kaohsiung_Net Каосинг
728 11 Hualien_Net Хуалинь
Регион номер 63, Япония
Номер сети Всего узлов Название сети Город или местность
730 19 FidoNet_Tokyo Токио
733 4 RockNet Окинава
670 11 GuamNet_HOST_GUAM Гуам
Регион номер 64, Филиппины, Пакистан и Индонезия
Номер сети Всего узлов Название сети Город или местность
750 13 NORTHERN_METRO_MANILA_NET Эрмита (Манила, Филиппины)
751 33 SOUTHERN_METRO_MANILA_NET Макати (Манила,Филиппины)
758 2 lndonesia_Net Индонезия
759 6 Pakistan Пакистан
Регион номер 65, , Китай
Номер сети Всего узлов Название сети Город или местность
650 9 Beijing_Net Бейянь
651 8 NorthEastChina_Net Шеньян
652 3 Hebei_Net Шацзячжуан
653 12 EastChina__Net Наньян
654 . 10 Shanghai_Net Шанхай
655 27 Guangdong_Net Ханчжоу
656 14 SouthwestChina_Net Ченду
657 5 Fujian_Net Цзиань
658 4 Guangxi_Net Биньянг
659 5 HaiNan_Net Хейкоу
660 5 ZheJiang_Net Нингбо
662 8 HeNan_Net Чженчжоу
663 7 Hubei_Net Ухань
Регион номер 66, Южная Корея (Сеул)
Номер сети Всего узлов Название сети Город или местность
760 8 Taehan_Net Сеул
ПрЕшиэжение VIII
Справочник
Web-серверов,
посвященных FidoNet
Сеть FidoNet хорошо представлена в сети Internet, что закономерно - FidoNet, как
и Internet, всемирная компьютерная сеть. Долгое время, до стремительного роста
популярности Internet в начале 90-х годов, именно эти сети приводили в качестве
примера самых крупных глобальных сетей. Кроме того, существенно, что многие
участники FidoNet имеют доступ в Internet по долгу службы и по роду занятий.
Поэтому Web-страниц, посвященных FidoNet, как сети в целом, так и ее отдельных
территориальных сегментов, в Internet очень много. Поиск по слову «FidoNet» на
популярных поисковых системах Internet дает от 16000 (www.lycos.com) до 89000
(www.altavista.com) совпадений. Как и многие другие сервисы FidoNet, любые
Internet-ресурсы, посвященные сети Fido, не являются чем-то раз и навсегда дан-
ным и абсолютно устойчивым, поскольку поддерживаются усилиями энтузиастов
и зависят от их возможности продолжать однажды начатое дело.
Настоящий справочник содержит небольшое количество ссылок на FTP-, News-
и Web-сайты, посвященные FidoNet, причем для представления отобраны сервисы
с многолетней историей. Можно надеяться, что большинство из них просуществует
еще по крайней мере несколько лет. При составлении списка был использован ре-
гулярно публикуемый в FidoNews список «Сайты, связанные с FidoNet» (“Fido-
Related Sites”), составляемый Джо Джаредом (Joe Jared, адрес в FidoNet 1:103/301),
а также «Список Web-сайтов русскоязычного FidoNet» Тимура Цыганко, ежене-
дельно публикуемый в эхе FIDONET. HI STORY, и другая информация из эхо-кон-
ференций FidoNet, представленная на Web-серверах в Internet. Ссылки на адреса
сайтов, посвященные российскому Fido, даны более подробно и дополнены указа-
нием географического положения сети, которой посвящен данный сайт. Все адреса
перед публикацией были проверены на существование в Internet.
Web-серверы, посвященные FidoNet
Общие для всей FidoNet Web-ресурсы
http://www.fidonet.org - центральный Web-сервер FidoNet.
http://www.fidonews.org - Web-сервер FidoNews.
ftp://ftp.nwstar.coni/fidonet/fidonews/ - архивы FidoNews.
ftp://ftp.sstar.com/fidonet/fnews/ - архивы FidoNews.
http://www.ftsc.org - сервер FTSC.
ftp://ftp.ftsc.org - архивы FTSC.
http://www.osirusoft.com/fidoip.html - список узлов, доступных через Internet.
http://owls.com/4errys/fidonet.html - описание FidoNet.
http://www.fidonews.org/fidoring/ - «кольцо» Web-серверов FidoNet.
http://home.nrh.de/fido/ - доступ к Fido через Internet.
Ресурсы FidoNet по зонам, регионам и сетям
Первая зона
http://www.zl .fidonet.org - сервер первой зоны FidoNet.
http://members.xoom.com/echolist/ - эхо-лист первой зоны.
http://www.psnw.com/~net205/regionl0.html - регион 10.
http://www.tnl-online.com/andy/rgn 10.htm - регион 10:
http://www.webworldinc.com/clubl03/ - сеть 103;
http://www.geocities.com/Area51/8687/net203index.html - сеть 203.
http://oeonline.com/~garyg/regionll/ - регион И:
http://oeonline.com/~garyg/net2410 / - сеть 2410.
http://sparkys.dyndns.org - регион 12.
http://www.net264.org/г 13.htm - регион 13:
http://www.net264.org/ - сеть 264;
http://www.homershut.net/~mahoover/net275/ - сеть 275.
http://www.rxn.com/~net282/ - регион 14, сеть 282.
http://www.nwstar.com/~regionl7/ - регион 17.
http://techshop.pdn.net/fido/ - регион 18.
http://members.home.net/hbh3/rl9 - регион 19:
http://www.startext.net/пр/net 124 - сеть 124;
http://texoma.net/~flv - сеть 124;
http://www.startext.net/homes/net 130 - сеть 130;
http://www.chatter.com/~wb/ - сеть 393.
Вторая зона
http://www.z2.fidonet.org - сервер второй зоны FidoNet.
ftp://ftp.sstar.com/fidonet/zone2 - нодлисты и другая информация.
Странички регионов второй зоны
http://www.fidonet.pp.se (на шведском языке) - регион 20.
http://www.fido.dk (на датском языке) - регион 23.
http://www.swb.de/personal/flop/gatebau.html (на немецком языке) - регион 24.
http://www.literary.freeserve.co.uk/net2502/ - регион 25.
http://www.nemesis.ie - регион 26:
http://www.nrgsys.com/orb - эхо-координатор региона 26.
http://telematique.org/ft/r27.htm - регион 27.
http://www.rtfm.be/fidonet/ (на французском языке) - регион 29.
http://www.fidonet.ch (на немецком языке) - регион 30.
http://www.fidoitalia.net (на итальянском языке) - регион 33.
http://www.pobox.com/cnb/r34.htm (на испанском языке) - регион 34:
http://www.geocities.com/SiliconValley/4552/ - эхо-координатор региона 34.
http://www.geocities.com/SiliconValley/7207/ - регион 36.
http://public.st.carnet.hr/~blagi/bbs/adriam.html - регион 38.
http://www.fidonet.gr - регион 41.
http://www.fido.cz - регион 42,
http://www.belarus4you.com/fido/ - регион 45 (Беларусь).
Регион 50 (Россия)
Общие ресурсы
http://www.fido7.com/ - регион 50 (Россия).
Конференции Fido7.* в Usenet:
http://www.fido7.ru/;
nntp://news.fido7.ru;
nntp://ddt. demos, su.
http://www.netclub.ru/~tim/fidolink.htm - список русских Web-сайтов FidoNet.
http://www.netclub.ru/~tim/faq.htm - FAQ из эхи FIDONET. HISTORY.
http://www.prospect.com.ru/~fidorus/ - страничка IRC-канала #FIDORUS.
http://www.init.ru/fido/ - страничка Бориса Палеева о FidoNet.
http://www.coca.com2com.ru/fido/ - «FidoNet для идиотов».
http://www.spektrum.org.ru/fido/ru/main.htm - чтение конференций Fido через
WWW.
ftp://ftp.lexa.ru/pub/fido/ - хранилище старых нодедиффов, начиная с nodelist. 144-
1991.
http://www.wolf.ru/fido.html - подборка информации о российском FidoNet.
http://www.cl.spb.ru/fido7/fido7.htm - все о гейтовании Fido-Internet.
http://hf.kru.to/ - официальный архив эхо-конференции HUMOR. FILTERED.
http://www.geocities.com/Paris/Rue/8306/ - официальная страничка эхо-кон-
ференции PVT. FLIRT.
Местные сети региона 50 второй зоны
http://www.n5000.z2.fidonet.net/ - сеть 2:5000 (Новосибирск).
http://aug.da.ru/ - сеть 2:5002 (Алтай).
http://www.komi.com/fido/ - сеть 2:5003 (Коми).
Сеть 2:5006 (Новокузнецк):
http://nkzfido.nkuz-gts.kemerovo.su/;
http://www.svzserv.kemerovo.su/main/misc/fido/;
http://www.kuzbass.ru/main/misc/fido/.
http://www.fido5009.da.ru/ - сеть 2:5009 (Тамбов).
http://www.n5010.z2.fidonet.net/ - сеть 2:5010 (Челябинск).
http://www.magnitka.ru/~shtirl/FIDO/index.html - сеть 2:5013 (Магнитогорск).
http://www.n5014. z2.fidonet.net/ - сеть 2:5014 (Вологда).
http://www.n5015.z2.fidonet.net/ - сеть 2:5015 (Нижний Новгород).
http://dedowsk.da.ru/ - сеть 2:5018 (Дедовск).
http://fido.tcbank.ru/ - сеть 2:5021 (Тверь).
http:// www i vano vo. su/КО LOBO К/ - сеть 2:5026 (Иваново).
http://www.fido.oryol.ru/ - сеть 2:5027 (Орел).
http://5028.yaroslavl.ru/ - сеть 2:5028 (Рыбинск).
http://kenga.ru/fido/ - сеть 2:5030 (Санкт-Петербург).
http://allspbftn.virtualave.net/ - весь Санкт-Петербургский FTN.
http://www.sinaps.ru/free-ip/denisp/ - сеть 2:5033 (Псков).
http://www.gas.lipetsk.ru/DAK/FidoNet/ - сеть 2:5036 (Липецк).
http://atv.karelia.ru/fido/ - сеть 2:5038 (Петрозаводск).
http://www.ussuriisk.ru/fido/ - Fido в Уссурийске (5045/17 и другие).
http://www.fido7.syzran.ru/ - сеть 2:5048 (Сызрань).
http://www.n5049.z2.fidonet.org/ - сеть 2:5049 (Казань).
http://www.vspu.ru/fido/ - сеть 2:5055 (Волгоград).
http://www.vspu.kirov.ru/~dmitry/Fido/INDEX.HTM - сеть 2:5056 (Вятка).
http://fido.hippo.net/ - сеть 2:5057 (Самара).
http://www.n5058.z2.fidonet.net/ - сеть 2:5058 (Оренбург).
http://www.penza.com.ru/fido/ - сеть 2:5059 (Пенза).
http://www.init.ru/fido/5060/index.html - сеть 2:5060 (Таганрог).
http://www.magnet.novoch.ru/fido/ - сеть 2:5061 (Новочеркасск, часть 2:5061).
http://www.rosnpp.vdonsk.ru/fido/ - сеть 2:5062 (Волгодонск).
http://minvody.cmw.ru/homepages/fido/ - сеть 2:5064 (Минеральные Воды,
часть 2:5064).
http://www.fido.chuvashia.com/ - сеть 2:5066 (Чувашия).
http://www.fido.esib.ru/ - сеть 2:5070 (Иркутск).
http://fido.rely.ru/ - сеть 2:5075 (Тольятти).
http://www.n5080.z2.fidonet.net - сеть 2:5080 (Екатеринбург).
http://www.karaganda.kz/fido/ - сеть 2:5084 (Караганда).
http://fido.ktk.ru/ - сеть 2:5090 (Красноярск).
http://www.n5095.z2.fidonet.net/ - сеть 2:5095 (Подольск, Троицк).
Третья зона
http://www.z3.fidonet.org - сервер третьей зоны.
Четвертая зона
http://fidobrasil.8m.com - регион 80.
http://members.tripod.com/~net904 - регион 90, сеть 904.
Шестая зона
http://www.z6.fidonet.org - сервер шестой зоны.
http://www.cfido.com/fidonet/cfidochina.html - регион 65.
Приложение 1ЭС
Правила выборов
сетевых координаторов
региона 50 сети FidoNet
Настоящее приложение содержит перевод документа NC_ELECT, регламентиру-
ющего процедуру выборов сетевых координаторов во второй зоне FidoNet. При
публикации сохранены все особенности оригинала; внесенные исправления каса-
ются только оформления текста.
FidoNet Zone 2 document NC_ELECT.Z2
Vl.O 05 Mar 1995 by Keith Wassell (RC/25) and Jan Vermeulen (RC/28)
Перевод на русский язык Дмитрия Морозовского (Dmitry Morozovsky, 2:5020/
268) и Максима Кочегарова (Maxim Kochegarov, 2:5021/8)
14 Jan 1997
Внесенные исправления одобрены Дмитрием Бароновым (Dmitry Baronov,
2:5020/80, R50C) 08 1998
Введение
Данные правила проведения выборов дополняют, но не заменяют правила, содер-
жащиеся в действующем уставе FidoNet.
Они предназначены для использования в ходе выборов сетевых координаторов
(NC) второй зоны FidoNet.
1. Проводящий выборы (returning officer)
Проводящего выборы (RO) назначает региональный координатор. Он же выби-
рает какой-либо узел FidoNet для проверки результатов (Vote Checker, VC), кото-
рому RO будет пересылать все голоса, кандидатуры и т.п. В выборах принимают
участие все узлы сети, не имеющие префиксов HOLD или DOWN на момент объяв-
ления голосования. Если HOLD/DOWN-узел возвращается к нормальному функ-
ционированию до начала голосования (и при этом существует в сегменте сети, оп-
ределенном RO на момент объявления голосования), то он имеет право голоса.
Выборы проводятся по принципу: 1 сисоп - 1 голос, то есть вне зависимости от
количества узлов сети, на которых человек является сисопом, от него принимает-
ся один голос.
При объявлении голосования RO явно указывает номер нодлиста, который
будет использоваться для определения электората (например, Nodelist. 147).
RO крайне желательно уведомить нетмейлом о голосовании все узлы сети, име-
ющие право голоса. В связи с объемами этой процедуры может применяться
routed нетмейл или другие схемы по согласованию с RC, однако предпочтителен
CRASH/DIRECT нетмейл.
Дальнейшая работа RO по организации голосования может проводиться в си-
сопской конференции сети. Узлы, не поддерживающие FTS-004 и желающие при-
нять участие в обсуждении кандидатов и т.п., должны договориться о получении
доступа к этой конференции на другом узле или BBS.
Проводящий выборы объявляет победившего кандидата, который после под-
тверждения правильности результатов голосования проверяющим и утверждения
результатов региональным координатором становится новым NC.
Когда это возможно, RO не должен принадлежать к сети, в которой проводятся
выборы, для обеспечения беспристрастности.
Узлы RO и VC не могут иметь префиксов HOLD, DOWN или PVT. Круглосу-
точный режим работы (СМ) желателен, но не является обязательным.
В случае, если более 10% узлов сети возражают Против кандидатуры RO или
проверяющего, региональный координатор должен назначить нового RO/VC.
Однако все отводы должны быть получены в течение семи дней после объявления
выборов. Сроки голосования корректируются на момент объявления нового RO.
2. Кандидаты
Кандидатом может быть любой сисоп сети, за исключением представленных толь-
ко узлом(ами) с флагом PVT в соответствующем сетевом сегменте nodelist.
От кандидата не требуется какого-либо опыта координаторской работы в FidoNet,
однако желательно, чтобы он являлся сисопом узла FidoNet не менее шести меся-
цев и был хорошо знаком с процедурами и официальными документами FidoNet.
Требования к программно-аппаратному обеспечению узла кандидата не опреде-
ляются. Круглосуточный (СМ) режим работы узла желателен, но не обязателен.
Кандидаты должны присутствовать в списке узлов FidoNet (Nodelist) без пре-
фиксов HOLD или DOWN.
Кандидаты должны иметь опубликованный в нодлисте номер телефона.
Кандидаты сообщают узлу, проводящему выборы, о своем желании баллотиро-
ваться. Кандидат может, но не обязан, представлять свою «предвыборную про-
грамму».
Включенный в официальный список кандидат может объявить о снятии своей
кандидатуры не позднее чем за сутки до момента начала голосования.
Если к началу обсуждения не остается ни одного согласного баллотироваться,
выборы отменяются, решение о дальнейшем функционировании сети принима-
ется региональным координатором.
3. Сроки выборов
Выборы должны быть проведены в шестинедельный срок: первые две недели пре-
доставляются для (само)выдвижения кандидатов, следующие две - для их обсуж-
дениями, наконец, последние две - собственно для голосования.
Обсуждение кандидатов желательно проводить в сетевой сисопской конферен-
ции. Иссоп узла, не поддерживающего FTS-004, разумеется, может использовать
нетмейл.
4. Голосование
Все голоса должны передаваться RO нетмейлом и, если технические проблемы не
препятствуют этому, прямым соединением (DIRECT).
Правила оформления голосов определяются RO при объявлении процедуры
выборов, а также непосредственно перед началом голосования. Желательно, что-
бы эти правила были доставлены нетмейлом всем узлам, имеющим право голоса.
Форма для голосования должна предусматривать возможность использования
пароля, который публикуется в общем протоколе для проверки правильности уче-
та голосов. Использование пароля не является обязательным; в случае его от-
сутствия в соответствующем итоговом протоколе такие голоса помечаются «по
password» или аналогичным образом.
Голосующему нетмейлом должно быть послано письмо с результатами обработ-
ки его голоса.
В качестве вариантов при голосовании допускается либо определяемое RO обо-
значение, однозначно идентифицирующее кандидата, либо обозначение «против
всех кандидатов». Голос, не содержащий таких обозначений или содержащий их
более одного, признается недействительным, о чем сообщается в письме с резуль-
татами обработки.
Никакая информация о результатах голосования до его окончания не публи-
куется.
Если один или несколько включенных в официальный список кандидатов от-
казываются баллотироваться в течение периода приема голосов, поданные за них
голоса переголосованию не подлежат и признаются действительными наравне
с другими. При подведении итогов эти голоса отражаются в итоговом протоколе
как «голоса за кандидатов, снявших кандидатуры в ходе голосования». О каждом
факте снятия кандидатуры RO должен незамедлительно сообщить в сетевой си-
сопской эхо-конференции.
Если к началу или в ходе голосования в официальном списке не остается ни
одного кандидата, выборы отменяются, решение о дальнейшем функционирова-
нии сети остается за региональным координатором.
Снятие кандидатуры после завершения приема голосов не влечет за собой пе-
ресчета голосов и изменение итогового протокола.
5. Определение победителя
Победитель голосования, определенный по правилам, описанным в данном пунк-
те, должен быть утвержден региональным координатором.
Выборы признаются состоявшимися при любом количестве проголосовавших.
Победителем на выборах считается кандидат, набравший более 50% признанных
действительными голосов. Если число голосов, поданных против всех кандида-
тов (none of the above), превышает число голосов, поданных за каждого из канди-
датов, победитель на выборах не объявляется, результаты выборов направляются
региональному координатору для принятия решения о функционировании сети
по его усмотрению.
Если ни один из кандидатов не набрал необходимого количества голосов, пос-
ле недельного перерыва происходит повторное голосование. Продолжительность
повторного голосования - две недели. В список для повторного голосования
включаются два кандидата, набравшие наибольшее количество голосов. Голоса,
поданные в первом голосовании «против всех кандидатов», не учитываются. Если
на включение в список претендуют несколько кандидатов с одинаковым числом
голосов, то в список включаются все такие кандидаты. При условии снятия вклю-
ченным в список кандидатом своей кандидатуры в течение недельного перерыва
между голосованиями, его место занимает следующий из кандидатов в порядке
убывания голосов с соблюдением тех же правил выбора.
Если к началу повторного голосования в списке остается один кандидат, по-
вторное голосование не проводится, оставшийся кандидат признается победите-
лем на выборах.
Повторное голосование проводится по тем же правилам, за исключением голо-
сования за «попе of the above»; голоса против всех кандидатов не допускаются.
Победитель определяется простым большинством голосов.
6. Результаты
Результаты желательно опубликовать в следующем или аналогичном виде:
Candidate : - Ivan Sidorov 6 Votes
Passwords : - Passwordl , Passwords , Passwords , Password4
Candidate : - Sidor Ivanov 4 Votes
Passwords : - Passwordl , Passwords , Passwords , Password4
В случае, если для сбора голосов используются специальные программы, опуб-
ликованы должны быть только указанные выше данные.
Полные результаты выборов (то есть данные о том, кто за какого кандидата го-
лосовал) не должны публиковаться.
Вообще говоря, исключаются действия, способные повлечь за собой преследо-
вания какого бы то ни было сисопа, основанные на его выборе или его неучастии
в голосовании1.
1 В оригинале использовано слово recrimination, что, наш взгляд, ошибочно; более вероятно - repres-
sion/discrimination. - Прим, переводчиков.
Результаты должны быть отправлены как минимум:
□ нетмейлом всем кандидатам;
□ в соответствующие сисопскую/координаторские конференции.
7. Срок полномочий
Срок полномочий сетевого координатора не должен превышать два года. Разуме-
ется, сменяемый NC может выставить свою кандидатуру на следующий срок,
предварительно подав в отставку (см. пункт 8).
Сменяемый NC не имеет права назначать своего последователя.
8. Нехватка кандидатов
При завершении двухлетнего срока своих полномочий текущий NC должен по-
дать в отставку. При желании продолжать координаторскую деятельность NC
может выставить свою кандидатуру на предстоящие выборы.
Если на выборы представлен только один кандидат, он автоматически стано-
вится координатором, за исключением случая, когда данный сисоп был только что
снят с поста по причине неспособности должным образом выполнять свои коор-
динаторские обязанности; в этом случае действует вариант «отсутствие кандида-
тов» (см. ниже).
Если на выборы не представлено ни одного кандидата, решение о дальнейшем
функционировании сети принимает RC.
Приложение X
Эхо-Полиси региона 50
второй зоны FidoNet
Версия: 1.0, 13 сентября 1994 г.
Дата принятия: 10 октября 1994 г.
1. Введение
1.1. Цель данного документа
Данный документ устанавливает политику и процедуры распространения эхо-
почты в рамках региона 50, а также порядок взаимодействия между участниками
системы распространения эхо-почты (регионального бекбона).
В документе рассматривается только региональный уровень распространения
эхо-почты - функционирование сетевых бекбонов может регулироваться сетевы-
ми Эхо-Полиси.
Действие данного документа распространяется на все узлы, которые изъявили
желание пользоваться услугами бекбона для получения эхо-почты.
В сетях региона могут действовать сетевые Эхо-Полиси, не противоречащие
общей Полиси FidoNet. Эхо-конференции сети, принятые на региональный бек-
бон, подчиняются Эхо-Полиси региона. Если сетевая Эхо-Полиси отсутствует, то
в сети действует Эхо-Полиси региона.
Данный документ не является частью FidoNet Полиси. Если какая-либо часть
этого документа вступает в противоречие с действующей Полиси, то действует
соответствующее положение Полиси.
1.2. Определения
Эхо-мейловая конференция - это совокупность сообщений, распространяемых
под определенным именем конференции (Areatag) и связанных с определенной
областью интересов.
Региональный бекбон - это структура распространения эхо-почты, координи-
руемая региональным эхо-координатором. Бекбон состоит из узлов, участвующих
в распространении эхо-почты, признающих данный документ и получивших от
регионального эхо-координатора статус эхо-хаба.
Сетевой бекбон - структура, аналогичная региональному бекбону, существую-
щая на уровне сети и координируемая сетевым эхо-координатором (NEC).
Региональный эхо-координатор (REC) - лицо, координирующее распростра-
нение эхо-почты и соблюдение данного документа в регионе.
Сетевой эхо-координатор (NEC) - лицо, координирующее распространение
эхо-почты и соблюдение данного документа в своей сети.
Эхо-хаб - узел, который распространяет эхо-почту на другие сети/узлы. Реги-
ональные хабы распространяют эхо-почту на региональном уровне. Сетевые эхо-
хабы - на уровне сети. В дальнейшем эхо-хабы будут именоваться хабами.
1.3. Региональный бекбон
Участие в эхо-мейловом бекбоне региона 50 является добровольным. Хабы, узлы
и модераторы, принимая участие в работе бекбона, соглашаются выполнять про-
цедуры и предоставлять сервис, описанные в данном документе.
Сервис, предлагаемый региональным бекбоном, является дополнением к тому,
который обязателен для членов FidoNet согласно Полиси FidoNet. Использова-
ние этого сервиса следует рассматривать как привилегию, а не как право.
Хотя участники регионального бекбона стремятся обеспечить наилучший сер-
вис в распространении эхо-почты, никакие гарантии не оговариваются.
2. Функционирование на региональном уровне
2.1. Обязанности
регионального эхо-координатора
Региональный эхо-координатор контролирует работу бекбона на региональном
уровне. В его обязанности входит:
□ определение структуры и состава регионального бекбона и поддержка его
нормального функционирования;
□ ведение списка конференций, принятых на региональный бекбон и временно
снятых с него;
□ ведение списка модераторов конференций регионального бекбона;
□ определение текущих ограничений, действующих при принятии конферен-
ций на бекбон (см. раздел 4.3);
□ определение перечня FTSC, обязательных для соблюдения на региональном
бекбоне, а также допустимого объема необязательной служебной информа-
ции в сообщениях;
□ разработка и обеспечение совместно с региональными хабами аварийного
плана, который используется в случае возникновения непредвиденных про-
блем у региональных хабов. у
2,2. Выборы регионального координатора
Региональный эхо-координатор выбирается из числа системных операторов уз-
лов FidoNet региона 50 тайным голосованием RC, NC, NEC и региональных эхо-
хабов. При совмещении одним человеком нескольких функций действует прин-
цип: один человек - один голос. Выборы проводятся, если произойдет одно из
следующих событий:
□ должность REC окажется вакантной;
□ более одной четверти людей, имеющих право голоса при выборах REC, по-
требуют проведения досрочных выборов и со времени последних выборов
пройдет более шести месяцев;
□ RC потребует проведения досрочных выборов и со времени последних выбо-
ров пройдет более шести месяцев;
□ пройдет более двух лет со времени последних выборов.
Предусмотрен следующий порядок выборов REC. RC назначает ответственного
за сбор кандидатур и проведение голосования из числа лиц, имеющих право голо-
са. В течение трех недель с момента объявления выборов происходит выдвижение
кандидатур. Возможно самовыдвижение кандидатов. От каждого из кандидатов
должно быть получено письменное согласие на участие в выборах. Ответствен-
ный за проведение выборов регистрирует кандидатов и сообщает о них в регио-
нальной технической эхо-конференции.
Голосование проводится в течение двух недель. Кандидат считается избранным,
если он набрал большее число голосов, нежели остальные кандидаты. Если наи-
большее число голосов получили несколько кандидатов, то RC назначает регио-
нальным эхо-координатором (REC) одного из них. Вновь избранный REC счита-
ется приступившим к своим обязанностям с момента опубликования результатов
голосования в региональной технической эхо-конференции.
Если к моменту начала выборов должность REC оказалась вакантной, то на
время проведения выборов RC назначает одного из сетевых эхо-координаторов
(NEC) региона исполняющим обязанности REC.
Порядок выборов (или назначения) NEC определяется Эхо-Полиси сети, если
таковая существует. При ее отсутствии применяется процедура, аналогичная опи-
санной выше.
2.3. Региональные хабы
REC определяет (утверждает) региональных хабов для распределения эхо-почты
на региональном уровне. REC может одновременно являться региональным ха-
бом, если он этого пожелает.
Каждый региональный хаб обеспечивает минимум одну межсетевую связь.
Каждый региональный хаб делает доступными все конференции бекбона и файл-
эху R5 0-BONE для передачи на сетевой уровень распространения. Однако никто
не вправе требовать от хаба распространения какой-либо конференции, если это
превышает его экономические возможности.
Региональные хабы обязаны поддерживать аварийный план, который исполь-
зуется в случае появления непредвиденных проблем у одного из них.
2.4. Взаимодействие с координаторами FidoNet
Эхо-координаторы и сисопы хабов бекбона являются узлами FidoNet и выполня-
ют все решения координаторов FidoNet. Координаторы FidoNet не вмешиваются
в деятельность эхо-координаторов и сисопов хабов бекбона, пока эта деятельность
не нарушает функционирование сети или региона. В случае возникновения кон-
фликтные ситуации разрешаются вышестоящим координатором FidoNet.
3. Модераторы конференций
Модераторы конференций председательствуют в конференциях. Участники бек-
бона не должны вмешиваться во внутренние дела конкретной конференции, пока
это не мешает функционированию бекбона. Модератор не обязан быть членом
FidoNet.
3.1. Признание модераторов
Модератор признается следующим образом:
□ при создании конференции человек, создавший конференцию, является мо-
дератором;
□ при отставке или замене существующего модератора выбор нового модерато-
ра определяется объявленными правилами конференции;
□ модераторы и ко-модераторы (если таковые существуют) перечисляются
в списке конференций бекбона, что служит для хабов руководством при по-
лучении необходимой для них информации.
Поощряется назначение модераторами ко-модераторов для помощи и замены
модераторов на время отсутствия.
3.2. Обязанности модераторов
Модераторы отвечают за следующий круг вопросов:
□ сообщение действительного нетмейлового адреса для помещения в список
признанных конференций, по которому к ним можно обратиться через
FidoNet;
□ просмотр сообщений в их конференциях на предмет соответствия теме и пра-
вилам конференции;
□ отсутствие в их конференциях нелегальной информации или содействия не-
легальной деятельности;
□ посылку в конференцию правил по крайней мере раз в месяц.
Если модератор определит, что узел постоянно нарушает правила конферен-
ции, он может потребовать, чтобы связь для этого узла была отрезана. Такое тре-
бование с перечнем нарушенных правил конференции оформляется в виде нет-
мейл-сообщения на хаб, снабжающий виновный узел, и посылается вместе с копией
провинившемуся узлу. После проверки наличия модератора в списке признанных
конференций хаб отрезает связь.
В случае невыполнения хабом директивы модератора, последний может потре-
бовать, чтобы этот хаб был отрезан и т.д. Такое требование оформляется в виде
нетмейл-сообщения хабу, снабжающему хаб, противодействующий модератору,
вместе с копией хабу, не выполнившему требование модератора, и соответствую-
щему эхо-координатору. После проверки информации хаб отрезается от данной
конференции.
Узел, отключенный модератором от конференции, не имеет права подписывать-
ся на эту конференцию до оговоренного срока ни на одном узле. Невыполнение
этого требования является основанием для полного отключения виновного узла
от бекбона по решению соответствующего эхо-координатора.
4. Другие функциональные процедуры
4.1. Технические области
Для ведения дел бекбона используются эхо-конференции R5 0 . BONE и R5 0 . HUBS.
R50 . BONE открыта для любого узла, имеющего дела с бекбоном. R50 . HUBS ог-
раничена для использования на региональном и сетевом уровне координаторами
бекбона и хабами. REC является модератором обеих конференций.
4.2. Технические стандарты сообщений
Перечень технических требований к конференциям (используемые стандарты и т.д.)
определяется REC и распространяется им по файл-эхе R50-BONE.
Бекбон не поддерживает пересылку зашифрованных сообщений (за исключе-
нием использования цифровых подписей).
Пересылка двоичных файлов, закодированных с помощью UUENCODE, ВТОА
и т.д., должна регламентироваться правилами конкретной эхо-конференции.
Хабы могут уничтожать сообщения, которые не удовлетворяют техническим
стандартам, когда такие сообщения могут нанести вред техническим операциям
бекбона. К ним относятся дублированные сообщения и сообщения в эхо-почте
с возрастом более 20 дней. Такие сообщения обычно не возвращаются.
Хабы функционируют в защищенном режиме. Это означает, что они автомати-
чески обрабатывают сообщения только от тех узлов, с которыми имеются предва-
рительные соглашения. Обычно хабы имеют пароль на сессию и защищенные
входные области. Однако приемлем и любой другой надежный метод, который
обеспечивает отсутствие на бекбоне несанкционированных сообщений.
4.3. Добавление конференций на бекбон
Конференция добавляется на бекбон и заносится в список признанных конферен-
ций, если выполнены все перечисленные ниже требования:
□ модератор отправил нетмейловый запрос к REC вместе с правилами своей кон-
ференции. Региональным эхо-координатором могут быть установлены ограни-
чения на начальный уровень распространения конференции, необходимый для
принятия конференции на бекбон. Если большинство NEC-сетей выскажутся
против установленных ограничений, REC обязан в месячный срок пересмот-
реть их. Текущие ограничения должны распространяться REC с помощью
файл-эхи г5 0-bone;
□ правила конференции допускают написание сообщений на русском языке,
в них оговорен порядок смены модератора и согласно им допускается рас-
пространение конференции в любой сети региона 50;
□ по крайней мере 10% NEC потребовали, чтобы конференция распространя-
лась для их сети через региональный бекбон.
Любая временно удаленная с бекбона конференция восстанавливается для ре-
гулярного распространения через бекбон, когда ситуация, вызвавшая ее удаление,
будет корректно устранена.
4.4. Удаление конференций с бекбона
Конференция временно удаляется с бекбона, если имеет место хотя бы одна из
перечисленных ситуаций:
□ в конференции нет модератора;
□ менее 10% NEC требуют распространения конференции через бекбон в их
сетях.
Конференция полностью удаляется с бекбона, если случится хотя бы одна из
перечисленных ситуаций:
□ модератор посылает нетмейлом региональному эхо-координатору требование
об удалении конференции с бекбона;
□ модератор не выполняет своих обязанностей, как это описано в разделе 3.2,
и требований REC;
□ трафик в конференции упал ниже установленного REC уровня;
□ конференция, временно удаленная с бекбона, не была восстановлена для регу-
лярного распространения через бекбон спустя два месяца с момента ее удаления.
Термины «временное удаление с бекбона» или «полное удаление с бекбона» не
означают запрета на распространение конференции региональными хабами либо
любыми другими узлами региона. Конференция, временно удаленная с бекбона,
изымается из списка конференций бекбона и переводится в список временно уда-
ленных, однако региональные хабы продолжают ее распространение. При полном
удалении конференции с бекбона она удаляется из всех списков, а системные опе-
раторы региональных хабов самостоятельно принимают решение о ее дальнейшем
распространении или нераспространении на своих узлах.
4.5. Внешние и паритетные конференции
Кроме внутрирегиональных конференций на бекбон могут быть приняты также
внешние и паритетные (межрегиональные или межсетевые) конференции.
Распространение внутрирегиональных конференций за пределы региона воз-
можно при согласии модератора и участников конференции, находящихся за
пределами региона, признавать и соблюдать Эхо-Полиси региона. Это касается
также и гейтования региональных конференций в другие сети.
Принятие внешних конференций на региональный бекбон при их соответствии
Эхо-Полиси региона производится на общих основаниях. REC может разрешить
принятие на региональный бекбон внешних конференций, не соответствующих
Эхо-Полиси региона при условии, что их содержание вызывает значительный
интерес в регионе. При этом должны быть определены процедуры, обеспечиваю-
щие нормальное функционирование бекбона.
Паритетные конференции (межрегиональные или межсетевые) распространя-
ются по региональному бекбону на основе соглашений REC регионов (или соот-
ветствующих ответственных лиц других сетей). При этом должны быть определе-
ны процедуры, обеспечивающие нормальное функционирование бекбона.
REC может снять с бекбона конференции, нарушающие его нормальное функ-
ционирование.
4.6. Финансовые взаимоотношения
В необходимых случаях в рамках регионального бекбона (как в целом, так и в от-
дельных его частях) может вводиться система взаимного возмещения расходов
(costsharing). Принципы и порядок функционирования такой системы устанавли-
ваются по взаимной договоренности заинтересованными лицами (лицом, несущим
расходы, и лицами, которые получают от него эхо-почту). Извлечение прибыли при
передаче конференций бекбона от системы к системе не допускается и влечет пол-
ное отключение узла от бекбона.
4.7. Конференции вне регионального бекбона
Эхо-конференции, которые распространяются в регионе помимо регионального
бекбона, находятся за пределами юрисдикции данного документа. Порядок и про-
цедуры распространения таких конференций оговариваются заинтересованными
лицами согласно общему уставу FidoNet (FidoNet Полиси).
5. Порядок разрешения конфликтов
В случае нарушений положений данного документа, которые создают угрозу для
нормального функционирования регионального бекбона, любой сисоп региона
может подать апелляцию NEC или REC. При подаче апелляций следует придер-
живаться следующего порядка. Первым шагом должна быть попытка связи с ли-
цом, допустившим нарушение. Если такие переговоры не дадут желаемого резуль-
тата, сисоп может направить апелляцию к NEC (в рамках сети) и REC, представив
копию переписки с нарушителем.
REC не принимаются апелляции на санкции, налагаемые модераторами кон-
ференций, если они являются внутренним делом конференции, не нарушают
объявленных правил конференции и не затрагивают других конференций бекбона.
Также не принимаются любые апелляции относительно конференций, распро-
страняемых помимо регионального бекбона.
В случае обнаружения дублированных сообщений (dupes) нетмейловое сооб-
щение об этом (с копией служебной информации) должно направляться нетмей-
лом соответствующим эхо-координаторам.
Требования эхо-координаторов о разрыве указанного ими линка для устране-
ния дублирования сообщений на бекбоне обязательны для выполнения любым
узлом, получающим эхо-почту с бекбона. Невыполнение этих требований или
неоднократное создание линков, порождающих дублированные сообщения, явля-
ются основанием для полного отключения виновного узла от бекбона по реше-
нию соответствующего эхо-коордиинатора.
Все конфликты, касающиеся соблюдения общего устава FidoNet (FidoNet По-
лней), должны решаться помимо структуры эхо-координаторов в порядке, пре-
дусмотренном FidoNet Полиси.
6. Порядок принятия и изменения Эхо-Полиси
6.1. Принятие Эхо-Полиси и переходный период
Данный документ принимается голосованием всех системных операторов регио-
на 50, перечисленных в нодлисте FidoNet, действующем на момент объявления
голосования. При голосовании должен соблюдаться принцип: один человек -
один голос. RC назначает одного из сисопов региона ответственным за проведе-
ние голосования. Документ считается принятым, если за него проголосует более
50% системных операторов уздов FidoNet региона 50 от числа принявших учас-
тие в голосовании.
REC и NEC, занимающие эти должности в момент принятия данного докумен-
та, продолжают выполнять свои обязанности в указанном объеме до отставки или
замены в соответствии с данным документом.
Если в момент принятия документа должность REC окажется вакантной (то
есть существующий REC заявит о своей отставке), то должны быть проведены
выборы REC по процедуре, описанной в разделе 2.2. В связи с отсутствием в на-
стоящий момент оформленного регионального бекбона в выборах принимают уча-
стие все системные операторы узлов региона 50.
REC определяет и рассылает по файл-эхе R5 0-BONE структуру и состав регио-
нального бекбона, перечень технических требований к конференциям, а также
список конференций регионального бекбона и их модераторов не позже, чем че-
рез два месяца после принятия данного документа (или после своего избрания,
если в момент принятия документа должность REC была вакантна). Не позже чем
через четыре месяца после принятия документа (или избрания REC) должен быть
разработан и согласован с региональными хабами аварийный план функциони-
рования бекбона (разделы 2.1 и 2.3).
Невыполнение REC этих требований в указанные сроки является основанием
для его смещения до истечения шести месяцев и проведения новых выборов.
Процедура формирования регионального бекбона в течение этих двух месяцев
(создание списков конференций бекбона и региональных хабов) определяется
REC и может отличаться от процедур, описанных в данном документе.
6.2. Внесение изменений в Эхо-Полиси
Изменения данного документа могут предлагаться RC, REC, NC, NEC и сисопа-
ми региональных хабов. Если предлагаемое изменение получит одобрение более
10% лиц, имеющих право голоса при выборах REC (раздел 2.2), то последний обя-
зан назначить голосование по этому изменению.
Оно проводится среди RC, REC, NC, NEC и региональных хабов по тем же пра-
вилам, что и выборы REC.
Изменение считается принятым, если за него проголосует более двух третей от
числа лиц, принявших участие в голосовании, и отклоняется, если проголосует
менее половины.
В случае, если предлагаемое изменение наберет не менее половины поданных
голосов, но и не более двух третей, то для его принятия или отклонения может
быть назначено голосование среди всех системных операторов региона. Оно на-
значается, если на его проведении настаивает человек, предложивший изменение.
Изменение принимается при наличии более 50% голосов системных операторов,
принявших участие в голосовании.
ОТрккоойлжш® Ю
Справочник
по программному
обеспечению FidoNet
Настоящий справочник составлен на основе регулярно публикуемого в FidoNews
списка Петера Поповича (адрес в FidoNet - 1:363/264). Отдельные таблицы даны
для различных операционных систем и аппаратных платформ.
Поскольку составитель списка «обитает» в первой зоне FidoNet, то собранные
им адреса для запроса программ расположены в основном в этой зоне. Адреса для
поиска Fido-программ в Internet можно найти в Приложении 8.
Обозначения
Каждая таблица содержит следующие графы:
Наименование - название программы;
Версия - версия программы;
Ф - функции:
В - BBS;
С - архивирование;
Е - редактор почты;
F - fossil;
G - шлюз;
М - почтовая программа;
N - обработка списка узлов (Nodelist);
Р - пойнт-система;
Т - тоссер;
О - другое;
Ц - цена программы:
С - коммерческий продукт;
D - демонстрационная программа;
F - freeware (бесплатная и свободно распространяемая программа);
G - свободно распространяется с исходными текстами;
Р - бесплатно для персонального использования;
S - shareware (условно-бесплатная программа);
X - crippleware (программа нуждается в доработке);
Контактное имя - имя автора программы или лица, ответственного за контак-
ты с пользователями;
Адрес - куда следует адресовать вопросы по данной программе;
Имя для запроса - имя файла или условное имя для запроса файла с програм-
мой по адресу контактной персоны (адрес в предыдущей графе). По этому имени
нужно искать программу в Internet;
Аппаратная платформа - сведения о минимально необходимом для работы
программы оборудовании:
186 - компьютер на основе процессора Intel 8086 или 8088 (например, IBM
PC или IBM PC XT);
1286 - компьютер на основе Intel 80286 (IBM PC AT286);
1386 - компьютер на основе Intel 80286 (IBM PC AT386);
I486 - компьютер на основе Intel 80486 или Intel Pentium либо более мощный.
Последняя графа в некоторых таблицах (там, где ее содержание очевидно) от-
сутствует.
Таблица ГП 1.1. Список программ FidoNet для операционной системы MS DOS
Наименование Версия Ф Ц Контактное имя Адрес Имя для запроса Аппаратная платформа
Act-Up 4.6 G D Chris Gunn 1:15/55 ACT-UP I86
ALLFIX 5.00 T S Harald Harms 2:281/415 ALLFIX I86
Announcer 1.12 0 S Peter Karlsson 2:206/221 ANNOUNCE I86
BGFAX 1.60 0 s B.J. Guillot 1:106/400 BGFAX I86
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP -
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BDOS_260.ZIP I86
BinkleyTerm-XE XR5 M F Thomas Waldmann 2:2474/400 BTXE_DOS I86
The Brake! 718.a9 M F John Gladkih 2:5020/1666 TBI718A9.ZIP I386
CFRoute 0.92 0 G C. Fernandez Sanz 2:341/70 CFR I86
CheckPnt 1,0a 0 G Michiel vd Vlist 2:500/9 CHECKPNT I86
FastEcho 1.46.1 T S Tobias Burchhardt 2:2448/400 FASTECHO I386
FastEcho/16 1.46.1 T S Tobias Burchhardt 2:2448/400 FEX I286
FastLst 1.36 N S Alberto Pasquale 2:332/504 FASTLSTD I286
FidoBBS (tm) 12u В S Ray Brown 1:1/117 FILES I86
FrontDoor 2.12 M S JoHo 2:201/330 FD I286
FrontDoor 2.20c M C JoHo 2:201/330 FDINFO I86
GEcho 1.00 T S Bob Seaborn 1:140/12 GECHO I86
GEcho/Plus 1.11 T C Bob Seaborn 1:140/12 GECHO I86
GEcho/Pro 1.20 T C Bob Seaborn 1:140/12 GECHO I286
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO I286
GoldED 3.01 E S Len Morgan 1:203/730 GED I86
GoldED/386 3.01 E S Len Morgan 1:203/730 GEX I386
GoldED Docs 3.01 E S Len Morgan 1:203/730 GEM -
GoldNODE 3.01 E S Len Morgan 1:203/730 GEN I86
Imail 1.75 T S Michael McCabe 1:1/121 IMAIL I86
ImCrypt 1.04 0 G Michiel vd Vlist 2:500/9 IMCRYPT I86
71 6 Приложение XI. Справочник по программному обеспечению FidoNet
Таблица П11.1. Список программ FidoNet для операционной системы MS DOS
Наименование Версия Ф ц Контактное имя Адрес Имя для запроса Аппаратная платформа
lnfoMail/86 1.21 0 F Damian Walker 2:2502/666 INFOMAIL I86
lnfoMail/386 1.21 0 F Damian Walker 2:2502/666 INFO386 I386
InterEcho 1.19 T С Peter Stewart 1:369/35 IEDEMO I86
InterMail 2.29k M С Peter Stewart 1:369/35 IMDEMO I86
InterPCB 1.52 0 S Peter Stewart 1:369/35 INTERPCB I86
IPNet 1.11 0 S Michele Stewart 1:369/21 IPNET I86
JD's CBV 1.4 0 S John Dailey 1:363/277 CBV I86
Jelly-Bean 1.01 T S Rowan Crowe 3:635/727 JELLY I86
Jelly-Bean/386 1.01 T S Rowan Crowe 3:635/727 JELLY386 I386
JMail-Hudson 2.81 T S Jason Steck 1:285/424 JMAIL-H I86
JMail-Goldbase 2.81 T S Jason Steck 1:285/424 JMAIL-G I86
MakePI 1ю9 N G Michiel vd Vlist 2:500/9 MAKEPL I86
Marena 1.1 beta 0 G Michiel vd Vlist 2:500/9 MARENA I86
Maximus 3.01 в Р Tech 1:249/106 MAX I86
Max User Ed. 0.18 0 F Larry Cooke 1:300/53 MUE I86
McMail 1.0 M S Michael McCabe 1:1/148 MCMAIL I86
MDNDP 1.18 N S Bill Doyle 1:388/7 MDNDP I86
Msged 4.10 E G Andrew Clarke 3:635/728 MSGED41D.ZIP I86
Msged/386 4.10 E G Andrew Clarke 3:635/728 MSGED41X.ZIP I386
NEF 2.38 0 S Alberto Pasquale 2:332/504 NEFD I86
Northstar 3.31.29 В S A&B Darin 1:285/82 NSTAR I86
Opus CBCS 1.79 В Р Christopher Baker 1:374/14 OPUS I86
O/T-Track 2.66 О S Peter Hampf 2:241/1090 ОТ I86
PcMerge 2.8 N G Michiel vd Vlist 2:500/9 PCMERGE I86
PlatinumXpress 1.3 M С Gary Petersen 1:290/111 PX13TD.ZIP I86
QuickBBS 2.81 В S Ben Schollnick 1:2613/477 QUICKBBS I86
RAR 2.01 С S Ron Dwight 2:220/22 RAR I86
RemoteAccess 2.50 В S Mark Lewis 1:3634/12 RA I86
Searchlight 4.5 В S Paul Casey 1:343/117 DEMO450.ZIP I86
Searchlight 5.02 В С Paul Casey 1:343/117 SLBBS50.TXT I86
Silver Xpress: Door 5.4 О С Gary Petersen 1:290/111 FILES I86
Silver Xpress: 4.4 Е S Gary Petersen 1:290/111 SXR44.ZIP I86
Reader
Spitfire 3.51 В S Mike Weaver 1:3670/3 SPITFIRE I86
Squish 1.11 Т р Tech 1:249/106 SQUISH I86
StealTag UK 1.c... О F Fred Schenk 2:284/412 STEAL_UK I86
T-Mail 2.600 м S Ron Dwight 2:220/22 TMAIL I86
Telegard 3.02 в F Tim Strike 1:259/423 TELEGARD I86
Terminate 5.00 О S Bo Bendtsen 2:254/261 TERMINATE I86
Tobruk 0.33 т G Paul Edwards 3:711/934 TOBRUK I86
Tornado 1.50g в F Konst Klyagin 2:461/22 TORNADO I86
TosScan 1.01 т С JoHo 2:201/330 TSINFO I86
TransNet 1.00 G S Marc S. Ressl 4:904/72 TN100ALL.ZIP I86
TriBBS 11.0 В S Gary Price 1:3607/26 TRIBBS I86
TriDog 11.0 Т F Gary Price 1:3607/26 TRIDOG I86
TriToss 11.0 т S Gary Price 1:3607/26 TRITOSS I86
WaterGate 0.93 G S Robert Szarka 1:320/42 WTRGATE I86
WWIV 4.24a В S Craig Dooley 1:376/126 WWIV I86
WWIVTOSS 1.36 Т S Craig Dooley 1:376/126 WWIVTOSS I86
xMail 2.00 Т S Thorsten Franke 2:2448/53 XMAIL I86
XRobot 3.01 О S JoHo I 2:201/330 XRDOS I86
Таблица П11.2. Список программ FidoNet для операционной системы OS/2
Наименование Версия Ф Ц Контактное имя Адрес Имя для запроса Аппаратная платформа
ALLFIX/2 5.00 T s Harald Harms 2:281/415 AFIXOS2 I386
BGFAX 1.60 0 s BJ. Guillot 1:106/400 BGFAX I386
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC__260.ZIP -
BinkleyTerm 2.60 M F BobJuge 1:1/102 BOS2_260.ZIP I386
BinkleyTerm-XE XR5 M F Thomas Waldmann 2:2474/400 BTXE_OS2 I386
CFRoute 0.92 0 G C. Fernandez Sanz 2:341/70 CFR I386
FastEcho 1.46.1 T S Tobias Burchhardt 2:2448/400 FE2 I386
FastLst 1.36 N S Alberto Pasquale 2:332/504 FASTLST I386
Fleetstreet 1.21 E S Michael Hohner 2:2490/2520 FLEET I486
FP-OS/2 97-03-21 0 F Mike Bilow 323/107 FP0S2 I386
GEcho/Pro 1.20 T C Bob Seaborn 1:140/12 GECHO I386
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO I386
GoldED 2.50 E S Len Morgan 1:203/730 GEO I386
GoldED Docs 2.50 E S Len Morgan 1:203/730 GEM -
GoldNODE 2.50 E S Len Morgan 1:203/730 GEN I386
ImCrypt 1.04 0 G Michiel vd Vlist 2:500/9 IMCRYPT I386
Maximus 3.01 В P Tech 1:249/106 MAXP I386
Max User Ed. 0.18 0 F Larry Cooke 1:300/53 MUEP 1386
Msged/2 4.10 E G Andrew Clarke 3:635/728 MSGED41O.ZIP I386
NEF 2.38 0 S Alberto Pasquale 2:332/504 NEF I386
PcMerge 2.3 N G Michiel vd Vlist 2:500/9 PCMERGE I386
RAR 2.01 C S Ron Dwight 2:220/22 RAR2 I386
Squish 1.11 T P Tech 1:249/106 SQUISHP I386
T-Mail 2.600 M S Ron Dwight 2:220/22 TMAIL2 I386
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK I386
Tornado 1.50g В F Konst Klyagin 2:461/22 TORNADO2 I386
WaterGate 0.93 G S Robert Szarka 1:320/42 WTRGATE I386
XRobot 3.01 0 S JoHo 2:201/330 XROS2 I386
Таблица П11.3
Список программ FidoNet для операционной системы Windows (16 бит)
Наименование Версия ф ц Контактное имя Адрес Имя для запроса Аппаратная платформа
BeeMail 1.0 м с Andrius Сераitis 2:470/1 BEEMAIL I386
FrontDoor АРХ 1.12 р S Mats Wallin 2:201/329 FDAPXW I386
Таблица П11.4. Программы FidoNet для операционной системы Windows (32 бит)
Наименование Версия Ф Ц Контактное имя Адрес Имя для запроса Аппаратная платформа
Argus 95/IP 2.704 M s Max Masyutin 2:469/77 A9I I386
Argus NT/IP 2.704 M s Max Masyutin 2:469/77 ANI I486
BeeMail 1.0 M c Andrius Cepaitis 2:470/1 BEEMAIL I386
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP -
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BW32_260.ZIP I386
BinkleyTerm-XE XR5 M F Thomas Waldmann 2:2474/400 BTXE_W32 I386
CFRoute 0.92 0 G C. Fernandez Sanz 2:341/70 CFR I386
FastLst 1.36 N S Alberto Pasquale 2:332/504 FASTLSTW I386
GoldED 2.50 E S Len Morgan 1:203/730 GEO I386
GoldED Docs 2.50 E S Len Morgan 1:203/730 GEM -
Maximus 3.01 В P Tech 1:249/106 MAXN I386
Msged/NT 4.10 . 0 G Andrew Clarke 3:635/728 MSGED41W.ZIP I486
NEF 2.38 0 S Alberto Pasquale 2:332/504 NEFW I386
PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO I486
Searchlight 5.02 В C Paul Casey 1:343/117 SLBBS50.TXT I486
T-Mail 2.600 M S Ron Dwight 2:220/22 TMAILNT I486
WinFOSSIL/95 1.12 r4 F s Bryan Woodruff 1:343/294 WNFOSSIL.ZIP I386
WinFOSSIL/NT 1.0 beta F s Bryan Woodruff 1:343/294 NTFOSSlL.ZIP I486
Таблица П11.5. Программы FidoNet для операционной системы UNIX
Наименование Версия Ф Ц Контактное имя Адрес Имя для запроса Аппаратная платформа
ifmail 2.12 M G Eugene Grosser 2:293/2219 IFMAIL I386
if mail-tx ...tx8.6 M G Pablo Saratxaga 2:293/2219 IFMAILTX I386
ifmail-tx.rpm ...tx8.6 M G Pablo Saratxaga 2:293/2219 IFMAILTX.RPM I386
Msged 4.00 E G Paul Edwards 3:711/934 MSGED I386
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK I386
Таблица П11.6. Программы FidoNet для компьютеров AMIGA
Наименование Версия Ф Ц Контактное имя Адрес Имя для запроса
CrashMail 1.31 T X Rene Laederach 2:301/133 CRASHMAIL
CrashTick 1.2 0 F Rene Laederach 2:301/133 CRASHTICK
DLG Pro BBOS 1.15 в C Holly Sullivan 1:202/720 DLGDEMO
GMS 1.1.85 M s Mirko Viviani 2:331/213 GMS
Msged 4.00 E G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
TrapDoor 1.86.b2 M S Max Hantsch 2:310/6 TRAPDOOR
TrapToss 1.50 T S Rene Hexel 2:310/6 TRAPTOSS
Таблица П11.7. Программы FidoNet для компьютеров ATARI
Наименование Версия Ф Ц Контактное имя Адрес Имя для запроса
ApplyList 1.00 N F Daniel Roesen 2:2432/1101 APLST100.LZH
BinkleyTerm/ST 3,18pl2 M F Bill Scull 1:363/112 BINKLEY
BTNC 2.00 N • G Daniel Roesen 2:2432/1101 BTNC
JetMail 0.99beta T S Joerg Spilker 2:2432/1101 JETMAIL
Semper 0.80beta M S Jan Kriesten 2:2490/1624 SMP-BETA
Таблица П11.8. Программы FidoNet для компьютеров Macintosh
Наименование Версия Ф Ц Контактное имя Адрес Имя для запроса
RavelMAIl 2.0LT M p Ciril Moorsin 2:5030/700 RAVEL
RavelSHUFFLER 2.0LT T p Ciril Moorsin 2:5030/700 RAVEL
RavelQUILL 2.0LT E p Ciril Moorsin 2:5030/700 RAVEL
RaveINC 2.0LT N p Ciril Moorsin 2:5030/700 RAVEL
RavelSETUP 2.0 LT 0 p Ciril Moorsin 2:5030/700 RAVEL
Библиография
Глава 1
1.1. THE LOST FIDONET ARCHIVES VOLUME THREE: FidoNet History and
Operation by Tom Jennings / Edited by V. Perriello. - FidoNews. Vol. 6. - No. 25. -
19 Jun., 1989.
1.2. THINK BEFORE У OU LEAP: About 1FNA/T.Jennings. -FidoNews. Vol. 3. -
No. 4.-27 Jan., 1986.
1.3. Interview with Tom Jennings / J. Lebkowsky. - FidoNews. Vol. 14. - No. 28. -
14 Jul., 1997.
1.4. Чамберс M., Гиббонс Д., Харрис Дж. и др. BBS без проблем! Running a perfect
BBS: Пер. с англ. - СПб.: Питер, 1996.
1.5. Вильховченко С. Модем 97. Выбор, установка, настройка. - М.: ABF, 1997.
1.6. The GNU Manifesto 1985, 1993. Free Software Foundation, Inc. - http://
www.gnu.org/gnu/manifesto.html.
1.7. FidoNet Standards Committee / R. Bush. - FidoNews. Vol. 3. - No. 29. - 28 Jul.,
1986.
1.8. RFC 0977. Network News Transfer Protocol / B. Kantor, P. Lapsley. - Feb., 1986.
1.9. Policy proposal / B. Dolmatov. - FidoNews. Vol. 11. - No. 25. - 20 Jun., 1994.
1.10. Vote Result: Proposed New Policy / M. Whelan. - FidoNews. Vol. 8. -
No. 20. - 20 May, 1991.
1.11. The FidoNet users group / T. Jennings. - FidoNews. Vol. 1. - No. 1. - 1 Dec., 1984.
1.12. Грозицкий С. У казанских фидошников теперь есть свой значок / Com-
puter world. - Kazan. - Sep., 1997.
Глава 2
2.1. FTA-1000. FTSC Chapter / Administrator FTSC, FidoNet Technical Standards
Committee Archive. - http://ftsc.org.
2.2. FTA-1001. FTSC Operations / Administrator FTSC, FidoNet Technical Stan-
dards Committee Archive. - http://ftsc.org.
2.3. FTA-1002. Document Submission and Publication Standard / Administrator
FTSC, FidoNet Technical Standards Committee Archive. - http://ftsc.org.
2.4. FTA-1003. Membership list / Administrator FTSC, FidoNet Technical Standards
Committee Archive. - http://ftsc.org.
2.5. FTS-0001. A Basic FidoNet(r) Technical Standard Revision 16 / R. Bush et
all. - FidoNet Technical Standards Committee Archive. - http://ftsc.org.
2.6. RFC2119. Key words for use in RFCs to Indicate Requirement Levels / S. Brad-
ner. - March, 1997.
2.7. RFC2026. The Internet Standards Process - Revision 3 / S. Bradner. - Oct., 1996.
2.8. FTS-0062. A Proposed Nodelist flag indicating Online Times of a Node /
D. J. Thomas. - FidoNet Technical Standards Committee Archive. - http://ftsc.org.
2.9. Country Level Support for FidoNet. A Proposed Approach / K. Trout. - FidoNews.
Vol. 3. - No. 37. - 29 Sep., 1986.
2.10. FSC-0004. Zones and Zonegates explained primitively / R. Bush. - FidoNet
Technical Standards Committee Archive. - 1986. - http://ftsc.org.
2.11. RFC-822. STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT
MESSAGES / D. H. Crocker. - 1982.
2.12. FTS-0009. MSGID/REPLY.A standard for unique message identifiers and
reply chain linkage / J. Nutt. - FidoNet Technical Standards Committee Archive. -
http://ftsc.org.
2.13. FTS-0004. Echomail specification / B. Hartman. - FidoNet Technical Standards
Committee Archive. - http://ftsc.org.
2.14. FSC-0074. Proposed echomail specification. / J. Souvestre, D. Troendle, B. Da-
vis, G. Peace. - FidoNet Technical Standards Committee Archive. - http://ftsc.org.
2.15. FSC-0057. Echo Area Managers - Specifications For Requests / F. Fabris,
J. Homrighausen. - FidoNet Technical Standards Committee Archive. - http://ftsc.org.
2.16. FSC-0028. FwdSpec - A Collection of Notes on Moving Files in FidoNet /
H. Lee. - FidoNet Technical Standards Committee Archive. - http://ftsc.org.
2.17. Вакка Дж. Диалектика. Секреты безопасности в Internet. - Киев, 1997.
Глава 3
3.1. Лагутенко О. И. МОДЕМЫ. Справочник пользователя. - СПб: Лань, 1997.
3.2. Xmodem documentation / W. Christensen. - 1982.
3.3. Xmodem documentation, CRC option / J. Byrns. - 1985.
3.4. Getting the Most out of Zmodem / C. Forsberg. Omen Technology. - http://
www.rdrop.com/users/caf/zmdzget.htm.
722
3.5. Recent Development in Zmodem / C. Forsberg. Omen Technology. - http://
www.rdrop.com/users/caf/zmdmwn.htm.
3.6. Evolution and selection of File Transfer Protocols / C. Forsberg. Omen Techno-
logy - http://www.rdrop.com/users/caf/zmdmev.htm.
3.7. FSC-0072. The HYDRA file transfer protocol / J. Homrighausen, A. Lentz. -
FidoNet Technical Standards Committee Archive. - http://ftsc.org.
3.8. FSP-1011. Binkp-a protocol for transferring FidoNet mail over reliable con-
nections / D. Maloff, N. Soveiko, M. Masyutin. - FidoNet Technical Standards Com-
mittee Archive. - http://ftsc.org.
Глава 4
4.1. FSC-0007. FidoNet(r) RFC822-Style Message Format (Informal Proposed
Message Format Specification - Draft, revised) / R. Heller. - 1990. - http://ftsc.org.
4.2. Fido’s internal structures / T. Jennings. - 1984. - http://www.fidonet.org.
4.3. FSC-0053. Specifications for the AaFLAGS field / J. Homrighausen. - FidoNet
Technical Standards Committee Archive. - http://ftsc.org.
4.4. FSC-0039. A Type-2 Packet Extension Proposal / M. Howard. - FidoNet
Technical Standards Committee Archive. - http://ftsc.org.
4.5. FSC-0048. A Proposed Type-2 Packet Extension / J. Vroonhof. - FidoNet
Technical Standards Committee Archive. - http://ftsc.org.
4.6. FSC-0024. A Proposal for a Type-3 Mail Bundle / O. McDonald. - FidoNet
Technical Standards Committee Archive. - http://ftsc.org.
Глава 5
5.1. Осадчук А. Сетевые архитектуры современных информационно-вычисли-
тельных сетей / Компьютер-Пресс. - 1995. - № 11; 1996. - № 3.
5.2. FSC-0080. Describing FidoNet with a layered model / M. Steldal. - 1995. - http:/
/ftsc.org.
5.3. FTS-0007. An Enhanced FidoNet(r) Technical Standard Extending FTS-0001
to include SEAlink protocol (Including Overdrive and File Restart) / P Becker. -
FidoNet Technical Standards Committee Archive. - http://ftsc.org.
5.4. FTS-0006. YOOHOO and YOOHOO/2U2. The netmail handshake used by
Opus-CBCS and other intelligent FidoNet, mail handling packages / V. Perriello. -
1991. - http://ftsc.org.
5.5. FSC-0054. The CHARSET Proposal. A System-Independent Way of Trans-
ferring Special Characters, Character Sets and Style Information in FIDO Messages /
D. McNutt. - 1991. - http://ftsc.org.
Глава 6
6.1. FSC-0008. Fundamentals of FOSSIL implementation and use/V. E. Perriello. -
FidoNet Technical Standards Committee Archive. - http://ftsc.org.
6.2. FSC-0015. Fundamentals of FOSSIL implementation and use / R. Moore. -
FidoNet Technical Standards Committee Archive. - http://ftsc.org.
Глава 7
7.2. FSC-0038. A Domain Proposal For FidoNet(r) / J. Nutt. - FidoNet Technical
Standards Committee Archive. - http://ftsc.org.
7.3. FSC-0003. FidoNet Route Files Explained / B. Baker. - FidoNet Technical
Standards Committee Archive. - http://ftsc.org.
7.4. Nodelist Version 7+ / A. Pasquale, T. Waldman. - From Binkley Term XE
documentation.
Глава 8
8.1. GENERAL ECHOMAIL POLICY 1.0 / FidoNews. Vol. 7. - No. 41. - 8 Oct., 1990.
8.2. GENERAL ECHOMAIL POLICY 2 / FidoNews. Vol. 13. - No. 36. - 2 Sep., 1996.
Глава 9
9.1. FSC-0028. Proposed file-forwarding standard / H. Lee. - FidoNet Technical
Standards Committee Archive. - 1988. - http://ftsc.org.
9.2. FSC-0061. Proposed Guidelines for the FileBone / E. V Riper. - FidoNet
Technical Standards Committee Archive. - 1992. - http://ftsc.org.
9.3. FSC-0087. File Forwarding in FidoNet Technology Networks / R. Williamson. -
FidoNet Technical Standards Committee Archive. - 1995. - http://ftsc.org.
Глава 10
10.1. Gateways to and from FidoNet <tm> Technical, Administrative and Policy
Considerations / R. Bush. - FidoNews. Vol. 6. - 1989. - April, 1989. - http://
www.fidonews.org.
10.2. FSC-0034. Gateways to and from FidoNet <tm> Technical, Administrative,
and Policy Considerations / R. Bush. - FidoNet Technical Standards Committee
Archive. - 1989 - http://ftsc.org.
10.3. FidoNet Internetwork Gateway Policy / M. Whelan et all. - FidoNews. Vol. 7. -
No. 45. - 5 Nov., 1990.
10.4. FSC-0035. Transparent Gateways to and from FidoNet <tm>. Technical
Considerations / M. Shiels. — FidoNet Technical Standards Committee Archive. -
22 Jun., 1989. - http://ftsc.org.
10.5. RFC-2045-RFC-2049. Multipurpose Internet Mail Extensions (MIME), Parts
I-V/N. Freed et all. - 1996.
10.6. FSC-0083. A proposed standard for message IDs on FTN systems / J. de Boyne
Pollard. - FidoNet Technical Standards Committee Archive. - 17 Jun., 1995. - http://
ftsc.org.
10.7. FSC-0064. InterDomain Message Identification, Gating, Reply Linking and
Addressing / J. Penner. - FidoNet Technical Standards Committee Archive. - 10 May,
1992. - http://ftsc.org.
10.8. RFC-0977. Network News Transfer Protocol / B. Kantor, P. Lapsley. - 1986.
10.9. Ifmail: FidoNet(tm) technology implementation on UNIX platform / E. G. Gros-
ser. - 1997.
Глава 11
11.1. FidoNet over IP, Part 1 and 2 of 4 / L. Behet. - FidoNews. Vol. 15. - No. 30. -
27 Jul., 1998.
11.2. FidoNet over IP, Part 3 of 4 / L. Behet. - FidoNews. Vol. 15. - No. 31. -
03 Aug., 1998.
11.3. Семенов Ю. А. Протоколы и ресурсы Internet. - M.: Радио и связь, 1996.
11.4. Немет Э. и др. UNIX: руководство системного администратора. - Киев:
BHV, 1997.
11.5. FTS-5000. THE DISTRIBUTION NODELIST / С. Turner et all. - FidoNet
Technical Standards Committee Archive. - 1999. - http://ftsc.org.
11.6. FTS-5001. NODELIST FLAGS AND USERFLAGS / C. Turner et all. - FidoNet
Technical Standards Committee Archive. - 1999. - http://ftsc.org.
11.7. How FidoNet <tm> Tunnels the Internet /R. Bush. - 1992. - http://
www.nsrc.org/lowcost ttols/fidonet/papers/fido-ip.
Алфавитный указатель
Л
Личная почта. См. Нетмейл
м
Мейлер. См. Почтовая программа
Некорректное поведение
АВ 141
ХАВ 141
Нетмейл
атрибуты писем 55, 290
AuditRequest 194, 292
ConfirmationRequest 292
Crash 193, 291
Direct 292
FileAttached 56, 193, 292
FileRequest 193, 292
FileUpdateReq 194
ForcePickup 291
HoldForPickup 193, 291
Immediate 291
InTransit 194
IsReturnReceipt 194, 291
KillFIle/Sent 292
KillSent 193, 292
Local 194, 291
Orphan 194
Private 193, 291
Read 291
Received 194, 291
ReturnReceiptRequest 193, 292
Sent 194, 291
TruncateFile/Sent 292
зональные шлюзы 161
кладжи
DEST 162
FLAGS 290
FMPT 195
INTL 162, 195
MSGID 166, 370
ORIG 162
ORIGIN 370
ROUTE 162
ТОРТ 195
VIA 370
маршрутизация
FRIP 165
Safrouter 164
по нодлисту 162
общее описание 160
правила обращения 160
стандарты FidoNet 165
трудности в доставке 370
badmail 372
дупы 372
петли 371
розыск потерянной почты 373
О
Операторы
логические. См. Логические
операторы
П
Полиси
WorldPol 117
запрос узлового адреса 97
история 46
основные положения 128
попытки изменения 48, 116
ранние версии 47
Эхо-Полиси 169. См. также
Эхо-Полиси
Помощь. См. Подсказка
Почтовая программа
драйвер комммуникационного
порта. См. FOSSIL
интерфейс пользователя 303
исходящий директорий
BSO 202, 205
LongBSO 210
АМА 204
коммуникационная подсистема 302
маршрутизация почты 311
нодлист 332
обработка 333
общее описание 294
очередь 202
планировщик 308
подсистема управления
очередью 298
почтовая сессия
EMSI 233
FTS0001 217
FTS0007 223
YOOHOO 228
запрос файла 224
примеры настройки 342
протокольные файлы 307
структура и состав 295
т
Тоссер. См. Эхо-почта
алгоритм работы 378
интерфейс пользователя 385
место в системе программ узла 285
настройка 385
архиваторы 396
дупобаза 392
общие параметры 392
описание конференций 399
описание линков 403
подсистема подписки 406
правила упаковки баз 395
уровень секретности 393
упаковка нетмейла 329
форматы баз. См. Эхо-почта
Ф
Файл-эхи 77, 173
общее описание 77
стандарты FidoNet 173
файл-эхопроцессор 285
ш
Шлюзы
зональные нетмейл-шлюзы 161
кладжи ORIG, ROUTE, DEST 162
срезание SEEN-BY 162
стандарт 161
с Usenet. См. Usenet флаги в нодлисте 152 трудности в доставке 415 формат письма 171, 378
э Эхо-процессор. См. Тоссер В
Эхо-Полиси бекбон 170 общее описание 170 Эхо-почта 168 история создания 65 BBS IEMSI 241 Internet 277. См. также Vmodem off-line readers 284
кладжи AREA 380 MSGID 382 ORIGIN 381 PATH 381 SEEN-BY 382 координация 408 NEC 410 REC 410 ZEC 410 бекбон 409 конфликты 411 модераторы 410 хабы 411 общее описание 65 время работы по нодлисту 93 как стать пользователем 92 настройка почтовой программы 346 настройка эхо-процессора 388 нетмейл-атрибут PVT 291 общее описание 27 особенности в России 34 принадлежность к сети FidoNet 131 программы BBS 284 сисоп BBS и его пользователи 118 файл-лист 287 флаг МО в нодлисте 150 F FidoNet FidoNews 50
подписка AreaFix 66 примеры 66 почтовая база 383 HUDSON 384 JAM 384 MSG 189, 383 SQUISH 384 связь с конференциями Internet 75 стандарты FidoNet 170 схемы реализации 412 бекбон 412, 413, 414 типы эхо-конференций 69 FTN 49 FTSC 142 IFNA 37 адрес 42 будущее 123 взаимоотношения участников 118 выбор операционной системы 87 выборы 48, 122 RC 139 и Internet 36, 75, 102 история возникновения 27 появления в России 32
конфликты и их разрешение 141
жалоба 141
координирование 134
костшаринг 161
маршрутизация почты
45, 59, 138, 162, 311
набор программ узла 281
некоммерческий характер сети 129
нодлист 146
общее устройство 38
Fido-системы 278
общество 36
пиратство 101
подключение 80
Полиси. См. Полиси
политика 48
программы 97
сервисы 53
стандарты 49
структура и управление 129
IC 140
NC 137
RC 139
ZC 140
зона 129
пойнт 132
регион 130
сеть 131
сисоп 137
узел 131
торговая марка 37
требования к компьютеру 243
«три кита» 44
тюрьма 122
уровневая модель 213
форматы данных 189
язык 128
FOSSIL
BNU 268
СОМТ 104
RLFOSSIL 104
SIO. Cm.SIO
VFD 275
Vmodem. См. Vmodem
WinFOSSIL 273
Х00 268
конфигурация 268
история создания 265
клоны 265
общее описание 264
G
Gateways. См. Шлюзы
I
Internet
ArpaNet 73
Fido DNS 108
fido7 76
fidonet.org 105
как среда передачи FidoNet 36
шлюз на
50/128 363
5020/32 34
5020/400 76
эхи FidoNet в Internet 34
fido7.* 76, 105
relcom.fido.* 34
N
netmail. См. Нетмейл
s
SIO
Vmodem. Cm. Vmodem
настройка 278
общее описание 275
сравнение с com.sys 276
U
Usenet
взаимодействие с FidoNet 35
телеконференции (News) 73
шлюзы с FidoNet 76
V
Vmodem
Ifmail 105
TELNET 275, 277
VMP 277
WinFOSSIL 274
модемные команды 274
настройка
SIO. См. SIO
принцип работы 104
флаг в нодлисте 159
X
ХАВ. См. Некорректное поведение
Шабашвили Эмир Евгеньевич
FidoNet
Руководство системного оператора
Профессиональная работа в непрофессиональной сети
Главный редактор
Литературный редактор
Технический редактор
Верстка
Графика
Дизайн обложки
Захаров И. М.
Ишков М. Н.
Прока С. В.
Куликов С. Л.
Бахарев А. А.
Антонов А. И.
ЛР№ 065625 от 15.01.98.
Подписано в печать 15.05.2000. Формат 70х100У16.
Гарнитура «Петербург». Печать офсетная.
Усл. печ. л. 46. Тираж 3000 экз. Заказ № 431
Издательство «ЛАЙТ Лтд.», 113093, Москва, Б. Серпуховская, 8/7, стр. 2.
Отпечатано в полном соответствии
с качеством предоставленных диапозитивов
в ППП «Типография «Наука»
121099, Москва, Шубинский пер., 6.