OpenUOM移动性改造-靠新的session iD而不是IP/Port识别客户端

1.设备会经常由于小区或模式切换而更改IP地址。

2.移动设备存在多张3G/4G/2.75G网卡时，希望这些网卡同时收发数据。

3.经常性的失联

4.RRC相关造成的额外延时

有时候，即便你处在信号很好的地方，也会发现打开一个网页非常慢，然后迅速就会变快，这其实是移动网络的本质，为了节省电量损耗，设备并不是一直和网络保持连接的，而是运行一种和Linux的NOHZ算法一样的机制，在设备长时间没有数据收发的时候，关闭连接，和Linux的NOHZ不同的是，NOHZ状态的脱离时间是明确的，它由下一个timer到期的时间以及时钟之外的任何中断的最小值决定，但是RRC机制却不同，数据什么时候会发送完全取决于神一样的用户，因此当有数据要发送的时候，必须重新接入移动网，协商参数等等，这无疑会消耗时间。这个抖动不是用户应用能解决的，因为这取决于设备厂商的实现以及移动网络的规范，这是一个纯粹的网络问题，因此本文不会涉及过多这方面的内容。

会话层真的太重要了

OpenUOM的故事

我希望OpenUOM的处理层完全和网络状态脱离，即使客户端的IP地址变了，也能用新的IP地址继续和服务端通信，即使信号全无，一旦有了信号，通信继续进行，也就是说，网络状态不会打扰到OpenUOM进程的处理。为了一步步地满足这个需求，我们看一下OpenUOM目前的行为，两端连通以后，我试着改变客户端的IP地址，结果服务端报错：

解决问题的步骤

写这篇文章并不是为了表达OpenUOM这个程序如何被用在移动设备上，这个可以写上一本书，本文的主要目的是想展示一种解决问题的方式，我在有了上面的思路后是如何验证其确实可行的呢？我并没有一头扎进那沸腾的代码，去实现最终的方案，比如直接就去修改OpenUOM的协议，而是先将代码写死，瞬间得到一个行或者不行的结论。这个过程要修改最少的代码！为了找到修改何处，还得从上面的报错入手。其在ssl.c的tls_pre_decrypt_lite函数报错，该函数没有任何关于multi_instance的信息，因此我知道在这个tls_pre_decrypt_lite函数调用之前，程序已经进入异常流了，因此就找tls_pre_decrypt_lite的调用代码，在mudp.c中的multi_get_create_instance_udp找到了：

