ns-3技术手册：深入理解网络模拟器

需积分: 9 11 浏览量更新于2024-07-20 收藏 1013KB PDF 举报

"ns-3的手册，包含了ns-3项目的详细技术信息，包括ns-3 Manual Release 3.25的各个章节，如随机变量、哈希函数、事件与模拟器、回调、对象模型、配置与属性、对象命名、日志、追踪、数据收集、统计框架、实时性、助手类、Gnuplot绘图、Python运行ns-3、测试以及支持等内容。" ns-3是一个开源的离散事件网络模拟器，它提供了丰富的网络协议和模型，广泛用于学术研究和教学。ns-3手册是该项目的主要文档之一，旨在帮助用户理解和使用这个强大的工具。 1. **组织结构**： ns-3软件的组织结构被清晰地划分，手册也相应地进行了编排。这包括模拟器的公共API的Doxygen文档、教程、最新版本和开发树的模型库，以及ns-3 wiki等资源。 2. **随机变量**：在ns-3中，随机变量用于模拟网络中的各种不确定行为，如数据包的到达时间、传输速率等。手册详细介绍了如何创建和使用这些随机变量。 3. **哈希函数**：哈希函数在ns-3中可能用于快速查找或数据处理。手册会阐述它们在模拟环境中的应用。 4. **事件和模拟器**： ns-3使用事件驱动的模拟机制，事件调度器管理所有的模拟事件。这部分会解释如何创建和调度事件，以及模拟器的工作原理。 5. **回调**：回调函数是ns-3中实现模块间交互的关键，允许在特定条件下执行自定义代码。手册将详细讲解如何设置和使用回调。 6. **对象模型**： ns-3基于C++的对象模型设计，包括继承、多态性和封装。手册会介绍如何创建和使用自定义的网络组件。 7. **配置和属性**：用户可以通过属性系统来配置模拟参数。手册会展示如何设置和查询对象属性。 8. **对象命名**：对象命名系统方便在模拟中引用和查找特定对象，对于管理和调试非常重要。 9. **日志和追踪**：日志用于记录模拟过程中的信息，追踪则允许用户指定感兴趣的数据进行跟踪。这部分会讲解如何启用和配置日志和追踪功能。 10. **数据收集和统计框架**：提供了机制来收集和分析模拟结果，如统计框架，有助于理解和优化模拟性能。 11. **实时性**：针对实时模拟场景，手册将说明如何在ns-3中实现。 12. **助手类**：助手类简化了常见网络配置，例如节点、链路和协议的设置。 13. **使用Gnuplot绘图**：手册包含如何利用内置的Gnuplot支持生成模拟结果的图形表示。 14. **使用Python运行ns-3**： ns-3支持使用Python脚本进行控制和数据分析，这部分会指导用户如何操作。 15. **测试**：提供了一套测试框架来验证模型的正确性，手册会讲解如何编写和执行测试用例。 16. **支持**：最后，手册还提供了获取帮助和支持的信息，包括社区资源和问题解决策略。这个手册全面覆盖了ns-3的各个方面，对于任何想要学习和使用ns-3的人来说，都是一份宝贵的参考资料。

ns-3 Manual, Release ns-3.25

These functions are declared and implemented as C++ templates to handle automatically the wide variety of C++ event

handler signatures used in the wild. For example, to schedule an event to execute 10 seconds in the future, and invoke

a C++ method or function with speciﬁc arguments, you might write this:

void handler (int arg0, int arg1)

{

std::cout << "handler called with argument arg0=" << arg0 << " and

arg1=" << arg1 << std::endl;

}

Simulator::Schedule(Seconds(10), &handler, 10, 5);

Which will output:

handler called with argument arg0=10 and arg1=5

Of course, these C++ templates can also handle transparently member methods on C++ objects:

To be completed: member method example

Notes:

• the ns-3 Schedule methods recognize automatically functions and methods only if they take less than 5 argu-

ments. If you need them to support more arguments, please, ﬁle a bug report.

• Readers familiar with the term ‘fully-bound functors’ will recognize the Simulator::Schedule methods as a way

to automatically construct such objects.

2. Common scheduling operations

The Simulator API was designed to make it really simple to schedule most events. It provides three variants to do so

(ordered from most commonly used to least commonly used):

• Schedule methods which allow you to schedule an event in the future by providing the delay between the current

simulation time and the expiration date of the target event.

• ScheduleNow methods which allow you to schedule an event for the current simulation time: they will execute

