【正文】 ........... 錯(cuò)誤 !未定義書(shū)簽。 本文討論基于 TCP/IP 通信開(kāi)發(fā)聊天程序的關(guān)鍵技術(shù) ,重點(diǎn)討論 面向?qū)ο蠓椒?以及聊天程序的實(shí)現(xiàn)方法 ,并給出了相應(yīng)的 VC++代碼 . 網(wǎng)絡(luò)聊天軟件在國(guó)外的有 icq 等，在國(guó)內(nèi)的主要有騰訊的 Oicq，還有 Ticq,OmO 和一些在網(wǎng)頁(yè)上的即時(shí)通訊工具，像 Chinaren 網(wǎng)站上的 WebMaster 等等，都做得即美觀，且功能強(qiáng)大， Oicq 現(xiàn)在擁有非常大的用戶(hù)群。但是有服務(wù)器的通訊軟件，有著不可比擬的優(yōu)勢(shì)：可以發(fā)送離線消息，不管用戶(hù)當(dāng)時(shí)是否在線，下次上線時(shí)，就可以看到這條消息了。而且，那種通訊軟件，是以機(jī)器為通訊單 元的，而這種聊天軟件是以人為通訊單元。 雖然說(shuō)，現(xiàn)在這個(gè)軟件已經(jīng)有公司把它開(kāi)發(fā)出來(lái)了，我再做也不一定有新意，也未必可以做得更好，但作為畢業(yè)設(shè)計(jì)，也算是對(duì)我能力的一個(gè)考驗(yàn)和這四年來(lái) 我學(xué)習(xí)知識(shí)的一個(gè)檢查。 意義 以前聊天的方式早已離我們遠(yuǎn)去。甚至這種氣氛也滲透到了家庭內(nèi)部，我們與家人一起聊天的時(shí)間也越來(lái)越少。在人情淡薄懷舊氣氛濃重的九十年代末期，網(wǎng)絡(luò)聊天出現(xiàn)了。 “ 網(wǎng)聊 ” 借助網(wǎng)絡(luò)這種現(xiàn)代通訊手段在一定程度上恢復(fù)甚至拓展了傳統(tǒng)聊天在人們生活中失去的地盤(pán)。 任務(wù) 、 要求及問(wèn)題提出 、要求 本設(shè)計(jì)基于 TCP/IP 通信開(kāi)發(fā)聊 天程序，綜合利用 VC++程序設(shè)計(jì)語(yǔ)言，以 SQL 本科生畢業(yè)設(shè)計(jì)（論文） 2 Server20xx 數(shù)據(jù)庫(kù)做后臺(tái)開(kāi)發(fā)出一高效實(shí)用的聊天系統(tǒng)客戶(hù)端軟件。 隨著計(jì)算機(jī)應(yīng)用技術(shù)的日 益普及，網(wǎng)絡(luò)也遍及到我們生活的每個(gè)角落，很好的利用這人資源，將為我們的工作和學(xué)習(xí)，帶來(lái)極大的方便和提高工作效率，所以，開(kāi)發(fā)一個(gè)網(wǎng)絡(luò)里的 C/S 通訊軟件，是十分必要。由于采用面向?qū)ο蟮南到y(tǒng)模型可以使整個(gè)軟件系統(tǒng)的結(jié)構(gòu)變得更加靈活，本系統(tǒng)的結(jié)構(gòu)模型將采用面向?qū)ο蟮南到y(tǒng)模型 ,采用 VC++ 這個(gè)可視化開(kāi)發(fā)工具進(jìn)行編碼。 面向?qū)ο蠓椒▽W(xué)是一種全新的軟件工程方法，其出發(fā)點(diǎn)和基本原則是盡可能模 擬人類(lèi)習(xí)慣的思維方式，把構(gòu)成客觀世界的實(shí)體抽象為對(duì)象。 用面向?qū)ο蠓椒▽W(xué)開(kāi)發(fā)的軟件有以下優(yōu)點(diǎn)： ； ； ； 。而且其程序的功能也伴隨著網(wǎng)絡(luò)技術(shù)的發(fā)展而不斷的完善和發(fā)展，從最初的只支持文本式聊天 一直到 現(xiàn)在的圖文聊天 、 語(yǔ)音聊天 、 視頻對(duì)話(huà)等，技術(shù)越來(lái)越成熟可靠。 現(xiàn)在也有很多，在網(wǎng)絡(luò)上不使用服務(wù)器的通訊軟件，這種軟件小巧且方便，也能解決一部分問(wèn)題。可以保存用戶(hù)的個(gè)人信息或介紹，供人查看?？傊@種軟件在網(wǎng)絡(luò)上，還是有很大的用途的，為網(wǎng)絡(luò)上通訊，帶來(lái)極大的方便。它包括非正式的私人談話(huà)，如家人團(tuán)聚、鄰居串門(mén)、朋友造訪，也包括一些較為隨意的多人集會(huì)如酒會(huì)、沙龍和座談會(huì)。傳統(tǒng)聊天具有多重社會(huì)功能，比如交流情感、促進(jìn)友誼、擴(kuò)散信息等等，但最主要的還是消閑，一種有效的排解無(wú)聊的手段 —— 無(wú)聊這一詞的字面意思就是指 “ 不值一聊 ” 。梁實(shí)秋的 “ 雅舍小品 ” 里有專(zhuān)文談聊天的好處。雖然電話(huà)和網(wǎng)絡(luò)提供了遠(yuǎn)程的即時(shí)交流手段，但是現(xiàn)代社會(huì)一方面加快了人們的生活和工作節(jié)奏，另一方面以商業(yè)化的手段向人們提供了更多消閑方式，其中電視就擠占了我們?cè)却罅康牧奶鞎r(shí)間。茶余飯后不再是門(mén)前一張板凳圍在一起胡 侃，而是每家每戶(hù)坐在封閉的單元房?jī)?nèi)面對(duì)一臺(tái)電子顯像管。電視并不促進(jìn)觀眾思考，也不會(huì)根據(jù)觀眾收看時(shí)的反應(yīng) 做 出調(diào)整。電視雖然對(duì)人類(lèi)消閑時(shí)間的爭(zhēng)奪戰(zhàn)中勝出，但它卻不可能滿(mǎn)足人類(lèi)所有的需要，尤其是傳統(tǒng)聊天能夠滿(mǎn)足的那些需要。這時(shí)，一種新的聊天形式借助網(wǎng)絡(luò)生長(zhǎng)出來(lái)，填補(bǔ)了人們的精神空白。但它并非是傳統(tǒng)聊天在網(wǎng)絡(luò)上簡(jiǎn)單的呈現(xiàn)和復(fù)制，它具有并 非本質(zhì)但十分重要的特殊性質(zhì)。網(wǎng)絡(luò)聊天的現(xiàn)實(shí)存在不可能因?yàn)槔蠋熀图议L(zhǎng)的反對(duì)而消除，也不會(huì)因?yàn)槟衬撤ㄒ?guī)的出臺(tái)而被管制。語(yǔ)音聊天更為經(jīng)濟(jì)快捷，單位時(shí)間傳遞的信息量也更大。等有一天，我們都可以像打免費(fèi)電話(huà)那樣語(yǔ)音聊天時(shí)，我們還會(huì)懷念當(dāng)年那段 “ 此時(shí)無(wú)聲勝有聲 ” 的網(wǎng)絡(luò)聊天故事嗎？ 本科生畢業(yè)設(shè)計(jì)（論文） 5 第二章 設(shè)計(jì)原理和過(guò)程 用戶(hù)需求分析 提供基于 TCP/IP 網(wǎng)絡(luò)的即時(shí)消息傳送、 大小圖標(biāo)方式 、實(shí)時(shí)聊天、 多人聊天 等功能。 可以同時(shí)發(fā)送同一個(gè)消息給多人，通過(guò)輸入這些人的號(hào)碼列表或姓名列表 。 即使用戶(hù)不在線，也能通過(guò)服務(wù)器發(fā)送離線消息 。 提供查看在線的人的功能 。 小窗口顯示，不占用屏幕很大的空間 。 可以實(shí)時(shí)顯示用戶(hù)的狀態(tài)和隨時(shí)改變自己的狀態(tài) 。 好友上線通知 。 查看好友信息 。 在好友列表中刪除某人 。 系統(tǒng)設(shè)置 。 速度快，占用資源少 。因?yàn)槭褂?UDP 協(xié)議進(jìn)行通訊，所以要自己控制其可靠性。當(dāng)然，發(fā)回來(lái)的確認(rèn)信息也可能丟失，但確認(rèn)信息很短，相對(duì)來(lái)說(shuō)，丟失的機(jī)率會(huì)小一些，是一個(gè)折中的辦法。服務(wù)器的數(shù)據(jù)庫(kù)采用的是 ODBC 的 SQL20xx 數(shù)據(jù)源，服務(wù)器訪問(wèn)數(shù)據(jù)庫(kù)，用的是 MFC 中的本科生畢業(yè)設(shè)計(jì)（論文） 6 CDatabase 和 CRecordset，因?yàn)?，?duì)數(shù)據(jù) 庫(kù)的操作簡(jiǎn)單，服務(wù)器端，我只要功能，不需做界面，所以使用 Sql 語(yǔ)句直接訪問(wèn)數(shù)據(jù)庫(kù)，已經(jīng)足夠滿(mǎn)足要求了。在線程里，按照接受到數(shù)據(jù)的類(lèi)別，進(jìn)行相應(yīng)的處理，如有需要，會(huì)向用戶(hù)發(fā)送處理的結(jié)果，或成功或失敗的消息，處理結(jié)束后，線程就結(jié)束了。 服務(wù)器端主要是為用戶(hù)存儲(chǔ)必要的信息，協(xié)調(diào)用戶(hù)之間 的通訊，服務(wù)器端的設(shè)計(jì)，主要在功能上面。 客戶(hù)端的運(yùn)行流程為： 若有本地用戶(hù)信息，則取出本地用戶(hù)信息，顯示登陸窗口，若沒(méi)有，則顯示用戶(hù)注冊(cè)窗口（在登陸窗口里，也可以選擇用戶(hù)注冊(cè)）。不在線的人，將以灰色顯示。如果有好友上線了，就會(huì)通知你，好友下線了，你也可以在好友列表中看到，你可能接受到別人給你發(fā)送的消息。 客戶(hù)端主要是提供給用戶(hù)一個(gè)友好的用戶(hù)界面，方便用戶(hù)操作，客戶(hù)端主要負(fù)責(zé)從服務(wù)器上得到數(shù)據(jù)后，顯示給用戶(hù)?？蛻?hù)端主要是界面的設(shè)計(jì)（除了底層通訊的以外），根據(jù)不同的要求，向服務(wù)器發(fā)送各種類(lèi)型的請(qǐng)求。客戶(hù)端的界面的設(shè)計(jì)很繁瑣，沒(méi)有詳細(xì)介紹的必要，所以， 我的重點(diǎn) 將放在服務(wù)器的設(shè)計(jì)上。 系統(tǒng)模塊設(shè)計(jì) 聊天系統(tǒng)將分為 六 大 模塊，包括用 查找 戶(hù)模塊， 查找在線用戶(hù) 模塊， 發(fā)群體消息 模塊 ，系統(tǒng)參數(shù)模塊，個(gè)人設(shè)定模塊，關(guān)于模塊 ?，F(xiàn)實(shí)世界的事物反映到人的頭腦中，人的大腦對(duì)它有個(gè)認(rèn)識(shí)過(guò)程，經(jīng)過(guò)分析（選擇、命名、分類(lèi)等）進(jìn)入信息世界。這兩個(gè)問(wèn)題貫穿了整個(gè)軟件系統(tǒng)的開(kāi)發(fā)過(guò)程，這也就是數(shù)據(jù)庫(kù)的設(shè)計(jì)問(wèn)題，也是軟件設(shè)計(jì)的一個(gè)核心。目前廣泛使用的數(shù) 據(jù)模型可分為兩種類(lèi)型，一種是獨(dú)立于計(jì)算機(jī)系統(tǒng)的“概念數(shù)據(jù)模型”如“實(shí)體聯(lián)系模型”， 另一種是直接面向數(shù)據(jù)庫(kù)邏輯結(jié)構(gòu)的“結(jié)構(gòu)數(shù)據(jù)模型”。 ER 模型直接從現(xiàn)實(shí)世界抽象出實(shí)體類(lèi)型 及實(shí)體間聯(lián)系，然后用 ER圖來(lái)表示數(shù)據(jù)模型。但 ER 模型只能說(shuō)明實(shí)體間語(yǔ)義的聯(lián)系，不能進(jìn)一步說(shuō)明詳細(xì)的數(shù)據(jù)結(jié)構(gòu)，它只是數(shù)據(jù)庫(kù)設(shè)計(jì)的第一步。 ，表示聯(lián)系類(lèi)型（實(shí)體間的聯(lián)系）。對(duì)于主鍵碼的屬性，如下表示：屬性名（ *）。 本系統(tǒng)為聊天系統(tǒng)客 戶(hù)端的實(shí)現(xiàn)，主要是聊天為主 ,考慮了多方面的因素以后，確定系統(tǒng)圖如下：下面就是各實(shí)體及聯(lián)系類(lèi)型的屬性圖：（為了表達(dá)的方便，在這里我沒(méi)有在一張圖上表達(dá)出所有的關(guān)系，而是分別采用實(shí)體屬性關(guān)系圖（即 ER 圖）來(lái)表達(dá)數(shù)據(jù)庫(kù)的結(jié)構(gòu)?？偣灿?三 個(gè)表： 用戶(hù)信息表（ Users）好友信息表（ Friends）離線消息表（ OffMsg） 表 21 用戶(hù)信息表（ Users） 字段名稱(chēng) 說(shuō)明 長(zhǎng)度 UserId（主鍵） 自動(dòng)編號(hào) 4 字節(jié)長(zhǎng)整形 Id 用戶(hù)帳號(hào) 4 字節(jié)長(zhǎng)整形 Photoid 用戶(hù)的圖象編號(hào) 4 字節(jié)長(zhǎng)整形 password 用戶(hù)登陸的密碼 字符串 name 用戶(hù)的姓名 字符串 sex 用戶(hù)的性別 單字節(jié)整形 0 男 1 女 2 未知 age 用戶(hù)的年齡 字符串 （為了適應(yīng)不 愿填寫(xiě)此項(xiàng)的人） canbeadd 能否被人加為好友 單字節(jié)整形 (0,1,2 不能被加入 ,允許被任何人加入 ,需要身份驗(yàn)證 ) 自己賬號(hào) 朋友賬號(hào)自動(dòng)編號(hào)好友信息離線消息自動(dòng)編號(hào) 接收者賬號(hào) 發(fā)送者賬號(hào) 接收時(shí)間本科生畢業(yè)設(shè)計(jì)（論文） 9 電子信箱 字符串 homepage 個(gè)人主頁(yè) 字符串 address 地址 字符串 phone 電話(huà) 字符串 fax 傳真 字符串 department 部門(mén) 字符串 description 個(gè)人簡(jiǎn)介 字符串 表 22 好友信息表（ Friends） 字段名稱(chēng) 說(shuō)明 長(zhǎng)度 Num（主鍵） 自動(dòng)編號(hào) 4 字節(jié)長(zhǎng)整形 MyId 自己帳號(hào) 4 字節(jié)長(zhǎng)整形 FriendId 朋友帳號(hào) 4 字節(jié)長(zhǎng)整形 表 23 離線消息表（ OffMsg） 字段名稱(chēng) 說(shuō)明 長(zhǎng)度 MsgId（主鍵） 自動(dòng)編號(hào) 4 字節(jié)長(zhǎng)整形 RecvId 接受者 帳號(hào) 4 字節(jié)長(zhǎng)整形 SenderId 發(fā)送者 帳號(hào) 4 字節(jié)長(zhǎng)整形 RecvTime 接受 時(shí)間 4 字節(jié)長(zhǎng)整形 nIndex 發(fā)送消息 類(lèi)型 4 字節(jié)長(zhǎng)整形 Msg 發(fā)送 消息 備注類(lèi)型 客戶(hù) /服務(wù)器程序 設(shè)計(jì) C/S 模型也是一種網(wǎng)絡(luò)模型，但與前述的模型不同，它并不是定義了網(wǎng)絡(luò)的層次結(jié)構(gòu)，而是描述了一種網(wǎng)絡(luò)程序運(yùn)行的方式?？蛻?hù)方對(duì)服務(wù)器方發(fā)送信息請(qǐng)求，服務(wù)器方對(duì)其做出相應(yīng)回答，提供服務(wù)。服務(wù)程序通常在一個(gè)眾所周知的地址監(jiān)聽(tīng)對(duì)服務(wù)的請(qǐng)求，也就是說(shuō)，服務(wù)進(jìn)程一直處于休眠狀態(tài)，直到一個(gè)客戶(hù)程序提出了請(qǐng)求信息。雖然基于連接的服務(wù)是設(shè)計(jì) C/S 應(yīng)用程序的標(biāo)準(zhǔn)，但有些服務(wù)也是可以通過(guò)數(shù)據(jù)報(bào) Socket 提供的。但是，也可以設(shè)計(jì)同時(shí)完成這兩種功能的程序，例如，一些服務(wù)器程序如果不能完成一個(gè)服務(wù)請(qǐng)求時(shí)，它將轉(zhuǎn)而充當(dāng)客戶(hù)程序，向其它服務(wù)器程序請(qǐng)求信息。 為了充分理解 TCP/IP 協(xié)議族，必須理解幾個(gè)重要術(shù)語(yǔ)。這些術(shù)語(yǔ)進(jìn)一步描述了與網(wǎng)絡(luò)連接、協(xié)議可靠性以及數(shù)據(jù)服務(wù)有關(guān)的協(xié)議特性。你知道， TCP 傳輸層通過(guò)協(xié)議端口和應(yīng)用程序（像服務(wù)器和客戶(hù)）通信，也就是說(shuō)，為了按收客戶(hù)請(qǐng)求，服務(wù)器程序必須對(duì)傳輸層的一個(gè)特定協(xié)議端口進(jìn)行偵聽(tīng)。也就是說(shuō)，程序告訴 socket執(zhí)行體使用哪－個(gè)協(xié)議端口進(jìn)行數(shù)據(jù)傳送。 使用無(wú)連接協(xié)議的程序和使用面向連接協(xié)議的服務(wù)器程序之間的主要相似之處是它們都必須對(duì)一個(gè)協(xié) 議端口進(jìn)行偵聽(tīng)。同樣，由于無(wú)連接客戶(hù)程序沒(méi)有和遠(yuǎn)地主機(jī)建立直接連接，所以它也必須對(duì)協(xié)議端口進(jìn)行偵聽(tīng)，以便接收以對(duì)它服務(wù)請(qǐng)求產(chǎn)生的數(shù)據(jù)報(bào)應(yīng)答。 下面程序行顯示了一個(gè)典型的函數(shù)調(diào)用： result＝ bind ( socket_handle, local_structure, socket_address, address_ length) 無(wú)連 接客戶(hù)程序也對(duì)一個(gè)協(xié)議端口進(jìn)行偵聽(tīng)。無(wú)連接客戶(hù)程序使用數(shù)據(jù)報(bào)發(fā)送網(wǎng)絡(luò)服務(wù)請(qǐng)求，它不建立點(diǎn)到點(diǎn)連接。與服務(wù)器程序一樣，無(wú)連接客戶(hù)程序也使用 bind 函數(shù)讓 Socket 執(zhí)行體登記協(xié)議端口。 Socket執(zhí)行體處理傳輸層內(nèi) UDP 軟件模塊和客戶(hù) 程序之間的接口。實(shí)際所稱(chēng)的 TCP/IP 協(xié)議包括了在國(guó)際互聯(lián)網(wǎng)絡(luò)應(yīng)用的一組協(xié)議，互聯(lián)網(wǎng)協(xié)議族是此協(xié)議族的另一個(gè)名字。 TCP 傳輸控制協(xié)議（ Transmission Control Protocol），負(fù)責(zé) 在應(yīng)用程序之間傳遞數(shù)據(jù)。 ICMP互連網(wǎng)控制報(bào)文協(xié)議（ Inter Control Message Protocol），處理主機(jī)間的差錯(cuò)和傳送控制。 RARP 反向地址解析協(xié)（ Reverse Address Resolution Protocol） ，負(fù)責(zé)將鏈路層地址轉(zhuǎn)換成網(wǎng)絡(luò)層地址。 TCP/IP 網(wǎng)絡(luò)環(huán)境下的應(yīng)用程序設(shè)計(jì)是通過(guò)網(wǎng)絡(luò)系統(tǒng)編程界面 Socket 實(shí)現(xiàn)的， Socket 提供應(yīng)用程序與系統(tǒng)內(nèi)核之間的網(wǎng)絡(luò)編程接口。可靠的協(xié)議意味著當(dāng)數(shù)據(jù)通過(guò)協(xié)議傳遞時(shí)，協(xié)議保證數(shù)據(jù)正確傳輸。首先，為了確保數(shù)據(jù)正確傳送，協(xié)議在通信應(yīng)用程序之間互相交換確認(rèn)信息。如果發(fā)送程序沒(méi)有收到這樣一個(gè)確認(rèn)信息，程序?qū)⒆詣?dòng)重新發(fā)送此報(bào)文，直到得到應(yīng)答信息為止。接收計(jì)算機(jī)重新計(jì)算校驗(yàn)和，與收到的校驗(yàn)和進(jìn)行比較。 傳輸控制協(xié)議 TCP是一個(gè)使用校驗(yàn)和 確認(rèn)信息以及其它可靠數(shù)據(jù)傳輸技術(shù)的可靠協(xié)議。協(xié)議試圖傳輸數(shù)據(jù)，但不保證成功?？蓪⒉豢煽繑?shù)據(jù)傳輸比作沒(méi)有返回地址的信件。即使發(fā)送地址是正確的，也不能保證郵遞系統(tǒng)不丟失你的信件。協(xié)議不管要求發(fā)送或接收數(shù)據(jù)的長(zhǎng)度和傳送數(shù)目，只是將數(shù)據(jù)看作一個(gè)簡(jiǎn)單的字節(jié)串流。協(xié)議單獨(dú)發(fā)送每個(gè)數(shù)據(jù)報(bào) —— 數(shù)據(jù)報(bào)之間不相互依賴(lài)。連接的接收方可以按每次 20 字節(jié)讀數(shù)據(jù)（要讀 5 次）。 字節(jié)流協(xié)議不關(guān)心每個(gè)數(shù)據(jù)段的長(zhǎng)度。相比之下，傳輸?shù)酵荒康牡氐亩鄠€(gè)數(shù)據(jù)報(bào)可能不會(huì)按發(fā)送順序到達(dá)。用戶(hù)數(shù)據(jù)報(bào)協(xié)議和互連網(wǎng)協(xié)議使用數(shù)據(jù)報(bào)傳輸數(shù)據(jù)。如果你在同一天給同一個(gè)人郵寄兩封信 ，你無(wú)法知道那個(gè)人先本科生畢業(yè)設(shè)計(jì)（論文） 13 收到那封信。收到信的順序和發(fā)送順序可能相反。 IP 數(shù)據(jù)報(bào)保存目的和源 IP 地址，同樣傳輸協(xié)議也保存源和目的端口號(hào)。你可能編寫(xiě)過(guò)往硬件端口送數(shù)