NS by Example 笔记（11）Add New Application and Agent

Add New Application and Agent

(Tested with ns-2.1b8a, ns-2.1b9a and ns-2.26)

 

 

目标 Objective

建立一个运行在UDP连接上的多媒体应用， 它模拟了一个虚构的多媒体应用的行为， 这个应用实现了5种媒体缩放比率（"five rate media scaling"）为的是通过改变编码和传输策略（与比例参数的值有关）来回应网络拥挤。

 

 

应用程序描述 Application Description

在应用中假设当连接建立时， 发送者和接收者同意5种不同的编码和传输策略(encoding and transmission policy pairs)， 并赋给他们5个标度值scale values (0-4)。 为了简化问题， 假设每个编码和传输策略是恒定的传输比率， 并且使用相同大小的数据包无论使用那种编码方案（encoding scheme）。 

 

基本上， "five rate media scaling"做以下工作。 发送者起始于标度为0的传输比率， 并改变传输比率根据接收者提供（notifies）的标度值。 接收者负责监听网络拥挤和决定标度因素scale factor。 对于拥挤的监听， 使用一个简单的周期性的(for every RTT往返时间 second)数据包丢失监听， 而且甚至把一个数据包每个周期都丢失视为网络拥挤。 如果发现拥挤， 接收者减少标度参数到原来的一半并通知发送者这个值。 如果没有发现丢包现象， 接收者则增加一个值给标度参数并通知发送者。

 

 

 

问题分析 Problem Analysis

在实现这个应用前， 先检查UDP的实现。 自从分配了UDP代理和发送网络数据包后， 所有的应用层通信的信息应该作为数据流被UDP代理处理。 然而， UDP分配的数据包只有header stack栈。 因此， 需要改变UDP的实现， 加入发送从应用程序中收到的数据的机制。 这个应用可能还被用于IP router queue management mechanisms。 因此， 我们需要区分这个类型的多媒体流和其他类型的数据流。 我们还需要修改UDP代理去记录数据类型到IP header的其中一项里。  

 

 

注意版本 Note on NS Versions

The locations of C++ source files in NS version 2.1b9a are slightly changed from 2.1b8a. In ns-2.1b9a, C++ source files are categorized and placed in sub-directories under the main ns-2 directory. For example, "packet.h" to "common/packet.h", "agent.h" to "common/agent.h" and "app.h" is moved to "apps/app.h". However, the locations of OTcl files are same as before ("tcl/lib/ns-packet.tcl", "tcl/lib/ns-default.tcl" and etc.)

 

 

 

设计与实现 Design and Implementation

应用程序中， 我们使用到CBR的实现并修改它去具有"five level media scaling"功能。检阅C++ class等级结构，然后命名这个应用的类为"MmApp"并作为的"Application"子类去实现。 对应的OTcl等级结构中的名字是 "Application/MmApp"。 应用中发送者和接收者的行为一起在"MmApp"中实现。 把修改后且支持"MmApp"的UDP代理命名为"UdpMmAgent"并并作为的"UdpAgent"子类。 对应的OTcl等级结构中的名字是"Agent/UDP/UDPmm"

• MmApp Header: 对于应用层的通信， 在C++文件"hdr_mm"定义结构命名的一个报头（define a header of which the structure named in C++ "hdr_mm"）。 无论何时应用程序传输信息， 它将提交到"UdpMmAgent"以"hdr_mm"的结构格式。 然后， "UdpMmAgent"分配一个或多个数据包(根据模拟的数据包大小而定)并给每个包的多媒体报头写入数据。 Figure 23 表示了报头的定义， 在这里面报头的结构和报头类的对象"MultimediaHeaderClass"（继承于"PacketHeaderCalss"）被定义。 在定义这个类时， 可以看到报头的OTcl名 ("PacketHeader/Multimedia")和定义好的报头结构的大小。 bind_offset() 必须在类的构造函数中调用。

  
  
   
  Figure 23. MM Header Structure & Class (in "udp-mm.h" & "udp-mm.cc")

  
  

  
  
   
  Figure 24 (a). Add to the "packet.h" file (C++)

  
  
   
  Figure 24 (b). Add to the "ns-packet.tcl" file (Otcl)

  我们还计入几行代码到packet.h和ns-packet.tcl文件， 见Figure 24 (a)和(b)中加入我们的"Mulltimedia"报头 到header stack。 到这里， 报头的建立已经完成， "UdpMmAgent"可以访问新的报头通过调用hdr_mm::access()这个成员函数。 详见NS Manual中报头建立和访问方法。 其余的程序和对UDP代理修改的描述参考"mm-app.h", "mm-app.cc", "udp-mm.h" and "udp-mm.cc"文件。 
   
• MmApp Sender: 发送者使用一个计时器来安排发送下一个程序数据包的时间。 定义"SendTimer" 类（继承于"TimerHandler"类）， 并编写 它的成员函数"expire()"去调用"MmApp"对象的成员函数"send_mm_pkt()"。 然后， 引入这个"SendTimer" 对象的实例作为"MmApp"对象的私有成员并引用到"snd_timer_"。 Figure 25 "SendTimer" implementation。

  
  
   
  Figure 25. SendTimer Implementation.

  在设置这个计时器timer前， "MmApp"使用当前标度值的传输比率和应用程序数据包的大小（模拟脚本中定义的或默认的大小）来重新计算下一个传输时间。 "MmApp" 发送者一旦接收到接收端发来的ACK application packet， 就去更新标度参数。  
   
