mes, а будет ли правильно сделать члены этой структуры константными и для изменения делать const_cast? просто я из геттера возвращаю константную ссылку, сет делаю только из одной части программы.
в общем спасибо, у меня сейчас несколько таких классов, пригодилось )

asmdzen, я, конечно, не mes (куда мне), но думаю, это - неправильно
const_cast - штука неприятная. следует её избегать, как чёрт ладана...
Никто не запрещает компилятору поместить переменную, задекларированную как const в память, помеченную "только для чтения"
(я понимаю, что тут попахивает тем самым животным в том самом безвоздушном пространстве, но тем не менее...). Таким образои, при const_cast'е может произойти сексВиолейшн.

ИМХО ( specially for boostcoder ) const_cast нужет только для поддержки старого кода, изменить который ты не можешь, а тебе кровь из носу желательны const'овые выражения

нет.. данные наружу отдавайте как конст, а внутри пусть они остаются не константными..

Добавлено через 4 минуты и 21 секунду

не только для этого, но действительно он нужен только в _экстремальных_ ситуациях и не стоит его впихивать куда не попади... 

Добавлено через 6 минут

внутри - это внутри логического компонента (объекта или группы объектов)

я извиняюсь, никого не хотел обидеть, просто mes это посоветовал - я у него и спросил, конечно спасибо за ответ.
у меня сейчас получается из одной крайности в другую, раньше я никаких констов не использовал, все переменные делал глобальными и весь код мог их свободно изменить, проблема была в том что 1. это "добро" работало только для одного потока, 2. невозможно было отследить кто именно изменил определенную переменную.

идеальным было бы если разные члены структуры могли изменять только метод(ы) какого то класса (наследованного от чего-то или как-то еще помеченного)



за оффтоп извиняюсь, если решения по этому поводу нет - вопрос снимаю.

Это сообщение отредактировал(а) asmdzen - 23.7.2011, 19:59

asmdzen, лучше объясни задачу. а то приходится догадываться чего ты хочешь..

boostcoder, рассинхронизация вышла ))
вопрос вдогонку: есть куча маленьких объектов(функций), все они видят какую-то структуру (похожую на ту что я показал), я сделал для них класс родителя в котором и пристроил эту структуру и эти объекты тоже, они обращаются к членам структуры через указатель на родителя который передается с конструктором. проблема заключается в том что извне я не могу обратится к этим объектам (есть методы типа enable/disable) - следует ли сделать структуру где нибудь еще (в одном из этих объектов) и передавать указатель на нее всем другим (будет прямой доступ к объектам) или следует сделать методы типа get для всех объектов которые возвращали бы константную ссылку?

функции - не объекты!
или же речь о std::function<> или boost::function<> ? или о функциональных объектах?


значит все же функциональные объекты ;)


покажи кодом. а то долго синхронизироваться будем.

Это сообщение отредактировал(а) boostcoder - 23.7.2011, 20:21

tcp и udp такие же как ip, только изменяют они sport и dport.

нужен доступ к объектам ip, udp, tcp. хотелось чтоб saddr и daddr мог изменить только объект ip.

Это сообщение отредактировал(а) asmdzen - 23.7.2011, 20:48

первое, по моему очень разумное предложение - переписать это чудо с использованием boost.signals. получится строчек 7 ;) или boost нельзя использовать?
во вторых - у тебя тут segfault!

метод Register сохраняет адреса в вектор. ну вот зарегал ты эти объекты и покинул конструктор. загадка: адреса каких объектов будут лежать в векторе? ;)


мое предложение - переписать все накер.

Добавлено через 2 минуты и 5 секунд

если критична производительность - я бы вместо std::vector и итераций в run-time, использовал boost::fusion::vector и "итерации" в compile-time ;) это как еще один вариант.

 
без комментариев  

ошибочка вышла ) я их через new создаю просто в примере забыл это.

я уже убедился что boost это сила, вот только руки не доходят с ним по ближе познакомится, вот и занимаюсь рукоблудием ))

boost::signal отличная вешь, почитаю.
вот только я думаю или ознакомится с главными частями boost сразу или писать код по старому а то я этот проект никогда не закончу )


Это сообщение отредактировал(а) asmdzen - 23.7.2011, 21:23

простите, не понял иронии...

Добавлено @ 21:31
asmdzen, мне архитектура видится такой:

http://liveworkspace.org/code/08b24c8a76d6...15d901b687f38b4

Это сообщение отредактировал(а) boostcoder - 23.7.2011, 21:41

