zsync ale nepracuje tak, ze by pozadoval od serveru hash nejake casti souboru. Takto pracuje rsync, cimz vznika na strane serveru vypocetni zatez (coz je duvoud, proc je tak tezke najit verejne servery s podporou rsync). zsync potrebuje ridici soubor, kde je kazdy blok souboru (typicka veliost bloku je 4kB) otisknut v podobe kontrolniho souctu (zjednoduseno). Tato informace (nenazyval by jsem to hash) se spocita jen jednou a jiz se nemeni. zsync si stahne tento popis souboru a pokusi se v dostupnych lokalnich datech (stare CD, atd) najit shodne bloky (ktere mohou byt klidne na jinych pozicich). Pokud se mu to podari, pouzije je. Pokud ne, chybejici useky souboru stahne z http serveru, pouziva se hlavicka range, velikost stahovanych bloku nemuseji byt nutne nasobkem 4kB (pokud se v lokalnich datech najdou dva 4kB bloky oddelene 543 chybejicimi daty, stahuje se jen chybejicich 453B…)
Zajimave je, ze pokud mate velmi rychle pripojeni a vykonny http server, dokaze WGET ziskat velky soubor rychleji, nez ZSYNC. Zrejme to souvisi s rizenim toku dat a buferovanim, mozna take ze „range“ neni implementovana na strane serveru optimalne, protoze vetsina klientu nepouziva „range“ tak intenzivne, jako zsync. WGET casto dokaze stahnout vice dat rychleji, nez ZSYNC mene dat. Pokud se soubory hodne lisi, WGET stahne data rychleji.
Pokud se podovate na hlavicku genrovanou zsync, tak to muze byt hodne divoke, treba tady:
Host: cdimage.ubuntu.com
Referer: http://cdimage.ubuntu.com/daily-live/current/karmic-desktop-i386.iso.zsync
Range: bytes=12910592–12955647,12976128–13139967,13152256–13877247,13922304–14270463,14307328–14311423,14348288–14352383,14430208–14434303,14585856–20189183,20205568–22876159,23699456–24178687,24219648–24338431,24363008–24367103,24387584–28774399,28790784–28794879,28803072–28852223,28868608–28872703,28884992–29073407,29093888–29102079,29122560–29290495,29319168–29323263
