F5/unison
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

doc: Update stale tutorial information

Browse Source
This commit is contained in:
Tom Henderson
2022-06-14 08:20:50 -07:00
parent bdfb10a108
commit 93c4bbd9ac
7 changed files with 396 additions and 441 deletions
Download Patch File Download Diff File Expand all files Collapse all files

222
doc/tutorial/source/building-topologies.rst
View File

@@ -335,14 +335,14 @@ the ``first.cc`` example.
}
In order to run this example, copy the ``second.cc`` example script into
the scratch directory and use ns3 to build just as you did with
the scratch directory and use the ``ns3`` build script to build just as you did with
the ``first.cc`` example. If you are in the top-level directory of the
repository you just type,
.. sourcecode:: bash
$ cp examples/tutorial/second.cc scratch/mysecond.cc
$ ./ns3
$ ./ns3 build
Warning: We use the file ``second.cc`` as one of our regression tests to
verify that it works exactly as we think it should in order to make your
@@ -351,13 +351,13 @@ tutorial experience a positive one. This means that an executable named
about what you are executing, please do the renaming to ``mysecond.cc``
suggested above.
If you are following the tutorial religiously (you are, aren't you) you will
If you are following the tutorial closely, you will
still have the NS_LOG variable set, so go ahead and clear that variable and
run the program.
.. sourcecode:: bash
$ export NS_LOG=
$ export NS_LOG=""
$ ./ns3 run scratch/mysecond
Since we have set up the UDP echo applications to log just as we did in
@@ -365,12 +365,10 @@ Since we have set up the UDP echo applications to log just as we did in
.. sourcecode:: text
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.415s)
Sent 1024 bytes to 10.1.2.4
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.2.4
At time +2s client sent 1024 bytes to 10.1.2.4 port 9
At time +2.0078s server received 1024 bytes from 10.1.1.1 port 49153
At time +2.0078s server sent 1024 bytes to 10.1.1.1 port 49153
At time +2.01761s client received 1024 bytes from 10.1.2.4 port 9
Recall that the first message, "``Sent 1024 bytes to 10.1.2.4``," is the
UDP echo client sending a packet to the server. In this case, the server
@@ -380,7 +378,7 @@ the echo packet. The final message, "``Received 1024 bytes from 10.1.2.4``,"
is from the echo client, indicating that it has received its echo back from
the server.
If you now go and look in the top level directory, you will find three trace
If you now look in the top level directory, you will find three trace
files:
.. sourcecode:: text
@@ -536,7 +534,7 @@ Finally, recall that we added the ability to control the number of CSMA devices
in the simulation by command line argument. You can change this argument in
the same way as when we looked at changing the number of packets echoed in the
``first.cc`` example. Try running the program with the number of "extra"
devices set to four:
devices set to four, instead of the default value of three (extra nodes):
.. sourcecode:: bash
@@ -546,13 +544,10 @@ You should now see,
.. sourcecode:: text
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.405s)
At time 2s client sent 1024 bytes to 10.1.2.5 port 9
At time 2.0118s server received 1024 bytes from 10.1.1.1 port 49153
At time 2.0118s server sent 1024 bytes to 10.1.1.1 port 49153
At time 2.02461s client received 1024 bytes from 10.1.2.5 port 9
At time +2s client sent 1024 bytes to 10.1.2.5 port 9
At time +2.0118s server received 1024 bytes from 10.1.1.1 port 49153
At time +2.0118s server sent 1024 bytes to 10.1.1.1 port 49153
At time +2.02461s client received 1024 bytes from 10.1.2.5 port 9
Notice that the echo server has now been relocated to the last of the CSMA
nodes, which is 10.1.2.5 instead of the default case, 10.1.2.4.
@@ -609,25 +604,36 @@ about what is going on,
.. sourcecode:: bash
$ rm *.pcap
$ rm *.tr
On line 110, notice the following command to enable tracing on one node
(the index 1 corresponds to the second CSMA node in the container):
.. sourcecode:: bash
csma.EnablePcap ("second", csmaDevices.Get (1), true);
Change the index to the quantity ``nCsma``, corresponding to the last
node in the topology-- the node that contains the echo server:
.. sourcecode:: bash
csma.EnablePcap ("second", csmaDevices.Get (nCsma), true);
If you build the new script and run the simulation setting ``nCsma`` to 100,
.. sourcecode:: bash
$ ./ns3 build
$ ./ns3 run "scratch/mysecond --nCsma=100"
you will see the following output:
.. sourcecode:: text
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.407s)
At time 2s client sent 1024 bytes to 10.1.2.101 port 9
At time 2.0068s server received 1024 bytes from 10.1.1.1 port 49153
At time 2.0068s server sent 1024 bytes to 10.1.1.1 port 49153
At time 2.01761s client received 1024 bytes from 10.1.2.101 port 9
At time +2s client sent 1024 bytes to 10.1.2.101 port 9
At time +2.0068s server received 1024 bytes from 10.1.1.1 port 49153
At time +2.0068s server sent 1024 bytes to 10.1.1.1 port 49153
At time +2.01761s client received 1024 bytes from 10.1.2.101 port 9
Note that the echo server is now located at 10.1.2.101 which corresponds to
having 100 "extra" CSMA nodes with the echo server on the last one. If you
@@ -635,17 +641,33 @@ list the pcap files in the top level directory you will see,
.. sourcecode:: text
second-0-0.pcap second-100-0.pcap second-101-0.pcap
second-0-0.pcap second-1-0.pcap second-101-0.pcap
The trace file ``second-0-0.pcap`` is the "leftmost" point-to-point device
which is the echo packet source. The file ``second-101-0.pcap`` corresponds
to the rightmost CSMA device which is where the echo server resides. You may
have noticed that the final parameter on the call to enable pcap tracing on the
echo server node was false. This means that the trace gathered on that node
was in non-promiscuous mode.
echo server node was true. This means that the trace gathered on that node
was in promiscuous mode.
To illustrate the difference between promiscuous and non-promiscuous traces, we
also requested a non-promiscuous trace for the next-to-last node. Go ahead and
To illustrate the difference between promiscuous and non-promiscuous traces,
let's add a non-promiscuous trace for the next-to-last node. Add the
following line before or after the existing PCAP trace line; the last
argument of ``false`` indicates that you would like a non-promiscuous trace:
.. sourcecode:: bash
csma.EnablePcap ("second", csmaDevices.Get (nCsma - 1), false);
Now build and run as before:
.. sourcecode:: bash
$ rm *.pcap
$ ./ns3 build
$ ./ns3 run "scratch/mysecond --nCsma=100"
This will produce a new PCAP file, ``second-100-0.pcap``. Go ahead and
take a look at the ``tcpdump`` for ``second-100-0.pcap``.
.. sourcecode:: bash
@@ -668,7 +690,9 @@ Now take a look at the ``tcpdump`` for ``second-101-0.pcap``.
$ tcpdump -nn -tt -r second-101-0.pcap
You can now see that node 101 is really the participant in the echo exchange.
Node 101 is really the participant in the echo exchange; the following trace
will exist regardless of whether promiscuous mode is set on that PCAP
statement.
.. sourcecode:: text
@@ -1190,25 +1214,22 @@ Finally, we actually run the simulation, clean up and then exit the program.
In order to run this example, you have to copy the ``third.cc`` example
script into the scratch directory and use CMake to build just as you did with
the ``second.cc`` example. If you are in the top-level directory of the
repository you would type,
repository, type the following:
.. sourcecode:: bash
$ cp examples/tutorial/third.cc scratch/mythird.cc
$ ./ns3 run scratch/mythird
$ ./ns3 run 'scratch/mythird --tracing=1'
Again, since we have set up the UDP echo applications just as we did in the
``second.cc`` script, you will see similar output.
.. sourcecode:: text
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.407s)
At time 2s client sent 1024 bytes to 10.1.2.4 port 9
At time 2.01796s server received 1024 bytes from 10.1.3.3 port 49153
At time 2.01796s server sent 1024 bytes to 10.1.3.3 port 49153
At time 2.03364s client received 1024 bytes from 10.1.2.4 port 9
At time +2s client sent 1024 bytes to 10.1.2.4 port 9
At time +2.01624s server received 1024 bytes from 10.1.3.3 port 49153
At time +2.01624s server sent 1024 bytes to 10.1.3.3 port 49153
At time +2.02849s client received 1024 bytes from 10.1.2.4 port 9
Recall that the first message, ``Sent 1024 bytes to 10.1.2.4``," is the
UDP echo client sending a packet to the server. In this case, the client
@@ -1218,7 +1239,8 @@ generated when it receives the echo packet. The final message,
"``Received 1024 bytes from 10.1.2.4``," is from the echo client, indicating
that it has received its echo back from the server.
If you now go and look in the top level directory, you will find four trace
If you now look in the top level directory, and you enabled tracing at
the command-line as suggested above, you will find four trace
files from this simulation, two from node zero and two from node one:
.. sourcecode:: text
@@ -1244,23 +1266,14 @@ You should see some wifi-looking contents you haven't seen here before:
.. sourcecode:: text
reading from file third-0-1.pcap, link-type IEEE802_11 (802.11)
0.000025 Beacon (ns-3-ssid) [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS
0.000308 Assoc Request (ns-3-ssid) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit]
0.000324 Acknowledgment RA:00:00:00:00:00:08
0.000402 Assoc Response AID(0) :: Successful
0.000546 Acknowledgment RA:00:00:00:00:00:0a
0.000721 Assoc Request (ns-3-ssid) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit]
0.000737 Acknowledgment RA:00:00:00:00:00:07
0.000824 Assoc Response AID(0) :: Successful
0.000968 Acknowledgment RA:00:00:00:00:00:0a
0.001134 Assoc Request (ns-3-ssid) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit]
0.001150 Acknowledgment RA:00:00:00:00:00:09
0.001273 Assoc Response AID(0) :: Successful
0.001417 Acknowledgment RA:00:00:00:00:00:0a
0.102400 Beacon (ns-3-ssid) [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS
0.204800 Beacon (ns-3-ssid) [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS
0.307200 Beacon (ns-3-ssid) [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS
reading from file third-0-1.pcap, link-type IEEE802_11_RADIO (802.11 plus radiotap header)
0.033119 33119us tsft 6.0 Mb/s 5210 MHz 11a Beacon (ns-3-ssid) [6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0 Mbit] ESS
0.120504 120504us tsft 6.0 Mb/s 5210 MHz 11a -62dBm signal -94dBm noise Assoc Request (ns-3-ssid) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit]
0.120520 120520us tsft 6.0 Mb/s 5210 MHz 11a Acknowledgment RA:00:00:00:00:00:08
0.120632 120632us tsft 6.0 Mb/s 5210 MHz 11a -62dBm signal -94dBm noise CF-End RA:ff:ff:ff:ff:ff:ff
0.120666 120666us tsft 6.0 Mb/s 5210 MHz 11a Assoc Response AID(1) :: Successful
...
You can see that the link type is now 802.11 as you would expect. You can
probably understand what is going on and find the IP echo request and response
@@ -1278,8 +1291,8 @@ Again, you should see some familiar looking contents:
.. sourcecode:: text
reading from file third-0-0.pcap, link-type PPP (PPP)
2.008151 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
2.026758 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
2.006440 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
2.025048 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
This is the echo packet going from left to right (from Wi-Fi to CSMA) and back
again across the point-to-point link.
@@ -1295,8 +1308,8 @@ Again, you should see some familiar looking contents:
.. sourcecode:: text
reading from file third-1-0.pcap, link-type PPP (PPP)
2.011837 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
2.023072 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
2.010126 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
2.021361 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
This is also the echo packet going from left to right (from Wi-Fi to CSMA) and
back again across the point-to-point link with slightly different timings
@@ -1314,12 +1327,12 @@ You should see some familiar looking contents:
.. sourcecode:: text
reading from file third-1-1.pcap, link-type EN10MB (Ethernet)
2.017837 ARP, Request who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1, length 50
2.017861 ARP, Reply 10.1.2.4 is-at 00:00:00:00:00:06, length 50
2.017861 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
2.022966 ARP, Request who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4, length 50
2.022966 ARP, Reply 10.1.2.1 is-at 00:00:00:00:00:03, length 50
2.023072 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
2.016126 ARP, Request who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1, length 50
2.016151 ARP, Reply 10.1.2.4 is-at 00:00:00:00:00:06, length 50
2.016151 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
2.021255 ARP, Request who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4, length 50
2.021255 ARP, Reply 10.1.2.1 is-at 00:00:00:00:00:03, length 50
2.021361 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
This should be easily understood. If you've forgotten, go back and look at
the discussion in ``second.cc``. This is the same sequence.
@@ -1395,42 +1408,41 @@ they happen.
.. sourcecode:: text
'build' finished successfully (5.989s)
$ ./ns3 build
$ ./ns3 run scratch/mythird
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10, y = 0
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.3841, y = 0.923277
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.2049, y = 1.90708
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.8136, y = 1.11368
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.8452, y = 2.11318
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.9797, y = 3.10409
At time 2s client sent 1024 bytes to 10.1.2.4 port 9
At time 2.01796s server received 1024 bytes from 10.1.3.3 port 49153
At time 2.01796s server sent 1024 bytes to 10.1.3.3 port 49153
At time 2.03364s client received 1024 bytes from 10.1.2.4 port 9
/NodeList/7/$ns3::MobilityModel/CourseChange x = 11.3273, y = 4.04175
/NodeList/7/$ns3::MobilityModel/CourseChange x = 12.013, y = 4.76955
/NodeList/7/$ns3::MobilityModel/CourseChange x = 12.4317, y = 5.67771
/NodeList/7/$ns3::MobilityModel/CourseChange x = 11.4607, y = 5.91681
/NodeList/7/$ns3::MobilityModel/CourseChange x = 12.0155, y = 6.74878
/NodeList/7/$ns3::MobilityModel/CourseChange x = 13.0076, y = 6.62336
/NodeList/7/$ns3::MobilityModel/CourseChange x = 12.6285, y = 5.698
/NodeList/7/$ns3::MobilityModel/CourseChange x = 13.32, y = 4.97559
/NodeList/7/$ns3::MobilityModel/CourseChange x = 13.1134, y = 3.99715
/NodeList/7/$ns3::MobilityModel/CourseChange x = 13.8359, y = 4.68851
/NodeList/7/$ns3::MobilityModel/CourseChange x = 13.5953, y = 3.71789
/NodeList/7/$ns3::MobilityModel/CourseChange x = 12.7595, y = 4.26688
/NodeList/7/$ns3::MobilityModel/CourseChange x = 11.7629, y = 4.34913
/NodeList/7/$ns3::MobilityModel/CourseChange x = 11.2292, y = 5.19485
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.2344, y = 5.09394
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.3601, y = 4.60846
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.40025, y = 4.32795
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.14292, y = 4.99761
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.08299, y = 5.99581
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.26068, y = 5.42677
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.35917, y = 6.42191
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.66805, y = 7.14466
/NodeList/7/$ns3::MobilityModel/CourseChange x = 6.71414, y = 6.84456
/NodeList/7/$ns3::MobilityModel/CourseChange x = 6.42489, y = 7.80181
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.36083, y = -0.769065
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.62346, y = 0.195831
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.42533, y = 1.17601
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.4854, y = 0.834616
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.79244, y = 1.55559
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.85546, y = 2.55361
At time +2s client sent 1024 bytes to 10.1.2.4 port 9
At time +2.01624s server received 1024 bytes from 10.1.3.3 port 49153
At time +2.01624s server sent 1024 bytes to 10.1.3.3 port 49153
At time +2.02849s client received 1024 bytes from 10.1.2.4 port 9
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.72774, y = 2.06461
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.52954, y = 2.6622
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.523, y = 2.77665
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.7054, y = 3.75987
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.143, y = 2.93301
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.2355, y = 1.9373
/NodeList/7/$ns3::MobilityModel/CourseChange x = 11.2152, y = 1.73647
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.2379, y = 1.94864
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.4491, y = 0.971199
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.56013, y = 1.42913
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.11607, y = 2.32513
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.22047, y = 1.88027
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.79149, y = 1.05934
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.41195, y = 0.275103
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.83369, y = -0.631617
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.15219, y = 0.100206
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.32714, y = 0.665266
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.46368, y = 0.160847
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.40394, y = -0.837367
/NodeList/7/$ns3::MobilityModel/CourseChange x = 6.96716, y = -1.73693
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.62062, y = -2.49388
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.99793, y = -1.56779
Queues in ns-3
**************

109
doc/tutorial/source/conceptual-overview.rst
View File

@@ -151,17 +151,16 @@ into an easy to use model for your convenience.
A First ns-3 Script
*******************
If you downloaded the system as was suggested above, you will have a release
of |ns3| in a directory called ``repos`` under your home
of |ns3| in a directory called ``workspace`` under your home
directory. Change into that release directory, and you should find a
directory structure something like the following:
.. sourcecode:: bash
AUTHORS doc RELEASE_NOTES.md utils
bindings examples scratch utils.py
CHANGES.html LICENSE src VERSION
contrib Makefile test.py
CONTRIBUTING.md README.md testpy.supp
AUTHORS CMakeLists.txt examples RELEASE_NOTES.md testpy.supp
bindings contrib LICENSE scratch utils
build-support CONTRIBUTING.md ns3 src utils.py
CHANGES.md doc README.md test.py VERSION
Change into the ``examples/tutorial`` directory. You should see a file named
``first.cc`` located there. This is a script that will create a simple
@@ -183,9 +182,9 @@ out of the way immediately. The |ns3| project, like most large
projects, has adopted a coding style to which all contributed code must
adhere. If you want to contribute your code to the project, you will
eventually have to conform to the |ns3| coding standard as described
in the file ``doc/codingstd.txt`` or shown on the project web page
in the file ``doc/contributing/source/coding-style.rst`` or shown on the project web page
`here
<http://www.nsnam.org/developers/contributing-code/coding-style/>`_.
<https://www.nsnam.org/docs/contributing/html/coding-style.html>`_.
We recommend that you, well, just get used to the look and feel of |ns3|
code and adopt this standard whenever you are working with our code. All of
@@ -194,7 +193,7 @@ grumbling. The emacs mode line above makes it easier to get the formatting
correct if you use the emacs editor.
The |ns3| simulator is licensed using the GNU General Public
License. You will see the appropriate GNU legalese at the head of every file
License version 2. You will see the appropriate GNU legalese at the head of every file
in the |ns3| distribution. Often you will see a copyright notice for
one of the institutions involved in the |ns3| project above the GPL
text and an author listed below.
@@ -249,14 +248,14 @@ configuration. CMake will also automatically generate a module include file to
load all of the public header files.
Since you are, of course, following this tutorial religiously, you will
already have done a
already have run the following command from the top-level directory:
.. sourcecode:: bash
$ ./ns3 configure -d debug --enable-examples --enable-tests
in order to configure the project to perform debug builds that include
examples and tests. You will also have done a
examples and tests. You will also have called
.. sourcecode:: bash
@@ -264,7 +263,7 @@ examples and tests. You will also have done a
to build the project. So now if you look in the directory
``../../build/include/ns3`` you will find the four module include files shown
above. You can take a look at the contents of these files and find that they
above (among many other header files). You can take a look at the contents of these files and find that they
do include all of the public include files in their respective modules.
Ns3 Namespace
@@ -298,7 +297,7 @@ The next line of the script is the following,
We will use this statement as a convenient place to talk about our Doxygen
documentation system. If you look at the project web site,
`ns-3 project
<http://www.nsnam.org>`_, you will find a link to "Documentation" in the navigation bar. If you select this link, you will be
<https://www.nsnam.org>`_, you will find a link to "Documentation" in the navigation bar. If you select this link, you will be
taken to our documentation page. There
is a link to "Latest Release" that will take you to the documentation
for the latest stable release of |ns3|.
@@ -825,18 +824,18 @@ Now build your first example script using ns3:
.. sourcecode:: bash
$ ./ns3
$ ./ns3 build
You should see messages reporting that your ``myfirst`` example was built
successfully.
.. sourcecode:: bash
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
[614/708] cxx: scratch/myfirst.cc -> build/debug/scratch/myfirst_3.o
[706/708] cxx_link: build/debug/scratch/myfirst_3.o -> build/debug/scratch/myfirst
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (2.357s)
Scanning dependencies of target scratch_myfirst
[ 0%] Building CXX object scratch/CMakeFiles/scratch_myfirst.dir/myfirst.cc.o
[ 0%] Linking CXX executable ../../build/scratch/ns3.36.1-myfirst-debug
Finished executing the following commands:
cd cmake-cache; cmake --build . -j 7 ; cd ..
You can now run the example (note that if you build your program in the scratch
directory you must run it out of the scratch directory):
@@ -849,15 +848,12 @@ You should see some output:
.. sourcecode:: bash
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.418s)
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2
At time +2s client sent 1024 bytes to 10.1.1.2 port 9
At time +2.00369s server received 1024 bytes from 10.1.1.1 port 49153
At time +2.00369s server sent 1024 bytes to 10.1.1.1 port 49153
At time +2.00737s client received 1024 bytes from 10.1.1.2 port 9
Here you see that the build system checks to make sure that the file has been
build and then runs it. You see the logging component on the echo client
Here you see the logging component on the echo client
indicate that it has sent one 1024 byte packet to the Echo Server on
10.1.1.2. You also see the logging component on the echo server say that
it has received the 1024 bytes from 10.1.1.1. The echo server silently
@@ -869,64 +865,15 @@ Ns-3 Source Code
Now that you have used some of the |ns3| helpers you may want to
have a look at some of the source code that implements that functionality.
The most recent code can be browsed on our web server at the following link:
https://gitlab.com/nsnam/ns-3-dev.git. There, you will see the Git/GitLab
summary page for our |ns3| development tree.
At the top of the page, you will see a number of links,
.. sourcecode:: text
summary | shortlog | changelog | graph | tags | files
Go ahead and select the ``files`` link. This is what the top-level of
most of our *repositories* will look:
.. sourcecode:: text
drwxr-xr-x [up]
-rwxrwxrwx 12507 nov 23 23:12 AUTHORS
drwxrwxrwx 0 dez 30 2020 bindings
drwxrwxrwx 4096 nov 28 11:25 build-support
-rwxrwxrwx 189870 nov 28 10:13 CHANGES.html
-rwxrwxrwx 1490 nov 22 10:56 .clang-format
-rwxrwxrwx 5079 nov 28 10:50 CMakeLists.txt
drwxrwxrwx 0 nov 28 00:56 contrib
-rwxrwxrwx 18336 nov 23 23:12 CONTRIBUTING.md
drwxrwxrwx 4096 nov 28 11:30 doc
-rwxrwxrwx 564 nov 22 10:56 .editorconfig
drwxrwxrwx 4096 nov 28 00:28 examples
drwxrwxrwx 4096 nov 28 11:15 .git
-rwxrwxrwx 42 nov 22 10:56 .gitattributes
-rwxrwxrwx 395 nov 28 11:25 .gitignore
drwxrwxrwx 4096 nov 28 11:37 .idea
-rwxrwxrwx 17987 nov 22 10:56 LICENSE
-rwxrwxrwx 6841 nov 22 10:56 .mailmap
drwxrwxrwx 0 jul 13 20:15 .nompi
-rwxrwxrwx 31942 nov 28 11:16 ns3
-rwxrwxrwx 4210 nov 28 11:25 README.md
-rwxrwxrwx 185874 nov 28 10:13 RELEASE_NOTES.md
drwxrwxrwx 4096 nov 28 00:28 scratch
drwxrwxrwx 0 out 21 11:42 .settings
drwxrwxrwx 8192 nov 28 00:56 src
-rwxrwxrwx 83149 nov 28 11:28 test.py
-rwxrwxrwx 131 nov 22 10:56 testpy.supp
drwxrwxrwx 4096 nov 28 11:25 utils
-rwxrwxrwx 4227 nov 28 11:25 utils.py
-rwxrwxrwx 6 nov 22 10:56 VERSION
Our example scripts are in the ``examples`` directory. If you click on ``examples``
Our example scripts are in the ``examples`` directory. If you change to ``examples`` directory,
you will see a list of subdirectories. One of the files in ``tutorial`` subdirectory is ``first.cc``. If
you click on ``first.cc`` you will find the code you just walked through.
The source code is mainly in the ``src`` directory. You can view source
code either by clicking on the directory name or by clicking on the ``files``
link to the right of the directory name. If you click on the ``src``
directory, you will be taken to the listing of the ``src`` subdirectories. If you
then click on ``core`` subdirectory, you will find a list of files. The first file
you will find (as of this writing) is ``abort.h``. If you click on the
``abort.h`` link, you will be sent to the source file for ``abort.h`` which
contains useful macros for exiting scripts if abnormal conditions are detected.
The source code is mainly in the ``src`` directory. The core of the simulator
is in the ``src/core/model`` subdirectory. The first file you will find there
(as of this writing) is ``abort.h``. If you open that file, you can view
macros for exiting scripts if abnormal conditions are detected.
The source code for the helpers we have used in this chapter can be found in the
``src/applications/helper`` directory. Feel free to poke around in the directory tree to

45
doc/tutorial/source/getting-started.rst
View File

@@ -70,7 +70,7 @@ You may want to take this opportunity to explore the |ns3| wiki
a bit, or the main web site at https://www.nsnam.org, since there is a
wealth of information there.
As of the most recent |ns3| release (ns-3.36), the following tools
As of the most recent |ns3| release (ns-3.36.1), the following tools
are needed to get started with |ns3|:
============ ===========================================================
@@ -124,21 +124,21 @@ get a copy of a release by typing the following into your Linux shell
$ cd
$ mkdir workspace
$ cd workspace
$ wget https://www.nsnam.org/release/ns-allinone-3.36.tar.bz2
$ tar xjf ns-allinone-3.36.tar.bz2
$ wget https://www.nsnam.org/release/ns-allinone-3.36.1.tar.bz2
$ tar xjf ns-allinone-3.36.1.tar.bz2
Notice the use above of the ``wget`` utility, which is a command-line
tool to fetch objects from the web; if you do not have this installed,
you can use a browser for this step.
Following these steps, if you change into the directory
``ns-allinone-3.36``, you should see a number of files and directories
``ns-allinone-3.36.1``, you should see a number of files and directories
.. sourcecode:: text
$ cd ns-allinone-3.36
$ cd ns-allinone-3.36.1
$ ls
bake constants.py ns-3.36 README
bake constants.py ns-3.36.1 README.md
build.py netanim-3.108 pybindgen-0.22.1 util.py
You are now ready to build the base |ns3| distribution and may skip ahead
@@ -174,7 +174,7 @@ something like this:
.. sourcecode:: console
$ ls
build.py constants.py download.py README util.py
build.py constants.py download.py README.md util.py
Note the presence of the ``download.py`` script, which will further fetch
the |ns3| and related sourcecode. At this point, you have a choice, to
@@ -189,7 +189,7 @@ release number:
.. sourcecode:: console
$ python3 download.py -n ns-3.36
$ python3 download.py -n ns-3.36.1
After this step, the additional repositories of |ns3|, bake, pybindgen,
and netanim will be downloaded to the ``ns-3-allinone`` directory.
@@ -258,10 +258,10 @@ distribution of your choice.
There are a few configuration targets available:
1. ``ns-3.36``: the module corresponding to the release; it will download
1. ``ns-3.36.1``: the module corresponding to the release; it will download
components similar to the release tarball.
2. ``ns-3-dev``: a similar module but using the development code tree
3. ``ns-allinone-3.36``: the module that includes other optional features
3. ``ns-allinone-3.36.1``: the module that includes other optional features
such as bake build system, netanim animator, and pybindgen
4. ``ns-3-allinone``: similar to the released version of the allinone
module, but for development code.
@@ -278,7 +278,7 @@ code either by inspection of the repository list or by going to the
`"ns-3 Releases"
<https://www.nsnam.org/releases>`_
web page and clicking on the latest release link. We'll proceed in
this tutorial example with ``ns-3.36``.
this tutorial example with ``ns-3.36.1``.
We are now going to use the bake tool to pull down the various pieces of
|ns3| you will be using. First, we'll say a word about running bake.
@@ -306,7 +306,7 @@ Step into the workspace directory and type the following into your shell:
.. sourcecode:: console
$ ./bake.py configure -e ns-3.36
$ ./bake.py configure -e ns-3.36.1
Next, we'll ask bake to check whether we have enough tools to download
various components. Type:
@@ -362,7 +362,7 @@ should yield something like:
>> Searching for system dependency cmake - OK
>> Downloading netanim-3.108 - OK
>> Downloading pybindgen-0.22.1 (target directory:pybindgen) - OK
>> Downloading ns-3.36 (target directory:ns-3.36) - OK
>> Downloading ns-3.36.1 (target directory:ns-3.36.1) - OK
The above suggests that three sources have been downloaded. Check the
``source`` directory now and type ``ls``; one should see:
@@ -371,7 +371,7 @@ The above suggests that three sources have been downloaded. Check the
$ cd source
$ ls
netanim-3.108 ns-3.36 pybindgen
netanim-3.108 ns-3.36.1 pybindgen
You are now ready to build the |ns3| distribution.
@@ -401,7 +401,7 @@ native |ns3| build system, CMake, to be introduced later in this tutorial.
If you downloaded
using a tarball you should have a directory called something like
``ns-allinone-3.36`` under your ``~/workspace`` directory.
``ns-allinone-3.36.1`` under your ``~/workspace`` directory.
Type the following:
.. sourcecode:: console
@@ -436,7 +436,7 @@ and you should see something like:
>> Building pybindgen-0.22.1 - OK
>> Building netanim-3.108 - OK
>> Building ns-3.36 - OK
>> Building ns-3.36.1 - OK
There may be failures to build all components, but the build will proceed
anyway if the component is optional. For example, a recent portability issue
@@ -719,27 +719,28 @@ for an already configured project:
Build profile: debug
The build.py script discussed above supports also the ``--enable-examples``
and ``enable-tests`` arguments, but in general, does not directly support
and ``enable-tests`` arguments and passes them through to the ns-3
configuration, but in general, does not directly support
other ns3 options; for example, this will not work:
.. sourcecode:: console
$ ./build.py --disable-python
$ ./build.py --enable-asserts
will result in:
.. sourcecode:: console
build.py: error: no such option: --disable-python
build.py: error: no such option: --enable-asserts
However, the special operator ``--`` can be used to pass additional
options through to ns3, so instead of the above, the following will work:
configure options through to ns3, so instead of the above, the following will work:
.. sourcecode:: console
$ ./build.py -- --disable-python
$ ./build.py -- --enable-asserts
as it generates the underlying command ``./ns3 configure --disable-python``.
as it generates the underlying command ``./ns3 configure --enable-asserts``.
Here are a few more introductory tips about CMake.

8
doc/tutorial/source/introduction.rst
View File

@@ -128,14 +128,14 @@ results. There are a few policies that we hope will encourage people to
contribute to |ns3| like they have for |ns2|:
* Open source licensing based on GNU GPLv2 compatibility
* `wiki
<https://www.nsnam.org/wiki>`_
* An `app store
<https://apps.nsnam.org>`_
* `Contributed Code
<https://www.nsnam.org/wiki/Contributed_Code>`_ page, similar to |ns2|'s popular Contributed Code
`page
<http://nsnam.isi.edu/nsnam/index.php/Contributed_Code>`_
* Use of GitLab.com including issue tracker
<https://www.gitlab.com/nsnam>`_
* Documentation on `how to contribute <https://www.nsnam.org/docs/contributing/html/index.html>`_
* Use of Git hosting at GitLab.com including `issue tracker <https://www.gitlab.com/nsnam>`_
We realize that if you are reading this document, contributing back to
the project is probably not your foremost concern at this point, but

8
doc/tutorial/source/quick-start.rst
View File

@@ -61,13 +61,13 @@ Downloading the Latest Release
::
$ tar xjf ns-allinone-3.36.tar.bz2
$ tar xjf ns-allinone-3.36.1.tar.bz2
3) Change into the |ns3| directory directly; e.g.
::
$ cd ns-allinone-3.36/ns-3.36
$ cd ns-allinone-3.36.1/ns-3.36.1
The ns-allinone directory has some additional components but we are skipping
over them here; one can work directly from the |ns3| source code directory.
@@ -89,12 +89,12 @@ only to `cd` into ns-3-dev; the `master` branch is checked out by default.
$ cd ns-3-dev
If instead you want to try the most recent release (version 3.36 as of this
If instead you want to try the most recent release (version 3.36.1 as of this
writing), you can checkout a branch corresponding to that git tag:
::
$ git checkout -b ns-3.36-branch ns-3.36
$ git checkout -b ns-3.36.1-branch ns-3.36.1
Building and testing ns-3
*************************

129
doc/tutorial/source/tracing.rst
View File

@@ -4,7 +4,7 @@
:format: html latex
.. Mimic doxygen formatting for parameter names
.. raw:: html
<style>.param {font-weight:bold; color:#602020;}</style>
@@ -77,7 +77,7 @@ standard output, as in::
...
std::cout << "The value of x is " << x << std::endl;
...
}
}
Nobody is going to prevent you from going deep into the core of |ns3|
and adding print statements. This is insanely easy to do and, after
@@ -107,7 +107,7 @@ other people as a patch to the existing core.
Let's pick a random example. If you wanted to add more logging to the
|ns3| TCP socket (``tcp-socket-base.cc``) you could just add a new
message down in the implementation. Notice that in
``TcpSocketBase::ProcessEstablished ()`` there is no log message for the
``TcpSocketBase::ProcessEstablished ()`` there is no log message for the
reception of a SYN+ACK in ESTABLISHED state.
You could simply add one, changing the code. Here is the original::
@@ -158,7 +158,7 @@ files to disk and process them down to a few lines whenever you want
to do anything.
Since there are no guarantees in |ns3| about the stability of
``NS_LOG`` output, you may also discover that pieces of log output
``NS_LOG`` output, you may also discover that pieces of log output
which you depend on disappear or change between releases. If you depend
on the structure of the output, you may find other messages being
added or deleted which may affect your parsing code.
@@ -328,14 +328,14 @@ the tutorial directory as ``fourth.cc``. Let's walk through it::
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include "ns3/object.h"
#include "ns3/uinteger.h"
#include "ns3/traced-value.h"
#include "ns3/trace-source-accessor.h"
#include <iostream>
using namespace ns3;
Most of this code should be quite familiar to you. As mentioned
@@ -376,7 +376,7 @@ simple Object we can work with.
;
return tid;
}
MyObject () {}
TracedValue<int32_t> m_myInt;
};
@@ -431,7 +431,7 @@ code to connect the source to the sink, which happens in ``main``::
{
Ptr<MyObject> myObject = CreateObject<MyObject> ();
myObject->TraceConnectWithoutContext ("MyInteger", MakeCallback(&IntTrace));
myObject->m_myInt = 1234;
}
@@ -522,7 +522,7 @@ more clear to you what this function is doing::
CourseChange (std::string context, Ptr<const MobilityModel> model)
{
Vector position = model->GetPosition ();
NS_LOG_UNCOND (context <<
NS_LOG_UNCOND (context <<
" x = " << position.x << ", y = " << position.y);
}
@@ -628,7 +628,7 @@ for "CourseChange" in your favorite editor. You should find
MakeTraceSourceAccessor (&MobilityModel::m_courseChangeTrace),
"ns3::MobilityModel::CourseChangeCallback")
which should look very familiar at this point.
which should look very familiar at this point.
If you look for the corresponding declaration of the underlying traced
variable in ``mobility-model.h`` you will find
@@ -740,7 +740,7 @@ an entry for
::
CourseChange: The value of the position and/or velocity vector changed
CourseChange: The value of the position and/or velocity vector changed
You should recognize this as the trace source we used in the
``third.cc`` example. Perusing this list will be helpful.
@@ -772,7 +772,7 @@ in the "All TraceSources" list and you want to figure out how to
connect to it. You know that you are using (again, from the
``third.cc`` example) an ``ns3::RandomWalk2dMobilityModel``. So
either click on the class name in the "All TraceSources" list, or find
``ns3::RandomWalk2dMobilityModel`` in the "Class List". Either way
``ns3::RandomWalk2dMobilityModel`` in the "Class List". Either way
you should now be looking at the "ns3::RandomWalk2dMobilityModel Class
Reference" page.
@@ -808,7 +808,7 @@ Look further down in the "Detailed Description" section for the list
of trace sources. You will find
No TraceSources are defined for this type.
**TraceSources defined in parent class ``ns3::MobilityModel``**
* **CourseChange**: The value of the position and/or velocity vector
@@ -843,11 +843,11 @@ and you may find your answer along with working code. For example, in
this case, ``src/mobility/examples/main-random-topology.cc`` has
something just waiting for you to use::
Config::Connect ("/NodeList/*/$ns3::MobilityModel/CourseChange",
Config::Connect ("/NodeList/*/$ns3::MobilityModel/CourseChange",
MakeCallback (&CourseChange));
We'll return to this example in a moment.
We'll return to this example in a moment.
Callback Signatures
+++++++++++++++++++
@@ -871,7 +871,7 @@ The callback signature is given as a link to the relevant ``typedef``,
where we find
``typedef void (* CourseChangeCallback)(std::string context, Ptr<const MobilityModel> * model);``
**TracedCallback** signature for course change notifications.
If the callback is connected using ``ConnectWithoutContext`` omit the
@@ -1040,11 +1040,11 @@ Just after this comment, you will find
::
template<typename T1 = empty, typename T2 = empty,
template<typename T1 = empty, typename T2 = empty,
typename T3 = empty, typename T4 = empty,
typename T5 = empty, typename T6 = empty,
typename T7 = empty, typename T8 = empty>
class TracedCallback
class TracedCallback
{
...
@@ -1063,11 +1063,11 @@ tracing system is in the ``Connect`` and ``ConnectWithoutContext``
functions. If you scroll down, you will see a
``ConnectWithoutContext`` method here::
template<typename T1, typename T2,
template<typename T1, typename T2,
typename T3, typename T4,
typename T5, typename T6,
typename T7, typename T8>
void
void
TracedCallback<T1,T2,T3,T4,T5,T6,T7,T8>::ConnectWithoutContext ...
{
Callback<void,T1,T2,T3,T4,T5,T6,T7,T8> cb;
@@ -1081,7 +1081,7 @@ instantiated for the declaration above, the compiler will replace
::
void
void
TracedCallback<Ptr<const MobilityModel>::ConnectWithoutContext ... cb
{
Callback<void, Ptr<const MobilityModel> > cb;
@@ -1304,8 +1304,8 @@ usual, ``grep`` is your friend:
$ find . -name '*.cc' | xargs grep CongestionWindow
This will point out a couple of promising candidates:
``examples/tcp/tcp-large-transfer.cc`` and
This will point out a couple of promising candidates:
``examples/tcp/tcp-large-transfer.cc`` and
``src/test/ns3tcp/ns3tcp-cwnd-test-suite.cc``.
We haven't visited any of the test code yet, so let's take a look
@@ -1316,7 +1316,7 @@ and search for "CongestionWindow". You will find,
::
ns3TcpSocket->TraceConnectWithoutContext ("CongestionWindow",
ns3TcpSocket->TraceConnectWithoutContext ("CongestionWindow",
MakeCallback (&Ns3TcpCwndTestCase1::CwndChange, this));
This should look very familiar to you. We mentioned above that if we
@@ -1405,16 +1405,16 @@ see some familiar looking code::
* along with this program; if not, write to the Free Software
* Foundation, Include., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include <fstream>
#include "ns3/core-module.h"
#include "ns3/network-module.h"
#include "ns3/internet-module.h"
#include "ns3/point-to-point-module.h"
#include "ns3/applications-module.h"
using namespace ns3;
NS_LOG_COMPONENT_DEFINE ("FifthScriptExample");
This has all been covered, so we won't rehash it. The next lines of
@@ -1469,20 +1469,20 @@ time.
class MyApp : public Application
{
public:
MyApp ();
virtual ~MyApp();
void Setup (Ptr<Socket> socket, Address address, uint32_t packetSize,
void Setup (Ptr<Socket> socket, Address address, uint32_t packetSize,
uint32_t nPackets, DataRate dataRate);
private:
virtual void StartApplication (void);
virtual void StopApplication (void);
void ScheduleTx (void);
void SendPacket (void);
Ptr<Socket> m_socket;
Address m_peer;
uint32_t m_packetSize;
@@ -1669,7 +1669,7 @@ course::
m_packetsSent (0)
{
}
MyApp::~MyApp()
{
m_socket = 0;
@@ -1681,7 +1681,7 @@ this ``Application`` in the first place.
::
void
MyApp::Setup (Ptr<Socket> socket, Address address, uint32_t packetSize,
MyApp::Setup (Ptr<Socket> socket, Address address, uint32_t packetSize,
uint32_t nPackets, DataRate dataRate)
{
m_socket = socket;
@@ -1690,7 +1690,7 @@ this ``Application`` in the first place.
m_nPackets = nPackets;
m_dataRate = dataRate;
}
This code should be pretty self-explanatory. We are just initializing
member variables. The important one from the perspective of tracing
is the ``Ptr<Socket> socket`` which we needed to provide to the
@@ -1734,12 +1734,12 @@ creating simulation events.
MyApp::StopApplication (void)
{
m_running = false;
if (m_sendEvent.IsRunning ())
{
Simulator::Cancel (m_sendEvent);
}
if (m_socket)
{
m_socket->Close ();
@@ -1769,7 +1769,7 @@ chain of events that describes the ``Application`` behavior.
{
Ptr<Packet> packet = Create<Packet> (m_packetSize);
m_socket->Send (packet);
if (++m_packetsSent < m_nPackets)
{
ScheduleTx ();
@@ -1865,11 +1865,11 @@ The following code should be very familiar to you by now::
{
NodeContainer nodes;
nodes.Create (2);
PointToPointHelper pointToPoint;
pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));
pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));
NetDeviceContainer devices;
devices = pointToPoint.Install (nodes);
@@ -1886,7 +1886,7 @@ congestion window.
|ns3| provides ``ErrorModel`` objects which can be attached to
``Channels``. We are using the ``RateErrorModel`` which allows us to
introduce errors
into a ``Channel`` at a given *rate*.
into a ``Channel`` at a given *rate*.
::
@@ -1921,7 +1921,7 @@ is commonly used in |ns3| for that purpose.
uint16_t sinkPort = 8080;
Address sinkAddress (InetSocketAddress(interfaces.GetAddress (1), sinkPort));
PacketSinkHelper packetSinkHelper ("ns3::TcpSocketFactory",
PacketSinkHelper packetSinkHelper ("ns3::TcpSocketFactory",
InetSocketAddress (Ipv4Address::GetAny (), sinkPort));
ApplicationContainer sinkApps = packetSinkHelper.Install (nodes.Get (1));
sinkApps.Start (Seconds (0.));
@@ -1931,7 +1931,7 @@ This should all be familiar, with the exception of,
::
PacketSinkHelper packetSinkHelper ("ns3::TcpSocketFactory",
PacketSinkHelper packetSinkHelper ("ns3::TcpSocketFactory",
InetSocketAddress (Ipv4Address::GetAny (), sinkPort));
This code instantiates a ``PacketSinkHelper`` and tells it to create
@@ -1952,9 +1952,9 @@ trace source.
::
Ptr<Socket> ns3TcpSocket = Socket::CreateSocket (nodes.Get (0),
Ptr<Socket> ns3TcpSocket = Socket::CreateSocket (nodes.Get (0),
TcpSocketFactory::GetTypeId ());
ns3TcpSocket->TraceConnectWithoutContext ("CongestionWindow",
ns3TcpSocket->TraceConnectWithoutContext ("CongestionWindow",
MakeCallback (&CwndChange));
The first statement calls the static member function
@@ -2036,10 +2036,7 @@ to run.
.. sourcecode:: bash
$ ./ns3 run fifth
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
'build' finished successfully (0.684s)
1 536
1.00419 536
1.0093 1072
1.01528 1608
1.02167 2144
@@ -2127,7 +2124,7 @@ information to a stream representing a file.
NS_LOG_UNCOND (Simulator::Now ().GetSeconds () << "\t" << newCwnd);
*stream->GetStream () << Simulator::Now ().GetSeconds () << "\t" << oldCwnd << "\t" << newCwnd << std::endl;
}
static void
RxDrop (Ptr<PcapFileWrapper> file, Ptr<const Packet> p)
{
@@ -2350,7 +2347,7 @@ and we did this in only 18 lines of code::
}
...
PcapHelper pcapHelper;
Ptr<PcapFileWrapper> file = pcapHelper.CreateFile ("sixth.pcap", "w", PcapHelper::DLT_PPP);
devices.Get (1)->TraceConnectWithoutContext("PhyRxDrop", MakeBoundCallback (&RxDrop, file));
@@ -2364,7 +2361,7 @@ previous sections, primarily :ref:`BuildingTopologies`, we have seen
several varieties of the trace helper methods designed for use inside
other (device) helpers.
Perhaps you will recall seeing some of these variations:
Perhaps you will recall seeing some of these variations:
::
@@ -2619,8 +2616,8 @@ inherited from the ASCII trace ``mixin``.
::
virtual void EnableAsciiInternal (Ptr<OutputStreamWrapper> stream,
std::string prefix,
virtual void EnableAsciiInternal (Ptr<OutputStreamWrapper> stream,
std::string prefix,
Ptr<NetDevice> nd,
bool explicitFilename) = 0;
@@ -2778,7 +2775,7 @@ but to summarize ...
This would result in a number of ASCII trace files being created,
each of which follows the ``<prefix>-<node id>-<device id>.tr``
convention.
Combining all of the traces into a single file is accomplished
similarly to the examples above::
@@ -2889,8 +2886,8 @@ class ``Object``, and methods that share the same signature.
::
virtual void EnablePcapIpv4Internal (std::string prefix,
Ptr<Ipv4> ipv4,
virtual void EnablePcapIpv4Internal (std::string prefix,
Ptr<Ipv4> ipv4,
uint32_t interface,
bool explicitFilename) = 0;
@@ -2967,7 +2964,7 @@ summarize ...
NodeContainer nodes;
...
NetDeviceContainer devices = deviceHelper.Install (nodes);
...
...
Ipv4AddressHelper ipv4;
ipv4.SetBase ("10.1.1.0", "255.255.255.0");
Ipv4InterfaceContainer interfaces = ipv4.Assign (devices);
@@ -3061,9 +3058,9 @@ method inherited from this class.
::
virtual void EnableAsciiIpv4Internal (Ptr<OutputStreamWrapper> stream,
std::string prefix,
Ptr<Ipv4> ipv4,
virtual void EnableAsciiIpv4Internal (Ptr<OutputStreamWrapper> stream,
std::string prefix,
Ptr<Ipv4> ipv4,
uint32_t interface,
bool explicitFilename) = 0;
@@ -3204,7 +3201,7 @@ but to summarize ...
NodeContainer nodes;
...
NetDeviceContainer devices = deviceHelper.Install (nodes);
...
...
Ipv4AddressHelper ipv4;
ipv4.SetBase ("10.1.1.0", "255.255.255.0");
Ipv4InterfaceContainer interfaces = ipv4.Assign (devices);
@@ -3220,7 +3217,7 @@ but to summarize ...
NodeContainer nodes;
...
NetDeviceContainer devices = deviceHelper.Install (nodes);
...
...
Ipv4AddressHelper ipv4;
ipv4.SetBase ("10.1.1.0", "255.255.255.0");
Ipv4InterfaceContainer interfaces = ipv4.Assign (devices);

316
doc/tutorial/source/tweaking.rst
View File

@@ -92,12 +92,10 @@ program
.. sourcecode:: bash
$ Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.413s)
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2
At time +2s client sent 1024 bytes to 10.1.1.2 port 9
At time +2.00369s server received 1024 bytes from 10.1.1.1 port 49153
At time +2.00369s server sent 1024 bytes to 10.1.1.1 port 49153
At time +2.00737s client received 1024 bytes from 10.1.1.2 port 9
It turns out that the "Sent" and "Received" messages you see above are
actually logging messages from the ``UdpEchoClientApplication`` and
@@ -138,25 +136,24 @@ The left hand side of the assignment is the name of the logging component we
want to set, and the right hand side is the flag we want to use. In this case,
we are going to turn on all of the debugging levels for the application. If
you run the script with NS_LOG set this way, the |ns3| logging
system will pick up the change and you should see the following output:
system will pick up the change and you should see something similar to
the following output:
.. sourcecode:: bash
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.404s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
Received 1024 bytes from 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoClientApplication:UdpEchoClient(0xef90d0)
UdpEchoClientApplication:SetDataSize(0xef90d0, 1024)
UdpEchoClientApplication:StartApplication(0xef90d0)
UdpEchoClientApplication:ScheduleTransmit(0xef90d0, +0ns)
UdpEchoClientApplication:Send(0xef90d0)
At time +2s client sent 1024 bytes to 10.1.1.2 port 9
At time +2.00369s server received 1024 bytes from 10.1.1.1 port 49153
At time +2.00369s server sent 1024 bytes to 10.1.1.1 port 49153
UdpEchoClientApplication:HandleRead(0xef90d0, 0xee7b20)
At time +2.00737s client received 1024 bytes from 10.1.1.2 port 9
UdpEchoClientApplication:StopApplication(0xef90d0)
UdpEchoClientApplication:DoDispose(0xef90d0)
UdpEchoClientApplication:~UdpEchoClient(0xef90d0)
The additional debug information provided by the application is from
the NS_LOG_FUNCTION level. This shows every time a function in the application
@@ -199,26 +196,29 @@ name.
.. sourcecode:: bash
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.417s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoClientApplication:UdpEchoClient(0xea8e50)
UdpEchoClientApplication:SetDataSize(0xea8e50, 1024)
UdpEchoClientApplication:StartApplication(0xea8e50)
UdpEchoClientApplication:ScheduleTransmit(0xea8e50, +0ns)
UdpEchoClientApplication:Send(0xea8e50)
UdpEchoClientApplication:Send(): At time +2s client sent 1024 bytes to 10.1.1.2 port 9
At time +2.00369s server received 1024 bytes from 10.1.1.1 port 49153
At time +2.00369s server sent 1024 bytes to 10.1.1.1 port 49153
UdpEchoClientApplication:HandleRead(0xea8e50, 0xea5b20)
UdpEchoClientApplication:HandleRead(): At time +2.00737s client received 1024 bytes from 10.1.1.2 port 9
UdpEchoClientApplication:StopApplication(0xea8e50)
UdpEchoClientApplication:DoDispose(0xea8e50)
UdpEchoClientApplication:~UdpEchoClient(0xea8e50)
You can now see all of the messages coming from the UDP echo client application
are identified as such. The message "Received 1024 bytes from 10.1.1.2" is
now clearly identified as coming from the echo client application. The
remaining message must be coming from the UDP echo server application. We
now clearly identified as coming from the echo client application.
Also, in most log statements, you will see a hexadecimal value printed
such as ``0xea8e50``; this is because most statements print out the value
of the C++ ``this`` pointer, so that objects can be distinguished from
one another.
The remaining message must be coming from the UDP echo server application. We
can enable that component by entering a colon separated list of components in
the NS_LOG environment variable.
@@ -236,27 +236,26 @@ in debugging problems.
.. sourcecode:: bash
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.406s)
UdpEchoServerApplication:UdpEchoServer()
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoServerApplication:StartApplication()
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
UdpEchoServerApplication:UdpEchoServer(0x2101590)
UdpEchoClientApplication:UdpEchoClient(0x2101820)
UdpEchoClientApplication:SetDataSize(0x2101820, 1024)
UdpEchoServerApplication:StartApplication(0x2101590)
UdpEchoClientApplication:StartApplication(0x2101820)
UdpEchoClientApplication:ScheduleTransmit(0x2101820, +0ns)
UdpEchoClientApplication:Send(0x2101820)
UdpEchoClientApplication:Send(): At time +2s client sent 1024 bytes to 10.1.1.2 port 9
UdpEchoServerApplication:HandleRead(0x2101590, 0x2106240)
UdpEchoServerApplication:HandleRead(): At time +2.00369s server received 1024 bytes from 10.1.1.1 port 49153
UdpEchoServerApplication:HandleRead(): Echoing packet
UdpEchoClientApplication:HandleRead(0x624920, 0x625160)
UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
UdpEchoServerApplication:StopApplication()
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()
UdpEchoServerApplication:HandleRead(): At time +2.00369s server sent 1024 bytes to 10.1.1.1 port 49153
UdpEchoClientApplication:HandleRead(0x2101820, 0x21134b0)
UdpEchoClientApplication:HandleRead(): At time +2.00737s client received 1024 bytes from 10.1.1.2 port 9
UdpEchoClientApplication:StopApplication(0x2101820)
UdpEchoServerApplication:StopApplication(0x2101590)
UdpEchoClientApplication:DoDispose(0x2101820)
UdpEchoServerApplication:DoDispose(0x2101590)
UdpEchoClientApplication:~UdpEchoClient(0x2101820)
UdpEchoServerApplication:~UdpEchoServer(0x2101590)
It is also sometimes useful to be able to see the simulation time at which a
log message is generated. You can do this by ORing in the prefix_time bit.
@@ -271,34 +270,33 @@ you should see the following output:
.. sourcecode:: bash
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.418s)
0s UdpEchoServerApplication:UdpEchoServer()
0s UdpEchoClientApplication:UdpEchoClient()
0s UdpEchoClientApplication:SetDataSize(1024)
1s UdpEchoServerApplication:StartApplication()
2s UdpEchoClientApplication:StartApplication()
2s UdpEchoClientApplication:ScheduleTransmit()
2s UdpEchoClientApplication:Send()
2s UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()
+0.000000000s UdpEchoServerApplication:UdpEchoServer(0x8edfc0)
+0.000000000s UdpEchoClientApplication:UdpEchoClient(0x8ee210)
+0.000000000s UdpEchoClientApplication:SetDataSize(0x8ee210, 1024)
+1.000000000s UdpEchoServerApplication:StartApplication(0x8edfc0)
+2.000000000s UdpEchoClientApplication:StartApplication(0x8ee210)
+2.000000000s UdpEchoClientApplication:ScheduleTransmit(0x8ee210, +0ns)
+2.000000000s UdpEchoClientApplication:Send(0x8ee210)
+2.000000000s UdpEchoClientApplication:Send(): At time +2s client sent 1024 bytes to 10.1.1.2 port 9
+2.003686400s UdpEchoServerApplication:HandleRead(0x8edfc0, 0x936770)
+2.003686400s UdpEchoServerApplication:HandleRead(): At time +2.00369s server received 1024 bytes from 10.1.1.1 port 49153
+2.003686400s UdpEchoServerApplication:HandleRead(): Echoing packet
+2.003686400s UdpEchoServerApplication:HandleRead(): At time +2.00369s server sent 1024 bytes to 10.1.1.1 port 49153
+2.007372800s UdpEchoClientApplication:HandleRead(0x8ee210, 0x8f3140)
+2.007372800s UdpEchoClientApplication:HandleRead(): At time +2.00737s client received 1024 bytes from 10.1.1.2 port 9
+10.000000000s UdpEchoClientApplication:StopApplication(0x8ee210)
+10.000000000s UdpEchoServerApplication:StopApplication(0x8edfc0)
UdpEchoClientApplication:DoDispose(0x8ee210)
UdpEchoServerApplication:DoDispose(0x8edfc0)
UdpEchoClientApplication:~UdpEchoClient(0x8ee210)
UdpEchoServerApplication:~UdpEchoServer(0x8edfc0)
You can see that the constructor for the UdpEchoServer was called at a
simulation time of 0 seconds. This is actually happening before the
simulation starts, but the time is displayed as zero seconds. The same is true
for the UdpEchoClient constructor message.
Recall that the ``scratch/first.cc`` script started the echo server
Recall that the ``scratch/myfirst.cc`` script started the echo server
application at one second into the simulation. You can now see that the
``StartApplication`` method of the server is, in fact, called at one second.
You can also see that the echo client application is started at a simulation
@@ -323,7 +321,7 @@ turning on all of the logging components in the system. Try setting the
The asterisk above is the logging component wildcard. This will turn on all
of the logging in all of the components used in the simulation. I won't
reproduce the output here (as of this writing it produces 1265 lines of output
reproduce the output here (as of this writing it produces thousands of lines of output
for the single packet echo) but you can redirect this information into a file
and look through it with your favorite editor if you like,
@@ -380,7 +378,7 @@ off the torrent of logging we previously enabled:
.. sourcecode:: bash
$ ./ns3
$ export NS_LOG=
$ export NS_LOG=""
Now, if you run the script,
@@ -403,13 +401,11 @@ message,
.. sourcecode:: bash
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.404s)
Creating Topology
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2
At time +2s client sent 1024 bytes to 10.1.1.2 port 9
At time +2.00369s server received 1024 bytes from 10.1.1.1 port 49153
At time +2.00369s server sent 1024 bytes to 10.1.1.1 port 49153
At time +2.00737s client received 1024 bytes from 10.1.1.2 port 9
Using Command Line Arguments
****************************
@@ -457,17 +453,15 @@ now see the ``--PrintHelp`` argument and respond with,
.. sourcecode:: bash
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.413s)
TcpL4Protocol:TcpStateMachine()
CommandLine:HandleArgument(): Handle arg name=PrintHelp value=
--PrintHelp: Print this help message.
--PrintGroups: Print the list of groups.
--PrintTypeIds: Print all TypeIds.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintGlobals: Print the list of globals.
myfirst [General Arguments]
General Arguments:
--PrintGlobals: Print the list of globals.
--PrintGroups: Print the list of groups.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintTypeIds: Print all TypeIds.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintVersion: Print the ns-3 version.
--PrintHelp: Print this help message.
Let's focus on the ``--PrintAttributes`` option. We have already hinted
at the |ns3| ``Attribute`` system while walking through the
@@ -534,25 +528,24 @@ If you run the script, you should now see the following output,
.. sourcecode:: bash
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.405s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.25732s Received 1024 bytes from 10.1.1.1
2.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()
+0.000000000s UdpEchoServerApplication:UdpEchoServer(0x20d0d10)
+1.000000000s UdpEchoServerApplication:StartApplication(0x20d0d10)
At time +2s client sent 1024 bytes to 10.1.1.2 port 9
+2.257324218s UdpEchoServerApplication:HandleRead(0x20d0d10, 0x20900b0)
+2.257324218s At time +2.25732s server received 1024 bytes from 10.1.1.1 port 49153
+2.257324218s Echoing packet
+2.257324218s At time +2.25732s server sent 1024 bytes to 10.1.1.1 port 49153
At time +2.51465s client received 1024 bytes from 10.1.1.2 port 9
+10.000000000s UdpEchoServerApplication:StopApplication(0x20d0d10)
UdpEchoServerApplication:DoDispose(0x20d0d10)
UdpEchoServerApplication:~UdpEchoServer(0x20d0d10)
Recall that the last time we looked at the simulation time at which the packet
was received by the echo server, it was at 2.00369 seconds.
was received by the echo server, it was at 2.0073728 seconds.
.. sourcecode:: bash
2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
+2.007372800s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
Now it is receiving the packet at 2.25732 seconds. This is because we just dropped
the data rate of the ``PointToPointNetDevice`` down to its default of
@@ -598,18 +591,17 @@ in which case we recover the timing we had when we explicitly set the
.. sourcecode:: bash
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.00369s Received 1024 bytes from 10.1.1.1
2.00369s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()
+0.000000000s UdpEchoServerApplication:UdpEchoServer(0x1df20f0)
+1.000000000s UdpEchoServerApplication:StartApplication(0x1df20f0)
At time +2s client sent 1024 bytes to 10.1.1.2 port 9
+2.003686400s UdpEchoServerApplication:HandleRead(0x1df20f0, 0x1de0250)
+2.003686400s At time +2.00369s server received 1024 bytes from 10.1.1.1 port 49153
+2.003686400s Echoing packet
+2.003686400s At time +2.00369s server sent 1024 bytes to 10.1.1.1 port 49153
At time +2.00737s client received 1024 bytes from 10.1.1.2 port 9
+10.000000000s UdpEchoServerApplication:StopApplication(0x1df20f0)
UdpEchoServerApplication:DoDispose(0x1df20f0)
UdpEchoServerApplication:~UdpEchoServer(0x1df20f0)
Note that the packet is again received by the server at 2.00369 seconds. We
could actually set any of the ``Attributes`` used in the script in this way.
@@ -639,7 +631,7 @@ a feature for this. If we ask for command line help we should see:
.. sourcecode:: bash
$ ./ns3 run "scratch/myfirst --PrintHelp"
myfirst [Program Arguments] [General Arguments]
myfirst [General Arguments]
General Arguments:
--PrintGlobals: Print the list of globals.
@@ -647,6 +639,7 @@ a feature for this. If we ask for command line help we should see:
--PrintGroup=[group]: Print all TypeIds of group.
--PrintTypeIds: Print all TypeIds.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintVersion: Print the ns-3 version.
--PrintHelp: Print this help message.
If you select the "PrintGroups" argument, you should see a list of all
@@ -662,7 +655,6 @@ again on the point-to-point module:
TypeIds in group PointToPoint:
ns3::PointToPointChannel
ns3::PointToPointNetDevice
ns3::PointToPointRemoteChannel
ns3::PppHeader
and from here, one can find the possible TypeId names to search for
@@ -713,21 +705,25 @@ Try,
.. sourcecode:: bash
$ ./ns3 build
$ ./ns3 run "scratch/myfirst --PrintHelp"
.. sourcecode:: bash
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.403s)
--PrintHelp: Print this help message.
--PrintGroups: Print the list of groups.
--PrintTypeIds: Print all TypeIds.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintGlobals: Print the list of globals.
User Arguments:
--nPackets: Number of packets to echo
[Program Options] [General Arguments]
Program Options:
--nPackets: Number of packets to echo [1]
General Arguments:
--PrintGlobals: Print the list of globals.
--PrintGroups: Print the list of groups.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintTypeIds: Print all TypeIds.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintVersion: Print the ns-3 version.
--PrintHelp: Print this help message.
If you want to specify the number of packets to echo, you can now do so by
setting the ``--nPackets`` argument in the command line,
@@ -740,25 +736,27 @@ You should now see
.. sourcecode:: bash
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.25732s Received 1024 bytes from 10.1.1.1
2.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
Sent 1024 bytes to 10.1.1.2
3.25732s Received 1024 bytes from 10.1.1.1
3.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()
+0.000000000s UdpEchoServerApplication:UdpEchoServer(0x836e50)
+1.000000000s UdpEchoServerApplication:StartApplication(0x836e50)
At time +2s client sent 1024 bytes to 10.1.1.2 port 9
+2.003686400s UdpEchoServerApplication:HandleRead(0x836e50, 0x8450c0)
+2.003686400s At time +2.00369s server received 1024 bytes from 10.1.1.1 port 49153
+2.003686400s Echoing packet
+2.003686400s At time +2.00369s server sent 1024 bytes to 10.1.1.1 port 49153
At time +2.00737s client received 1024 bytes from 10.1.1.2 port 9
At time +3s client sent 1024 bytes to 10.1.1.2 port 9
+3.003686400s UdpEchoServerApplication:HandleRead(0x836e50, 0x8450c0)
+3.003686400s At time +3.00369s server received 1024 bytes from 10.1.1.1 port 49153
+3.003686400s Echoing packet
+3.003686400s At time +3.00369s server sent 1024 bytes to 10.1.1.1 port 49153
At time +3.00737s client received 1024 bytes from 10.1.1.2 port 9
+10.000000000s UdpEchoServerApplication:StopApplication(0x836e50)
UdpEchoServerApplication:DoDispose(0x836e50)
UdpEchoServerApplication:~UdpEchoServer(0x836e50)
You have now echoed two packets. Pretty easy, isn't it?
You can see that if you are an |ns3| user, you can use the command
line argument system to control global values and ``Attributes``. If you are
a model author, you can add new ``Attributes`` to your ``Objects`` and