Перейти к содержимому
Local
pavlabor

Требуется эмулятор StarGazerа.

Рекомендованные сообщения

Почитал вопросы возникающие вокруг работы ubilling и понял что проблемы связаны с архитектурой  Stargazer

Насколько я понял проблем очень много, некоторые из них.

Stargazer работает с базой в памяти и при параллельной работе с базой возникают конфликты с работой, например с внесением оплаты другим приложением.

При остановке Stargazerа или биллинга идет сбой работы Насов.

Текущая архитектура может стать ограничением по количеству возможно обслуживаемых клиентов.

 

Проблемы не все, но этих достаточно чтобы задуматься о альтернативе написания эмулятора  Stargazer-а.

Мое понимание, эмулятор должен выглядеть как модуль, который можно включить или выключить, или выбор работы или через Stargazer, или через внутренний модуль.

 

Приветствуется любая критика и предложения,

помощь в консультации и программировании.

Спонсирование заинтересованных сторон, приветствуется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не совсем понятна идея. Со Старгейзером все понятно. А зачем его еще и эмулировать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
34 минуты назад, vop сказал:

Не совсем понятна идея. Со Старгейзером все понятно. А зачем его еще и эмулировать?

 

Выражение "Эмулятор Старгейзера" используется как указатель именно на то что о чем собственно разговор.

Старгейзер висит как не зависимый демон, слушает, отдает команды насам, поэтому дабы не положить сеть, структура управляющих команд должна совпадать.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это весеннее обострение, не обращайте внимания.

  • Like 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ключевые слова: транзакция, acid

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
52 минуты назад, KaYot сказал:

Это весеннее обострение, не обращайте внимания.

 

Полезнее было бы направить энергию в нужное русло -- писать законопроекты в ВР.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
44 минуты назад, Prime сказал:

ключевые слова: транзакция, acid

 

Где искать?

Сначала нужно собрать инфу, потом анализ - что можно сделать, а дальше смотреть какие получатся объемы работ.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

в коде работы с базой данных, бизнес операции должны проходить транзакционно.

 

https://ru.wikipedia.org/wiki/Уровень_изолированности_транзакций

вы должные сами определять где какой уровень изоляции.

где в каких местах присоединяться к транзакции, где требовать открытую, где открывать новую принудительно.

 

Цитата

Stargazer работает с базой в памяти и при параллельной работе с базой возникают конфликты с работой, например с внесением оплаты другим приложением.

возможно так и нужно?

если он работает через буфер и не делает flush в базу это одно, если второй datasource не видит uncommited batch transaction это другое

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
56 минут назад, Prime сказал:

возможно так и нужно?

Безусловно так и нужно.

 

Но Stargazer не решает проблему одновременного обращения к полю, скажем при работе с одной карточкой двумя менеджерами горбыль гарантирован.

Насколько я понял, основная проблема Stargazer-а в непредсказуемости работы с насами.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я думаю что от stargazer-а нужно отказаться уже в самом начале. Ключевое звено в каждой сети это NAS (Network Access Server) и он должен работать очень надёжно и быть независимым от доступности сервера(ов) билинга. По сути для NAS нужно знать IP+MAC пользователя, скорость приема/передачи, и когда отключить или включить, и это должен сформировать билинг и передать на NAS.

Изменено пользователем olsasha

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Собственно можно и отказаться, но тогда нужно пересобрать всю архитектуру юбиллинга, а это люди, сроки и деньги.

Хотелось бы решить малой кровью, хотя это может быть в итоге дороже.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, Prime сказал:

в коде работы с базой данных, бизнес операции должны проходить транзакционно.

 

https://ru.wikipedia.org/wiki/Уровень_изолированности_транзакций

вы должные сами определять где какой уровень изоляции.

где в каких местах присоединяться к транзакции, где требовать открытую, где открывать новую принудительно.

 

возможно так и нужно?

если он работает через буфер и не делает flush в базу это одно, если второй datasource не видит uncommited batch transaction это другое

 

Для сетевиков это слищком ... заумно :) ...

  • Haha 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
25 minutes ago, olsasha said:

Я думаю что от stargazer-а нужно отказаться уже в самом начале.[/quote]

 

Это надо было делать лет 15 назад. :)

 

Quote

Ключевое звено в каждой сети это NAS (Network Access Server) и он должен работать очень надёжно и быть независимым от доступности сервера(ов) билинга. По сути для NAS нужно знать IP+MAC пользователя, скорость приема/передачи, и когда отключить или включить, и это должен сформировать билинг и передать на NAS.

 

