c++專案——聊天室——第一節
- 概述
- 引言
- 聊天室初步
- 1 總體設計
- 2 思路設計
- 3 資料結構設計(細節設計)
- (1)分析訊息協議部分
- (2)分析客戶端
- (3)分析服務器
- 聊天室1.0
- 聊天室1.0 github地址:
- 參考文獻
概述
本節內容是在 如何學習編程 之后進一步由理論結合實踐去驗證和加深該學習思想,為了方便起見,不會再過多的闡述先驗知識,因此若是在閱讀程序中出現因先驗知識不足而導致的難以理解的情況,請自行學習相關的先驗知識,
因為c++這門語言學習起來總有一定的難度,除了語言本身的原因以外,由于學的人相對較少,學精通的人更少,導致在推廣方面,無論是人數還是質量都難以保證,
自己在剛開始學c++的時候,出現過很多問題,影響最大的還是以下幾點:
- 1 資源相對較少,當時自己找資源的能力也比較有限,
- 2 資源參差不齊,有些博主自己都沒有完全理解,寫了一大堆專業術語出來裝逼的,
- 3 c++比較權威的書對于c++初學者不是很友好,因為權威書籍很多先驗知識都默認你會了,但這也沒辦法,
所以除了有借此加深鞏固自己之前所學以外,也希望自己的文章可以幫助到更多的c++小白,讓越來越多的人喜歡上c++,愿c++經久不衰,
引言
再次宣告,本篇文章是讓小白過渡到初學者的文章,因為本人也是初學者,所以掌握的知識的全面程度和深度肯定是有限的,但學習本身就是不斷的擴寬自己的廣度和深度,所以這很正常,就如同牛頓力學過度到量子力學一樣,牛頓力學沒有錯,量子力學也沒有錯,只是適用范圍不同罷了,或者說量子力學的適用范圍更大,但不管怎么說,能在一定范圍內正確解釋世界規律的,我覺得就是好理論,
先驗知識宣告:在進入聊天室的學習之前,必須要有一定的c++基礎知識和計算機相關的基礎知識,沒有這些基礎,什么牛鬼蛇神來了都沒有,就算是所謂的“天才、聰明人”,也只是通過類比的方式,結合他自己之前類似的經歷推出來的(我對天才這個詞很反感,我覺得就是騙騙世人,給人們找借口的詞匯,如有不適敬請見諒),所以如果沒有掌握這些知識,你看起來無比難受是很正常的事情,
具體的先驗知識:(其中黃色是必須掌握,淺色黑體是掌握了對細節的把味訓更好)
1、c++基礎部分:類初步(如建構式解構式、公有繼承私有繼承等)、STL基本使用(deque、vector、list、string、chrono時間庫)、命名空間、列舉、基本關鍵字(typedef、using)、const參考和值傳遞的區別、記憶體對齊、右值參考和左值參考的區別、例外、c++11新特性(加強for回圈、智能指標)還有其他c和c++相同的部分、c++多執行緒基礎,
2、計算機網路基礎:c++asio網路庫簡單api使用、tcp報文格式、計算機網路資料是如何從一臺主機上經過5層模型(或者7層參考模型)到達另一臺主機的宏觀了解,
3、liunx基礎:liunx最基本命令、liunx下cmake使用、liunx非常基本的腳本撰寫,
4、其他:像google protobuf等序列工具的使用、為什么要序列化、protobuf為什么快等,
細心的同學可能發現了,為啥我沒有把c++多執行緒標記為必會呢?因為我們這個聊天室是一個循序漸進的版本,因此如果沒到后面多執行緒的版本,不需要掌握c++多執行緒基礎當然也可以駕馭,
還有就是,如果對c++記憶體掌握程度高的話,對一些細節的理解肯定還會更好,畢竟我們學習知識肯定是知其然還要知其所以然,再功利點說:遇到bug你也能知道原因然后快速定位去解決嘛,
聊天室初步
1 總體設計
正所謂:兵馬未動,糧草先行;理論是用來更好指導實踐的,有一個好的架構體系,或者說在設計之初就考慮好很多東西的話,對后面無論是出問題還是迭代肯定都會更好解決,(可以結合 如何學習編程 提到的守恒思想去分析),
無論是設計和分析問題,首先要把握的就是他的核心,用哲學的話來說就是:把握事物的主要矛盾,其實也就是把握事物的本質,
聊天室聊天室,核心肯定是提供一個較為舒適的聊天服務,把握本質以后,接下來我們做的事情是什么?——計算機分治思想,或者簡單點說,把問題分解,
其實細心的同學在生活中就可以觀察到:無論我們做任何事情,無形之中其實就已經把這件事情分成若干字問題進行處理了,
比如在吃飯的時候,先拿起筷子,做好姿勢、選中要夾的菜、計算筷子到要夾的菜要走什么樣的路徑、夾中菜后把握怎么樣的力度可以不讓菜掉下來…
回到正題,那么我們該如何把問題分解呢——剪取不重要細節,借鑒或者類比之前吃飯的例子,舒適的聊天室,本質上就是多人之間進行聊天,那我們先分析兩個人的情況,也先不管舒不舒適的問題,那現在的問題就變成了——兩個人的聊天室,
如果加入服務器——客戶端的模型思想:服務器用來接收和發送這兩個人的訊息,客戶端負責(從命令列)接收訊息,并交由服務器處理,同時還會接受來自服務器的訊息,
這其實還是有點抽象,簡單點說,舉個例子:A和B同學聊天,現在A同學想對B同學說 “ni hao”,那么簡單至極有兩種方式:1 A直接給B發訊息, 2 A給一個中轉站發訊息,由這個中轉站給B發訊息,
有的同學可能會說:“哎呀,那肯定是第一種了,第二種這么麻煩”,但是我們簡化問題的時候也不能忽略原本的內容——也就是俗話說 未雨綢繆,現在是兩個同學發訊息,如果是五個同學、十個同學呢,這就不好處理了,所以目前我們就使用方法2,
到這,我們的1.0版本的聊天室已經逐漸浮出水面了:A同學和中轉站建立連接,之后向中轉站建立連接;B同學和中轉站也建立連接,接受中轉站發送過來A的訊息,
然后我們發現,無論有多少個同學,都要和這個中轉站建立連接,而每一位同學做的動作都是差不多的——和中轉站建立連接、發送或接收中轉站的訊息,
如果把中轉站換個名字——服務器,把每個同學的動作邏輯換個名字——客戶端,
那么聊天室1.0的雛形就出來了——服務器用于和客戶端連接并收發訊息;客戶端用于接收用戶輸入并收發服務器的訊息,
2 思路設計
下面我們就來逐步分析服務器和客戶端都是怎么設計的,
1 客戶端,客戶端由兩個方面組成:接收客戶輸入并把訊息發送給服務器 和 接收由服務器發送給客戶端的訊息,還是一樣,繼續分解問題:先考慮接收客戶輸入并把訊息發送給服務器怎么做?接受客戶輸入:可以用cin的getline接收,并把訊息放到一個佇列里;把訊息發送給服務器:借助c++asio網路提供的api即可,再來看服務器發送給客戶端的訊息怎么做?服務器發送給客戶端的資料通過網路傳輸最開始肯定是發到網卡上,但是對網卡的操作也太底層了,因此借助c++asio網路庫——借助asio網路庫的api接收服務端資訊,并用佇列放到記憶體,并用cout輸出即可,即:
- 接收客戶輸入并把訊息發送給服務器:用cin的getline接收用戶輸入,并把訊息放到一個佇列里,最后用asio庫api發給服務器;
- 接收由服務器發送給客戶端的訊息:借助asio網路庫的api接收服務端資訊,并用佇列放到記憶體,并用cout輸出,
2 服務器,服務器也是由兩個部分組成:接收客戶端訊息 和 將聊天室訊息發送給客戶端,因為和客戶端有點類似,這里直接給出結論,即:
- 接收客戶端訊息:通過asio網路庫api接收客戶端訊息,并把所有訊息都放到一個佇列里,;
- 將聊天室訊息發送給客戶端:將佇列中的內容借助asio網路庫的api廣播(發送)給所有客戶端,
3 資料結構設計(細節設計)
上面的設計內容部分算是結束了,但具體如何去設計類和資料結構還有待商榷,
(1)分析訊息協議部分
還是一樣,將分治的思想融入進來,無論是客戶端還是服務器,最先要解決的,就是雙方要統一訊息的格式,也就是我們常說的協議,
因此我們設計一個chat_message類,用于存放訊息,同時規定:訊息結構是 訊息頭部 + 訊息體的形式,訊息頭部存放了訊息體的長度和訊息型別(比如是客戶端發送給服務器聊天的訊息還是服務器發給客戶端的訊息),而且是定長的,這樣就可以通過頭部去處理訊息體的內容,
簡單表示一下就是:
struct Header{
int bodySize;
int type;
};
enum MessageType {
MT_BIND_NAME = 1,
MT_CHAT_INFO = 2,
MT_ROOM_INFO = 3,
};
class chat_message {
Header m_header;
char data[header_length + max_body_length];
};
(2)分析客戶端
之后分析客戶端,cin的getline接收用戶輸入,同時還要有一個佇列,簡單表示就是:
while (std::cin.getline(line, chat_message::max_body_length + 1)){
chat_message msg;
auto type = 0;
std::string input(line, line + std::strlen(line));
std::string output;
if(parseMessage(input,&type,output)){
msg.setMessage(type, output.data(), output.size());
c.write(msg);
}
下面是chat_client的表示:
chat_client {
chat_message read_msg_;
chat_message_queue write_msgs_;
};
再分析一下要有什么函式:
1 要有和服務器連接的函式——目前放在建構式里面,
2 要有接收函式——接收服務器發送的資料,
3 要有寫出函式——向服務器發送自己的訊息,
因此類可以表示為:
chat_client {
public:
//連接函式和接受函式都在建構式里面了
//即chat_client(xxx) <==> connect + accept
chat_client(xxx); //有參建構式
void write(const chat_message& msg);
void close();
private:
chat_message read_msg_;
chat_message_queue write_msgs_;
};
(3)分析服務器
服務器除了要和客戶端連接chat_server,還要有一個聊天室chat_room接收訊息,但是在廣播訊息的時候,需要向每個客戶端都發訊息,因此用chat_session表示接入進來的客戶端,簡單表示如下:
class chat_room{
private:
chat_message_queue recent_msgs_;
};
class chat_session {
private:
chat_room& room_; //屬于哪個聊天室
std::string m_name; //這里是這個session的名字
chat_message read_msg_;
chat_message_queue write_msgs_;
};
class chat_server{
public:
//有參建構式里包括了connect和read
chat_server(xxx);
private:
chat_room room_; //管理所有的room
};
再分析一下需要有什么樣的函式:
1 對于room來說,需要有客戶端加入到聊天室的join函式、需要有客戶端離開的leave函式和向所有客戶端廣播的deliver函式,
2 所有的具體處理函式放在chat_session中,server只負責connect和read、room負責控制客戶加入退出和發送,到這其實已經足夠,但為了封裝和可擴展性,把server的read和room的發送放在了session里面做,即 read <=> session.start, deliver <=> session.deliver,
更完整的類宣告如下:
class chat_room{
public:
void join(chat_session_ptr);
void leave(chat_session_ptr);
void deliver(const chat_message&);
private:
chat_message_queue recent_msgs_;
};
class chat_session {
public:
void start();
void deliver(const chat_message& msg);
private:
chat_room& room_; //屬于哪個聊天室
std::string m_name; //這里是這個session的名字
chat_message read_msg_;
chat_message_queue write_msgs_;
};
class chat_server{
public:
//有參建構式里包括了connect和read
chat_server(xxx);
private:
chat_room room_; //管理所有的room
};
當然,因為要結合c++的asio庫,所以宣告肯定還要更復雜一些,但那都是asio的東西,把握了這主體的東西對我們的編程來說就足夠了,
聊天室1.0
下面來看看聊天室1.0的內容:
一共分為5個檔案:
1 chat_message.hpp、structHeader.h、structHeader.cpp用于存放訊息格式的約定(協議),
2 chat_server.cpp放服務器相關邏輯,
3 chat_client.cpp放客戶端相關邏輯,
至此完成的就是asio的例子程式完成的內容,不過雖然功能一樣,但是我們把訊息變成了type進行了一個小改動,這樣讓我們的可擴展性就提升了一些,我們在此基礎上加入客戶端可以發送“系結名字”的訊息,
當然代碼很簡單,完整代碼我把它放到了github上,后續我們會逐漸對他進行更新和迭代,在循序漸進中慢慢感受理論與實踐相結合的樂趣,
聊天室1.0 github地址:
聊天室1.0
參考文獻
1 b站課程
2 boost-asio網路庫
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/374755.html
標籤:其他
