From 93c4bbd9ac19c913bd0f3278e4f6325b5c05fba5 Mon Sep 17 00:00:00 2001 From: Tom Henderson Date: Tue, 14 Jun 2022 08:20:50 -0700 Subject: [PATCH] doc: Update stale tutorial information --- doc/tutorial/source/building-topologies.rst | 222 +++++++------- doc/tutorial/source/conceptual-overview.rst | 109 ++----- doc/tutorial/source/getting-started.rst | 45 +-- doc/tutorial/source/introduction.rst | 8 +- doc/tutorial/source/quick-start.rst | 8 +- doc/tutorial/source/tracing.rst | 129 ++++---- doc/tutorial/source/tweaking.rst | 316 ++++++++++---------- 7 files changed, 396 insertions(+), 441 deletions(-) diff --git a/doc/tutorial/source/building-topologies.rst b/doc/tutorial/source/building-topologies.rst index 729c513c6..d30d40211 100644 --- a/doc/tutorial/source/building-topologies.rst +++ b/doc/tutorial/source/building-topologies.rst @@ -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 ************** diff --git a/doc/tutorial/source/conceptual-overview.rst b/doc/tutorial/source/conceptual-overview.rst index 880acf64d..6a8fbd992 100644 --- a/doc/tutorial/source/conceptual-overview.rst +++ b/doc/tutorial/source/conceptual-overview.rst @@ -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 -`_. +`_. 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 -`_, you will find a link to "Documentation" in the navigation bar. If you select this link, you will be +`_, 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 diff --git a/doc/tutorial/source/getting-started.rst b/doc/tutorial/source/getting-started.rst index 2dc4ec761..80c5d7874 100644 --- a/doc/tutorial/source/getting-started.rst +++ b/doc/tutorial/source/getting-started.rst @@ -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" `_ 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. diff --git a/doc/tutorial/source/introduction.rst b/doc/tutorial/source/introduction.rst index ac80f2aba..a7e455030 100644 --- a/doc/tutorial/source/introduction.rst +++ b/doc/tutorial/source/introduction.rst @@ -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 - `_ +* An `app store + `_ * `Contributed Code `_ page, similar to |ns2|'s popular Contributed Code `page `_ -* Use of GitLab.com including issue tracker - `_ +* Documentation on `how to contribute `_ +* Use of Git hosting at GitLab.com including `issue tracker `_ We realize that if you are reading this document, contributing back to the project is probably not your foremost concern at this point, but diff --git a/doc/tutorial/source/quick-start.rst b/doc/tutorial/source/quick-start.rst index c8e816d69..97ba7e0de 100644 --- a/doc/tutorial/source/quick-start.rst +++ b/doc/tutorial/source/quick-start.rst @@ -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 ************************* diff --git a/doc/tutorial/source/tracing.rst b/doc/tutorial/source/tracing.rst index 578b5c145..32c21c103 100644 --- a/doc/tutorial/source/tracing.rst +++ b/doc/tutorial/source/tracing.rst @@ -4,7 +4,7 @@ :format: html latex .. Mimic doxygen formatting for parameter names - + .. raw:: html @@ -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 - + 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 m_myInt; }; @@ -431,7 +431,7 @@ code to connect the source to the sink, which happens in ``main``:: { Ptr myObject = CreateObject (); 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 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 * 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 - 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 - void + void TracedCallback::ConnectWithoutContext ... { Callback cb; @@ -1081,7 +1081,7 @@ instantiated for the declaration above, the compiler will replace :: - void + void TracedCallback::ConnectWithoutContext ... cb { Callback > 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 #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, Address address, uint32_t packetSize, + + void Setup (Ptr 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 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, Address address, uint32_t packetSize, + MyApp::Setup (Ptr 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`` 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 = Create (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 ns3TcpSocket = Socket::CreateSocket (nodes.Get (0), + Ptr 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 file, Ptr p) { @@ -2350,7 +2347,7 @@ and we did this in only 18 lines of code:: } ... - + PcapHelper pcapHelper; Ptr 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 stream, - std::string prefix, + virtual void EnableAsciiInternal (Ptr stream, + std::string prefix, Ptr 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 ``--.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, + virtual void EnablePcapIpv4Internal (std::string prefix, + Ptr 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 stream, - std::string prefix, - Ptr ipv4, + virtual void EnableAsciiIpv4Internal (Ptr stream, + std::string prefix, + Ptr 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); diff --git a/doc/tutorial/source/tweaking.rst b/doc/tutorial/source/tweaking.rst index 073e98527..d25b78319 100644 --- a/doc/tutorial/source/tweaking.rst +++ b/doc/tutorial/source/tweaking.rst @@ -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