Я об этом сейчас веду неторопливый дискусс на наге. Данные, которые необходимы для предоставления услуги я называю реестром доступа. Для NASа - это пара IP-MAC, или другие данные. Объем этих данных решительно небольшой, и делать зависимость работы NASа от сложной системы, которой является биллинг - совсем не умно.

 

Изменено пользователем vop
  • Like 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 minutes ago, Stroj said:

Для сетевиков это слищком ... заумно :) ...

 

Для обеспечения надежности транзакций подойдут любые методы, от семафоров и блокировок, до разделения полномочий на изменение данных. Сетевики могут найти для себя подходящие методы. :)

2 minutes ago, olsasha said:

Скинь ссылку на тему на НАГе.

 

https://forum.nag.ru/index.php?/topic/139742-srochno-nuzhen-nomer-kruglosutochnoy-podderzhki-carbonsoft/

 

Там бедные админы мучаются отсутствием интернета из-за неработающего биллинга. Ну и попутно возникла концептуальная часть беседы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
44 минуты назад, pavlabor сказал:

Но Stargazer не решает проблему одновременного обращения к полю, скажем при работе с одной карточкой двумя менеджерами горбыль гарантирован.

Извините, но Вы не понимаете смысла работы с релятивными Базами данных ... :( В разрезе многопользовательской среды ...

Тут работать или с со старой методологией изолированных транзакций (не гарантирующих впрочем ничего) ...

Или идти по принципу отказа от "релятивизма" в сторону объектного представления данных.

Точнее, как по мне, выреженого в словах: "постоянный пересчет конечных данных на основе объектных моделей".

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
9 минут назад, Stroj сказал:

Извините, но Вы не понимаете смысла работы с релятивными Базами данных ... :( В разрезе многопользовательской среды ...

Тут работать или с со старой методологией изолированных транзакций (не гарантирующих впрочем ничего) ...

Или идти по принципу отказа от "релятивизма" в сторону объектного представления данных (к сожалению без рекурсий в строед-процедурах тут не обойтись, что не всем SQL движкам пока по вкусу :( ).

Точнее, как по мне, выреженого в словах: "постоянный пересчет конечных данных на основе объектных моделей".

 

 

Изменено пользователем Stroj

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
17 минут назад, olsasha сказал:

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

Как по мне, это через чур глобально.

ubilling написан поверх "RCMS Framework 1.2.12", сейчас на сайте есть "ReloadCMS 1.5.1 WebSat, version from 15.01.2013" но не качается, возможно что тоже помер.

Взять к сведению это

2 минуты назад, Stroj сказал:

Или идти по принципу отказа от "релятивизма" в сторону объектного представления данных.

Точнее, как по мне, выреженого в словах: "постоянный пересчет конечных данных на основе объектных моделей".

на сколько я понимаю это решается на уровне процедур базы данных, потянет ли это мускуль, вопрос открытый, свой биллинг писал на PostgreSQL.

Далее делать ревизию и портировать модули с ubilling-а.

Координатором брать nightfly, с последующей передачей ему всего депозитария.

 

Это самый широкий и дешевый вариант.

Но по любасу денег это может затянуть даже не на соточку гривен.

 

Мне l1ght  предложил открыть ветку обсуждения на https://github.com/nightflyza/Ubilling, но почему то мне кажется что на локале это эффективней решится.

Нужно заценить объемы, выйти на сумму, открыть счет и после сбора определенной сумы запилить новый биллинг.

Без бодрого финансирования, такой глобальный проект за три месяца утоптать сложно.

15 минут назад, Stroj сказал:

Извините, но Вы не понимаете смысла работы с релятивными Базами данных ... :( В разрезе многопользовательской среды ...

Извиняю и готов сотрудничать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
18 минут назад, pavlabor сказал:

Нужно заценить объемы, выйти на сумму, открыть счет и после сбора определенной сумы запилить новый биллинг.

Без бодрого финансирования, такой глобальный проект за три месяца утоптать сложно.

3 Месяца? Я сомневаюсь :( Это же такое !бодрое! финансирование должно быть ... :(

....

Короче ... я - пас ... (я свой проект, из примера, 2 года пилил), если конкретикой - помогу советом или кодом ...

Но учитывая что я понимаю чего это стоить будет - я, в основном, ПАС!. Не обессудьте ...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
4 минуты назад, Stroj сказал:

если конкретикой - помогу советом или кодом ...

Любая помощь приветствуется.

Я задумывался, но никогда не занимался многопользовательской средой.

Поэтому готов выслушать практические предложения.

Первое, есть ли такая практика?

Второе, какая база данных?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

pavlabor, вы сейчас смешали 3 компонента:

сам демон биллинга, который работает с бд, веб морду, которая работает с бд и сам сервер базы данных.

 

в данном случае - у вас "общий ресурс" это сервер бд, неважно какой движок вы используете, будь то mysql, будь postgres - принципы ACID в реляционных бд одни и те же.

по хорошему, для систем с временными рядами удобней всего ClickHouse от яндекса, более крутой системы я не видел.

 

если хотите писать свой биллинг: возьмите стек Java, Postgres, Clickhouse, Angular.

в этом ключе дофига фреймворков для скейлабилити, эвейлиабилити, фейловеров и прочих необходимых вещей.

 

стг уже плохо масштабируется, я помню в 2005 году еще на с++ под него что-то писал, но кардинально все осталось тем же.

ребята были первые, кто сделал простой и работаюший биллинг с inetaccess и sgconfig нативными приложениями под винду :)

 

работать напрямую с сервером бд не очень хорошая практика.

удобней и правильней иметь какой-то API для работы с биллингом, популярней и гибче HTTP - для биллинга сложно придумать.

это дает возможность интеграции с огромным количеством других компонентов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
20 минут назад, pavlabor сказал:

Первое, есть ли такая практика?

Второе, какая база данных?

1) Есть. Для начала сеть пейджинговой связи (древность). Во вторых сеть АЗС ... (торговля). В третьих сеть удаленных "юридических  консультаций", потом сеть торговых точек (вообще разное), и т.д. Пока не занялся провайдингом ...

2) Firebird (ака Interbase и её клоны) http://www.ibase.ru/ (Но это скорее моё личное предпочтение)

 

ЗЫ: А вообще-то пофиг на чем писать, для начала нужно выкристализовать структуру, концепцию ...

Изменено пользователем Stroj

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Цитата

ЗЫ: А вообще-то пофиг на чем писать, для начала нужно выкристализовать структуру, концепцию ...

скачать

http://ab.kh.ua/books/Vigers Karl - Razrabotka Trebovany K Programmnomu obespecheniu.pdf

 

описание

https://balka-book.com/razrabotka_programnogo_obespecheniya-366/razrabotka_trebovaniy_k_programmnomu_obespecheniyu_izdanie_trete_dopolnennoe-25248

 

я уже павлабору рекомендовал ее

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
12 минут назад, Stroj сказал:

2) Firebird (ака Interbase и её клоны) http://www.ibase.ru/ (Но это скорее моё личное предпочтение)

https://db-engines.com/en/system/Firebird;PostgreSQL

вот здесь можно сравнивать движки.

 

FB был не плох в свое время, но есть нюансы, связанный даже не с внутренней реализацией СУБД, а с ее поддержкой современными фреймворками.

безусловно можно делать все руками, но это время, деньги, баги, нервы... 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

  • Похожие публикации

    • Автор: Woods
      Здравствуйте, ситуация такова. Нужно замутить такую схему:
       
      При балансе равным нулю, чтобы доступ к учетке на ubilling блокировался и перенаправлял на внешний сайт с оплатой.
      Или же при ситуации, если аккаунта у пользователя нет, так же доступа к ubilling не предоставлялся, а происходило перенаправление на внешний сайт с оплатой. (регистрацией аккаунта в системе биллинг).
      Метод использования Хот-спот.
       
      P.S. тапками прошу не кидаться, новичок.
    • Автор: felixio_01
      День добрый! Использую Ubilling+stargazer. Переходить на другой биллинг нет желания (но, возможно, придётся). 
      Нахожусь в Крыму (прошу без политоты). В связи с этим необходимо внедрять в сеть СОРМ3, также делать выгрузку данных с биллинга. 
      Есть ли у кого реальный опыт интеграции СОРМ3 и Ubilling?
      Может быть кто-то может взяться (естественно не бесплатно) за написания модуля/скриптов для осуществления выгрузки данных на оборудование СОРМ3. Необходимая техдокументация имеется. 
      Прошу только конструктивный диалог.
    • Автор: camchatix
      Добрый день
       
      Имеется работающий ubilling 0.8.8 rev 6006
      ponizator + бдком + opt82 - все работает
      Подключил zte c300, добавил в разделе свич оборудование с описание ОЛТ (снмп шаблон выбрал zte 320 ГПОН)
      айпишка пингуется с биллинга
       
      на ЗТЕ есть работающие 3 онушки но при опросе олт - в понизаторе, в списке неизвестных ону нету ону с ЗТЕ.. только с бдком
      с билинга запустил snmpwalk на zte - посыпались данные
       
      дальше поковырялся и в папке billing/exports вижу файлы с опросами ОЛТ
      так вот файлы от бдкома вижу 5 штук (distance, fdb, signals, onuindex, onuinterface) 
      а вот от zte c300 только один IDOLT_OLTSIGNALS (посмотрел что внутри а там все верно - 3 онушки и ихние сигналы)
       
      но в понизаторе в таблице zte c300 пусто
      такое ощущение что в файле snmp не правильные MIBs указаны
       
      поделитесь инфо, или шаблоном snmp
      версия firmware zte c300 1.2.5
    • Автор: pavlabor
      Вопрос дополнения базы данных и биллинга таблицей "все-ко-всем", продиктованы следующими потребностями.
      Есть модуль "Филиалы".
      При подключении данного модуля возникает следующая проблема.
      Не возможно подключить например город или филиалы для филиала, потому как филиал получает доступ ко всей информации о других филиалах.
      Нужно создать условия при которых филиал сможет самостоятельно вносить пользователей, адреса, вести склад при этом не видя информацию в материнской базе и других филиалах.
      Далее филиал не может создавать филиал.
       
      Такие задачи решаются созданием таблицы "все-ко-всем" в которой формируется каскадное вложение филиалов и связкой соответствующих таблиц сервисов.
      При правильном построении форм запроса и проверке на стороне сервера прав, филиал сможет получать доступ только к разрешенным ему модулям, и только его позициям в базе.
      Более того филиал сможет создавать свои филиалы, контролировать в них данные.
       
      Приветствуется любая критика и предложения,
      помощь в консультации и программировании.
      Спонсирование заинтересованных сторон, приветствуется.
    • Автор: pavlabor
      Права, введение расширенной настройки прав.
      Предлагаю рассмотреть формирование и в перспективе реализации расширения следующих прав.
      Имеется, структурированное управление правами, которое не совсем закрывает потребность.
      Имеется.
      Объекты.
      - Модуль.
      - Позиция в модуле, юнит.
      Юзатели.
      - Филиалы.
      - Администраторы.
      Администраторы.
      - Стажер(демо).
      - Специалист.
      - Эксперт.
      Действия.
      - Просмотр.
      - Создание.
      - Редактирование.
      - Удаление.
      Собственно идея в чем. В оператора, или при создании филиала, администраторам могут быть переданы права на работу с модулем.
      В текущий момент, не имеется сквозной политики на права, поэтому они предоставляются выборочно и не совсем понятно по какой системе, по все вероятности "так получилось", как следствие, например.
      При создании филиала и передачи ему права на роботу с модулем город, то админ филиала может удалить город, изменить название, что может привести к проблеме у других филиалах и материнской структуре.
      При реализации единой политики, появляется необсуждаемая возможность и требование к модулям по правам.
      В связи с этим, определенный модуль можно делегировать/не делегировать филиалу, с определенными ограничениями, например филиал может просматривать, вносить города, но не может их редактировать или удалять.
      Внутри филиала, появляется возможность создавать профили уровней сотрудников не беспокоясь о состоянии базы, например создаеются
      - Стажер(демо).
      - Специалист 3 категории.
      - Специалист 2 категории.
      - Специалист 1 категории.
      - Эксперт.
      Взяли на работу чела, дали ему уровень стажера и пусть листает базу пока не прозреет,
      прозрел, дается профиль Специалиста 3 категории, и т.д.
      То же самое и с филиалами.
      Как админ филиала может завести пользователя, а выносить мозг дирекции тоже не каширно, вот и даются оговоренные права что админ филиала пользователя может завести, но редактировать и удалять не может, если другое не оговорено.
       
      Параллельно возникает вопрос с пользователями другого филиала, но этот вопрос будет рассмотрен в разделе "Требуется внесение таблицы "все-ко-всем".
       
      Приветствуется любая критика и предложения,
      помощь в консультации и программировании.
      Спонсирование заинтересованных сторон, приветствуется.
       
×