【正文】 字接口，區(qū)分來(lái)自不同應(yīng)用程序進(jìn)程或網(wǎng)絡(luò)連接的通信，實(shí)現(xiàn)數(shù)據(jù)傳輸?shù)牟l(fā)服務(wù) 開(kāi)發(fā)平臺(tái)簡(jiǎn)介 Linux 系統(tǒng)簡(jiǎn)介 Linux 操作系統(tǒng)是 UNIX 操作系統(tǒng)的一種克隆系統(tǒng)。 既然 UDP 是一種不可靠的網(wǎng)絡(luò) 協(xié)議 ，那么還有什么使用價(jià)值或必要呢？其實(shí)不然，在有些情況下 UDP 協(xié)議 可能會(huì)變得非常有用。 UDP 協(xié)議 UDP 協(xié)議 是英文 User Datagram Protocol 的縮寫(xiě)，即用戶(hù)數(shù)據(jù)報(bào) 協(xié)議 ，主要用來(lái)支持那些需要在計(jì)算機(jī)之間傳輸數(shù)據(jù)的網(wǎng)絡(luò)應(yīng)用。 TCP 是面向連接的端到端的可靠協(xié)議 ,并保證傳送數(shù)據(jù)包的順序，而順序是用一個(gè)響應(yīng)序號(hào)來(lái)保證的，這個(gè)響應(yīng)序號(hào)告訴接收者發(fā)送 者期望的下一個(gè)包。 與 IP 協(xié)議相結(jié)合， TCP 代表了網(wǎng)絡(luò)協(xié)議的核心。 本章小結(jié) 需求是開(kāi)發(fā)的前提，只有明確了需求才能開(kāi)發(fā)出一個(gè)符合用戶(hù)期望的優(yōu)質(zhì)軟件。 總體性能需求 服務(wù)器端性能需求 服務(wù)器 需要 同時(shí)連接很多個(gè)用戶(hù)，并能提供給這些連接用戶(hù)所需要的任務(wù)處理請(qǐng)求，這就要求服務(wù)器能同時(shí)處理多個(gè) socket 連接。 2 軟件需求分析 為了開(kāi)發(fā)出符合要求的 網(wǎng)絡(luò)聊天程序 ，首先必須知道使用者的需求。 網(wǎng)絡(luò)聊天軟件在國(guó)外 有 ICQ 等，在國(guó)內(nèi) 主要有 OICQ、 Ticq 和一些 基于網(wǎng)頁(yè)的即時(shí)通訊工具，像 Chinaren 網(wǎng)站上的 WebMaster 等等，都做得即美觀，且功能強(qiáng)大， OICQ 現(xiàn)在擁有非常大的用戶(hù)群。 17 客戶(hù)端主要窗口設(shè)計(jì) 15 詳細(xì)設(shè)計(jì) 14 申請(qǐng)用戶(hù)流程 6 方案比較 4 開(kāi)發(fā)平臺(tái)簡(jiǎn)介 2 服務(wù)器端性能需求 2 2 軟件需求分析 軟件的預(yù)期效果在這一章節(jié)中得到了體現(xiàn)，完成效果符合前期的需求分析。 源程序代碼等全套設(shè)計(jì)聯(lián)系 174320523 各專(zhuān)業(yè)都有 分類(lèi)號(hào)： U D C： D10621408(2021)61410 密 級(jí)：公 開(kāi) 編號(hào) 2021032148 成都信息工程學(xué)院 學(xué)位論文 Linux 平臺(tái) 下 的 聊天 軟件的設(shè)計(jì) 與 開(kāi)發(fā) 論文作者姓名： 張曉韜 申請(qǐng)學(xué)位專(zhuān)業(yè)： 網(wǎng)絡(luò)工程 申請(qǐng)學(xué)位類(lèi)別： 工學(xué)學(xué)士 指導(dǎo)教師姓名（職稱(chēng)）： 李曉崗（高級(jí)工程師） 論文提 交日期： 2021 年 6 月 10 日 Linux 平臺(tái)下 的 聊天軟件的設(shè)計(jì) 與開(kāi)發(fā) 摘 要 如今互聯(lián)網(wǎng)技術(shù)高度 發(fā)達(dá)，網(wǎng)絡(luò)帶給人們的方便不言而喻。 程序設(shè)計(jì)路線這一章節(jié)對(duì)該軟件的各個(gè)功能模塊和操作處理流程進(jìn)行了 詳細(xì)的劃分和設(shè)計(jì)，并且運(yùn)用各種圖表清晰的展現(xiàn)了軟件的模塊信息和總體結(jié)構(gòu)。 Graphics user interface 目 錄 論文頁(yè)數(shù)： 27 頁(yè) 1 引言 1 課題的背景及意義 1 網(wǎng)絡(luò)聊天軟件的發(fā)展及現(xiàn)狀 3 本章小結(jié) 3 TCP協(xié)議 3 UDP協(xié)議 4 套接字簡(jiǎn)介 7 采用 UDP方式連接 16 服務(wù)器消息處理模塊的設(shè)計(jì)與實(shí)現(xiàn) 18 客戶(hù)端主要函數(shù)和變量 最初的網(wǎng)絡(luò)聊天軟件只是有簡(jiǎn)單的文本界面，功能也十分 有限，隨著技術(shù)的不斷發(fā)展與強(qiáng)大，擁有更多功能和美觀界面的聊天程序走進(jìn)了我們的生活，也有越來(lái)越多的人將網(wǎng)絡(luò)聊天軟件作為他們?nèi)粘Ｉ罱涣骱屯ㄐ诺墓ぞ摺? 由于設(shè)計(jì)該軟件的主要目的是深入的學(xué)習(xí) Linux 平臺(tái)上應(yīng)用程序的編寫(xiě)方法，本系統(tǒng)將采用 GNU 的理論方法 進(jìn)行開(kāi)發(fā) 。 應(yīng)該具有易用、美觀的圖形界面 。 因此，當(dāng)應(yīng)用程序出現(xiàn)了錯(cuò)誤的時(shí)候我們就需要程序能提供給我們出錯(cuò)的信息，這樣用戶(hù)就能夠很快的找出具體的出錯(cuò)原因，以便尋找合理的途徑去解決它。 TCP：傳輸控制協(xié)議（ TCP： Transmission Control Protocol） 傳輸控制協(xié)議是一個(gè) TCP/IP 組中能夠?qū)崿F(xiàn)可靠數(shù)據(jù)傳送的傳輸層協(xié)議，并通過(guò)順序響應(yīng)能實(shí)現(xiàn)對(duì)應(yīng)用程序的虛擬連接服務(wù)，在必要的時(shí)候進(jìn)行包轉(zhuǎn)發(fā)。這對(duì)應(yīng)用程序有利，因?yàn)樵诒凰统? TCP 之前應(yīng)用程序不需要?jiǎng)澐殖蓧K， TCP 可以將字節(jié)整合成字段 ,然后發(fā)送給 IP。 TCP 中的多路技術(shù)：大量上層同時(shí)會(huì)話(huà)在單連接時(shí)進(jìn)行多路復(fù)用。每一個(gè)數(shù)據(jù)報(bào)的前 8個(gè)字節(jié)用來(lái)包含報(bào)頭信息，剩余字節(jié)則用來(lái)包含具體的傳輸數(shù)據(jù)。 區(qū)分不同應(yīng)用程序進(jìn)程間的網(wǎng)絡(luò)通信和連接， 套接字 主要有 3個(gè)參數(shù)：通信的目的 IP 地址、使用的傳輸層協(xié)議 (TCP 或 UDP)和使用的端口號(hào) 。Gtk+是基于 LGPL授權(quán)的。 GTK 本質(zhì)上是面向?qū)ο蟮膽?yīng)用程序編程接口 (API )。另一方面，有另一個(gè)工具（ glade）可以用來(lái)把這些 XML 文件直接生成相應(yīng)的 Gtk+/Gtkmm 代碼。 Linux 系統(tǒng)下的 gcc（ GNU C Compiler）是 GNU 推出的功能強(qiáng)大、性能優(yōu)越的多平臺(tái) 編譯器，是 GNU 的代表作品之一。那樣 用戶(hù) 可以試著修正某個(gè) bug 引起的問(wèn)題，然后繼續(xù)查找另一個(gè) bug。 此時(shí)，服務(wù)程序被 驚醒 并且為客戶(hù)提供服務(wù)，對(duì)客戶(hù)的請(qǐng)求做出適當(dāng)?shù)姆磻?yīng)。 使用無(wú)連接協(xié)議的程序和使用面向連接協(xié)議的服務(wù)器程序之間的主要相似之處是它們都必須對(duì)一個(gè)協(xié)議端口進(jìn)行偵聽(tīng)。與服務(wù)器程序一樣，無(wú)連接客戶(hù)程序也使用 bind 函數(shù)讓 Socket 執(zhí)行體登記協(xié)議端口。 4 程 序 設(shè)計(jì)路線 本章節(jié)詳細(xì)的闡述了 該軟件 的整體結(jié)構(gòu) 和開(kāi)發(fā)流程 ， 各個(gè)模塊的詳細(xì)信息與代碼部分 。 處理 申請(qǐng)信息 模塊 ：通過(guò)用戶(hù)申請(qǐng)模塊進(jìn)行新用戶(hù)的注冊(cè)，保存該用戶(hù)信息。 客戶(hù)端 功能 示意圖： 服務(wù)器端 處理申請(qǐng)信息 轉(zhuǎn)發(fā)聊天信息 處理登陸信息 發(fā)布系統(tǒng)消息 第 10 頁(yè) 共 27 頁(yè) 圖 42 客戶(hù)端功能模型 消息標(biāo)識(shí)的定義 define GIF_LOGIN_MSG 1 用戶(hù)登錄 define GIF_CALL_MSG 2 用戶(hù)呼叫 define GIF_ADDRLIST_MSG 3 更新 聯(lián)系人 列表 信息 define GIF_ADD_CONTACTS_MSG 4 添加連接信息 define GIF_DELETE_CONTACTS_MSG 5 刪除連接信息 define GIF_CHAT_MSG 6 聊天信息 define GIF_DISCONNECT_MSG 7 用戶(hù)下線 消息 define GIF_SUCCESS_N_ERROR_MSG 8 消息請(qǐng)求成功或失敗信息 define GIF_OFFLINE_REQUEST_MSG 9 發(fā)送離線消息 define GIF_OFFLINE_MSG 10 離線消息 define GIF_OFFLINE_DELETE_MSG 11 刪除離線消息 用戶(hù)發(fā)送消息成功或失敗定義： define GIF_ERROR_LOGIN_INCORRECT 101 錯(cuò)誤的登陸信息 define GIF_SUCCESS_ADD_CONTACTS 102 添加連接信息成功 define GIF_ERROR_ADD_CONTACTS 103 添加連接信息錯(cuò)誤 define GIF_SUCCESS_DELETE_CONTACTS 104 刪除連接信息成功 define GIF_ERROR_DELETE_CONTACTS_NOT_A_CONTACT 105 用戶(hù) 離線 define GIF_ERROR_DELETE_CONTACTS_NOT_A_MEMBER 106 無(wú)指定用戶(hù) 登陸到服務(wù)器 客戶(hù)端 界面顯示模塊 配置信息模塊 聊天功能模塊 離線消息模塊 息 第 11 頁(yè) 共 27 頁(yè) 消息結(jié)構(gòu)體的設(shè)計(jì) 消息頭： typedef struct _gifhdr_t { unsigned int type。 }users_t。 }user_status_t。 unsigned int new。具體流程如下圖所示： 第 15 頁(yè) 共 27 頁(yè) 圖 45 客戶(hù)端消息處理流程圖 申請(qǐng)用戶(hù)流程 管理員在服務(wù)器一端統(tǒng)一注冊(cè)用戶(hù)，然后將賬號(hào)分發(fā)給各用戶(hù)，申請(qǐng)用戶(hù)為單獨(dú)程序完成，當(dāng)新用戶(hù)注冊(cè)好后系統(tǒng)會(huì)創(chuàng)建 3個(gè)用 戶(hù)信息表用來(lái)保存相應(yīng)的客戶(hù)信息。如果匹配不成功，服務(wù)器將發(fā)送登錄失敗消息給客戶(hù)端，要求用戶(hù)重新登錄。 服務(wù)器數(shù)據(jù)存儲(chǔ)的方法 該服務(wù)器采用文件作為數(shù)據(jù)存儲(chǔ)的對(duì)象。 客戶(hù)端主要窗口設(shè)計(jì) 根據(jù)前面的選題背景和需求分析，此款軟件的客戶(hù)端部分提供了圖形用戶(hù)界面， 程序運(yùn)行后激活主窗體 ，在主窗體上點(diǎn)擊設(shè)置為敏感狀態(tài)的按鈕就會(huì)產(chǎn)生相應(yīng)的事件，該事件將會(huì)觸發(fā)一個(gè)消息驅(qū)動(dòng)所指定的函數(shù)來(lái)處理這個(gè)操作。 圖 411 離線消息窗體 聊天窗口： 第 21 頁(yè) 共 27 頁(yè) 當(dāng)用戶(hù)點(diǎn)擊好友時(shí)，該窗口被激活。 enum { CONTACTS_COLUMN_TEXT, STATUS_COLUMN_PIXMAP }。 例如： gdk_threads_enter()。之后， 程序進(jìn)入主體運(yùn)行狀態(tài)，各功能模塊被激活。 將建好的列添加到樹(shù)視圖中 gtk_tree_view_append_column (GTK_TREE_VIEW (tree), column)。實(shí)現(xiàn) 刷新 的方法是，先將以前的樹(shù)移除然后按照新的聯(lián)系人狀態(tài)進(jìn)行樹(shù)的繪制，具體的編 寫(xiě)方法在上節(jié)的界面顯示模塊中以給出，這里就不再重復(fù)了。 結(jié) 論 在經(jīng)過(guò)了幾個(gè)月的設(shè)計(jì)和編寫(xiě)過(guò)后，一套適用于 Linux 操作系統(tǒng)的 網(wǎng)絡(luò) 聊天軟件基本成型 ， 前期設(shè)計(jì) 的一些功能需求也都得到了實(shí)現(xiàn) 。 [2] Stevens[美 ].UNIX 網(wǎng)絡(luò)編程 (卷 1：套接口 API)第三版 [M].北京： 清華大學(xué)出版社 ， 2021。除非另有說(shuō)明，本文的工作是原始性工作。 特此聲明！ 作者簽名： 2021 年 6月 日