Zusammenfassung

  • Project Athena entwickelte Zephyr für kurze, zeitkritische Hinweise in einem wachsenden Netz von Arbeitsstationen, in dem lokale Rundsendungen und E-Mail jeweils an anderen Grenzen stießen.
  • Authentifizierte Identität, Anmeldeort, gewählte Sichtbarkeit, Themenabonnement und Zustellung waren getrennte Zustände; keiner bewies Verfügbarkeit oder Lektüre.

Die erste Frage war nicht, wie Text in einem Fenster erscheint. Es ging darum, die richtige Person zu erreichen, nachdem Computerarbeit von einem gemeinsam genutzten Rechner auf viele vernetzte Arbeitsstationen wechselte. Athenas Pläne von 1987–88 beschreiben diesen Wandel auf dem Campus. Ein Dateiserver musste Nutzer über eine Abschaltung informieren, der Druckdienst den Abschluss eines Auftrags melden und eine Lehrassistenz vielleicht einen ganzen Kurs erreichen. E-Mail bewahrte Nachrichten, verlangte aber Wartezeit und eine Empfängerliste.

Ein Netzwerk-Broadcast war schnell, blieb jedoch auf das lokale Netz begrenzt und zwang jeden Rechner, auch Mitteilungen für wenige andere zu verarbeiten. Die Zephyr-Entwickler benannten den Gegensatz: E-Mail war langsam und umständlich; Broadcasts waren flüchtig und skalierten schlecht.

Zephyr wurde daher als Transport für mehrere Kommunikationsdienste entworfen. Der USENIX-Beitrag von 1988 beschreibt eine Basisschicht mit darüberliegenden Diensten für Abonnements und Nutzerstandorte. Der technische Plan vom 5. Juni 1989 konkretisiert den Aufbau: pro Arbeitsstation ein HostManager (zhm), pro Anmeldesitzung ein WindowGram-Client (zwgc) und mehrere Zephyr-Server für Registrierung, Weiterleitung und Zustandsverwaltung. Ein Hinweis trennte Routing-Header und Clientdaten. Server lasen den Header, um Empfänger zu bestimmen, ohne den Nachrichtentext auswerten zu müssen. Ein Dateidienst konnte bekannte Nutzer benachrichtigen; ein Dienst ohne feste Zielgruppe veröffentlichte in einer Klasse, die interessierte Clients abonnierten.

Ein Abonnement war ein expliziter Zustand, kein Ruf an den gesamten Campus. Der Server speicherte ein Tupel aus Klasse, Instanz und Empfänger. Der Client konnte das Abonnement beantragen; passende Hinweise wurden anschließend an interessierte Clients geleitet. zwrite adressierte eine bestimmte Identität. Kerberos lieferte authentifizierte Principals, die als Zephyr-IDs dienten. So unterschied das System ein authentifiziertes Konto von einem Namen, der nur im Nachrichtentext stand. Authentifizierung beantwortete jedoch „Welche Identität stellte diese Anfrage?“ und nicht automatisch „Darf dieser Absender jeden Empfänger lokalisieren oder unterbrechen?“ Zugriffskontrollen, Sichtbarkeitseinstellungen und privilegierte Notfallhinweise waren gesonderte Regeln.

Auch Präsenzdaten hatten Grenzen. Zephyr speicherte Anmeldungen und Orte, damit ein Hinweis den Nutzer erreichen konnte, ohne dass der Absender die konkrete Arbeitsstation kennen musste. Die Entwickler warnten davor, die Standortdatenbank als vollständige Echtzeitliste zu verstehen. Ein Eintrag bedeutete, dass eine authentifizierte Anmeldung gemeldet worden war. Bei einem Rechnerabsturz konnte die Abmeldung ausbleiben und ein alter Eintrag bestehen bleiben. Umgekehrt bewies ein fehlender sichtbarer Ort nicht, dass die Person nie angemeldet war: Sie konnte die Standortfreigabe ablehnen.

Neustarts und ausbleibende Antworten lösten Bereinigungen veralteter Zustände aus. Das verringerte Fehler, machte den verteilten Dienst aber nicht zum unfehlbaren Zeugen.

Der Plan von 1989 nannte sechs Sichtbarkeitsstufen: none, opstaff, realm-visible, realm-announced, net-visible und net-announced. Standortabfrage und Ankündigungen bei Anmeldung und Abmeldung waren keine einzige Einstellung. Der MIT-Nutzerleitfaden von 1993 unterschied zudem hide vom Abschalten des Dienstes: Das Verbergen des Standorts hielt andere nicht davon ab, Hinweise zu senden. Das war ein engerer Schutz als ein allgemeiner Schalter „Bitte nicht kontaktieren“.

Die Zuverlässigkeit des Transports war eine weitere Frage. Zephyr nutzte UDP und ergänzte je nach Bedarf mehrere Bestätigungsstufen. Die Entwickler dokumentierten Duplikate, falsche Reihenfolge, Verlust und fehlende Flusskontrolle. Das Beispiel für zwrite garantierte das Absenden, nicht die Ankunft oder eine einmalige Zustellung. Eine Serverbestätigung, eine Clientbestätigung und das Lesen durch einen Menschen waren unterschiedliche Ereignisse. Zephyr eignete sich für schnelle Koordination; ein Transportbeleg war jedoch kein Nachweis für Einverständnis, Aufmerksamkeit oder erledigte Arbeit.

1993 beschrieb der MIT-Leitfaden individuelle und gruppenweite Zephyrgrams als übliche Athena-Werkzeuge; eine Studie von 1996 untersuchte Zephyr Help als synchronen Supportkanal. Das belegt die Nutzung am MIT, nicht eine universelle Vorbildrolle für Instant Messaging. Aufschlussreich ist vielmehr die Trennung, die Zephyr aufrechterhielt: Identität konnte Routing ermöglichen, eine Anmeldung einen Ortseintrag erzeugen und ein Abonnement Interesse an einer Hinweisklasse ausdrücken. Erlaubnis, Erreichbarkeit und menschliche Aufmerksamkeit blieben davon unabhängige Fragen.

Quellen