Какие методы доступны в Unix для Pub Sub IPC?
Существуют различные варианты IPC.
По сети:
- для клиента-сервера, можно использовать TCP
- для sub sub можно использовать многоадресную рассылку UDP
Локально:
- для клиент-сервера можно использовать доменные сокеты unix
- для паба саб, можете использовать???
Я полагаю, что меня заинтересует некоторый файловый дескриптор, который поддерживает много читателей (подписчиков) и много писателей (издателей) одновременно. Является ли этот шаблон использования осуществимым / эффективным в Unix?
3 ответа
После долгих поисков я не нашел ничего особенного в способе многоадресной рассылки ipc, поэтому я решил написать программу pubsub, которая принимает в качестве аргументов адрес издателя и адрес подписчика, прослушивает и принимает соединения по этим двум адресам, а затем для каждой полезной нагрузки, полученной по соединению издателя, запишите его в каждое из соединений подписчика. Меня не удивит, если это неэффективно или изобретать велосипед, но я не нашел лучшего решения.
Я искал решения для подобной проблемы и нашел /dev/fanout. Fanout - это модуль ядра, который реплицирует свой вход во все процессы, читающие из него. Вы можете думать об этом как о механизме трансляции IPC. Хорошо работает для небольших данных полезных нагрузок, по словам автора. Несколько процессов могут записывать на устройство, а несколько процессов могут читать с него. Я не уверен в атомарности записей, хотя. Небольшие записи из нескольких процессов должны происходить атомарно, как в случае FIFO и т. Д.
Подробнее о Fanout:
http://compgroups.net/comp.linux.development.system/-dev-fanout-a-one-to-many-multi/2869739 http://www.linuxtoys.org/fanout/fanout.html
Также есть очереди сообщений Posix. Как man mq_overview кладет это:
Очереди сообщений POSIX позволяют процессам обмениваться данными в форме сообщений. Этот API отличается от того, который предоставляется очередями сообщений System V (msgget(2), msgsnd(2), msgrcv(2) и т. Д.), Но обеспечивает аналогичную функциональность.
Очереди сообщений создаются и открываются с использованием mq_open(3); эта функция возвращает дескриптор очереди сообщений (mqd_t), который используется для ссылки на открытую очередь сообщений в последующих вызовах. Каждая очередь сообщений идентифицируется именем формы /somename; то есть строка с нулевым символом в конце длиной до NAME_MAX (т. е. 255) символов, состоящая из начального слэша, за которым следует один или несколько символов, ни один из которых не является слешем. Два процесса могут работать в одной и той же очереди, передавая одинаковое имя в mq_open (3).
Сообщения передаются в очередь и из нее с помощью mq_send (3) и mq_receive (3). Когда процесс завершил использование очереди, он закрывает ее с помощью mq_close (3), а когда очередь больше не требуется, его можно удалить с помощью mq_unlink (3). Атрибуты очереди можно получить и (в некоторых случаях) изменить, используя mq_getattr (3) и mq_setattr (3). Процесс может запросить асинхронное уведомление о прибытии сообщения в ранее пустую очередь, используя mq_notify (3).
Дескриптор очереди сообщений является ссылкой на описание открытой очереди сообщений (см. Open (2)). После fork (2) дочерний объект наследует копии дескрипторов очереди сообщений своего родителя, и эти дескрипторы ссылаются на те же описания открытых очередей сообщений, что и соответствующие дескрипторы в родительском объекте. Соответствующие дескрипторы в двух процессах имеют общие флаги (mq_flags), которые связаны с описанием открытой очереди сообщений.
Каждое сообщение имеет связанный приоритет, и сообщения всегда доставляются процессу получения с наивысшим приоритетом в первую очередь. Приоритеты сообщений варьируются от 0 (низкий) до sysconf(_SC_MQ_PRIO_MAX) - 1 (высокий). В Linux sysconf (_SC_MQ_PRIO_MAX) возвращает 32768, но POSIX.1 требует только, чтобы реализация поддерживала как минимум приоритеты в диапазоне от 0 до 31; некоторые реализации предоставляют только этот диапазон.
Более дружелюбное введение Майкла Керриска доступно здесь: http://man7.org/conf/lca2013/IPC_Overview-LCA-2013-printable.pdf