【文章內(nèi)容簡介】 為 client 端和 Server 端之間的通信。所以采用 C/S模型 進行網(wǎng)絡(luò)聊天 系統(tǒng)的設(shè)計 需要分別編寫 client 端 和 Server 端 的 源代碼 ， client 端 和 Server 端 之間相互通信的程序流程如實驗圖 13 所示。 圖 13 Socket通信流程圖 網(wǎng)絡(luò)套接字（ socket）的概念 Socket 接口 是 TCP/IP 的 API，它提供了 相應(yīng)的功能函數(shù)與 例程， 我們 可以使用 對應(yīng)的函數(shù)與例程進行 TCP/IP 應(yīng)用程序 的開發(fā)與維護 。 使用 Socket 套接字 進行網(wǎng)絡(luò)通信的 開發(fā) 過程如 下面的 步驟： (1) 建立一個 Socket 套接字 (2) 按 我們所需要的 要求配置 好 Socket 套接字 ，將 socket 連接到 遠程 server 端或者是本機 server 端 或給 Socket 套接字 指定本地協(xié)議端口 號 。 (3) 按要求通過 Socket 套接字 發(fā)送和接受 相應(yīng)的 數(shù)據(jù) 與信息 。 (4) 完成通信以后我們需要 關(guān)閉此 Socket 套接字并且釋放相應(yīng)的其他銷耗系統(tǒng)的操作 。 以上就是 通過 Socket 套接字來 實現(xiàn)點對點 信息 通信 的 4 個編程 的核心 要點。 系統(tǒng)的選擇 方案一：紅帽子系統(tǒng)即 Red Ha 系統(tǒng) 是目前銷售量最高、安裝最簡便、最適合初學(xué)者的Linux 發(fā)行版，也是目前世界上最流行的 Linux 發(fā)行套件，它的市場營銷、包裝及服務(wù)做的相當(dāng)不錯，自行開發(fā)了 RPM 套件管理程序及 X 桌面環(huán)境 Gnome 的眾多軟件并將其源代碼回饋給 Open Source munity。 也正是因為 Red Hat 的方便性，安裝程序?qū)⑾到y(tǒng)的構(gòu)架或軟件安裝方式全部做了包裝，用戶學(xué)到的都是 GUI 界面（圖形用戶界面）上輸入一些設(shè)置值的粗淺知識，至于軟件安裝了那些文件、安裝到哪個文件目錄、系統(tǒng)作了哪些設(shè)置，使用者則一無所知，一旦真正遇到系統(tǒng)程序發(fā)生問題時，要解決問題也就比較困難。 方案二： Caldera OpenLinux 系統(tǒng)， Caldera 將 OpenLinux 這套系統(tǒng)定位為容易使用與設(shè)置的發(fā)行版，以集成使用環(huán)境與最終用戶辦公環(huán)境，容易安裝使用與簡便管理為系統(tǒng)目標(biāo)，有望成為最流行的公司團體臺式 Linux 操作系統(tǒng)，適合初學(xué)者使用，全部安裝需要 1GB 的硬盤空間。 Caldera 有自行研發(fā)的圖形界面的安裝程序向?qū)?，安裝過程可以玩俄羅斯方塊，提供完整的 KDE 桌面環(huán)境，附贈功能強大的商業(yè)軟件，如 StarOffice、圖形界面的硬盤分割工具Partition Magic 等。 方案三： SuSE Linux 系統(tǒng)， SuSE 是歐洲最流行的 Linux 發(fā)行版，而且 SuSE 是軟件國際化的先驅(qū)，讓軟件支持各國語系，貢獻頗豐， SuSE 也是用 RPM 作為軟件安裝管理程序，不過 SuSE 并不適合新手使用，提供了非常多的工具軟件，全部安裝 需 的硬盤空間，安裝過程也較為復(fù)雜。 通過以上三種方案的比較，考慮適用性，和可操作性，選擇 Red hat Linux 操作系統(tǒng)。 開發(fā)工具的選擇 方案一： vi 編輯器， vi 編輯器 是 Linux 上最基本的 文本編輯器 ， 它是以 字符 模式 為核心的 。由于 去除了 UI 界面，使 vi 編輯器 效率 提高了 很 多 。在 Linux 上也有 許多 UI 界面的 編輯器 ，但 VI在系統(tǒng)和 服務(wù)器管理 中的 相應(yīng)的 功能是 UI編輯器 不可以達到的 。 VI編輯器 在 Linux上的 重要性是與 Edit 在 DOS 上 的地位是 一樣。 Vi 編輯器 可以執(zhí)行 文字 輸出、 文字 刪除、 文字 查找、 文字 替換、 文件 塊操作等眾多文本操作，用戶 也 可以根據(jù)自 身的 需要對其進行 相應(yīng)的 定制 和二次開發(fā) ，這是其他 編輯程序 所 不能達到的效果 。 加上紅帽子系統(tǒng)中自帶的 gcc編譯器 和 gdb 調(diào)試 工具，所以 Linux 系統(tǒng)目前最主流的開發(fā)工具。 方案二： 用 eclipse 加 CDT+GCC+GDB，雖然 eclipse 擁有 方便的 UI 界面 ， 配置開發(fā)環(huán)境有點 復(fù)雜 ,如果配置好了，開發(fā)的效率還是不錯的。和 在 windows 下開發(fā) 基本相似。 用eclipse+CDT 可以 自動生成 makefile 文件，比較適合偏愛圖形界面的開發(fā)人員。 通過以上兩種方案的比較，考慮適用性，和編程習(xí)慣，選擇方案一。 多線程與多進程 點對點通信的實現(xiàn)知識 ,了解了 主機進程與服務(wù)器進程之間的連接 關(guān)系 ，建立連接 了一對一的 進程聯(lián)系，即主機的一個進程 必須與 服務(wù)器的一個進程之間建立 相應(yīng)的 連接。而 對于每一個 client 端服務(wù)器都要建立一個相應(yīng)的進程去實現(xiàn)和 client 端的通信。 對于線程的并發(fā)情況我們就要建立多個線程去出來 。 由于服務(wù)端 接受信息 的行為 是被動的，當(dāng) 服務(wù)端 沒有信息可以接收時，該進程就 應(yīng)該自動的 阻塞，發(fā)送任務(wù)也 應(yīng)該 一起被阻塞。不同 端口的 收發(fā)之間就存在 并發(fā) 情況 ， 這樣我們就應(yīng)該 應(yīng)該 建立多個 不同的 進程 去分別完成信息的 收發(fā) 。這樣，當(dāng) 一個 client 端的請求 被阻塞時，不至于影響 其它的 client 端 的 正常工作 。 關(guān)于多進程和多線程， 我覺得 最 核心 的一句話是 “進程是資源分配的最小單位，線程是CPU調(diào)度的最小單位 ”。 方案一 ：多進程， 數(shù)據(jù)共享 非常 復(fù)雜，需要用 IPC 處理 ；數(shù)據(jù)是分開 處理的 ，同步 比較簡單 ；但是 內(nèi)存 耗的 多，切換 相應(yīng)的會比較 復(fù)雜， CPU 利用率低創(chuàng)建銷毀、切換復(fù)雜，速度慢 ；編程簡單，調(diào)試簡單； 適應(yīng)于多核、多機分布式；如果一臺機器不夠，擴展到多臺機器比較簡單 。 方案二：多線程，他的優(yōu)點在于 共享進程 間的 數(shù)據(jù)，數(shù)據(jù)共享 就變的十分的 簡單， 并且創(chuàng)建銷毀、切換簡單，速度很快 ，缺點也由于 這個原因?qū)е峦綇?fù)雜 ；雖然 占用內(nèi)存少，切換簡單， 但是 CPU 利用率高 ， 編程復(fù)雜，調(diào)試復(fù)雜 ； 一個線程 死掉 將導(dǎo)致整個進程 失去功能。 通過以上兩種方案的比較，考慮適用性，選擇多線程實現(xiàn)對客戶端的監(jiān)聽。 I/O 多路復(fù)用 除了可以采用多進程和多線程方法去實現(xiàn)并發(fā)情況之外，還可以采用 I/O 多路復(fù)用這門技術(shù)來實現(xiàn)。通過該技術(shù)，系統(tǒng)內(nèi)核首先會緩沖 I/O 數(shù)據(jù)，當(dāng)某個 I/O 準(zhǔn)備好后，系統(tǒng)自動通知相應(yīng)的應(yīng)用程序去完成 I/O讀或?qū)懖僮?，這樣應(yīng)用程序可以迅速的完成對應(yīng)的 I/O操作，因而系統(tǒng)不需要等待完成相應(yīng) I/O 操作，從而應(yīng)用程序設(shè)置阻塞。 因此我在收發(fā)信息方面使用了 I/O 多路復(fù)用去處理，即在處理群聊私聊的信息傳送時。對于 client 端，一旦我們輸 入了一行文字發(fā)，系統(tǒng)會自動的讀取，進而發(fā)送給系統(tǒng)內(nèi)的server 端，然后由 server 端反饋給對應(yīng)的目標(biāo) client 端。 方案一：當(dāng)我們使用的 poll 函數(shù) 返回時，會 返回 一個文件是讀寫標(biāo)志，應(yīng)用程序根據(jù)不同的 返回 標(biāo)志 去 讀寫相應(yīng)的文件，實現(xiàn) 不用阻塞就可以完成 讀寫。 這 允許進程來決定 那個client 端 是可讀或?qū)懸粋€或多個文件而不 用 阻塞 的 。 poll 返回不同的標(biāo)志， 這些標(biāo)志 告訴主進程文件是否可以讀寫，其原型（定義在 linux\ ） : unsigned int (*poll) (struct file *filp, poll_table *wait)。 實現(xiàn)這個設(shè)備 的 方法分 為下面的 兩步 : 1. 在一個或多個可指示查詢狀態(tài)變化的等待隊列上調(diào)用 poll_wait. 當(dāng) 文件描述符 不可以 可用來執(zhí)行 I/O 時 , 內(nèi)核 將使 這個進程在 處于等待狀態(tài)，一旦又來可使用的文件描述符時， . 驅(qū)動 自動的 通過調(diào)用函數(shù) poll_wait 增加一個 新的 等待隊列到 poll_table 結(jié)構(gòu)，原型 : void poll_wait (struct file *, wait_queue_head_t *, poll_table *)。 2. 返 回一個位掩碼： 我們在處理某一些功能時 不必 要 阻塞 ，需要 立刻進行的操作， 那么我們就需要下面的 幾個標(biāo)志 (通過 linux/ 定義 )用來指示可能的操作 ，如表 21 所示： 標(biāo)志 含義 POLLIN 如果設(shè)備無阻塞的讀，就返回該值 POLLRDNORM 通常的數(shù)據(jù)已經(jīng)準(zhǔn)備好，可以讀了，就返回該值。通常的做法是會返回（ POLLLIN|POLLRDNORA） POLLRDBAND 如果可 以從設(shè)備讀出帶外數(shù)據(jù)，就返回該值，它只可在 linux 內(nèi) 核的某些網(wǎng)絡(luò)代碼中使用，通常不用在設(shè)備驅(qū)動程序 中 POLLPRI 如果可 以無阻塞的讀取高優(yōu)先級（帶外）數(shù)據(jù)，就返回該值，返回該值會導(dǎo)致 select 報告文件發(fā)生異常，以為 select 八帶外數(shù)據(jù)當(dāng)作異常處理 POLLHUP 當(dāng)讀設(shè) 備的進程到達文件尾時，驅(qū)動程序必須返回該值，依照 select 的功能描述，調(diào)用 select 的進程被告知進程時可讀的。 POLLERR 如果設(shè) 備發(fā)生錯誤，就返回該值。 POLLOUT 如果設(shè)備可以無阻塞地些，就返回該值 POLLWRNORM 設(shè)備已經(jīng)準(zhǔn)備好，可以寫了，就返回該值。通常地做法是（ POLLOUT|POLLNORM） POLLWRBAND 于 POLLRDBAND 類似 表 21 poll函數(shù)返回的位掩碼及其含義 方案二： select 函數(shù)： select()函數(shù)的接口主要 以 39。fd_set39。類型 為 基礎(chǔ) 而建立的 。 39。fd_set)是一組文件描述符 (fd)的 大 集合。由于 在不同的平臺上 fd_set 類型的長度 是 不同 的 ，因此 規(guī)定用一組標(biāo)準(zhǔn)的宏定義來處理此類變量 顯得尤其重要 ： fd_set set。 FD_ZERO(amp。set)。 FD_SET(fd, amp。set)。 FD_CLR(fd, amp。set)。 FD_ISSET(fd, amp。set)。 在過去，一個 fd_set 通常是小于 32 個文件描述符 的 ，因為 fd_set 其實 僅僅使用 了一個int 的比特矢量來實現(xiàn) 它。 在大多數(shù)情況下系統(tǒng)的責(zé)任 之一包括 檢查 fd_set 能包括任意值的文件描述符， 但是當(dāng)我們知道我們的文件描述符的多少時 你應(yīng)該檢查 /修改宏 FD_SETSIZE的值。這個值是 與 系統(tǒng)相關(guān)的，同時 我們也要 檢查 Linux 系統(tǒng)中的 自帶的 sel