Конвеер по обработке данных (Нужно архитектурное решение)

[Zeus]

Суть задачи: пишу конвертер который "слушает" сетевой сокет, получает пакет данных, определённым образом перелопачивает его и отправляет дальше в сеть. Попутно протоколирует ошибки, возможно протоколирует пакеты (полученный и/или отправленный и/или промежуточные результаты преобразований).

Думаю сделать что-то вроде "конвеера":
объект, получающий пакет, "кладёт" его на "конвеер",
объект, протоколирующий пакет, пишет данные из него в БД,
объект, перекодирующий данные, обрабатывает пакет (возможно из одного изначального пакета получится несколько новых),
объект, протоколирующий обработанные данные, пишет их в БД,
объект отсылающий данные в сеть - посылает полученные пакеты.

В дальнейшем структура может усложниться тем, что конвеер будет в определённом месте ветвиться: какой-то объект будет отправлять одни пакеты в одну сторону, вторые - в другую.

Хотелось бы, чтобы это было что-то вроде движка, который бы по XML-файлу загружал объекты из shared libraries, строил бы из них конвеер и запускал main loop.

Вот как это лучше сделать архитектурно? Может паттерны какие-то подходят?
Как "гнать" данные по конвееру: просто двоичные массивы (грубо говоря, как они приходят из сети и как туда уйдут) или структурированными объектами?
В последнем случае, получается, объекты должны уметь работать не просто с std::list<unsigned char>, а с оригинальными структурами данных, что накладывает определённые ограничения... Появляются вопросы обеспечения полиморфного поведения, в то время как в первом случае вообще без разницы кого в какой последовательности "ставить" на "конвеер": двоичные данные обработает любой объект (другое дело правильно ли он их интерпретирует).

В общем, я в раздумьях...
Может уже есть похожий программный продукт, в код которого можно "заглянуть"?
Или вообще есть подобный движок?

Язык: с++

[sarutobi]

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

[Zeus]

ДА! Забыл написать: язык - с++

[/dev/random]

Если допустимо posix-зависимое решение, то я бы реализовал через fork() и pipe(). И пофиг, на каком языке. Форкуем программу на 5 обменивающихся через каналы: приёмник -> логгер -> обработчик -> логгер -> передатчик. Если приёмник и передатчик работают через один сокет, то их лучше объединить, и форковать программу не на 5 частей, а на 4. Правда, С++ тут везде кроме "обработчика" будет выступать просто в качестве "навороченного С", без ООП.

[Zeus]

Если допустимо posix-зависимое решение, то я бы реализовал через fork() и pipe(). И пофиг, на каком языке.

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

Правда, С++ тут везде кроме "обработчика" будет выступать просто в качестве "навороченного С", без ООП.

Это не страшно.
Смущает другое: обмен через pipe'ы - не сильно ли накладный механизм?
А то вдруг трафик будет большой...

[Portnov]

pipe - это практически непосредственная передача данных между процессами (кроме случая, когда приемник не успевает обрабатывать данные - они будут буферизоваться в памяти). Выше производительность может быть только в случае shared memory.

[Denjs]

гм.... я как всегда пытаюсь представить это все в виде сигналов и слотов....

[Zeus]

pipe - это практически непосредственная передача данных между процессами

А такое возможно без участия ядра?

[whirlwind]

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

[Portnov]

Zeus, а как вы себе такое представляете? Процессы не имеют доступа к адресным пространствам друг друга. Самый скоростной способ передачи данных между процессами - shared memory, быстрее уже просто некуда.

[Zeus]

Portnov
Самое быстрое - работать в рамках одного процесса.

[d_n_k]

Может уже есть похожий программный продукт, в код которого можно "заглянуть"?
Или вообще есть подобный движок?

gstreamer - конвеерная обработка