Wapr-Old

В новой версии не нашлось места для механизма удаления неактуальных сообщений. Жаль. Будем подождать ещё...

Как обычно, я хочу предусмотреть всё :argh: Но на эту мысль меня навёл Ваш-же скриншот, на котором можно увидеть список с повторяющимися IP адресами. Очевидно, что порты при этом разные, но их в списке не видно. Всё, аллес капут На самом деле у меня была ситуация, когда я запускал 2 биллинга на одном сервере, правда с целью отладки, но всё равно не хочется из за ерунды, не предусмотренной сегодня, влететь на проблемы завтра

Щас будем вместе въезжать =) ИМХО в профайле каждая запись соответствует одному экземпляру биллинга, а по сути сокету TCP/IP, но в списке, который вываливается, не сокеты, а только хосты. И поскольку имён у записей видимо не предусмотрено, по этой информации опознать конкретный экземпляр биллинга в общем случае невозможно. Либо надо показывать в списке и порт (10.10.0.1:5895) либо предусмотреть имя и выводить его.

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

Можно

При первом же запуске 2 получается или только при запуске с предварительно упавшим предыдущим старгазером? Что-то попадает при этом в stgkrash.log? И замени ps awxu |grep stargazer|awk '{print $2;}' на ps ax |grep stargazer | cut -f1 -d" " Так ведь проще пид получить и быстрее. Зачем с awk связываться?

Думаю, что повремёнка в 2006 году - это из разряда патефона, если только Вы не имеете такого "продвинутого" провайдера := А галочка в авторизаторе это вообще на грани фола... почему бы тогда не дать там полный список тарифов и пусть юзер их переключает как хочет =)

Респект! По пункту С14: Сейчас пишу особоизвращённую систему скриптов управления нетфильтром и всё больше убеждаюсь в его необходимости, т.к. я думал влепить необходимые изменения в OnChange, но есть 2 проблемы - этот скрипт не получает IP изменяемого юзера (что естественно, т.к. он может быть офлайн) и неизвестность в смысле того, а не может ли этот скрипт оказаться запущеннным одновременно с каким-либо другим из OnConnect/OnDisconnect другого юзера. Чревато конфликтом. PS: Доработал скрипты для чернового решения проблемы смены тарифа. Кроме того добавил оптимизацию. тут

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

Даже если картинки реально выложены, так давать ссылки на народ нельзя. Они блокируют прямые обращения к файлам. Надо положить там хтмл и в нём дать эти ссылки.

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

Всегда хотел спросить по пункту К4, но не решался :-(=) Зачем нужен релоад, я понимаю, а вот зачем нужен стоп и как его применить можно... не понимаю Ведь после этого старт будет давать некому. Ещё... К6.а: Да, этого давно ждали и мне лично большего не надо, но ведь если клиентов не 2 3 десятка, а 2 3 сотни, такой механизм теряет практический смысл. Ближе к идеалу было бы выделение клиентов прямо в главном окне (это ведь тоже список, причём сортируемый. Главное, чтобы при изменении сортировки текущее выделение не сбрасывалось, хотя как это сделать, я не скажу), а если мечтать о несбыточном, то в 2.0 есть окошко "фильтр", но в нём нет кнопки "Применить", т.е. увидеть результат фильтрации не закрывая окна и затем нажать ещё одну несуществующую кнопку "Выделить" и вуаля, нужные клиенты готовы к рассылке. Ну как то так примерно...

Это можно реалиховать в скриптах управления файрволом А это я бы делать не стал, т.к. если трафик может считаться в минус, его можно накачать сколько угодно и не заплатить потом. Проще кредит поставить... ВО! ИДЕЯ!! =:-/ future request: Если юзер перешёл к использованию кредита, он должен (при нахождении онлайн) периодически получать от сервера автоматические сообщения о необходимости его погашения. Например раз в час или около того. Например параметр CreditReminder=<кол-во секунд между повторами> если=0, не напоминать. Точнее напомнить 1 раз, при авторизации.

