0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

采用服務(wù)端完成端口通信技術(shù)對(duì)路燈監(jiān)控系統(tǒng)軟件進(jìn)行優(yōu)化設(shè)計(jì)

電子設(shè)計(jì) ? 來(lái)源:照明工程學(xué)報(bào) ? 作者:劉暾東,黃祚,孫 ? 2020-05-26 08:05 ? 次閱讀

1、 引言

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

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

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

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

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

采用服務(wù)端完成端口通信技術(shù)對(duì)路燈監(jiān)控系統(tǒng)軟件進(jìn)行優(yōu)化設(shè)計(jì)

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

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

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

3. 1 完成端口原理

3. 1. 1 完成端口簡(jiǎn)介

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

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

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

3. 1. 2 重疊I /O

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

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

3. 1. 3 工作線程

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

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

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

主線程:

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

CompletionPort = CreateIoCompletionPort ( INVALID_ HANDLE_ VALUE,NULL,0,0);

2) 啟動(dòng)2* N + 2 個(gè)工作線程,N 為CPU 數(shù)量:

3) 進(jìn)入一個(gè)*循環(huán),開始*客戶端連接請(qǐng)求;

4) 將接收到的客戶端SOCKET 與完成端口對(duì)象綁定;

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

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

工作線程:

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

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

3) 提交一個(gè)新的WSASend /WSARecv 操作請(qǐng)求;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. 1 測(cè)試對(duì)象

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

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

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

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

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

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

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

6、 結(jié)束語(yǔ)

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

責(zé)任編輯:gt


聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 無(wú)線通信
    +關(guān)注

    關(guān)注

    58

    文章

    4570

    瀏覽量

    143549
  • 服務(wù)器
    +關(guān)注

    關(guān)注

    12

    文章

    9165

    瀏覽量

    85437
  • 監(jiān)控系統(tǒng)

    關(guān)注

    21

    文章

    3915

    瀏覽量

    174788
