简介NS-allinone 2.26 是一套完整的网络仿真软件包整合了 ns-2 网络模拟器及周边工具适合网络专业学生、研究人员与工程测试者使用。它重点支持 MAC 层与路由层模拟MAC 层负责数据链路的地址识别与冲突检测路由层决定数据包从源到目标的传递路径借助该环境无需真实硬件即可观察拥塞、丢包、延迟等现象从而深入理解网络协议的设计意图。压缩包共含 5056 个文件整体约 50.44MB其中 tcl 脚本用于描述测试拓扑与业务流量cc、c、h 为 ns-2 核心源码test 与 readme 给出回归用例和使用文档nam 可辅助查看动画结果解压后按标准流程配置编译即可运行。目前已有 108 人学习下载内含大量无线、路由、组播等经典实验场景与扩展模块可作为课程实验、毕业设计或科研性能对比的参考基线适合网络仿真入门者与进阶者使用。1. ns-allinone-2.26 是什么为什么 2.26 这个老版本还有人坚持在装手头只有一台 Linux 机器、一篇 2004 年的无线自组网论文以及一个写着ns-allinone-2.26.tar.gz的下载链接——这是很多研究生第一次接触 NS-2 的起点。这个包不是普通的源码压缩包它把 ns-2.26 核心仿真器以及全部运行依赖打包在一起Tcl/Tk 8.4.5 脚本环境、otcl 面向对象扩展、tclcl 的 C 绑定层、nam 网络动画回放器、xgraph 绘图工具。一次下载、一次编译就能把解释器、仿真内核和可视化工具全部备齐。它的价值在于解决了一个很现实的问题现在的 Linux 发行版软件源里几乎找不到 NS-2单独去下载各个依赖很容易版本错配。而 2.26 这个版本被大量课程讲义、学位论文和实验平台长期沿用像 MANET 场景常用的 DSDV、AODV 路由协议实现都是这个年代稳定下来的要复现老论文的数据版本必须卡死在 2.26。适合的人群很明确需要跑无线多跳网络、TCP 变体对比、队列管理算法验证的研究者和工程师。需要提前说清楚的是这个包没有任何二进制安装拿到手就是源码靠一个install脚本从头编译——这也是后面最容易翻车的地方。2. 解包之前先核对三件事组件构成、编译顺序与 gcc 版本选型2.1 六个组件各自的职责与编译顺序allinone 为什么叫 allinonens-allinone-2.26里的 allinone 不是营销话术而是它真的把一整条工具链按顺序摆好了。ns-2.26 的仿真内核本身是 C 写的但用户写仿真场景用的是 Tcl 脚本这就需要一个解释器来执行 Tcl 代码为了让 C 的对象能被 Tcl 脚本直接操作需要 otcl 这个面向对象的 Tcl 扩展以及 tclclTcl/C 绑定层把两边拼起来。nam 负责把 trace 文件里的运动轨迹回放成动画xgraph 负责把仿真数据画成曲线。这套生态的分工决定了它们的编译顺序极其严格。组件语言/作用编译顺序tcl8.4.5Tcl 解释器基础库1tk8.4.5Tcl 的图形界面扩展nam 依赖它2otcl-1.0a7面向对象 Tcl 扩展C 实现3tclcl-1.14C 对象到 Tcl 的绑定层4ns-2.26仿真内核本体5nam-1.11网络动画回放器6xgraph-12.1简单绘图工具7顺序为什么不能乱因为后一个组件的 configure 脚本会去前一个组件安装好的目录里找头文件和库文件。tclcl 链接 otcl 的库ns 链接 tclcl 的库nam 依赖 tk 的窗口组件。install脚本把这个顺序写死并逐个调用configure make你不需要手动记但必须知道一旦中间某个组件编译失败后续所有组件都会跟着失败看日志时需要顺着这个顺序往上找根因。还有一个经常被忽视的选型理由为什么 allinone 里固定用 tcl 8.4.5而不是系统自带的 8.6因为 NS-2.26 的 otcl 和 tclcl 是按 8.4 的 C API 写的8.5 之后 Tcl 改了 channel 和事件调用的内部接口强行用系统新版 Tcl 会导致编译期对不上符号或者编译过去了运行期崩溃。所以不管你的机器上有没有 Tcl都优先用包里自带的这一套这就是 allinone 存在的意义。2.2 三步完成解包与版本核对tar 命令、install.conf、编译器探测拿到ns-allinone-2.26.tar.gz之后我一般不会直接跑./install而是先做三件事解包、看目录结构、探测编译器版本。这套动作能帮你提前判断这个包在你的机器上会不会顺利编过。tar xzvf ns-allinone-2.26.tar.gz cd ns-allinone-2.26 ls -F cat install.conf第一行解包会输出每个文件的展开路径留意有没有tcl8.4.5/、tk8.4.5/、otcl-1.0a7/、tclcl-1.14/、ns-2.26/、nam-1.11/、xgraph-12.1/这些目录。第二行进入包目录第三行ls -F能看到一个没有扩展名的可执行脚本install它就是这个 allinone 包的编译总入口。第四行cat install.conf是查看编译配置里面会写明默认的 C 编译器名通常是c如果你系统里装了多个版本的 gcc这一步就能确认它会调用哪个。接下来是编译器探测g --version make --version这两条命令的目的是确认工具链的存在。NS-2.26 是 2003 年前后的代码它默认假设你用的是 gcc 3.x而 gcc 4.0 之后的 C 标准检查已经变严。如果g --version显示的是 7、9、11 这类版本号你要有心理准备这个包大概率不能一次编译通过后面要么换编译器要么打补丁。这一步提前做了比编译到一半报错再去查资料省时间得多。我特别不建议跳过我上面说的第三步直接去跑 install因为在你机器上第一个失败的组件往往不是 ns 内核而是 otcl 或 tclcl——这两个目录的编译错误信息特别有迷惑性新手容易误以为包坏了删掉重新解压再来一遍结果浪费半小时又回到同一个错误。先确认编译器版本再决定走哪条路。2.3 gcc 版本选型4.x 以下用原装代码5.x 以上直接准备打补丁或换老环境ns-allinone-2.26 的源码是给 gcc 3.x 写的这决定了它在不同系统上的编译命运差异极大。我按踩过的机器整理了一个选型参考下面这张表可以直接对照使用g 主版本预期情况建议做法3.4原始目标环境基本能一次过无需额外处理4.4 ~ 4.8可能直接过或偶发个别报错小补丁即可优先选择5 ~ 7otcl/tclcl 大概率报 void* 转换错误加-fpermissive或降级编译器8 及以上多处 C 语法检查失败建议直接用老发行版虚拟机或容器这里说的选型理由本质上是 C 标准收紧和代码老旧之间的矛盾。旧代码里经常把malloc返回的void*直接赋给char*或int变量这在 C 里本来就是非法转换但 gcc 3.x 只给警告能编过gcc 4.x 开始把它升级成 error编译直接中断。遇到这种情况两条路一是给编译参数加-fpermissive让错误降级回警告这是最快的补丁方案二是给这台机器装一个 gcc-4.8 或者干脆用 Ubuntu 14.04 时代的虚拟机。做网络仿真本身对 CPU 性能要求不高跑一次几秒到几分钟的 Tcl 脚本老环境完全够用。我个人的习惯是如果物理机的 g 已经到 8 以上就不在真机上死磕了。直接用 Docker 拉一个带 gcc-4.8 的镜像或者 VirtualBox 装个 Ubuntu 16.04把所有仿真都放在里面跑。这样做不是逃避问题而是 ns-allinone-2.26 这套代码的坑是确定性的与其一个补丁一个补丁地打不如让编译器回到它熟悉的年代。如果你一定要在现代系统上编必须做好记录你改了哪些文件、动了哪些 flags否则三个月后换个机器再装又要重新踩一遍。3. 用 ./install 编译 ns-allinone-2.26三个环境变量与一次最小验证3.1 执行 ./install 并读懂每步输出从 tcl 编译到 xgraph 收尾进入ns-allinone-2.26目录后直接运行./install这是整个包的总入口。它会依次进入每个子目录执行configure make整个过程在虚拟机里大概十几分钟在现代机器上会快一些。我建议把输出重定向到日志文件这样出错了可以回头翻而不是盯着滚动的屏幕干瞪眼。cd /home/user/ns-allinone-2.26 ./install install.log 21 tail -n 60 install.log第二行是核心操作 install.log 21把标准输出和标准错误都写进文件。第三行tail -n 60看日志最后 60 行判断是否编译完成。install脚本每编完一个组件会在终端打印类似*** otcl-1.0a7 completed ***的提示最后会打印一段环境变量配置说明这是整个安装最重要的产物。注意如果编译在中途中断直接重跑./install即可已经编译好的组件目录不会被清空configure 会检测到已有产物不会全部重来。这一点我踩过坑早期以为中途失败必须删包重解压其实白白浪费了时间。日志里需要重点盯的阶段有三个otcl 编译阶段、tclcl 链接阶段、nam 的 configure 阶段。otcl 和 tclcl 是 C 代码最容易触发语法报错的地方nam 的 configure 则最容易因为系统缺 X11 开发库而中止。如果日志停在这三处对照第 5 章的避坑记录处理即可。3.2 环境变量配置PATH、LD_LIBRARY_PATH、TCL_LIBRARY 少一个都跑不起来./install跑完后没有任何桌面提示它只会告诉你把几个目录加进环境变量。这个步骤漏掉是最常见的“假安装成功”当时能用重启终端就ns: command not found。原因是 ns 可执行文件、动态库和 Tcl 库分别装在三个不同位置的目录里shell 默认根本不知道它们在哪。export PATH$PATH:$HOME/ns-allinone-2.26/bin:$HOME/ns-allinone-2.26/tcl8.4.5/unix:$HOME/ns-allinone-2.26/tk8.4.5/unix export LD_LIBRARY_PATH$LD_LIBRARY_PATH:$HOME/ns-allinone-2.26/otcl-1.0a7:$HOME/ns-allinone-2.26/lib export TCL_LIBRARY$HOME/ns-allinone-2.26/tcl8.4.5/library这三行是有明确分工的。PATH 里加bin是为了让系统找到ns、nam、xgraph这三个可执行文件加tcl8.4.5/unix和tk8.4.5/unix是因为包里的 tclsh 和 wish 这两个解释器程序编译后放在这里。LD_LIBRARY_PATH 加otcl-1.0a7和lib是让动态链接器能找到libotcl.so这类运行库。TCL_LIBRARY 指向tcl8.4.5/library里面是 Tcl 的标准脚本库ns 启动时要用它初始化解释器。我一般会把这些 export 追加到~/.bashrc末尾而不是只手动执行一次。因为.bashrc是每次打开新终端都会加载的写进去才能保证持久生效。追加后执行source ~/.bashrc让它立即生效再运行which ns验证。命令行which ns如果输出路径说明安装链路基本打通了。这一步别偷懒我在多台机器上见过用户把 export 敲在终端里就跑结果换一个终端就“丢配置”还以为是系统坏了。3.3 最小验证跑通 tcl/ex/simple.tcl 并调用 validate 回归套件环境变量配好之后不要急着写自己的仿真脚本先用 ns-2.26 自带的例子做一次冒烟测试。tcl/ex/simple.tcl是 allinone 包里自带的最小有线仿真例子两个节点之间传 UDP 数据包能完整走通“编译→运行→产出 trace 文件”整条链路。cd $HOME/ns-allinone-2.26/ns-2.26 ./ns tcl/ex/simple.tcl head -n 5 out.tr第一行进入 ns 源码目录第二行调用刚才装的 ns 解释器执行示例脚本。执行完会看到屏幕上刷出一长串事件行最后出现Scheduler: Simulation completed之类的完成提示同时当前目录下生成out.tr文件。第三行用head -n 5查看前 5 行 trace能看到类似 0.02 0 1 cbr ...的事件记录。这段输出的价值是确认三件事ns 能启动、Tcl 脚本能执行、trace 文件能正确写入。如果这步通过再跑一下官方回归验证套件。进入ns-2.26目录后执行./validate -r它会批量运行 test-suite 目录下的几十个测试用例并把结果与官方期望值比对。这个命令耗时很长小机器上可能要跑几十分钟但它是检验你的编译环境是否影响仿真结果的黄金标准。我在旧机器上见过 validate 全过也在新编译器环境上见过个别用例因浮点精度差异失败——后者不代表代码坏了但你要知道你的环境存在这种偏差跑对比实验时要记录编译环境信息。4. 从 Tcl 脚本到 out.tr用 ns-2.26 跑通第一个 2 节点仿真4.1 最小 Tcl 脚本逐行拆解Simulator、node、duplex-link、Agent/UDP 与 CBR 参数系统装好后真正的用法是用 Tcl 写仿真场景。下面这个脚本是我最常用的最小模板两个有线节点一条 UDP 流跑 1.5 秒产出 trace 文件。它短到可以逐行背下来但涵盖了你写任何 NS-2 脚本都会遇到的四个要素。# 创建仿真器实例 set ns [new Simulator] # 打开 trace 文件并把仿真事件写入其中 set tracefile [open out.tr w] $ns trace-all $tracefile # 创建两个节点 set n0 [$ns node] set n1 [$ns node] # 用 1Mb 带宽、10ms 延迟的 DropTail 链路连接两个节点 $ns duplex-link $n0 $n1 1Mb 10ms DropTail # 在 n0 上挂 UDP 发送代理在 n1 上挂 Null 接收代理 set udp0 [new Agent/UDP] $ns attach-agent $n0 $udp0 set null0 [new Agent/Null] $ns attach-agent $n1 $null0 $ns connect $udp0 $null0 # 配置 CBR恒定比特率流量发生器 set cbr0 [new Application/Traffic/CBR] $cbr0 attach-agent $udp0 $cbr0 set packetSize_ 1000 $cbr0 set interval_ 0.02 # 调度事件0.1 秒启动流量1.0 秒停止 $ns at 0.1 $cbr0 start $ns at 1.0 $cbr0 stop # 1.5 秒结束仿真 $ns at 1.5 $ns halt # 开始运行 $ns run这段脚本第一行new Simulator是所有 NS-2 仿真器的根对象事件调度、节点创建都由它管理。trace-all把后续所有网络事件写入 out.tr。duplex-link的三个参数是带宽、传播延迟和队列类型这里用 1Mb、10ms、DropTail 是教材级默认值实际项目里带宽看链路场景延迟跟距离和介质相关。Agent/UDP加Agent/Null是一对经典的发送/接收组合Null 接收端只丢弃收到的包是测量接收量的标准锚点。Application/Traffic/CBR模拟恒定速率流量packetSize_ 1000表示每个包 1000 字节interval_ 0.02表示每 0.02 秒发一个包也就是 50 包每秒。packetSize_和interval_这两个参数决定流量速率改成interval_ 0.01就是 100 包每秒再乘以包大小就是带宽大小。我见过有人直接把interval_设成 0 导致 CPU 满转那相当于无限速率发包队列立刻打满。4.2 解析 out.tr、r、d 三列事件与 awk 统计收包/丢包跑完上面的脚本当前目录会生成 out.tr。这个文件的每一行记录一个网络事件前四列固定是事件类型、时间、源节点 ID、目的节点 ID。看懂前四列你就掌握了 trace 分析的主干。 0.020000 0 1 cbr 1000 ------- 0 0.0 1.0 0 0 r 0.022000 0 1 cbr 1000 ------- 0 0.0 1.0 0 0 0.040000 0 1 cbr 1000 ------- 0 0.0 1.0 0 0 d 0.055000 1 2 cbr 1000 ------- 0 0.0 1.0 0 0第一列的事件字符表示数据包进入节点队列r表示数据包被接收d表示数据包被丢弃无线仿真里还会出现s表示节点发送到无线信道。第二列是事件发生时刻第三列和第四列是源和目的节点的 ID。后面的列依次是包类型、包大小、流标识、源地址、目的地址等有线场景下前四列足够完成大部分统计。统计收发包最直接的方式是用 awk 一行扫完整个文件。我常用的统计命令如下awk $1 {sent} $1r {recv} $1d {drop} \ END {printf sent%d recv%d drop%d\n, sent, recv, drop} out.tr这条 awk 的逻辑是逐行读取 out.tr按第一列匹配事件类型并累加计数最终打印发送、接收、丢弃三个数字。对于 2 节点无丢包的小场景drop 数应该是 0如果 drop 数异常优先回头检查链路带宽是不是设小了队列是不是打满了。丢包率、吞吐量的计算都可以从这三个数字出发吞吐量就是recv乘以 packetSize_ 再乘以 8除以仿真有效时长。这套 awk 逻辑我从 2.26 用到 2.35几乎没改过。4.3 用 nam-1.11 回放动画从 trace 到可视化的两条路数据统计做完后很多人想把仿真过程可视化这时用到的就是 allinone 包里的 nam-1.11。nam 直接读取 trace 文件回放动画不需要额外配置。在图形桌面环境下进入 trace 文件所在目录执行以下命令即可打开可视化窗口nam out.trnam 窗口里会看到两个节点、一条链路以及数据包在链路上的移动过程窗口底部有播放/暂停按钮。它默认读取的是仿真开始到结束的全过程包含数据包入队、发送、接收的动画。如果你只想看某个时间段可以在 nam 界面里拖动进度条定位。nam 有一个前提条件必须运行在带图形界面的 X 环境下纯服务器、无显示环境或者 WSL 未配置图形转发时它会报couldnt open display一类的错误。这种情况不用慌nam 只是表现层不影响仿真结果分析。我一般会把可视化当作“给论文答辩准备的演示材料”而把数值统计作为主要研究手段——毕竟 nam 回放的是宏观动画它不能替代基于 trace 数值的精确分析。如果机器实在没有图形界面又需要给人展示正确做法是保存 trace 文件后拷到有图形环境的机器上再打开 nam或者直接用 gnuplot 把数值画成曲线。5. ns-allinone-2.26 避坑记录5 个高频翻车点与对应处理5.1 otcl/tclcl 报 invalid conversion from void*老 C 代码撞上新编译器现象编译到 otcl-1.0a7 或 tclcl-1.14 时控制台刷出一堆invalid conversion from void* to char*或from void* to int的错误然后 make 中断退出。这是 2.26 在 gcc 5 以上系统里最常见的第一道坎。原因源码里用了malloc分配内存后直接赋给非 void 指针或者把Tcl_Alloc的返回值赋给 int 变量。gcc 3.x 时代这只是警告gcc 4.x 起按 C 标准严格处理成编译错误。解决两个办法优先给这两个组件加-fpermissive把这类错误降级回警告代码逻辑不受影响。用文本编辑器打开otcl-1.0a7/Makefile和tclcl-1.14/Makefile找到CXXFLAGS变量所在行手动追加-fpermissive保存后回到 ns-allinone 根目录重新执行./install。如果 ns-2.26 本体也报同类错误同样把参数加到ns-2.26/Makefile的CXXFLAGS里。注意改文件后要先make clean或直接删掉对应目录里的.o文件否则 make 检测不到变化不会重新编译。5.2 64 位系统链接期 undefined reference-fPIC 与两条取巧路线现象在 x86_64 机器上编 otcl 或 tclcl前面 configure 和编译都顺利到了链接阶段报relocation R_X86_64_32S can not be used when making a shared object或者是大段的undefined reference to ...。原因这套 2003 年的代码编译共享库时没有启用-fPIC位置无关代码选项。32 位时代这不是问题64 位系统的动态链接器要求共享对象里所有代码都位置无关否则重定位失败。解决把-fPIC塞进编译参数。常见做法是修改otcl-1.0a7/configure和tclcl-1.14/configure里的 CFLAGS 变量在原有-O2后追加-fPIC改完之后删除对应目录下的 config.cache 和所有 .o 文件再重新跑 install。我一般直接执行grep -n CFLAGS otcl-1.0a7/configure tclcl-1.14/configure先用这条命令找到需要改的行号再手动编辑比用 sed 盲改更稳妥。如果你不想折腾补丁第二条取巧路线就是直接换 32 位环境或老版本 gcc一了百了。这里额外提醒-fPIC加与不加不影响仿真逻辑只影响链接产物可以放心改。5.3 nam configure 找不到 Xmu缺了三个 X 开发库现象编译进度走到 nam-1.11 时configure 输出checking for Xmu... no随后报X11/Xmu/Xmu.h: No such file or directory并中止。原因nam 是 Tk 图形程序依赖 X Window 系统的 Xmu、Xt、Xext 三个开发库。服务器最小化安装通常只有 X 运行库没有开发头文件configure 自然找不到。解决安装开发包后重编。Debian/Ubuntu 系列执行sudo apt-get install libxmu-dev libxt-dev libxext-devRHEL/CentOS 系列对应的包名是libXmu-devel、libXt-devel、libXext-devel。装完不要直接跑整个./install单独进 nam-1.11 目录执行make clean再回根目录重跑速度更快。如果你的机器完全没有图形界面、也不打算用 nam可以暂时跳过 nam 的编译它不影响 ns 内核和 trace 分析。5.4 换终端就 ns: command not found环境变量只写在当前 shell 的后果现象安装当天明明能跑ns关掉终端或重启系统后再输入ns提示command not found但有的时候同一个终端里又能用行为很“玄学”。原因安装时只在当前终端手动执行了 export这些变量是进程级的终端一关就没了。bash 每次启动新会话都会重新加载环境配置没写进.bashrc的变量自然丢失。解决把第 3.2 节的三行 export 追加到~/.bashrc末尾然后执行source ~/.bashrc立即生效。验证方式是用which ns和echo $LD_LIBRARY_PATH检查。我见过最隐蔽的情况是用户把 export 写进了/etc/profile但自己的 shell 配置里又把它覆盖了导致有时能用有时不能用。排查时先用echo $PATH看当前会话实际加载的路径再对照配置文件确认有没有冲突。这条坑不值得反复踩追求稳妥的人可以直接把自己机器上的仿真统一放到固定用户目录下环境配置一次写对之后所有终端通用。5.5 无线脚本报 couldnt read file cbrgen.tcl相对路径陷阱与 setdest 生成场景现象从tcl/ex里拷出无线仿真脚本到其他目录运行报couldnt read file ./cbrgen.tcl或者couldnt read file ./setdest/scen.tcl换成在源码目录里运行却正常。原因2.26 的示例脚本里写的是相对路径引用了当前工作目录下的场景生成工具。当你把脚本复制到另一个目录路径就断了。解决两个选择。一是脚本不动把工作目录切到脚本所在目录再运行二是把脚本里的source cbrgen.tcl这类语句改成绝对路径。做无线自组网实验时场景文件一般用 setdest 工具生成生成出来的移动场景脚本需要被你自己的仿真脚本 source。我常用的生成命令是cd ns-allinone-2.26/ns-2.26/indep-utils/cmu-scen-gen/setdest ./setdest -n 40 -p 0 -M 20 -t 200 -x 800 -y 800 scen.tcl-n是节点数-p是节点暂停时间秒-M是节点最大移动速度米/秒-t是仿真时长-x和-y是场景区域大小。生成后的scen.tcl里是一堆$node_ set X_ ...之类的初始位置语句直接在仿真脚本开头 source 它即可。如果命令提示setdest: command not found说明该目录没在 PATH 里用绝对路径调用即可。6. 装完再往前走一步validate 回归、setdest 无线场景与可复现数据6.1 用 validate 做回归确认你的 2.26 没被改坏装好之后先别急着写大实验先用官方的回归套件验证一遍环境。进入ns-2.26目录执行./validate -r它会跑几十个预先写好的测试用例每个用例代表一种典型网络场景比如 TCP 拥塞控制、队列管理、无线路由等。跑完后脚本会比对输出与官方参考值是否一致。这一步能一次性暴露你环境里的隐性问题编译器版本导致的行为差异、补丁是否打对、库链接是否有隐藏错误。我在一台 gcc-4.8 的虚拟机上跑过 validate全部通过也见过群里有人在现代 gcc 上加了一堆-fpermissive后强行编过个别用例在浮点输出上有细微偏差。这类偏差平时跑小实验看不出来但当你把仿真结果写进论文、别人按你的环境去复现时就会出问题。所以我会把编译器版本和 validate 结果记录成一份文本放在项目目录里这比以后写“实验环境”章节时凭记忆靠谱得多。6.2 无线场景与 setdest/cbrgen让对比实验有数据可用回归确认无误后就可以进入正题了。做 MANET 路由协议对比时典型流程是先随机生成节点移动场景和流量模型再跑多个随机种子取平均值。setdest 生成移动场景的命令前面已经给出流量模型用 cbrgen 生成两者都是 ns-2.26 自带的工具。流量生成命令如下cd ns-allinone-2.26/ns-2.26/indep-utils/cmu-scen-gen/cbrgen ns cbrgen.tcl -n 40 -t 200 traffic.tcl-n指定参与的节点数-t指定流量结束时间。生成的 traffic.tcl 里包含多条 UDP 流每条流从随机源节点到随机目的节点。移动场景和流量都准备好后在你的主仿真脚本里按下面顺序 source 这两个文件source scen.tcl source traffic.tcl我常用的做法是写一个外层 shell 循环同一组参数跑 10 个不同随机种子每个种子生成独立的 trace 文件再用第 4.2 节的 awk 统计出端到端吞吐、平均延迟和丢包率最后取平均画曲线。这样产出的数据才有统计意义单次仿真结果在论文里基本没有说服力。对照组之间只改路由协议其他参数保持一致这也是 NS-2 时代复现研究的标准纪律。说回安装本身。我最早拿到 ns-allinone-2.26 是在一台 64 位新机器上gcc 版本很新我在 otcl、tclcl、nam 三个组件上轮流翻车整整折腾了两天才把环境跑通。后来养成的习惯是解压后先看编译器版本再决定是直接./install还是换 gcc-4.8 环境装完先 validate 再写自己的脚本。这套流程用顺手之后从拿到 tar.gz 到跑出第一份实验数据压缩到半天以内完全可行。这个包虽然老但它文档齐全、依赖自包含、复现性极强只要把环境关卡把住它依然是做网络协议对比实验最省心的选择。希望帮到你。本文还有配套的精品资源点击获取
