Czerwiec 2004 - lms - lists.lms.org.pl

Re: htb - jeszcze
by detekt＠detekt.pl 15 Cze '04

15 Cze '04

Witam A.L.E.C, > A.L.E.C wrote: >> Tomasz Chilinski wrote: >>> Też popieram pierwsze rozwiązanie. >>> Jak realizujesz klasyfikację ruchu? >> >> wiem, że chciałbyś ipt_account, > o czym ja piszę? pytasz się o klasyfikację i ja ze zliczaniem wyskakuję, > sorry za nieporozumienie. Będzie to tc + esfq w standardowej wersji (jesli > dobrze pamiętam znany rc.htb tak robi) bez imq. a czy esfq jest w standardzie w jaju czy potrzeba latke na jajko ?? bo jezeli nie ma go w standardzie to proponuje sfq -- Pozdrawiam Detekt

1 0

Re: htb - jeszcze
by A.L.E.C 15 Cze '04

15 Cze '04

pbern(a)pbern.biz wrote: > Przy okazji czy moglbys dodac mozliwosc zdefiniowania parametrow dla > lacz asymetrycznych? napisz dokładnie jak to ma wyglądać a się zastanowię, bo htb znam raczej pobieżnie, a mam zlecenie na zintegrowanie tego z lmsem i myslę, że ktoś może z tego jeszcze skorzystać. -- Pozdrawiam Aleksander Machniak ( A.L.E.C ) http://alec.pl gg-2275252

1 0

Re: htb - jeszcze
by A.L.E.C 15 Cze '04

15 Cze '04

A.L.E.C wrote: > Tomasz Chilinski wrote: >> Też popieram pierwsze rozwiązanie. >> Jak realizujesz klasyfikację ruchu? > > wiem, że chciałbyś ipt_account, o czym ja piszę? pytasz się o klasyfikację i ja ze zliczaniem wyskakuję, sorry za nieporozumienie. Będzie to tc + esfq w standardowej wersji (jesli dobrze pamiętam znany rc.htb tak robi) bez imq. -- Pozdrawiam Aleksander Machniak ( A.L.E.C ) http://alec.pl gg-2275252

1 0

Re: htb - jeszcze
by pbern＠pbern.biz 15 Cze '04

15 Cze '04

On Tue, 15 Jun 2004, A.L.E.C wrote: > A ha, zapomiałem dodać, że ja jestem za pierwszym rozwiązaniem jednak. Czyli > wszystkie dane definiujemy w taryfie, a limity są obliczane średnio na każdy > komputer użytkownika. Myślę, że to będzie najbardziej wygodne i uniwersalne, > choć nie idealne. Ale może macie jakieś inne pomysły? Moim zdaniem jest to rozwiazanie bardzo rozsadne.. a w skrypcie zakladajacym ograniczenia w przypadku wiekszej liczby kompow (pow. 1) dzielimy przez ilosc kompow limit polaczen i te wartosci wstawiamy. Przy okazji czy moglbys dodac mozliwosc zdefiniowania parametrow dla lacz asymetrycznych? Pozdrawiam Pawel Bernadowski GG 3377, email kontakt(a)pbern.biz

1 0

Re: htb - jeszcze
by A.L.E.C 15 Cze '04

15 Cze '04

Tomasz Chilinski wrote: > Też popieram pierwsze rozwiązanie. > Jak realizujesz klasyfikację ruchu? wiem, że chciałbyś ipt_account, ale to dodatkowe wymaganie i dla małych sieci nie potrzebne, choć myslę, że dorobi się mozliwość wyboru rozwiązania, tak samo jak nie będę zmuszał do korzystania z ipp2p, które mam zamiar także zastosować. -- Pozdrawiam Aleksander Machniak ( A.L.E.C ) http://alec.pl gg-2275252

1 0

Re: htb - jeszcze
by Tomasz Chilinski 15 Cze '04

15 Cze '04

On Tue, 15 Jun 2004 16:23:11 +0200, A.L.E.C wrote > A ha, zapomiałem dodać, że ja jestem za pierwszym rozwiązaniem > jednak. Czyli wszystkie dane definiujemy w taryfie, a limity są > obliczane średnio na każdy komputer użytkownika. Myślę, że to będzie > najbardziej wygodne i uniwersalne, choć nie idealne. Ale może macie > jakieś inne pomysły? Też popieram pierwsze rozwiązanie. Jak realizujesz klasyfikację ruchu? > Pozdrawiam > Aleksander Machniak ( A.L.E.C ) Pozdrawiam Tomasz Chiliński

1 0

Re: htb - jeszcze
by detekt＠detekt.pl 15 Cze '04

15 Cze '04