Продвинутая версия управления через iptables OnConnect: #!/bin/sh #Этот скрипт вызывается в момент, когда пользователь #успешно прошел авторизацию на сервере. Задача скрипта - перестроить #файрвол так, что бы пользователь получил доступ в интернет # ©2003-2006 Wapr Old. Ver 3.0 #Умолчания: При запуске сервера должна быть создана цепочка BILL # с последним правилом -j DROP и в неё должны отправляться все пакеты # для которых необходимо управление доступом. (как минимум из FORWARD) # например так: # iptables -A FORWARD -i $WAN -o $LAN -j BILL # iptables -A FORWARD -i $LAN -o $WAN -j BILL # iptables -A INPUT -p tcp --dport 3128 -i $LAN -j BILL #1. Скрипт проверяет наличие юзерской цепочки по шаблону # BILL_${LOGIN} и если её нет, создает её. #2. В неё при создании добавляются в нужном порядке # разрешающие правила для всех необходимых адресов и критериев # ограничения скорости с возвратом пакетов через -j ACCEPT # Стоит учесть, что сюда попали пакеты ТОЛЬКО данного юзера. #3. В цепочку BILL добавляется вызов юзерской цепочки для всех # входящих и исходящих пакетов данного юзера # iptables -I BILL -s $IP -j BILL_${LOGIN} # iptables -I BILL -d $IP -j BILL_${LOGIN} #4. Для отключения юзера надо удалить только 2 правила в цепочке BILL, # а его цепочка остается на будущее. (так будет) #Отдельная цепочка для каждого юзера сделана для минимизации нагрузки #на сервер при управлении широкими каналами (у меня 2x100Мбит) и исключения #ситуации, когда пакеты одного юзера проходят через все правила всех остальных. # Login LOGIN=$1 #user IP IP=$2 #cash CASH=$3 #user ID ID=$4 DinM=( 31 28 31 30 31 30 31 31 30 31 30 31 ) D=`date '+%Y-%m-%d %H-%M-%S'` Month=${D:5:2} Day=${D:8:2} IPT="/usr/sbin/iptables" sgconf="/sbin/sgconf" bc="/usr/bin/bc" GW2="10.100.100.128" usersconf="/var/stargazer/users/$LOGIN/conf" usersstat="/var/stargazer/users/$LOGIN/stat" tariffs="/var/stargazer/tariffs" abon_key="_abon" anlim_key="anlim_" logfile="/var/log/stargazer-test" if [ ! -e "$usersconf" ]; then echo "ERROR: User file '$usersconf' not found" >> $logfile exit fi TariffName=`cat "$usersconf" | grep "Tariff=" | cut -d"=" -f2` # Сделаем юзерскую цепочку (если нету) if $IPT -N "BILL_$LOGIN" 2>/dev/null; then if [ "_${TariffName#$anlim_key}" != "_${TariffName}" ]; then # анлим найден limit_value=${TariffName:${#anlim_key}:2} # параметр анлима из тарифа # дебильное ограничение скорости limit="-m limit --limit ${limit_value}/s --limit-burst ${limit_value}0" # фильтры для внешней локальной сети без ограничений и в самом начале. $IPT -A "BILL_$LOGIN" -s 10.0.0.0/8 -d $IP -j ACCEPT # т.к. LAN: 10.100.0.0/16 $IPT -A "BILL_$LOGIN" -d 10.0.0.0/8 -s $IP -j ACCEPT # а WAN: 10.0.0.0/8 $IPT -A "BILL_$LOGIN" -s 85.21.29.0/24 -j ACCEPT # далее IP можно не упоминать $IPT -A "BILL_$LOGIN" -d 85.21.28.0/24 -j ACCEPT $IPT -A "BILL_$LOGIN" -s 85.21.52.0/24 -j ACCEPT $IPT -A "BILL_$LOGIN" -d 85.21.52.0/24 -j ACCEPT $IPT -A "BILL_$LOGIN" -s 85.21.79.0/24 -j ACCEPT $IPT -A "BILL_$LOGIN" -d 85.21.79.0/24 -j ACCEPT $IPT -A "BILL_$LOGIN" -s 85.21.88.0/24 -j ACCEPT $IPT -A "BILL_$LOGIN" -d 85.21.88.0/24 -j ACCEPT $IPT -A "BILL_$LOGIN" -s 85.21.90.0/24 -j ACCEPT $IPT -A "BILL_$LOGIN" -d 85.21.90.0/24 -j ACCEPT # всё остальное ограничиваем по скорости $IPT -A "BILL_$LOGIN" $limit -j ACCEPT else # это для тарифов без ограничения скорости # limit="" $IPT -A "BILL_$LOGIN" -j ACCEPT fi fi # Управление локальным файрволом iptables -I BILL -d $IP -j "BILL_$LOGIN" && \ iptables -I BILL -s $IP -j "BILL_$LOGIN" # turn on internet echo "$D Local login='$LOGIN' ip=$IP cash=$CASH" >> $logfile # Управление удалённым файрволом и уведомления об оплате # Проверим, что юзер платит абонплату (в названии его тарифа есть фрагмент "$key") if [ "_${TariffName#$anlim_key}" != "_${TariffName}" -o \ "_${TariffName%$abon_key}" != "_${TariffName}" ]; then if [ $Day -ge $(( ${DinM[$Month]}-2 )) ]; then # осталось меньше 2-х дней Fee=$(cat $tariffs/$TariffName.tf | grep "Fee=" | cut -d"=" -f2) # Узнаем абонплату # echo "$CASH < $Fee = " $(echo "$CASH < $Fee" | bc) # for debug if [ $(echo "$CASH < $Fee" | $bc) != 0 ]; then echo "$sgconf -s 127.0.0.1 -p 5555 -a messenger -w free \ -u $LOGIN -m 'бМХЛЮМХЕ! с бЮЯ МЕ НОКЮВЕМ ЯКЕДСЧЫХИ ЛЕЯЪЖ. \ рЮПХТ: $Fee; нЯРЮРНЙ: $CASH ЕД.'" | at now+1minutes 2>/dev/null fi fi exit # второй роутер отключен # Проверка доступности GW if [ `ping -A -c 2 $GW2 >/dev/null;echo $?` != "0" ]; then echo "$D Error! Gateway $GW2 is inaccessible." >> $logfile $sgconf -s 127.0.0.1 -p 5555 -a messenger -w free -u $LOGIN -m "хГБХМХРЕ, МН ЬКЧГ $GW2 МЕДНЯРСОЕМ. яБ exit fi # Проверка, что юзер уже включен на втором GW already=`ssh $GW2 -l r_main "/sbin/iptables -L BILL | grep $IP" 2>/dev/null` if [ -z $already ]; then # если не включен # Проверим, что баланс > 0 cash=`cat "$usersstat" | grep "Cash=" | grep "-"` if [ -z "$cach" ]; then # если не в минусе ssh $GW2 -l r_main "/sbin/iptables -I BILL -d $IP -j RETURN" ssh $GW2 -l r_main "/sbin/iptables -I BILL -s $IP -j RETURN" echo "$D Remote login='$LOGIN' ip=$IP" >> $logfile fi elif [ -e "/home/$LOGIN/free_always.txt" ]; then echo "$D Remote Find keeped connect from '$LOGIN' ip=$IP" >> $logfile else echo "$D Warning! Double login from $IP" >> $logfile fi fi OnDiconnect: #!/bin/sh #Этот скрипт вызывается в момент, когда пользователь #желает отключится от интернета или вышел таймаут у пользователя #и сервер сам отключает пользователя # Задач скрипта подобна задаче скрипта OnConnect - перестроить #файрвол так, что бы пользователю закрыть доступ в интернет # ©2003-2006 Wapr Old. Ver 3.0 #Умолчания: При запуске сервера должна быть создана цепочка BILL # с последним правилом -j DROP и в неё должны отправляться все пакеты # для которых необходимо управление доступом. (как минимум из FORWARD) # например так: # iptables -A FORWARD -i $WAN -o $LAN -j BILL # iptables -A FORWARD -i $LAN -o $WAN -j BILL # iptables -A INPUT -p tcp --dport 3128 -i $LAN -j BILL # Login LOGIN=$1 #user IP IP=$2 #cash CASH=$3 #user ID ID=$4 D=`date '+%Y-%m-%d %H-%M-%S'` IPT="/usr/sbin/iptables" GW2="10.100.100.128" #ssh_timeout="-o ConnectionTimeout 5" usersconf="/var/stargazer/users/$LOGIN/conf" usersstat="/var/stargazer/users/$LOGIN/stat" key="_abon" anlim_key="anlim_" logfile="/var/log/stargazer-test" if [ ! -e "$usersconf" ]; then echo "ERROR: User file '$usersconf' not found" >> $logfile exit fi TariffName=`cat "$usersconf" | grep "Tariff=" | cut -d"=" -f2` # Управление локальным файрволом $IPT -D BILL -d $IP -j "BILL_$LOGIN" && \ $IPT -D BILL -s $IP -j "BILL_$LOGIN" # turn off internet echo "$D Local logout='$LOGIN' ip=$IP cash=$CASH" >> $logfile # удаление юзерской цепочки # это временно, до появления в сервере переподключения при смене тарифа # или придумывания механизма пересоздания этой цепочки на лету при смене тарифа $IPT -F "BILL_$LOGIN" && $IPT -X "BILL_$LOGIN" exit # Управление удалённым файрволом # Проверим, что юзер платит абонплату (в названии его тарифа есть фрагмент "$key") if [ "_${TariffName#$anlim_key}" != "_${TariffName}" -o \ "_${TariffName%$abon_key}" != "_${TariffName}" ]; then if [ ! -e "/home/$LOGIN/free_always.txt" ]; then ssh $GW2 -T -l r_main "/sbin/iptables -D BILL -d $IP -j RETURN" && \ ssh $GW2 -T -l r_main "/sbin/iptables -D BILL -s $IP -j RETURN" if [ $? != "0" ]; then echo "$D Error! Gateway $GW2 it is inaccessible." >> $logfile exit fi echo "$D Remote logout='$LOGIN' ip=$IP" >> $logfile else echo "$D Remote Keep connect for '$LOGIN' ip=$IP" >> $logfile fi fi Предполагается, что тарифы без абонплаты названы просто "ляляля", а с абонплатой - "ляляля_abon", "жужужу_abon", "anlim_15", "anlim_70"... А также при запуске сервера создаётся цепочка BILL, в которую собираются все пакеты, подлежащие управлению биллингом. ... IPT=/usr/sbin/iptables ... # interfaces LAN="eth1" # my local network iface WAN_1="eth2" # inet from adsl router WAN_2="eth0" # local network corbina WAN_VPN="ppp+" # inet pptp corbina localnet="10.100.0.0/16" ... # billing chain # через эту цепочку проходят все пакеты из/в интернет $IPT -N BILL $IPT -A BILL -j DROP ... # INPUT ##################### $IPT -A INPUT -i lo -j ACCEPT $IPT -A INPUT -p tcp --dport 3128 -i $LAN -j BILL ... # OUTPUT #################### $IPT -A OUTPUT -p tcp --sport 3128 -o $LAN -j BILL # query trough squid ... # FORWARD ################### $IPT -A FORWARD -i $WAN_1 -o $LAN -j BILL $IPT -A FORWARD -i $LAN -o $WAN_1 -j BILL $IPT -A FORWARD -i $WAN_VPN -o $LAN -j BILL $IPT -A FORWARD -i $LAN -o $WAN_VPN -j BILL $IPT -A FORWARD -i $WAN_2 -o $LAN -j BILL $IPT -A FORWARD -i $LAN -o $WAN_2 -j BILL $IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT ...

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

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

