一種cms前置機與服務器的通訊方法
【專利摘要】本發(fā)明公開了一種CMS前置機與服務器的通訊方法包括：步驟1：在服務器端創(chuàng)建監(jiān)聽CMS前置機連接線程，判斷是否有CMS前置機發(fā)起連接，是則執(zhí)行步驟2，否則繼續(xù)等待并繼續(xù)監(jiān)聽；步驟2：創(chuàng)建IOCP工作線程，接受連接，將套接字關(guān)聯(lián)在IOCP對象上；步驟3：判斷CMS前置機是否發(fā)送數(shù)據(jù)，是則執(zhí)行步驟4，否則執(zhí)行步驟5;步驟4：創(chuàng)建接收數(shù)據(jù)處理線程并進行處理，跳轉(zhuǎn)至步驟6；步驟5：創(chuàng)建掃描線程，負責在一定時間間隔查詢所有CMS前置機連接是否與服務器進行過通信，否則斷開無數(shù)據(jù)連接，重新發(fā)起連接，是則返回步驟5；步驟6：創(chuàng)建服務器端發(fā)送數(shù)據(jù)處理線程將配置和處理的結(jié)果數(shù)據(jù)發(fā)送到對應的CMS前置機。本方法提高CMS前置機的并行化接入數(shù)量，提高內(nèi)存使用效率，提高服務器資源的利用率。
【專利說明】—種CMS前置機與服務器的通訊方法
【技術(shù)領域】
[0001]本發(fā)明涉及一種CMS前置機與服務器的通訊方法，尤其涉及一種用于風力發(fā)電領域的CMS前置機與服務器的通訊方法。
【背景技術(shù)】
[0002]當前，國內(nèi)發(fā)展的風力發(fā)電機都是最近幾年建設的新能源，在運營的過程中出現(xiàn)了一些急需解決的問題，對風力發(fā)電機的振動故障進行監(jiān)測，對產(chǎn)生的故障進行實時的檢測，提前預知故障，提前備件，制定維修計劃，其中CMS(CMS Condition MonitoringSystem)前置機與服務器通信是實現(xiàn)這一目的必要條件。
[0003]要解決現(xiàn)場人員實時掌握風力發(fā)電機的健康狀況，需要在每臺風力發(fā)電機中安裝CMS前置機來與中控室的服務器進行實時的通信。對于服務器來說，風場的風力發(fā)電機少的上百臺，多的上千臺，關(guān)鍵是如何設計一個有效的服務器端來滿足CMS前置機的連接數(shù)量和流量使系統(tǒng)高效運行的要求。
[0004]現(xiàn)有技術(shù)主要存在以下技術(shù)缺點:
1.要設計一個高性能的服務器，關(guān)鍵是選擇一種適合于要求的網(wǎng)絡通信套接字I/O模型以及基于此模型建立一個高效的內(nèi)存模型，線程模型。在網(wǎng)絡通信方法中服務器端較為普遍的應用是，基于套接字I/o模型中最常見的select模型所采用的兩種模式:串行化或者并行化。串行化模式僅適用一個線程等待接收客戶端請求，當請求達到后，線程被喚醒處理請求，這種模式弊端在于無法同時處理多個客戶端的連接請求，顯然不符合服務器的設計要求。并行化模式則是用一個線程等待客戶端連接，每當?shù)絹硪粋€新的連接，該線程會創(chuàng)建一個新的工作線程去專門處理維護和新連接客戶端的通信。并行化模式可以同時與多個客戶端保持連接通信，但隨著客戶端數(shù)量的增加，工作線程也隨之增加，過多的工作線程會導致大量額外的環(huán)境切換(context switching),效率反而降低。在服務器端采用這種設計模式，單線程下默認最大CMS前置機連接數(shù)為64個，多線程模式下無法突破1000的瓶頸，因此該模型也難以滿足實際的運營要求。
[0005]2.由于客戶端的數(shù)量巨大，在服務器端申請內(nèi)存，系統(tǒng)需要根據(jù)算法在內(nèi)存空閑表中查找一塊空閑內(nèi)存，釋放內(nèi)存時，系統(tǒng)可能需要合并空閑內(nèi)存塊，這些會產(chǎn)生額外的開銷。在通信的過程中頻繁的申請和釋放內(nèi)存會產(chǎn)生大量的內(nèi)存碎片，從而降低程序的運行效率，還可能會造成內(nèi)存泄露。
[0006]3.在客戶端與服務器通信連接后，如長時間未進行數(shù)據(jù)交互，建立的socket連接不會主動斷開，如果系統(tǒng)長時間運行，會占用一定的系統(tǒng)資源，造成浪費，還可能影響其他需要與服務器進行交互的客戶端的連接。
[0007]4.為了能讓一個應用程序高效的同時，管理數(shù)量眾多的套接字，windows NT3.5引入了 10CP(I/0 Completion Port輸入輸出完成端口)模型,作為開發(fā)高性能服務器的最佳選擇。IOCP模型是一種能夠使多線程得到合理利用和管理的機制，其理論基礎是:并行運行的線程數(shù)量必須設置上限。如此可有效的避免線程數(shù)量過多時因進行環(huán)境切換所造成的CPU浪費。

