網絡傳輸涉及發送與接收兩方面, 其中接收較為簡單, 而發送卻非常復雜, 通常會涉及一二個難點;


一: 異步發送時的數據亂序列問題


? ? 如果不等上一次數據發完就進行下一次的異步發送, 無法對包的先后順序進行控制, ?所以接收端將無法解析包,
導致接收的數據沒有任何意義; ?針對這個現象, 有人提出弄一個隊列, 向隊列投遞數據, 發送完隊列中的一個再發
下一個; 這種方法是可以解決問題的, 但完全損害了采用異步發送的初衷, 如果這樣還不如直接采用同步發送來得好;
這樣還可以省一個隊列; 如果采用隊列, 數據又不能發送出去, 就可能產生內存的暴漲問題, 又如何解決;?

如果從socket層面來看, 這個問題是沒有好的解決方法的, 但如果從我們發送的數據方面來著手, 就很容易解決了;
為了使接收端能解析接收到的亂序包, 必須為每個包的包頭添加對應的標志符, 指定這個包的用處, 及收到后如何重新
組裝成一個新的包; 這樣我們就可以無顧忌的發送了; ?但這也造成了網絡資源的浪費, 因為每個包可能會多一兩個字節;
一般而言, MAC 層接收的包數據大概在1400左右, 就相當于多產生了 1/700 的流量; 當然我個人覺得這個附加流量是非常
小的了. 所以這種方案最劃算;

二: 異步發送時, 數據發送丟失的現象:


? ? 有時候發送一個數據包, 可能有點大, 一次性發不完, 需要多次發送, 而異步投遞有一個回調函數, 我們可以把發送的字節
及剩余的字節數,還有本次發送負責的數據塊 傳遞進來; 這樣我們在回調里就再次進行發送; 讓剩下的數據發完; 當然如果怕
? ? 亂序, 還是要加上相應標志位來傳輸; 通常為了保證數據發送能一次性完成, 都定義成以太網的包大小即可, (1400個字節);


? ? 第二個難點, 其實并不難; 只是要注意, 發送的時候不要采用臨時內存, 免得沒發送完第二次發送時內存無效的現象發生;

總結

以上是生活随笔為你收集整理的异步传输中的批量发送问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。