Фантазии... Допустим я имею 2 канала в инет для целей надёжности и хочу как то распределить трафик чтобы резерв не простаивал. В медленный резервный канал я пущу например аську и почту, а остальное в основной. При этом я даю юзерам тариф, в котором имеется сколько то БМ (в общем). Ещё я хочу разделить подсчёт аськи и почты по разным направлениям. И ещё хочу (помня о том, что по аське можно и файлы гнать без ограничения), чтобы резервный канал не был забит трафиком вусмерть. И ещё поскольку почтовый сервис - отдельная (теоретически) услуга, хочу дать на него некое гарантированное количество БМ. Моё решение: Делаю тариф с абонкой например 100р. и БМ 1000Мб. При этом говорю юзеру что тариф предоставляет право юзать хттп, почту, аську и игры и что что аська будет считаться отдельно. В тарифе, в глобальных БМ пишу 900Мб. Это на главный канал. Соответственно в ДИР0 попадает хттп, игры и прочая фигня. БМ0 поставлю = 0, значит трафик будет сразу расходовать БМ тарифа. Затем по цене направления 0. Фильтрую почту на ДИР1 и кладу на БМ1 100Мб. Перерасход этих БМ приведёт к тому, что сначала начнут расходоваться БМ тарифа. (я ведь обещал дать 1000Мб в сумме) Затем по цене направления 1, а т.к. это другой канал, медленный, то и цену другую логично поставить, поменьше (типа пряник). Фильтрую аську на ДИР2 и кладу на БМ2 например 10мб от щедрот (должно хватить для обычного общения). А чтобы файлы особо не гнали или если гонят, чтоб не расходовали БМ тарифа, присваиваю этим локальным БМ2 статус глобальных. Т.е. перерасход аськиного трафика будет приводить сразу к пересчёту в деньги по цене направления 2 (которое сделать поболее чем в ДИР1, типа кнут). вот такие сумбурные мысли...

