--- a/doc/tutorial/building-topologies.texi Sun Jan 02 22:57:04 2011 -0800
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,1458 +0,0 @@
-
-@c ========================================================================
-@c Begin document body here
-@c ========================================================================
-
-@c ========================================================================
-@c PART: Building Topologies
-@c ========================================================================
-@c The below chapters are under the major heading "Building Topologies"
-@c This is similar to the Latex \part command
-@c
-@c ========================================================================
-@c Building Topologies
-@c ========================================================================
-@node Building Topologies
-@chapter Building Topologies
-
-@menu
-* Building a Bus Network Topology::
-* Building a Wireless Network Topology::
-@end menu
-
-@c ========================================================================
-@c Building a Bus Network Topology
-@c ========================================================================
-@node Building a Bus Network Topology
-@section Building a Bus Network Topology
-
-@cindex topology
-@cindex bus network topology
-In this section we are going to expand our mastery of @command{ns-3} network
-devices and channels to cover an example of a bus network. @command{Ns-3}
-provides a net device and channel we call CSMA (Carrier Sense Multiple Access).
-
-The @command{ns-3} CSMA device models a simple network in the spirit of
-Ethernet. A real Ethernet uses CSMA/CD (Carrier Sense Multiple Access with
-Collision Detection) scheme with exponentially increasing backoff to contend
-for the shared transmission medium. The @command{ns-3} CSMA device and
-channel models only a subset of this.
-
-Just as we have seen point-to-point topology helper objects when constructing
-point-to-point topologies, we will see equivalent CSMA topology helpers in
-this section. The appearance and operation of these helpers should look
-quite familiar to you.
-
-We provide an example script in our @code{examples/tutorial} directory. This script
-builds on the @code{first.cc} script and adds a CSMA network to the
-point-to-point simulation we've already considered. Go ahead and open
-@code{examples/tutorial/second.cc} in your favorite editor. You will have already seen
-enough @command{ns-3} code to understand most of what is going on in this
-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"
-@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.
-
-In this case, you can see that we are going to extend our point-to-point
-example (the link between the nodes n0 and n1 below) by hanging a bus network
-off of the right side. Notice that this is the default network topology
-since you can actually vary the number of nodes created on the LAN. If you
-set nCsma to one, there will be a total of two nodes on the LAN (CSMA
-channel) --- one required node and one ``extra'' node. By default there are
-three ``extra'' nodes as seen below:
-
-@verbatim
-// Default Network Topology
-//
-// 10.1.1.0
-// n0 -------------- n1 n2 n3 n4
-// point-to-point | | | |
-// ================
-// LAN 10.1.2.0
-@end verbatim
-
-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
- using namespace ns3;
-
- NS_LOG_COMPONENT_DEFINE ("SecondScriptExample");
-@end verbatim
-
-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.
-
-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. 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 (``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
-point-to-point link. The @code{NodeContainer} is used to do this just as was
-done in @code{first.cc}.
-
-@verbatim
- NodeContainer p2pNodes;
- p2pNodes.Create (2);
-@end verbatim
-
-Next, we declare another @code{NodeContainer} to hold the nodes that will be
-part of the bus (CSMA) network. First, we just instantiate the container
-object itself.
-
-@verbatim
- NodeContainer csmaNodes;
- csmaNodes.Add (p2pNodes.Get (1));
- csmaNodes.Create (nCsma);
-@end verbatim
-
-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. 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 @code{Attributes} so
-that we create a five megabit per second transmitter on devices created using
-the helper and a two millisecond delay on channels created by the helper.
-
-@verbatim
- PointToPointHelper pointToPoint;
- pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));
- pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));
-
- NetDeviceContainer p2pDevices;
- p2pDevices = pointToPoint.Install (p2pNodes);
-@end verbatim
-
-We then instantiate a @code{NetDeviceContainer} to keep track of the
-point-to-point net devices and we @code{Install} devices on the
-point-to-point nodes.
-
-We mentioned above that you were going to see a helper for CSMA devices and
-channels, and the next lines introduce them. The @code{CsmaHelper} works just
-like a @code{PointToPointHelper}, but it creates and connects CSMA devices and
-channels. In the case of a CSMA device and channel pair, notice that the data
-rate is specified by a @emph{channel} @code{Attribute} instead of a device
-@code{Attribute}. This is because a real CSMA network does not allow one to mix,
-for example, 10Base-T and 100Base-T devices on a given channel. We first set
-the data rate to 100 megabits per second, and then set the speed-of-light delay
-of the channel to 6560 nano-seconds (arbitrarily chosen as 1 nanosecond per foot
-over a 100 meter segment). Notice that you can set an @code{Attribute} using
-its native data type.
-
-@verbatim
- CsmaHelper csma;
- csma.SetChannelAttribute ("DataRate", StringValue ("100Mbps"));
- csma.SetChannelAttribute ("Delay", TimeValue (NanoSeconds (6560)));
-
- NetDeviceContainer csmaDevices;
- csmaDevices = csma.Install (csmaNodes);
-@end verbatim
-
-Just as we created a @code{NetDeviceContainer} to hold the devices created by
-the @code{PointToPointHelper} we create a @code{NetDeviceContainer} to hold
-the devices created by our @code{CsmaHelper}. We call the @code{Install}
-method of the @code{CsmaHelper} to install the devices into the nodes of the
-@code{csmaNodes NodeContainer}.
-
-We now have our nodes, devices and channels created, but we have no protocol
-stacks present. Just as in the @code{first.cc} script, we will use the
-@code{InternetStackHelper} to install these stacks.
-
-@verbatim
- InternetStackHelper stack;
- stack.Install (p2pNodes.Get (0));
- stack.Install (csmaNodes);
-@end verbatim
-
-Recall that we took one of the nodes from the @code{p2pNodes} container and
-added it to the @code{csmaNodes} container. Thus we only need to install
-the stacks on the remaining @code{p2pNodes} node, and all of the nodes in the
-@code{csmaNodes} container to cover all of the nodes in the simulation.
-
-Just as in the @code{first.cc} example script, we are going to use the
-@code{Ipv4AddressHelper} to assign IP addresses to our device interfaces.
-First we use the network 10.1.1.0 to create the two addresses needed for our
-two point-to-point devices.
-
-@verbatim
- Ipv4AddressHelper address;
- address.SetBase ("10.1.1.0", "255.255.255.0");
- Ipv4InterfaceContainer p2pInterfaces;
- p2pInterfaces = address.Assign (p2pDevices);
-@end verbatim
-
-Recall that we save the created interfaces in a container to make it easy to
-pull out addressing information later for use in setting up the applications.
-
-We now need to assign IP addresses to our CSMA device interfaces. The
-operation works just as it did for the point-to-point case, except we now
-are performing the operation on a container that has a variable number of
-CSMA devices --- remember we made the number of CSMA devices changeable by
-command line argument. The CSMA devices will be associated with IP addresses
-from network number 10.1.2.0 in this case, as seen below.
-
-@verbatim
- address.SetBase ("10.1.2.0", "255.255.255.0");
- Ipv4InterfaceContainer csmaInterfaces;
- csmaInterfaces = address.Assign (csmaDevices);
-@end verbatim
-
-Now we have a topology built, but we need applications. This section is
-going to be fundamentally similar to the applications section of
-@code{first.cc} but we are going to instantiate the server on one of the
-nodes that has a CSMA device and the client on the node having only a
-point-to-point device.
-
-First, we set up the echo server. We create a @code{UdpEchoServerHelper} and
-provide a required @code{Attribute} value to the constructor which is the server
-port number. Recall that this port can be changed later using the
-@code{SetAttribute} method if desired, but we require it to be provided to
-the constructor.
-
-@verbatim
- UdpEchoServerHelper echoServer (9);
-
- ApplicationContainer serverApps = echoServer.Install (csmaNodes.Get (nCsma));
- serverApps.Start (Seconds (1.0));
- serverApps.Stop (Seconds (10.0));
-@end verbatim
-
-Recall that the @code{csmaNodes NodeContainer} contains one of the
-nodes created for the point-to-point network and @code{nCsma} ``extra'' nodes.
-What we want to get at is the last of the ``extra'' nodes. The zeroth entry of
-the @code{csmaNodes} container will be the point-to-point node. The easy
-way to think of this, then, is if we create one ``extra'' CSMA node, then it
-will be at index one of the @code{csmaNodes} container. By induction,
-if we create @code{nCsma} ``extra'' nodes the last one will be at index
-@code{nCsma}. You see this exhibited in the @code{Get} of the first line of
-code.
-
-The client application is set up exactly as we did in the @code{first.cc}
-example script. Again, we provide required @code{Attributes} to the
-@code{UdpEchoClientHelper} in the constructor (in this case the remote address
-and port). We tell the client to send packets to the server we just installed
-on the last of the ``extra'' CSMA nodes. We install the client on the
-leftmost point-to-point node seen in the topology illustration.
-
-@verbatim
- UdpEchoClientHelper echoClient (csmaInterfaces.GetAddress (nCsma), 9);
- echoClient.SetAttribute ("MaxPackets", UintegerValue (1));
- echoClient.SetAttribute ("Interval", TimeValue (Seconds (1.)));
- echoClient.SetAttribute ("PacketSize", UintegerValue (1024));
-
- ApplicationContainer clientApps = echoClient.Install (p2pNodes.Get (0));
- clientApps.Start (Seconds (2.0));
- clientApps.Stop (Seconds (10.0));
-@end verbatim
-
-Since we have actually built an internetwork here, we need some form of
-internetwork routing. @command{ns-3} provides what we call global routing to
-help you out. Global routing takes advantage of the fact that the entire
-internetwork is accessible in the simulation and runs through the all of the
-nodes created for the simulation --- it does the hard work of setting up routing
-for you without having to configure routers.
-
-Basically, what happens is that each node behaves as if it were an OSPF router
-that communicates instantly and magically with all other routers behind the
-scenes. Each node generates link advertisements and communicates them
-directly to a global route manager which uses this global information to
-construct the routing tables for each node. Setting up this form of routing
-is a one-liner:
-
-@verbatim
- Ipv4GlobalRoutingHelper::PopulateRoutingTables ();
-@end verbatim
-
-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
- pointToPoint.EnablePcapAll ("second");
- csma.EnablePcap ("second", csmaDevices.Get (1), 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 arrange 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(1)},
-which selects the first 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
- Simulator::Run ();
- Simulator::Destroy ();
- return 0;
- }
-@end verbatim
-
-In order to run this example, copy the @code{second.cc} example 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 just type,
-
-@verbatim
- cp examples/tutorial/second.cc scratch/mysecond.cc
- ./waf
-@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
- 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
-@end verbatim
-
-Recall that the first message, ``@code{Sent 1024 bytes to 10.1.2.4},'' is the
-UDP echo client sending a packet to the server. In this case, the server
-is on a different network (10.1.2.0). The second message, ``@code{Received 1024
-bytes from 10.1.1.1},'' is from the UDP echo server, 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 three trace
-files:
-
-@verbatim
- 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. 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.
-
-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
- 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.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)
-which we expect. You then see the echo packet leaving node zero via the
-device associated with IP address 10.1.1.1 headed for IP address
-10.1.2.4 (the rightmost CSMA node). This packet will move over the
-point-to-point link and be received by the point-to-point net device on node
-one. Let's take a look:
-
-@verbatim
- 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 (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
- 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.
-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. 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.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.
-
-@verbatim
- 2.003801 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
-@end verbatim
-
-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.
-
-@verbatim
- 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
-
-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 running the program with the number of ``extra''
-devices set to four:
-
-@verbatim
- ./waf --run "scratch/mysecond --nCsma=4"
-@end verbatim
-
-You should now see,
-
-@verbatim
- 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)
- Sent 1024 bytes to 10.1.2.5
- Received 1024 bytes from 10.1.1.1
- Received 1024 bytes from 10.1.2.5
-@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.
-
-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 fairly easily.
-
-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
- pointToPoint.EnablePcap ("second", p2pNodes.Get (0)->GetId (), 0);
- csma.EnablePcap ("second", csmaNodes.Get (nCsma)->GetId (), 0, false);
- csma.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.
-
-An alternate way, which we use here, is to realize that the
-@code{NodeContainers} contain pointers to @command{ns-3} @code{Node} Objects.
-The @code{Node} Object has a method called @code{GetId} which will return that
-node's ID, which is the node number we seek. Let's go take a look at the
-Doxygen for the @code{Node} and locate that method, which is further down in
-the @command{ns-3} core code than we've seen so far; but sometimes you have to
-search diligently for useful things.
-
-Go to the Doxygen documentation for your release (recall that you can find it
-on the project web site). You can get to the @code{Node} documentation by
-looking through at the ``Classes'' tab and scrolling down the ``Class List''
-until you find @code{ns3::Node}. Select @code{ns3::Node} and you will be taken
-to the documentation for the @code{Node} class. If you now scroll down to the
-@code{GetId} method and select it, you will be taken to the detailed
-documentation for the method. Using the @code{GetId} method can make
-determining node numbers much easier in complex topologies.
-
-Let's clear the old trace files out of the top-level directory to avoid confusion
-about what is going on,
-
-@verbatim
- rm *.pcap
- rm *.tr
-@end verbatim
-
-If you build the new script and run the simulation setting @code{nCsma} to 100,
-
-@verbatim
- ./waf --run "scratch/mysecond --nCsma=100"
-@end verbatim
-
-you will see the following output:
-
-@verbatim
- 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)
- Sent 1024 bytes to 10.1.2.101
- Received 1024 bytes from 10.1.1.1
- Received 1024 bytes from 10.1.2.101
-@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 you will see,
-
-@verbatim
- second-0-0.pcap second-100-0.pcap second-101-0.pcap
-@end verbatim
-
-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-100-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
-
-Now take a look at the @code{tcpdump} for @code{second-101-0.pcap}.
-
-@verbatim
- tcpdump -nn -tt -r second-101-0.pcap
-@end verbatim
-
-You can now see that node 101 is really the participant in the echo exchange.
-
-@verbatim
- reading from file second-101-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.003696 arp reply 10.1.2.101 is-at 00:00:00:00:00:67
- 2.003801 IP 10.1.1.1.49153 > 10.1.2.101.9: UDP, length 1024
- 2.003801 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.101
- 2.003822 arp reply 10.1.2.1 is-at 00:00:00:00:00:03
- 2.003822 IP 10.1.2.101.9 > 10.1.1.1.49153: UDP, length 1024
-@end verbatim
-
-@c ========================================================================
-@c Models, Attributes and Reality
-@c ========================================================================
-@node Models, Attributes and Reality
-@section Models, Attributes and Reality
-
-This is a convenient place to make a small excursion and make an important
-point. It may or may not be obvious to you, but whenever one is using a
-simulation, it is important to understand exactly what is being modeled and
-what is not. It is tempting, for example, to think of the CSMA devices
-and channels used in the previous section as if they were real Ethernet
-devices; and to expect a simulation result to directly reflect what will
-happen in a real Ethernet. This is not the case.
-
-A model is, by definition, an abstraction of reality. It is ultimately the
-responsibility of the simulation script author to determine the so-called
-``range of accuracy'' and ``domain of applicability'' of the simulation as
-a whole, and therefore its constituent parts.
-
-In some cases, like @code{Csma}, it can be fairly easy to determine what is
-@emph{not} modeled. By reading the model description (@code{csma.h}) you
-can find that there is no collision detection in the CSMA model and decide
-on how applicable its use will be in your simulation or what caveats you
-may want to include with your results. In other cases, it can be quite easy
-to configure behaviors that might not agree with any reality you can go out
-and buy. It will prove worthwhile to spend some time investigating a few
-such instances, and how easily you can swerve outside the bounds of reality
-in your simulations.
-
-As you have seen, @command{ns-3} provides @code{Attributes} which a user
-can easily set to change model behavior. Consider two of the @code{Attributes}
-of the @code{CsmaNetDevice}: @code{Mtu} and @code{EncapsulationMode}.
-The @code{Mtu} attribute indicates the Maximum Transmission Unit to the
-device. This is the size of the largest Protocol Data Unit (PDU) that the
-device can send.
-
-The MTU defaults to 1500 bytes in the @code{CsmaNetDevice}. This default
-corresponds to a number found in RFC 894, ``A Standard for the Transmission
-of IP Datagrams over Ethernet Networks.'' The number is actually derived
-from the maximum packet size for 10Base5 (full-spec Ethernet) networks --
-1518 bytes. If you subtract the DIX encapsulation overhead for Ethernet
-packets (18 bytes) you will end up with a maximum possible data size (MTU)
-of 1500 bytes. One can also find that the @code{MTU} for IEEE 802.3 networks
-is 1492 bytes. This is because LLC/SNAP encapsulation adds an extra eight
-bytes of overhead to the packet. In both cases, the underlying hardware can
-only send 1518 bytes, but the data size is different.
-
-In order to set the encapsulation mode, the @code{CsmaNetDevice} provides
-an @code{Attribute} called @code{EncapsulationMode} which can take on the
-values @code{Dix} or @code{Llc}. These correspond to Ethernet and LLC/SNAP
-framing respectively.
-
-If one leaves the @code{Mtu} at 1500 bytes and changes the encapsulation mode
-to @code{Llc}, the result will be a network that encapsulates 1500 byte PDUs
-with LLC/SNAP framing resulting in packets of 1526 bytes, which would be
-illegal in many networks, since they can transmit a maximum of 1518 bytes per
-packet. This would most likely result in a simulation that quite subtly does
-not reflect the reality you might be expecting.
-
-Just to complicate the picture, there exist jumbo frames (1500 < MTU <= 9000 bytes)
-and super-jumbo (MTU > 9000 bytes) frames that are not officially sanctioned
-by IEEE but are available in some high-speed (Gigabit) networks and NICs. One
-could leave the encapsulation mode set to @code{Dix}, and set the @code{Mtu}
-@code{Attribute} on a @code{CsmaNetDevice} to 64000 bytes -- even though an
-associated @code{CsmaChannel DataRate} was set at 10 megabits per second.
-This would essentially model an Ethernet switch made out of vampire-tapped
-1980s-style 10Base5 networks that support super-jumbo datagrams. This is
-certainly not something that was ever made, nor is likely to ever be made,
-but it is quite easy for you to configure.
-
-In the previous example, you used the command line to create a simulation that
-had 100 @code{Csma} nodes. You could have just as easily created a simulation
-with 500 nodes. If you were actually modeling that 10Base5 vampire-tap network,
-the maximum length of a full-spec Ethernet cable is 500 meters, with a minimum
-tap spacing of 2.5 meters. That means there could only be 200 taps on a
-real network. You could have quite easily built an illegal network in that
-way as well. This may or may not result in a meaningful simulation depending
-on what you are trying to model.
-
-Similar situations can occur in many places in @command{ns-3} and in any
-simulator. For example, you may be able to position nodes in such a way that
-they occupy the same space at the same time, or you may be able to configure
-amplifiers or noise levels that violate the basic laws of physics.
-
-@command{ns-3} generally favors flexibility, and many models will allow freely
-setting @code{Attributes} without trying to enforce any arbitrary consistency
-or particular underlying spec.
-
-The thing to take home from this is that @command{ns-3} is going to provide a
-super-flexible base for you to experiment with. It is up to you to understand
-what you are asking the system to do and to make sure that the simulations you
-create have some meaning and some connection with a reality defined by you.
-
-@c ========================================================================
-@c Building a Wireless Network Topology
-@c ========================================================================
-@node Building a Wireless Network Topology
-@section Building a Wireless Network Topology
-
-@cindex topology
-@cindex wireless network topology
-In this section we are going to further expand our knowledge of @command{ns-3}
-network devices and channels to cover an example of a wireless network.
-@command{Ns-3} provides a set of 802.11 models that attempt to provide an
-accurate MAC-level implementation of the 802.11 specification and a
-``not-so-slow'' PHY-level model of the 802.11a specification.
-
-Just as we have seen both point-to-point and CSMA topology helper objects when
-constructing point-to-point topologies, we will see equivalent @code{Wifi}
-topology helpers in this section. The appearance and operation of these
-helpers should look quite familiar to you.
-
-We provide an example script in our @code{examples/tutorial} directory. This script
-builds on the @code{second.cc} script and adds a Wifi network. Go ahead and
-open @code{examples/tutorial/third.cc} in your favorite editor. You will have already
-seen enough @command{ns-3} code to understand most of what is going on in
-this example, but there are a few new things, so we will go over the entire
-script and examine some of the output.
-
-Just as in the @code{second.cc} example (and in all @command{ns-3} examples)
-the file begins with an emacs mode line and some GPL boilerplate.
-
-Take a look at the ASCII art (reproduced below) that shows the default network
-topology constructed in the example. You can see that we are going to
-further extend our example by hanging a wireless network off of the left side.
-Notice that this is a default network topology since you can actually vary the
-number of nodes created on the wired and wireless networks. Just as in the
-@code{second.cc} script case, if you change @code{nCsma}, it will give you a
-number of ``extra'' CSMA nodes. Similarly, you can set @code{nWifi} to
-control how many @code{STA} (station) nodes are created in the simulation.
-There will always be one @code{AP} (access point) node on the wireless
-network. By default there are three ``extra'' CSMA nodes and three wireless
-@code{STA} nodes.
-
-The code begins by loading module include files just as was done in the
-@code{second.cc} example. There are a couple of new includes corresponding
-to the Wifi module and the mobility module which we will discuss below.
-
-@verbatim
-#include "ns3/core-module.h"
-#include "ns3/simulator-module.h"
-#include "ns3/node-module.h"
-#include "ns3/helper-module.h"
-#include "ns3/wifi-module.h"
-#include "ns3/mobility-module.h"
-@end verbatim
-
-The network topology illustration follows:
-
-@verbatim
- // Default Network Topology
- //
- // Wifi 10.1.3.0
- // AP
- // * * * *
- // | | | | 10.1.1.0
- // n5 n6 n7 n0 -------------- n1 n2 n3 n4
- // point-to-point | | | |
- // ================
- // LAN 10.1.2.0
-@end verbatim
-
-You can see that we are adding a new network device to the node on the left
-side of the point-to-point link that becomes the access point for the wireless
-network. A number of wireless STA nodes are created to fill out the new
-10.1.3.0 network as shown on the left side of the illustration.
-
-After the illustration, the @code{ns-3} namespace is @code{used} and a logging
-component is defined. This should all be quite familiar by now.
-
-@verbatim
- using namespace ns3;
-
- NS_LOG_COMPONENT_DEFINE ("ThirdScriptExample");
-@end verbatim
-
-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 (``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
-that we will connect via the point-to-point link.
-
-@verbatim
- NodeContainer p2pNodes;
- p2pNodes.Create (2);
-@end verbatim
-
-Next, we see an old friend. We instantiate a @code{PointToPointHelper} and
-set the associated default @code{Attributes} so that we create a five megabit
-per second transmitter on devices created using the helper and a two millisecond
-delay on channels created by the helper. We then @code{Intall} the devices
-on the nodes and the channel between them.
-
-@verbatim
- PointToPointHelper pointToPoint;
- pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));
- pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));
-
- NetDeviceContainer p2pDevices;
- p2pDevices = pointToPoint.Install (p2pNodes);
-@end verbatim
-
-Next, we declare another @code{NodeContainer} to hold the nodes that will be
-part of the bus (CSMA) network.
-
-@verbatim
- NodeContainer csmaNodes;
- csmaNodes.Add (p2pNodes.Get (1));
- csmaNodes.Create (nCsma);
-@end verbatim
-
-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 and a CSMA device. We then create a number of ``extra''
-nodes that compose the remainder of the CSMA network.
-
-We then instantiate a @code{CsmaHelper} and set its @code{Attributes} as we did
-in the previous example. We create a @code{NetDeviceContainer} to keep track of
-the created CSMA net devices and then we @code{Install} CSMA devices on the
-selected nodes.
-
-@verbatim
- CsmaHelper csma;
- csma.SetChannelAttribute ("DataRate", StringValue ("100Mbps"));
- csma.SetChannelAttribute ("Delay", TimeValue (NanoSeconds (6560)));
-
- NetDeviceContainer csmaDevices;
- csmaDevices = csma.Install (csmaNodes);
-@end verbatim
-
-Next, we are going to create the nodes that will be part of the Wifi network.
-We are going to create a number of ``station'' nodes as specified by the
-command line argument, and we are going to use the ``leftmost'' node of the
-point-to-point link as the node for the access point.
-
-@verbatim
- NodeContainer wifiStaNodes;
- wifiStaNodes.Create (nWifi);
- NodeContainer wifiApNode = p2pNodes.Get (0);
-@end verbatim
-
-The next bit of code constructs the wifi devices and the interconnection
-channel between these wifi nodes. First, we configure the PHY and channel
-helpers:
-
-@verbatim
- YansWifiChannelHelper channel = YansWifiChannelHelper::Default ();
- YansWifiPhyHelper phy = YansWifiPhyHelper::Default ();
-@end verbatim
-
-For simplicity, this code uses the default PHY layer configuration and
-channel models which are documented in the API doxygen documentation for
-the @code{YansWifiChannelHelper::Default} and @code{YansWifiPhyHelper::Default}
-methods. Once these objects are created, we create a channel object
-and associate it to our PHY layer object manager to make sure
-that all the PHY layer objects created by the @code{YansWifiPhyHelper}
-share the same underlying channel, that is, they share the same
-wireless medium and can communication and interfere:
-
-@verbatim
- phy.SetChannel (channel.Create ());
-@end verbatim
-
-Once the PHY helper is configured, we can focus on the MAC layer. Here we choose to
-work with non-Qos MACs so we use a NqosWifiMacHelper object to set MAC parameters.
-
-@verbatim
- WifiHelper wifi = WifiHelper::Default ();
- wifi.SetRemoteStationManager ("ns3::AarfWifiManager");
-
- NqosWifiMacHelper mac = NqosWifiMacHelper::Default ();
-@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.
-
-Next, we configure the type of MAC, the SSID of the infrastructure network we
-want to setup and make sure that our stations don't perform active probing:
-
-@verbatim
- Ssid ssid = Ssid ("ns-3-ssid");
- mac.SetType ("ns3::StaWifiMac",
- "Ssid", SsidValue (ssid),
- "ActiveProbing", BooleanValue (false));
-@end verbatim
-
-This code first creates an 802.11 service set identifier (SSID) object
-that will be used to set the value of the ``Ssid'' @code{Attribute} of
-the MAC layer implementation. The particular kind of MAC layer that
-will be created by the helper is specified by @code{Attribute} as
-being of the "ns3::StaWifiMac" type. The use of
-@code{NqosWifiMacHelper} will ensure that the ''QosSupported''
-@code{Attribute} for created MAC objects is set false. The combination
-of these two configurations means that the MAC instance next created
-will be a non-QoS non-AP station (STA) in an infrastructure BSS (i.e.,
-a BSS with an AP). Finally, the ``ActiveProbing'' @code{Attribute} is
-set to false. This means that probe requests will not be sent by MACs
-created by this helper.
-
-Once all the station-specific parameters are fully configured, both at the
-MAC and PHY layers, we can invoke our now-familiar @code{Install} method to
-create the wifi devices of these stations:
-
-@verbatim
- NetDeviceContainer staDevices;
- staDevices = wifi.Install (phy, mac, wifiStaNodes);
-@end verbatim
-
-We have configured Wifi for all of our STA nodes, and now we need to
-configure the AP (access point) node. We begin this process by changing
-the default @code{Attributes} of the @code{NqosWifiMacHelper} to reflect the
-requirements of the AP.
-
-@verbatim
- mac.SetType ("ns3::ApWifiMac",
- "Ssid", SsidValue (ssid),
- "BeaconGeneration", BooleanValue (true),
- "BeaconInterval", TimeValue (Seconds (2.5)));
-@end verbatim
-
-In this case, the @code{NqosWifiMacHelper} is going to create MAC
-layers of the ``ns3::ApWifiMac'', the latter specifying that a MAC
-instance configured as an AP should be created, with the helper type
-implying that the ''QosSupported'' @code{Attribute} should be set to
-false - disabling 802.11e/WMM-style QoS support at created APs. We
-set the ``BeaconGeneration'' @code{Attribute} to true and also set an
-interval between beacons of 2.5 seconds.
-
-The next lines create the single AP which shares the same set of PHY-level
-@code{Attributes} (and channel) as the stations:
-
-@verbatim
- NetDeviceContainer apDevices;
- apDevices = wifi.Install (phy, mac, wifiApNode);
-@end verbatim
-
-Now, we are going to add mobility models. We want the STA nodes to be mobile,
-wandering around inside a bounding box, and we want to make the AP node
-stationary. We use the @code{MobilityHelper} to make this easy for us.
-First, we instantiate a @code{MobilityHelper} object and set some
-@code{Attributes} controlling the ``position allocator'' functionality.
-
-@verbatim
- MobilityHelper mobility;
-
- mobility.SetPositionAllocator ("ns3::GridPositionAllocator",
- "MinX", DoubleValue (0.0),
- "MinY", DoubleValue (0.0),
- "DeltaX", DoubleValue (5.0),
- "DeltaY", DoubleValue (10.0),
- "GridWidth", UintegerValue (3),
- "LayoutType", StringValue ("RowFirst"));
-@end verbatim
-
-This code tells the mobility helper to use a two-dimensional grid to initially
-place the STA nodes. Feel free to explore the Doxygen for class
-@code{ns3::GridPositionAllocator} to see exactly what is being done.
-
-We have arranged our nodes on an initial grid, but now we need to tell them
-how to move. We choose the @code{RandomWalk2dMobilityModel} which has the
-nodes move in a random direction at a random speed around inside a bounding
-box.
-
-@verbatim
- mobility.SetMobilityModel ("ns3::RandomWalk2dMobilityModel",
- "Bounds", RectangleValue (Rectangle (-50, 50, -50, 50)));
-@end verbatim
-
-We now tell the @code{MobilityHelper} to install the mobility models on the
-STA nodes.
-
-@verbatim
- mobility.Install (wifiStaNodes);
-@end verbatim
-
-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::ConstantPositionMobilityModel}:
-
-@verbatim
- mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
- mobility.Install (wifiApNode);
-@end verbatim
-
-We now have our nodes, devices and channels created, and mobility models
-chosen for the Wifi nodes, but we have no protocol stacks present. Just as
-we have done previously many times, we will use the @code{InternetStackHelper}
-to install these stacks.
-
-@verbatim
- InternetStackHelper stack;
- stack.Install (csmaNodes);
- stack.Install (wifiApNode);
- stack.Install (wifiStaNodes);
-@end verbatim
-
-Just as in the @code{second.cc} example script, we are going to use the
-@code{Ipv4AddressHelper} to assign IP addresses to our device interfaces.
-First we use the network 10.1.1.0 to create the two addresses needed for our
-two point-to-point devices. Then we use network 10.1.2.0 to assign addresses
-to the CSMA network and then we assign addresses from network 10.1.3.0 to
-both the STA devices and the AP on the wireless network.
-
-@verbatim
- Ipv4AddressHelper address;
-
- address.SetBase ("10.1.1.0", "255.255.255.0");
- Ipv4InterfaceContainer p2pInterfaces;
- p2pInterfaces = address.Assign (p2pDevices);
-
- address.SetBase ("10.1.2.0", "255.255.255.0");
- Ipv4InterfaceContainer csmaInterfaces;
- csmaInterfaces = address.Assign (csmaDevices);
-
- address.SetBase ("10.1.3.0", "255.255.255.0");
- address.Assign (staDevices);
- address.Assign (apDevices);
-@end verbatim
-
-We put the echo server on the ``rightmost'' node in the illustration at the
-start of the file. We have done this before.
-
-@verbatim
- UdpEchoServerHelper echoServer (9);
-
- ApplicationContainer serverApps = echoServer.Install (csmaNodes.Get (nCsma));
- serverApps.Start (Seconds (1.0));
- serverApps.Stop (Seconds (10.0));
-@end verbatim
-
-And we put the echo client on the last STA node we created, pointing it to
-the server on the CSMA network. We have also seen similar operations before.
-
-@verbatim
- UdpEchoClientHelper echoClient (csmaInterfaces.GetAddress (nCsma), 9);
- echoClient.SetAttribute ("MaxPackets", UintegerValue (1));
- echoClient.SetAttribute ("Interval", TimeValue (Seconds (1.)));
- echoClient.SetAttribute ("PacketSize", UintegerValue (1024));
-
- ApplicationContainer clientApps =
- echoClient.Install (wifiStaNodes.Get (nWifi - 1));
- clientApps.Start (Seconds (2.0));
- clientApps.Stop (Seconds (10.0));
-@end verbatim
-
-Since we have built an internetwork here, we need to enable internetwork routing
-just as we did in the @code{second.cc} example script.
-
-@verbatim
- Ipv4GlobalRoutingHelper::PopulateRoutingTables ();
-@end verbatim
-
-One thing that can surprise some users is the fact that the simulation we just
-created will never ``naturally'' stop. This is because we asked the wireless
-access point to generate beacons. It will generate beacons forever, and this
-will result in simulator events being scheduled into the future indefinitely,
-so we must tell the simulator to stop even though it may have beacon generation
-events scheduled. The following line of code tells the simulator to stop so that
-we don't simulate beacons forever and enter what is essentially an endless
-loop.
-
-@verbatim
- Simulator::Stop (Seconds (10.0));
-@end verbatim
-
-We create just enough tracing to cover all three networks:
-
-@verbatim
- pointToPoint.EnablePcapAll ("third");
- phy.EnablePcap ("third", apDevices.Get (0));
- csma.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
- Simulator::Run ();
- Simulator::Destroy ();
- return 0;
- }
-@end verbatim
-
-In order to run this example, you have to copy the @code{third.cc} example
-script into the scratch directory and use Waf to build just as you did with
-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/mythird.cc
- ./waf
- ./waf --run scratch/mythird
-@end verbatim
-
-Again, 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
- 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)
- Sent 1024 bytes to 10.1.2.4
- Received 1024 bytes from 10.1.3.3
- Received 1024 bytes from 10.1.2.4
-@end verbatim
-
-Recall that the first message, ``@code{Sent 1024 bytes to 10.1.2.4},'' is the
-UDP echo client sending a packet to the server. In this case, the client
-is on the wireless network (10.1.3.0). The second message,
-``@code{Received 1024 bytes from 10.1.3.3},'' is from the UDP echo server,
-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 four trace
-files from this simulation, two from node zero and two from node one:
-
-@verbatim
-third-0-0.pcap third-0-1.pcap third-1-0.pcap third-1-1.pcap
-@end verbatim
-
-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
- 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.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 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
-nodes are actually moving around during the simulation. Let's do this by hooking
-into the @code{MobilityModel} course change trace source. This is just a sneak
-peek into the detailed tracing section which is coming up, but this seems a very
-nice place to get an example in.
-
-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/mythird.cc} script, add the
-following function:
-
-@verbatim
- void
- CourseChange (std::string context, Ptr<const MobilityModel> model)
- {
- Vector position = model->GetPosition ();
- NS_LOG_UNCOND (context <<
- " x = " << position.x << ", y = " << position.y);
- }
-@end verbatim
-
-This code just pulls the position information from the mobility model and
-unconditionally logs the x and y position of the node. We are
-going to arrange for this function to be called every time the wireless
-node with the echo client changes its position. We do this using the
-@code{Config::Connect} function. Add the following lines of code to the
-script just before the @code{Simulator::Run} call.
-
-@verbatim
- std::ostringstream oss;
- oss <<
- "/NodeList/" << wifiStaNodes.Get (nWifi - 1)->GetId () <<
- "/$ns3::MobilityModel/CourseChange";
-
- Config::Connect (oss.str (), MakeCallback (&CourseChange));
-@end verbatim
-
-What we do here is to create a string containing the tracing namespace path
-of the event to which we want to connect. First, we have to figure out which
-node it is we want using the @code{GetId} method as described earlier. In the
-case of the default number of CSMA and wireless nodes, this turns out to be
-node seven and the tracing namespace path to the mobility model would look
-like,
-
-@verbatim
- /NodeList/7/$ns3::MobilityModel/CourseChange
-@end verbatim
-
-Based on the discussion in the tracing section, you may infer that this trace
-path references the seventh node in the global NodeList. It specifies
-what is called an aggregated object of type @code{ns3::MobilityModel}. The
-dollar sign prefix implies that the MobilityModel is aggregated to node seven.
-The last component of the path means that we are hooking into the
-``CourseChange'' event of that model.
-
-We make a connection between the trace source in node seven with our trace
-sink by calling @code{Config::Connect} and passing this namespace path. Once
-this is done, every course change event on node seven will be hooked into our
-trace sink, which will in turn print out the new position.
-
-If you now run the simulation, you will see the course changes displayed as
-they happen.
-
-@verbatim
- Build finished successfully (00:00:01)
- /NodeList/7/$ns3::MobilityModel/CourseChange x = 10, y = 0
- /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 = 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