Ns-3 - Is it a Network Simulator or a Network Simulation Library?

[Charles Pandian]

Mr. Tom and all,

Sorry.
Because of my decade-old confusion in this regard, I am making it a separate topic here.

Your authentic answers will give me justifications to understand it correctly.

Reference: What Makes ns-3 a Complex Thing to Understand and Use? 

------------------------

I take no offense at what you wrote.

 

First of all I thank you for understanding my concerns regarding these "understanding issues" on ns-3.

Please keep in mind that the simulator is really a set of shared libraries that are less frequently compiled.  I am not sure that calling every simulation script a separate 'simulator' is a helpful way to put it.

 

I'm sorry but I do not really understand the emphasis here on whether or not to call ns-3 or its programs a simulator. 

 Conventionally, If we compile code, it will generate a binary. The binary is the final product that can be called as an "Application/Software" from the user's perspective.

So, for example. in the case of ns-2, if we compile it, then it will create a binary 'ns' that binary is the simulator that will run a simulation like

$ ns  example.tcl 
Here the example.tcl is the simulation script and ns is the simulator that is going to simulate it.

Another example is if we compile the code of NetAnim, we will get a final binary "NetAnim" that can be called as an "Application/Software" from the user's perspective.

But, I think, in the case of ns-3, you will not have a separate, "runnable" simulator binary - of course, all the compiled components of ns-3 will be in binary form - but not runnable separately as in the case of ns-2's ns or NetAnim.

So, if we write a simulation script using ns-3 conventions and using ns-3 library modules, and compile it as follows:

./waf --run example  
Then it will compile the simulation script "example.cc" and run the code from the main() function of example.cc.

As per my understanding, the core scheduler itself becoming part of my code example.cc and called from within the binary of example.cc and scheduling the events that are referred in example.cc - since it is only having the entry point main() -  am I wrong?

So, from my point of view (or from an end-user perspective), the binary of example.cc  is the final product after compilation - so it is the standalone simulator that will run as a separate process and will interpret the lines from with in the main() function of it.

That's why I am understanding each and every binary of my ns-3 simulation scripts as separate versions of simulator (which are built on the shared libraries of ns-3 modules)

If we do a UWNS simulation using a ns-3 simulation script, then the resultant binary is an UnderwaterNetworkSimulator.
Like that if we do a VANET simulation another a ns-3 simulation script, then the resultant binary will become a FANET simulator.

Because we chan change the behaviour of these "simulators" by passing different values/parameters through the mechanism basically ns-3 is providing.

Do I miss something here? 
Is there any other main() function from which ns-3 is running my compiled binary of example.cc?

Please explain it.

Where is the binary of the simulator ns-3 so that it can be called a standalone application? (as in the case of ns-2 - of course, I understand ns-3 is not the next version of ns-2 - and entirely different thing)

The above question is one of my mind-itching questions from the first release of ns-3.
In fact, this question only delayed my practical use of ns-3 for more than 10 years (trust me - it is true).
After abstractly understanding this fact only, I started to use ns-3 without any hesitation.

I am having a different opinion on some of your points in the reply (of What Makes ns-3 a Complex Thing to Understand and Use? ) - but they are not important - And I may discuss them later.

Charles Pandian,

[igs...@gmail.com]

This question is important because, where I  first tried to compile the very first release of ns-3, after compiling it I searched for a simulator.
Because, in my previous experience with open source and non-free  simulators, I found one such simulator in them after installing or compiling them.

source   -      binary
-------------------------------------
ns-2  ->             ns
Omnet++ ->    omnetpp
Opent  ->         opnet  (? - forgot the  name of the binary  because, nowadays, I am using only open source simulators)
...              ->          ...

----------------------------------------

After compiling ns-3 for first time, I didn't able to find one such  simulator to do simulations. It was a great disappointment to me at that time  :-)) 
I was continuously trying to understand the 'simulator' in 'ns-3 code'.
But only after a decade, I realized that, the  simulation itself becoming the simulator. (from my perspective)

That is why this is a serious question here to understand ns-3  (at least for a beginner like me who had experience with some other simulators)

I hope that you will understand this.

[Gabriel]

You seem to be confused about the lack of an executable that runs the simulation. 

The essential simulator components of ns-3 are in the core library.

 It doesn't have a main, but a start, stop and destroy. 

The simulators you mention parse the simulation file and then call essentially their versions of schedule, start, stop and destroy. 

So you're really pointing to a parser of the simulation and not the simulator itself. 

You can setup a simulation parser in c++ to read parameters from a json/yaml/TCL file and schedule the appropriate events, compile it and call it ns3. It doesn't make it a simulator, since it doesn't implement the simulator components, just call them. 

[Tom Henderson]

On 11/23/21 10:46 PM, igs...@gmail.com wrote:
> This question is important because, where I  first tried to compile the
> very first release of ns-3, after compiling it I searched for a simulator.
> Because, in my previous experience with open source and non-free
> simulators, I found one such simulator in them after installing or
> compiling them.
>
> source   -      binary
> -------------------------------------
> ns-2  ->             ns
> Omnet++ ->    omnetpp
> Opent  ->         opnet  (? - forgot the  name of the binary  because,
> nowadays, I am using only open source simulators)
> ...              ->          ...
> ----------------------------------------
>
>
> After compiling ns-3 for first time, I didn't able to find one such
> simulator to do simulations. It was a great disappointment to me at that
> time  :-))
> I was continuously trying to understand the 'simulator' in 'ns-3 code'.
> But only after a decade, I realized that, the  simulation itself
> becoming the simulator. (from my perspective)
>
> That is why this is a serious question here to understand ns-3  (at
> least for a beginner like me who had experience with some other simulators)
>
> I hope that you will understand this.
>