【發(fā)明內(nèi)容】

[0008]本發(fā)明的目的是針對上述【背景技術(shù)】存在的缺陷，提供提供一種可避免線程數(shù)量過多時因進行環(huán)境切換所造成的CPU浪費，避免頻繁分配釋放內(nèi)存導致的內(nèi)存效率降低，最大化利用系統(tǒng)資源的CMS前置機與服務器的通訊方法。
[0009]為實現(xiàn)上述目的，本發(fā)明一種CMS前置機與服務器的通訊方法，包括:
步驟1:在服務器端創(chuàng)建監(jiān)聽CMS前置機連接線程，判斷是否有CMS前置機發(fā)起連接，是則執(zhí)行步驟2，否則繼續(xù)等待并繼續(xù)監(jiān)聽；
步驟2:創(chuàng)建IOCP工作線程，接受連接，將套接字關(guān)聯(lián)在IOCP對象上；
步驟3:判斷CMS前置機是否發(fā)送數(shù)據(jù)，是則執(zhí)行步驟4，否則執(zhí)行步驟5;
步驟4:創(chuàng)建接收數(shù)據(jù)處理線程并進行處理，跳轉(zhuǎn)至步驟6 ;
步驟5:創(chuàng)建掃描線程，負責在一定時間間隔查詢所有CMS前置機連接是否與服務器進行過通信，否則斷開無數(shù)據(jù)連接，重新發(fā)起連接，是則返回步驟5 ；
步驟6:創(chuàng)建服務器端發(fā)送數(shù)據(jù)處理線程將配置和處理的結(jié)果數(shù)據(jù)發(fā)送到對應的CMS前置機。
[0010]綜上所述，本發(fā)明一種CMS前置機與服務器的通訊方法提高CMS前置機的并行化接入數(shù)量，提高內(nèi)存使用效率，提高服務器資源的利用率。
【專利附圖】

