Zusammenfassung

  • RFC 1913 ließ Whois++-Server verdichtetes „forward knowledge“ weitergeben: deduplizierte Begriffe, die auf möglicherweise passende Server unterhalb verwiesen. Das war Suchsteuerung, kein Datensatzbeweis.
  • Mehrere Indexpfade lockerten eine einzige Hierarchie, erzeugten aber einen Graphen, den der Client mit Schleifen-, Zeit-, Kosten- und Erreichbarkeitsregeln durchlaufen musste.
  • 1999 wurde das Prinzip im Common Indexing Protocol verallgemeinert; Whois++ selbst wurde 2006 nach einer IETF-Prüfung als definiert, aber nicht genutzt eingeordnet und auf Historic gesetzt.

Nützlich, weil Informationen fehlen

Das kleine Beispiel in RFC 1913 enthält zwei Benutzer und eine Domain. Der Centroid bewahrt für jede Vorlage und jedes Attribut jedes vorkommende Wort genau einmal. „Smith“ erscheint einmal, unabhängig von der Zahl der Einträge. Wörter aus einem gemeinsamen Feld stehen anschließend getrennt. Datensatzkennung, Anzahl, Zusammenhang, Reihenfolge, Herkunft und Gegenwartsnachweis fehlen.

Das ist keine defekte Datenbank, sondern ein bewusst kleiner Aussageumfang. Ein Index muss nicht alle Quelldaten kopieren, um aussichtslose Zweige auszuschließen. Seine zulässige Aussage lautet: Nach dem vorhandenen Indexzustand kam dieses Wort in diesem Attribut irgendwo unterhalb vor. Daraus folgt eine Weiterleitung, nicht die Antwort.

Ein Geflecht oberhalb der Quellen

Der im August 1995 veröffentlichte RFC 1835, Architecture of the WHOIS++ service, führte typisierte Vorlagen und strukturierte Attribut-Wert-Paare ein. Er unterschied Basisserver mit ausgefüllten Einträgen von Indexservern mit Vorwissen und Verweisen. Ein Rechner konnte beide Rollen übernehmen, ohne dass Hinweis und Quelldatensatz dasselbe wurden.

Ein weltweites Zentralverzeichnis hätte Speicher, Verkehr und Ausfall konzentriert. Ein starrer Baum verlangte Vorwissen über den Ablageort, belastete obere Ebenen und eignete sich schlecht für querliegende „Gelbe-Seiten“-Fragen.

Im Februar 1996 legte RFC 1913, Architecture of the Whois++ Index Service, ein Mesh über die Einträge. Indexserver konnten Centroids von Basis- oder anderen Indexservern sammeln und erneut verdichten. Ein Server durfte von mehreren Eltern indexiert werden und geografischen, administrativen oder topologischen Hierarchien zugleich angehören. Identität und Entdeckungspfad wurden getrennt.

Das schuf alternative Wege und spezialisierte Verzeichnisse, ohne die autoritativen Daten zu verschieben. Doch das Mesh beförderte Gründe für die nächste Anfrage. Die Wirklichkeit blieb am Ziel.

Eine Änderung hatte mehrere Zeitpunkte

RFC 1913 definierte authentisierte POLL-Abfragen für vollständige Centroids oder Änderungen bestimmter Vorlagen und Felder. Ein unterer Server konnte mit DATA-CHANGED eine Änderung melden; der Empfänger entschied, ob und wann er neu abfragte.

So zerfiel eine Änderung in Datensatzänderung, neue Verdichtung, Mitteilung, Annahme, Abfrage, Authentisierung, lokale Übernahme und spätere Weitergabe. Antwortcode 227 bedeutete angenommen und für weitere Bearbeitung protokolliert. Er bedeutete nicht überall angewandt.

Ein alter positiver Hinweis konnte zu einem Server führen, auf dem der Begriff inzwischen fehlte. Eine neue, noch nicht verbreitete Übereinstimmung konnte fälschlich ausgefiltert werden. Die RFCs quantifizieren diese Fälle nicht. Sicher ist nur: Empfang, Anwendung, Verbreitung und aktueller Zustand benötigen unterschiedliche Belege.

