Zusammenfassung

  • Die optionale Complete-Sammlung enthält erfolgreiche Aufträge und processed-Aufträge ohne weitere Statusmeldungen. Ihre Zugehörigkeit ist keine allgemeine Erfolgsbestätigung.
  • Der einzelne Zustand complete verlangt erfolgreich abgeschlossene Aktionen einschließlich betroffener nachgelagerter CDNs. Ein Zwischenanbieter darf processed eines Nachfolgers nicht zu complete aufwerten.
  • Eine geschätzte Abschlusszeit hilft beim Planen, bestätigt aber kein Ergebnis. Die Trigger-Schnittstelle fordert keine synchronisierten Uhren zwischen verbundenen CDNs.
  • Invalidierung, Purge, Vorabladen, Abbruch und Löschen eines Statusberichts haben unterschiedliche Folgen. Abhängige Arbeit muss ihr tatsächlich benötigtes Ergebnis benennen.
  • Das Austauschbeispiel ist eine Analyse der Spezifikation, kein beobachteter Anbieterfehler und keine Messung allgemeiner Verbreitung.

Der nächste Auftrag wartet auf das falsche Zeichen

Ein Inhaltsanbieter will Material unter denselben URLs austauschen. Zuerst soll sein Verteilungspartner die alte Fassung entfernen, danach die neue vorab laden. Die Reihenfolge soll verhindern, dass ein noch laufender alter Purge den Ersatz wieder trifft.

Der Partner nimmt den Auftrag an. Später erscheint dessen Statusressource in der Complete-Sammlung. Die aktive Berichtsliste ist um einen Eintrag kürzer. Für eine einfache Freigabelogik könnte damit der Start des Vorabladens erlaubt sein.

Der einzelne Zustand kann jedoch processed lauten. Der Auftrag wurde angenommen, weitere Statusaktualisierungen werden nicht geliefert; der Zustand ist auch für Fälle vorgesehen, in denen der Abschluss nicht bestätigt werden kann. Die Berichterstattung ist beendet, nicht notwendigerweise die benötigte Erfolgsfrage.

Diese angenommene Situation benennt keinen realen Defekt. RFC 8007 erlaubt begrenzte Berichterstattung ausdrücklich. Untersucht wird, was passiert, wenn ein anderer Beteiligter daraus die stärkere Zusage ableitet, auf die seine Folgearbeit angewiesen ist.

Der Beobachter fragt, ob er noch neue Meldungen verfolgen muss. Der Inhaltsanbieter fragt, ob der alte Purge erfolgreich abgeschlossen ist. Ein gemeinsamer Eintrag kann diese Fragen nicht durch seinen Ablageort gleichsetzen.

Zwei Arten des Abschlusses in einer Sammlung

RFC 8007 wurde im Dezember 2016 als IETF-Dokument auf dem Standards Track veröffentlicht. Der Eintrag des RFC Editor führt Proposed Standard. Die Spezifikation beschreibt den Trigger-Teil der CDNI-Steuerschnittstelle.

Ein vorgelagertes CDN kann ein nachgelagertes Netz auffordern, Metadaten oder Inhalte zu erwerben, zu invalidieren oder zu entfernen. Der zugehörige Status lässt sich anschließend prüfen. Damit ist nicht die gesamte geschäftliche Beziehung, Erstkonfiguration oder lokale Zugriffsentscheidung zentral vereinheitlicht.

Das empfangende Netz unterhält Statusressourcen für den jeweiligen Auftraggeber. Gefilterte Sammlungen sind optional. Werden sie angeboten, müssen ihre Verknüpfungen in der Gesamtsammlung zugänglich sein. Kein Leser sollte aus einer üblichen Darstellung schließen, dass jede Implementierung diese Ansicht besitzt.

Die Complete-Sammlung enthält erfolgreich abgeschlossene Arbeit und processed-Aufträge ohne weitere Aktualisierungen. Der Name ordnet die Lebensdauer der Beobachtung. Er verstärkt nicht die Aussage des einzelnen Status.

Der einzelne Zustand complete bedeutet, dass die ausgelöste Arbeit erfolgreich abgeschlossen wurde. Processed bedeutet Annahme ohne weitere Statusmeldungen, auch wenn sich der Abschluss nicht bestätigen lässt. Dass beide zur selben Sammlung gehören, hebt den Unterschied nicht auf.

