1 引言

　　目前,，全國很多城市的路燈監(jiān)控系統(tǒng)" title="監(jiān)控系統(tǒng)">監(jiān)控系統(tǒng)受到區(qū)域限制，仍停留在小規(guī)模的監(jiān)控模式上,，使得各地區(qū)的監(jiān)控標(biāo)準(zhǔn)不統(tǒng)一,，管理混亂，同時也占用了大量的人力和物力資源,。因此,，將各區(qū)域的路燈監(jiān)控系統(tǒng)進行統(tǒng)一的管理，形成一個大規(guī)模的統(tǒng)一的監(jiān)控體系,， 已成為將來路燈監(jiān)控發(fā)展的趨勢,。傳統(tǒng)的SOCKET 通信模型" title="通信模型">通信模型有著客戶端數(shù)量的限制，當(dāng)實際的客戶端超過限制,，將會出現(xiàn)數(shù)據(jù)阻塞和丟失,，甚至是服務(wù)器軟件崩潰的情況，而引入了完成端口技術(shù)的通信模型沒有客戶端數(shù)量的限制,，并且擁有著高效的數(shù)據(jù)處理能力,，能夠在大規(guī)模路燈監(jiān)控系統(tǒng)內(nèi)發(fā)揮優(yōu)勢，保障了數(shù)據(jù)傳輸?shù)母咝院涂煽啃浴?/p>

　　在Visual C++ 2008 編程環(huán)境下,，通過完成端口技術(shù)的應(yīng)用,，將原有的基于C / S 模式的路燈監(jiān)控系統(tǒng)軟件進行優(yōu)化，使得整套系統(tǒng)可以應(yīng)用于大數(shù)量客戶端的場合,，并且仍能保持通信系統(tǒng)較高的穩(wěn)定性,。

　　2 監(jiān)控系統(tǒng)軟件的總體構(gòu)架

　　路燈監(jiān)控系統(tǒng)分為遠(yuǎn)程終端設(shè)備和監(jiān)控軟件兩個部分。遠(yuǎn)程終端設(shè)備安裝在路燈控制現(xiàn)場,，是實現(xiàn)監(jiān)控功能的主要硬件設(shè)備,。遠(yuǎn)程終端通過GPRS無線通信網(wǎng)絡(luò)與服務(wù)器相連，根據(jù)用戶的設(shè)置參數(shù),，實現(xiàn)定時開關(guān)燈,，采集數(shù)據(jù)和事故報警等功能。

　　根據(jù)不同地區(qū)的情況,，其數(shù)量可能非常的龐大,，傳輸?shù)椒?wù)器的數(shù)據(jù)量也會非常龐大。監(jiān)控軟件是一套在Visual C + + 2008 開發(fā)平臺下,， 基于Client /Server 模式的網(wǎng)絡(luò)通信軟件,，由服務(wù)端" title="服務(wù)端">服務(wù)端軟件和客戶端軟件兩個部分組成， 后臺數(shù)據(jù)庫選用MS SQLServer 2005,。監(jiān)控系統(tǒng)結(jié)構(gòu)圖如圖1 所示,。

圖1 系統(tǒng)結(jié)構(gòu)圖

　　監(jiān)控軟件的服務(wù)端安裝并工作于服務(wù)器上,，負(fù)責(zé)接收監(jiān)控終端設(shè)備傳輸而來的數(shù)據(jù)，對數(shù)據(jù)進行分析,，并存入數(shù)據(jù)庫; 同時與軟件的客戶端進行通信,，并且將軟件客戶端的指令數(shù)據(jù)，轉(zhuǎn)發(fā)到相應(yīng)的監(jiān)控終端設(shè)備,，對被監(jiān)控對象的進行管理與控制,。

