零消息隊(duì)列通信的讀寫(xiě)器配置模塊設(shè)計(jì)

，

(天津科暢慧通信息技術(shù)有限公司，天津 300399)

引 言

射頻識(shí)別系統(tǒng)包括標(biāo)簽和讀寫(xiě)器。讀寫(xiě)器一般有1～4個(gè)天線端口，天線的工作頻率、功率，空口協(xié)議所使用的前反向速率、編碼方式、調(diào)制方式以及讀寫(xiě)器的IP地址、ntp同步服務(wù)器等都需要在客戶端配置。這些配置信息存儲(chǔ)在讀寫(xiě)器Flash或者EEPROM上，因此配置模塊是讀寫(xiě)器設(shè)計(jì)的一個(gè)重要模塊。

當(dāng)前讀寫(xiě)器和客戶端通信通常使用TCP/IP Socket通信，讀寫(xiě)器內(nèi)部配置模塊和其他業(yè)務(wù)模塊之間的通信通常采用消息隊(duì)列、管道等進(jìn)程間通信實(shí)現(xiàn)。這樣配置模塊和其他模塊之間的耦合性很強(qiáng)，并且配置模塊要管理來(lái)自不同內(nèi)部模塊和客戶端的消息，處理起來(lái)相對(duì)復(fù)雜，給模塊的設(shè)計(jì)帶來(lái)了一定難度。

ZMQ看起來(lái)像是一套嵌入式的網(wǎng)絡(luò)鏈接庫(kù)，但工作起來(lái)更像是一個(gè)并發(fā)式的框架。它提供的套接字可以在多種協(xié)議中傳輸消息(如線程間、進(jìn)程間、TCP、廣播等)，也可以使用套接字構(gòu)建多對(duì)多的連接模式(如扇出、發(fā)布-訂閱、任務(wù)分發(fā)、請(qǐng)求-應(yīng)答等)。ZMQ的快速足以勝任集群應(yīng)用產(chǎn)品，它的異步I/O機(jī)制支持構(gòu)建多核應(yīng)用程序，完成異步消息處理任務(wù)。ZMQ支持多語(yǔ)言，并能在幾乎所有的操作系統(tǒng)上運(yùn)行。讀寫(xiě)器配置模塊使用ZMQ作為消息通信的方式，能夠很好地解決上面的各種問(wèn)題，降低開(kāi)發(fā)難度，適用于各種嵌入式開(kāi)發(fā)環(huán)境。

1 ZMQ模式介紹

1.1 請(qǐng)求/應(yīng)答模式(REP/REQ)

圖1 請(qǐng)求/應(yīng)答模式

如圖1所示，請(qǐng)求/應(yīng)答模式特征如下：①服務(wù)器使用REP類型套接字而客戶端使用REQ類型套接字；②客戶端發(fā)送請(qǐng)求和接收答復(fù)，而服務(wù)器則接收請(qǐng)求并發(fā)送答復(fù)；③客戶端可以連接到一個(gè)或多個(gè)服務(wù)器，在這種情況下，請(qǐng)求會(huì)在所有的服務(wù)器(Reps)之間循環(huán)，一個(gè)請(qǐng)求被發(fā)送到某個(gè)服務(wù)器，下一個(gè)請(qǐng)求則被發(fā)送到下個(gè)服務(wù)器，如此進(jìn)行下去；④客戶端在發(fā)送另一個(gè)請(qǐng)求之前，必須先接收前一個(gè)請(qǐng)求的答復(fù)，而服務(wù)器在接收另一個(gè)請(qǐng)求之前，必須答復(fù)前一個(gè)請(qǐng)求。

1.2 發(fā)布/訂閱模式(PUB/SUB)

如圖2所示，發(fā)布/訂閱模式特征如下：①發(fā)布者使用PUB類型套接字，訂閱者則使用SUB類型套接字；②一個(gè)發(fā)布者可以有一個(gè)或者多個(gè)訂閱者；③一個(gè)訂閱者可以連接到一個(gè)或者多個(gè)發(fā)布者；④發(fā)布者發(fā)送消息而訂閱者接收消息；⑤訂閱者可以使用SubscribeAll方法訂閱所有的發(fā)布者消息，也可以使用Subscrube方法訂閱某個(gè)特定的消息，這時(shí)要將所感興趣的發(fā)布者消息前綴作為參數(shù)，對(duì)消息的過(guò)濾發(fā)生在訂閱者端，即發(fā)布者將其所有的消息發(fā)送給訂閱者，而訂閱者負(fù)責(zé)將不需要的消息丟棄；⑥訂閱者可以用UnsubscribeAll方法取消所有訂閱，也可以使用Unsubscribe方法加上消息前綴來(lái)退訂某個(gè)發(fā)布者；⑦發(fā)布者將消息發(fā)送到已連接的所有訂閱者；⑧如果發(fā)布者沒(méi)有和任何訂閱者連接，那么消息將會(huì)被丟棄；⑨如訂閱者連接到多個(gè)發(fā)布者，那么它會(huì)均勻接收所有發(fā)布者的消息(公平隊(duì)列)。

圖2 發(fā)布/訂閱模式

2 配置模塊設(shè)計(jì)

2.1 配置模塊作用

