Кратко

  • RFC 1235 описал передачу одного файла многим клиентам по сети с широковещательной доставкой. Авторы исходили из одновременной загрузки бездисковых станций в экспериментальной пакетной радиосети.
  • Клиент сначала слушал уже идущую передачу, при её отсутствии просил весь файл, а после паузы запрашивал только собственные недостающие номера блоков.

Три рабочие станции просят один файл. Если сервер ведёт с каждой отдельный разговор, он отправляет одни и те же байты трижды. John Ioannidis и Gerald Maguire Jr. в июньском RFC 1235 1991 года предложили использовать свойство среды, где одну передачу слышат многие. Их Coherent File Distribution Protocol, CFDP, переносил основную копию файла в общий поток.

Отправной задачей была одновременная загрузка бездисковых станций через экспериментальную пакетную радиосеть. Авторы приводили и другие ситуации: одно обновление программ на множество машин, один объект для участников электронного занятия. У всех клиентов совпадало содержимое запроса. Повторять большой файл N раз означало нагружать сервер и сеть работой, которая не добавляет новых данных.

Получатель начинал не с файла, а с билета. Внешняя служба связывала имя файла с 32-битным идентификатором, размером файла и блока. Для неё годился изменённый BOOTP или TFTP; сама привязка имени к билету стояла вне основного протокола CFDP. Получив билет, станция сперва слушала пакеты с таким идентификатором. Возможно, кто-то уже запустил рассылку. Если подходящих пакетов не было до истечения времени ожидания, клиент отправлял FULREQ с просьбой передать файл целиком.

Сервер рассылал пронумерованные блоки UDP. Каждый клиент проверял пакет и размещал данные по указанному смещению. Опоздавший пропускал начало; другой мог потерять один пакет посередине. Когда поток затихал, а локальный файл ещё имел дыры, станция отправляла PARREQ со списком своих пропущенных номеров. Пример с тремя клиентами в RFC показывает, как из одного общего потока выходят три разные истории приёма.

Ремонт не был мгновенным. Запросы на тот же файл, пришедшие во время его передачи, сервер игнорировал; клиент ждал и повторял попытку. Авторы не стали строить отдельное управление скоростью под каждую станцию. Они предложили замедлять отправку паузой между пакетами — примерно вдвое дольше времени передачи пакета сетевым интерфейсом. В их эксперименте ожидание длиной в шесть-восемь таких времён давало лучший результат. Сервер мог быстро закончить работу и всё же оставить медленный приёмник с пустыми местами.

Блок в 512 байт удерживал пакет ниже приведённого в документе минимального IP MTU в 576 байт. При 16-битном номере блока предел логического файла составлял 32 МБ; при блоке 1024 байта — 64 МБ. Больший файл следовало делить. Обычную широковещательную передачу слышали и посторонние машины, поэтому авторы считали IP multicast более удачным выбором после распространения его реализаций.

Официальная карточка относит CFDP к Experimental. RFC сообщает о референсных программах, но не содержит подсчёта распространения или результата завершённой загрузки конкретной станции. Историческая ценность проекта — в расчёте конца работы: общую передачу можно закончить один раз, а полным файл должен стать отдельно у каждого получателя.

Источники