網(wǎng)絡聊天系統(tǒng)開發(fā)設計與實現(xiàn)畢業(yè)論文(編輯修改稿)
2024-07-25 21:16 本頁面
【文章內容簡介】 第 8 頁 共 24 頁 圖 1 用戶數(shù)據(jù)報頭格式源端口是可選域，當其有意義時，它指的是發(fā)送進程的端口，這也就假定了在沒有其它信息的情況下，返回信息應該向什么地方發(fā)送。如果不使用它，則在此域中填 0。目的端口在有特定的目的網(wǎng)絡地址時有意義。長度指的是此用戶數(shù)據(jù)報長度的八進制表示。 （這表明最小的數(shù)據(jù)報長度是 8。 ）校驗碼有 16 位，是對 IP 頭，UDP 頭和數(shù)據(jù)中信息包頭的數(shù)位取反之和再取反得到的。包頭從概念上說是在 UDP 頭信息之前的，它包括有源地址，目的地地址，所使用的協(xié)議和UDP 長度。這些信息使信息不能被錯誤地接收。這個校驗過程與 TCP 中使用的過程一致。圖 2 用戶數(shù)據(jù)報頭格式如果計算出的校驗碼為零，它將被全零發(fā)送。全零的校驗值意味著發(fā)送者未產生校驗碼。用戶接口用戶接口應該允許創(chuàng)建新的接收端口，在接收端口的接收操作有：應該返回一個八進制數(shù)說明源端口和源地址，允許數(shù)據(jù)報傳送，指定數(shù)據(jù)，源和目標端口和目的地地址。IP 層接口UDP 模塊必須能夠決定源和目標的網(wǎng)絡地址，而且必須能夠從包頭中得知所使用的協(xié)議。一個可能的接口方式是返回整個數(shù)據(jù)報，包括接收操作返回的包頭。這樣的接口還應該允許 UDP 向IP 傳送完整的帶包頭的數(shù)據(jù)報用于傳送。由 IP 來確定一致性并計算校驗碼。協(xié)議應用此協(xié)議的最主要的用途是網(wǎng)際名稱服務器和小文件傳輸協(xié)議。協(xié)議號 山東英才職業(yè)技術學院 計算機應用技術專業(yè)畢業(yè)（設計）論文題目：網(wǎng)絡聊天系統(tǒng)的設計與實現(xiàn) 第 9 頁 共 24 頁 在 IP 中使用它時，它的協(xié)議號是 17（八進制中是 21） 。 協(xié)議 軟件環(huán)境 Microsoft Windows 98 中文版；Windows NT（ 以上）或 Windows 2022 操作系統(tǒng)；Delphi 。 山東英才職業(yè)技術學院 計算機應用技術專業(yè)畢業(yè)（設計）論文題目：網(wǎng)絡聊天系統(tǒng)的設計與實現(xiàn) 第 10 頁 共 24 頁 二、UDP 協(xié)議簡介 的定義UDP（User Datagram Protocol）協(xié)議就是“用戶數(shù)據(jù)報協(xié)議”，它是一種無連接的協(xié)議，無連接主要是和 TCP 協(xié)議相比較的。我們知道當利用 TCP 協(xié)議傳送數(shù)據(jù)的時候，首先必須先建立連接（也就是所謂的握手）才可以傳輸數(shù)據(jù)。而當計算機利用 UDP 協(xié)議進行數(shù)據(jù)傳輸?shù)臅r候，發(fā)送方只需要知道對方的 IP 地址和端口號就可以發(fā)送數(shù)據(jù)，而并不需要進行連接。當然如果你非要進行連接，通過 VisualB＃也是可以實現(xiàn)的，但前提是要確定連接的遠程主機的端口號處于監(jiān)聽狀態(tài)，否則程序會出現(xiàn)不必要的錯誤，但這是種畫蛇添足的做法，不僅丟失了 UDP 協(xié)議的無連接傳送數(shù)據(jù)的特點和優(yōu)點，而且還給程序運行帶來了不安定的因素。所以這種方法并不值得提倡。 的組成UDP 信息包由 UDP 標題和數(shù)據(jù)組成。UDP 的標題結構如圖 1521 所示,它由 5 個域組成：服務器(socket( ))、客戶機(socket( ))、用戶數(shù)據(jù)包的長度(Length)和檢查和（Checksum)。其中，前 4個域組成 UDP 標題(UDPheader)，每個域由 4 個字節(jié)組成；檢查和域占據(jù) 2 個字節(jié)，它用來檢測傳輸過程中是否出現(xiàn)了錯誤；用戶數(shù)據(jù)包的長度包括所有 5 個域的字節(jié)數(shù)。 服 務 器 socket( ) bind( ) recvfrom( ) sendto( ) 阻 塞 ， 等 待 客 戶 數(shù) 據(jù) 處 理 服 務 請 求 socket( ) bind( ) sendto( ) recvfrom( ) 客 戶 機 服 務 請 求 服 務 應 答 無 連 接 套 接 口 應 用 程 序 時 序 圖 closesocket( ) closesocket( ) UDP 信息包的標題結構檢查和的詳細計算可在 RFC1071 中找到，現(xiàn)舉一例說明使用檢查和檢測錯誤的道理。例如， 山東英才職業(yè)技術學院 計算機應用技術專業(yè)畢業(yè)（設計）論文題目：網(wǎng)絡聊天系統(tǒng)的設計與實現(xiàn) 第 11 頁 共 24 頁 假設從源端 A 要發(fā)送下列 3 個 16 位的二進制數(shù)： word1，word2 和 word3 到終端 B，檢查和計算如下： word10110011001100110word20101010101010101word30000111100001111sum=word1+ word2+ word31100101011001010檢查和(sum 的反碼)0011010100110101從發(fā)送端發(fā)出的 4 個(word1，2，3 以及檢查和)16 位二進制數(shù)之和為 1111111111111111，如果接收端收到的這 4 個 16 位二進制數(shù)之和也是全“1”，就認為傳輸過程中沒有出差錯。許多鏈路層協(xié)議都提供錯誤檢查，包括流行的以太網(wǎng)協(xié)議，讀者也許想知道為什么 UDP 也要提供檢查和。其原因是鏈路層以下的協(xié)議在源端和終端之間的某些通道可能不提供錯誤檢測。雖然 UDP 提供有錯誤檢測，但檢測到錯誤時，UDP 不做錯誤校正，只是簡單地把損壞的消息段扔掉，或者給應用程序提供警告信息。讀者也可能會問，收發(fā)兩端的兩個進程是否有可能通過 UDP 提供可靠的數(shù)據(jù)傳輸？答案是可以的。但必需要把確認和重傳措施加到應用程序中，應用程序不能指望 UDP 來提供可靠的數(shù)據(jù)傳輸。由于 UDP 協(xié)議并不需要進行確定的連接，所以編寫基于 UDP 協(xié)議的應用程序比起編寫基于TCP 協(xié)議的應用程序要簡單些（程序中可以不需要考慮連接和一些異常的捕獲工作） 。但同時也給基于 UDP 協(xié)議編寫的程序帶來了一個致命的缺點， UDP 由于不提供可靠數(shù)據(jù)的傳輸，當計算機之間利用 UDP 協(xié)議傳送數(shù)據(jù)的時候，發(fā)送方只管發(fā)送數(shù)據(jù)，而并不確認數(shù)據(jù)是否被對方接收。這樣就會導致某些 UDP 協(xié)議數(shù)據(jù)包在傳送的過程中丟失，尤其網(wǎng)絡質量不令人滿意的情況下，丟失數(shù)據(jù)包的現(xiàn)象會更嚴重。這就是為什么在網(wǎng)絡上傳輸重要數(shù)據(jù)不采用 UDP 協(xié)議的原因。但是我們也不能因為這一個缺點就全面否定 UDP 協(xié)議，這是因為雖然利用 UDP 協(xié)議來傳送安全性要求高的數(shù)據(jù)是不適合的，但對于那些不重要的數(shù)據(jù)，或者即使丟失若干數(shù)據(jù)包也不影響整體性的數(shù)據(jù)，如音頻數(shù)據(jù)，視頻數(shù)據(jù)等，采用 UDP 協(xié)議就是一個非常不錯的選擇。如目前網(wǎng)絡流行的很多即時聊天程序，如 OICQ 和 ICQ 等，采用的就是 UDP 協(xié)議。同時雖然 UDP 協(xié)議無法 山東英才職業(yè)技術學院 計算
環(huán)評公示相關推薦
鄂ICP備17016276號-1