企业官网建设流程全解析

简介：这是一份基于OPNET Modeler搭建ALOHA与AODV协议联合仿真平台的工程资源包，面向网络协议研究人员、通信专业学生及无线自组网仿真入门者。压缩包共36个文件，大小仅93KB，核心包含10个m模型源码、2个c代码文件、2个prj工程文件，以及dll、obj、seq、log、ef、gdf等编译产物、事件序列与仿真输出记录，可直接打开运行或二次修改。资源完整搭建了ALOHA收发节点（aloha_tx/aloha_rx）、网络拓扑cct_network-aloha及多个命名场景（如test_Sm_Int-first_floor、test_Sm_Int-expansion），并涉及模型定义、协议参数配置、事件调度和性能指标设置等关键环节，便于用户理解ALOHA随机访问机制（含纯ALOHA/时隙ALOHA）与AODV按需路由协议的交互过程。已有338人学习浏览，适合作为课程设计、毕业设计或论文仿真的参考资料，通过剖析这些工程文件可快速掌握OPNET建模与协议仿真的完整流程。

1. 用 OPNET Modeler 搭 ALOHA 仿真平台：一份能跑的工程，胜过三篇论文

拿到这份 opnet_aloha 工程包的第一感觉是：它不像教程，更像一个刚从仿真机上整体拷贝下来的工作目录。里面既有 aloha_tx、aloha_rx 两个进程模型的源码，也有 cct_network-aloha 网络模型、test_Sm_Int 工程文件，甚至连编译好的 dev32.i0.nt.dll 都塞在里面。对想复现 ALOHA 协议仿真的从业者来说，这个资源最大的价值在于省掉了从零建模最痛苦的两步：画状态转移图和调编译链。它适合三类人：做 MANET 课题的学生、需要在 OPNET 上快速出对比数据的工程师、以及搜 opnetaodv 相关资料时想找一个可扩展底座的协议研究者。那一串 .pr.m、.nt.m、.pb.m 后缀，就是 OPNET 模型世界的目录索引，顺着它拆下去，这份工程就没有黑匣子。

2. 拆开 opnet_aloha 工程包：用文件后缀读懂 Modeler 的三层模型

OPNET Modeler 的工程目录乍看很乱，实际上每个后缀都对应一套严格的模型体系。不先把这个映射关系理清楚，后面改任何一个文件都可能翻车。这一章把文件清单按 OPNET 的三层建模逻辑重新分组，顺便讲清楚 ALOHA 和 AODV 在这份工程里的真实关系。

2.1 OPNET Modeler 的三大模型层级：Network、Node、Process

OPNET Modeler 建模仿真遵循三层模型结构：网络模型（Network Model）、节点模型（Node Model）、进程模型（Process Model）。这三层分别对应工程里的 .nt.m、.nd.m、.pr.m 三类文件。

进程模型是最底层，描述协议或算法的状态机行为。aloha_tx.pr.m 和 aloha_tx.pr.c 就是发送端进程，前者是状态转移图的图形化描述，后者是 OPNET 从状态图生成的 Proto-C 代码。aloha_rx.pr.m 和 aloha_rx.pr.c 对应接收端进程。进程模型里定义状态变量、转移条件、以及每个状态内的 FB（Function Block）代码，ALOHA 的随机发送逻辑就藏在这里。

节点模型是中间层，把若干个进程模块和收发信机、队列、处理器等组件装配成一个完整的网络节点。文件清单里的 cct_rx.nd.m 是一个接收节点的节点模型，名字里的 cct 大概率是工程自定义的前缀。节点模型上每个模块引用一个进程模型，模块之间通过包流（packet stream）和统计线（statistic wire）连接。

网络模型是最顶层，描述节点在仿真场景里的拓扑位置和连接关系。cct_network-aloha.nt.m 就是 ALOHA 场景的网络模型，test_Sm_Int-first_floor.nt.m 和 test_Sm_Int-expansion.nt.m 则是 test_Sm_Int 工程下两个具体场景的网络模型。网络模型里放的是节点实例，节点实例引用节点模型，层层嵌套。

表 2-1 列出文件后缀与 OPNET 建模层级的对应关系，这份工程里所有文件都可以挂到这张表上：

这张表就是整个资源的索引。从 .prj 入手打开工程，从 .pr.m 入手改协议，从 .pb.m 入手调统计，从 .nt.log 入手查编译错误，方向不会错。

