Q1: В чем разница между использованием ZeroMQ для отправки сообщений дочерним процессам и взаимодействием между процессами по умолчанию, объясненным здесь?
Вопрос 2. Что будет более подходящим для прямого общения с ребенком? (Быстрее)
Q3: В документации сказано: Creates an IPC channel, какой тип IPC он использует? TCP? Розетки?
Хороший момент, чтобы заявить в самый начальный момент - ZeroMQ без брокера
ZeroMQ для отправки сообщений и IPCну, говоря таким образом, ZeroMQ сосредотачивается на самых разных преимуществах, а не только на возможности отправлять сообщения и масштабировать (и то, и другое полезно).
ZeroMQ знакомит с (хорошо масштабируемыми) шаблонами формального общенияПри этом основное внимание на стороне приложения направлено на то, какие примитивы шаблонов библиотеки ZeroMQ можно использовать для прямого выполнения действительно необходимой модели поведения между участвующими агентами (один PUB + много SUB< /strong>-s / много PUB-s + много перекрестно связанных SUB-s )
или
как составить немного более сложный, специфичный для приложения , сигнальная плоскость (используя доступные ZeroMQ строительных блоков поведенчески-примитивных архетипов сокетов + устройства + логика приложения, предоставляя конечный автомат или транзакционные механизмы для дополнительной функциональности сигнальной плоскости).
IPC предоставляет тупую службу на основе операционной системы, никакого поведениячто нормально, если понимать его в чистом контексте O/S (т. е. "батарейки включены" не).
Тем не менее, любая поддержка обмена сообщениями более высокого уровня и другие важные функции (такие как справедливая очередь, циклическое планирование, мультиплексная транспортно-независимая композиция услуг по любым / всем { inproc:// | ipc:// | tcp:// | pqm:// | ... } транспортным классам, многоканальные опрашивающие устройства с миллисекундной настройкой, нулевое копирование передача сообщений и многие другие интеллектуальные функции) должны быть спроектированы/реализованы самостоятельно (это как раз тот случай, почему ZeroMQ был добавлен в игру, не для того ли, не так ли? большое спасибо, команда Мартина СУСТРИКА и Питера ХИНТДЖЕНСА )
Чтобы увидеть большую картину по этому вопросу >>> с дополнительными аргументами, простое изображение сигнального самолета и прямая ссылка на обязательную к прочтению книгу Питера ХИНТДЖЕНСА.
Если вас интересует младшая сестра ZeroMQ, nanomsg, проверьте еще более легкую структуру от Мартина САСТРИКА nanomsg.org >>>.
Быстрее, быстрее, быстрее всего...
Для вдохновения по поводу минимальных накладных расходов (читается как высокий потенциал скорости) и нулевого копирования (читается как эффективное предотвращение накладных расходов) прочитайте о транспортных классах inproc:// для обмена сообщениями между потоками:
IPC.IPC сам по себе является транспортным классом. Нет необходимости перепаковывать/выравнивать/собирать/CRC/инкапсулировать/отправлять|декодировать\CRC-recheck\demap... необработанные IPC-данные в TCP-пакеты более высокой абстракции, если они транспортируются прямо между localhost процессами по IPC-канал, что ли?
ipc:// вообще не требует TCP накладных расходов и может работать аналогично в nanomsg по именованным каналам ››› nanomsg.org/v0.1/nn_ipc.7.html
- person user3666197; 21.09.2015
Использование очереди сообщений, такой как ZeroMQ, дает вам возможность масштабирования до нескольких компьютеров, в то время как взаимодействие дочерних процессов является только локальным и может масштабироваться только для использования преимуществ оборудования на этом компьютере.
Наличие брокера сообщений будет медленнее, поскольку он полагается на TCP, тогда как для связи дочернего процесса используется канал или стандартный ввод-вывод. Что быстрее, поскольку позволяет избежать накладных расходов TCP и сетевого стека. Хотя я бы сказал, что преимущество в скорости здесь незначительно, особенно если вы планируете масштабирование до нескольких машин.
Также стоит отметить, что ZeroMQ может использовать unix_sockets и предлагает другие формы IPC, которые очень похожи на то, что будет предлагаться основным модулем child_process. Хотя, вероятно, это было бы сложнее в использовании.
Возможно, было бы неплохо использовать ZeroMQ с unix_sockets или конвейерами, пока вам не понадобится масштабирование на нескольких машинах.
Что ж, в случае, на который вы ссылаетесь, мы говорим о двух конкурирующих протоколах. Один общий (ZMQ), а другой привязан к NodeJS. Цитата из статьи о IPC, которую вы связали с доступом к каналу IPC fd любым способом, кроме process.send(), или использованием канала IPC с дочерним процессом, который не является экземпляром Node.js, не поддерживается.
В общем, IPC (межпроцессное взаимодействие) может относиться к ряду различных протоколов, включая ZMQ. ZMQ — это механизм IPC. Существуют и другие механизмы более низкого уровня, такие как PIPE и UDP-сокеты. Я работал как с PIPE, так и с сокетами UDP и обнаружил, что протокол более высокого уровня, такой как ZMQ, почти всегда лучше даже в простом двухстороннем случае из-за двух проблем с PIPE и UDP:
Буферизация и разбиение на фрагменты.
Буферизация. Операционная система постоянно создает буферы для хранения частей сообщений, отправляемых между процессами. Эти буферы должны быть сброшены. В конечном итоге вам придется написать кучу сложного кода, который трудно понять правильно, как для сброса сообщений, так и для чтения и сшивания частично отправленных сообщений.
Разбиение на фрагменты: UDP имеет переменный максимальный размер сообщения от 500 до 65000 байт. Вы должны иметь дело с этими максимальными размерами и разбивать свои сообщения при непосредственном использовании UDP. ZMQ обрабатывает фрагментацию автоматически, и вам не нужно возиться с этим. В ZMQ нет максимального размера сообщения (ну, в случае ZMQ сообщения должны помещаться в памяти).
