Resumen

  • El proyecto Athena diseñó Zephyr para llevar avisos breves y urgentes por una red creciente de estaciones de trabajo, donde las difusiones locales y el correo fallaban de maneras distintas.
  • La identidad autenticada, el lugar de conexión, la exposición elegida, la suscripción temática y la entrega eran estados distintos; ninguno demostraba disponibilidad o lectura.

El reto no era mostrar texto en una ventana. Era alcanzar a la persona correcta cuando la informática dejaba de concentrarse en una máquina compartida. Los planes de Athena de 1987–88 describen un campus que pasaba a muchas estaciones conectadas. Un servidor de archivos debía avisar de un corte a sus usuarios; la impresora, informar que había terminado un trabajo; un ayudante docente, contactar con una clase. El correo podía conservarse, pero implicaba demora y una lista de destinatarios. La difusión de red era rápida, aunque solo alcanzaba la red local y obligaba a cada equipo a procesar mensajes destinados a unos pocos.

Los diseñadores resumieron el intercambio: el correo era lento y engorroso; la difusión era fugaz y no escalaba.

Por eso Zephyr se planteó como transporte de avisos sobre el que podían montarse varios servicios. El artículo de USENIX de 1988 describe una capa básica y otras de suscripción y localización. El plan técnico del 5 de junio de 1989 concreta la arquitectura: un HostManager (zhm) por estación, un cliente WindowGram (zwgc) por sesión y varios servidores Zephyr para registrar usuarios, enrutar y conservar estado. El aviso separaba la cabecera de encaminamiento de los datos del cliente. Los servidores leían la cabecera para hallar destinatarios, sin tener que interpretar el cuerpo. Un servidor de archivos podía escribir a usuarios que ya conocía; un servicio sin público definido podía publicar en una clase y dejar que los clientes se suscribieran.

La suscripción era estado explícito, no un grito a todo el campus. El servidor guardaba una tupla de clase, instancia y destinatario. El cliente podía pedir la suscripción y recibir después los avisos coincidentes. zwrite dirigía un mensaje a una identidad concreta. Kerberos aportaba los principales autenticados que servían como Zephyr IDs. Así, el sistema diferenciaba una cuenta autenticada de un nombre escrito en un mensaje. Pero autenticar respondía «¿qué identidad envió esta solicitud?», no «¿tiene permiso para localizar o interrumpir a cualquiera?». Los controles de acceso, la exposición elegida y los avisos de emergencia privilegiados se trataban por separado.

La presencia también tenía límites. Zephyr registraba las sesiones y sus ubicaciones para poder enrutar avisos sin que el remitente supiera qué estación usaba la persona. Los diseñadores advirtieron que la base de localización no era un listado perfecto y actualizado. Una entrada indicaba que se había registrado un inicio de sesión autenticado, pero una caída del equipo podía impedir el aviso de salida y dejar datos obsoletos. La inferencia contraria tampoco servía: la falta de una ubicación visible no demostraba que nadie hubiera iniciado sesión, pues la persona podía ocultar ese dato.

El reinicio y los fallos de respuesta activaban la limpieza de estado antiguo. Reducían los errores, pero no convertían el servicio distribuido en un testigo infalible.

El plan de 1989 enumeraba seis niveles de exposición: none, opstaff, realm-visible, realm-announced, net-visible y net-announced. Consultar la ubicación y anunciar cada inicio o cierre no eran un único interruptor. En 1993, la guía de usuario del MIT también distinguía hide de apagar Zephyr: ocultar la ubicación no impedía que otros enviaran avisos. Era un control más limitado que un botón universal de «no me contactes».

La fiabilidad del transporte era otra cuestión. Zephyr usaba UDP y ofrecía varios niveles de confirmación. Sus diseñadores documentaron duplicados, desorden, pérdidas y ausencia de control de flujo. El ejemplo de zwrite garantizaba el envío, no la llegada ni que hubiera una sola copia. La confirmación del servidor, la del cliente y la lectura humana eran sucesos distintos. Zephyr facilitaba la coordinación rápida, pero un recibo de transporte no probaba consentimiento, atención ni trabajo terminado.

En 1993, la guía del MIT describía los Zephyrgrams individuales y grupales como herramientas habituales de Athena; un estudio de 1996 examinó Zephyr Help como canal de asistencia sincrónica. Eso prueba usos en el MIT, no que Zephyr se convirtiera en el modelo universal de mensajería instantánea. Su historia resulta más reveladora por la frontera que trazó: la identidad permitía enrutar, el inicio de sesión alimentaba un registro de ubicación y la suscripción expresaba interés en una clase de avisos, mientras permiso, alcance y atención seguían siendo preguntas distintas.

Fuentes