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

wrap up tutorial updates

Browse Source
This commit is contained in:
Craig Dowell
2009-03-24 17:53:30 -07:00
parent 0ed62f98e1
commit f2c609494d
6 changed files with 453 additions and 323 deletions
Download Patch File Download Diff File Expand all files Collapse all files

727
doc/tutorial/building-topologies.texi
View File

@@ -53,6 +53,17 @@ example, but we will go over the entire script and examine some of the output.
Just as in the @code{first.cc} example (and in all ns-3 examples) the file
begins with an emacs mode line and some GPL boilerplate.
The actual code begins by loading module include files just as was done in the
@code{first.cc} example.
@verbatim
#include "ns3/core-module.h"
#include "ns3/simulator-module.h"
#include "ns3/node-module.h"
#include "ns3/helper-module.h"
#include "ns3/global-routing-module.h"
@end verbatim
One thing that can be surprisingly useful is a small bit of ASCII art that
shows a cartoon of the network topology constructed in the example. You will
find a similar ``drawing'' in most of our examples.
@@ -75,53 +86,47 @@ three ``extra'' nodes as seen below:
// LAN 10.1.2.0
@end verbatim
The actual code begins by loading module include files just as was done in the
@code{first.cc} example. Then the ns-3 namespace is @code{used} and a logging
component is defined. This is all just as it was in @code{first.cc}, so there
is nothing new yet.
Then the ns-3 namespace is @code{used} and a logging component is defined.
This is all just as it was in @code{first.cc}, so there is nothing new yet.
@verbatim
#include "ns3/core-module.h"
#include "ns3/simulator-module.h"
#include "ns3/node-module.h"
#include "ns3/helper-module.h"
#include "ns3/global-routing-module.h"
@verbatim
using namespace ns3;
NS_LOG_COMPONENT_DEFINE ("SecondScriptExample");
@end verbatim
The main program begins by enabling the @code{UdpEchoClientApplication} and
@code{UdpEchoServerApplication} logging components at @code{INFO} level so
we can see some output when we run the example. This should be entirely
familiar to you so far.
The main program begins with a slightly different twist. We use a verbose
flag to determine whether or not the @code{UdpEchoClientApplication} and
@code{UdpEchoServerApplication} logging components are enabled. This flag
defaults to true (the logging components are enabled) but allows us to turn
off logging during regression testing of this example.
@verbatim
int
main (int argc, char *argv[])
{
LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);
LogComponentEnable("UdpEchoServerApplication", LOG_LEVEL_INFO);
@end verbatim
A fixed seed is provided to the random number generators so that they will
generate repeatable results.
@verbatim
RandomVariable::UseGlobalSeed (1, 1, 2, 3, 5, 8);
@end verbatim
Next, you will see some familiar code that will allow you to change the number
You will see some familiar code that will allow you to change the number
of devices on the CSMA network via command line argument. We did something
similar when we allowed the number of packets sent to be changed in the section
on command line arguments.
on command line arguments. The last line makes sure you have at least one
``extra'' node.
The code consists of variations of previously covered API so you should be
entirely comfortable with the following code at this point in the tutorial.
@verbatim
bool verbose = true;
uint32_t nCsma = 3;
CommandLine cmd;
cmd.AddValue ("nCsma", "Number of \"extra\" CSMA nodes/devices", nCsma);
cmd.AddValue (``nCsma'', ``Number of \"extra\" CSMA nodes/devices'', nCsma);
cmd.AddValue (``verbose'', ``Tell echo applications to log if true'', verbose);
cmd.Parse (argc,argv);
if (verbose)
{
LogComponentEnable(``UdpEchoClientApplication'', LOG_LEVEL_INFO);
LogComponentEnable(``UdpEchoServerApplication'', LOG_LEVEL_INFO);
}
nCsma = nCsma == 0 ? 1 : nCsma;
@end verbatim
The next step is to create two nodes that we will connect via the
@@ -147,7 +152,10 @@ The next line of code @code{Gets} the first node (as in having an index of one)
from the point-to-point node container and adds it to the container of nodes
that will get CSMA devices. The node in question is going to end up with a
point-to-point device @emph{and} a CSMA device. We then create a number of
``extra'' nodes that compose the remainder of the CSMA network.
``extra'' nodes that compose the remainder of the CSMA network. Since we
already have one node in the CSMA network -- the one that will have both a
point-to-point and CSMA net device, the number of ``extra'' nodes means the
number nodes you desire in the CSMA section minus one.
The next bit of code should be quite familiar by now. We instantiate a
@code{PointToPointHelper} and set the associated default attributes so that
@@ -286,7 +294,7 @@ leftmost point-to-point node seen in the topology illustration.
@end verbatim
Since we have actually built an internetwork here, we need some form of
internetwork routing. @command{Ns-3} provides what we call a global route
internetwork routing. @command{ns-3} provides what we call a global route
manager to set up the routing tables on nodes. This route manager has a
global function that runs though the nodes created for the simulation and does
the hard work of setting up routing for you.
@@ -302,15 +310,40 @@ is a one-liner:
GlobalRouteManager::PopulateRoutingTables ();
@end verbatim
The remainder of the script should be very familiar to you. We just enable
pcap tracing, run the simulation and exit the script. Notice that enabling
pcap tracing using the CSMA helper is done in the same way as for the pcap
tracing with the point-to-point helper.
Next we enable pcap tracing. The first line of code to enable pcap tracing
in the point-to-point helper should be familiar to you by now. The second
line enables pcap tracing in the CSMA helper and there is an extra parameter
you haven't encountered yet.
@verbatim
PointToPointHelper::EnablePcapAll ("second");
CsmaHelper::EnablePcap ("second", csmaDevices.Get (0), true);
@end verbatim
The CSMA network is a multi-point-to-point network. This means that there
can (and are in this case) multiple endpoints on a shared medium. Each of
these endpoints has a net device associated with it. There are two basic
alternatives to gathering trace information from such a network. One way
is to create a trace file for each net device and store only the packets
that are emitted or consumed by that net device. Another way is to pick
one of the devices and place it in promiscuous mode. That single device
then ``sniffs'' the network for all packets and stores them in a single
pcap file. This is how @code{tcpdump}, for example, works. That final
parameter tells the CSMA helper whether or not to capture packets in
promiscuous mode.
In this example, we are going to select one of the devices on the CSMA
network and ask it to perform a promiscuous sniff of the network, thereby
emulating what @code{tcpdump} would do. If you were on a Linux machine
you might do something like @code{tcpdump -i eth0} to get the trace.
In this case, we specify the device using @code{csmaDevices.Get(0)},
which selects the zeroth device in the container. Setting the final
parameter to true enables promiscuous captures.
The last section of code just runs and cleans up the simulation just like
the @code{first.cc} example.
@verbatim
PointToPointHelper::EnablePcapAll ("second");
CsmaHelper::EnablePcapAll ("second");
Simulator::Run ();
Simulator::Destroy ();
return 0;
@@ -318,27 +351,40 @@ tracing with the point-to-point helper.
@end verbatim
In order to run this example, you have to copy the @code{second.cc} example
script into the scratch directory and use Waf to build just as you did with
script into the scratch directory and use waf to build just as you did with
the @code{first.cc} example. If you are in the top-level directory of the
repository you would type,
@verbatim
cp examples/second.cc scratch/
cp examples/second.cc scratch/mysecond.cc
./waf
./waf --run scratch/second
@end verbatim
Warning: We use the file @code{second.cc} as one of our regression tests to
verify that it works exactly as we think it should in order to make your
tutorial experience a positive one. This means that an executable named
@code{second} already exists in the project. To avoid any confusion
about what you are executing, please do the renaming to @code{mysecond.cc}
suggested above.
If you are following the tutorial religiously (you are, aren't you) you will
still have the NS_LOG variable set, so go ahead and clear that variable and
run the program.
@verbatim
export NS_LOG=
./waf --run scratch/mysecond
#end verbatim
Since we have set up the UDP echo applications to log just as we did in
@code{first.cc}, you will see similar output when you run the script.
@verbatim
~/repos/ns-3-dev > ./waf --run scratch/second
Entering directory `/home/craigdo/repos/ns-3-dev/build'
Compilation finished successfully
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
Build finished successfully (00:00:00)
Sent 1024 bytes to 10.1.2.4
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.2.4
~/repos/ns-3-dev >
@end verbatim
Recall that the first message, @code{Sent 1024 bytes to 10.1.2.4} is the
@@ -349,38 +395,41 @@ the echo packet. The final message, @code{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 a number of
trace files:
If you now go and look in the top level directory, you will find two trace
files:
@verbatim
~/repos/ns-3-dev > ls *.pcap
second-0-0.pcap second-1-1.pcap second-3-0.pcap
second-1-0.pcap second-2-0.pcap second-4-0.pcap
~/repos/ns-3-dev >
second-0-0.pcap second-1-0.pcap second-2-0.pcap
@end verbatim
Let's take a moment to look at the naming of these files. They all have the
same form, @code{<name>-<node>-<device>.pcap}. For example, the first file
in the listing is @code{second-0-0.pcap} which is the pcap trace from node
zero - device zero. There are no other devices on node zero so this is the
only trace from that node.
zero, device zero. This is the point-to-point net device on node zero. The
file @code{second-1-0.pcap} is the pcap trace for device zero on node one,
also a point-to-point net device; and the file @code{second-2-0.pcap} is the
pcap trace for device zero on node two.
Now look at @code{second-1-0.pcap} and @code{second-1-1.pcap}. The former is
the pcap trace for device zero on node one and the latter is the trace file
for device one on node one. If you refer back to the topology illustration at
the start of the section, you will see that node one is the node that has
both a point-to-point device and a CSMA device, so we should expect two pcap
traces for that node.
If you refer back to the topology illustration at the start of the section,
you will see that node zero is the leftmost node of the point-to-point link
and node one is the node that has both a point-to-point device and a CSMA
device. You will see that node two is the first ``extra'' node on the CSMA
network and its device zero was selected as the device to capture the
promiscuous-mode trace.
Now, let's follow the echo packet through the internetwork. First, do a
tcpdump of the trace file for the leftmost point-to-point node --- node zero.
@verbatim
~/repos/ns-3-dev > tcpdump -r second-0-0.pcap -nn -tt
tcpdump -nn -tt -r second-0-0.pcap
@end verbatim
You should see the contents of the pcap file displayed:
@verbatim
reading from file second-0-0.pcap, link-type PPP (PPP)
2.000000 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
2.007382 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024
~/repos/ns-3-dev >
2.007602 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024
@end verbatim
The first line of the dump indicates that the link type is PPP (point-to-point)
@@ -391,134 +440,163 @@ point-to-point link and be received by the point-to-point net device on node
one. Let's take a look:
@verbatim
~/repos/ns-3-dev > tcpdump -r second-1-0.pcap -nn -tt
reading from file second-1-0.pcap, link-type PPP (PPP)
2.003686 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
2.003695 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024
~/repos/ns-3-dev >
tcpdump -nn -tt -r second-1-0.pcap
@end verbatim
You should now see the pcap trace output of the other side of the point-to-point
link:
@verbatim
reading from file second-1-0.pcap, link-type PPP (PPP)
2.003686 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
2.003915 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024
@end verbatim
Here we see that the link type is also PPP as we would expect. You see the
packet from IP address 10.1.1.1 headed toward 10.1.2.4 appear on this
interface. Now, internally to this node, the packet will be forwarded to the
CSMA interface and we should see it pop out the other device headed for its
ultimate destination. Let's then look at second-1-1.pcap and see if its there.
packet from IP address 10.1.1.1 (that was sent at 2.000000 seconds) headed
toward IP address 10.1.2.4 appear on this interface. Now, internally to this
node, the packet will be forwarded to the CSMA interface and we should see it
pop out on that device headed for its ultimate destination.
Remember that we selected node 2 as the promiscuous sniffer node for the CSMA
network so let's then look at second-2-0.pcap and see if its there.
@verbatim
~/repos/ns-3-dev > tcpdump -r second-1-1.pcap -nn -tt
reading from file second-1-1.pcap, link-type EN10MB (Ethernet)
2.003686 arp who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
2.003687 arp reply 10.1.2.4 is-at 00:00:00:00:00:06
2.003687 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
2.003691 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4
2.003691 arp reply 10.1.2.1 is-at 00:00:00:00:00:03
2.003695 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024
~/repos/ns-3-dev >
tcpdump -nn -tt -r second-2-0.pcap
@end verbatim
You should now see the promiscuous dump of node two, device zero:
@verbatim
reading from file second-2-0.pcap, link-type EN10MB (Ethernet)
2.003696 arp who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
2.003707 arp reply 10.1.2.4 is-at 00:00:00:00:00:06
2.003801 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
2.003811 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4
2.003822 arp reply 10.1.2.1 is-at 00:00:00:00:00:03
2.003915 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024
@end verbatim
As you can see, the link type is now ``Ethernet''. Something new has appeared,
though. The bus network needs @code{ARP}, the Address Resolution Protocol.
The node knows it needs to send the packet to IP address 10.1.2.4, but it
Node one knows it needs to send the packet to IP address 10.1.2.4, but it
doesn't know the MAC address of the corresponding node. It broadcasts on the
CSMA network (ff:ff:ff:ff:ff:ff) asking for the device that has IP address
10.1.2.4. In this case, the rightmost node replies saying it is at MAC address
00:00:00:00:00:06. This exchange is seen in the following lines,
00:00:00:00:00:06. (Note that node two is not directly involved in this
exchange, but is sniffing the network and reporting all of the traffic it sees.)
This exchange is seen in the following lines,
@verbatim
2.003686 arp who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
2.003687 arp reply 10.1.2.4 is-at 00:00:00:00:00:06
2.003696 arp who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
2.003707 arp reply 10.1.2.4 is-at 00:00:00:00:00:06
@end verbatim
Then node one, device one goes ahead and sends the echo packet to the UDP echo
server at IP address 10.1.2.4. We can now look at the pcap trace for the
echo server,
server at IP address 10.1.2.4.
@verbatim
~/repos/ns-3-dev > tcpdump -r second-4-0.pcap -nn -tt
reading from file second-4-0.pcap, link-type EN10MB (Ethernet)
2.003686 arp who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
2.003686 arp reply 10.1.2.4 is-at 00:00:00:00:00:06
2.003690 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
2.003690 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4
2.003692 arp reply 10.1.2.1 is-at 00:00:00:00:00:03
2.003692 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024
~/repos/ns-3-dev >
2.003801 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
@end verbatim
Again, you see that the link type is ``Ethernet''. The first two entries are
the ARP exchange we just explained. The third packet is the echo packet
being delivered to its final destination.
The echo server turns the packet around and needs to send it back to the echo
client on 10.1.1.1 but it knows that this address is on another network that
it reaches via IP address 10.1.2.1. This is because we initialized global
The server receives the echo request and turns the packet around trying to send
it back to the source. The server knows that this address is on another network
that it reaches via IP address 10.1.2.1. This is because we initialized global
routing and it has figured all of this out for us. But, the echo server node
doesn't know the MAC address of the first CSMA node, so it has to ARP for it
just like the first CSMA node had to do. We leave it as an exercise for you
to find the entries corresponding to the packet returning back on its way to
the client (we have already dumped the traces and you can find them in those
tcpdumps above.
Let's take a look at one of the CSMA nodes that wasn't involved in the packet
exchange:
just like the first CSMA node had to do.
@verbatim
~/repos/ns-3-dev > tcpdump -r second-2-0.pcap -nn -tt
reading from file second-2-0.pcap, link-type EN10MB (Ethernet)
2.003686 arp who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
2.003691 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4
~/repos/ns-3-dev >
2.003811 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4
2.003822 arp reply 10.1.2.1 is-at 00:00:00:00:00:03
@end verbatim
You can see that the CSMA channel is a broadcast medium and so all of the
devices see the ARP requests involved in the packet exchange. The remaining
pcap trace will be identical to this one.
The server then sends the echo back to the forwarding node.
@verbatim
2.003915 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024
@end verbatim
Looking back at the rightmost node of the point-to-point link,
@verbatim
tcpdump -nn -tt -r second-1-0.pcap
@end verbatim
You can now see the echoed packet coming back onto the point-to-point link as
the last line of the trace dump.
@verbatim
reading from file second-1-0.pcap, link-type PPP (PPP)
2.003686 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
2.003915 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024
@end verbatim
Lastly, you can look back at the node that originated the echo
@verbatim
tcpdump -nn -tt -r second-0-0.pcap
@end verbatim
and see that the echoed packet arrives back at the source at 2.007602 seconds,
@verbatim
reading from file second-0-0.pcap, link-type PPP (PPP)
2.000000 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
2.007602 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024
@end verbatim
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
@code{first.cc} example. Try setting the number of ``extra'' devices to four:
@code{first.cc} example. Try running the program with the number of ``extra''
devices set to four:
@verbatim
~/repos/ns-3-dev > ./waf --run "scratch/second --nCsma=4"
Entering directory `/home/craigdo/repos/ns-3-dev/build'
Compilation finished successfully
./waf --run "scratch/mysecond --nCsma=4"
@end verbatim
You should now see,
@verbatim
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
Build finished successfully (00:00:00)
Sent 1024 bytes to 10.1.2.5
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.2.5
~/repos/ns-3-dev >
@end verbatim
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. You can
increase the number to your hearts content, but remember that you will get a
pcap trace file for every node in the simulation. One thing you can do to
keep from getting all of those pcap traces with nothing but ARP exchanges in
them is to be more specific about which nodes and devices you want to trace.
nodes, which is 10.1.2.5 instead of the default case, 10.1.2.4.
Let's take a look at @code{scratch/second.cc} and add that code enabling us
to be more specific. The file we provided used the @code{EnablePcapAll}
methods of the helpers to enable pcap on all devices. We now want to use the
more specific method, @code{EnablePcap}, which takes a node number and device
number as parameters. Go ahead and replace the @code{EnablePcapAll} calls
with the calls below.
It is possible that you may not be satisfied with a trace file generated by
a bystander in the CSMA network. You may really want to get a trace from
a single device and you may not be interested in any other traffic on the
network. You can do this,
Let's take a look at @code{scratch/mysecond.cc} and add that code enabling us
to be more specific. @code{ns-3} helpers provide methods that take a node
number and device number as parameters. Go ahead and replace the
@code{EnablePcap} calls with the calls below.
@verbatim
PointToPointHelper::EnablePcap ("second", p2pNodes.Get (0)->GetId (), 0);
CsmaHelper::EnablePcap ("second", csmaNodes.Get (nCsma)->GetId (), 0);
CsmaHelper::EnablePcap ("second", csmaNodes.Get (nCsma)->GetId (), 0, false);
CsmaHelper::EnablePcap ("second", csmaNodes.Get (nCsma-1)->GetId (), 0, false);
@end verbatim
We know that we want to create a pcap file with the base name "second" and
we also know that the device of interest in both cases is going to be zero,
so those parameters are not really interesting. In order to get the node
number, you have two choices: first, nodes are numbered in a monotonically
increasing fashion starting from zero in the order in which you created them.
One way to get a node number is to figure this number out ``manually'' by
contemplating the order of node creation. If you take a look at the network
topology illustration at the beginning of the file, we did this for you and
you can see that the last CSMA node is going to be node number
@code{nCsma + 1}. This approach can become annoyingly difficult in larger
simulations.
so those parameters are not really interesting.
In order to get the node number, you have two choices: first, nodes are
numbered in a monotonically increasing fashion starting from zero in the
order in which you created them. One way to get a node number is to figure
this number out ``manually'' by contemplating the order of node creation.
If you take a look at the network topology illustration at the beginning of
the file, we did this for you and you can see that the last CSMA node is
going to be node number @code{nCsma + 1}. This approach can become
annoyingly difficult in larger simulations.
An alternate way, which we use here, is to realize that the
@code{NodeContainers} contain pointers to @command{ns-3} @code{Node} Objects.
@@ -537,35 +615,54 @@ to the documentation for the @code{Node} class. If you now scroll down to the
documentation for the method. Using the @code{GetId} method can make
determining node numbers much easier in complex topologies.
Now that we have got some trace filtering in place, it is reasonable to start
increasing the number of CSMA devices in our simulation. If you build the
new script and run the simulation setting @code{nCsma} to 100, you will see
the following output:
If you build the new script and run the simulation setting @code{nCsma} to 100,
@verbatim
~/repos/ns-3-dev > ./waf --run "scratch/second --nCsma=100"
Entering directory `/home/craigdo/repos/ns-3-dev/build'
Compilation finished successfully
./waf --run "scratch/mysecond --nCsma=100"
@end verbatim
you will see the following output:
@verbatim
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
Build finished successfully (00:00:00)
Sent 1024 bytes to 10.1.2.101
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.2.101
~/repos/ns-3-dev >
@end verbatim
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
list the pcap files in the top level directory,
list the pcap files in the top level directory you will see,
@verbatim
~/repos/ns-3-dev > ls *.pcap
second-0-0.pcap second-101-0.pcap
~/repos/ns-3-dev >
second-0-0.pcap second-100-0.pcap second-101-0.pcap
@end verbatim
you will see that we have, in fact, only created two trace files. The trace
file @code{second-0-0.pcap} is the ``leftmost'' point-to-point device which is
the echo packet source. The file @code{second-101-0.pcap} corresponds to the
rightmost CSMA device which is where the echo server resides.
The trace file @code{second-0-0.pcap} is the ``leftmost'' point-to-point device
which is the echo packet source. The file @code{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.
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
take a look at the @code{tcpdump} for @code{second-10-0.pcap}.
@verbatim
tcpdump -nn -tt -r second-100-0.pcap
@end verbatim
You can now see that node 100 is really a bystander in the echo exchange. The
only packets that it receives are the ARP requests which are broadcast to the
entire CSMA network.
@verbatim
reading from file second-100-0.pcap, link-type EN10MB (Ethernet)
2.003696 arp who-has 10.1.2.101 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
2.003811 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.101
@end verbatim
@c ========================================================================
@c Building a Wireless Network Topology
@@ -651,36 +748,27 @@ component is defined. This should all be quite familiar by now.
NS_LOG_COMPONENT_DEFINE ("ThirdScriptExample");
@end verbatim
As has become the norm in this tutorial, the main program begins by enabling
the @code{UdpEchoClientApplication} and @code{UdpEchoServerApplication}
logging components at @code{INFO} level so we can see some output when we run
the simulation.
@verbatim
int
main (int argc, char *argv[])
{
LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);
LogComponentEnable("UdpEchoServerApplication", LOG_LEVEL_INFO);
@end verbatim
A fixed seed is provided to the random number generators so that they will
generate repeatable results.
@verbatim
RandomVariable::UseGlobalSeed (1, 1, 2, 3, 5, 8);
@end verbatim
Next, you will see more familiar code that will allow you to change the number
of devices on the CSMA and Wifi networks via command line argument.
The main program begins just like @code{second.cc} by adding some command line
parameters for enabling or disabling logging components and for changing the
number of devices created.
@verbatim
bool verbose = true;
uint32_t nCsma = 3;
uint32_t nWifi = 3;
CommandLine cmd;
cmd.AddValue ("nCsma", "Number of \"extra\" CSMA nodes/devices", nCsma);
cmd.AddValue ("nWifi", "Number of wifi STA devices", nWifi);
cmd.AddValue (``nCsma'', ``Number of \"extra\" CSMA nodes/devices'', nCsma);
cmd.AddValue (``nWifi'', ``Number of wifi STA devices'', nWifi);
cmd.AddValue (``verbose'', ``Tell echo applications to log if true'', verbose);
cmd.Parse (argc,argv);
if (verbose)
{
LogComponentEnable(``UdpEchoClientApplication'', LOG_LEVEL_INFO);
LogComponentEnable(``UdpEchoServerApplication'', LOG_LEVEL_INFO);
}
@end verbatim
Just as in all of the previous examples, the next step is to create two nodes
@@ -775,7 +863,6 @@ Once the PHY helper is configured, we can focus on the MAC layer:
wifi.SetRemoteStationManager ("ns3::AarfWifiManager");
@end verbatim
The @code{SetRemoteStationManager} method tells the helper the type of
rate control algorithm to use. Here, it is asking the helper to use the AARF
algorithm --- details are, of course, available in Doxygen.
@@ -873,10 +960,10 @@ STA nodes.
We want the access point to remain in a fixed position during the simulation.
We accomplish this by setting the mobility model for this node to be the
@code{ns3::StaticMobilityModel}:
@code{ns3::ConstantPositionMobilityModel}:
@verbatim
mobility.SetMobilityModel ("ns3::StaticMobilityModel");
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (wifiApNode);
@end verbatim
@@ -960,18 +1047,20 @@ loop.
Simulator::Stop (Seconds (10.0));
@end verbatim
We use the same trick as in the @code{second.cc} script to only generate
pcap traces from the nodes we find interesting. Note that we use the same
``formula'' to get pcap tracing enabled on Wifi devices as we did on the
CSMA and point-to-point devices.
We create just enough tracing to cover all three networks:
@verbatim
WifiHelper::EnablePcap ("third",
wifiStaNodes.Get (nWifi - 1)->GetId (), 0);
CsmaHelper::EnablePcap ("third",
csmaNodes.Get (nCsma)->GetId (), 0);
PointToPointHelper::EnablePcapAll ("third");
YansWifiPhyHelper::EnablePcap ("third", apDevices.Get (0));
CsmaHelper::EnablePcap ("third", csmaDevices.Get (0), true);
@end verbatim
These three lines of code will start pcap tracing on both of the point-to-point
nodes that serves as our backbone, will start a promiscuous (monitor) mode
trace on the Wifi network, and will start a promiscuous trace on the CSMA
network. This will let us see all of the traffic with a minimum number of
trace files.
Finally, we actually run the simulation, clean up and then exit the program.
@verbatim
@@ -987,22 +1076,20 @@ the @code{second.cc} example. If you are in the top-level directory of the
repository you would type,
@verbatim
cp examples/third.cc scratch/
cp examples/third.cc scratch/mythird.cc
./waf
./waf --run scratch/third
./waf --run scratch/mythird
@end verbatim
Since we have set up the UDP echo applications just as we did in the
@code{second.cc} script, you will see similar output.
@verbatim
~/repos/ns-3-dev > ./waf --run scratch/third
Entering directory `/home/craigdo/repos/ns-3-dev/build'
Compilation finished successfully
Entering directory `repos/ns-3-allinone-dev/ns-3-dev/build'
Build finished successfully (00:00:00)
Sent 1024 bytes to 10.1.2.4
Received 1024 bytes from 10.1.3.3
Received 1024 bytes from 10.1.2.4
~/repos/ns-3-dev >
@end verbatim
Recall that the first message, @code{Sent 1024 bytes to 10.1.2.4} is the
@@ -1013,74 +1100,123 @@ generated when it receives the echo packet. The final message,
@code{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 two trace
files:
If you now go and look in the top level directory, you will find four trace
files, two from node zero and two from node one:
@verbatim
~/repos/ns-3-dev > ls *.pcap
third-4-0.pcap third-7-0.pcap
~/repos/ns-3-dev >
third-0-0.pcap third-0-1.pcap third-1-0.pcap third-1-1.pcap
@end verbatim
The file ``third-4-0.pcap'' corresponds to the pcap trace for node four -
device zero. This is the CSMA network node that acted as the echo server.
Take a look at the tcpdump for this device:
The file ``third-0-0.pcap'' corresponds to the point-to-point device on node
zero -- the left side of the ``backbone.'' The file ``third-1-0.pcap''
corresponds to the point-to-point device on node one -- the right side of the
``backbone.'' The file ``third-0-1.pcap'' will be the promiscuous (monitor
mode) trace from the Wifi network and the file ``third-1-1.pcap'' will be the
promiscuous trace from the CSMA network. Can you verify this by inspecting
the code?
Since the echo client is on the Wifi network, let's start there. Let's take
a look at the promiscuous (monitor mode) trace we captured on that network.
@verbatim
~/repos/ns-3-dev > tcpdump -r third-4-0.pcap -nn -tt
reading from file third-4-0.pcap, link-type EN10MB (Ethernet)
tcpdump -nn -tt -r third-0-1.pcap
@end verbatim
You should see some wifi-looking contents you haven't seen here before:
@verbatim
reading from file third-0-1.pcap, link-type IEEE802_11 (802.11)
0.000025 Beacon () [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS
0.000263 Assoc Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit]
0.000279 Acknowledgment RA:00:00:00:00:00:07
0.000357 Assoc Response AID(0) :: Succesful
0.000501 Acknowledgment RA:00:00:00:00:00:0a
0.000748 Assoc Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit]
0.000764 Acknowledgment RA:00:00:00:00:00:08
0.000842 Assoc Response AID(0) :: Succesful
0.000986 Acknowledgment RA:00:00:00:00:00:0a
0.001242 Assoc Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit]
0.001258 Acknowledgment RA:00:00:00:00:00:09
0.001336 Assoc Response AID(0) :: Succesful
0.001480 Acknowledgment RA:00:00:00:00:00:0a
2.000112 arp who-has 10.1.3.4 (ff:ff:ff:ff:ff:ff) tell 10.1.3.3
2.000128 Acknowledgment RA:00:00:00:00:00:09
2.000206 arp who-has 10.1.3.4 (ff:ff:ff:ff:ff:ff) tell 10.1.3.3
2.000487 arp reply 10.1.3.4 is-at 00:00:00:00:00:0a
2.000659 Acknowledgment RA:00:00:00:00:00:0a
2.002169 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
2.002185 Acknowledgment RA:00:00:00:00:00:09
2.009771 arp who-has 10.1.3.3 (ff:ff:ff:ff:ff:ff) tell 10.1.3.4
2.010029 arp reply 10.1.3.3 is-at 00:00:00:00:00:09
2.010045 Acknowledgment RA:00:00:00:00:00:09
2.010231 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
2.011767 Acknowledgment RA:00:00:00:00:00:0a
2.500000 Beacon () [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS
5.000000 Beacon () [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS
7.500000 Beacon () [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS
@end verbatim
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
packets in this trace. We leave it as an exercise to completely parse the
trace dump.
Now, look at the pcap file of the right side of the point-to-point link,
@verbatim
tcpdump -nn -tt -r third-0-0.pcap
@end verbatim
Again, you should see some familiar looking contents:
@verbatim
reading from file third-0-0.pcap, link-type PPP (PPP)
2.002169 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
2.009771 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
@end verbatim
This is the echo packet going from left to right (from Wifi to CSMA) and back
again across the point-to-point link.
Now, look at the pcap file of the right side of the point-to-point link,
@verbatim
tcpdump -nn -tt -r third-1-0.pcap
@end verbatim
Again, you should see some familiar looking contents:
@verbatim
reading from file third-1-0.pcap, link-type PPP (PPP)
2.005855 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
2.006084 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
@end verbatim
This is also the echo packet going from left to right (from Wifi to CSMA) and
back again across the point-to-point link with slightly different timings
as you might expect.
The echo server is on the CSMA network, let's look at the promiscuous trace
there:
@verbatim
tcpdump -nn -tt -r third-1-1.pcap
@end verbatim
You should see some familiar looking contents:
@verbatim
reading from file third-1-1.pcap, link-type EN10MB (Ethernet)
2.005855 arp who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
2.005855 arp reply 10.1.2.4 is-at 00:00:00:00:00:06
2.005859 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
2.005859 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4
2.005861 arp reply 10.1.2.1 is-at 00:00:00:00:00:03
2.005861 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
~/repos/ns-3-dev >
2.005877 arp reply 10.1.2.4 is-at 00:00:00:00:00:06
2.005877 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
2.005980 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4
2.005980 arp reply 10.1.2.1 is-at 00:00:00:00:00:03
2.006084 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
@end verbatim
This should be familiar and easily understood. If you've forgotten, go back
and look at the discussion in @code{second.cc}. This is the same sequence.
Now, take a look at the other trace file, ``third-7-0.pcap.'' This is the
trace file for the wireless STA node that acts as the echo client.
@verbatim
~/repos/ns-3-dev > tcpdump -r third-7-0.pcap -nn -tt
reading from file third-7-0.pcap, link-type IEEE802_11 (802.11)
0.000146 Beacon (ns-3-ssid) ...
H: 0
0.000180 Assoc Request (ns-3-ssid) ...
0.000336 Acknowledgment RA:00:00:00:00:00:07
0.000454 Assoc Response AID(0) :: Succesful
0.000514 Acknowledgment RA:00:00:00:00:00:0a
0.000746 Assoc Request (ns-3-ssid) ...
0.000902 Acknowledgment RA:00:00:00:00:00:09
0.001020 Assoc Response AID(0) :: Succesful
0.001036 Acknowledgment RA:00:00:00:00:00:0a
0.001219 Assoc Request (ns-3-ssid) ...
0.001279 Acknowledgment RA:00:00:00:00:00:08
0.001478 Assoc Response AID(0) :: Succesful
0.001538 Acknowledgment RA:00:00:00:00:00:0a
2.000000 arp who-has 10.1.3.4 (ff:ff:ff:ff:ff:ff) tell 10.1.3.3
2.000172 Acknowledgment RA:00:00:00:00:00:09
2.000318 arp who-has 10.1.3.4 (ff:ff:ff:ff:ff:ff) tell 10.1.3.3
2.000581 arp reply 10.1.3.4 is-at 00:00:00:00:00:0a
2.000597 Acknowledgment RA:00:00:00:00:00:0a
2.000693 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
2.002229 Acknowledgment RA:00:00:00:00:00:09
2.009663 arp who-has 10.1.3.3 (ff:ff:ff:ff:ff:ff) tell 10.1.3.4
2.009697 arp reply 10.1.3.3 is-at 00:00:00:00:00:09
2.009869 Acknowledgment RA:00:00:00:00:00:09
2.011487 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
2.011503 Acknowledgment RA:00:00:00:00:00:0a
2.500112 Beacon[|802.11]
5.000112 Beacon[|802.11]
7.500112 Beacon[|802.11]
~/repos/ns-3-dev >
@end verbatim
You can see that the link type is now 802.11 as you would expect. We leave
it as an exercise to parse the dump and trace packets across the internetwork.
This should be easily understood. If you've forgotten, go back and look at
the discussion in @code{second.cc}. This is the same sequence.
Now, we spent a lot of time setting up mobility models for the wireless network
and so it would be a shame to finish up without even showing that the STA
@@ -1088,13 +1224,13 @@ nodes are actually moving around. Let's do this by hooking into the
@code{MobilityModel} course change trace source. This is usually considered
a fairly advanced topic, but let's just go for it.
As mentioned in the Tweaking Ns-3 section, the @command{ns-3} tracing system
As mentioned in the ``Tweaking ns-3'' section, the @command{ns-3} tracing system
is divided into trace sources and trace sinks, and we provide functions to
connect the two. We will use the mobility model predefined course change
trace source to originate the trace events. We will need to write a trace
sink to connect to that source that will display some pretty information for
us. Despite its reputation as being difficult, it's really quite simple.
Just before the main program of the @code{scratch/third.cc} script, add the
Just before the main program of the @code{scratch/mythird.cc} script, add the
following function:
@verbatim
@@ -1150,41 +1286,40 @@ If you now run the simulation, you will see the course changes displayed as
they happen.
@verbatim
~/repos/ns-3-dev > ./waf --run scratch/third
Entering directory `/home/craigdo/repos/ns-3-dev/build'
Compilation finished successfully
Build finished successfully (00:00:01)
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10, y = 0
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.1304, y = 0.493761
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.70417, y = 1.39837
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.94799, y = 2.05274
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.82597, y = 1.57404
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.3003, y = 0.723347
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.41539, y = -0.811313
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.46199, y = -1.11303
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.52738, y = -1.46869
/NodeList/7/$ns3::MobilityModel/CourseChange x = 6.67099, y = -1.98503
/NodeList/7/$ns3::MobilityModel/CourseChange x = 5.6835, y = -2.14268
/NodeList/7/$ns3::MobilityModel/CourseChange x = 4.70932, y = -1.91689
Sent 1024 bytes to 10.1.2.4
Received 1024 bytes from 10.1.3.3
Received 1024 bytes from 10.1.2.4
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.74083, y = 1.62109
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.00146, y = 0.655647
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.98731, y = 0.823279
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.50206, y = 1.69766
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.68108, y = 2.26862
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.25992, y = 1.45317
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.55655, y = 0.742346
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.21992, y = 1.68398
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.81273, y = 0.878638
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.83171, y = 1.07256
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.60027, y = 0.0997156
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.45367, y = 0.620978
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.68484, y = 1.26043
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.53659, y = 0.736479
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.51876, y = 0.548502
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.89778, y = 1.47389
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.98984, y = 1.893
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.91524, y = 1.51402
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.98761, y = 1.14054
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.16617, y = 0.570239
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.02954, y = 1.56086
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.09551, y = 2.55868
~/repos/ns-3-dev >
/NodeList/7/$ns3::MobilityModel/CourseChange x = 5.53175, y = -2.48576
/NodeList/7/$ns3::MobilityModel/CourseChange x = 4.58021, y = -2.17821
/NodeList/7/$ns3::MobilityModel/CourseChange x = 4.18915, y = -1.25785
/NodeList/7/$ns3::MobilityModel/CourseChange x = 4.7572, y = -0.434856
/NodeList/7/$ns3::MobilityModel/CourseChange x = 4.62404, y = 0.556238
/NodeList/7/$ns3::MobilityModel/CourseChange x = 4.74127, y = 1.54934
/NodeList/7/$ns3::MobilityModel/CourseChange x = 5.73934, y = 1.48729
/NodeList/7/$ns3::MobilityModel/CourseChange x = 6.18521, y = 0.59219
/NodeList/7/$ns3::MobilityModel/CourseChange x = 6.58121, y = 1.51044
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.27897, y = 2.22677
/NodeList/7/$ns3::MobilityModel/CourseChange x = 6.42888, y = 1.70014
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.40519, y = 1.91654
/NodeList/7/$ns3::MobilityModel/CourseChange x = 6.51981, y = 1.45166
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.34588, y = 2.01523
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.81046, y = 2.90077
/NodeList/7/$ns3::MobilityModel/CourseChange x = 6.89186, y = 3.29596
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.46617, y = 2.47732
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.05492, y = 1.56579
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.00393, y = 1.25054
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.00968, y = 1.35768
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.33503, y = 2.30328
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.18682, y = 3.29223
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.96865, y = 2.66873
@end verbatim
If you are feeling brave, there is a list of all trace sources in the

12
doc/tutorial/conceptual-overview.texi
View File

@@ -726,13 +726,7 @@ the @code{scratch} directory.
~/repos/ns-3-dev > cp examples/first.cc scratch/myfirst.cc
@end verbatim
Warning: We use the file @code{first.cc} as one of our regression tests to
verify that it works exactly as we expect. This means that an executable
named @code{first} already exists in the project. If you want to execute
what you compile, and not a previously compiled program, please do the
renaming suggested below.)
Now build your example using Waf:
Now build your first example script using waf:
@verbatim
./waf
@@ -742,7 +736,7 @@ You should see messages reporting that your @code{myfirst} example was built
successfully.
@verbatim
Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
Entering directory `repos/ns-3-allinone-dev/ns-3-dev/build'
[563/648] cxx: scratch/myfirst.cc -> build/debug/scratch/myfirst_3.o
[646/648] cxx_link: build/debug/scratch/myfirst_3.o -> build/debug/scratch/myfirst
Build finished successfully (00:00:02)
@@ -758,7 +752,7 @@ directory you must run it out of the scratch directory):
You should see some output:
@verbatim
Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
Entering directory `repos/ns-3-allinone-dev/ns-3-dev/build'
Build finished successfully (00:00:00)
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1

4
doc/tutorial/getting-started.texi
View File

@@ -446,7 +446,7 @@ You should see a report from each unit test that executes indicating that the
test has passed.
@verbatim
Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
Build finished successfully (00:00:00)
-- Running NS-3 C++ core unit tests...
PASS AddressHelper
@@ -499,7 +499,7 @@ You should see messages indicating that many tests are being run and are
passing.
@verbatim
Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
[647/669] regression-test (test-csma-bridge)
[648/669] regression-test (test-csma-broadcast)
[649/669] regression-test (test-csma-multicast)

20
doc/tutorial/tweaking.texi
View File

@@ -99,7 +99,7 @@ You should see the now familiar output of the first @command{ns-3} example
program
@verbatim
Entering directory `/home/craigdo/repos/ns-3-dev/build'
Entering directory `repos/ns-3-dev/build'
Compilation finished successfully
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
@@ -148,7 +148,7 @@ you run the script with NS_LOG set this way, the @command{ns-3} logging
system will pick up the change and you should see the following output:
@verbatim
Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
Build finished successfully (00:00:00)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:StartApplication()
@@ -201,7 +201,7 @@ that every message from the given log component is prefixed with the component
name.
@verbatim
Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
Build finished successfully (00:00:00)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:StartApplication()
@@ -236,7 +236,7 @@ echo client and server applications. You may see that this can be very useful
in debugging problems.
@verbatim
Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
Build finished successfully (00:00:00)
UdpEchoServerApplication:UdpEchoServer()
UdpEchoClientApplication:UdpEchoClient()
@@ -269,7 +269,7 @@ Again, you will have to remove the newline above. If you run the script now,
you should see the following output:
@verbatim
Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
Build finished successfully (00:00:00)
0s UdpEchoServerApplication:UdpEchoServer()
0s UdpEchoClientApplication:UdpEchoClient()
@@ -399,7 +399,7 @@ If you now run the script you will see your new ``Creating Topology'' log
message,
@verbatim
Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
Build finished successfully (00:00:00)
Creating Topology
Sent 1024 bytes to 10.1.1.2
@@ -453,7 +453,7 @@ sort out which program gets which argument. The command line parser will
now see the @code{--PrintHelp} argument and respond with,
@verbatim
Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
Build finished successfully (00:00:00)
--PrintHelp: Print this help message.
--PrintGroups: Print the list of groups.
@@ -589,7 +589,7 @@ in which case we recover the timing we had when we explicitly set the
@code{DataRate} and @code{Delay} in the script:
@verbatim
Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
Build finished successfully (00:00:00)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
@@ -666,7 +666,7 @@ Try,
@end verbatim
@verbatim
Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
Build finished successfully (00:00:00)
--PrintHelp: Print this help message.
--PrintGroups: Print the list of groups.
@@ -688,7 +688,7 @@ setting the @code{--nPackets} argument in the command line,
You should now see
@verbatim
Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
Entering directory `repos/ns-3-allinone/ns-3-dev/build'
Build finished successfully (00:00:00)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()

8
examples/second.cc
View File

@@ -37,8 +37,8 @@ int
main (int argc, char *argv[])
{
bool verbose = true;
uint32_t nCsma = 3;
CommandLine cmd;
cmd.AddValue ("nCsma", "Number of \"extra\" CSMA nodes/devices", nCsma);
cmd.AddValue ("verbose", "Tell echo applications to log if true", verbose);
@@ -51,6 +51,8 @@ main (int argc, char *argv[])
LogComponentEnable("UdpEchoServerApplication", LOG_LEVEL_INFO);
}
nCsma = nCsma == 0 ? 1 : nCsma;
NodeContainer p2pNodes;
p2pNodes.Create (2);
@@ -102,8 +104,8 @@ main (int argc, char *argv[])
GlobalRouteManager::PopulateRoutingTables ();
PointToPointHelper::EnablePcap ("second", p2pDevices.Get (1));
CsmaHelper::EnablePcap ("second", csmaDevices.Get (0), true);
PointToPointHelper::EnablePcapAll ("second");
CsmaHelper::EnablePcap ("second", csmaDevices.Get (1), true);
Simulator::Run ();
Simulator::Destroy ();

5
examples/third.cc
View File

@@ -40,11 +40,10 @@ NS_LOG_COMPONENT_DEFINE ("ThirdScriptExample");
int
main (int argc, char *argv[])
{
bool verbose = true;
uint32_t nCsma = 3;
uint32_t nWifi = 3;
CommandLine cmd;
cmd.AddValue ("nCsma", "Number of \"extra\" CSMA nodes/devices", nCsma);
cmd.AddValue ("nWifi", "Number of wifi STA devices", nWifi);
@@ -162,7 +161,7 @@ main (int argc, char *argv[])
Simulator::Stop (Seconds (10.0));
PointToPointHelper::EnablePcap ("third", p2pDevices.Get (0));
PointToPointHelper::EnablePcapAll ("third");
YansWifiPhyHelper::EnablePcap ("third", apDevices.Get (0));
CsmaHelper::EnablePcap ("third", csmaDevices.Get (0), true);