Zusammenfassung

  • RFC 1235 schlug eine gemeinsame Dateiübertragung für viele Empfänger vor. Ausgangspunkt war der gleichzeitige Start plattenloser Workstations über ein experimentelles Paketfunknetz.
  • Ein Client hörte erst nach einer laufenden Übertragung, forderte bei Stille die ganze Datei an und meldete nach Verlust nur die eigenen fehlenden Blocknummern zurück.

Dem Server war der Inhalt gleichgültig; er musste bloß dieselben Bytes immer wieder verschicken. So lässt sich die Last beschreiben, gegen die John Ioannidis und Gerald Maguire Jr. im Juni 1991 RFC 1235 schrieben. Wenn N Workstations dieselbe Datei brauchen, erzeugen N Einzelverbindungen N Kopien auf dem Netz. Ein sendefähiges gemeinsames Medium kann einen Datenstrom an alle liefern. CFDP, das Coherent File Distribution Protocol, sollte diese Eigenschaft ausnutzen.

Entstanden war der Vorschlag für den gleichzeitigen Start plattenloser Rechner auf einem experimentellen Paketfunknetz. Die Autoren nannten auch Softwareverteilung an mehrere Maschinen und gemeinsame Objekte in einem elektronischen Unterricht. Der Fall bleibt derselbe: wenige Quellen, viele Empfänger, gleiche Datei. Die große Sendung kann geteilt werden; die Umstände des Empfangs sind verschieden.

Ein vorgeschalteter Dienst ordnete dem Dateinamen ein 32-Bit-Ticket, Dateigröße und Blockgröße zu. Ein angepasster BOOTP- oder TFTP-Dienst konnte diese Aufgabe übernehmen. Die Namensauflösung gehörte nicht zum eigentlichen CFDP-Transfer. Mit dem Ticket lauschte der Client zunächst auf Pakete eines bereits laufenden Transfers. Erst wenn er bis zum Ablauf der Frist nichts Passendes hörte, löste er mit FULREQ eine vollständige Aussendung aus. Ein später eintreffender Rechner durfte so in die vorhandene Sendung einsteigen.

Der Server verschickte nummerierte Blöcke per UDP. Jeder Rechner prüfte die Pakete und setzte ihre Daten an der passenden Stelle in die eigene Datei. Einer verpasste vielleicht den Anfang, ein anderer einen Block in der Mitte. Nach einer Pause mit noch unvollständiger Datei schickte jeder seine Liste fehlender Nummern als PARREQ. Die im RFC gezeichnete Folge mit drei Clients zeigt den Mechanismus: eine gemeinsame Aussendung, mehrere unterschiedliche Reparaturlisten.

Auch der Rückweg war nicht frei von Reibung. Während ein Transfer derselben Datei lief, ignorierte der Server neue Anfragen dafür. Die Clients warteten und versuchten es erneut. Für die gemeinsame Sendung sahen die Autoren keine eigene Flusssteuerung pro Empfänger vor. Stattdessen empfahlen sie Abstände zwischen den Paketen, ungefähr doppelt so lang wie die Sendezeit eines Pakets an der Schnittstelle. In ihrer Versuchsumgebung bewährten sich Zeitüberschreitungen vom Sechs- bis Achtfachen dieser Sendezeit. Die Ersparnis einer gemeinsamen Übertragung hing also davon ab, ob die Empfänger ihrem Takt folgen konnten.

Mit 512 Byte pro Block blieb das gesamte Paket unter der im RFC angeführten Mindest-MTU von 576 Byte für IP. Weil die Blocknummer 16 Bit belegte, passten höchstens 32 MB in eine logische Datei; bei 1024-Byte-Blöcken 64 MB. Größere Inhalte mussten zerlegt werden. Gewöhnlicher Broadcast traf zudem unbeteiligte Rechner. Die Autoren hielten IP-Multicast für sinnvoller, sobald seine Implementierungen weiter verbreitet wären.

Der RFC-Editor-Eintrag führt CFDP als Experimental. Das Dokument nennt Referenzprogramme, aber keine Verbreitungszahl oder belegte erfolgreiche Inbetriebnahme eines Rechners. Der präzise historische Punkt liegt woanders: Mit dem Ende einer Sendung ist der Empfang nicht automatisch für alle fertig. Die Buchhaltung wandert von der zentralen Kopie zu jeder einzelnen Lücke.

Quellen