Der Client übernahm den Graphen

Das Mesh sah hierarchisch aus, war wegen mehrerer Eltern aber ein Graph. RFC 1913 nutzte für Abfragebeziehungen eine Hop-Zahl, in dieser Version höchstens acht. Für Suchweiterleitungen sollte der Client bereits besuchte Server festhalten.

RFC 1914, How to Interact with a Whois++ Mesh, ebenfalls vom Februar 1996, beschrieb den Ablauf. Der Client verband sich, fragte an, erhielt Datensätze und Verweise, trennte die Verbindung und wählte das nächste Ziel. Er führte eine Menge bereits befragter Server und konnte seine Suche über den Einstieg hinaus erweitern.

Blindes Erweitern konnte jedoch exponentiell wachsende Ressourcenkosten erzeugen. In Teilen des Mesh waren kostenpflichtige Antworten denkbar. Clients brauchten Zeit- und Geldgrenzen, Sperrlisten und Abbruchmöglichkeiten. Vollständigkeit hing von Einstieg, verfügbaren Verweisen, Schleifenerkennung, Erweiterungspolitik, Budget und Verfügbarkeit ab. Sie war keine Eigenschaft der ersten Antwort.

Stabile Kennung, veralteter Standort

Hostname, IP-Adresse und Port einer Weiterleitung konnten aus einer Wochen alten Abfrage stammen. Scheiterte die Verbindung, konnte der Client mit dem stabileren server handle beim Directory of Servers nach dem zuletzt bekannten Ziel suchen.

Die Trennung von Identität und Standort ermöglichte Umzüge ohne gleichzeitige Erneuerung aller Caches. „Zuletzt bekannt“ hieß dennoch nicht „jetzt erreichbar“. Auch der zweite Versuch konnte scheitern. RFC 1913 unterschied einen unerreichbaren Server von einem erreichbaren Host mit nicht antwortendem Dienst. Eine Kennung reparierte einen alten Zeiger, nicht den ausgefallenen Prozess.

Auch Sicherheit blieb begrenzt. RFC 1913 erklärte, Sicherheitsfragen nicht zu behandeln. RFC 1914 empfahl Sperrlisten, weil falsche Whois++-Server auftauchen könnten. Das belegt keinen beobachteten Angriff. Es zeigt, dass jede Weiterleitung eine neue Verwaltungsgrenze und eine neue Datenbehauptung eröffnete.

Der Gedanke löste sich vom Produkt

Im August 1999 bezeichnete RFC 2651, The Architecture of the Common Indexing Protocol, CIP als Weiterentwicklung und Verfeinerung der Whois++-Indexierung. Er löste den Indexaustausch vom Datenzugriffsprotokoll, verallgemeinerte Indexobjekte und beschrieb sie als Hinweise zur Anfragesteuerung. Für echte Ergebnisse blieb ein natives Zugriffsprotokoll nötig.

Eine Architekturidee kann also das Angebot überleben, in dem sie zuerst erschien. Whois++ verband Centroid und Vorlagenverzeichnis; CIP isolierte den wiederverwendbaren Mechanismus kompakter Hinweise zwischen Servern.

Im März 2006 dokumentierte RFC 4450, Getting Rid of the Cruft, eine zurückhaltende Prüfung alter Proposed Standards. RFC 1835, 1913 und 1914 kamen in die Historic-Liste; Whois++ wurde als definiert, aber nicht genutzt genannt. Das leugnet weder Versuche noch Software — RFC 2651 erwähnt Digger. Es hält das IETF-Urteil fest, dass die Dokumente keine gegenwärtige Praxis mehr darstellten, die als Proposed Standard gepflegt werden sollte.

Dies ist keine einfache Geschichte vom Sieg der Zentrale über das Verteilte. Das Mesh behandelte ein echtes Suchproblem, und seine Abstraktion lebte weiter. Dauerhaft blieb der Aufwand jedes Übergangs vom Hinweis zur Tatsache.

Quellen

  • RFC 1835, RFC 1913, RFC 1914, RFC 2651 und RFC 4450 sind in der Analyse jeweils genau einmal verlinkt.