這篇的重點內容是講解算法，但是在正式開始之前，我強烈建議你再回顧一下上一篇的內容，因爲要理解這個算法，就需要意識到協議的具體細節不重要，重要的是這種協議是否可以用一種樹形結構來表達，而且在這個結構中，每一個節點（即field）要麼是一個必要節點，要麼是一個可選節點，且它最多隻依賴於一個之前的（如果我們以文件目錄樹來想像這棵樹的話，一個節點更靠前就意味着這個節點更靠近上方的位置）節點，即，不能出現一個節點依賴於之前的多個節點——除非這些節點可以合併爲一個複合節點（即子協議field）——或之後的某個節點，但是多個節點都依賴於之前的同一個節點的情況是允許的（通常，我們也可以把這些節點合併爲一個複合節點）。通俗的講，就是我們接下來要討論的這個算法，與這棵協議樹長得什麼樣子無關（對於同一個協議，不同的人可能將它描述成不同的樣子，這種情況是可能的，也是允許的），而只與每個節點的性質有關。正是這個特性，使得這個算法具有極強的通用性。這樣，我們只要保證我們描述出的協議樹與協議文檔是一致的（檢查其正確性也要比分析一堆的if else和位運算容易得多），那麼就可以期待我們能夠得到一個正確的結果。
聽起來，這個算法好像很複雜，其實不然，它意外的非常簡單，但需要你有較好的想像力。是不是有點迫不及待了呢？好，現在我們先從一個特例開始：所有節點都是必要的節點，沒有任何兩個節點有依賴關係（即所有節點都是獨立的）。對於這種情況，我們想像一下把這棵樹“拍平”，只留下葉子節點（但先後順序不變），那麼這個葉子節點組成的節點序列，不就是我們要的field序列了嗎（因爲每個複合節點在bit流中的起始位置，就是這個複合節點的第一個葉子節點在bit流中的起始位置，而大小就是所有葉子節點的大小的和，然後想象將bit流映射到這個field序列上）？而要得到一個“拍平”的樹，我們只需要執行一個深度優先的遍歷算法就可以，是不是很簡單呢？（事實上這個特例有更簡單的處理方法，就是按協議寫一個大大的嵌套式的struct，然後直接對buffer指針做一個強制類型轉換即可，這個例子提醒我們，程序設計是一門非常靈活的藝術，我們不能教條的去看待它，這也是我本人不欣賞《設計模式》一書的原因）
那麼當我們引入了可選節點後，是否情況就不一樣了呢？其實是一樣的，還是想像我們把一棵樹“拍平”，只不過現在，有些葉子節點我們需要刪除，刪除的原則就是，先一個一個的檢查這個葉子是否是必要節點，如果是，就保留這個節點，同時修正bit流的訪問偏移量（即指向下一個field的起始位置）；而如果不是，就向（已生成的）序列的前方找到它的條件節點，然後看看它的條件節點的內容是不是允許這個可選節點出現（即計算出這個可選節點的個數），如果允許，就保留（並修正bit流的訪問偏移量），否則，就刪除。看到了嗎？差別只有一點點，是不是也很簡單？（現在你應該明白，爲什麼上一篇文章中，我們的協議描述接口要設計成那樣了吧？同時，正因爲大部分的協議都是這種情況，所以我們不能象上一種情況那樣，用一個靜態的struct去處理它們）