On Wed, 19 Nov 2003 17:53:22 +0100, Administrator (warsztat) wrote
> Witaj Przemysław,
>
> W Twoim liście datowanym 18 listopada 2003 (22:59:13) można przeczytać:
>
> >> Dobrym rozwiazeniem bylo by tez dodanie w taryfac pola CIR...
> >>
> PRG> Hmm.... IMHO zbędne..
> PRG> jeżeli chcesz generować pliki do HTB możesz określić CIR jako:
> PRG> * stałą wartość
> PRG> * procent przepustowości
>
> PRG> Osobićie generuję rozwiazanie 2 częściowe: LMS generuje mi plik
> w formacie PRG> %ID %IP %UPRATE %DOWNRATE i na jego podstawie
> dopiero generuję plik dla PRG> htb.init (ot takie lenistwo) gdzie
> określam RATE (CIR) CEIL (EIR)
>
> Tzn ja generuje EIR (narazie) dla upload i downrate wiec juz nie mam
> pola na CIR, ale to nie bedzie chyba trudne do zrobienia wiec pomysle
> nad tym (bo uwazam ze jest to dobra mysl). Narazie jednak mam dwa
> kola :(
Ja myslalem sporo nad tymi taryfami i tym co moze byc potrzebne zeby system
taryf byl mozliwie bardzo elastyczny i zeby dal sie dopasowac do kazdej
sieci. Tak amatorskiej jak i komercyjnej.
W moim chorym umysle zrodzil sie taki oto szatanski plan:
0. Wywalic z tabeli tariffs pola downrate i uprate i dolozyc pole "credits"
ktore bedzie limitem ilosci danych jaki bedzie mogl uzytkownik przeslac w
ciagu miesiaca. (Teraz kozystam z uslug firmy ktora rozlicza klientow z
ilosci danych jakie przesylaja, mam miesiecznie 10GB, a potem kazdy megabajt
kosztuje mnie 2gr)
1. Dolozyc jeszcze jedna tabele ktora w mysql'u bedzie defiuniowana na
przyklad tak:
CREATE TABLE tariffs_timezones (
id int(11) NOT NULL auto_increment,
tariffid int(11) NOT NULL default '0',
timezone time NOT NULL default '00:00:00',
dl_cir int(11) default '0',
dl_mir int(11) default '0',
ul_cir int(11) default '0',
ul_mir int(11) default '0',
PRIMARY KEY (id),
UNIQUE KEY id (id),
KEY id_2 (id)
) TYPE=MyISAM;
2. Kazdy rekord w tabeli tarrifs bedzie sie tyczyl ogolnej definicji taryfy,
tylko ogolnej bez predkosci czy sterf czasowych.
3. Kazdy reokrd w nowej tabeli bedzie definicja tego jak ma dzialac dana
taryfa w okreslonej porze dnia lub nocy iu jaka predkosc ma miec user w danej
porze dnia.
4. Pola w nowej tabeli:
- id - identyfikator danej regoly (na dobra sprawe mozna yb to chyba pominac)
- tariffid - identyfoikator taryfy do ktorej nalezy regola
- timezone - czas od ktorego ma obowiazywac dana regola (na przykalad od
01:00) Do momentuy nie wlaczoenia kolejnej regoly beidze obowiazywala ta
- dl_cir - predkosc jaka chcemy uzytkownikowki zagwarantowac w tym czasie
- dl_mir - w przypadku niedociazonego lacza prezdkosc jaka uzytkownik bedzie
mogl osiagnac maxymalnie
- ul_mir - analogicznie
- ul_mir - analogicznie
Co myslicie o takim rozwiaznaiu??
Bo mnie sie wydaje ze moze to kompleksowo rozwiazac wszelkie mozliwosci
taryfowe.
Jezeli cos jest nie jasne to pytajcie :) BO pise ot po 5 godzinach zabwy w
noigagame i mi mozg sie jeszcze po tym nie przestawil na normalne myslenie :P
z powazaniem
Rafal Ramocki
