Summary

  • RFC 1235 proposed sending one file by broadcast to many clients, motivated by simultaneous booting of diskless workstations on an experimental packet-radio network.
  • Each client first listened for an existing transfer, then asked for the full file if needed. After a timeout it could request only its own missing numbered blocks; the server paced packets instead of using per-client flow control.

Three workstations want the same boot file. A conventional server can send it three times, once down each private conversation. The file has not changed, but the network and server pay for three transmissions. In June 1991, John Ioannidis and Gerald Maguire Jr. published RFC 1235 with a different bargain: exploit a broadcast-capable medium, send the file once, and let receivers collect whichever parts they hear.

The authors had built the protocol around simultaneous booting on an experimental packet-radio network. They also named software upgrades to several machines and shared objects in a live class as possible uses. Those examples share a shape: one sender, many clients, identical bytes. The proposal called that traffic coherent. Its economic promise was plain. Sending the same file N times wastes server work and network capacity when a single transmission can reach N listeners.

Getting onto that shared transmission required a ticket. A front end, perhaps a modified BOOTP or TFTP service, mapped a file name to a 32-bit ticket, a block size and the file size. That name-to-ticket step sat outside the core CFDP transfer. A client with a ticket listened first: another client might already have caused the server to start broadcasting that file. Only after a timeout without matching traffic did it send a full-file request, FULREQ. Late arrival no longer required the server to begin again from byte one.

The server broadcast numbered UDP blocks. Each workstation checked a packet, placed it at the offset identified by its block number and marked that block received. The three machines could hear different subsets. One might miss the beginning because it joined late; another might lose a block in the middle. Silence triggered a different request: PARREQ listed the block numbers that particular client still lacked. The RFC's worked three-client timeline made the separation visible. One broadcast was shared; completion remained personal to each receiver.

The protocol did not make requests free. If a request for the same file arrived during an ongoing transfer, the server ignored it. The client waited and tried again. To prevent the sender from overrunning clients, the authors favored spacing packets rather than per-client flow control. They suggested a delay around twice the interface's packet transmission time, and reported that timeouts of six to eight packet transfer times worked best in their experimental setting. A fast server could still be too fast for a receiver; one shared stream has to respect the machines trying to keep up.

The suggested 512-byte block size kept a packet below the 576-byte IP minimum MTU cited by the RFC. A 16-bit block number then limited one logical file to 32 MB; at 1024 bytes per block the limit rose to 64 MB. Larger files needed splitting. The RFC also said IP multicast would reduce overhead on machines that were not participants once multicast implementations became more common. Broadcast saved duplicate sends while making every bystander on that medium hear the traffic.

The RFC Editor record marks CFDP Experimental. The RFC reports reference clients and a server, but no measured adoption or completed boot outcome. Its lasting scene is the repair ledger: the sender broadcasts a common file, while each workstation still has to prove to itself that every block arrived. The network can share the large job. It cannot share away the last missing piece.

Sources