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

Unix IPC

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

1. Трубка

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

2. ФИФО или именованный канал

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

3. Разъем и Сокет домена Unix

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

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

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

5. Сигнал

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

6. Семафор

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

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

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

Проблема с границей сообщения

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

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

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

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

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

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

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

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

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

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

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

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

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

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