封包組合與剖析器設計@node.js (III) 產生剖析器

一、前言

上一篇文章,我們介紹如何使用 Dissolve 模組來為你的 DSL 格式封包製作剖析器,在文章最後,我留了一個牛刀小試的資料物件,以及這個資料的編制格式。但是我相信!!!  應該是沒有人有真的試著用 Dissolve 去剖析他!!  科科....
 
  好啦!假設真的有人試著去剖析他好了!(這樣我的故事才能說下去)

二、用 Dissolve 的困難

假使那一題牛刀小試你做過了,你一定會發現,這個看起來也沒有多複雜的資料,竟然會這麼難搞啊!除了數字跟字串,你還遇到了數字的陣列,以及字串的陣列。假使你對 Dissolve 的 loop 有點了解,你會發現還是有點難做,因為你會遇到 loop 中還有 loop 的情況,再考慮剖出來的資料片段要掛在哪個命名空間下,更是雪上加霜啊!而且,當你遇到 3 層以上的 loop,我保證你大概會一邊寫 code 一邊哀爸叫母~
 
  我在工作專案上就曾經遇過這樣的困難,當初是在剖析 ZigBee 的封包,最哭臉的就是 ZCL 的訊息框剖析,有興趣的人可以看看白皮書,那花樣真的很多啊~ 當初,就是照 spec 的規範,一條一條硬幹,最後當然也是順利做完啦!後來,我們有另一個 BLE 的 project,也需要做類似的事情。當時我就想,「哇操,這麼 low level 的東西,雖然是沒有多偉大,但是做起來也是挺辛苦的!這次絕對要好好地研究一下剖析器的實作,要怎樣才能有效率一點。」
 

三、Dissolve-Chunks 的誕生

正是因為要解決工作上的問題,我花了一點時間自己設計了一個「宣告式的剖析器產生器 - Dissolve-Chunks」(好繞口~)

  為什麼要取這個名字呢?因為它是基於 dissolve 這個模組,所以有很大的功勞是 dissolve 所貢獻的,所以向它致敬。後面加一個 Chunks,指的意思是:「我可以把一串很長的資料,切割成一段一段的 data chunk,每一小段都有各自對應的剖析規則來處理,各個擊破」。
 
  這個模組有一些內建的規則,也接受使用者自訂新的規則。面對這些資料,我只要把需要用到的「規則」一一宣告,接著呼叫 join() 把這些規則依序串起來,最後用 compile() 方法,就能組合出一支剖析器,而且命名空間也在宣告時指定好即可,不需要像 dissolve 一層層 tap() 時指定。當我們把最小片段的規則列出來後,還可以使用 squash() 將幾個剖析規則,擠壓成一條中小型片段資料的剖析規則。
  
  重點是,寫 parser 幾乎都是用「宣告」的,這意味著你會很少寫到「剖析過程的處理細節」 (當然,如果是要自訂剖析規則的話,你還是得自己寫處理邏輯)。
  
  這邊我要說明一件事,就是呢!當我在做 parser 的時候,我發現了兩件事情:
  • 格式定義好了,規則就是死的
  • 同樣的 parsing code 一直重複出現

  我就在想,阿規則既然是死的,然後我又一直寫重複的程式碼,在處理那些類似格式的東西,真的好沒效率。當時第一個想法,就是至少應該把重複的程式碼抽成一支函式吧!後來呢,我覺得這根本就跟資料驗證器 (data validator) 或是宣告 Schema 的想法很類似,驗證規則還不就那些,對吧!阿驗證規則也是規則,就是一撮一撮的 validating codes。當我需要執行哪一種驗證,就跟全世界宣告「我是什麼鬼」,然後就有對應的驗證規則會去驗證你是不是個鬼!(什麼鬼啊~~好爛哦!) 我想這應該就是人家講策略模式典型的例子吧!
 
  好啦!總之,我就依照我的發現跟想法,就做出了 Dissolve-Chunks 這個鬼東西,雖然說 npm 上下載量很低,應該沒有人在用啦!哈哈~ 不過呢,這個模組正實際用在我們公司自己的專案上面,到目前為止是還沒出過什麼大問題。小問題也在專案的實際應用上,一一地修正掉了,所以應該還算穩定。其實,它真的蠻好用的,節省我們工程師不少的時間。不管如何,這都是工程師寫程式解決自己痛點的好例子!
 