если быстро : динамический полиморфизм и fusion не совместимы и производительность тут не причем 

в том то и дело. зачем динамический полиморфизм, если есть возможность обойтись без него?
итерация по std::vector в любом случае происходит в рантайме. а еще и в придачу динамический полиморфизм. а вызов виртуальной функции дороже чем обыкновенной.
если использовать fusion::vector - то можно использовать статический полиморфизм + никакой итерации в рантайме + никаких виртуальных функций.

или я чего-то не понимаю?...

boostcoder, опять моя ошибка, не правильно показал пример.
в общем программа работает с сетевым потоком, получает буфер данных (последовательность IP пакетов или еще каких), выжимает из него всю полезную информацию. у каждого объекта анализатора должен быть свой список зарегистрированных анализаторов, например какой-то ip туннелинг типа gre,
регистрирую gre в ip и ip в gre, ip передает свои данные уже без заголовка gre, тот убирает свой заголовок и передает опять ip.

вопрос был в том, следует ли держать все эти объекты в каком-то другом объекте родителе и получать ссылку на них при необходимости или так-же будет нормально  и без родителя (с точки зрения правильного проектирования)
например мне нужно создать объект обработчик данных (CParrent) но который обрабатывал бы только tcp, для этого мне нужно написать еще какой-то механизм передачи флагов в конструктор, типа такие объекты создаются, такие нет, или создаю дефолтный объект потом делаю disable не нужным объектам (жор памяти но зато get не выдаст ошибку при запросе ненужного объекта)

Это сообщение отредактировал(а) asmdzen - 23.7.2011, 21:53

asmdzen, ты путаешь тем, что объясняешь задачу так, каким ты ее решение видишь. просто объясни цель/ТЗ.

+ невозможность построения динамичной цепочки, а нам неизвестно можно ли от этого отказаться  это раз
в теме для новичков призывать использовать сложные для понимания конструкции, когда они еще с простыми не разобрались - это два 

ну... я представил что протоколов не бесконечно много. это раз.


я же поинтересовался у вопрошающего: "или boost нельзя использовать?" это два.
я просто высказал мнение о том как бы это сделал я: "если критична производительность - я бы" это три.
я абсолютно забыл что это раздел новичков  и это четыре.

все. ушел на "свое место" 

Добавлено @ 22:07
и тем не менее, на вопрос я ответил кодом уровня вопрошающего.  

Это сообщение отредактировал(а) boostcoder - 23.7.2011, 22:07

цель написать real-time анализатор net трафика, с возможностью включения/отключения анализа определенных протоколов. По всем протоколам показывается статистика типа скорость передачи данных, количество переданных данных, количество неправильных checksum'ов.
Поток нужно обработать до уровня приложения (HTTP, FTP, TORRENT, POP3).
в интерфейсе должна быть возможность начать анализ из нескольких источников с разными параметрами (разные протоколы влючены/отключены) и возможностью изменения этих параметров во время работы.

порядок и  общее кол-во протоколов заранее определено ?

да


Это сообщение отредактировал(а) asmdzen - 23.7.2011, 22:38

зачем тогда вообще регистрация ? 
чем не устраивает самый простой вариант ? :

самый простой вариант у меня уже есть на С, хочу написать код так чтоб можно было потом легко добавлять новые протоколы.
еще tcp.Analyze() вызываться должен из ip объекта, откуда этот объект будет знать про tcp объект, не буду же я прописывать его в классе ip, вот и наследовал их всех от базового класса. к тому же цепочка обработки протоколов заранее не известна, т.е. можно дойти от ip до http несколькими разными путями, которые определяются уже во время обработки путем проверки какому протоколу принадлежит этот пакет (по очереди).

можно в псевдографическом виде диаграмму цепочки ? кто за кем и как обрабатывает пакет.. 

ip - tcp                   -
    - udp - l2tp - ip  - HTTP || FTP || POP3
    - gre - ip            - 

не знаю как это наглядней показать. суть в том что некоторые пакеты содержат в себе инкапсулированные ip пакеты и нужно вернуть управление ip обработчику.

диаграмма на граф похожа.

Тогда лучше сделать членов этой структуры mutable, это будет работать (и соответствовать стандарту). Но вот тому, кто будет смотреть такой код, придется долго и аргументированно объяснять, зачем это было сделано   



