Альтернативное исправление багов и feature Request

[Max 0]

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

 

Я описываю недостатки версии сервера 2.0.16.7.6 и конфигуратора 1.60.7, но исправления будут вноситься исключительно в версию 2.4+

##################################################

Синим цветом выделены пункты которые находятся в обработке

Оранжевым цветом выделены пункты которые будут следующими

Зелёным цветом выделены пункты которые сделаны.

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

Пурпурным цветом выделено то что исправлено или сделано самими авторами

##################################################

 

Конфигуратор (К)

 

К1. При нажатии кнопки логин (или обновить) в окне где имя пользователя и пароль было ещё одно поле ввода: "Имя сервера", причём чтоб данное поле бралось из конфига, и при внесеении в него нового значения запоминалось, а потом выпадало со старыми вариатами ввода.

К2. В главном окне в низу таблицы хотелось бы видеть под полем:

а) Логин -> Количество логинов в системе

б) Баланс-> Сумму всего столбца баланс (отрицательные числа/положительные числа)

в) Статус-> Количество юзеров Онлайн

г) Upload-> Сумму по колонке

д) Download-> Сумму по колонке

К3.Правка->Редактировать пользователя:

а) около поля логин, хотелось бы видеть возможность преименования пользователя (тут надо будет править сервер СТГ-2.4)

==Проблема: Старгаейзер многопотоковая программа, и переименование пользователя требует перезапуска биллинга в целом дабы монополизировать изменения в имени пользователя (Разработка пока отложена, из-за не срочности и трудности)

б) пароль что звёздочками отображался а не плюсами (+)

в) хочу видекть кнопку обнуление трафика пользователя (С подтверждением операции!)(надо дописывать СТГ-2.4)

г)Сделать суммарный подсчёт трафика. (сумма внизу колонок)

д)В поле IP-адрес сделать так чтобы оно было изначално пустым и поддерживало ввод, но при этом было выпадающим, что бы можно было выбрать диапазон адресов, которые можно назначать клиентам. При добавлении нового юзера конфигуратор сам будет назначать свободный ай-пи.(изменение в конфиге)

е)сделать так что бы можно было редактировать размер окна пользователських настроек. Причём чтобы данный размер запоминался.

ж)БМ - см обсуждение ниже

з)хотелось бы иметь возможность редактирования названия полей: UserData0 и UserData1, как в конфигураторе так и в сервере (может брать данное поле с сервера?)

К4.Хотелось бы видеть в конфигураторе наверху пару кнопок: Стоп сервер (в смысле СТГ-2.4), Рестарт (релоад) сервера СТГ-2.4 и перечитывание правил подсчёта

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

К6. Инструменты->Отправить сообщение..:

а) Рассылку сообщения одновременно нескольким клиентам. Например, чтоб при выборе работал ctrl и shift в GUI конфигураторе.

К6. Инструменты->Отправить сообщение..:

а) Рассылку сообщения одновременно нескольким клиентам. Например, чтоб при выборе работал ctrl и shift в GUI конфигураторе. Более удачная реализация от авторов.

б) (БК8) Не рассылаются длинные сообщения (длиннее примерно 172 символов)! хотя программа рапортует, что сообщение успешно отправлено. (и зачем она тогда позволяет ввести сообщение длиннее этой величины?)

в) очень хочется поддержку шаблонов и регулярных выражений, и вообще такое же окно в целом (как у рассылки писем)

К7. Услуги (тоже устно раскажу, так как во первых ещё не доканца понял что хочу, и во вторых слижком сложно это).

К8.Сделать возможность сохранения сортировки таблицы по соответствующему полю (конфигуратор под Windows). По умолчанию при запуске конфигуратора идёт сортировка по алфавиту логина.

К9.

а)Перенести параметр Настройки>Настройки...>Раскраска>Кол-во знако в деньгах после запятой в закладку Интерфейс.

б) Пороги изменения цвета трафика невозможно изменить, что приводит к их бесполезности для подавляющего количества админов.

в) Строка с выделенным юзером закрашивается серым, т.е. все цвета отменяются. Надо сделать как раньше - цветную рамку по границе.

==Проблема: Отсутвие свежих исходников конфигуратора

К10. Отойти от модели один сервер (Хотя бы в конфигураторе и авторизаторе) То есть сделать выпадающие меню со списком доступных серверов (если их больше одного, список редактировать в конфиге конфигуратора). Тоесть поддерживать профайлы

К11. Вынести в отдельный файл шаблон формы создания нового пользователя в конфигураторе. Причина следующая при создании болше 20 пользоватлей начинает задалбываь набирать одно и то же. Тоесть галочку автозаполнение общих полей, (но это тоже наверное устно)

К12. В Инструменты-> фильтр пользователей хорошо бы, чтобы фильтровал пользователей и при рассылке сообщений. А то там при любом фильтре все юзеры показываются.

