@brainDotExe An den von dir genannten Details scheitert es nicht, wenn man identische Daten an Millionen verteilen will:
Zeitgleich Downloads starten? Unnötig! Man spielt in der heißen Update-Phase das Update immer wieder "im Kreis" aus. Die Empfänger klinken sich zu beliebigem Zeitpunkt ein, empfangen bis zum Ende des Files und danach den noch fehlenden Anfang bis sie alles haben.
Exakt gleiche Geschwindigkeit? Kein Problem. Du bietest dein "File" in paar verschiedenen Geschwindigkeiten an. Mit z.B. 5 Streams mit verschiedenen Geschwindigkeiten wird jeder Empfänger eine für seine Netzanbindung halbwegs angemessene Variante finden. Genau wie beim Video-Streaming, wo man auf einen low-quali-Stream wechselt, wenn das Netz lahm ist.
Kein TCP? Richtig, aber unnötig. Per UDP+Multicast wird die große Masse effektiv verteilt. Dabei entstehende, kleine Lücken durch verlorene Pakete werden nachträglich "manuell sonderbehandelt", also nicht automatisiert auf Netzwerkebene .
Die Datenverteilung via Multicast scheitert nicht an schlau gebauten Anwendungen sondern am Netz. Es gibt zwar viele Wolken, die intern Multicast verteilen, ein globales Routing findet aber nicht statt. Für die klassische Multicast-Semantik (mehrere Sender pro Gruppe) ist das Thema zwar lange tot, aber für das relevante, deutlich leichter zu händelnde
SSM gibts
Chancen, dass mehr Wolken miteinander reden und mehr Endnutzer erreichbar sind. Leider gibts auch wirtschaftliche Interessen dagegen. Wer will scho (als Provider), dass FranzFremdling "meine" Kunden in "meinem" Netz sehr effektiv mit seinem Content füttern kann ...
