Souběžné posílání souboru multicastem

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Tuhle otázku si asi nějací lidí kladli,  tak bych se divil, kdyby neexistovalo řešení. Možná tak funguje bittorenent, nebo windows update cache v lokální síti.

Mám do switche (1Gbps x5) připojeno 1 zařízení, ze kterého chci z zařízení UNO rychlostí 1Gbps přemístit soubor do zbylých čtyřech zařízení, a každé bude příjmat souběžně čtyřykrát 1Gbps.    .. problém co :
(luxus jako 10Gbit switch  by sice šlo, ale je to řešení na sílu a to jsem neprozradil, že zdrojový seeder má taky 1Gbps)

Dá se tohle nějak zařídit.? Asi bude nevyhnutelný linkový/síťový multicast a speciální konfigurace stacku zdrojového zařízení a asi to bude diktovat volbu vhodného transportního démona+ protokolu (samba, rsync, ftp, torrent ,, webdav ,wtf) A aso

A ideálně, aby na cílových počítačích mohl být libovolný OS, ale pochopitelně s tím speciálním klientem.

přestavuju si to tak, že na cílových počítačích dám: něco jako  : superftp > connect 239.239.239.250 :21 ; get  file.zip
jakmile to dopišu na prvním druhém třetím , klienti začnou čekat. Až to napíšu na posledním čtvrtém, tak na serveru dám  příkaz start a ono to začne posílat

Jde to nějak? (nevidím problém v směru od serveru k klientům (hromadně), ale jak klienti budou handlovat (zvlášť) ack, pokud bych uvažoval TCP, je to vůbec možné, takovýhle TCP kočkopes) nebo se bude muset spolehnout na bezACKový protokol? čili jak řešit zpětnou komunikaci a obejde se to bez ní?

[Reklama]

[RDa]

Tak si neco takoveho napis, ze to bude distribuovat obsah v plovoucim okne a dokud vsichni prijemci nepotvrdi dokad ten obsah maji, tak se okno nebude posouvat a bude to delat retransmise.

Alternativne muzes pouzit namisto multicastu daisy-chain, ze kazdy klient vyjma posledniho bude jakoby proxy. To by slo zhackovat snad velice rychle skrze nejaky http proxy s lokalni cache... na 1..N-1 nastavis proxy, a na N-tem udelas wget

Rychlostne by to melo mit stejne parametry jako multicast, jen to bude mit vyssi spotrebu (protoze kazdy port ve switchi naplno vyuzije oba smery, vyjma prvniho a posledniho).

[František Ryšánek]

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 :-)

[Kitter]

Onehdy jsem potřeboval rozdistribuovat image disku pro 30 počítačů. Používal jsem linux, a v něm prográmek udp-sender a udp-receiver z repozitářů debianu. Už je to pár let, tak se to může jmenovat jinak, nebo úplně chybět.
https://linux.die.net/man/1/udp-receiver
1× Stdin a N× stdout, ty programy si to nějak vzájemně ACKujou a případně retransmisujou.
Používá to multicast protokolu UDP, takže pozor, hloupější switche to otrocky rozesílají na všechny porty a může se tím zahltit síť, hlavně když je tam nějaké 100mbps zařízení.

BT tak nefunguje, protože multicast a broadcast fungujou jenom v rámci síťového segmentu, takže ne napříč routerama. WU cache teoreticky jo, ale prakticky spíš ne, protože s UDP přes Wifi taky občas bývají problémy. Funguje takhle ale "vzájemné bezserverové DNS" (asi se to i nějak jmenuje ) ve Windows a tím tedy funguje překlad jmen počítačů na IP adresy i bez standardního DNS serveru. Taky na kolejích ČVUT prý jeden čas takhle přes multicast fungovalo sledování televize :-)

[alex6bbc]

ja bych to psal pomoci brokeru napr. zmq a nebo dds, ty maji multicast v sobe.

[Reklama]

[Michal Šmucr]

Na podobnou distribuci přes UDP multicasty existuje software.. UFTP
https://uftp-multicast.sourceforge.net/
Přenosy se iniciují ze strany odesilatele pomocí uftp. Na straně příjemce pak běží instance uftpd, co přijímají ty multicasty a ukládají soubory. Ty jdou buď do finálního umístění, nebo se dá nastavit dočasný adresář během přenosu a až když je to celé, tak se to přesouvá.
Řeší to spousty dalších věcí okolo, je tam nastavitelná velikost bloku (chunku), re-transmission, volitelné AES šifrování, součástí je i proxy (pro oddělené sítě to tuneluje multicasty).
Primární důvod, proč to vzniklo, byla distribuce dat ze zařízení s limitovaným uplinkem přes sítě s velkou latencí (např. satelit), kde se už výrazně projevuje bw latency product s normálními TCP pakety, takže to používá UDP a potvrzují se celé chunky. Ale jak už tu bylo zmíněno předtím, UDP má také svá úskalí a bez správného nastavení multicastů to může udělat pěkný flood.
Také je třeba rozumně zvolit rychlost posílání tak, aby to pobrala všechna zařízení, co to mají přijímat, a nebylo tam moc opakování. Což může pro větší přenosy na rychlejších sítích vyžadovat i trochu systémového ladění přijímacích bufferů (to je typické např. na některých BSDčkách nebo Windows) a případně počítat, že tam může být i nějaký ramping na začátku přenosů.

Osobně teď v reálných projektech nemám potřebu to používat, ale před pár lety jsme si spolu s kolegou blbli v nějaké WAN síti, šlapalo to, a za určitých okolností to může být výhodné.

[mkudlacek]

Podobnym zpusobem funguje Syncthing (https://syncthing.net). Sdilis adresar mezi X zarizenimi bez centralniho bodu. Kdyz se pripojis s novym zarizenim (nebo se starym obsahem sdilenyho adresare) tak zacnes dostavat data od vsech ostatnich zarizeni zaroven.

[Hornik]

Muzete rozvest ten use case?

Co se tim snazite resit?