vop

Одна из главных ошибок биллинга - кормление его трафиком, а не данными, необходимыми для расчетов. Ибо объемы трафика для биллинга вообще не должны волноать, ибо он должен получать только суммарные числа для расчета и вся разница объемов заключается в разнице числа в обперации умножения. А с трафиком должен справляться 1-й уровень - коллектор трафика. Ну ладно, не буду сильно разворачиваться, т.к. обещал не тратить время на тех, кто не умеет слушать разумные доводы.

Это не утопия, а совершенно нормальная схема, работающая более 10 лет в моем биллинге. Ничего не стоит разнести структуры учета клиентов и учета услуг, связав их друг с другом, и формализовав по параметрам. В резульате всего получим КОЛЛОСАЛЬНОЕ УПРОЩЕНИЕ биллинга, и "опупенное" увеличение гибкости и функциональности. Всего-то. Специализация по продаже услуг, и не дергании файервола очень помогает.

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

Господа, еще раз замечу, если вы не продаете канал, то нехрен писать в договорах "безлимит" и заниматься маркетинговым нажучиванием. Пишите ограничения (100 Гиг, 40%), но не старайтесь обмануть сами себя. А то получается полная хренотень, типа, и "безлимит" продали, и не такой уж он и безлимит...

Двууровневый (многоуровневый) биллинг предназначен для продажи услуг, а не интернета. Что он даст персоналу из, скажем, сколько угодно абонентов? Ну не знаю. Как минимум, возможность вести учет продажам не только IP подключениями (в любом количестве и конфигураций), но и другими услугами, характерными для провайдера, но о которых, почему-то создатели биллингов практически не думают. Например, почтовый ящик(и), домен(ы), виртулальный хост, доступ к игровому серверу или хранилищу файлов, и т. д, не говоря уже об iptv и voip. Когда авторам биллингов приходит это понимание, то начинают появлятся прилёпки в виде "дополнительных услуг" и т.д. И это при золотом правиле, что дополнительных услуг не может быть, ибо все услуги основные. Так вот оба упомянутых биллинга предназначены для торговли ip-подключением.

Только не понятно, зачем нужно сопряжение с биллингами

Оба, и STG и NoDeny - одноранговые биллинги (т.е. считалки трафика с "умножением" на стоимость). У STG в принципе, самая неудачная структура, которую только можно было придумать. Поэтому, если нет никаких предубеждений перед перловым скриптом, наверно, лучше пользоваться им.

Очень хотелось бы встретиться с теми, кто производит интернет, а не перепродает

В приличных домах Утрехтщины в договорах клиентов пишут, (в вольном переводе) "предоставляется канал со скоростью 4 мегабита с максимальной загрузкой не более 25%". Ибо там же для офиса продается "гарантированый" канал без ограничения. Вот в этом случае есть отличие домашнего от корпоративного, в том числе и по цене. Это именно тот случай, при котором клиент по сути получает безлимит на 1м, но со скоростью в 4м - тот самый "комфортный" интернет. Если в договоре нет такого пояснения, то и отличия нет, а все остальное - мелкое мошенничество со стороны провайдера

У меня в доме два кабельных ТВ провайдера. В принципе, набор каналов одинаковый, и цены примерно равные... Только вот один хочет денег за "дополнительный телевизор", а второй говорит - подключайте сколько хотите через сплиттеры, только не увлекайтесь, ибо, сигнал не резиновый, слабеет... К какому я подключился, гадать не стоит.

На одном интерфейсе? Почему бы пример не привести?

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

не работает Что именно не работает? Что говорит telnet 192.168.0.1 9770 ?

И на этом форуме подскажу. Я бы сделал порт-прокси при помощи netcat'а. Для этого на машинке 192.168.0.1 В файлик /etc/inetd.conf добавляем строчку, типа: 9770 stream tcp nowait nobody /bin/nc nc 192.168.0.2 9770 Не забыть перезапустить inetd (killall -HUP inetd). Это существенно проще, нежели поднимать влан с форвардингом портов.

Автономка нужна не "для раздачи белых IP клиентам", а для организации динамического роутинга, как бы

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

Не понял одного момента. Как юзер скачивает чего-то, если у него сеть не настроена?

Чисто косметически. Желательно проверять коды завершения работы командочек, и только потом заносить в логфайл done or error...

