zeroMQ

ZMQ 혹은 0MQ 라고도 쓰는것 같은데 접속 모델부터 좀 찾아 보는 중

 

REQ-REP는 단순(?)한 요청-응답 모델이고

PUB-SUB는 서버에 의한 broadcast 모델 pipeline은 아직 모르겠다.

REQuest-REPly PUBlisher - SUBscriber PUSH- PULL (pipeline)

[링크 : https://soooprmx.com/zmq의-기본-개념들/]

[링크 : https://makersweb.net/opensource/19422]

[링크 : https://zeromq.org/]

 

Figure 2 - Request-Reply	Figure 4 - Publish-Subscribe	Figure 5 - Parallel Pipeline
Figure 6 - Fair Queuing

[링크 : https://zguide.zeromq.org/docs/chapter1/]

 

Shared Queue (DEALER and ROUTER sockets) In the Hello World client/server application, we have one client that talks to one service. However, in real cases we usually need to allow multiple services as well as multiple clients. This lets us scale up the power of the service (many threads or processes or nodes rather than just one). The only constraint is that services must be stateless, all state being in the request or in some shared storage such as a database.

[링크 : https://zguide.zeromq.org/docs/chapter2/]

 

Request-Reply Combinations We have four request-reply sockets, each with a certain behavior. We’ve seen how they connect in simple and extended request-reply patterns. But these sockets are building blocks that you can use to solve many problems. These are the legal combinations: REQ to REP DEALER to REP REQ to ROUTER DEALER to ROUTER DEALER to DEALER ROUTER to ROUTER

[링크 : https://zguide.zeromq.org/docs/chapter3/]

 

Messaging Patterns Underneath the brown paper wrapping of ZeroMQ’s socket API lies the world of messaging patterns. ZeroMQ patterns are implemented by pairs of sockets with matching types. The built-in core ZeroMQ patterns are: Request-reply, which connects a set of clients to a set of services. This is a remote procedure call and task distribution pattern. Pub-sub, which connects a set of publishers to a set of subscribers. This is a data distribution pattern. Pipeline, which connects nodes in a fan-out/fan-in pattern that can have multiple steps and loops. This is a parallel task distribution and collection pattern. Exclusive pair, which connects two sockets exclusively. This is a pattern for connecting two threads in a process, not to be confused with “normal” pairs of sockets.

XPUB socket Same as PUB except that you can receive subscriptions from the peers in form of incoming messages. Subscription message is a byte 1 (for subscriptions) or byte 0 (for unsubscriptions) followed by the subscription body. Messages without a sub/unsub prefix are also received, but have no effect on subscription status.

XSUB socket Same as SUB except that you subscribe by sending subscription messages to the socket. Subscription message is a byte 1 (for subscriptions) or byte 0 (for unsubscriptions) followed by the subscription body. Messages without a sub/unsub prefix may also be sent, but have no effect on subscription status.

[링크 : https://zeromq.org/socket-api/]

 

int zmq_device (int device, const void *frontend, const void *backend); ZMQ_QUEUE starts a queue device ZMQ_FORWARDER starts a forwarder device ZMQ_STREAMER starts a streamer device Queue device ZMQ_QUEUE creates a shared queue that collects requests from a set of clients, and distributes these fairly among a set of services. Requests are fair-queued from frontend connections and load-balanced between backend connections. Replies automatically return to the client that made the original request. This device is part of the request-reply pattern. The frontend speaks to clients and the backend speaks to services. You should use ZMQ_QUEUE with a ZMQ_XREP socket for the frontend and a ZMQ_XREQ socket for the backend. Other combinations are not documented. Refer to zmq_socket(3) for a description of these socket types. Forwarder device ZMQ_FORWARDER collects messages from a set of publishers and forwards these to a set of subscribers. You will generally use this to bridge networks, e.g. read on TCP unicast and forward on multicast. This device is part of the publish-subscribe pattern. The frontend speaks to publishers and the backend speaks to subscribers. You should use ZMQ_FORWARDER with a ZMQ_SUB socket for the frontend and a ZMQ_PUB socket for the backend. Other combinations are not documented. Refer to zmq_socket(3) for a description of these socket types. Streamer device ZMQ_STREAMER collects tasks from a set of pushers and forwards these to a set of pullers. You will generally use this to bridge networks. Messages are fair-queued from pushers and load-balanced to pullers. This device is part of the pipeline pattern. The frontend speaks to pushers and the backend speaks to pullers. You should use ZMQ_STREAMER with a ZMQ_PULL socket for the frontend and a ZMQ_PUSH socket for the backend. Other combinations are not documented. Refer to zmq_socket(3) for a description of these socket types.

[링크 : http://api.zeromq.org/2-1:zmq-device]