Vlákno názorů k článku Trickle: rozdělte své připojení od PG - Mohl by někdo znalý vysvětlit, jak to funguje...
-
Kvakor (neregistrovaný)Nevim jak to dela Trickle , ale treba takovy wget to resi funkci sleep() a zbytek nechava na TCP/IP stacku. Kdyz ma napr. stahovat rychlosti 100KB/s, tak precte 100KB, koukne, kolik mu to zabralo casu, a pokud je to mene nez sekunda, zbyvajici cas prospi. TCP/IP se na to postupne adaptuje a po nejake dobe se rychlost ustali na pozadovane hodnote. Viz man(1) wget a option --limit-rate.
-
luky (neregistrovaný)to zni docela logicky, ale prece ta uroven tcp/ip funguje jinak... jakmile je jednou zaslany request, tak ty nizkourovnovy packety uz to zaridi ne? to proudeni, neumim si predstavit ze by se nejak pustil na clientovi sleep a server by neposilal data... ty data musi prichazet tak jako tak podle me teda... nvm no
-
luky (neregistrovaný)aha, ale pokud vytvorim klasickou socketovou aplikaci naprikald ktera posle http request, tak tam nikde neni prostor pro nejaky zasobnik... proste udelam connect, send, a onreceive zpracuju data a neni tam nikde prostor pro nejaky skrceni ci vybirani nevybirani dat ze zasobniku....
-
luky (neregistrovaný)nebo to je teda tak, ze nejaky buffer se tam nastavuje, ja mel za to ze to je maximalni velikost paketu, ale zrejme je to teda ten tcp stack, potom ta udalost onreceive teda asi nastava (?) kdyz se naplni ten zasobnik, a tam by slo dat tedy sleep, na jednu sekundu treba.... paklize ta udalost ale nenastava jen kdyz se naplni zasobnik, tak pak nevim jak to resit... ale ta prvni varianta by byla docela logicka.. nvm sock aplikaci sem neprogramoval uz asi 1,5 roku
-
Hlavní problém je, že se to děje na příliš vysoké úrovni. :|
Je sice pravda, že průměrnou přenosovou rychlost lze takhle omezit, ale fakticky se např. při stahování stane tohle:
- klient naváže spojení a pošle požadavek (to asi zpomalené nebude, protože je málo)
- server začne posílat data
- klient začne plnit TCP buffery; protože každý přijatý paket v tuto chvíli potvrzuje, velikost TCP okna se poměrně rychle zvětšuje; v tuto chvíli je stahující proces schopen zcela zahltit linku
- kvůli pomalému odebírání dat z kernelu (ano, tak to trickle dělá) přicházejí kernelu data ze sítě rychleji, než je aplikace odebírají, takže buffery se zaplní a kernel přestane potvrzovat příchozí pakety
- server si všimne, že druhá strana přestala posílat potvrzení, poslední pakety tedy pošle znovu a zmenší velikost TCP okna
- po nějaké době se velikost TCP okna ustálí víceméně na hodnotě, která odpovídá škrcení pomocí trickle
Nevýhody to má následující:
- jednotlivé pakety v rámci TCP okna se přenášejí nárazově, což pravděpodobně povede k "zadrhávání" síťového připojení (to se pozná zejména u interaktivních služeb)
- po celou dobu přenosu jsou na serveru i na klientu permanentně plné TCP buffery
- některé pakety se musejí (zbytečně) přenášet vícekrát
S první (podle mne hlavní) uvedenou nevýhodou se lze jakž takž vypořádat - nastavit parametry tak, aby se velikost okna ustálila na nějakém násobku velikosti MTU. Daní je pak opravdu malá přenosová rychlost, navíc nastavitelná s příliš velkou granularitou. S počátečním zadrhnutím se ale ani tak nedá udělat nic.
Celé je to trochu složitější, než jsem to napsal (algoritmy pro dynamickou úpravu velikosti TCP okna jsou docela sofistikované), ale jako první přiblížení to snad poslouží.