Witam A.L.E.C, > Mam już gotowe rozwiązanie i chcę je zintegrować z lmsem, ale potrzebuję > waszej rady, aby było w miarę uniwersalne. Mianowicie potrzebuję w bazie > przechowywać dane upceil, downceil, uprate, downrate, limit, connlimit > (ograniczanie ilości połaczeń). I teraz jest problem gdy jeden użytkownik ma > kilka komputerów. Bo jeśli umieszczę te dane w tabeli tariffs, to nie będę > miał powiązania z komputerami, tzn. który ma jakie ograniczenia. Można > przyjąć, że w takim przypadku obliczamy średnią na komputer z sumy taryff > (jeśli ich jest więcej), ale to nie to. Drugim rozwiązaniem jest oderwanie > sprawy "traffic control" od taryf i utworzenie tabeli tcassignments na te > dane, ale to też nie to (niewygodne zarządzanie). Trzecim pomysłem na > rozwiązanie tego problemu jest zaimplementowanie grup komputerów (tak jak > grupy użytkowników). Wtedy zarządzanie byłoby wygodniejsze, ale w dalszym > ciągu oderwane od taryf. Co wy na to? a moze polaczyc rozwiazanie 1 i 2 tzn w standardzie pola dla poszczegolnych komputerow maja wartosc np.null a wszystko wyliczamy ze sredniej, natowmiast gdy chcemy zmienic cos dla konkretnego komputera zmianiamy w jego wlasciwosciach. Wiem jest to pewien nadmiar danych w bazie (w dwoch tabelach te same parametry zarowno w tariffs oraz nodes) ale jest chyba najbardziej uniwersalny gdyz nadal zarzadzamy ruchem za pomoca taryf ale z drugiej strony gdy ktos ma specyficzne wymagania moze ustawiac rowniez dla pojedynczych komputerow. No i kolejna sprawa to tak ze jest to bardziej zagmatwane pod wzgledem napisania tego. ps. wracam do pytania ktore zadalem pare dni temu czy jest mozliwe zeby ograniczenia na internet dzialaly rowniez na podsieci tzn. na eth1 jest x podsieci przez co jedna podsiec moze gadac z innymi a takie mozliwosc jest bardzo bolesna gdy sie ma pare radii(wiem ze mozna zrobic rejecta i podsieci nie beda gadac ale wsrod tych klas adresowych mam sporo publicznych i ich nie moge rejectowac) -- Pozdrawiam Michal Kusmirek

1 0

Re: htb - jeszcze
by A.L.E.C 15 Cze '04

15 Cze '04

A ha, zapomiałem dodać, że ja jestem za pierwszym rozwiązaniem jednak. Czyli wszystkie dane definiujemy w taryfie, a limity są obliczane średnio na każdy komputer użytkownika. Myślę, że to będzie najbardziej wygodne i uniwersalne, choć nie idealne. Ale może macie jakieś inne pomysły? -- Pozdrawiam Aleksander Machniak ( A.L.E.C ) http://alec.pl gg-2275252

1 0

htb - jeszcze
by A.L.E.C 15 Cze '04

15 Cze '04

Mam już gotowe rozwiązanie i chcę je zintegrować z lmsem, ale potrzebuję waszej rady, aby było w miarę uniwersalne. Mianowicie potrzebuję w bazie przechowywać dane upceil, downceil, uprate, downrate, limit, connlimit (ograniczanie ilości połaczeń). I teraz jest problem gdy jeden użytkownik ma kilka komputerów. Bo jeśli umieszczę te dane w tabeli tariffs, to nie będę miał powiązania z komputerami, tzn. który ma jakie ograniczenia. Można przyjąć, że w takim przypadku obliczamy średnią na komputer z sumy taryff (jeśli ich jest więcej), ale to nie to. Drugim rozwiązaniem jest oderwanie sprawy "traffic control" od taryf i utworzenie tabeli tcassignments na te dane, ale to też nie to (niewygodne zarządzanie). Trzecim pomysłem na rozwiązanie tego problemu jest zaimplementowanie grup komputerów (tak jak grupy użytkowników). Wtedy zarządzanie byłoby wygodniejsze, ale w dalszym ciągu oderwane od taryf. Co wy na to? -- Pozdrawiam Aleksander Machniak ( A.L.E.C ) http://alec.pl gg-2275252

1 0

Re: Faktury w PDFie
by Paweł Rohde 15 Cze '04

15 Cze '04

Dnia 2004-06-14 17:18, Użytkownik detekt(a)detekt.pl napisał: >>A z czego korzystałeś? >> >> > >pdfliba oraz probowalem podmieniac zawartosc tak jak w rtfie no i >niestety zawsze zamiast ogonkow byly szlaczki > > Ja się przymierzam do www.fpdf.org -> z tutoriala (7) wynika że można pisać w dowolnym języku. Jak rozpoznam to dam znać. -- pozdrawiam [ pawel(a)rohde.poznan.pl [ Paweł Rohde

1 0