Какой метод IPC лучше выбрать?

sockets

>sockets А чуть подробнее почему?

Для больших объемов стратежнее использовать разделяемую память + сообщения

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

Сказал же чел, что источник - всё равно какой-то поток. Так что сокеты однозначно.

Где он это сказал ?

Похоже, что действительно поток....

Вам ещё вариант:
1) берём OmniORB4, ORBit или MICO
2) пишем IDL наподобие этого:

interface MyDaemon {
    typedef sequence <byte> Packet;

    void begin ();
    void packet (in Packet packet);
    void end ();
};

3) делаем реализацию
   (для такого интерфейса - что может быть проще?)

Всё работает, все довольны. Демоны общаются.
Можно даже пофантазировать со сложными схемами общения,
большим числов клиентов и т д.

http://omniorb.sourceforge.net/
http://www.gnome.org/projects/ORBit2/
http://omg.org

из базуки по муравьям, блин.

совсем не unix way

Автор темы не уточнил, муравьи у него или мамонты :)

они самые - муравьи. Орбит точно не подойдет :)

> Для больших объемов стратежнее использовать разделяемую память + сообщения

Для действительно больших объёмов - файлы.

erDiZz прав на 100%..
по хорошему сложно-сочинённые отношения процессов 
надо делать на CORBA..
Это вообще правильный подход и целиком и полностью unix-way

pipes или mmap :-)

> pipes или mmap :-) Точна. mkfifo(char*,mode_t) и вперёд

А mkfifo() со всеми вытекающими не будет замедлять I/O. Всеж это структура файловой системы, или нет?

>>omniORB is a robust high performance CORBA ORB for C++ and Python.

Не это не UNIX way

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

Че мозги человеку парите...

Если все в пределах одного хоста и в планах нету размазывать шнягу по сетке - однозначно пайпы, быстрее чем сокет и проще. Разделяемая память ище быстрее, но с пайпом проще работать, меньше проблем. Ничего не тормозит, создаешь mkfifo-й вначале два пайпа в /tmp/ или ище где, через один гонишь данные в одну сторону, через другой в другую.

Если есть (может возникнуть) необходимость разнесения по разным хостам, тогда сокеты. Реализцию на пайпах при необходимости несложно переделать на сокеты (или настроить NFS и оставить все на пайпах - но это будет муйня).

Для драфта я б брал пайпы и не мучался - пайп создать одлна строка, сокет поднять и следить и за евойными ошибками... это несколько сложнее.

> А mkfifo() со всеми вытекающими не будет замедлять I/O. Всеж это структура файловой системы, или нет?

Мож и замедляет. Я как-то передавал данные от драйвера платы L-783 к приложению, которое это все добро обрабатывало. 3 канала по 1 МГц 12 разрядного АЦП шли пормально.

> Если все в пределах одного хоста и в планах нету размазывать шнягу по сетке - однозначно пайпы, быстрее чем сокет и проще. Разделяемая память ище быстрее, но с пайпом проще работать, меньше проблем. Ничего не тормозит, создаешь mkfifo-й вначале два пайпа в /tmp/ или ище где, через один гонишь данные в одну сторону, через другой в другую.

Поддерживаю полностью.

Работать с сокетами сложнее, и следить за ошибками тоже сложнее, но это, по крайней мере, возможно. А у пайпа не особенно поймешь, что происходит. Один SIGPIPE чего стоит ...

Каналы - очень простой механизм для очень простых применений.