客戶端,伺服器發包走向

2022-03-15 03:49:27 字數 978 閱讀 1642

多執行緒模式

其實這個早看過了,在複習一下

主線程建立四個子執行緒,乙個執行緒乙個event_base,專門派發這個

有個監聽執行緒,在監聽執行緒收到連線之後輪詢選擇乙個執行緒就交給他處理了,其實就這麼簡單

在看看包走向

客戶端發過來的

加入以登入為例(不知客戶端是不是走這一套)

1.先打包成protocol形式

2.在livevent裡面有個100k的m_sendbuff,然後將這個protocol資料再封裝一下就是前面加4個位元組的資料的整個長度,然後就是呼叫bufferent_write

3.伺服器響應了讀事件,然後將其放到datastream,因為一次buff_read有可能讀多個包,或者包的格式不對,然後這個也能起到乙個快取的作用,然後從這個流中迴圈讀取,再從記憶體池中取protocol長度的記憶體,然後將其複製到分配到這塊記憶體中

4.然後將這個記憶體池儲存的放到乙個boost::lockfree::queue> m_all_packet;無所佇列中,這個m_all_packet相當於緩衝的作用

5.在netprocsvr子執行緒有個100m的緩衝,我懷疑剛開始經理是不是寫錯了,從無鎖佇列中取出乙個包,然後將其內容拷貝到m_recvbuff裡面,然後將記憶體池歸還

6.接下來就走了共享佇列這塊,都知道,

7.gs這邊也是事先分配好記憶體然後從共享記憶體中取,然後將共享記憶體歸還

伺服器發過去

1.先將其打包成protocol形式的然後從gs這邊的記憶體池分配記憶體,然後放到m_quecmd,我想這個也是模仿net那邊的,那邊也是從記憶體池分配然後放到佇列中

2.然後將這個放到共享記憶體中

3.這邊從共享記憶體中取出之後也是放到乙個sendbuff裡面,然後前面加入了四個位元組的長度

4,客戶端這邊解包這塊也是直接new的,然後放到包佇列中

我在想為什麼接收的包搞緩衝,為什麼傳送的就不搞緩衝,有可能是因為接受是四個執行緒,而傳送時主線程在發在乙個執行緒裡面,而這個緩衝重要是針對多執行緒的

伺服器與客戶端

建立socket操作,建立流式套接字,返回套接字型大小socksrv socket socket int af,int type,int protocol 第乙個引數,指定位址簇 tcp ip只能是af inet,也可寫成pf inet socket socksrv socket af inet,s...

UDP 客戶端伺服器

udp 客戶端 include include include include include define size 100 define ip 127.0.0.1 define port 10086 int main struct sockaddr in addr 建立socket udp so...

客戶端與伺服器

cs與bs 軟體使用方式上的兩種劃分 c s client server pc客戶端與伺服器架構 特點 在伺服器當中就主要是乙個資料庫,把所有業務邏輯都交給客戶端來完成 優點 較為安全,使用者介面豐富,客戶體驗好 缺點 每次公升級都要重新安裝,針對不同的作業系統開發,可移植性差 b sbrowser...