A wszystko zaczęło się gdy na samym początku zabawy z siecią, na łączu o przepustowości 1Mbit, dostała mi się prawie setka, w większości świeżych i rządnych kaaza internautów, oraz routerek a na nim kompletnie obcy mi wtedy linux. Było tragicznie, lecz blokowanie P2P mnie nie zainteresowało, brak umiejętności admina nie może być pretekstem do serwowania ludziom, jakby nie patrzeć, niepełnosprawnego internetu. Zacząłem od cbq.init by szybko porzucić go i zacząć pisać samemu regułki za pomocą składni 'tc', lecz efekt podziału pasma na usługi był cokolwiek nie fortunny, stałe przydziały dla użytkowników tym bardziej. Admin po którym przejmowałem schedę w sieci, używał oprogramowanie dynamicznie dopasowującego przydzielane pasmo do aktualnego obciążenia, niestety dostępne pasmo się marnowało, użytkownicy otrzymywali przydziały po 2KB/s, ogólnie mimo polecania, nie przypadło mi to rozwiązanie do gustu. Tak więc po jakimś czasie opracowałem idee i napisałem własny skrypt do dynamicznego podziału pasma. Tak skrypt, najpierw w bashu, uruchamiany co minutę z crona;) Mimo to efekty były zachęcające. Niestety bash hamował rozwój a o tym zacząłem coraz częściej myśleć, więc przyszła pora by nauczyć się C/C++, całość została przepisana od zera, a powstały kod był już wielokrotnie przebudowywany aż do dzisiejszej postaci.

To chyba na tyle wstępu, mój aktualny kod na pewno nie jest zbyt poprawny, niektóre fragmenty są fatalne, ale programistą nie jestem a piszę, jedynie dla własnego użytku, nie dysponuje też odpowiednią ilością czasu, by dodając nowe funkcje tracić go na szukanie odpowiedniejszego z punktu widzenia estetyki kodu, rozwiązania. Idea działania powstała po pewnych obserwacjach, otóż przykładowe wejście na stronę to "wystrzał" danych ze strony serwera do klienta, do naprawdę wygodnego surfowania dobrze mieć dostęp do pasma o przepustowości kilkunastu KB/s, a nawet większego. Gdy większa liczba osób ogląda jedynie www czy ściąga pocztę, ruch się rozkłada, najczęściej każde wywołanie strony wpada w lukę pomiędzy wywołaniami innych użytkowników, gdy zaś pojawi się ktoś ściągający nachalnie duże ilości danych, robi to w sposób ciągły i zabiera pewną część pasma na wyłącznie własny użytek, dlatego taka osoba powinna być szybko wyłapana i po pewnym okresie czasu powoli "ścinana" w dół. I nie chodzi oto, by zablokować lecz zepchnąć do pewnego znośnego dla ogółu poziomu. I tu powstaje jeszcze drugi kruczek, dzielenie w matematycznie poprawny sposób tzn. by suma przydziałów była równa przepustowości naszego łącza internetowego skutkuje marnotrawieniem dostępnego pasma i często to wolne pasmo sięga 50% możliwości łącza którego koszt jest z reguły nie zależny od stopnia wykorzystania. Dlatego też wykorzystałem owo rozkładanie się ruchu, i sprawdza się to tym lepiej im większa liczba osób korzysta z internetu jednocześnie. NiceShaper może utrzymywać stopień wykorzystania łącza na poziomie dochodzącym do 90% przepustowości, a do tego użytkownicy mogą jednocześnie korzystać z gier online, pracować zdalnie czy używać P2P. W uproszczeniu sens w tym że przydzielamy wszystkim, jakby w dobrej wierze na wyrost, i odpowiednio szybko wyłapujemy tych którzy przesadzają. Jeśli ktoś nie wykorzystuje całego swojego pasma nie zostaje mu ono zmniejszone, lecz zostaną zwiększone przydziały reszty. Dzięki temu nikt nie jest zmuszany do surfowania z pasmem 2KB/s, co wygodne na pewno nie jest.

Od strony konfiguracji, najważniejsze wytyczne jakimi się kierowałem, to prostota i intuicyjność. Przecież nie każdy kierowca samochodu lubi dostrajać pracę silnika, a program powinien sam wybrać optymalny sposób działania, i udostępnić jedynie najważniejsze funkcje do skonfigurowania ( coś na kształt obecnej polityki gnome team'u, tylko bardziej adekwatnie do specyfiki zastosowania ;). Uniwersalność pozwalającą na prace na każdym standardowym serwerze udostępniającym internet dla sieci osiedlowej. Równie ważne jest dla mnie traktowanie transferów wychodzących jak i wchodzących na równi już z poziomu samego kodu. Bo cóż nam z dużej przepustowości downloadu jeśli upload ledwo zipi i nie jesteśmy w stanie wysłać w stronę internetu żadnych zapytań. A z reguły użytkownicy P2P nie czują się ile udostępniają. I na koniec oczywiście minimalne obciążenie systemu. Naprawdę nie miałem problemu z podziałem internetu w mojej sieci na Pentium 166Mhz z MMX. Choć już dawało się tu we znaki obciążenie generowane przez samo kolejkowanie CBQ.

A oto wykres MRTG pokazujący, efekt działania w małej sieci, gdzie maksymalnie w tej samej chwili z internetu korzysta do dwudziestu kilku użytkowników, lecz bardzo intensywnie wykorzystujących P2P wymagających udostępnienia pasma, co jest zabójcze dla łącz z małym pasmem wychodzącym jak InternetDSL z TPSA. Na zielono download, upload - niebieska linia, praktycznie zawsze w pełni obciążony, jednocześnie każdy użytkownik ma zagwarantowane wygodne surfowanie, czy granie online.