Muduo 網路編程樣本(二) Boost.Asio 的聊天伺服器

來源:互聯網
上載者:User

本文講介紹一個與 Boost.Asio 的範例程式碼中的聊天伺服器功能類似的網路服務程式,包括用戶端 與服務端的 muduo 實現。這個例子的主要目的是介紹如何處理分包,並初步涉及 Muduo 的多線程功能 。Muduo 的下載地址: http://muduo.googlecode.com/files/muduo-0.1.7-alpha.tar.gz ,SHA1 873567e43b3c2cae592101ea809b30ba730f2ee6,本文的完整代碼可線上閱讀

http://code.google.com/p/muduo/source/browse/trunk/examples/asio/chat/ 。

TCP 分包

前面一篇《五個簡單 TCP 協議》中處理的協議沒有涉及分包,在 TCP 這種位元組流協議上做應用程式層 分包是網路編程的基本需求。分包指的是在發生一個訊息(message)或一幀(frame)資料時,通過一定的 處理,讓接收方能從位元組流中識別並截取(還原)出一個個訊息。“粘包問題”是個偽問題。

對於短串連的 TCP 服務,分包不是一個問題,只要發送方主動關閉串連,就表示一條訊息發送完畢 ,接收方 read() 返回 0,從而知道訊息的結尾。例如前一篇文章裡的 daytime 和 time 協議。

對於長串連的 TCP 服務,分包有四種方法:

1. 訊息長度固定,比如 muduo 的 roundtrip 樣本就採用了固定的 16 位元組訊息;

2. 使用特殊的字元或字串作為訊息的邊界,例如 HTTP 協議的 headers 以 "rn" 為欄位的分隔 符;

3. 在每條訊息的頭部加一個長度欄位,這恐怕是最常見的做法,本文的聊天協議也採用這一辦法;

4. 利用訊息本身的格式來分包,例如 XML 格式的訊息中 <root>...</root> 的配對 ,或者 JSON 格式中的 { ... } 的配對。解析這種訊息格式通常會用到狀態機器。

在後文的代碼講解中還會仔細討論用長度欄位分包的常見陷阱。

聊天服務

本文實現的聊天服務非常簡單,由服務端程式和用戶端程式組成,協議如下:

* 服務端程式中某個連接埠偵聽 (listen) 新的串連;

* 用戶端向服務端發起串連;

* 串連建立之後,用戶端隨時準備接收服務端的訊息並在螢幕上顯示出來;

* 用戶端接受鍵盤輸入,以斷行符號為界,把訊息發送給服務端;

* 服務端接收到訊息之後,依次發送給每個串連到它的用戶端;原來發送訊息的用戶端進程也會收 到這條訊息;

* 一個服務端進程可以同時服務多個用戶端進程,當有訊息到達服務端後,每個用戶端進程都會收 到同一條訊息,服務端廣播發送訊息的順序是任意的,不一定哪個用戶端會先收到這條訊息。

* (可選)如果訊息 A 先於訊息 B 到達服務端,那麼每個用戶端都會先收到 A 再收到 B。

這實際上是一個簡單的基於 TCP 的應用程式層廣播協議,由服務端負責把訊息發送給每個串連到它的客 戶端。參與“聊天”的既可以是人,也可以是程式。在以後的文章中,我將介紹一個稍微複雜的一點的 例子 hub,它有“聊天室”的功能,用戶端可以註冊特定的 topic(s),並往某個 topic 發送訊息,這 樣代碼更有意思。

相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。