Connexions maximales : ce qui se passe quand un portail n’a plus de créneaux

"max_connections": "2",
"active_cons": "1"

"max_connections": 2,
"active_cons": 1

Deux versions de panneau, un point de terminaison, les deux mêmes champs, et aucun accord sur le fait que les valeurs soient des chaînes ou des nombres. Le second bloc est tiré d’une fixture, valeurs comprises. Le premier est assemblé : la charge utile en forme de chaînes que nous conservons porte un max_connections de "1" et aucun active_cons, donc cette paire exacte n’apparaît dans aucun fichier que nous détenons. La variance est réelle dans les deux cas. Notre objet de transfert de données type les deux champs comme une chaîne nullable derrière un convertisseur qui lit une chaîne JSON, un nombre JSON ou un booléen, parce qu’un seul champ strict fait échouer toute la poignée de main, et qu’une source dont la poignée de main échoue n’a aucune chaîne.

Le premier de ces nombres décide si votre prochain changement de chaîne s’ouvre. Le second est un compte en direct de ce que votre compte occupe à l’instant, et il n’atteint aucun écran de notre application. Les deux faits sont porteurs. Le second, c’est à moi d’en répondre.

Un créneau vit sur la source, pas dans le lecteur#

max_connections est le plafond de flux simultanés du compte. L’API du panneau le documente sur le même objet que active_cons, les connexions actives à l’instant. Le plafond est tenu sur la source et, sur une version qui l’applique correctement, appliqué là. Qu’une version donnée l’applique vraiment, ou compte deux flux depuis une même adresse comme un seul, aucun client ne peut le tester.

Ce que notre application ne fait pas, c’est surveiller le nombre. Le portail vous le dirait : active_cons voyage dans la même réponse que le plafond, et un client qui le réinterrogerait pourrait le voir bouger. Nous le lisons une fois, quand le serveur importe votre source ou quand une synchronisation ultérieure rejoue la poignée de main, et nous ne regardons plus jamais. Tout ce qui suit sur le moment où une source libère un créneau est une inférence depuis notre côté de la socket. Nous savons exactement quand nous cessons de lire. Quand le compteur à l’autre bout redescend, nous ne l’avons jamais mesuré.

Dans notre Application Windows, six choses ouvrent un flux et dépensent contre ce plafond :

• le lecteur en direct qui affiche la chaîne où vous êtes
• un film, un épisode ou un programme en replay, qui puise dans le même compte et le même plafond que le direct
• chaque tuile d’une disposition multivue, qui reçoit sa propre instance de décodeur et son propre lecteur
• un enregistrement en cours
• le décodeur en attente pendant un chevauchement de bascule, pendant quelques secondes
• le lecteur en direct de nouveau après un basculement picture-in-picture, qui démonte le pipeline et le reconstruit

La synchronisation du catalogue et les téléchargements du guide sont des requêtes qui se terminent. Qu’une source les compte contre le même plafond la regarde ; ce n’est pas quelque chose que nous pouvons observer.

Le nombre arrive comme une chaîne, comme un nombre, ou pas du tout#

Trois formes de max_connections ont des fixtures. "max_connections": "2" est la graphie que les références de l’API du panneau écrivent. "max_connections": 2 est un nombre nu, et même cette version n’est pas cohérente : dans la charge utile en forme de nombres que nous conservons, les horodatages d’expiration et de création sont des entiers nus tandis que timestamp_now reste entre guillemets. Et "user_info": [], un tableau là où l’objet devrait se trouver, annule tout le bloc utilisateur et emporte les deux champs de connexion avec lui pendant que le reste de l’import se poursuit.

Une quatrième forme est atteignable et non épinglée. Le même convertisseur traduit un false nu en absent, pas en zéro, ce que nous n’avons consigné que pour un champ URL, où un "0" serait pire que rien. max_connections porte ce convertisseur, donc un booléen à cet endroit disparaît de la même manière. Aucune fixture ne le prouve, et je préfère le signaler plutôt que de laisser trois formes mesurées passer pour quatre.

Ce qui survit est converti par une analyse d’entier en culture invariante, et une valeur qui échoue omet la clé des métadonnées stockées au lieu d’y écrire une valeur de repli. Absent et un sont deux états différents sur le réseau, jusqu’au moment précis où l’appareil les lit.