2.2 工程文件红黑榜：哪些要改、哪些只读、哪些是编译垃圾

同一个目录里混着源码、配置、二进制和运行日志，很多人拿到手第一反应是全部重新编译，这其实没必要。按可操作属性，这份工程包里的文件可以分成三类。

第一类是核心源码，也是你真正要改的部分：aloha_tx.pr.m、aloha_tx.pr.c、aloha_rx.pr.m、aloha_rx.pr.c 四个进程模型文件，cct_rx.nd.m 节点模型，以及 cct_network-aloha.nt.m 网络模型。ALOHA 协议的发送策略、重传机制、冲突检测都在这些文件里，改协议行为就改它们。

第二类是配置文件，属于“平时不动、调参时动”的类型：test_Sm_Int-first_floor.pb.m 是 probe 配置，决定仿真结束后能取到哪些曲线；aloha.ac 是分析工具配置，决定结果视图里展示什么；aloha.ef、cct_network-aloha.ef 是外部文件描述，如果工程引用了外部轨迹文件或地形文件，就在这里指定路径。这类文件建议改之前先备份。

第三类是可以放心删除、让 OPNET 重新生成的编译产物和日志：dev32.i0.nt.dll、dev32.i0.nt.lib、dev32.i0.nt.exp、dev32.i0.nt.pdb、两个 .pr.obj、.nt.log、.cml。这些是当前机器上编译出来的二进制和中间文件，换个 OPNET 版本就失效。我拿到任何工程的第一件事都是把 .dll 和 .obj 删掉重新编译，避免旧二进制干扰仿真结果。.ov 文件是历史仿真输出，如果不想保留数据也可以删，不影响工程打开。

处理文件时给一个实用操作，Linux 或 Git Bash 环境下解压后先按类型清点一遍：

tar xf opnet_aloha.rar # 实际按压缩格式处理 ls -la # 按后缀统计文件数量，快速识别工程规模和编译产物占比 ls *.dll *.lib *.obj 2>/dev/null | wc -l # 查看关键源代码文件大小，确认进程模型内容完整 wc -l aloha_tx.pr.m aloha_tx.pr.c aloha_rx.pr.c

这里先把待编译的二进制清点出数量，再确认进程模型源码非空。如果 aloha_tx.pr.m 没有内容或者只有几十行，说明进程模型状态图可能损坏，后面编译必出问题。OPNET 是图形化建模工具，正常保存的 .pr.m 文件会包含完整的状态和转移描述，用 wc 检查行数是一种粗暴但有效的完整性验证。经验上，一个功能完整的进程模型 .pr.m 文件至少在 300 行以上。

2.3 ALOHA 与 AODV 的协议栈关系：MAC 层随机接入，网络层按需路由

摘要里有一句容易误导人的话，说这是“基于 ALOHA 协议的 AODV 路由协议仿真平台”。这里必须把协议栈关系拆清楚：ALOHA 是数据链路层（MAC）的随机接入协议，AODV 是网络层的按需路由协议，两者不是替代关系，而是上下层叠加关系。这份工程里的 aloha_tx 和 aloha_rx 干的是 MAC 层的活——决定节点什么时候能占用无线信道发送数据包；AODV 干的是网络层的活——决定数据包沿着哪条路径从源节点到达目的节点。

拿这份资源去搜 opnetaodv 的人，实际上需要的是“以 ALOHA 做 MAC 层接入、以 AODV 做路由协议的完整 MANET 仿真”。这份工程给出了前一半：一个可以跑的 ALOHA MAC 层仿真。后一半需要你在 cct_network-aloha.nt.m 的基础上叠加 AODV 进程模型，OPNET 自带 manet 模型库里有 dsr、aodv 等现成实现，直接在节点模型的网络层位置挂一个 AODV 处理器模块就行。

表 2-2 是这份工程对应的协议栈：

理清这个关系之后，这份资源的价值边界就清楚了：它不是一个完整的 AODV 仿真工程，而是一个 ALOHA 底座。把这个底座吃透，再往上叠加 AODV 就只涉及节点模型内部加模块和配参数，不至于从头折腾信道模型和接入机制。

3. 把 test_Sm_Int 工程跑通：场景选择、编译运行与结果导出的完整路径

