Nyílt forrású µTP implementáció

Már csak az a kérdés, a többi kliens átveszi-e. Mert ha nem, akkor bukta.

--
Don't be an Ubuntard!

Eljen. A Vuze-nak a sajat DHT-jat is kicsit felpofozhatnak vagy ott hagyhatnak a busba.

Ez tök jó tényleg, de gondolom csak kliens szinten látja a hálózati forgalmat. Otthonra jó, de ahol sok gép van és kevés sávszél.. marad a torrent tiltása. De ha tud valaki valami jó megoldást az ne tartsa magában :)

A KTorrent 4.0 már támogatja.
http://ktorrent.org/?q=node/42

kivancsi vagyok igy a upc mennyi ido mulva tudja majd ezt is akkor korlatozni

Átfutottam a kommenteket, és eléggé csalódott vagyok, hogy a szokásos kliens-háborúba meg FLOSS-fejlesztők gyalázásába torkollott a dolog. Próbáljunk valami szakmait is hozzátenni.

Ezt a két linket futottam át: egy, kettő.

While we think there are substantial advantages for ISPs in the broad adoption of uTP

Az ISP-k számára az a fontos, hogy fizesd ki az átalánydíjat (tervezhető bevétel), és ezért egy (statisztikákkal megtámogatott) havi forgalmi korlát alatt maradj. A szigorúbbak (illetve a konkurenseik előtt kevésbé titkolózó ISP-k) ezt a korlátot nevesítik és betartatják, a többi ISP pedig csak visszacsatolja az árazásba. (Volt olyan ISP, amelyik a titkos limit alapján megpróbált ügyfelet kivágni, de nagy botrányt kapott a nyakába.)

Az átalánydíjnak az a lényege, hogy a teljes forgalom (teljes költség) túlnyomó részét nagyon kevés ügyfél viszi el. Ők bőven az átalánydíj felett fogyasztanak. Őket a sok egyszerű felhasználó átalánydíja finanszírozza. Az ISP-nek ez az aránytalanság mindegy, neki az a lényeg, hogy átlagosan keressen minden ügyfélen. Ezért felhasználóként akkor éri meg az átalánydíjat választani, ha a fogyasztásarányos díj magasabb lenne ugyanolyan felhasználói viselkedés mellett. (Vagyis az átalánydíj akkor éri meg, amikor valójában a többi user-rel fizettetjük meg a saját viselkedésünket.)

Bármilyen olyan megoldás, amely a mezei felhasználókat hozzásegíti a kapcsolatuk teljes kihasználásához, rossz az ISP-nek, mert a korábbi átalánydíj átlagosan már nem lesz elégséges fedezet. (Vö. minden háztartás innentől napi 24 órában nyitva tartja a vízcsapot.) A teljes gerinchálózati kapacitást szétosztva minden felhasználó között, konstans "csontig húzatom" hozzáállással, a mai sávszélességek százada lenne elérhető (a konkrét számra nem emlékszem, de nagyságrendileg valami ilyet olvastam). Mindenki nem lehet power user. Teljesen értelmes, hogy átalánydíj esetén a jobb kihasználhatóság érdekében bizonyos szempontból túlterhelik a hálózatot. (Ez a túlterhelés látszik a "garantált" és a "várható" sebességek közti szakadékban.)

Innentől jön a trükközés az ISP-oldali csomagütemezővel meg tűzfallal (egyébként ezt a protokollt valószínűleg triviális lenne szűrni). Az ISP egy idő után csak forgalmi díjas szolgáltatást fog nyújtani (vagyis minimális, adminisztrációs alapdíj + forgalomarányos díj). Az egy őszinte megoldás, és rögtön megoldja a korlátozást, mert mindenki annyit fog használni, amennyiért hajlandó fizetni. Akkor jön a bérelt vonal, ahol valóban garantált a garantált sebesség, meg akkor jön a közmű, amelynél mindenki annyi vizet, gázt, villanyt fizet, amennyit fogyaszt.

Mindenesetre az kijelenthető, hogy a jelenlegi lakossági modellben nagyon nem éri meg az ISP-knek az uTP.

The fact remains that when using TCP, a poorly tuned BitTorrent client may well result in an internet connection that habitually gets congested and then drops packets

