Maximale Verbindungen: was passiert, wenn einem Portal die Plätze ausgehen

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

"max_connections": 2,
"active_cons": 1

Zwei Panel-Builds, ein Endpunkt, dieselben zwei Felder, und keine Einigkeit darüber, ob die Werte Zeichenketten oder Zahlen sind. Der zweite Block stammt aus einer Testvorlage, Werte und alles. Der erste ist zusammengesetzt: die zeichenkettenförmige Nutzlast, die wir aufbewahren, trägt ein max_connections von "1" und überhaupt kein active_cons, dieses genaue Paar steht also in keiner Datei, die wir halten. Die Abweichung ist so oder so echt. Unser Datenübertragungsobjekt typisiert beide Felder als nullable Zeichenkette hinter einem Konverter, der eine JSON-Zeichenkette, eine JSON-Zahl oder einen Booleschen Wert liest, denn ein einziges striktes Feld lässt den ganzen Handschlag scheitern, und eine Quelle, deren Handschlag scheitert, hat überhaupt keine Sender.

Die erste dieser Zahlen entscheidet, ob Ihr nächster Senderwechsel aufgeht. Die zweite ist eine Live-Zählung dessen, was Ihr Konto gerade hält, und sie erreicht in unserer App keinen einzigen Bildschirm. Beide Tatsachen sind tragend. Für die zweite muss ich geradestehen.

Ein Platz liegt auf der Quelle, nicht im Player#

max_connections ist die Obergrenze des Kontos für gleichzeitige Streams. Die Panel-API dokumentiert es auf demselben Objekt wie active_cons, die aktuell aktiven Verbindungen. Die Obergrenze wird auf der Quelle geführt und, auf einem Build, der sie korrekt durchsetzt, auch dort angewendet. Ob ein bestimmter Build sie überhaupt durchsetzt oder zwei Streams von einer Adresse als einen zählt, kann kein Client prüfen.

Was unsere App nicht tut, ist die Zahl zu beobachten. Das Portal würde es Ihnen sagen: active_cons reist auf derselben Antwort mit wie das Limit, und ein Client, der erneut abfragt, könnte es wandern sehen. Wir lesen es einmal, wenn der Server Ihre Quelle importiert oder wenn eine spätere Synchronisierung den Handschlag wiederholt, und danach nie wieder. Alles, was unten darüber steht, wann eine Quelle einen Platz freigibt, ist eine Schlussfolgerung von unserer Seite des Sockets aus. Wir wissen genau, wann wir aufhören zu lesen. Wann der Zähler am anderen Ende wieder heruntergeht, haben wir nie gemessen.

In unserer Windows-App öffnen sechs Dinge einen Stream und verbrauchen gegen diese Obergrenze:

• der Live-Player, der den Sender zeigt, auf dem Sie gerade sind
• ein Film, eine Episode oder eine Catch-up-Sendung, die auf dasselbe Konto und dasselbe Limit zurückgreifen wie Live
• jede Kachel eines Multiview-Layouts, die ihre eigene Decoder-Instanz und ihren eigenen Player bekommt
• eine laufende Aufnahme
• der Bereitschafts-Decoder während einer Wechselüberlappung, für einige Sekunden
• der Live-Player erneut nach einem Wechsel ins Bild-im-Bild, der die Kette abbaut und neu aufbaut

Katalogsynchronisierung und Programmdownloads sind Anfragen, die enden. Ob eine Quelle diese gegen dieselbe Obergrenze zählt, ist ihre Sache und nichts, was wir beobachten können.

Die Zahl kommt als Zeichenkette, als Zahl oder gar nicht an#

Für drei Formen von max_connections gibt es Testvorlagen. "max_connections": "2" ist die Schreibweise, die die Referenzen der Panel-API festhalten. "max_connections": 2 ist eine blanke Zahl, und selbst dieser Build ist nicht konsistent: in der zahlenförmigen Nutzlast, die wir aufbewahren, sind die Ablauf- und Erstellungsstempel blanke Ganzzahlen, während timestamp_now weiterhin in Anführungszeichen steht. Und "user_info": [], ein Array dort, wo das Objekt hingehört, leert den gesamten Nutzerblock und reißt beide Verbindungsfelder mit sich, während der Rest des Imports weiterläuft.