收藏 人收藏

    評(píng)論

    相關(guān)推薦

    [原創(chuàng)]基于WSN的路燈監(jiān)控管理系統(tǒng)

    信息數(shù)據(jù),控制各個(gè)路燈節(jié)點(diǎn)以及自組織等功能的無(wú)線傳感器網(wǎng)絡(luò)。節(jié)點(diǎn)與節(jié)點(diǎn)之間采用多跳通信協(xié)議,監(jiān)控中與各個(gè)監(jiān)控終端之間的
    發(fā)表于 02-02 12:45

    基于C/S 模式與完成端口路燈監(jiān)控軟件的設(shè)計(jì)

    端口技術(shù)的應(yīng)用,將原有的基于C / S 模式的路燈監(jiān)控系統(tǒng)軟件進(jìn)行優(yōu)化,使得整套
    發(fā)表于 07-14 16:17

    LED路燈節(jié)能監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

    開發(fā)工具VisualBasic6.0 來(lái)進(jìn)行開發(fā)。監(jiān)控中心主界面如圖4 所示。圖3 軟件系統(tǒng)框圖圖4 LED 節(jié)能控制中心軟件界面  針
    發(fā)表于 09-29 09:51

    zigbee無(wú)線通信終端基于太陽(yáng)能路燈監(jiān)控系統(tǒng)的應(yīng)用

    對(duì)太陽(yáng)能充電情況、蓄電池狀態(tài)、LED燈頭溫度、照度等參數(shù)進(jìn)行監(jiān)測(cè), 同時(shí)為合理利用資源,避免浪費(fèi)情況的發(fā)生, 應(yīng)對(duì)路燈的開、關(guān), 輸出功率的調(diào)整給予控制。 系統(tǒng)組成: 1.監(jiān)控中心:包
    發(fā)表于 08-31 10:46

    MDC系統(tǒng)軟件

    。以軟件通信手段為主,采用以太網(wǎng)、串口、MPI總線等設(shè)備進(jìn)行通信實(shí)現(xiàn)數(shù)據(jù)采集。該方式幾乎不用增加過多硬件即可實(shí)現(xiàn)對(duì)機(jī)床全面的數(shù)據(jù)采集和
    發(fā)表于 08-12 13:28

    裝配生產(chǎn)線MES系統(tǒng)軟件

    并發(fā)線程數(shù),針對(duì)MES系統(tǒng)軟件平臺(tái)的關(guān)鍵技術(shù)進(jìn)行優(yōu)化。通過測(cè)試證明,按照優(yōu)化方案進(jìn)行改進(jìn)后的M
    發(fā)表于 12-20 19:21

    TCP通信時(shí)服務(wù)端如何接收客戶的數(shù)據(jù)?

    畢設(shè)采用的是TCP協(xié)議,組員做的是下位機(jī),C編程,WiFi模塊工作處于客戶。我負(fù)責(zé)上位機(jī),Labview使用tcp協(xié)議時(shí)服務(wù)端怎么接收客戶的數(shù)據(jù)呢? 我找到的例程都是
    發(fā)表于 04-14 14:49

    基于ARM7及GPRS的路燈監(jiān)控通信系統(tǒng)終端

    路燈監(jiān)控通信系統(tǒng)的終端,實(shí)現(xiàn)遠(yuǎn)程無(wú)線的各路現(xiàn)場(chǎng)數(shù)據(jù)的傳輸。結(jié)合上位機(jī)軟件,將各路數(shù)據(jù)實(shí)時(shí)傳遞到集中監(jiān)控
    發(fā)表于 11-02 07:00

    監(jiān)控系統(tǒng)客戶服務(wù)端設(shè)計(jì)

    詳情2.1.2 數(shù)據(jù)庫(kù)接口及實(shí)現(xiàn)2.1.2.1 用戶注冊(cè)2.1.2.2 用戶查詢2.2 監(jiān)控系統(tǒng)客戶服務(wù)端設(shè)計(jì)2.2.1 `CS`模型2.2.2 功能2.2.2
    發(fā)表于 12-21 07:02

    監(jiān)控服務(wù)器資源利用率的服務(wù)端腳本

    其主要目的是:基于 Python 編程語(yǔ)言來(lái)監(jiān)控服務(wù)器的 CPU、內(nèi)存、/目錄、/appslog、/bigdata目錄使用率以及網(wǎng)卡接收和發(fā)送情況。 該腳本部署場(chǎng)景分為:服務(wù)端和客戶
    的頭像 發(fā)表于 01-22 16:02 ?739次閱讀

    MQTT中服務(wù)端和客戶

    MQTT 是一種基于客戶-服務(wù)端架構(gòu)(C/S)的消息傳輸協(xié)議,所以在 MQTT 協(xié)議通信中,有兩個(gè)最為重要的角色,它們便是服務(wù)端和客戶。
    的頭像 發(fā)表于 07-30 14:55 ?2652次閱讀

    服務(wù)端的測(cè)試主要是測(cè)什么內(nèi)容

    服務(wù)端測(cè)試是軟件開發(fā)過程中的一個(gè)重要環(huán)節(jié),主要目的是確保服務(wù)端程序的穩(wěn)定性、性能、安全性和可靠性。 功能測(cè)試 功能測(cè)試是服務(wù)端測(cè)試的基礎(chǔ),主要驗(yàn)證
    的頭像 發(fā)表于 05-30 15:24 ?4051次閱讀

    服務(wù)端測(cè)試和客戶測(cè)試區(qū)別在哪

    服務(wù)端測(cè)試和客戶測(cè)試是軟件開發(fā)過程中的兩個(gè)重要環(huán)節(jié),它們分別針對(duì)服務(wù)器端和客戶軟件
    的頭像 發(fā)表于 05-30 15:27 ?3099次閱讀

    服務(wù)端測(cè)試是web測(cè)試嗎為什么

    客戶請(qǐng)求、執(zhí)行業(yè)務(wù)邏輯、與數(shù)據(jù)庫(kù)交互等。服務(wù)端測(cè)試的目的是確保服務(wù)器端軟件組件能夠按照預(yù)期工作,沒有錯(cuò)誤,并且能夠滿足性能要求。 服務(wù)端
    的頭像 發(fā)表于 05-30 15:30 ?615次閱讀

    服務(wù)端測(cè)試包括什么類型

    服務(wù)端測(cè)試是確保軟件系統(tǒng)服務(wù)器端正常運(yùn)行和滿足性能要求的重要環(huán)節(jié)。本文將詳細(xì)介紹服務(wù)端測(cè)試的類型、方法和最佳實(shí)踐。 1.
    的頭像 發(fā)表于 05-30 16:03 ?758次閱讀