文件清点完，下一步是把工程真正跑起来。OPNET Modeler 是图形化操作主导的工具，绝大多数操作在 GUI 里完成，但每个操作背后对应什么文件、报错看什么地方，这里按路径拆透。

3.1 场景与工程结构：first_floor 和 expansion 分别对应什么

test_Sm_Int.prj 是工程入口文件，双击或在 OPNET Modeler 里通过 File -> Open 打开它，会看到一个包含多个场景的工程树。工程里至少有两个场景：test_Sm_Int-first_floor 和 test_Sm_Int-expansion。从文件命名看，first_floor 是基础场景，expansion 是扩展场景，后者通常在前者基础上增加节点数量、扩大覆盖范围或者叠加更多业务流。

场景切换在 OPNET 的 Scenarios 菜单里完成，默认打开的可能是最后一次保存的场景。在场景列表里分别打开两个场景对比拓扑规模，先确认 max 场景里的节点数量、分布区域和流量配置。文件清单里 test_Sm_Int-first_floor 和 test_Sm_Int-expansion 各自带有 .seq、.ov、.pb.m 和 -stp_info.gdf 文件，说明两个场景都完整跑过仿真，结果数据是现成的。

.seq 文件是场景的仿真序列配置，记录仿真事件序列和时间推进设置；.ov 是输出向量文件，保存每次运行产生的 statistic 采样值；.stp_info.gdf 记录与步进事件（step）相关的信息，比如节点在特定时刻的状态变化。如果第一次仿真就想快速验证，建议先用 first_floor 场景，节点少、编译快、出问题好定位。

打开场景后第一件事是检查节点是否正常加载。如果节点图标显示为灰色方块或者缺模型，说明节点模型或进程模型的搜索路径配置有问题，这属于第 5 章要讲的典型坑。正常状态是每个节点都能从右键菜单里看到 Process Model 属性，并且引用到 aloha_tx 或 aloha_rx 进程模型。

3.2 编译与运行：把进程模型变成可执行内核

OPNET 里的仿真运行不是解释执行，而是先把所有引用到的模型编译成动态链接库，再由仿真内核加载。这就是为什么工程里会出现 cct_network-aloha.dev32.i0.nt.dll 这类文件——dev32 表示开发版 32 位内核，i0 表示序列号，nt 表示网络模型。编译动作实际是把当前场景引用的所有节点模型、进程模型、链路模型打包到一个 DLL 里。

在最新版本的 Modeler 里，直接点击工具栏的编译按钮，或者右键场景名称选择 Compile。编译过程会把 aloha_tx.pr.m、aloha_rx.pr.m 等进程模型生成 Proto-C 代码并编译成目标文件，再链接到网络模型的 DLL 里。编译日志写在 cct_network-aloha.nt.log 里，一旦编译失败，优先打开这个日志文件定位错误行号。

推荐的做法是先手动删除旧的 .dll、.lib、.obj、.pdb 文件再编译，确保加载的是当前源码构建的新内核。然后进入 Configure/Run Simulation 对话框，关键参数如表 3-1：

参数设置完成后运行仿真，观察事件推进。如果仿真在 0 秒就结束，说明场景里没有可调度的事件，常见原因是流量源未使能。如果仿真卡在某时刻不动，大概率是模型里出现了死循环或等待某个永远不会到达的事件，这时候要在 Debug 模式下查看事件列表。

3.3 结果查看：从 .ov 向量文件到吞吐量曲线

仿真结束后，View -> Results -> View Results 打开结果浏览器，能看到的曲线全部来自 .pb.m 文件里预先配置好的统计量采集项。这份工程的 test_Sm_Int-first_floor.pb.m 定义了基础统计量，包括发送端产生的包数、接收端收到的包数、信道吞吐量等。

如果只需要看单条曲线，直接在结果浏览器里选中即可。但做协议对比时往往需要把数据导出到外部工具处理。结果浏览器里选中目标统计量后，用 Export to Spreadsheet 功能导出为 CSV 文件。导出的 CSV 通常包含时间戳和采样值两列，下面是处理吞吐数据的 Python 脚本参考：

import csv import sys def calc_throughput(csv_path, bit_per_packet=1000): total_bits = 0 start_time = None end_time = None with open(csv_path, "r") as f: reader = csv.reader(f) for row in reader: if len(row) < 2: continue try: t = float(row[0].strip()) val = float(row[1].strip()) except ValueError: continue if start_time is None: start_time = t end_time = t total_bits += val * bit_per_packet duration = end_time - start_time if duration <= 0: return 0.0 return total_bits / duration # bits per second if __name__ == "__main__": print("throughput:", calc_throughput(sys.argv[1]), "bps")

