[Ns-developers] NS3 Animation Interface and stand-alone animation tool
gjcarneiro at gmail.com
Mon Jan 26 03:43:40 PST 2009
2009/1/22 George Riley <riley at ece.gatech.edu>
> Hi All,
> I (with Raj's help :) uploaded a new ns3 repo called ns-3-netanim in user
> The modifications to the base ns3 code are nearly trivial; aside from some
> minor tweaks to some containers (for consistency with other containers, and
> some small conveniences), the only change of substance is a new trace event
> in the point to point net device, notifying when a packet has been
> THis trace callback provides some needed information regarding the source
> and destination of the packet, and the time of transmission and arrival.
> Also checked in is a dumbbell.cc and dumbbell.h, that simply construct
> a dumbbell topology of specified size (left and right leaf counts) and
> several methods to query the various nodes and devices in the topology.
> Also checked in is a new example "testdb.cc" that illustrates the use of
> the dumbbell
> object and the animation-interface object (described next)
> Finally, checked in are animation-interface.h and animation-interface.cc.
> These are NOT the animator, but rather just provide a simple method for
> an ns-3 simulation to provide outputs to an external animator. Raj and I
> discussed, and came up with four potential use cases (actually just three
> since two of the cases are nearly identical).
> 1) THe ns3 simulation writes a file, that is later used as input to the
> This is identical to the approach of the existing ns2 NAM.
> 2) The ns3 simulation writes to a tcp socket. In this case, the animator
> a) Run on the same host as ns3, connecting to "localhost"
> b) Run on any other host, connecting to the ns3 host system remotely.
> From the point of view of the ns3 process, (a) and (b) are identical.
> 3) The animation is built in the ns-3 simulation and runs as part of the
> ns3 simulation.
> The animation-interface.cc/h checked in support the first two use cases,
> but not the last. To get the animation built in to ns3 would require some
> waf help to locate the qt4 includes and libraries, and some "ifdefs" to
> compile without those (and or course without animation).
> Attached is the tar.gz source code for the stand-alone animator, which also
> supports use cases (1) and (2). Raj and I discussed where it should go,
> and decided on "contrib", but I did not yet check it in there, due to waf
> issues for compiling with qt4. This animator knows nothing about ns3
> and does not include any ns3 includes.
> Also attached is a short movie showing the output of the animator; this is
> a bit misleading, since the movie only shows the display window without
> the controls (stop, play, backup, etc). I will try to make a better movie
> showing the controls as well.
> The animator only (for now) supports wired, point to point links. I would
> hope to get wireless animation support soon, but it's a bit more complex.
> I would also want to (if possible) leverage Gustavo's mobility visualizer,
> but am not familiar with how he did that. There are of course quite a few
> enhancemnts I can imagine; setting node and packet colors, setting
> graphic files to be used for node objects (voip phones, routers, etc).
> Please comment. I am not recommending inclusion in the upcoming release
> or hold it up in any way, but the changes to basic ns3 are indeed minimal.
I am afraid I was unable to run NetAnim. The included binary is for OSX,
and there is some problem in the makefile:
make: *** No rule to make target
`/usr/local/Trolltech/Qt-4.4.0/mkspecs/macx-g++/qmake.conf', needed by
Regarding the core changes, I have to agree with Tom that it might not be a
good idea to add animation-specific trace sources. I think we can either
add Tx and Rx trace sources, with no time or duration (they could be derived
from Simulator::Now), or we have a single source like "Transfer" with begin
and end time. But not both; that would be duplication of functionality,
IMHO, and to be avoided. And I think separate Tx and Rx events are
slightly more flexible than a single event for both.
Regarding the "animation interface", well I guess it tries to fulfill a role
similar to pcap or ascii tracing functions. So following similar style as
them makes some sense, i.e. helper-like functions.
Regarding wireless, in the case of pyviz I do not try to represent an
animated packet traveling, only an arrow at the time of packet reception by
the receiving node, so my job is simplified. Nevertheless, it was easy
enough to obtain the needed information via Tx and Rx event in the
WifiNetDevice. But if you want to represent a packet traveling you cannot
use Tx plus Rx and take the time difference as transmission time because, as
I recently was
surprised to discover, Tx is a trace source when a packet is queued, not
when its transmission begins.
The only other thing regarding wireless that I do is to periodically (every
100ms) monitor WifiNetDevice::GetBssid() of STAs, match it against AP MAC
addresses, and represent dashed lines for matching pairs. This gives you an
idea of which STAs are associated with which APs. So it's really nothing
On a related subject, personally I liked better the iNSpect style of showing
packet transmissions as arrows that appear and disappear, because unless the
simulation animation is much slower than real time the animated packets
would be pretty fast since the transmission delays are often very low. And
the arrow has added benefits, like being able to condense multiple packets
in a single arrow, whose thickness can be controlled to give a visual cue of
the bitrate, as well as adding a label to indicate the flowing bitrate.
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
More information about the Ns-developers