Изпечатай

Цитат

Производителността със сигурност ще се увеличи и то не само от самия match (1! правило), ами и в последствие при събирането на данните и обработката им - (работим с файл в /proc/sys/...., който е в паметта - доколкото разбрах от описанието на ACCOUNT).

1.Това, че правилото е едно НЕ ОЗНАЧАВА, че ще се премине по бързо от колкото 2 други ( в общия случай)!
2.всички вериги се държат в РАМ-а така че ?
btw.

Примерен код

/sbin/modprobe rd /sbin/mkfs.ext2 /dev/ram0 /bin/mount /dev/ram0 /mnt/rd

Цитат

По отношение на тц-то: хрумна ми, че *може би* можеда се направи filter по MARK за parent-а за всеки отделен трафик, а в него листата да се мачват по ИП - само, че не знам дали ще сработи

това е идейно  донякаде макар,че ще увеличи правилата спрямо случая с hash-a ... струва си да тестваш

[VladSun]

Там е работата, че с текущата НИ accounting система, като цяло има адски много правила - идеята ми е глобално да се намалят тези правила (за FORWARD разрешенията на ИП-тата няма как да стане, но за MARK има). С други думи да се премахнат *последователното* обхождане на правилата във веригите за маркиранe, а както се видя може и да се премахне и *последователното* обхождане на филтрите на тц-то.
По принцип ВСЯКА система, която се занимава с филтриране (търсене) ТРЯБВА да използва hashing (или поне сортиране) алгоритми за по-добра производителност - не е ли така?
Това го има във всяка книжка за "алгоритми-структури-данни".

За ACCOUNT patch-a:

1. Истината е, че броят на правилата в момента през които минаваме средно е 1/2 от всичките правила за маркиране - съгласен? ;
2. Ако преминем към системата, която ти предлагам в пред. пост, то както ти каза по-рано няма как да правим traffic accounting - ето тук използването на ACCOUNT е просто наложително (другия вариант е статистиките на тц-то);
3. на 99% съм сигурен, че ACCOUNT-patach-a е направен с hashing-алгоритъм (то дори и по индекс на масив да го правят стига). Нещо от сорта на:
account_table[IP]+= lengthOf(packet);
Това ние не можем да го постигнем с iptables правила;
4. по отношение на ползването на RAM-a - ок, съгласен съм '>

Цитат

това е идейно  донякаде макар,че ще увеличи правилата спрямо случая с hash-a ... струва си да тестваш

Тъй като не те разбрах много добре, ще кажа какво аз съм имал предвид:
root - > parent_bg_in(mark) -> hashed filters(ip)
root - > parent_bg_out(mark) -> hashed filters(ip)
root - > parent_int_in(mark) -> hashed filters(ip)
.......
Ние и в момента имаме това разделение (и няма начин да го махнем), но hashing алгоритъма в листат за ип-тата ще си работи пак по същия начин.

ПС: За n-ти път ще ти благодаря, че участваш в дискусията '> '> '> А за прекомерния ми ентусиазъм - ще ми простиш

//Off
Има проблем - има ентусиазъм.
Аз като нямам проблем само си човъркам пресъхналия мозък с контра-тези ей така да открием истината в спора.
Трябва някой път да обсъдим решението на задачката.
'>

/офф
все си мисля, че обсъждането ще протече по-гладко на маса със салатка и ракийка (все пак зима е '> ) '> '> '>

[VladSun]

@Uvigii
Пак ти благодоря за коментарите '>
Вече има резултат - статийка