NS2下AOMDV的初步实现及过程分析

kant_3600

v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}

  Normal
  0
  
  7.8 磅
  0
  2
  
  false
  false
  false
  
   
   
   
   
   
   
   
   
   
   
   
   
  
  MicrosoftInternetExplorer4



/* Style Definitions */
table.MsoNormalTable
        {mso-style-name:普通表格;
        mso-tstyle-rowband-size:0;
        mso-tstyle-colband-size:0;
        mso-style-noshow:yes;
        mso-style-parent:"";
        mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
        mso-para-margin:0cm;
        mso-para-margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:10.0pt;
        font-family:"Times New Roman";
        mso-fareast-font-family:"Times New Roman";
        mso-ansi-language:#0400;
        mso-fareast-language:#0400;
        mso-bidi-language:#0400;}
NS2下AOMDV的初步实现及过程分析
       读本文的一些要求：
       对NS2有一定的了解（最好知道怎么用吧？不然会比较浪费你的时间！）
       对AOMDV有一定的了解，包括它的原理运作方式（这里可以参看论文：Ad hoc on-demand multipath distance vector routing. Mahesh K. Marina）和代码之类的（或者对AODV有一定的了解）。这两个要求只是希望能节省点大家的时间。
       本次实验是为了验证AOMDV的多路径是否正常工作。本次测试是在6个节点的场景下进行的。如下图：


  
  
  
  
  
  
  
  
  
  
  
  




file:///C:/DOCUME%7E1/YJC/LOCALS%7E1/Temp/msohtml1/01/clip_image002.gif


AOMDV简单6节点拓扑图(见相册)
       从测试的过程来看，是符合AOMDV的算法要求的。即：源节点和中间节点会维护多条转发路径（forward-paths）,目的节点和中间节点会维护多条反向路径（reverse-paths），这两个过程可以跟踪目的节点的AOMDV::recvRequest和源节点AOMDV::recvReply过程来查看，你会发现在aomdv_rt_entry::path_insert中为源节点和目的节点的路径列表中增加了一条路径，并且让两者的rt_num_paths_都增加到了2。并且在后面的跟踪中还会发现，这几条路径的下一跳和最后一跳节点是不一样的。这足以充分说明了多条路径在AOMDV中建立成功了（本文选用的AOMDV_NODE_DISJOINT_PATHS方式）。
       为了验证拥有多条路径的源节点在链路断路的时候会否重新发送RREQ，这里我让节点0的下一跳节点1断开（本来设置的1和3到0的空间距离是相同的，不知道为什么会选1，而AODV却是选择的3，本文未细究）。这样节点0就会进入aomdv_rt_failed_callbackàaomdv::rt_ll_failed过程，这个过程是比较关键的，因为最开始直接运行代码的时候，进入该过程，过程没有继续向下发展而是直接进入了宏AOMDV_LINK_LAYER_DETECTION然后包就被直接丢弃了，并没有进行后续的在节点0中选择另条路径的工作。对于AOMDV_LINK_LAYER_DECTECTION，在原代码中明明已经被禁用了但是仍然还是执行了，我估计是在某个其他的头文件里被定义了，这里也不做深究。所以这个需要修改，不然结果会和AODV一样。我用的方法比较直接，屏蔽掉这个功能，后面很多时候我也是做了一些屏蔽处理（勿怪，因为我发现在我所设定的应用场景中不需要或者对我目前的研究没有什么不利的影响）。仍然是在会到AOMDV::rt_ll_failed中，下面的AOMDV::handle_link_failure的过程也比较重要，这个过程会帮我们删除路径列表中包含断链的下一跳节点的路径，如果不执行类似的过程，我们在path_find的时候仍然会找到该已经中断的路径，从而造成一定的循环，最终仍然是需要发送RREQ。但是在执行AOMDV::handle_link_failure这个过程时结果仍然不太理想，因为在handle_link_failure过程中有个aomdv_rt_entry::path_delete的过程，而且在执行当执行完rt_ll_failed后会出现nb_delete的过程也会调用到handle_link_failure，同时删除这个节点中的维护的path。因为nb_delete是删除了邻居节点的路径（我是这样理解的，理论上讲只因该删除包含断链节点的路径，但是AOMDV却把将目的节点3也看出了断链的下一跳节点）这样就会造成其他节点特别是节点4中到目的节点的路径被删除，结果是出现segment default（这是个比较棘手的错误，但是如果有足够的耐心的话还是可以很轻易查找到错误之处的，这里是因为找到的路径为空，然后又将空路径的下一跳赋给了ch->next_hop()这样就出来了那个错误）。于是将handle_link_fail这个过程也给屏蔽了，因为我只是为了验证AOMDV的多路径特性（具体如何操作见代码）。还有个小地方需要注意，在rt_ll_failed过程中，删除了无用路径后会path_find到另外一条路径，但是该路径的rt_flags肯定是RTF_DOWN的，因为这条路径之前不是可用的。所以在选择的时候，我把rt_flags==RTF_UP给删除了，并且在后面forward之前，给将rt_flags赋值RTF_UP，这样进一步到达了forward之后，经过一列的赋值操作，就可以看到此时forward的对象ch->next_hop()已经变成3了。
       NS2中AOMDV代码的过程固然是成立的，但是对于本文的这个六个节点的简单拓扑来说，AOMDV这样操作的意义其实还没有直接发送RREQ或者本地修复来的快。具体的延时和吞吐量的分析还是不要拿出来了，在这个拓扑中的确是比AODV要略差的。但这些指标目前不是我研究的范围，希望有感兴趣的读者来进行进一步的研究，并给大家指示下AOMDV的具体意义何在（在论文中AOMDV是用于移动ad-hoc网络这种移动性很强的网络的，而且节点密度也不低），如果需要的话。
       其实这里只是不希望在ns2中增加AOMDV的代码原创者（NS2.34中已经集成了AOMDV的代码）来找我的麻烦将他的代码乱改一气。不过估计那个老外也看不明白中文。本文只是将本人对AOMDV的NS2代码的理解转发成文字，给大家学习起到借鉴作用，行文间无可避免有些考虑不周的地方，望大家相互学习讨论，共同进步。
      

       
        文件:AOMDV.pdf
        大小:398KB
        下载:
下载
       

               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/97671/showart_2110682.html