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

，

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

引 言

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

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

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

1 ZMQ模式介紹

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

圖1 請求/應答模式

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

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

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

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

2 配置模塊設計

2.1 配置模塊作用

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

2.2 ZMQ模式考慮

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

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

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

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

3 設計實現(xiàn)

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

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

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

3.2 配置模塊和讀寫器內部模塊消息交互

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

圖4 配置模塊和讀寫器內部模塊消息交互圖

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

結 語