【附圖說明】
[0011]圖1為本發(fā)明一種CMS前置機與服務器的通訊方法的簡要流程示意圖。
【具體實施方式】
[0012]為詳細說明本發(fā)明的技術(shù)內(nèi)容、構(gòu)造特征、所達成目的及效果，以下茲例舉實施例并配合附圖詳予說明。
[0013]請參閱圖1，本發(fā)明一種CMS前置機與服務器的通訊方法，該方法是基于IOCP模型，提出了一種CMS前置機與服務器通信的設計模型，該模型能夠滿足數(shù)量眾多的風電場的并發(fā)連接通信，并且CMS前置機的請求具有即時的處理響應，提高服務器的內(nèi)存效率，最大合理化的利用服務器的資源。
[0014]服務器程序，主要使用IOCP模型，來滿足眾多的CMS前置機的并發(fā)請求。然而，由于IOCP本身是開發(fā)大型服務器的一種網(wǎng)絡通信模型，在風力發(fā)電機中的CMS前置機與服務器通信中的模型中，不能完全按照IOCP模型實現(xiàn)服務器的方式來設計，基于此，本發(fā)明采取從CMS前端接收的數(shù)據(jù)和返回的結(jié)果請求投遞到IOCP對象上處理，向CMS前置機發(fā)送的配置數(shù)據(jù)則直接發(fā)送不再投遞。對于在一定時間內(nèi)未與服務器進行交互地連接，進行處理，提高資源利用。
[0015]本發(fā)明一種CMS前置機與服務器的通訊方法設計了獨立的線程協(xié)調(diào)工作來共同實現(xiàn)，分別是:
一個監(jiān)聽CMS前置機連接線程；
若干個IOCP工作線程(通常是CPU個數(shù)的兩倍左右)； 一個掃描線程；
一個接收數(shù)據(jù)處理線程；
一個發(fā)送數(shù)據(jù)處理線程。
[0016]具體的，所述監(jiān)聽CMS前置機連接線程具體的工作任務是:(一)創(chuàng)建IOCP對象，創(chuàng)建的對象就是被用來為大量接入的套接字管理其對應的I/O請求；(二)創(chuàng)建一個套接字，綁定在指定的端口上來循環(huán)監(jiān)聽接收CMS前置機的連接；(三)當新連接一個CMS前置機時，將新生產(chǎn)的套接字與創(chuàng)建的IOCP對象關(guān)聯(lián)起來。
[0017]所述IOCP的工作線程的工作任務是:負責循環(huán)等待并接收所有關(guān)聯(lián)在IOCP對象上的套接字完成的輸入和輸出事件。
[0018]所述掃描線程的工作任務是:每間隔一定的時間，掃描所有已經(jīng)建立的連接是否進行過數(shù)據(jù)交互，如無則關(guān)閉連接，等待CMS前置機重新連接。
[0019]所述接收數(shù)據(jù)處理線程的工作任務是:從內(nèi)存池中分配空間，將從IOCP工作線程中取的數(shù)據(jù)包進行解析，校驗數(shù)據(jù)完整性，按照不同的消息類型進行處理。
[0020]所述發(fā)送數(shù)據(jù)處理線程的工作任務是:判斷發(fā)送的數(shù)據(jù)類型，分別做出不同的發(fā)送請求，提高系統(tǒng)效率。
[0021]本發(fā)明中的一種用于CMS前置機與服務器的通信方法，包括以下步驟:
步驟1:在服務器端創(chuàng)建監(jiān)聽CMS前置機連接線程，判斷是否有CMS前置機發(fā)起連接，是則執(zhí)行步驟2，否則繼續(xù)等待并繼續(xù)監(jiān)聽；
步驟2:創(chuàng)建IOCP工作線程，接受連接，將套接字關(guān)聯(lián)在IOCP對象上；
步驟3:判斷CMS前置機是否發(fā)送數(shù)據(jù)，是則執(zhí)行步驟4，否則執(zhí)行步驟5;
步驟4:創(chuàng)建接收數(shù)據(jù)處理線程，并進行處理，跳轉(zhuǎn)至步驟6 ；
步驟5:創(chuàng)建掃描線程，負責在一定時間間隔查詢所有CMS前置機連接是否與服務器進行過通信，否則斷開無數(shù)據(jù)連接，重新發(fā)起連接，是則返回步驟5 ；
步驟6:創(chuàng)建服務器端發(fā)送數(shù)據(jù)處理線程將配置和處理的結(jié)果數(shù)據(jù)發(fā)送到對應的CMS前置機。
[0022]所述步驟4中利用內(nèi)存池技術(shù)對數(shù)據(jù)進行處理
所述步驟4中，接收數(shù)據(jù)處理線程的工作任務是:從內(nèi)存池中分配空間，將從IOCP工作線程中取的數(shù)據(jù)包進行解析，校驗數(shù)據(jù)完整性，按照不同的消息類型進行處理。
[0023]所述步驟5中，一定時間間隔為3?10分鐘之間的任意時間間隔。具體實施例中，時間間隔為5分鐘。
[0024]所述步驟6中，發(fā)送數(shù)據(jù)處理線程的工作任務是:判斷發(fā)送的數(shù)據(jù)內(nèi)型，分別做出不同的發(fā)送請求，提高系統(tǒng)效率。
[0025]具體實施中，可以采用以下步驟:
CMS前置機發(fā)起連接請求，服務器監(jiān)聽CMS前置機連接線程收到請求后，將相應的CMS前置機相關(guān)信息存入到內(nèi)存池已經(jīng)分配好的PSocketList中，并將返回的套接字存入到pSocketList內(nèi)對應的PerHandleData指向的結(jié)構(gòu)體當中。
[0026]調(diào)用CreateloCompletionPort函數(shù),將返回的套接字關(guān)聯(lián)到創(chuàng)建的IOCP對象上，同時將指定該套接字的指針PerHandleData也作為參數(shù)傳入，以后若有完成通知到達時，此PerHandleData也會隨通知一起收到，并且以pSocketList_>Per1Data所指向的結(jié)構(gòu)體中的LPWSAOVERLAPPED為參數(shù)，首次投遞WSARecv請求，實際的接收工作交由IOCP工作線程。
[0027]CMS前置機與服務器建立連接后，則會每隔5分鐘掃描所有建立的連接是否在5分鐘內(nèi)有數(shù)據(jù)交互，若無數(shù)據(jù)，則關(guān)閉套接字，等待CMS前置機的重新建立連接。
[0028]當CMS前置機發(fā)來數(shù)據(jù)，系統(tǒng)完成WSARecv并將數(shù)據(jù)發(fā)送至IOCP對象。IOCP工作線程里的GetQueuedCompletionStatus函數(shù)會立即返回，將數(shù)據(jù)從Per1Data指向的結(jié)構(gòu)體中的接收數(shù)據(jù)存儲區(qū)取出數(shù)據(jù)交由接收數(shù)據(jù)處理線程處理。接著IOCP工作線程根據(jù)取出的數(shù)據(jù)類型繼續(xù)投遞WSARecv或者WSASend請求。等待接收或發(fā)送下一次的數(shù)據(jù)。
[0029]接收數(shù)據(jù)處理線程會解析出具體是那個CMS前置機發(fā)送來的具體數(shù)據(jù)類型信息，如果是請求的配置文件數(shù)據(jù)，接收數(shù)據(jù)處理線程會從PSocketList中找到對應的發(fā)往CMS前置機的套接字，直接調(diào)用send函數(shù)回復對應的配置文件。如果是采集振動的原始信號數(shù)據(jù)，接收數(shù)據(jù)線程會在已經(jīng)申請好的內(nèi)存池中對數(shù)據(jù)進行校驗，通過后再按照自定義協(xié)議格式進行封裝，處理數(shù)據(jù)。將處理結(jié)果投遞到IOCP的WSASend中進行回復。
[0030]關(guān)鍵點:監(jiān)聽服務器線程，如果CMS前置機端發(fā)起連接，則創(chuàng)建IOCP工作線程，接受連接，將套接字關(guān)聯(lián)在IOCP對象上，間隔5分鐘掃描所以的連接是否進行過數(shù)據(jù)交互，如無則關(guān)閉連接，釋放資源。如收到數(shù)據(jù)則放入已經(jīng)申請好的內(nèi)存池中，在根據(jù)不同的消息數(shù)據(jù)類型，做出不同的發(fā)送請求，返回數(shù)據(jù)。
[0031]綜上所述，本發(fā)明一種CMS前置機與服務器的通訊方法提高CMS前置機的并行化接入數(shù)量，提高內(nèi)存使用效率，提高服務器資源的利用率。
[0032]以上所述的技術(shù)方案僅為本發(fā)明一種CMS前置機與服務器的通訊方法的較佳實施例，任何在本發(fā)明一種CMS前置機與服務器的通訊方法基礎上所作的等效變換或替換都包含在本專利的權(quán)利要求的范圍之內(nèi)。
【權(quán)利要求】
1.一種CMS前置機與服務器的通訊方法，包括: 步驟1:在服務器端創(chuàng)建監(jiān)聽CMS前置機連接線程，判斷是否有CMS前置機發(fā)起連接，是則執(zhí)行步驟2，否則繼續(xù)等待并繼續(xù)監(jiān)聽； 步驟2:創(chuàng)建IOCP工作線程，接受連接，將套接字關(guān)聯(lián)在IOCP對象上； 步驟3:判斷CMS前置機是否發(fā)送數(shù)據(jù)，是則執(zhí)行步驟4，否則執(zhí)行步驟5; 步驟4:創(chuàng)建接收數(shù)據(jù)處理線程并進行處理，跳轉(zhuǎn)至步驟6 ; 步驟5:創(chuàng)建掃描線程，負責在一定時間間隔查詢所有CMS前置機連接是否與服務器進行過通信，否則斷開無數(shù)據(jù)連接，重新發(fā)起連接，是則返回步驟5 ； 步驟6:創(chuàng)建服務器端發(fā)送數(shù)據(jù)處理線程將配置和處理的結(jié)果數(shù)據(jù)發(fā)送到對應的CMS前置機。
2.根據(jù)權(quán)利要求1所述的一種CMS前置機與服務器的通訊方法，其特征在于:步驟4中利用內(nèi)存池技術(shù)對數(shù)據(jù)進行處理。
3.根據(jù)權(quán)利要求2所述的一種CMS前置機與服務器的通訊方法，其特征在于:所述步驟4中，接收數(shù)據(jù)處理線程的工作任務是:從內(nèi)存池中分配空間，將從IOCP工作線程中取的數(shù)據(jù)包進行解析，校驗數(shù)據(jù)完整性，按照不同的消息類型進行處理。
4.根據(jù)權(quán)利要求1所述的一種CMS前置機與服務器的通訊方法，其特征在于:所述步驟5中，一定時間間隔為3?10分鐘之間的任意時間間隔。
5.根據(jù)權(quán)利要求4所述的一種CMS前置機與服務器的通訊方法，其特征在于:時間間隔為5分鐘。
6.根據(jù)權(quán)利要求1所述的一種CMS前置機與服務器的通訊方法，其特征在于:所述步驟6中，發(fā)送數(shù)據(jù)處理線程的工作任務是:判斷發(fā)送的數(shù)據(jù)內(nèi)型，分別做出不同的發(fā)送請求，提聞系統(tǒng)效率。
7.根據(jù)權(quán)利要求1所述的一種CMS前置機與服務器的通訊方法，其特征在于:調(diào)用CreateloCompletionPort函數(shù)，將返回的套接字關(guān)聯(lián)到創(chuàng)建的IOCP對象上，同時將指定該套接字的指針PerHandleData也作為參數(shù)傳入，以后若有完成通知到達時，此PerHandleData也會隨通知一起收到，并且以pSocketList_>Per1Data所指向的結(jié)構(gòu)體中的LPWSAOVERLAPPED為參數(shù)，首次投遞WSARecv請求，實際的接收工作交由IOCP工作線程。
8.根據(jù)權(quán)利要求7所述的一種CMS前置機與服務器的通訊方法，其特征在于:當CMS前置機發(fā)來數(shù)據(jù)，系統(tǒng)完成WSARecv并將數(shù)據(jù)發(fā)送至IOCP對象；10CP工作線程里的GetQueuedCompIetionStatus函數(shù)會立即返回，將數(shù)據(jù)從Per1Data指向的結(jié)構(gòu)體中的接收數(shù)據(jù)存儲區(qū)取出數(shù)據(jù)交由接收數(shù)據(jù)處理線程處理；接著IOCP工作線程根據(jù)取出的數(shù)據(jù)類型繼續(xù)投遞WSARecv或者WSASend請求,等待接收或發(fā)送下一次的數(shù)據(jù)。
9.根據(jù)權(quán)利要求8所述的一種CMS前置機與服務器的通訊方法，其特征在于:接收數(shù)據(jù)處理線程會解析出具體是那個CMS前置機發(fā)送來的具體數(shù)據(jù)類型信息，如果是請求的配置文件數(shù)據(jù)，接收數(shù)據(jù)處理線程會從PSocketList中找到對應的發(fā)往CMS前置機的套接字，直接調(diào)用send函數(shù)回復對應的配置文件；如果是采集振動的原始信號數(shù)據(jù)，接收數(shù)據(jù)線程會在已經(jīng)申請好的內(nèi)存池中對數(shù)據(jù)進行校驗，通過后再按照自定義協(xié)議格式進行封裝，處理數(shù)據(jù),將處理結(jié)果投遞到IOCP的WSASend中進行回復。
【文檔編號】H04L29/08GK103457926SQ201310017090
【公開日】2013年12月18日 申請日期:2013年1月17日 優(yōu)先權(quán)日:2013年1月17日
【發(fā)明者】王小康 申請人:成都阜特科技股份有限公司