Разделить именованный канал на два конца: один только для чтения, один только для записи.

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

По сути, я пытаюсь “разделить” канал пополам, так чтобы конец записи был с моей первой программой:

program1/
├── write-end-of-pipe
└── program1.c

и чтобы конец чтения был со второй программой:

program2/
├── read-end-of-pipe
└── program2.c

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

На данный момент, мое лучшее решение следующее:

1. Создать именованный канал в program1 и изменить разрешения файла так, чтобы он был доступен только для записи этим пользователем:

   cd ~/program1
   mkfifo write-end-of-pipe
   chmod 200 write-end-of-pipe
   

2. Создать именованный канал в program2 и изменить разрешения файла так, чтобы он был доступен только для чтения этим пользователем:

   cd ~/program2
   mkfifo read-end-of-pipe
   chmod 400 read-end-of-pipe
   

3. Создать нового пользователя для маршрутизации и запустить демон, который будет переправлять данные из первого именованного канала во второй:
   (Предполагается, что пользователь уже создан:)

   su - forwarding-daemon-user
   chmod 400 ~/program1/write-end-of-pipe
   chmod 200 ~/program2/read-end-of-pipe
   cat write-end-of-pipe > read-end-of-pipe &
   

Проблема, с которой я сталкиваюсь, двоякая:

1. Требуется два канала вместо одного.
2. Требуется демон. (Моя команда cat недостаточно надёжна сама по себе, но она передаёт суть.)

Есть ли более лучший способ создать два файла для канала, один из которых можно только записывать, а другой — только читать?

Редактирование 1: Для некоторого контекста о том, для чего я хотел бы использовать это межпроцессное взаимодействие: Я думаю, было бы круто, если бы я мог реализовать “шэринг экрана,” где один процесс, написанный на одном языке, создаёт экран (по сути видеопоток), а другой процесс на совершенно другом языке отображает полученный экран. (Пример использования: один язык делает лёгким создание игры, но вы хотите написать GUI на другом языке.) Причина моей паранойи по поводу записи/чтения заключается в том, что я хочу иметь возможность заменять различные программы, создающие или просматривающие экраны, и не хочу беспокоиться о подключении двух создателей экранов вместе (если я предоставляю конец чтения и конец записи, тогда одна программа получает неверный конец, если я сделал такую ошибку, и ошибка обнаруживается немедленно, а не позже, когда канал переполняется) или другие неработающие программы, вызывающие скрытые проблемы.

Редактирование 2: Я считаю, что должен объяснить, почему наличие двух отдельных пользователей для чтения/записи не является идеальным решением для меня. Главная причина заключается в том, что это значительный шаг на пути к контейнеризации. Как только вы скажете: “Я просто буду управлять разрешениями через отдельных пользователей/пространства имён,” вы должны понять, как вы собираетесь настраивать этих пользователей/пространства имён, и это, по сути, означает помещать программу в контейнер. Я хочу избежать этого, потому что это не так гибко; внезапно каждая программа теперь нуждается в стандартизированном способе запуска, а именованный канал, соединяющий две программы, должен создаваться специальным пользователем, который может заглядывать в эти контейнеры и т.д.

Таким образом, я бы предпочёл избежать использования нескольких пользователей и подобные техники, требующие обёртывания программы, которую нужно вызвать. Решение, которое будет работать хорошо – это если бы был способ “монтировать” именованный канал так, чтобы у него были разные разрешения на файл из двух разных мест для записи/чтения, но я не думаю, что это возможно в Linux.

Если бы я абсолютно хотел гарантировать, что ситуация с двойной записью или двойным чтением не может произойти, я бы просто перешёл на использование сокетов (либо TCP, либо UNIX).

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

Записывающая программа должна будет принять (accept()) входящее соединение, и вы можете просто реализовать логику так, чтобы она не принимала второго соединения, пока первое соединение не завершится – таким образом избегая ситуации с двойным чтением.

Итог: fifos подходят для быстрого создания чего-то, но для надёжного решения я бы их игнорировал.

С другой стороны, вы должны спросить “является ли это реальной проблемой”?
Затраты на появление проблемы/затраты на её исправление настолько минимальны, что, вероятно, не стоит моего времени, чтобы этого избежать.

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

├── write-end-of-pipe
├── read-end-of-pipe

Нет, этого не произойдет с именованными каналами. Их суть в том, что они одно “видимое имя” для обоих концов.

Итак, если это то, что вы хотите, то это неверная технология.

Для действительно однонаправленных сообщений с файловой семантикой, вы могли бы позволить двум процессам соединяться через двунаправленные UNIX-сокеты¹. Вы могли бы использовать pipe для открытия каналов, закрывать конец, который они не хотят использовать, и передавать файловые дескрипторы через сокет.

Другой вариант – создать именованный канал, позволить первой программе открыть его в нужном ей режиме и изменить разрешения для того же пользователя так, чтобы он был “только для чтения” или “только для записи”. Это не влияет на дескрипторы файлов, полученные через открытие до изменения разрешений, так что программа продолжает работать, но делает невозможным для “следующей” программы получить доступ к файлу в неправильном режиме. Однако, в этом есть очевидная временная гонка.

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

¹ TCP здесь не сработает, потому что вам нужно обмениваться файловыми дескрипторами