Eine vierte Form ist erreichbar und nicht festgeschrieben. Derselbe Konverter bildet ein blankes false auf abwesend ab, nicht auf null, was wir nur für ein URL-Feld aktenkundig haben, wo eine "0" schlimmer wäre als nichts. max_connections trägt diesen Konverter, ein Boolescher Wert verschwindet dort also genauso. Keine Testvorlage belegt es, und ich weise lieber darauf hin, als drei gemessene Formen für vier durchgehen zu lassen.

Was überlebt, wird mit einer Ganzzahl-Auswertung in invarianter Kultur umgewandelt, und ein Wert, der daran scheitert, lässt den Schlüssel aus den gespeicherten Metadaten weg, statt einen Ersatzwert hineinzuschreiben. Abwesend und eins sind auf der Leitung zwei verschiedene Zustände, genau bis zu dem Moment, in dem das Gerät sie liest.

Am Gerät fallen sie zu einem Zustand zusammen. Alles, was nicht größer als null ist, wird auf 1 normalisiert, und eine Quellen-ID, von der der Limit-Zwischenspeicher nie gehört hat, liest sich ebenfalls als 1. Nicht-Portal-Arten nehmen immer diesen Standardwert, denn das Feld existiert nur beim Portal-Handschlag. Über die 2.203 Einträge der beiden echten Playlists, die wir vermessen, umfasst die EXTINF-Attributfläche acht Schlüssel, keiner davon eine Verbindungszahl, und weder RFC 8216 noch die Referenz, bei der sich jeder Player bedient definiert eine.

Eine Quelle, deren echtes Limit acht beträgt und die an einem Nachmittag importiert wurde, an dem ihr Portal in Zeitüberschreitungen lief, ist für uns also eine Quelle mit einer Verbindung, bis eine spätere Synchronisierung die Metadaten nachträgt: der Import hüllt diesen Handschlag in ein Best-Effort-Catch, mit der Begründung, dass die Zugangsdaten in Ordnung sein können, auch wenn der Metadatenaufruf es nicht ist. Eins ist die vorsichtige Richtung, und jede Folge eines falschen Rateschlusses ist eine Funktion, die nicht handelt, nie ein Stream, der abgewürgt wird.

Ein Wechsel ist eine Freigabe gefolgt von einer Belegung, in dieser Reihenfolge#

Der Senderwechsel führt eine Funktion hinter einer Sperre pro Player aus: Player stoppen, Medium abhängen, verwerfen, Ersatz konstruieren, abspielen. Die Reihenfolge ist kein Zufall. Die Sperre gibt es, weil zwei um einen Player konkurrierende Vorgänge sich so verschränken könnten, dass der veraltete sein Stopp-und-Leeren ausführt, nachdem der neuere seinen Stream bereits gestartet hat, und damit genau den Stream tötet, den die Nutzerin oder der Nutzer angefordert hat. Der veraltete Vorgang stellt dann fest, dass er überholt wurde, und kehrt zurück, bevor er irgendetwas baut. Was übrig bleibt, ist nicht der alte Sender. Es ist ein schwarzes Rechteck.

Stop ist der einzige Teil eines Senderwechsels, der Sekunden dauern kann.

Es ist ein synchroner nativer Aufruf, und auf einem toten oder gerade neu verbindenden Sender blockiert er, weshalb er auf einem Pool-Thread läuft und nie auf dem Thread, der Ihre Oberfläche zeichnet. Das ist gut für die Oberfläche und genau das, was ein Limit kleiner wirken lässt, als es ist. Die App ist weitergezogen. Der Socket ist nicht zwangsläufig geschlossen, und der Zähler der Quelle wurde ganz sicher nicht befragt.

Der Abbau, wenn Sie eine Seite verlassen oder die App schließen, ist noch lockerer. Einen Player auszumustern ist Absenden und Vergessen: stoppen, leeren, verwerfen, alles auf einem Pool-Thread, ohne dass irgendetwas auf das Ergebnis wartet. Zwei Pfade begrenzen die Wartezeit. Das Beenden der App erlaubt 1 Sekunde; ein Player, der auf halbem Weg beim Aufbau gescheitert ist, bekommt 2. Wenn der begrenzte Pfad die Sperre in seinem Fenster nicht bekommt, gibt er den Abbau an den unbegrenzten zurück und kehrt trotzdem zurück, denn einen Player unter einem Thread wegzuräumen, der noch in der nativen Bibliothek steckt, reißt den Prozess mit. Beide Werte sind einkompilierte Konstanten und werden sich ändern, sobald jemand sie nachmisst. Die App zu schließen ist eine Bitte um Freigabe, kein Beweis, dass die Freigabe abgeschlossen ist.