Sur l’appareil, ils se replient en un seul état. Tout ce qui n’est pas strictement supérieur à zéro se normalise à 1, et un identifiant de source dont le cache de plafond n’a jamais entendu parler se lit aussi 1. Les types autres que portail prennent toujours cette valeur par défaut, parce que le champ n’existe que sur la poignée de main du portail. Sur les 2 203 entrées des deux vraies playlists que nous mesurons, la surface d’attributs EXTINF compte huit clés, dont aucune n’est un nombre de connexions, et ni la RFC 8216 ni la référence que tous les lecteurs empruntent n’en définit un.

Donc une source dont le vrai plafond est de huit, importée un après-midi où son portail expirait, est pour nous une source à une connexion jusqu’à ce qu’une synchronisation ultérieure fusionne les métadonnées : l’import enveloppe cette poignée de main dans un catch au mieux, au motif que les identifiants peuvent être bons même quand l’appel de métadonnées ne l’est pas. Un est la direction prudente, et chaque conséquence d’une mauvaise estimation est une fonctionnalité qui refuse d’agir, jamais un flux qu’on tue.

Un changement est une libération suivie d’une acquisition, dans cet ordre#

Changer de chaîne exécute une seule fonction derrière un verrou par lecteur : arrêter le lecteur, détacher le média, le libérer, construire le remplaçant, lire. L’ordre n’est pas accessoire. Le verrou existe parce que deux applications en course sur un même lecteur pourraient s’entrelacer de sorte que la périmée exécute son préfixe d’arrêt et de vidage après que la plus récente a déjà démarré son flux, tuant le flux que l’utilisateur a demandé. L’application périmée se découvre alors supplantée et retourne avant de construire quoi que ce soit, donc ce qui survit n’est pas l’ancienne chaîne. C’est un rectangle noir.

Stop est la seule partie d’un changement de chaîne qui peut prendre des secondes.

C’est un appel natif synchrone et, sur une chaîne morte ou en reconnexion, il bloque, raison pour laquelle il s’exécute sur un thread du pool et jamais sur le thread qui dessine votre interface. C’est bon pour l’interface et c’est exactement ce qui fait paraître un plafond plus petit qu’il n’est. L’application est passée à autre chose. La socket ne s’est pas nécessairement fermée, et le compteur de la source n’a certainement pas été consulté.

Le démontage quand vous quittez une page ou fermez l’application est plus lâche encore. Retirer un lecteur se fait sans attendre le résultat : stop, vidage, dispose, tout sur un thread du pool, sans que rien n’attende. Deux chemins bornent l’attente. La fermeture de l’application accorde 1 seconde ; un lecteur dont la construction a échoué en cours de route en reçoit 2. Si le chemin borné ne peut pas prendre le verrou dans sa fenêtre, il rend le démontage au chemin non borné et retourne quand même, parce que libérer un lecteur sous un thread encore à l’intérieur de la bibliothèque native fait tomber le processus. Les deux chiffres sont des constantes compilées et bougeront si quelqu’un les mesure. Fermer l’application est une demande de libération, pas la preuve que la libération est terminée.

Le picture-in-picture est le cas surprenant. Déplacer le canevas vidéo entre fenêtres exige un démontage complet et un réamorçage du décodeur, donc chaque basculement ferme le flux et le rouvre. Deux basculements font deux reconnexions sur un plafond qui n’a jamais eu de place que pour une.

L’arithmétique qu’un changement avec chevauchement doit satisfaire#

La plupart des changements ont besoin d’un créneau à la fois. Un cas en exige vraiment deux : un flux échoue, souvent sans que le moteur signale autre chose que Playing, et le lecteur monte un remplaçant sur un second décodeur pour que l’image ne passe jamais au noir. Pendant ce chevauchement, les deux flux sont ouverts. La règle qui le conditionne, copiée depuis le planificateur qui possède la décision :

required  = 1 (standby)
          + 1 when the candidate streams from the same source as the outgoing stream
          + active recordings on the incoming source
available = max_connections of the incoming source

La première ligne est le flux de remplacement, ce que le chevauchement achète. La deuxième est le flux sortant, compté seulement quand il puise dans la même entrée de source. La troisième est chaque enregistrement déjà en cours sur la source entrante, ce qui empêche le chevauchement de prendre un créneau qu’un enregistrement détient. La comparaison se fait contre la source entrante seule, parce que la source sortante garde sa connexion et la rend quand la permutation est validée.

