Биллинговая система Nodeny
22 Ноября 2024, 23:55:20 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
Новости: Прекращена поддержка версии Nodeny 49
 
   Начало   Помощь Поиск Войти Регистрация  
Страниц: [1]
  Печать  
Автор Тема: Анатомия NoDeny+  (Прочитано 8826 раз)
Efendy
Администратор
Спец
*****

Карма: 138
Offline Offline

Сообщений: 4790



Просмотр профиля
« : 26 Сентября 2012, 08:36:34 »

Не в порядке важности, а как приходит в голову, неструктурно буду постепенно описывать отличия внутренностей NoDeny+ и NoDeny50


  • Дополнительные поля. В N50 каждое поле абонента хранилось в отдельной строке таблицы БД. Т.е. чтобы получить все поля, нужно было прочитать несколько строк. Это было сделано для гибкости - можно было хранить любое количество полей т.к. количество строк на абонента никто не ограничивал.

    В N+ я решил поступить в соответствии с классическим подходом: каждое поле - это отдельный столбец. Должна увеличиться скорость доступа к данным т.к. чтобы получить все данные абонента, достаточно прочитать одну строку. Правда появилась мизерная, но вероятность того, что при изменении структуры полей в случае ошибки, будет структура, требующая вмешательства админа, поскольку ALTER TABLE не может выполнится в транзакции.

    Значения дополнительных полей хранятся в таблице data0. Я думал для каждого пресета сделать отдельную таблицу (data1, data2 ...), но потом передумал.

    Сами поля описываются в  таблице datasetup (в N50 эквивалент dopfields).

    Ревизий нет. В N+ практически все изменения упаковываются в хеш и сохраняются в pays. Это называется серилизацией. В моем случае, получается dump хеша в ввиде perl-кода. Если нужно расшифровать дамп: eval $dump;

  • таблица dictionary - словарь, ключ = значение. В N50 выпадающий список был только у поля "улицы", сейчас прямо из админки можно сделать на что угодно, хоть выпадающий список "курит/пьет/развратничает", достаточно сказать, что поле связано со словарем таким-то (поле type)

  • Практически все таблицы стали транзакционными. Чтобы понять как работать с транзакциями, гляньте web/user/cards.pl - все элементарно просто.

  • Из таблицы users улетели многие поля. Алиасов нет. На клиента можно навесить ip, связав запись в таблице ip_pool с конкретным клиентом. Т.е. клиенту можно присвоить ip только если он есть в таблице ip_pool. Т.е. заранее необходимо нагенерить (это просто из админки) списки ip, которые будут юзаться.

    Если клиенту не присвоить ip, то он будет присвоен в момент pppoe авторизации, после окончания сессии освобожден.

  • В таблице детализации трафика появилось поле uip - ip клиента, поскольку ip может меняться, можно узнать ip клиента на любое время.

    В некоторых таблицах с трафиком в N50 время отсчитывалось в секундах от начала суток, сейчас везде полный timestamp.

продолжение следует...
Записан
elite
Начальник планеты
NoDeny
Спец
*

Карма: 52
Offline Offline

Сообщений: 1226

In LAN we trust!

358714596
Просмотр профиля
« Ответ #1 : 26 Сентября 2012, 09:46:44 »

может в форме вики делать доку?
Записан
stix
NoDeny
Спец
*

Карма: 72
Offline Offline

Сообщений: 1872


Nodeny Support Team

205539
Просмотр профиля
« Ответ #2 : 26 Сентября 2012, 09:57:09 »

да, было бы очень хорошо.
и туда можно выложить было бы скрипты
Записан
Efendy
Администратор
Спец
*****

Карма: 138
Offline Offline

Сообщений: 4790



Просмотр профиля
« Ответ #3 : 26 Сентября 2012, 21:31:31 »

Продолжаем. Как работает ядро.

В N50 было ядро и были скрипты на сателлитах. В N+ ядро модульное, т.е. можно запускать все ядро или его части на разных серверах. Например, возможен такой вариант, что подсчет трафика будет на одном сервере, все остальные функции на другом. Все, кроме скрипта управления фаерволом (пока не переделал его), является модулем ядра. Т.е. чтобы обеспечить определенный функционал на сателлите, вам нужно запустить на нем копию ядра с нужными модулями, обычно вам понадобится только модуль сервер-авторизации, если вы юзаете авторизатор.

