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

[Max 0]

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

[Wapr-Old 0]

Так я бы может и поспорил, но не вижу с чем. Нет внятного описания Вашей модели. Может они нормальная, но я её не видел

[Max 0]

я пытался её вам описать но мы с вами даже в терминах расходимся.

[Wapr-Old 0]

Ну ладно, Вот моя последняя отчаяная папытка

[Max 0]

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

http://stg-tarif.narod.ru/back.jpg

Причём как видно там имеется возможность отключать БМ направления и БМ тарифа.

[Max 0]

И мне всё таки не понятно как мы можем использовать одновременно и БМ направления и БМ тарифа. Тоесть случай с DIR2.

Выражусь точнее: как этот тариф будет выглядеть на бумаге? Как данные ГБМ и ЛБМ могут друг с другом стыковаться (если у них цена например разная)?

[XoRe 0]

Как я понимаю, вы хотите в каждом тарифе иметь по отдельному числу БМ на каждое направление (DIR).

Для какого-то направления БМ давать, для кого-то не давать.

Плюс к этому иметь возможность дать БМ на весь трафик юзера.

Причем сначала снимается БМ направления, а потом БМ тарифа.

И так же БМ тарифа можно давать, можно не давать.

 

Имхо, реализовать можно, при условии что если СТГ будет заниматься какой-то конкретный кодер.

Тогда со стороны конфигов нужно убрать параметр FreeMb из conf-файла сервера (имхо, там он в этом случае уже не нужен).

И добавить его в файлы тарифов для каждого направления.

Типа dir1freemb=10

Можно даже ввести ещё параметр, определяющий, как считать БМ.

Как МБ или как деньги.

Ну например так же в тарифы добавить:

dir1type= mb или cash или none

 

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

Ну там... флаг "есть ли БМ", есть ли есть, то МБ или деньги и снимать это число, а не деньги со счета юзера.

 

Имхо, делать одно число БМ для одного направления во всех тарифах не стоит.

Лучше потыкать в тарифах и поставить самому.

[Max 0]

Имхо, реализовать можно, при условии что если СТГ будет заниматься какой-то конкретный кодер.

Так и есть, еть програмер который уже пишет. Вопрос только во времени и деньгах.

делать одно число БМ для одного направления во всех тарифах не стоит

Никто так делать и не хотел, хотели предусмотреть такую возможность.

[Wapr-Old 0]

Ну вот пошёл предметный разговор. Это приятно.

 

2 XoRe

Тогда со стороны конфигов

Конфиги как раз фигня, это самое простое и последнее в нашей проблеме.

Можно даже ввести ещё параметр, определяющий, как считать БМ.

Как МБ или как деньги.

А зачем БМ считать как деньги если они именно Бесплатные Мегабайты?

 

2 Max

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

Причём как видно там имеется возможность отключать БМ направления и БМ тарифа.

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

Поясню на примере среднего канала вашей схемы: есть 3 параметра управления - верхний вентиль, размер бачка и нижний вентиль. При указанном положении верхнего вентиля размер бачка никак не влияет на работу канала и => его можно принять = 0. При переключении верхнего вентиля и размере бачка = 0, работа канала никак не изменится => мы имеем один лишний элемент управления.

Если я чего-то не заметил, меня можно и нужно поправить

И мне всё таки не понятно как мы можем использовать одновременно и БМ направления и БМ тарифа. Тоесть случай с DIR2.

Честно? Не знаю! Но это неважно т.к. ничто не заставляет это делать. Но и не запрещает, что имхо важно.

Как данные ГБМ и ЛБМ могут друг с другом стыковаться (если у них цена например разная)?

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

Просто мы оба на своей счеме нарисовали неправильно, что внизу все сливается в одну трубу и потом считается, нет такого. С каждым направлением ассоциированы свои поля данных для рассчёта проходящего трафика, которые вступают в работу при исчерпании БМ.

[Max 0]

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