　　監(jiān)控軟件的客戶端工作在用戶電腦上，通過網(wǎng)絡(luò)與服務(wù)端和數(shù)據(jù)庫相連,，為少數(shù)特定的路燈監(jiān)控管理員提供服務(wù),。客戶端為這些管理員用戶提供了一個功能齊全的圖形界面,。用戶可以通過客戶端查詢數(shù)據(jù),，發(fā)送控制指令，也可以通過客戶端的電子地圖功能和柜體監(jiān)控動畫實時的了解各個遠(yuǎn)程終端的工作狀態(tài),。

　　3 服務(wù)端完成端口通信模型的實現(xiàn)

　　3. 1 完成端口原理

　　3. 1. 1 完成端口簡介

　　網(wǎng)絡(luò)通信模塊是整個系統(tǒng)最核心的部分，由于要負(fù)責(zé)大規(guī)模的數(shù)據(jù)傳輸與處理,，因此對軟件的性能的高效性提出了挑戰(zhàn),，而完成端口通信技術(shù)的應(yīng)用解決了這一難題。

　　完成端口( I /O Completion Port ) 是一個Windows NT 執(zhí)行子系統(tǒng)的核心對象,。通過將完成端口與任意I /O 句柄( 文件或Socket 等) 關(guān)聯(lián),，使得用戶可以通過完成端口，異步的獲取并處理I /O 的結(jié)果,。

　　完成端口是由系統(tǒng)直接提供并行優(yōu)化支持的,，在完成端口上建立幾個并行的服務(wù)線程，一般數(shù)量為CPU 數(shù),，它們?yōu)榈竭_(dá)完成端口的服務(wù)請求提供服務(wù),。當(dāng)有服務(wù)請求到達(dá)時，如果有可用的服務(wù)線程,，則激活該線程,，如果沒有可用服務(wù)線程，則將服務(wù)請求加入請求隊列,，該隊列采用先進先出( FIFO)的策略,，來保證這些請求得到公平的服務(wù)。服務(wù)線程的建立和請求隊列的FIFO 策略,，減少了CPU 在不同線程間切換的次數(shù),，降低線程上下文切換所造成的開銷。

　　3. 1. 2 重疊I /O

　　完成端口的設(shè)計原理是讓應(yīng)用程序使用重疊的數(shù)據(jù)結(jié)構(gòu),，一次投遞一個或多個I /O 請求,，當(dāng)這些請求完成后,，應(yīng)用程序可以為他們提供服務(wù)。這就要求我們在使用完成端口時必須要使用重疊I /O,。

　　重疊I /O,，即當(dāng)I /O 功能調(diào)用時，不論I /O 是否完成,，函數(shù)馬上返回,，由操作系統(tǒng)底層處理I /O 的實際工作，而應(yīng)用程序( 進程) 可以繼續(xù)做其他事情,。因而,，完成端口是處理完成重疊I /O 的一種高效的機制。

　　3. 1. 3 工作線程

　　除了工作在完成端口上的服務(wù)線程外,，在關(guān)聯(lián)套接字之前,，還必須創(chuàng)建一個或多個工作線程，以便在I /O 請求投遞給完成端口對象后,，為完成端口提供服務(wù),。工作線程的個數(shù)取決于應(yīng)用程序的總體設(shè)計情況。創(chuàng)建的工作線程由完成端口管理,。當(dāng)有I /O 完成通知到來,，則由完成端口喚醒一個工作線程接收I /O 完成通知，并對其進行處理,。完成端口自動對工作線程進行調(diào)度,，喚醒哪個工作線程則由完成端口決定。若無I /O 完成通知,，則所有的工作線程都在等待,。根據(jù)經(jīng)驗，工作線程的數(shù)量一般為CPU 數(shù)量的兩倍再加上2,。

　　3. 2 完成端口的程序?qū)崿F(xiàn)

　　網(wǎng)絡(luò)通信模塊通過CreateIoCompletionPort 函數(shù)創(chuàng)建完成端口對象,，并將接收到的socket 對象與完成端口關(guān)聯(lián)， 啟動一定數(shù)量的工作線程,， 通過GetQueuedCompletionStatus 函數(shù)獲取完成端口上SOCKET 的當(dāng)前狀態(tài),，并將收到的數(shù)據(jù)從緩存出取出。完成端口的主要工作流程圖如圖2 所示,。