Это можно сделать через интерфейсы, состоящие из гетеров и сетеров. Каждый интерфейс будет описывать набор данных для конкретного класса-клиента. Основной класс должен реализовать все эти интерфейсы (можно приватно)
Недостатки - много писанины (хотя можно все прикрыть шаблонами и макросами), и run-time накладные расходы на динамический полиморфизм

ip  на схеме это один и тот же объект или в каждой точке свой объект ?

в задаче есть интересный момент, если передавать управление из одного анализатора в другой напрямую, то во первых будет никому ненужное заполнение стека, во вторых будет затруднительно добавление действия между анализаторами..

Добавлено через 1 минуту и 50 секунд

к тому же не приносящей пользы для данной задачи 

один и тот-же, просто не знал как это показать.


т.е. когда объект ip вызывает метод tcp напрямую? или я не догоняю?
когда было все на С написано, я из анализатора ip знал конкретно кого вызывать следующим по номеру протокола в ip хидере, сейчас же я передаю управление каждому последующему анализатору по очереди, они сами смотрят ip хидер и решают их это пакет или нет.



заполнение чем?


это возврат к тому с чего начинал плюс наследственность ))
лучше уж самому следить за изменением членов структур чем такой расход ресурсов, была бы проверка в compile-time, это бы все меняло.

не напрямую это условно  так : http://liveworkspace.org/code/4c9f662f58dc...5c334d65f5cb8a6

Добавлено @ 15:21
тогда после каждого анализа можно выполнять свои действия.. например вывод статистики..

Добавлено через 7 минут и 35 секунд
с маршрутизацией вроде понятно, теперь возникает вопрос, что есть анализатор, т.е. что он должен уметь, кроме как модифицировать пакет ?

Добавлено через 9 минут и 10 секунд
иначе он больше, чем на функцию не тянет.. 


Это сообщение отредактировал(а) mes - 24.7.2011, 15:26

mes, если бы было все так просто, т.е. каждый анализатор возвращает как-бы указатель на следующий. но так не получится из-за особенности некоторых протоколов туннелирования, при анализе одного пакета они могут выдать на выход несколько новых пакетов другого протокола.
т.е. нельзя вызвать анализатор ip, по окончании анализа взять его результаты (указатель на буфер и длину буфера) и передать другому анализатору, каждый анализатор должен сам вызывать следующего столько раз сколько ему понадобится.
наверное было бы проще если бы я сразу сказал что цепочка выполнения анализа протоколов похоже на древо, т.е. возможен такой анализ одного пакета (есть обработчики ip, tcp, udp, l2tp и http)
ip -> udp -> l2tp -> ip -> tcp - http
т.е. анализ доходит до l2tp, тот перемещает указатель за своим заголовком и передает управление опять ip анализатору, все начинается как-бы сначала, только на этот раз ip получает другой пакет который раньше находился в его области данных.
еще есть протоколы с сжатием, анализ доходит до них, они распаковывают содержимое в буфер и передают управление дальше, в таких случаях требуется чтобы после анализа буфера управление вернулось обратно к анализатору создавшему этот буфер, он его освободит.

Добавлено через 5 минут и 56 секунд

пакет он ни в коем случае не должен модифицировать, он может извлечь из него другой пакет (при декомпрессии) но выдает только указатель на начало пакета другого протокола.

так у меня они и были функциями, просто во всех есть общая часть, все должны рассчитывать скорость прохода данных по ним, количество проанализированных данных, количество ошибок checksum, возможность включения/отключения проверки checksum. есть еще разная информация и опции но они уже относятся к определенному протоколу, типа включение/выключение возможности дефрагментации ip пакетов, вкл./выкл. возможности сохранения http заголовков в файл.

согласно требованию и диаграмме, логично представить что каждый обработчик должен иметь список других обработчиков которые он может вызвать при встрече другого типа пакета. так же, стОит обратить внимание на тот факт, что если все обработчики могут вызвать все остальные обработчики - почему просто во всех обработчиках не регистрировать все остальные обработчики? ведь если какой-то из обработчиков не может(ему просто не нужно) вызвать какой-то другой конкретный обработчик, то факт того что он имеет о нем информацию - ничем и никак не мешает. отсюда вывод - регистратор должен быть один! а для того чтоб обработчик мог вызвать какой-то нужный ему - он обращается к регистратору и вызывает.

и никакого дерева или графа тут не нужно.

вот 

Добавлено через 2 минуты и 4 секунды
т.е. регистратор - банальный map где ключи - типы пакетов, а значения - сами обработчики.

