简介：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(encoding='utf-8-sig', errors='ignore') 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 2>&1 &这里我见过不少人把复制命令写成 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 Diameter
AODV 的行为由一组定时器和阈值控制。在 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 Interval | 1.0 s | 0.5 ~ 2.0 s | 链路感知速度与控制开销 |
| Active Route Timeout | 3.0 s | 1.5 ~ 6.0 s | 路由失效速度 |
| Net Diameter | 20 跳 | 5 ~ 30 跳 | RREQ 泛洪范围 |
| RREQ Retries | 2 次 | 0 ~ 5 次 | 路由发现成功率 |
| Node Traversal Time | 40 ms | 0.01 ~ 0.1 s | RREP 延迟补偿 |
这些参数之间是耦合的。比如你把 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 统计结果全是 0：AODV 明明在工作却不记录
现象：仿真跑完后，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_、.pr（1）这种多余后缀。在 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(f"90th latency = {latency_90*1000:.1f} ms") print(f"median 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 也是这种来历不明的东西，记住先跑通最小场景再改代码，希望帮到你。
本文还有配套的精品资源，点击获取
