>Насчет архитектуры. Реализовывать все внутри СУБД звучит гордо, круто и >красиво. А Вы пробовали это дело ставить на поток. Я видел два самописных
>билинга - один написан под MSSQL и все что можно запихано
>в него и nibs. Результат не в пользу MSSQL - nibs
>авторизовывает юзера за 0.5-1 секунду, MSSQL 8-10 сек, причем он тратит
>столько ресурсов, что становится грустно...
Да у меня на работе работает именно такой билинг. Тормозить начинает только когда данных скапливается более чем за полгода. >Автор пишет продукт и пишет к нему документацию, если Вас она не
>устраивает - заплатите деньги, я уверен - он с радостью напишет
>ее персонально под Вас, если не хотите платить, то есть смысл
>довольствоваться тем что есть.
Слабая документация эта самая главная проблема open source проектов.
На cake специально написана документация по шагам, чтобы меньше вопросов, при установке.
>Я готов с Вами спорить на что угодно, если я сейчас попытаюсь поставить >Ваш биллинг у меня возникнет
>куча вопросов, которые не будут освещены в Вашей доке.
Начинай. ;)
>Ядром всего есть freenibs.
А что есть ядро база? Я думаю там мало, что осталось от FreeNIBS.
>Да, то что Вы говорите звучит красиво и заманчиво, но попробуйте это
>дело поставить на поток, когда надо обсчитать несколько сотен >пользователей. в
>этом случае быстрота обсчета и потребление ресурсов базой будет значительно уступать
>модулю, написанному на C.
С базой вы будете работать чистым SQL так ? Причем к запросам RADIUS'а добавятся запросы модуля на C. А далее эти SQL запросы в базе сначала скомпилируются, а затем запустятся. Хранимая процедура компилируется один раз при создании, перекомпилируется при изменении. Далее хранится в скомпилированном виде и просто вызывается. Т.е. вызов хранимой процедуры менее затратен чем чистый вызов SQL.
>только потому что при больших нагрузках он ведет себя адекватней mysql.
А что вы хотели?
>точно Вам говорю. Нет смысла ставить для обсчет 10 пользователей Oracle
Зависит от задач этих десяти пользователей. Если у них есть лишние 10 тыщ баксов почему бы нет ?
>Стрельба из пушки по воробьям - это не есть гуд.
Обоснуйте почему я должен использовать MySQL с SQL89, если использование PostgreSQL с SQL92 (хотя там не полная реализация) более целесобразно. Трудоемкость написания хранимой процедуры, ниже написания модуля на C или на Perl. К тому же компактнее и менее затратно по отношению к операционной системе.
>Правильно. Где больше возможностей, там и сложнее конфигурация. Системы с >большими возможностями никогда не настраивались нажатием одной кнопки или
Сложность настройки FreeNIBS проистекает от его архитектуры, а не его возможностей. Можно добавить в Cake теже фичи, что есть во FreeNIBS. Но сложность установки не возрастет. Более того изменятся только файлы схемы данных и интерфейсного модуля.
>>Сброс пользователя при помощи pppd с линии.
>упс. nibs отдает pppd session-timeout благодаря которому пользователь >благополучно улетает с линии.
Внимательно читаем. При помощи pppd и по траффику. Да pppd это умеет.
Причем плюс минус 30 кб. И по session-timeout тоже умеет сбрасывать.
>если пользователю не возможно расчитать session-timeout (в случае, если пользователя надо
>обсчитывать по трафику), то там есть такой волшебный скрипт который скидывает
>его с линии при достижении 0-го баланса. причем в него можно
>писать все что хочешь - и kill по rsh и по
>snmp.
Вопрос какой волшебный скрипт ? checkrad.sh ? У него больше погрешность.
И он запускается из cron'ом.
>Теория не всегда сходится с практикой, на практике есть масса нюансов.
Просто проэктировщики не всегда выбирают удачную архитектуру. А разработчики, не всегда удачно ее реализуют.
