OpenUOM++多处理之-最新架构

好久没有更新这个系列了，因为我之前也说过，前段时间实在太忙了，而且早在一个月前就预示着本月将更加忙！事实也确实如此！终于在国庆前夕完成了既定的计划，心里也终于可以长出一口气了。最近在忙什么呢？其实就是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的观点，我很认同。如果你感兴趣，你一定能找到或者写出想要的代码，或者说，你也许能帮到我。

---

浙江温州皮鞋湿，下雨进水不会胖。