Project

General

Profile

Проблема с ограничением 1токен = 1 сессия

Added by александр Мохнов about 1 year ago

Пытаюсь ограничить 1токен = 1 сессия В скрипте проверке токена отправляем на flussonic header('HTTP/1.0 200 OK') header("X-AuthDuration: 3600"."\r\n"); header("X-UserId: ".$_GET['token']."\r\n"); header("X-Max-Sessions: 1"."\r\n"); В течении 5 мин все сессии кроме последней обрываются. Но бан по токену не происходит. При перезапуске потока он благополучно стартует. Если плеер с циклическим перезапуском - то вообще никаких обрывов не ощущается. Пробовал удалять из заголовков header("X-AuthDuration: 3600"."\r\n"); - результат тот же Тестировал на версиях 4.5.14 и 4.5.15 - результат одинаковый Как побороть данную ситуацию?


Replies (22)

RE: Проблема с ограничением 1токен = 1 сессия - Added by александр Мохнов about 1 year ago

мпег вообще не лочися, ХЛС - через 30-60 сек перезапускается

RE: Проблема с ограничением 1токен = 1 сессия - Added by александр Мохнов about 1 year ago

А X-AuthDuration: 3600 - это 1 час, но его никак нет

RE: Проблема с ограничением 1токен = 1 сессия - Added by Vladimir Gordeev about 1 year ago

Какими протоколами пользуетесь? HLS? RTMP?

RE: Проблема с ограничением 1токен = 1 сессия - Added by александр Мохнов about 1 year ago

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

RE: Проблема с ограничением 1токен = 1 сессия - Added by Vladimir Gordeev about 1 year ago

В последнем релизе 4.5.20 были исправления по ограничению сессий для persistent-протоколов, в вашем случае для mpegts. Посмотрите пожалуйста.
Почему у вас некорректно работает ограничение по HLS пока непонятно.

RE: Проблема с ограничением 1токен = 1 сессия - Added by александр Мохнов about 1 year ago

Установили 4.5.20 протестировали.
Раньше хоть сессии обрывало, но временно не банило, теперь даже сессии не обрывает. Проверяли mpegts и hls раздачу.

На флюс, от скрипта проверки токенов, все приходит

RE: Проблема с ограничением 1токен = 1 сессия - Added by Vladimir Gordeev about 1 year ago

Мы недавно переделали работу ограничения сессий, в грядущем релизе 4.5.23 улучшения уже будут доступны.
Если вам интересно протестировать, напишите на , мы сможем выслать вам промежуточную сборку флюссоника.

RE: Проблема с ограничением 1токен = 1 сессия - Added by Sergey M 11 months ago

В версии 4.5.26 не работает ограничения сессий при переключении просмотра между HLS и MPEGTS. Вернее работает слишком активно и блокирует новую сессию вместо старой. У нас клиенты Live получают по MPEGTS, а DVR по HLS. Так вот если клиент переключается между Live и DVR, то первые 30 секунд новая сессия не работает. В версии 4.5.17 все работало отлично. Пока пришлось полностью отключить ограничение сессий, потому что клиенты начали массово жаловаться.
Я попробую воспроизвести проблему на тестовом сервере без middleware чтобы более точно написать что происходит.

RE: Проблема с ограничением 1токен = 1 сессия - Added by Vladimir Gordeev 11 months ago

Я посмотрю что там может быть такое.

RE: Проблема с ограничением 1токен = 1 сессия - Added by Sergey M 11 months ago

Спасибо. Кстати, я уже когда то предлагал как можно значительно упростить эту задачу. Насколько я понимаю вся проблема в том что по HLS невозможно отличить более новый токен от старого. Так вот я предлагал чтобы auth скрипт возвращал время создания токена, т.к. токены генерирует middleware который точно знает когда он создал токен. Тогда flussonic не придется гадать какой токен новый, а какой старый...он просто проверит время создания возвращенное auth скриптом и отрубит более старый и все. А если скрипт не вернет время, то тогда уже будет работать тот вариант который работает сейчас.

RE: Проблема с ограничением 1токен = 1 сессия - Added by Vladimir Gordeev 11 months ago

в том что по HLS невозможно отличить более новый токен от старого

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

RE: Проблема с ограничением 1токен = 1 сессия - Added by Sergey M 11 months ago