Das Bild-im-Bild ist der überraschende Fall. Die Video-Zeichenfläche zwischen Fenstern zu bewegen erfordert einen vollständigen Abbau und Neustart des Decoders, jeder Wechsel schließt den Stream also und öffnet ihn erneut. Zwei Wechsel sind zwei Neuverbindungen auf einem Limit, das immer nur für eine Platz hatte.

Die Rechnung, die ein überlappender Wechsel bestehen muss#

Die meisten Wechsel brauchen einen Platz auf einmal. Ein Fall braucht wirklich zwei: ein Stream fällt aus, oft ohne dass die Engine etwas anderes als Playing meldet, und der Player fährt einen Ersatz auf einem zweiten Decoder hoch, damit das Bild nicht schwarz wird. Während dieser Überlappung sind beide Streams offen. Die Regel, die das absichert, herauskopiert aus dem Planer, dem die Entscheidung gehört:

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

Zeile eins ist der Ersatzstream, und der ist das, was die Überlappung einkauft. Zeile zwei ist der abgehende Stream, gezählt nur dann, wenn er aus demselben Quelleneintrag schöpft. Zeile drei ist jede Aufnahme, die auf der eingehenden Quelle bereits läuft, und so wird verhindert, dass die Überlappung einen Platz nimmt, den eine Aufnahme hält. Verglichen wird allein gegen die eingehende Quelle, denn die abgehende behält ihre Verbindung und gibt sie zurück, wenn der Wechsel vollzogen ist.

Drei Folgen ergeben sich daraus, und alle drei sind durch Tests festgeschrieben. Eine Quelle mit einer Verbindung kann quellenübergreifend überlappen, das ist der gewöhnliche Wechsel bei zusammengeführten Quellen. Dieser Test vergleicht eingerichtete Quellen-IDs, nicht Zugangsdaten. Wenn also zwei Ihrer Quellen dasselbe Portalkonto sind, das zweimal eingetragen wurde, kann der Planer das nicht erkennen, und die Überlappung verbraucht zwei Plätze auf einem Limit. Eine Quelle mit einer Verbindung kann nie innerhalb ihrer selbst überlappen, eine Alternative auf derselben Quelle fällt also auf den sichtbaren Neustart zurück, den es schon vor dieser Funktion gab. Und erforderlich 3 gegen verfügbar 2, eine Überlappung auf derselben Quelle, auf der bereits aufgenommen wird, wird verweigert. Verweigern ist die sichere Richtung. Das Limit zu reißen würde den Stream abwürgen, den die Zuschauerin oder der Zuschauer gerade noch sieht, und das ist schlimmer als der Neustart, den die Überlappung vermeiden sollte.

Auf unserer Seite ist das Fenster begrenzt. Die aktuelle Abstimmung gibt der Bereitschaft 6.000 ms bis zu ihrem ersten Bild und 250 ms zum Beruhigen, bevor der Wechsel vollzogen wird, wir halten den zweiten Decoder also höchstens 6.250 ms offen und geben eine Bereitschaft auf, die die Frist verpasst. Wann die Quelle aufhört, diese Verbindung zu zählen, ist eine andere Frage, und keine, die wir beantworten können. Das sind Abstimmungswerte und sie werden sich ändern; die Rechnung ist der Teil, der die Bedeutung trägt. Die Tests für Verbindungsbudget, Planer, Limit-Zwischenspeicher, Schlichter und Aufnahmenebenläufigkeit laufen über 57 Fälle und bestehen zum Zeitpunkt dieses Textes alle.

Eine Aufnahme nimmt die Verbindung, die das Bild benutzt hat#

Die Aufnahmekapazität ist das Limit minus eins, eine Quelle mit drei Verbindungen kann also zwei Aufnahmen fahren und lässt Ihnen trotzdem einen Platz zum Zuschauen. Eine Quelle mit einer Verbindung ist im Code ein Sonderfall und in der Praxis ein grober: die Kapazität bleibt bei eins, und das Starten einer Aufnahme setzt die Wiedergabe für diese Quelle aus, verlässt das Bild-im-Bild und ersetzt das Video durch eine Karte mit der Überschrift "Vorschau während der Aufnahme pausiert". Nichts wird gestohlen und nichts staut sich hinter einer Blockade. Die Aufnahme bekommt den Platz und der Bildschirm sagt es, in Texten, die für einen Live-Sender, einen Film und eine Episode getrennt geschrieben sind.

