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

zeroMQ被稱之為"sockets on steroids"，該庫使得計算機之間通信極為簡單。zeroMQ通信協(xié)議具有跨平臺的統(tǒng)一通信標(biāo)準(zhǔn)?；?a target="_blank">LabVIEW的zeroMQ的發(fā)布，使得LabVIEW在不同語言之間，不同計算機之間無延時通信變得很容易。這個庫在windows 系統(tǒng)，32位和64位測試都是可以正常運行的，通過VIPM進行安裝。

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

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

這種模式類似HTTP的webService

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

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

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

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

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

訂閱者：

<性能分析>

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

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

但是測試數(shù)據(jù)僅供參考，因為缺少必須的環(huán)境參數(shù)和性能指標(biāo)，比如：CPU參數(shù)、內(nèi)存參數(shù)、消息模型、通信協(xié)議、極限時消耗CPU百分比、極限時消耗內(nèi)存百分比等。

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

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

責(zé)任編輯：haq