整个仿真的目的是为了进一步研究生成结果,其中NS3提供的Tracing系统就是为了这个目的而定制的。
因为NS3是由C++编写的,所以C++的标准输入输出是在NS-3中是可以用的:
#include
…
int main()
{
…
std::cout<<"The value of xis "<<x<<std::endl;
…
}
我们可以用日志模块来为我们的解决方法添加一些小结构。这种方法会产生很多已知的问题,所以我们提供了一种生成事件的tracing子系统来解决那些我们认为重要的问题。
NS3 tracing系统的基本目标是:
1.对于基本的任务,tracing系统允许用户为常用的tracing发送端生产标准的tracing,并且可以定制哪些对象生成tracing。
2.中间的用户必须能够拓展tracing系统来修改生成的输出格式,或者在不修改仿真器核心的情况下,插入新的tracing发送端。
3.高级用户可以修改仿真器核心来增加新的tracing发送端和接收端。
NS3tracing系统是建立在独立的tracing发送端和接收端概念上,并且有统一的机制来连接发送端和接收端。Trace发送端可以在仿真过程中产生信号事件,并且提供有关数据访问通道。例如,一个trace发送端可以提供一个数据包被一个网络设备接收的时间,并且根据接收端的要求提供此数据包的内容。
Trace发送端自身是没用的,必须和接收端提供的有用信息代码段“相连”。Trace接收端是trace发送端提供的事件和时间的使用者。例如,可以创建一个可以输出数据包有用信息的trace接收端(当连接到之前例子中的trace发送端)。
这种发送端和接收端明确分工的基本原理是允许用户将已有的发送端与新类型的接收端相连,而不需要编辑和重新编译仿真器的核心。因此,上面的例子中,用户可以在他的脚本中定义一个新的tracing接收端,并且可以将其与与仿真核心中第一的tracing接收端相连。
NS3提供两种tracing机制:ASCII码tracing和pcap级别的tracing。
一.ASCII码Tracing
NS3提供了封装底层tracing系统的helper功能,用来提供配置简单数据包的更多细节。如果你使用了这个功能,将在ASCII文件中输出结果——这就是为什么这种tracing得名ASCIItracing。对于熟悉NS2的用户,这种trace与out.tr相似。
让我们在first.cc脚本中添加ASCIItracing输出。
首先,在Simulator::Run()前,添加下面的代码:
AsciiTraceHelperascii;
pointToPoint.EnalbeAsciiAll(ascii.CreateFileStream("first.tr"));
//CreateFileStream()用未命名的对象在协议栈中创建了一个文件流,并把这个文件流传递给了调用方法,即创建了一个对象代表着一个名为“first.tr”的文件,并传递给了NS3。
//EnableAsciiAll()告诉helper你想要将ASCIItracing安装在仿真中的点到点设备上,并且你想要接收端以ASCII格式写出数据包移动信息。
这两行代码用来打开一个将被写入名为“first.tr”文件中的数据流。代码段中的第二行告诉NS3在仿真中为所有点到底设备启用ASCIItracing功能,并且你想要用ASCII格式来写出数据流中数据包的移动信息。类似于NS2中,trace事件和一般的trace“+”、“-”、“d”、“r”事件。
编译并运行脚本,可以看到编译成功的信息。
此时,程序将创建一个名为“first.tr”的文件。由于Waf的工作方式,这个文件将不在本地目录下创建,而是在NS3根目录中创建。
结果中的每一行对应了一个trace事件。本例中,我们查看每个点到点设备的传输队列的trace事件。传输队列是任意目的地为点到点信道的数据包必经的队列。注意!trace文件的每一行都以一个单独的字符开始(后面带有空格)。这些字符具有如下含义:
+ :设备队列中的入队操作;
- :设备队列中的出队操作;
d :数据包被丢弃,通常是因为队列已满;
r
我们来详细看第一行,为了看得清楚,我把这一行分为不同的部分,并在左边标出了序号:
1. +
2. 2
3. /NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue
//入队操作在最后部分的“tracepath”TxQueue/Enqueue中体现。
4. ns3::PppHeader(
5. Point-to-Point Protocol:IP(0x0021))
6. ns3::Ipv4Header(
7. tos 0x0 DSCP Default ECNNot-ECT ttl 64 id 0 protocol 17 offset (bytes) 0 flags[none]
8. length: 1052 10.1.1.1 >10.1.1.2)
9. ns3::UdpHeader(
10. length: 103249153>9)
11. Payload(size=1024)
在trace文件中的下一行显示这个数据包在这个节点中从传输队列中被移除。
trace文件的第三行显示了数据包正在被echo服务器所在的节点的网络设备接收。trace如下:
1. r
2. 2.00369
3. /NodeList/1/DeviceList/0/$ns3::PointToPointNetDevice/MacRx
4. ns3::PppHeader(
5. Point-to-Point Protocol:IP(0x0021))
6. ns3::Ipv4Header(
7. tos 0x0 DSCP Default ECNNot-ECT ttl 64 id 0 protocol 17 offset (bytes) 0 flags[none]
8. length: 105210.1.1.1>10.1.1.2)
9. ns3::UdpHeader
10. length: 103249153>9)
11. Payload(size=1024)
二.PCAPTracing
NS3也支持创建.pcap格式的trace文件,缩写pcap表示packetcapture,事实上是包含有定义一个.pcap文件格式的API。可以读取并且显示这种格式的程序是Wireshark。然而,有很多其他分析器也使用这个数据包格式。本例中,我们用tcpdump来查看pcaptrace。
pointToPoint.EnalbePcapAllll("first");
在first.cc中,我们刚增加的ASCIItrace代码后面插入这行代码。注意字符串是“first”,而不是“first.pcap”。这是因为这里传递的参数是个前缀,而不是完整的文件名。在仿真过程中,PointToPointHelper将为每一个点到点设备创建trace文件。文件名将包含预设前缀,节点数,设备数和".pcap"后缀。
编译运行脚本后:
会得到3个日志文件:ASCII码的trace文件:first.tr,pcap的trace文件:first-0-0.pcap,first-1-0.pcap。
first-0-0.pcap代表第0个节点的第0个设备。
用tcpdump来读pcap文件。
$ tcpdump -nn -tt -rfirst-0-0.pcap
$ tcpdump -nn -tt -rfirst-1-0.pcap
如果不是很了解Wireshark,可以通过官网获取相关信息:http://www.wireshark.org/