Darüber sitzt eine globale Einstellung für gleichzeitige Aufträge mit dem Standardwert 2, und das wirksame Limit je Quelle ist der kleinere der beiden Werte. Bei einem Limit von drei sind die beiden Grenzen gleichauf. Ab vier ist der eigene Standardwert der App die bindende Beschränkung.

Ein geplanter Auftrag friert sein Programmfenster in dem Moment, in dem Sie ihn buchen, auf einen festen UTC-Start und ein festes UTC-Ende ein, und danach löst ihn nichts mehr neu auf. Wenn der Programmführer eine Stunde daneben lag, als Sie gebucht haben, wird der Platz eine Stunde neben der gewünschten Sendung verbraucht. Verschiebt sich der Programmführer später, bleibt der Auftrag stehen und nimmt stillschweigend den falschen Inhalt auf. Die Verbindungsrechnung kann keinen der beiden Fälle bemerken, denn von ihrem Standpunkt aus wurde ein Platz angefordert und ein Platz benutzt.

Aus Gründen des Limits verweigert überhaupt nichts eine geplante Aufnahme. Die Rechnung ist da und die Verdrängung der Live-Wiedergabe nutzt sie, aber Sie können auf einer Quelle mehr überlappende Aufnahmen buchen, als ihr Limit tragen kann, und die überzähligen Aufträge scheitern beim Start an der Quelle, ohne dass beim Planen gewarnt wurde. Unsere Fehlertaxonomie führt einen Code für diese Verweigerung und hält ihn als teilweise hinterlegt fest: die Rechnung gibt es, die Prüfung bei der Planung nicht.

Neun Kacheln brauchen neun Verbindungen nur, wenn sie sich eine Quelle teilen#

Jede Kachel baut ihre eigene Decoder-Instanz und ihren eigenen Player, und die sechs ausgelieferten Geometrien fassen 2, 4, 3, 4, 6 und 9 Kacheln in der Reihenfolge ihrer Deklaration. Eine belegte Kachel kostet eine Verbindung ihrer eigenen Quelle, neun Kacheln brauchen also nur dann neun Verbindungen, wenn alle neun aus einem Konto schöpfen; über drei Quellen verteilt kosten sie je drei, und ein leerer Platz kostet nichts. Gemeinsam öffnende Kacheln verteilen sich über einen geteilten Zeitplan von 180 ms, was die neunte Kachel eines 3x3-Layouts 1.440 ms hinter die erste setzt, wobei dieser Abstand eine weitere einkompilierte Konstante ist.

Die Quellenauswahl zählt belegte Kacheln je Quelle und schließt den Platz, den Sie gerade bearbeiten, bewusst aus, sodass das Ändern des Senders einer Kachel deren Verbindung freigibt, bevor der Ersatz geprüft wird. Zeilen lesen sich als "2 von 4 Verbindungen in diesem Layout" oder markieren die Quelle als voll, und ein Layout ohne Platz erhält einen blockierten Zustand, keinen Fehler. Die Quellenliste erklärt dieselbe Zahl leiser, als Abzeichen mit dem Text "1 Verbindung" oder "4 Verbindungen" und einem Tooltip, der sie als die maximalen gleichzeitigen Stream-Verbindungen benennt, die dieses Portal erlaubt.

Der schlimmste Fehler, den diese Funktion je ausgeliefert hat, hatte nichts mit Verbindungen zu tun und alles mit diesen neun Kacheln. Die serverseitige Prüfung für synchronisierte Layouts trug eine Geometrie-Positivliste, die nie über vier Formen hinaus erweitert worden war, während beide Clients bereits 2x3 und 3x3 schrieben. Das Speichern eines Layouts mit sechs oder neun Kacheln erzeugte deshalb eine Nutzlast, die der Server ablehnte. Das Symptom war kein fehlgeschlagenes Speichern des Layouts, das wäre auffindbar gewesen. Die Synchronisierung schickt Änderungen in Stapeln von bis zu 500, und ein abgelehnter Datensatz lässt den ganzen Stapel scheitern. Ein unbeteiligter Favorit, der im selben Zeitfenster umgeschaltet wurde, verschwand also mit, und die Person, die ihn verlor, hatte keinen Grund, das mit einem Minuten zuvor gebauten Layout in Verbindung zu bringen. Der Kommentar über der korrigierten Positivliste sagt die Regel jetzt laut: eine Geometrie im Client hinzuzufügen heißt, sie hier hinzuzufügen, in derselben Änderung.

