Page 5 of 9

ЧаВО

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

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

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

ЧаВО

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

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

ЧаВО

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

Поэтому я считаю, что будущее за CCS - там решены все эти проблемы.
Да-да, мы это как раз наблюдали недавно в Москве :)
Там правда еще большой процент ошибок добавлял эффекта, но это уже другая история...

ЧаВО

Posted: 07 Apr 2015, 18:02
by R3ABM
R2AJV wrote: А немцы случаем не ircd-seven патчили?
Нет :)

ЧаВО

Posted: 08 Apr 2015, 06:13
by R3ABM
UT2UU wrote: Поэтому я считаю, что будущее за CCS - там решены все эти проблемы.
Это иллюзия :) CCS по набору сервисов не отличается от ircddb или US Trust. Вся "фишка" CCS в том, что коммутация вызовов вынесена на сервер, клиент постоянно поддерживает соединение с сервером и пролазит через любой NAT без форварда портов и получения публичных IP.

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

ЧаВО

Posted: 08 Apr 2015, 10:00
by UT2UU
R3ABM wrote: Это иллюзия :) CCS по набору сервисов не отличается от ircddb или US Trust. Вся "фишка" CCS в том, что коммутация вызовов вынесена на сервер, клиент постоянно поддерживает соединение с сервером и пролазит через любой NAT без форварда портов и получения публичных IP.
Мне больше всего нравится, что человеку, которого ты вызываешь ничего не нужно предпринимать, чтобы поговорить с тобой. Ты просто соединяешься и говоришь - он отвечает, все выглядит логично.
К тому же можно послушать что там происходит - просто подсоединяешься и слушаешь. В ircddb ведь нельзя прослушать удаленный узел или станцию.

Так же было бы классно интегрировать Hytera в CSS чтобы можно было по коду звать из DStar станцию в DMR.
R3ABM wrote: По факту надежность решения снижена: вся коммутация происходит на одной площадке (xreflector.net, не дай Бог упадет из AS), трафиг гонять приходится через весь мир.
Проблема с пропускной способностью серверного канала сейчас совершенно не стоит. А вот проблема с "последней милей" до узла стоит очень остро. Многие узлы стоят на мобильном интернете, оплачиваемом покилобайтно.
И CCS тут смотрится гораздо более выгодно, потому что не гоняет по сети кучу ненужной информации, как это делает ircddb.
R3ABM wrote: Ну и, наконец, автор DG1GH сейчас потерял интерес к этому проекту.
Эта проблема случается со всеми проектами рано или поздно, к сожалению :(

ЧаВО

Posted: 08 Apr 2015, 10:55
by R3ABM
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.

ЧаВО

Posted: 08 Apr 2015, 13:43
by UT2UU
R3ABM wrote: Нужно четко для себя понимать, какие задачи преследует частный (персональный) вызов, а какие - групповой. Никто не мешает присоединиться к тому же рефлектору, что и удаленный узел.
А зачастую узел не подключен ни к какому рефлектору. Народ ведет беседу локально, а послушать о чем говорят - хочется.
UT2UU wrote: Рекомендую подучить теорию. С серверной стороны проблемы с резервированием канала, питания и так далее. Нужно отдавать отчет в том, что держа все яйца в одной корзине (все сервера в одном ЦОДе) вероятность отказа всего решения в целом из-за падения питания или канального оборудования гораздо выше, чем децентрализованного. Тут не о чем спорить.
За 6 лет использования Амазоновское облако AWS меня ни разу не подвело. Наверное я что то не так делаю. Базы у меня крутятся в Azure - тоже никаких проблем. Наверное Microsoft не слышал о яйцах в одной корзине и у него поэтому все работает :)

ЧаВО

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

ЧаВО

Posted: 17 Apr 2015, 06:46
by R3ABM
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 гарантирована только в моей версии рефлектора, в остальных случаях соединение не гарантируется.