Resumen

  • El RFC 1235 diseñó una difusión de archivos para varios clientes, motivada por el arranque simultáneo de estaciones sin disco sobre una red de radio experimental.
  • Cada cliente escuchaba primero un envío en marcha. Podía pedir el archivo completo si no oía tráfico y, más tarde, reclamar solo sus propios bloques ausentes.

La red no debería pagar tres veces por los mismos bytes. Así se entiende la propuesta que John Ioannidis y Gerald Maguire Jr. publicaron en junio de 1991. Su RFC 1235 describe el Coherent File Distribution Protocol, CFDP: un servidor envía por difusión un archivo que varios equipos necesitan al mismo tiempo. La prueba que dio origen al diseño fue el arranque simultáneo de estaciones de trabajo sin disco en una red de radio experimental.

Los autores veían la misma forma de tráfico en actualizaciones de software para varias máquinas y en objetos compartidos durante una clase o conferencia electrónica. Hay pocos emisores, muchos clientes y un archivo idéntico. En transferencias individuales, el servidor repite N veces el contenido y carga la red con N copias. CFDP intentaba gastar el ancho de banda común una vez, siempre que el medio permitiera difusión.

Primero hacía falta una entrada. Un servicio frontal asignaba al nombre del archivo un ticket de 32 bits, el tamaño del archivo y el de cada bloque. Podía adaptarse BOOTP o TFTP para esa tarea; la correspondencia nombre-ticket quedaba fuera del núcleo de CFDP. Con el ticket, el cliente escuchaba si ya circulaban paquetes de ese archivo. Si se incorporaba tarde, aprovechaba lo que aún pasaba. Si no oía nada antes del plazo fijado, enviaba FULREQ para iniciar el archivo entero.

El servidor difundía bloques UDP numerados. Cada estación comprobaba los paquetes y colocaba los datos en su posición. Una podía haber perdido el principio por llegar tarde; otra, un bloque intermedio. Tras un intervalo sin recibir datos, la máquina incompleta enviaba PARREQ con sus números pendientes. La cronología de tres clientes que contiene el RFC enseña justamente eso: el servidor hace una emisión, pero cada receptor lleva su propio inventario de huecos.

El servidor ignoraba solicitudes nuevas del mismo archivo mientras una transmisión seguía en curso. Los clientes debían esperar y repetir sus peticiones. Los autores evitaron el control de flujo individual y prefirieron espaciar los paquetes para que los receptores no se ahogaran. Propusieron un intervalo cercano al doble del tiempo que tarda la interfaz en transmitir un paquete; en sus ensayos, plazos de seis a ocho veces ese tiempo funcionaron mejor. La velocidad de quien emite no demuestra que cada equipo haya podido seguirla.

El tamaño sugerido de 512 bytes por bloque mantenía el paquete por debajo de los 576 bytes de MTU mínimo IP citados en el RFC. Con números de bloque de 16 bits, un archivo lógico llegaba hasta 32 MB; a 1024 bytes por bloque, hasta 64 MB. Para archivos mayores había que dividirlo. La difusión también alcanzaba a máquinas ajenas al envío, por lo que el texto veía en IP multicast una mejora cuando esa tecnología estuviera más extendida.

La ficha oficial clasifica CFDP como Experimental. El RFC menciona programas de referencia, pero no mide una implantación general ni el éxito final de un arranque. Su aporte histórico está en la contabilidad: ahorrar copias en el centro exige conocer las piezas que todavía le faltan a cada extremo.

Fuentes