Der Player kann Ihnen nicht sagen, dass das Limit der Grund war#

libvlc kennt den HTTP-Statuscode. Es liest ihn aus und verzweigt danach, legt ihn aber nie auf die Ereignisfläche, gegen die unser Player gebaut ist, und unser Protokollweiterleiter filtert über eine Positivliste aus neun Fragmenten für Pools, Decoder und Oberflächen, in der kein http steht. Eine Verweigerung wegen des Verbindungslimits, ein abgelaufenes Konto, ein vertippter Host und ein toter Sender erreichen uns also als ein und dasselbe Ereignis. Das ist unsere Verkabelung, nicht das Protokoll, und unsere Taxonomie weist die Dokumentation an, den Status nicht zu versprechen, weshalb diese Seite es nicht tut.

Eine Verweigerung kennen wir, weil wir sie selbst berechnet haben: die Überlappung, die keine freie Verbindung fand. Sie benennt eine Ursache, an der ein Mensch etwas ändern könnte, und erreicht keine Oberfläche, was unsere eigene Notiz einräumt. Jede Oberfläche hier ist Windows-Desktop; der Xbox-Kopf hat keinen Aufnahmecode und keine dieser Karten.

Wir lesen active_cons und zeigen es niemandem#

active_cons wird von demselben toleranten Konverter ausgewertet wie das Limit, in eine Ganzzahl umgewandelt, von dem Server, der den Handschlag ausgeführt hat, in die gespeicherten Metadaten geschrieben, über die Leitung an die Desktop-App getragen und in der Webkonsole typisiert. Kein Bildschirm stellt es dar. Eine Suche über die Web-App, die Client-Quellen und die Textkataloge findet es nur in den Typen und Abbildungen, die es weiterreichen, nie in einer Ansicht oder einer Zeile Text. Die Budget-Momentaufnahme hat ein passendes totes Feld, ein Kennzeichen dafür, ob die Wiedergabe eine Verbindung hält, das der Produktivcode nur je auf falsch setzt.

Das ist mein Fehler, kein geerbtes Versäumnis, und er ärgert mich jedes Mal, wenn ich den Typ ansehe.

Es gibt eine vertretbare Fassung dieser Entscheidung. Der Wert würde lügen. Er wird während eines Handschlags erfasst und mit dem Zeitpunkt der Erfassung gestempelt, jede Zahl, die wir zeichnen würden, wäre also eine Ablesung von der letzten Synchronisierung und keine Live-Zählung, und der Limit-Zwischenspeicher aktualisiert sich aus derselben gespeicherten Momentaufnahme statt aus einem frischen Aufruf Ihres Portals. Ein veraltetes "3 von 4 in Benutzung" ist schlimmer als gar keine Zahl, besonders auf dem Bildschirm, den Leute öffnen, wenn sie ohnehin schon eine Ursache suchen. Dieses Argument ist echt. Es ist auch nicht das Argument, das den heutigen Zustand hervorgebracht hat, denn das Feld wurde bis auf die Leitung getragen und dort dann liegen gelassen.

Unsere Windows-App führt diese Rechnung auf Ihrem Rechner aus, gegen das Limit, das Ihre Quelle bei ihrem eigenen Handschlag gemeldet hat. Der Server behält diese eine Zahl und zu keinem Zeitpunkt läuft ein Stream durch uns. Sie können ein kostenloses Konto anlegen und es an einer Quelle ausprobieren, die Sie bereits haben.

Zählen Sie Ihre eigenen Öffner, bevor Sie die Quelle beschuldigen. Die App sieht nur die Streams, die sie selbst geöffnet hat, ein zweites Gerät, das in einem anderen Raum auf einem Sender stehen geblieben ist, ist also ein Verbrauch, den sie nie verbuchen kann. Wenn Ihr Player scheitert, während dasselbe Konto auf dem zweiten Gerät einwandfrei läuft, ist das Limit das Erste, was Sie verdächtigen sollten, und keine Fehlermeldung wird es für Sie verdächtigen.