This is a readonly text dump of old forum. New forum https://forum.flussonic.com
Обсуждение эрливидео

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

Added by александр Мохнов over 2 years 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 Sergey M over 1 year ago
Пока ничего. Проблема до сих пор не решена.
RE: Проблема с ограничением 1токен = 1 сессия
added by александр Мохнов over 1 year ago
Так в итоге что с проблемой перехода между HLS->MPEGTS ?
RE: Проблема с ограничением 1токен = 1 сессия
added by Sergey M about 2 years ago
Оказывается что сейчас все намного интереснее...Оказывается что если попытаться открыть вторую сессию, то она и блокируется вместо того чтобы выкинуть первую сессию (по крайней мере так работает HTTP MPEGTS сессии). Именно поэтому и не работает переход между HLS->MPEGTS...потому что HLS сессия считается открытой еще 30 секунд и все это время попытки открыть MPEGTS сессию даже с новым токеном отбиваются с 403 ошибкой.
RE: Проблема с ограничением 1токен = 1 сессия
added by Sergey M about 2 years ago
У нас стоит X-AuthDuration = 36000, неужели это означает что все HLS сесии висят по 10 часов? В Web админке сессия пропадает через 30 секунд даже если X-AuthDuration = 36000...или она остается где-то внутри и просто не считается?
RE: Проблема с ограничением 1токен = 1 сессия
added by Vladimir Gordeev about 2 years ago
> Например клиент может сразу загрузить 10 первых сегментов для буфферизации, а потом минуту молчать и если таймаут меньше минуты, то время открытия сессии будет потеряно. Я вас понял. Вот этот таймаут протухания сессии можно задать через X-AuthDuration через auth. По-умолчанию он равен 30-ти секундам. (Кстати, именно поэтому у вас открывалась сессия на DVR через 30 секунд). > Но если слишком долго хранить сессии которые давно не забирались, то тогда это будет расходовать слишком много ресурсов. Не думаю что это будет создавать проблемы. Вы сталкивались с какими-то проблемами при увеличении длительности сессии? Я думаю можно смело ставить длительность в час или даже больше.
RE: Проблема с ограничением 1токен = 1 сессия
added by Sergey M about 2 years ago
>Ну флюссоник оценивает какую сессию блокировать по времени открытия сессии. Долна блокироваться более старая. А сколько работает сессия -- 20 секунд или сутки, это не важно. Так в том то и проблема что в общем случае с HLS невозможно отследить время открытия сессии. Для HTTP MPEGTS все просто - открыли TCP соединение это и есть сессия и пока TCP соединение открыто сессия есть и можно узнать ее время, как только закрыли - сессии нет. А в HLS нет такого потому что стрим забирается кусками и между этими заборами невозможно определить активна сессия или нет потому что клиент может просто проигрывать текущий кусок, или он мог выключить приставку, а мог поставить на паузу. И сервер физически не может различить два этих состояния. Поэтому сервер должен сам отслеживать когда HLS сессия реально отвалилась и единственный способ это сделать - timeout. Но если слишком долго хранить сессии которые давно не забирались, то тогда это будет расходовать слишком много ресурсов. А если хранить их не долго, то тогда есть шанс попасть в ситуацию когда старая сессия будет опознана как новая. Но в любом случае, при запросе сегментов с разницей даже чуть больше чем timeout, сессия некорректно определяется как новая и выбивает реально новую сессию. Причем количество реализаций разных клиентов, прокси и т.п. не может гарантировать что куски будут забираться равномерно и не будет превышен timeout. Например клиент может сразу загрузить 10 первых сегментов для буфферизации, а потом минуту молчать и если таймаут меньше минуты, то время открытия сессии будет потеряно.
RE: Проблема с ограничением 1токен = 1 сессия
added by Vladimir Gordeev about 2 years ago
> ну как же этой проблемы может не быть. Ну флюссоник оценивает какую сессию блокировать по времени открытия сессии. Долна блокироваться более старая. А сколько работает сессия -- 20 секунд или сутки, это не важно. Такое поведение может быть в чём-то неудобным?
RE: Проблема с ограничением 1токен = 1 сессия
added by Sergey M about 2 years ago
Конечно в данном конкретном случае проблема не в этом, но в общем случае с HLS проблема есть и ее можно легко решить.
RE: Проблема с ограничением 1токен = 1 сессия
added by Sergey M about 2 years ago
ну как же этой проблемы может не быть. Представте что middleware генерирует для каждого клиента HLS ссылки с разными токенами. Клиент использует первую ссылку, потом переходит на вторую и тогда первая перестает работать, а через пол часа/день/неделю он опять использует первую ссылку. Flussonic физически не может помнить первую ссылку и он думает что это новая ссылка и вместо того чтобы ее заблокировать, он блокирует вторую, хотя она более новая. Это конечно экстремальный вариант, но если таких ссылок не 2,а 10-20 (клиент перематывает каждые 10 секунд) и они приходят с частотой несколько раз в минуту, то очень не просто разобраться какую ссылку блокировать. А если ввести время, то тогда вообще ничего думать не надо и все будет работать стабильно и предсказуемо на 100%. Так что проблема как раз есть и Максим много раз об этом писал.
RE: Проблема с ограничением 1токен = 1 сессия
added by Vladimir Gordeev about 2 years ago
> в том что по HLS невозможно отличить более новый токен от старого Нет, такой проблемы нет. Там просто есть кое-какие сложности, т.к. ограничение сессий должно работать сразу для разных протоколов, которые ведут себя немного по-разному. Возможно тут закралась какая-то ошибка.
RE: Проблема с ограничением 1токен = 1 сессия
added by Sergey M about 2 years ago
Спасибо. Кстати, я уже когда то предлагал как можно значительно упростить эту задачу. Насколько я понимаю вся проблема в том что по HLS невозможно отличить более новый токен от старого. Так вот я предлагал чтобы auth скрипт возвращал время создания токена, т.к. токены генерирует middleware который точно знает когда он создал токен. Тогда flussonic не придется гадать какой токен новый, а какой старый...он просто проверит время создания возвращенное auth скриптом и отрубит более старый и все. А если скрипт не вернет время, то тогда уже будет работать тот вариант который работает сейчас.
RE: Проблема с ограничением 1токен = 1 сессия
added by Vladimir Gordeev about 2 years ago
Я посмотрю что там может быть такое.
RE: Проблема с ограничением 1токен = 1 сессия
added by Sergey M about 2 years ago
В версии 4.5.26 не работает ограничения сессий при переключении просмотра между HLS и MPEGTS. Вернее работает слишком активно и блокирует новую сессию вместо старой. У нас клиенты Live получают по MPEGTS, а DVR по HLS. Так вот если клиент переключается между Live и DVR, то первые 30 секунд новая сессия не работает. В версии 4.5.17 все работало отлично. Пока пришлось полностью отключить ограничение сессий, потому что клиенты начали массово жаловаться. Я попробую воспроизвести проблему на тестовом сервере без middleware чтобы более точно написать что происходит.
RE: Проблема с ограничением 1токен = 1 сессия
added by Vladimir Gordeev about 2 years ago
Мы недавно переделали работу ограничения сессий, в грядущем релизе 4.5.23 улучшения уже будут доступны. Если вам интересно протестировать, напишите на support@erlyvideo.org, мы сможем выслать вам промежуточную сборку флюссоника.
RE: Проблема с ограничением 1токен = 1 сессия
added by александр Мохнов over 2 years ago
Установили 4.5.20 протестировали. Раньше хоть сессии обрывало, но временно не банило, теперь даже сессии не обрывает. Проверяли mpegts и hls раздачу. На флюс, от скрипта проверки токенов, все приходит
RE: Проблема с ограничением 1токен = 1 сессия
added by Vladimir Gordeev over 2 years ago
В последнем релизе 4.5.20 были исправления по ограничению сессий для persistent-протоколов, в вашем случае для mpegts. Посмотрите пожалуйста. Почему у вас некорректно работает ограничение по HLS пока непонятно.
RE: Проблема с ограничением 1токен = 1 сессия
added by александр Мохнов over 2 years ago
Возможно решение описанной проблемы, или нам необходимо искать альтернативные варианты достижения требуемого результата?
RE: Проблема с ограничением 1токен = 1 сессия
added by Vladimir Gordeev over 2 years ago
тьфу, вижу.
RE: Проблема с ограничением 1токен = 1 сессия
added by Vladimir Gordeev over 2 years ago
Какими протоколами пользуетесь? HLS? RTMP?
RE: Проблема с ограничением 1токен = 1 сессия
added by александр Мохнов over 2 years ago
А X-AuthDuration: 3600 - это 1 час, но его никак нет
RE: Проблема с ограничением 1токен = 1 сессия
added by александр Мохнов over 2 years ago
мпег вообще не лочися, ХЛС - через 30-60 сек перезапускается
RE: Проблема с ограничением 1токен = 1 сессия
added by Max Lapshin over 2 years ago
какие протоколы?