自動重傳請求arq 是差錯控制技術之一。從廣義上來講，arq 主要有兩種方法來應對網路出
錯，即ack 與nack，其中包括多種實現方式，例如停等協議arq、滑動視窗arq、快速重傳
arq 等。
（1）停等協議arq：指的是在源端每次只向客戶端傳送乙個包，同時開啟定時器。在定時時
間之內，如果收到ack，就重置定時器並傳送下乙個包，如果沒有收到，則認為丟包，並重傳這個
包。這種方式的缺點是具有非常低的傳輸效率。
（2）滑動視窗arq：指的是在源端維持著乙個具有一定大小的傳送視窗，在傳送視窗內的所
有資料報可以以連續的方式發出，中間不用依次等待客戶端的ack 確認。在客戶端以積累確認的
模式向源端進行反饋，即不用逐個傳送ack，而是在連續收到幾個包後，對順序到達的最後乙個包
序號傳送ack，表示這個包及之前的所有包都已經收到。在亂序比較嚴重的網路下，這種積累確認
模式會有很低的效率，部分沒有按照順序送達但實際已經送達的包也會要求重傳。
（3）快速重傳arq：快速重傳arq 指的是如果客戶端接收到了序號跳躍的資料報，則立即
給源端傳送最後乙個連續的資料報的ack，如果源端連續收到3 個重複確認，則認為該ack 的
下乙個資料報丟失了，並立即重傳丟失的資料報。
前幾種方式都是使用ack 機制的傳輸協議，即當客戶端在收到資料後會給源端返回乙個「已
收到資料」的訊息（ack），告訴傳送方「我已經收到了」，從而確保資料傳輸的可靠性。
（4）nack：客戶端利用反饋報文，將所有未收到的包序號傳送到源端進行重傳。
傳統的fec 技術是一種資料碼之間的編碼技術，而本文使用的前向糾錯技術fec 是一種資料
包級的編碼技術，它可以根據流**資料報的重要程度進行有選擇的保護，它由rfc5109 標準所定
義。其主要原理如下：
源端從**資料流中取出若干個rtp 資料報，並對所有的資料報進行異或操作（其中包括rtp
頭），這樣便可以得到乙個含有fec 資訊的rtp 資料報，在客戶端可以從fec 頭所攜帶的荷載信
息部分得知那些資料報用於產生fec 包，從而當其中乙個資料報丟失時，利用這個資料報恢復出任
何乙個用來產生它的資料報，如圖3-4 所示，其中編碼長度未指定，由程式開發人員進行設計。
本系統中可以設定兩種編碼長度，當編碼長度為2 時，代表兩個資料報產生1 個fec 包，當編
碼長度為4 時則代表4 個資料報產生乙個fec 包。
fec 機制的加入大大提高了整個系統的容錯率，提高了系統的服務質量（qos）*。
根據以上分析，自動重傳請求arq 與前向糾錯機制fec 是如今在流**應用中常用的用來保
證傳輸質量的兩種手段，其對比分析如表3-1 所示
類的前向宣告與呼叫
類的宣告與變數的宣告類似，如 int a 定義乙個變數或宣告乙個變數 class a 宣告乙個類，類名為a 注 宣告乙個類的時候，不占用任何儲存空間 不知正確與否，看到網上好多人這麼說。用sizeof試驗時，sizeof a 是不能通過編譯的 下面通過例項來進行說明類的前向宣告與呼叫問題 inclu...
Unity 前向渲染與延遲渲染
只要在攝像機設定下就可以了 由於我設定了9盞燈光，而unity buildin只支援4盞，所以顯示的燈光是錯誤的 由上圖可見 unity前向渲染的順序是 先做深度圖，我猜是為了做深度剔除，深度測試，避免重複繪製，然後在renderloop裡對每個物體進行光照法線計算 天空盒透明物體 後效貌似延遲渲染...
oc 關於標頭檔案宣告 與前向宣告
參照 1.import和 include的區別 當我們在 中使用兩次 include的時候會報錯 因為 include相當於拷貝標頭檔案中的宣告內容，所以會報重複定義的錯誤 但是使用兩次 import的話，不會報錯，他會做一次判斷，如果已經匯入一次就不匯入了 import本身有防止標頭檔案被重複包含...