Processed ist nicht stets ein Fehlschlag. Es ist auch nicht stets Erfolg, Stillstand, Untätigkeit oder die Zusage, dass keine weiteren Wirkungen auftreten. Es begrenzt zuerst das, was der Partner noch berichten wird.

Für die Verwaltung laufender Beobachtung ist diese Einordnung nützlich. Für eine Folgeentscheidung, die einen bestimmten Erfolg voraussetzt, reicht sie nicht allein. Ein Bericht kann aus dem Arbeitsvorrat des Beobachters verschwinden, während die Voraussetzung eines anderen Betreibers noch offenbleibt.

Annahme schafft eine Prüfreferenz

Nimmt das nachgelagerte CDN einen Trigger an, erzeugt es eine Statusressource und liefert deren Ort mit HTTP 201. Der Auftraggeber hat nun eine Referenz für die weitere Prüfung. Der Antwortcode erklärt die angefragte Arbeit nicht schon zur vollendeten Tatsache.

Der zurückgegebene Link ist maßgeblich. Der Auftraggeber darf weder die URI-Struktur erraten noch Beispiele als verbindliche Abbildung zwischen Objekten und Pfaden behandeln. Eine einmal verwendete Status-URI darf auch nach dem Löschen nicht erneut benutzt werden.

Diese Identitätsregel verhindert, dass eine alte Prüfreferenz unbemerkt eine neue Aufgabe bezeichnet. Ein erreichbarer Ort allein würde sonst nicht garantieren, dass man weiterhin über denselben Auftrag entscheidet.

Eine Implementierung mit Fortschrittsverfolgung kann wartend, aktiv und schließlich erfolgreich oder fehlgeschlagen melden. Ist diese Verfolgung nicht möglich, muss sie den begrenzten Bericht mit processed kennzeichnen und die Ressource zu Complete hinzufügen. Eine geeignete geschätzte Abschlusszeit wird empfohlen.

Auch ein Auftrag ohne neue Tätigkeit kann dort korrekt landen. Vielleicht betrifft der Purge Daten, die noch nie erworben wurden. Vielleicht sind die vorzuladenden Daten bereits vorhanden und gültig. Processed oder complete kann in solchen Fällen richtig sein.

Ein erfolgreicher Zustand misst daher nicht automatisch transportierte Bytes oder geleerte Speichermedien. Seine Bedeutung folgt aus Auftragstyp und Umfang. Ein Zähler abgeschlossener Berichte ersetzt diese Information nicht.

In der Kaskade darf Gewissheit nicht erfunden werden

Das empfangende CDN kann die Auslieferung an weitere Netze delegieren. Trigger müssen an diejenigen weitergereicht werden, die betroffen sein können. Der eigene lokale Abschluss eines Zwischenanbieters beseitigt diese Abhängigkeiten nicht.

RFC 8007 verbietet complete, bevor der Auftrag in allen betroffenen nachgelagerten CDNs complete ist. Meldet ein Nachfolger processed, müssen Zwischenanbieter ebenfalls processed melden. Begrenzte Bestätigung darf beim Zusammenfassen nicht zu bestätigtem Erfolg werden.

Das ist eine Regel für den Gehalt der aggregierten Antwort, keine Forderung nach einem Zentrum für jede Ausführung. Die Netze entscheiden lokal, dürfen aber nur die Gewissheit weitergeben, die ihre Kette tatsächlich hervorbringt.

Fehler können bereits vorliegen, während andere Ziele noch bearbeitet werden. Die Statusressource kann eine aktive Aufgabe mit einer Liste einzelner Fehler darstellen. Jeder Fehler benennt betroffene angefragte URLs oder Muster.

Diese Referenzen müssen den Anfragen genau entsprechen und dürfen nicht zu einem größeren Bereich verallgemeinert werden. Ein fehlgeschlagenes Ziel bedeutet nicht, dass alle Ziele scheiterten. Ein noch nicht gemeldeter Fehler ist umgekehrt kein Nachweis für Erfolg.

Damit bleibt selektive Fortsetzung möglich. Unabhängige Arbeit kann ausreichend bestätigt sein, während eine andere Tätigkeit auf eine offene Voraussetzung angewiesen ist. Eine vollständige Sperre und eine vollständige Freigabe können beide am tatsächlichen Umfang vorbeigehen.

