简介AODV路由协议是无线自组织网络中典型的按需距离矢量协议这份源码包可配合OPNET仿真平台使用面向高校网络专业学生、科研人员及路由协议开发者解决AODV协议实现与仿真验证问题。压缩包包含1个C语言源文件文件大小约33KB代码聚焦协议核心逻辑便于阅读、编译与二次开发。当前已有139人学习下载在同类源码资源中具有一定参考价值。源码包已涵盖AODV路由请求RREQ、路由回复RREP、路由错误RERR处理以及序列号防环、TTL广播限制等关键实现可直接导入OPNET工程进行网络场景仿真。通过配置节点拓扑与业务流读者能够观察路由发现、维护与撤销的完整过程并统计丢包率、端到端延迟、吞吐量等性能指标从而加深对协议工作机制的理解也为对比其他路由协议或改进算法提供实验依托。1. 拿到 aodv_rte.pr.zip 之后AODV 仿真的第一步不是解压而是弄清这个“路由进程”在你工程里是干什么的AODV 是 MANET 仿真里被问最多、也最容易翻车的按需路由协议而 aodv_rte.pr.zip 这个压缩包恰恰是很多人在 OPNET 里找不到或改不动的那块拼图。我第一次看到这个包时也踩过坑解压出一堆 .pr、.h、.c 文件以为把整个 AODV 模型装上就能跑结果项目里连路由协议下拉菜单都找不到。后来才明白这里面的 aodv_rte.pr 是路由表维护进程它要配合主进程、IP 模块和节点模型才能工作。下面这条路会带你把它读明白、装进去、跑起来并给出调参和排错的落地路径让做 Ad Hoc 路由实验的师弟师妹们少熬几个夜。2. 把 aodv_rte.pr 拆开看路由表在 OPNET 进程模型里到底长什么样2.1 一个 .pr 文件不等于一个协议进程模型与周边文件的分工OPNET 里的路由协议并不是一把梭的单个文件。观察压缩包里的文件结构你会发现除了 aodv_rte.pr通常还会有一批头文件和外部函数。我们在实际工程里一般按这个分工去理解.pr 文件保存进程模型的状态转移图定义路由表进程在收到事件后怎么跳转.h/.m 文件存放结构体定义和宏.c/.ms 文件放外部函数和状态服务的具体实现。只有把这一组文件都放到正确目录OPNET 才能把这个进程当成可实例化的颗粒挂到网络节点上。那 aodv_rte.pr 本身承担什么角色呢从命名看“rte”就是 route table。AODV 协议在 RFC 3550 里要求每个节点维护一张路由表表项要包含目的地址、下一跳、跳数、目的序列号、生命周期和活跃邻居等。OPNET 实现中这张表不是由 ip 模块统一管理而是交给一个专门的路由表进程来持有和维护。也就是说aodv_rte.pr 进程实例里通常会有若干个状态有的负责接收主协议进程发来的“路由查询”请求有的负责在路由超时后把表项标记为失效还有的在收到 RERR 时主动删除反向路由。你要做的第一步就是先打开这个文件找到这些状态。这里给你一个不管什么版本都适用的探查脚本用 Python 扫描 .pr 文件里的关键字。它不会替换你的 OPNET 操作但能让你在不解包的情况下快速判断手里这个模型是完整版还是被裁剪过# 快速探查 aodv_rte.pr 的结构状态名、转移条件和统计句柄 import re from pathlib import Path path Path(aodv_rte.pr) text path.read_text(encodingutf-8-sig, errorsignore) states re.findall(r^\s*state\s(\w), text, re.M) print(状态列表, states[:30]) for keyword in [Condition, Force Transition, op_stat_reg, rt_table]: print(f关键字 {keyword:20} 命中 {text.count(keyword):4d} 次)这个脚本的逻辑很简单OPNET 的进程模型虽然在 Process Editor 里以图形显示但落盘为文本后状态定义和转移函数都有相对固定的关键字。你会发现路由表进程里最常出现的状态名称是 init、idle、processing以及和 RERR、RREP 相关的动作状态。看到这些就能确认这个 .pr 是真正参与路由维护的实体而不是单纯的接口壳。进程模型为什么要这样切因为 AODV 主进程每收到一个控制包都要立刻判断是 RREQ、RREP 还是 RERR如果把路由表查询和组表操作也塞进主进程状态机复杂度会直线上升。把它们拆开主进程只负责协议语义表项增删改查全交给路由表进程状态转移图就会清晰很多。反过来这也解释了为什么你改了 aodv_rte.pr 却不生效没有把这个进程模型作为 subprocess 挂到 aodv 主进程上OPNET 根本不会执行你的代码。所以拆开文件后下一步就是用 Model Rediscovery 检查模型依赖关系确认 aodv_rte.pr 被正确引用。2.2 路由表项的数据结构从 SV 到内存布局继续往内看路由表的数据结构通常定义在头文件里而不是直接写在 .pr 中。一个实用的做法是打开同包内的 aodv_rte.h找 typedef struct rt_entry。我一般会先关注下面几个字段dest_addr、next_hop、hop_count、dest_seqno、lifetime、flags。这几个字段对应着 RFC 3550 路由表的主要条目。如果你改的是“路由失效判断”会碰 lifetime 和 flags如果你改的是“多路径支持”就要在 next_hop 外面再套一层链表。为了让你快速对应我用表格把“协议概念—OPNET 常见实现字段—调参入口”列一下。这里字段名用的是我在多个模型里见到的通用命名不同 fork 会发生前缀变化比如 aodv_rt_ 前缀协议概念常见字段作用在哪里调目的地址dest_addr路由表项的主键进程状态代码一般不直接改下一跳next_hop数据包转发出口路由查询返回后写入跳数hop_count路由通告/比较rreq/rrep 处理状态目的序列号dest_seqno防环的核心rreq/rrep 更新逻辑生命周期lifetime超时置失效决定失效快慢Active Route Timeout 参数路由标志flags是否有效/是否正在修复布尔判断常踩坑这张表建议打印一份贴在屏幕旁边。因为很多坑在“现象上是协议不收敛根因却是路由表项释放时机不对”定位问题时会反复回到这张表。操作上拿到一个新的 AODV 包后我给出的顺序是先跑上面的 Python 脚本确认进程状态完整再用文本编辑器打开 .pr跳转到“find_route”与“update_route”两个动作状态。你会发现路由表进程主要是在这两个状态里完成业务。之后打开同目录下的头文件尝试把上面的表格映射到真实结构。不要一开始就改代码先在纸上把这个映射写出来能让你后面省下大量反复重编译时间。如果你想直接看运行时的表项内容最好用的方法是 ODB 调试器。在 OPNET 菜单里启动 Debug 模式后在 aodv_rte.pr 中插入下面这段打印代码每产生一条有效路由就输出一行摘要// 在 update_route 成功写入新表项后打印关键字段 if (rtp ! OPC_NIL) { printf(RTT [%s] - nh[%s] seq[%d] hop[%d] life[%.2f]\n, rtp-dest_addr, rtp-next_hop, rtp-dest_seqno, rtp-hop_count, rtp-lifetime); }这里 rtp 是路由表项指针O 表示目的地址nh 表示下一跳seq 是目的序列号hop 是跳数life 是剩余生命周期。通过打印这些值你可以直观看到路由建立和失效的时机比事后看统计曲线要准确得多。很多模型里这些字段名可能是 dest_addr、next_hop、dest_seqno但含义不变打印变量的命名要跟着你实际编译的头文件走否则编译期就会报 undefined identifier。最后补充一点aodv_rte.pr 的真实结构在 OPNET 14.5 和 18.0 里都高度相似但不同分支的代码风格差异极大。有的把路由表做成纯链表有的用外部列表容器。千万别把另一套模型的字段名直接复制进来否则编译能过、运行给你报 NULL pointer access。我们实验室吃过这个亏后来约定任何模型改动都从最新原始包出发不再做跨包搬运。3. 在 OPNET 里把 AODV 工程跑通从压缩包到一条可复现的仿真链路3.1 安装模型目录、环境变量与“看不见的缓存”这里要覆盖两个常见问题放哪个目录、如何让 OPNET 识别。OPNET 查找模型库的顺序是先看用户模型目录再看系统模型目录。如果直接把 .pr 复制进默认安装目录的 std/models/std系统升级或重装后你的改动就没了而且 Windows 下不同版本对目录权限敏感。我一般的做法是建一个单独的个人模型目录比如 D:\models 或 ~/opnet/models然后把整个 aodv 文件夹放进去。接下来要修改环境变量。在 Linux 下是 export OPNET_MODEL_DIRS在 Windows 下是在“我的电脑 属性 高级系统设置 环境变量”里增加 OPNET_MODEL_DIRS。模型搜索是多路径的多个目录用分号或冒号分隔。我附一段 bash 脚本把整个流程固定下来方便新机器上复现#!/usr/bin/env bash # 安装 AODV 模型到个人目录并启动 OPNET set -e MODEL_SRC/path/to/aodv_rte.pr.zip_expanded MODEL_DEST$HOME/opnet_models/aodv mkdir -p $MODEL_DEST # 复制进程模型、头文件、外部代码 cp -av $MODEL_SRC/. $MODEL_DEST/ # 将个人目录加入模型搜索路径 if ! echo $OPNET_MODEL_DIRS | grep -q $MODEL_DEST; then export OPNET_MODEL_DIRS$MODEL_DEST:$OPNET_MODEL_DIRS fi echo AODV 模型目录: $MODEL_DEST echo OPNET_MODEL_DIRS: $OPNET_MODEL_DIRS # 如果是 linux 版可直接启动 opnet /dev/null 21 这里我见过不少人把复制命令写成 cp *.pr结果漏掉 .h 和 .m编译时满屏 undefined identifier。我用.把整个目录内容复制过去头文件、外部代码和进程模型全部一起进目录避免遗漏。设置环境变量后最好在 OPNET 启动时看一眼菜单里是不是有 Add Model Directory有的版本需要在 Tools Options Model Directories 里手动添加一次。你可能会问我明明放对了为什么 OPNET 还是认不出 aodv_rte.pr答案往往在缓存。OPNET 会在模型目录下生成模型库索引旧版本直接扫描目录新版本会缓存文件类型。在 Windows 下遇到这种“玄学”问题我第一个动作是删除模型目录下所有 .cache、.osp、.pml 文件再重启 OPNET。千万别小看这个它至少帮我省出过两个下午。安装完成后不要急着开 GUI先在命令行验证一下文件是否完整。对于 Linux 下的 OPNET我会用一条命令检查进程模型头部# 检查复制后的 .pr 文件是否完整 head -n 5 $MODEL_DEST/aodv_rte.pr输出里如果包含 OPNET PROCESS MODEL 这种标识说明文件没有在解压或复制过程中损坏。如果看到一堆乱码或截断的内容就要回到压缩包重新解压并用 7-Zip 而不是系统自带解压工具避免路径过长导致文件被截断。3.2 构造网络拓扑并绑定 AODV 进程最小 MANET 场景模型装好后接下来要在场景里把 AODV 用起来。OPNET 的无线仿真中我们一般会从标准节点模型库拖几个 wlan_station_adv 节点。这个节点模型内置了无线局域网 MAC 层和 IP 层唯一的缺口是它默认的路由协议不是 AODV而是 None。所以你要做两件事一是给 IP 模块装一个 MANET 路由管理接口二是在路由管理接口里选 AODV。在旧版 OPNET 中操作路径是双击节点图标进入 Node Editor找到 ip 进程模块把它的 Routing Protocol 属性从 None 改成 AODV。但在新版里则要增加一个 ip_rtmgr 进程模块并把该模块的 MANET Routing Protocol 设置为 AODV。我强烈建议你从一个小场景开始验证两个静态节点一个发 UDP一个接收先不移动。因为这两点之间直连路由AODV 的路由发现流程在十几毫秒内就应该完成。如果这个都跑不通问题不在移动模式而在于模型没加载或节点模型不对。下面是一个等价于 GUI 操作过程的 YAML 配置清单如果你打算用 OPNET 的批量仿真脚本或给组里成员备课用可以直接按这个模板填# 最小 AODV 场景2 个 wlan_station_adv UDP 业务流 scenario: nodes: - name: src model: wlan_station_adv x: 100 y: 100 - name: dst model: wlan_station_adv x: 300 y: 100 ip_layer: routing_protocol: AODV rtmgr_parameters: active_route_timeout_sec: 3.0 hello_interval_sec: 1.0 traffic: type: UDP packet_interval_sec: 0.02 packet_size_bytes: 512这里面的节点坐标、包参数都要在仿真运行前确认。启动仿真后观察第一秒左右应出现 AODV 路由请求交互。OPNET 的仿真统计里如果没有任何 AODV 相关事件多半是绑定失败。判断标准很简单在 IP 层打开路由协议统计或者直接抓包看有没有 RREQ 广播。如果不想每次都用鼠标点来点去也可以把场景存成 .sca 文件后用命令行批跑。这在实验矩阵里非常有用。下面是一个跑多随机种子的脚本片段# 基于已保存的 AODV.sca 跑 5 个随机种子的批处理 for seed in 1 2 3 4 5; do echo run seed$seed op_runsim -scenario AODV.sca -seed $seed -force_rand logs/seed_$seed.log done这个命令里 -seed 指定随机数种子-force_rand 确保节点初始位置和业务起点随种子变化。注意批处理前要把统计量配置好否则跑完发现结果文件里没有需要的路由表和延迟数据就得重新跑一遍血亏。为了验证绑定成功你可以先开一次 Debug 级别日志在 aodv 主进程里加一个 op_prg_odb_print_major 调用或者用 OPNET 自带的 ODB 断点。下一章讲的参数调整都建立在“这个最小场景能通”的前提下所以浪费一点时间在这里是值得的。4. AODV 仿真必调的 5 个参数从路由表维护到链路断裂应对4.1 协议参数组Hello Interval、Active Route Timeout 与 Net DiameterAODV 的行为由一组定时器和阈值控制。在 OPNET 的 AODV 模型里你会在节点属性上看到成串的参数名比如 Hello Interval、Active Route Timeout、Route Reply Aggregation、Net Diameter、RREQ Retries、RREQ Rate Limit 等。这些参数不是摆设决定你跑的仿真像无线自组网还是拿着大喇叭广播。Hello Interval 是用来做链路本地互通的。每个节点周期广播 HELLO 消息让邻居记录活跃度。如果 Hello Interval 太短控制开销压弯了吞吐太长链路断了要等很久才被感知。常见默认值在 1 秒左右高动态场景下我会调到 0.5 秒但前提是数据包间隔小于 1 秒否则 HELLO 会抢占信令资源。Active Route Timeout 是路由表项的生命周期。只要在这个超时时间内收到数据包路由保持活跃一旦超时表项被标记为无效。这条直接影响路由切换速度。OPNET 里单位通常为秒。如果你做的是消防员室内移动这种短连接、高频断链场景我会降到 1.5 秒否则失效路由会一直占着位置数据包反复打到黑洞里。Net Diameter 对应协议中最大跳数。它主要影响 RREQ 的 TTL 初始值。在 100 个节点的大规模仿真里如果网络直径估算过大RREQ 扩得极快产生大量广播风暴如果过小远端节点收不到请求。所以它不是随便填的要结合场景面积和传输距离反推最大跳数。我一般先用一个粗略值跑两遍再根据路由表统计调整。下面是几个核心参数的经验值实际使用时建议从这些范围出发不要直接套论文里的默认值因为节点密度和数据速率不同最优区间会整体平移参数常见默认推荐调整范围主要影响Hello Interval1.0 s0.5 ~ 2.0 s链路感知速度与控制开销Active Route Timeout3.0 s1.5 ~ 6.0 s路由失效速度Net Diameter20 跳5 ~ 30 跳RREQ 泛洪范围RREQ Retries2 次0 ~ 5 次路由发现成功率Node Traversal Time40 ms0.01 ~ 0.1 sRREP 延迟补偿这些参数之间是耦合的。比如你把 Active Route Timeout 调大路由表项生命周期长但链路断了之后仍然长时间保留坏路由调小则失效感知快但 RERR 风暴也会变多。所以做参数对比时最好一次只调一个参数并且把 hello interval 和 active route timeout 放在一起观察因为两者的比值直接影响邻居活性判断。4.2 场景参数组节点密度、移动速度、仿真时长与随机种子协议参数之外影响 AODV 最大的是场景参数。节点数量不是越多越好AODV 是按需协议节点多但业务少时控制开销很低节点多且业务并发时路由发现广播相互叠加会出现明显的广播风暴。我自己的经验是在 OPNET 里做对比实验时保持业务负载不变把节点数从 20、50、100 拉开能清楚看到 AODV 在 50 到 80 之间性能开始掉头。这个拐点可以作为论文里的“网络规模敏感性”分析。移动速度的设定更有意思。AODV 在低速步行场景下表现尚可但速度超过 20 m/s 时路由维护跟不上链路断裂丢包率上升曲线会非常陡。很多仿真里喜欢用 Random Waypoint这个模型本身有“密度波”问题会让稳定路由需求下降。所以设计实验时我通常把节点最小速度设为非零值或者在脚本里让每个节点独立设置速度上限避免所有节点同时停在场中央。仿真时长和随机种子经常被忽视。做 AODV 评估至少要跑 800 秒以上因为路由发现和收敛的冷启动效应会持续很长短于 300 秒的仿真实质上在统计“协议还没启动”的丢包。随机种子至少做 5 组不然任意一次移动轨迹差异都可能把结果反转。下面是实验矩阵示例我一般会在批量仿真前生成这样一个 YAML 文件再映射到不同场景# 实验矩阵节点数 × 速度 × 随机种子 experiments: - nodes: 20 speed_mps: [1, 5, 10, 20] seeds: [101, 102, 103, 104, 105] - nodes: 50 speed_mps: [1, 5, 10, 20] seeds: [101, 102, 103, 104, 105] - nodes: 100 speed_mps: [1, 5, 10, 20] seeds: [101, 102, 103, 104, 105]这个矩阵里每个组合至少跑一次也就是 3×4×5 60 次仿真。这么多轮次手动操作不现实所以我会把每个节点的移动脚本用 OPNET 的 Trajectory 文件生成再配上上一节提到的命令行批处理。这样跑一个晚上第二天就能拿到完整数据。场景参数中还要注意无线传输模型。OPNET 默认的 WLAN 模型如果不修改接收功率阈值两个节点隔着 200 米可能完全收不到包但你以为是路由协议出了问题其实是物理层已经断了。所以在跑 AODV 前先确认节点间距小于传输距离的 0.7 倍确保路由层有机会工作然后再讨论协议好坏。最后提醒一个容易翻车的地方OPNET 的随机种子影响的不只节点位置还会影响业务生成和包冲突。你不能在同一场景下只改 seed 就认为移动轨迹完全变了必须同时在 scenario 中重新生成节点初始坐标。否则你比较的是同一拓扑下不同业务冲突而不是不同移动场景下的协议表现。5. AODV 在 OPNET 里的 5 个高频翻车现场与排查方法5.1 模型加载成功却找不到 AODV 协议选项现象项目里已经新建了无线节点双击 IP 模块看到路由协议下拉框里只有 None、OSPF、RIP 这些没有 AODV。原因模型目录没有加载 aodv_rte.pr 依赖的主进程或者 OPNET 只扫描了编译后的 .po 文件而你复制的是源码。很多第三方 AODV 包在压缩包里带了两个进程一个是 aodv_rte.pr另一个是 aodv_rte_4.pr 之类的主进程如果只复制了其中之一OPNET 在构建节点模块时找不到可用进程列表。解决先检查压缩包内是否有两个 .pr 文件。安装时用上文的 cp -av 保证全部文件进目录然后在 OPNET 的 Model Directories 设置里强制重新索引目录。Windows 下删掉缓存文件Linux 下用 op_mkdev 或直接重启 GUI。如果还不行把目录的完整路径贴出来看看是不是包含中文或空格路径里的空格会让 OPNET 的模型解析器直接跳过该目录。5.2 仿真时间“卡死”在 RREQ 重传循环现象事件日志里不断出现 RREQ 重传隔几秒就重试一次始终收不到 RREP。最夸张的是一次实验跑 5 分钟事件列表全被路由发现刷满业务包一个没发出去。原因目的节点不是有效 IP 层节点或者两个无线节点之间的距离超过传输范围且中间没有中继。还有一种可能是反向路由被 aodv_rte.pr 提前清掉RREP 回来时找不到路由然后源节点还以为路由不存在继续重传 RREQ。解决先用事件追踪功能看 RREQ 是否到达目的节点的 MAC 层。如果没到就是距离或中继问题增加一个中继节点或缩短距离。如果到了但 RREP 发不回源节点就在 aodv_rte.pr 的 rrep 处理状态里打断点观察反向路由表项在收到 RREQ 后是否存在。我遇到过最鬼的情况是某版本模型把 RREP 方向的下一跳地址写成了广播地址导致包到了目的节点却被 MAC 层丢弃。5.3 自定义 aodv_rte.pr 之后“所有包都丢到黑洞”现象修改了路由表失效逻辑后数据面一通控制面全丢或者反过来路由表建立后数据包在 IP 层排队直到超时没有实际发往物理层。原因改动了状态转移的强制条件比如把 TTL 递减放在错误的状态出口或者路由表项被释放后还有包引用该指针。OPNET 进程模型里强制转移Force Transition优先级最高新手容易在外部转移和强制转移之间漏一个“包到出口”的宏调用导致事件被吞掉。解决用 ODB 对每个路由表项的引用计数组件做断点确保在状态下发之前不释放。具体做法是把修改后的 .pr 和原始 .pr 做 diff只看路由表项释放相关的那几行。我常用的二分法是先跑通最小场景然后在释放表项的代码前后各打印一条日志看日志顺序是否符合预期。如果释放函数从未被调用再检查 active_rt_timeout 的超时事件有没有被正确调度。5.4 统计结果全是 0AODV 明明在工作却不记录现象仿真跑完后End to End Delay 和 Packet Delivery Ratio 统计栏一片空白或者在结果浏览器里显示全部为 0。原因aodv_rte.pr 进程没有调用 op_stat_reg 注册统计句柄或者注册名与结果分析器里选择的名字不一致。很多精简版模型为了省时间删掉了统计注册代码只保留路由发现逻辑所以协议在跑但你无数据可看。解决打开 .pr 文件搜索 op_stat_reg确认路由表进程是否登记了路由长度、路由发现次数等全局统计。如果没有就手动加一段注册代码或者在节点模块的“全局统计”里选择 IP 层和 UDP 层的收发统计来间接验证。更省事的办法是直接在源端和目的端各加一个 sink 节点用 Application 业务流自带的响应统计代替协议内部统计。5.5 从 zip 解压后文件损坏或命名错乱导致编译失败现象Windows 下解压后文件名为 aodv_rte.pr 但打开全是乱码或者出现 aodv_rte.pr_、.pr1这种多余后缀。在 OPNET 的 Process Editor 里打开后报“file not found”。原因压缩包内目录层级过深路径总长超过 Windows 260 字符限制系统解压器自动截断文件名或者是压缩时用非 UTF-8 编码中文路径导致解压失败。解决用 7-Zip 解压到短路径比如 D:\AODV而不是 C:\Users\你的名字\Downloads...。解压后先用命令行 head 或 just 打开 .pr 文件确认开头包含 OPNET PROCESS MODEL 字符串。如果文件内容看起来是二进制而不是文本模型那说明这个 .pr 是旧版模型编译后的可执行格式需要放到对应版本模型库中不能直接当源码改。这个坑很隐蔽很多从 CSDN 下载的压缩包干脆就是编译好的 .po 文件改不了源码只能当黑盒用。6. 验证与进阶用路由表日志和统计曲线证明 AODV 真的“干活了”一个很多人忽略的验证技巧是不要只盯最终曲线要盯协议内部的日志。我会在 aodv_rte.pr 的 RREP 处理状态里留一行打印记录目的 IP、下一跳和序列号然后在运行完仿真后把这些日志从 OPNET 的 DES Log 中导出来和拓扑中实际路径做对比。这种方法在 10 个节点以内的小场景里特别快能直接看出路由选路是否符合预期。另一种更量化的验证方式是把 OPNET 统计导出成 CSV用 Python 做快速计算。下面这段代码是我常用的脚本骨架可以算出 90 分位延迟和中位投递率比看平均值更能暴露 AODV 的路由抖动import pandas as pd # 读取 OPNET 导出的结果 stats pd.read_csv(aodv_scenario_results.csv) # 过滤冷启动阶段前 10 秒 steady stats[stats[time_sec] 10] # 一呃逆指标90 分位延迟关注尾部风险 latency_90 steady[end_to_end_delay_sec].quantile(0.9) # 投递率取中位数避免单次波动影响 pdr_med steady[packet_delivery_ratio].median() print(f90th latency {latency_90*1000:.1f} ms) print(fmedian PDR {pdr_med:.2%})这段脚本里end_to_end_delay_sec 和 packet_delivery_ratio 是我在统计配置里自定义的列名你用的时候改成自己场景里的实际列名。计算时把前 10 秒切掉是因为 AODV 在启动后第一轮路由发现过程产生的 RREQ 风暴会严重拉低延迟和投递率不切掉会得到假结论。进阶一点你可以把不同参数的实验输出汇总成一张对比表然后判断某组参数是否值得投入。我见过很多人在论文里只放三组曲线没有做随机种子平均评审一问就翻车。所以我会把所有种子跑完然后在 Python 里按参数组分组计算均值和 95% 置信区间再把结果画出来。这个流程虽然多花一点时间但能让仿真结论站得住脚。最后讲讲我自己的教训刚接触 AODV 那年修改 aodv_rte.pr 总喜欢一次改好几个地方结果每次跑完都不收敛根本分不清是哪个字段写错。后来养成习惯每次只改一个字段、打一行日志、跑通一个最小场景并保存 benchmark才把节奏找回来。如果你手头的 aodv_rte.pr.zip 也是这种来历不明的东西记住先跑通最小场景再改代码希望帮到你。本文还有配套的精品资源点击获取