圖2 完成端口模塊流程圖

　　主線程：

　　1) 程序啟動的時候,，初始化網(wǎng)絡(luò)并且創(chuàng)建完成端口句柄：

　　CompletionPort = CreateIoCompletionPort ( INVALID_ HANDLE_ VALUE，NULL,，0,，0)；

　　2) 啟動2* N + 2 個工作線程,，N 為CPU 數(shù)量：

　　3) 進入一個*循環(huán),，開始*客戶端連接請求,；

　　4) 將接收到的客戶端SOCKET 與完成端口對象綁定；

　　5) 發(fā)出一個異步的WSARecv 或是WSASend 操作,，實際的接收和發(fā)送數(shù)據(jù)操作會由操作系統(tǒng)完成,。

　　6) 重復(fù)以上3) 到5) 的操作。

　　工作線程：

　　1) 進入循環(huán),， 通過GetQueuedCompletionStatus函數(shù),， 從完成端口上取得WSASend /WSARecv 的操作結(jié)果：

　　2) 根據(jù)完成端口上I /O 狀態(tài)， 進行數(shù)據(jù)的處理;

　　3) 提交一個新的WSASend /WSARecv 操作請求;

　　4) 重復(fù)以上1) 到4) 的操作,。

　　3. 3 通信規(guī)約設(shè)計

　　整個監(jiān)控系統(tǒng)采用TCP ( Transmission ControlProtocol,，傳輸控制協(xié)議) 進行數(shù)據(jù)傳輸，在此基礎(chǔ)上設(shè)計了一套監(jiān)控系統(tǒng)規(guī)約,，來完成服務(wù)端與遠(yuǎn)程終端,，服務(wù)端與客戶端的通信。根據(jù)路燈監(jiān)控的實際需求,，數(shù)據(jù)報文包括以下幾種形式,。

　　1) 遠(yuǎn)程終端主動向軟件服務(wù)端發(fā)送的連接認(rèn)證數(shù)據(jù)報文，如表1 所示,。

表1 連接認(rèn)證數(shù)據(jù)報文格式

　　2) 遠(yuǎn)程終端定時向軟件服務(wù)端發(fā)送的現(xiàn)場數(shù)據(jù)報文,，主要包括路燈監(jiān)控現(xiàn)場采集到的電流，電壓,，溫度，開關(guān)狀態(tài),，報警信息等數(shù)據(jù)信息,，如表2 所示。

　　3) 軟件客戶端發(fā)送給服務(wù)端,， 并由服務(wù)端轉(zhuǎn)發(fā)到相應(yīng)遠(yuǎn)程終端的參數(shù)設(shè)置報文,，根據(jù)不同的功能號，報文發(fā)送不同的參數(shù)信息,，包括開關(guān)燈時間,，報警閥值，數(shù)據(jù)采集周期等如表3 所示,。

表2 現(xiàn)場數(shù)據(jù)報文

表3 參數(shù)設(shè)置報文

　　3. 4 完成端口通信的優(yōu)化

　　3. 4. 1 內(nèi)存池的設(shè)計

　　完成端口模型采用異步通信模式,， 每次調(diào)用WSASend 和WSARecv 函數(shù)都需要在內(nèi)存創(chuàng)建一個結(jié)構(gòu)體空間，函數(shù)調(diào)用完畢后,，再銷毀這個結(jié)構(gòu)體空間,。頻繁的創(chuàng)建和銷毀內(nèi)存空間占用了大量的系統(tǒng)資源，因此,，在設(shè)計完成端口程序時,，根據(jù)需求創(chuàng)建一定數(shù)量的結(jié)構(gòu)體空間,，并將其放入一個統(tǒng)一的空閑隊列，當(dāng)調(diào)用WSASend 和WSARecv 函數(shù)時,，從隊列中取用一個結(jié)構(gòu)體空間,，使用完畢，再將其放回隊列,。

