[Ns-developers] NS-3 GUI (visualization again)

[Jeremy]

This all sounds pretty good to me. I'll just step through your last email to
clarify.


In ns-3, there is no difference between the initial node position and
> the changes in the node position and/or velocity. They are all reported
> as a set of events which indicate that a new position/velocity is about
> to take effect at a specific time. So, initial node positions are
> usually reported as events for time 0.0.


That works perfectly. The only reason I wrote that in is because the
new-trace format for ns-2 used to only report changes in node position. That
works fine except for when a node does not move during a simulation (eg a
base station).

In ns-3, you have to register with each layer for its packet events so,
> the network layer is implicit when you get a packet event. The other
> items might be problematic depending on your definition:
>  a) involved parties
>  b) port
>  c) packet comment


a. Involved parties would be every node that heard the information. So for
unicast, it would normally be two nodes on a hop, where broadcast is
everyone in range. It could be easier if the packet was formatted such that
the involved parties was just a list of nodes with the first one being the
sender and the rest being the ones who heard it. However, it is not
necessary and maybe not even a good idea since traces would be harder to
parse if they were used in other ways by researchers as well. What do you
guys think would be easiest or most useful for implementing considering how
ns-3 works?

b. Port is not necessary, but would be nice to allow filtering when
visualizing.

c. Sorry, this was not meant to be in the list of things necessary. Ignore
this request.


> >     * Packet Events (time, involved parties, port, packet comment,
> > network layer)
>
> We have no energy models in ns-3, so, the following is not relevant.
>
> >     * Node energy information (Who is involved)
>
> We have two types of links:
>  - point to point links: duplex with one pair of nodes interconnected.
>  - non-point to point links: multiple nodes potentially talking to all
> other nodes.
> We can, of course, report both of these to you: how do you want that
> information to be formatted ?

So currently, nam defines

l -t time -s src -d dst -S state -c color -o orientation -r bw -D delay

from what I understand as far as the link format. To me, I think extending
this would be the best way to go about it. The two impressions I have are to
allow multiple -d flags or to make the individual -d flag a list of nodes
when reporting multiple links. Either way is easy to deal with for iNSpect's
purposes. What do you guys think is a better solution though for long term,
etc?


>
>
> >     * Wired Link existence
>
> We can easily tell you which nodes are potentially "interconnected"
> through a wireless network. This does not mean that packet transmissions
> between the two nodes will always (or ever) be successful though.
>
> >     * Wireless link existence (nice, but optional)
>

I think that maybe this we can worry about at a later date. The thought was
that the simulator would be better suited to tell if two nodes were in range
than a simple concentric circle in iNSpect. However, it is noisy data that
becomes very useless when more realistic propagation models are applied, so
lets just forget it for now.

I also forgot to add, that any other information you can think of would also
be nice. If it is information that would be good to visualize, lets start
that list up too. If we provide that information through tracing, we are
that much closer to providing it in the visualizer.

Thanks,
Jeremy Norman