> > > Фактически получилось что технологический бекгроунд услуги dialup
> > > оказался жестко связан с расчетной частью. А это и есть главная ошибка.
> >
> > Я категорически с этим не согласен. Расчетная часть, по крайней мере
> > ее модули прямого и обратного тарификаторов, является неотъемлемой
> > частью услуги dialup. Без нее невозможно учитывать потраченные ресурсы,
> > и как следствие невозможно принять решение об авторизации.
> >
> Стоп.
> Авторизация статична, ее цель - дать атрибуты сессии клиента перед ее
> началом. И все!
Да. Именно так - аттрибуты. Одним из аттрибутов может быть
session_timeout.
> Всем остальным занимается система учета. Это именно она принимает решение
> пускать не пускать, когда срубать, какова стоимость и тп.
Вопрос о том, кто чем должен заниматься и как делить систему на модули
не так очевиден. Я бы не стал говорить так уверенно. Многое зависит
от выставляемых требований.
> Если решена задача контроля учетной системой всей сессии клиента
> динамически (real-time система), то совершенно необязательно ее функции
> передавать в стадию авторизации.
Иногда ее хочется оттуда запускать, чтобы получить тот самый аттрибут.
> Ну авторизовался клиент в сети где-то на деревне васюки, информация об
> этом (acct-пакет) пошла в учетный центр и он принял решение
> отменить/завершить эту сессию в тот же момент. И не только по причине
> окончания оплаченного времени, например при мульти-логине, временных
> рамках и еще бог знает почему.
> В том то и ошибка, что проблемы системы учета повсеместно решают с помощью
> авторизации. Ломать это надо в себе ;)
Можно и так. Этот параграф проясняет твою мысль. Достаточно изящно,
особенно если это отрубание клиента описать в условиях и доках для
сотрудников, и в других модулях системы (не считать за это денег)
Но опять нет никакой зависимости от протокола обмена между сервером
авторизации и сервером доступа.
>
> > Что касается разделения на авторизацию и эккаунтинг, то она
> > есть как в радиусе, так и в такаксе. Нет никаких проблем ее отделить
> > и отправить другим путем. Собственно так оно и живет.
> >
> > Сервер авторизации - это _не_ радиус/такакс. Это совсем другое,
> > а пресловутые слова - всего-лишь _интерфейсы_ по которым к ним
> > обращаются сервера доступа.
> >
> Я говорил о том что у радиуса есть два отдельных протокола (см. RFC2138
> и RFC2139). На разных портах. Что не противоречит и "на разных серверах".
> Более конкретно -- аккаунтинг сервер в учетном центре, сервера авторизации
> на местах.
> В такаксе такой идеологии нет, впрочем как и нет до сих пор RFC.
> Вопрос: почему програмисты из ливингстона сделали два разных порта, а
> студенты от циско нет? Дальновидность?
Может и так. Я не хочу раздувать дискуссии что лучше. Другое дело, что
этот особый порт и особый протокол не дает особой выгоды. Все то-же самое
делается и на одном порту. Никто не мешает серверу авторизации, принявшему
через tacacs авторизационный запрос, отправить эккаунтинговый пакет на
сервер биллинга. Хоть бы и по протоколу radius.
> > сравнение binary/text mode и их применимость в Интернет. Можно обсудить
> > легкость интегрирования третьих продуктов, использования совремемнных
> > средств типа CORBA/LDAP в противовес propertary protocols, etc.
> >
> > Но это уже другое, и тут есть немало интересного. К протоколу обмена
> > между сервером авторизации/эккаунтинга и сервером доступа уже никакого
> > отношения не имеет.
> >
> Все пытаются прикорячить какие-то сторонние технологии к решению этого
CORBA/LDAP - это не сторонние, а общие универсальные технологии. В
противоположность частным. Даже если написать RFC - частная технология
не станет общей.
> > > Вы представляете сколько времени, сил и денег народ уже потерял и упорно
> > > продолжает терять на изобретение этих соплей? Было бы гораздо грамотней
> > > решить эту задачу в самом низу, там, где еще проблем как бы и нет никаких.
> >
> > Задача не решается внизу. Т.к. нет необходимого видения всех
> > бизнес-процессов и связанных с ними аттрибутов.
> >
> Значит нужно пытаться упростить задачу.
> Мы, например, упростили ее до уровня только контроля времени, это то что
> действительно требуется в реал-тайме. В нашей базе нет денег совсем,
> только время. Все формализовано на время. Такая вот единица измерения,
> ничем не хуже фантиков как оказалось.
Это не время. Это фантики такие. Иначе ночной тариф не получается.
Вобщем и мы делаем аналогично, а вот MTU/absolut принципиально иначе.
С чего дискуссия и началась.
> В легкую. Нет в них потребности на dialup услуге. Продаем то время.
Нет. Продаем услугу. А она может иметь хитрую структуру. С разными
тарифами в разное время суток и дня недели. Поэтому просто
складывать/вычитать время не получается. Нужно запускать тарификатор.
> А другие услуги предоставляются по факту оплаты как в магазине. Вам нужно
> хранить историю таких сделок только для бухгалтерии, ну так и храните ее
> там, в системе документоборота, причем тут real-time система учета dialup,
> она лишь звено в общей системе.
Откуда ты знаешь что люди хотят делать? Откуда ты знаешь из
бизнес-процессы и цели? Я вполне допускаю наличие потребности в real-time,
и хочу сказать, что дешево его не сделаешь. А меня пытаються убедить,
что уже сделали "только глюкает маленько" и "щас совсем круто доделаем".
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
