|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Alexander Kolesnikoff 2:5020/400 24 Jan 2002 06:45:30
To : Lev Walkin
Subject : Re: RADIUS + [ hardware NAS | software NAS]
--------------------------------------------------------------------------------
Lev Walkin <vlm@netli.com> wrote:
>
>
> Полагаю, тут множество народу этим занималось (занимается), но просто
> отвечать всем лень. Потому что статистика показывает, что все равно
> все всё сами пишут. Так как ТЗ у всех хоть немного, но различается,
> а попытка сделать универсальность проваливается в дыры, называемые
> "коммерческая реализация". То есть, за деньги.
>
Так и есть - все делают системы под свои нужды.
>
>> Кому как, а мне система с отслеживанием в реальном времени
>> активности клиентов и связанного с этим вычисления остатка денег
>> на счету, сбрасыванием линии, если баланс = 0, не нравится в принципе.
>> Моё решение: вычислять значение аттрибута Session-Timeout один
>> раз, при входе клиента в систему, с учётом смены тарифных планов
>> во время сеанса связи. Вычислять остаток на счету клиента один раз,
>> по окончанию сеанса связи. Всё это должен делать радиус.
>
>
> А вот теперь посмотри на эту схему и подумай: что будет, если в систему
> войдет _два_ или больше клиентов? Если они войдут примерно одновременно,
> то они могут уйти в минус достаточно далеко.
>
Я исхожу из того, что двух одинаковых логинов в системе
быть не может. Более того, выставляется параметр в конфигурации
радиуса Simultaneous-Use=1, запрещающий одновременный заход двух
клиентов в систему под одним логином.
>
>
> 1. Стадия авторизации. Есть скрипт или более навернутое решение (как
> вариант, _модуль_ в AAA демоне), который смотрит на остаток на счете.
> Если остаток отрицателен, не дает клиенту авторизоваться. Иначе, далее.
>
В общем-то без наворотов это делает радиус с поддержкой MySql.
> 2. Стадия разбора аккаунтинга.
>
> Делается программа, которая сидит постоянно в памяти (daemon, типа),
>
> Эта схема имеет одно большое преимущество перед теми, которые основаны
> на кормлении железок байками о том, когда надо скидывать пользователя.
> Преимущество такое, что можно одновременно обслуживать неограниченное
> число (или ограничивать произвольной величиной) пользователей, заходящих
> в систему под одним логином.
Если требуется, чтобы несколько клинетов пользовались
одним балансовым счётом - тогда такая схема и нужна. Сам же
сказал: у всех разные ТЗ. :-)
Alexander
--- ifmail v.2.15dev5
* Origin: UKU (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
