>Информация на какой хост пропускать обратный icmp-пакет берется из заголовка tcp пакета.
>А для FTP, чтобы узнать какой именно порт нужно открыть, откуда, куда
>и когда закрыть, файрволу приходится отслеживать обмен по 21 порту. А
>течении сессии может быть открыто и закрыто несколько соединений. Причем они
>могут быть закрыты не только по команде в символьном канале ,
>но и по таймауту, а может и вообще не быть корректного
>завершения (например клиентская машина ушла в голубой экран). И т.д. и
>т.п...
>
>И все это файрвол должен отследить и правильно обработать. То есть чтобы
>надежно защитить систему, файрвол вынужден подняться на уровень приложения и знать
>систему команд и логику обмена. Вот это я называю гиморрой...
другие называют функционал.
кто прав?
>А что разве есть? Тогда расскажи нам про универсальный инструмент, который и
>летает, и стирает, и удовлетворяет...
>Я знаю только один такой. Это моя жена...
%)
>Э-э... Я аж дар речи потерял. А от чего тогда меняется-то? И
>меняется ли скорость вообще по твоей теории?
меняеться
но не когда наличиствет N независимых модулей функционала, а эти модули вызывают друг друг
в силу разных причин.
Т.е. если простыми словами:
- вот так вот передавать управление:
switch(n) {
case 1: go_there1(); break;
case 2: go_there2(); break;
case 3: go_there3(); break;
case 4: go_there4(); break;
....
case N: go_thereN(); break;
....
}
да, время пердачи управления модулю N растет линейно относительно количества модулей.
Но связка из пары-тройки инструкций сравнения на каждый case это практически несравнимо
мизерные затраты проца относительно роста функционала.
Все равно что бумажку с номером лепить на танк - несравнимо малая нагрузка на мотор, по сравнению с броней.
Посему, я берусь утверждать, что добавить функционал в наше время не есть уменьшить как либо значимо производительность системы. А особо если применяя likely()/unlikely() заоптимизить даже этот поиск более часто используемыми модулями - вообще сказка получиться
