Руководство пользователя binkd

0. Введение.

0.0. Об этом руководстве.

Документ, который Вы читаете, предлагается как руководство по использованию программы binkd. Предполагается, что читатель хотя бы поверхностно знаком с понятиями «FIDOnet», «FIDOnet Technology Network» («FTN»), с системой адресации и структурой сети FIDOnet, с почтовыми очередями, используемыми в FIDOnet, с понятиями «mailer» («мейлер»), «tosser» («тоссер»), «netmail tracker» («трекер»), «File Request» («FREQ»), «FREQ processor» («FREQ-процессор»), «netmail», «echomail», «outbound», «domain», «flavour», «DNS», «Internet», «protocol» («протокол»), «IP», «TCP», «proxy» («прокси»). Не помешает также знакомство с семиуровневой моделью OSI. Наличие представлений о перечисленном не является обязательным, но поможет в понимании текста и, в итоге, поможет в поиске ошибок в настройке binkd.

При составлении этого документа использовались: страница man binkd, комментарии к файлу конфигурации из дистрибутива binkd, исходные тексты binkd и руководство пользователя по binkd версии 0.9.2, написанное Nick Soveiko (адрес email nsoveiko@doe.carleton.ca), и опубликованное в Internet на странице http://www.doe.carleton.ca/~nsoveiko/fido/binkd/man/. Использовалась также информация, полученная от других разработчиков binkd.

Автор этого руководства: Стас Дёгтев (Stas Degteff 2:5080/102@FIDOnet, g@grumbler.org, stas.grumbler@gmail.com) и другие участники сообщества разработки binkd.

Этот документ распространяется на условиях свободной лицензии GNU для документации (Free Documentation License, FDL).

0.1. Что такое binkd.

Бинкд (binkd) – программа, разработанная для передачи почты и файлов (мейлер) по технологии FTN в международной любительской сети FIDOnet. В отличие от классических FTN-мейлеров, binkd работает по специально разработанному для него протоколу binkp, используя в качестве транспорта TCP/IP. Таким образом, binkd позволяет передавать почту FIDOnet через Internet и по локальным сетям.

В представленном документе описан binkd версии 1.0.0.

0.2. Основные возможности binkd.

0.3. Источники получения binkd.

Binkd разрабатывается под свободной лицензией GNU и распространяется бесплатно, поэтому его дистрибутивы и исходные тексты можно бесплатно скачать с официальных сайтов и каталогов FTP, скачать c BBS, получить по файл-эхе FIDOnet либо взять из других источников.

0.3.1. Официальные источники по распространению binkd.

В сети FIDOnet:

В сети Internet:

0.4. История создания binkd.

С распространением Internet в России у фидошного сообщества сформировалась идея использовать новый транспорт для передачи трафика. Поначалу использовалось обычное ПО, разработанное для модемных соединений, но это было крайне неэффективно и в некоторых ситуациях сеанс связи FTN не устанавливался несмотря на нормальную работу протоколов Internet. Binkd создавался Дмитрием Маловым в 1996 году как приложение для Internet с тем, чтобы максимально использовать преимущества транспорта TCP/IP. В дальнейшем к разработке подключились другие люди, а Малов в последние годы отошёл от работы над binkd. Первые версии binkd разрабатывались для ОС класса UNIX, в дальнейшем binkd был адаптирован для OS/2, затем для Windows, MSDOS (PCDOS) и AmigaOS.

Название «binkd» было составлено из слов «Bink Daemon», или «Bink-style Daemon». (Иногда его даже пишут с первой и последней заглавными буквами, полностью копируя части исходных слов: «BinkD».) Таким образом, название в некоторой мере описывает назначение программы: демон для работы с bink style outbound. И именно поэтому binkd называют в мужском роде.

1. Философия binkd.

1.1. Протокол.

Дмитрий Малов разработал для binkd собственный протокол, исходя из принципов скорости, простоты в реализации и расширяемости. Протокол был назван его автором «binkp»: сокращение от слов «binkd's protocol».

Протокол binkp разработан в расчёте на использование поверх протокола транспортного уровня, обеспечивающего целостность передаваемых данных, такого как TCP. Базовый протокол binkp использует минимальное количество служебной информации при передаче и приеме данных (файлов), передача файлов производится без пауз последовательно друг за другом, передача и приём на каждой стороне производятся одновременно. Этим обеспечивается эффективное использование полосы пропускания канала связи.

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

Протокол binkp версии 1.0 описан в документе FSP-1018, в других документах FTSC описаны расширения и новые версии протокола. (Подробнее см. на сайте FTSC и на сайте binkd.) Общее описание binkp включено в состав дистрибутива binkd.

1.2. Разделение функциональности.

В мире UNIX принят подход к проектированию приложений, при котором для выполнения некоторой задачи создаётся и используется программа с максимально узкой специализацией. Binkd создавался с учётом такого подхода: это программа-демон, которая работает без непосредственного вмешательства человека и выполняет узкую задачу по приёму и передаче файлов между узлами сетей, построенных по технологии FTN (в частности, FIDOnet). В отличие от случаев использования почтовых программ, ориентированных на работу через модемы, в случае использования binkd подготовка почты к отправке (фактически превращение писем из почтовой базы в файлы – упаковка почты) осуществляется отдельными программами: тоссерами (tosser) в случае эхомейла и трекерами (netmail tracker) в случае нетмейла. подготовка файлов к пересылке по файл-эхам осуществляется тоже специализированными программами – файлэхопроцссорами. Более того, обработка файловых запросов в binkd реализована только при использовании специализированной программы FREQ-менеджера.

1.3. Клиент и сервер.

Binkd является приложением, предназначенным для работы в Internet (точнее, для работы в сетях, построенных по технологии TCP/IP). Каждое приложение Internet работает либо как сервер, принимающий соединения, либо как клиент, осуществляющий соединение с серверным приложением. В binkd эти две части соединены в одном приложении, поскольку алгоритмы работы в этих вариантах различаются несколькими деталями и основная часть кода при работе по протоколу binkp у клиента и у сервера совпадает. Однако пользователь может настроить binkd на работу только сервером либо только клиентом. Возможен также однократный запуск binkd с включенной только одной функцией (сервера либо клиента), при этом указываются специальные опции командной строки. В терминологии binkd серверная часть функционала реализуется сервер-менеджером (server manager), а клиентская – клиент-менеджером (client manager).

Поскольку в сетях TCP/IP нет монопольных ресурсов, например, таких как единственная телефонная линия в случае модемных коммутируемых соединений, сервер может принимать, а клиент - осуществлять одновременно множество соединений, независимых друг от друга. При этом для каждого соединения binkd создаёт отдельный процесс (или поток – в многопоточных операционных системах), и параллельная работа binkd с разными удалёнными узлами обеспечивается средствами операционной системы. Такой подход позволил не создавать собственный менеджер процессов, что значительно упростило програмирование. (Примечание. В однозадачных ОС, например, в MSDOS, binkd может работать либо клиентом, либо сервером, причем параллельная работа с разными линками исключается.)

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

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

1.4. Версии binkd.

Первые версии binkd нумеровались, начиная с нуля: 0.1, 0.2, ...0.9. Кроме того, после небольших доработок (исправление ошибок, небольшие улучшения) добавлялась и увеличивалась третья цифра: 0.9.1, 0.9.2, .... К промежуточным выпускам, распространяемым для отладки, добавлялась буква.

Начиная с версии 0.9.5 сделаны две ветки: стабильная, в которой только исправлялись ошибки, и ветка активной разработки. Стабильная ветка названа 0.9.5-stable и к ней относятся версии 0.9.6, 0.9.7, 0.9.8, 0.9.9, 0.9.10, 0.9.11, являющиеся исправленными релизами после 0.9.5. Следующая ветка обозначена как 1.0. Долгое время она находилась в разработке, было добавлено много новых возможностей, таких, как поддержка IPv6, перечитывание конфига "на лету" (без перезапуска), поддержка перловых хуков и многое другое. Когда она стала стабильной, была создана ветка binkd-1_0-stable, был выпущен релиз binkd 1.0.0, а в разработке находится ветка 1.1.

Стабильная ветка отличается от ветки в разработке тем, что в стабильной не добавляются новые возможности, а лишь исправляются замеченные ошибки. В случае обнаружения и исправления ошибок в стабильной ветке 1.0 будут выпущены исправленные версии 1.0.1, 1.0.2 и далее.

Для ветки, находящейся в разработке, версии нумеруются несколько иначе: 1.1a-номер_исправления, например, binkd 1.1a-295. Когда ветка 1.1 станет стабильной, появится ветка binkd-1_1-stable и релиз binkd 1.1.0, а в разработке станет версия 1.2.

1.5. Особенности binkd в разных ОС.

Binkd изначально разрабатывался для операционных систем семйства UNIX, но в настоящее время из одних и тех же исходных текстов компилируются версии также для OS/2, Amiga, DOS, Windows 3.x, Windows 9x, Windows NT/2000/XP/2003. При этом получается отдна и та же версия, но на разных платформах, отличия между которыми минимальны и определяются особенностями платформы и, иногда, компилятора.

Для OS/2 существует четыре варианта binkd: скомпилированный компилятором Watcom C, два варианта, скомпилированные EMX (GNU C) и вариант, скомпилированный ICC (IBM C Compiler) В первом и четвёртом вариантах получается полный исполняемый файл, во втором и третьем для работы binkd требуется установленный в системе EMX run-time. Соответственно скомпилированный Watcom исполняемый файл binkd имеет больший размер и потребляет больше ресурсов. Кроме того, из-за ошибок компиляторов в каждом варианте есть свои недостатки. Исполняемый файл, собранный посредством Watcom C, имеет имя binkd2.exe, собранный посредством ICC – binkd.exe, а собранный EMX – binkd2eo.exe либо binkd2e.exe в зависимости от того, собран он с в режиме OMF или нет.

В DOS binkd может работать только в среде IBM TCP/IP for PC-DOS, поэтому требуется разыскать и установить этот пакет поддержки сети. Источники IBM TCP/IP for PC-DOS указаны в Binkd FAQ.

Для 32-битных версий Windows существует несколько вариантов компиляции исполняемого файла binkd: варианты, работающие сервисами только в линейке Windows NT (это NT, 2000, XP, 2003) и варианты, работающие сервисами только в линейке Windows 95 (это 95, 98, Me). Другое деление – варианты, собранные в полный исполняемый файл (со всеми библиотеками, «статическая» сборка) и в исполняемый файл, который использует DLL (в первую очередь, msvcrt.dll). Кроме того, собрать binkd для Windows можно двумя компиляторами: Microsoft Visual C из пакета Visual Studio и GNU C из пакета MinGW32 или Cygwin. Для работы binkd, скомпилированного MinGW32, всегда необходима библиотека msvcrt.dll (MS Visual C run-time DLL), а для статически собранного с помощью Microsoft Visual C она не требуется. (Хотя особого смысла собирать статическую win32-версию binkd нет, поскольку очень многие программы используют библиотеку msvcrt.dll.)

Варинат binkd, работающий сервисом в Windows 95 (98, Me) отличается от других тем, что не имеет текстовой консоли и ничего не выводит на экран во время работы. Остановить его вручную можно только завершив процесс из менеджера задач Windows. Он называется bink/w9x и исполняемый файл имеет имя binkdw9x.exe. Обычный консольный binkd/w32 не способен работать сервисом в Windows 95 из-за особенностей реализации консоли win32 в этой ОС.

Для 16-битных версий Windows (Windows 3.1, Windows 3.11) binkd может работать только клиентом либо только сервером. Поэтому, чтобы и осуществлять вызовы, и принимать соединения, необходимо запускать две копии binkd/w16 с разными параметрами.

2. Установка binkd.

2.1. Установка скомпилированного пакета из дистрибутива.

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

2.1.1. Комплектация дистрибутивного пакета.

Дистрибутивные пакеты binkd, подготовленные разработчиками, содержат (в скобках указано имя файла/ов):

В последующем состав пакетов может быть изменён.

2.1.2. Последовательность действий для ОС семейства UNIX.

  1. Возьмите архив дистрибутива с последней версией binkd ветки binkd-1_0-stable из одного из официальных источников (либо из источника, которому Вы доверяете). Для разных ОС и дистрибутивов ОС он будет отличаться, например, для Red Hat Linux это пакет RPM, для Debian Linux – пакет DEB.

  2. Выполните установку (распаковку) пакета в соответствии с документацией на ОС.

  3. Найдите пример файла конфигурации: binkd.conf-dist. (Обычно он помещается в каталог /usr/local/etc.)

  4. Скопируйте binkd.conf-dist в binkd.conf, отредактируйте binkd.conf в соответствии с параметрами Вашей FTN-станции и желаемой функциональностью binkd. Подробно настройка binkd описана в главе 3.

  5. Проверьте правильность конфигурации, для чего укажите в файле конфигурации первой строкой слово debugcfg и запустите binkd, указав в командной строке параметр – имя файла конфигурации:
    binkd binkd.conf
    либо запустите binkd, указав в командной строке опцию -vvv и параметр – имя файла конфигурации:
    binkd -vvv binkd.conf
    (В последующих версиях binkd дамп конфигурации сделан иначе.)

  6. Если конфигурация неверна, binkd выведет диагностическое сообщение об ошибке и завершит работу. В этом случае придётся исправить ошибки. В случае правильной конфигурации binkd будет пытаться осуществить вызов, либо будет ждать соединения, либо завершится по прошествии времени, указанного в директиве rescan-delay файла конфигурации. Принудительно завершить работу binkd можно нажатием сочетания клавиш Ctrl-C.

  7. Если Вы хотите, чтобы binkd работал демоном и запускался при старте ОС, вставьте следующую строку вызова binkd в стартовый скрипт ОС согласно документации на вашу ОС:
    binkd -Dq binkd.conf

