Сравнение Unix / Linux IPC - PullRequest
Новая
       22

Сравнение Unix / Linux IPC

76 голосов
/ 01 января 2009

Unix / Linux предлагает множество IPC: каналы, сокеты, разделяемая память, dbus, очереди сообщений ...

Каковы наиболее подходящие приложения для каждого и как они работают?

Ответы [ 4 ]

93 голосов
/ 01 января 2009

Unix IPC

Вот большая семерка:

  1. труба

    Полезно только среди процессов, связанных как родитель / потомок. Звоните pipe(2) и fork(2). Однонаправленный.

  2. FIFO или именованная труба

    Два несвязанных процесса могут использовать FIFO в отличие от простой трубы. Звоните mkfifo(3). Однонаправленный.

  3. Сокет и Unix Domain Socket

    двунаправленная. Предназначен для сетевого общения, но может использоваться и локально. Может быть использован для другого протокола. Там нет границы сообщения для TCP. Звоните socket(2).

  4. Очередь сообщений

    ОС поддерживает дискретное сообщение. См. sys / msg.h .

  5. Сигнал

    Сигнал отправляет целое число в другой процесс. Не очень хорошо сочетается с многопоточностью. Звоните kill(2).

  6. Семафор

    Механизм синхронизации для нескольких процессов или потоков, похожий на очередь людей, ожидающих ванную. См. sys / sem.h .

  7. Общая память

    Выполните свой собственный контроль параллелизма. Звоните shmget(2).

Сообщение Граничная проблема

Одним из определяющих факторов при выборе одного метода над другим является проблема границы сообщения. Вы можете ожидать, что «сообщения» будут отдельными друг от друга, но это не относится к потокам байтов, таким как TCP или Pipe.

Рассмотрим пару эхо-клиента и сервера. Клиент отправляет строку, сервер получает ее и отправляет обратно. Предположим, клиент отправляет «Hello», «Hello» и «Как насчет ответа?».

При использовании протоколов байтовых потоков сервер может получать сообщения «Hell», «oHelloHow» и «about answer?»; или более реалистично "HelloHello, как насчет ответа?" Сервер не имеет ни малейшего представления, где находится граница сообщения.

Старая хитрость заключается в том, чтобы ограничить длину сообщения CHAR_MAX или UINT_MAX и согласиться сначала отправить длину сообщения в char или uint. Таким образом, если вы находитесь на принимающей стороне, вы должны сначала прочитать длину сообщения. Это также подразумевает, что только один поток должен одновременно выполнять чтение сообщений.

С дискретными протоколами, такими как UDP или очереди сообщений, вам не нужно беспокоиться об этой проблеме, но программно потоки байтов легче решать, поскольку они ведут себя как файлы и stdin / out.

16 голосов
/ 01 января 2009

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

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

Очереди сообщений и сигналы могут быть полезны для сложных приложений реального времени, но они не так гибки.

Эти методы были естественным образом созданы для связи между процессами, и использование нескольких потоков внутри процесса может усложнить ситуацию, особенно с помощью сигналов.

10 голосов
/ 14 мая 2009

Вот веб-страница с простым тестом: https://sites.google.com/site/rikkus/sysv-ipc-vs-unix-pipes-vs-unix-sockets

Насколько я могу судить, у каждого есть свои преимущества:

  • Канал ввода-вывода самый быстрый, но для работы требуются отношения родитель / потомок.
  • Sysv IPC имеет определенную границу сообщения и может локально подключать разрозненные процессы.
  • Сокеты UNIX могут локально соединять разрозненные процессы и имеют более высокую пропускную способность, но нет внутренних границ сообщения.
  • Сокеты TCP / IP могут соединять любые процессы, даже по сети, но имеют более высокие издержки и нет внутренних границ сообщения.
8 голосов
/ 02 января 2009

Стоит отметить, что многие библиотеки реализуют один тип вещей поверх другого.

Совместно используемая память не должна использовать ужасные функции совместно используемой памяти sysv - гораздо более элегантно использовать mmap () (mmap файл в tmpfs / dev / shm, если вы хотите, чтобы он назывался; если вы хотите, чтобы процессы не выполнялись, чтобы наследовать их анонимно). Тем не менее, это по-прежнему оставляет вашим процессам некоторую потребность в синхронизации, чтобы избежать проблем - обычно с помощью некоторых других механизмов IPC для синхронизации доступа к общей области памяти.

...