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, возможно ли перенести все посты связанные с обработчиком потока в отдельный топик?

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


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

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