原创 函數不能傳遞動態內存

下面這道面試題是有關指針、動態內存分配的相關內容,感覺比較經典,記錄下來大家共享。 問題: What will happen after running the "Test"? #include <iostream> using nam

原创 回射客戶-服務器模型(3)

前面連接的C/S模型只是單方面的客戶端發送數據,服務器端接收數據。那麼本節將根據前兩節已有的經驗知識來實現一個簡單的點對點聊天程序。 注:這裏只實現了以個服務器與一個客戶端的相互收發數據。 下面這篇文章對整個回射客戶服務器的模型建立過程有

原创 回射客戶-服務器模型(4)

由於TCP是一種基於字節流的傳輸,屬於無邊界傳輸,所以它不能夠處理消息與消息之間的邊界問題,因此存在粘包問題。 如下圖所示: M1和M2是從主機A傳送到主機B的兩條消息,那麼中間可能有幾種傳輸情況: a. 兩條消息剛好分別完整的傳輸;

原创 用select改進回射客戶-服務器模型

這一節主要來說一下如何用select函數來改進我們前面的客戶端-服務器模型。 前面我們在處理多客戶端模型時,每當連接一個客戶端時,服務器端就需要開闢一個新的進程來處理新的客戶端,這樣就會耗費很大的內存資源。 而select函數允許進程指示

原创 進程線程的啓動與終止方式的比較

這裏只是先給出進程和線程各個中間過程所用到的函數。

原创 bind函數—綁定地址和端口

在調用bind函數是,可以指定一個端口號,或指定一個IP地址,也可以兩者都指定,還可以都不指定。 服務器在啓動時捆綁它們的衆所周知端口。如果一個TCP客戶或服務器未曾調用bind捆綁一個端口,當調用connect或listen時,內核就

原创 TCP傳輸的可靠性及滑動窗口協議

TCP不可靠的表現:     出錯——通過校驗和解決;     丟包——超時重傳+確認機制解決;     失序、重複——通過TCP頭部的序號解決; TCP如何保證傳輸的可靠性? 1.應用數據被分割成TCP認爲最合適發送的數據塊,稱爲段,傳

原创 線程的狀態及其相互轉換

線程從創建、運行到結束總是處於下面五個狀態之一:新建狀態、就緒狀態、運行狀態、阻塞狀態以及死亡狀態。 其中,阻塞狀態會因爲不同的原因而產生的,所以根據不同的阻塞狀態,線程的狀態轉換圖又可以細化如下: 注意:要從Blocked狀態轉換到

原创 線程互斥——互斥鎖與讀寫鎖

一. 線程同步與互斥概念     1. 線程同步 是一個宏觀概念,在微觀上包含線程的相互排斥和線程先後執行的約束問題;解決同步方式:條件變量和線程信號量;    2. 線程互斥 線程執行的相互排斥;解決互斥方式:互斥鎖、讀寫鎖和線程信

原创 進程的啓動和終止

C程序的啓動過程         我們通常認爲C語言的起始函數是main函數,實際上一個程序的啓動函數不一定是main函數,這個可以採用鏈接器來設置,但是gcc中默認main函數就是C語言的入口函數,在執行main函數之前,內核會啓動一個

原创 線程的清理、控制以及線程屬性的概念

一. 線程清理和控制函數 如同進程可以調用atexit函數安排在它退出時需要調用的函數一樣,線程也可以安排在它退出時執行一些函數。這些清理函數記錄在棧中,所以它們執行的順序和註冊的順序是相反的。 #include <pthread.h>

原创 線程的創建和終止

一. 線程的創建 #include <pthread.h> int pthread_create(pthread_t *restrict tidp, const pthread_attr_t *re

原创 回射客戶-服務器模型(1)

最近在學習socket編程,根據自己的學習過程及學習筆記,下面來梳理一下如何實現一個簡單的回射客戶-服務器模型,也藉此來熟悉一下socket、bind、listen、accept、connect這些函數的使用。 簡單的回射客戶/服務器模型

原创 堆和棧理論以及程序內存分配

一. 預備知識—程序的內存分配        一個由C/C++編譯的程序佔用的內存分爲以下幾個部分: 棧區(stack):由編譯器自動分配釋放,存放函數的參數值,局部變量的值等。其操作方式類似於數據結構中的棧;堆區(heap):一般由程

原创 類對象作爲函數參數

網上看見一段代碼,是關於類對象作爲函數的參數,其中有幾點知識,貼出來大家一起學習。 直接來看代碼: #include <iostream> #include <string> using namespace std; class pe