_after_ the current event is ﬁnished executing but _before_ the simulation time is changed for the next event.

• ScheduleDestroy methods which allow you to hook in the shutdown process of the Simulator to cleanup simu-

lation resources: every ‘destroy’ event is executed when the user calls the Simulator::Destroy method.

3. Maintaining the simulation context

There are two basic ways to schedule events, with and without context. What does this mean?

Simulator::Schedule (Time const &time, MEM mem_ptr, OBJ obj);

vs.

Simulator::ScheduleWithContext (uint32_t context, Time const &time, MEM mem_ptr, OBJ obj);

Readers who invest time and effort in developing or using a non-trivial simulation model will know the value of the

ns-3 logging framework to debug simple and complex simulations alike. One of the important features that is provided

by this logging framework is the automatic display of the network node id associated with the ‘currently’ running

event.

The node id of the currently executing network node is in fact tracked by the Simulator class. It can be accessed with

the Simulator::GetContext method which returns the ‘context’ (a 32-bit integer) associated and stored in the currently-

executing event. In some rare cases, when an event is not associated with a speciﬁc network node, its ‘context’ is set

to 0xffffffff.

12 Chapter 1. Contents

ns-3 Manual, Release ns-3.25

To associate a context to each event, the Schedule, and ScheduleNow methods automatically reuse the context of the

currently-executing event as the context of the event scheduled for execution later.

In some cases, most notably when simulating the transmission of a packet from a node to another, this behavior is

undesirable since the expected context of the reception event is that of the receiving node, not the sending node. To

avoid this problem, the Simulator class provides a speciﬁc schedule method: ScheduleWithContext which allows one

to provide explicitly the node id of the receiving node associated with the receive event.

XXX: code example

In some very rare cases, developers might need to modify or understand how the context (node id) of the ﬁrst event

is set to that of its associated node. This is accomplished by the NodeList class: whenever a new node is created,

the NodeList class uses ScheduleWithContext to schedule a ‘initialize’ event for this node. The ‘initialize’ event thus

executes with a context set to that of the node id and can use the normal variety of Schedule methods. It invokes

the Node::Initialize method which propagates the ‘initialize’ event by calling the DoInitialize method for each object

associated with the node. The DoInitialize method overridden in some of these objects (most notably in the Application

base class) will schedule some events (most notably Application::StartApplication) which will in turn scheduling

trafﬁc generation events which will in turn schedule network-level events.

Notes:

• Users need to be careful to propagate DoInitialize methods across objects by calling Initialize explicitely on

their member objects

• The context id associated with each ScheduleWithContext method has other uses beyond logging: it is used by

an experimental branch of ns-3 to perform parallel simulation on multicore systems using multithreading.

The Simulator::* functions do not know what the context is: they merely make sure that whatever context you specify

with ScheduleWithContext is available when the corresponding event executes with ::GetContext.

It is up to the models implemented on top of Simulator::* to interpret the context value. In ns-3, the network models

interpret the context as the node id of the node which generated an event. This is why it is important to call Sched-

uleWithContext in ns3::Channel subclasses because we are generating an event from node i to node j and we want to

make sure that the event which will run on node j has the right context.

1.4.3 Time

To be completed

1.4.4 Scheduler

To be completed

1.5 Callbacks

Some new users to ns-3 are unfamiliar with an extensively used programming idiom used throughout the code: the

ns-3 callback. This chapter provides some motivation on the callback, guidance on how to use it, and details on its

implementation.

1.5.1 Callbacks Motivation

Consider that you have two simulation models A and B, and you wish to have them pass information between them

during the simulation. One way that you can do that is that you can make A and B each explicitly knowledgeable

about the other, so that they can invoke methods on each other:

1.5. Callbacks 13

ns-3 Manual, Release ns-3.25

The basic mechanism that allows one to address the problem above is known as a callback. The ultimate goal is to

allow one piece of code to call a function (or method in C++) without any speciﬁc inter-module dependency.

This ultimately means you need some kind of indirection – you treat the address of the called function as a variable.

This variable is called a pointer-to-function variable. The relationship between function and pointer-to-function pointer

is really no different that that of object and pointer-to-object.

In C the canonical example of a pointer-to-function is a pointer-to-function-returning-integer (PFI). For a PFI taking

one int parameter, this could be declared like,:

int (

pfi)(int arg) = 0;

What you get from this is a variable named simply pfi that is initialized to the value 0. If you want to initialize this

