Фон

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

Реальная идея заключается в создании лучшего решения, быстрого, параллельного и эффективного, которое будет использоваться в качестве агрегатора / хранилища данных.

Требования

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

интерактивные декодеры: логика декодирования может быть легко изменена во время выполнения. Такой подход может быть весьма полезным для разработчиков протоколов - скорость декодирования не так критична, но гибкость и быстрые результаты важнеевстраиваемые декодеры: может использоваться как библиотека. Предполагается, что этот тип обладает хорошей производительностью и достаточно гибок, чтобы использовать все доступные процессоры и ядра.декодеры как услуга: можно получить доступ через чистый API. Этот тип должен обеспечивать лучшую производительность и эффективность породы

Результаты

Мое текущее решение - основанные на JVM декодеры. Фактическая идея состоит в том, чтобы повторно использовать код, исключить портирование и т. Д., Но при этом иметь хорошую эффективность.

Интерактивные декодеры: реализовано в GroovyВстраиваемые декодеры: реализовано на JavaДекодеры как услуга: Tomcat + оптимизации + встраиваемые декодеры, обернутые в сервлет (двоичный вход, выход XML)

Проблемы, которые необходимо решить

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

Я делаю правильно, используя JVM везде? Видите ли вы какой-либо другой хороший и элегантный способ достижения первоначальной цели: получить легко пишущиеся и масштабируемые и эффективные декодеры протоколов?

Протокол, формат результатов и т. Д. Не фиксируются.