　　3. 4. 2 連接池的設(shè)計

　　當(dāng)用傳統(tǒng)的accept 函數(shù)接收客戶端時,，accept函數(shù)會創(chuàng)建一個socket 作為返回值，分配給客戶端,。

　　客戶端斷開連接時,，創(chuàng)建的socket 會被銷毀。創(chuàng)建和銷毀socket 的過程會占用大量的系統(tǒng)資源,，因此在接收客戶端時,， 采用acceptEx 函數(shù)代替accept，該函數(shù)可以把一個事先創(chuàng)建好的socket 對象,，分配給接收到的客戶端,。首先， 創(chuàng)建好一定數(shù)量的socket 對象,，形成一個連接池,，當(dāng)接收到客戶端的連接請求時，從連接池中取出空閑socket 對象,，分配給該客戶端,，斷開連接時，再將socket 放回連接池隊列,。連接池的設(shè)計減少了客戶端SOCKET 的不斷創(chuàng)建與銷毀,，節(jié)省了大量的系統(tǒng)資源。

　　3. 4. 3 線程池的設(shè)計

　　完成端口本身就應(yīng)用了線程池技術(shù),，線程池中的線程不僅包括了工作者線程,，還包括了工作上完成端口上的服務(wù)線程。有效的對這些線程進行管理,，能夠減少CPU 在不同線程間的頻繁切換,，降低了切換線程上下文所耗費的時間。

　　3. 4. 4 數(shù)據(jù)池的設(shè)計

　　完成端口模塊接收到的數(shù)據(jù),，要根據(jù)通信規(guī)約進行處理與分析,，并將數(shù)據(jù)存儲到相應(yīng)的數(shù)據(jù)庫中。

　　由于完成端口網(wǎng)絡(luò)通信的數(shù)據(jù)傳輸總是不平穩(wěn)的,，常常會出現(xiàn)短時間內(nèi)接收到大量數(shù)據(jù),，而另一段時間內(nèi)只接收到少量數(shù)據(jù)要的情況。為了防止服務(wù)器在短時間內(nèi)超負(fù)荷工作,，造成的數(shù)據(jù)意外丟失或是程序崩潰的情況,，在進行數(shù)據(jù)處理時,，預(yù)先建立了數(shù)據(jù)存儲隊列，形成一個數(shù)據(jù)池,，將未處理的數(shù)據(jù)加入隊列,， 并采用FIFO 的策略來分配CPU 時間，這就使得CPU 資源得到充分的利用,，提高了數(shù)據(jù)處理的安全性和可靠性,。

　　4 客戶端軟件設(shè)計

　　客戶端軟件通過一般的SOCKET 通信方式與服務(wù)器相連，主要是功能是為用戶提供一個簡潔,，便利的用戶功能界面,。地圖顯示模塊通過對GIS 電子地圖的繪制，將城市地圖及路燈系統(tǒng)的分布圖直觀的顯示給用戶,，使得用戶能夠大體的了解到整個路燈系統(tǒng)的運行狀態(tài),。動畫顯示模塊通過FLASH 編程技術(shù)，將單個遠(yuǎn)程終端所控制的配電柜示意圖展示給用戶,，用戶可以了解到現(xiàn)場的實時數(shù)據(jù)并對具體的監(jiān)控點進行設(shè)置,，開關(guān)燈等操作。數(shù)據(jù)顯示模塊與數(shù)據(jù)庫相連,，用戶可以查詢到各個監(jiān)控點的歷史數(shù)據(jù)以及當(dāng)前的設(shè)置參數(shù),，了解路燈系統(tǒng)的具體工作狀態(tài)。軟件客戶端主界面如圖3 所示,。

圖3 客戶端軟件主界面

　　5 完成端口服務(wù)器軟件的性能測試