OK, I understand better now where your concern arises. I will try to
update the tutorial to clarify this. Something like:

"Readers may be familiar with other simulators that are compiled into an
executable that is invoked with a second file interpreted by the
simulator and that contains the configuration. For example, in ns-2:

./ns simple.tcl

ns-3 is not compiled into a generic executable that interprets
configuration files, such as the above. Instead, ns-3 is made up of
shared libraries that are later linked to a different executable
(containing configuration) that the user creates. The libraries are
modular and typically can be found in the 'build/lib' directory. The
essential library to include is 'core' since that has the implementation
of running and stopping the simulator's event scheduler, but other
libraries can be added depending on the functionality needed. The user
would then write a 'simple.cc' program with a main() function and
compile and link it to the necessary ns-3 libraries, and then call the
'simple' executable directly. If desired, the 'simple.cc' can be
further configured to accept command-line arguments and to read
configuration files so that changes to the parameterization of the
program do not require recompilation and relinking.

In summary, in a simulator like ns-2, the step of running the simulation
such as:

./ns simple.tcl [... optional arguments]

looks like the following in ns-3 (making use of a script named 'ns3'):

./ns3 --run 'simple [... optional arguments]'

or when no options are present:

./ns3 --run simple"

What do you think; does it help?

The above explanation is how it is planned to work when we convert to
CMake; with the current code and Waf, one would instead run:

./waf --run simple

- Tom

[Charles Pandian]

Mr. Tom,
As usual, you are the one that correctly understanding the issue and its magnitude.

Strictly speaking, ns-3 is not a standalone network simulator (even though it has everything in it) - is just a state-of-the-art Network Simulator Library.

In fact, I understand what is ns-3 after 10 years of a vague confusion and struggle (because, I really searched for a runnable binary in the default installation).
So, while a simulation script is using this library, after that only a simulator will born.

You may elaborately  explain the difference between ns-3 and other simulator. But before doing that, you must simply define it something like the following to any further confusion for people like me.

-------------------------------------------
1) Unlike other simulators, ns-3  is an advanced Simulator/Simulation Library. Because ns-3 doesn't have a standalone runnable binary. Explicitly saying, ns-3 is a network Simulation/Simulator library version 3.  (you decide which is technically correct to say at this point Simulation/Simulator of let it be both)

2) All the typical simulator core functionalities (including scheduler and other things -correct this)  as well the basic & advanced networking related  functionalities were implemented as shared library modules in 'ns-3 library package(?)'.

3) To get a runnable simulator, we have to write a simulation script (Test1.cc) using the both  simulator core libraries and network related libraries along with our own custom simulation descriptions.

4) If we compile the simulation script (Test1.cc), then the final binary that contains simulator core, will schedule the events to run the descriptions that we organized in our simulation script (using the referenced network functionalities). 

5. So the final binary that we got here will be our customized simulator called  Test1  that will (only can) do things according to our simulation descriptions using the ns-3 library.

-----------------------------------
6) We can add other contributed ns-3 libraries/models from ns-3 app store and other internet sources to extend the functionality of our simulations (Test1.cc).
For example, if we will need some advanced 5G related network functionalities, we may use contributed ns-3 libraries/models such as mmWave.

Explanation for point (3)

for example, if we write a (simulation) script "test.cc"

main() {

std::cout<<"testing 123";

}

and compile it and run it as follows :

./waf --run test,

Then it will not be "Network Simulation" because, we are not having any networking functionalities here.
So, a simulation script can be called as a Network Simulation script, if and only  if  it is using the Simulator core libraries and some Networking related libraries in and organized manner. So, here, test.cc is definitely not a simulation script.

Note:
Mr. Tom, after continuously using ns-3 for more than a decade. Almost, the first 10 years I really do not know what it is -I just dropped it by  saying " சீ சீ இந்தப்பழம் புளிக்கும்" TAMIL -meaning  I don't need any sour grapes   So, I dropped ns-3 like that fox.

In fact, there were two reasons for this; the first and main reason is I could not find a simulator binary in it and the second reason was, ns-3's immaturity at that time (at that time ns-3 did not have that many protocols implemented in it like ns-2)

What I said is truly my mental picture of ns-3 (after several years of effort towards understanding it correctly).
So, if you think that my convention will be useful for other to understand ns-3 in a better way, then you must even simply the above 6 point and give it as a brief  introduction of ns-3. My request is you please try to correct the technical quality and most importantly try to reduce the number of words in those 6 lines.

After that 5 or 6 line, you may elaborately explain it with illustrations. It may save few years for someone like in future to completely understand what is ns-3.

If you wish to share your views on this , I am waiting to hear it.

Charles Pandian,

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/e657b4d2-306d-444a-f825-fa25e6c20d1e%40tomh.org.

[igs...@gmail.com]

 A small correction in my previous reply :
3) To get a runnable instance of simulator, we have to write a simulation script (Test1.cc) using the both  simulator core libraries and network related libraries along with our own custom simulation descriptions.

[igs...@gmail.com]

Sorry. Another correction in my point  5 of my previous reply
5. So the final binary that we got here will be our customized simulator (/Simulator Instance) called  Test1  that will (only can)do things according to our simulation descriptions using the ns-3 library.

On Thursday, November 25, 2021 at 1:13:08 AM UTC+5:30 Tom Henderson wrote: