Re: Visualization library

In response to your discussion and on behalf of the Toilers
Research
Group, I would like to fill everyone in on our efforts to
date at
developing an ns-3 visualization tool.

Many of you may have already heard of iNSpect, but for those
of you
who haven't, it is an ns-2 visualization tool that is used
by over
420 researchers in 51 countries (as of December 2007) for
visualizing
mobile ad-hoc and/or wireless networks (MANets). The current
version
of iNSpect is version 3.5. The original version of iNSpect
was
developed by Tracy Camp, Stuart Kurkowski, Mike Colagrosso,
Neil
(Tuli) Mushell,  Matthew Gimlin, Neal Erickson, and Jeff
Boleng from
the Toilers Research Group at the Colorado School of Mines.
In April
2005, Fatih Gey and Peter Eginger from the Department
Security
Technology at the Fraunhofer Institute for Computer Graphics
Research
over-hauled the iNSpect (version 3.3) visualization tool for
wireless
networks. This overhaul provided a cleaner and more logical
class
structure, allowing it to be much easier to extend this
visualization
tool. In November 2007, the Toilers decided to update
iNSpect to
handle both wired and wireless visualization and to work in
ns-3. Our
hope is that the new iNSpect visualizer (for wired and
wireless
simulations) will be included with future ns-3
distributions.
Our current team consists of Jeremy Norman, Chris Walsh,
Kurt
Strovink, and Tracy Camp from the Toilers Research Group at
the
Colorado School of Mines. We are extending the Fraunhofer
IGD
implementation of iNSpect by adding simulation support for
wired
networks (dubbed version 4). So far we have redesigned the
internal
model to handle wired and wireless simulations, and we have
added the
ability to turn nodes on and off during the simulation
(e.g., to
handle limited energy models). Our update to iNSpect is
still able to
handle the ns-2 new-trace format for wireless, but can now
also
handle ns-2 wired traces. Currently, we are adding parsers
for the
PCAP trace format and plan to start more in-depth ns-3
wired/wireless
parsing soon. Most of our current focus has been on
finishing the
visualization updates necessary for wired traces and
updating the
wireless visualization to a new format. We hope to have the
visualization portion done within the next couple weeks.

Just as a note for completeness, iNSpect version 4 currently
relies
on g++ 4.1.2 and 4.2.1, gtkglext 1.2.0 (distributed with
iNSpect),
and OpenGL 2.0. Previous versions were tested on cygwin,
redhat, and
Windows XP SP2 (Using Dev C++). We plan to keep the new
version of
iNSpect at least as portable as the previous versions.

Finally, I would like to extend a warm welcome to any
suggestions or
help that we can get from the ns-3 development community to
make this
update. If you would like to assist in this effort, please
contact me
at jnormanmines.edu (or respond to this message).

Sincerely,

Jeremy Norman, the iNSpect team, and the Toilers Research
Group.

On Tue, 2008-03-11 at 22:42 -0600, Jeremy wrote:

[snip]

> handle ns-2 wired traces. Currently, we are adding
parsers for the
> PCAP trace format and plan to start more in-depth ns-3
wired/wireless
> parsing soon. Most of our current focus has been on
finishing the
> visualization updates necessary for wired traces and
updating the
> wireless visualization to a new format. We hope to have
the
> visualization portion done within the next couple
weeks.
> 
> Just as a note for completeness, iNSpect version 4
currently relies
> on g++ 4.1.2 and 4.2.1, gtkglext 1.2.0 (distributed
with iNSpect),
> and OpenGL 2.0. Previous versions were tested on
cygwin, redhat, and
> Windows XP SP2 (Using Dev C++). We plan to keep the new
version of
> iNSpect at least as portable as the previous versions.
> 
> Finally, I would like to extend a warm welcome to any
suggestions or
> help that we can get from the ns-3 development
community to make this
> update. If you would like to assist in this effort,
please contact me
> at jnormanmines.edu (or respond to this message).

What would be potentially useful is to be able to have
access to a
public repository of the code, regardless of whether the
code works or
not. Being able to look at it early might help spot early
problems with
the ns-3 integration, and thus save you a lot of time later
down the
road.

