madf

Выдержка из $ ./sgconf ... To change user's upload traffic value use: sgconf -s <server> -p <port> -a <admin> -w <admin_pass> -u <user> --u0 <traff> [--u1<traff> ...] To change user's download traffic value use: sgconf -s <server> -p <port> -a <admin> -w <admin_pass> -u <user> --d0 <traff> [--d1<traff> ...] ...

user.cpp Метод ProcessDayFee Падение при удалении проявляется не всегда. Кое-какие фиксы в этом направлении были, но пока я не гарантирую того что он не будет при этом падать. Просто такое поведение редко проявляется.

В этой версии вполне может не быть. Попробуй прописать в конфиге FullFee = yes

В версию, которая лежит на оффсайте не включены только исправления от den68 в модуле mysql.

По идее на сайте все должно быть самое свежее. С помощью projects/convertor можно конвертнуть откуда угодно куда угодно.

Ну в логе ничего нету. Если проблема будет повторяться - собери в debug-режиме и посмотри что он на консоль выведет при падении. Желательно получить корку и отослать вместе с бинарями мне (faust@stg.dp.ua).

Никто и не утверждал что ether_cap идеален. Напротив, если не ошибаюсь, в документации сказано, что для получения абсолютно точного результата следует использовать именно ipq_cap. И я всегда говорю, что ether_cap может пропускать пакеты - и это нормально.

В чем проявилось зависание?

Совершенно верно.

При нулевом балансе авторизатор никак не уведомляет об этом пользователя. Наличие денег на счету никак не влияет на процесс авторизации. То есть, при нулевом балансе пользователь вполне успешно авторизуется в системе. Сам по себе авторизатор отключаться не должен.

А он и не ломался. Уже тысячу раз говорили: cap_ether не гарантирует 100% захвата трафика! При высоких нагрузках на сервер и при большом трафике он может пропускать пакеты.

Они могли быть в системе не полный месяц. ТОгда абонка снимается только частично. Или они могли быть заморожены. Посмотри в сторону параметра FullFee в конфиге.

Если в процессе отключения приходит запрос на подключение - такой запрос считается ошибочным и не обрабатывается. Пользователь зависает в фазе отключения некоторое время, после чего снова считается подключенным. Если в подключенном состоянии пользователь не отвечает на Alive-запросы сервера в течении некоторого времени - он считается отключенным. При этом очищается индекс ip-адресов. Если пользователь "зависает" в процессе подключения - через определенное время он сбрасывается в состояние "отключен". Да, еще. В этом контексте слово "подключен" следует читать как "авторизован", а "отключе

Никаких таблиц. Все зпросы на подключения представляют собой UDP-пакеты. STG просто последовательно их вычитывает и обрабатывает. Процесс авторизации разбит на несколько фаз. У каждой из них есть таймаут. При привышении считается что пользователь отключился и все связанные с ним кеши и индексы очищаются. В STG практически нет таблиц фиксированного размера - используются контейнеры STL. По этому ограничений никаких не налагается.

Тем-же, чем и divert от bpf. Переключаться, соответственно. сменив название модуля в конфиге Вобще, все это есть в документации.

На cap_ether или на cap_ipq?

Если честно - тогда я вобще ничего не понимаю. Все должно работать. Под рукой есть какой-нибуть другой дистрибутив? Попробовать собрать на нем?

Для такого - хз. На серваки, думаю, лучше Debian ставить

У меня на Pentium I 66MHz, 32 Mb RAM, 650 Mb HDD крутился STG под Gentoo Linux - раздавал инет на 3 человек. Работал через cap_ether (аналог cap_bpf). Без потерь, вполне успешно. Понятное дело, никаких Apache/MySQL/FreeRADIUS там небыло.

Все относительно. Я не могу скзать, что быстрее: iptables или ipfw. Ядро Linux или ядро FreeBSD. Все это зависит от кучи разных вещей. Да и понятие "слабенькой машинки" - это сферический конь в вакууме. Для кого-то и 320-процессорный монстр слабоват. А для некоторых задач с головой хватит пня 166. Нужно проверять.

divert физически не может пропускать пакеты. По этому и выше точность и выше нагрузка. Если машинка слабенькая - bpf будет много терять.

Используй divert bpf может пропускать пакеты при интенсивном сетевом обмене

Всяческие серверо-независимые чаты стоит использовать в сетях до 10 машин. IRC - самое нормальное решение, благо клиентов достаточно. Еще стоит посмотреть в сторону Jabber и конференций (юзеры получат и IM, и чат). Можно прикрутить гейты для ICQ и IRC при необходимости.

Для FreeBSD нужно использовать gmake а не make gmake install поможет отцу русской демократии

Версия Фри? И проверь системное время. Если время модиикации файлов в будущем - вполне может и зациклиться.