基于LabVIEW的zeromq通信研究與應(yīng)用分析

zeroMQ被稱(chēng)之為"sockets on steroids"，該庫(kù)使得計(jì)算機(jī)之間通信極為簡(jiǎn)單。zeroMQ通信協(xié)議具有跨平臺(tái)的統(tǒng)一通信標(biāo)準(zhǔn)。基于LabVIEW的zeroMQ的發(fā)布，使得LabVIEW在不同語(yǔ)言之間，不同計(jì)算機(jī)之間無(wú)延時(shí)通信變得很容易。這個(gè)庫(kù)在windows 系統(tǒng)，32位和64位測(cè)試都是可以正常運(yùn)行的，通過(guò)VIPM進(jìn)行安裝。

<請(qǐng)求應(yīng)答模式>

由請(qǐng)求端發(fā)起請(qǐng)求，然后等待回應(yīng)端應(yīng)答。一個(gè)請(qǐng)求必須對(duì)應(yīng)一個(gè)回應(yīng)，從請(qǐng)求端的角度來(lái)看是發(fā)-收配對(duì)，從回應(yīng)端的角度是收-發(fā)對(duì)。跟一對(duì)一結(jié)對(duì)模型的區(qū)別在于請(qǐng)求端可以是1~N個(gè)。該模型主要用于遠(yuǎn)程調(diào)用及任務(wù)分配等。Echo服務(wù)就是這種經(jīng)典模型的應(yīng)用。

這種模式類(lèi)似HTTP的webService

這里提供了一個(gè)說(shuō)”word”的服務(wù)，服務(wù)端在等待請(qǐng)求，接收到請(qǐng)求后，回復(fù)world。

客戶(hù)端發(fā)送“hello”后等待服務(wù)端的回復(fù)，如下圖所示。

<發(fā)布訂閱模式>

發(fā)布端單向分發(fā)數(shù)據(jù)，且不關(guān)心是否把全部信息發(fā)送給訂閱端。如果發(fā)布端開(kāi)始發(fā)布信息時(shí)，訂閱端尚未連接上來(lái)，則這些信息會(huì)被直接丟棄。訂閱端未連接導(dǎo)致信息丟失的問(wèn)題，可以通過(guò)與請(qǐng)求回應(yīng)模型組合來(lái)解決。訂閱端只負(fù)責(zé)接收，而不能反饋，且在訂閱端消費(fèi)速度慢于發(fā)布端的情況下，會(huì)在訂閱端堆積數(shù)據(jù)。該模型主要用于數(shù)據(jù)分發(fā)。這種模式類(lèi)似于LabVIEW的產(chǎn)生事件、通知等形式。

范例提供了簡(jiǎn)單的發(fā)布者例子，如下所示。

訂閱者：

<性能分析>

目前，市面上類(lèi)似的產(chǎn)品不少，主要有4種：MSMQ（微軟產(chǎn)品）、ActiveMQ（Java）、RabbitMQ(Erlang)、ZeroMQ（C++）。除ZeroMQ外，其它3款產(chǎn)品都是一個(gè)單獨(dú)服務(wù)或者進(jìn)程，需要單獨(dú)安裝和運(yùn)行，且對(duì)環(huán)境有一定依賴(lài)。其中，MSMQ在非Windows平臺(tái)下安裝非常復(fù)雜，ActiveMQ需要目標(biāo)機(jī)器上已經(jīng)安裝了Java，RabbitMQ需要Erlang環(huán)境。而ZeroMQ是以庫(kù)的形式存在，由應(yīng)用程序加載、運(yùn)行即可。但是ZeroMQ僅提供非持久性的消息隊(duì)列。

下圖來(lái)自于Internet的性能測(cè)試數(shù)據(jù)。顯示的是每秒鐘發(fā)送和接受的消息數(shù)。整個(gè)過(guò)程共產(chǎn)生1百萬(wàn)條1K的消息，測(cè)試環(huán)境為Windows10。從測(cè)試數(shù)據(jù)可以看出，ZeroMQ的性能遠(yuǎn)遠(yuǎn)高于其它3個(gè)MQ。

但是測(cè)試數(shù)據(jù)僅供參考，因?yàn)槿鄙俦仨毜沫h(huán)境參數(shù)和性能指標(biāo)，比如：CPU參數(shù)、內(nèi)存參數(shù)、消息模型、通信協(xié)議、極限時(shí)消耗CPU百分比、極限時(shí)消耗內(nèi)存百分比等。

原文標(biāo)題：基于LabVIEW的zeromq通信

文章出處：【微信公眾號(hào)：LabVIEW逆向工程高級(jí)編程】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。

責(zé)任編輯：haq