Метод 'затягивания форвардинга' (опция -u)
Этот алгоритм появился начиная с версии bcm 1.44, он полностью совместим с FBB и уже показал свою эффективность при активном форвардинге с несколькими партнёрами. Суть его заключается в следующем:

Например ббс1 ведёт форвардинг с ббс2, тут к ббс1 подключился ещё и ббс3. Так как обмен с ббс2 уже практически завершен, то форвардинг с ним разорвался. Форвардинг с ббс3 пока продолжается. В процессе форвардинга ббс3 передал ббс1 письмо или бюллетени для ббс2. В обычном режиме ббс1 снова начнёт вызывать ббс2 для передачи ему письма, а если ббс1 имеет 5-7 партнёров то наблюдается постоянный эффект "скакания".

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

ббс1 ведёт форвардинг с ббс2, тут к ббс1 подключился ещё и ббс3. Теперь ббс1 не разрывает форвардинг с ббс2 а ждёт, не передаст ли ббс3 сообщение для ббс2. Если такое сообщение поступило, оно тутже, без задержки, отправляется дальше. Как мы видим ббс1 поступил вполне разумно, он не стал разрывать связь с ббс2, а подождал. Таким образом мы избавились от лишних запросов на форвардинг и ускорили передачу почты между ббс2 и ббс3.

Это простейший пример для иллюстрации, в реальных условиях, при 5 партнёрах и более, выигрыш в количестве соединений, нагрузки на сеть и скорости передачи, получается просто огромным! Вы спросите: Как же ббс1 может сказать ббс2 чтобы он подождал, веть в стандартном протоколе форвардинга такой команды нет? Да очень просто! Ббс1 задерживает передачу FQ на запрос FF. Вот и всё, поэтому этот механизм остаётся в рамках стандартного форвардинга.

Одновременный форвардинг со всеми партнёрами
BCM может вести форвардинг одновременно с 80 партнёрами. Причём, ему всё равно вызывают они его или он их. Чтобы начать форвардинг сразу со всеми, дайте команду SF ALL.

Проверка подлинности бюллетеня
Чтобы обьяснить все все происходит, давайте представим следующую ситуацию. Есть bbs rz6hxa который ведет форвардинг с bbs ut4nf и bbs ut5ug. Например ut4nf послал бюллетень. Обычно бюллетень будет передан на rz6hxa и ut5ug и разойдется дальше по сети. Здесь все как обычно.

Теперь представим другую ситуацию:
Бюллетень отправил ut4nf, но только на ut5ug. Форвардинг между ut4nf и rz6hxa не состоялся например по причине отсутствия сетевого соединения. В тоже время bbs ut5ug дальше рассылает бюллетень полученный от bbs ut4nf и передает его на bbs rz6hxa. У bbs rz6hxa возникает сомнение в подлинности такого бюллетеня и это вполне логично, веть бюллетень от ut4nf должен был прийти напрямую на rz6hxa без посредников на пути. Тогда bbs rz6hxa чтобы убедиться что бюлленеть действительно пришел от ut4nf ставит его на отправку этому bbsу. Тут используется очень простая логика! Если бюллетень послал действительно ut4nf то он от него откажется так как бюллетень с таким BID у него уже есть. Если это подмена и бюллетень фальшивый, то ut4nf его примет, а bbs rz6hxa просигнализирует sysop о данном проишествии!

Управление HTTP-интерфейсом
BCM имеет встроенный http-сервер, который по умолчанию включен и отвечает на порту 8080. Для доступа пользователей в ББС через http-интерфейс, sysop дожен установить tty-пароль тому пользователю которому разрешено пользоваться этим интерфейсом. Sysop может закрыть http-интерфейс или изменить номер порта на котором этот сервис будет отвечать.

Если вы организовали гостевой вход через http-интерфейс для всех желающих (как это сделано на rz6hxa) то обеспечьте неизменность указанных вами данных. Для этого через crond и файлы .imp нужно организовать автоматическое восстановление исходных данных гостевого входа.

Всё соединения и потытки входа через http-интерфейс отмечаются лог-файле. Sysоp может изменить обои для http-интерфейса и немного его украсить. Получить права суперпользователя через http-интерфейс - невозможно! Также не будут работать некоторые сервисы, например файловый сервер и др. Вы можете использовать практически любые www-браузеры: Opera, Internet Explorer, Mozilla, Netscape и др. Авторизация для работы через http-интерфейс, обязательна.

Организация обмена PR почтой через E-MAIL
BCM имеет встроенный smtp/pop3-сервер, который по умолчанию включен и отвечает на портах 8025/8110. Все соединения пользователей отмечаются в логах. Сервер работает очень устойчиво и надёжно, заголовки подменяются автоматически при отправки из e-mail в pr и обратно. Программа TheBat! понимает русскую кодировку CP-866 и позволяет полноценно работать с BCM. Для того чтобы пользователь мог использовать pop3/smtp, ему нужно установить tty-пароль.

Получение бюллетеней из NNTP-сервера
Для того чтобы получать бюллетени из BCM и нормально читать русские тексты, используйте программы Mozilla, Netscape, Forte Agent. Писать бюллетени через NNTP-сервер, невозможно. Авторизация не требуется.

Эффективная работа на радиочастотах
Самым эффективным контроллером (для УКВ радиосетей) является RMNC и его аналог PC/FlexNet, далее идут TNC-3, TNC-4, (X)NET. Baybox может напрямую работать с этими контроллерами, без дополнительных драйверов, что делает связку BCM+RMNC (или PC/FlexNet+BCM) очень удачным решением для радиосетей где количество пользователей более 3х на каждый порт.

UA6HJQ