Перейти к содержимому
Калькуляторы

^rage^

VIP
  • Публикации

    1194
  • Зарегистрирован

  • Посещение

Все публикации пользователя ^rage^


  1. а чем штатный pktgen из linux-ядра не подходит? работает в kernel space.
  2. 2vIv: >Точнее, там не реал-тайм, а скорее ближе к аккаунтингу по alive-отметкам. То-есть автор биллинга (домашний оператор) регулярно получает отсчёты аккаунтинга и может в любой момент разорвать сессию. Ну скажем так: msc стучицца к hlr, получает профиль абонента где есть список доступных сервисов, detection points и GT IN-платформы(один из предоставляемых сервисов которой - тот самый prepaid). На платформе для каждого сервиса в прописан размер резервации. Для gprs/3g datacall резервация в килобайтах(Она для них разная: для gprs квант меньше). Отсюда возможна весьма забавная ситуация: Имея 50 руб на счету при резервациях 500кб для 3g и 10кб для gprs при цене 10р/Мб заказав какую-то контентную смс за 46 руб в случае 3g абонент обломается воспользоваться передачей данных, т.к. тупо не хватит денег на резервацию. >Скорее про MSRN. Обычно его выдают при коммутации звонка, а ты, видимо, видел ситуацию, когда за терминалом такой номер резервируют на всё время пребывания в гостевой сети. MSRN выдают при регистрации в сети. В том числе в домашней. 2Kirya: TMSI - это 4 октета, еще один номер абонента туда совсем не влезет :))) Да и нужен он для того, чтобы не светить в эфире IMSI & Ki лишний раз :) 2thodin: >Дык я и рассказываю: на MSRN тоже можно позвонить и узнать его не сложно. Конечно, он будет меняться, но это сущие мелочи. нельзя туда позвонить =) проверялось много раз. Вообще, в описанной ситуации всё просто: у меги с данным оператором не открыт camel-роуминг(либо греческий оператор не умеет верблюда) и тарификация роуминга идет в tap-файлах(которые формируются из cdr'ов коммутатора) и задержка между услугой и приходом тапок вполне может быть неделя-месяц. Опять же, надо не забывать про непрепейдные тарифы(на которых обычно и держат всякие 3g модемы) где тарификация так же идет на базе всяких cdr'ов(с msc, ggsn, smsc, mmsc).
  3. Имеется NetUP Dual DVB-S2-CI + PowerCam Pro v 4.5 + офиц. карточки нтв+ изменили подписку, но что-то обновление не прошло. перерыл кучу форумов, везде пишут про ресиверы =( а как это делать на карточках? или же всё-таки искать ресивер, обновляться и возвращать карточку на место?
  4. есть готовые решения от Amdocs/CBOSS/Comverse. стоп. что вы подразумеваете под кластеризацией? и чего хотим ей достичь: high availability, load balancing или же все сразу?пока у меня сложилось впечатление, что вы говорите только о SSI, рассматривая другие варианты как идеологически неверные. Имхо, SSI надо только там, где есть сильносвязанные данные(что для биллинга совершенно неверно). у хапе? высокой доступности? у них из high end есть только superdome на итаниках(которые, фактически похоронены amd64/emt64).Выпустить что-то новое они смогут как только интел родит свежих итаников. Про представителей сотовиков: я писал про realtime billing(некоторые называют это rating'ом). Та часть, о которой упоминаете вы - это скорее всего выставление счетов итп вещи. Там скучно: high end storage(например, hp eva 8400), sun fire e25k/m9000(на котором живет оракл) + ферма серверов с логикой. дешевле по сравнению с чем? задачи и масштабы у всех разные. Телекому на 50к абонентов и не нужны все эти кластеры/СХД. им может хватить двух машин с drbd.
  5. а толку? все равно мы уже упали. в случае сервиса все проще: обвешиваемся супервизорами критичных процессов и в случае краха перезапускаем. сильно быстрее чем поднимать ОС+сервис. тут вроде упоминался kemari - оно вообще жестоко по отношению к производительности. А синхронизация между нодами через GE - это слишком долго в таком случае. Хорошо подходит на роль интерконнекта infiniband - но это уже другие $$
  6. а можно примеры таких систем? хотя бы 3-4 штуки достаточно. подождите... вы сейчас описываете абсолютно неправильную и идиотскую идею: заставить безногого инвалида крутить педали велосипеда.Если биллинг должен обслуживать _много_ абонентов и в реальном времени, то решение проблем масштабируемости и доступности решаются на этапе его дизайна. это очень дорого, сложно и имеет массу проблем. проще и дешевле делать это на уровне приложений, а не операционной системы или железа. Например "размазать" базу абонентов по нескольким нодам(каждая из которых - сама по себе кластер, например ibm p570) на которой живет оракл. Логику положить на массив машин 1u или несколько блейдцентров. Примерно так устроены платформы онлайн-биллинга у любимых многими ОПСОСов :) ага. давайте вложимся в офигенно дорогое оборудование типа e25k или m9000, к ним ещё топовую emc symmetrix(а чтобы совсем-совсем все по взрослому - разнесем по двум ДЦ и сделаем полное дублирование). нет никакого барьера. биллинг - это система массового обслуживания и отказы будут. Другое дело, что такое пара тысяч отбитых вызовов/запросов авторизации на фоне 80-100 млн успешных?Например, сейчас у одного вендора есть конвергентный биллинг на ~ 300 млн абонентов. В принципе, можно и больше, но пока нет оператора с такой абонентской базой. бывают. да и какая разница, грохнулось ядро или application, которое обрабатывает логику? эффект практически эквивалентен.
  7. АХТУНГ! БиЛайн тырит бабки!

    угу. а успешный первод самому себе? Кстати, с билайном припоминается вот такая ситуация: http://www.newsru.com/russia/11nov2003/bee.html http://www.newsru.com/finance/13jan2004/bee.html
  8. АХТУНГ! БиЛайн тырит бабки!

    почему за бесплатно? вон у МТС в оферте написано: весь вопрос в законности взятия денег за "формирование распоряжения". PS: то, что можно перевести самому себе - шикарнейший косяк со стороны билайна. тоже интересно, ведь вроде пунктом 3.2 прикрылись.