Mně to taky připadá jako téma na hezké programování v C(++) a BSD sockets API.
Kladu si otázku: co řešíte za specifický problém?
Potřebujete distribuovat nějaké soubory, a těch dat je příliš mnoho, než aby to 1Gb linka na straně serveru zvládla přenést všem klientům, ale pokud se to bude multicastovat, tak se to vejde/stihne?
Klienti potřebují vždy všichni tentýž soubor ve stejném čase? Je v tom případě potřeba, aby si o něj sami říkali? Nemůže mít server informaci, který soubor budou klienti potřebovat, a prostě ho "odvysílá" o své vůli? Musí server čekat, až budou všichni klienti připraveni, a tedy čekat až všichni projeví zájem?
Našel jsem
jednu aplikaci, kde něco velmi podobného funguje. Cílový business model je "digital signage" = zobrazování reklamy na obrazovkách v síti, kde u každé obrazovky je malý lokální počítač s vlastní úložnou kapacitou. A říkají k tomu, že se jedná o "push delivery" souborů na klientské stroje (přehrávače).
Pokud by měl server dělat retransmise, pokud byť jediný klient signalizuje, že data nedostal, může se snadno smazat úspora, která z multicastingu plyne. Pokud se počet retransmisí neomezí, může to dopadnout volně v intencích toho co lze vidět na CANbusu při nějaké poruše fyzické vrstvy: jeden uzel stále dokola vysílá tutéž zprávu, ale všechny ostatní datové toky se zastaví :-) Princip toho jevu je podstatně odlišný, ale to deja-vu je silné :-)
Když mluvíte o multicastingu, plánujete "přihlašování k odběru" pomocí IGMP ? (Pokude ne, bavíme se efektivně o broadcastingu...)
Vypadá to na zábavné téma k analýze, ale chtělo by to trochu víc vstupních informací, aby stálo za to nad tím dumat :-)
Poslední příspěvky