ZMQ通信模式

 

请求响应模式

常规搭配：ZMQ_REQ + ZMQ_REP
	
带输入负载(Round Robin)均衡搭配：ZMQ_REQ + ZMQ_ROUTER
	
消息分发搭配：ZMQ_ROUTER + ZMQ_DEALER
	
带输出负载(load-balance)均衡搭配：ZMQ_DEALER + ZMQ_REP
ZMQ_REQ模式在发送消息时，ZMQ底层会在消息内容头部插入一个空帧，在接收消息时，会去掉空帧，将内容返回给应用层。

ZMQ_REP模式在接收消息时，会将消息空帧之前的信封帧保存起来，将空帧之后的内容传给上层应用。上层应用在响应消息时，底层会在响应消息前加上空帧以及对应请求的信封帧。

ZMQ_ROUTER模式在接收消息时，ZMQ底层会在消息头部添加上一个信封帧，用于标记消息来源。该信封帧可由发送端指定（调用zmq_setsockopt(ZMQ_IDENTITY)），也可由接收端自动生成唯一标识作为信封帧。在发送消息时，将信封帧之后的内容发送到以信封帧为标识的地址。

ZMQ_DEALER模式，对接收到的消息公平排队fair-queue，以Round-Robin方式发送消息。

发布订阅模式

ZMQ_SUB <-- ZMQ_PUB

任务管道模式

ZMQ_PUSH -> [ ZMQ_PULL , ZMQ_PUSH] --> ZMQ_PULL

一对一通信

ZMQ_PAIR <--> ZMQ_PAIR

1. 实验1
    1.1 安装zmq在ubuntu虚拟机上
        1.1.1 下载，./autogen.h   ./configure   ./make   ./sudo make install ，生成到动态链接库默认安装目录是  /usr/local/lib/，头文件包含在 /usr/local/include/zmq.h
    1.2 编辑helloworldserver.c 和 helloworldclient.c
    1.3  分别编译 gcc -o hws -lzmq helloworldserver.c 以及 gcc -o hwc -lzmq helloworldclient.c 生成 hws 和 hwc
    1.4  运行抓包软件 wireshark ： sudo wireshark,打开监听 lo 回环端口（因为server 和 client 都绑定在本地lo端口）
    1.5 先运行 ./hws ，然后运行 ./hwc ，可以看到 wireshark 抓到了 127.0.0.1 到 127.0.0.1 的数据
（元代马和编译后的hws\hwc都在附件 helloworld.tar.gz）
 
发现问题： 实验是让 hwc 发‘hello’给 hws,后者接到后发送'world'给前者，但是，wireshark 抓到的数据根本看不出来'hello'或者'world'，有可能是zmq传输数据时不是原文来着。
 
2. 实验2
    2.1 开启一个 hws ，同时开启多个 hwc,发现所有终端正常工作
    2.2 开启一个hwc,同时开启多个 hws，发现只有一个 hws 响应hwc(最先启动的那个)
    2.3 先开启 hwc,hwc终端界面在发了第一个数据后停在，然后开启hws,发现hwc和hws 都正常工作了
 
对于2.3 ，说明zmq内部有‘延迟’机制，可以在客户端比服务端先开启的情况下也正常工作，wireshark抓包分析，hwc一直在给127.0.0.1:5555端口发连接请求，但一直收到<RST,ACK>，表明这是localhost的 5555 端口还没有开启。因为代码设定的模式是S-C模式，使用TCP连接，所以wireshark结果符合我们的理解。2.1说名一个服务段可以同时为多个客户端提供服务。2.2 说明 zmq 内部对多个服务端可能造成混乱的情况做了处理，究竟什么策略，还要再看
 
 
3. 实验3
3.1 使用模式 Pub-Sub，分发-订购 ，S-C 模式下服务器绑定一个端口并监听，可以在该端口收和发数据，客户端连接服务器端口，也可以在连接上收和发数据。Pub-Sub模式下publisher 分发器绑定一个端口并分发信号，不能接受信号，subscriber 连接某个pub并接收信号，不能发送信号。 代码 wuserver.c 和 wuclient.c ，实现了pub一直分发代表天气信息的数据，sub 接收自己需要的数据（使用过滤器），代码在 weatherup.tar.gz
3.2 单独运行./wus ，抓包发现，没有任何连接数据，表明分发器在没有与任何订阅者建立连接之前，不会产生网络流量。
3.3 单独运行 ./wuc,发现sub一直往 127.0.0.1：5556 发送 SYN 信号请求建立连接，这点跟 2.3 一致。
3.4 先运行 ./ wus ，再运行 ./wuc，pub 和 sub 建立TCP连接，然后有了数据交流，从包里依然看不出是什么数据（加密了！）
3.4 运行多个 wuc(不同过滤条件)，发现它们只打印自己过滤后的数据。根据文档说明，P-S的过滤是在sub段，所以每个Sub都可以接收所有数据，然后通过过滤器取所需数据
 

ZMQ 第一章 ZeroMQ基础 

https://blog.csdn.net/zzhongcy/article/details/19810553

 

ZMQ 第二章 ZeroMQ进阶

https://blog.csdn.net/zzhongcy/article/details/19811825

 

ZMQ 第三章 高级请求-应答模式

