Résumé

  • Le projet Athena a conçu Zephyr pour acheminer de brèves notices urgentes à travers un réseau de stations de travail, là où les diffusions locales et le courrier électronique échouaient chacune à leur manière.
  • Identité authentifiée, lieu de connexion, visibilité choisie, abonnement à un sujet et livraison restaient des états distincts ; aucun ne prouvait disponibilité ou lecture.

Le problème initial n’était pas d’afficher un texte dans une fenêtre. Il fallait atteindre la bonne personne après le passage d’une machine partagée à de nombreuses stations connectées. Les plans d’Athena de 1987–1988 décrivent ce changement à l’échelle d’un campus. Un serveur de fichiers devait prévenir ses utilisateurs d’un arrêt ; l’impression devait signaler la fin d’un travail ; un assistant pouvait vouloir joindre une classe. Le courrier persistait, mais impliquait un délai et une liste de destinataires connue.

La diffusion réseau était rapide, mais restait locale et imposait à chaque machine de traiter les messages destinés à quelques-uns. Les concepteurs de Zephyr résumaient le compromis : le courriel était lent et lourd ; la diffusion était éphémère et ne passait pas à l’échelle.

Zephyr fut donc conçu comme une couche de transport pour plusieurs formes de communication. L’article USENIX de 1988 décrit un transport de base, complété par des couches d’abonnement et de localisation. Le plan technique du 5 juin 1989 précise l’architecture : un HostManager (zhm) par station, un client WindowGram (zwgc) par session, et plusieurs serveurs Zephyr pour les inscriptions, l’acheminement et l’état. Une notice séparait son en-tête de routage de ses données. Le serveur lisait l’en-tête pour trouver les destinataires, sans interpréter le corps. Le serveur de fichiers pouvait écrire aux personnes déjà concernées ; un service sans public fixe pouvait publier dans une classe et laisser les clients s’abonner.

L’abonnement n’était pas un cri lancé à tout le campus. Le serveur conservait un triplet classe, instance et destinataire. Le client demandait cet abonnement, puis les notices correspondantes étaient acheminées aux personnes intéressées. zwrite désignait un destinataire précis. Kerberos fournissait les identités authentifiées servant de Zephyr IDs : le système pouvait distinguer un compte authentifié d’un simple nom saisi. Mais l’authentification répondait à « qui a formulé cette demande ? », pas à « cette personne a-t-elle le droit de localiser ou d’interrompre tout destinataire ? ». Les contrôles d’accès, les niveaux de visibilité et les notices d’urgence privilégiées étaient traités séparément.

La présence avait ses propres limites. Zephyr enregistrait les connexions et les lieux pour router une notice sans que l’expéditeur connaisse la station utilisée. Les concepteurs avertissaient de ne pas prendre la base de localisation pour un relevé parfait en temps réel. Une entrée attestait qu’une connexion authentifiée avait été signalée ; une panne pouvait empêcher le message de déconnexion et laisser une donnée obsolète. L’absence d’entrée ne prouvait pas davantage que la personne ne s’était jamais connectée : elle pouvait choisir de ne pas rendre son lieu visible.

Les redémarrages et les échecs de réponse déclenchaient un nettoyage de l’état ancien. Cela réduisait les erreurs sans rendre le témoignage distribué infaillible.

Le plan de 1989 proposait six niveaux de visibilité : none, opstaff, realm-visible, realm-announced, net-visible et net-announced. La consultation de localisation et l’annonce des connexions n’étaient pas un seul interrupteur. En 1993, le guide utilisateur du MIT distinguait aussi la commande hide de la désactivation du service : masquer sa localisation n’empêchait pas les autres d’envoyer une notice. Ce contrôle était plus étroit qu’un bouton universel « ne me contactez pas ».

La fiabilité du transport constituait une autre question. Zephyr reposait sur UDP et ajoutait plusieurs niveaux d’accusé de réception. Les concepteurs signalaient les doublons, le désordre, les pertes et l’absence de contrôle de flux. L’exemple zwrite garantissait l’envoi, pas l’arrivée ni l’unicité. Accusé du serveur, accusé du client et lecture humaine étaient trois événements différents. Zephyr servait à la coordination rapide, mais un reçu de transport ne démontrait ni consentement, ni attention, ni travail accompli.

En 1993, le guide du MIT présentait les Zephyrgrams individuels et collectifs comme des outils courants d’Athena ; une étude de 1996 observait le canal Zephyr Help comme moyen d’assistance synchrone. Cela documente l’usage au MIT, sans prouver que Zephyr serait devenu le modèle universel de la messagerie instantanée. Son histoire éclaire plutôt la frontière qu’il a tracée : l’identité pouvait permettre le routage, la connexion alimenter un registre de localisation et l’abonnement exprimer un intérêt pour une classe de notices, tandis que permission, joignabilité et attention restaient des questions séparées.

Sources