Привет!
Thu Oct 21 13:25, Boris Tyshkiewitch <bvt@zenon.net> wrote:
> > Во-вторых, в этом вопросе пока также нет готового стандартного и красивого
> > решения, каждый изобретает свой велосипед по-новой. Или уже есть кстати?
>
> Нет. По идеология cisco - адрес выделяет NAS.
>
> > И кроме того, ничто не мешает acct-коллектору отрелеить/имитировать stop
> > пакет куда сказано.
>
> А чем это лучше ситуации, когда auth sending stop to acct?
>
Ничем не лучше. А оно надо? Об том и речь.
Если выдавать адрес auth сервером, то впринципе можно продумать алгоритм
кеширования и без завершающего сессию маркера (в вашем случае acct-stop).
На вскидку -- признаком освобождения может быть и занятие этого же порта
следующим клиентом...
> Ага, значит лог-файл все-таки есть и мы умеем его парсить? А ради чего
> тогда все? Этот лог файл и является буффером. Бери из него в максимальном
> темпе. Эффективная реализация tail описана много где. Зачем два механизма?
> Чтобы глюки потом искать?
>
Ради реалтайма.
> У тебя уже есть два надежных, простых, близких к NAS сервера, где ты
> предлагаешь вести авторизацию. Отдай туда эккаунтинг и забирай/передавай
> дальше. По любому протоколу.
>
Можно.
Только вопрос -- зачем? Повысить надежность. Надежность _чего_?
> > В начале сессии клиента мы загружаем его текущий баланс, лучше если это
> > сразу время в секундах (деньги еще на стоимост поделить и округлить
> > придеться;),
>
> Пойми, ситуация когда можно поделить и округлить пройдена нами 5 лет
> назад. Уже с вводом ночного тарифа все становиться веселее, а с nightsurf+
> еще веселее, а с weekend еще, а с multilink еще. Описанный тобой
> алгоритм тарификации (ночью считаем 10 секунды за 5) не обеспечивает
> достаточной точности расчетов и требует бессмысленных прерываний,
> увеличивающих нагрузку на систему.
>
В этом абзаце нет конкретики, ля-ля тополя ;)
Нагрузку на систему как раз оказывают всевозможные подпорки, которым нет
конца. Это не технология, это ее иммитация подручными средствами, об чем
я и говорил ранее.
Точность рассчетов равна кванту времени прерывания на одну сессию. Если
сделать прерыватель каждую секунду, то и точность расчетов будет ровно
1 секунда. Можно и каждую микросекунду сделать, если проц успеет, только
смысла в этом нет никакого.
> Просто какой-то натуральный счет по пальцам. Чтобы сложить 8 и 7
> ты делаешь прибавление 7 единиц.
>
> Поэтому я и говорю про обратный тарификатор, который переводит деньги в
> секунды. Это сложный алгоритм. Но он есть и работает.
>
Давай поконкретней тогда уж.
Чем занимается обратный тарификатор, и что там за алгоритм у него такой
сложный, что он не успевает отрабатывать за микросекунды процессорного
времени, т.е. почему его нельзя выполнять каждую 1сек, а не раз в 5мин.
> > взводим таймер чтоб прерывал нас каждые 10 сек, в каждом
>
> Какие 10сек? Что за маразм? Таймер ставиться на столько секунд сколько
> нужно для данного входа. И прерывает он нас - когда нужно. Опять-же
> классическая реализация таймеров по книжке.
>
> > прерывании отнимаем от остатка времени клиента 10 сек. (5 сек., 20 сек),
> > попутно коллектим acct-пакеты, отрабатываем пропадания связи и пр.,
> > когда результат <= 0 то срубаем его сессию, сохраняем остаток...
>
> Что, вот так раз в 10 секунд, по всем 1000 линиям сравниваешь с 0?
>
Блин. Что за вопрос?
Демонок распределяет у себя в памяти структурку длиной 200-300 байт, где
хранит все кишки от сессии одного клиента. Структурки формируются в
цепочки. Распределить 1 000 000 сруктур по 200 байт и ходить по ним всем
с грубо говоря "if (timeleft -= quant <= 0)" раз в секунду является
большой проблемой??
Если это на перле делать тогда может быть...
> > Таким образом мы "растягиваем" время ночью, "ускоряем" в час пик, следим
> > за границами дозволенного времени, контроллируем мульти-логины, проверяем
> > номер звонящего, "восстанавливаем" потеряные acct-пакеты и тд., и все это
> > в одном демоночке, вместо кучи подпорок по всей цепи тарификации.
>
> Я так и не понял какие там подпорки. Там все очень просто и легковесно.
>
> А описанный тобой алгоритм у нас давно работает. (с учетом различий
> алгоритма тарификации) Живет следящий демон, сшибающий по SNMP. Правда у
> нас не 1000 линий, а 650, и не 10сек, а 5 мин., поэтому проблем пока нет.
> Но будут. Именно поэтому мы подготовились к внедрению нормальных таймеров.
>
Вопрос только в том как это все делать в реальном времени. И только лишь.
И я утвердаю что это можно делать. Концептуально.
И опровержений пока что так и нет.
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on