Достаточно не путать коммерческий договор с гражданской доверенностью. Тогда все встанет на свои места.

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

Да, это очень важный критерий оценки работы софта.

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

Вообще-то, деньги хранят в целых величинах только потому, что это целочисленные вещи. По крайней мере, мне не известно ни одной финансовой системы (бухгалтерский софт, банкинги и т.д.), где бы использовались плавающая арифметика, хотя бы потому, что в в ней закладывается практически обязательная погрешность. Мой пример вовсе не говорит о существовании проблем с потерей данных, но показывает, что они потенциально всегда существуют в системах, в которых смешивается целочисленная и плавающая арифметика. Вообще-то к "пре" и "пост" паиду это не имеет никакого отношения. Финансовая модель должна быть отделена логически вообще от считалки байтов, и быть самодостаточной. Просто никто не отменял учет текушего затратного баланса с блокировочной суммой. Система совершенно аналогична работе расчетов банковскими картами - текущая аторизация затрат с блокировкий суммы и дальнейший батч (рельное списание) суммы. Про уплывающий трафик - накопление погрешностей атомарного начисления. Реально должна быть одна погрешность - меньше копейки в месяц, или где-то так. Вообще-то, существующая схема хуже, так-как она реализует исчезающее изменение данных. А неисчезающая схема только одна - та, про которую я написал, и та, которая гарантируется реализацией любой OS. Именно такая схема и реализуется в разного рода системных утилитах, типа rsync или scp.

Совершенно зря. Байты - вещи целочисленные. Рубли-копейки - тем более. Тут нет места для даблов, тем более, можно хорошо на конвертах пролететь. Для прикола, простой примерчик залета. // gcc -o aaa aaa.c ; ./aaa #include <stdio.h> #include <stdlib.h> #include <stdint.h> int main(int argc, char *argv[]) { int traf=70; double cost=.6; int sum; sum=traf*cost; printf("%d\n", sum); return(0); } Я Борису об этом говорил еще в те времена, когда старгейзер еще не назывался старгейзером. Зря, что он проигнорировал. Это значит, что в течении месяца количественные показания услуг (напр, трафик) накапливаются, а расчет происходит при закрытии месяца. В этом случае, баланс не "уплывает". Прим. уплывший баланс, по сути, обман клиента. При бориной системе расчета, взявши сумаррный месячный трафик (по категориям) и умноживши на его стоимость (так же по категориям) мы не получим сумму:, которую "снял" старгейзер. "Обман" может достигать до 15%. Заглянул для любопытство. Не то. Ну, в принципе, rename используется, но не там, так-как не достигается главная цель - надежное неисчезающее хранение данных. Мое многолетнее взывание к Борису, все же, в ключевом моменте заключалось не в команде rename, а немного в дрогом. Правило простое - ни при каких условиях, ни в каком случае, ну просто никогда нельзя открывать файл данных на запись, ибо, это означает обнуление данных. А это означает, что если в этот момент старгейзер завершит работу, причем, нормльно, по sigint, данные пропадут (а вовсе не при повреждении файловой системы, как Борис настаивал). оэтому алгоритм работы с файлом данных очень простой. Если хотим что-то изменить в файле данных, то поступаем просто: 1. создаем временный файл рядышком с файлом данных, в которых складываем всю информацию, включая необходимые изменения (если этот файл поломается - пофиг, он никому не нужен). 2. Закрываем файл, и проверяем, как минимум, размер созданного файла (желательно, при создании, мониторим количество записываемой информации). 3. Вот тут уже делаем rename временного файла на постоянный файл. Это и будет неисчезающее изменение файла данных. И в этом случае ему ничего не гроизт, ни ^C, ни падение, ни конец места на диске или упор в квоту, ни падение сервера. Честно говоря, я так и не доехал, почему Борис столько лет так упорно сопротивлялся в понимании такого простого алгоритма, который используют многие программы (тот же rsync). Мораль тут немоног другая. Если не хватает сил сделать элементарную работу с данными, то переход на более технологичные способы хранения в базах данных не спасет. Ибо, подход тот же А кто эту структуру дергает? Вообще, структурная путаница в старгейзере играет плохую шутку во всем этом деле. Продукт усложняется гораздо быстрее, чем растет функционал. Ну да ладно, это уже вопросы политики, тут мне посоветовать нечего.

Опять те же грабли: client = ip address.