[Ns-developers] NS3 Animation Interface and stand-alone animation tool

[Tom Henderson]

George Riley wrote:
>> we probably ought to have consistency in the topology objects that are 
>> geared towards point-to-point-- the "star" topology is part of 
>> PointToPointHelper but Dumbbell is outside of that helper class.
> I think the star topology is our only existing instance of a topology 
> helper, so am not convinced it is a real "precedent".  Regardless,
> the dumbbell should definitely not be part of PointToPointHelper, as you 
> almost always want
> different link characteristics for the bottleneck link and leaf links.. 
> Using a member function in the P2PHelper implies the current
> attributes of that helper are to be used, which is not the case.  I 
> think the right solution is to move the star topology from p2phelper
> and make it a stand-alone object like the dumbbell. THis seems much more 
> natural to me.

If we can achieve some level of device independence with the topology 
objects, I agree that it would make sense to split them out.

> 
>>
>>
>>> 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 animator.
>>> 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 can:
>>>    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.
>>
>> Probably this could exist in parallel with the other standalone 
>> packages  in ns-3-allinone directory, but outside of ns-3-dev, and be 
>> conditionally downloaded/compiled by the new scripts in ns-3-allinone.
> I would rather see it (the animatino-interface) in "src" somewhere.  It 
> does not depend on
> anything outside ns3, unless we implement use case (3) which would 
> require qt4 code (presumably with
> appropriate #ifdefs to compile without qt4 present.

Yes, I think the animation interface should be part of ns-3, while I was 
suggesting that the animator itself could be the separately downloaded 
part (sorry if I wasn't clear on that).

Tom