К13. Если в виндовом конфигураторе все столбцы не влезают в экран и имеется горизонтальная прокрутка, то при прокрутке вправо к последним столбцам и затем любом клике мышкой в таблице, всё прокручивается опять в крайнее левое положение. Приходится опять крутить вправо.

==Проблема: Похоже ошибка в библиотеках конфигуратора, пока отложено

К14. Если клиент установлен "Всегда онлайн", то в таблице невозможно отличить его от обычных клиентов, которые онлайн по авторизатору. Даже если он оффлайн в этот момент, т.к. отсутствие пинга ни о чём не говорит.

К15. Очень не помешала бы колонка "Договор" и быстрый поиск по ней.Реализовано разработчиками в виде изменения Любого поля UserData* Вообще прикольно бы было что бы конфигуратор умел искать по всем полям в данных юзера. иногда нужно найти или по телефону или по квартире. Было бы вообще мегакруто если бы с вводом символов в поиске - проводилась сортировка юзеров и несовпадающие пользователи сразу зафильтровывались и не выводились на экран.

К16. Иногда приходится изменять какой-нибудь параметр всем пользователям (или половине) вручную. Когда времени много и если я извращенец, то я буду тыкать и всё делать, но. Пожалейте админов, введите в конфигуратор опцию смены параметров юзеров в массовом порядке. Горячий пример: я захотел всем на счёт кинуть 100 рублей, или изменить параметр UserData1 на должник, или установить счётчик входящего локального трафика в 0. (Наверное в тему планировщика)

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

К18. Обновить интерфейс, делать более приятным глазу.