配置模塊接收客戶端下發(fā)的配置消息，并將配置信息保存到讀寫(xiě)器的Flash或者EEPROM中，并通知讀寫(xiě)器內(nèi)部模塊(比如通信模塊、業(yè)務(wù)模塊)配置變更，并將配置信息傳遞給讀寫(xiě)器內(nèi)部模塊，其在接收到配置變更消息后，處理該模塊的配置信息，更新配置。此外，讀寫(xiě)器內(nèi)部模塊可以主動(dòng)向配置模塊請(qǐng)求該模塊配置。

2.2 ZMQ模式考慮

讀寫(xiě)器配置模塊和客戶端之間的消息是配置下發(fā)消息和配置獲取消息，讀寫(xiě)器收到客戶端消息后，會(huì)返回響應(yīng)消息，因此可以采用REP/REQ模式。讀寫(xiě)器內(nèi)部模塊和配置模塊之間的消息包括內(nèi)部模塊向配置模塊獲取配置消息，以及配置模塊收到客戶端的配置信息后，將配置信息下發(fā)給讀寫(xiě)器其他模塊的消息。讀寫(xiě)器其他模塊向配置模塊獲取配置消息可以采用REP/REQ模式和一問(wèn)一答的模式；配置模塊下發(fā)給讀寫(xiě)器其他模塊的配置變更消息可以采用PUB/SUB模式，其中配置模塊作為PUB端，其他模塊為SUB端。這樣不管讀寫(xiě)器內(nèi)部有多少模塊，只要訂閱了配置模塊的PUB消息，就能收到配置模塊下發(fā)的配置變更消息，獲取自己需要的配置。

在鏈路模式上，配置模塊應(yīng)該作為服務(wù)端，這樣無(wú)論是客戶端還是讀寫(xiě)器內(nèi)部模塊都能去鏈接配置模塊的端口號(hào)，配置模塊只需處理一個(gè)套接字上面的消息就能處理所有消息。

在鏈路協(xié)議上，配置模塊和客戶端之間只能采用TCP協(xié)議，這樣能保證消息的可靠性；在配置模塊和讀寫(xiě)器內(nèi)部其他模塊之間，既可以采用進(jìn)程間(線程間)消息通信，也可以采用TCP消息通信，在這里為了和后臺(tái)客戶端之間保持一致，配置模塊應(yīng)該采用TCP通信協(xié)議，這樣配置模塊只需綁定一個(gè)TCP端口就能夠處理所有模塊(客戶端或者閱讀器內(nèi)部模塊)發(fā)來(lái)的消息。

因此，配置模塊作為服務(wù)端應(yīng)該采用TCP通信協(xié)議與其他模塊進(jìn)行通信，采用ZMQ的REP和PUB模式，保證了最少的監(jiān)聽(tīng)套接字和發(fā)送套接字。

3 設(shè)計(jì)實(shí)現(xiàn)

3.1 客戶端和配置模塊消息交互

圖3 客戶端和配置模塊消息交互圖

如圖3所示,讀寫(xiě)器配置模塊為服務(wù)端，以REP模式綁定TCP協(xié)議一個(gè)端口，客戶端則以REQ模式去鏈接服務(wù)器。其中消息A是客戶端下發(fā)的配置消息或者請(qǐng)求配置消息，配置模塊在收到客戶端的消息后處理消息，并將配置響應(yīng)消息或者獲取配置響應(yīng)消息(圖中B消息)返回給客戶端。

3.2 配置模塊和讀寫(xiě)器內(nèi)部模塊消息交互

配置模塊和讀寫(xiě)器內(nèi)部模塊消息交互圖如圖4所示，其中A和B消息是配置模塊和讀寫(xiě)器內(nèi)部模塊之間的消息，此時(shí)配置模塊仍然作為服務(wù)端，采用ZMQ中的REP模式，讀寫(xiě)器內(nèi)部模塊作為客戶端，采用REQ模式。讀寫(xiě)器內(nèi)部模塊上電后或者需要查詢配置時(shí)，可以通過(guò)消息A下發(fā)配置查詢消息，配置模塊在收到查詢消息后，返回配置查詢響應(yīng)消息(即消息B)給讀寫(xiě)器內(nèi)部模塊。

圖4 配置模塊和讀寫(xiě)器內(nèi)部模塊消息交互圖

讀寫(xiě)器配置模塊在收到客戶端下發(fā)的配置消息后，會(huì)將讀寫(xiě)器配置信息存儲(chǔ)在設(shè)備的Flash或者EEPROM中，此時(shí)配置模塊應(yīng)該將配置變更消息通知讀寫(xiě)器內(nèi)部模塊。該通知消息是一對(duì)多消息，采用ZMQ中的PUB/SUB模式能較為簡(jiǎn)潔地實(shí)現(xiàn)該功能。此時(shí)配置模塊作為服務(wù)端，采用PUB模式；讀寫(xiě)器內(nèi)部模塊作為客戶端，采用SUB模式。配置模塊僅需一個(gè)套接字就能將變更消息通知讀寫(xiě)器其他內(nèi)部模塊，需要配置信息的讀寫(xiě)器內(nèi)部模塊只需訂閱配置模塊的消息就能收到配置變更消息。圖4中C消息就是配置模塊下發(fā)的配置變更消息，內(nèi)部模塊收到C消息后，獲取自己模塊所需的配置信息。

結(jié) 語(yǔ)