Die CDNI-Anforderungen in RFC 7337, einem Informational-Dokument, verlangten geeignete Meldungen über Abschluss und Erfolg oder Misserfolg auch in Kaskaden. Die Trigger-Spezifikation macht zusätzlich begrenzte Beobachtbarkeit ausdrückbar, statt sie hinter einer pauschalen Erfolgsmarkierung zu verstecken.

Welcher Erfolg überhaupt benötigt wird

Vorabladen verlangt den Erwerb von Metadaten oder Inhalten. Invalidierung verlangt erneute Validierung vor Wiederverwendung und muss die gespeicherten Daten nicht löschen. Purge verlangt, dass die angegebenen Daten nach Bearbeitung nicht mehr gehalten werden; bei Bedarf können sie später erneut erworben werden.

Das aktuelle IANA-Register bewahrt diese Unterscheidung. Eine Bedingung für künftige Nutzung ist nicht dasselbe physische Ergebnis wie das Entfernen aus einem Speicher.

Die Spezifikation lässt complete bei einer Invalidierung zu, obwohl betroffene Cache-Server offline sind, sofern diese bei Rückkehr die Daten vor Wiederverwendung revalidieren. Der Erfolg bezieht sich auf die künftige Nutzungsbedingung, nicht auf nachgewiesene Leerung jedes unerreichbaren Geräts.

Purge und Vorabladen können processed sein, wenn die Arbeit bei Rückkehr der Caches abgeschlossen wird. Wird sie aufgegeben, sollte ein Fehler gemeldet werden. Nicht jeder terminal eingeordnete Bericht steht für bereits bestätigte physische Löschung.

Auch die Reichweite bleibt begrenzt. Es geht um die angefragten Daten in der betreffenden Verteilungsbeziehung, nicht um jede Kopie im Internet. Bereits an einen Empfänger gelieferter Inhalt wird durch eine spätere Statusänderung nicht zurückgeholt.

Sendeordnung ist keine Ausführungsordnung

Beginn und Geschwindigkeit der Arbeit liegen beim nachgelagerten CDN. Purge und Invalidierung müssen vor Annahme erworbene Daten betreffen. Sie sollten später erworbene Daten nicht erfassen, doch der Auftraggeber kann sich nicht darauf verlassen, dass diese Ausnahme immer erreichbar ist.

Wie ein bei Eingang bereits gestarteter Erwerb behandelt wird, bleibt ebenfalls eine Implementierungsentscheidung. Zwei nacheinander gesendete Aufträge schaffen keinen eindeutigen globalen Schnitt zwischen alten und neuen Daten.

Deshalb empfiehlt RFC 8007, Purge oder Invalidierung abzuschließen, bevor Ersatz unter denselben URLs vorgeladen wird. Bei paralleler Ausführung kann der neue Inhalt erworben und anschließend vom noch laufenden früheren Auftrag wieder betroffen werden.

Eine diamantförmige Verteilung kann mehrere legitime Erwerbspfade und wiederholte Aufträge erzeugen. Das empfangende Netz muss diese nicht zwingend zusammenführen. Ein Pfad hat seinen Purge beendet und fordert Vorabladen an, während ein anderer Purge weiterhin den frischen Ersatz erfasst.

Erneuter Erwerb kann die Verfügbarkeit wiederherstellen. Er beweist nicht, dass die erste Fortsetzung durch den sofortigen Abschluss aller konkurrierenden Arbeiten abgesichert war.

Der Inhaltsanbieter muss seine Voraussetzung benennen. Wartet er auf bestätigten Erfolg für den benötigten Umfang? Akzeptiert er eine Schätzung samt Unsicherheit in einer lokalen Vereinbarung? Ist seine nächste Arbeit vom unsicheren Ziel unabhängig? Die Complete-Sammlung entscheidet keine dieser Fragen.

Eine Schätzung wird nicht durch Zeitablauf zum Beleg

Die optionale Eigenschaft etime nennt den erwarteten Abschlusszeitpunkt des nachgelagerten Netzes. Sie unterstützt Planung. Sie bestätigt nicht, dass der erwartete Erfolg bei Erreichen dieses Zeitpunkts eingetreten ist.