https://blog.csdn.net/zzhongcy/article/details/19812569

 

ZMQ 第四章 可靠的请求-应答模式

https://blog.csdn.net/zzhongcy/article/details/19813403

 

ZMQ 第五章 高级发布-订阅模式

https://blog.csdn.net/zzhongcy/article/details/19813825

 

ZeroMQ研究与应用分析

https://blog.csdn.net/zzhongcy/article/details/19814133

 

ZMQ性能测试

https://blog.csdn.net/zzhongcy/article/details/88352223

历史告诉我们，ZMQ 2.0是一个低延迟的分布式消息系统，它从众多同类软件中脱颖而出，摆脱了各种奢华的名目，向世界宣告“无极限”的口号。这是我们一直在使用的稳定发行版。

时过境迁，2010年流行的东西在2011年就不一定了。当ZMQ的开发者和社区开发者在激烈地讨论ZMQ的种种问题时，ZMQ 2.1横空出世了，成为新的稳定发行版。

本指南主要针对ZMQ 2.1进行描述，因此对于从ZMQ 2.0迁移过来的开发者来说有一些需要注意的地方：


	
在2.0中，调用zmq_close()和zmq_term()时会丢弃所有尚未发送的消息，所以在发送完消息后不能直接关闭程序，2.0的示例中往往使用sleep(1)来规避这个问题。但是在2.1中就不需要这样做了，程序会等待消息全部发送完毕后再退出。
	
	

	
相反地，2.0中可以在尚有套接字打开的情况下调用zmq_term()，这在2.1中会变得不安全，会造成程序的阻塞。所以，在2.1程序中我们会先关闭所有的套接字，然后才退出程序。如果套接字中有尚未发送的消息，程序就会一直处于等待状态，除非手工设置了套接字的LINGER选项（如设置为零），那么套接字会在相应的时间后关闭。
	
	

	
int zero = 0;
zmq_setsockopt (mysocket, ZMQ_LINGER, &zero, sizeof (zero));
	

	
2.0中，zmq_poll()函数没有定时功能，它会在满足条件时立刻返回，我们需要在循环体中检查还有多少剩余。但在2.1中，zmq_poll()会在指定时间后返回，因此可以作为定时器使用。
	
	

	
2.0中，ZMQ会忽略系统的中断消息，这就意味着对libzmq的调用是不会收到EINTR消息的，这样就无法对SIGINT（Ctrl-C）等消息进行处理了。在2.1中，这个问题得以解决，像类似zmq_recv()的方法都会接收并返回系统的EINTR消息。
	
 

正确地使用上下文

ZMQ应用程序的一开始总是会先创建一个上下文，并用它来创建套接字。在C语言中，创建上下文的函数是zmq_init()。一个进程中只应该创建一个上下文。从技术的角度来说，上下文是一个容器，包含了该进程下所有的套接字，并为inproc协议提供实现，用以高速连接进程内不同的线程。如果一个进程中创建了两个上下文，那就相当于启动了两个ZMQ实例。如果这正是你需要的，那没有问题，但一般情况下：

在一个进程中使用zmq_init()函数创建一个上下文，并在结束时使用zmq_term()函数关闭它

如果你使用了fork()系统调用，那每个进程需要自己的上下文对象。如果在调用fork()之前调用了zmq_init()函数，那每个子进程都会有自己的上下文对象。通常情况下，你会需要在子进程中做些有趣的事，而让父进程来管理它们。

正确地退出和清理

程序员的一个良好习惯是：总是在结束时进行清理工作。当你使用像Python那样的语言编写ZMQ应用程序时，系统会自动帮你完成清理。但如果使用的是C语言，那就需要小心地处理了，否则可能发生内存泄露、应用程序不稳定等问题。

内存泄露只是问题之一，其实ZMQ是很在意程序的退出方式的。个中原因比较复杂，但简单的来说，如果仍有套接字处于打开状态，调用zmq_term()时会导致程序挂起；就算关闭了所有的套接字，如果仍有消息处于待发送状态，zmq_term()也会造成程序的等待。只有当套接字的LINGER选项设为0时才能避免。

我们需要关注的ZMQ对象包括：消息、套接字、上下文。好在内容并不多，至少在一般的应用程序中是这样：

处理完消息后，记得用zmq_msg_close()函数关闭消息；
	
如果你同时打开或关闭了很多套接字，那可能需要重新规划一下程序的结构了；
	
退出程序时，应该先关闭所有的套接字，最后调用zmq_term()函数，销毁上下文对象。
如果要用ZMQ进行多线程的编程，需要考虑的问题就更多了。我们会在下一章中详述多线程编程，但如果你耐不住性子想要尝试一下，以下是在退出时的一些建议：

不要在多个线程中使用同一个套接字。不要去想为什么，反正别这么干就是了。
	
关闭所有的套接字，并在主程序中关闭上下文对象。
	
如果仍有处于阻塞状态的recv或poll调用，应该在主程序中捕捉这些错误，并在相应的线程中关闭套接字。不要重复关闭上下文，zmq_term()函数会等待所有的套接字安全地关闭后才结束。
看吧，过程是复杂的，所以不同语言的API实现者可能会将这些步骤封装起来，让结束程序变得不那么复杂。