pointer to something meaningful, you have to have a function with a matching signature. In this case:

int MyFunction (int arg) {}

If you have this target, you can initialize the variable to point to your function like:

pfi = MyFunction;

You can then call MyFunction indirectly using the more suggestive form of the call:

int result = (

pfi) (1234);

This is suggestive since it looks like you are dereferencing the function pointer just like you would dereference any

pointer. Typically, however, people take advantage of the fact that the compiler knows what is going on and will just

use a shorter form:

int result = pfi (1234);

Notice that the function pointer obeys value semantics, so you can pass it around like any other value. Typically, when

you use an asynchronous interface you will pass some entity like this to a function which will perform an action and

call back to let you know it completed. It calls back by following the indirection and executing the provided function.

In C++ you have the added complexity of objects. The analogy with the PFI above means you have a pointer to a

member function returning an int (PMI) instead of the pointer to function returning an int (PFI).

The declaration of the variable providing the indirection looks only slightly different:

int (MyClass::

pmi) (int arg) = 0;

This declares a variable named pmi just as the previous example declared a variable named pfi. Since the will be to

call a method of an instance of a particular class, one must declare that method in a class:

class MyClass {

public:

int MyMethod (int arg);

};

Given this class declaration, one would then initialize that variable like this:

pmi = &MyClass::MyMethod;

This assigns the address of the code implementing the method to the variable, completing the indirection. In order to

call a method, the code needs a this pointer. This, in turn, means there must be an object of MyClass to refer to. A

simplistic example of this is just calling a method indirectly (think virtual function):

1.5. Callbacks 15

ns-3 Manual, Release ns-3.25

int (MyClass::

pmi) (int arg) = 0; // Declare a PMI

pmi = &MyClass::MyMethod; // Point at the implementation code

MyClass myClass; // Need an instance of the class

(myClass.

pmi) (1234); // Call the method with an object ptr

Just like in the C example, you can use this in an asynchronous call to another module which will call back using a

method and an object pointer. The straightforward extension one might consider is to pass a pointer to the object and

the PMI variable. The module would just do:

(

objectPtr.

pmi) (1234);

to execute the callback on the desired object.

One might ask at this time, what’s the point? The called module will have to understand the concrete type of the calling

object in order to properly make the callback. Why not just accept this, pass the correctly typed object pointer and

do object->Method(1234) in the code instead of the callback? This is precisely the problem described above.

What is needed is a way to decouple the calling function from the called class completely. This requirement led to the

development of the Functor.

A functor is the outgrowth of something invented in the 1960s called a closure. It is basically just a packaged-up

function call, possibly with some state.

A functor has two parts, a speciﬁc part and a generic part, related through inheritance. The calling code (the code that

executes the callback) will execute a generic overloaded operator () of a generic functor to cause the callback to

be called. The called code (the code that wants to be called back) will have to provide a specialized implementation

of the operator () that performs the class-speciﬁc work that caused the close-coupling problem above.

With the speciﬁc functor and its overloaded operator () created, the called code then gives the specialized code

to the module that will execute the callback (the calling code).

The calling code will take a generic functor as a parameter, so an implicit cast is done in the function call to convert the

speciﬁc functor to a generic functor. This means that the calling module just needs to understand the generic functor

type. It is decoupled from the calling code completely.

The information one needs to make a speciﬁc functor is the object pointer and the pointer-to-method address.

The essence of what needs to happen is that the system declares a generic part of the functor:

template <typename T>

class Functor

{

public:

virtual int operator() (T arg) = 0;

};

The caller deﬁnes a speciﬁc part of the functor that really is just there to implement the speciﬁc operator() method:

template <typename T, typename ARG>

class SpecificFunctor : public Functor<ARG>

{

public:

SpecificFunctor(T

p, int (T::

_pmi)(ARG arg))

{

m_p = p;

m_pmi = _pmi;

}

virtual int operator() (ARG arg)

{

16 Chapter 1. Contents

剩余164页未读，继续阅读

lmfreeking

粉丝: 16
资源: 8

ns-3技术手册：深入理解网络模拟器

ns-3 教程+手册（tutorial+manual）

ns-3-manual.pdf

ns3-manual

NS-3 v2p relay

怎么在ubuntu中卸载ns-3

你会使用ns-3进行无线网络仿真吗

ns-3 3.38如何增加自己地model

如何实现NS-3和Hyperledger Fabric联合实验？

开源网络模拟器ns-3 架构与实践 pdf下载

ns3-tutorial

最新资源