Trois conséquences en découlent, et les trois sont épinglées par des tests. Une source à une connexion peut chevaucher entre sources, la bascule ordinaire de source agrégée. Ce test compare des identifiants de sources configurées, pas des identifiants de connexion, donc si deux de vos sources sont le même compte de portail saisi deux fois, le planificateur ne peut pas le voir, et le chevauchement dépense deux créneaux sur un seul plafond. Une source à une connexion ne peut jamais chevaucher avec elle-même, donc une alternative de même source se dégrade en redémarrage visible, celui qui était livré avant que ceci existe. Et requis 3 contre disponible 2, un chevauchement de même source sur une source déjà en enregistrement, refuse. Refuser est la direction sûre. Franchir le plafond couperait le flux que le spectateur regarde encore, ce qui est pire que le redémarrage que le chevauchement devait éviter.

La fenêtre est bornée de notre côté. Le réglage actuel donne au flux en attente 6 000 ms pour atteindre sa première image et 250 ms pour se stabiliser avant que la permutation soit validée, donc nous gardons le second décodeur ouvert 6 250 ms au maximum et abandonnons un flux en attente qui rate l’échéance. Le moment où la source cesse de compter cette connexion est une question distincte, à laquelle nous ne pouvons pas répondre. Ce sont des chiffres de réglage et ils bougeront ; l’arithmétique est la partie qui porte le sens. Les tests de budget de connexions, de planificateur, de cache de plafond, d’arbitre et de concurrence d’enregistrement exécutent 57 cas et passent tous à l’heure où j’écris.

Un enregistrement prend la connexion que l’image utilisait#

La capacité d’enregistrement est le plafond moins un, donc une source à trois connexions peut mener deux enregistrements et laisser encore un créneau pour que vous regardiez quelque chose. Une source à une connexion est un cas particulier dans le code et un cas brutal en pratique : la capacité reste à un, et démarrer un enregistrement suspend la lecture pour cette source, quitte le picture-in-picture et remplace la vidéo par une carte titrée « Aperçu suspendu pendant l'enregistrement ». Rien n’est volé et rien n’est mis en attente derrière un blocage. L’enregistrement obtient le créneau et l’écran le dit, dans des textes écrits séparément pour une chaîne en direct, un film et un épisode.

Au-dessus se trouve un réglage global de tâches simultanées, à 2 par défaut, et le plafond effectif par source est le plus petit des deux. À un plafond de trois, les deux limites sont à égalité. À quatre et au-delà, c’est la valeur par défaut de l’application qui devient la contrainte.

Une tâche planifiée fige sa fenêtre de guide en un début et une fin UTC fixes au moment où vous la réservez, et rien ne la recalcule ensuite. Si le guide était décalé d’une heure au moment de la réservation, le créneau est dépensé une heure à côté du programme que vous vouliez. Si le guide bouge ensuite, la tâche reste en place et enregistre silencieusement le mauvais contenu. Le calcul de connexions ne peut remarquer ni l’un ni l’autre, parce que de là où il se trouve, un créneau a été demandé et un créneau a été utilisé.

Rien ne refuse un enregistrement planifié pour des raisons de plafond, absolument rien. Le calcul est là et la préemption de la lecture en direct s’en sert, mais vous pouvez réserver sur une source plus d’enregistrements qui se chevauchent que son plafond ne peut en porter, et les tâches excédentaires échouent côté source au démarrage, sans aucun avertissement au moment où vous les avez planifiées. Notre taxonomie d’erreurs porte un code pour ce refus et l’enregistre comme partiellement couvert : le calcul existe, la vérification à la planification n’existe pas.

Neuf tuiles n’ont besoin de neuf connexions que si elles partagent une source#

Chaque tuile construit sa propre instance de décodeur et son propre lecteur, et les six géométries livrées contiennent 2, 4, 3, 4, 6 et 9 tuiles dans l’ordre de déclaration. Une tuile remplie coûte une connexion à sa propre source, donc neuf tuiles ont besoin de neuf connexions seulement quand les neuf puisent dans un même compte ; réparties sur trois sources, elles en coûtent trois à chacune, et un emplacement vide ne coûte rien. Les tuiles qui s’ouvrent ensemble s’étalent sur un calendrier partagé de 180 ms, ce qui place la neuvième tuile d’une disposition 3x3 à 1 440 ms derrière la première, cet espacement étant une autre constante compilée.

Le sélecteur de source compte les tuiles assignées par source et exclut délibérément l’emplacement que vous éditez, donc changer la chaîne d’une tuile libère la connexion de cette tuile avant que le remplaçant soit testé. Les lignes indiquent « 2 connexions sur 4 dans cette disposition », ou marquent la source pleine, et une disposition sans aucune place obtient un état bloqué, pas un échec. La liste des sources explique le même nombre plus discrètement, sous forme de badge indiquant « 1 connexion » ou « 4 connexions » avec une infobulle le nommant le maximum de connexions de flux simultanées autorisées par le portail.