Спасибо :tongue: На самом деле я исхожу из того, что сделать схему, которая разрешит только нужные комбинации и при этом будут разрешены все нужные и запрещены ненужные гораздо сложнее, чем схему, просто разрешающую всё необходимое. А если при этом образуются бесполезные на первый взгляд комбинации, так ведь можно их просто не использовать. Правда? Тем более, что эти комбинации не являются чем то неправильным, багами или бэкдорами с точки зрения логики рассчёта трафика. Ох не люблю я этот виндовозный принцип, когда элемент управления в гуях не соответствует его логической сущности :argh: Мы говорим - Ленин, подразумеваем - партия, мы говорим - партия, подразумеваем - Ленин. (С) Короче всегда говорим одно, а подразумеваем совсем другое.

Ну вот пошёл предметный разговор. Это приятно. 2 XoRe Конфиги как раз фигня, это самое простое и последнее в нашей проблеме. А зачем БМ считать как деньги если они именно Бесплатные Мегабайты? 2 Max На мой взгляд было внесено лишнее усложнение в виде верхних вентилей. Поясню на примере среднего канала вашей схемы: есть 3 параметра управления - верхний вентиль, размер бачка и нижний вентиль. При указанном положении верхнего вентиля размер бачка никак не влияет на работу канала и => его можно принять = 0. При переключении верхнего вентиля и размере бачка = 0, работа канала никак не изменится => мы имеем один лишний элемент управления. Если я чего-то не заметил, меня можно и нужно поправить Честно? Не знаю! Но это неважно т.к. ничто не заставляет это делать. Но и не запрещает, что имхо важно. Правильно, не могут. Но и не будут т.к. это именно мегабайты и цены у них нету пока они бесплатные. А вот как только они закончатся, вступают обычные правила пересчёта мегабайт в деньги, которые для каждого направления разумеется свои. Просто мы оба на своей счеме нарисовали неправильно, что внизу все сливается в одну трубу и потом считается, нет такого. С каждым направлением ассоциированы свои поля данных для рассчёта проходящего трафика, которые вступают в работу при исчерпании БМ.

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

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

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

