<请求应答模式>
由请求端发起请求,然后等待回应端应答。一个请求必须对应一个回应,从请求端的角度来看是发-收配对,从回应端的角度是收-发对。跟一对一结对模型的区别在于请求端可以是1~N个。该模型主要用于远程调用及任务分配等。Echo服务就是这种经典模型的应用。
这种模式类似HTTP的webService
这里提供了一个说”word”的服务,服务端在等待请求,接收到请求后,回复world。
客户端发送“hello”后等待服务端的回复,如下图所示。
<发布订阅模式>
发布端单向分发数据,且不关心是否把全部信息发送给订阅端。如果发布端开始发布信息时,订阅端尚未连接上来,则这些信息会被直接丢弃。订阅端未连接导致信息丢失的问题,可以通过与请求回应模型组合来解决。订阅端只负责接收,而不能反馈,且在订阅端消费速度慢于发布端的情况下,会在订阅端堆积数据。该模型主要用于数据分发。这种模式类似于LabVIEW的产生事件、通知等形式。
范例提供了简单的发布者例子,如下所示。
订阅者:
<性能分析>
目前,市面上类似的产品不少,主要有4种:MSMQ(微软产品)、ActiveMQ(Java)、RabbitMQ(Erlang)、ZeroMQ(C++)。除ZeroMQ外,其它3款产品都是一个单独服务或者进程,需要单独安装和运行,且对环境有一定依赖。其中,MSMQ在非Windows平台下安装非常复杂,ActiveMQ需要目标机器上已经安装了Java,RabbitMQ需要Erlang环境。而ZeroMQ是以库的形式存在,由应用程序加载、运行即可。但是ZeroMQ仅提供非持久性的消息队列。
下图来自于Internet的性能测试数据。显示的是每秒钟发送和接受的消息数。整个过程共产生1百万条1K的消息,测试环境为Windows10。从测试数据可以看出,ZeroMQ的性能远远高于其它3个MQ。
但是测试数据仅供参考,因为缺少必须的环境参数和性能指标,比如:CPU参数、内存参数、消息模型、通信协议、极限时消耗CPU百分比、极限时消耗内存百分比等。
原文标题:基于LabVIEW的zeromq通信
文章出处:【微信公众号:LabVIEW逆向工程高级编程】欢迎添加关注!文章转载请注明出处。
责任编辑:haq
全部0条评论
快来发表一下你的评论吧 !