好久沒有更新這個系列了，因爲我之前也說過，前段時間實在太忙了，而且早在一個月前就預示着本月將更加忙！事實也確實如此！終於在國慶前夕完成了既定的計劃，心裏也終於可以長出一口氣了。最近在忙什麼呢？其實就是OpenUOM++！既然OpenUOM++-ng已經不在計劃內，那麼讓OpenUOM++支持多處理就是必然要做的了。
還記得下面這張圖嗎？我暫且叫它版本1：
起初，我一直以爲畫完這幅圖就已經證明自己對OpenUOM++很精通了，後來我慢慢知道我錯了，於是，我畫出下面這幅圖的時候，事實證明我當初的理解是多麼膚淺！下面這幅圖我稱爲版本2：
版本1的出現是在2012年，那說明我對原生的OpenUOM++已經有了比較深刻的理解，但是在經歷了2012的後半年，2013年的整年，2014年的上半年，我一直在等待OpenUOM++的更新升級，這期間我也一直在關注硬件和網絡技術的進展，OpenUOM++落後了，誰也沒有提到過這一點，等到了2014年的農曆年前後，我覺得我該做點什麼了。就這樣，出現了版本2。如果說之前的文章展示的都是設想，那麼有了這副版本2之後，它就是一個實際的實現了，雖然是最簡的實現。目前還有很多TODO：
1.目前每一個multi_instance只能由一個線程的multi_context處理。
當初我希望的是所有的線程都能處理所有的multi_instance，但是由於如此一來鎖開銷太大，只有作罷。事實上OpenUOM++的原生架構很難實現多線程擴展，因爲每一個multi_instance都有一個buff，每一個context也有一個buff，每一個multi_context的所有instance共享一個buff，這些buff被複制來複制去，很難實現細粒度的鎖，因爲你很難定義什麼是一個不可打斷的事務。
2.目前的多隊列TUN驅動在返回包隊列分發的實現有些粗糙。
3.TUN驅動模塊和OpenUOM++之間的耦合度太高，不利於分別擴展升級。
4.線程間的信號分發機制太粗糙。
5.如果OpenUOM++的某個線程從tun收到一個廣播包，分發效率太低。
6.客戶端無法實現多進程打開同一個虛擬網卡，而只能捆綁多個虛擬網卡。
...
以上這些都是需要慢慢完善的。我希望自己不會就此作罷，也希望和高手們進一步交流。
在實現的過程中，遇到過無數的問題，和起初設計的時候想象的根本不一樣，很多細節都沒有考慮到。比如tap的ARP廣播分發問題，當時我覺得隨便分發到一個線程即可，後來發生了無數次的段錯誤，assert失敗...最終發現，即使是ARP也沒有什麼特殊的，只要解析出ARP的內容中的sip和dip即可，將它和IP報文同樣對待...
還是那句話，如果你能畫一張圖把一個技術展示明白，那麼你絕對掌握了這項技術，如果你畫圖的過程中，突然不知道怎麼畫了，那麼這點就是你的技術盲點。不要抱怨不會用畫圖軟件，紙筆伺候，手繪即可。手繪圖更能讓你的精力集中在圖本身而不是畫圖軟件怎麼用，因爲你用你的腦子驅使你的手，藉助筆的硬度和鉛，墨水等在紙上留下痕跡，你的大腦完全起100%的作用，反之你用畫圖軟件的話，你必須通過電腦的CPU芯片，即你必須想辦法告訴CPU如何展示你腦子裏想象的圖像，而CPU卻並不如紙和筆那樣做你的奴隸，反之，你要迎合它的規則...說了這麼多，其實我想說的是，版本1的最初版就是我手繪的，如下圖所示：
最後，不要索要代碼，代碼通過郵件，QQ分發是一種不正規且不優雅的傳播方式，這是Linus的觀點，我很認同。如果你感興趣，你一定能找到或者寫出想要的代碼，或者說，你也許能幫到我。
---
浙江溫州皮鞋溼，下雨進水不會胖。