四、使用 Dissolve-Chunks 產生剖析器

我們的資料跟格式是
var data1 = {
    x: 100,
    y: 'hello',
    z: {
        z1: 30,
        z2: 'world!',
        z3: [ 1, 2, 3, 4, 5 ]
    },
    m: [ 'It ', 'makes ', 'my ', 'life ', 'easier.' ]
};
底下這張圖顯示了我們自訂封包的格式,比較清楚的表格可以看這裡


這一段封包,它的 buffer 如下 (這可能是你從外部接收進來的原始資料)
var data1_buf = new Buffer([
  0x64, 0x05, 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x1e, 
  0x06, 0x77, 0x6f, 0x72, 0x6c, 0x64, 0x21, 0x05,
  0x01, 0x02, 0x03, 0x04, 0x05, 0x05, 0x03, 0x49,
  0x74, 0x20, 0x06, 0x6d, 0x61, 0x6b, 0x65, 0x73,
  0x20, 0x03, 0x6d, 0x79, 0x20, 0x05, 0x6c, 0x69,
  0x66, 0x65, 0x20, 0x07, 0x65, 0x61, 0x73, 0x69,
  0x65, 0x72, 0x2e
]);
產生剖析器,並試著將這些 binaries 寫入剖析器,看看剖析結果吧!在底下這份程式碼中,它的概念是這樣的:
  • 封包格式已知,我可以用更小段的眼光,依序為每一個小段宣告它的剖析規則
  • chunkRules 這個陣列,裡面所放的每個小規則。每一個小規則,都由 ru 這個物件所提供,它提供了很多常用的規則,例如剖析 uint32le 的整數等等。
  • 每一條 ru 的規則,你可以塞給他一個名稱,例如 ru.uint8('x') 指的就是,等一下你剖析完的 uint8 整數,把它放到剖析物件的 x 這個 property 底下
  • 等到規則一一列完,就 join() 它們,最後呼叫 compile() 把 parser 編出來,這樣 parser 就產生出來吧!我們在 parser 身上掛一個 'parsed' 事件的 listener,當它剖析完之後會引發這個事件通知你
  • 最後,把我們的 binaries (上面給的那段 data1_buf) 寫入 parser 吧!!
var DChunks = require('dissolve-chunks'),
    ru = DChunks().Rule();

var chunkRules = [
    ru.squash([ru.uint8('x'), ru.stringPreLenUint8('y')]),
    ru.squash('z', [
        ru.uint8('z1'),
        ru.stringPreLenUint8('z2'),
        ru.repeat('z3', ru.uint8)
    ]),
    ru.repeat('m', ru.stringPreLenUint8)
];

var parser = DChunks().join(chunkRules).compile();

parser.on('parsed', function (result) {
    console.log(result);
});

parser.write(data1_buf);
你也可以使用另一種 style,一條一條的 rule,依序 join(),最後產生剖析器:
var chunkRules1 = [ ru.uint8('x'), ru.stringPreLenUint8('y') ],
    chunkRule2 = ru.squash('z', [
        ru.uint8('z1'),
        ru.stringPreLenUint8('z2'),
        ru.repeat('z3', ru.uint8)
    ]),
    chunkRule3 = ru.repeat('m', ru.stringPreLenUint8);

var parser = DChunks().join(chunkRules1)
                      .join(chunkRule2)
                      .join(chunkRule3)
                      .compile();

五、後記

想不到這一系列三篇文章,我可以拖那麼久啊!哈哈哈~ 其實 dissolve-chunks 的文件寫得蠻清楚的啦!如果覺得看英文可以接受的話,那麼讀原始文件會更清楚知道如何安排你的rules 或者是怎麼樣撰寫自己的 rules。
 
我想,用宣告式的方式就是程式碼看起來會精簡許多,而且也不會到處都有重複的剖析程式碼。不過,假使你很熱血,其實用 Buffer 提供的 low-level 方法直接硬幹也是可以的,作法千百種,我們只要挑選適合自己的、習慣的方式都 ok 的~~
 
 
 
 
simen

An enthusiastic engineer with a passion for learning. After completing my academic journey, I worked as an engineer in Hsinchu Science Park. Later, I ventured into academia to teach at a university. However, I have now returned to the industry as an engineer, again.

Post a Comment (0)
Previous Post Next Post