Поясню на примере среднего канала вашей схемы: есть 3 параметра управления - верхний вентиль, размер бачка и нижний вентиль. При указанном положении верхнего вентиля размер бачка никак не влияет на работу канала и => его можно принять = 0. При переключении верхнего вентиля и размере бачка = 0, работа канала никак не изменится => мы имеем один лишний элемент управления.

Если я чего-то не заметил, меня можно и нужно поправить

Я отталкивался от идеи с порогами в тарифах: есть галочка "без порога" - поле недоступно для редактирования, тут так же.

Честно? Не знаю! Но это неважно т.к. ничто не заставляет это делать. Но и не запрещает, что имхо важно.

Оригинально , ничего не скажешь.

[Wapr-Old 0]

Оригинально e.gif, ничего не скажешь.

Спасибо :tongue:

 

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

 

Я отталкивался от идеи с порогами в тарифах: есть галочка "без порога" - поле недоступно для редактирования

Ох не люблю я этот виндовозный принцип, когда элемент управления в гуях не соответствует его логической сущности :argh:

 

Мы говорим - Ленин, подразумеваем - партия, мы говорим - партия, подразумеваем - Ленин. (С) Короче всегда говорим одно, а подразумеваем совсем другое.

Відредаговано 2006-08-22 21:31:16 Wapr-Old

[Wapr-Old 0]

Фантазии...

 

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

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

 

Моё решение:

Делаю тариф с абонкой например 100р. и БМ 1000Мб. При этом говорю юзеру что тариф предоставляет право юзать хттп, почту, аську и игры и что что аська будет считаться отдельно.

 

В тарифе, в глобальных БМ пишу 900Мб. Это на главный канал.

 

Соответственно в ДИР0 попадает хттп, игры и прочая фигня. БМ0 поставлю = 0, значит трафик будет сразу расходовать БМ тарифа. Затем по цене направления 0.

 

Фильтрую почту на ДИР1 и кладу на БМ1 100Мб. Перерасход этих БМ приведёт к тому, что сначала начнут расходоваться БМ тарифа. (я ведь обещал дать 1000Мб в сумме) Затем по цене направления 1, а т.к. это другой канал, медленный, то и цену другую логично поставить, поменьше (типа пряник).

 

Фильтрую аську на ДИР2 и кладу на БМ2 например 10мб от щедрот (должно хватить для обычного общения). А чтобы файлы особо не гнали или если гонят, чтоб не расходовали БМ тарифа, присваиваю этим локальным БМ2 статус глобальных. Т.е. перерасход аськиного трафика будет приводить сразу к пересчёту в деньги по цене направления 2 (которое сделать поболее чем в ДИР1, типа кнут).

 

вот такие сумбурные мысли...

[Max 0]

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

 

обновлено! К20,К21,К22,К23,БC9,БК14,A4.

[Wapr-Old 0]

Future request: Можно ли сделать так, чтобы перед переводом юзера с тарифа на тариф, биллинг сначала его отключал принудительно, а затем подключал уже по новому тарифу?

 

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

Я ввёл несколько тарифов по образцу: anlim_50, anlim_70 и т.п. При этом число в имени тарифа используется при задании параметров netfilter для ограничения скорости. И всё вроде работает за исключением того, что перевод с тарифа на тариф тех, кто online, вызывает логическую ошибку скрипта, т.к. когда после перевода на новый тариф юзер отключается, iptables разумеется выдаёт ошибку удаления правила фильтрации. Ведь создавал он правило с другими параметрами.

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

[Max 0]

конечно можно, но я думаю данную фитчу нужно сделать опциональной.

С14

[Sonnar 0]

Кстати по безлимитным тарифам.

Было бы неплохо добавить два поля в тарифных планах rate-up и rate-down

и в них указывать скорость данного тарифного плана.

И если установить пользователю данный тарифный план то срабатывал скрипт addrate в который передаются параметры, rate-up, rate-down, login, ip а если меняю тариф на котором нет ограничения то срабатывет скрипт delrate.

