Resumo

  • O Project Athena criou o Zephyr para encaminhar avisos curtos e urgentes em uma rede crescente de estações de trabalho, onde o broadcast local e o e-mail falhavam de maneiras diferentes.
  • Identidade autenticada, local do login, exposição escolhida, assinatura de tópico e entrega eram estados separados; nenhum deles provava disponibilidade ou leitura.

O primeiro desafio não era exibir texto em uma janela. Era alcançar a pessoa certa quando a computação deixava de estar concentrada em um computador compartilhado. Os planos do Athena de 1987–88 descrevem a mudança para muitas estações de trabalho em rede. Um servidor de arquivos precisava avisar seus usuários de uma parada; o serviço de impressão precisava comunicar a conclusão de um trabalho; um assistente de ensino talvez quisesse alcançar uma turma. O e-mail preservava mensagens, mas exigia espera e uma lista de destinatários.

O broadcast de rede era rápido, porém restrito à rede local e obrigava cada máquina a processar mensagens destinadas a poucos usuários. Os projetistas do Zephyr resumiram o contraste: o e-mail era lento e trabalhoso; o broadcast era passageiro e não escalava.

O Zephyr foi pensado como uma camada de transporte para diferentes serviços de comunicação. O artigo da USENIX de 1988 descrevia uma base sobre a qual seriam construídas camadas de assinatura e localização de usuários. O plano técnico de 5 de junho de 1989 detalhou a arquitetura: cada estação teria um HostManager (zhm), cada sessão de login um cliente WindowGram (zwgc), e vários servidores Zephyr cuidariam de registro, roteamento e estado. O aviso separava cabeçalho de roteamento e dados do cliente. O servidor consultava o cabeçalho para encontrar os destinatários, sem interpretar o corpo. Um servidor de arquivos podia notificar quem já conhecia; um serviço sem público fixo podia publicar em uma classe e deixar os clientes assinarem.

A assinatura era um estado explícito, não um chamado para o campus inteiro. O servidor guardava uma tupla de classe, instância e destinatário. O cliente solicitava a assinatura e recebia avisos que correspondiam a ela. zwrite direcionava a mensagem a uma identidade específica. O Kerberos fornecia principais autenticados usados como Zephyr IDs, permitindo distinguir uma conta autenticada de um nome digitado no texto. Mas autenticação respondia “qual identidade fez este pedido?”, não “essa pessoa tem autorização para localizar ou interromper qualquer destinatário?”. Controles de acesso, exposição do usuário e avisos de emergência privilegiados eram tratados separadamente.

A presença também tinha limites. O Zephyr registrava logins e locais para entregar avisos sem exigir que o remetente soubesse em qual estação a pessoa estava. Os projetistas alertaram que o banco de localizações não era uma lista perfeita em tempo real. Um registro indicava que um login autenticado havia sido informado; se a estação travasse, o aviso de saída poderia não chegar e o dado antigo permanecer. A inferência contrária também falhava: não ver uma localização não provava que a pessoa nunca havia entrado, pois ela podia escolher não expor esse dado. Reinicializações e falhas de resposta acionavam a limpeza de estados antigos.

Isso reduzia os erros, mas não tornava o serviço distribuído uma testemunha infalível.

O plano de 1989 enumerava seis níveis de exposição: none, opstaff, realm-visible, realm-announced, net-visible e net-announced. A consulta de localização e o anúncio de login e logout não eram o mesmo botão. O guia de usuários do MIT de 1993 também diferenciava hide de desligar o serviço: esconder a localização não impedia outras pessoas de enviar avisos. Era um controle mais limitado do que um botão universal de “não entre em contato”.

A confiabilidade do transporte era outra questão. O Zephyr usava UDP e acrescentava níveis de confirmação conforme a necessidade da aplicação. Os projetistas registraram a possibilidade de duplicatas, reordenação, perda e ausência de controle de fluxo. O exemplo de zwrite garantia que a mensagem havia sido enviada, não que chegaria ou chegaria uma única vez. A confirmação do servidor, a do cliente e a leitura por uma pessoa eram eventos diferentes. O Zephyr servia à coordenação rápida, mas um recibo de transporte não comprovava consentimento, atenção nem trabalho concluído.

Em 1993, o guia do MIT já descrevia Zephyrgrams individuais e em grupo como ferramentas comuns do Athena; um estudo de 1996 examinou o Zephyr Help como canal síncrono de suporte. Isso comprova uso no MIT, não que o Zephyr tenha se tornado o modelo universal de mensagens instantâneas. O que sua história esclarece é a separação que manteve: a identidade permitia o roteamento, o login alimentava um registro de localização e a assinatura expressava interesse em uma classe de avisos, enquanto permissão, alcance e atenção continuavam sendo questões distintas.

Fontes