Egy rosszul konfigurált (szétturkált forrású) UDP kliens ezerszer hatékonyabban vágja haza az ember interaktív TCP forgalmát. A TCP a kernelben van implementálva többnyire és kooperatív. Az UDP alapú cucc ütemezője user space-ben hangolható; elég néhány paraméterét megreszelni (nem beszélve a kódjáról), hogy jószándékúan minden más elé helyezze magát.

In practice, the uTP target delay is set to 100 ms. Each socket aims to never see more than 100 ms delay on the send link. If it does, it will throttle back.

Egyik link alatt sem találtam meg a "latency" szót. Ez gáz. A TCP-vel is az (az egyik) baj a nagy távolságú linkeken (annak ellenére, hogy azoknak nagyon nagy is lehet az áteresztőképességük), hogy a magas latencia miatt visszaskálázza magát (valójában ok nélkül). Ha jól értem a fenti idézetet, akkor pont ide fog vezetni, hogy a kicsit lassabban válaszoló (messzebb lévő) peer-ek késlekedését a transzport torlódásnak fogja érzékelni -- vissza fogja fojtani magát. (Tipikus WiFi jelenség is -- ahol a csomagvesztés mindennapos --: nincs válasz, csak sokára, ergo torlódunk, ergo lassítsunk. Holott torlódásról szó sincs, a szomszéd mikrosütője zavart be (kis túlzással), a helyes megoldás nyomulni és azonnal újraküldeni.)

The problem is that DSL and cable modems typically have a send buffer disproportional to their max send rate, which can hold several seconds worth of packets

Ez nem véletlen. Az ingadozó linkeken csak úgy lehet jó átlagot elérni, ha van miből átlagolni, vagyis ha az írást aszinkronná tesszük és a lehető legtöbb helyen buffer-elünk.

A valódi cél a prioritáskezelés (sávokra bontás). Ehhez az kell, hogy a teljes útvonalon legyenek "előzősávok". Az előzősávok jelenléte egyáltalán nem ütközik a hosszú sorokkal. Tök mindegy, hogy hány száz autó áll a Rákóczi úti dugóban, amikor a taxi a dedikált buszsávban ötvennel elsöpör mellettük.

Az ISP-k ill. a szélesebb körben értelmezett internet-üzemeltetés ilyet most nem nyújt, legalábbis nem egységesen. (Pontosabban: nem teszi a felhasználók kezébe.) A fejlesztés ezt a döntést próbálja kitépni az ISP-k kezéből; ekkor jön a poor man's QoS, vagyis "amíg nem küldök mást, csak VoIP csomagokat, addig nem tudnak tőlem mást ütemezni a VoIP csomagjaim elé". A 2+1 sávos Rákóczi út után most idézzük fel az (eddig) egysávos Andor utcát, a következőképpen: percenként csak egy-egy kocsit engedjünk ki rá, vagyis tartsuk lényegében üresen (The ideal buffer utilization for uTP (or any background traffic protocol) is to run at 0 bytes buffer utilization), de legalább a busz végig tud rajta veretni, amikor kell.

Az egész ott bukik meg, hogy a rövid queue-ban nem tud adat haladni, ha a termelő oldal pillanatnyilag mással van elfoglalva. Ez igenis átlagos átvitel-visszaeséshez vezet. Rövid queue-nál az átvitelhez két feltételnek kell egyidejűleg teljesülnie: a küldő tudjon mit küldeni, és ne legyen torlódás. Hosszú queue-nál a két feltétel időben szét van csatolva; az átvitelhez csak az kell, hogy ne legyen torlódás. A termelőnek nem kell tudnia most küldeni, elég, ha valamikor korábban képes volt -- azt ui. jól elraktuk a buffer-be (függetlenül attól, hogy akkor torlódott-e a drót vagy sem), és most elküldjük a buffer-ből, hiába homokórázik pillanatnyilag a termelő.

Ne menjünk messzebbre: egy 100 megabites LAN-on vegyük le a file szerver kimenő socket buffer-ét valami nevetséges értékre (néhány KB), és nézzük meg, mekkora sebességgel tudunk róla letölteni, és az mekkora CPU terhelést okoz a szerveren.

Szerintem ez egy nagyon okosan kitalált algoritmus, és az ócska DSL-ek / kábelmodemek végén lógó felhasználók imádni fogják. Az ISP-k utálni fogják, szűrni fogják, vagy be fogják árazni. Egy csomó (lakossági felhasználókra talán kevésbé jellemző) esetben pedig simán nem lesz értelme használni, mert csak rontana a helyzeten.