Добавлено через 11 минут и 26 секунд
т.е. код что я привел тут: http://liveworkspace.org/code/08b24c8a76d6...15d901b687f38b4
соответствует требованию. только вектор нужно заменить на мап.

boostcoder, т.е. разделить обработку пакета на уровни, типа tcp/ip model или OSI model, только наверное понадобится multimap или map но значение не один обработчик а например вектор обработчиков, чтоб можно было сохранить индекс того обработчика который успешно проанализировал текущий тип пакета. еще наверное стоит сделать этот map статическим членом базового класса CAnalyzator от которого все обработчики наследуются и при создании какого-то объекта он автоматически помещался бы в этот map, но это наверное не будет thread safe, т.е. нельзя будет запустить обработку двух разных буферов в разных потоках? В общем спасибо, отличная мысль )

map ссылающийся на другой map.


по моему, это лишнее...


посмотри мой код еще раз.


в с/с++ ничего по умолчанию не thread-safe.


можно. но придется либо расставлять блокировки, либо...

еще, каждый обработчик имеет два идентификатора, первый тип пакетов которые он обрабатывает (link, internet, transport, application  layer), второй тип пакетов которые он выдает на выходе, по первому будет определятся куда именно вставить этот обработчик в map'е, второй будет определять к обработчикам какого типа этот анализатор может обратится. В общем это серьезно упростило задачу, теперь нельзя будет зарегистрировать одному анализатору все другие анализаторы а только те что соответствуют его выходным данным. Это мысли вслух ) думаю вопрос можно закрыть, а то я неуютно себя чувствую не в своем топике )

уже ответил: мап в мапе.


об этом нужно было думать с самого начала  

посмотрел Ваш код еще раз, да с analyzers_registry будет возможность запустить несколько обработок сразу





это нужно при обработке пакетов на уровне сессий, протокол можно определить только в начале сессий (порты не всегда можно определить, например в тунеллинге), после этого обработчик сессий сохраняет у себя идентификатор текущей сессии (saddr, daddr, sport, dport) и индекс анализатора которому следует передавать пакеты в будущем идущие в этой сессии.

еще из analyzers_registry следует вынести AnalyzeNext() в базовый класс анализатора, тот передает управление обработчикам по очереди пока кто нибудь из них не вернет положительный ответ что пакет он успешно обработал.

Добавлено через 2 минуты и 33 секунды

думаю можно модератора попросить вынести все обсуждение моего обработчика потока в отдельную тему   
щас попробуем.

Нет, не тоже самое. Я предлагаю выделить наборы гетеров/сетеров для каждого конкретного анализатора в отдельные интерфейсы. И только сам базовый класс будет определять, кому и какой интерфейс отдать. Т.е. анализаторы не смогут получить доступ к чужим полям.

Другое дело, что в вашем случае нужно нечто иное, чем набор разных полей. Вам скорее нужна сущность 'пакет с данными' и набор анализаторов (как предлагал boostcoder). Анализаторы принимают на вход пакет, выделяют из него свои заголовки и хвосты, а то, что осталось представляют как новый пакет и отправляют для анализа следующим в цепочке анализаторам

у меня так и было, только это была статическая структура, что не позволяло обрабатывать поток в разных тредах. Еще одним нюансом было то что в этой структуре присутствовали поля pdata и len, что оказалось большой ошибкой - очень сложно проследить кто и как эти поля изменил, я их извлек наружу и передавал/передаю как параметры функции, что бы не случилось эти параметры остаются.


наверное этот пакет тоже следует сделать статическим членом базового класса, чтоб не передавать указатель на него каждый раз при обработке, т.е. анализаторы заранее знают как к нему обратится, или передавать указатель на него в конструкторе анализаторов (как я сейчас делаю с CParrent*).


я об этом и спрашивал, но не то чтоб не имели доступ, а чтоб не могли изменить чужие поля, например udp может прочесть daddr но не может его изменить. Но думаю открытая структура не повредит, ведь геттеры/сеттеры нужны для инкапсуляции, а у меня не предвещается изменения типа ip адреса или порта.

заигрался ты со статическими членами/переменными. на самом деле они очень редко необходимы.

asmdzen, по существу вопросы есть? что мешает тебе реализовать хотя бы так, как я предложил?

Добавлено через 26 секунд
и что с отдельной темой?  

Как раз нет. Класс, описывающий пакет, должен состоять из указателя на начало и длинны. Само тело пакета (точнее пакета верхнего уровня), действительно лежит внутри корневого класса, а вот экземпляры классов пакетов генерятся при каждом вызове следующего в цепочке анализатора. Ссылаются все сгенерированные пакеты внутрь одного и того же корневого буфера (с оригинальным пакетом канального уровня)