Erstellungs-, Änderungs- und geschätzte Abschlusszeiten werden vom berichtenden CDN bestimmt. Die Schnittstelle verlangt keine Uhrensynchronisation zwischen verbundenen CDNs. Eine sortierte Liste ihrer Zahlen schafft noch keine gemeinsame kausale Reihenfolge.

Die Beteiligten können lokal festlegen, wie Zeitbasen und Unsicherheit in ihre Planung eingehen. Eine solche Vereinbarung ändert processed nicht in complete. Selbst perfekt übereinstimmende Uhren machen eine Erwartung nicht zur eingegangenen Erfolgsbestätigung.

Bedingte HTTP-Anfragen reduzieren Beobachtungskosten. RFC 8007 empfiehlt ETags für Ressourcen und Sammlungen. HTTP-Semantik und Caching-Regeln erklären das Werkzeug, nicht den Erfolg der dahinterliegenden Arbeit.

Eine 304-Antwort zu einer unveränderten processed-Ressource kann richtig sein. Sie sagt, dass deren Repräsentation unverändert blieb. Sie liefert nicht die Ergebnisbestätigung, die der Partner ausdrücklich nicht weiter anbieten wird. Häufigere Beobachtung vergrößert keinen begrenzten Beobachtungsvertrag.

Abbruch und Berichtsreinigung sind kein Rückweg

Der Dienst muss einen Abbruchauftrag angemessen beantworten; die tatsächliche Abbruchfunktion ist optional. Die Antwort kann inaktive Arbeit, angenommene Unterbrechung bei weiter aktiver Arbeit oder fehlende Unterstützung unterscheiden.

Eine wartende Aufgabe kann starten, bevor der Abbruch verarbeitet wird. Eine aktive Aufgabe muss nicht sofort stoppen. Bereits erfolgte Löschung oder Erwerb werden nicht allgemein rückgängig gemacht. Complete oder failed darf nicht nachträglich zu abgebrochen umetikettiert werden.

Die Zeichenfolgen auf der Leitung müssen ebenfalls stimmen. Das verifizierte technische Erratum 5053 korrigiert cancelling und cancelled; 5054 korrigiert ecancelled. Das redaktionelle Erratum 5064 trennt ein ausdrückliches Abbruchbeispiel vom Löschen einer Statusressource. Natürliche Erklärung darf die Protokollwerte nicht anders schreiben.

Beim Löschen verschwindet die Prüfreferenz samt Sammlungsverweisen. Die Wirkung ähnelt einem Abbruch, lässt aber keinen Bericht zurück. Ein später fehlschlagendes GET erklärt nicht, welches Ergebnis vor der Entfernung entstand.

Automatische Aufbewahrung begrenzt ebenso das Beobachtungsfenster. Wird alter Status entfernt, muss die Dauer bekannt gemacht werden. Mindestens vierundzwanzig Stunden für terminale Ressourcen sind empfohlen, keine ausnahmslos verbindliche Untergrenze. Benötigte Ergebnisse sollten vor Ablauf dieses Fensters eingeholt werden.

Geschützter Transport trägt auch begrenzte Antworten

Aufträge müssen auf die Daten des betreffenden Auftraggebers beschränkt sein. Die Diamantkonfiguration erkennt mehrere mögliche legitime Erwerbspfade an, keine allgemeine Macht über fremde Daten.

Sammlungen gehören zum jeweiligen Auftraggeber und dürfen anderen CDNs nicht sichtbar sein. TLS mit Authentifizierung der Gegenstelle ist erforderlich, sofern keine geeignete alternative Sicherung die Informationen schützt. Die konkreten Zugriffsregeln sind lokal; die geschäftliche Vertrauensbeziehung liegt außerhalb des Protokolls.

Die aktuellen TLS-Empfehlungen ersetzen die früher zitierte Anleitung. Ein geschützter Austausch kann die Herkunft eines Berichts stützen. Er bestätigt nicht den erfolgreichen Vollzug aller angefragten Aktionen.

CDNI-Rahmen, Metadaten und Logging ergänzen die Evidenz. Eine gesunde Auslieferung an einem Punkt ist keine Bestätigung des Datenzustands jedes offline befindlichen oder weiter nachgelagerten Systems.

Quellen

Die Primärdokumente begründen die semantischen Unterschiede. Entscheidungsvorschläge sind Analyse des Autors, keine neuen Standardanforderungen.