К19. Попробовать реализовать дизайн конфигуратора в стиле 1с 8.0 (имеется ввиду вид кнопок, формат шрифта, цвет полей, и надписей.

К20. При каких либо изменениях в настройках пользователя (статус,IP, и тд.) приходится обновлять данные в ручную, неплохо было бы если конфигуратор делал это сам после нажатия кнопки 'ОК' в настройках пользователя.

К21. Хотелось бы видеть в верхнем левом углу небольшую табличку содержащую: шапку статистики top. Активность сетевой подситсемы роутера.

К22. Было бы очень хорошо если бы поля запоминали то что в них вводили (как в IE строка запроса), но не всё подряд, а только одногрупные поля. Например если я ввёл у одного юзера в поле группа слово Абоненты, а другому юзеру я ввёл слово Администрация, то при создании нового юзера что бы можно было выбрать два этих слова, по мимо ввода нового.

К23. Было бы класно если бы в окне логина можно было бы установить иконку (logo) своей организации. А так же в самом конфигураторе в верхнем правом углу. Logo может быть http линком.

К24. Реализовать редактор скриптов On* и конфигов сервера с проверкой синтаксиса.

К25. Реализовать модуль выгрузки информации из БД (счета на основании которых можно создать акты выполненных работ, или акты выполненных работ на основании которых можно созадть счета) в 1с-v8.0

К26. реализовать обратную выгрузку платёжных поручений и приходных кассовых ордеров из 1с-v8.0 в старгеёзер, для того что бы средства поступившие в кассу или на р/с поступали и в биллинг, но тут есть одна сложность нужно писать обработку (на языке 1сv8.0) наши програмеры так не умеют, может кто то возьмётся? Формат XML

К27. Добавить в свойства пользователя галочку не пинговать.

 

##############################################################################

Теперь по поводу багов конфигуратора:

БК1. Если залогиниться к серверу, а потом нажать logout и попытаться залогиниться ко второму серверу, происходит бага, а именно вылазит окно с ошибкой:

заголовок окна: Айпи адрес сервера к которому пытаемся login ....::Stargazer:...

Тело окна:Access violation at address 0056871A in module 'Sgconfig.exe'. Write off address 00000001

БК2. Правка->Редактировать пользователя:

По моему не работает поле "запись в лог"

БК3. Настройки->Настройки..->Интерфейс: Устанавливается (но не сохраняется) галочка "Загружать последний шаблон".

БК4. Не правильная сортировка и исчезновение значка сортировки в шапке таблицы, при отключении столбца (Upload) отправлено.

БК5. Если нажать: Инструменты->Отчистить таблицу пользователей, а потом нажать обновить выпадает бага (кстати что самое что и БК1). Обсуждалось тут http://local.com.ua/forum/index.php?act=ST...st=0&do=findComment&comment=22794

==Проблема: Тоже что БК1

БК6.<\>

БК7. При посылке сообщения, в котором есть перевод строки, до клиента доходит только последняя строка. (вероятно это ошибка авторизатора)

БК8.</>

БК9. Проверить: sgconfig 1.60.7: в строке примечания почему-то находится e-mail.

==Проблема: отсутствие свежих исходников

БК10. Если установить название тарифа с пробелом, например: "Unlim 512", то при редактировании пользователя, поумолчанию в поле Тарифный план стоит пустое место, и приходится вручную ставить.

БК11. При внесении денег юзеру на счет если слишком быстро нажать несколько раз Enter то сумма может внестись более одного раза.

БК12. Иногда после добавления денег пользователю вылетает сообщение об ошибке: Access violation at address 044cd6da in module 'sgconfig.exe'. Read address 00000068

БК13. Иногда после добавления денег пользователю (после нажатия кнопки ок во всплывающем окне) вылетает сообщение об ошибке: Access violation at address 0001AA8. Read address 00001AA8

БК14. При установке таймаута кредита, если установить нужную дату, то флаг "без ограничений" не убирается. И действие по сути на смарку, так как очень часто забывашь снять данный флаг.

******************************************************************************

Сервер (С)

С1. Планировщик: Должна быть возможность создавать события, создать тип событий оповещение, и в данном событии создать возможность: отсылки сообщения клиенту в авторизатор (при подключении клиента)|мылом|смс : "Сумма на вашем счету меньше чем кредит. Пополните ваш счёт", сервер должен брать данный текст из шаблона.

С2. В систему логов -> В connect.log по мимо денег ещё очень бы хотелось выдеть суммарное количество входящего (одним числом) и исходящего трафика по всем направлениям за сессию. Только,что бы разные диапазоны IP для разных групп....

С3. Добавить в лог пользователя (детальный) (опционально через stargazer.conf) опцию при которой в детальную статистку пишется есчё и порт как src так и dst

С4. Чтобы можно было выбирать: снимать абонплату в конце месяца (за который снимается абонплата) или наперед. К примеру, заводится новый пользователь, и с него сразу снимается абонплата (кратная кол-ву дней до конца месяца) и добавляюся бесплатные метры (кратные снятой абонплате). Очень нужно!

С5. Хотелось бы просто иметь некоторые дополнительные цифровые параметры (3-4 штуки) на каждого пользователя, и стату дополнительную по направлениям, к примеру, скачано за 5 мин, скачано с начала часа, скачано с начала суток. Причём чтобы эти параметры могли передоваться в скрипты онконнет и ондисконнект.

С6. Писать в файле conf в виде Userdata0=param1,param2,param3

С7. Почему бы не разделить лог сервера (stargazer.log) на лог относящийся к пользователям и на лог относящийся к работе самого сервера, а то часто сообщение об ошибке теряется в тысячах запсей о конекте и дисконекте.

С8. Хотелось бы, чтобы обнуление статистики всех пользователей в определенный день было опционально (да/нет). А для полного счастья, чтобы эта дата была отдельной для каждого пользователя. Например. Если я хочу обнулять всех пользоватей в один день, то выбираю "да" и указываю дату. Если же я выбрал "нет", то эта дата (всмысле число) задавалась бы при создании клиента и потом была возможность ее поменять. Это связано с тем, что система учета у нас построена так, что у пользователей учетный период начинается с разных чисел месяца (день фактического подключения).

С9. сделать возможность, чтоб абоплата не снималась при отрицательном балансе. Отдельным параметром в конфиге.

С10. Если есть два канала в инет, а как следствие разные ip сети выданные провайдерами и как следствие разные политики ната, то очень не удобно писать все действия в одном скрипте onconnect. Просьба сделать такой параметр у пользователя как канал в виде cannel=1|2|3 и скрипты onconnect звать как onconnect.1|onconnect2

С11. Чтобы стг-2.4 дублировал файл stat (например в файл Stat.sav)

С12. Ввести в файл стат пользователя такой параметр (month_cash например) - как сумма денег насиженная (с учётом абонки и всех изменений по счёту пользователя) пользователем с начала месяца, который бы обнулялся в начале каждого месяца, очень удобно при экспорте в 1с если пользователь не является хроническим должником.

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

###########################################

Баги сервера:

БС1. Иногда, при больших нагрузках на сервер или просто при остановке демона СТГ затираются файлы со статистикой пользователя.

БС2. Проверить на актуальность:

При установка флага ЗАМОРОЖЕН не приводит к неснятию абон. оплаты в начале месяца.

БС3&БК6. Полная ерунда с Бесплатными МБ.! (Важно!)

БС4. Если у клиента накопилось несколько сообщений (messages) (пока он был оффлайн), сервер отдаёт из не в порядке создания а начиная с последнего.

БС5. Обнаружена жутко неприятная фича под ОС: FreeBSD.

При удалении/создании пользователя происходит перестроение индексов, что приводит к следующей фишке: т.к. во FreeBSD добавление/удаление правил фаервола основывается на UserID то это приводит к тому что после отключения тех юзеров которые были онлайн на момент создания/удаления юзера их разрешающие правила из фаервола не удаляются.

БС6. Вместе с деньгами тратится еще предоплаченный трафик (Важно!).

Кстати вот ссылка на последние сырцы сервера: http://local.com.ua/?op=39&st=2&dwnld=1143205566

БС7. Если изменить на ходу тариф с предоплаченным трафиком, т.е. было 1Гб, стало 1.5Гб, но ни в авторизаторах ни в сервере это не отразилось. При превышении 1Гб начали сниматься деньги. Перезапуск сервера не помогает.

Создание нового тарифа - не выход, т.к. неудобно.

БС8. При смене рассчётного периода происходит неприятные моменты, а именно:

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

б) Абонплата снимается иногда не совсем верно.

