Resumen

  • El RFC 992 planteó anunciar fallos y recuperaciones mediante multidifusión ordenada, para que los miembros activos de un grupo compartieran la secuencia de cambios de composición.
  • GBCAST organizaba esos cambios; ABCAST hacía coincidir el orden de operaciones replicadas; CBCAST conservaba la causalidad y dejaba correr en paralelo los mensajes independientes.

Una petición para sacar el primer elemento de una cola sale hacia tres máquinas. Antes de llegar a todas, una se apaga. Las otras dos siguen encendidas, pero una ve primero la petición y la otra, primero el aviso de caída. Cada cual puede actuar con impecable lógica y producir un resultado distinto. La alta disponibilidad acaba convertida en una discusión entre testigos que estuvieron en la misma sala y juran haber visto otra película.

Kenneth Birman y Thomas Joseph describieron esa carrera en el RFC 992, publicado en noviembre de 1986 a partir del trabajo de ISIS en Cornell. Los RFC 966 y RFC 988 habían tratado los grupos de hosts y el envío a varios receptores. El problema de Cornell aparecía justo cuando la lista de receptores cambiaba durante el envío. En ese instante, entregar el mensaje por sí solo no bastaba: también importaba qué miembros contaban como grupo cuando cada réplica lo interpretaba.

Su herramienta más severa se llamaba GBCAST. Un miembro que volvía anunciaba su recuperación; por uno que caía, el sistema enviaba el aviso. El servidor muerto, naturalmente, no podía redactar su despedida. El protocolo le buscaba portavoz. Ese mensaje de cambio de grupo quedaba ordenado con los demás: si un receptor había visto una petición antes del aviso, los destinos compartidos también la verían antes. Los mensajes previos del emisor caído llegaban antes de su propia noticia de caída. Así, cada miembro mantenía una VIEW de la composición del grupo que avanzaba por la misma serie de cambios.

No había una campanada universal; había un orden de capítulos.

GBCAST era caro en coordinación, por lo que los autores no lo proponían como saludo obligatorio para cada mensaje. ABCAST resolvía otra necesidad: los mensajes con la misma etiqueta llegaban en el mismo orden a los destinos comunes. Una cola replicada podía aplicar sus operaciones sin que cada copia improvisara una secuencia. CBCAST era más ligero: respetaba la cadena causal entre mensajes, mientras dejaba a los independientes circular sin desfile. La elección era económica en el sentido más literal de la ingeniería: pagar exactamente por la sincronización que salva la consistencia.

El trabajo asumía fallos de parada y un mecanismo que los detectaba. Sus ejemplos de relojes de estaciones de trabajo y retrasos entre sitios reflejan las condiciones de aquel laboratorio, donde confiar en una hora idéntica para resolver carreras resultaba poco convincente. El artículo presentaba una arquitectura en desarrollo, con un prototipo anterior de ISIS completado y una nueva implementación en marcha. La idea que atravesó el papel era más simple que sus siglas: la desaparición de un miembro modifica el significado de los mensajes que quedan. Hay que entregar también esa desaparición.

El ordenador caído se perdió la reunión. Los demás, al menos, recibieron el acta en el mismo orden.