Ядро - скрипт nokernel.pl. Модули в папке kernel, файл cfg.pl - конфиг ядра в виде perl файла. Это чуть сложнее обычного текстового файла, но редактируется элементарно (меняются только параметры, а не структура), зато структура более гибкая. Если посмотрите cfg.pl, то увидите, что у каждого модуля есть параметр run - если установлен, то модуль запускается автоматом при запуске ядра. Иначе придется в командной строке указать конкретно этот модуль.

Ядро использует так называемые зеленые потоки - это не настоящая многопоточность, модуль выполняют мелкую задачу, потом передает управление другому модулю и т.д. Это похоже на ядро N50. Но есть одна существенная разница: можно запускать несколько ядер с комбинацией модулей.

В идеале на каждый модуль можно запустить отдельное ядро и все будет выполнятся строго параллельно в разных процессах. Но обычно это не требуется. Если же вы видите, что какой-то модуль подтупливает - его можно запустить отдельным процессом. Это же может понадобиться для задействования многоядерности.

Иногда я использую и настоящие потоки, например, опрос коллекторов трафика (не подсчет трафика, а именно опрос коллекторов). Однако, я стараюсь прибегать к этому в крайнем случае т.к. во-первых многопоточность трудна для понимания, увеличивается вероятность ошибки (надо лочить разделяемые ресурсы и т.д.), да еще есть проблема с утечками памяти в некоторых случаях.

Код:
perl nokernel.pl -v -m=system_check

запустит модуль system_check отдельным процессом в verbose режиме.

Код:
perl nokernel.pl -L

выведет список модулей и флаг запускаются ли они автоматом или нет

Код:
perl nokernel.pl -m=authserver -d &

запускает в режиме демона сервер обработки авторизаций от авторизатора.

Код:
perl nokernel.pl -d &

запуск всех модулей, у которых run=1

может в форме вики делать доку?
Если бы кто-то занялся этим, я один все не могу
Записан
Efendy
Администратор
Спец
*****

Карма: 138
Offline Offline

Сообщений: 4790



Просмотр профиля
« Ответ #4 : 04 Ноября 2012, 14:13:36 »

Ajax.

При нажатии на гиперссылку (также сабмит формы) текущая страница идет в небытие и загружается новая. Ajax позволяет получать данные не перезагружая страницу.

В N+, если у гиперссылки стоит класс ajax - она автоматически становится аяксовой:

<a href='?a=ajCool' class='ajax'>Кликай</a>

Кстати, в N+ в модулях теперь очень редко встречается html-код, поэтому лучше юзать немного ООП (на самом деле вам даже не надо знать, что это ооп, копипаста будет рулить):

url->a('Кликай', a=>'ajCool', -class=>'ajax');

Для удобства я пишу так:

url->a('Кликай', a=>'ajCool', -ajax=>1);

т.к. параметр ajax автоматом будет приводить к тому, что к ссылке добавится класс ajax.

При нажатии на аяксовую ссылочку, js на ее месте нарисует анимационный кружочек (типа "ждите..."), а в фоне отправит запрос на сервер.

Ajax  и не  ajax для сервера почти ничем не отличаются, только лишь тем в какой форме будет выдан результат. Неаяксовый запрос вернет просто html-страничку.

Не в N+ аяксовые запросы могут вернуть что угодно - тут стандарта нет, обычно в каждом проекте они возвращают в каком-то своем формате, а то и в разном на разных страницах. В  N+  формат возврата всегда един - это JSON (можете даже не смареть что это такое поначалу, в N+  можно программить и без этих знаний). JSON  - это типа XML, только в формате javascript.

В N+ в JSON  реализован _очень_ маленький язык: он говорит "я прислал данные такого-то типа и их нужно всунуть туда-то". На самом деле там на пару команд больше, но пока неважно.

Вы можете посмотреть на код любого ajXxx.pl файла и увидеть, что ответ пишется в массив в виде простейших команд:

data => 'Olala',
id => 'b12'

Данная команда говорит: выведи текст "Olala" в html-объект с id='b12'

Практически в 90% случаев вся работа сводится к такой цепочке: вы нажимаете на ajax-ссылку, идет запрос на сервер, формируются данные, запихиваются в json и отправляются клиенту.На клиенте js всовывает эти данные в нужное место.

Очень просто выводить всплывающие (модальные окна) - достаточно послать что-то в объект с id='modal_window' и оно отобразится автоматически.