这个脚本把每个采样点代表的包数量乘以包长（默认 1000 bit），再除以仿真时长，得到平均吞吐量。实际使用时把 bit_per_packet 改成你工程里设置的包长。如果是用 OPNET 自带的吞吐量 statistic，直接读采样值做平均即可。注意 CSV 从 OPNET 导出时时间戳列可能带单位后缀，脚本里做了异常过滤，但最好先用文本编辑器打开确认列格式。

如果你要对比不同参数下的 ALOHA 吞吐，推荐做法是批量跑完仿真后，把每个场景的 .ov 导出为独立 CSV，用 Python 批量算平均吞吐，再统一画图。这样可以避开在 OPNET GUI 里反复切换比对曲线的低效操作。

4. 把 ALOHA 参数调到可信：信道速率、时隙时长与重传窗口的取值

ALOHA 协议的原理很简单，但仿真参数设置不对，结果很容易背离理论值。这一章把纯 ALOHA 与时隙 ALOHA 的理论公式、进程模型里的参数映射、以及性能指标采集配置放在一起讲，直接对应到这份工程的 aloha_tx.pr.m 和 .pb.m 文件。

4.1 纯 ALOHA 与时隙 ALOHA：公式与 OPNET 模型里的实现差异

ALOHA 协议有纯 ALOHA 和时隙 ALOHA（Slotted ALOHA）两种。纯 ALOHA 里节点随时可以发送数据，两个节点发送时间只要有重叠就发生冲突，冲突后各自随机延时重传。时隙 ALOHA 把时间轴划分成固定长度的时隙，节点只能在时隙边界开始发送，冲突窗口缩小一半，信道利用率翻倍。

对应理论公式：纯 ALOHA 的吞吐量 S = G·e^(-2G)，最大吞吐出现在 G=0.5 时，S_max ≈ 0.184，即信道利用率上限约 18.4%；时隙 ALOHA 的 S = G·e^(-G)，最大吞吐出现在 G=1 时，S_max ≈ 0.368。这里的 G 是信道负载，等于单位传输时间内所有节点产生的总数据量（含重传）与信道容量的比值。

在 OPNET 进程模型里实现两种模式的关键差异在于发送前是否检查时隙边界。纯 ALOHA 状态机里，节点生成数据包后直接进入发送状态；时隙 ALOHA 则需要节点维护一个时隙时钟，包生成后先进入等待状态，直到下一个时隙边界到来才真正发送。这份工程里的 aloha_tx.pr.m 如果要改造成时隙 ALOHA，重点改进程模型的发送前状态转移条件即可。

4.2 aloha_tx 进程模型关键参数：发包间隔、负载 G 与退避策略

仿真结果是否可信，取决于参数是否贴近真实场景。这份工程里 aloha_tx 进程模型可调的参数，常见包括数据包生成间隔、包长、最大重传次数、重传退避时间等。在 OPNET 进程模型编辑器里，这些参数通过 Attributes 定义，运行时用 op_ima_sim_attr_get 读取。

表 4-1 是 ALOHA 仿真里最核心的参数组及推荐取值思路：

比如信道速率设置为 1 Mbps，包长 1000 bit，一次传输时间就是 1 ms。当 Interarrival Time 均值也是 1 ms 时，信道负载 G 接近 1，纯 ALOHA 刚好在理论吞吐峰值附近。想验证曲线逼近 0.184 的上限，就把负载打到 0.1 到 2 之间多取几个点。

进程模型里读取参数的 Proto-C 代码通常是这样的模式：

// 在进程模型的初始化状态中读取用户配置 double interarrival; double pkt_size; int max_retry; // 从进程模型属性中读取参数 op_ima_sim_attr_get_dbl (self, "Interarrival Time", &interarrival); op_ima_sim_attr_get_dbl (self, "Packet Size", &pkt_size); op_ima_sim_attr_get_int (self, "Max Retransmissions", &max_retry);

这段代码里 op_ima_sim_attr_get 系列函数负责从仿真内核里读取用户在节点属性面板设置的参数。改参数时如果发现改了 GUI 属性但行为不变，优先怀疑属性名不匹配，核对这里字符串是否与进程模型 Attributes 里定义的名字完全一致，包括大小写和空格。