в) Не устаналвливается вообще предоплаченный траффик. Счётчики сбрасываются, а бесплатные Мб нет

БС9. Если юзер отключается за неуплату, в файл юзер/log данные о сессии не пишутся!

БС10. Проверить в сырцах есть ли поддержка скриптов: OnUserAdd OnUserDell OnChange

БС11. Проверить на актуальность: не обнуляются счётчики трафика за месяц, при смене расчётного периода.

БС12. Проверить на актуальность: если есть пользователь которий всегда online и ему поменять ІР, потом обновить, то пользователю с новим ІР запрещено ходить в инет а старому ІР можна, нужно снимать постоянно в онлайн ставить постоянно в онлайн тогда все гуд.

 

 

******************************************************************************

Авторизатор (А)

А1. При получении уведомления авторизатор не только выводит окошко с сообщением, но и сам вылезает из трея. А зачем?

А2. Если мне послано сообщение и я был offline, то при подключении я его не увижу, т.к. полученное сообщение исчезает с экрана вместе с уходящим в трей авторизатором. (легко его не заметить)

А3. Если я на автомате нажал кнопку OK на полученном сообщении, я больше его прочитать не смогу, т.к. оно нигде (ни у клиента, ни на сервере) не сохраняется.

А4. В инетакцессе если ввести пароль, поставить галку сохранить пароль и нажать подключиться, а потом закрыть крестиком авторизатор, то пароль не сохранится, он схраниься лиж тогда когда нажать кнопку отключиться! По мойму это плохо, почему бы не сохранять настройки при нажатии на кнопу ОК?

==Проблема: нет исходных кодов

 

Общее:

-- Общие пожелания --

ОБ1. При рассылке сообщений в них нет встроенной информации о времени создания. Это приводит к тому если я посылаю срочное уведомление, например о перезагрузке сервера или т.п., те клиенты, которые соединятся позже, получат ложную информацию. Решение имхо состоит из 3-х частей: 1) включить в пакет с сообщением системное время создания и пусть авторизатор его показывает, 2) В окошке создания сообщения добавить поле с временем жизни этого сообщения на сервере и 3) сервер при авторизации клиента и попытке послать ему сообщения из пула пусть проверит это поле.

ОБ2. Сделать снятие абонплаты опциональной. (Причём дублировать данный параметр как глобально так и локально на юзера)

ОБ3. Сделать то-же самое для пингования клиентов.

ОБ4. Ввести в конфиг тарифа параметр количество порогов, как временных так и мегабайтных.

ОБ5. Если у пользователя нет денег на счету (если меньше кредита), то сообщение отправленное ему не приходит к нему. (ВАЖНО!)

Если же денег добавить то после переподключения сообщение приходит.

ОБ6. Разработать модуль RADIUS протокола для СТГ-2.4 на основе сервера FreeRadius.

ОБ7. Разработать модуль MYSQL для хранения БД стг-2.4 в ней.

==Проблема: програмист всего один и сейчас занят

Відредаговано 2006-11-06 16:23:34 Max

[egor2fsys 5]

ок, данные баги и запросы фич приняты на рассмотрение

[Max 0]

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

[egor2fsys 5]

ну баги все равно нам ловить тоже.

 

так что список полезный

[zulu_Radist 856]

фух а я аж прям задалбался читать =)

[Max 0]

фух а я аж прям задалбался читать

Теперь програмер задолбается это исправлять :argh: !

[Wapr-Old 0]

Грандиозная коллекция багов Но забыто ещё как минимум два с расцветкой:

1. Пороги изменения цвета трафика невозможно изменить, что приводит к их бесполезности для подавляющего количества админов.

2. Строка с выделенным юзером закрашивается серым, т.е. все цвета отменяются. Надо сделать как раньше - цветную рамку по границе.

(Я об этом писал сразу после их появления)

[Max 0]

фенкс, учту.

[p0int 0]

по сути я расколупал как работает протокол обмена стж и виндового конфигуратора

написать новый с кучей функций не проблема работа 2-3 х дней

но имхно лень очень этим заниматься тем более что я считаю веб более удобным

[XoRe 0]

2p0int:

Ну сделай на веб)

 

А вообще если можно, хорошо бы заиметь сырцы конфигуратора)

 

От себя пару багов 2.4:

Трафик локальный может как глобальный посчитаться.

Не отсылаются сообщения.

Вроде все, что критично для меня)

[p0int 0]

уже давно сделал

через веб

----------------

и еще неудобная фича делаешь пользователя и не видишь сразу его пароль

