ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: Inet-Admins
Inet-Admins mailing list archive (inet-admins@info.east.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [inet-admins] сертификация биллинговой системы



Привет!

Wed Oct 20 15:30, Boris Tyshkiewitch <bvt@zenon.net> wrote:
> > Фактически получилось что технологический бекгроунд услуги dialup
> > оказался жестко связан с расчетной частью. А это и есть главная ошибка.
> 
>   Я категорически с этим не согласен. Расчетная часть, по крайней мере
> ее модули прямого и обратного тарификаторов, является неотъемлемой 
> частью услуги dialup. Без нее невозможно учитывать потраченные ресурсы, 
> и как следствие невозможно принять решение об авторизации.  
> 
Стоп.
Авторизация статична, ее цель - дать атрибуты сессии клиента перед ее
началом. И все!
Всем остальным занимается система учета. Это именно она принимает решение
пускать не пускать, когда срубать, какова стоимость и тп.
Если решена задача контроля учетной системой всей сессии клиента
динамически (real-time система), то совершенно необязательно ее функции
передавать в стадию авторизации.
Ну авторизовался клиент в сети где-то на деревне васюки, информация об
этом (acct-пакет) пошла в учетный центр и он принял решение 
отменить/завершить эту сессию в тот же момент. И не только по причине
окончания оплаченного времени, например при мульти-логине, временных
рамках и еще бог знает почему.
В том то и ошибка, что проблемы системы учета повсеместно решают с помощью
авторизации. Ломать это надо в себе ;)

>   Что касается разделения на авторизацию и эккаунтинг, то она
> есть как в радиусе, так и в такаксе. Нет никаких проблем ее отделить
> и отправить другим путем. Собственно так оно и живет. 
> 
>   Сервер авторизации - это _не_ радиус/такакс. Это совсем другое,
> а пресловутые слова - всего-лишь _интерфейсы_ по которым к ним
> обращаются сервера доступа.
> 
Я говорил о том что у радиуса есть два отдельных протокола (см. RFC2138
и RFC2139). На разных портах. Что не противоречит и "на разных серверах".
Более конкретно -- аккаунтинг сервер в учетном центре, сервера авторизации
на местах.
В такаксе такой идеологии нет, впрочем как и нет до сих пор RFC.
Вопрос: почему програмисты из ливингстона сделали два разных порта, а
студенты от циско нет? Дальновидность?

> сравнение binary/text mode и их применимость в Интернет. Можно обсудить
> легкость интегрирования третьих продуктов, использования совремемнных 
> средств типа CORBA/LDAP в противовес propertary protocols, etc.
> 
>   Но это уже другое, и тут есть немало интересного. К протоколу обмена 
> между сервером авторизации/эккаунтинга и сервером доступа уже никакого 
> отношения не имеет.
> 
Все пытаются прикорячить какие-то сторонние технологии к решению этого
вопроса, вместо того чтобы сделать просто новую технологию. Мужики из
bellcore вот взялись делать MGCP для ip телефонии и молодцы, а индусы
от циско приверчивают туда что под руку попадается.

>   Извини. Такая жизнь. Выкини киску, поставь вместо нее нормальный
> сервер доступа (какой?) и может полегчает. Только не вериться.
> Но дилема радиуса/такакса тут точно не причем.
> 
Мы сейчас тут обсуждаем идеологии разных подходов к билингу, а не
сравниваем радиус с такаксом. Идеология, заложенная (может и случайно)
в радиус мне просто кажется более.
Вместо циски можно использовать и ливингстон, дело вкуса. Но проблемы
то останутся те же. И их нужно как-то решать, а не затыкать заплатками.

> > Вы представляете сколько времени, сил и денег народ уже потерял и упорно
> > продолжает терять на изобретение этих соплей? Было бы гораздо грамотней
> > решить эту задачу в самом низу, там, где еще проблем как бы и нет никаких.
> 
>   Задача не решается внизу. Т.к. нет необходимого видения всех
> бизнес-процессов и связанных с ними аттрибутов.
> 
Значит нужно пытаться упростить задачу.
Мы, например, упростили ее до уровня только контроля времени, это то что
действительно требуется в реал-тайме. В нашей базе нет денег совсем,
только время. Все формализовано на время. Такая вот единица измерения,
ничем не хуже фантиков как оказалось.

> > Это первый шаг к действительному real-time.
> > Второй шаг - это отказ от учета фантиков и переход к учету собственно
> > услуги, т.е. к учету времени в реальном же времени.
> 
>   Время не является единственным атрибутом услуги. Те самые фантики
> (деньги) - являются. Посмотри на тарифы различных провайдеров. От фантиков
> никуда не денешься.
> 
В легкую. Нет в них потребности на dialup услуге. Продаем то время.
А другие услуги предоставляются по факту оплаты как в магазине. Вам нужно
хранить историю таких сделок только для бухгалтерии, ну так и храните ее
там, в системе документоборота, причем тут real-time система учета dialup,
она лишь звено в общей системе.

=============================================================================
"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 http://info.east.ru/rus/inetadm.html



 




Copyright © Lexa Software, 1996-2009.