4.3 性能指标配置：从 probe 文件到吞吐、丢包与延迟

仿真跑完能不能出想要的指标，取决于 .pb.m 文件里配置了哪些采集项。test_Sm_Int-first_floor.pb.m 和 test_Sm_Int-expansion.pb.m 各自对应一个场景的采集配置，这是要重点研究和修改的文件。

一个基本的 ALOHA 性能指标集应包括三部分。吞吐量：统计接收端每秒成功收到的数据量，可以直接采集 aloha_rx 接收模块的包到达速率，或以 bit 为单位统计信道吞吐；丢包率：等于发送端产生的包数减去接收端成功接收的包数再除以发送总数，在 ALOHA 场景里冲突丢弃是丢包主因；端到端延迟：从发送端产生包到接收端完整收到包的时间差，在 OPNET 里通常用包延迟统计量采集。

probe 文件的修改在 GUI 里完成。菜单 Design -> Define Probes 打开 Probe Model 编辑器，选择要采集的统计量，保存后会写回 .pb.m 文件。如果新增了统计量但结果浏览器里看不到，打开 .pb.m 文件确认 XML 里是否录入了对应的 statistic 名称，和进程模型里 op_stat_register 注册的名字要完全匹配。

最后补一个很多教程不会讲的操作：把节点处理能力、队列容量等设备属性也纳入考察。摘要里的 equipmentqst 标签指的就是这类设备级参数——节点 CPU 速率、buffer 大小、接口队列长度会影响 ALOHA 在高负载下的丢包行为。如果只关注接入协议本身，这些属性可以保持默认；但要做“设备能力受限时的协议退化”这类实验，就需要在节点模型中为每个模块设置处理速率上限，通常在节点模块的 Processing Delay 或 Data Rate 属性里调整，这两者的典型取值区间是 10 kbps 到 100 Mbps，按仿真场景的规模量级选择才能看到差异。

5. OPNET 仿真常见问题排查：编译失败、DLL 加载错误与空数据曲线的五个坑

这份工程包是从实际仿真机上拷贝下来的，到另一台机器上复现时，难免遇到环境差异导致的问题。这一章列五个高频坑，全部是按“现象-原因-解决”的路径记录的真实经验。

坑 1：.prj 打开后节点是灰色方块，无法运行仿真

现象：工程能打开，但网络模型里的节点图标显示异常，双击节点看不到进程模型属性，仿真按钮置灰。

原因：节点模型文件 .nd.m 或进程模型文件 .pr.m 没有在当前工程的模型搜索路径里。拷贝工程时如果只复制了 .prj，没有把整个模型目录一起复制，或者目录路径包含中文、空格导致 OPNET 找不到引用文件，都会出现这个表现。

解决：打开 Edit -> Preferences，检查 Model Directories 设置，把 opnet_aloha 工程所在目录添加进去。确认 aloha_tx.pr.m、aloha_rx.pr.m、cct_rx.nd.m 都在该目录下。保存后重新打开工程，节点应该恢复正常。建议工程目录用纯英文路径，这是 OPNET 环境里最常见的玄学问题来源。

坑 2：编译成功但运行时报 DLL 加载失败，提示“无法定位程序输入点”

现象：点击 Run Simulation 后，仿真内核启动失败，弹出 DLL 相关错误，或者提示找不到 cct_network-aloha.dev32.i0.nt.dll 的某个导出函数。

原因：工程包里带的是别人机器上编译的二进制，和当前 OPNET 版本的运行时库不匹配。OPNET 14.5、17.5、18.x 等不同版本编译出来的 DLL 二进制布局有差异，跨版本直接复用必然报错，这个跟网络模型源代码无关。

解决：把工程目录下所有 .dll、.lib、.exp、.pdb、.obj 文件全部删除，重新编译网络模型。编译完成后确认新的 .dll 生成时间戳是刚生成的，再运行仿真。如果是 14.5 版本，还要检查编译器版本是否匹配，常见搭配是 VC6 或 VS2005，编译器不匹配同样会导致链接错误。

坑 3：仿真运行正常，但结果浏览器里一条曲线都没有

现象：仿真跑到结束，没有报错，但 View Results 里统计量为空。

原因：probe 文件 .pb.m 没有正确关联到当前场景。场景复制、重命名后容易出现这种情况，旧场景的 probe 配置还挂在旧场景名上，新场景里没有可用的采集项。此外，如果统计量是在仿真启动后动态注册的，而 probe 配置在仿真前没有选中该统计量，也会采不到数据。

解决：打开 Probe Model 编辑器，确认当前场景的采集项列表非空。为空时就逐个添加需要的统计量并保存。注意要把 probe 文件关联到当前场景，在 Scenarios -> Scenario 设置里检查 probe 文件的引用路径。

坑 4：改了 aloha_tx.pr.c 里的源码，仿真结果完全没变化

现象：在 aloha_tx.pr.c 里手动修改了发送逻辑，重新编译也成功，但吞吐曲线和修改前一模一样。

原因：OPNET 进程模型的主文件是 .pr.m，图形化状态图里生成的 Proto-C 代码才同步写到 .pr.c。直接在 .pr.c 里改代码，下一次进程模型编辑器任何一次保存操作都会用状态图重新生成 .pr.c，覆盖手工修改。而且编译优先使用 .pr.m 重新生成的 Proto-C，手工改的 .pr.c 可能根本没进入编译链。

解决：永远在进程模型编辑器里改状态图，包括状态转移条件、FB 代码、临时变量。改完保存后，在菜单 Generate Proto-C 里显式触发代码生成，再编译。这个步骤最容易被忽略，却又是最影响结果可信度的一步。那以后我每次改完进程模型都会写下这个流程，避免再犯同类错误。

坑 5：扩展场景 expansion 编译报错，提示外部文件找不到

现象：first_floor 场景编译运行正常，切换到 expansion 场景后编译失败，日志里提示某个 .ef 文件描述的外部文件路径不存在。

原因：expansion 场景比 first_floor 场景引用了额外的外部文件，比如移动节点的轨迹文件、地形文件或外部流量描述文件。工程从一台机器拷贝到另一台机器后，绝对路径失效，而 .ef 文件里记录的还是旧路径。

解决：编辑 aloha.ef 和 cct_network-aloha.ef 文件，把外部引用改成本机实际路径，推荐改成相对路径。检查 expansion 场景的网络模型中是否有引用外部文件的节点属性，比如 trajectory 属性指向的 .trj 文件。逐个修正后重新编译即可。这条也是工程迁移最耗时间的部分，因为报错提示往往只给文件编号不给完整路径，要顺着场景里的引用链一层层找。

6. 把 ALOHA 底座升级为 AODV 场景：RREQ/RREP 叠加与验证方法

最后把这份资源最大的扩展空间说出来：在 ALOHA 的 MAC 层之上叠加 AODV 路由协议。搜 opnetaodv 的人真正要的场景，是把 ALOHA 的随机接入能力和 AODV 的按需路由结合起来，仿真它们在移动自组织网络中的协同表现。

改造路径分三步。第一步，在节点模型编辑器中新增一个 AODV 处理器模块。OPNET 的 manet 模型库自带 aodv 进程模型，直接拖进节点模型，放在网络层位置，上下分别连接应用层和 MAC 层的 ALOHA 模块，包流方向按路由协议标准接法打通。第二步，删除 aloha_tx 模块中与路由查找相关的逻辑，ALOHA 只保留信道接入功能，MAC 层收到的数据包统一交给 AODV 层判断是转发还是上抛。第三步，配置 AODV 参数。

关键参数按表 6-1 设置：

验证方法也讲究：先在静态拓扑下跑纯 ALOHA，确认 MAC 层数据包延迟稳定；再开启节点移动轨迹文件，让网络拓扑发生变化，观察 AODV 的 RREQ 洪泛次数、路由表项变化频率，以及端到端延迟是否随路由重建出现尖峰。具体做法是在场景网络模型里给节点配置 trajectory 属性，或者在仿真中动态改变节点的 position 属性，让 MANET 的拓扑不断演化，这就完整复现了 ALOHA 与 AODV 跨层交互的仿真链路。

从那以后，我拿到任何 OPNET 工程的第一件事都是先删掉所有 .dll 和 .obj 重新编译，再检查 .pb.m 是否挂在当前场景上，最后才谈参数调优。ALOHA 这份资源是这样走通的，往 AODV 方向改造时也强制走一遍同样的流程，省下好几个小时的排错时间。希望帮到你。

本文还有配套的精品资源，点击获取