а только когда редактируешь

[Max 0]

енто в ТЗ уже было указано

[Max 0]

1. Пороги изменения цвета трафика невозможно изменить, что приводит к их бесполезности для подавляющего количества админов.

2. Строка с выделенным юзером закрашивается серым, т.е. все цвета отменяются. Надо сделать как раньше - цветную рамку по границе.

Добавил.

[Max 0]

Обновлено!

[Wapr-Old 0]

ж) большое замечание по бесплатным мегабайтам, но это нужно устно расказывать, как описать буквами я не знаю

Я знаю как буквами :-(=)

1. Бесплатные мегабайты (БМ) должны быть!

2. Считаться они должны именно как мегабайты, а не как деньги.

3. БМ должны принадлежать не тарифу, а направлению.

4. Обнуление счётчика БМ в конце учётного периода должно быть опциональным и принадлежать направлению внутри тарифа, а не тарифу или тем более биллингу в целом.

5. Начисление БМ в начале учётного периода должно быть связано с проверкой счёта юзера на положительность.

6. Если в данном конкретном направлении БМ не предусмотрены, но начислены, ничего с ними делать не надо. Пусть остаются и расходуются по общим правилам направления.

7. (если подумаю - ещё допишу)

 

Т.е. никакой интеллектуальной обработки умолчаний, никаких пересчётов одного в другое, и т.п.

 

Мои мысли:

Пункт С1 можно реализовать и скриптом OnConnect при наличии КК, тем более, что в нём проверки более гибко реализовать можно.

[Max 0]

Обновлено!

 

 

Wapr-Old Спасибо за участие.

БМ должны принадлежать не тарифу, а направлению.

Во первых поправлю вас: БМ должны принадлежать не тарифу, а направлению в тарифе.

Не совсем согласен с вами, бывают ситуации когда например есть пять направлений и у всех у них одинаковая стоимость (5 взяты для удобства и детализации например: www,mail,icq,other) мне бы было удобно задать глобально несколько БМ чем задавать для каждого направления в отдельности.

Потом встаёт другой вопрос. Всё таже ситуация с 5 направлениями и одной стоимотью, если делать БМ на каждое направление отдельно, то сколько я должен установить БМ на каждое направление?

Выход из ситации и достижении гибкости я вижу в опциональности привязки (через конфиг) БМ как к тарифу так и к направлению тарифа.

Пункт С1 можно реализовать и скриптом OnConnect при наличии КК, тем более, что в нём проверки более гибко реализовать можно.

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

[Wapr-Old 0]

Не совсем согласен с вами, бывают ситуации когда например есть пять направлений и у всех у них одинаковая стоимость (5 взяты для удобства и детализации например: www,mail,icq,other) мне бы было удобно задать глобально несколько БМ чем задавать для каждого направления в отдельности.

Не понял. Честно. Как можно задать глобально и несколько?

 

Потом встаёт другой вопрос. Всё таже ситуация с 5 направлениями и одной стоимотью, если делать БМ на каждое направление отдельно, то сколько я должен установить БМ на каждое направление?

Выход из ситации и достижении гибкости я вижу в опциональности привязки (через конфиг) БМ как к тарифу так и к направлению тарифа.

Тоже как то не вполне врубился...

 

В общем есть преложение, подкупающее своей простотой. -)

Всё решается путём ещё большего упрощения алгоритма. Что мы имеем по структуре объектов? Базовая единица - объект "направление", от него порождаются объекты "тариф", от которого объект "биллинг". Т.е. надо породить одно из другого и в базовом объекте заложить поле БМ. Тогда БМ будет в всех объектах, а метод, вычитающий трафик из поля БМ будет просто передавать наверх остаток трафика, который образовался при обнулении счётчика БМ объекта. Пока поле БМ не обнулится, наверх ничего не уходит. Родительский метод сделает тоже самое и остаток передаст ещё выше, в объект "биллинг" и уже там с этим остатком произведут рассчёты как с денежной величиной, хотя не исключаю возможности, что будет также ещё один уровень, содержащий всё перечисленное, но в приложении к каналам.

 

Теперь тоже самое, но человеческим языком :-(=)

Поле БМ содержится и в тарифе (как есть сейчас) и в направлении тарифа. При потреблении трафика сначала расходуется БМ направления (например icq), а при обнулении начинают расходоваться БМ тарифа. Как только БМ тарифа стали = 0, начинают списываться деньги со счёта.

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

[Max 0]

Не понял. Честно. Как можно задать глобально и несколько?

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

Тоже как то не вполне врубился...

Блин, ладно опять...

Есть три направления: а б с и 100БМ

Тут возможны два варианта:

1) задать 100БМ глобально на весь тариф.

2) локально на а 100БМ/кол-во_направлений, на б 100БМ/кол-во_направлений, на с 100БМ/кол-во_направлений.

Вот пункт 2 меня и смущает. как определить эту формулу?

 