Добавлено через 2 минуты и 19 секунд
2 asmdzen - сделай новую тему по стеку разбора пакета, и лучше не в новичках. Тема явно не для начинающих   

угу. я свою реализацию с бустами и фьюженами выложу. интересная задача. а главное - пригодится!  

делаю, вопрос - будет ли правильно например при анализе ip пакета, после передачи его на обработку анализаторам следующего уровня сохранить индекс того анализатора который успешно обработал пакет, в паре с номером протокола из ip хидера? чтоб потом при нахождении пакета с таким же номером протокола ip обработчик уже знал точно кому передавать пакет. Или это преждевременная оптимизация? )


написал модератору, а xvr не заметил ))

xvr, возможно ли перенести все посты связанные с обработчиком потока в отдельный топик?

зависит от задачи. если надо - сохраняй.


угу. когда все будет работать - тогда и оптимизируй.

Сможете туда перенести старые посты? или сделать тему когда новые вопросы будут?

в общем на практике не совсем вяжется с тем что я имею, т.е. map я прикрепил, геттеры/сеттеры убрал, но передача управления только анализаторам определенного типа не устраивает тем что у меня есть класс для вывода данных на сетевой адаптер, регистрировал за любым другим обработчиком выше ip или ip и он выводил ip пакет на адаптер, с уровнями не знаю как это сделать (


не могу понять - зачем? сейчас я передаю указатель на буфер и его длину как параметры функции
все остальные члены(s/daddr, s/dport, seq, указатели на хидеры IP, TCP, UDP) оставил в родителе в котором хранится и map со всеми анализаторами. Получилось не так много изменений как я думал )

bsa спасибо за новый топик )

не могу уловить суть. где-то по моему точка пропущена. или даже две 

"у меня есть класс для вывода данных на сетевой адаптер, регистрировал за любым обработчиком  >= ip , он выводил ip пакет на адаптер, с уровнями в map'е не знаю как это сделать ("

разобрался, сделаю новый уровень специально для вывода данных, если будет разрешен вывод данных для данного анализатора, он передаст свои данные всем объектам вывода по очереди (вывод в файл, в сеть).

У вас отсутствует одна необходимая сущность - селектор. Он должен быть прикреплен к каждому конкретному анализатору и выбирать следующий анализатор по содержимому тела пакета, выделенному в результате работы текущего анализатора.

Т.е. у вас вырисовывается такая схема:

Анализаторы тут - потомки базового класса Анализатор. Селектор - один конкретный класс (содержит map для хранения следующих анализаторов и нечто для выбора этих самых анализаторов по содержимому пакета. Что именно это нечто должно быть надо подумать)

я так понимаю это паттерн проектирования? только недавно начал с ними знакомится
это будет самое оно, потому что сейчас явно виден перерасход ресурсов. вот только не во всех анализаторах можно определить кто должен обработать пакет после него. Может написать(выдернуть из кода) маленькие функции которые делали бы проверку на годность пакета для обработки текущим анализатором?
например из ip пакета сразу можно понять кто должен обработать пакет, типа анализаторы при регистрации записываются в map как значение а ключ это номер протокола из ip, но для общего случая там должен быть не номер а что то типа функтора что-ли, но тогда и мап не обязателен, всеравно по очереди проходить придется.
еще есть не очень понятный для меня момент - пакет обрабатывается до момента где известен его seq, т.е. смещение его данных по отношению к старту сессии, тогда я передаю анализатору который обрабатывает сессии CSessionAnalyzer, сейчас он занимается именно тем что сохраняет идентификатор сессии (уже писал) и индекс анализатора который обрабатывает эту сессию. Неясность заключается в том что при старте сессии может не хватить данных в одном только пакете, т.е. заголовок идет в нескольких пакетах, кто именно должен сохранить этот пакет и последующие тоже, это должен сделать анализатор сессий или анализатор протокола? в общем вопрос пока очень мутный.

такой вопрос - есть базовый класс CAnalyzer, в нем в private части есть указатель на хидер того протокола который наследник обрабатывает, есть контейнер с указателями на CAnalyzer, можно канибудь сделать тип указателя параметром шаблона но при этом чтоб можно было записывать указатели так же свободно в контейнер?
например:
но чтоб можно было писать

т.е. если базовый класс шаблон, можно наследников запихнуть в один контейнер?

