【正文】 ............. 31 第 7章 主要問(wèn)題及解決 ............................................................................................................. 32 多線程問(wèn)題 ................................................................................................................... 32 套接字異常 ................................................................................................................... 32 網(wǎng)絡(luò)流異常 ................................................................................................................... 32 參考文獻(xiàn) .................................................................................................................................... 33 附錄 ........................................................................................................................................... 34 1 局域網(wǎng)聊天工具 設(shè)計(jì) —— 文本聊天、文件傳輸及用戶管理 摘要 ： 隨著計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)的發(fā)展，各種各樣基于網(wǎng)絡(luò)的應(yīng)用也隨之誕生 ,比如基于互聯(lián)網(wǎng)的信息發(fā)布，通信，數(shù)據(jù)共享等等。因此基于局域網(wǎng)的即時(shí)通信工具，就這樣應(yīng)運(yùn)而生了。s functions are reasonable and easy to extend, as well as customization. Key words: LAN。 multithreaded 3 第 1 章 引言 系統(tǒng)開(kāi)發(fā)的背景 當(dāng)今世界正處于信息時(shí)代，計(jì)算機(jī)和通信網(wǎng)絡(luò)是這一時(shí)代所謂“信息基礎(chǔ)設(shè)施”。于是這就需要 1種便宜，快速，能同時(shí)與多個(gè)好友進(jìn)行通訊的網(wǎng)絡(luò)工具的出現(xiàn)，而網(wǎng)絡(luò)聊天工具就滿足了這些需求，填補(bǔ)了這個(gè)空白。 廣域網(wǎng)上的即時(shí)通信工具，如今一般采用 UDP 或者 TCP協(xié)議體系來(lái)實(shí)現(xiàn)，開(kāi)發(fā)技術(shù)已經(jīng)比較成熟，這些軟件，在使用方面各有特色，在實(shí)現(xiàn)方面也各有所長(zhǎng)，但基于這些產(chǎn)品正在商業(yè)運(yùn)營(yíng)階段，其實(shí)現(xiàn)方式屬于商業(yè)機(jī)密，具體細(xì)節(jié)不可能得知，但是它在大的方面無(wú)非就是利用各種平臺(tái)上的網(wǎng)絡(luò)通信接口，建構(gòu)基于 TCP/IP,或者 UDP 協(xié)議的軟件產(chǎn)品。 聊天工具開(kāi)發(fā)的現(xiàn)實(shí)意義 局域網(wǎng)聊天工具，是在局域網(wǎng)內(nèi)部使用的，用戶之間用來(lái)交流的一個(gè)工具，一般都具有文本聊天和文件傳輸功能。但是， ipmsg 在某些時(shí)候，在同一 vlan 下的用戶，能夠彼此看見(jiàn)對(duì)方，卻不能通信，因?yàn)槠洳捎玫氖?udp協(xié)議作為消息 傳遞協(xié)議，而這種傳輸是不穩(wěn)定的，所以有時(shí)候能看到對(duì)方的用戶之間不能實(shí)現(xiàn)互相通信，怎么辦呢？一種解決方法就是，采用 tcp協(xié)議，面向連接的傳輸層協(xié)議作為消息傳遞協(xié)議，開(kāi)發(fā)出相應(yīng)的網(wǎng)絡(luò)應(yīng)用程序就能夠?qū)崿F(xiàn)彼此連接的雙方進(jìn)行信息的傳遞。而用戶的選擇也將包括電腦與電腦、電腦與電話、電話與 電話、電話與 (智能 )手機(jī)等通話方式。通過(guò)開(kāi)發(fā)本軟件，可以了解當(dāng)前流行的 voip 技術(shù)，練習(xí) socket 編程，擴(kuò)展知識(shí)面，鍛煉編程的能力等，所以極具研究?jī)r(jià)值。 MicroSoft .NET Framework 簡(jiǎn)介 .NET Framework 是由 微軟 開(kāi)發(fā)，一個(gè)致力于 敏捷軟件開(kāi)發(fā) （ Agile software development）、 快速應(yīng)用開(kāi)發(fā) （ Rapid application development）、 平臺(tái)無(wú)關(guān)性 和 網(wǎng)絡(luò)透明化 的軟件開(kāi)發(fā) 平 臺(tái) 。這些革新使得程序設(shè)計(jì)員可以同時(shí)進(jìn)行 Windows 應(yīng)用軟件 和 網(wǎng)絡(luò) 應(yīng)用軟件 以及 元件 和服務(wù)（ web service）的開(kāi)發(fā)。這是一個(gè)覆蓋面相當(dāng)廣泛的名詞，可以這么說(shuō)：輔助開(kāi)發(fā)某一類軟件的相關(guān)文檔、范例和工具的集合都可以叫做 “ SDK”。而 API 和 SDK 是開(kāi)發(fā) Windows 應(yīng)用程序所必需的東西，所以其它編程框架和類庫(kù)都是建立在它們之上的，比如 VCL 和 MFC，雖然他們比起“ SDK 編程”來(lái)有著更高的抽象度，但這絲毫不妨礙它們?cè)谛枰臅r(shí)候隨時(shí)直接調(diào)用 API 函數(shù)。有兩種主要的多線程方法是 .NET所提倡的：使用 ThreadStart 來(lái)開(kāi)始你自己的進(jìn)程，直接的 （使用）或者間接的（比如 ，或者調(diào)用 BeginInvoke）使用 ThreadPool 類。有時(shí) ,可能有多個(gè)客戶向同一個(gè)服務(wù)器同時(shí)請(qǐng)求服務(wù) ,這就需要服務(wù)器決定怎樣處理這些請(qǐng)求。 Client/Server 模型最終可歸結(jié)為一種“請(qǐng)求 /應(yīng)答”關(guān)系。 圖 21 客戶機(jī)／服務(wù)器通信結(jié)構(gòu)示圖 為了方便 Client/Server 模型的網(wǎng)絡(luò)編程， 90年代初，由 Microsoft 聯(lián)合了其他幾家公司共同制定了一套 WINDOWS 下的網(wǎng)絡(luò)編程接口，即 Windows Sockets 規(guī)范，它不是一種網(wǎng)絡(luò)協(xié)議 ,而是一套開(kāi)放的、支持多種協(xié)議的 Windows 下的網(wǎng)絡(luò)編程接口。一旦建立了這種連接，就可以在設(shè)備之間可靠地傳輸數(shù)據(jù)。一般情況下，使用 TcpClient 連接、發(fā)送和接收數(shù) 據(jù)，使用 TcpListener監(jiān)聽(tīng)是否有傳入的連接請(qǐng)求，使用 Close()方法釋放與 TcpClient 關(guān)聯(lián)的所有資源。所以，系統(tǒng)結(jié)構(gòu)將設(shè)計(jì)成如圖 23的方 式。 XML 與 Access,Oracle 和 SQL Server 等數(shù)據(jù)庫(kù)不同，數(shù)據(jù)庫(kù)提供了更強(qiáng)有力的數(shù)據(jù)存儲(chǔ)和分析能力，例如：數(shù)據(jù)索引、排序、查找、相關(guān)一致性等， XML 僅僅是展示數(shù)據(jù)。 XML 的主要作用有： (1)豐富文件（ Rich Documents） 自定文件描述并使其更豐富 (2)屬于文件為主的 XML 技術(shù)應(yīng)用 (3)標(biāo)記是用來(lái)定義一塊數(shù)據(jù) 應(yīng)該如何呈現(xiàn) (4)解釋數(shù)據(jù)（ Metadata） 描述其它文件或在線信息 (5)屬于數(shù)據(jù)為主的 XML 技術(shù)應(yīng)用 (6)標(biāo)記是用來(lái)說(shuō)明一塊資料的意義 (7)組態(tài)檔案（ Configuration Files） 描述軟件的組態(tài)參數(shù) 10 第 3 章 需求分析 用戶需求 隨著中小型企事業(yè)的不斷發(fā)展，在企業(yè)內(nèi)部實(shí)現(xiàn)局域網(wǎng)通信是必不可少的。 客戶端能夠注冊(cè)新用戶 可以在局域網(wǎng)實(shí)現(xiàn)文字和文件的傳輸 可以進(jìn)行聊天記錄保存 可以實(shí)現(xiàn)局域網(wǎng)語(yǔ)音聊天 系統(tǒng)運(yùn)行穩(wěn)定、安全可靠 系統(tǒng)功能需求 這個(gè)程序要實(shí)現(xiàn)的功能如下： (1)程序啟動(dòng)之后就能看到當(dāng)前哪些機(jī)器在線，哪些可以與之進(jìn)行對(duì)等通信。 (5)當(dāng)有遠(yuǎn)程用戶向本機(jī)發(fā)送文件的時(shí)候，要彈出一個(gè)消息提示框，提示本機(jī)用戶，可以選擇接收或者拒絕。要求提前設(shè)想到類似的盡可能多的可能發(fā)生的事件，做 出相應(yīng)的應(yīng)對(duì)措施，并向用戶提交簡(jiǎn)單易懂清晰明白的提示信息。并且不發(fā)生內(nèi)存泄漏之類影響系統(tǒng)運(yùn)行的錯(cuò)誤事件。 可行性研究 （ 1）成本可行性分析 本軟件只做開(kāi)發(fā)學(xué)習(xí)使用，所以暫且不考慮經(jīng)濟(jì)成本及盈利問(wèn)題。 客戶端的功能包括：注冊(cè)新用戶、用戶登錄、文本聊天、語(yǔ)音聊天、文件傳輸。 此系統(tǒng)由 2 個(gè)成員共同完成，各成員分工情況如表 41所示。文本聊天的信息傳輸協(xié)議主要有面向連接的 TCP 和無(wú)連接的 UDP。 文本聊天服務(wù)器工作原理 開(kāi)啟服務(wù)器，文本聊天窗體加載成功后，將啟動(dòng)監(jiān)聽(tīng)線程，服務(wù)器主要是負(fù)責(zé)監(jiān)聽(tīng)局域網(wǎng)內(nèi)的用戶的連接請(qǐng)求。通信雙方就可以進(jìn)行文字聊天了。文本聊天服務(wù)器工作流程如圖 51所示。若已建立連接，當(dāng)斷開(kāi)連接時(shí)，將向?qū)Ψ桨l(fā)送斷開(kāi)信號(hào)，然 后將釋放Socket 和網(wǎng)絡(luò)流，不影響到下一次連接的發(fā)起。程序?qū)崿F(xiàn)的原理也比較簡(jiǎn)單，但是用到了 P2P 技術(shù) 非中心化 的基本原則。當(dāng)無(wú)接入請(qǐng)求，則判斷是否有嘗試連接遠(yuǎn)程服務(wù)端事件，若有，則按照文本聊天客戶端模塊工作流程執(zhí)行，如圖 53 所示。當(dāng)用戶未輸入文執(zhí)行監(jiān)聽(tīng)線程，監(jiān)聽(tīng)端口 是 否 開(kāi)始 有接入連接請(qǐng)求 是 是 否 否 連接服務(wù)器？ 是 否 是否斷開(kāi)連接？ 連接雙方進(jìn)行消息通信 是 終止 保存聊天記錄 否 保存記錄？ 發(fā)送斷開(kāi)信號(hào)，關(guān)閉文本聊天 是 本地或遠(yuǎn)程服務(wù)端允許？ 建立連接，允許發(fā)送消息事件，啟動(dòng)接受信息線程 18 字而嘗試發(fā)送時(shí)，彈出消息提示框，提示不能發(fā)送空信息，節(jié)省系統(tǒng)和網(wǎng)絡(luò)資源。 集成主窗體創(chuàng)建后，創(chuàng)建一個(gè) tcpListener 的對(duì)象， 端口為 5000， IP為任意。若同意，則創(chuàng)建 接 收 信息線程 th，并 啟動(dòng) th。 當(dāng)無(wú)接入請(qǐng)求，則判斷用戶是否有嘗試連接遠(yuǎn)程服務(wù)端事件。 斷開(kāi)連接或關(guān)閉窗體，需要將 Socket、網(wǎng)絡(luò)流以及接收信息線程 th 進(jìn)行關(guān)閉，重置各按鈕的可用狀態(tài)。文件共享的實(shí)現(xiàn)離不開(kāi) 文件傳輸。若同意接收，則彈出文件保存對(duì)話框，用戶選擇文件保存路徑并確認(rèn)后，發(fā)送接收信號(hào)給文件發(fā)送端，啟動(dòng)計(jì)時(shí)器開(kāi)始接收文件流，將遠(yuǎn)程文件保存在本地，并在文件傳輸過(guò)程中對(duì)文件傳輸狀態(tài)進(jìn)行反饋，文件接收完畢后，關(guān)閉計(jì)時(shí)器，關(guān)閉文件流，并在狀態(tài)欄上顯示出完畢狀態(tài)。若接收端拒絕接受文件，則取消本次文件發(fā)送，等待用戶的下一次文件發(fā)送事件。 2) P2P 文件傳輸工作流程圖 負(fù)責(zé)接收文件的監(jiān)聽(tīng)線程集成在聊天窗體內(nèi)，當(dāng)聊天窗體加載時(shí)，將開(kāi)啟此線程。 添加待傳送的文件 接收端同意接收文件？ 否 是 啟動(dòng)計(jì)時(shí)器，發(fā)送文件流，反饋狀態(tài) 終止 向接收端發(fā)送文件傳輸請(qǐng)求 關(guān)閉計(jì)時(shí)器，關(guān)閉文件流 將本地文件發(fā)送至接收端 開(kāi)始 22 圖 57 P2P文件傳輸 程序 流程圖 3) 文件傳輸發(fā)送端窗體 文件發(fā)送主要作用是發(fā)送本地文件至遠(yuǎn)程接收端，所以功能盡可能簡(jiǎn)單化，方便用戶操作，設(shè)計(jì)人性化。文件接收功能集成在聊天窗體內(nèi)，文件發(fā)送窗體界面如圖 58所示。 ReceiverWorker 線程執(zhí)行的是 ReceiverStart()方法。若用戶拒絕文件傳入，則向遠(yuǎn)程主機(jī)發(fā)送一個(gè)拒絕信號(hào)。 SenderWorker線程執(zhí)行 SenderStart()方法。 用戶管理模塊實(shí)現(xiàn) 用戶管理模塊概述 不管是任何系統(tǒng)，都必然會(huì)有用戶這個(gè)角色，因此用戶管理是每一個(gè)應(yīng)用中必不可少的部分。模塊中只涉及到用戶一個(gè)模型，涉及到的屬性項(xiàng)目有 用戶 ID、 用戶名 (姓名 )、 密碼 、 注冊(cè)時(shí)間 等，其 ER 圖如圖 59所示。其中， version 是標(biāo)明此 XML 文件所用的標(biāo)準(zhǔn)的版本號(hào) ， encoding 指明了此 XML 文件中所使用的字符類型為 utf8。 文檔結(jié)構(gòu)如圖 510所示。若用戶名已被注冊(cè)，則通過(guò)服務(wù)器向客戶端返回用戶名已經(jīng)被注冊(cè)的提示信息。若 user節(jié)點(diǎn)不存在，則返回不存在信息，結(jié)束遍歷；否則進(jìn)入 user節(jié)點(diǎn)，對(duì)其子節(jié)點(diǎn) userName進(jìn)行對(duì)比。測(cè)試總是先假設(shè)程序中存在缺陷，再通過(guò)執(zhí)行程序來(lái)發(fā)現(xiàn)并最終改正缺陷。 測(cè)試只能證明缺陷存在，而不能證明缺陷不存在。 測(cè)試有助于提高軟件的質(zhì)量，但是提高軟件的質(zhì)量不能依賴于測(cè)試。 正確性測(cè)試 正確性測(cè)試檢查軟件的功能是否符合規(guī)格說(shuō)明。 當(dāng)兩個(gè)客戶端在建立連接時(shí)，出現(xiàn)過(guò)程序假死異常。連接斷開(kāi)后，重置 isconnected=false，將處理移交給用戶。 整個(gè)開(kāi)發(fā)過(guò)程中，共歷經(jīng) 200多次相互斷開(kāi)、連接測(cè)試， P2P文本聊天模塊終于可以正常運(yùn)行。 功能性測(cè)試 先在其中一臺(tái)機(jī)器 A上啟動(dòng)服務(wù)端軟 件，開(kāi)啟監(jiān)聽(tīng)服務(wù)。所以，功能測(cè)試為成功。當(dāng)系統(tǒng)本身發(fā)生錯(cuò)誤，比如網(wǎng)絡(luò)初始化失敗，綁定套接字失敗，數(shù)據(jù)讀取失敗等，都會(huì)進(jìn)行相對(duì)應(yīng)的正確處理。 文件傳輸?shù)臅r(shí)候，通過(guò)對(duì)文件長(zhǎng)度以及已傳輸信息量的相減運(yùn)算，顯示出當(dāng)前傳輸狀態(tài)，需要占用較多的系統(tǒng)計(jì)算資源和時(shí)間，而且傳輸速度相對(duì) IPMSG等軟件，慢太多。另外，此設(shè)計(jì)中未限制傳輸文件的大小，經(jīng)測(cè)試， 5GB以上的文件也能夠通過(guò)文件傳輸模塊進(jìn)行傳輸。本聊天工具使用過(guò)程中提示信息詳細(xì)，界面友好，操作簡(jiǎn)單，新 用戶能夠很快學(xué)會(huì)使用，所以具有比較好的易用性。否則，在完全滿足前一個(gè)請(qǐng)求之前，將無(wú)法處理其他的新的請(qǐng)