ну как же этой проблемы может не быть. Представте что middleware генерирует для каждого клиента HLS ссылки с разными токенами. Клиент использует первую ссылку, потом переходит на вторую и тогда первая перестает работать, а через пол часа/день/неделю он опять использует первую ссылку. Flussonic физически не может помнить первую ссылку и он думает что это новая ссылка и вместо того чтобы ее заблокировать, он блокирует вторую, хотя она более новая.
Это конечно экстремальный вариант, но если таких ссылок не 2,а 10-20 (клиент перематывает каждые 10 секунд) и они приходят с частотой несколько раз в минуту, то очень не просто разобраться какую ссылку блокировать. А если ввести время, то тогда вообще ничего думать не надо и все будет работать стабильно и предсказуемо на 100%. Так что проблема как раз есть и Максим много раз об этом писал.

RE: Проблема с ограничением 1токен = 1 сессия - Added by Sergey M 11 months ago

Конечно в данном конкретном случае проблема не в этом, но в общем случае с HLS проблема есть и ее можно легко решить.

RE: Проблема с ограничением 1токен = 1 сессия - Added by Vladimir Gordeev 11 months ago

ну как же этой проблемы может не быть.

Ну флюссоник оценивает какую сессию блокировать по времени открытия сессии. Долна блокироваться более старая. А сколько работает сессия -- 20 секунд или сутки, это не важно.

Такое поведение может быть в чём-то неудобным?

RE: Проблема с ограничением 1токен = 1 сессия - Added by Sergey M 11 months ago

Ну флюссоник оценивает какую сессию блокировать по времени открытия сессии. Долна блокироваться более старая. А сколько работает сессия -- 20 секунд или сутки, это не важно.

Так в том то и проблема что в общем случае с HLS невозможно отследить время открытия сессии. Для HTTP MPEGTS все просто - открыли TCP соединение это и есть сессия и пока TCP соединение открыто сессия есть и можно узнать ее время, как только закрыли - сессии нет. А в HLS нет такого потому что стрим забирается кусками и между этими заборами невозможно определить активна сессия или нет потому что клиент может просто проигрывать текущий кусок, или он мог выключить приставку, а мог поставить на паузу. И сервер физически не может различить два этих состояния. Поэтому сервер должен сам отслеживать когда HLS сессия реально отвалилась и единственный способ это сделать - timeout. Но если слишком долго хранить сессии которые давно не забирались, то тогда это будет расходовать слишком много ресурсов. А если хранить их не долго, то тогда есть шанс попасть в ситуацию когда старая сессия будет опознана как новая. Но в любом случае, при запросе сегментов с разницей даже чуть больше чем timeout, сессия некорректно определяется как новая и выбивает реально новую сессию. Причем количество реализаций разных клиентов, прокси и т.п. не может гарантировать что куски будут забираться равномерно и не будет превышен timeout. Например клиент может сразу загрузить 10 первых сегментов для буфферизации, а потом минуту молчать и если таймаут меньше минуты, то время открытия сессии будет потеряно.

RE: Проблема с ограничением 1токен = 1 сессия - Added by Vladimir Gordeev 11 months ago

Например клиент может сразу загрузить 10 первых сегментов для буфферизации, а потом минуту молчать и если таймаут меньше минуты, то время открытия сессии будет потеряно.

Я вас понял.

Вот этот таймаут протухания сессии можно задать через X-AuthDuration через auth.
По-умолчанию он равен 30-ти секундам. (Кстати, именно поэтому у вас открывалась сессия на DVR через 30 секунд).

Но если слишком долго хранить сессии которые давно не забирались, то тогда это будет расходовать слишком много ресурсов.

Не думаю что это будет создавать проблемы. Вы сталкивались с какими-то проблемами при увеличении длительности сессии?
Я думаю можно смело ставить длительность в час или даже больше.

RE: Проблема с ограничением 1токен = 1 сессия - Added by Sergey M 11 months ago

У нас стоит X-AuthDuration = 36000, неужели это означает что все HLS сесии висят по 10 часов? В Web админке сессия пропадает через 30 секунд даже если X-AuthDuration = 36000...или она остается где-то внутри и просто не считается?

RE: Проблема с ограничением 1токен = 1 сессия - Added by Sergey M 11 months ago

Оказывается что сейчас все намного интереснее...Оказывается что если попытаться открыть вторую сессию, то она и блокируется вместо того чтобы выкинуть первую сессию (по крайней мере так работает HTTP MPEGTS сессии). Именно поэтому и не работает переход между HLS->MPEGTS...потому что HLS сессия считается открытой еще 30 секунд и все это время попытки открыть MPEGTS сессию даже с новым токеном отбиваются с 403 ошибкой.

RE: Проблема с ограничением 1токен = 1 сессия - Added by александр Мохнов 5 months ago

Так в итоге что с проблемой перехода между HLS->MPEGTS ?

RE: Проблема с ограничением 1токен = 1 сессия - Added by Sergey M 5 months ago

Пока ничего. Проблема до сих пор не решена.

    (1-22/22)