FAQ¶
Ответы на вопросы, которые чаще других возникают при эксплуатации: совместимость SRT со сторонним ПО и приём мультикаста на высоких битрейтах.
SRT: авторизация по логину и паролю в стороннем ПО¶
Между двумя узлами Perfect Streamer авторизация SRT настраивается штатно, полями входа и выхода (SRT). Работа с другим ПО не гарантируется: параметр stream ID не стандартизован и в разном ПО реализован по-разному.
Механизм совместимости общий: принимающая сторона берёт stream ID подключающегося клиента и ищет по нему учётную запись в списке локальных логинов (Пользователь: добавление и изменение). Совпасть должно поле «Логин» — целиком со значением stream ID. Например, при ссылке
srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890
в поле «Логин» вводится
!#::u=1234567890,password=1234567890
Синтаксис stream ID для Perfect Streamer значения не имеет: строка не разбирается по частям, а сравнивается целиком. Исключений три — символы, которые узел трактует сам:
|— разделитель: часть строки до первого такого символа считается логином, остальное паролем учётной записи;*— stream ID не задан; клиент авторизуется по адресу, то есть учётной записью с признаком «Учётная запись по IP-адресу»;@в начале строки зарезервирован за служебной авторизацией между узлами домена Meshwork.
Длину stream ID Perfect Streamer не ограничивает — ограничение приходит от библиотеки SRT и составляет 512 байт вместе с завершающим нулём. Значения длиннее примерно 500 символов передавать не следует: слишком длинная строка либо обрывает соединение, либо уходит пустой без сообщения об ошибке.
Разное ПО формирует stream ID по-своему, поэтому, если приём по ссылке не работает, включите на выходе SRT дополнительную настройку «Trace». В журнале потока, который принимает подключение, появятся адрес клиента, полученный stream ID и причина отказа — по этой строке видно, что сторона прислала на самом деле. Дальше stream ID можно скорректировать: например, убрать лишние символы в начале строки, мешающие передаче значения.
Рекомендации по работе с UDP-мультикастом¶
Задача. Стабильно принять UDP-мультикаст с суммарным битрейтом в несколько сотен Мбит/с (1 Гбит/с и более) на одном сервере.
Проблема. При приёме на сетевые карты с интерфейсом RJ-45 с ростом трафика выше нескольких сотен мегабит начинаются нарастающие потери пакетов мультикаста. Тонкая настройка карты не помогает — в современных версиях операционных систем уже используются оптимальные значения. Карты на лучших чипах проблему не снимают, особенно после 500 Мбит/с. Не помогает и бондинг двух карт: одна мультикаст-группа всегда приходит на один физический канал и на одну очередь приёма, поэтому агрегируется суммарная полоса, а не запас по отдельному потоку.
Решение. По опыту эксплуатации для приёма и передачи UDP-мультикаста следует использовать 10-гигабитные сетевые карты с интерфейсом SFP+. Достаточно бюджетной карты уровня Intel X520-DA1/2 (Intel 82599ES) — в наших тестах она устраняет потери пакетов при трафике мультикаста свыше 1 Гбит/с. Дополнительно заметно снижается нагрузка на CPU: обработка прерываний и очередей приёма на таких картах обходится дешевле.
Учтите при диагностике: счётчик ошибок приёма recv-err в статистике
входа считает только ошибки чтения сокета и рассинхронизацию по границе
TS-пакета. Потери, вызванные переполнением приёмного буфера ядра, до
приложения не доходят и в этот счётчик не попадают — их видно командой
netstat -su (строка RcvbufErrors) и по ошибкам непрерывности в
анализаторе потока (Анализатор).
Рекомендации по настройке сети для мультикаста¶
Раздел относится к сетевым входам UDP / RTP и Pro-MPEG. На приём SRT эти параметры не влияют: библиотека SRT задаёт размер буфера сама, а задержка и запас на ретрансмиссию настраиваются на самом входе (SRT).
Размер приёмного буфера сокета задаётся дополнительной настройкой входа
«Socket buffer (bytes)». По умолчанию она равна нулю — узел ничего не
запрашивает, и сокет получает размер буфера, заданный в системе
параметром net.core.rmem_default. Заданное значение — запрос, а не
итог: как только оно указано явно, начинает действовать потолок
net.core.rmem_max, и ядро урезает запрос до этого предела, сообщая об
успехе в любом случае. Поэтому потолок поднимают до того, как задавать
размер буфера у входа.
Сколько буфера выдано на самом деле, узел показывает у работающего входа в двух местах: в статистике потока, в блоке «Входное соединение», есть строка «Буфер сокета (выдано)» (Статистика потока), а в редакторе входа (Редактор входа и выхода) выданный размер выводится под самим полем и рядом появляется предупреждение, если запрос не уместился в потолок. В обоих местах показан полезный объём, доставшийся сокету, а не то, что набрано в поле: под полем — в байтах, чтобы сравнивать с ним напрямую, в статистике — округлённо. Отсутствие строки означает, что сокета нет: вход остановлен. Нулевого буфера она не означает никогда.
Значение в статистике обновляется вместе с остальными показателями, а под полем оно считывается один раз, при открытии окна потока. Поэтому после сохранения нового размера строка под полем исчезает: сохранение переоткрывает сокет, и прежнее число к нему уже не относится. Чтобы увидеть выданное новому сокету, окно потока закрывают и открывают заново — или смотрят статистику, где значение живое.
Параметры задаются отдельным файлом в /etc/sysctl.d/:
cat > /etc/sysctl.d/99-pss-net.conf <<EOF
net.core.rmem_default=8388608
net.core.rmem_max=16777216
EOF
Применить:
sudo sysctl --system
Значение rmem_max — только потолок, память по нему не резервируется.
Значение rmem_default применяется ко всем UDP-сокетам системы; если
такой глобальный размер нежелателен, оставьте его без изменений и задайте
«Socket buffer (bytes)» только тем входам, которым он действительно нужен.
Ноль и явно заданное число неравноценны даже при одинаковой величине:
запрошенный размер ядро удваивает, а размер по умолчанию берёт как есть,
тогда как половина выданного в обоих случаях уходит на служебный учёт
пакетов. Поэтому на системе с тем же rmem_default вход с явно
указанным числом получает вдвое больше полезного места, чем вход с нулём.
Ориентир для расчёта — битрейт потока, умноженный на допустимую паузу в
обслуживании сокета: 8 МБ покрывают около 64 мс при 1 Гбит/с. Ориентир
задаёт полезный объём, то есть число в поле входа; потолок
net.core.rmem_max при этом должен быть вдвое больше самого крупного
такого числа — рекомендованная пара значений выше это условие выполняет.
Flussonic и SRT¶
Пример ссылки SRT для приёма на ПО «Flussonic»:
srt://Stream_IP:port?streamid=flussonic
Где streamid — это логин клиента в ПО «Flussonic», который задаётся в разделе «Конфигурация — Настройка пиров».
При добавлении нового клиента достаточно указать только логин, в тестовой ссылке указан «flussonic». ПО «Flussonic» при работе с SRT автоматически генерирует streamID, и если не указать в ссылке логин streamID на приёме, то поток приниматься не будет, а Perfect Streamer не сможет его отдать.
Аналогичным образом можно задать streamID в формате логина и пароля,
создав в Perfect Streamer учётную запись, у которой поле «Логин» равно
!#::u=1234567890,password=1234567890, и прописав во «Flussonic»
ссылку:
srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890
Возможно указать streamID в формате IP-адреса у Perfect Streamer — для этого у учётной записи включается признак «Учётная запись по IP-адресу», а в поле адреса вводится:
192.168.1.1— единичный IP;192.168.1.1-192.168.1.254— диапазон IP.
В обоих случаях ссылка для приёма по IP во «Flussonic» будет выглядеть
так: srt://Stream_IP:port?streamid=*
Поток привязывается к IP-адресу клиента: приём по этой ссылке возможен только с указанного IP-адреса (или из указанного диапазона).