Le pire bogue que cette fonctionnalité ait livré n’avait rien à voir avec les connexions et tout à voir avec ces neuf tuiles. Le validateur côté serveur des dispositions synchronisées portait une liste blanche de géométries jamais étendue au-delà de quatre formes, alors que les deux clients écrivaient déjà 2x3 et 3x3, donc enregistrer une disposition de six ou neuf tuiles produisait une charge utile que le serveur refusait. Le symptôme n’était pas un échec d’enregistrement de disposition, ce qui aurait été trouvable. La synchronisation expédie les changements par lots de 500 au plus et un seul enregistrement rejeté fait échouer tout le lot, donc un favori sans rapport basculé dans la même fenêtre disparaissait aussi, et la personne qui l’avait perdu n’avait aucune raison de le relier à une disposition construite quelques minutes plus tôt. Le commentaire au-dessus de la liste blanche corrigée énonce maintenant la règle tout haut : ajouter une géométrie au client veut dire l’ajouter ici, dans le même changement.

Le lecteur ne peut pas vous dire que la limite était la raison#

libvlc connaît le code d’état HTTP. Il analyse le code et branche dessus, mais ne le pose jamais sur la surface d’événements sur laquelle notre lecteur est construit, et notre relais de journal filtre sur une liste blanche de neuf fragments de pools, de décodeurs et de surfaces sans aucun http dedans. Donc un refus pour raison de connexions, un compte expiré, un hôte mal saisi et une chaîne morte nous parviennent comme un seul événement. C’est notre plomberie, pas le protocole, et notre taxonomie dit à la documentation de ne pas promettre le code d’état, donc cette page ne le promet pas.

Un refus que nous connaissons bel et bien, parce que nous l’avons calculé : le chevauchement qui n’a trouvé aucune connexion libre. Il nomme une cause sur laquelle une personne pourrait agir et n’atteint aucune surface, ce que notre propre note concède. Toutes les surfaces ici sont sur le bureau Windows ; la tête Xbox n’a aucun code d’enregistrement et aucune de ces cartes.

Nous lisons active_cons et ne le montrons à personne#

active_cons est analysé par le même convertisseur tolérant que le plafond, converti en entier, écrit dans les métadonnées stockées par le serveur qui a exécuté la poignée de main, transporté sur le réseau jusqu’à l’application de bureau et typé dans la console web. Aucun écran ne l’affiche. Une recherche dans l’application web, le code source du client et les catalogues de chaînes de caractères ne le trouve que dans les types et les mappeurs qui le transportent, jamais dans une vue ni dans une ligne de texte. L’instantané de budget a un champ mort assorti, un indicateur disant si la lecture détient une connexion, que le code de production ne met jamais qu’à faux.

Celui-là est mon erreur, pas un oubli dont j’ai hérité, et il m’agace chaque fois que je regarde le type.

Il existe une version défendable de la décision. La valeur mentirait. Elle est capturée pendant une poignée de main et estampillée de l’instant de capture, donc tout chiffre que nous afficherions serait une lecture de la dernière synchronisation, pas un compte en direct, et le cache de plafond se rafraîchit depuis ce même instantané stocké plutôt que depuis un appel frais à votre portail. Un « 3 sur 4 utilisées » périmé est pire qu’aucun nombre, surtout sur l’écran que les gens ouvrent quand ils cherchent déjà une cause. Cet argument est réel. Ce n’est pas non plus l’argument qui a produit l’état actuel, puisque le champ a été transporté jusqu’au réseau puis laissé là.

Notre Application Windows fait cette arithmétique sur votre machine, contre le plafond que votre source a signalé pendant sa propre poignée de main. Le serveur garde ce seul nombre et aucun flux ne passe par nous à aucun moment. Vous pouvez créer un compte gratuit et l’essayer sur une source que vous avez déjà.

Comptez vos propres ouvertures avant d’accuser la source. L’application ne voit que les flux qu’elle a ouverts elle-même, donc un second appareil laissé sur une chaîne dans une autre pièce est une dépense dont elle ne pourra jamais rendre compte. Quand votre lecteur échoue alors que ce compte fonctionne bien sur le second appareil, le plafond est la première chose à soupçonner, et aucun message d’erreur ne le soupçonnera pour vous.