Если у ajax-ссылки класс равен autosubmit - она засабмитится автоматически после загрузки страницы.

Есть такая вещь как триггеры. Представьте, вы сабмитите аякс-форму пополнения счета клиента, счет пополнен, в нужное место страницы написало "ок", но страница не перезагружена (типо так и задумано). А, скажем, в какой-то части страницы отображается баланс клиента, который после пополнения уже не актуальный. Поэтому создан механизм триггеров: если модуль меняет баланс, он включает javascript триггер "изменился баланс" и все гиперссылки, реагирующие на данный триггер сабмитятся автоматически, т.е сабмитится кнопка "показать баланс"
Записан
stix
NoDeny
Спец
*

Карма: 72
Offline Offline

Сообщений: 1872


Nodeny Support Team

205539
Просмотр профиля
« Ответ #5 : 04 Ноября 2012, 14:22:26 »

кул, я так понимаю привел к MVC паттерну или его подобию?
Записан
VitalVas
NoDeny
Спец
*

Карма: 60
Offline Offline

Сообщений: 991



Просмотр профиля WWW
« Ответ #6 : 04 Ноября 2012, 14:36:58 »

кул, я так понимаю привел к MVC паттерну или его подобию?
да, и это очень круто
Записан
Efendy
Администратор
Спец
*****

Карма: 138
Offline Offline

Сообщений: 4790



Просмотр профиля
« Ответ #7 : 04 Ноября 2012, 16:32:45 »

кул, я так понимаю привел к MVC паттерну или его подобию?

Что-то есть от MVC. Но. Конкретно в случае NoDeny, я взвесил все за и против и пришел к выводу, что MVC будет нехилым оверхедом в плане как понимания, так в плане быстрого написания модулей. Движок заточен чисто под околобилинговые функции. Я имею ввиду, что номенклатура объектов в представлении (шаблонах) - мизерная. Логика шаблонов - тоже мизерная. Они используются, но в очень малом количестве, фактически только для основных блоков. Суть админки нодени - посчитать данные и вывалить в поток. Этот поток практически аналог консоли. Вернее трех консолей: левая, правая, центральная. Никакой особой логики/дизайна и т.д. дополнительно не требуется, оно и так отлично выглядит как вы видите.

Т.е. представление наполовину-таки формируется в коде, но исключительно в calls.pm. С другой стороны, модули понимают куда они выводят данные и в какой последовательности, т.е небольшая логика отображения в них есть. Однако, я считаю это приемлемым.

Я вот сейчас работаю с чужим кодом, использующим MVC, и мне приходится прилагать много усилий чтоб понять где что находится. Т.е. в N+ я попытался балансировать и придумал что-то свое. Но зато гораздо лучше NoDeny 50, где в коде полная смесь html и логики
Записан
stix
NoDeny
Спец
*

Карма: 72
Offline Offline

Сообщений: 1872


Nodeny Support Team

205539
Просмотр профиля
« Ответ #8 : 04 Ноября 2012, 18:03:24 »

скажешь, когда в SVN будет обновлено финально.
буду параллельно к N+ привыкать
Записан
Efendy
Администратор
Спец
*****

Карма: 138
Offline Offline

Сообщений: 4790



Просмотр профиля
« Ответ #9 : 05 Ноября 2012, 10:12:26 »

скажешь, когда в SVN будет обновлено финально.
финального обновления не будет - буду развивать пока есть идеи
Записан
stix
NoDeny
Спец
*

Карма: 72
Offline Offline

Сообщений: 1872


Nodeny Support Team

205539
Просмотр профиля
« Ответ #10 : 05 Ноября 2012, 15:41:41 »

т.е. сейчас это есть в репозитории?
Записан
Efendy
Администратор
Спец
*****

Карма: 138
Offline Offline

Сообщений: 4790



Просмотр профиля
« Ответ #11 : 05 Ноября 2012, 17:11:54 »

т.е. сейчас это есть в репозитории?
более того, при каждом коммите я в комментариях пишу что добавил/изменил
Записан
Efendy
Администратор
Спец
*****

Карма: 138
Offline Offline

Сообщений: 4790



Просмотр профиля
« Ответ #12 : 18 Ноября 2012, 11:12:25 »

Закоммитил docs/develop/calls.pm.html с документацией на calls.pm. Пока там только хорошо описано как работать с таблицами. Дальше будет еще
Записан
Страниц: [1]
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.20 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!