Выбор IPC-решения для событийного приложения

В настоящее время я работаю над довольно большим однопоточным, основанным на событиях, приложением, разработанным для epoll под Linux и сопоставимых технологий под другими платформами. В настоящее время, когда мы хотим, чтобы два экземпляра обменивались данными, они обычно делают это через сокеты, независимо от того, работают они на одном компьютере или нет. По соображениям производительности я предполагаю использовать некоторую форму IPC для ускорения обмена данными с одной и той же машиной. Теперь мне нужно решить, какой механизм IPC использовать.

Для меня важны следующие факторы:

  • управляемый событиями, без полной переделки - если механизм IPC не подходит для epoll, для меня потеряны месяцы работы
  • быстро - если этот механизм не быстрее сокетов, не стоит тратить время на его реализацию
  • гибкий и (пере) настраиваемый во время выполнения - я считаю, что это исключает MPI и другие
  • многопоточность не требуется.

Я готов использовать разные механизмы для разных платформ, если все они используют одну и ту же парадигму. Я также готов как можно глубже изучить C / C ++ / Obj-C для привязок к конкретной платформе.

Любое предложение?

Спасибо.


person Yoric    schedule 06.12.2010    source источник
comment
Кстати, сокеты имеют гораздо лучшую производительность, когда они открыты на одном компьютере: stackoverflow.com/questions/1644851/   -  person    schedule 06.12.2010
comment
По моему опыту, IP-сокеты этого не делают.   -  person Yoric    schedule 24.01.2011


Ответы (3)


Сокеты Unix. Именованные каналы. ФИФО.

Все они предлагают одну и ту же базовую функциональность - обмен данными между процессами между компьютерами. Однако реализации предлагают немного другое поведение.

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

person AlastairG    schedule 06.12.2010
comment
IIRC, FIFO реализованы поверх каналов, а каналы имеют репутацию не слишком быстрых (я не проверял это годами, поэтому, возможно, я не в курсе событий). - person Yoric; 06.12.2010
comment
* Никсы традиционно тратили немало времени на оптимизацию своей реализации конвейера. Они не медленные, но среди самых быстрых механизмов IPC. - person nos; 06.12.2010

действительно, как упоминалось в skwllsp, сокеты AF_INET оптимизированы для передачи данных на локальном хосте, а скорость и сложность сопоставимы (почти такие же?) с FIFO, pipe, unix-сокетами (большая часть обработки skbuff пропускается, если адресатом является тот же хозяин). мои 2 цента - использовать розетки. таким образом вы не только сохраняете тот же интерфейс для своего механизма IPC, но и успешно повторно используете свой код как для удаленных, так и для локальных сценариев.

person user237419    schedule 06.12.2010

Попробуйте Unix SysV IPC. Он поддерживает: -

  • Очереди сообщений
  • Семафор
  • Общая память

который может вам помочь.

Эта ссылка может помочь больше: http://www.ibm.com/developerworks/aix/library/au-ipc/index.html

person Omid    schedule 09.12.2010
comment
Действительно ли SysV IPC совместим с подходом epoll? У меня создалось впечатление, что это не так. - person Yoric; 10.12.2010
comment
Причин несовместимости найти не удалось, но, честно говоря, я не уверен! Дело в том, что SysV IPC - это просто другой тип, и пока вам удастся использовать сокет (хотя я не знаю, какой сокет вы использовали, я предполагаю, что TCP), тогда это не должно быть проблемой. - person Omid; 11.12.2010
comment
Перефразирую: epoll очень сильно ориентирован на fd. SysV IPC использует полностью систему событий, не так ли? Значит, мне придется проводить опрос из двух источников вместо одного? - person Yoric; 14.12.2010