author | Tom Henderson <tomh@tomh.org> |
Tue, 15 Sep 2015 12:13:38 -0700 | |
changeset 11670 | 61dae169dc6a |
parent 11221 | 243001f59f66 |
permissions | -rw-r--r-- |
6754 | 1 |
.. include:: replace.txt |
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
2 |
.. highlight:: cpp |
6754 | 3 |
|
11088
50e89dc6d8b1
[Sphinx] Update the Tracing chapter in the Tutorial.
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
11050
diff
changeset
|
4 |
.. _BuildingTopologies: |
50e89dc6d8b1
[Sphinx] Update the Tracing chapter in the Tutorial.
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
11050
diff
changeset
|
5 |
|
6754 | 6 |
Building Topologies |
7 |
------------------- |
|
8 |
||
9 |
Building a Bus Network Topology |
|
10 |
******************************* |
|
11 |
||
12 |
In this section we are going to expand our mastery of |ns3| network |
|
13 |
devices and channels to cover an example of a bus network. |ns3| |
|
14 |
provides a net device and channel we call CSMA (Carrier Sense Multiple Access). |
|
15 |
||
16 |
The |ns3| CSMA device models a simple network in the spirit of |
|
17 |
Ethernet. A real Ethernet uses CSMA/CD (Carrier Sense Multiple Access with |
|
18 |
Collision Detection) scheme with exponentially increasing backoff to contend |
|
19 |
for the shared transmission medium. The |ns3| CSMA device and |
|
20 |
channel models only a subset of this. |
|
21 |
||
22 |
Just as we have seen point-to-point topology helper objects when constructing |
|
23 |
point-to-point topologies, we will see equivalent CSMA topology helpers in |
|
24 |
this section. The appearance and operation of these helpers should look |
|
25 |
quite familiar to you. |
|
26 |
||
11221
243001f59f66
fix tutorial typos (found by Renan)
Tom Henderson <tomh@tomh.org>
parents:
11088
diff
changeset
|
27 |
We provide an example script in our ``examples/tutorial`` directory. This script |
6754 | 28 |
builds on the ``first.cc`` script and adds a CSMA network to the |
29 |
point-to-point simulation we've already considered. Go ahead and open |
|
30 |
``examples/tutorial/second.cc`` in your favorite editor. You will have already seen |
|
31 |
enough |ns3| code to understand most of what is going on in this |
|
32 |
example, but we will go over the entire script and examine some of the output. |
|
33 |
||
34 |
Just as in the ``first.cc`` example (and in all ns-3 examples) the file |
|
35 |
begins with an emacs mode line and some GPL boilerplate. |
|
36 |
||
37 |
The actual code begins by loading module include files just as was done in the |
|
38 |
``first.cc`` example. |
|
39 |
||
40 |
:: |
|
41 |
||
42 |
#include "ns3/core-module.h" |
|
7137
dbefbad7bee3
Fix module names in documentation
Mitch Watrous <watrous@u.washington.edu>
parents:
6754
diff
changeset
|
43 |
#include "ns3/network-module.h" |
dbefbad7bee3
Fix module names in documentation
Mitch Watrous <watrous@u.washington.edu>
parents:
6754
diff
changeset
|
44 |
#include "ns3/csma-module.h" |
dbefbad7bee3
Fix module names in documentation
Mitch Watrous <watrous@u.washington.edu>
parents:
6754
diff
changeset
|
45 |
#include "ns3/internet-module.h" |
dbefbad7bee3
Fix module names in documentation
Mitch Watrous <watrous@u.washington.edu>
parents:
6754
diff
changeset
|
46 |
#include "ns3/point-to-point-module.h" |
dbefbad7bee3
Fix module names in documentation
Mitch Watrous <watrous@u.washington.edu>
parents:
6754
diff
changeset
|
47 |
#include "ns3/applications-module.h" |
dbefbad7bee3
Fix module names in documentation
Mitch Watrous <watrous@u.washington.edu>
parents:
6754
diff
changeset
|
48 |
#include "ns3/ipv4-global-routing-helper.h" |
6754 | 49 |
|
50 |
One thing that can be surprisingly useful is a small bit of ASCII art that |
|
51 |
shows a cartoon of the network topology constructed in the example. You will |
|
52 |
find a similar "drawing" in most of our examples. |
|
53 |
||
54 |
In this case, you can see that we are going to extend our point-to-point |
|
55 |
example (the link between the nodes n0 and n1 below) by hanging a bus network |
|
56 |
off of the right side. Notice that this is the default network topology |
|
57 |
since you can actually vary the number of nodes created on the LAN. If you |
|
58 |
set nCsma to one, there will be a total of two nodes on the LAN (CSMA |
|
59 |
channel) --- one required node and one "extra" node. By default there are |
|
60 |
three "extra" nodes as seen below: |
|
61 |
||
62 |
:: |
|
63 |
||
64 |
// Default Network Topology |
|
65 |
// |
|
66 |
// 10.1.1.0 |
|
67 |
// n0 -------------- n1 n2 n3 n4 |
|
68 |
// point-to-point | | | | |
|
69 |
// ================ |
|
70 |
// LAN 10.1.2.0 |
|
71 |
||
72 |
Then the ns-3 namespace is ``used`` and a logging component is defined. |
|
73 |
This is all just as it was in ``first.cc``, so there is nothing new yet. |
|
74 |
||
75 |
:: |
|
76 |
||
77 |
using namespace ns3; |
|
78 |
||
79 |
NS_LOG_COMPONENT_DEFINE ("SecondScriptExample"); |
|
80 |
||
81 |
The main program begins with a slightly different twist. We use a verbose |
|
82 |
flag to determine whether or not the ``UdpEchoClientApplication`` and |
|
83 |
``UdpEchoServerApplication`` logging components are enabled. This flag |
|
84 |
defaults to true (the logging components are enabled) but allows us to turn |
|
85 |
off logging during regression testing of this example. |
|
86 |
||
87 |
You will see some familiar code that will allow you to change the number |
|
88 |
of devices on the CSMA network via command line argument. We did something |
|
89 |
similar when we allowed the number of packets sent to be changed in the section |
|
90 |
on command line arguments. The last line makes sure you have at least one |
|
91 |
"extra" node. |
|
92 |
||
93 |
The code consists of variations of previously covered API so you should be |
|
94 |
entirely comfortable with the following code at this point in the tutorial. |
|
95 |
||
96 |
:: |
|
97 |
||
98 |
bool verbose = true; |
|
99 |
uint32_t nCsma = 3; |
|
100 |
||
101 |
CommandLine cmd; |
|
102 |
cmd.AddValue ("nCsma", "Number of \"extra\" CSMA nodes/devices", nCsma); |
|
103 |
cmd.AddValue ("verbose", "Tell echo applications to log if true", verbose); |
|
104 |
||
7275 | 105 |
cmd.Parse (argc, argv); |
6754 | 106 |
|
107 |
if (verbose) |
|
108 |
{ |
|
109 |
LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO); |
|
110 |
LogComponentEnable("UdpEchoServerApplication", LOG_LEVEL_INFO); |
|
111 |
} |
|
112 |
||
113 |
nCsma = nCsma == 0 ? 1 : nCsma; |
|
114 |
||
115 |
The next step is to create two nodes that we will connect via the |
|
116 |
point-to-point link. The ``NodeContainer`` is used to do this just as was |
|
117 |
done in ``first.cc``. |
|
118 |
||
119 |
:: |
|
120 |
||
121 |
NodeContainer p2pNodes; |
|
122 |
p2pNodes.Create (2); |
|
123 |
||
124 |
Next, we declare another ``NodeContainer`` to hold the nodes that will be |
|
125 |
part of the bus (CSMA) network. First, we just instantiate the container |
|
126 |
object itself. |
|
127 |
||
128 |
:: |
|
129 |
||
130 |
NodeContainer csmaNodes; |
|
131 |
csmaNodes.Add (p2pNodes.Get (1)); |
|
132 |
csmaNodes.Create (nCsma); |
|
133 |
||
134 |
The next line of code ``Gets`` the first node (as in having an index of one) |
|
135 |
from the point-to-point node container and adds it to the container of nodes |
|
136 |
that will get CSMA devices. The node in question is going to end up with a |
|
137 |
point-to-point device *and* a CSMA device. We then create a number of |
|
138 |
"extra" nodes that compose the remainder of the CSMA network. Since we |
|
139 |
already have one node in the CSMA network -- the one that will have both a |
|
140 |
point-to-point and CSMA net device, the number of "extra" nodes means the |
|
141 |
number nodes you desire in the CSMA section minus one. |
|
142 |
||
143 |
The next bit of code should be quite familiar by now. We instantiate a |
|
144 |
``PointToPointHelper`` and set the associated default ``Attributes`` so |
|
145 |
that we create a five megabit per second transmitter on devices created using |
|
146 |
the helper and a two millisecond delay on channels created by the helper. |
|
147 |
||
148 |
:: |
|
149 |
||
150 |
PointToPointHelper pointToPoint; |
|
151 |
pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps")); |
|
152 |
pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms")); |
|
153 |
||
154 |
NetDeviceContainer p2pDevices; |
|
155 |
p2pDevices = pointToPoint.Install (p2pNodes); |
|
156 |
||
157 |
We then instantiate a ``NetDeviceContainer`` to keep track of the |
|
158 |
point-to-point net devices and we ``Install`` devices on the |
|
159 |
point-to-point nodes. |
|
160 |
||
161 |
We mentioned above that you were going to see a helper for CSMA devices and |
|
162 |
channels, and the next lines introduce them. The ``CsmaHelper`` works just |
|
163 |
like a ``PointToPointHelper``, but it creates and connects CSMA devices and |
|
164 |
channels. In the case of a CSMA device and channel pair, notice that the data |
|
165 |
rate is specified by a *channel* ``Attribute`` instead of a device |
|
166 |
``Attribute``. This is because a real CSMA network does not allow one to mix, |
|
167 |
for example, 10Base-T and 100Base-T devices on a given channel. We first set |
|
168 |
the data rate to 100 megabits per second, and then set the speed-of-light delay |
|
169 |
of the channel to 6560 nano-seconds (arbitrarily chosen as 1 nanosecond per foot |
|
170 |
over a 100 meter segment). Notice that you can set an ``Attribute`` using |
|
171 |
its native data type. |
|
172 |
||
173 |
:: |
|
174 |
||
175 |
CsmaHelper csma; |
|
176 |
csma.SetChannelAttribute ("DataRate", StringValue ("100Mbps")); |
|
177 |
csma.SetChannelAttribute ("Delay", TimeValue (NanoSeconds (6560))); |
|
178 |
||
179 |
NetDeviceContainer csmaDevices; |
|
180 |
csmaDevices = csma.Install (csmaNodes); |
|
181 |
||
182 |
Just as we created a ``NetDeviceContainer`` to hold the devices created by |
|
183 |
the ``PointToPointHelper`` we create a ``NetDeviceContainer`` to hold |
|
184 |
the devices created by our ``CsmaHelper``. We call the ``Install`` |
|
185 |
method of the ``CsmaHelper`` to install the devices into the nodes of the |
|
186 |
``csmaNodes NodeContainer``. |
|
187 |
||
188 |
We now have our nodes, devices and channels created, but we have no protocol |
|
189 |
stacks present. Just as in the ``first.cc`` script, we will use the |
|
190 |
``InternetStackHelper`` to install these stacks. |
|
191 |
||
192 |
:: |
|
193 |
||
194 |
InternetStackHelper stack; |
|
195 |
stack.Install (p2pNodes.Get (0)); |
|
196 |
stack.Install (csmaNodes); |
|
197 |
||
198 |
Recall that we took one of the nodes from the ``p2pNodes`` container and |
|
199 |
added it to the ``csmaNodes`` container. Thus we only need to install |
|
200 |
the stacks on the remaining ``p2pNodes`` node, and all of the nodes in the |
|
201 |
``csmaNodes`` container to cover all of the nodes in the simulation. |
|
202 |
||
203 |
Just as in the ``first.cc`` example script, we are going to use the |
|
204 |
``Ipv4AddressHelper`` to assign IP addresses to our device interfaces. |
|
205 |
First we use the network 10.1.1.0 to create the two addresses needed for our |
|
206 |
two point-to-point devices. |
|
207 |
||
208 |
:: |
|
209 |
||
210 |
Ipv4AddressHelper address; |
|
211 |
address.SetBase ("10.1.1.0", "255.255.255.0"); |
|
212 |
Ipv4InterfaceContainer p2pInterfaces; |
|
213 |
p2pInterfaces = address.Assign (p2pDevices); |
|
214 |
||
215 |
Recall that we save the created interfaces in a container to make it easy to |
|
216 |
pull out addressing information later for use in setting up the applications. |
|
217 |
||
218 |
We now need to assign IP addresses to our CSMA device interfaces. The |
|
219 |
operation works just as it did for the point-to-point case, except we now |
|
220 |
are performing the operation on a container that has a variable number of |
|
221 |
CSMA devices --- remember we made the number of CSMA devices changeable by |
|
222 |
command line argument. The CSMA devices will be associated with IP addresses |
|
223 |
from network number 10.1.2.0 in this case, as seen below. |
|
224 |
||
225 |
:: |
|
226 |
||
227 |
address.SetBase ("10.1.2.0", "255.255.255.0"); |
|
228 |
Ipv4InterfaceContainer csmaInterfaces; |
|
229 |
csmaInterfaces = address.Assign (csmaDevices); |
|
230 |
||
231 |
Now we have a topology built, but we need applications. This section is |
|
232 |
going to be fundamentally similar to the applications section of |
|
233 |
``first.cc`` but we are going to instantiate the server on one of the |
|
234 |
nodes that has a CSMA device and the client on the node having only a |
|
235 |
point-to-point device. |
|
236 |
||
237 |
First, we set up the echo server. We create a ``UdpEchoServerHelper`` and |
|
238 |
provide a required ``Attribute`` value to the constructor which is the server |
|
239 |
port number. Recall that this port can be changed later using the |
|
240 |
``SetAttribute`` method if desired, but we require it to be provided to |
|
241 |
the constructor. |
|
242 |
||
243 |
:: |
|
244 |
||
245 |
UdpEchoServerHelper echoServer (9); |
|
246 |
||
247 |
ApplicationContainer serverApps = echoServer.Install (csmaNodes.Get (nCsma)); |
|
248 |
serverApps.Start (Seconds (1.0)); |
|
249 |
serverApps.Stop (Seconds (10.0)); |
|
250 |
||
251 |
Recall that the ``csmaNodes NodeContainer`` contains one of the |
|
252 |
nodes created for the point-to-point network and ``nCsma`` "extra" nodes. |
|
253 |
What we want to get at is the last of the "extra" nodes. The zeroth entry of |
|
254 |
the ``csmaNodes`` container will be the point-to-point node. The easy |
|
255 |
way to think of this, then, is if we create one "extra" CSMA node, then it |
|
256 |
will be at index one of the ``csmaNodes`` container. By induction, |
|
257 |
if we create ``nCsma`` "extra" nodes the last one will be at index |
|
258 |
``nCsma``. You see this exhibited in the ``Get`` of the first line of |
|
259 |
code. |
|
260 |
||
261 |
The client application is set up exactly as we did in the ``first.cc`` |
|
262 |
example script. Again, we provide required ``Attributes`` to the |
|
263 |
``UdpEchoClientHelper`` in the constructor (in this case the remote address |
|
264 |
and port). We tell the client to send packets to the server we just installed |
|
265 |
on the last of the "extra" CSMA nodes. We install the client on the |
|
266 |
leftmost point-to-point node seen in the topology illustration. |
|
267 |
||
268 |
:: |
|
269 |
||
270 |
UdpEchoClientHelper echoClient (csmaInterfaces.GetAddress (nCsma), 9); |
|
271 |
echoClient.SetAttribute ("MaxPackets", UintegerValue (1)); |
|
9112
ede7a74e7411
bug 1514: make TimeValue usage consistent in the tutorial
Tom Henderson <tomh@tomh.org>
parents:
7772
diff
changeset
|
272 |
echoClient.SetAttribute ("Interval", TimeValue (Seconds (1.0))); |
6754 | 273 |
echoClient.SetAttribute ("PacketSize", UintegerValue (1024)); |
274 |
||
275 |
ApplicationContainer clientApps = echoClient.Install (p2pNodes.Get (0)); |
|
276 |
clientApps.Start (Seconds (2.0)); |
|
277 |
clientApps.Stop (Seconds (10.0)); |
|
278 |
||
279 |
Since we have actually built an internetwork here, we need some form of |
|
280 |
internetwork routing. |ns3| provides what we call global routing to |
|
281 |
help you out. Global routing takes advantage of the fact that the entire |
|
282 |
internetwork is accessible in the simulation and runs through the all of the |
|
283 |
nodes created for the simulation --- it does the hard work of setting up routing |
|
284 |
for you without having to configure routers. |
|
285 |
||
286 |
Basically, what happens is that each node behaves as if it were an OSPF router |
|
287 |
that communicates instantly and magically with all other routers behind the |
|
288 |
scenes. Each node generates link advertisements and communicates them |
|
289 |
directly to a global route manager which uses this global information to |
|
290 |
construct the routing tables for each node. Setting up this form of routing |
|
291 |
is a one-liner: |
|
292 |
||
293 |
:: |
|
294 |
||
295 |
Ipv4GlobalRoutingHelper::PopulateRoutingTables (); |
|
296 |
||
297 |
Next we enable pcap tracing. The first line of code to enable pcap tracing |
|
298 |
in the point-to-point helper should be familiar to you by now. The second |
|
299 |
line enables pcap tracing in the CSMA helper and there is an extra parameter |
|
300 |
you haven't encountered yet. |
|
301 |
||
302 |
:: |
|
303 |
||
304 |
pointToPoint.EnablePcapAll ("second"); |
|
305 |
csma.EnablePcap ("second", csmaDevices.Get (1), true); |
|
306 |
||
307 |
The CSMA network is a multi-point-to-point network. This means that there |
|
308 |
can (and are in this case) multiple endpoints on a shared medium. Each of |
|
309 |
these endpoints has a net device associated with it. There are two basic |
|
310 |
alternatives to gathering trace information from such a network. One way |
|
311 |
is to create a trace file for each net device and store only the packets |
|
312 |
that are emitted or consumed by that net device. Another way is to pick |
|
313 |
one of the devices and place it in promiscuous mode. That single device |
|
314 |
then "sniffs" the network for all packets and stores them in a single |
|
315 |
pcap file. This is how ``tcpdump``, for example, works. That final |
|
316 |
parameter tells the CSMA helper whether or not to arrange to capture |
|
317 |
packets in promiscuous mode. |
|
318 |
||
319 |
In this example, we are going to select one of the devices on the CSMA |
|
320 |
network and ask it to perform a promiscuous sniff of the network, thereby |
|
321 |
emulating what ``tcpdump`` would do. If you were on a Linux machine |
|
322 |
you might do something like ``tcpdump -i eth0`` to get the trace. |
|
323 |
In this case, we specify the device using ``csmaDevices.Get(1)``, |
|
324 |
which selects the first device in the container. Setting the final |
|
325 |
parameter to true enables promiscuous captures. |
|
326 |
||
327 |
The last section of code just runs and cleans up the simulation just like |
|
328 |
the ``first.cc`` example. |
|
329 |
||
330 |
:: |
|
331 |
||
332 |
Simulator::Run (); |
|
333 |
Simulator::Destroy (); |
|
334 |
return 0; |
|
335 |
} |
|
336 |
||
337 |
In order to run this example, copy the ``second.cc`` example script into |
|
338 |
the scratch directory and use waf to build just as you did with |
|
339 |
the ``first.cc`` example. If you are in the top-level directory of the |
|
340 |
repository you just type, |
|
341 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
342 |
.. sourcecode:: bash |
6754 | 343 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
344 |
$ cp examples/tutorial/second.cc scratch/mysecond.cc |
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
345 |
$ ./waf |
6754 | 346 |
|
347 |
Warning: We use the file ``second.cc`` as one of our regression tests to |
|
348 |
verify that it works exactly as we think it should in order to make your |
|
349 |
tutorial experience a positive one. This means that an executable named |
|
350 |
``second`` already exists in the project. To avoid any confusion |
|
351 |
about what you are executing, please do the renaming to ``mysecond.cc`` |
|
352 |
suggested above. |
|
353 |
||
354 |
If you are following the tutorial religiously (you are, aren't you) you will |
|
355 |
still have the NS_LOG variable set, so go ahead and clear that variable and |
|
356 |
run the program. |
|
357 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
358 |
.. sourcecode:: bash |
6754 | 359 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
360 |
$ export NS_LOG= |
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
361 |
$ ./waf --run scratch/mysecond |
6754 | 362 |
|
363 |
Since we have set up the UDP echo applications to log just as we did in |
|
364 |
``first.cc``, you will see similar output when you run the script. |
|
365 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
366 |
.. sourcecode:: text |
6754 | 367 |
|
368 |
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' |
|
369 |
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' |
|
370 |
'build' finished successfully (0.415s) |
|
371 |
Sent 1024 bytes to 10.1.2.4 |
|
372 |
Received 1024 bytes from 10.1.1.1 |
|
373 |
Received 1024 bytes from 10.1.2.4 |
|
374 |
||
375 |
Recall that the first message, "``Sent 1024 bytes to 10.1.2.4``," is the |
|
376 |
UDP echo client sending a packet to the server. In this case, the server |
|
377 |
is on a different network (10.1.2.0). The second message, "``Received 1024 |
|
378 |
bytes from 10.1.1.1``," is from the UDP echo server, generated when it receives |
|
379 |
the echo packet. The final message, "``Received 1024 bytes from 10.1.2.4``," |
|
380 |
is from the echo client, indicating that it has received its echo back from |
|
381 |
the server. |
|
382 |
||
383 |
If you now go and look in the top level directory, you will find three trace |
|
384 |
files: |
|
385 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
386 |
.. sourcecode:: text |
6754 | 387 |
|
388 |
second-0-0.pcap second-1-0.pcap second-2-0.pcap |
|
389 |
||
390 |
Let's take a moment to look at the naming of these files. They all have the |
|
391 |
same form, ``<name>-<node>-<device>.pcap``. For example, the first file |
|
392 |
in the listing is ``second-0-0.pcap`` which is the pcap trace from node |
|
393 |
zero, device zero. This is the point-to-point net device on node zero. The |
|
394 |
file ``second-1-0.pcap`` is the pcap trace for device zero on node one, |
|
395 |
also a point-to-point net device; and the file ``second-2-0.pcap`` is the |
|
396 |
pcap trace for device zero on node two. |
|
397 |
||
398 |
If you refer back to the topology illustration at the start of the section, |
|
399 |
you will see that node zero is the leftmost node of the point-to-point link |
|
400 |
and node one is the node that has both a point-to-point device and a CSMA |
|
401 |
device. You will see that node two is the first "extra" node on the CSMA |
|
402 |
network and its device zero was selected as the device to capture the |
|
403 |
promiscuous-mode trace. |
|
404 |
||
405 |
Now, let's follow the echo packet through the internetwork. First, do a |
|
406 |
tcpdump of the trace file for the leftmost point-to-point node --- node zero. |
|
407 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
408 |
.. sourcecode:: bash |
6754 | 409 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
410 |
$ tcpdump -nn -tt -r second-0-0.pcap |
6754 | 411 |
|
412 |
You should see the contents of the pcap file displayed: |
|
413 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
414 |
.. sourcecode:: text |
6754 | 415 |
|
416 |
reading from file second-0-0.pcap, link-type PPP (PPP) |
|
417 |
2.000000 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024 |
|
11049
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
418 |
2.017607 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024 |
6754 | 419 |
|
420 |
The first line of the dump indicates that the link type is PPP (point-to-point) |
|
421 |
which we expect. You then see the echo packet leaving node zero via the |
|
422 |
device associated with IP address 10.1.1.1 headed for IP address |
|
423 |
10.1.2.4 (the rightmost CSMA node). This packet will move over the |
|
424 |
point-to-point link and be received by the point-to-point net device on node |
|
425 |
one. Let's take a look: |
|
426 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
427 |
.. sourcecode:: bash |
6754 | 428 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
429 |
$ tcpdump -nn -tt -r second-1-0.pcap |
6754 | 430 |
|
431 |
You should now see the pcap trace output of the other side of the point-to-point |
|
432 |
link: |
|
433 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
434 |
.. sourcecode:: text |
6754 | 435 |
|
436 |
reading from file second-1-0.pcap, link-type PPP (PPP) |
|
437 |
2.003686 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024 |
|
11049
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
438 |
2.013921 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024 |
6754 | 439 |
|
440 |
Here we see that the link type is also PPP as we would expect. You see the |
|
441 |
packet from IP address 10.1.1.1 (that was sent at 2.000000 seconds) headed |
|
442 |
toward IP address 10.1.2.4 appear on this interface. Now, internally to this |
|
443 |
node, the packet will be forwarded to the CSMA interface and we should see it |
|
444 |
pop out on that device headed for its ultimate destination. |
|
445 |
||
446 |
Remember that we selected node 2 as the promiscuous sniffer node for the CSMA |
|
447 |
network so let's then look at second-2-0.pcap and see if its there. |
|
448 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
449 |
.. sourcecode:: bash |
6754 | 450 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
451 |
$ tcpdump -nn -tt -r second-2-0.pcap |
6754 | 452 |
|
453 |
You should now see the promiscuous dump of node two, device zero: |
|
454 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
455 |
.. sourcecode:: text |
6754 | 456 |
|
457 |
reading from file second-2-0.pcap, link-type EN10MB (Ethernet) |
|
11049
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
458 |
2.007698 ARP, Request who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1, length 50 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
459 |
2.007710 ARP, Reply 10.1.2.4 is-at 00:00:00:00:00:06, length 50 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
460 |
2.007803 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
461 |
2.013815 ARP, Request who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4, length 50 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
462 |
2.013828 ARP, Reply 10.1.2.1 is-at 00:00:00:00:00:03, length 50 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
463 |
2.013921 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024 |
6754 | 464 |
|
465 |
As you can see, the link type is now "Ethernet". Something new has appeared, |
|
466 |
though. The bus network needs ``ARP``, the Address Resolution Protocol. |
|
467 |
Node one knows it needs to send the packet to IP address 10.1.2.4, but it |
|
468 |
doesn't know the MAC address of the corresponding node. It broadcasts on the |
|
469 |
CSMA network (ff:ff:ff:ff:ff:ff) asking for the device that has IP address |
|
470 |
10.1.2.4. In this case, the rightmost node replies saying it is at MAC address |
|
471 |
00:00:00:00:00:06. Note that node two is not directly involved in this |
|
472 |
exchange, but is sniffing the network and reporting all of the traffic it sees. |
|
473 |
||
474 |
This exchange is seen in the following lines, |
|
475 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
476 |
.. sourcecode:: text |
6754 | 477 |
|
11049
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
478 |
2.007698 ARP, Request who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1, length 50 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
479 |
2.007710 ARP, Reply 10.1.2.4 is-at 00:00:00:00:00:06, length 50 |
6754 | 480 |
|
481 |
Then node one, device one goes ahead and sends the echo packet to the UDP echo |
|
482 |
server at IP address 10.1.2.4. |
|
483 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
484 |
.. sourcecode:: text |
6754 | 485 |
|
11049
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
486 |
2.007803 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024 |
6754 | 487 |
|
488 |
The server receives the echo request and turns the packet around trying to send |
|
489 |
it back to the source. The server knows that this address is on another network |
|
490 |
that it reaches via IP address 10.1.2.1. This is because we initialized global |
|
491 |
routing and it has figured all of this out for us. But, the echo server node |
|
492 |
doesn't know the MAC address of the first CSMA node, so it has to ARP for it |
|
493 |
just like the first CSMA node had to do. |
|
494 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
495 |
.. sourcecode:: text |
6754 | 496 |
|
11049
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
497 |
2.013815 ARP, Request who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4, length 50 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
498 |
2.013828 ARP, Reply 10.1.2.1 is-at 00:00:00:00:00:03, length 50 |
6754 | 499 |
|
500 |
The server then sends the echo back to the forwarding node. |
|
501 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
502 |
.. sourcecode:: text |
6754 | 503 |
|
11049
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
504 |
2.013921 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024 |
6754 | 505 |
|
506 |
Looking back at the rightmost node of the point-to-point link, |
|
507 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
508 |
.. sourcecode:: bash |
6754 | 509 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
510 |
$ tcpdump -nn -tt -r second-1-0.pcap |
6754 | 511 |
|
512 |
You can now see the echoed packet coming back onto the point-to-point link as |
|
513 |
the last line of the trace dump. |
|
514 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
515 |
.. sourcecode:: text |
6754 | 516 |
|
517 |
reading from file second-1-0.pcap, link-type PPP (PPP) |
|
518 |
2.003686 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024 |
|
11049
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
519 |
2.013921 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024 |
6754 | 520 |
|
521 |
Lastly, you can look back at the node that originated the echo |
|
522 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
523 |
.. sourcecode:: bash |
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
524 |
|
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
525 |
$ tcpdump -nn -tt -r second-0-0.pcap |
6754 | 526 |
|
11221
243001f59f66
fix tutorial typos (found by Renan)
Tom Henderson <tomh@tomh.org>
parents:
11088
diff
changeset
|
527 |
and see that the echoed packet arrives back at the source at 2.017607 seconds, |
6754 | 528 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
529 |
.. sourcecode:: text |
6754 | 530 |
|
531 |
reading from file second-0-0.pcap, link-type PPP (PPP) |
|
532 |
2.000000 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024 |
|
11049
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
533 |
2.017607 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024 |
6754 | 534 |
|
535 |
Finally, recall that we added the ability to control the number of CSMA devices |
|
536 |
in the simulation by command line argument. You can change this argument in |
|
537 |
the same way as when we looked at changing the number of packets echoed in the |
|
538 |
``first.cc`` example. Try running the program with the number of "extra" |
|
539 |
devices set to four: |
|
540 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
541 |
.. sourcecode:: bash |
6754 | 542 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
543 |
$ ./waf --run "scratch/mysecond --nCsma=4" |
6754 | 544 |
|
545 |
You should now see, |
|
546 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
547 |
.. sourcecode:: text |
6754 | 548 |
|
549 |
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' |
|
550 |
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' |
|
551 |
'build' finished successfully (0.405s) |
|
11049
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
552 |
At time 2s client sent 1024 bytes to 10.1.2.5 port 9 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
553 |
At time 2.0118s server received 1024 bytes from 10.1.1.1 port 49153 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
554 |
At time 2.0118s server sent 1024 bytes to 10.1.1.1 port 49153 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
555 |
At time 2.02461s client received 1024 bytes from 10.1.2.5 port 9 |
6754 | 556 |
|
557 |
Notice that the echo server has now been relocated to the last of the CSMA |
|
558 |
nodes, which is 10.1.2.5 instead of the default case, 10.1.2.4. |
|
559 |
||
560 |
It is possible that you may not be satisfied with a trace file generated by |
|
561 |
a bystander in the CSMA network. You may really want to get a trace from |
|
562 |
a single device and you may not be interested in any other traffic on the |
|
563 |
network. You can do this fairly easily. |
|
564 |
||
565 |
Let's take a look at ``scratch/mysecond.cc`` and add that code enabling us |
|
566 |
to be more specific. ``ns-3`` helpers provide methods that take a node |
|
567 |
number and device number as parameters. Go ahead and replace the |
|
568 |
``EnablePcap`` calls with the calls below. |
|
569 |
||
570 |
:: |
|
571 |
||
572 |
pointToPoint.EnablePcap ("second", p2pNodes.Get (0)->GetId (), 0); |
|
573 |
csma.EnablePcap ("second", csmaNodes.Get (nCsma)->GetId (), 0, false); |
|
574 |
csma.EnablePcap ("second", csmaNodes.Get (nCsma-1)->GetId (), 0, false); |
|
575 |
||
576 |
We know that we want to create a pcap file with the base name "second" and |
|
577 |
we also know that the device of interest in both cases is going to be zero, |
|
578 |
so those parameters are not really interesting. |
|
579 |
||
580 |
In order to get the node number, you have two choices: first, nodes are |
|
581 |
numbered in a monotonically increasing fashion starting from zero in the |
|
582 |
order in which you created them. One way to get a node number is to figure |
|
583 |
this number out "manually" by contemplating the order of node creation. |
|
584 |
If you take a look at the network topology illustration at the beginning of |
|
585 |
the file, we did this for you and you can see that the last CSMA node is |
|
586 |
going to be node number ``nCsma + 1``. This approach can become |
|
587 |
annoyingly difficult in larger simulations. |
|
588 |
||
589 |
An alternate way, which we use here, is to realize that the |
|
590 |
``NodeContainers`` contain pointers to |ns3| ``Node`` Objects. |
|
591 |
The ``Node`` Object has a method called ``GetId`` which will return that |
|
592 |
node's ID, which is the node number we seek. Let's go take a look at the |
|
593 |
Doxygen for the ``Node`` and locate that method, which is further down in |
|
594 |
the |ns3| core code than we've seen so far; but sometimes you have to |
|
595 |
search diligently for useful things. |
|
596 |
||
597 |
Go to the Doxygen documentation for your release (recall that you can find it |
|
598 |
on the project web site). You can get to the ``Node`` documentation by |
|
599 |
looking through at the "Classes" tab and scrolling down the "Class List" |
|
600 |
until you find ``ns3::Node``. Select ``ns3::Node`` and you will be taken |
|
601 |
to the documentation for the ``Node`` class. If you now scroll down to the |
|
602 |
``GetId`` method and select it, you will be taken to the detailed |
|
603 |
documentation for the method. Using the ``GetId`` method can make |
|
604 |
determining node numbers much easier in complex topologies. |
|
605 |
||
606 |
Let's clear the old trace files out of the top-level directory to avoid confusion |
|
607 |
about what is going on, |
|
608 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
609 |
.. sourcecode:: bash |
6754 | 610 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
611 |
$ rm *.pcap |
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
612 |
$ rm *.tr |
6754 | 613 |
|
614 |
If you build the new script and run the simulation setting ``nCsma`` to 100, |
|
615 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
616 |
.. sourcecode:: bash |
6754 | 617 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
618 |
$ ./waf --run "scratch/mysecond --nCsma=100" |
6754 | 619 |
|
620 |
you will see the following output: |
|
621 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
622 |
.. sourcecode:: text |
6754 | 623 |
|
624 |
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' |
|
625 |
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' |
|
626 |
'build' finished successfully (0.407s) |
|
11049
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
627 |
At time 2s client sent 1024 bytes to 10.1.2.101 port 9 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
628 |
At time 2.0068s server received 1024 bytes from 10.1.1.1 port 49153 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
629 |
At time 2.0068s server sent 1024 bytes to 10.1.1.1 port 49153 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
630 |
At time 2.01761s client received 1024 bytes from 10.1.2.101 port 9 |
6754 | 631 |
|
632 |
Note that the echo server is now located at 10.1.2.101 which corresponds to |
|
633 |
having 100 "extra" CSMA nodes with the echo server on the last one. If you |
|
634 |
list the pcap files in the top level directory you will see, |
|
635 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
636 |
.. sourcecode:: text |
6754 | 637 |
|
638 |
second-0-0.pcap second-100-0.pcap second-101-0.pcap |
|
639 |
||
640 |
The trace file ``second-0-0.pcap`` is the "leftmost" point-to-point device |
|
641 |
which is the echo packet source. The file ``second-101-0.pcap`` corresponds |
|
642 |
to the rightmost CSMA device which is where the echo server resides. You may |
|
643 |
have noticed that the final parameter on the call to enable pcap tracing on the |
|
644 |
echo server node was false. This means that the trace gathered on that node |
|
645 |
was in non-promiscuous mode. |
|
646 |
||
647 |
To illustrate the difference between promiscuous and non-promiscuous traces, we |
|
648 |
also requested a non-promiscuous trace for the next-to-last node. Go ahead and |
|
649 |
take a look at the ``tcpdump`` for ``second-100-0.pcap``. |
|
650 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
651 |
.. sourcecode:: bash |
6754 | 652 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
653 |
$ tcpdump -nn -tt -r second-100-0.pcap |
6754 | 654 |
|
655 |
You can now see that node 100 is really a bystander in the echo exchange. The |
|
656 |
only packets that it receives are the ARP requests which are broadcast to the |
|
657 |
entire CSMA network. |
|
658 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
659 |
.. sourcecode:: text |
6754 | 660 |
|
661 |
reading from file second-100-0.pcap, link-type EN10MB (Ethernet) |
|
11049
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
662 |
2.006698 ARP, Request who-has 10.1.2.101 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1, length 50 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
663 |
2.013815 ARP, Request who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.101, length 50 |
6754 | 664 |
|
665 |
Now take a look at the ``tcpdump`` for ``second-101-0.pcap``. |
|
666 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
667 |
.. sourcecode:: bash |
6754 | 668 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
669 |
$ tcpdump -nn -tt -r second-101-0.pcap |
6754 | 670 |
|
671 |
You can now see that node 101 is really the participant in the echo exchange. |
|
672 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
673 |
.. sourcecode:: text |
6754 | 674 |
|
675 |
reading from file second-101-0.pcap, link-type EN10MB (Ethernet) |
|
11049
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
676 |
2.006698 ARP, Request who-has 10.1.2.101 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1, length 50 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
677 |
2.006698 ARP, Reply 10.1.2.101 is-at 00:00:00:00:00:67, length 50 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
678 |
2.006803 IP 10.1.1.1.49153 > 10.1.2.101.9: UDP, length 1024 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
679 |
2.013803 ARP, Request who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.101, length 50 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
680 |
2.013828 ARP, Reply 10.1.2.1 is-at 00:00:00:00:00:03, length 50 |
e6e6201f32f5
update tutorial second.cc program output
Tom Henderson <tomh@tomh.org>
parents:
9957
diff
changeset
|
681 |
2.013828 IP 10.1.2.101.9 > 10.1.1.1.49153: UDP, length 1024 |
6754 | 682 |
|
683 |
Models, Attributes and Reality |
|
684 |
****************************** |
|
685 |
||
686 |
This is a convenient place to make a small excursion and make an important |
|
687 |
point. It may or may not be obvious to you, but whenever one is using a |
|
688 |
simulation, it is important to understand exactly what is being modeled and |
|
689 |
what is not. It is tempting, for example, to think of the CSMA devices |
|
690 |
and channels used in the previous section as if they were real Ethernet |
|
691 |
devices; and to expect a simulation result to directly reflect what will |
|
692 |
happen in a real Ethernet. This is not the case. |
|
693 |
||
694 |
A model is, by definition, an abstraction of reality. It is ultimately the |
|
695 |
responsibility of the simulation script author to determine the so-called |
|
696 |
"range of accuracy" and "domain of applicability" of the simulation as |
|
697 |
a whole, and therefore its constituent parts. |
|
698 |
||
699 |
In some cases, like ``Csma``, it can be fairly easy to determine what is |
|
700 |
*not* modeled. By reading the model description (``csma.h``) you |
|
701 |
can find that there is no collision detection in the CSMA model and decide |
|
702 |
on how applicable its use will be in your simulation or what caveats you |
|
703 |
may want to include with your results. In other cases, it can be quite easy |
|
704 |
to configure behaviors that might not agree with any reality you can go out |
|
705 |
and buy. It will prove worthwhile to spend some time investigating a few |
|
706 |
such instances, and how easily you can swerve outside the bounds of reality |
|
707 |
in your simulations. |
|
708 |
||
709 |
As you have seen, |ns3| provides ``Attributes`` which a user |
|
710 |
can easily set to change model behavior. Consider two of the ``Attributes`` |
|
711 |
of the ``CsmaNetDevice``: ``Mtu`` and ``EncapsulationMode``. |
|
712 |
The ``Mtu`` attribute indicates the Maximum Transmission Unit to the |
|
713 |
device. This is the size of the largest Protocol Data Unit (PDU) that the |
|
714 |
device can send. |
|
715 |
||
716 |
The MTU defaults to 1500 bytes in the ``CsmaNetDevice``. This default |
|
717 |
corresponds to a number found in RFC 894, "A Standard for the Transmission |
|
718 |
of IP Datagrams over Ethernet Networks." The number is actually derived |
|
719 |
from the maximum packet size for 10Base5 (full-spec Ethernet) networks -- |
|
720 |
1518 bytes. If you subtract the DIX encapsulation overhead for Ethernet |
|
721 |
packets (18 bytes) you will end up with a maximum possible data size (MTU) |
|
722 |
of 1500 bytes. One can also find that the ``MTU`` for IEEE 802.3 networks |
|
723 |
is 1492 bytes. This is because LLC/SNAP encapsulation adds an extra eight |
|
724 |
bytes of overhead to the packet. In both cases, the underlying hardware can |
|
725 |
only send 1518 bytes, but the data size is different. |
|
726 |
||
727 |
In order to set the encapsulation mode, the ``CsmaNetDevice`` provides |
|
728 |
an ``Attribute`` called ``EncapsulationMode`` which can take on the |
|
729 |
values ``Dix`` or ``Llc``. These correspond to Ethernet and LLC/SNAP |
|
730 |
framing respectively. |
|
731 |
||
732 |
If one leaves the ``Mtu`` at 1500 bytes and changes the encapsulation mode |
|
733 |
to ``Llc``, the result will be a network that encapsulates 1500 byte PDUs |
|
734 |
with LLC/SNAP framing resulting in packets of 1526 bytes, which would be |
|
735 |
illegal in many networks, since they can transmit a maximum of 1518 bytes per |
|
736 |
packet. This would most likely result in a simulation that quite subtly does |
|
737 |
not reflect the reality you might be expecting. |
|
738 |
||
739 |
Just to complicate the picture, there exist jumbo frames (1500 < MTU <= 9000 bytes) |
|
740 |
and super-jumbo (MTU > 9000 bytes) frames that are not officially sanctioned |
|
741 |
by IEEE but are available in some high-speed (Gigabit) networks and NICs. One |
|
742 |
could leave the encapsulation mode set to ``Dix``, and set the ``Mtu`` |
|
743 |
``Attribute`` on a ``CsmaNetDevice`` to 64000 bytes -- even though an |
|
744 |
associated ``CsmaChannel DataRate`` was set at 10 megabits per second. |
|
745 |
This would essentially model an Ethernet switch made out of vampire-tapped |
|
746 |
1980s-style 10Base5 networks that support super-jumbo datagrams. This is |
|
747 |
certainly not something that was ever made, nor is likely to ever be made, |
|
748 |
but it is quite easy for you to configure. |
|
749 |
||
750 |
In the previous example, you used the command line to create a simulation that |
|
751 |
had 100 ``Csma`` nodes. You could have just as easily created a simulation |
|
752 |
with 500 nodes. If you were actually modeling that 10Base5 vampire-tap network, |
|
753 |
the maximum length of a full-spec Ethernet cable is 500 meters, with a minimum |
|
754 |
tap spacing of 2.5 meters. That means there could only be 200 taps on a |
|
755 |
real network. You could have quite easily built an illegal network in that |
|
756 |
way as well. This may or may not result in a meaningful simulation depending |
|
757 |
on what you are trying to model. |
|
758 |
||
759 |
Similar situations can occur in many places in |ns3| and in any |
|
760 |
simulator. For example, you may be able to position nodes in such a way that |
|
761 |
they occupy the same space at the same time, or you may be able to configure |
|
762 |
amplifiers or noise levels that violate the basic laws of physics. |
|
763 |
||
764 |
|ns3| generally favors flexibility, and many models will allow freely |
|
765 |
setting ``Attributes`` without trying to enforce any arbitrary consistency |
|
766 |
or particular underlying spec. |
|
767 |
||
768 |
The thing to take home from this is that |ns3| is going to provide a |
|
769 |
super-flexible base for you to experiment with. It is up to you to understand |
|
770 |
what you are asking the system to do and to make sure that the simulations you |
|
771 |
create have some meaning and some connection with a reality defined by you. |
|
772 |
||
773 |
Building a Wireless Network Topology |
|
774 |
************************************ |
|
775 |
||
776 |
In this section we are going to further expand our knowledge of |ns3| |
|
777 |
network devices and channels to cover an example of a wireless network. |
|
778 |
|ns3| provides a set of 802.11 models that attempt to provide an |
|
779 |
accurate MAC-level implementation of the 802.11 specification and a |
|
780 |
"not-so-slow" PHY-level model of the 802.11a specification. |
|
781 |
||
782 |
Just as we have seen both point-to-point and CSMA topology helper objects when |
|
783 |
constructing point-to-point topologies, we will see equivalent ``Wifi`` |
|
784 |
topology helpers in this section. The appearance and operation of these |
|
785 |
helpers should look quite familiar to you. |
|
786 |
||
787 |
We provide an example script in our ``examples/tutorial`` directory. This script |
|
788 |
builds on the ``second.cc`` script and adds a Wifi network. Go ahead and |
|
789 |
open ``examples/tutorial/third.cc`` in your favorite editor. You will have already |
|
790 |
seen enough |ns3| code to understand most of what is going on in |
|
791 |
this example, but there are a few new things, so we will go over the entire |
|
792 |
script and examine some of the output. |
|
793 |
||
794 |
Just as in the ``second.cc`` example (and in all |ns3| examples) |
|
795 |
the file begins with an emacs mode line and some GPL boilerplate. |
|
796 |
||
797 |
Take a look at the ASCII art (reproduced below) that shows the default network |
|
798 |
topology constructed in the example. You can see that we are going to |
|
799 |
further extend our example by hanging a wireless network off of the left side. |
|
800 |
Notice that this is a default network topology since you can actually vary the |
|
801 |
number of nodes created on the wired and wireless networks. Just as in the |
|
802 |
``second.cc`` script case, if you change ``nCsma``, it will give you a |
|
803 |
number of "extra" CSMA nodes. Similarly, you can set ``nWifi`` to |
|
804 |
control how many ``STA`` (station) nodes are created in the simulation. |
|
805 |
There will always be one ``AP`` (access point) node on the wireless |
|
806 |
network. By default there are three "extra" CSMA nodes and three wireless |
|
807 |
``STA`` nodes. |
|
808 |
||
809 |
The code begins by loading module include files just as was done in the |
|
810 |
``second.cc`` example. There are a couple of new includes corresponding |
|
811 |
to the Wifi module and the mobility module which we will discuss below. |
|
812 |
||
813 |
:: |
|
814 |
||
815 |
#include "ns3/core-module.h" |
|
7772
a27e716d01d9
update tutorial per bug 843 changes
Rohit Agarwal <mindprince@gmail.com>
parents:
7275
diff
changeset
|
816 |
#include "ns3/point-to-point-module.h" |
7137
dbefbad7bee3
Fix module names in documentation
Mitch Watrous <watrous@u.washington.edu>
parents:
6754
diff
changeset
|
817 |
#include "ns3/network-module.h" |
7772
a27e716d01d9
update tutorial per bug 843 changes
Rohit Agarwal <mindprince@gmail.com>
parents:
7275
diff
changeset
|
818 |
#include "ns3/applications-module.h" |
a27e716d01d9
update tutorial per bug 843 changes
Rohit Agarwal <mindprince@gmail.com>
parents:
7275
diff
changeset
|
819 |
#include "ns3/wifi-module.h" |
a27e716d01d9
update tutorial per bug 843 changes
Rohit Agarwal <mindprince@gmail.com>
parents:
7275
diff
changeset
|
820 |
#include "ns3/mobility-module.h" |
7137
dbefbad7bee3
Fix module names in documentation
Mitch Watrous <watrous@u.washington.edu>
parents:
6754
diff
changeset
|
821 |
#include "ns3/csma-module.h" |
dbefbad7bee3
Fix module names in documentation
Mitch Watrous <watrous@u.washington.edu>
parents:
6754
diff
changeset
|
822 |
#include "ns3/internet-module.h" |
6754 | 823 |
|
824 |
The network topology illustration follows: |
|
825 |
||
826 |
:: |
|
827 |
||
828 |
// Default Network Topology |
|
829 |
// |
|
830 |
// Wifi 10.1.3.0 |
|
831 |
// AP |
|
832 |
// * * * * |
|
833 |
// | | | | 10.1.1.0 |
|
834 |
// n5 n6 n7 n0 -------------- n1 n2 n3 n4 |
|
835 |
// point-to-point | | | | |
|
836 |
// ================ |
|
837 |
// LAN 10.1.2.0 |
|
838 |
||
839 |
You can see that we are adding a new network device to the node on the left |
|
840 |
side of the point-to-point link that becomes the access point for the wireless |
|
841 |
network. A number of wireless STA nodes are created to fill out the new |
|
842 |
10.1.3.0 network as shown on the left side of the illustration. |
|
843 |
||
844 |
After the illustration, the ``ns-3`` namespace is ``used`` and a logging |
|
845 |
component is defined. This should all be quite familiar by now. |
|
846 |
||
847 |
:: |
|
848 |
||
849 |
using namespace ns3; |
|
850 |
||
851 |
NS_LOG_COMPONENT_DEFINE ("ThirdScriptExample"); |
|
852 |
||
853 |
The main program begins just like ``second.cc`` by adding some command line |
|
854 |
parameters for enabling or disabling logging components and for changing the |
|
855 |
number of devices created. |
|
856 |
||
857 |
:: |
|
858 |
||
859 |
bool verbose = true; |
|
860 |
uint32_t nCsma = 3; |
|
861 |
uint32_t nWifi = 3; |
|
862 |
||
863 |
CommandLine cmd; |
|
864 |
cmd.AddValue ("nCsma", "Number of \"extra\" CSMA nodes/devices", nCsma); |
|
865 |
cmd.AddValue ("nWifi", "Number of wifi STA devices", nWifi); |
|
866 |
cmd.AddValue ("verbose", "Tell echo applications to log if true", verbose); |
|
867 |
||
868 |
cmd.Parse (argc,argv); |
|
869 |
||
870 |
if (verbose) |
|
871 |
{ |
|
872 |
LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO); |
|
873 |
LogComponentEnable("UdpEchoServerApplication", LOG_LEVEL_INFO); |
|
874 |
} |
|
875 |
||
876 |
Just as in all of the previous examples, the next step is to create two nodes |
|
877 |
that we will connect via the point-to-point link. |
|
878 |
||
879 |
:: |
|
880 |
||
881 |
NodeContainer p2pNodes; |
|
882 |
p2pNodes.Create (2); |
|
883 |
||
884 |
Next, we see an old friend. We instantiate a ``PointToPointHelper`` and |
|
885 |
set the associated default ``Attributes`` so that we create a five megabit |
|
886 |
per second transmitter on devices created using the helper and a two millisecond |
|
11221
243001f59f66
fix tutorial typos (found by Renan)
Tom Henderson <tomh@tomh.org>
parents:
11088
diff
changeset
|
887 |
delay on channels created by the helper. We then ``Install`` the devices |
6754 | 888 |
on the nodes and the channel between them. |
889 |
||
890 |
:: |
|
891 |
||
892 |
PointToPointHelper pointToPoint; |
|
893 |
pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps")); |
|
894 |
pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms")); |
|
895 |
||
896 |
NetDeviceContainer p2pDevices; |
|
897 |
p2pDevices = pointToPoint.Install (p2pNodes); |
|
898 |
||
899 |
Next, we declare another ``NodeContainer`` to hold the nodes that will be |
|
900 |
part of the bus (CSMA) network. |
|
901 |
||
902 |
:: |
|
903 |
||
904 |
NodeContainer csmaNodes; |
|
905 |
csmaNodes.Add (p2pNodes.Get (1)); |
|
906 |
csmaNodes.Create (nCsma); |
|
907 |
||
908 |
The next line of code ``Gets`` the first node (as in having an index of one) |
|
909 |
from the point-to-point node container and adds it to the container of nodes |
|
910 |
that will get CSMA devices. The node in question is going to end up with a |
|
911 |
point-to-point device and a CSMA device. We then create a number of "extra" |
|
912 |
nodes that compose the remainder of the CSMA network. |
|
913 |
||
914 |
We then instantiate a ``CsmaHelper`` and set its ``Attributes`` as we did |
|
915 |
in the previous example. We create a ``NetDeviceContainer`` to keep track of |
|
916 |
the created CSMA net devices and then we ``Install`` CSMA devices on the |
|
917 |
selected nodes. |
|
918 |
||
919 |
:: |
|
920 |
||
921 |
CsmaHelper csma; |
|
922 |
csma.SetChannelAttribute ("DataRate", StringValue ("100Mbps")); |
|
923 |
csma.SetChannelAttribute ("Delay", TimeValue (NanoSeconds (6560))); |
|
924 |
||
925 |
NetDeviceContainer csmaDevices; |
|
926 |
csmaDevices = csma.Install (csmaNodes); |
|
927 |
||
928 |
Next, we are going to create the nodes that will be part of the Wifi network. |
|
929 |
We are going to create a number of "station" nodes as specified by the |
|
930 |
command line argument, and we are going to use the "leftmost" node of the |
|
931 |
point-to-point link as the node for the access point. |
|
932 |
||
933 |
:: |
|
934 |
||
935 |
NodeContainer wifiStaNodes; |
|
936 |
wifiStaNodes.Create (nWifi); |
|
937 |
NodeContainer wifiApNode = p2pNodes.Get (0); |
|
938 |
||
939 |
The next bit of code constructs the wifi devices and the interconnection |
|
940 |
channel between these wifi nodes. First, we configure the PHY and channel |
|
941 |
helpers: |
|
942 |
||
943 |
:: |
|
944 |
||
945 |
YansWifiChannelHelper channel = YansWifiChannelHelper::Default (); |
|
946 |
YansWifiPhyHelper phy = YansWifiPhyHelper::Default (); |
|
947 |
||
948 |
For simplicity, this code uses the default PHY layer configuration and |
|
949 |
channel models which are documented in the API doxygen documentation for |
|
950 |
the ``YansWifiChannelHelper::Default`` and ``YansWifiPhyHelper::Default`` |
|
951 |
methods. Once these objects are created, we create a channel object |
|
952 |
and associate it to our PHY layer object manager to make sure |
|
953 |
that all the PHY layer objects created by the ``YansWifiPhyHelper`` |
|
954 |
share the same underlying channel, that is, they share the same |
|
955 |
wireless medium and can communication and interfere: |
|
956 |
||
957 |
:: |
|
958 |
||
959 |
phy.SetChannel (channel.Create ()); |
|
960 |
||
961 |
Once the PHY helper is configured, we can focus on the MAC layer. Here we choose to |
|
962 |
work with non-Qos MACs so we use a NqosWifiMacHelper object to set MAC parameters. |
|
963 |
||
964 |
:: |
|
965 |
||
966 |
WifiHelper wifi = WifiHelper::Default (); |
|
967 |
wifi.SetRemoteStationManager ("ns3::AarfWifiManager"); |
|
968 |
||
969 |
NqosWifiMacHelper mac = NqosWifiMacHelper::Default (); |
|
970 |
||
971 |
The ``SetRemoteStationManager`` method tells the helper the type of |
|
972 |
rate control algorithm to use. Here, it is asking the helper to use the AARF |
|
973 |
algorithm --- details are, of course, available in Doxygen. |
|
974 |
||
975 |
Next, we configure the type of MAC, the SSID of the infrastructure network we |
|
976 |
want to setup and make sure that our stations don't perform active probing: |
|
977 |
||
978 |
:: |
|
979 |
||
980 |
Ssid ssid = Ssid ("ns-3-ssid"); |
|
981 |
mac.SetType ("ns3::StaWifiMac", |
|
982 |
"Ssid", SsidValue (ssid), |
|
983 |
"ActiveProbing", BooleanValue (false)); |
|
984 |
||
985 |
This code first creates an 802.11 service set identifier (SSID) object |
|
986 |
that will be used to set the value of the "Ssid" ``Attribute`` of |
|
987 |
the MAC layer implementation. The particular kind of MAC layer that |
|
988 |
will be created by the helper is specified by ``Attribute`` as |
|
989 |
being of the "ns3::StaWifiMac" type. The use of |
|
990 |
``NqosWifiMacHelper`` will ensure that the "QosSupported" |
|
991 |
``Attribute`` for created MAC objects is set false. The combination |
|
992 |
of these two configurations means that the MAC instance next created |
|
993 |
will be a non-QoS non-AP station (STA) in an infrastructure BSS (i.e., |
|
994 |
a BSS with an AP). Finally, the "ActiveProbing" ``Attribute`` is |
|
995 |
set to false. This means that probe requests will not be sent by MACs |
|
996 |
created by this helper. |
|
997 |
||
998 |
Once all the station-specific parameters are fully configured, both at the |
|
999 |
MAC and PHY layers, we can invoke our now-familiar ``Install`` method to |
|
1000 |
create the wifi devices of these stations: |
|
1001 |
||
1002 |
:: |
|
1003 |
||
1004 |
NetDeviceContainer staDevices; |
|
1005 |
staDevices = wifi.Install (phy, mac, wifiStaNodes); |
|
1006 |
||
1007 |
We have configured Wifi for all of our STA nodes, and now we need to |
|
1008 |
configure the AP (access point) node. We begin this process by changing |
|
1009 |
the default ``Attributes`` of the ``NqosWifiMacHelper`` to reflect the |
|
1010 |
requirements of the AP. |
|
1011 |
||
1012 |
:: |
|
1013 |
||
1014 |
mac.SetType ("ns3::ApWifiMac", |
|
7772
a27e716d01d9
update tutorial per bug 843 changes
Rohit Agarwal <mindprince@gmail.com>
parents:
7275
diff
changeset
|
1015 |
"Ssid", SsidValue (ssid)); |
6754 | 1016 |
|
1017 |
In this case, the ``NqosWifiMacHelper`` is going to create MAC |
|
1018 |
layers of the "ns3::ApWifiMac", the latter specifying that a MAC |
|
1019 |
instance configured as an AP should be created, with the helper type |
|
1020 |
implying that the "QosSupported" ``Attribute`` should be set to |
|
7772
a27e716d01d9
update tutorial per bug 843 changes
Rohit Agarwal <mindprince@gmail.com>
parents:
7275
diff
changeset
|
1021 |
false - disabling 802.11e/WMM-style QoS support at created APs. |
6754 | 1022 |
|
1023 |
The next lines create the single AP which shares the same set of PHY-level |
|
1024 |
``Attributes`` (and channel) as the stations: |
|
1025 |
||
1026 |
:: |
|
1027 |
||
1028 |
NetDeviceContainer apDevices; |
|
1029 |
apDevices = wifi.Install (phy, mac, wifiApNode); |
|
1030 |
||
1031 |
Now, we are going to add mobility models. We want the STA nodes to be mobile, |
|
1032 |
wandering around inside a bounding box, and we want to make the AP node |
|
1033 |
stationary. We use the ``MobilityHelper`` to make this easy for us. |
|
1034 |
First, we instantiate a ``MobilityHelper`` object and set some |
|
1035 |
``Attributes`` controlling the "position allocator" functionality. |
|
1036 |
||
1037 |
:: |
|
1038 |
||
1039 |
MobilityHelper mobility; |
|
1040 |
||
1041 |
mobility.SetPositionAllocator ("ns3::GridPositionAllocator", |
|
1042 |
"MinX", DoubleValue (0.0), |
|
1043 |
"MinY", DoubleValue (0.0), |
|
1044 |
"DeltaX", DoubleValue (5.0), |
|
1045 |
"DeltaY", DoubleValue (10.0), |
|
1046 |
"GridWidth", UintegerValue (3), |
|
1047 |
"LayoutType", StringValue ("RowFirst")); |
|
1048 |
||
1049 |
This code tells the mobility helper to use a two-dimensional grid to initially |
|
1050 |
place the STA nodes. Feel free to explore the Doxygen for class |
|
1051 |
``ns3::GridPositionAllocator`` to see exactly what is being done. |
|
1052 |
||
1053 |
We have arranged our nodes on an initial grid, but now we need to tell them |
|
1054 |
how to move. We choose the ``RandomWalk2dMobilityModel`` which has the |
|
1055 |
nodes move in a random direction at a random speed around inside a bounding |
|
1056 |
box. |
|
1057 |
||
1058 |
:: |
|
1059 |
||
1060 |
mobility.SetMobilityModel ("ns3::RandomWalk2dMobilityModel", |
|
1061 |
"Bounds", RectangleValue (Rectangle (-50, 50, -50, 50))); |
|
1062 |
||
1063 |
We now tell the ``MobilityHelper`` to install the mobility models on the |
|
1064 |
STA nodes. |
|
1065 |
||
1066 |
:: |
|
1067 |
||
1068 |
mobility.Install (wifiStaNodes); |
|
1069 |
||
1070 |
We want the access point to remain in a fixed position during the simulation. |
|
1071 |
We accomplish this by setting the mobility model for this node to be the |
|
1072 |
``ns3::ConstantPositionMobilityModel``: |
|
1073 |
||
1074 |
:: |
|
1075 |
||
1076 |
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel"); |
|
1077 |
mobility.Install (wifiApNode); |
|
1078 |
||
1079 |
We now have our nodes, devices and channels created, and mobility models |
|
1080 |
chosen for the Wifi nodes, but we have no protocol stacks present. Just as |
|
1081 |
we have done previously many times, we will use the ``InternetStackHelper`` |
|
1082 |
to install these stacks. |
|
1083 |
||
1084 |
:: |
|
1085 |
||
1086 |
InternetStackHelper stack; |
|
1087 |
stack.Install (csmaNodes); |
|
1088 |
stack.Install (wifiApNode); |
|
1089 |
stack.Install (wifiStaNodes); |
|
1090 |
||
1091 |
Just as in the ``second.cc`` example script, we are going to use the |
|
1092 |
``Ipv4AddressHelper`` to assign IP addresses to our device interfaces. |
|
1093 |
First we use the network 10.1.1.0 to create the two addresses needed for our |
|
1094 |
two point-to-point devices. Then we use network 10.1.2.0 to assign addresses |
|
1095 |
to the CSMA network and then we assign addresses from network 10.1.3.0 to |
|
1096 |
both the STA devices and the AP on the wireless network. |
|
1097 |
||
1098 |
:: |
|
1099 |
||
1100 |
Ipv4AddressHelper address; |
|
1101 |
||
1102 |
address.SetBase ("10.1.1.0", "255.255.255.0"); |
|
1103 |
Ipv4InterfaceContainer p2pInterfaces; |
|
1104 |
p2pInterfaces = address.Assign (p2pDevices); |
|
1105 |
||
1106 |
address.SetBase ("10.1.2.0", "255.255.255.0"); |
|
1107 |
Ipv4InterfaceContainer csmaInterfaces; |
|
1108 |
csmaInterfaces = address.Assign (csmaDevices); |
|
1109 |
||
1110 |
address.SetBase ("10.1.3.0", "255.255.255.0"); |
|
1111 |
address.Assign (staDevices); |
|
1112 |
address.Assign (apDevices); |
|
1113 |
||
1114 |
We put the echo server on the "rightmost" node in the illustration at the |
|
1115 |
start of the file. We have done this before. |
|
1116 |
||
1117 |
:: |
|
1118 |
||
1119 |
UdpEchoServerHelper echoServer (9); |
|
1120 |
||
1121 |
ApplicationContainer serverApps = echoServer.Install (csmaNodes.Get (nCsma)); |
|
1122 |
serverApps.Start (Seconds (1.0)); |
|
1123 |
serverApps.Stop (Seconds (10.0)); |
|
1124 |
||
1125 |
And we put the echo client on the last STA node we created, pointing it to |
|
1126 |
the server on the CSMA network. We have also seen similar operations before. |
|
1127 |
||
1128 |
:: |
|
1129 |
||
1130 |
UdpEchoClientHelper echoClient (csmaInterfaces.GetAddress (nCsma), 9); |
|
1131 |
echoClient.SetAttribute ("MaxPackets", UintegerValue (1)); |
|
9112
ede7a74e7411
bug 1514: make TimeValue usage consistent in the tutorial
Tom Henderson <tomh@tomh.org>
parents:
7772
diff
changeset
|
1132 |
echoClient.SetAttribute ("Interval", TimeValue (Seconds (1.0))); |
6754 | 1133 |
echoClient.SetAttribute ("PacketSize", UintegerValue (1024)); |
1134 |
||
1135 |
ApplicationContainer clientApps = |
|
1136 |
echoClient.Install (wifiStaNodes.Get (nWifi - 1)); |
|
1137 |
clientApps.Start (Seconds (2.0)); |
|
1138 |
clientApps.Stop (Seconds (10.0)); |
|
1139 |
||
1140 |
Since we have built an internetwork here, we need to enable internetwork routing |
|
1141 |
just as we did in the ``second.cc`` example script. |
|
1142 |
||
1143 |
:: |
|
1144 |
||
1145 |
Ipv4GlobalRoutingHelper::PopulateRoutingTables (); |
|
1146 |
||
1147 |
One thing that can surprise some users is the fact that the simulation we just |
|
1148 |
created will never "naturally" stop. This is because we asked the wireless |
|
1149 |
access point to generate beacons. It will generate beacons forever, and this |
|
1150 |
will result in simulator events being scheduled into the future indefinitely, |
|
1151 |
so we must tell the simulator to stop even though it may have beacon generation |
|
1152 |
events scheduled. The following line of code tells the simulator to stop so that |
|
1153 |
we don't simulate beacons forever and enter what is essentially an endless |
|
1154 |
loop. |
|
1155 |
||
1156 |
:: |
|
1157 |
||
1158 |
Simulator::Stop (Seconds (10.0)); |
|
1159 |
||
1160 |
We create just enough tracing to cover all three networks: |
|
1161 |
||
1162 |
:: |
|
1163 |
||
1164 |
pointToPoint.EnablePcapAll ("third"); |
|
1165 |
phy.EnablePcap ("third", apDevices.Get (0)); |
|
1166 |
csma.EnablePcap ("third", csmaDevices.Get (0), true); |
|
1167 |
||
1168 |
These three lines of code will start pcap tracing on both of the point-to-point |
|
1169 |
nodes that serves as our backbone, will start a promiscuous (monitor) mode |
|
1170 |
trace on the Wifi network, and will start a promiscuous trace on the CSMA |
|
1171 |
network. This will let us see all of the traffic with a minimum number of |
|
1172 |
trace files. |
|
1173 |
||
1174 |
Finally, we actually run the simulation, clean up and then exit the program. |
|
1175 |
||
1176 |
:: |
|
1177 |
||
1178 |
Simulator::Run (); |
|
1179 |
Simulator::Destroy (); |
|
1180 |
return 0; |
|
1181 |
} |
|
1182 |
||
1183 |
In order to run this example, you have to copy the ``third.cc`` example |
|
1184 |
script into the scratch directory and use Waf to build just as you did with |
|
1185 |
the ``second.cc`` example. If you are in the top-level directory of the |
|
1186 |
repository you would type, |
|
1187 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1188 |
.. sourcecode:: bash |
6754 | 1189 |
|
11050
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1190 |
$ cp examples/tutorial/third.cc scratch/mythird.cc |
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1191 |
$ ./waf |
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1192 |
$ ./waf --run scratch/mythird |
6754 | 1193 |
|
1194 |
Again, since we have set up the UDP echo applications just as we did in the |
|
1195 |
``second.cc`` script, you will see similar output. |
|
1196 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1197 |
.. sourcecode:: text |
6754 | 1198 |
|
1199 |
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' |
|
1200 |
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' |
|
1201 |
'build' finished successfully (0.407s) |
|
11050
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1202 |
At time 2s client sent 1024 bytes to 10.1.2.4 port 9 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1203 |
At time 2.01796s server received 1024 bytes from 10.1.3.3 port 49153 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1204 |
At time 2.01796s server sent 1024 bytes to 10.1.3.3 port 49153 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1205 |
At time 2.03364s client received 1024 bytes from 10.1.2.4 port 9 |
6754 | 1206 |
|
1207 |
Recall that the first message, ``Sent 1024 bytes to 10.1.2.4``," is the |
|
1208 |
UDP echo client sending a packet to the server. In this case, the client |
|
1209 |
is on the wireless network (10.1.3.0). The second message, |
|
1210 |
"``Received 1024 bytes from 10.1.3.3``," is from the UDP echo server, |
|
1211 |
generated when it receives the echo packet. The final message, |
|
1212 |
"``Received 1024 bytes from 10.1.2.4``," is from the echo client, indicating |
|
1213 |
that it has received its echo back from the server. |
|
1214 |
||
1215 |
If you now go and look in the top level directory, you will find four trace |
|
1216 |
files from this simulation, two from node zero and two from node one: |
|
1217 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1218 |
.. sourcecode:: text |
6754 | 1219 |
|
1220 |
third-0-0.pcap third-0-1.pcap third-1-0.pcap third-1-1.pcap |
|
1221 |
||
1222 |
The file "third-0-0.pcap" corresponds to the point-to-point device on node |
|
1223 |
zero -- the left side of the "backbone". The file "third-1-0.pcap" |
|
1224 |
corresponds to the point-to-point device on node one -- the right side of the |
|
1225 |
"backbone". The file "third-0-1.pcap" will be the promiscuous (monitor |
|
1226 |
mode) trace from the Wifi network and the file "third-1-1.pcap" will be the |
|
1227 |
promiscuous trace from the CSMA network. Can you verify this by inspecting |
|
1228 |
the code? |
|
1229 |
||
1230 |
Since the echo client is on the Wifi network, let's start there. Let's take |
|
1231 |
a look at the promiscuous (monitor mode) trace we captured on that network. |
|
1232 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1233 |
.. sourcecode:: bash |
6754 | 1234 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1235 |
$ tcpdump -nn -tt -r third-0-1.pcap |
6754 | 1236 |
|
1237 |
You should see some wifi-looking contents you haven't seen here before: |
|
1238 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1239 |
.. sourcecode:: text |
6754 | 1240 |
|
1241 |
reading from file third-0-1.pcap, link-type IEEE802_11 (802.11) |
|
7772
a27e716d01d9
update tutorial per bug 843 changes
Rohit Agarwal <mindprince@gmail.com>
parents:
7275
diff
changeset
|
1242 |
0.000025 Beacon (ns-3-ssid) [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS |
11050
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1243 |
0.000308 Assoc Request (ns-3-ssid) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1244 |
0.000324 Acknowledgment RA:00:00:00:00:00:08 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1245 |
0.000402 Assoc Response AID(0) :: Successful |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1246 |
0.000546 Acknowledgment RA:00:00:00:00:00:0a |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1247 |
0.000721 Assoc Request (ns-3-ssid) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1248 |
0.000737 Acknowledgment RA:00:00:00:00:00:07 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1249 |
0.000824 Assoc Response AID(0) :: Successful |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1250 |
0.000968 Acknowledgment RA:00:00:00:00:00:0a |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1251 |
0.001134 Assoc Request (ns-3-ssid) [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1252 |
0.001150 Acknowledgment RA:00:00:00:00:00:09 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1253 |
0.001273 Assoc Response AID(0) :: Successful |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1254 |
0.001417 Acknowledgment RA:00:00:00:00:00:0a |
7772
a27e716d01d9
update tutorial per bug 843 changes
Rohit Agarwal <mindprince@gmail.com>
parents:
7275
diff
changeset
|
1255 |
0.102400 Beacon (ns-3-ssid) [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS |
a27e716d01d9
update tutorial per bug 843 changes
Rohit Agarwal <mindprince@gmail.com>
parents:
7275
diff
changeset
|
1256 |
0.204800 Beacon (ns-3-ssid) [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS |
a27e716d01d9
update tutorial per bug 843 changes
Rohit Agarwal <mindprince@gmail.com>
parents:
7275
diff
changeset
|
1257 |
0.307200 Beacon (ns-3-ssid) [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS |
6754 | 1258 |
|
1259 |
You can see that the link type is now 802.11 as you would expect. You can |
|
1260 |
probably understand what is going on and find the IP echo request and response |
|
1261 |
packets in this trace. We leave it as an exercise to completely parse the |
|
1262 |
trace dump. |
|
1263 |
||
11221
243001f59f66
fix tutorial typos (found by Renan)
Tom Henderson <tomh@tomh.org>
parents:
11088
diff
changeset
|
1264 |
Now, look at the pcap file of the left side of the point-to-point link, |
6754 | 1265 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1266 |
.. sourcecode:: bash |
6754 | 1267 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1268 |
$ tcpdump -nn -tt -r third-0-0.pcap |
6754 | 1269 |
|
1270 |
Again, you should see some familiar looking contents: |
|
1271 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1272 |
.. sourcecode:: text |
6754 | 1273 |
|
1274 |
reading from file third-0-0.pcap, link-type PPP (PPP) |
|
11050
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1275 |
2.008151 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1276 |
2.026758 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024 |
6754 | 1277 |
|
1278 |
This is the echo packet going from left to right (from Wifi to CSMA) and back |
|
1279 |
again across the point-to-point link. |
|
1280 |
||
1281 |
Now, look at the pcap file of the right side of the point-to-point link, |
|
1282 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1283 |
.. sourcecode:: bash |
6754 | 1284 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1285 |
$ tcpdump -nn -tt -r third-1-0.pcap |
6754 | 1286 |
|
1287 |
Again, you should see some familiar looking contents: |
|
1288 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1289 |
.. sourcecode:: text |
6754 | 1290 |
|
1291 |
reading from file third-1-0.pcap, link-type PPP (PPP) |
|
11050
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1292 |
2.011837 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1293 |
2.023072 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024 |
6754 | 1294 |
|
1295 |
This is also the echo packet going from left to right (from Wifi to CSMA) and |
|
1296 |
back again across the point-to-point link with slightly different timings |
|
1297 |
as you might expect. |
|
1298 |
||
1299 |
The echo server is on the CSMA network, let's look at the promiscuous trace |
|
1300 |
there: |
|
1301 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1302 |
.. sourcecode:: bash |
6754 | 1303 |
|
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1304 |
$ tcpdump -nn -tt -r third-1-1.pcap |
6754 | 1305 |
|
1306 |
You should see some familiar looking contents: |
|
1307 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1308 |
.. sourcecode:: text |
6754 | 1309 |
|
1310 |
reading from file third-1-1.pcap, link-type EN10MB (Ethernet) |
|
11050
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1311 |
2.017837 ARP, Request who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1, length 50 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1312 |
2.017861 ARP, Reply 10.1.2.4 is-at 00:00:00:00:00:06, length 50 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1313 |
2.017861 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1314 |
2.022966 ARP, Request who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4, length 50 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1315 |
2.022966 ARP, Reply 10.1.2.1 is-at 00:00:00:00:00:03, length 50 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1316 |
2.023072 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024 |
6754 | 1317 |
|
1318 |
This should be easily understood. If you've forgotten, go back and look at |
|
1319 |
the discussion in ``second.cc``. This is the same sequence. |
|
1320 |
||
1321 |
Now, we spent a lot of time setting up mobility models for the wireless network |
|
1322 |
and so it would be a shame to finish up without even showing that the STA |
|
1323 |
nodes are actually moving around during the simulation. Let's do this by hooking |
|
1324 |
into the ``MobilityModel`` course change trace source. This is just a sneak |
|
1325 |
peek into the detailed tracing section which is coming up, but this seems a very |
|
1326 |
nice place to get an example in. |
|
1327 |
||
1328 |
As mentioned in the "Tweaking ns-3" section, the |ns3| tracing system |
|
1329 |
is divided into trace sources and trace sinks, and we provide functions to |
|
1330 |
connect the two. We will use the mobility model predefined course change |
|
1331 |
trace source to originate the trace events. We will need to write a trace |
|
1332 |
sink to connect to that source that will display some pretty information for |
|
1333 |
us. Despite its reputation as being difficult, it's really quite simple. |
|
9755
92b68bcb87f6
clarify statement in tutorial
Tom Henderson <tomh@tomh.org>
parents:
9112
diff
changeset
|
1334 |
Just before the main program of the ``scratch/mythird.cc`` script (i.e., |
92b68bcb87f6
clarify statement in tutorial
Tom Henderson <tomh@tomh.org>
parents:
9112
diff
changeset
|
1335 |
just after the ``NS_LOG_COMPONENT_DEFINE`` statement), add the |
6754 | 1336 |
following function: |
1337 |
||
1338 |
:: |
|
1339 |
||
1340 |
void |
|
1341 |
CourseChange (std::string context, Ptr<const MobilityModel> model) |
|
1342 |
{ |
|
1343 |
Vector position = model->GetPosition (); |
|
1344 |
NS_LOG_UNCOND (context << |
|
1345 |
" x = " << position.x << ", y = " << position.y); |
|
1346 |
} |
|
1347 |
||
1348 |
This code just pulls the position information from the mobility model and |
|
1349 |
unconditionally logs the x and y position of the node. We are |
|
1350 |
going to arrange for this function to be called every time the wireless |
|
1351 |
node with the echo client changes its position. We do this using the |
|
1352 |
``Config::Connect`` function. Add the following lines of code to the |
|
1353 |
script just before the ``Simulator::Run`` call. |
|
1354 |
||
1355 |
:: |
|
1356 |
||
1357 |
std::ostringstream oss; |
|
1358 |
oss << |
|
1359 |
"/NodeList/" << wifiStaNodes.Get (nWifi - 1)->GetId () << |
|
1360 |
"/$ns3::MobilityModel/CourseChange"; |
|
1361 |
||
1362 |
Config::Connect (oss.str (), MakeCallback (&CourseChange)); |
|
1363 |
||
1364 |
What we do here is to create a string containing the tracing namespace path |
|
1365 |
of the event to which we want to connect. First, we have to figure out which |
|
1366 |
node it is we want using the ``GetId`` method as described earlier. In the |
|
1367 |
case of the default number of CSMA and wireless nodes, this turns out to be |
|
1368 |
node seven and the tracing namespace path to the mobility model would look |
|
1369 |
like, |
|
1370 |
||
1371 |
:: |
|
1372 |
||
1373 |
/NodeList/7/$ns3::MobilityModel/CourseChange |
|
1374 |
||
1375 |
Based on the discussion in the tracing section, you may infer that this trace |
|
1376 |
path references the seventh node in the global NodeList. It specifies |
|
1377 |
what is called an aggregated object of type ``ns3::MobilityModel``. The |
|
1378 |
dollar sign prefix implies that the MobilityModel is aggregated to node seven. |
|
1379 |
The last component of the path means that we are hooking into the |
|
1380 |
"CourseChange" event of that model. |
|
1381 |
||
1382 |
We make a connection between the trace source in node seven with our trace |
|
1383 |
sink by calling ``Config::Connect`` and passing this namespace path. Once |
|
1384 |
this is done, every course change event on node seven will be hooked into our |
|
1385 |
trace sink, which will in turn print out the new position. |
|
1386 |
||
1387 |
If you now run the simulation, you will see the course changes displayed as |
|
1388 |
they happen. |
|
1389 |
||
9957
1a4d84a85bad
Manual and Tutorial syntax coloring
Peter D. Barnes, Jr. <barnes26@llnl.gov>
parents:
9755
diff
changeset
|
1390 |
.. sourcecode:: text |
6754 | 1391 |
|
11050
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1392 |
'build' finished successfully (5.989s) |
6754 | 1393 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10, y = 0 |
11050
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1394 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.3841, y = 0.923277 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1395 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.2049, y = 1.90708 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1396 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.8136, y = 1.11368 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1397 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.8452, y = 2.11318 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1398 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.9797, y = 3.10409 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1399 |
At time 2s client sent 1024 bytes to 10.1.2.4 port 9 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1400 |
At time 2.01796s server received 1024 bytes from 10.1.3.3 port 49153 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1401 |
At time 2.01796s server sent 1024 bytes to 10.1.3.3 port 49153 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1402 |
At time 2.03364s client received 1024 bytes from 10.1.2.4 port 9 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1403 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 11.3273, y = 4.04175 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1404 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 12.013, y = 4.76955 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1405 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 12.4317, y = 5.67771 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1406 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 11.4607, y = 5.91681 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1407 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 12.0155, y = 6.74878 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1408 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 13.0076, y = 6.62336 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1409 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 12.6285, y = 5.698 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1410 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 13.32, y = 4.97559 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1411 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 13.1134, y = 3.99715 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1412 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 13.8359, y = 4.68851 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1413 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 13.5953, y = 3.71789 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1414 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 12.7595, y = 4.26688 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1415 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 11.7629, y = 4.34913 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1416 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 11.2292, y = 5.19485 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1417 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10.2344, y = 5.09394 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1418 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.3601, y = 4.60846 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1419 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.40025, y = 4.32795 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1420 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.14292, y = 4.99761 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1421 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.08299, y = 5.99581 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1422 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.26068, y = 5.42677 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1423 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.35917, y = 6.42191 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1424 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.66805, y = 7.14466 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1425 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 6.71414, y = 6.84456 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1426 |
/NodeList/7/$ns3::MobilityModel/CourseChange x = 6.42489, y = 7.80181 |
1535244f85d6
update tutorial third.cc program output
Tom Henderson <tomh@tomh.org>
parents:
11049
diff
changeset
|
1427 |