IrcDDB: различия между версиями

Материал из APRS
Перейти к навигации Перейти к поиску
(Новая страница: « == Введение == Селективные вызовы в D-STAR - это и преимущество и недостаток. Преимущество …»)
 
Строка 22: Строка 22:
  
 
== ircDDB ==
 
== ircDDB ==
Для решения вновь появившейся проблемы немцы из Georg Simon Ohm University of Applied Sciences (DB0FHN) предложили свою разработку - ircDDB.
+
Для решения вновь появившейся проблемы немцы из Georg Simon Ohm University of Applied Sciences ([[DB0FHN]]) предложили свою разработку - ircDDB.
  
 
Своей идеей реализации ircDDB обязан ботнетам - для передачи команд используется старая, как весь Интернет, технология IRC.
 
Своей идеей реализации ircDDB обязан ботнетам - для передачи команд используется старая, как весь Интернет, технология IRC.

Версия 15:06, 1 июля 2012

Введение

Селективные вызовы в D-STAR - это и преимущество и недостаток.

Преимущество в том, что они есть, ровно как и в профессиональных технологиях транкинговой связи (например: TETRA) и телефонной связи.

Недостаток - на репитерах D-STAR нет возможности разделять частоты (FDMA), а в рамках несущей - время (TDMA). Иными словами, при селективной передаче ресурс репитера монополизируется одним пользователем. Это, кстати, одна из причин, по которой крейне рекомендуется call-routing реализовывать на дуплексных репитерах.

Идея call-routing проста - ровно как в сотовой сети вы не знаете, к какому репитеру подключен ваш корреспондент, знаете лишь позывной ближайшего репитера. В новой станции ICOM ID-31 такая функциональность доведена до блеска - на флеш-карте станции хранится файл со списком репитеров, репитер выбирается по геопозиции, полученой со встроенного GPS-приёмника станции.

При смене позиции ваша станция инициирует передачу на репитер (ну или вы сами нажимаете PTT), таким образом она регистрируется на репитере.

Я точно не знаю, как изначально появился call-routing на ID-RP1C, но эта функция реализована в ПО RS-RP2C и ПО pdplus. В настоящий момент времени вся информация о регистрациях (в инфраструктуре ICOM) передается на Trust Server, доступ к которому жёстко модерируется.

В ранних версиях ПО (generation 1 - G1) была реализована множественная репликация данных между узлами и это приводило к тому, что информация о регистрации узлов могла реплицироваться вплоть до пары часов.

Первый и основной Trust Server был создан командой K5TIT и, как ясно из позывного, находится в штате Техас, США.

Многим радиолюбителям за пределами США не нравилось, что информация о их местоположении "сливается" в США, что привело к организации X-Trust / Multi-Trust. На самом деле краеугольным камнем тут является не то, что техническая площадка находится в Техасе, а что она удалена и при её недоступности (авария на площадке, проблемы на каналах связи) страдают все узлы D-STAR, на которых предоставляется call-routing.

В общем, в Европе появился свой независимый X-Trust, "общения" с которым у US-Trust не было.

ircDDB

Для решения вновь появившейся проблемы немцы из Georg Simon Ohm University of Applied Sciences (DB0FHN) предложили свою разработку - ircDDB.

Своей идеей реализации ircDDB обязан ботнетам - для передачи команд используется старая, как весь Интернет, технология IRC.

IRC - это не что иное, как чат-сервер с функцией релея, благодаря которой сервера можно масштабировать горизонтально, разнеся их географически. Одна группа серверов в США, другая в Европе - все они объеденены группой чатов. Каждый репитер/шлюз является ботом в чате dstar. Практически при каждой новой передаче шлюз передает информацию о маршруте другим ботам через сервера IRC. Информация передается внутри географических регионов и реплицируется на уровне опорных узлов ircDDB. Таким образом обеспечивается высокая производительность и надёжность решения. Хранение операционных данных о маршрутах производится локально на узлах. Теперь становится понятна вторая часть названия системы DDB - distributed database (распределенная база данных).

Я умеренно употребил слово "боты", потому как получателем сообщения о факте передачи (heard) является не весь чат-канал, а боты-серверы ircDDB (ircddbd).

Задачами ircddbd являются:

  • кэширование таблиц маршрутизации позывных и видимости;
  • обработка входящих сообщений heard;
  • подготовка статистики для чат-канала статистики;
  • нотификация всех узлов в канале об изменении таблиц маршрутизации и видимости.

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

Теперь о связи Trust и ircDDB. Всем узлам, базирующимся на ПО RS-RP2C предлагается установить ircDDB Add-on, подключающий эти узлаы к ircDDB. Таким образом ircDDB покрывает маршрутные таблицы всех Trust-сетей.

Как это работает на практике?

Вы нажимаете PTT на вашей станции. Она отправляет заголовок передачи на репитер. В свою очередь ПО репитера/узла информирует серверных ботов ircDDB о регистрации вашей станции на узле. Таким образом все репитеры, подключённые к ircDDB узнают, с каким репитером вы работаете. Далее, вы делаете селективный вызов через репитер. ПО шлюза по локальной копии маршрутных таблиц определяет, на каком репитере зарегистрирован ваш корреспондент, позывной и IP-адрес шлюза и отправляет VoIP-поток на этот узел.

Вот так вот происходит QSO.