===
В марте, помнится, я написал в ipfw@
предложения по архитектурным улучшениям ipfw, как кандидат на
GSoC 2008. Никто не отреагировал (многабукаф, фигли). Дальше, в конце мая в RU.UNIX.BSD разгорелся спор - народ хотел изменения "как Cisco ACLs, но лучше", однако конкретики не было, хотя со временем что-то уже
вырисовалось, я поглядел на идеи для
(
Read more... )
1) текущая максимальная длина такого списка без таблицы - 30 (из длины опкода), то есть предлагаемые изменения касаются диапазона 11-30 адресов, и вопрос, скольким людям это реально надо. Хотя, конечно, чуть менее ленивый юзер может извратиться и сделать блок { src-ip 1.2.3.4,... or src-ip 5.6.7.8,... or ... }, но тогда:
2) необходимо добавлять оптимизатор в парсер, чтобы он это мог ловить (а пока что, исходя из нагрузок, юзер может расположить их нужным в перечислении, чтобы линейный поиск самых частых срабатывал сразу же, это эффективнее и таблиц) - но оптимизатор туда и так неплохо бы добавить. Правда, другим путем - ввести вместо правил отдельный язык, и плоский набор опкодов (не поделенный на правила), пускай сразу весь оптимизирует. Здесь эта идея, кстати, пригодится для счетчиков count/log, потому что рулесет с точки зрения локов на SMP следует держать в read-only.
3) также, из (1) и планируемых изменений адресации таблиц/portset и регистров, не хочется вводить лишнюю сущность, не адресуемую машиной (уже упоминал, что возможность машинного управления неплохо б сохранить).
В общем, мысль интересная, но замеры бы не помешали.
Reply
Leave a comment