宿 州 學 院 畢 業 論 文 論文題目 基于 C+遠程控制系統的設計 系 別 信息工程學院 專 業 計算機科學與技術 班 級 09 專升本 1 班 學 號 2009110457 學生姓名 劉偉偉 指導教師 （簽名） 完成時間 2011年 3 月 I 摘要 隨著計算機信息現代工業的發展 ， 計算機遠程 控制 管理系統越 來越受到 各方面的 重視。本文主要分析了遠程 控制 系統的一些基本功能和組成情況 ， 包括系統的需求分析、系統結構、功能模塊劃分分析等 ， 重點對應用程序的實際開發實現作了介紹。達到了實時性和安全性 ， 且應用程序功能完備。同時簡單介紹了 + 程環境和 功能特點。 本課題設計是為適應遠程控制及協助的要求 ， 使遠程 控制 提高到計算機的實時水平而設計的。遠程 控制 包括多項內容 ， 本課題設計只是承建 了其中的一部分即：實時 控制 。本課題設計 為一個通信應用程序 ， 用到了多項技術 ， 諸如：異步模式向對象編程、軟件工程思想 、 。 本系統 采用 + 為開發工具 , 整個系統操作簡潔、界面友好、功能靈活、實用，實現了包括客戶端屏幕監控、文件監控及傳輸、進程監控、系統服務和注冊表監控 等 基本功能， 基本完成了遠程 控制 中 所 需要到 的主要功能 。 關鍵詞 ： 套接字 面向對象 軟件工程 遠程 監控 of on + of is by of of of to of It + 6.0 of at is in to on by to up of a of of + + 6.0 as a of is is is of to 目錄 第一章 緒論 . 1 課題背景 . 1 目的以及意義 . 1 第二章 開發平臺的理論基礎 . 2 +及編程模式簡介 . 2 系統架構的模式 . 5 術簡介 . 6 的簡單介紹 . 7 第三章 需求分析 . 9 系統基本情況描述 . 9 系統可行性分析 . 9 功能需求分析 . 10 系統流程圖 . 12 第四章 總體設計 . 13 使用工具 . 13 系統模塊的設計 . 13 第五章 系統詳細設計 . 17 客戶端與服務器連接設計 . 17 系統各模塊界面設計及其實現 . 18 第六章 系統測試 . 32 軟件測試基礎 . 32 本系統采用的測試方法 . 32 第七章 總結 . 35 參考文獻 . 36 附錄 . 37 致謝 . 44 1 第一章 緒論 課題背景 通常企業內部或者 任務是通過電話解答疑難問題，努力減少技術人員到現場服務或者讓用戶把設備送到支持中心進行維護。這種技術支持方式盡管被普遍采用，但效率不高而且大大增加了技 術支持成本。 通常，技術支持必須依賴技術人員和用戶之間的口頭交流來進行，這種交流既耗時又容易出錯。許多商業用戶對計算機知之甚少，然而當遇到問題時，他們必須向技術人員提供故障情報及相關操作。在嘗試解決問題時，技術人員可能指導用戶執行一系列復雜的過程，而這些過程對用戶來說或許完全不熟悉；如果用戶不能正確的按要求操作，反而使問題惡化。此外，如果通過電話不能解決問題，那么 在 技術人員親自到用戶現場解決問題之前，計算機將 無法繼續 使用 ，導致工作延誤 。 目的以及意義 本文正是在 上文提到的 背景下提出的 ， 目的 就 是為了 解決計 算機的遠程操作，降低企業對軟件的后期維護成本，設計出一款遠程控制 系統 。 遠程 控制 系統 能使技術人員直接操作遠程計算機，就像操作本地機器一樣，無須用戶介入，技術人員技能得到該機器的問題的第一手材料，從而加快了問題的解決。實際上，使用遠程 控制 工具的技術人員能夠做到解答疑難問題，安裝和配置軟件，把軟件下載到用戶計算機上，配置應用程序和系統軟件設置并可通過實際操作培訓用戶。 總之，本課題的設計與實現具有很大的現實意義。 2 第二章 開發平臺的理論基礎 +及編程模 式簡介 +的簡介 +的資源編輯器能以所見即所得（ is 形式直接編輯程序的用戶界面，為所有資源分配 識號。 把對話框模板與生成的類定義或與已有的類代碼連接起來，為菜單項、控制等資源生成空的處理函數模板，創建消息映射條目，并將資源 處理函數連接起來。通過使用 序員的編程工作便簡化為用資源編輯器直觀的設計界面，完善對話框類代碼，在空的處理函數模板處填寫響應用戶操 作的代碼，這是一種比較完善的可視化編程方法。 但產品名 “ +” 也容易誤導人，讓人認為自己使用的是一個與似的完全可視化的系統。然而，使用 +，開發人員必須真正地閱讀和編寫 C+代碼。 +向導可以節省時間和提高精度，但是，程序員也必須理解向導產生的代碼，并且，最重要的是，還必須理解 的結構和 作系統的內部工作方式 7。 應用程序框架 應用程序框架的一種定義是：提供一般應用程序需要的全部面向對象軟件組件的集成集合。 C+流行的一個原因是它可以用類庫擴充。類庫是可在應用程序中使用的有關 C+類的集合。應用程序框架是類庫的超集。一般的類庫只是一種孤立的類的集合，用來嵌入在任何程序中，但是，應用程序框架卻定義了程序的結構。自從 發布以來， 經成為主要的 庫。使用 庫構建應用程序具有以下優點： 1. 是 C+的 2. 應用程序框架生成的應用程序使用了標準的 結構，具有標準化的用戶接口，這對具有標準用戶界面的 序來說，可以極大的減輕程序員的負擔，使程序員不必過多地考慮界面，可把主要精力放在程序設計上，以提高程序設計的效率。 3. 使用應用程序框架的應用程序不僅小，而且運行速度快，具有很大的靈 3 活性。 裝了 的幾乎所有函數，能實現 統的任何功能。 4. 架降低了編碼的復雜性。 5. 應用程序框架有豐富的特性，如： C+接口、通用的（非 特有的）類、 “共用根對象 ”類層次結構、流線式多文檔界 面（ 用程序支持等。 6. 強大的功能。除封裝了大部分的 數外， 提供了應用程序本身的數據和操作及 操作類。 架的核心是文檔 /視圖結構（ 這是一個很好用、但又往往較難以入門的功能。簡單的說，文檔 /視圖結構就是將數據和對數據的觀察或數據的表現（顯示）相分 離。文檔僅處理數據的實際讀、寫操作，視圖則是顯示和處理數據的窗口，視圖可以操作文檔中的數據 7。 消息映射 在使用 +進行 序設計時，消息映射是一個非常重要的概念。用程序是消息驅動的，應用程序不能直接得到用戶所做的操作，如鼠標按鍵、鍵盤輸入和窗口移動等。這些操作由操作系統管理，操作系統檢測到操作事件后，便向相關的應用程序發送消息，應用程序響應這些消息來完成用戶的操作。 1 消息 的消息是操作系統與應用程序之間、應用程序 與應用程序之間、應用程序各對象之間相互控制與傳遞信息的方式。 消息的基本格式如下： 消息名稱； 與消息相關的 參數； 與消息相關的 參數。 消息主要有以下 3 類。 統消息： 統向窗口發送的消息，由窗口（ 視圖（ 行響應處理。這類消息包括除 息之外的名稱以 控制通知消息：控制或子窗口傳給父窗口的 知的消息。 命令消息：在響應用戶接口操作時，將產生 令消息。其參 4 數指定了用戶接口的標識號，如菜單項和按鈕等 。 2 消息映射過程 在使用 建應用程序時， 用程序框架設置了相應的消息處理函數來響應消息，以完成相應的操作。消息處理函數是某些類（通常是窗口類）的成員函數和程序員在其中編寫響應消息時應進行操作的代碼。 框架將消息和它們的處理函數連接起來就是消息映射。消息映射使應用程序在接收到消息時調用對應的消息處理函數來響應和處理消息。 創建新類時將為其創建一個消息映射，并為每個類能響應的消息 和 命 令 增 加 對 應 的 處 理 函 數 。 在 源 代 碼 中 ， 消 息 映 射 開 始 于，結束于 ，中間由一系列預定義的被稱為 “ 條目宏 ” 的宏組成。其基本格式如下： 條目宏 1 條目宏 2 條目宏 3 /) 其中 擁有消息映射的當前類名， 當前類的父類名。條目宏定義了類所處理的消息與其對應的函數。常用的條目宏類型如表 示。 表 消息映射條目宏 消息類型 宏格式 說明 息 息名 命令 D,命令標識號， 更新命令 D,命令標 識號， 控制通知 D,控制標識號， 用戶定義消 D,消息標識號， 息 為處理函數名 用戶注冊消息 D,消息標識號， 息的處理函數在 中進行了預定義，類庫以消息名為基礎定義這些處理函數的名稱，且 求所有消息處理函數 聲明為 型。例如，消息 處理函數在 中的聲明如下： ; 通過 派生類中用同樣的原型定義處理函數并為該函數生成消息映射條目，然后由程序員編寫處理函數代碼，并在派生類中覆蓋了其父類的消息處理函數。在有些情況下，必須在派生類的消息處理函數中調用其父類的消息處理函數，使 基類能對消息進行處理。 在生成的處理函數中建議是否應調用父類的消息處理函數及調用的次序。除此之外，用戶定義和注冊的消息、命令和控制通知都沒有默認的處理函數，需要在定義時聲明，一般根據其 稱來為函數命名 7。 系統架構的模式 C/S 結構，即 戶機 /服務器 )結構， 軟件系統體系結構，通過將任 務 合理分配到 和 ，降低了系統的通訊開銷，可以充分利用兩端硬件環境的優勢。 C/S 模式即 構模式 構，它的發展經歷了兩個階段：從兩層結構到三層結構。 1. 兩層結構：它由兩部分構成：前端是客戶機，通常是 要完成用戶界面顯示，接受數據輸入，校驗數據有效性，向后臺數據庫發請求，接受返回結果，處理應用邏輯；后端是服務器，運行 供數據庫的查詢和管理。應用邏輯主要在前端，如在后端則是存儲過程的形式。 2. 三層結構：利用中間件將應用分為表示層、業務邏輯層和數據存儲層三個不同的處理層次。三個層次的劃分是從邏輯上來分的，具體的物理分法可以有多種組合。基于三層結構的應用系統不但具備了大型機系統穩定、安全和處理能力高等特性，同時擁有開放系統成本低、可擴展性強、開發周期短等優點。而中間件作為構造三層結構應用系統的基 礎平臺，提供了以下主要功能：負責客戶機與服務器間、服務器間與服務器間的聯接和通訊；實現應用與數據庫的高效連接；提供一個三層結構應用的開發、運行、部署和管理的平臺。 6 ， 服務器端首先監聽一個固定端口，客戶端再連接到服務端，此時服務端執行 作，以接受客戶端的連接 。 此時連接創建成功，則進行數據傳輸，待數據傳輸完畢，服務端和客戶端就斷開連接。 圖 2 通信流程 C/S 結構的優點 術在目前程序開發中得到了廣泛的應用 ， 這種技術的優點在于它將處理工作按照一定的比例分配到客戶端和服務器上去執行，這樣減少了網絡傳輸的工作量，從而合理地利用了資源，提高了應用程序開發的效率。由于客戶端實現與服務器的直接相連，沒有中間環節，因此響應速度快。 術 簡介 統下的編程，消息 傳遞是貫穿其始終的。這個消息可以簡單理解為一個有特定意義的整數，正如老故 事片中的 “ 長江長江，我是黃河 ”一個含義。 定義的消息給初學者的印象似乎是 “ 不計其數 ” 的，常見監聽 創建 接受 數 據 傳 輸 斷開 連接 創建 數 據 傳 輸 斷開 7 的一部分消息在 文件中定義。 消息有著非常密切的聯系，它的中文含義是 “ 鉤子 ” ，這樣理解起來不難得出 “ 消息處理中的一個環節，用于監控消息在系統中的傳遞，并在這些消息到達最終的消息處理過程前，處理某些特定的消息 ” 。這也是 為不同種類的原因。 在 經常 接觸到 用的 天隨著控件， 術的出現， 諸如控件這些現成的手段不能實現的功能時，因此 還需要借助 初有些人對某些 產生了如何修改這些 之更好的服務于程序的想法，這樣 過 變一個系統 本的方法就是通過 接觸 ”到需要修改的 變它的地址指向新的自定義的函數。 3類 以說， 什么特別不同的 也需要通過基本的 越不同進程間訪問的限制，達到修改 的簡單介紹 通過類名就知道這是一個異步非阻塞 什么是異步非阻塞呢？舉個例子：一位體育老師，需要測驗 100位同學的 400米 成績。 老師 每隔 10秒讓一位同學起跑，直到所有同學出發完 畢；另一邊每有一個同學回到終點就記錄成績，直到所有同學都跑完。 老師 設計了兩個函數， 其中一個函數記錄起跑時間和學生號，該函數會主動調用 100次；另一個函數記錄到達時間和學生號，該函數是一個事件驅動的 有同學到達終點時，被動調用。 老師 主動調用的函數是異步的，因為 調用它 時 ，它并不會 立刻返回 ；這個函數也是非阻塞的，因為一旦調用它，它就馬上返回， 不用等待就可以再次調用它。 這就是異步非阻塞模式。 然而，最不容易被初學 是本課題最要提醒的一點是，客戶方在使用 時，往往返回一個 其它的某些函數調用也如此 ，如： ,等 ） ，實際上這不應該算作一個錯誤，它是 醒 用戶 ，由于使用了非阻塞以 （ 連接 ） 操作需要時間，不能瞬間建立。 因此 可以 在程序中 等待 ，等它連接成功為止，于是許多程序員就在調用 之后， )，然后不停地用 或者 查看 8 直到返回成功為止。這是一種錯誤的做法， 不能達到預期 目的。事實上， 可以在調用之后等待 事件被觸發，是要表明 么連接徹底失敗了 。 9 第三章 需求分析 系統基本情況描述 隨著計算機技術的不斷發展， 人們 要處理的任務也越來越多， 工作地點也有可能是多個，在計算機使用的過程中就會遇到這樣那樣的問題 ，從而使得工作變得更加繁重 。 如果將計算機系統進行還原或重裝，一些重要 資料有可能將會丟失。尋求一種方便、高效的方法對出現故障的系統進行修復已經成為人們的迫切需要 。本課題設計 的使用，能幫助技術人員方便、高效的修復遠程系統軟件，提高人們的工作效率，降低系統維護的成本 。 系統可行性分析 可行性研究的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的方法。 可行性分析實質上是要進行一次大大壓縮簡化了的系統分析和設計的過程，也就是在較高層次上以較抽象的方式進行的系統分析和設計的過程。 要研究每一種解法的可行性，一般說來，應從經濟可行性、技術可行性、 操 作可行性 等方面研究可行性 12。 經濟可行性 本課題設計 成本低廉，要的只是兩個 發的 址，而且這也多用于局域網或企業網等內網，就更談不上成本上的問題。但是如果需要對程序的質量提高可以購買 加密 算法，對傳輸數據進行加密。 技術可行性 本課題設計 所用到的一系列的技術已是累積了幾十年的技術，這些技術在這么多年的發展中并沒有被淘汰，反而是越來越來熱門。當初遠程 協助 這門技術在 是受網絡的制約，但是此時這門技術還是受網絡技術制約著。網絡流量的問題是造成所有通信 程序的不穩定性的罪魁禍首。但是 本課題設計 在局域網中是完全能夠實現的，而且也是專門為企業網內部所設計，因為數據信息沒被加密，如果想走 需建立 操作可行性 根據系統的操作是否簡單易懂，是否為用戶所接受，從操作的角度研究系統的可行性。 本課題設計 操作簡單，客戶端安裝后無需其它操作，服務端待客戶端 10 自動連接后，則可以對其屏幕、文件、注冊表等進行操作，完全像操作本地機器一樣簡單 。 綜合以上三方面的可行性分析， 本課題設計 的操作 是可行的。 功能需求 分析 功能需求是對軟件系統的 一項基本需求，這方面的需求指定系統必須提供的服務。 根據對 一般的遠程協助 的調查了解， 該系統應該至少包含以下幾個功能 ： 1. 服務端對 客戶端的屏幕監控 。 遠程協助系統就是 要 解決那些 難以 用語言描述的軟件問題， 協助端（服務端）如果能實時的看見被協助端（客戶端）的系統桌面，那將大大提高解決 問題的效率。 當然，為了更方便的操作，協助端還 必須能 控制被協助端的鼠標和鍵盤 。 系統 服務端 桌面監控 的 用例圖如圖 3 圖 3面監控 用例圖 2. 服務端對客戶端文件操作 。 服務端如果僅僅能監控客戶端桌面，那幫助也許沒那么大，比如客戶端要修復一些文件，而在客戶端本地硬盤中又沒有相應的修復工具，此時服務端也是無能為力的。當然，可以通過 通訊工具傳輸，這樣做畢竟也是很麻煩的，因此服務端能實現對客戶端 的 文件 遠程操作則是不可或缺 的。 文件操作包括：上傳文件、下載文件、修改文件名、創建文件夾、執行遠程程序 等等 。 該 功 能 模 塊 的 用 例 圖 如圖 3示 ： 獲取遠程桌面 控制遠程鼠標 控制遠程鍵盤 遠程協助系統 11 圖 3件操作用例圖 3. 服務端對客戶端的高級操作 。 對于維護和修復一個系統，難免要與系統注冊表、 系統 服務、進程打交道，在桌面監控功能中雖然能實現對這些功能的操作，但是畢竟受到網絡帶寬的限制，遠程桌面圖片傳輸較慢，實時性較低。 服務端向客戶端發送一條命令，客戶端針對該命令分別枚舉出客戶端的注冊表、系統服務、進程等，再以文本方式發送給服務端，服務端獲取到信息后，則可以對注冊表、系統服務、進程做刪除、添加、結束等操作。 4. 消息廣播 。 服務端可以同時被多個客戶端連接，消息廣播則合適企業或學校的管理 。 在該功能中，服 務端有權限阻止客戶端發送的廣播消息，也有權限向某一客戶端發送消息。 5. 自動上線 。 自動上線其實就是一種反彈式連接，該功能 只需 應用在服務端動態的情況 下 。服務端首先要擁有一個動態域名，假設為： ，然后將此時服務端的 新到一個頁面中，如： ，客戶端則不斷去訪問該頁面，以便獲取服務端最新的 后連接到服務端。 6. 進程守護。對于企業或學校的多客戶端連接，為了能使得管理順利進行，則需對客戶端進程進行保護，防止被惡意結束。 上傳文件到客戶端 下載客戶端文件 修 改文件名 遠程協助系統 創建文件夾 執行遠程程序 12 系 統流程圖 安裝好客戶端后，客戶端則會不斷的嘗試連接服務器， 連接成功了就會根據服務端發送的操作命令執行不同的操作，再將結果返回給服務端 ，本系統流程圖如圖 3示 ： 圖 3統流程圖 連接服務端 連接成功 ？ 客戶端程序 服務端程序 接受并添加客戶端信息 失敗 成功 發送 登 錄 信息 發送操作命令 解析命令 屏幕操作 文件操作 注冊表操作 服務操作 進程操作 發送結果 顯示結果 是否退出？ 退出系統 是 否 13 第四章 總體設計 經過需求分析階段，在軟件需求分析階段已經弄清楚了 各種需求，較好地解決了所開發的系統 “ 做什么 ” 的問題，并已在軟件需求說明書和數據要求說明書中詳盡和充分地闡明了這些需求以后，下一步就要著手對軟件系統的結構、數據結構、用戶界面等進行設計 。 使 用工具 本系統采用 + 為開發工具 ，客戶端調試使用 擬機 。 系統模塊的設計 模塊設計 本系統面向的對象有兩種，一種是 服務端 ，一種是 客戶端 。 服務端只要是向客戶端發送操作命令，客戶端解析命令后執行相應操作，然后將結果返回給服務端 ，服務端再將結果顯示出來 。 屏幕監控 模塊 設計 屏幕監控，也就是將客戶端的屏幕截圖，然后發送給服務端。由于截圖圖片格式為 幀圖像數據量很大，因此在此模塊中引用第三方開源類庫壓 縮庫 截圖在內存中壓縮成 式，然后再調用 壓縮函數進一步對 縮，最后再發送給服務端。鼠標和鍵盤的操作則是通過模擬來實現，在服務端捕獲鼠標鍵盤操作后，服務端的命令連接就會將捕獲的結果發送到客戶端，客戶端再 通過調用 兩個 數進行模擬鼠標鍵盤操作。 該模塊 大致 流程圖 如圖 4示 ： 14 圖 4幕監控 大致 流程圖 文件 操作 模塊 設計 文件操作，包括文件上傳、文件下 載、刪除文件、修改文件名、執行遠程程序 。 在文件傳輸過程中，服務端能顯示傳輸進度，也可以終止傳輸 。 該模塊大致流程圖如圖 4示 ： 發送截屏命令 解析命令 截屏 圖片壓縮 添加數據包尾 發送數據 接收數據 是數據包尾嗎？ 模擬鼠標點擊移動 模擬鍵盤操作 是 否 數據包解壓 顯示圖片 服務端 客戶端 發送鍵盤鼠標命令 停止傳輸嗎？ 開始屏幕傳輸 停止屏幕傳輸 是 否 15 圖 4件操作 大致 流程圖 命令操作模塊 設計 命令操作，包括系統注冊表、服務、進程、消息廣播、執行 啟或關閉遠程計算機等操作，命令操作傳輸的數據量小，響應快 。 為了客戶端程序能正常對進程、服務等操作，還必須對客戶端進程進行提升權限操作。 該模塊的功能模塊圖如圖 4示： 發送命令 解析命令 修改文件名 執行遠程程序 服務端 客戶端 刪除文件 文件傳輸 文件傳輸 發送結果 顯示結果 停止傳輸嗎？ 停止傳輸 是 否 16 圖 4令操作 功能模塊圖 務器模塊 設計 對于使用自動上線的用戶來說，如果系統包含 務器的話就會比較方便，因此在該遠程協助系統中，嵌入了簡單的 務器，用戶可以借助這兩個服務器 ，將服務端的 新到動態域名的某個文件中， 使得客戶端能夠自動上線 。 塊設計 本系統采用 術對客戶端進程進行守護，達到防止客戶端進程被惡意結束的目的。 該功能采用了微軟的開源類庫 兩個系統 行 從而實現對客戶端進程進行守護的目的。 遠程協助系統 遠程 注冊表 管理 遠程服務管理 遠程 作 遠程進程管理 遠程關機重啟管理 17 第五章 系統詳細設計 根據系統的主要功能及上一章的總體設計，系統進入 詳細設計 階段 。 詳細設計階段的根本目標是確定應該怎樣具體地實現所要求的系統，經過這個階段的設計工作，得出對目標系統的精確描述。 由于代碼較多，本章在說明部分功能時，只介紹了相關的函數和某些關鍵的 代碼 語句。 客戶端與服務器 連接 設計 載了 接和斷開的消息事 件，用戶可以在這些事件中判斷 連接情況，但是斷開消息事件在一種情況下無法觸發，也就是網線被拔掉或其中一方斷電時，為了解決這種情況，可以在服務端和客戶端中都添加一個連接時鐘，周期性的給對方發送一個心跳包，如果發送失敗則表示對方已經斷開連接 ，此時則進入斷開重連狀態 。 對于異步非阻塞的 說，連接成功與否是在其 件里 判斷的 ， 該事件函數原型為： ，傳進的參數如果等于0，則表示連接成功。 相關代碼如下： = 0)/如果連接成功 024; 1024; ; ; 0; :&= 0; = | + | + |; 1024; 18 :&= 0; = 系統各模塊界面設計及其實現 屏幕監控 模塊 服務端向客戶端第一次發送獲取屏幕命令時，客戶端并非立刻截屏然后 將數據發送 服務端 ，考慮到 多個 客戶端的屏幕分辨率大小不一致的情況 下 ， 客戶端首次收到服務端的屏幕監控命令后，應先將客戶端當前屏幕分辨率發送給服務端， 服務端在窗口上創建一個矩形區域用于顯示客戶端桌面圖片，然后才是屏幕數據的傳輸， 由于客戶端不停的發送屏幕數據，為了能使服務端區分每一 幀的屏幕，客戶端在發送屏幕數據前，