zmq 中的 cs 模式
zmq 中 的 网络编程,
server:
zmq_ctx_new 创建环境,即启动线程池,初始化一些结构体等等一些预备操作,,, zmq_socket 创建套接字,就是linux c 中 的socket, zmq_bind 绑定地址并对进行监听(linux c 中是 bind listen), 然后 我们就可以send , 和 recv , 在zmq 中是zmq_send, zmq_recv
或者 zmq_msg_send, zmq_msg_recv
其实现是使用的是epoll 模式, 对epoll的事件例如EPOLLIN , EPOLLOUT, EPOLLHUP 等等的一些事件进行监听
client:
zmq_ctx_new 创建环境 , zmq_socket 创建套接字, zmq_connect 发起连接, 如果我们需要对zmq中的一些事件进行监听, 则需要要zmq_socket_monitor 创建一个双向管道, 在linux c中的就是 socketpair() 进行创建, 我们可以在这个管道中recv, send , 然后会根据读取到的事件(该事件在最后),然后看看在套接字组上,发生了什么事情, 如果不需要,我们就可以对其进行接受,和发送了
但是, 在zmq 中, 套接字的类型, 不止是 SOCK_STREAM ,和SOCK_DGARA, 两种, zmq 中的套接字, 把这些细分了很多, 不同的模型中对send 和 recv 加了限制, 如果不按照其模式的要求来, 接受和发送消息会没有效果 .
请求-应答模型:(ZMQ_REQ)
该模型是被用作 从一个 客户端发送请求到一个或者是多个服务器,然后服务器对每个请求做出请求.
如果没有服务器存在,客户端会阻塞, 直到有一个服务器变成可用状态为止,其服务器操作是 zmq_recv, zmq_send.即交替使用
对于客户端来说,需要先send, 再 recv
ZMQ_REP 模式
该模式是客户端发送请求,到服务器, 服务器接受,并对其做出相应的处理
其使用时 先zmq_recv, 再 zmq_send.
该模式,一般用于服务器
ZMQ_DEALER 模型
该模型是对请求响应套接字的扩展, 每个消息的发送是通过轮询调度算法去实现. 其 send和 recv 是不受限制 的
ZMQ_STREAM 模型
该模式 对send, recv 不限制,.
ZMQ__PUB 模型
就是发送方, 该类型的套接字不能接受消息, 只能发送消息, 在zmq中没有实现该模式
的接收操作, zmq_recv不起作用,zmq_send 是起作用的.
ZMQ_SUB 模型
接受方, 与ZMQ_PUB连用, 不能发送消息, 只能接受消息,在zmq中没有实现该模式的
发送操作, 也就是zmq_send 是不起作用的.zmq_recv 是起作用的.
ZMQ_PAIR: 该套接字模型 , 类似于双向管道, 也就是linux c 中的socketpair(), 主要是用于进程间通信, 可以通过它来检测 zmq中的连接, 接受, 重连, 崩溃等等的一些事件.
以下是 zmq_event_t 的事件类型.
ZMQ_EVENT_CONNECTED
ZMQ_EVENT_CONNECT_DELAYED
ZMQ_EVENT_CONNECT_RETRIED
ZMQ_EVENT_LISTENING
ZMQ_EVENT_BIND_FAILED
ZMQ_EVENT_ACCEPTED
ZMQ_EVENT_ACCEPT_FAILED:ZMQ_EVENT_CLOSED
ZMQ_EVENT_CLOSE_FAILED
ZMQ_EVENT_DISCONNECTED: