令牌桶重置引起的詭異現象

前情簡介

這個故事講起來可能有點費事，前先後後涉及到的東西比較多，我但願儘可能能把故事講清楚，不足之處，還請各位看官包涵。

首先說一下令牌桶：

令牌桶是一種經常使用的流量控制技術。令牌桶自己沒有丟棄和優先級策略。原理：
1．令牌以必定的速率放入桶中。
2．每一個令牌容許源發送必定數量的比特。
3．發送一個包，流量調節器就要從桶中刪除與包大小相等的令牌數。
4．若是沒有足夠的令牌發送包，這個包就會等待直到有足夠的令牌（在整形器的狀況下）或者包被丟棄，也有可能被標記更低的DSCP（在策略者的狀況下）。
5．桶有特定的容量，若是桶已經滿了，新加入的令牌就會被丟棄。所以，在任什麼時候候，源發送到網絡上的最大突發數據量與桶的大小成比例。令牌桶容許突發，可是不能超過限制。

畫個圖可能更直觀：

啊，我好像不會畫高大上的圖啊，將就一下。。

說完令牌桶，再說一下個人應用場景，一樣，畫個圖吧：

大體流程如上圖所致，具體的過程更爲複雜一些。

應用場景：

奇怪的現象是，當server-phone旋轉後，偶現client端屏幕畫面卡死現象。

案情偵破

猜想可能的緣由：

• client 解碼模塊出現異常
• server 編碼模塊出現異常
• server 沒有收到client的request

令牌數量	VideoSource幀	用於編碼的幀	發送出去幀
request	input	drawing	output

邏輯是這樣的：

收到令牌: request++
|
|
收到Input（且 request大於0時）：request--， drawing++
|
|
監聽到encoder的output： drawing++
複製代碼

理論上

request = drawing = output

input 會因爲沒有request的狀況被丟棄

從 VideoEncoder 收到圖像幀到編碼完成，輸出適用於在網絡上傳輸的 H.264 data 是一個耗時過程。

當屏幕旋轉時，因爲 ***VideoEncoder*** 會被銷燬，而後再建立。

當旋轉屏幕時

有drawing未被output --> 丟幀
丟幀                --> client收不到數據
client收不到數據    --> 再也不產生令牌request
再也不產生令牌request --> server收不到request
server收不到request --> 再也不進行drawing
複製代碼

因此解決辦法就是，重置Encoder時，要從新計算request：

reqeust = request + drawing;
drawing = 0;
複製代碼

案件總結

要謹慎當心對待每個異步過程。

你能不能來找我一下，我準備了酒，也準備了故事！372702757