ЧаВО

R2AJV · Post by **R2AJV** » 07 Apr 2015, 17:40

R3ABM wrote:1. Потому что серверная часть ircddb не для всех. Кому нужно - разберется. Скажу еще, что помимо ircddb, нужно патчить сервер IRC. Немцы патчили старую версию, я использую более свежие, найдя возможность вынести патченый функционал в плагин.

2. Из взаимодействия с разработчиком, Джонатоном G4KLX. Список доменных имен вшит в код.

3. Потому что изначально ircddb делался как addon к репитерному софту от Icom. У нас, в свою очередь, ограничение, что такой софт использовать нельзя. Код ircddb под это дело пропатчен специальным образом.

Понятно.
Чем глубже, тем интереснее

А немцы случаем не ircd-seven патчили?

UT2UU · Post by **UT2UU** » 07 Apr 2015, 17:50

R2AJV wrote:Почему в ircDDB.net регистрируют только клубные (коллективные) позывные, а в ircddb.dstar.su - персональные?

Я тоже в начале заморачивался с регистрацией в ircDDB. А теперь понял, что она 99.9% пользователей просто не нужна - не умеет народ пользоватся роутингом вызовов и не хочет. Мертвая функция получается:
- Если ты человека зовешь направленно, то он не понимает, что для ответа нужно ему тоже поставить направленный вызов на тебя. Начинает звать просто так, а ты не слышишь.
- Если провести статистику использования, то 99.99% вызовов это вызова в рефлектор. Вызовами на Gateway вообще никто не пользуется.
- Часто проще самому перелинковать узел в нужный рефлектор, чем объяснять принцип работы Call Routing

Поэтому я считаю, что будущее за CCS - там решены все эти проблемы.

R2AJV · Post by **R2AJV** » 07 Apr 2015, 17:56

UT2UU wrote:
R2AJV wrote:Почему в ircDDB.net регистрируют только клубные (коллективные) позывные, а в ircddb.dstar.su - персональные?
Я тоже в начале заморачивался с регистрацией в ircDDB. А теперь понял, что она 99.9% пользователей просто не нужна - не умеет народ пользоватся роутингом вызовов и не хочет. Мертвая функция получается:
- Если ты человека зовешь направленно, то он не понимает, что для ответа нужно ему тоже поставить направленный вызов на тебя. Начинает звать просто так, а ты не слышишь.
- Если провести статистику использования, то 99.99% вызовов это вызова в рефлектор
- Часто проще самому перелинковать узел в нужный рефлектор, чем объяснять принцип работы Call Routing

Поэтому я считаю, что будущее за CCS - там решены все эти проблемы.

Да-да, мы это как раз наблюдали недавно в Москве

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

Post by **R3ABM** » 07 Apr 2015, 18:02

R2AJV wrote: А немцы случаем не ircd-seven патчили?

Нет

Post by **R3ABM** » 08 Apr 2015, 06:13

UT2UU wrote: Поэтому я считаю, что будущее за CCS - там решены все эти проблемы.

Это иллюзия

CCS по набору сервисов не отличается от ircddb или US Trust. Вся "фишка" CCS в том, что коммутация вызовов вынесена на сервер, клиент постоянно поддерживает соединение с сервером и пролазит через любой NAT без форварда портов и получения публичных IP.

По факту надежность решения снижена: вся коммутация происходит на одной площадке (xreflector.net, не дай Бог упадет из AS), трафиг гонять приходится через весь мир. Ну и, наконец, автор DG1GH сейчас потерял интерес к этому проекту.

UT2UU · Post by **UT2UU** » 08 Apr 2015, 10:00

R3ABM wrote: Это иллюзия CCS по набору сервисов не отличается от ircddb или US Trust. Вся "фишка" CCS в том, что коммутация вызовов вынесена на сервер, клиент постоянно поддерживает соединение с сервером и пролазит через любой NAT без форварда портов и получения публичных IP.

Мне больше всего нравится, что человеку, которого ты вызываешь ничего не нужно предпринимать, чтобы поговорить с тобой. Ты просто соединяешься и говоришь - он отвечает, все выглядит логично.
К тому же можно послушать что там происходит - просто подсоединяешься и слушаешь. В ircddb ведь нельзя прослушать удаленный узел или станцию.

Так же было бы классно интегрировать Hytera в CSS чтобы можно было по коду звать из DStar станцию в DMR.

R3ABM wrote: По факту надежность решения снижена: вся коммутация происходит на одной площадке (xreflector.net, не дай Бог упадет из AS), трафиг гонять приходится через весь мир.

Проблема с пропускной способностью серверного канала сейчас совершенно не стоит. А вот проблема с "последней милей" до узла стоит очень остро. Многие узлы стоят на мобильном интернете, оплачиваемом покилобайтно.
И CCS тут смотрится гораздо более выгодно, потому что не гоняет по сети кучу ненужной информации, как это делает ircddb.

R3ABM wrote: Ну и, наконец, автор DG1GH сейчас потерял интерес к этому проекту.

Эта проблема случается со всеми проектами рано или поздно, к сожалению

Post by **R3ABM** » 08 Apr 2015, 10:55

UT2UU wrote: Мне больше всего нравится, что человеку, которого ты вызываешь ничего не нужно предпринимать, чтобы поговорить с тобой. Ты просто соединяешься и говоришь - он отвечает, все выглядит логично.

Это не про CCS.

CCS - это транспорт, почти такой же как ircddb + G2 или trust + G2. Да и в чем проблема? Ставишь в режиме DR позывной в To и разговариваешь.

