>Я вообщем то имел ввиду, что информацию от циски можно обрабатывать анализируя
>radutmp, а не то что надо это или не надо периодически
>слать эту информацию.
ну наконец-то до сути добрались :). я же с самого начала нашего с тобой разговора именно на этом акцент делал: надо прежде чем данные обрабатывать, быть уверенным в том, что они достоверны (отражают текущее состояние). radius сам по себе этого обеспечить не может, да и не должен - это не его задача. он только обрабатывает что к нему пришло и дает ответ. а что там после его ответа случилось его не волнует. и информацией он может оперировать устаревшей - что к нему последний раз пришло, тому и верит. поэтому не лишнее "дергать" его переодически новыми данными.
Может быть оно так действительно надежнее. Просто я
>этого не делаю, так мне оно пока не надо -
и об этом я говорил - все решает поставленная задача
>пакетов затерянных навсегда на пути к киске - такого еще не
>случалось ни разу, по крайней мере последние года два (хм, пожалуй
>я данный феномен объяснить вообще не смогу :)), да и
да и у меня не было таких проблем, за последние два года. а сейчас вот получилось так, что радиус-сервер от моей циски за 200 км с лишним стоит. так что все эти мои "придумки" не из пальца высосаны :)
>со стоп-пакетами все было нормально если перед перезагрузкой кошака принудительно
>очистить все линни.
>
дык еще бы - ты таким путем все сессии нормально завершаешь, получаешь своим радиусом стоп-пакеты - и дело в шляпе
>Насчет клиентов. У меня была задача (точнее одна из задач), как только
>у клиента кончаются деньги и долг достигнет определенной суммы, его надо
>сразу отключать и больше не давать ему входа, пока долг не
>будет погашен, так что твой фокус с "потом нагонит" здесь бы
>не прошел.
еще как замечательно прошел бы :). видно ты не совсем этот "фокус" понял. учитывая наши доисторические АТС, которые повсеместно (и учитывая прочие причины), больше шансов на то, что ты получишь NULL поле структуры radutmp из за некоректного отвала пользователя, чем то что клиент будет через каждые 3 мин рвать связь со своим провайдером и восстанавливать ее снова, чтобы работать на халяву (это первое). ты при любой нестандартной ситуации снимаешь со счета клиента чуть больше (за 3 мин), чем надо было бы. я не говорил, что не должно быть механизма, который "отбивает" нормально работающего пользователя, у которого кончились деньги в течении 1-4 с :). я говорил, что для норамльного биллинга демонов пописать придется (это второе). сортировка пользователей на "нормально работающих" и отвалившихся осуществляется обработкой alive-пакетов с циски (это третье). в конечном счете ты всегда оказываешься в выигрыше (это четвертое)
(3 мин было приведено в моих придыдущих постингах как пример. если не жаль свой сервак и клиентов - можешь поставить меньший интервал. однако моя практика показывает, что оптимальное значение от 3 до 5 мин)
Теперь что такое 2 часа. Это твои 40 клиентов
>переседевших по 3 минуты - наверняка за день у тебя больше
>набегает этих лишних минут, а циску, как мы например, в среднем
умножь все что я скаал выше на 40 и я в 40 раз больше в выигрыше окажусь при нестандартных ситуациях. а при нормальной работе ничего не потеряю.
>грузят раз в год. И кроме того, перед перезагрузкой мы все-таки
>делаем clear all... ;-)))
>
ну счет clear all коментарий уже выше был, а насчет перезагузки - ежу понятно, что не каждый день это происходит :))
>На счет гибкости. Представь себе - этого демона (кстати пока одного единственного
тоже не есть хорошо, что "единственного". на мой взгляд не стоит не связанные м/ду собой задачи одному демону поручать. этот же "единственный", к тому же уже выполняет выполняет задачу, которую можно было решить и средствами демона radius. если честно - я не понимаю зачем такое надо было делать.
>- наверное билинг не очень серьезный :)))) я написал именно для
>достижения этой гибкости. Пришлось конечно немножко поднапрячь мозги, но я бы
>не назвал это гемороем - даже для меня, умеренно-умного, задача чуть
>выше среднего. Кроме ночных,вечерних и дневных, есть еще скажем только праздничные,
>только будничные, определенное число часов по одному, более дешевому тарифу, по
>достижении этого числа часов по другому, более дорогому. Далее, если пользователь
>вошел когда действовал дневной тариф, а вышел когда действует вечерний, то
"умеренно-умные" ч/з iptables все считают (не в обиду никому сказано - для определенного круга задач тоже очень неплохой вариант) - так что не надо прибедняться :).
>дневное время подсчитается по дневному, а вечернее по вечернему тарифу ну
>и так далее. Не буду утомлять еще и алгоритмом, скажу только,
>что он довольно простой. Всего то около 50Kb С++ исходников +
>пара ранее написанных мною либ. Хотя может для кого-то это и
>геморой.
>
а как сложность алгоритма связана с количеством кода его реализующего? зависимость на мой взгляд отнюдь не прямая :). на самом деле у меня было желание, когда я писал на счет прогнозирования отключения, в предыдущем постинге, предложить тебе еще один демон состряпать (специально обученный), но ты уже ухитрился сделать "все в одном флаконе" :)
>И все это в режиме реального времени, а не с периодичностью в
>3 минуты (уже третий месяц пошел - пока полет нормальный :)))).
дык, "сколько вешать в граммах"? :о) несколько раз уже повторял - все от задач зависит. насколько надо тебе, настолько и делай. тока про возможность развития не забывай - сейчас если что, будешь демона, который "один за всех" переписывать...
>Ну, а если все таки возникнут проблемы (сомневаюсь аднака), то я
>пожалуй воспользуюсь твоей подсказкой насчет update-periodic ;-))).
>
если нет проблем, значит уже умер ;-))
>P.S. Меня этот тред тоже несколько утомил, но ты тут такие мрачные
>картины потери трафика расписал... ;-)
не так страшен черт... :)
всего самого лучшего!
Вариант для распечатки
OpenNET: Виртуальная конференция (Public)
on
25-Июн-03, 11:09 (MSK)