　　5. 1 測試對象

　　完成端口通信模型與傳統(tǒng)通信模型相比,，擁有更大的數(shù)據(jù)吞吐量和客戶端數(shù)目，并且通過線程池,、連接池,、內(nèi)存池的設(shè)計和應(yīng)用，節(jié)省了系統(tǒng)資源,，提高了服務(wù)器軟件的數(shù)據(jù)處理效率。在對傳統(tǒng)通信模型和完成端口通信模型的性能測試和比較中,，選取饑餓的客戶端和每秒線程上下文切換次數(shù)兩個重要指標(biāo)為測試對象,。饑餓的客戶端定義為同一時間向服務(wù)器申請連接并發(fā)送數(shù)據(jù)的客戶端中，未被服務(wù)器影響的客戶端數(shù),。

　　5. 2 測試環(huán)境

　　選用兩臺Intel Core2 1. 9GHz 雙核CPU,，2G 內(nèi)存臺式機，一臺用作服務(wù)器電腦,，一臺用作客戶端電腦,。服務(wù)器電腦上分別安裝傳統(tǒng)通信模型的舊版路燈監(jiān)控軟件和完成端口模型的新版路燈監(jiān)控軟件，并且在軟件程序中加入測試代碼,，用來計算饑餓客戶端數(shù)目和線程上下文的切換次數(shù); 客戶端電腦上用測試軟件來模擬一定數(shù)量的終端設(shè)備的客戶端,，并向服務(wù)器同時進行連接和發(fā)送數(shù)據(jù)的操作,。

　　5. 3 測試結(jié)果及分析

　　不斷的改變模擬客戶端的數(shù)量，對兩種通信模型進行測試,，分別記錄下兩種模型在不同數(shù)量的客戶端下,，饑餓客戶端數(shù)量和線程上下文切換的次數(shù)，重復(fù)多次測試,，取得多組數(shù)據(jù),，取其平均值。

　　如表4 所示,，當(dāng)模擬客戶端數(shù)目逐漸增加時,，傳統(tǒng)通信模型的饑餓客戶端數(shù)量也不斷增加，這就使得大量的客戶端無法得到服務(wù)器響應(yīng),，大量客戶端的數(shù)據(jù)無法傳輸,，導(dǎo)致數(shù)據(jù)的阻塞和丟失。而完成端口通信模型采取了一系列的優(yōu)化策略,，并不存在客戶端無法得到服務(wù)的情況,。

　　如表5 所示，在模擬客戶端數(shù)量較少時,，兩種通信模型的線程上下文切換次數(shù)相當(dāng); 當(dāng)模擬客戶端數(shù)量增加時,，傳統(tǒng)通信模型的切換次數(shù)劇增，而每次的切換都會導(dǎo)致系統(tǒng)資源的額外開銷,，這就使的傳統(tǒng)通信模型的數(shù)據(jù)處理效率十分低下,。使用完成端口通信模型時，線程上下文切換次數(shù)并未隨著模擬客戶端的增加而產(chǎn)生更大的變化,，因此完成端口模型更適合于大量客戶端的應(yīng)用場合,，并且仍可保持的數(shù)據(jù)通信的可靠性和高效性。

表4 饑餓客戶端測試

表5 每秒線程上下文切換次數(shù)

　　6 結(jié)束語

　　完成端口技術(shù)的引入,， 充分發(fā)揮了服務(wù)器多CPU 的優(yōu)勢,，使得整個監(jiān)控系統(tǒng)的數(shù)據(jù)通信性能得到了極大的優(yōu)化了。經(jīng)過壓力測試,，當(dāng)監(jiān)控終端設(shè)備數(shù)量達(dá)5000 時,，系統(tǒng)仍然能夠保持高效、穩(wěn)定的運行,。目前該系統(tǒng)應(yīng)用于廈門路橋公司,，龍巖長汀等地的路燈控制，取得了良好的效果,。