В поле БМ содержится и в тарифе (как есть сейчас) и в направлении тарифа.

В направлении тарифа БМ нет...

 

Поле БМ содержится и в тарифе (как есть сейчас) и в направлении тарифа. При потреблении трафика сначала расходуется БМ направления (например icq), а при обнулении начинают расходоваться БМ тарифа. Как только БМ тарифа стали = 0, начинают списываться деньги со счёта.

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

Поймите бывают ситуации когда есть например 100БМ на ВСЕ НАПРАВЛЕНИЯ ВМЕСТЕ, а НАПРАВЛЕНИЯ есть нечто иное как детализация трафика или они имеют одну цену.

 

Я предлагаю немного переделать вашу структуру (языком объектов):

Формат: объект|Опции|Действия

Биллинг|

_______Тариф|Опция глобальные_БМ*|Отключение опции_локальные_БМ

_____________Направления|Опция_локальные_БМ|Отдельное_вычисление_БМ_по каждому_направлению

 

Опция_глоюбальные_БМ* - эта опция отвечает за то чтобы БМ были одной цыфрой на весь тариф (на все направления)

Опция_локальные_БМ - эта опция отвечает за то чтобы БМ были одной цыфрой на каждое направление в отдельности

Билинг - Списание_денег_происходит_только_когда_закончились_БМ (либо глобальные либо по направлению в отдельности)

Відредаговано 2006-08-15 14:53:48 Max

[Max 0]

ну баги все равно нам ловить тоже.

 

так что список полезный

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

[Wapr-Old 0]

В направлении тарифа БМ нет...

Я заметил

Я предлагаю немного переделать вашу структуру (языком объектов):

Формат: объект|Опции|Действия

Биллинг|

_______Тариф|Опция глобальные_БМ*|Отключение опции_локальные_БМ

_____________Направления|Опция_локальные_БМ|Отдельное_вычисление_БМ_по каждому_направлению

 

Опция_глоюбальные_БМ* - эта опция отвечает за то чтобы БМ были одной цыфрой на весь тариф (на все направления)

Опция_локальные_БМ - эта опция отвечает за то чтобы БМ были одной цыфрой на каждое направление в отдельности

Билинг - Списание_денег_происходит_только_когда_закончились_БМ (либо глобальные либо по направлению в отдельности)

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

Почему наличие глобальных БМ должно отключать локальные БМ? И если хочется реализовать подобную логику, по моей системе достаточно не задавать локальные БМ. Результат будет аналогичный.

Единственный вариант, который у меня не реализуется, такой: есть 3 направления А Б В. Направление А - суть отдельный канал, а Б и В - другой канал, но например http и ftp. И мы хотим, чтобы при наличии глобальных БМ и всех локальных БМ, при окончании БМ из направления А глобальные БМ не списывались, а сразу списывались деньги. А по окончании БМ из Б и В - списывались глобальные БМ тарифа, которые тоже установлены.

Хотя в общем и эта извращённая схема реализуема введением в локальных БМ флага, переводящего их в режим глобального. Т.е. видится такая иерархия:

Биллинг|

_______БМ биллинга;

_______Методы учёта трафика

_______Тариф1|

______________БМ (глобальные)

______________Метод распределения БМ по напр. (делегирование)

______________Флаг глобальности БМ

______________Методы учёта трафика

______________Направление1|

_____________________БМ1 (локальные)

_____________________Флаг глобальности БМ

_____________________Правила направления 1

_____________________Методы учёта трафика

______________Направление2|

_____________________БМ2

_____________________Флаг глобальности БМ2

_____________________Правила направления 2

_____________________Методы учёта трафика

...

[Max 0]

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

Не согласен, мне всё равно не понятно как эта схема может работать?

Приведите живой пример.

 

Почему наличие глобальных БМ должно отключать локальные БМ?

А смыл в локальных когда есть глобальные, мы с вами опять вернулись банальной ситуации:

Есть тариф Эконом, например, с абонентской платой в 80руб в неё входит 25 МБ всё свыше отдаётся по 3 рубля, направлений 8.

Внимание вопрос: Как вы тогда поделите эти 25 метров на каждое направление? Равномерно разделите 25 на на 8 - не выход. А если пользователь хочет все 25 на 1 первое направление? а не 25/8. Выход один - задать глобально на тариф эти 25 МБ. А отключение Локальных БМ (тарифа) - это так как смысл в данной ситуации в БМ на направдление отсутсвует, и во-вторых это просто защита от дурака, что потом нам всем новички мозг не е..ли с банальной проблеймой когда БМ указаны как глобально на тариф, так и локально на направление. Поправьте если не прав.

 

И мы хотим, чтобы при наличии глобальных БМ и всех локальных БМ

Я так и не понял чего мы хотим.

 

