в общем на практике не совсем вяжется с тем что я имею, т.е. 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 и вывод статистики всех анализаторов зарегистрированных в нем.