關於tcp通訊中，recv函式接收資料大小的問題，之前一直覺得，只要是客戶端與伺服器一發一收的模式，那麼recv接收的資料大小一定是函式中指定的資料大小。這次寫了客戶端與伺服器通訊的程式，在這上面栽了乙個大跟斗。
程式功能如下：通過客戶端與伺服器的通訊，實現檔案的傳輸，客戶端每次傳送1k的資料，伺服器每次接收1k大小資料並將資料儲存到檔案中，就這樣一發一收的迴圈傳送接收，實現了檔案的拷貝。
但在實際的測試中，發現不能實現檔案的拷貝，因為對每個1k大小的傳送包都編了序號，發現在傳輸的過程出現了錯誤，但tcp是的宗旨是可靠傳輸，這就相互矛盾了。為此我到網上去搜尋相關資訊，看廣大網友對此的看法以及解決方法。在網上搜尋的資訊不多，只發現乙個解決該問題方法，那就是讓伺服器sleep一秒，我將伺服器睡眠一秒後執行，發現是能夠解決一點問題，但只能將錯誤的概率減少，不能徹底解決問題。
既然網上暫時沒有找到解決方法，我只能夠自己慢慢測試了。因為之前覺得tcp的可靠帶著recv一起可靠了所以沒有對返回值進行判斷，現在加上對返回值的判斷，發現
錯誤傳輸時，recv返回值只有幾百k(所以說一定一定要對函式返回值進行判斷，這樣能減少程式bug，也能更加快速找到問題所在)，發現問題所在了。
原來當recv去接收時，核心只傳送了幾百k到使用者空間，並沒有傳送1k（至於為什麼會這樣，我就不得知道了，沒有去深究），這樣我對返回值進行判斷，等於指定值時，就接著迴圈接收，少於指定值時，多加乙個迴圈結束，直到將1k全部接收為止，這樣就完美的解決了，部分**如下
while (1)
#if 1
/* 判斷資料是否接收完整 */
if (recv_back < sizeof(data))
m = 1036 - remain_data_size - 4; // m為上一次接收得資料量 - 4
for (n = 0; n < remain_data_size; n++)
else if (k >= 1028) // num
else
}/* 當兩個值相等時，代表資料接收完畢 */
if (recv_back == remain_data_size)
remain_data_size = 1036 - recv_back - remain_data_size;
}} }
接收資料 recv
int recv socket s,const char far buf,int len,int flags 該函式用於從已連線的套接字上接收資料，此引數既可用於面向連線服務的socket，也可用於非連線服務的socket。但是對於面向連線服務的套接字來說，則一定要使用recv 函式，而對於面向非連...
大量資料的tcp的recv
最近在調程式的時候，發現傳送端傳送乙個119136個char的記憶體的時候，在接收端不能全部接收，於是，通過除錯發現，必須在接收端多次的recv以後，進行拼接 如下 char lenbuf 4 int ilen 接收資料 int bytes 先接受前面的四位訊息體長度 if bytes recv c...
TCP資料接收處理方法
tcp作為流式傳輸協議，只能保證傳送和接收的資料，順序是一致的，而無法保證send和recv時返回的長度是一致的，send的資料有可能是多條資料的合併，也可能是大資料的分包，那麼如何解決這個問題？通常建議通過約定協議解決，比如增加頭，頭里帶上資料長度，接收方通過資料長度來讀對應的資料。寫個簡單的偽 ...