есть 3 направления А Б В. Направление А - суть отдельный канал, а Б и В - другой канал, но например http и ftp. И мы хотим, чтобы при наличии глобальных БМ и всех локальных БМ, при окончании БМ из направления А глобальные БМ не списывались, а сразу списывались деньги. А по окончании БМ из Б и В - списывались глобальные БМ тарифа, которые тоже установлены.

Что то я не въехал в вашу ситуацию.

Биллинг|

_______БМ биллинга;

_______Методы учёта трафика

Какие могут быть БМ у биллинга? Над тарифами? А смысл?

 

_______Тариф1|

______________БМ (глобальные)

______________Метод распределения БМ по напр. (делегирование)

______________Флаг глобальности БМ

______________Методы учёта трафика

тут я с вами согласен, но мне непонятна опция Флаг распределения БМ (делегирование), смысл в этой опции когда БМ и так глобальны на тариф?

______________Направление1|

_____________________БМ1 (локальные)

_____________________Флаг глобальности БМ

_____________________Правила направления 1

_____________________Методы учёта трафика

______________Направление2|

_____________________БМ2

_____________________Флаг глобальности БМ2

_____________________Правила направления 2

_____________________Методы учёта трафика

Тут тоже согласен, только что такое Флаг глобальности БМ и Флаг глобальности БМ2? они ведь уже локальными считаются, разве нет?

[Wapr-Old 0]

Ладно, попытаюсь объяснить моё видение процесса (но писанины будет много).

 

Умолчания:

1. Под направлениями биллинга я понимаю именно то, что забито в биллинге. Т.е. совокупность правил фильтрации пакетов. Всё.

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

3. Когда я говорю о направлении, я всегда говорю о п.2

 

Теперь ответы:

Есть тариф Эконом, например, с абонентской платой в 80руб в неё входит 25 МБ всё свыше отдаётся по 3 рубля, направлений 8.

Внимание вопрос: Как вы тогда поделите эти 25 метров на каждое направление? Равномерно разделите 25 на на 8 - не выход. А если пользователь хочет все 25 на 1 первое направление? а не 25/8. Выход один - задать глобально на тариф эти 25 МБ.

а. В данном случае я не буду делить ничего. Просто при создании тарифа "Эконом" будет указано, что его абонплата=80руб. , а на направлении 1 имеется 25Мб БМ. Это всё записано в определении тарифа, которое будет применяться ко всем клиентам под этим тарифом.

б. Если мы захотим поделить 25 на части, мы создадим тариф "Эконом изврат" и в нём на 1м напрвлении будет 15Мб, на втором 10Мб, а на 3-ем и остальных - 0Мб. Тогда трафик по 3..8 напрвлениям будет сразу переводиться в деньги и считаться.

в. Теперь создадим тариф "Эконом экстра изврат" в котором на 1-м напдавлении будет 10Мб, на 2-м тоже 10Мб, а дальше интересно: осталось 5Мб, которые надо как-то распределить по оставшимся 6-и напрвлениям. Делить на части? Вот это точно экстра изврат. Поэтому мы эти 5Мб кладём на БМ тарифа в целом и теперь направления 3..8 берут БМ из общего пула тарифа пока он не кончится.

г. Ок. А теперь сделаем тариф "Эконом мега изврат". Сделаем его на базе тарифа "Эконом экстра изврат" для простоты. Итак можно заметить, что в "эстре" БМ тарифа могут расходоваться не только направлениями 3..8, но и 1..2 как только их БМ обнулятся. Чтобы этого избежать и дать клиенту гарантированные БМ для направлений 3..8, на направлениях 1..2 поставим флаг "Глобальные БМ". Всё! Теперь 5Мб могут быть израсходованы только с напрвлений 3..8.

д. Ну и наконец рассмотрим ситуацию, когда среди направлений 3..8 есть некоторые, например 6 и 7, на которых вообще не должно быть БМ. Ни при каких условия. На базе тарифа "Эконом мега изврат" сделаем тариф "Эконом супермега изврат". Для этого просто на направлениях 6 и 7 (в которых БМ=0, а они таковы во всех напрвлениях 3..8) поставим галку "Глобальные БМ". Вуаля! Теперь весь трафик по этим 2-м напрвлениям будет считаться как деньги, независимо от БМ тарифа или БМ других напрвлений.

 

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

мне непонятна опция Флаг распределения БМ (делегирование), смысл в этой опции когда БМ и так глобальны на тариф?

Это не флаг, это метод, т.е. процедура задания БМ методом "обратного давления". Может понадобиться в случае, когда глобальные БМ нефиксированы и надо их распределить по тарифам и направлениям сверху вниз.

Какие могут быть БМ у биллинга? Над тарифами? А смысл?

Ну мало ли... например я покупаю не анлимный канал у провайдера, а допустим 20Гб. При этом неизрасходованный трафик переносится на след. месяц. Как его распределить? (См. про "обратное давление")

 

Дисклаймер: везде вместо напрвлений надо понимать направления :-/

Відредаговано 2006-08-18 15:10:09 Wapr-Old

