Resumo

  • O RFC 992 tratou falha e recuperação como mensagens de grupo ordenadas, para que os processos ativos avançassem pela mesma sequência de mudanças de membros.
  • GBCAST organizava a composição do grupo; ABCAST alinhava operações compartilhadas; CBCAST preservava relações de causa e efeito sem segurar mensagens independentes.

Pense numa fila de tarefas guardada por três cópias. Chega um pedido para retirar o primeiro item. No mesmo instante, uma máquina apaga. Uma sobrevivente vê o pedido antes do aviso da falha; a outra recebe o aviso primeiro. As duas seguem instruções plausíveis e terminam com filas diferentes. A redundância salvou o hardware, mas deixou o serviço com duas biografias. É uma maneira bastante sofisticada de continuar funcionando errado.

Kenneth Birman e Thomas Joseph enfrentaram essa corrida no RFC 992, publicado em novembro de 1986 como parte do trabalho ISIS em Cornell. Os RFC 966 e RFC 988 já discutiam grupos de hosts e comunicação em multicast. A pergunta aqui era mais afiada: quando a lista de membros muda durante a entrega, qual lista dá sentido ao pedido? Uma mensagem enviada ao grupo tem consequências diferentes conforme quem ainda faz parte dele.

O instrumento mais rígido recebeu o nome GBCAST. Um processo recuperado anuncia sua volta; quando alguém falha, o sistema manda a notícia em seu nome. O morto ganha um porta-voz, porque escrever o próprio comunicado já está fora das suas capacidades. A notícia entra na ordem das mensagens comuns. Se um destinatário recebe um pedido antes do anúncio de falha, os destinatários em comum também observam essa ordem. As mensagens anteriores do processo caído chegam antes de sua notificação de queda. Cada participante mantém uma VIEW, uma versão da composição do grupo, e acompanha a mesma sequência de mudanças.

Os relógios não precisam bater à mesma hora; a narrativa precisa seguir as mesmas páginas.

Todo esse cuidado custa coordenação. Por isso, os autores reservaram GBCAST para mudanças de composição e outras ações globais, como classificação dos membros, pontos de recuperação e migração. ABCAST dá a mensagens com o mesmo rótulo a mesma ordem nos destinos compartilhados; uma fila replicada precisa desse acordo ao aplicar operações. CBCAST cobra menos: conserva a ordem entre mensagens ligadas por causalidade e deixa as independentes seguir caminho. A pergunta prática é quanto ordenamento cada tarefa merece. Comprar a cerimônia completa para toda mensagem faria a resiliência perder o fôlego.

O modelo partia de falhas do tipo parar e de um mecanismo capaz de detectá-las. Os números sobre relógios de estações de trabalho e trânsito entre locais eram argumentos do laboratório dos anos 1980 para desconfiar de uma solução baseada apenas em horário. O texto registrava um protótipo anterior de ISIS concluído e uma nova implementação em andamento. Seu ponto mais duradouro cabe numa cena: se a saída de um membro altera o significado da próxima ordem, a saída também precisa ser entregue como parte da conversa.

A máquina caída perdeu a reunião. As outras receberam a ata sem trocar a ordem dos acontecimentos.