1. дома
  2. Вопрос и ответ
  3. Выбор решения IPC для приложения, управляемого событиями

Выбор решения IPC для приложения, управляемого событиями

2010-12-06 3 views
4

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

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

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

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

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

Спасибо.

источник

2010-12-06 Yoric

+1

Кстати, розетки имеют гораздо более высокую производительность, когда они открыты на одном компьютере: http://stackoverflow.com/questions/1644851/sockets-on-same -machine-for-windows-and-linux/1650906 # 1650906 – 2010-12-06 10:38:48

+0

Ну, по моему опыту, IP-разъемов нет. – Yoric 2011-01-24 13:44:28

ответ

3

Unix гнезда. Именованные трубы. FIFO.

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

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

источник

2010-12-06 10:52:01 AlastairG

+0

IIRC, FIFO реализованы поверх труб, а трубы имеют репутацию не слишком быстро (я не проверял это в течение многих лет, поэтому я, возможно, не был в курсе темы). – Yoric 2010-12-06 11:14:45

2

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

источник

2010-12-06 13:05:59 user237419

 Смежные вопросы

  • Нет связанных вопросов^_^