【正文】 ......................................................................................21 山東英才職業(yè)技術(shù)學(xué)院 計算機(jī)應(yīng)用技術(shù)專業(yè)畢業(yè)（設(shè)計）論文題目：網(wǎng)絡(luò)聊天系統(tǒng)的設(shè)計與實現(xiàn) 第 4 頁 共 24 頁 摘 要紹了無連接協(xié)議的 SOCKET 編程模型,以及闡述了聊天程序的設(shè)計目的前景和具體規(guī)劃,還有聊天程.第一部分簡單的分析了即時聊天系統(tǒng)開發(fā)的可行性，并重點對技術(shù)可行性（選擇 VB）做了詳細(xì)分析；第二部分借助數(shù)據(jù)流圖和數(shù)據(jù)字典對系統(tǒng)的功能和性能進(jìn)行了詳細(xì)的需求分析，建立了系統(tǒng)的邏輯結(jié)構(gòu)；第三部分利用 VB 程序設(shè)計了 UDP 聊天程序；第四部分驗證了設(shè)計的程序；第五部分是此次設(shè)計的結(jié)論總結(jié)及部分參考文獻(xiàn)和附錄。 The second part has carried on the detailed demand analysis with the aid of the data flow graph and the data dictionary to the system function and the performance, has established the system logical anization。 The fourth part has confirmed the design procedure。因此，兩臺計算機(jī)之間進(jìn)行即時通訊、發(fā)送文件等交流方式已經(jīng)成為必然潮流。目前，用于實現(xiàn)單一的即時通訊、文件共享的軟件實在太少，而且，它們中大部分都是絕對的Ｃ／Ｓ模式，對遠(yuǎn)程服務(wù)器有非常大的依賴性，沒有徹底實現(xiàn)點對點的交流。本軟件屬于點對點連接的，在連接并通信時，尤其是近程的即時通訊，徹底的脫離了遠(yuǎn)程的服務(wù)器，避免了和遠(yuǎn)程服務(wù)器連接時過多的浪費(fèi)網(wǎng)絡(luò)資源。包括網(wǎng)絡(luò)視頻會議系統(tǒng)在內(nèi)的眾多的客戶/服務(wù)器模式的網(wǎng)絡(luò)應(yīng)用都需要使用 UDP 協(xié)議。 (2) 與我們所熟知的 TCP（傳輸控制協(xié)議）協(xié)議一樣，UDP 協(xié)議直接位于 IP（網(wǎng)際協(xié)議）協(xié)議的頂層。(3) UDP 協(xié)議的主要作用是將網(wǎng)絡(luò)數(shù)據(jù)流量壓縮成數(shù)據(jù)報的形式。每一個數(shù)據(jù)報的前 8 個字節(jié)用來包含報頭信息，剩余字節(jié)則用來包含具體的傳輸數(shù)據(jù)。雖然 UDP 是一個不可靠的協(xié)議，但它是分發(fā)信息的一個理想?yún)f(xié)議。UDP 也用在路由信息協(xié)議 RIP(Routing Information Protocol)中修改路由表。UDP 廣泛用在多媒體應(yīng)用中，例如，Progressive Networks 公司開發(fā)的 RealAudio 軟件，它是在因特網(wǎng)上把預(yù)先錄制的或者現(xiàn)場音樂實時傳送給客戶機(jī)的一種軟件，該軟件使用的 RealAudio audioondemand protocol 協(xié)議就是運(yùn)行在 UDP 之上的協(xié)議，大多數(shù)因特網(wǎng)電話軟件產(chǎn)品也都運(yùn)行在UDP 之上。此協(xié)議默認(rèn)認(rèn)為網(wǎng)路協(xié)議（IP）是其下層協(xié)議。此協(xié)議是面向操作的，未提供提交和復(fù)制保護(hù)。數(shù)據(jù)報格式如下： 山東英才職業(yè)技術(shù)學(xué)院 計算機(jī)應(yīng)用技術(shù)專業(yè)畢業(yè)（設(shè)計）論文題目：網(wǎng)絡(luò)聊天系統(tǒng)的設(shè)計與實現(xiàn) 第 8 頁 共 24 頁 圖 1 用戶數(shù)據(jù)報頭格式源端口是可選域，當(dāng)其有意義時，它指的是發(fā)送進(jìn)程的端口，這也就假定了在沒有其它信息的情況下，返回信息應(yīng)該向什么地方發(fā)送。目的端口在有特定的目的網(wǎng)絡(luò)地址時有意義。 （這表明最小的數(shù)據(jù)報長度是 8。包頭從概念上說是在 UDP 頭信息之前的，它包括有源地址，目的地地址，所使用的協(xié)議和UDP 長度。這個校驗過程與 TCP 中使用的過程一致。全零的校驗值意味著發(fā)送者未產(chǎn)生校驗碼。IP 層接口UDP 模塊必須能夠決定源和目標(biāo)的網(wǎng)絡(luò)地址，而且必須能夠從包頭中得知所使用的協(xié)議。這樣的接口還應(yīng)該允許 UDP 向IP 傳送完整的帶包頭的數(shù)據(jù)報用于傳送。協(xié)議應(yīng)用此協(xié)議的最主要的用途是網(wǎng)際名稱服務(wù)器和小文件傳輸協(xié)議。 協(xié)議 軟件環(huán)境 Microsoft Windows 98 中文版；Windows NT（ 以上）或 Windows 2022 操作系統(tǒng)；Delphi 。我們知道當(dāng)利用 TCP 協(xié)議傳送數(shù)據(jù)的時候，首先必須先建立連接（也就是所謂的握手）才可以傳輸數(shù)據(jù)。當(dāng)然如果你非要進(jìn)行連接，通過 VisualB＃也是可以實現(xiàn)的，但前提是要確定連接的遠(yuǎn)程主機(jī)的端口號處于監(jiān)聽狀態(tài)，否則程序會出現(xiàn)不必要的錯誤，但這是種畫蛇添足的做法，不僅丟失了 UDP 協(xié)議的無連接傳送數(shù)據(jù)的特點和優(yōu)點，而且還給程序運(yùn)行帶來了不安定的因素?！?的組成UDP 信息包由 UDP 標(biāo)題和數(shù)據(jù)組成。其中，前 4個域組成 UDP 標(biāo)題(UDPheader)，每個域由 4 個字節(jié)組成；檢查和域占據(jù) 2 個字節(jié)，它用來檢測傳輸過程中是否出現(xiàn)了錯誤；用戶數(shù)據(jù)包的長度包括所有 5 個域的字節(jié)數(shù)。例如， 山東英才職業(yè)技術(shù)學(xué)院 計算機(jī)應(yīng)用技術(shù)專業(yè)畢業(yè)（設(shè)計）論文題目：網(wǎng)絡(luò)聊天系統(tǒng)的設(shè)計與實現(xiàn) 第 11 頁 共 24 頁 假設(shè)從源端 A 要發(fā)送下列 3 個 16 位的二進(jìn)制數(shù)： word1，word2 和 word3 到終端 B，檢查和計算如下： word10110011001100110word20101010101010101word30000111100001111sum=word1+ word2+ word31100101011001010檢查和(sum 的反碼)0011010100110101從發(fā)送端發(fā)出的 4 個(word1，2，3 以及檢查和)16 位二進(jìn)制數(shù)之和為 1111111111111111，如果接收端收到的這 4 個 16 位二進(jìn)制數(shù)之和也是全“1”，就認(rèn)為傳輸過程中沒有出差錯。其原因是鏈路層以下的協(xié)議在源端和終端之間的某些通道可能不提供錯誤檢測。讀者也可能會問，收發(fā)兩端的兩個進(jìn)程是否有可能通過 UDP 提供可靠的數(shù)據(jù)傳輸？答案是可以的。由于 UDP 協(xié)議并不需要進(jìn)行確定的連接，所以編寫基于 UDP 協(xié)議的應(yīng)用程序比起編寫基于TCP 協(xié)議的應(yīng)用程序要簡單些（程序中可以不需要考慮連接和一些異常的捕獲工作） 。這樣就會導(dǎo)致某些 UDP 協(xié)議數(shù)據(jù)包在傳送的過程中丟失，尤其網(wǎng)絡(luò)質(zhì)量不令人滿意的情況下，丟失數(shù)據(jù)包的現(xiàn)象會更嚴(yán)重。但是我們也不能因為這一個缺點就全面否定 UDP 協(xié)議，這是因為雖然利用 UDP 協(xié)議來傳送安全性要求高的數(shù)據(jù)是不適合的，但對于那些不重要的數(shù)據(jù)，或者即使丟失若干數(shù)據(jù)包也不影響整體性的數(shù)據(jù)，如音頻數(shù)據(jù)，視頻數(shù)據(jù)等，采用 UDP 協(xié)議就是一個非常不錯的