【正文】 作都在這個(gè)窗體中完成。 離線消息存儲(chǔ)文件： 該文件中保存了其它用戶發(fā)給當(dāng)前用戶的離線消息。 用戶擁有好友文件： 第 17 頁(yè) 共 26 頁(yè) 該文件中保存了當(dāng)前用戶所添加的好友信息。 服務(wù)器上主要存放 5類用戶信息文件： 用戶信息數(shù) 據(jù)文件： 該文件中保存了用戶的 loginid 和 password。之所以采用這種發(fā)式是因?yàn)樵摲?wù)器作為一個(gè)小型的聊天軟件的服務(wù)器，本身所要求保存的數(shù)據(jù)量并不大，且用戶數(shù)量也是比較有限的，在這種情況下采用文件方式對(duì)信息進(jìn)行讀取在速度和開銷上都要有一些優(yōu)勢(shì)，且便于管理員管理用戶。 刪除離線消息處理模塊： 如果客戶做出了刪除離線消息的動(dòng)作，那么服務(wù)器端將會(huì)根據(jù)用戶的發(fā)送信息把該用戶的離線消息文件中的離線消息刪除。 用戶下線消息處理模塊： 當(dāng)服 務(wù)器判斷用戶所請(qǐng)求的信息為下線消息后，服務(wù)器將把用戶從 中刪除，設(shè)置該用戶狀態(tài)為下線，同時(shí)調(diào)用發(fā)送聯(lián)系人狀態(tài)函數(shù)將標(biāo)志位設(shè)置為離線向該用戶的聯(lián)系人發(fā)送。 用戶聊天信息轉(zhuǎn)發(fā)的處理模塊： 當(dāng)服務(wù)器判斷用戶所請(qǐng)求的信息為聊天消息后，服務(wù)器會(huì)根據(jù)用戶所指定的聊天對(duì)象到 表中查找被指定用戶是否在線，如果被指定用戶在線則提取他的套接字地址結(jié)構(gòu)，并按照該套接字信息將消息轉(zhuǎn)發(fā)。 添加好友信息處理模塊： 當(dāng)服務(wù)器收到用戶請(qǐng)求加好友的消息時(shí)，服務(wù)器首先在 中查找要被添加的用戶是否存在，如果該用戶存在則把該用戶的信息存儲(chǔ)到當(dāng)前用戶的好友文件中，同時(shí)在被添加好友的用戶的 表中保存當(dāng)前用戶的信息。 服務(wù)器消息處理模塊的設(shè)計(jì)與實(shí)現(xiàn) 服務(wù)器的消息處理模塊主要由 7 部分組成，下面進(jìn)行分別論述： 用戶登錄消息處理模塊： 當(dāng)服務(wù)器接收到用戶消息并判斷是登錄消息后，服務(wù)器將根據(jù)用戶所發(fā)送過來的用戶名和密碼到 表中進(jìn)行匹配，如果匹配成功則把該用戶加入到 表中，設(shè)置用戶在線狀態(tài)為真的同時(shí)調(diào)用發(fā)送聯(lián)系人在線列表函數(shù)，向添加該用戶為好友的用戶發(fā)送該用戶的上線信息。 發(fā)送聯(lián)系人狀態(tài)函數(shù)： void gif_send_clients_contact_list(chat *client_loginid,int client_sockfd, int type)該函數(shù)的主要 作用是當(dāng)用戶的在線狀態(tài)標(biāo)志發(fā)生變動(dòng)時(shí)，服務(wù)器要及時(shí)地做出判斷，并向該用戶的聯(lián)系人發(fā)送該用戶狀態(tài)變更后的信息，以便對(duì)方能夠及時(shí)地了解到聯(lián)系人的狀態(tài)信息。 該函數(shù)中有 7 個(gè)主要消息處理模塊，這些模塊針對(duì)不同的客戶消息進(jìn)行處理，將他們組合在一起便形成了一套完整的消息處理機(jī)制。具體流程如下圖所示： 圖 46 管理 用戶流程圖 運(yùn)行用戶管理程序 添加用戶 顯示用戶 刪除用戶 退出程序 第 15 頁(yè) 共 26 頁(yè) 5 詳細(xì)設(shè)計(jì) 該部分詳細(xì)講述了服務(wù)器和客戶端的界面和代碼，直觀地對(duì)該軟件進(jìn)行設(shè)計(jì)說明，通過該部分將對(duì)軟件有一個(gè)全面的了解。當(dāng)用戶點(diǎn)擊離線用戶時(shí)便會(huì)觸發(fā)一個(gè)離線消息事件，該事件通過服務(wù)器轉(zhuǎn)發(fā)方式發(fā)送給離線用戶，當(dāng)對(duì)方上線時(shí)便可查看該離線消息。具體流程如下圖所示： 圖 43 服務(wù)器流程圖 客戶端操作流程 這款聊天軟件的客戶端采用圖形化用戶接口方式， GTK圖形界面的主要特點(diǎn)就是事件觸發(fā)，當(dāng)處理引擎接收到某一窗體消息時(shí)，處理引擎就會(huì)按照事先編寫好的函數(shù)作相應(yīng)的處理動(dòng)作，下圖總體上描述了客戶端軟件的操作處理流程： 第 13 頁(yè) 共 26 頁(yè) 圖 4－ 4 客戶端操作流程圖 客戶端消息發(fā)送和接收流程 客戶端運(yùn)行后首先要用戶登錄到服務(wù)器，如果登陸成功服務(wù)器會(huì)將在線的用戶聯(lián)系人列表發(fā)送給客戶端，此 時(shí)客戶端即可顯示有哪些好友在線而哪些是離線的。 4 軟件流程 本節(jié)主要敘述了該軟件的整體運(yùn)作流程，包括服務(wù)器和客戶端對(duì)消息的處理等流程，通過本節(jié)將能夠?qū)浖墓ぷ髁鞒痰玫揭粋€(gè)總體的認(rèn)識(shí)。 unsigned int length。 char dateserial[20]。 }offline_msgs_t。 unsigned int new。 離線消息存儲(chǔ)時(shí)離線消息結(jié)構(gòu)： typedef struct _offline_msgs_t { char sender[20]。 unsigned int status。 第 11 頁(yè) 共 26 頁(yè) }user_contacts_t。 }online_users_t。 在線用戶信息結(jié)構(gòu)： typedef struct _online_users_t { char loginid[20]。 char password[20]。 }gifhdr_t。 char receiver[10]。 unsigned int length。 配置信息模塊：提供基本的軟件配置操作。 聊天功能模塊：處理各種聊天信息，并判斷消息類型。因此，針對(duì)這些操作特性，將客戶端模塊進(jìn)行如下劃分： 登陸功能模塊：建立與服務(wù)器的連接并登陸，能顯 示登陸錯(cuò)誤信息。 發(fā)布系統(tǒng)消息模塊：將用戶上下線的消息發(fā)給各客戶端，并改寫用戶在服務(wù)器端和客戶端的狀態(tài)。 處理聊天信息模塊：轉(zhuǎn)發(fā)消息給指定的用戶。就將在線用戶發(fā)給該用戶，并將該用戶的狀態(tài)發(fā)給各在線用戶。 接受來自客戶端的各種信息并分別處理。 總體設(shè)計(jì)方案 為實(shí)現(xiàn)網(wǎng)絡(luò)聊天的功能，該軟件采用 Socket 編程，服務(wù)器與客戶端采用了TCP/IP 方式連接，在設(shè)計(jì)聊天方案時(shí)，實(shí)行將所有信息發(fā)往服務(wù)器端，再由服務(wù)器進(jìn)行分別處理的思路，服務(wù)器端是所有信息的中心。采用 C/S結(jié)構(gòu)。 Socket 執(zhí)行體處理傳輸層內(nèi) UDP 軟件模塊和客戶程序之間的接口。與服務(wù)器程序一樣，無連接客戶程序也使用 bind 函數(shù)讓 Socket 執(zhí)行體登記協(xié)議端口。無連接客戶程序使用數(shù)據(jù)報(bào)發(fā)送網(wǎng)絡(luò)服務(wù)請(qǐng)求，它不建立點(diǎn)到點(diǎn)連接。 下面程序行顯示了一個(gè)典型的函數(shù)調(diào)用： result ＝ bind ( socket_handle, local_structure socket_address, address_ length) 無連接客戶程序也對(duì)一個(gè)協(xié)議端口進(jìn)行偵聽。同樣，由于無連接客戶程序沒有和遠(yuǎn)地主機(jī)建立直接連接，所以它也必須對(duì)協(xié)議端口進(jìn)行偵聽，以便接收以對(duì)它服務(wù)請(qǐng)求產(chǎn)生的數(shù)據(jù)報(bào)應(yīng)答 。 使用無連接協(xié)議的程序和使用面向連接協(xié)議的服務(wù)器程序之間的主要相似之處是它們都必須對(duì)一個(gè)協(xié)議端口進(jìn)行偵聽。 Socket 執(zhí)行體接著告 訴傳輸層某個(gè)特定協(xié)議端口已被使用，并將其收到的所有數(shù)據(jù)傳送給 Socket API。當(dāng)服務(wù)器配置 socket 接口時(shí)，它使用 bind()函數(shù)讓 socket 執(zhí)行體登記一個(gè)協(xié)議端口。 當(dāng)建立服務(wù)器程序時(shí)，應(yīng)該將服務(wù)器程序設(shè)計(jì)成等候客戶的請(qǐng)求。此時(shí)，服務(wù)程序被 驚醒 并且為客戶提供服務(wù)，對(duì)客戶的請(qǐng)求做出適當(dāng)?shù)姆磻?yīng)。在 TCP/IP 網(wǎng)絡(luò)應(yīng)用中，多數(shù)網(wǎng)絡(luò)應(yīng)用程序是使用客戶 /服務(wù)器模型設(shè)計(jì)的。 客戶及 /服務(wù)器模型將網(wǎng)絡(luò)應(yīng)用程序分為客戶和服務(wù)器兩部分。 3 程序設(shè)計(jì)方案 方案比較 采用 TCP 方式連接 TCP 方式連接的一個(gè)顯著特點(diǎn)就是需要有服 務(wù)器，這種類型的程序通常被稱為客戶機(jī) /服務(wù)器模式。 本章小結(jié) 需求是開發(fā)的前提，只有明確了需求才能開發(fā)出一個(gè)符合用戶期望的優(yōu)質(zhì)軟件。當(dāng)有錯(cuò)誤發(fā)生時(shí)，我們應(yīng)該有一個(gè)很好的機(jī)制來保障錯(cuò)誤能夠及時(shí)地被排除。 當(dāng)一個(gè)窗體出現(xiàn)問題時(shí)能夠及時(shí)的處理，讓主程序不受影響。 因此我們將采用多線程方式的并發(fā)服務(wù)器來設(shè)計(jì)服務(wù)器端，這樣將能從很大程度上提高服務(wù)器的運(yùn)行效率。 總體性能需求 服務(wù)器端性能需求 服務(wù)器需要同時(shí)連接很多個(gè)用戶，并能提供給這些連接用戶所需要的任務(wù)處理請(qǐng)求，這就要求服務(wù)器能同時(shí)處理多個(gè) socket 連接。 客戶端程序可以 顯示在線好友。 客戶可以通過服務(wù)器轉(zhuǎn)發(fā)，實(shí)現(xiàn)一對(duì)一 的 聊天 。 軟件功能需求 登錄功能。 2 軟件需求分析 為了開發(fā)出符合要求 的網(wǎng)絡(luò)聊天程序，首先必須知道使用者的需求。所以，開發(fā)一個(gè)網(wǎng)絡(luò)里的 C/S 通訊軟件是十分必要的。 用戶 可以用 GDB 來調(diào)試 C和 C++寫的程序。 改變程序。 保證程序在指定的條 件下停止 。 GDB 主要能做四件事 (包括為了完成這些事而附加的功能 )，幫助 用戶 找出程序中的錯(cuò)誤。 gcc 是可以在多種硬體平臺(tái)上編譯出可執(zhí)行程序的超級(jí)編譯器，其執(zhí)行效率與一般的編譯器相比平均效率要高20%~30% gcc 編譯器能將 C、 C++語言源程序、匯程式化序和目標(biāo)程序編譯、連接成可執(zhí)行文件，如果沒有給出可執(zhí)行文件的名字， gcc 將生成一個(gè)名為 的文件。 Linux 發(fā)布版本中都提供了 C編譯器 gcc，它目前的版本是 。 C語言也更易移植，因而，在 Linux 下編程的最佳語言應(yīng)該是 C語言， Linux上的很多應(yīng)用程序就是用 C 語言寫的。也許這是以后桌面應(yīng) 用程序開發(fā)的一個(gè)方向。對(duì)于比較小型的項(xiàng)目，這種方法是比較適用的。 Glade 提供了一個(gè)類庫(kù)，在程序運(yùn)行的時(shí)候，它可以通過讀取 XML 文件而生成相應(yīng)的程序界面，從而達(dá)到了程序代碼邏輯與用戶界面的完全分離。 Glade 集成開發(fā)工具 簡(jiǎn)介 Glade 是面向 GTK+/Gtkmm 的圖形界面開發(fā)工具。Gnome 的一些新特性，如 popt 參數(shù)分析，保存應(yīng)用程序設(shè)置等也是 Gtk+構(gòu)件所沒有的。雖然完全是用 C寫成的，但它仍然是用類和回調(diào)函數(shù) (指向函數(shù)的指針 )的方法實(shí)現(xiàn) 的。從本質(zhì)上來說， Gtk+構(gòu)件和 Gnome 構(gòu)件是完全類似的東西。一般把這些構(gòu)件稱為 Gnome 構(gòu)件 (與 Gtk+構(gòu)件相對(duì)應(yīng) )?？梢杂盟鼈儊順?gòu)造非常豐富的用戶界面。 Gtk+圖形庫(kù)使用一系列稱為“構(gòu)件”的對(duì)象來創(chuàng)建應(yīng)用程序的圖形用戶接口。 第 4 頁(yè) 共 26 頁(yè) Gtk+圖形開發(fā)庫(kù) 簡(jiǎn)介 Gtk+(GIMP Toolkit， GIMP工具包 )是一個(gè)用于創(chuàng)造圖形用戶接口的圖形庫(kù)。旨在開發(fā)一個(gè)類似 Unix、并且是自由軟件的完整操作系統(tǒng)： GNU 系統(tǒng)。以后借助于 Inter 網(wǎng)絡(luò)，并經(jīng)過全世界各地計(jì)算機(jī)愛好者的共同努力下，現(xiàn)已成為今天世界上使用最多的一種UNIX 類操作系統(tǒng)，并且使用人數(shù)還在迅猛增長(zhǎng)。通過將這 3個(gè) 參數(shù)結(jié)合起來，與一個(gè) Socket 綁定，應(yīng)用層就可以和傳輸層通過套接字接口，區(qū)分來自不同應(yīng)用程序進(jìn)程或網(wǎng)絡(luò)連接的通信，實(shí)現(xiàn)數(shù)據(jù)傳輸?shù)牟l(fā)服務(wù) 開發(fā)平臺(tái)簡(jiǎn)介 Linux 系統(tǒng)簡(jiǎn)介 Linux 操作系統(tǒng)是 UNIX 操作系統(tǒng)的一種克隆系統(tǒng)。為了區(qū)別不同的應(yīng)用程序進(jìn)程和連接，許多計(jì)算機(jī)操作系統(tǒng)為應(yīng)用程序與 TCP／ IP協(xié)議交互提供了稱為套接字 (Socket)的接口。 套接字簡(jiǎn)介 應(yīng)用層通過傳輸層進(jìn)行數(shù)據(jù)通信時(shí)， TCP和 UDP 會(huì)遇到同時(shí)為多個(gè)應(yīng)用程序進(jìn)程提供并發(fā)服務(wù)的問題。雖然 TCP 協(xié)議 中植入了各種 安全 保障功能，但是在實(shí)際執(zhí)行的過程中會(huì)占用大量的系統(tǒng)開銷，無疑使速度受到嚴(yán)重的影響。 既然 UDP 是一種不可靠的網(wǎng)絡(luò) 協(xié)議 ，那么還有什么使用價(jià)值或必要呢？其實(shí)不然，在有些情況下 UDP 協(xié)議 可能會(huì)變得非常有用。一個(gè)典型的數(shù)據(jù)報(bào)就是一個(gè)二進(jìn)制數(shù)據(jù)的傳輸單位。根據(jù) OSI（開放系統(tǒng)互連）參考模型， UDP 和 TCP 都屬于傳輸層 協(xié)議 。 UDP 協(xié)議 從問世至今已經(jīng)被使用了很多年，雖然其最初的光彩已經(jīng)被一些類似 協(xié)議 所掩蓋，但是即使是在今天， UDP 仍然不失為一項(xiàng)非常實(shí)用和可行的網(wǎng)絡(luò)傳輸層 協(xié)議 。 UDP 協(xié)議 簡(jiǎn)介 UDP 協(xié)議 是英文 U