[serg1981]

Поздно Вы решили продавать биллинг для ISP.

Сейчас всех мелких провайдеров, на которых рассчитан Ваш биллинг либо уже купили/вытеснили, либо скоро купят/вытеснят с рынка. Так что позднякс-с.

 

Тем более без тех. поддержки, без 10 лет на рынке, без сертификата, без нормального сайта и с контактами по e-mail и icq. Встречают по обложке как говорят...

[dolphinik]

Ну хватит уже. Мы всё умираем умираем и никак не умрём. Раз проект существует - значит он нужен. И пусть пока нет сертификата, который нужен только для РФ, за то функционал то какой. А сертификат можно показать и на какой-нибудь официально купленый трафик инспектор, если попросят.

[serg1981]

... за то функционал то какой...

 

Посмотрел функционал - такой же как у большинства биллингов.

Не понял, что такого особенного есть в Вашем биллинге?

[dolphinik]

Не считая представленного списка возможностей он идейно монолитен, очень гибок, устойчив и производителен. Но о предпочтениях не спорят, поэтому каждый будет выбирать сам что ему удобно - сидеть ковырять перловские скрипты, чтобы получить то, что хочешь, или настроить это же из интерфейса администратора несколькими кликами мыши. Вот в чём разница.

[serg1981]

Не считая представленного списка возможностей он идейно монолитен, очень гибок, устойчив и производителен. Но о предпочтениях не спорят, поэтому каждый будет выбирать сам что ему удобно - сидеть ковырять перловские скрипты, чтобы получить то, что хочешь, или настроить это же из интерфейса администратора несколькими кликами мыши. Вот в чём разница.

 

Это общие слова, которые говорит каждый производитель биллингов. Когда мы покупали свой биллинг - нам каждый поставщик решения повторил Ваши слова.

[dolphinik]

Каждый хватил свою корову.

Пока не попробуешь - своё мнение не сформируется. Попробуйте :) Будет интересно узнать ваше мнение.

[Paparaцo]

Не считая представленного списка возможностей он идейно монолитен, очень гибок, устойчив и производителен. Но о предпочтениях не спорят, поэтому каждый будет выбирать сам что ему удобно - сидеть ковырять перловские скрипты, чтобы получить то, что хочешь, или настроить это же из интерфейса администратора несколькими кликами мыши. Вот в чём разница.

 

Есть ли цифры по производительности? Например, тянет 10 тыс. абонентов, 7 тыс. в онлайне одновременно, железо такое-то.

Уверен, что через перловые скрипты можно многое сделать, чего нет у вас в интерфейсе и тем более за несколько кликов.

 

И насчет сертификата все-таки озаботьтесь, вы же его здесь в России продаете, а не в Папуа — Новая Гвинея. :)

[dolphinik]

Есть ли цифры по производительности? Например, тянет 10 тыс. абонентов, 7 тыс. в онлайне одновременно, железо такое-то.

Производительность дело растяжимое и в первую очередь зависит от тарифных планов, железа и доп. услуг.

Последние тесты радиуса дали следующий результат: 550-750 пакетов в секунду с таймаутами до 1с на всех типах авторизаций с загрузкой одного ядра процессора около 35-40%. При установленном аккаунтинг интервале в 1 минуту можно прикинуть, что это 42000 сессий онлайн. В реальности, цифра будет раза в 2 меньше, но это всё равно показатель.

NetFlow коллектор переваривает поток статистики в 5-8 мегабит, потребляя при этом 50-60% ресурсов одного ядра процессора. Опять же загрузка сильно зависит от количества классов трафика и размера абонентской базы.

По ядру - 10-20-30 тысяч абонентов. Не вижу преград сделать и больше. Ядро формирует кэши парой запросов в бд и потом работает с ними, периодически обновляя и создавая определённые структуры данных, которые потом можно быстро и удобно обработать.

Вот время работы треда, списывающего абонентскую плату равными частями на протяжении расчётного периода у небольшого провайдера с абонентской базой в 200 человек:

PSALIVE: Period. service thread run time: 0.03

Умножаем цифру на 10, получаем 2000 абонентов и 0.3 секунды. Пускай это будет даже 1 секунда, но порядок цифр можно всё равно себе представить.

 

Всё это тестировалось на 4-ядерном AMD Phenom c 4 GB DDRIII.

 

Уверен, что через перловые скрипты можно многое сделать, чего нет у вас в интерфейсе и тем более за несколько кликов.

Я тоже в этом уверен, но вопрос в том лезете вы в скрипты сразу, потому что нужного фуонкционала нет или дописываете их как обработчики каких-то событий, генерируемых биллингом. Разница в том, что один раз что-то поправив вам придётся при каждом обновлении системы опять лезть искать места где вы что-то меняли и опять это менять. Согласитесь, что неудобно.

 