• MmApp Receiver: 接收者使用名叫"ack_timer_"的计时器去安排下一个间隔时间等于平均RTT的application ACK packet的发送。 当从发送者那里收到一个数据包， 接收者计算收到的包的数量和丢包的数量通过数据包的序号sequence number。 当"ack_timer_"期满时， 调用"MmApp"的成员函数"send_ack_pkt"， 它根据收到和丢失数据包的accounting信息来调整标度值，重置received和lost count 为0， 并发出一个含有调整后的标度值ACK packet。 这里要注意， 接收者没有任何建立和关闭连接的方法。 因此， 自从第一个数据包到达，接收者就周期性地发出ACK packets并重不停止(这是个BUG).
   
• UdpMmAgent: "UdpMmAgent"是由"UdpAgent"修改得来并具有以下附加功能: (1) 把从"MmApp"收到的信息写入发送数据包的MM报头（或从收到数据包的MM报头读取信息并提交给"MmApp"）， (2) 分割（segmentation）和重组（re-assembly） ("UdpAgent"只实现了分割)， 和 (3) 为"MmApp"数据包设置优先级位（priority bit） (IPv6) to 15 (max priority)。 
   
• Modify "agent.h": 为了让新的程序和代理在NS中运行， 应该给"Agent"类加入2个公共方法。  在"MmApp"类的成员函数"command"中定义一个名为"attach-agent"的OTcl命令。 当从OTcl收到这个命令时， "MmApp"尝试把它自己附加到底层的代理(underlying agent )上。 在附加前， 它调用底层代理的成员函数"supportMM()"去检查是否底层代理支持多媒体传输multimedia transmission (i.e. 它是否能够携带数据从一个应用程序到另一个)， 并且如果可以传输的话就调用"enableMM()"。 尽管在"UdpMmAgnet"类中定义了这2个成员函数， 而没有在它的基类"Agent"中定义， 并且是在常用的"Agent"类的这两个成员函数被调用到。Even though these two member functions are defined in the "UdpMmAgnet" class, it is not defined in its base ancestor "Agent" class, and the two member functions of the general "Agent" class are called. 因此， 当尝试去编译代码时，会收到报错信息。 把这两个方法method做为"Agent"类的公共的成员函数加入到"agent.h"去解决这个问题。

  
  
   
  Figure 26 (a). Add two member functions to "Agent" class.

• Modify "app.h": 添加一个成员函数"recv_msg(int nbytes, const char *msg)"到"Application"类， 见Figure 26 (b)。 在旧版本的NS(ns-2.1b4a)这个成员函数包含在"Application"类中，但在新版本中被移除(ns-2.1b8a)。 Our multimedia application was initially written for the ns-2.1.b4a, and therefore requires "Application::recv_msg()" member function for ns-2.1b8a or later versions.

  
  
   
  Figure 26 (b). Add a member function to "Application" class.

• Set default values for new parameter in the "ns-default.tcl": 在实现了应用程序和代理的所有部件后， 最后要做的就是为新加入的可配置参数设置默认值在"ns-default.tcl"文件中。  Figure 26 展示了为"MmApp"引入的可配置参数设置默认值的例子。

  
  
   
  Figure 27. Default parameter value settings

Download and Compile

在重新编译NS前先核对以下几项。

1. 下载 "mm-app.h", "mm-app.cc", "udp-mm.h" and "udp-mm.cc"(打包在附件的source code.zip)到"ns-2"文件夹。
2. 确定已经注册了新的application header通过修改"packet.h" and "ns-packet.tcl" 如同所示在Figure 24 (a)和(b)。
3. 添加supportMM()和enableMM()方法到"Agent"类在"agent.h"中，见Figure 26 (a)。
4. 添加recv_msg()方法到"Application"类在"app.h"中，见Figure 26 (b)。
5. 为在"ns-default.tcl"文件中新加入的可配置参数设置默认值， 见Figure 27。 一定要完成最后一步， 否则所有的five-scale rates都初始化为零，除非在模拟脚本中指定(i.e. 后面给出的测试模拟的脚本没有传输任何frames).

 

 

完成以上内容后， 修改"Makefile"如果需要的话(把"mm-app.o"和"udp-mm.o"加入到object file list) 并重新编译NS。 在重新编译前一定要运行"make clean"和"make depend"， 否则新的应用程序不能传输任何数据包。 良好的习惯做法是在改动"Makefile"后就运行"make depend"，然后再去重新编译re-compile。

Test Simulation

Figure 28 演示了用来测试"MmApp"的模拟拓扑和场景， 而Figure 29 是test simulation script （见附件ex-mm-app.zip）.

 
Figure 28. Test Simulation Topology and Scenario

 

Figure 29. "MmApp" Test Simulation Script