Q : Где или в какой системе находятся очереди сообщений?
Концепция Zen-of-Zero, asвстроенный ZeroMQ использует разумные и достаточно правильные сопоставления, в зависимости от конкретного случая.
Существуют случаи, когда вообще нет Очереди, как вы их знаете, например:
транспортный класс inproc:// не имеет очереди, как можно знать, поскольку существуют только области памяти, в которые сообщения помещаются и считываются.Таким образом, вся магия появляется внутри специального компонента - экземпляра Context().Там происходит отображение сообщений в память.Случай inproc:// является особым случаем, когда потоки ввода-вывода вообще не нужны, поскольку весь процесс основан исключительно на отображении памяти, а экземпляр Context() манипулирует его внутренними состояниями, чтобыэмулировать как внешне предоставленную абстракцию поведения, подобного очереди, так и внутреннее управление "очередью".
Другие, аналогично, работают с localhost расположенными внутренними конечными точками очереди (-ями):
по очевидной причине, поскольку ZeroMQ - это система без посредников, отсутствует «центральное» место, и все функции распределены по участвующим (скоординированным и взаимодействующим) узлам.
Любой из концов Очереди находится в Context() -экземплярах, один в localhost -области одной стороны, другой в "удаленном" -хосте * Context(), как было объявлено и согласованопри построении указанного сокета-архетипа ZMTP / RFC .bind() / .connect().Поскольку для такого сокета, специфичного для ZMTP, было получено положительное подтверждение, абстракция очереди (реализованная в распределенной системе ) остается в силе, пока такой сокет не получит .close() -ед или Context() -экземпляр не был получен принудительно или случайно .term() -ed.
По этим причинам, необходимые емкость размеры необходимы, как сообщенияможет храниться в памяти, работающей с Context(), до того, как она будет транспортирована по соединению, опосредованному { network | ipc-channel } (на стороне .send()), или до того, как будет .recv() -ед (изнутри удаленного экземпляра Context())с помощью удаленного кода приложения для любого дальнейшего использования данных полезной нагрузки сообщения (возможно управление данными сообщения нулевой копии, однако не все варианты использования действительно используют этот режим для избежания реплицированных выделений памяти и затрат на передачу данных).