можно, если есть общая база ии посредством адаптера.. но Вы явно уходите в сторону..

Добавлено через 1 минуту и 31 секунду
из предыдущих постов стало ясно кто такие анализаторы, но не понятно как представлен пакет, точнее как представлена та информация, на основе которой идет выбор..

Добавлено через 5 минут и 35 секунд
если выбор следующего анализатора зависит 
1. от предыдущих пакетов, значит каждый анализатор должен иметь доступ к контексту сессии
2. от того пути по которому прошел, то должен быть отдельный контроллер, осуществляющий диспатчеризацию.. 
в любом случае логику не очень хорошо разбрасывать по разным наследникам..

Добавлено через 11 минут и 47 секунд
чтоб легче было представить давайте устно разберем один маршрут..
итак пришел пакет, отправили его на ip_анализ, результатом стал другой пакет, посмотрели кто он ? а tcp, значит отправили его на нужный анализ, а результативный пакет, опять на проверку, о это ip-пакет, его снова в ip-анализатор .. 
Примерно так ? а то я с этим пока еще не сталкивался и не представляю где и что есть, а на чтение документации сейчас времени  и настроя нет .. 

да. уровень вложенности зависит от типа пакета/протокола. потому я и предложил рекурсивный вызов обработчиков.

Это сообщение отредактировал(а) boostcoder - 26.7.2011, 00:51

есть и третий пункт, выбор осуществляется по содержимому хидера текущего протокола (встречал только у ip - поле protocol), или по содержимому пакета - первые байты это идентификатор какого-то протокола или приходится предположить что это заголовок именно какого-то протокола и проверить его на подлинность (поля хидера находятся в нужном диапазоне и поля типа length соответствуют той длине пакета что у нас есть) 

анализаторы расположены на уровни, они не могут обработать пакет другого уровня (например udp не сможет обработать ip пакет), эти уровни я вижу примерно так:
link_layer - протоколы типа Ethernet, MPE в DVB сетях
internet_layer - ip, icmp
transport_layer - tcp, udp, gre
tunnel_layer - глобакс, слонакс
application_layer - http, ftp, pop3, smtp, irc
т.е. все как в tcp/ip модели плюс уровень для туннелей.
известно что от tcp пакет идет сразу к анализаторам на application_layer'е
после gre идет к ip и оттуда уже обрабатывается по новой
послу udp идет к анализаторам на tunnel_layer'е те уже сами знают на какой уровень передать исходящий пакет(ы).
еще получается так что при анализе одного пакета из туннеля, на выход могут получится несколько новых пакетов.

в общем получается что зависит от всех трех пунктов в разных моментах, пример
в пакете ip записано что в нем вложен udp, в udp - если пакеты из этой сессии уже проходили то можно сохранить id того анализатора который с ними справляется и передавать ему все последующие пакеты. Если это первый пакет мы не знаем кто вложен, приходится передавать по очереди всем анализаторам,
эти анализаторы (которые обрабатывают пакет после udp) уже знают для какого уровня они выдают данные. Т.е. если это какой-то туннелинг, анализатор знает что он выдает ip пакеты и передает управление ip анализатору, если же анализатор выдает данные для уровня приложения (http, ftp, pop3) то обычно так-же не известно кому точно передавать управление и следует проверить все анализаторы уровня приложения.
получается что на разных этапах анализа можно сохранить путь по которому проходит пакет, но это должны сделать сами анализаторы.


Это сообщение отредактировал(а) asmdzen - 26.7.2011, 09:46

в общем разобрался )
оказалось я недооценил первый пример от boostcoder'а, просто нужно было его чуток доработать.
т.е. я добавил рекурсию, получилось довольно интересно
http://liveworkspace.org/code/3c825596ca23...0c826a39f54e6f7
(странный прикол если написать (&reg) ))

тольку у меня не vector а map и обращаюсь к следующему протоколу по идентификатору из enum'а, так же добавил возможность проанализировать пакет на каком-то уровне, т.е. я не знаю чей именно это протокол и передаю не nextAnalyzerID а nextLevelID, получается что-то типа "chain of responsability"
после анализа на одном уровне в родителе остается идентификатор следующего протокола который уже обработал пакет, чтоб в следующий раз можно было уже вызывать обработку конкретного протокола (например та же сессия, значит и протокол будет тот же)

в общем осталось придумать как все это показать в интерфейсе, т.е. создание такого объекта как analizers_registry и вывод статистики всех анализаторов зарегистрированных в нем.