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

，

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

引 言

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

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

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

1 ZMQ模式介紹

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

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

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

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

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

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

2 配置模塊設(shè)計

2.1 配置模塊作用

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

2.2 ZMQ模式考慮

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

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

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

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

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

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

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

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

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

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

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

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

結(jié) 語