И насчет сертификата все-таки озаботьтесь, вы же его здесь в России продаете, а не в Папуа — Новая Гвинея. :).

Спасибо за совет :) Уже обратились в соответствующий орган. Ждём ответа.

Изменено 27 сентября, 2011 пользователем dolphinik

[Saab95]

я бы все таки вам посоветовал прочитать что такое очереди, прежде чем говорить о том, что с симпле ни чего не будет при 100% загрузки канала, канал заберут себе клиенты которые используют торрент, а остальные получат остатки которые будут ой как не сладки, и что вообще из себя представляет симпле (дословно - частный случай) это не для провайдера.

 

Так если авторизация по PPPoE, то там никакие очереди не создаются ведь, режется где-то внутри микротика на основе профилей. Поэтому никаких проблем с балансировкой нагрузки быть не должно.

[dolphinik]

Создаются.

[Saab95]

Создаются.

 

Тогда скажите, пожалуйста, где они? Т.к. имея кучу клиентов PPPoE никаких очередей нигде не наблюдается, единственное что нашел это правила change MSS

 

[dolphinik]

Если их нет - значит в access accept не было параметров, указывающих скорость.

[sherwood]

Тогда скажите, пожалуйста, где они? Т.к. имея кучу клиентов PPPoE никаких очередей нигде не наблюдается

вы про какие очереди думаете? я имел ввиду работу шейпера в частности очередь PCQ.

вопрос к разработчикам:

1.подробный принцип работы оплаты через киви кошелек, на сайте у вас написано, но не черта не понятно. особенно настораживает то что идет привязка к ID терминала, то есть абонент сможет платить только через один терминал указанный у него в веб оснастке.

2.списание средств с абонента, если например клиент не оплачивает на текущий месяц средства, то в следующий месяц ему еще будет начислена абонентка, то есть было у него например минус 500р, на следующий месяц уже минус 1000. интересует алгоритм срабатывания.

Изменено 28 сентября, 2011 пользователем sherwood

[Saab95]

Если их нет - значит в access accept не было параметров, указывающих скорость.

 

Были, в том-то и дело что какое-то не соответствие получается. В профилях указана максимальная скорость. Попробуйте сами и увидите что нигде не появляется в правилах ограничение скорости=)

[dolphinik]

Тогда скажите, пожалуйста, где они? Т.к. имея кучу клиентов PPPoE никаких очередей нигде не наблюдается

вы про какие очереди думаете? я имел ввиду работу шейпера в частности очередь PCQ.

вопрос к разработчикам:

1.подробный принцип работы оплаты через киви кошелек, на сайте у вас написано, но не черта не понятно. особенно настораживает то что идет привязка к ID терминала, то есть абонент сможет платить только через один терминал указанный у него в веб оснастке.

2.списание средств с абонента, если например клиент не оплачивает на текущий месяц средства, то в следующий месяц ему еще будет начислена абонентка, то есть было у него например минус 500р, на следующий месяц уже минус 1000. интересует алгоритм срабатывания.

Никакой привязки к конкретному терминалу нету. В настройках скрипта указывается ID провайдерского кошелька, от имени которого будут выставляться счета.

1. В биллинге реализовано 2 схемы оплаты.

1.1 Официальная и неудобнная, но безопасная для абонента.

1.2 Неофициальная и удобная, но опасная для абонента :)

 

1.1 - Первый механизм стандартный - биллинг выставляет счёт абоненту и показыает ссылку, перейдя по которой абонент подтвердит платёж на сайте qiwi. Раз в 5 минут специальный скрипт коннектится к кошельку провайдера, проверяет какие счета были оплачены и зачисляет деньги абоненту на счёт.

 

1.2 Реализация qiwi в ExpertBilling позволяет выставить счёт и сразу же подтвердить его. При этом деньги попадают на баланс сразу. Для того, чтобы это работало, абонент при оплате вводит свой пароль от qiwi кошелька. Биллинг выставляет счёт и, используя xml возможности qiwi, отправляет запрос на подтверждение счёта.

 

2. Как вам будет удобно - так и сделаете. Биллинг позволяет реализовать любой алгоритм действий.

[sherwood]

1.1 - Первый механизм стандартный - биллинг выставляет счёт абоненту и показыает ссылку, перейдя по которой абонент подтвердит платёж на сайте qiwi. Раз в 5 минут специальный скрипт коннектится к кошельку провайдера, проверяет какие счета были оплачены и зачисляет деньги абоненту на счёт.

для этого на стороне клиента что то надо устанавливать?

 

1.2 Реализация qiwi в ExpertBilling позволяет выставить счёт и сразу же подтвердить его. При этом деньги попадают на баланс сразу. Для того, чтобы это работало, абонент при оплате вводит свой пароль от qiwi кошелька. Биллинг выставляет счёт и, используя xml возможности qiwi, отправляет запрос на подтверждение счёта.

