在某些時候，當編碼套接字時，人們將面臨接收函式系列（recv, recvfrom,recvmsg）。
這個函式接受一個 FLAG 引數，我在其中看到MSG_WAITALL在網路上的許多示例中都使用了 ，例如 UDP 上的這個示例。
這是MSG_WAITALL標志的定義
MSG_WAITALL（自 Linux 2.2 起）
此標志請求操作阻塞，直到滿足完整請求。但是，如果捕獲到信號、發生錯誤或斷開連接，或者要接收的下一個資料與回傳的型別不同，則呼叫回傳的資料仍可能少于請求的資料。該標志對資料報套接字無效。
因此，我的兩個問題：
- 為什么需要使用
MSG_WAITALLFLAG 而不是0FLAG？（有人可以解釋一個使用它來解決問題的場景嗎？） - 為什么要將它與 UDP 一起使用？
uj5u.com熱心網友回復：
正如參考的手冊頁所提到的，MSG_WAITALL對 UDP 套接字沒有影響，所以沒有理由在那里使用它。確實使用它的示例可能會混淆和/或幾代貨物崇拜/復制和粘貼編程的結果。:)
對于 TCP，OTOH，默認行為recv()是阻塞，直到至少一個位元組的資料可以從套接字傳入資料緩沖區復制到用戶的緩沖區中。當然，TCP 堆疊會嘗試提供盡可能多的資料位元組，但如果套接字的傳入資料緩沖區包含的資料位元組數少于用戶傳入的位元組數recv()，則 TCP 堆疊將復制為盡可能多的位元組，并回傳指示它實際提供的位元組數的位元組數。
然而，有些人發現他們更愿意讓他們的recv()呼叫一直阻塞，直到他們傳入的陣列中的所有位元組都被填滿，不管這可能需要多長時間。對于這些人，MSG_WAITALL標志提供了一種簡單的方法來獲得該行為。（該標志不是絕對必要的，因為程式員總是可以通過撰寫一個根據需要多次while()呼叫的回圈來模擬這種行為，直到緩沖區中的所有位元組都被填充......但它仍然是為了方便而提供的）recv()
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/456317.html
標籤：插座
上一篇：服務器在發送大量資料時被中斷
下一篇：使用套接字編程接收訊息時的問題