qos-free-zone asi nezafunguje ... viz changeset 22, řádek 952 a 961.
Doprčic, teď už to chápu, proč to tam bylo :-(
V současné době tedy sice síť v qos-free-zone není ani markovaná, ani klasifikovaná, ale díky "default" v root HTB padne do hlavní "internetové" třídy, nikoliv do "médium". Tedy to nefunguje.
Ahoj,
začal jsem používat promethea, rád bych ho použil i pro oshapování klientů, kteří mají zaplacený datový tarif. Tzn, klient si zaplatí např. 10 GB za měsíc a po dosažení toho limitu, by se mu nastavila ceil na rate, tak jako je to nyní u hard shapingu v prometheovi. Myslím, že přidat tuto featuru by nebylo tak obtížné. Jaký je váš názor?
No ale mě není jasné, co je na tom k doprogramování: prostě stačí pro měsíční místo denní datový limit spouštět Promethea jednou měsíčně, místo jednou denně :-) Samozřejmě: požadavek je zřejmě asi kombinovat denní a měsíční limity.. nebo o co přesně jde ?
Každopádně žádné měsíční limity se mi tam asi nechce programovat, zadarmo ani za peníze (samozřejmě, je to open source.. takže každý má právo si to tam dopsat... pokud změny commitne do společného SVN). Pointou HTB bylo, že fixní limity nejsou potřeba - že je lze počítat "on-fly" v reálném čase. A pointou Promethea je, že i když se ukázalo, že v reálném životě to tak docela nefunguje, tak přeci jen stačí tohle "zúčtování" provozovat jednou za 24-48h, a ne na celý měsíc (popravdě: kdokoliv, koho bychom oshapovali na celý měsíc, by od nás asi odešel)
Samozřejmě jistá představa, proč jsem do psaní téhle aplikace šel, je to, že by mohla sjednotit politiku, pomocí které internetové brány konkurují ADSL a mobilním operátorům - vytvořit jakýsi "cech" živnostníků v oboru internetového připojení dá se říct. A měsíční limity pokládám v podstatě za slepou uličku - takže fakt nevím, jaké peníze by to musely být, aby se mi to chtělo programovat...
(Nicméně napovím, čeho lze dosáhnout i bez zásahu do zdrojáků: Prometheus má tzv. Credit file, který u nás slouží k převodu nevyčerpaných dat z předchozího dne: pokud by člověk tento credit file automaticky generoval každý den před spuštěním Promethea podle nějakých vlastních pravidel, tak lze dosáhnout zajímavých efektů... i když nevím jestli přesně toho, o čem je řeč...)
Asi nejprůchodnější cesta je např. generovat si hosts soubor každý den nějakým skriptem z SQL databáze (takový skript se dá napsat v podstatě asi na řádky řádky v bashi nebo PHP), a řešit si toto omezování sosáků nějak ručně, skrze SQL databázi: protože ceil může mít úmyslně každá adresa nastavený úplně jinak, není potřeba vytvářet extra tarif (u Promethea keyword) jako třeba v LMS...
Pro generování měsíčních přehledů je BTW už dnes možné použít volání prometheus -m - pouze to zatím vygeneruje jen HTML stránku... takže ruční zásah obchodníka je pořád potřeba.
Osobně mě nikdy nebylo sympatické nějaké vytváření "zbraní hromadného ničení", které by obchodníkům umožnilo co nejefektivněji ždímat z lidí peníze: vždycky jsem měl za to, že by se kolem těchto algoritmů umožňující sofistikované "nepeněžní obchodování", "barterování", "nepeněžní úvěry", apod. měla rozvinout široká a v zásadě demokratická diskuze na téma "svoboda jednoho končí tam, kde začíná svoboda druhého". Mikroekonomická "Úvěrová politika internetové brány" není nepodobná makroekonomickým jevům, jako třeba "úvěrová politika centrální banky" - akorát se to vše děje poněkud v menším, regionálním měřítku...
No, ale když jsme u těch požadovaných features: ve skutečnosti, fakt už se chystám dodělat režim "-s", který by byla alternativou k "-p" a krome generování preview by rovnou selektivně oshapoval/oclassoval ty, kteří už svůj aktuální FUP pro dané období vyčerpali: takže potom by se měsíční limity aplikovaly tak, že by se plné znovunačtení promethea dělalo jen jednou měsíčně, a a několikrát denně by se spouštělo -s ... ovšem ouha: v tomto případě by -s muselo zároveň i přidávat třídy pro IP adresy nově přidané do konfiguráku, protože jinak by povolování připojení novým klientům bylo možné jen 1x měsíčně (u nás se jako omezující ukázalo i přidávání 1x denně - nakonec se to vyřešilo dočasným NATováním nově přidaných adres...)
Zdravim. Neviem ci mi vobec niekto bude vediet odpovedat na moju otazku, ale potrebujem vyriesit problem s "aktivnymi" stahovacmi, ktori maju zaplatene ucty na rapidshare a jednoducho mi zabiju AP. Hodilo by sa mi nieco ako connbytes, cize po suvislom datovom toku, ktory presiahne napr. 50MByte, sa obmedzi dynamicky rychlost tohto datoveho toku podla stanovenych podmienok. Je mozne nieco podobne implementovat do Promethea? Alebo mi vie niekto poradit ako by som dany problem vyriesil bez toho, aby mi to ovplyvnilo samotny beh promethea?
Vdaka.
pro začátek by max. rychlost přidělená jednotlivým uživatelům na AP měla být nižší, než fyzická kapacita média. u nás nikdo na wi-fi nemá víc jak 1.2 Mbps.
problém je tu s tím že ti to zabije to spojení už o vrstvu níž, podle mě. kdyby šlo jen o rozumné nasdílení čistě se chovajícího média, tak jednodenní limity stačí, a HTB pořeší realtime výkyvy.
klasická 2.4 Ghz AP ti zabije daleko spíš počet packetů za sekundu, když jsme u toho. viry vyvolávající floody napáchají více škody, než download velkých packetů. a floody ti to hlavně zabijou ještě než se to vůbec dostane k traffic shapingu, ty packety. 2.4 Ghz je prostě dead technologie, je vhodná tak max. pro připojení jednoho klienta současně.
no ale Prometheus bude mít feature na omezení IP s překročenými limity ještě během dne, což k tomuto účelu můžeš asi použít. pouze nevím, kdy to dodělám. sice nějaké nabídky že by podobnou funkci někdo zaplatil tu byly... ale nic konkrétního.
já mám práce až nad hlavu, a v naší síti to priorita není.
už mám vymyšlené jak na to - prometheus si někam zaloguje vztahy mezi IP adresami a čísly těch traffic class, a vždy, když bude potřeba něco shapovat, tak zruší a znovu vytvoří jen to jedno konkrétní pravidlo. takže to celé proběhne rychle - asi jako režim se switchem -p (preview)
ale skutečně: není žádná extra motivace to tam dodělat. kromě toho je to open source... můžeš se domluvit i s jiným programátorem...
No moment, o kterých prioritách se tu mluví? Já teda žiju v přesvědčení, že priorita u htb se pohybuje v mezích 0-7, celkem osm hodnot. Podle mě to žádné 99 ani 98 zpracovat neumí, zkusil bych, jestli to nebude tím.
11.10.2008 v 09:18
