![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
nuclightВ честь 26 годовщины 26 апреля уволился с текущей работы и таки наконец начал проект http://wiki.freebsd.org/IpfwNg — хотя на работе FreeBSD и была основной системой, реальную возможность пилить ядро я так и не получил (хотя тот же NAT64 нам бы понадобился не через полгода, так через год). В ближайшие недели посижу дома и надеюсь сделать хотя бы скелет, который можно будет потом уже в свободное время потихоньку пилить — работы по проекту предстоит очень много.
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-05-25 06:17 am (UTC)возможно да. возможно нет. я пока не вижу принципиальных проблем реализации 5-тупле в виде абстракции с той же производительностью (ну почти той же). в конце концов 5-тупле -- это 3 поля фиксированной длинны по фиксированному смещению + 2 поля фиксированной длинны по чуть менее произвольному смещению. 5 операций косвенности условно говоря. скорее всего на общем фоне разницы не будет. с FSM не так очевидно. но почему бы FSM в виде талицы должна быть существнно медленнее FSM на switch?
ну и кроме того, FPGA ты не обгонишь, а скрость кодирования поддержки новых протоколов и расширения -- она не менее важна, а скорее и более. в конце концов более двух десяток в тазик нынче не актуально, а 24 ядра на это хватит (если десток не две, то их скорее всего надо уже двадцать четыре, а столько в тазик не запихаешь да и память и pci-e сдохнет).
а у кого что, у кого сколько?
10гбит на одном ядре невозможно и не нужно. отключение чего в iptables?
и да, statefull производительность будет просаживать. безусловно. независимо от реализации. это надо понимать и на это надо идти. просто надо либо отключать state либо в таких случая предлагать использовать обычный ipfw, почему нет? как stateless от вполне употребимый, поскольку работает в контексте прерывания драйвера -- по ядрам раскладывается сам. в конце концов от Cat6500 на 10G/40G никто умных acl не ждет -- они там простые, которые в FPGA реализованны.
в листе дерева можно хранить ссылку на строку, из которой этот лист образовался и показывать именно ее. gdb ведь не занимается декомпиляцией до си при пошаговой отладке.
да, делать надо так, что бы 80% обычных пользователей было понятно, сложности от них были спрятанны, задачи решались бы легко. смысла делать еще одну простую поделку я не вижу. потребности в еще одном обычном
стиральном порошкефайрволе, но в нетграфе -- нет. файрвол нужен хороший и в котором добавление поддержки еще одного протокола не выливается в месяц работы. если трудоемкость будет высокая, но профит очевидный -- трудовые ресурсы как-то найти будет можно. но это потом.no subject
Date: 2012-05-25 07:48 am (UTC)На эту тему был какой-то прогресс у imax: http://blog.imax.in.ua/2012/02/userfw-freebsd.html
no subject
Date: 2012-05-25 08:05 am (UTC)no subject
Date: 2012-05-25 08:09 am (UTC)no subject
Date: 2012-05-25 08:15 am (UTC)описание протоколов должно быть декларативное, общее, что бы можно было все свести воедино и построить оптимальное дерево разбора.
и это, состояний и потоков у него так же нет.
no subject
Date: 2012-05-31 11:07 pm (UTC)no subject
Date: 2012-06-01 04:37 am (UTC)тех, которые в понятии statefull.