а чем она удобная? абоненту придется каждый раз при оплате лезть в свой кабинет и вводить пароль, а абоненты ой как ленивы. опасность выражается в том что абоненту постоянно надо знать свой пароль или отправка пароля через веб интерфейс?

далее еще вопрос, если абоненты подключены не посредстве к шлюзу а сервер с биллингом стоит в "стороне", какой механизм блокировки клиентов на шлюзе при например отрицательном балансе? статистику на сколько я понял в этом случае биллинг будет снимать с шлюза через NetFlow.

[dolphinik]

для этого на стороне клиента что то надо устанавливать?

Все настройки делаются в скрипте. Прописываете адрес своего кошелька и пароль. Дополнительно могут указываться адрес и данные для доступа к HTTP прокси и атрибуты высталвнного счёта(уведомлять по SMS и проч.)

 

а чем она удобная? абоненту придется каждый раз при оплате лезть в свой кабинет и вводить пароль, а абоненты ой как ленивы. опасность выражается в том что абоненту постоянно надо знать свой пароль или отправка пароля через веб интерфейс?

Удобная тем, что в одном месте абонент вводит номер своего киви телефона, сумму, пароль, нажимает "Оплатить" и продолжает работать дальше, вместо того, чтобы переходить по ссылкам, авторизоваться на сайте киви и подтверждать выставленный счёт.

 

далее еще вопрос, если абоненты подключены не посредстве к шлюзу а сервер с биллингом стоит в "стороне", какой механизм блокировки клиентов на шлюзе при например отрицательном балансе? статистику на сколько я понял в этом случае биллинг будет снимать с шлюза через NetFlow.

А сервер и должен стоять в сторонке. Не забывайте, что ExpertBilling -это биллинг-система, а не шлюз наподобии Айдеко или Трафик инспектор. Конечно, возможен вариант, когда и биллинг и сервер доступа - это одна физическая машина, но логика от этого не меняется.

Управление по-умолчанию осуществляется по SSH/rfc3576, но есть встроеная возможность использовать любой другой протокол. Будь то telnet или snmp. Для каждого из событий в системе (добавление абонента, добавление субаккаунта, активация, деактивация, изменение скорости и т.д.) настраиваются шаблоны команд, в которые будут подставлены переменные и которые будут отправлены на сервер доступа выбранным вам способом. А какую уже логику вы реализуете этим набором команд - это ваше дело. По-умолчанию настроены команды для RouterOS MikroTik, которые формируют адрес листы и создают simple очереди.

[sherwood]

Все настройки делаются в скрипте. Прописываете адрес своего кошелька и пароль. Дополнительно могут указываться адрес и данные для доступа к HTTP прокси и атрибуты высталвнного счёта(уведомлять по SMS и проч.)

так и не понял, это на стороне биллинга делается?

Удобная тем, что в одном месте абонент вводит номер своего киви телефона, сумму, пароль, нажимает "Оплатить" и продолжает работать дальше, вместо того, чтобы переходить по ссылкам, авторизоваться на сайте киви и подтверждать выставленный счёт.

тогда, да этот способ удобнее.

По-умолчанию настроены команды для RouterOS MikroTik, которые формируют адрес листы и создают simple очереди.

в адрес-лист добавляется или удаляется новый авторизованный клиент или лист каждый раз заливается новый согласно данным биллинга? то есть со всей кучей клиентов.

[dolphinik]

так и не понял, это на стороне биллинга делается?

Да. На сервере с биллингом.

 

в адрес-лист добавляется или удаляется новый авторизованный клиент или лист каждый раз заливается новый согласно данным биллинга? то есть со всей кучей клиентов.

Добавляется/удаляется только авторизованный клиент.

[sherwood]

какие ограничения в дэмо-версии?

[dolphinik]

100 аккаунтов.

[JeremyEi]

Скачать бесплатно X-Rumer 7.0 можно тут: google.com

пишите личное сообщение или в I.C.Q. 17612621

[dolphinik]

Если кому будет интересно - в EBS появился хелпдеск и система учёта оборудования провайдера с возможностью контроля выданного оборудования абонентам.

По хелпдеску написано тут. В виках более подробная статейка по настройке.

На сайте размещена свежая демка на 100 аккаунтов и обновлён интерфейс кассира. Будет интересно узнать ваше мнение.

[rain63]

Система не плохая, вполне не плохо работает. Я как человек плохо шарящий в сетевых делах легко смог её победить. Ещё конечно не мешало бы как нибудь реализовать оплату через банковские карты.

[DD-WRT]

Мы у себя используем EBS уже года 2 ил 2,5, начинали с 1.3 версии, с сапортом туговастенько, но не безнадежно !!!