BiTel

Привет.
Помогите пожалуйста получше разобраться в логике работы приостановленных и закрытых сессия. Речь идет только о RADIUS сессиях.
Вопросы:
1)Допустим в течении connection.suspend.timeout не приходят RADIUS update и сессия переводится в состояние приостановлена.
Написано что: "Приостановленная сессия не учитывается в ограничении на количество сессий"
Значит ли это, что в этот момент клиент может зайти (например с тем же логином но с другого компа) и его пустят несмотря на ограничение скажем в 1 активную сессию.?
Далее первая сессия получит UPDATE пакет перед наступлением таймаута заданного в connection.close.timeout и первая сессия будет переведена в активное состояние.
Получится что будут присутствовать две сессии несмотря на установленный лимит в 1 сессию. (Адреса допустим динамические)

2) что имеется ввиду под: "connection.finish.timeout. Это позволяет, в частности, реализовать сбор "запоздалой" информации о трафике, которая может прийти после Stop-пакета".
Какая еще информация о трафике может придти после Stop - пакета? Это имеет смысл только когда кроме радиуса одновременно используется сбор трафика по netflow, а при использовании только радиуса connection.finish.timeout можно устанавливать равным connection.suspend.timeout?

3)>> После перезапуска Accounting для всех сессий считает время последней активности от момента старта. Это сделано для того, чтобы при возможном долгом простое Accounting после запуска не начал завершать все сессии по таймауту.
Может кто-нибудь пояснить, что именно тут происходит? Я не совсем понимаю. Какой именно алгоритм? Как он считает?
Accounting смотрит время последнего пришедшего Update - пакета для каждой сессии, а не время старта? Откуда он берет последний Update если процесс Accounting был остановлен и Updatы никто не получал и не обрабатывал?
В каком случае он "завершил бы сессии по таймауту" ? Может пример, как могло бы быть *плохо" и как есть "хорошо"?
Спасибо!

1. Да. Можно также установить connection.suspend.timeout равным connection.close.timeout, тогда сессия завершится в биллинге. А при получении RADIUS-Update-пакета создастся новая.
При двух активных сессиях и ограничении на одну биллинг должен попытаться сбросить/ограничить доступ к более старой.

2. Да, для Netflow. Нет, значение finish timeout идет от времени стопа сессии, т.е. обычно указывают 5-10 секунд.

3. Здесь речь именно о работе suspend/close timeout. Время последнего Update-пакета есть в поле БД "(последняя) Активность", но после перезапуска InetAccounting это значение не используется, т.к. InetAccounting мог быть выключен в течении времени close timeout или больше и, соответственно, не получал Update-пакеты. Если бы он использовал время из поля "Активность", он бы закрыл сессии по таймауту. Поэтому при старте он у себя подменяет это значение на значение времени старта, а уже при получении следующего Update-пакета для сессии обновляет на новое и использует его.
Изменили немного формулировку в документации.

Создастся всегда или только еcли connection.start.fromUpdate=1 ?

Только если connection.start.fromUpdate не равен 0, по умолчанию он равен 1.

И что получится, по Update создаться новая и тут же будет сброшена? Какой будет точный алгоритм работы?

Создастся новая, только если сейчас нет сессии с таким Acct-Session-Id.
Т.е. этот флаг на случай, если пропустили Start-пакет или уже закрыли по таймауту Update-пакетов, а теперь вдруг пришел Update по этой сессии.

Ну так я и хочу четко понять как оно будет
Если пришел Update для которого нет активной сесси с таким же Acct-Session-Id то.....
1) если connection.start.fromUpdate = 0 - его просто отбрасываем. Это даже мне понятно. )
2) если connection.start.fromUpdate != 0 то.... дальше я не очень понимаю. Вроде как по описанию сессия должна и будет создана.
Вариантов тут я вижу два:
а) мы пропустили старт, тогда эта новая созданная сессия проблем никаких не создаст.
б) сессия уже была закрыта по connection.close.timeout, но на NAS она еще существует, клиент сидит в инете, и это пришел очередной UPDATE.
НО внезапно! в этот момент может быть активна другая сессия с таким же логином и лимит сессий на логин будет превышен.
Если мы создадим новую сессию по "старому UPDATE" будут работать оба. Одного надо скинуть. Кого, как, когда, по какому алгоритму?

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