期末的時候做完開題報告，用了半個寒假投了一篇英文**出去。兩本書籍已經閱讀完畢，現總結高效能伺服器程式框架內容，分四篇文章介紹伺服器模型、i/o模型（四種i/o模型）、兩種高效事件處理模式和兩種高效的併發模式。
正文開始：
1.c/s模型
圖 1 c/s模型
c/s模型的邏輯很簡單。伺服器期待後，首先建立乙個（或多個）監聽socket，並呼叫bind函式將其繫結到伺服器感興趣的埠上，然後呼叫listen函式等待客戶連線。伺服器穩定執行之後，客戶端就可以呼叫connect函式向伺服器發起連線了。由於客戶連線請求是隨機到達的非同步事件，伺服器就要適用某種i/o模型來監聽這一事件。i/o模型有多種，下圖2中，伺服器使用的是i/o復用技術之一的select系統呼叫。當監聽到聯結器請求後，伺服器就呼叫accept函式接受它，並分配乙個邏輯單元為新的連線服務。邏輯單元可以是新建立的子程序、子執行緒或者其他。
圖2中，伺服器給客戶端分配的邏輯單元是由fork系統呼叫建立的子程序。邏輯單元讀取客戶請求，處理該請求，然後將處理結果返回給客戶端。客戶端接收到伺服器的反饋結果之後，可以繼續向伺服器傳送請求，也可以立即主動關閉連線。如果客戶端主動關閉連線，則伺服器執行被動關閉連線。至此，雙方的通訊結束。需要注意的是，伺服器在處理乙個客戶請求的同時還會繼續監聽其他客戶請求，否則就變成了效率低下的序列伺服器了（必須先處理完前乙個客戶的請求，才能繼續處理下乙個客戶請求）。圖2中，伺服器同時監聽多個客戶請求是通過select系統呼叫實現的。
圖 2 tcp伺服器和tcp客戶端的工作流程
優點：c/s模型非常適合資源相對集中的場合，並且它的實現也很簡單。
缺點：伺服器是通訊的中心，當訪問量過大時，可能所有客戶都將得到很慢的響應。
2. p2p模型
p2p(peer to peer， 點對點)模型比c/s模型更符合網路通訊的實際情況。它摒棄了以伺服器為中心的格局，讓網路上所有主機重新回歸對等的地位。p2p模型如圖3(a)所示。p2p模型使得每台機器在消耗服務的同時也給別人提供服務，這樣資源能夠充分、自由地共享。雲計算機群可以看做p2p模型的乙個典範。但p2p模型的缺點也很明顯；當使用者之間傳輸的請求過多時，網路的負載將加重。
圖3(a)所示的p2p模型存在乙個顯著的問題，即主機之間很難互相發現。所以實際使用的p2p模型通常有乙個專門的發現伺服器，如圖3(b)所示。這個發現伺服器通常還提供查詢服務（甚至還可以提供內容服務），使得每個客戶都能盡快地找到自己需要的資源。
圖 3 a:p2p模型 b:帶發現伺服器的p2p模型
從程式設計角度來講，p2p模型可以看做c/s模型的擴充套件：每台主機既是客戶端，又是伺服器。因此，現今大多數使用者依舊是採用c/s模型來討論網路程式設計。
下面繼續介紹伺服器程式框架之i/o模型。
搭建伺服器程式框架
現在我在幫桂林西川軟體開發 開發乙個 eim 企業即時通訊平台。現在概要設計已經基本完成了，由於詳細設計懶得寫了，從現在開始就進入編寫 階段，然後把每個版本的過程都寫下來，以方便以後學習 回顧 總結。這個版本最主要就是搭建伺服器整個程式框架 具體做法如下 一 新建工程 1 新建乙個 mfc工程，取名...
伺服器模型
伺服器模型 1 迴圈伺服器模型 tcp 迴圈伺服器 udp 迴圈伺服器 2 併發伺服器 tcp 併發伺服器 父子程序實現併發伺服器 父親程序 接收請求。accept 兒子程序 處理具體客戶端需求。send recv 注意點 殭屍程序，父親活著，兒子死亡，父親沒有為兒子程序收屍，會產生殭屍程序。避免殭...
伺服器模型
在使用socket進行網路程式設計時，首先要選擇乙個合適的伺服器模型是很重要的。在網路程式裡，通常都是乙個伺服器服務多個客戶機，為了處理多個客戶機的請求，伺服器端的程式有不同的處理方式。迭代模型算是最早期的伺服器模型，其核心實現是每來乙個使用者，然後為這個使用者服務到底，過程中不接受任何新的使用者請...