好久沒有更新這個系列了，因為我之前也說過，前段時間實在太忙了，而且早在乙個月前就預示著本月將更加忙！事實也確實如此！終於在國慶前夕完成了既定的計畫，心裡也終於可以長出一口氣了。最近在忙什麼呢？其實就是openuom++！既然openuom++-ng已經不在計畫內，那麼讓openuom++支援多處理就是必然要做的了。
還記得下面這張圖嗎？我暫且叫它版本1：
起初，我一直以為畫完這幅圖就已經證明自己對openuom++很精通了，後來我慢慢知道我錯了，於是，我畫出下面這幅圖的時候，事實證明我當初的理解是多麼膚淺！下面這幅圖我稱為版本2：
版本1的出現是在2023年，那說明我對原生的openuom++已經有了比較深刻的理解，但是在經歷了2012的後半年，2023年的整年，2023年的上半年，我一直在等待openuom++的更新公升級，這期間我也一直在關注硬體和網路技術的進展，openuom++落後了，誰也沒有提到過這一點，等到了2023年的農曆年前後，我覺得我該做點什麼了。就這樣，出現了版本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的觀點，我很認同。如果你感興趣，你一定能找到或者寫出想要的**，或者說，你也許能幫到我。
浙江溫州皮鞋溼，下雨進水不會胖。
Python多處理簡介
多處理程式包使用類似於執行緒模組的api支援生成過程。它還提供本地和遠端併發。本教程將討論python中的多重處理，以及如何使用多重處理在程序之間進行通訊並執行程序之間的同步以及日誌記錄。如下所示，通過建立乙個process物件然後呼叫其start 方法來進行多處理。from multiproces...
異構多處理系統
早期嵌入式處理系統通常由乙個微控制器和一系列外設構成。這些系統通常用來完成獲取少量資料 處理資料 做出決策 基於決策結果輸出資訊等工作。在某些情況下會實現簡單的人機互動介面如讀取鍵盤並顯示結果。處理需求 同時產生需求，以現在的標準來看似乎微不足道。現代嵌入式系統通常需要處理和分析十億位元組級的海量資...
SpringMVC對於靜態資源多處理
今天在學習springmvc的時候想用html而不用jsp實現頁面，但是像平常一樣配置好controller後一直是404找不到html頁面，同時internalresourceviewresolver預設是加 根目錄 字首和 jsp 字尾，所以最後變成了 demo name.html.jsp，go...