[Max 0]

Умолчания:

1. Под направлениями биллинга я понимаю именно то, что забито в биллинге. Т.е. совокупность правил фильтрации пакетов. Всё.

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

3. Когда я говорю о направлении, я всегда говорю о п.2

Блин, не я так не могу, честно говоря я не въехал, в то как вы всё называете.

Может всётаки привязяться к билингу?

Что тариф это - тариф

Направление - это какой-то DIR

?

далее

 

а. В данном случае я не буду делить ничего. Просто при создании тарифа "Эконом" будет указано, что его абонплата=80руб. , а на направлении 1 имеется 25Мб БМ. Это всё записано в определении тарифа, которое будет применяться ко всем клиентам под этим тарифом.

Не правильно, а если пользователь хочет все 25 метров на второе направление тарифа?

 

б. Если мы захотим поделить 25 на части, мы создадим тариф "Эконом изврат" и в нём на 1м напрвлении будет 15Мб, на втором 10Мб, а на 3-ем и остальных - 0Мб. Тогда трафик по 3..8 напрвлениям будет сразу переводиться в деньги и считаться.

в. Теперь создадим тариф "Эконом экстра изврат" в котором на 1-м напдавлении будет 10Мб, на 2-м тоже 10Мб, а дальше интересно: осталось 5Мб, которые надо как-то распределить по оставшимся 6-и напрвлениям. Делить на части? Вот это точно экстра изврат. Поэтому мы эти 5Мб кладём на БМ тарифа в целом и теперь направления 3..8 берут БМ из общего пула тарифа пока он не кончится.

г. Ок. А теперь сделаем тариф "Эконом мега изврат". Сделаем его на базе тарифа "Эконом экстра изврат" для простоты. Итак можно заметить, что в "эстре" БМ тарифа могут расходоваться не только направлениями 3..8, но и 1..2 как только их БМ обнулятся. Чтобы этого избежать и дать клиенту гарантированные БМ для направлений 3..8, на направлениях 1..2 поставим флаг "Глобальные БМ". Всё! Теперь 5Мб могут быть израсходованы только с напрвлений 3..8.

д. Ну и наконец рассмотрим ситуацию, когда среди направлений 3..8 есть некоторые, например 6 и 7, на которых вообще не должно быть БМ. Ни при каких условия. На базе тарифа "Эконом мега изврат" сделаем тариф "Эконом супермега изврат". Для этого просто на направлениях 6 и 7 (в которых БМ=0, а они таковы во всех напрвлениях 3..8) поставим галку "Глобальные БМ". Вуаля! Теперь весь трафик по этим 2-м напрвлениям будет считаться как деньги, независимо от БМ тарифа или БМ других напрвлений.

 

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

Блин, я всё равно никак не могу понять зачем городить эти извраты? когда приведённая выше схема решает все эти проблемы путём установки одной - двух галочек?

Где тут гибкость? По моему это не гибкость, а надругательство над админом . В принципе настоящая гибкость достигается путём внедрения скриптового языка описания тарифа.

[Max 0]

я скоро постараюсь выложить алгоритм работы моей схемы в блок схеме. Может тогда мы поймём друг друга.

[Wapr-Old 0]

далее

 

 

а. В данном случае я не буду делить ничего. Просто при создании тарифа "Эконом" будет указано, что его абонплата=80руб. , а на направлении 1 имеется 25Мб БМ. Это всё записано в определении тарифа, которое будет применяться ко всем клиентам под этим тарифом.

 

Не правильно, а если пользователь хочет все 25 метров на второе направление тарифа?

а чуть ранее...

А если пользователь хочет все 25 на 1 первое направление? а не 25/8. Выход один - задать глобально на тариф эти 25 МБ.

Вы там как нибудь договоритесь между собой, чего же он все таки хочет :argh: Я отвечал на поставленный вопрос, а не на подразумеваемый.

Если он хочет просто 25 на все направления оптом, то это тривиальный случай, реализованный в текущем биллинге. Не понимаю, зачем тогда напрягать программера?

В принципе настоящая гибкость достигается путём внедрения скриптового языка описания тарифа.

Это да, но если так сделать, мало кто сумеет заюзать полученную гибкость. Ибо не все тут программисты.

Блин, не я так не могу, честно говоря я не въехал, в то как вы всё называете.

Может всётаки привязяться к билингу?

Что тариф это - тариф

Направление - это какой-то DIR

Так рассуждать неправильно, т.к. понятие "тариф" в существующей версии отличается от того, о чём мы говорим. А понятие "направление" вообще имеет 2 смысла даже сейчас: 1. DIR в считалке трафика и 2. Направление как часть тарифа, т.е. с привязкой ко времени, к ценам, к DIR и т.д. Утверждать, что это одно и тоже - неверно и даже вредно, т.к. в общем случае эти понятия между собой могут быть и не связаны. Думаю Ваш программист это понимает.