FAQ

Réponses aux questions qui se posent le plus souvent en exploitation : la compatibilité SRT avec les logiciels tiers et la réception de multicast à haut débit.

SRT : autorisation par identifiant et mot de passe dans un logiciel tiers

Entre deux nœuds Perfect Streamer, l’autorisation SRT se configure de manière native, par les champs de l’entrée et de la sortie (SRT). Le fonctionnement avec d’autres logiciels n’est pas garanti : le paramètre stream ID n’est pas normalisé et il est mis en œuvre différemment selon le logiciel.

Le mécanisme de compatibilité est le même dans tous les cas : la partie réceptrice prend le stream ID du client qui se connecte et recherche à partir de celui-ci un compte dans la liste des identifiants locaux (Utilisateur : ajout et modification). C’est le champ « Identifiant » qui doit correspondre — intégralement — à la valeur du stream ID. Par exemple, avec l’URL

srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890

dans le champ « Identifiant », on saisit

!#::u=1234567890,password=1234567890

La syntaxe du stream ID est sans importance pour Perfect Streamer : la chaîne n’est pas décomposée en parties, elle est comparée dans son intégralité. Il existe trois exceptions — des caractères que le nœud interprète lui-même :

• | — séparateur : la partie de la chaîne située avant le premier caractère de ce type est prise pour l’identifiant, le reste pour le mot de passe du compte ;

• * — le stream ID n’est pas défini ; le client est autorisé par son adresse, c’est-à-dire par un compte portant l’indicateur « Compte par adresse IP » ;

• @ en début de chaîne est réservé à l’autorisation de service entre les nœuds d’un domaine Meshwork.

Perfect Streamer ne limite pas la longueur du stream ID — la limite vient de la bibliothèque SRT et s’élève à 512 octets, zéro terminal compris. Les valeurs dépassant environ 500 caractères ne doivent pas être transmises : une chaîne trop longue soit interrompt la connexion, soit part vide sans aucun message d’erreur.

Chaque logiciel construit le stream ID à sa manière ; par conséquent, si la réception par l’URL ne fonctionne pas, activez le réglage supplémentaire « Trace » sur la sortie SRT. Le journal du flux qui accepte la connexion affichera alors l’adresse du client, le stream ID reçu et le motif du refus — cette ligne montre ce que l’autre partie a réellement envoyé. Le stream ID peut ensuite être corrigé : par exemple, en supprimant les caractères superflus en début de chaîne qui empêchent la transmission de la valeur.

Recommandations pour l’utilisation du multicast UDP

Objectif. Recevoir de façon stable du multicast UDP dont le débit cumulé atteint plusieurs centaines de Mbps (1 Gbps et plus) sur un seul serveur.

Problème. Lors d’une réception sur des cartes réseau à interface RJ-45, des pertes croissantes de paquets multicast apparaissent dès que le trafic dépasse quelques centaines de mégabits. Le réglage fin de la carte n’y change rien — les versions actuelles des systèmes d’exploitation utilisent déjà les valeurs optimales. Les cartes équipées de meilleures puces ne suppriment pas non plus le problème, en particulier au-delà de 500 Mbps. Le bonding de deux cartes n’aide pas davantage : un même groupe multicast arrive toujours sur un seul lien physique et sur une seule file de réception ; c’est donc la bande passante totale qui est agrégée, et non la marge disponible pour un flux pris isolément.

Solution. L’expérience d’exploitation montre que la réception et l’émission de multicast UDP doivent s’appuyer sur des cartes réseau 10 gigabits à interface SFP+. Une carte économique de la classe Intel X520-DA1/2 (Intel 82599ES) suffit — dans nos tests, elle élimine les pertes de paquets pour un trafic multicast supérieur à 1 Gbps. La charge CPU diminue en outre sensiblement : le traitement des interruptions et des files de réception revient moins cher sur ces cartes.

À prendre en compte lors du diagnostic : le compteur d’erreurs de réception recv-err des statistiques de l’entrée ne comptabilise que les erreurs de lecture du socket et les pertes de synchronisation sur la frontière du paquet TS. Les pertes provoquées par le débordement du tampon de réception du noyau n’atteignent pas l’application et n’entrent pas dans ce compteur — elles sont visibles avec la commande netstat -su (ligne RcvbufErrors) et à travers les erreurs de continuité dans l’analyseur de flux (Analyseur).

Recommandations de configuration réseau pour le multicast

Cette section s’applique aux entrées réseau UDP / RTP et Pro-MPEG. Ces paramètres n’influent pas sur la réception SRT : la bibliothèque SRT définit elle-même la taille du tampon, tandis que la latence et la marge de retransmission se configurent sur l’entrée elle-même (SRT).