If your goal is integration in ns-3, you will have to use
mercurial, so,
it might make sense to move your repository history (if you
have one) to
mercurial now to avoid the later pain.
(http://www.selenic.com/mercurial/wiki/index.
cgi/RepositoryConversion
explains how to do this but if you have questions about this
process, I
suspect I can probably help, feel free to drop by on
irc.freenode.net#ns-3)

I hope that this helps.

regards,
Mathieu

PS: it would also be probably useful to include a link to
your project's
homepage in your email: a quick google search for
"iNSpect" did not turn
up much.

Sorry it took me so long to respond, it's spring break  for
us and I was out
of office.

Just to clarify what we are hoping to have occur is to have
iNSpect
distributed with ns-3 as a standalone piece of software.
That being said,
for now we are planning on focusing on continuing
development of iNSpect as
a standalone package rather than switching our version
control system.
However, anyone who would like a copy of our working code,
I'd be happy to
send it to you directly or if you would like to be more
involved, we can
figure out a solution.

Finally, I meant to include this in my last email, but our
project homepage
is at http://toil
ers.mines.edu/Public/NsInspect . Again, if you would
like a
copy of inspect, please contact me directly rather than the
link that page
provides so that you can get the latest copy rather than the
original (but
stable) Toilers code for ns-2. We also have a small
development site up at
http://www.goog
le.com/group/nsinspect which includes a bit of
documentation
about how to easily extend the source to get you started
once you have a
working copy (the articles vary in timely accuracy).

Hope this is useful to everyone,
Jeremy Norman

On Wed, Mar 12, 2008 at 10:45 AM, Mathieu Lacage <
mathieu.lacagesophia.inria.fr> wrote:

>
> On Tue, 2008-03-11 at 22:42 -0600, Jeremy wrote:
>
> [snip]
>
> > handle ns-2 wired traces. Currently, we are adding
parsers for the
> > PCAP trace format and plan to start more in-depth
ns-3 wired/wireless
> > parsing soon. Most of our current focus has been
on finishing the
> > visualization updates necessary for wired traces
and updating the
> > wireless visualization to a new format. We hope to
have the
> > visualization portion done within the next couple
weeks.
> >
> > Just as a note for completeness, iNSpect version 4
currently relies
> > on g++ 4.1.2 and 4.2.1, gtkglext 1.2.0
(distributed with iNSpect),
> > and OpenGL 2.0. Previous versions were tested on
cygwin, redhat, and
> > Windows XP SP2 (Using Dev C++). We plan to keep
the new version of
> > iNSpect at least as portable as the previous
versions.
> >
> > Finally, I would like to extend a warm welcome to
any suggestions or
> > help that we can get from the ns-3 development
community to make this
> > update. If you would like to assist in this
effort, please contact me
> > at jnormanmines.edu (or respond to this message).
>
> What would be potentially useful is to be able to have
access to a
> public repository of the code, regardless of whether
the code works or
> not. Being able to look at it early might help spot
early problems with
> the ns-3 integration, and thus save you a lot of time
later down the
> road.
>
> If your goal is integration in ns-3, you will have to
use mercurial, so,
> it might make sense to move your repository history (if
you have one) to
> mercurial now to avoid the later pain.
> (http://www.selenic.com/mercurial/wiki/index.
cgi/RepositoryConversion
> explains how to do this but if you have questions about
this process, I
> suspect I can probably help, feel free to drop by on
> irc.freenode.net#ns-3)
>
> I hope that this helps.
>
> regards,
> Mathieu
>
> PS: it would also be probably useful to include a link
to your project's
> homepage in your email: a quick google search for
"iNSpect" did not turn
> up much.
>
>

On 17/03/2008, Jeremy <jnormanmines.edu> wrote:
>
> Sorry it took me so long to respond, it's spring break 
for us and I was
> out
> of office.
>
> Just to clarify what we are hoping to have occur is to
have iNSpect
> distributed with ns-3 as a standalone piece of
software. That being said,
> for now we are planning on focusing on continuing
development of iNSpect
> as
> a standalone package rather than switching our version
control system.
> However, anyone who would like a copy of our working
code, I'd be happy to
> send it to you directly or if you would like to be more
involved, we can
> figure out a solution.


>From the videos, iNSspect looks promising.

ns-3-viz is only less than 400 lines of code, right now.  It
will probably
grow some day, but still it is a rather
"lightweight" visualizer.  iNSpect
looks more "enterprise-y" code.  It is not clear
to me how does iNSpect
integrate with NS-3 code.  Trace files, or?...  If iNSpect
links directly
with the NS-3 library, keep in mind that that code needs to
be GPL.

About using OpenGL, harware accelerated OpenGL can be a good
thing, and can
make the iNSpect very performant.  On the other hand, one of
the drawbacks
of OpenGL is that when it is not hardware accelerated it can
also be
extremely slow.

ns-3-viz, on the other hand, uses goocanvas, which is based
on the portably
Cairo 2D graphics library.  Cairo can also be hardware
accelerated.  On
linux, besides a simple software renderer, it can use X
RENDER extension, or
OpenGL (glitz).  On Windows Cairo uses GDI+.  Goocanvas is
available in
recent linux distributions, and can be compiled for other
systems
(goocanvas' configure script checks for win32, so I assume
it can also be
compiled for win32).

One big advantage of Cairo over OpenGL is the ability of
directly exporting
graphics to a vector format, such as PDF, EPS, or SVG.  For
researchers
trying to produce high quality figures for papers this could
be a real time
saver...  On the downside it doesn't support 3D, but I don't
think in this
case 3D is important, and in any case 3D scenes can be
transformed into 2D
graphics (projection).

To conclude, I would say that iNSpect and ns-3-viz only
partially overlap.
Different feature sets, different levels of integration with
NS-3.  I still
think NS-3 would benefit from inclusion of ns-3-viz.

Thanks,

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." --
Frank Herbert

On Sun, 2008-03-16 at 22:40 -0600, Jeremy wrote:

> Just to clarify what we are hoping to have occur is to
have iNSpect
> distributed with ns-3 as a standalone piece of
software. That being

I personally think that it would be really nice if a piece
of code which
is being designed to be shipped with ns-3 could also be
implemented in a
more open manner than what everyone used to do in ns2: big
code drops of
fully-designed and almost finished products might be nice
for the
original developers but it is much harder to digest for the
ns-3
maintainers.

It seems to me that it would also make _a lot_ of sense to
host an open
discussion about the feature set, architecture, and scope of
such an
important piece of code for the project (if it is set to
become an
official gui). And, again, posting your code as read-only
early will
help others assess the scope of what you want to achieve
which might
make it easier to gather momentum around a useful single
tool.

>  said, for now we are planning on focusing on
continuing development
> of iNSpect as a standalone package rather than
switching our version
> control system. However, anyone who would like a copy
of our working
> code, I'd be happy to send it to you directly or if you
would like to
> be more involved, we can figure out a solution. 

I think that it would be really useful to everyone if you
used a public
repository, whatever tool you use: I am sure that a hosting
solution can
be found for you which allows you to control who gets write
access if
that is your worry but it sure would be pretty cool to
provide a public
read-only repo of your current devel work.

> Finally, I meant to include this in my last email, but
our project
> homepage is at http://toil
ers.mines.edu/Public/NsInspect . Again, if

thanks.

regards,
Mathieu

We do welcome any suggestions or comments you may have about
iNSpect. To
help with this, what I did was write a quick shell script to
post up to date
working copies of our code every night list by build number.
This listing is
at ht
tp://alamode.mines.edu/~jnorman/toilers/inspect/

If you have any questions, please let me know.
Jeremy Norman

On Mon, Mar 17, 2008 at 10:31 AM, Mathieu Lacage <
mathieu.lacagesophia.inria.fr> wrote:

>
> On Sun, 2008-03-16 at 22:40 -0600, Jeremy wrote:
>
> > Just to clarify what we are hoping to have occur
is to have iNSpect
> > distributed with ns-3 as a standalone piece of
software. That being
>
> I personally think that it would be really nice if a
piece of code which
> is being designed to be shipped with ns-3 could also be
implemented in a
> more open manner than what everyone used to do in ns2:
big code drops of
> fully-designed and almost finished products might be
nice for the
> original developers but it is much harder to digest for
the ns-3
> maintainers.
>
> It seems to me that it would also make _a lot_ of sense
to host an open
> discussion about the feature set, architecture, and
scope of such an
> important piece of code for the project (if it is set
to become an
> official gui). And, again, posting your code as
read-only early will
> help others assess the scope of what you want to
achieve which might
> make it easier to gather momentum around a useful
single tool.
>
> >  said, for now we are planning on focusing on
continuing development
> > of iNSpect as a standalone package rather than
switching our version
> > control system. However, anyone who would like a
copy of our working
> > code, I'd be happy to send it to you directly or
if you would like to
> > be more involved, we can figure out a solution.
>
> I think that it would be really useful to everyone if
you used a public
> repository, whatever tool you use: I am sure that a
hosting solution can
> be found for you which allows you to control who gets
write access if
> that is your worry but it sure would be pretty cool to
provide a public
> read-only repo of your current devel work.
>
> > Finally, I meant to include this in my last email,
but our project
> > homepage is at http://toil
ers.mines.edu/Public/NsInspect . Again, if
>
> thanks.
>
> regards,
> Mathieu
>
>


-- 
Curiosity didn't kill the cat, it taught it something it
didn't know before.

hi jeremy,

On Mon, 2008-03-17 at 14:50 -0600, Jeremy wrote:
> We do welcome any suggestions or comments you may have
about iNSpect.
> To help with this, what I did was write a quick shell
script to post
> up to date working copies of our code every night list
by build
> number. This listing is at
> ht
tp://alamode.mines.edu/~jnorman/toilers/inspect/ 

The attached patch was needed to make this code link. You
also probably
should consider removing the config.log and Makefile files
from your svn
repo. I will try to run the code sometime tomorrow 

regards,
Mathieu