1 ZeroMQ Overview
ZeroMQ is based multithreaded network message queue library, its socket type connection processing frame, even abstract details of the underlying routing, across multiple transport protocols to provide sockets. ZeroMQ network communication is a new layer, between the application layer and the transport layer (in accordance with the TCP / IP division), which is a scalable layers, may be run in parallel, distributed across the system dispersion.
2 System Architecture
2.1 The overall architecture
ZeroMQ Almost all I / O operations are asynchronous, the main thread is not blocked. ZeroMQ based on an incoming call when the user zmq_init function interface parameters, create a corresponding number of I / O Thread. Each I / O has bound with the Thread Poller, Poller Reactor classic pattern implementation, Poller using a different network I / O model (select, poll, epoll, devpoll, kequeue etc.) depending on the operating system platform. Main thread and I / O thread to communicate by passing messages Mail Box. When the Client or Server starts listening to initiate a connection, or create zmq_connecter zmq_listener in the main thread, in the form of Mail Box message will bind it to the I / O threads, I / O thread will zmq_connecter or zmq_listener to add to the Poller listening read / write events. Server and Client at the time of the first communication, creates zmq_init to send identity, in order to be certified. After the certification, the two sides will create a Session for this connection, after the two sides to communicate through Session. Session will be associated with each of the respective read / write pipeline, the main thread messaging are only read from the pipe / write data. Session not actually exchange I / O data with the kernel, but to exchange I / O data to the kernel via the plugin to the Session Engine.
2.3 Message Model
ZeroMQ message traffic into four models, each model is the one junction (Exclusive-Pair), a request response model (Request-Reply), publish-subscribe model (Publish-Subscribe), the push-pull model (Push-Pull). This summary of the four models of the generic network communication model, in practice may be required depending on the application, a combination of two or more models in which to form their own solutions.
2.3.1 one pair model
The simplest 1: 1 messaging model can be considered a TCP Connection, but TCP Server can only accept a connection. Data can flow bidirectionally, the request response is different from this model later.
2.3.2 request response model
By a request initiates a request, then wait for a response end response. Must correspond to a request for a response from the requester's point of view is made - receive pair, from the perspective of the receiving end response - send right. One with the difference of the model is that the requester node may be 1 ~ N a. This model is mainly used for long-distance calls and task allocation. Echo service is the application of this classic model.
FIG 3 Request Response Model
2.3.3 publish-subscribe model
Posted end of a one-way distribution of data, and does not care whether or not to send all the information to the subscription ends. If the publishing side began publishing information, subscribe to end up not already connected, the information will be discarded. Subscribe to end unconnected lead to information loss problem, you can request a response model portfolio to solve. Subscribe to end the case only responsible for receiving, but not feedback, and in the end consumer subscription slower than the publishing side, it will accumulate data in the subscription ends. The model for data distribution. Weather Forecast, microblogging star fans can apply this classic model.
Figure 4 publish and subscribe model
2.3.4 Push model
Server-side end as Push, Pull and Client-side as the end, if there are multiple simultaneous connections to the Client-Server end, you'll do a Server-side load balancing in-house, using an algorithm evenly distributed, all the messages posted to the Client-balanced on. Compared with the publish-subscribe model, sliding model in the absence of the consumer, the announcement will not be consumed; in the case of insufficient ability of the consumer, the consumer can provide multiple parallel consumer solutions. This model is mainly used for multi-tasking.
5 Push model
2.4 Communication Protocol
提供进程内、进程间、机器间、广播等四种通信协议。通信协议配置简单，用类似于URL形式的字符串指定即可，格式分别为inproc://、ipc://、tcp://、pgm://。ZeroMQ会自动根据指定的字符串解析出协议、地址、端口号等信息。
3 工作流程
图6 基本流
4 ZMQ交互对象
序列图有助于理解对象状态变迁，下图描述的是客户端的对象状态变迁。zmq_socket以ZMQ_REQ模式实例化，用以进行tcp通信：
void *requester = zmq_socket (context, ZMQ_REQ); zmq_connect (requester, "tcp://localhost:5555");
5 ZMQ 类层次
①、object_t，主要用于发送命令和处理命令，所有继承object_t的子类都具备该类的功能
②、io_thread_t，内含一个poller，可监听句柄的读、写、异常状态，继承自object_t，具有接收命令、处理命令、发送命令的功能
③、io_object_t，可以获取一个io_thread_t的poller，从而具备poller功能，所有继承自该类的子类都具有pollere功能，可监听句柄的读、写、异常状态
④、reaper_t，zmq的回收线程
⑤、own_t，zmq的对象树结点，或者说多叉树的结点，其主要用于对象的销毁，可以想到，对象的销毁就是这棵树的销毁过程，必须要使用深度优先的算法来销毁。关于zmq对象树在Internal Architecture of libzmq有详细讲解
⑥、tcp_connector_t，zmq_socket的连接器，使用她来建立tcp连接
⑦、tcp_listener_t，zmq_socket的监听器
⑧、stream_engine，负责处理io事件中的一种----网络事件，把网络字节流转换成zeromq的msg_t消息传递给session_base_t。另外一些和版本兼容相关的杂务也stream_engine处理的。stream_engine_t处理完杂务，到session_base_t就只看见msg_t了。
⑨、session_base_t，管理zmq_socket的连接和通信，主要与engine进行交换
⑩、socket_base_t，zeromq的socket，在zmq中，被当成一种特殊的”线程“，具有收发命令的功能
参考资料
Internal Architecture of libzmq