La taille du tampon de réception du socket est définie par le réglage supplémentaire « Socket buffer (bytes) » de l’entrée. Par défaut, il vaut zéro — le nœud ne demande rien et le socket reçoit la taille de tampon fixée dans le système par le paramètre net.core.rmem_default. La valeur saisie est une demande, non un résultat : dès qu’elle est définie explicitement, le plafond net.core.rmem_max entre en vigueur et le noyau réduit la demande à cette limite, tout en signalant un succès dans tous les cas. C’est pourquoi le plafond est relevé avant de définir la taille du tampon sur l’entrée.

Quelle quantité de tampon a réellement été accordée, le nœud l’indique pour une entrée en fonctionnement à deux endroits : dans les statistiques du flux, le bloc « Liaison d’entrée » comporte la ligne « Tampon socket (accordé) » (Statistiques du flux), et dans l’éditeur de l’entrée (Éditeur d’entrée et de sortie) la taille accordée est affichée sous le champ lui-même, un avertissement apparaissant à côté si la demande n’est pas entrée sous le plafond. Aux deux endroits est indiqué le volume utile revenu au socket, et non ce qui est saisi dans le champ : sous le champ — en octets, afin de pouvoir le comparer directement, dans les statistiques — arrondi. L’absence de la ligne signifie qu’il n’y a pas de socket : l’entrée est arrêtée. Elle ne signifie jamais un tampon nul.

La valeur dans les statistiques est actualisée en même temps que les autres indicateurs, tandis que sous le champ elle est lue une seule fois, à l’ouverture de la fenêtre du flux. C’est pourquoi la ligne sous le champ disparaît après l’enregistrement d’une nouvelle taille : l’enregistrement rouvre le socket et l’ancien nombre ne s’y rapporte plus. Pour voir ce qui a été accordé au nouveau socket, on ferme et rouvre la fenêtre du flux — ou l’on consulte les statistiques, où la valeur est vivante.

Les paramètres sont définis dans un fichier distinct sous /etc/sysctl.d/ :

cat > /etc/sysctl.d/99-pss-net.conf <<EOF
net.core.rmem_default=8388608
net.core.rmem_max=16777216
EOF

Appliquer :

sudo sysctl --system

La valeur rmem_max n’est qu’un plafond, aucune mémoire n’est réservée à ce titre. La valeur rmem_default s’applique à tous les sockets UDP du système ; si une telle taille globale n’est pas souhaitable, laissez-la inchangée et ne définissez « Socket buffer (bytes) » que sur les entrées qui en ont réellement besoin. Zéro et un nombre défini explicitement ne sont pas équivalents, même à grandeur égale : le noyau double la taille demandée alors qu’il prend la taille par défaut telle quelle, la moitié de ce qui est accordé servant dans les deux cas à la comptabilité interne des paquets. Ainsi, sur un système ayant le même rmem_default, une entrée dotée d’un nombre explicite dispose de deux fois plus de place utile qu’une entrée laissée à zéro.

Pour le calcul, prenez comme repère le débit du flux multiplié par la pause admissible dans le traitement du socket : 8 MB couvrent environ 64 ms à 1 Gbps. Ce repère fixe le volume utile, c’est-à-dire le nombre inscrit dans le champ de l’entrée ; le plafond net.core.rmem_max doit alors valoir le double du plus grand de ces nombres — le couple de valeurs recommandé ci-dessus remplit cette condition.

Flussonic et SRT

Exemple d’URL SRT pour la réception par le logiciel « Flussonic » :

srt://Stream_IP:port?streamid=flussonic

Où streamid est l’identifiant du client dans le logiciel « Flussonic », qui se définit dans la section « Configuration — Paramétrage des pairs ».

Lors de l’ajout d’un nouveau client, il suffit d’indiquer uniquement l’identifiant ; l’URL de test utilise « flussonic ». Lorsqu’il travaille avec SRT, le logiciel « Flussonic » génère automatiquement le streamID, et si l’identifiant streamID n’est pas indiqué dans l’URL du côté réception, le flux ne sera pas reçu et Perfect Streamer ne pourra pas le délivrer.

De la même manière, il est possible de définir le streamID au format identifiant et mot de passe : créez dans Perfect Streamer un compte dont le champ « Identifiant » est égal à !#::u=1234567890,password=1234567890, puis renseignez dans « Flussonic » l’URL :

srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890

Il est possible d’indiquer le streamID au format adresse IP dans Perfect Streamer — pour cela, l’indicateur « Compte par adresse IP » est activé sur le compte et le champ d’adresse reçoit :

• 192.168.1.1 — une IP unique ;

• 192.168.1.1-192.168.1.254 — une plage d’IP.

Dans les deux cas, l’URL de réception par IP dans « Flussonic » se présente ainsi : srt://Stream_IP:port?streamid=*

Le flux est lié à l’adresse IP du client : la réception via cette URL n’est possible que depuis l’adresse IP indiquée (ou depuis la plage indiquée).