摘要

  • RFC 1235 为支持广播的网络设计了一对多文件传送，直接动机是在实验性分组无线网络上让无盘工作站同时启动。
  • 客户端先听是否已有同文件传输；没有就请求整份文件。收不齐时，它列出自己缺失的块号，请服务器单独补发那些块。

服务器发完一份文件，与三台机器都拿到这份文件，是两件事。John Ioannidis 与 Gerald Maguire Jr. 在 1991 年 6 月的 RFC 1235 中，正是围绕这个差别设计 CFDP。多台无盘工作站需要同一份启动文件，逐台单播就要把相同字节送出 N 遍。广播能让一份数据同时经过许多接收者，服务器和网络少做重复劳动。

方案出自实验性分组无线网络上的同时启动需求。作者还举了批量软件升级、电子课堂里向所有人发送同一对象的例子。它们并非同一款应用，却都有“一人发送、多人要同样内容”的流量形状。文件有几份不是关键；每份文件被送了几遍，才是服务器的成本账。

要加入广播，工作站先向前端索取一张票据：32 位标识符、文件长度、分块大小。前端可借助修改过的 BOOTP 或 TFTP 服务把文件名换成票据；这一步不属于 CFDP 的核心传输。拿到票据后，客户端先监听同票据的数据流。另一台机器若已启动传送，新来的机器便接住后面的块。等了一段时间仍听不到，才发 FULREQ 请求整份文件。

服务器把文件分成带编号的 UDP 数据块广播出去。每台机器检查收到的块，并按块号把它写到本地文件的正确位置。迟到者可能缺开头，另一台可能在中间漏一个块。数据停下来、文件仍不完整时，各自发 PARREQ，列出自己的缺块编号。RFC 里三台客户端的示例把这种分叉画得很清楚：大流量可以共用，缺块清单不能共用。

补发也不是随叫随到。若同一文件正在传输，服务器忽略新来的整文件或部分块请求；客户端等超时再试。作者没有让每台机器单独控制广播速度，而是要求服务器在数据包之间留间隔，以免接收者跟不上。他们建议间隔大约是网卡发送一个包所需时间的两倍，并报告在自己的实验里，六到八倍包传输时间的超时设置效果较好。这些数字显示设计要顾及接收端的节奏。

块长选 512 字节时，连同报头的包低于文档引用的 IP 576 字节最低 MTU。块号只有 16 位，于是一份逻辑文件上限为 32 MB；块长改成 1024 字节，上限为 64 MB。更大的内容需要拆分。作者还指出，普通广播会打扰不参与传输的机器；当 IP 多播更普及，多播地址会更合适。

RFC Editor 状态页 将 CFDP 标为 Experimental。RFC 记载了参考客户端和服务器，但没有给出普及数量或任何工作站完成启动的记录。它留下一个比“广播很省带宽”更重要的旧问题：公共传输结束那一刻，最后一台机器还缺哪几块？

来源