2.1.3. Последовательность действий для других ОС (Windows разных версий, OS/2, DOS и пр.).

  1. Возьмите выбранный Вами архив дистрибутива с последней версией binkd ветки binkd-1_0-stable для вашей ОС из одного из официальных источников (либо из источника, которому Вы доверяете).
    Для Windows существует две версии binkd: универсальная консольная версия (binkd/w32) и специализированная для работы сервисом в ОС Windows 95/98/Me (binkd/w9x). Отличие последней в том, что работает она без всякого вывода информации на экран и прервать её работу можно, только завершив процесс binkdw9x. Консольная же версия создаёт текстовое окно консоли win32 и в это окно выводятся сообщения протокола работы (если при запуске binkd не указана опция -q).
    Для OS/2 существует два варианта исполняемых файлов binkd: собранный компилятором Watcom C и собранный компилятором EMX (GNU C). Вариант, собранный Watcom C, не требует дополнительных программ (название архива и исполняемого файла начинается с «binkd2»). Вариант, собранный EMX, для работы требует установленного пакета EMX run-time версии не ниже 0.9c. Его можно скачать с сервера Hobbes (ftp://hobbes.nmsu.edu/pub/os2/unix/emx09c/), с CDROM.COM ( ftp://ftp.cdrom.com/pub/hobbes/emx09c/) и из других источников.

  2. Создайте каталог, в котором будет располагаться binkd, например, C:\ftn\binkd

  3. Распакуйте архив в приготовленный каталог.

  4. Отредактируйте конфигурационный файл binkd.cfg в соответствии с параметрами Вашей FTN-станции и желаемой функциональностью binkd.

  5. Проверьте правильность конфигурации, для чего укажите в файле конфигурации первой строкой слово debugcfg и запустите binkd, указав в командной строке параметр – имя файла конфигурации:
    binkd binkd.cfg
    либо запустите binkd, указав в командной строке опцию -vvv и параметр – имя файла конфигурации:
    binkd -vvv binkd.cfg
    (В последующих версиях binkd дамп конфигурации сделан иначе.)

  6. Если конфигурация неверна, binkd выведет диагностическое сообщение об ошибке и завершит работу. В этом случае придётся исправить ошибки. В случае правильной конфигурации binkd будет пытаться осуществить вызов, либо будет ждать соединения, либо завершится по прошествии времени, указанного в директиве rescan-delay файла конфигурации. Принудительно завершить работу binkd можно нажатием сочетания клавиш Ctrl-C.

  7. (Только для 32-битных версий Windows) В случае, если Вы хотите, чтобы binkd работал сервисом, выполните установку сервиса одной из команд:
    binkd -i binkd.cfg
    binkd -i -S binkd-service binkd.cfg
    где binkd-service – имя сервиса, которое Вы можете указать (по умолчанию используется «binkd-service»).
    В случае Windows NT (Windows 2000, Windows XP, Windows Server 2003) нужно использовать вариант binkd/w32, а в случае Windows 95 (Windows 98, Windows Me) – binkd/w9x. Если Вы попробуете установить сервисом неподходящий вариант binkd, результат достигнут не будет. В случае успешной установки сервисом binkd он будет сразу запущен (при условии достаточных прав пользователя у Вашей учетной записи в ОС).

2.2. Компиляция и установка binkd из исходных текстов.

Для компиляции исходных текстов Вам понадобится комплект компилятора и линковщика (часто поставляется в едином пакете). В операционных системах семейства UNIX (основанных на UNIX, совместимых с UNIX, подобных UNIX), вам понадобится компилятор GNU C версии 2.94 либо 3.2. В 32-битных операционных системах Windows понадобится либо Microsoft Visual C (Visual Studio), либо MinGW32 (GNU C для Win32, отдельным пакетом либо в комплекте с cygwin). Для OS/2 понадобится либо Watcom C версии 10.0 или 11.0, либо пакет EMX 0.9c (GNU C для OS/2), либо IBM C Compiler (ICC). Для MSDOS (PCDOS) понадобится Microsoft C 6.0 и пакет IBM TCP/IP for DOS. Для платформы Amiga понадобится Amiga Development Environment.

В большинстве платформ можно собрать разные варианты binkd: с минимумом возможностей (это вариант по умолчанию), с расширенным (отладочным) выводом, с поддержкой сервисов Windows 9x (в версии для Windows). Вариант компиляции задают параметры командной строки команды make (nmake, wmake, ...), они перечислены в начале файла с програмой сборки (файл с именем Makefile). Расшифровка:

Настройка binkd при установке самостоятельно скомпилированного binkd проводится так же, как и при установке из готового дистрибутива.

2.2.1. Компиляция и установка binkd в ОС семейства UNIX.

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

$ cp mkfls/unix/* ./
$ sh configure --help
(Скрипт configure выведет информацию о доступных опциях сборки, выберите нужные Вам и используйте как параметры в следующей команде. Например, поддержка прокси, поддержка NTLM аутентификации на прокси и поддержка ASO по умолчанию выключены)
$ sh configure –witn-aso –with-https --with-ntlm
(скрипт configure будет выводить информацию о множестве проверок)
$ make depend
(Будет проведено отслеживание зависимостей.)
$ make
(Будет проведена компиляция.)
$ make install
(Будет выполнена установка программы, файла конфигурации и страницы man.)
$ make clean
(Будет выполнено удаление промежуточных файлов.)

Если распакованные исходные тексты Вам более не нужны, Вы можете удалить каталог с ними.

2.2.2. Компиляция и установка binkd в 32-битных версиях Windows.

В Windows 95/98/Me либо в Windows NT/2000/XP/2003 лучшие результаты даёт компилятор Microsoft Visual C, желательно последней версии. Разработчики использовали для сборки binkd компиляторы MS Visual C версий 6 и 7 (из состава пакетов Visual Studio 6.0 и Visual Studio .NET). Сборка binkd выполняется командой nmake. В строке запуска можно использовать несколько параметров, они описаны в начале файла Makefile (располагается в подкаталоге mkfls\nt95-msvc в дереве каталогов с исходными текстами).

Другой вариант – использовать пакет MinGW32, представляющий собой компилятор GNU C, портированый для платформы Win32. Он может быть отдельным пакетом либо в составе пакета Cygwin. В случае использования MinGW32 сборка binkd осуществляется командой make и использует файл Makefile, расположенный в подкаталоге mkfls\nt95-mingw. В строке запуска make можно использовать несколько параметров, они описаны в начале файла Makefile. Также в среде Cygwin можно использовать ту же последовательность действий, что и для ОС семейства UNIX, но полученный таким образом исполняемый файл будет работать медленнее и ему потребуется динамически подгружаемая библиотека cygwin1.dll.

В случае компиляции DLL-варианта со встроенным Perl, учтите, какая версия и какой вариант perl используется компилятором и какой установлен в системе. То же самое относится и к библиотекам компрессии.

Распакуйте архив, содержащий исходные тексты binkd в некоторый каталог по Вашему выбору. Распаковывать нужно с сохранением всего дерева подкаталогов. Затем скопируйте в этот каталог все файлы из подкаталога, соответствующего выбранному Вами компилятору: mkfls\nt95-msvc в случае MS Visual C и mkfls\nt95-mingw в случае MinGW32. Затем запустите команду компиляции: nmake в случае MS Visual C и make в случае MinGW32.

Примеры компиляции с использованием MS Visual C:

nmake
nmake DLLRTL=1
nmake BINKD9X=1
nmake DLLRTL=1 BINKD9X=1

Примеры компиляции с использованием MinGW32:

make
make DEBUG=1
make BINKD9X=1

После успешной сборки с помощью Ms Visual C в зависимости от использованных опций компиляции Вы получите каталог Release, Release-w9x, Release-dll либо Release-w9x-dll с помещённым в него исполняемым файлом (binkd.exe, binkd9x.exe, binkd-dll.exe либо binkd9x-dll.exe).

После успешной сборки с помощью MinGW32 исполняемый файл будет располагаться в каталоге с исходными текстами.

Скопируйте в каталог, предназначенный для рабочей копии binkd, получившийся исполняемый файл и следующие файлы из базового каталога с исходными текстами binkd: файл конфигурации binkd.cfg и файлы документации binkd-faq.txt.ru (или binkd-faq.txt.en) и все остальные файлы, имена которых подходят под маски *.txt и *.htm. Для работы binkd необходимы только исполняемый файл и файл конфигурации, но документацию иметь под рукой не повредит.

2.2.3. Компиляция и установка binkd в OS/2.

В OS/2 лучшие результаты даёт компилятор ICC (IBM C Compiler), хотя он появился не так давно и результат его работы тестировался мало. Как и ICC, Watcom C даёт единый исполняемый файл, и скомпилированный им binkd тщательно оттестирован. Binkd, собранный EMX, наиболее близок к версии для UNIX (EMX-версия является многопроцессной, тогда как остальные - многопоточными), но он и потребляет больше ресурсов.

При компиляции учтите, какая версия драйвера стека TCP/IP установлена в системе и какая будет использована при компиляции (DLL могут отличаться). Также, в случае компиляции со встроенным Perl и с компрессией данных, учтите, какая версия и какой вариант perl используется. И, в случае компиляции с помощью EMX, убедитесь в совместимости библиотек компилятора и установленных в системе. Лучше всего использовать одни и те же библиотеки при сборке и во время работы binkd.

Распакуйте архив, содержащий исходные тексты binkd, в некоторый каталог по Вашему выбору. Распаковывать нужно с сохранением всего дерева подкаталогов. Затем скопируйте в этот каталог все файлы из подкаталога, соответствующего выбранному Вами компилятору: mkfls\os2-wc в случае использования Watcom C, mkfls\os2-emx в случае использования EMX, mkfls\os2-icc в случае использования ICC. Затем запустите команду компиляции: wmake в случае Watcom C, make или make -f Makefile.emo в случае EMX. В начале используемого Makefile перечислены возможные параметры запуска, задающие разные варианты компиляции.

После успешной сборки в зависимости от использованного компилятора и Makefile Вы получите файл binkd.exe, binkd2.exe, binkd2e.exe либо binkd2eo.exe.

Скопируйте в каталог, предназначенный для рабочей копии binkd, получившийся исполняемый файл и следующие файлы из базового каталога с исходными текстами binkd: файл конфигурации binkd.cfg и файлы документации binkd-faq.txt.ru (или binkd-faq.txt.en) и все остальные файлы, имена которых подходят под маски *.txt и *.htm. Для работы binkd необходимы только исполняемый файл и файл конфигурации, но документацию иметь под рукой не повредит.

2.2.4. Компиляция и установка binkd в DOS.

Сборка binkd в DOS возможна (во всяком случае пока) только компилятором Microsoft C 6.0 при наличии пакета IBM TCP/IP for DOS.

Распакуйте архив, содержащий исходные тексты binkd, в некоторый каталог по Вашему выбору. Распаковывать нужно с сохранением всего дерева подкаталогов. Затем скопируйте в этот каталог все файлы из подкаталога mkfls\dos-msc6 и запустите make.

После успешной сборки Вы получите файл binkd.exe.

Скопируйте в каталог, предназначенный для рабочей копии binkd, получившийся исполняемый файл и следующие файлы из базового каталога с исходными текстами binkd: файл конфигурации binkd.cfg и файлы документации binkd-faq.txt.ru (или binkd-faq.txt.en) и все остальные файлы, имена которых подходят под маски *.txt и *.htm. Для работы binkd необходимы только исполняемый файл и файл конфигурации, но документацию иметь под рукой не повредит.

2.2.5. Компиляция и установка binkd для Amiga.

Сборка binkd на платформе Amiga возможна с использованием ADE (Amiga Development Environment) при наличии библиотеки ixemul версии не ниже 0.47 (см. файл README в подкаталоге mkfls\amiga в каталоге с исходными текстами binkd).

Распакуйте архив, содержащий исходные тексты binkd, в некоторый каталог по Вашему выбору. Распаковывать нужно с сохранением всего дерева подкаталогов. Затем скопируйте в этот каталог все файлы из подкаталога mkfls\amiga и запустите make.

После успешной сборки Вы получите файл binkd.

Скопируйте в каталог, предназначенный для рабочей копии binkd, получившийся исполняемый файл и следующие файлы из базового каталога с исходными текстами binkd: файл конфигурации binkd.cfg и файлы документации binkd-faq.txt.ru (или binkd-faq.txt.en) и все остальные файлы, имена которых подходят под маски *.txt и *.htm. Для работы binkd необходимы только исполняемый файл и файл конфигурации, но документацию иметь под рукой не повредит.

3. Первичная настройка binkd.

В этой главе описана простейшая настройка binkd. Другими словами: выполнив описанные в этой главе действия, вы получите работоспособный мейлер, но без полной адаптации к Вашим условиям. Чтобы выполнить тонкую настройку, надо изучить главу о файле конфигурации и главы о работе binkd.

Для настройки binkd вам понадобится любой текстовый редактор, предназначенный для редактирования простых текстовых файлов (т.е. без оформления шрифтами, цветом и пр.). В Windows удобен встроенный редактор файлового менеджера FAR, хотя можно использовать и поставляющийся с ОС редактор Блокнот (Notepad). В OS/2 можно использовать E или EE, в MS-DOS – Edit, edlin или встроенный редактор Norton Commander, в юниксоподобных ОС – vi, ed, ee. Кроме перечисленных, подойдёт любой текстовый редактор, не вставляющий коды форматирования в текст.

Процесс настройки binkd заключается в редактировании файла конфигурации (binkd.cfg либо названного по Вашему выбору) и в создании описанных в файле конфигурации каталогов. Во время редактирования файла конфигурации смотрите на приведённые в нём примеры и комментарии (текст, помещённый справа от знака решётки «#»).

Все знаки «\» в файле конфигурации должны дублироваться, поскольку этот символ является символом искейпинга (подстановки спецсимволов).

Сделайте резервную копию файла конфигурации перед внесением изменений, чтобы не потерять исходный файл. Затем откройте файл конфигурации в выбранном Вами редакторе.

3.1. Обязательные параметры настройки.

В этом разделе описана настройка минимально необходимых директив файла конфигурации binkd, без которых он не будет работать.

3.1.1. Адреса и общая информация.

Отредактируйте строку address - укажите свой адрес в сети FIDOnet или в другой FTN-сети. Адрес нужно указывать в формате 5D, т.е. в виде зона:сеть/узел.пойнт@домен. Если адресов несколько – укажите их все, разделяя соседние пробелом.

Также замените информацию в строке «sysop» на Ваши личные данные, как они представлены в сети, укажите в строке «location» информацию о расположении и в строке «sysname» название FTN-системы (FTN-станции). В строке «nodeinfo» укажите скорость канала, либо полосу пропускания, отведённую binkd и, после запятой, флаги, описывающие параметры станции, разделяя их запятыми.

Пример:

address 2:5047/999@fidonet 2:5020/999.1@fidonet
sysop "Ivan Ivanov"
sysname "Ivan's BBS"
location "Magadan, Russia"
nodeinfo 115200,TCP,BINKP

3.1.2. Каталоги и файлы.

Укажите в строке «domain» использующийся в Вашей сети домен FTN (для сети FIDOnet укажите слово fidonet), через пробел укажите путь к каталогу почтовой очереди для зоны Вашего адреса и затем через пробел – номер этой зоны. Используемые в качестве разделителей каталогов обратные слэши «\» необходимо дублировать. (В ОС семейства unix разделители каталогов - прямые слэши и их дублировать не нужно.)

Укажите в строке «inbound» путь к каталогу, в который будут помещаться файлы, принятые во время сеансов связи, защищенных паролем. Этот каталог должен совпадать с каталогом, используемым программами распаковки почты и файлов (tosser, netmail tracker, fileechoprocessor, FREQ manager и др.)

Укажите в строке «inbound-nonsecure» путь к каталогу, в который будут помещаться файлы, принятые во время сеансов связи, не защищенных паролем. Он также должен совпадать с аналогичным для других программ.

Укажите в строке «log» путь к файлу, в который будет записываться протокол работы binkd.

Пример:

domain fidonet c:\\bbs\\outbound 2
log c:\\bbs\\log\\binkd.log
inbound c:\\bbs\\inbound
inbound-nonsecure c:\\bbs\\inbound\\unknown

3.1.3. Линки.

В строках «node» опишите FTN-системы, с которыми будет соединяться Ваш binkd (то есть линки Вашей FTN-системы). В простейшем случае нужно указать три параметра: адрес удалённой системы, её адрес IP либо доменное имя, пароль. Если же адрес удалённой системы описан в DNS в домене fidonet.net, вместо адреса IP можно указать знак «звёздочка» («*»). Вы также можете описать FTN-системы, связь с которыми будет осуществляться по их инициативе. Для этого вместо адреса удалённой системы укажите знак «минус» («-»), и binkd не будет пытаться соединиться с таким линком.

Примеры:

node 2:5047/996@fidonet 123.45.67.89 password996
node 2:5047/997@fidonet hostname997 password997
node 2:5047/998@fidonet * password998
node 2:5047/999.2@fidonet – password999.2

3.2. Необязательные параметры настройки.

Ниже перечислены директивы файла конфигурации, заданные разработчиками (в том виде, в котором они присутствуют в примере файла конфигурации из дистрибутива), но которые можно просто закомментировать (т.е. вставить в первую позицию знак «решётка» - «#»):

temp-inbound c:\\bbs\\inbound\\incomplete
filebox d:\\fido\\tmail\\boxes
brakebox d:\\fido\\brake\\boxes

Все остальные директивы файла конфигурации можно оставить без изменений.

3.3. Проверка конфигурации.

Чтобы проверить, правильно ли указаны пути и все ли необходимые параметры заданы, запустите binkd с указанием имени файла конфигурации в качестве параметра в строке запуска:

binkd binkd.cfg

Если binkd будет работать (а не завершится с диагностическим сообщением) – всё необходимые параметры заданы.

Второй этап проверки заключается в анализе дампа конфигурации, который выводит binkd при указании в командной строке опции «-vvv»:

binkd -vvv binkd.cfg

либо при добавлении в начало файла конфигурации директивы «debugcfg» и обычным запуском binkd.

(Описаны способы получения дампа конфигурации для версий 0.9.5 и более поздних 0.9.x. В последующих версиях binkd 1.x дамп конфигурации выводится другим способом.)

Завершить работу binkd можно нажатием на клавиатуре сочетания клавиш Ctrl-C.

4. Директивы файла конфигурации.

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

Комментарий начинается со знака «решётка» («#»), который может располагаться в любой позиции строки. Всё, что расположено справа от знака «решётка», игнорируется binkd.

Каждая директива файла конфигурации начинается с ключевого слова, которое может располагаться в любой позиции строки, но перед ключевым словом допускаются только пробелы или знаки табуляции (символы с кодами 32 и 9). Директива может состоять только из ключевого слова, либо за ключевым словом могут следовать один или несколько параметров, разделенные пробелами или знаками табуляции. Если параметр (например, пароль) содержит пробел, знак комментария («решётку») или знак табуляции, он должен быть заключён в кавычки либо указанный знак должен предваряться знаком «обратная косая черта» («\»). Если параметр содержит знак «обратная косая черта» («\»), этот знак должен дублироваться, а в некоторых случаях и учетверяться (такие случаи специально оговорены).

Порядок следования в файле конфигурации для некоторых директив имеет значение, поскольку binkd просматривает файл конфигурации сверху вниз. В тексте главы директивы приведены в алфавитном порядке для облегчения поиска.

В файле конфигурации можно использовать ссылки на переменные окружения (environment variables). Название переменной окружения с обеих сторон заключается в знаки процента («%»).

В дальнейшем для простоты под словом «пробел» подразумевается знак пробела либо знак табуляции.

«Нашей» FTN-системой названа система, которую мы конфигурируем. «Удалённой» FTN-системой названа система, с которой возможно соединение нашей FTN-системы по протоколу binkp.

4.01. address

Перечисление адресов нашей FTN-системы, разделённых пробелами. Адреса указываются в формате 5D, хотя возможно и указание их в сокращенной форме (3D или 4D). В случае сокращенной записи адреса, подставляется тот домен, который указан в первой строке «domain» файла конфигурации (в версиях 1.x такое поведение будет изменено). Нулевой номер пойнта у адреса узла указывать не рекомендуется.

Эта директива является обязательной.

Пример:

address 2:5047/999@fidonet 2:5020/999.1@fidonet

4.02. aso

Если директива aso указана в файле конфигурации, binkd будет работать с почтовой очередью стандарта Amiga Style Outbound (ASO) вместо Binkley Style Outbound (BSO), используемого по умолчанию.

Эта директива является необязательной.

Пример:

aso

4.03. backresolv

Если директива backresolv указана в файле конфигурации, binkd будет проводить поиск доменного имени по адресу удалённой FTN-системы, которая обратилась к binkd нашей FTN-системы. Такая операция требует некоторого времени (особенно в случае отсутствия адреса удалённой системы в DNS), на которое произойдёт задержка в процессе установлении сеанса связи.

Эта директива является необязательной.

Пример:

backresolv

4.04. bindaddr

Директива bindaddr задаёт адрес IP, который будет «слушать» серверная часть binkd. Эта директива обычно используется при необходимости использовать несколько копий binkd с разными конфигурациями на разных адресах либо ограничить использование binkd одним адресом IP.

Параметр – адрес IP в октетной записи. Значение по умолчанию – 0.0.0.0 (все адреса, имеющиеся на хосте).

Эта директива является необязательной.

Пример:

bindaddr 192.168.0.3

4.05. binlog

Директива binlog задаёт файл, в который binkd будет записывать статистику каждого соединения. Этот файл совместим с используемым в мейлере T-Mail и может быть обработан любой программой, работающей с двоичным логфайлом T-Mail, например, программой T-Hist. Параметр – строка, содержащая имя файла, обычно с путём. Значение по умолчанию не установлено (нет файла, протокол в двоичном виде не ведется).

Эта директива является необязательной.

Пример:

binlog c:\\bbs\\log\\binkd.sts

4.06. brakebox

Директива brakebox задаёт путь к каталогу файл-боксов в стиле мейлера «The Brake!». Путь указывается параметром этой директивы. Значение по умолчанию не установлено (файлбоксы не используются).

Эта директива является необязательной.

Пример:

brakebox C:\\fido\\brakebox

4.07. call-delay

Директива call-delay задаёт задержку перед запуском новых клиентских процессов (потоков) при достижении максимально разрешённого числа запущенных клиентских процессов (потоков), указанного в директиве maxclients. Побочное действие: на время этой задерки не проводится сканирование почтовой очереди. Параметр – целое неотрицательное число. Значение по умолчанию – 60 (секунд).

Эта директива является необязательной.

Пример:

call-delay 60

4.08. conlog

Директива conlog задаёт уровень протоколирования, который будет использоваться при выводе диагностических сообщений на консоль binkd. Параметр директивы – число (положительное или отрицательное в пределах -32768..32767 либо -2147483648..2147483647 в зависимости от компилятора, реальный смысл имеют значения от -1 до 10). Чтобы полностью запретить вывод на экран, достаточно указать значение, меньшее -1. Значение по умолчанию – 0.

Эта директива является необязательной.

Пример:

conlog 4

4.09. connect-timeout

Директива connect-timeout задаёт время ожидания при установлении соединения TCP. Параметр – целое неотрицательное число. Единицы измерения – секунды. Значение по умолчанию – 0 (используется таймаут, заложенный в ОС). Эта директива имеет смысл, если указанное значение меньше таймаута TCP сетевого драйвера операционной системы.

Эта директива является необязательной.

Пример:

connect-timeout 300

4.10. debugcfg

Если директива debugcfg указана в файле конфигурации, binkd перед началом работы выведет обработанную им конфигурацию, прочитанную из файла. Используется для проверки конфигурации. Эквивалентна указанию опции «-vvv» в строке запуска binkd. Эта директива устарела и в версиях binkd 1.x будет убрана.

Пример:

debugcfg

4.11. defnode

Директива defnode описывает умолчания для узлов, не описанных явно в файле конфигурации (в строках node). Значение по умолчанию не установлено (нет умолчаний). Параметры те же, что и директивы node.

Эта директива является необязательной.

Пример:

defnode -nd *

4.12. deletebox

Если директива deletebox указана в файле конфигурации, binkd при сканировании будет удалять пустые файлбоксы. Эту директиву нужно использовать с осторожностью, поскольку в случае работы в многозадачной ОС возможно завершение работы тоссера с ошибкой, например, в ситуации, когда тоссер пытается записать файл в файлбокс, непосредственно перед этим удалённый в binkd (тоссер не сможет создать файл).

Эта директива является необязательной.

Пример:

deletebox

4.13. deletedirs

Если директива deletedirs указана в файле конфигурации, binkd при завершении сеанса связи с линком будет удалять относящиеся к нему пустые каталоги в почтовой очереди. Действие этой директивы распространяется на пойнтовые адреса линка (т.е. адреса с ненулевым номером пойнта). Использование этой директивы совершенно безопасно в отличие от директивы deletebox.

Эта директива является необязательной.

Пример:

deletedirs

4.14. domain

Директива domain может указываться в двух форматах. Основной формат описывает FTN-домены с указанием основного каталога почтовой очереди (аутбаунда, outbound) и основной номер зоны для каждого домена. «Основной номер зоны» - это номер зоны, который не добавляется к пути к каталогу аутбаунда. Подробности см. в описании Binkley Style Outbound (BSO). Дополнительный формат указывает псевдоним (дополнительное имя, алиас) для ранее заданного домена.

Первый формат:

domain <домен> <путь> <номер зоны> [<root-domain>]

Второй формат:

domain <псевдоним> alias-for <домен>

Эта директива является обязательной.

Примеры:

domain fidonet c:\\bbs\\outbound\\fidonet 2
domain musicnet c:\\bbs\\outbound\\musicnet 333 musicnet.ru
domain fido alias-for fidonet
domain fidonet.org alias-for fidonet

В приведённых примерах для зоны 2 FTN-домена fidonet используется каталог c:\bbs\outbound\fidonet, для остальных зон FTN-домена fidonet используются каталоги c:\bbs\outbound\fidonet.<номер_зоны> (так, для зоны 1 – c:\bbs\outbound\fidonet.1). Для зоны 333 FTN-домена musicnet используется каталог c:\bbs\outbound\musicnet, для остальных зон FTN-домена musicnet – каталоги c:\bbs\outbound\musicnet.<номер_зоны>. При соединениях с линками, предъявившими адреса из доменов fido и fidonet.org, используется домен fidonet. (Такая возможность реализована для устранения последствий ошибочных конфигураций на удалённых узлах.)

Дополнительный необязательный параметр <root-domain> указывается для описания, какой интернетовский домен использовать для получения адреса узла, если в конфиге он прописан как «*». Если этот параметр не указан, используется глобальный параметр root-domain (по умолчанию - fidonet.net).

4.15. exec

Директива exec описывает условие и команду ОС, которая будет запущена при выполнении условия. Условием служит событие приёма файла, имя которого подходит под заданную маску. Команда, как правило, заключается в кавычки.

Если команда предваряется восклицательным знаком, она будет выполнена сразу по приёму файла. Иначе – по окончании сеанса.

В binkd для 32-хбитных версий Windows, кроме «!», можно использовать модификаторы «@» и «@@». «@» означает запуск програмы в отдельном окне консоли, «@@» - в скрытом окне.

В строке команды можно использовать макросы, начинающиеся с символа звездочки «*», поэтому знак звёздочки (не макрос) в команде должен предваряться символом искейпинга (обратной косой чертой «\»), а чтобы указать в команде этот символ, его нужно указывать дважды. В маске имени файла каждый символ искейпинга нужно дополнительно дублировать, поэтому пути в ОС Windows нужно указывать четыре знака «\» подряд (например: «c:\\\\binkd»).

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

Формат (последние два варианта могут быть использованы только в binkd/w32 и binkd/w9x):

exec "команда параметры и/или макросы" <маска имени>
exec "!команда параметры и/или макросы" <маска имени>
exec "@команда параметры и/или макросы" <маска имени>
exec "@@команда параметры и/или макросы" <маска имени>

где:

команда параметры и/или макросы – командная строка для запуска програмы с макросами или без них;

<маска имени> - маска имени файла, проверяемая по приёму каждого файла.

Возможные макросы:

*F – полное имя принятого файла (с путём);

*A0..*A9 – первые 10 адресов удалённой системы (*A0 – первый адрес, *A9 – десятый адрес);

*A*, *A@ - список всех адресов удалённой системы, разделенных пробелами;

*P – признак парольности сеанса, принимает значения 0 (непарольный) или 1 (парольный);

*L - признак известности удалённой системы (т.е. Описана ли эта система в строке node), принимает значения 0 (неизвестна) или 1 (известна);

*H – имя хоста или адрес IP удалённой системы;

*N – короткое имя приянтого файла (используется только в версии для 32х-битных ОС Windows);

*S – имя файла с информацией SRIF (см. !SRIF.TXT из дистрибутива или комплекта исходных текстов binkd, также см. документ FTSC «FSC-0086.001»).

Эта директива является необязательной.

Примеры:

exec "!my-freq-processor.exe /options *S" *.req
exec "d:\\path\\my-pkt-unpacker.exe /options *A*" c:\\\\bbs\\\\inbound\\\\*.pkt
exec "d:\\path\\my-tosser.exe /options" *.su? *.mo? *.tu? *.we? *.th? *.fr? *.sa?
Exec "!d:\\path\\my-pkt-filter.exe *F /options" c:\\\\bbs\\\\inbound\\\\unsecure\\\\*.pkt
exec "d:\\path\\my-special-unpacker.bat /options" c:\\\\bbs\\\\inbound-of-my-friend\\\\*

В первом примере binkd сформирует файл по стандарту SRIF и запустит программу my-freq-processor.exe с указанными параметрами сразу по приёму файла, заканчивающегося на «.req», независимо от того, с каким линком проходит сеанс связи (защищен паролем или нет, и даже если для линка используется отдельный каталог для приёма файлов). Программа должна располагаться в текущем каталоге или в каталоге, который указан в переменной окружения PATH. Во втором примере по окончании сеанса связи будет выполнена команда d:\path\my-pkt-unpacker.exe с указанными опциями, в конец будет подстановлено имя файла, если сеанс связи был защищён паролем и в парольный инбаунд был принят файл с пакетом нетмейла. В третьем примере программа будет выполнена по окончании сеанса связи с любым линком, если был принят пакет эхомейла. В четвёртом примере программа будет выполнена во время сеанса связи, не защищенного паролем, в котором был принят файл с пакетом нетмэйла, в начале списка параметров команды будет вставлено имя принятого файла с путём. В пятом примере скрипт будет выполнен по окончании сеанса связи с узлом, в строке node для которого указан входящий инбаунд в случае, если от этого линка был принят любой файл.

4.16. fdinhist

Директива fdinhist задаёт имя файла, в который в двоичном виде будет записываться статистика входящих сеансов связи. Формат файла совместим с мейлером «FrontDoor», что позволяет использовать анализаторы статистики, разработанные для этого мейлера.

Параметр – путь и имя файла. Значение по умолчанию не установлено.

Эта директива является необязательной.

Пример:

fdinhist c:\\bbs\\log\\in.his

4.17. fdouthist

Директива fdouthist задаёт имя файла, в который в двоичном виде будет записываться статистика исходящих сеансов связи. Формат файла совместим с мейлером «FrontDoor», что позволяет использовать анализаторы статистики, разработанные для этого мейлера.

Параметр – путь и имя файла. Значение по умолчанию не установлено.

Эта директива является необязательной.

Пример:

fdouthist c:\\bbs\\log\\out.his

4.18. filebox

Директива filebox задаёт путь к каталогу файл-боксов в стиле мейлера «T-Mail». Путь указывается параметром этой директивы. Binkd умеет работать с файлбоксами в «коротком» и в «длинном» формате T-mail. Подробнее о формате файлбоксов см. в п. 7.1.3 и в документации на мейлер «T-Mail». Значение по умолчанию не установлено (файлбоксы не используются).

Эта директива является необязательной.

Пример:

filebox c:\\bbs\\filebox

Примечание.

Файлбоксы стиля T-mail используют 4D-адресацию FTN, поэтому их не рекомендуется использовать в случае работы с несколькими доменами FTN.

4.19. flag

Директива flag задаёт условие и имя файла, который будет создан при выполнении условия. Файл создатся пустым (длиной 0 байт). Если файл существует, он не будет перезаписан, но будет обновлено время его модификации. Условием служит событие приёма файла, имя которого подходит под заданную маску.

Имеет смысл указывать полный путь к файлу флага. В пути к файлу флага каждый символ «\» нужно указывать дважды. В маске имени файла его нужно дополнительно дублировать, поэтому пути файлам в ОС Windows нужно указывать четыре знака «\» подряд (например: «c:\\\\binkd»).

Эта директива является необязательной.

См. также описание директивы exec.

Примеры:

flag c:\\bbs\\flags\\toss.now *.su? *.mo? *.tu? *.we? *.th? *.fr? *.sa?
flag c:\\bbs\\flags\\netmail.in c:\\\\bbs\\\\inbound\\\\*.pkt

4.20. ftrans

Директива ftrans задаёт правила подстановки строк в путях, перечисленных в файлах-списках (*.?lo) почтовой очереди. Используется в случае использования binkd и других программ на разных компьютерах, возможно с разными ОС (например, binkd на сервере под FreeBSD, а тоссер и редактор на компьютере пользователя под Windows 2000). При этом каталог почтовой очереди располагается на сетевом диске и пути к нему отличаются на разных компьютерах. Параметры – две строки: заменяемая и заменяющая, как правило заключаются в кавычки.

В случае использования смешанного окружения (ОС семейства UNIX и Windows, OS/2, DOS), когда символ разделителя элементов пути различается, необходимо использовать два правила (задавать две директивы ftrans): для подстановки пути и для подстановки разделителя. В строках поиска и подстановки каждый символ «\» нужно указывать дважды.

Формат:

ftrans "заменяемая подстрока" "заменяющая подстрока"

Эта директива является необязательной.

Примеры:

ftrans "D:\\fido\\outbound" "/var/spool/fido/outb"
ftrans "\\" "/"
ftrans "D:\\fido\\outbound" "М:\\outbound"

4.21. hold

Директива hold задаёт паузу между сериями попыток вызова линка в случае его недоступности. Пауза устанавливается после заданного директивой try числа попыток соединения. Параметр – положительное число. Пауза задаётся в секундах. Значение по умолчанию: 0 (нет паузы).

Технически пауза реализуется путём записи в файл NNNNMMMM.hld строки с числом - временем окончания паузы в формате unixtime, левая часть имени файла совпадает с левой частью имени файлов *.?ut и *.?lo для этого линка. (См. п. 7.3.2.)

Эта директива является необязательной.

Пример:

hold 600

4.22. hold-skipped

Директива hold-skipped задаёт

Параметр – целое неотрицательное число. Значение по умолчанию – 0 (нет предела).

Эта директива является необязательной.

Пример:

hold-skipped

4.23. inbound

Директива inbound указывает путь к каталогу, в который binkd помещает файлы, принятые во время сеансов связи, защищённых паролем (во время парольных сессий). Этот каталог должен быть одинаковым в настройках всех программ, составляющих нашу FTN-систему. В пути к файлу каждый символ «\» нужно указывать дважды.

Эта директива является обязательной.

Пример:

inbound c:\\bbs\\inbound

4.24. inbound-nonsecure

Директива inbound-nonsecure указывает путь к каталогу, в который binkd помещает файлы, принятые во время сеансов связи, не защищённых паролем (во время непарольных сессий). Этот каталог должен быть одинаковым в настройках всех программ, составляющих нашу FTN-систему, если он указан в этих программах. В пути к файлу каждый символ «\» нужно указывать дважды.

Эта директива является необязательной. В случае её отсутствия все принятые файлы помещаются в каталог, указанный в директиве inbound.

Пример:

inbound-nonsecure c:\\bbs\\inbound\\unsecure

4.25. inboundcase

Директива inboundcase задаёт режим преобразования регистра букв в имёнах принятях binkd файлов. Возможные значения режима:

Параметр – строка, принимающая одно из четырёх значений: «save», «upper», «lower», «mixed». Значение по умолчанию – «save» (оставлять имена файлов без изменения).

Эта директива является необязательной.

Пример:

inboundcase save

4.26. include

Директива include используется для включения части конфигурации из другого файла. Параметр директивы – строка, путь к включаемому файлу. Может использоваться, к примеру, для запуска нескольких копий binkd с файлами конфигурации, различающимися в части параметров и большой общей (включаемой) частью конфигурации. В пути к файлу каждый символ «\» нужно указывать дважды.

Пример:

include c:\\bbs\\binkd\\nodes.cfg

4.27. iport

Директива iport задаёт TCP порт, который будет открыт binkd для приёма входящих соединений. Эта директива может использоваться для установки нестандартного порта для работы binkd, в частности для обхода запрещающих правил сетевого шлюза-брандмауэра.

Параметр – целое положительное число либо строка (название номера порта из файла /etc/services в unix и c:\winnt\system32\drivers\etc\services в Windows NT и 2000, в c:\windows\system32\drivers\etc\services вWindows XP и 2003). Значение по умолчанию – 24554.

Эта директива является необязательной.

Пример:

iport 443

4.28. kill-dup-partial-files

Если директива kill-dup-partial-files указана в файле конфигурации, binkd при приёме нового файла будет удалять не полностью принятый файл с тем же именем, но отличающийся временем изменения и размером. Если эта директива не указана, в каталоге приёма файлов (в каталоге, указанном директивой temp-inblund либо, если временный каталог инбаунда не задан, в каталогах inbound и inbound-nonsecure) будут накапливаться файлы с именами *.dt и *.hr.

Эта директива является необязательной.

Пример:

kill-dup-partial-files

4.29. kill-old-bsy

Если директива kill-old-bsy указана в файле конфигурации, binkd будет удалять из каталога почтовой очереди файлы-флаги занятости удалённой системы *.bsy, которые старше, чем указанный в параметре период времени.

Параметр – целое положительное число, единицы измерения - секунды. Значение по умолчанию не установлено (файлы *.bsy не удаляются).

Эта директива является необязательной.

Пример:

kill-old-bsy 43200

4.30. kill-old-partial-files

Директива kill-old-partial-files задаёт время, по истечении которого binkd будет удалять старые частично принятые файлы. Время указывается в параметре директывы положительным целым числом, измеряется в секундах. Если эта директива не указана, в каталоге приёма файлов (в каталоге, указанном директивой temp-inblund либо, если временный каталог не задан, в каталогах inbound и inbound-nonsecure) будут накапливаться файлы с именами *.dt и *.hr.

Эта директива является необязательной.

Пример:

kill-old-partial-files 86400

4.31. location

Директива location задаёт название местности, в которой расположена FTN-система. Это исключительно справочная информация, которая предъявляется удалённой стороне во время процедуры опознания FTN-системы. Параметр – текстовая строка, обычно заключается в кавычки.

Эта директива является обязательной.

Пример:

location "Magadan, Russia"

4.32. log

Директива log задаёт имя файла, в который binkd будет записывать протокол своей работы. В большинстве случаев имеет смысл указывать имя файла с путём, чтобы исключить путаницу при запуске binkd из разных каталогов файловой системы. В пути к файлу каждый символ «\» нужно указывать дважды.

Параметр – строка. Значение по умолчанию не установлено (протокол не ведется).

Эта директива является обязательной. При запуске binkd сервисом в Windows и демоном в ОС семейства UNIX имеет смысл указывать её первой директивой файла конфигурации, чтобы ошибки конфигурации были записаны в файл протокола.

Пример:

log c:\\bbs\\logs\\binkd.log

4.33. loglevel

Директива loglevel задаёт уровень протоколирования, который будет использоваться при выводе диагностических сообщений в файл протокола binkd либо в syslog. Параметр директивы – положительное число (положительное или отрицательное в пределах 0..32767 либо 0..2147483647 в зависимости от компилятора, реальный смысл имеют значения от 0 до 10). Значение по умолчанию – 0 (протоколируются только критические ошибки).

Перечень уровней протоколирования:
-1 – сообщения windows-версии об установке, удалении и состоянии сервиса;
0 – критическая ошибка, в результате которой дальнейшая работа binkd невозможна;
1 – ошибки и причины остановки;
2 – ошибки соединения, трансляция путей, изменения файла конфигурации, состояние протокола binkp;
3 – включение/выключение расширений binkp, прием и отправка файлов, запуск внешних программ, удаление пустых файлбоксов;
4 – запуск binkd, код возврата завершившегося потомка, полл, ошибка сервера, работа с файлами и др.;
5 – работа с DNS, открытие/закрытие сокетов и файлов, обрезание и переименование файлов и др.;
6 – протокол binkp, относительные пути;
7 – адреса в режиме ND, прием и передача блоков данных;
8 – преобразования имён файлов, таймаут в Windows 9x, адреса удалённой системы, время операции, ...;
9 – информация о процессе приёма;
10 – отладочные сообщения о взаимодействии с прокси.

Эта директива является необязательной.

Пример:

loglevel 4

4.34. maxclients

Директива maxclients задаёт максимально допустимое для binkd число клиентских процессов (или потоков в многопоточных ОС), которые могут работать одновременно. Другими словами: это максимально возможное число одновременных исходящих сеансов связи. Параметр – целое неотрицательное число. Значение по умолчанию – 100.

Эта директива является необязательной.

Пример:

maxclients 2

4.35. maxservers

Директива maxservers задаёт максимально допустимое для binkd число серверных процессов (или потоков в многопоточных ОС), которые могут работать одновременно. Другими словами: это максимально возможное число одновременных входящих сеансов связи. Параметр – целое неотрицательное число. Значение по умолчанию – 100.

Эта директива является необязательной.

Пример:

maxservers 2

4.36. minfree

Директива minfree задаёт минимально допустимое количество свободного места на разделе диска, в котором расположен каталог, описанный в директиве inbound. Параметр – неотрицательное число, обозначает количество килобайт. Если во время парольной сессии binkd обнаружил, что свободное место после приёма следующего файла станет меньше указанного, он в этом сеансе отказывается от приёма файлов и работает только на отправку. Значение по умолчанию не установлено (без ограничений).

Эта директива является необязательной.

Пример:

minfree 2048

4.37. minfree-nonsecure

Директива minfree-nonsecure задаёт минимально допустимое количество свободного места на разделе диска, в котором расположен каталог, описанный в директиве inbound. Параметр – неотрицательное число, обозначает количество килобайт. Если во время непарольной сессии binkd обнаружил, что свободное место после приёма следующего файла станет меньше указанного, он в этом сеансе отказывается от приёма файлов и работает только на отправку. Значение по умолчанию не установлено (без ограничений).

Эта директива является необязательной.

Пример:

minfree-nonsecure 2048

4.38. node

Директива node описывает параметры линка, с которым возможно соединение.

Формат (необязательные параметры заключены в квадратные скобки, обязательные – в угловые скобки, фигурные скобки обрамляют варианты, один из которых обязателен, варианты разделяются символом «|»):

node <FTN-адрес> [-nr|-nd] [-md|-nomd] [-ip|-sip] [{адреса хостов|-} [{пароль|-} [атрибут [{аутбокс|-} [{инбокс|-}]]]]]

где:

Эта директива является необязательной. В случае, когда устанавливается сеанс связи с линком, не описанным в директиве node, используются настройки, заданные директивой defnode и пароли из файла паролей, указанного в директиве passwords.

Пример:

node 5047/888 - password
node 5047/999 hostname;* password i c:\\bbs\\boxes\\to999 c:\\bbs\\boxes\\from999

4.39. nodeinfo

Директива nodeinfo описывает параметры нашей FTN станции. Принято указывать максимально возможную в сеансе связи скорость (в форме «число» (байт) либо «ЧислоЕдиницаизмерения») и, через запятую, поддерживаемые флаги нодлиста.

Параметр – произвольная строка. Значение по умолчанию не установлено.

Эта директива является обязательной.

Пример:

nodeinfo 128K,IBN,XW

4.40. oblksize

Директива oblksize задаёт максимальный размер передаваемого блока данных в байтах. Уменьшение значения может потребоваться в ситуации с большим количеством потерь пакетов IP (с целью уменьшить избыточный трафик при повторной посылке пакетов в TCP). Увеличение значения повышает эффективность передачи файлов (в каждом блоке данных binkp 1.0 используется 2 байта на служебную информацию).

Параметр – целое положительное число. Значение по умолчанию – 4096 (байт). Максимально допустимое значение – 32767 (ограничено протоколом binkp).

Эта директива является необязательной.

Пример (в котором значение размера блока устанавливается таким, чтобы исключить фрагментацию пакетов IP при подключении по Ethernet):

oblksize 1445

4.41. oport

Директива oport назначает порт, на который binkd будет пытаться установить соединение в том случае, когда порт для линка не указан явно в адресе хоста линка в строке node.

Параметр – целое положительное число либо строка (название номера порта из файла /etc/services в unix и c:\winnt\system32\drivers\etc\services в Windows NT и 2000, в c:\windows\system32\drivers\etc\services вWindows XP и 2003). Значение по умолчанию – 24554.

Эта директива является необязательной.

Пример:

oport 24555

4.42. overwrite

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

Параметры – список строк, разделенных пробелами. Каждый параметр описывает одну маску имени файла без указания пути.

Эта директива является необязательной.

Пример:

overwrite net_*.*

4.43. passwords

Директива passwords задаёт имя файла паролей стиля мейлера T-mail. Директива используется для ведения списка паролей в одном месте (в одном файле) на станции FTN.

Параметр – строка, имя файла, обычно с путём. В пути к файлу каждый символ «\» нужно указывать дважды. Значение по умолчанию не установлено (файл паролей не используется).

Формат файла паролей (угловые скобки обозначают обязательные элементы, квадратные – необязательные):

<адрес FTN> [пароль]

Эта директива является необязательной.

Пример:

passwords c:\\t-mail\\password.lst

4.44. percents

Если директива percents указана в файле конфигурации, binkd выводит на консоль (экран) информацию о том, какая часть файла передана или принята.

Параметра нет.

Эта директива является необязательной.

Пример:

percents

4.45. pid-file

Директива pid-file задаёт имя файла, который будет использоваться для хранения идентификатора процесса binkd во время его работы. Этот файл используется в ОС семейства unix для простоты обнаружения неработающего binkd в случае его аварийного завершения и для простоты управления демоном binkd (например, команда, инициирующая перечитывание файла конфигурации, выглядит так: «kill -1 `cat binkd.pid`»). См. также п. 7.3.1.

Параметр – строка, имя файла, обычно с путём. В пути к файлу каждый символ «\» нужно указывать дважды. Значение по умолчанию не установлено (файл PID не используется).

Эта директива является необязательной.

Пример:

pid-file /var/run/binkd.pid

4.46. prescan

Директива prescan задаёт дополнительное сканирование каталога почтовой очереди для линка уже после установления с ним соединения и при передаче файлов.

Параметр отсутствует.

Эта директива является необязательной.

Пример:

prescan

4.47. printq

Если директива printq указана в файле конфигурации, binkd выводит на консоль (экран) информацию о состоянии почтовой очереди при каждои её сканировании.

Параметр отсутствует.

Эта директива является необязательной.

Пример:

printq

4.48. proxy

Директива proxy задаёт параметры сервера прокси стандарта HTTP/HTTPS, который должен использовать binkd для осуществления исходящих соединений. Совместно с binkd можно использовать любой сервер прокси, который поддерживает команду CONNECT протокола HTTP. Соединение с сервером прокси может быть защищено комбинацией логина и пароля, при этом возможно использование методов аутентификации BASIC и NTLM-DIGEST. Примеры совместимого ПО серверов прокси: Squid, MS ISA Server, OOPS, WinProxy, WinGate.

Параметр - строка вида:

адрес:порт[/логин/пароль[/имя_компьютера/домен_windows]]

, где:

Значение по умолчанию не установлено (прокси стандарта HTTP/HTTPS не используется).

Эта директива является необязательной.

Примеры:

proxy proxy.my.dom:3128
proxy proxy.secure.my.dom:3128/login/password
proxy proxy.ntlm.my.dom:1080/login/password/myhost/domain

В первом примере используется прокси без аутентификации, во втором – c аутентификацией BASIC, в третьем - с аутентификацией NTLM.

4.49. rescan-delay

Директива rescan-delay задаёт задержку между сканированиями почтовой очереди. Эта задержка может увеличиваться на значение, казанное в директиве call-delay. Побочное действие директивы – регулирует задержку перед завершением binkd в случае использования опции командной строки «-p».

Параметр – целое положительное число. Значение по умолчанию – 60 (секунд).

Эта директива является необязательной.

Пример:

rescan-delay 2

4.50. root-domain

Директива root-domain задаёт строку базового домена DNS для формирования имени DNS для хоста линка из его адреса FTN.

Формат преобразования:

pПОЙНТ.fНОДА.nСЕТЬ.zЗОНА.root-domain.
fНОДА.nСЕТЬ.zЗОНА.root-domain.

где ПОЙНТ, НОДА, СЕТЬ и ЗОНА обозначают соответствующие номера-части адреса FTN линка, если номер пойнта отсутствует или равен нулю, он не транслируется и эта часть домена DNS не используется. Так, адрес 1:2/3.4 преобразуется к виду «p4.f3.n2.z1.fidonet.net.» при указании базового домена «fidonet.net.»

Параметр – строка. Значение по умолчанию – «fidonet.net.». Рекомендуется указывать имя домена, завершая его точкой, во избежание автоматического поиска домена в процедуре разрешения доменных имён с подстановкой в конец строк домена по умолчанию и доменов для поиска, описанных в конфигурации ОС.

Эта директива является необязательной.

Пример:

root-domain fidonet.net.

4.51. send-if-pwd

Если директива send-if-pwd указана в файле конфигурации, binkd будет отправлять файлы в случае входящего сеанса связи, защищённого паролем и при любом исходящем сеансе связи. Если эта директива указана и на линка с отсутствующим паролем имеется почта либо файлы с атрибутом hold, они могут никогда не быть переданы. Такая почта никогда не будет передана на линка, у которого не указан адрес хоста.

Эта директива является необязательной.

Пример:

send-if-pwd

4.52. skipmask

Директива skipmask задаёт маски имён файлов, которые не будут приниматься binkd на нашей стороне и будут удаляться как успешно переданные на стороне линка.

Параметры – список масок имён файлов без путей. Значение по умолчанию не установлено (принимаются все файлы).

Эта директива является необязательной.

Пример:

skipmask *.avi pm2.*

4.53. socks

Директива socks задаёт параметры прокси-сервера стандарта socks, который должен использовать binkd для осуществления исходящих соединений. Совместно с binkd можно использовать socks версий 4 и 5, при использовании socks 5 соединение с сервером socks может быть защищено комбинацией логина и пароля.

Параметр - строка вида:

адрес:порт[/[логин/пароль]]

, где:

В случае использования socks 4 указывается только адрес и порт, в случае использования socks 5 без аутентификации в конец строки добавляется символ косой черты «/», в случае использования socks 5 с аутентификацией используется полный формат.

Значение по умолчанию не установлено (прокси стандарта socks не используется).

Эта директива является необязательной.

Примеры:

socks socks4.my.dom:1080
socks socks5.my.dom:1080/
socks socks5.secure.my.dom:1080/login/password

В первом примере используется socks 4, во втором – socks 5 без аутентификации, в третьем - socks 5 с аутентификацией по логину и паролю.

4.54. syslog

Если директива syslog указана в файле конфигурации, binkd выводит протокол работы в системный лог ОС. Директива действительна только в ОС семейства UNIX и binkd, скомпилированный для других ОС, воспринимает эту директиву как ошибочную (неизвестную).

Параметр – строка, название syslog facility. Возможные значения: «kern», «user», «mail», «daemon», «auth», «syslog», «lpr», «news», «uucp», «cron», «authpriv», «ftp», «local0», «local1», «local2», «local3», «local4», «local5», «local6», «local7» (уточнить список допустимых для Вашей ОС значений можно в странице man syslog). Значение по умолчанию не установлено.

Эта директива является необязательной.

Пример:

syslog local0

4.55. sysname

Директива sysname задаёт название нашей FTN станции.

Параметр – произвольная строка, обычно заключается в кавычки.

Эта директива является обязательной.

Пример:

sysname «My Cool Station»

4.56. sysop

Директива sysop задаёт имя сисопа нашей FTN-системы. Параметр – строка, обычно заключается в кавычки.

Эта директива является обязательной.

Пример:

sysop Ivan

4.57. temp-inbound

Директива temp-inbound задаёт путь к каталогу для временного хранения принятых не до конца файлов. Если указана, все принимаемые binkd файлы сначала записываются в этот каталог, затем перемещаются в каталог, указанный к директиве inbound или inbound-nonsecure. Для скорости перемещения файлов имеет смысл располагать каталоги, описанные в директивах «temp-inbound», «inbound» и «inbound-nonsecure» на одном дисковом логическом разделе (томе). Параметр – строка-путь. Значение по умолчанию – не установлено.

Эта директива является необязательной.

Пример:

temp-inbound c:\\bbs\\inbound\\binkdtmp

4.58. timeout

Директива timeout задаёт время ожидания ответа в секундах при установленном TCP-соединения с удалённой системой. Параметр – целое неотрицательное число. Значение по умолчанию – 300 (т.е. пять минут).

Эта директива является необязательной.

Пример:

timeout 300

4.59. try

Директива try задаёт число попыток вызова удалённой FTN-системы, после неудачи которых вызовы этой системы будут приостановлены на время, указанное в директиве hold. Параметр – целое неотрицательное число. Значение по умолчанию – 0 (нет ограничения числа попыток).

Эта директива является необязательной.

Пример:

try 10

4.60. tzoff

Директива tzoff задаёт смещение локального часового пояса к мировому времени UTC в секундах. Параметр – целое число. Значение по умолчанию – 0 (время на часах компьютера соотвествует UTC).

Эта директива является необязательной и её использование необходимо только в тех операционных системах и при компиляции binkd теми компиляторами, в которых нет готовых функций вычисления времени UTC. В каждом конкретном случае имеет смысл проверить, соответствует ли время событий, записанных в файл протокола, UTC. Нет необходимости использовать эту директиву в Windows, OS/2, ОС семейства UNIX.

Пример (смещение UTC+6):

tzoff 1800

5. Параметры командной строки.

Binkd при нормальной работе должен быть запушен с указанием параметров в командной строке.

Формат строки вызова binkd (указаны все возможные опции для всех ОС, необязательные элементы заключены в квадратные скобки, знак «|» разделяет варианты – т.е. опции, которые не могут быть использованы одновременно):

[/path/to/]binkd [-[C][c][p][q][r][s][v][m][h][T][i|u]] [-t srvcmd] [-S srvn] [-P node] config

Параметры, начинающиеся со знака минус («-»), называются опциями (options). Все буквы в опциях – латинские. Порядок указания опций не имеет значения, главное чтобы параметр – имя файла конфигурации был указан последним.

Набор действующих опций зависит от ОС, для которой скомпилирован binkd, и от варианта сборки binkd.

Краткую справку по параметрам командной строки binkd можно всегда получить, запустив binkd без параметров или с параметром «-h». Пример для Windows NT:

C:\fido\binkd> binkd -h
usage: binkd [-CcpqrsvmhTiu] [-S srvn] [-P node] config
-C exit(3) on config change
-c run client only
-T minimize to System Tray
-i install WindowsNT service
-u uninstall WindowsNT service
-S srvn name of WindowsNT service (default: binkd-service)
-P node poll a node
-p run client only, poll, quit
-q be quiet
-r disable crypt traffic
-s run server only
-v be verbose / dump version and quit
-m disable CRAM-MD5 authorization
-h print this help

Copyright (c) 1996-2012 Dima Maloff and others.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation. See COPYING.

Report bugs to 2:463/68 or binkd-bugs@happy.kiev.ua.

Далее в этой главе следуют описания каждой опции.

5.01. -C (заглавная, прописная буква «C»).

Если binkd запущен с опцией «-C», он перед сканированием почтовой очереди будет проверять обновление файла конфигурации. В ОС семейства UNIX и при работе сервисом в 32-х битных ОС Windows в случае, если файл конфигурации изменился, binkd запустит себя заново и предыдущая копия завершится (в Windows с кодом возврата 3, в UNIX - 0). В версиях для DOS и Windows 3.x и при работе binkd/w32 в обычном режиме (не сервисом) binkd завершится с кодом возврата 3. Это используется для автоматического принятия изменений в файле конфигурации binkd.

Пример командного файла для MS DOS и Windows:

@echo off
:loop
c:\bbs\binkd\binkd -C c:\bbs\binkd\binkd.cfg
if errorlevel 4 goto end
if errorlevel 3 goto loop
:end

5.02. -c (строчная буква «c»).

Опция «-c» запрещает binkd принимать входящие соединения, т.е. в binkd работает только клиентская часть.

Пример:

binkd -c binkd.cfg

5.03. -D (прописная буква «D»).

Опция «-D» указывает binkd работать демоном (в фоновом режиме). Имеет смысл только для ОС семейства UNIX и в других ОС эта опция недоступна.

Пример:

/usr/local/sbin/binkd -D /usr/local/etc/binkd.conf

5.04. -h (строчная буква «h»).

Binkd, вызванный с опцией «-h», выведет на экран информацию формате командной строки и о доступных опциях, затем завершит работу. Такое же поведение у binkd, запущенного без указания в командной строке параметров и опций, а также с неподерживаемыми им опциями. При использовании опции «-h» файл конфигурации в командной строке указывать не обязательно.

Пример:

binkd -h
binkd

5.05. -i (строчная буква «i»).

Действие опции «-i» зависит от операционной системы, для которой скомпилирован binkd. В 32-хбитных ОС семейства Windows эта опция используется для установки сервиса с теми параметрами, которые были заданы совместно с опцией «-i». Binkd устанавливает себя сервисом и сразу запускает этот сервис. В ОС семейства UNIX и в OS/2 эта опция служит для запуска binkd из-под демона inetd, при этом подразумевается опция «-s». Опция «-i» не может использоваться одновременно с опцией «-u» (в Windows).

Примеры команд установки сервиса для Windows 2000 (NT, XP, 2003):

binkd -i binkd.cfg
binkd -i -S binkd binkd.cfg
binkd -i -S binkd -s -T binkd.cfg

Примеры команд установки сервиса для Windows 95 (98, Me):

c:\bbs\binkd\binkd9x -i c:\bbs\binkd\binkd.cfg
binkd9x -i -S binkd binkd.cfg

Пример строки для файла конфигурации inetd (/etc/inetd.conf) во FreeBSD (аналогично и в любой другой ОС семейства UNIX):

binkp stream tcp nowait fido /usr/local/sbin/binkd binkd -i -q /usr/local/etc/fido/binkd.conf

5.06. -m (строчная буква «m»).

Опция «-m» запрещает binkd использовать шифрование пароля по алгоритму MD5 (аутентификацию CRAM-MD5, см. FSP-1019), таким образом, binkd всегда будет передавать и принимать пароль только в открытом виде. Также не будет использоваться шифрование согласно расширению CRYPT протокола binkp, поэтому опция «-m» фактически подразумевает опцию «-r». Эта опция может использоваться только для тестирования или в защищённой от проникновений извне локальной сети. Вместо неё рекомеднуется использовать опцию «-nomd» в директиве node.

Пример:

binkd -m binkd.cfg

5.07. -n (строчная буква «n»).

Опция «-n» появилась в binkd 0.9.9. Она указывает binkd не осуществлять и не принимать вызовы, таким образом, после чтения файла конфигурации и выполнения действий, заданных другими опциями командной строки, binkd завершит работу . Опция «-n» обычно используется совместно с опцией «-P» или «-vvv».

Примеры:

binkd -n -P2:5076/207 -P 3:712/848 binkd.cfg
binkd -nvvv binkd.cfg

5.08. -P (прописная буква «P»).

Опция «-P» задаёт адрес линка, на который binkd создаст poll (создаст пустой или обновит файл вида *.ilo, соответствующий линку, в каталоге почтовой очереди). Адрес линка указывается параметром опции вплотную или через пробел. В командной строке могут быть указаны несколько опций «-P». Опция «-P» обычно используется совместно с опцией «-p».

Примеры:

binkd -P2:5076/207 -P 3:712/848 binkd.cfg
binkd -P2:5080/102 -p binkd.cfg

5.09. -p (строчная буква «p»).

Если в командной строке указана опция «-p», binkd запустится в режиме клиента (будет осуществлять только исходящие соединения) и по опустошению очереди на отправку, завершится с кодом возврата 0. Эта опция полезна для того, чтобы быстро отправить и/или забрать почту, например, при установлении модемного соединения по диалапу. Опция «-p» подразумевает действие опции «-c» и несовместима с опций «-s».

Пример:

binkd -p binkd.cfg

5.10. -q (строчная буква «q»).

Опция «-q» запрещает binkd выводить что бы то ни было на консоль (на экран). Используется обычно в строке вызова binkd из демона inetd.

Пример:

binkd -q binkd.cfg

5.11. -r (строчная буква «r»).

Опция «-r» запрещает binkd использовать шифрование трафика согласно расширению CRYPT протокола binkp.

Пример:

binkd -r binkd.cfg

5.12. -S (прописная буква «S»).

Опция «-S» служит в binkd/w32 и binkd/w9x для указания имени сервиса вместо заданного по умолчанию «binkd-service». Имя может содержать буквы, цифры, пробелы, знаки «-» (Если в имени сервиса присутствуют пробелы, оно должно быть заключено в кавычки во избежания ошибки распознавания параметров командной строки). Опция «-S» используется совместно с опциями «-i» или «-u». Эта опция имеет смысл только для binkd/w32 и binkd/w9x и в других вариантах binkd не воспринимается.

Примеры:

binkd -i -S «Binkd service» binkd.cfg
binkd -u -S «Binkd service»

5.13. -s (строчная буква «s»).

Опция «-s» запрещает binkd осуществлять исходящие соединения, т.е. в binkd работает только серверная часть.

Пример:

binkd -s binkd.cfg

5.14. -T (прописная буква «T»).

Опция «-T» задаёт режим работы binkd/w32, в котором в свёрнутом состоянии binkd помещает свою иконку в «System Tray» Windows (в правой части «Панели задач») и при клике левой кнопкой мыши по иконке восстанавливает вид окна. При работе binkd сервисом использование этой опции является одним из способов спрятать окно консоли binkd с экрана (другой способ – в параметрах сервиса убрать пометку взаимодействия с рабочим столом, но тогда вызвать окно консоли сервиса binkd будет невозможно).

Примеры:

binkd -T binkd.cfg
binkd -T -i binkd.cfg

Во втором примере binkd устанавливает себя сервисом, который будет сворачиваться в system tray.

5.15. -t (строчная буква «t»).

Опция «-t» служит для управления сервисом в binkd, скомпилированного для ОC Windows 95 (98, Me). Команда управления сервисом задаётся параметром опции. Binkd/w9x выполняет команду и завершается. Опция «-t» часто используется совместно с опцией «-S».

Допустимые команды:

Примеры:

binkd9x -t start
binkd9x -tstop
binkd9x -t status -S binkd
binkd9x -trestart -Sbinkd

5.16. -u (строчная буква «u»).

В 32-хбитных ОС семейства Windows опция «-u» используется для удаления ранее установленного сервиса binkd. Перед удалением сервиса в Windows он будет остановлен. Опция «-u» не может использоваться одновременно с опцией «-i»

Примеры команд остановки и удаления сервиса для Windows 2000 (NT, XP, 2003):

binkd -u
binkd -u -S binkd

Примеры команд удаления сервиса для Windows 95 (98, Me):

c:\bbs\binkd\binkd9x -u
binkd9x -u -S binkd

5.17. -v (строчная буква «v»).

Binkd, вызванный с опцией «-v», выведет на экран информацию о версии, затем завершит работу.

Если опция «-v» указана трижды либо указана в виде «-vvv», либо «-vv -v» и после неё указан файл конфигурации, binkd выведет прочитанную и обработанную им конфигурацию на экран и продолжит работу. (Тройная «v» в списке опций эквивалентна указанию директивы «debugcfg» в файле конфигурации.) Такое поведение binkd считается устаревшим и в версиях 1.x будет изменено.

При использовании одиночной опции «-h» файл конфигурации в командной строке указывать не обязательно.

Примеры:

binkd -v
binkd -vvv binkd.cfg
binkd -v -v -v binkd.cfg
binkd -vv -v binkd.cfg

6. Описание работы binkd.

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

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

В случае успешного чтения файла конфигурации binkd инициализирует серверный и клиентский процессы (потоки в многопоточных ОС). Разумеется, соответствующий процесс (поток) инициализируется только тогда, когда он не запрещён опциями «-c», «-s» и директивами файла конфигурации «maxservers», «maxclients»: указание в командной строке одной опции «-c» без опции «-s» либо указание в файле конфигурации «maxservers 0» запрещает запуск серверного процесса; указание в командной строке одной опции «-s» без опции «-c» либо указание в файле конфигурации «maxclients 0» запрещает запуск клиентского процесса. Учтите, что опция «-p» подразумевает также и действие опции «-c». В случае использования опции «-p» binkd инициирует клиентский процесс, который при обнаружении пустой очереди завершает работу binkd. Эта возможность используется для осуществления разового вызова линка(ов), часто совместно с опцией «-P<address>».

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

При инициации сеанса связи (как входящего, так и исходящего) binkd создаёт специальный процесс (поток) для его обработки. Таким образом многозадачные возможности ОС используются для упрощения кода. Этот подход накладывает ограничение в один сеанс связи для binkd в однозадачных ОС (например, в DOS).

6.1. Протоколирование.

В процессе работы binkd может сообщать информацию о проводимых действиях и их результатах путём вывода информационных сообщений на экран (консоль) и в файл протокола (log-файл). Вывод информации на экран регулируется опцией «-q» и параметрами файла конфигурации «conlog» и «printq». Протоколирование в файл определяется параметрами файла конфигурации «log» и «loglevel», также в ОС семейства Unix может использвоаться вывод сообщений в системную службу syslog, что задаётся параметром.файла конфигурации «syslog».

Для обычной работы уровень протоколирования устанавливается в значение от 0 до 4 (значение 4 предлагается в примере файла конфигурации, поставляемом в дистрибутиве binkd). Уровни 5 и 6 используются для выяснения неполадок с файлами в очереди (уровень 5) и для выявления ошибок в соединении с удалённым узлом (уровень 6). Уровни более 6 используются для отладки и рекомендуются разработчиками для использования в отчётах об обнаруженных ошибках в программе.

6.2. Исходящие соединения (binkd-client).

Как указано выше, для каждого исходящего сеанса связи создаётся свой процесс (поток). Этот процесс определяет адрес IP линка из DNS или файла конфигурации, осуществляет попытку соединения с линком, в случае неудачи повторяет попытку заданное в директиве try число раз, а в случае удачи проводит сеанс связи, затем записывает результат работы в файл *.try в каталоге почтовой очереди и завершается с кодом возврата, сообщающим об успешной работе (код 0) или об ошибке.

Работой клиентской части binkd управляет так называемый «менеджер клиентов» (client manager). Это подпрограмма, которая производит периодический просмотр каталогов почтовой очереди и всех файл-боксов, и запускает процесс (поток) для установления соединения и отправки почты при наличии «активной» почты (т.е. почты, требующей отправки в настоящий момент времени).

Соединение инициируется (т.е. запускается соответствующий клиентский процесс или поток) при наличии почты с атрибутами «normal», «direct», «crash», «immediate» и не инициируется при наличии почты с атрибутом «hold», исходящими FREQ (файлами *.req) и файлами в файлбоксах.

6.2.1. Алгоритм работы менеджера клиентов.

Рассмотрим подробно работу менеджера клиентов.

Сразу же после запуска менеджера клиентов он просматривает (сканирует) почтовую очередь: каталоги почтовой очереди (outbound), и файл-боксы – как объявленные в файле конфигурации файл-боксы стилей мейлеров «T-mail» и «The Brake!», так и описанные в директивах «node» персональные файл-боксы линков. В случае наличия «активной» почты (см. п. 6.1) для линка, отсутсвии с ним активного соединения и при известном адресе IP либо доменном имени этого линка менеджер клиентов запускает процедуру инициирования соединения, для сего создаёт процесс (поток), который работает с этим линком. Так происходит до того момента, пока число запущенных клиентских процессов (потоков) не достигло значения директивы «maxclients» файла конфигурации либо почтовая очередь не исчерпается. В случае достижения предела «maxclients» менеджер клиентов делает паузу длительностью «call-delay» и затем повторяет проверку числа запущенных клиентских процессов. По исчерпании почтовой очереди менеджер клиентов делает паузу длительностью «rescan-delay». После сканирования почтовой очереди, если она пуста, нет активных сеансов связи и binkd запущен с опцией «-P», менеджер клиентов завершает работу binkd. Формально алгоритм описан в таблице 6.2.1.

Таблица 6.2.1

?

Действие

Следующий

1

Инициализация.

2

2

Сканирование почтовой очереди и составление списка линков, для которых имеется почта.

3

3

Очередь пуста?

Да: 9.
Нет: 4.

4

Выбор очередного линка из очереди.

5

5

Почта на линка «активна»? (почта с атрибутами «normal», «direct», «crash», «immediate»; нет файла *.hld для линка или время, указанное в файле *.hld, уже прошло, список интернет-адресов линка непустой)

Да: 6.
Нет: 4.

6

Число запущенных клиентских процессов (потоков) меньше «maxclients»?

Да: 8.
Нет: 7.

7

Пауза на время «call-delay»

6

8

Запуск клиентского процесса (потока) для линка.

4

9

Binkd запущен с опцией «-p» и число запущенных клиентских процессов = 0?

Да: 11.
Нет: 10.

10

Пауза на время «rescan-delay»

2

11

Завершение.




6.2.2. Описание работы клиентского процесса.

Рассмотрим подробно работу клиентского процесса: процесса (или потока в многопоточных вариантах binkd), который осуществляет соединение с удалённым узлом и проводит сеанс связи.

Клиентский процесс стартует из менеджера клиентов после формирования непустой очереди файлов, предназначенных некоторому линку. При вызове клиентский процесс получает параметры линка и список файлов на отправку, выбранный из почтовой очереди.

Клиентский процесс после старта выбирает первое доменное имя или адрес IP линка из указанных в директиве файла конфигурации node либо, в случае её отсутсвия, defnode. (Если указанн символ «*», ещё до вызова клиентского процесса проводится преобразование к виду pNN.fNNN.nNNNN.zN.fidonet.net согласно FSP-1026 (вместо fidonet.net может быть указан другой корневой домен). В том случае, если выбранный адрес internet представляет собой доменное имя, производится запрос к ОС о разрешении имени в адрес IP. В случае отсутствия адреса IP у указанного доменного имени работа производится выборка следующего интернет-адреса линка. Когда все интернет-адреса линка заканчиваются, клиентский процесс завершается.

После определения адреса IP линка производится попытка установления соединения TCP. В случае указания специфичного для линка порта TCP производится соединение с указанным портом, по умолчанию же используется порт 24554. Перед попыткой установить соединение TCP выставляется таймер, указанный в директиве файла конфигурации «connect-timeout» (если эта директива присутствует в конфигурации binkd) и случае отсутствия ответа TCP от хоста линка по истечении указанного времени процедура установки соединения прерывается.

В случае установления соединения TCP проверяется предъявленный удалённым узлом адрес и поддерживаемые им версии и расширения протокола binkp, также отсылается собственная такая информация. В случае совпадения одного из предъявленных удалённой стороной адреса FTN с вызываемым адресом проводится процедура аутентификации на удалённом узле (отправляется пароль или дайджест пароля – в зависимости от запрошенного удалённой стороной способа аутентификации). В случае успешной аутентификации проводится обмен файлами.

В случае работы по протоколу binkp 1.1 по завершении процедуры обмена файлами проводится повторное сканирование почтовой очереди и формирование файлов для отправки. Если новых файлов нет ни с нашей, ни с удалённой стороны – сеанс завершается.

6.2.3. Однократно забрать и отослать почту.

Осуществить одиночный вызов основного линка – типичная задача оконечного пользователя (point, пойнт) сети FIDOnet (или другой сети, построенной по технологии FTN). В binkd для этого предуспотрен специальный режим работы, задаваемый опциями командной строки «-p» и «-P». Опция «-P» для создания в почтовой очереди пустого файла, инициирущего соединение, а опция «-p» используется для запуска клиентской части binkd и завершения работы после осуществления сеанса связи (либо исчерпания числа попыток соединиться). Эти опции можно использовать и по отдельности, но надо учитывать, что указание опции «-P» без опции «-p» разрешает работу серверной части binkd и по завершении всех соединений binkd не будет самостоятельно завершаться. Поэтому использование опции «-P» без опции «-p» малоприменимо. Если же опция «-p» используется без опции «-P», binkd завершится сразу в том случае, когда очередь на отправку пуста и осуществит вызов если в очереди имеются файлы. Это может использоваться, например, для отправки исходящей почты в том случае, когда держать binkd постоянно работающим нецелесообразно (например, в случае комутируемого сеансового подключения к Internet).

Пример вызова узла 3:712/848@fidonet:

binkd -P 3:712/848@fidonet -p binkd.cfg

Однократный вызов можно использовать для осуществления вызовов любого количества линков, для чего на каждого из них должны быть файлы в очереди на отправку (или для каждого нужно указать опцию «-P» его адресом). Более того, в случае непустой очереди binkd будет пытаться установить соединение со всеми известными ему линками, для которых имеется почта.

На работу binkd в режиме однократного вызова непосредственно влияют директивы файла конфигурации: rescan-delay, try, maxclients, также может повлиять директива call-delay (в случае, когда число линков в очереди больше числа maxclients) и в некоторых ситуациях могут влиять директивы defnode и connect-timeout.

Директива rescan-delay своим побочным действием задает паузу перед тем, как binkd завершит работу. В случае недоступности какого-либо линка директива connect-timeout имеет значение, если она меньше таймаута TCP сетевого драйвера операционной системы. Директива try в случае недоступности линка и при отсутствии ответа на запрос установления соединения TCP также может внести задержку на время try*<таймаут установления сеанса TCP> (таймаут во многих ОС равен минуте) либо на время try*connect-timeout (в зависимости от того, какой таймаут меньше).

В случае указания в директиве defnode звёздочки в поле адреса IP binkd будет также пытаться отправить почту на необъявленные явно в файле конфигурации адреса (если какая-либо почта имеется в почтовой очереди).

6.2.3. Постоянно работающий binkd-client.

В случае, когда у пойнта сети FIDOnet (или другой FTN-совместимой сети) имеется постоянно включенный компьютера с выходом в internet, сисоп может использовать binkd работающим постоянно. При этом binkd будет осуществлять вызов после того, как в его почтовой очереди окажется что-то требующее отправки. Проверка почтовой очереди проводится с периодом, указанным в директиве «rescan-delay» (в секундах). (Не забывайте, речь идёт о пойнте, которому необязательно принимать входящие соединения, а иногда он и не имеет такой возможности, например, в случае, когда компьютер не имеет публичного IP адреса и используется NAT - Network Address Translation).

Для работы в режиме клиента используется опция командной строки «-c» без указания опции «-s». В ОС семейства UNIX в случае работы binkd в фоновом режиме (т.н. режиме демона) используется также опция «-D», при этом binkd после инициализации отсоединяется от консоли и работает без вывода информации на экран. В 32-х битных версиях ОС Windows при использовании опции «-T» окно binkd может быть спрятано, при этом в системный трэй помещается оригинальная иконка. Также в ОС Windows 95 (98, Me) можно использвоать специальную версию binkd/w9x, которая всегда работает в фоновом режиме и предназначена для использования в качестве «сервиса» Windows 9x, а в ОС Windows NT (2000, XP, 2003) можно установить binkd в качестве системного сервиса с помощью опций «-i» и «-S» (подробнее см. описания этих опций).

Пример простого запуска binkd в качестве клиента:

binkd -с binkd.cfg

Пример запуска binkd в качестве клиента в режиме демона (в ОС семейства UNIX):

/usr/local/sbin/binkd -сD /usr/local/etc/binkd/binkd.conf

Пример запуска binkd в качестве клиента свёрнутым в системный трэй в Windows:

start /min binkd.exe -сT binkd.cfg

Примеры установки и запуска binkd-клиента сервисом Windows NT (с именем сервиса по умолчанию и с указанием имени):

binkd.exe -сi binkd.cfg

binkd.exe -сi -S "binkd client" binkd.cfg

Примеры установки и запуска binkd-клиента сервисом Windows 9x, (с именем сервиса по умолчанию и с указанием имени):

binkd9x.exe -сi binkd.cfg

binkd9x.exe -сi -S "client only binkd" binkd.cfg

6.3. Входящее соединение (binkd-server).

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

6.3.1. Алгоритм работы менеджера сервера.

Менеджер сервера открывает сокет типа TCP и ждёт соединения от удалённого узла. При установлении входящего соединения TCP менеджер сервера создаёт новый процесс (поток в многопоточных ОС), который обрабатывает это соединение. Менеджер сервера отслеживает количество одновременно работающих серверным процессов (потоков).

Другая задача менеджера сервера – отслеживать изменение файла конфигурации. Реакция на изменение файла конфига зависит от операционной системы и от компилятора. В ОС семейсва UNIX инициируется перезапуск binkd, в ОС Windows и в однозадачных ОС binkd завершается с кодом возврата 3. (В следующих версиях это будет изменено, будьте внимательны.)

6.3.2. Алгоритм работы серверного процесса.

После запуска серверный процесс проверяет число работающих «коллег» и случае превышения лимита, заданного в директиве «maxservers» файла конфигурации, новое входящее соединение завершается, при этом удалённый узел получает сообщение протокола binkp «M_BSY Too many servers».

Следом проводится анализ информации, полученной от удалённой стороны: адреса FTN, подерживаемые версии и расширения протокола binkp. Далее такая информация о себе отсылается для удалённой стороны.

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

Далее формируется список файлов на отправку и производится обмен файлами.

В случае работы по протоколу binkp 1.1 по завершении процедуры обмена файлами проводится повторное сканирование почтовой очереди и формирование файлов для отправки. Если новых файлов нет ни с нашей, ни с удалённой стороны – сеанс завершается.

6.3.3. Интерактивная работа binkd-сервер.

Для работы в режиме сервера используется опция командной строки «-s» без указания опции «-c». При этом binkd выводит информационные сообщения на свою консоль, в зависимотси от директив файла конфигурации «conlog», «printq» и «loglevel». Вывод информации на консоль запрещает опция командной строки «-q». В любом случае на консоль выводятся сообщения об ошибках в командной строке, о невозможности загрузить файл конфигурации и об ошибках в нём. В 32-х битных версиях ОС Windows при использовании опции «-T» окно binkd может быть спрятано, при этом в системный трэй помещается оригинальная иконка.

Примеры запуска binkd в режиме «только сервер»:

binkd -s binkd.cfg

binkd.exe -sT binkd.cfg

6.3.4. Работа binkd-сервер системной службой.

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

Пример запуска binkd-сервер в режиме демона: в UNIX:

/usr/local/sbin/binkd -Dqs /usr/local/etc/fido/binkd.conf

Пример установки и запуска binkd сервисом Windows:

binkd.exe -i binkd.cfg

Пример остановки и удаления сервиса binkd в Windows:

binkd.exe -u

Подробности о таком использовании binkd см. в разделе 6.4.1.

6.3.5. Работа binkd-сервер под управлением inetd.

В некоторых операционных системах возможна автоматическая работа binkd в режиме сервера под управлением inetd. При этом служба inetd «слушает» назначенный для binkd порт и запускает binkd после установления соединения TCP. В таком режиме binkd обменивается данными с удалённым узлом через свои стандартный входной и выходной потоки (stdin и stdout в терминах языка программирования С). Связь между этими потоками и сокетом TCP устанавливает inetd. Работа такой связки в некоторых ситуациях экономит используемую оперативную память и процессорное время, поскольку binkd запускается только на время входящего сеанса связи.

Для работы совместно с inetd у binkd, скомпилированного для OS/2, Amiga или ОС семейства UNIX, предусмотрена опция командной строки «-i». При этом, чтобы не смешивать передаваемые данные и информационные сообщения binkd, требуется указывать также опцию «-q» либо запрещать вывод информации на консоль в файле конфигурации binkd (закомментировать директивы «conlog» и «printq»).

Начинающие часто делают ошибку, забывая, что в файле конфигурации inetd необходимо первым параметром указывать имя программы.

Пример строки запуска binkd в файле конфигурации inetd (inetd.conf) для ОС семейства unix:

binkp stream tcp nowait root /usr/local/sbin/binkd binkd -isq /usr/local/etc/fido/binkd.conf

При этом в списке возможных портов (файл /etc/services) должна быть запись о протоколе binkp:

binkp 24554/TCP

6.4. Универсальный режим работы binkd: сервер+клиент.

Типичным применением binkd на узле FIDOnet является его комбинирванное использование в качестве как клиента, так и сервера. Такой режим работы в binkd сделан по умолчанию (т.е. при отсутсвии каких-либо опций командной строки).

В комбинированном режиме менеджер сервера кроме обслуживания серверной части binkd, выполняет также функции общего управления: отслеживает изменения файла конфигурации, обрабатывает сигналы ОС. В остальном работа менеджера сервера и менеджера клиентов binkd особенностей не имеет.

Примеры запуска binkd в универсальном режиме (первый пример – обычный запуск, второй пример – запуск в Windows с возможостью скрытия окна binkd в системный трэй):

binkd binkd.cfg

binkd.exe -T binkd.cfg

6.4.1. Работа binkd без участия пользователя.

В случае необходимости постоянной работы binkd в качестве сервера, имеет смысл запускать его как системную службу. В ОС, основанных на UNIX, системные службы называются «демонами» («daemons»), в ОС Windows - «сервисами» или «службами» («services»). В других операционных системах работа binkd в качестве системной службы предусмотрена только под управлением inetd (см. п.6.3.5), в ОС семейства UNIX работа binkd под управлением inetd также возможна.

6.4.1.1. Сервис в Windows.

В случае необходимости постоянной работы binkd в качестве сервера, имеет смысл запускать его как системную службу. В Windows это реализуется путём установки binkd системным сервисом с использованием опций командной строки «-i» и «-S».

В Windows NT, Windows 2000 м более поздних версиях линейки NT сервис binkd по умолчанию выводит своё консольное окно на экран после того, как пользователь залогинится в систему. Убрать его с экрана можно двумя способами. Первый способ: указать при установке binkd сервисом опцию командной строки «-T», и при появлении окна bikd свернуть его в системный трэй кнопкой минимизации окна. Второй способ – изменить настройки системного сервиса, сняв пометку «разрешить взаимодействие с рабочим столом», в этом случае имеет смысл запретить binkd выводить информацию на консоль (указать опцию командной строки «-q» при установке сервиса либо закомментировать директивы «conlog» и «printq» в файле конфигурации).

В Windows 95, Windows 98 и Windows Me из-за особенностей реализации текстовой консоли в этих версиях ОС приходится использовать специальный вариант исполняемого файла: binkd9x.exe, который работает без постоянной консоли (создаёт консоль только в необходимых случаях на небольшое время). Идентифицировать этот вариант binkd можно по наличию подстроки Win9x в информационном сообщении, выводимым binkd при указании опции командной строки «-v», например:

Binkd 1.0a-499 (Dec 20 2006 01:12:53/Win9x)
Press any key...

Использование binkd/win9x без установки его сервисом в Windows 95 (98, Me) возможно, но в этом случае он работает исключительно в фоновом режиме подобно демону в UNIX.

В целях улучшения безопасности использования binkd в режиме сервиса в Windows NT (2000, XP, 2003) имеет смысл назначить ему для работы отдельного пользователя, которому разрешить доступ только к нужным файлам и каталогам.

Пример установки и запуска binkd сервисом Windows с именем по умолчанию («binkd-service»):

binkd.exe -i binkd.cfg

Пример установки и запуска binkd сервисом Windows с именем «Universal binkd» с возможностью скрытия окна в системный трэй:

binkd.exe -iTS "Universal binkd" binkd.cfg

Пример остановки и удаления сервиса Windows с именем «Universal binkd»:

binkd.exe -uS "Universal binkd"

Пример остановки и удаления сервиса Windows с именем «binkd-service» (имя сервиса binkd по умолчанию):

binkd.exe -u

6.4.1.2. Демон в unix.

В ОС, основанных на UNIX, системные службы называются «демонами» («daemons») и для запуска binkd в качестве демона используется опция командной строки «-D». При использовании этой опции binkd отсоединяется от консоли и работает в фоновом режиме. Поскольку связь с консолью у демона отсутствует, вся информация, которая в интерактивном режиме выводится на экран, уходит в «никуда» и имеет смысл совместно с опцией «-D» указывать опцию «-q» либо запрещать вывод на экран в файле конфигурации, для чего закомментировать директивы «conlog» и «printq».

Пример запуска binkd-сервер в режиме демона:

/usr/local/sbin/binkd -Dqs /usr/local/etc/fido/binkd.conf

Обычно работа демоном нужна в непрерывном режиме - чтобы демон binkd запускался в процессе загрузки ОС. Для этого нужно вставить строку запуска binkd в один из стартовых скриптов ОС, например во FreeBSD/OpenBSD/NetBSD в файл /etc/rc.local. Можно также создать скрипт запуска/остановки binkd и поместить его в каталог стартовых скриптов: /etc/init.d (Linux) или /usr/local/etc/rc.d (FreeBSD). Скрипт приблизительно такой:

#!/bin/sh

case $1 in

start)
su fido -c «/usr/local/sbin/binkd -Dq /usr/local/etc/fido/binkd.conf»
;;

stop)
kill `cat /var/run/binkd.pid`
;;

esac



В целях улучшения безопасности использования binkd имеет смысл назначить ему для работы отдельного пользователя, которому разрешить доступ только к нужным файлам и каталогам. Возможно также запускать binkd с использованием chroot.

6.4. Работа в защищенной (корпоративной) сети.

Нередко binkd установлен на хосте, расположенном в защищённом межсетевым экраном сегменте сети (например, на сервере либо компьютере пользователя в организации). Даже если он работает на компьютере, напрямую подключенном к Internet, сам компьютер в современном мире должен быть защищён от произвольного доступа из Internet (от вирусов, от несанкционированного доступа). Некоторые провайдеры Internet также защищают компьютеры своих клиентов. Во всех описанных и в некоторых других случаях необходимы специальные настройки межсетевого экрана или персонального (локального) сетевого фильтра IP.

6.4.1. Использование proxy.

Зачастую в организациях пользователи имеют доступ к ресурсам Internet только посредством сервера proxy. Такой сервер принимает соединение от программы-клиента и создаёт запрос к внешнему ресурсу. После установления соединения с внешним ресурсом сервер прокси осуществляет пересылку данных между программой-клиентом и удаленным сервером, возможно с анализом и фильтрацией содержимого.

Binkd поддерживает серверы прокси трёх стандартных видов:

  1. HTTP/HTTPS, как с аутентификацией пользователя, так и без неё;

  2. SOCKS v.4;

  3. SOCKS v.5, как с аутентификацией пользователя, так и без неё.

В случае работы через сервер прокси HTTP/HTTPS binkd осуществляет запрос к серверу прокси методом CONNECT с указанием адреса и порта удалённой стороны (по умолчанию используется порт 24554). Но в типовых настройках серверов прокси разрешены не все запросы метода CONNECT , а только к избранному списку портов TCP, обычно только один порт с номером 443 (этот порт используется браузерами по умолчанию в протоколе HTTPS при работе с URL вида https://host.domain.tld). Соотвественно, чтобы binkd мог работать через такой сервер прокси, необходимо либо работать с линком, у которого совместимый с binkd мейлер отвечает на порту TCP 443, либо нужно изменить конфигурацию сервера прокси таким образом, чтобы он позволял соединения по методу CONNECT на стандартный порт binkp – TCP 24554.

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

При работе через прокси SOCKS v.5 может требоваться аутентификация пользователя. При работе же через прокси SOCKS v.4 аутентификация не требуется.

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

Примеры конфигурации binkd для работы с использованием сервера прокси см. в п.п. 4.48. и 4.53.

6.4.2. Использование NAT и настройка firewall.

Помимо работы через сервер прокси, в сетях организаций (а иногда и в сети провайдера Internet) используются так называемые частные подмножества адресов IP, также называемые адресами Intranet. Это адрсе из подсетей 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16 (см. RFC 1918 «Address Allocation for Private Internets»). При использовании такой адресации для доступа в Internet используется трансляция адресов IP из внутренней сети в Internet и обратно, называемая NAT (network address translation) или PAT (port address translation). Трансляция проводится на устройстве или сервере, работающим в качестве шлюза в Internet, причём обычно такой шлюз является файрволом (межсетевым экраном).

В случае работы binkd в сети, защищённой шлюзом или файрволом с NAT, для работы binkd с внешними по отношению к локальной сети узлами необходима специальная конфигурация файрвола. При этом настройки самого binkd не имеют особенностей, они точно такие же как и при его работе на компьютере с публичным адресом IP.

Во-первых, для осуществелния клиентских соединений от binkd к внешним узлам на файрволе должны быть разрешены соединения от адреса IP компьютера, на котором работает binkd, по протоколу TCP на порт 24554 (и, возможно, на другие порты – в том случае, если производятся соединения на нестандартный порт на каких-то узлах).

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

  1. Назначить соответсвие одного из доступных публичных (выделенных провайдером) адресов IP адресу IP компьютера, на котором работает binkd; Другими словами – обеспечить трансляцию выделенного публичного и приватного адресов IP (NAT). При этом и исходящие от binkd соединения будут выглядеть как соединения с этого же адреса. В этом случае необходимо разрешить соединения из Internet на этот адрес только по порту 24554 протокола TCP (или другой порт, на котором отвечает binkd), а все прочие – запретить. Это необходимо для обеспечения защищённости компьютера от взлома (а в итоге и локальной сети в целом).

  2. Перенаправлять входящие соединения по протоколу TCP и порту 24554 на адрес комьютера с работающим binkd на тот порт, на котором он принимает соединения. Другими словами – обеспечить трансляцию адреса и порта (PAT). В этом случае для обеспечения входящих соединений не нужен специальный адрес IP. Но в том случае, когда приватная адресация используется провайдером, вряд ли он будет транслировать отдельный порт, и в случае его отказа придётся заказывать у него выделенный адрес IP.

6.6. Запуск внешних программ из binkd.

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

Один из вариантов действий – создание (пустого) файла при удовлетворении условия (т.е. когда был принят файл, подходящий по указанной в условии маске). Условие создание такого файла и его имя задаётся в директиве файла конфигурации «flag». (См. п.4.19) Появление соответствующего файла может обыть отслежено другими программами, которые произведут необходимые действия (запустят обработку).

Другой вариант действий при выполнении условия – запуск программ прямо из binkd. Это действие задаётся в директиве файла конфигурации «exec». (См. п.4.15)

Запуск программ осуществляется с использованием системного вызова system(), при этом вызывается интерпретатор команд, используемый операционной системой. В ОС семейства UNIX вызывается интерпретатор, указанный в описании пользователя, от имени которого работает binkd. В остальных ОС – тот интерпретатор команд, на который настроена операционная система (обычно это COMMAND.COM в Windows 95,98,Me; CMD.EXE в Windows NT,2000,XP,2003; CMD.EXE в OS/2). Программы выполняются из процесса (потока), который принял файлы, подходящие по маске к описанным в директиве файла конфигурации «exec».

Запуск команд возможен как непосредственно после приёма файлов, так и по завершении сеанса. Оперативный запуск может иметь смысл для обработки файловых запросов и отправки запрошенного в том же сеансе (для чего файлы нужно поместить в файлбокс, соответствующий адресу удалённой стороны либо использовать протокол взаимодействия мэйлера и фрекпроцессора SRIF, см. ). Задержанный запуск имеет смысл для предотвращения длительных пауз в передаче данных и для предотвращения повторного запуска одной и той же программы в случае приёма пачки однотипных файлов.

В 32-битных версиях Windows возможен запуск команд в отдельном процессе. Это позволяет избежать задержек, вызванных ожиданием завершения работы внешней программы.

При формировании маски файлов нужно внимательно отслеживать, в каких случаях будет срабатывать это условие. Для того, чтобы выполнить обработку принятой почты не во всех случаях, а только после сеанса связи, защищённого паролем, нужно указать маску полного пути к файлам в каталоге, заданном в директиве «inbound». Наоборот, чтобы выполнить обработку принятой почты только после сеанса связи без использования пароля, нужно указать в маске полный путь к файлам в каталоге, заданном в директиве «inbound-nonsecure». Также нужно учитывать особенности ОС и файловой системы, например, в ОС семейства UNIX штатные файловые сситемы являются регистрозависимыми, и маски должны учитывать все варианты написания имени файла и пути. При использовании же сетевых дисков в случае разных ОС сервера и клиента возможны неочевидные ситуации.

В маске файла можно указывать знаки макроподстановки «?», обозначающий один любой символ, и «*», обозначающий произвольное количество любых символов (в том числе и отсутвие символа). Кроме того, можно использовать последовательность символов, заключённых в квадратные скобки, такая конструкция является списком альтернативных символов. Чтобы указать символы «?», «*», «]», «[», «\», «#», их необходимо предварять знаком обратной косой черты «\». (Этот знак можно использовать и для других символов, в которых вы сомневаетесь.)

Примеры запуска команд для ОС семейства UNIX.

Обработка FREQ во время сеанса:

exec "!/fido/scripts/simplefreq *S" *.[Rr][Ee][Qq]

Обработка почты по завершению сеанса:

exec "/fido/scripts/ftrack.sh" *.[Pp][Kk][Tt]
exec "/fido/scripts/pkt2000toss.sh" *.[Pp]2[Kk]
exec "/fido/scripts/echotoss.sh" *.[Ss][Uu]? *.[Mm][Oo]? *.[Tt][Tu]? *.[Ww][We]?
exec "/fido/scripts/echotoss.sh" *.[Tt][Hh]? *.[Ff][Rr]? *.[Ss][Aa]?
exec "/fido/scripts/fechotoss.sh" /fido/inbound-secure/*.[TtZz][Ii][Cc]

Примеры запуска команд для ОС Windows, OS/2 и т.п..

Обработка FREQ во время сеанса:

exec "!d:\\path\\allfix.exe Rp -SRIF *S" *.req

Обработка почты по завершению сеанса:

exec "d:\\path\\my-pkt-unpacker.exe /options" c:\\\\bbs\\\\inbound\\\\*.pkt
exec "d:\\path\\my-tosser.exe /options" *.su? *.mo? *.tu? *.we? *.th? *.fr? *.sa?
exec "d:\\path\\my-filer.exe /options" *.tic *.zic
exec "d:\\path\\my-pkt-filter.exe /options *F" c:\\\\bbs\\\\inbound\\\\unsecure\\\\*.pkt

7. Форматы служебных файлов и каталогов.

7.1. Cправка по каталогам почтовой очереди и файлбоксам.

7.1.1. BSO.

Аббревиатура «BSO» расшифровывается как «Binkley style outbound», этот формат очереди получил своё название от мэйлера BinkleyTerm, в котором был применён впервые, и до сих пор классическим описанием формата является раздел outbound руководства по BinkleyTerm.

Аутбаунд BSO представляет собой иерархию подкаталогов, в которых содержатся файлы, адресованные линку. Файлы с непакованным (неархивированным) нетмейлом именуются с суффиксом «ut», остальные файлы перечисляются в файле-списке с суффиком «lo» (flow-file). Перед суффикcом ставится символ атрибута, и эти три символа отделяются от левой части имени файла точкой (и в терминах DOS образуют расширение файла). Адрес линка закодирован в имени каталога и имени файла: для кодирования адреса используется написание домена FTN (не более 8 знаков), шестнадцатиричное представление номера зоны, четырёхразрядные шестнадцатиричные представления номеров сети и узла, для пойнтов также восьмиразрядное шестнадцатиричное представление номера пойнта.

Почта для узлов выглядит в BSO следующим образом:

Каталог вида
/Домен[.Номер_зоны]/
в котором располагаются файлы вида
НомерсетиНомерузла.АтрибутТип
Уникальноеимя.ДеньнеделиНомер

Почта для пойнтов - таким:

Каталог вида:
/Домен[.Номер_зоны]/НомерсетиНомерузла/
в котором располагаются файлы вида:
Номерпойнта.АтрибутТип
Уникальноеимя.ДеньнеделиНомер

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

Формат записи в файле-списке:

[Модификатор][Путь]Имяфайла

Примеры имён файлов.

Нетмейловый пакет с атрибутом «normal» для узла 2:5080/68@fidonet с узла 2:5080/102@fidonet (зона у этих узлов одна, поэтому каталог без суффикса с номером зоны):

D:\Ftn\Outbound\Fidonet\13d80044.out

Нетмейловый пакет с атрибутом «direct» для узла 3:712/848@fidonet с узла 2:5080/102@fidonet:

D:\Ftn\Outbound\Fidonet.003\02c80350.dut

Файл-список с атрибутом «direct» для узла 3:712/848@fidonet с узла 2:5080/102@fidonet:

D:\Ftn\Outbound\Fidonet.003\02c80350.dlo

Нетмейловый пакет с атрибутом «hold» для пойнта 2:5080/102.100@fidonet с узла 2:5080/102@fidonet:

D:\Ftn\Outbound\Fidonet\13d80066\00000064.hut

Файл-список с атрибутом «hold» для пойнта 2:5080/102.100@fidonet с узла 2:5080/102@fidonet:

D:\Ftn\Outbound\Fidonet\13d80066\00000064.hlo

Пример содержимого файла-списка.

^D:\Ftn\Outbound\Fidonet\d08a1f00.mo0
#D:\Ftn\Outbound\Fileout\nodediff.z74
#D:\Ftn\Outbound\Fileout\17h2n539.tic

Некоторые программы используют дополнительно собственные типы файлов аутбаунда с суффиксами:

.csy — файл–флаг "звонок", обозначает, что в этот момент иницируется сеанс связи с линком (используется во многих мейлерах);
.stc — файл с информацией о статусе соединения (используется в binkd);
.hld — файл–индикатор приостановки попыток соединения с линком (используется в binkd).

7.1.2. ASO.

«ASO» — аббревиатура, составленная из первых букв названия «Amiga Style Outbound». Это формат почтовой очереди Фидонет, впервые реализованный на платформе «Commodor Amiga».

Аутбаунд ASO представляет собой единственный каталог, в котором содержатся файлы, адресованные линкам. Зоны FTN в ASO не поддерживаются, это чистый 4D-аутбаунд. Это ограничивает использование ASO только теми станциями, которые имеют адрес(а) только в одном домене FTN. Другим недостатком ASO является то, что все файлы для всех линков размещаются в одном каталоге на диске, и при большом числе линков неизбежны задержки при сканирования аутбаунда.

Преимуществом ASO можно считать наглядность имён файлов: сразу видно, какому линку предназначен файл.

Как и в BSO, файлы с непакованным (неархивированным) нетмейлом именуются с суффиксом «ut», остальные файлы перечисляются в файле-списке с суффиком «lo» (flow-file). Перед суффикcом ставится символ атрибута, и эти три символа отделяются от левой части имени файла точкой (и в терминах DOS образуют расширение файла). Формат строк в файлах списках тот же, что и в BSO.

Остальная часть (левая) файла формируется из 4D-адреса линка, поля которого разделяются точкой, то есть имена файлов формируются по шаблону:

zz.nn.ff.pp.ext
где:

zz — номер зоны
nn — номер сети
ff — номер узла (ноды)
pp — номер поинта
ext — тип файла («?ut» или «?lo»)

(все номера в десятичном формате).

Примеры имён файлов.

Нетмейловый пакет с атрибутом «normal» для узла 2:5080/68@fidonet с узла 2:5080/102@fidonet:

D:\Ftn\Outbound\ASO\2.5080.68.0.out

Файл-список с атрибутом «hold» для пойнта 2:5080/102.100@fidonet с узла 2:5080/102@fidonet:

D:\Ftn\Outbound\ASO\2.5080.102.100.hlo

Нетмейловый пакет с атрибутом «direct» для узла 3:712/848@fidonet с узла 2:5080/102@fidonet:

Невозможен в аутбаунде ASO.

Некоторые программы используют дополнительно собственные типы файлов аутбаунда (как и в BSO):

csy — файл–флаг "звонок", обозначает, что в этот момент иницируется сеанс связи с линком (используется во многих мейлерах);
stc — файл с информацией о статусе соединения (используется в binkd);
hld — файл–индикатор приостановки попыток соединения с линком (используется в binkd).

7.1.3. Long BSO.

7.1.4. Файлбоксы, совместимые с мейлером «T-Mail».

Binkd способен отправлять файлы, помещённые мейлером T-Mail в специальные каталоги, называемые файлбоксами. У T-mail есть два вида файлбоксов: традиционные «короткие», подчиняющиеся правилам именования файлов в DOS (8.3) и реализованные в T-mail/NT и T-mail/2 «длинные». Файлбоксы формата T-mail используют 4D-адресацию FTN (без домена).

«Короткие» файлбоксы формата T-mail представляют собой подкаталоги с именами стиля DOS в базовом каталоге. Имя каждого подкаталога-файлбокса сгенерировано из адреса FTN системы назначения с использованием 32-ричной системы счисления, в которой цифры от «0» до «9» совпадают с 10-ричными цифрами, а цифрам от 10 до 31 назначены буквы латинского (английского) алфавита от «A» до «V», все буквы - прописные (заглавные). Под номер зоны отведены два символа, под номер сети и номер узла - по три знака, под номер пойнта - два первых знака после точки (у узла ставится «00»). Третий знак после точки может использоваться для атрибута «hold», для чего используется буква «H». Таким образом, файлбокс «короткого» формата T-mail имеет ограничения: для адресов узлов от 1:1/0 до 1023:32767/32767 и для номеров пойнтов от 0 до 1023.

Формат короткого файлбокса T-mail:
НомерзоныНомерсетиНомерузла.Номерпойнта[Атрибут]

Примеры коротких файлбоксов T-mail:

Файлбокс с атрибутом «normal» для отправки файлов координатору зоны 2:

D:\Ftn\fileboxT\02002000.00

Файлбокс с атрибутом «hold» для пойнта 2:5080/102.63

D:\Ftn\fileboxT\024UO036.1VH

«Длинные» файлбоксы формата T-mail представляют собой подкаталоги с длинными именами в базовом каталоге. Имя каждого подкаталога-файлбокса состоит из цифр адреса FTN системы назначения с использованием десятичной системы счисления, разделённых точками. В конце для указания атрибута «hold» может стоять «.H» или «.h». Таким образом, файлбокс «длинного» стиля T-mail не имеет ограничений.

Формат длинного файлбокса T-mail:
Номерзоны.Номерсети.Номерузла.Номерпойнта[.Атрибут]

Примеры длинных файлбоксов T-mail:

Файлбокс с атрибутом «normal» для отправки файлов координатору зоны 2:

D:\Ftn\fileboxT\2.2.0.0

Файлбокс с атрибутом «hold» для пойнта 2:5080/102.63

D:\Ftn\fileboxT\2.5080.102.63.H

7.1.5. Файлбоксы, совместимые с мейлером «The Brake!».

Файлбоксы формата The Brake! представляют собой подкаталоги с длинными именами в базовом каталоге. Имя каждого подкаталога-файлбокса состоит из домена и цифр адреса FTN системы назначения с использованием десятичной системы счисления, разделённых точками. В конце, после точки, указан атрибут. Таким образом, файлбокс формата The Brake! не имеет ограничений.

Формат файлбокса The Brake!:
Домен.Номерзоны.Номерсети.Номерузла.Номерпойнта.Атрибут

Примеры файлбоксов формата The Brake!

Файлбокс с атрибутом «normal» для отправки файлов координатору зоны 2 сети fidonet:

D:\Ftn\fileboxTheBrake\fidonet.2.2.0.0.normal

Файлбокс с атрибутом «hold» для пойнта 2:5080/102.63@fidonet

D:\Ftn\fileboxTheBrake\fidonet.2.5080.102.63.Hold

7.2. Форматы файлов

7.2.1. Файл паролей.

Binkd способен читать пароли из текстового файла паролей, используемого мейлером: T-Mail.

В файле формата T-mail каждая строка содержит два слова: адрес FTN и пароль, разделённые пробелами и/или знаками табуляции. Cтрока может начинаться пробелами и/или знаками табуляции. Пустые строки и строки, первое слово в которых не является адресом FTN, игнорируются (так игнорируются строки комментариев T-mail). Также игнорируется остаток строки после пароля.

Пример.

;==Файл паролей стиля T-mail=====================
2:5080/102 pwd1
7:1500/102 pwd2

7.2.2. Двоичный файл статистики стиля T-mail.

7.2.3. Двоичный файл статистики стиля FrontDoor.

7.3. Файлы, создаваемые binkd в процессе работы.

7.3.1. Файл с PID.

В ОС семейства UNIX binkd создаёт файл с номером процесса (PID – Process ID). Это помогает предупредить повторный запуск binkd и отследить его работоспособность. Файл PID обычно располагается в каталоге /var/run и называется binkd.pid. В файле конфигурации можно задать другое его размещение и имя, что позволяет запускать несколько копий binkd с разными конфигурациями.

Файл PID представляет собой текстовый файл и содержит строку-число, равное номеру «родительского» процесса. В случае запуска с опцией «-c» это процесс менеджера клиентов, в остальных случаях – процесс менеджера сервера binkd.

7.3.2. Файлы, создаваемые в каталоге почтовой очереди.

Binkd создаёт и использует несколько файлов для отслеживания состояния соединений с линками. Имена таких файлов составляются из двух частей, разделённых точкой: левая часть имени соответствует правилам кодирования адреса в используемом аутбаунде, правая часть состоит из трёх букв и указывает на функцию файла.

  • Файл вида *.bsy.
    Стандартный файл-флаг занятости линка для BSO. Создаётся при успешном соединении с линком после получения от него списка адресов FTN.

  • Файл вида *.csy.
    Файл-флаг, являющийся расширением оригинальной спецификации BSO. Используется для индикации процесса установления соединения с линком. Клиентский процесс создаёт его перед открытием сокета и удаляет после создания флага *.bsy, а в случае обнаружения такого файла завершается. Этот файл-флаг предотвращает одновременную попытку соединиться двумя клиентскими процессами, также он создаётся и проверяется некоторыми другими FTN мейлерами (например, T-mail).

  • Файл вида *.hld.
    Используется для хранения времени, до которого отложен следующий вызов линка после исчерпания лимита неудачных попыток соединения. Время записано в виде строки цифр, представляющих собой число секунд от "начала эпохи UNIX" (1 января 1970 г.).
    Этот файл специфичен для binkd.

  • Файл вида *.try.
    Используется для хранения статуса последнего сеанса свяи с линком (удачного или неудачного). Состоит из трёх полей: количество успешных попыток (двоичное 16-тибитное число с порядком байт «младший первым»), количество безуспешных попыток (двоичное 16-тибитное число с порядком байт «младший первым») и строку с сообщением. В случае успешно завершившегося сеанса третье поле содержит строку «CONNECT/BND», в случае неудачного - строку сообщения об ошибке.
    При безуспешной попытке соединения binkd увеличивает счётчик неудачных попыток (второе поле в файле *.try) до тех пор, пока не будет превышено число, заданное в директиве файла конфигурации «try», после чего обнуляет счётчик и записывает время следующей попытки в файл *.hld.
    Этот файл специфичен для binkd.

  • Файл вида *.stc.
    Файл с информацией о состоянии почты для/от линка при работе в режиме ND («No Dupes mode»).
    Этот файл специфичен для binkd.

7.3.3. Временные файлы, использующиеся при приеме файлов.

Чтобы исключить обработку принятых не до конца файлов другими программами, binkd сначала записывает принятые данные в файлы со специальными именами, а по завершении приёма (при получении от линка подтверждения о завершении передачи) переименовывает временный файл в назначенное удалённой стороной имя.

Для каждого принимаемого файла binkd создаёт в каталоге для приёма файлов два временных файла: *.hr с описанием файла и *.dt с содержимым файла (левые части файлов генерируются с обеспечением уникальности и совпадают у обоих файлов). Хранение информации о принимаемом файле отдельно от него самого гарантирует независимость binkd от используемой файловой системы и ОС.

Файл *.hr содержит строку, состоящую из четырёх полей: имя файла, его размер, время последнего изменения и адрес линка, который шлёт файл. На основе этой информации binkd принимает решение о приёме файла с совпадающим именем от этого же линка как продолжение существующего файла либо как нового.

8. Другая документация.

8.1. Документация из дистрибутивного комплекта binkd.

В комплекте официального дистрибутива binkd обязательно присутствует инструкция по установке, файл со списком функциональных изменений, документ «Частые вопросы по мейлеру binkd и ответы на них» («Binkd FAQ»), страничка man binkd, описание binkd/w9x, краткое описание протокола binkp, описание протокола SRIF и некоторые другие документы, представляющие интерес скорее для разработчиков. В архивах с binkd, не являющихся официальными дистрибутивами, часть или вся документация может отсутствовать, поэтому будьте внимательны.

8.2. Документация в Internet.

На момент написания этого текста в Internet имеется несколько источников, содержащих документацию по мейлеру binkd и протоколу binkp:

  1. Сайт http://binkd.grumbler.org

  2. Архив FTP ftp://cvs.happy.kiev.ua/pub/fidosoft/mailer/binkd/ и несколько его зеркал:
    ftp://cheetah.itpark.com.ua/pub/fido/binkd/ (Украина, поддерживает зеркало Pavel Gulchouck 2:463/68)
    ftp://fido.thunderdome.ws/pub/mirror/binkd/ (США, поддерживает зеркало Matt Bedynek 1:106/1)
    ftp://ftp.alexblues.ru/pub/binkd/ (Россия, поддерживает зеркало Alexander Gladchenko 2:5080/111)
    ftp://cube.sut.ru/pub/mirror/binkd/ (Россия, поддерживает зеркало Dmitriy Yermakov 2:5030/1115)
    http://binkd.spb.ru (Россия, поддерживает зеркало Andrey Ostanovsky 2:5030/1957)

  3. Руководство пользователя binkd v.0.9.2 на английском языке, написанное Nick Soveiko: http://www.doe.carleton.ca/~nsoveiko/fido/binkd/

  4. Авторское описание binkd и протокола binkp Дмитрия Малова:
    http://www.corbina.net/~maloff/binkd

  5. Коллекция стандартов FTN на сайте FTSC:
    http://www.ftsc.org/download/

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

8.2. Источники информации в FIDOnet.

Псокольку binkd является почтовой программой, используемой в сети FIDOnet, естественно, что в этой сети достаточно просто найти информацию о нём и, более того, можно получить помощь в настройке. Для общения пользователей и разработчкиов binkd существует две эхоконференции FIDOnet: русскоязычная RU.BINKD и англоязычная BINKD (она является международной). Также имеющие отношение к binkd файлы распространяются по файлэхе AFTNBINKD.

$Id$