struct multi_instance *
multi_get_create_instance_udp (struct multi_context *m)
{
    ...
    if (mroute_extract_openuom_sockaddr (&real, &m->top.c2.from.dest, true)) {
        struct hash_element *he;
        const uint32_t hv = hash_value (hash, &real);
        struct hash_bucket *bucket = hash_bucket (hash, hv);

        hash_bucket_lock (bucket);
        he = hash_lookup_fast (hash, bucket, &real, hv);

        if (he) {
            mi = (struct multi_instance *) he->value;
        } else {
            // 找不到multi_instance的异常流处理
            if (!m->top.c2.tls_auth_standalone
                 || tls_pre_decrypt_lite (m->top.c2.tls_auth_standalone, &m->top.c2.from, &m->top.c2.buf)) {
                // 异常流处理
            }
        }
...
}

关键是multi_instance没有找到，为什么呢？我发现mroute_extract_openuom_sockaddr的传入参数real，正是根据接收到的数据包的来源IP和端口初始化的，接下来查询multi_instance哈希表的时候，这个real就是key的值，在客户端的IP地址改变了之后，当然找不到任何value了，就算找到也是冲突链的value，最终返回的为NULL！接下来是关键点，既然是查询哈希表没有查到，并且是由于数据包的源IP/Port改变了没有找到，那么就忽略掉这个查询key，即想办法让这个查询百分百可以找到结果。这个思想是快速解决问题的关键，正是由于找不到key对应的value才失败，如果key能找到value的话要是能成功，问题就转化为了如何让key找到value而这我们已经有办法了，即从buffer里面取key，实际上这是另一个问题，这难道不是一次深刻的执果索因之旅吗？我在高中的物理竞赛中用此法获得了，唉，不提当年勇！这个思想很简单，但用的人不多，很多人都是一开始就修改OpenUOM协议，然后到最后一起调试，对于设计方案通过的研发任务，这是常规做法，但对于预研或极限开发来讲，这万万要不得！你根本就不知道自己的想法在OpenUOM既有框架内是否行得通，怎能一开始就大段改代码呢？R&D没有写成RD是因为它们实际上不是一个部门，起码员工解决问题的思路是不同的，R部门侧重因果推导，
执果索因，可行性验证，测试，D部门侧重设计，代码质量，进度控制，项目管理以及各种模型(迭代瀑布...)。

m->hash = hash_init (t->options.real_hash_size,
               fake_addr_hash_function,
               fake_addr_compare_function);

其中：

 

uint32_t fake_addr_hash_function(const void *key, uint32_t iv)
{
    return 0x10101010;
}
bool fake_addr_compare_function(const void *key1, const void *key2)
{
    return true;
}

就改这些即可！服务端已经可以将客户端对应到唯一的那个multi_instance了，并且成功解析封装后的IP报文，可是发现服务端往客户端返回的时候没有通过，我通过192.168.1.199接入OpenUOM成功，然后将OpenUOM客户端的地址改为了192.168.1.197，OpenUOM客户端所在机器长ping服务端的虚拟IP地址，服务端日志打印如下：

Wed Jan  1 00:02:11 2014 us=389812 zhaoya/192.168.1.199:38310 UDPv4 WRITE [77] to 192.168.1.199:38310: P_DATA_V1 kid=0 DATA len=76

发现写入的目标地址还是192.168.1.199，为何没有切换到我新改的地址？我觉得这是一个小问题。我只要找到打印上面日志的位置就好，而这很简单，代码在forward.c的process_outgoing_link函数中，注意以下的代码：

 

ASSERT (link_socket_actual_defined (c->c2.to_link_addr));

可见，这个to_link_addr是关键，这个值是OpenUOM客户端接入的时候生成的，以后不会变化，我只要将其改为实时更新的即可，就是说，无条件使用上次数据包的from地址，这些都在context_2结构体：

 

struct context_2
{
...
  struct link_socket_actual *to_link_addr;    /* IP address of remote */
  struct link_socket_actual from;               /* address of incoming datagram */
...
}

注释很清晰！怎么改呢？可以将使用to_link_addr的地方全部使用&from，当然我不会这么做，因为这只是一个可行性证实，不是正儿八经的改代码，如此鲁莽是不对的，我的做法是添加一段临时代码：

 

void
process_outgoing_link (struct context *c)
{
  struct gc_arena gc = gc_new ();

  perf_push (PERF_PROC_OUT_LINK);
#if 1    // 吐嘈时骂过的，实际上我经常这么玩
{
        c->c2.to_link_addr = &c->c2.from;
}
#endif
...
}

至此，我认为当初的想法是可行的。事后，我试着在OpenUOM的协议中增加了一个32位的session ID，然后彻底更改了hash function，传入的key就是从BPTR(buf)中取出的这个session ID，并且我把OpenUOM客户端的数量增加到了3个，同样是一致的结果，时间定在了晚上1点35分。如果这是一个下雨的夜晚，我可能会做更多的修改，但是这是一个燥热的初夏之夜！

关于本文的引申

不能杜绝问题的发生，那就忽略掉问题，使其对自身毫无影响。多加一个层就可以隔离问题！你不能让天公不下雨，但你能带上伞或穿上雨衣雨鞋，或者将活动改在室内，再或者像我这样，尽情雨中欢呼...如果你为了不下雨而去研究大气运行原理，研究让云层散开的炮弹，那你就走偏了，虽然最终你可能会成为伟大科学家，但目前，你可能只是因为下雨影响了你的心情，而已。

       在定位问题的过程中，千万不要过早扎入代码细节，用最快的方式验证可行性和合理性。然后再细嚼慢咽，要分清主要问题和次要问题，主要问题简化其本质，次要问题模拟其现象，不应该为次要问题浪费大量时间和精力。你不可能一次搞定所有问题，学会模拟当前非本质问题造成的现象是一种技巧技能，能从简化环境中得到真实结论是一种推理技能。

关于模拟不仿真