Resumen

  • Para usar recursos repartidos entre varias máquinas, Cronus debía descubrir primero quién los ofrecía. Su pregunta colectiva no salía de la red local; dos procesos en ordenadores distintos hicieron llegar las preguntas elegidas al otro lado.
  • Sus operadores pudieron definir destinos y filtros sin cambiar pasarelas ajenas. El ordenador compartido pagó ese control: su proceso se despertaba por cada UDP recibido, aunque lo descartase.

Si un servidor estaba al otro lado de una pasarela, Cronus podía hablarle una vez conocida su dirección. El problema era descubrir primero cuál era el servidor. Para una aplicación que reparte trabajo entre máquinas, esa diferencia determina si puede incorporar un recurso a su funcionamiento normal. La pregunta colectiva se quedaba con los vecinos de la Ethernet de origen. Alguien debía escoger ciertas preguntas y volver a pronunciarlas en la LAN distante.

Esa decisión no cabía sin más en un dibujo de cables. Para conservar la dirección del emisor original, el ordenador que repetía un mensaje tenía que poder usar una dirección ajena. Los ingenieros de Cronus añadieron esa capacidad, reservada a procesos privilegiados, a su implementación de TCP/IP. La solución exigía software y responsables concretos, aunque al emisor le pareciera transparente.

La RFC 947, publicada en junio de 1985, lo cuenta al describir un experimento de BBN Laboratories. Sus autores, Ken Lebowitz y David Mankins, querían ampliar el radio de acción de Cronus, un sistema operativo distribuido que reunía servicios de ordenadores de distintos tipos.

Cronus utilizaba TCP y UDP. También recurría a la difusión para localizar recursos y recoger el estado de varios servidores. Esa forma de preguntar tenía una ventaja práctica: permitía dirigirse a los vecinos sin conocer de antemano todas sus direcciones. Pero los paquetes difundidos en una red local no llegaban por ese mecanismo a quienes estaban al otro lado de una pasarela.

La mayoría de esas preguntas interesaba solo a una parte de los receptores. Los autores reconocían que la multidifusión encajaba mejor, aunque no estaba disponible en algunas de sus implementaciones. Las primeras herramientas emplearon la difusión que sí podían utilizar. La RFC 919 de 1984 ya había señalado su contrapartida: cada ordenador que oye un mensaje tiene que dedicarle algún esfuerzo.

Decidir qué sale de la red

El repetidor de Cronus separaba una decisión de una entrega. En la red de origen, un proceso elegía qué preguntas merecían cruzar el límite, al principio por los puertos UDP de Cronus. En la red de destino, otro proceso hacía que las máquinas locales pudieran oírlas. El primero encapsulaba los paquetes seleccionados y los enviaba al segundo; este volvía a difundirlos sin perder la dirección de origen. La separación permitía conservar la selección junto a quienes configuraban Cronus y usar la pasarela solo como camino entre ambos extremos.

Al arrancar, el proceso de transferencia leía un archivo con las direcciones de los repetidores y las reglas para cada destino. Abría conexiones TCP y reintentaba periódicamente las que fallaban. También podía enviar un datagrama directamente a un ordenador normal incluido en el archivo. Ese destinatario no necesitaba ofrecer un servicio de repetición.

La posibilidad de cambiar la lista era parte del atractivo. Los ingenieros habían considerado incorporar la función a las pasarelas de Internet, pero eso exigía nuevos mecanismos de control y dependía de que los fabricantes la implementaran. Además, las decisiones sobre qué mensajes necesitaba Cronus pertenecían a una capa con conocimiento de la aplicación.

Había una dificultad aún más cotidiana: quien administraba la pasarela podía pertenecer a una organización distinta de la que configuraba Cronus. Ampliar un conjunto experimental de ordenadores podía convertirse en una gestión sobre equipos ajenos. La RFC incluyó esa complicación entre sus razones para elegir procesos en un host.

Llevar la función al núcleo de Cronus tampoco resolvía todo. Según los autores, las alternativas examinadas exigían que cada participante conociera las direcciones de los demás o daban lugar a una solución específica del sistema. Un repetidor separado ofrecía un punto de configuración propio y podía servir a otros protocolos basados en difusión.

Los paquetes que sobraban también contaban

El montaje comunicaba dos Ethernets separados por otras dos redes locales, atravesando al menos dos pasarelas. Funcionaba en un VAX con 4.2BSD UNIX y software de red de BBN. Los autores informaron de varios meses de uso satisfactorio para sus fines: una experiencia concreta, sin cifras que permitan atribuirle una adopción general.

El diseño incluía precauciones para que los mensajes no circularan de vuelta. El proceso no se conectaba a repetidores de su propia LAN ni reenviaba paquetes cuya dirección de origen perteneciera a otra red. Conservar esa dirección ayudaba a tomar la decisión, pero no demostraba la identidad del remitente.

La carga del servicio aparecía antes de decidir si un paquete merecía viajar. Como el filtrado se hacía en software de usuario, cada paquete UDP que llegaba al host despertaba al proceso. Muchos podían acabar descartados; el ordenador compartido ya había realizado trabajo para examinarlos.

Los autores contemplaron trasladar el filtrado al núcleo del sistema, dejando la configuración y la repetición en programas de usuario. También planeaban mover el servicio a un sistema de tiempo real basado en un microordenador que ya formaba parte de Cronus. El documento no confirma que ninguna de esas opciones se completara.

El avance consistía en poder ajustar el alcance de las consultas desde el propio sistema. Su coste se encontraba en un ordenador que atendía paquetes, mantenía conexiones y volvía a intentarlo cuando fallaban. La historia de ese repetidor permite ver la autonomía como una capacidad que alguien tenía que sostener cada día.

El RFC 922 ofrece el contexto contemporáneo de la difusión IP con subredes. El RFC 1112, posterior, especificó extensiones para multidifusión IP; no demuestra que sustituyera esta instalación de Cronus.