> > > Во-вторых, в этом вопросе пока также нет готового стандартного и красивого
> > > решения, каждый изобретает свой велосипед по-новой. Или уже есть кстати?
> > Нет. По идеология cisco - адрес выделяет NAS.
> > > И кроме того, ничто не мешает acct-коллектору отрелеить/имитировать stop
> > > пакет куда сказано.
> > А чем это лучше ситуации, когда auth sending stop to acct?
> Ничем не лучше. А оно надо? Об том и речь.
Надо.
> Если выдавать адрес auth сервером, то впринципе можно продумать алгоритм
> кеширования и без завершающего сессию маркера (в вашем случае acct-stop).
> На вскидку -- признаком освобождения может быть и занятие этого же порта
> следующим клиентом...
??????? Ты наверно потерял нить дискуссии. Нужно держать выделение
IP адреса как можно дольше. Указанное событие сводит все усилия на нет.
> > Ага, значит лог-файл все-таки есть и мы умеем его парсить? А ради чего
> > тогда все? Этот лог файл и является буффером. Бери из него в максимальном
> > темпе. Эффективная реализация tail описана много где. Зачем два механизма?
> > Чтобы глюки потом искать?
> >
> Ради реалтайма.
Почему чтение из socket/pipe претендует на подобие реал-тайма, а чтение
из такого-же хендла, но связанного с файлом на диске - нет? В чем разница?
> > У тебя уже есть два надежных, простых, близких к NAS сервера, где ты
> > предлагаешь вести авторизацию. Отдай туда эккаунтинг и забирай/передавай
> > дальше. По любому протоколу.
> >
> Можно.
> Только вопрос -- зачем? Повысить надежность. Надежность _чего_?
В данном случае надежность системы эккаунтинга. Если же освобождать
адреса по событиям эккаунтинга, то и надежность системы авторизации.
> > > В начале сессии клиента мы загружаем его текущий баланс, лучше если это
> > > сразу время в секундах (деньги еще на стоимост поделить и округлить
> > > придеться;),
> >
> > Пойми, ситуация когда можно поделить и округлить пройдена нами 5 лет
> > назад. Уже с вводом ночного тарифа все становиться веселее, а с nightsurf+
> > еще веселее, а с weekend еще, а с multilink еще. Описанный тобой
> > алгоритм тарификации (ночью считаем 10 секунды за 5) не обеспечивает
> > достаточной точности расчетов и требует бессмысленных прерываний,
> > увеличивающих нагрузку на систему.
> >
> В этом абзаце нет конкретики, ля-ля тополя ;)
Извини, я думал, что все тут понимают проблему тарификации по сложным
интервалам, и что делением/умножением тут далеко не уежешь. Ok.
Подробности ниже.
> Нагрузку на систему как раз оказывают всевозможные подпорки, которым нет
> конца. Это не технология, это ее иммитация подручными средствами, об чем
> я и говорил ранее.
> Точность рассчетов равна кванту времени прерывания на одну сессию. Если
> сделать прерыватель каждую секунду, то и точность расчетов будет ровно
> 1 секунда. Можно и каждую микросекунду сделать, если проц успеет, только
> смысла в этом нет никакого.
Да, точность расчетов равна квантам, которые у тебя 10сек. Я считаю,
что уже эти 10 сек. создают неоправданную нагрузку, не говоря уже
о требуемых 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)" раз в секунду является
> большой проблемой??
Для каждой структурки ты должен слазить в некую структуру данных,
где из типа контракта пользователя, текущей позиции на абсолютной шкале
времени нужно вычислить текущий тариф. Иначе ты не знаешь сколько нужно
вычесть - 1 или 0 или 0.1 Сделать можно, но это будет существенно более
сложный код нежли "if (timeleft -= quant <= 0)".
Пойми, ты пытаешься осуществить интегрирование в real-time. Не спорю
- бывает. Летают и самолеты и ракеты. Но тебе это надо? Как насчет
цены всей этой конструкции?
Плюс вторая проблема - у тебя тарификация идет online, и нет первичного
документа - основания разборок с пользователем. Возвращаясь к сабжекту
данной дискуссии, я считаю, что сертифицировать твой алгоритм будет очень
сложно.
> > > Таким образом мы "растягиваем" время ночью, "ускоряем" в час пик, следим
> > > за границами дозволенного времени, контроллируем мульти-логины, проверяем
> > > номер звонящего, "восстанавливаем" потеряные acct-пакеты и тд., и все это
> > > в одном демоночке, вместо кучи подпорок по всей цепи тарификации.
> >
> > Я так и не понял какие там подпорки. Там все очень просто и легковесно.
> >
> > А описанный тобой алгоритм у нас давно работает. (с учетом различий
> > алгоритма тарификации) Живет следящий демон, сшибающий по SNMP. Правда у
> > нас не 1000 линий, а 650, и не 10сек, а 5 мин., поэтому проблем пока нет.
> > Но будут. Именно поэтому мы подготовились к внедрению нормальных таймеров.
> >
> Вопрос только в том как это все делать в реальном времени. И только лишь.
> И я утвердаю что это можно делать. Концептуально.
> И опровержений пока что так и нет.
Как тут уже справедливо заметили нельзя сделать реал-тайм алгоритм без
real-time OS. Еще нужна real-time сеть (QoS как минимум). Поэтому мы
все-таки говорим о различных уровнях приближения к оному реал-тайму.
Я считаю, что подойти можно очень близко. Но гарантировать нельзя.
Boris.
=============================================================================
"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