UT2UU wrote: К тому же можно послушать что там происходит - просто подсоединяешься и слушаешь. В ircddb ведь нельзя прослушать удаленный узел или станцию.

Нужно четко для себя понимать, какие задачи преследует частный (персональный) вызов, а какие - групповой. Никто не мешает присоединиться к тому же рефлектору, что и удаленный узел.

UT2UU wrote:Так же было бы классно интегрировать Hytera в CSS чтобы можно было по коду звать из DStar станцию в DMR.

Семантика сетей разная. Именно по этому я не делаю шлюз между DMR и D-STAR для частных (персональных) вызов, хотя могу:
D-STAR ничего не знает об ID в DMR, а DMR ничего не знает о позывных. И если говорить про Ham DMR, то у нас есть знание о тождественных радиолюбительским позывным DMR ID, то вот что делать для случаев, когда у пользователя System Fusion или D-STAR нет в сети DMR (ну или, например, APCO) своего ID?
Дальше есть и другие проблемы. Например, если пользователь сам присутствует в обоих сетях, нужно давать себе отчет, что "перенос" позывного из DMR в D-STAR автоматически отключит маршрутизацию этого позывного на станции D-STAR. Короче, в такой затее нет смысла. Кому нужно, опять таки, исходя из того, что 80% (я сводил статистику, 80, а не 99.9) вызовов происходит в рефлекторе, вполне достаточно иметь такую интеграцию, какая есть у нас сейчас - между рефлектором D-STAR и групповым ID в DMR. Или это тоже сюрприз?

UT2UU wrote: Проблема с пропускной способностью серверного канала сейчас совершенно не стоит. А вот проблема с "последней милей" до узла стоит очень остро. Многие узлы стоят на мобильном интернете, оплачиваемом покилобайтно.
И CCS тут смотрится гораздо более выгодно, потому что не гоняет по сети кучу ненужной информации, как это делает ircddb.

Рекомендую подучить теорию. С серверной стороны проблемы с резервированием канала, питания и так далее. Нужно отдавать отчет в том, что держа все яйца в одной корзине (все сервера в одном ЦОДе) вероятность отказа всего решения в целом из-за падения питания или канального оборудования гораздо выше, чем децентрализованного. Тут не о чем спорить.
Далее, опять же миф, что CCS "ест" меньше трафика. А поддерживать keep-alive соединения как минимум нужно? Кроме того, CCS обязывает транслировать все вызовы "в центр". Где тут "меньше трафика"? Единственное, с чем могу согласится - это нет необходимости протаскивать порты. Но мы эту задачу решаем за счет AMPR и нашего VPN.

UT2UU · Post by **UT2UU** » 08 Apr 2015, 13:43

R3ABM wrote: Нужно четко для себя понимать, какие задачи преследует частный (персональный) вызов, а какие - групповой. Никто не мешает присоединиться к тому же рефлектору, что и удаленный узел.

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

UT2UU wrote: Рекомендую подучить теорию. С серверной стороны проблемы с резервированием канала, питания и так далее. Нужно отдавать отчет в том, что держа все яйца в одной корзине (все сервера в одном ЦОДе) вероятность отказа всего решения в целом из-за падения питания или канального оборудования гораздо выше, чем децентрализованного. Тут не о чем спорить.

За 6 лет использования Амазоновское облако AWS меня ни разу не подвело. Наверное я что то не так делаю. Базы у меня крутятся в Azure - тоже никаких проблем. Наверное Microsoft не слышал о яйцах в одной корзине и у него поэтому все работает

UT2UU · Post by **UT2UU** » 17 Apr 2015, 00:27

Мучают вопросы достойные помещения в FAQ:
- Почему G4KLX не соединяется с DCS\XRF рефлекторами, если он не соединился с ircddb. В то же время UP4DAR соединяется спокойно, хотя ircddb там вообще не реализован ?
- Почему G4KLX не соединяется с XRF250 без проброса портов на роутере. В то же время UP4DAR соединяется (если нажать кнопку "разрешить доступ с IP" ?

Post by **R3ABM** » 17 Apr 2015, 06:46

UT2UU wrote:Мучают вопросы достойные помещения в FAQ:
- Почему G4KLX не соединяется с DCS\XRF рефлекторами, если он не соединился с ircddb. В то же время UP4DAR соединяется спокойно, хотя ircddb там вообще не реализован ?

Потому что в первом случае у автора кривые руки

UT2UU wrote: - Почему G4KLX не соединяется с XRF250 без проброса портов на роутере. В то же время UP4DAR соединяется (если нажать кнопку "разрешить доступ с IP" ?

В D-Extra изначально порт "прибит".
Для того, чтобы UP4DAR и другие хот-споты нормально ходили через NAT без проброски портов я сделал патч, который позволяет рефлектору отвечать в тот же порт, с которого было установлено соединение. Такую схему нельзя применять с G4KLX, потому что G4KLX отправляет стримы с разных портов (30001-30007), а слушает всегда на одном.
Таким образом мне пришлось помимо авторизации IP и позывного по внешней базе еще в этой базе иметь признак типа подключения. Для узлов привязка IP с позывным осуществляется по ircddb, для таких позывных я считаю, что порт "прибит".
Если же привязка осуществляется через Личный Кабинет, я маркирую такое подключение, как подключение с NAT.
Так что такая схема для UP4DAR в D-Extra гарантирована только в моей версии рефлектора, в остальных случаях соединение не гарантируется.