forum.bitel.ru :: Просмотр темы - Не работает ограничение количества сессий (вер. 4.6)

Вероятнее всего, у вас UPDATE пакеты идут реже, чем интервал указанный в конфигурации модуля в max.update.timeout . Т.е. между апдейт пакетами соединение успевает пометиться как неактивное.

#для режима UPDATE - время после последнего UDPATE пакета, по истечении которого сессия считается неактивной
#(не учитывается в подсчете числа одновременных соединений)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
max.update.timeout=120

Можете RADIUS запросы по любой сессии выложить?

Автор:	krm [ 13 авг 2009, 21:56 ]
Заголовок сообщения:	Не работает ограничение количества сессий (вер. 4.6)
В версии 4.6 при достаточно частых попытках авторизации (раз в 20 - 30 сек) очень высока вероятность успешной авторизации для второй сессии при ограничении в 1 сессию. Эта проблема поднималась ранее http://www.bgbilling.ru/forum/viewtopic ... 1%F1%E8%E8, но, по видимому, она до сих пор не решена. Если возможно, сообщите алгоритм проверки на количество сессий при авторизации, чтобы понять как оптимизировать систему для предотвращения подобных ошибок.

Автор:	Администратор [ 14 авг 2009, 11:23 ]
Заголовок сообщения:
Вообще если даже сессия авторизуется, ее через некоторое время сбросить должно. 20 авторизаций в секунду вообще как делают?

Автор:	krm [ 14 авг 2009, 13:39 ]
Заголовок сообщения:
Не 20 авторизаций в секунду, а одна авторизация в 20 секунд. Через какое время должно сбросить? И где это можно настроить?

Автор:	Администратор [ 14 авг 2009, 15:07 ]
Заголовок сообщения:
У вас режим обсчета случаем не checker стоит в конфигурации? Поставьте update. Раз в 30 секунд проверяет..

Автор:	krm [ 14 авг 2009, 19:30 ]
Заголовок сообщения:
У нас стоит dialup.workmode = 1, то есть режим update, и тем не менее двойные сессии продолжаются десятки минут и часы, то есть не сбрасываются.

forum.bitel.ru http://forum.bitel.ru/

Не работает ограничение количества сессий (вер. 4.6) http://forum.bitel.ru/viewtopic.php?f=5&t=2734	Страница 1 из 1

Автор:	Администратор [ 17 авг 2009, 14:40 ]
Заголовок сообщения:
А UPDATE пакеты идут вообще?

Автор:	krm [ 17 авг 2009, 18:52 ]
Заголовок сообщения:
UPDATE пакеты посылаются каждые 5 минут. Вот хронология событий для некоторого аккаунта: 17 13:59:20 - начало 1-й сессии 17 16:10:04 - Превышен лимит сессий - для 2-й сессии 17 16:10:26 - Превышен лимит сессий - для 2-й сессии 17 16:11:53 - Превышен лимит сессий - для 2-й сессии 17 16:31:25 - Превышен лимит сессий - для 2-й сессии 17 16:31:57 - Начало 2-й сессии Далее каждые 5 минут посылаются UPDATE пакеты для обеих сессий, трафик и время сессий увеличиваются.

Автор:	krm [ 24 авг 2009, 11:29 ]
Заголовок сообщения:
Есть какое-то решение? Сейчас, как временную меру, наряду с ограничением по логину используем скрипт по контролю соответствия МАК адреса, но это не особенно удобно. Хотелось бы чтобы заявленные функции работали.

Автор:	Администратор [ 25 авг 2009, 13:13 ]
Заголовок сообщения:
У вас получается воспроизвести ошибку самостоятельно? Выложите скрины, как настроен логин, как у него установлено ограничение по сессиям. Выборку из connection.log 2х сессий под одним логином выложите.

Автор:	krm [ 26 авг 2009, 21:56 ]
Заголовок сообщения:
Отправлено в ЛС.

Автор:	Администратор [ 27 авг 2009, 11:24 ]
Заголовок сообщения:
Вероятнее всего, у вас UPDATE пакеты идут реже, чем интервал указанный в конфигурации модуля в max.update.timeout . Т.е. между апдейт пакетами соединение успевает пометиться как неактивное. Можете RADIUS запросы по любой сессии выложить?

Автор:	corban [ 27 авг 2009, 16:36 ]
Заголовок сообщения:
Администратор писал(а): Вероятнее всего, у вас UPDATE пакеты идут реже, чем интервал указанный в конфигурации модуля в max.update.timeout . Т.е. между апдейт пакетами соединение успевает пометиться как неактивное. ну а как же фраза из документации: Код: #для режима UPDATE - время после последнего UDPATE пакета, по истечении которого сессия считается неактивной #(не учитывается в подсчете числа одновременных соединений) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ max.update.timeout=120 Было max.update.timeout=120 Сейчас установим max.update.timeout=360 и попробуем повторить с одновременными соединениями. Цитата: Можете RADIUS запросы по любой сессии выложить? по любой сессии или именно одной из двойных?

Автор:	Администратор [ 28 авг 2009, 10:34 ]
Заголовок сообщения:
Цитата: по любой сессии или именно одной из двойных? Да с любой, просто посмотрите интервал между Update пакетами. А Auth Accept что передается в Acct-Interim-Interval?

Автор:	Администратор [ 28 авг 2009, 10:36 ]
Заголовок сообщения:
Цитата: ну а как же фраза из документации: Ну собственно согласно этой фразе и работает. То, что в скобках - описывает свойства коннекта а не опции. Т.е. неактивное соединение не учитывается в списке активных. Ну чтобы висяки клиенту зайти не помешали если что.

Автор:	corban [ 28 авг 2009, 13:19 ]
Заголовок сообщения:
т.е. для нормальной работы ограничения необходимо, чтобы параметр max.update.timeout был больше времени между UPDATE-пакетами?

Автор:	snark [ 28 авг 2009, 16:53 ]
Заголовок сообщения:
corban писал(а): т.е. для нормальной работы ограничения необходимо, чтобы параметр max.update.timeout был больше времени между UPDATE-пакетами? ну из названия опции же следует что это таймаут между апдейтами, т.е. если на сессию апдейт не пришел в течении времени max.update.timeout значит сессия умерла, например, при аливах раз в 60 сек значение в 120 говорит о том что если в течении 120 сек. не пришло ни одного алива, а должно прийти 1-2 алива, значит сессию можно считать мертвой ... значение max.update.timeout обычно = Acct-Interim-Interval * 2 или 3

Автор:	corban [ 02 сен 2009, 16:59 ]
Заголовок сообщения:
Просто не правильно был понят комментарий к опции. Выставление опции Код: max.update.timeout = ( время между UPDATE пакетами + 60 сек ) решило проблему. Спасибо за помощь.

Страница 1 из 1	Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/