FAQ¶
Respuestas a las preguntas que surgen con más frecuencia durante la explotación: la compatibilidad de SRT con software de terceros y la recepción de multicast con tasas de bits elevadas.
SRT: autorización mediante usuario y contraseña en software de terceros¶
Entre dos nodos de Perfect Streamer la autorización SRT se configura de forma nativa, con los campos de la entrada y de la salida (SRT). El funcionamiento con otro software no está garantizado: el parámetro stream ID no está estandarizado y cada software lo implementa de una manera distinta.
El mecanismo de compatibilidad es común: la parte receptora toma el stream ID del cliente que se conecta y busca con él una cuenta en la lista de usuarios locales (Usuario: añadir y editar). Debe coincidir el campo «Usuario» — íntegramente con el valor del stream ID. Por ejemplo, con la URL
srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890
en el campo «Usuario» se introduce
!#::u=1234567890,password=1234567890
La sintaxis del stream ID carece de importancia para Perfect Streamer: la cadena no se descompone en partes, sino que se compara íntegramente. Hay tres excepciones — los caracteres que el propio nodo interpreta:
|— separador: la parte de la cadena anterior al primer carácter de este tipo se considera el usuario, y el resto, la contraseña de la cuenta;*— el stream ID no está definido; el cliente se autoriza por dirección, es decir, mediante una cuenta con el atributo «Cuenta de dirección IP»;@al principio de la cadena está reservado para la autorización de servicio entre los nodos de un dominio Meshwork.
Perfect Streamer no limita la longitud del stream ID — la limitación procede de la biblioteca SRT y es de 512 bytes, incluido el cero final. No conviene transmitir valores de más de unos 500 caracteres: una cadena demasiado larga o bien corta la conexión, o bien se envía vacía sin ningún mensaje de error.
Cada software forma el stream ID a su manera, por eso, si la recepción por la URL no funciona, active en la salida SRT el ajuste adicional «Trace». En el registro del flujo que acepta la conexión aparecerán la dirección del cliente, el stream ID recibido y el motivo del rechazo — esa línea muestra qué envió realmente la otra parte. Después se puede corregir el stream ID: por ejemplo, eliminar del principio de la cadena los caracteres sobrantes que impiden la transmisión del valor.
Recomendaciones para trabajar con multicast UDP¶
Objetivo. Recibir de forma estable multicast UDP con una tasa de bits total de varios cientos de Mbps (1 Gbps o más) en un solo servidor.
Problema. En la recepción con tarjetas de red de interfaz RJ-45, a medida que el tráfico supera los varios cientos de megabits comienzan pérdidas crecientes de paquetes de multicast. El ajuste fino de la tarjeta no ayuda — las versiones actuales de los sistemas operativos ya emplean los valores óptimos. Las tarjetas basadas en mejores chips tampoco eliminan el problema, sobre todo por encima de 500 Mbps. Tampoco ayuda el bonding de dos tarjetas: un mismo grupo multicast llega siempre a un único canal físico y a una única cola de recepción, por lo que se agrega el ancho de banda total y no el margen de un flujo concreto.
Solución. La experiencia de explotación indica que para la recepción y la transmisión de multicast UDP conviene utilizar tarjetas de red de 10 gigabits con interfaz SFP+. Basta con una tarjeta económica del nivel de la Intel X520-DA1/2 (Intel 82599ES) — en nuestras pruebas elimina la pérdida de paquetes con tráfico de multicast superior a 1 Gbps. Además, la carga de la CPU se reduce notablemente: el procesamiento de las interrupciones y de las colas de recepción resulta más barato en esas tarjetas.
Téngalo en cuenta durante el diagnóstico: el contador de errores de recepción recv-err de las estadísticas de la entrada cuenta únicamente los errores de lectura del socket y la pérdida de sincronización con el límite del paquete TS. Las pérdidas provocadas por el desbordamiento del búfer de recepción del kernel no llegan a la aplicación y no aparecen en ese contador — se ven con el comando netstat -su (línea RcvbufErrors) y por los errores de continuidad en el analizador de flujo (Analizador).
Recomendaciones para la configuración de la red para multicast¶
La sección se refiere a las entradas de red UDP / RTP y Pro-MPEG. Estos parámetros no afectan a la recepción SRT: la biblioteca SRT establece por sí misma el tamaño del búfer, mientras que el retardo y el margen para la retransmisión se configuran en la propia entrada (SRT).
El tamaño del búfer de recepción del socket se establece con el ajuste adicional de la entrada «Socket buffer (bytes)». De forma predeterminada es cero — el nodo no solicita nada y el socket recibe el tamaño de búfer definido en el sistema por el parámetro net.core.rmem_default. En cuanto el valor se define de forma explícita, entra en vigor el límite superior net.core.rmem_max: el kernel recorta silenciosamente la solicitud hasta ese límite sin informar del truncamiento ni al registro ni a las estadísticas. Por eso el límite superior se eleva antes de establecer el tamaño del búfer en la entrada.
Los parámetros se definen en un archivo aparte en /etc/sysctl.d/:
cat > /etc/sysctl.d/99-pss-net.conf <<EOF
net.core.rmem_default=8388608
net.core.rmem_max=16777216
EOF
Aplicar:
sudo sysctl --system
El valor rmem_max es solo un límite superior; no se reserva memoria por él. El valor rmem_default se aplica a todos los sockets UDP del sistema; si ese tamaño global no es deseable, déjelo sin cambios y defina «Socket buffer (bytes)» solo en las entradas que realmente lo necesiten. Como referencia para el cálculo sirve la tasa de bits del flujo multiplicada por la pausa admisible en el servicio del socket: 8 MB cubren unos 64 ms a 1 Gbps.
Flussonic y SRT¶
Ejemplo de URL SRT para la recepción en el software «Flussonic»:
srt://Stream_IP:port?streamid=flussonic
Donde streamid es el usuario del cliente en el software «Flussonic», que se define en la sección «Configuración — Ajustes de pares».
Al añadir un cliente nuevo basta con indicar solo el usuario; en la URL de prueba se indica «flussonic». El software «Flussonic», al trabajar con SRT, genera streamID automáticamente, y si en la URL de recepción no se indica el usuario streamID, el flujo no se recibirá y Perfect Streamer no podrá entregarlo.
De forma análoga se puede definir streamID en formato de usuario y contraseña: cree en Perfect Streamer una cuenta cuyo campo «Usuario» sea igual a !#::u=1234567890,password=1234567890 e indique en «Flussonic» la URL:
srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890
Es posible indicar streamID en formato de dirección IP en Perfect Streamer — para ello se activa en la cuenta el atributo «Cuenta de dirección IP» y en el campo de dirección se introduce:
192.168.1.1— una única IP;192.168.1.1-192.168.1.254— un rango de IP.
En ambos casos la URL para la recepción por IP en «Flussonic» tendrá el siguiente aspecto: srt://Stream_IP:port?streamid=*
El flujo queda vinculado a la dirección IP del cliente: la recepción a través de esta URL solo es posible desde la dirección IP indicada (o desde el rango indicado).