Ладно, попытаюсь объяснить моё видение процесса (но писанины будет много). Умолчания: 1. Под направлениями биллинга я понимаю именно то, что забито в биллинге. Т.е. совокупность правил фильтрации пакетов. Всё. 2. Под направлением тарифа я понимаю совокупность правил, флагов и полей, привязанных к конкретному направлению биллинга. 3. Когда я говорю о направлении, я всегда говорю о п.2 Теперь ответы: а. В данном случае я не буду делить ничего. Просто при создании тарифа "Эконом" будет указано, что его абонплата=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Гб. При этом неизрасходованный трафик переносится на след. месяц. Как его распределить? (См. про "обратное давление") Дисклаймер: везде вместо напрвлений надо понимать направления :-/

Я заметил Честно говоря не вижу принципиальных отличий от моего предложения, за исключением того, что моё гибче. Или гибчее Почему наличие глобальных БМ должно отключать локальные БМ? И если хочется реализовать подобную логику, по моей системе достаточно не задавать локальные БМ. Результат будет аналогичный. Единственный вариант, который у меня не реализуется, такой: есть 3 направления А Б В. Направление А - суть отдельный канал, а Б и В - другой канал, но например http и ftp. И мы хотим, чтобы при наличии глобальных БМ и всех локальных БМ, при окончании БМ из направления А глобальные БМ не списывались, а сразу списывались деньги. А по окончании БМ из Б и В - списывались глобальные БМ тарифа, которые тоже установлены. Хотя в общем и эта извращённая схема реализуема введением в локальных БМ флага, переводящего их в режим глобального. Т.е. видится такая иерархия: Биллинг| _______БМ биллинга; _______Методы учёта трафика _______Тариф1| ______________БМ (глобальные) ______________Метод распределения БМ по напр. (делегирование) ______________Флаг глобальности БМ ______________Методы учёта трафика ______________Направление1| _____________________БМ1 (локальные) _____________________Флаг глобальности БМ _____________________Правила направления 1 _____________________Методы учёта трафика ______________Направление2| _____________________БМ2 _____________________Флаг глобальности БМ2 _____________________Правила направления 2 _____________________Методы учёта трафика ...

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