Плюс ко всему, нужно что бы сервер проверял при смене тарифа, был ли до смены тариф с ограничением по скорости, и если был тариф с ограничением по скорости, то сначала выполнялся скрипт delrate с параметрами предидущего тарифного плана, а уж затем выполнялся скрипт addrate

с новыми параметрами.

И было бы совсем замечательно, если добавить три поля в настройки пользователя rate-up, rate-down если вдруг надо для какого нить пользователя, выставить ограничение по скорости в независимости от тарифного плана, а в третьем поле просто ставить галочку с названием "приоритет", это если вдруг у этого пользователя есть текущий тарифный план с ограничением по скорости а нужно что бы была скорость указаная в настройках пользователя.

[Sonnar 0]

Вот ещё не как не пойму, толи баг сервера или так задумано.

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

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

Можно ли как-то это исправить?

[Max 0]

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

Честно скажу не понял зачем галочка приоритет, поясните чётче.

Вот ещё не как не пойму, толи баг сервера или так задумано.

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

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

Можно ли как-то это исправить?

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

[Sonnar 0]

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

Честно скажу не понял зачем галочка приоритет, поясните чётче.

Вот ещё не как не пойму, толи баг сервера или так задумано.

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

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

Можно ли как-то это исправить?

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

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

 

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

 

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

 

 

 

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

[Wapr-Old 0]

2 Max Да, конечно опцией, т.к. надо только при привязке параметров нетфильтра к параметрам тарифа юзера. Мне вот впервые за более чем 3 года понадобилось

 

2 Sonnar По неудалению правил: давай зададимся вопросом - что более надёжно работает - netfilter+iptables или stargazer? Ответ имхо очевиден. Поэтому описанная ситуация может возникнуть только при ошибках в установке системы или сбоях в железе, а тогда как можно вообще это эксплуатировать?

С 2003 года у меня стоят простые правила добавления/удаления, без всяких циклических проверок и сбои такого рода возникли всего 1 раз именно при глюках сервера, повлёкших в результате его ремонт. С тех пор опять все нормально пашет.

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

[Max 0]

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

 

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

 

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

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

[Sonnar 0]

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

 

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

 

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

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

Да я так, для примера сказал что "Приоритет" а так пусть хоть "123" называется

[Sonnar 0]

2 Max Да, конечно опцией, т.к. надо только при привязке параметров нетфильтра к параметрам тарифа юзера. Мне вот впервые за более чем 3 года понадобилось

 

2 Sonnar По неудалению правил: давай зададимся вопросом - что более надёжно работает - netfilter+iptables или stargazer? Ответ имхо очевиден. Поэтому описанная ситуация может возникнуть только при ошибках в установке системы или сбоях в железе, а тогда как можно вообще это эксплуатировать?

С 2003 года у меня стоят простые правила добавления/удаления, без всяких циклических проверок и сбои такого рода возникли всего 1 раз именно при глюках сервера, повлёкших в результате его ремонт. С тех пор опять все нормально пашет.

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

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

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

[Wapr-Old 0]

пользователя кончились деньги и трафик, Интернет заблокировался, но почту из Интернета он всё равно может принимать.

Это можно реалиховать в скриптах управления файрволом

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

А это я бы делать не стал, т.к. если трафик может считаться в минус, его можно накачать сколько угодно и не заплатить потом. Проще кредит поставить... ВО! ИДЕЯ!! =:-/

future request: Если юзер перешёл к использованию кредита, он должен (при нахождении онлайн) периодически получать от сервера автоматические сообщения о необходимости его погашения. Например раз в час или около того. Например параметр CreditReminder=<кол-во секунд между повторами> если=0, не напоминать. Точнее напомнить 1 раз, при авторизации.

[Max 0]

future request: Если юзер перешёл к использованию кредита, он должен (при нахождении онлайн) периодически получать от сервера автоматические сообщения о необходимости его погашения. Например раз в час или около того. Например параметр CreditReminder=<кол-во секунд между повторами> если=0, не напоминать. Точнее напомнить 1 раз, при авторизации.

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

 

Обновлено ОБ6, ОБ7.