Взаимосвязь различного Интернета, связывающего системы была раздражающим вопросом недавно. Каждая система имеет ее стандарты операции и культурного ядра. Взаимосвязи рискуют из нарушения этих уникальных качеств каждой системы, разрушая Интернет, связывающийся для каждого - пользователи и операторы подобно. Из-за внезапного и неожиданного увеличения числа(номера) безудержных ссылок(связей) между системами в конце 2002, я был вынужден выпустить(освободить) информацию к общедоступному ранее чем ожидаемый. Мой взгляд - я предпочитаю видеть, что пересечение связывается управляемый, чем позволяет ему(этому) развиваться способом для данного случая. Эта страница выделяет цели дизайна взаимосвязей IRLP-EchoLink и затем детализирует текущую работу в стадии реализации, чтобы реализовать эти рекомендации. Исход - проект EchoIRLP, который развился в течение 2003.
IRLP - EchoLink - проблема:
Выпуски(Проблемы), включенные в себя в соединение IRLP и EchoLink включают в себя различия между этими двумя системами. В то время как на поверхности, IRLP и EchoLink выглядят несколько подобными, они фактически весьма различны на их подходах. Важные различия включают:
EchoLink позволяет пользователям использовать их PC, чтобы подключиться к сети. IRLP спроектирован, чтобы предотвратить этот вид(сортировку) подключения(связи).
IRLP использует основанную схему аутентификации PGP. EchoLink использует более простую схему пароля, и ее процедуры проверки правильности позывного не приняты как адекватные всеми частями семейства IRLP.
Cмотря на различия, мы можем видеть, что в первом случае, эти две сети имеют противостоящие представления(виды) относительно желательности подключений(связей) PC с узлами. Владельцы узла стремились к одной сети или другому на этой только точке(пункте), во многих случаях. Соединение этих двух сетей заставит некоторых владельцев узла IRLP чувствовать себя нарушенными, потому что есть обход цикла, который позволяет пользователям PC подключаться к их узлу - самой вещи, которой они хотели избегать, используя IRLP.
На второй точке(пункте), заслуживающее внимания, что безопасность только столь же хороша как ее самая слабая ссылка(связь). Позволение IRLP и сетей EchoLink, чтобы стать связанный без дополнительных элементов управления владельца узла уменьшает(сокращает) эффективный уровень безопасности IRLP до немного больше чем, что предлагает EchoLink.
Рекомендации для IRLP - Взаимосвязи EchoLink.
Теперь мы - бит более знакомый со включенными в себя выпусками(проблемами) (и игнорирование критических изоляционистов с обеих сторон:)), мы можем сформулировать некоторые рекомендации для взаимосвязи этих двух сетей. Я идентифицировал два сценария взаимосвязи, которые минимизируют воздействие взаимосвязей между EchoLink и сетями IRLP. Один из тех сценариев имеет два типа sub. Возможные схемы чтобы связывать системы следующие:
Общий сервер конференции, способный к принятию подключений(связей) от IRLP или узлов EchoLink.
Постоянно связываемый IRLP и серверы конференции EchoLink (расширение к *1).
Двойной системный способный узел IRLP.
Временное пересечение связывается для критического положения и специальных событий.
Эти сценарии взаимосвязи будут описаны подробно ниже.
Общий сервер конференции - основная идея имеет сервер конференции, способный к принятию подключений(связей) или от IRLP или от узлов EchoLink. Узлы, желающие поддерживать связь поперек IRLP - граница EchoLink может подключенный к одному из общих серверов, используя их родной протокол и поддерживать связь, как если бы подключался к родной сети. Поскольку конференции требуют, чтобы преднамеренное(неторопливое) действие соединилось с, и также их адреса узла известны с обеих сторон, он(это) прост для людей с обеих сторон сервера блокировать его(это), если они не желают быть в состоянии подключиться к другой сети. Технология, чтобы выполнить этот вид(сортировку) взаимосвязи уже существует и была экстенсивно тестирована, а также пользовательские сценарии IRLP, чтобы очевидно соединиться со способными конференциями EchoLink IRLP. Это - 100 %, выбирают в системе, поскольку он(это) не возможен для узла IRLP, чтобы найти общедоступные серверы конференции без добавления дополнительных сценариев. Поскольку обе сети способны к сжатию аудио GSM (стандарт для EchoLink и опции для IRLP), и транспортные протоколы весьма похожи, сервер конференции в состоянии выполнить относительно простое преобразование протоколов и передать аудио между IRLP и EchoLink без любой деградации качества - кое-чего, что существующие взаимосвязи не могут требовать, поскольку они декодируют обратно к аналоговому аудио и затем повторно кодируют.
Связанный IRLP и серверы конференции EchoLink - Это похоже на вышеупомянутый сценарий, за исключением того, что IRLP и конференции EchoLink постоянно находятся на отдельных серверах. Основные преимущества этого вида(сортировки) системы состоят в том, что родные протоколы системы защиты могут более легко использоваться на обоих серверах, и также пропускная способность может быть увеличена (при наличии серверов IRLP И ECHOLINK на отдельных сайтах). Вплоть до середины 2004, такие связанные серверы были реализованы, используя аналоговую методику, используя два узла (1 IRLP, 1 EchoLink) вплотную. В течение августа и сентября 2004, программное обеспечение было разработано, чтобы позволить функционировать цифровой ссылке(связи) между отражателем IRLP (подканалы GSM только) и конференция EchoLink. Первая ссылка(связь) теста была установлена в августе 2004, с первым comong ссылок(связей) "продукции" онлайн в октябре 2004. С нетерпением ждите более официально санкционированных сетей кросс-системы в 2005! Первая сеть, которая будет использовать цифровое связующее звено официально будет VoIP Skywarn сеть в конце 2004. Я также смотрю на выполнимость перемещения шлюза кросс-системы к в пределах отражателя IRLP. Это будет требовать, чтобы немного помощи от Дейва Кеймрона VE7LTD тестировало и реализовало. Отдельное(единственное) решение сервера имеет преимущества простоты и безопасности, за счет способности(вместимости), поскольку все узлы будут использовать полосу пропускания той же самой системы.
Двойной системный узел - Это предлагает различный подход к общедоступным подходам сервера. В действительности, IRLP - функция EchoLink перемещена(тронута) _within_ узел IRLP непосредственно. Есть два способа достигнуть этого. Первое должно просто выполнить IRLP и систему EchoLink рядом, но предоставить некоторую форму сообщения между двумя системами так, чтобы только один мог быть активным. Нижняя сторона этого - он(это), требует некоторых дополнительных аппаратных средств (по крайней мере, другая плата интерфейса и звуковая плата, если программа EchoLink Linux используется на машине IRLP), и если выполнено на двух отдельных машинах, в сообщении могут быть условия состязания. Альтернативный подход должен фактически выполнить узел IRLP с шлюзом EchoLink на том же самом поле непосредственно. Программное обеспечение IRLP будет управлять всеми операциями и обращаться к межсетевым компонентам EchoLink, когда они требуются. Для входящих вызовов EchoLink, шлюз EchoLink сообщит о программном обеспечении IRLP посредством подготовленного интерфейса. Это позволяет одному полю выполнять обе роли и гарантирует что, в то время как пользователи могут решить, какая система соединяться с, и что узел является полностью функционирующим узлом в обеих сетях, он(это) не может создать ссылку(связь) между сетями. Текущая версия EchoIRLP поддерживает этот режим работы и экстенсивно использовалась в поле на конец 2004.
Изменение(Разновидность) этого подхода, который использует измененного клиента EchoLinux, чтобы подключиться к узлам EchoLink, согласно элементу управления системы IRLP, находится в настоящий момент под разработкой в США и, вероятно, будет освобождено в начале 2003. Сетевой результат будет тем же самым - узел, способный к присоединению или к EchoLink или к IRLP, но не соединять эти две сети. На 2004, разработка подхода echoLinux, кажется, останавливается.
Причина для того, чтобы выбирать IRLP как основная платформа для двойного системного узла - из-за аутентификационных требований IRLP, которые требуют узла IRLP, а также критической гибкости платформы IRLP.
Будущие планы включают в себя сжимание интеграции между EchoIRLP и сетью IRLP. Это позволит сценариям EchoIRLP без швов межтереть в узел IRLP, создавая объединенный пользовательский интерфейс для конечного пользователя (на февраль 2004, система уже очень прозрачна). Связь с разработчиками IRLP в стадии реализации, чтобы определить и предоставленный необходимые обработчики прерываний, чтобы сгладить от остающихся грубых краев(граней).
Конечный(Заключительный) сценарий заслуживает упоминания. Аварийные связи - почти всегда универсальное исключение к нормальным сетевым правилам, таким образом нормальный принцип хранения сетей, отдельных больше не применяется(не обращается). Однако, перекрестные ссылки(связи), используемые для критического положения, обучаясь и специальных событий должны придерживаться следующих рекомендаций:
Если возможно, получите предшествующее право доступа от узла и включенных в себя владельцев конференции (очевидно, в критическом положении, это не всегда возможно).
Узлы, подключенные к crosslink не должны иметь никаких хвостов, идентификаторов или другого постороннего размножения сигналов в ссылку(связь). Они - реальная проблема на больших сетях.
Средства, чтобы позволить "монитор только" подключения(связи) должны быть предоставлены. Это можно сделать или, используя EchoLink или, используя обычный потоковый аудио (MP3/Ogg Vorbis/Real Носители/Windows Media).
Сам crosslink должен иметь столь же высокое качество насколько возможно и должен избежать ссылки(связи) РФ между сетями. Есть уже достаточно потери качества из-за включенного в себя изменения(замены) кодер-декодера. Теперь, когда цифровое связующее звено выполнимо, я рекомендую, чтобы все перекрестные ссылки(связи) использовали новую цифровую систему. Это предоставляет самое высокое звуковое качественное и самое низкое время ожидания. Цифровая система может связать конференцию EchoLink с GSM отражатель IRLP (ADPCM не поддерживается и при этом нет почти никакого преимущества, поскольку производительность не будет намного лучше чем существующие аппаратные аналоговые шлюзы).
EchoIRLP - Дизайн и Архитектура.
Система EchoIRLP способна к реализации и общедоступная конференция и двойные системные режимы работы. Выбор режима работы делается множеством переменных среды. Кроме того, EchoIRLP способен к действию в общедоступном режиме конференции, подключаясь к известным общедоступным конференциям, в то время как, используя родные протоколы EchoLink для всех других подключений(связей) EchoLink, если требуется.
Цели дизайна для EchoIRLP были (и все еще-), следующим образом:
Система не должна пересечь ссылку(связь) эти две сети
EchoIRLP должен поддержать локальную конференц-связь. Это происходит из-за того, что подключения(связи) PC используют одно подключение(связь) на человека, которое является неэффективным. Кроме того, Windows пользователи EchoLink используется к этой возможности также.
Система должна быть настолько прозрачной насколько возможно до конца пользователь.
EchoIRLP должен поддержать(обслужить) технические стандарты IRLP непосредственно относительно управления каналом (то есть он(это) должен уважать занятые каналы, и т.д).
EchoIRLP должен сообщить о таком большом количестве полезной информации назад соединяющемуся пользователю в случае сбоя подключения(связи) или других неожиданных событий.
В общедоступном режиме конференции, EchoIRLP может только подключиться к конференциям, определенным в echo_conf файле. echo_conf файл содержит имя конференции, адрес IP, число(номер) узла и пароль подключения(связи) для каждой конференции. Дополнительная опция позволяет владельцу узла выбирать, использовать ли серверы каталога EchoLink или статические входы в файле главных компьютеров, чтобы разрешить адрес IP для конференции. Используя главные компьютеры файл позволяет узлу IRLP подключаться к конференции без любой ассоциации к сети EchoLink. Недостаток - то, что, если адрес IP изменяется, подключение(связь) будет терпеть неудачу. Используя директивные серверы разрешает эту проблему, но требует, чтобы идентификатор EchoLink был зарегистрирован для узла, таким образом он(это) может войти.
Как только адрес IP конференции известен, узел IRLP делает подключение(связь), используя двоичные файлы IRLP к межсетевым портам на сервере конференции. Кроме того, он(это) устанавливает занятое состояние IRLP, чтобы показать, что он(это) подключен к себе, который является принятым способом показать, что узел подключен к чему - то другому чем IRLP. Дополнительные файлы состояния содержат информацию о подключении(связи) для фактического общедоступного подключения по типу конференц-связи.
Полная двойная системная операция требует, чтобы копия thebridge была конфигурирована как специализированный(выделенный) шлюз для узла. Обычно thebridge выполнен на узле IRLP непосредственно (localhost) для простоты общения, хотя есть обработчики прерываний, чтобы позволить thebridge, чтобы быть выполненный на отдельной машине. Дополнительное программное обеспечение заботится обо всех функциях EchoLink - войти, разрешение адресов IP, присоединение к узлам и получению входящих вызовов. Интерфейс между сценариями EchoIRLP и thebridge - через двухсторонний интерфейс создания сценария:
Команды отправляют thebridge, используя утилиту, названную(вызванную) tbdcmd. Это дает сценариям законченный элемент управления стороны EchoLink системы.
События от thebridge отправляют специальному сценарию (в EchoIRLP, он(это) вызвал echoirlp-состояние), который решает, что событие печатает и затем передает управление к соответствующему сценарию для того события. Это позволяет системе отвечать на входящие подключения(связи), разъединения и изменения(замены) состояния.
Присоединение к узлу EchoLink, используя thebridge похоже на общедоступный метод конференции со следующими исключениями:
Адрес IP разрешен(решен), используя файл главных компьютеров thebridge, который автоматически обновлен каждые 5 минут. Это отменяет любые другие параметры настройки разрешающей способности.
Все подключения(связи) протокола IRLP сделаны на главный компьютер (обычно localhost/127.0.0.1), что thebridge продолжается.
Подключение(Связь) происходит в двух стадиях - IRLP к стадии thebridge и стадии EchoLink, где thebridge делает окончательное подключение(связь) с узлом EchoLink.
Наконец, чтобы встретить(выполнить) рекомендации в верхней части этой страницы, должен быть некоторый механизм, чтобы предотвратить системы, становящиеся пересечением, связанным случайно. Это достигнуто на двух уровнях. Во-первых, архитектура делает чрезвычайно трудным пересечь ссылку(связь) эти две сети. EchoIRLP использует те же самые аппаратные средства и программное обеспечение, которых сам IRLP требует, и чрезвычайно трудно совместно использовать это способом, который позволил бы перекрестной ссылке(связи) работать. Во-вторых, само программное обеспечение имеет множитель, проверяет существующие ранее подключения(связи). Поскольку EchoIRLP устанавливает открытый файл IRLP, любая попытка соединиться от IRLP, в то время как подключение(связь) EchoLink происходит, приводит к занятому ответу, отправляемому удаленному узлу IRLP. Подобно для прибывающих подключений(связей), проверки программы EchoIRLP все комбинации IRLP и открытых файлов EchoLink, чтобы определить состояние системы, и только позволяют подключению(связи) продолжаться(переходить), если нет никакой возможности перекрестной ссылки(связи) (то есть, узел - простой или уже на подключении(связи) EchoLink). Кроме того, EchoIRLP использует те же самые методы как IRLP непосредственно, чтобы проверить(отметить), ли канал занят и может сообщить об этом состоянии назад к узлу вызова. Для исходящих соединений, когда-то узел подключен к другой системе, не могут быть сделаны никакие дальнейшие исходящие соединения. Это может измениться в будущих версиях EchoIRLP.
Дополнительные проверки также выполнены, чтобы видеть, разрешают ли узлу вызова подключиться к системе. Этим управляют 3 списка контроля доступа на системе, которые являются полностью владельцем узла, с перестраиваемой конфигурацией.
На 2004, EchoIRLP двигается в автоматизированные обновления, как IRLP непосредственно. Это сделает систему безболезненной для владельцев узла, чтобы поддержать(обслужить), поскольку объем работы будет делаться автоматически, так же, как с IRLP непосредственно.
Обсуждая межсистемные шлюзы, он(это) стоит рассматривать то, что могло бы потребоваться, чтобы позволить eQSO быть соединенным в общедоступные конференции между eQSO и другими сетями. В то время как ссылки(связи) пересечения eQSO уже существуют с EchoLink, они реализованы связью узел EchoLink к eQSO узлу, который начинает некоторые выпуски(проблемы) синхронизации с сообщающего PTT, а также деградации звукового качества из-за дополнительного декодирования проходов и перекодирования.
Лучший подход должен был бы иметь часть программного обеспечения, выполняют трансляцию между различными транспортными протоколами. От моего понимания, eQSO также использует GSM 6.10 кодер-декодеров, то же самое как EchoLink и одна из опций с IRLP. Однако, eQSO использует транспорт(транспортировку) TCP вместо основанных транспортов(транспортировок) UDP, которые EchoLink и IRLP используют. Поскольку кодер-декодеры все совместимы между этими тремя системами, появляется, что относительно простое преобразование транспортного протокола могло управляться между eQSO, EchoLink и IRLP. Кроме того, потому что eQSO - основанный сервер (никакие ссылки(связи) равноправного-узла-равноправного-узла), только общедоступный сценарий конференции должен рассмотреться. Более сложные шлюзы равноправного-узла-равноправного-узла не требуются для eQSO, но интегрирования eQSO клиента на узел IRLP, стиль EchoIRLP мог быть интересным осуществлением(упражнением).
Наличие eQSO возможности на общедоступном сервере конференции также имеет некоторые интересные технические импликации. eQSO использует простое экспортное подключение(связь) TCP для его звукового пути. Этот тип подключения(связи) легко договаривается о шлюзах NAT, в отличие от реализаций UDP. Это могло быть использовано, чтобы позволить "сайт разбиения" IRLP или системы EchoLink, где родной IRLP или часть EchoLink системных жизней на удобном общедоступном адресе IP, и радио-стороне присоединены к копии работающего eQSO в лачуге. Безопасность могла быть осуществлена(предписана), используя Linux iptables, чтобы предотвратить другие главные компьютеры, подключающиеся к шлюзу. Множитель eQSO клиенты может жить позади того же самого маршрутизатора NAT с отдельным(единственным) общедоступным адресом IP.
Для такой системы, чтобы быть выполнимым, eQSO протоколы должны быть открыты таким же образом, что протоколы EchoLink были открыты (IRLP использует Говорить Свободно протокол для его звукового транспорта(транспортировки), для которого открытая исходная реализация всегда была доступна). Я имею его(это) на хорошем полномочии, что eQSO протоколы не будут открыты в обозримом будущем, однако, есть хорошая возможность работы с разработчиками, чтобы принести eQSO в сгиб кросс-системы на цифровом уровне, с открытым интерфейсом к eQSO системе, являющейся реальной возможностью.
Заключение.
Я представил сценарий IRLP - пересечение EchoLink соединение и некоторые из выпусков(проблем), окружающих такие ссылки(связи). Выпуски(проблемы) рассматривались подробно, и диапазон возможных решений был представлен. Решения представляли включенный в себя или предоставление(обеспечение) общего сервиса конференции, где узлы обеих систем могли соединиться и поддержать связь друг с другом, или узлами, способными к сообщению(связи) машинно как узел полноправного члена каждой системы, но неспособный создать ссылку(связь) между системами. Ожидается, что оба типа подключения использовались бы практически, поскольку они служат совсем другим потребностям.
Разработка программного обеспечения, чтобы достигнуть вышеупомянутых целей уже началась, и множество экспериментальных мостов конференции было уже экстенсивно тестировано и IRLP и узлами EchoLink. Сценарии IRLP, чтобы подключиться к этим серверам были также написаны и тестированы. Двойной узел IRLP/EchoLink находится под разработкой и как ожидают, будет освобожден в начале 2003. Обновите: я имею частичную реализацию двойной системной работы узла. Он(это) ждет еще некоторую разработку межсетевого кода, прежде, чем я могу продолжать разрабатывать сценарии.
Вопрос соединения IRLP и EchoLink не то, если, а когда и как. Как должен управляться, получить лучший результат для всех. Точно так же взаимосвязи к eQSO и другим сетям также случатся, хотя по более медленной норме(разряду,скорости), из-за больших различий протокола, и факта, что eQSO протокол еще не находится в общедоступном домене(области).
Избранные действующие эхолинки (23) -->
