最近接到一個關於收看直播資料包亂序處理任務，服務端會一直在輪詢傳送直播的資料（也可以是升級包資料），附帶有包序號和總包數以及每包的長度，各個終端接收直播資料，直到資料全部接收完為止；

一般領導安排任務的時候都是三兩句話的功夫，程式設計師可能就需要兩三天來實現這個需求，排除大神之外，我們都是再普通不過的程式設計師了。

組長給了一點建議：收看直播在實際場景真正用的時候，下載的檔案大小可能很大，然後可能還有多個終端同時在下載，建議是集齊一小段連續片段在磁碟上寫一段，最後所有片段做一個合成；
這個方案昨天上午實現了一部分後發現實際用程式碼實現過程中並沒有那麼簡單，需要考慮的情況有很多種，比如分片大小和分片的起止索引，如果在網路不好的情況下，丟包處理等等。於是就自己想了一個比較偷懶的方案，實際測試過程中發現效果還不錯，現在記錄到部落格裡來；

1.接收端始終從包序號=0的時候開始接收，並記錄下總包數和包長度，同時把所有的包序號儲存下來；

2.每次接收到一包資料，判斷包序號是否存在，存在就偏移到要寫的檔案位置，然後寫檔案，並把對應的包序號移除；

3.當所有的包序號收集完就表示所有資料接收完了。

需要注意的是：

1.由於網路原因可能出現丟包問題，在第一輪接收過程中可能丟了100包，到下一輪可能還會丟失10包，直到把所有的資料包收集完，實際測試過程中最多一次接收完需要接收5輪。

2.第一輪不接收，因為服務端會先發資料後發收看直播指令，所以當接收到的時候已經發送了好幾千包資料了。

下面是具體實現程式碼和實際執行結果：

 當m_mapPacketIndex.size()==0時就表示全部接收完了；

實際傳送的檔案大小和接收到檔案的大小一致；

剛剛同事說上報下載進度有問題，我先看看去；

歡迎廣大網友交流討論更好的實現方案。