From jnorman at mines.edu  Fri Aug  1 08:39:19 2008
From: jnorman at mines.edu (Jeremy)
Date: Fri, 1 Aug 2008 09:39:19 -0600
Subject: [Ns-developers] NS-3 GUI (visualization again)
In-Reply-To: <a467ca4f0807311535q42dafb2aub4d5e5378366e1f5@mail.gmail.com>
References: <9f8df64e0807310807p4a0282d5hb6af0d80823e54aa@mail.gmail.com>
	<a467ca4f0807311122o11b4d478pbe5179757d5e4efc@mail.gmail.com>
	<a467ca4f0807311535q42dafb2aub4d5e5378366e1f5@mail.gmail.com>
Message-ID: <9f8df64e0808010839r5f1f3f57wce36e499dc94f227@mail.gmail.com>

Gustavo,

Again, great feedback.

5- The 'placement' files for wired nodes are also a PITA. ...
>

>From just a quick scan of graphviz I was not able to figure out if there was
a separate library. However, it does have command line tools that might be
able to be used in the absence of a library. If nothing else, a shell script
could be written and distributed with iNSpect so that graphviz can layout
the nodes and then have iNSpect run from that automatically. Obviously,
there are other options that could quite likely be better as well -- even
maybe creating an interpreter that reads straight from graphviz and a
command line option that attempts to fork graphviz and pipe information back
into iNSpect?

In any event, any of the options are probably going to need to wait a few
weeks until fall semester starts for the Toilers to do it alone. However, I
am going to put a ticket into bugzilla so that we at least look into it.

-Jeremy

On Thu, Jul 31, 2008 at 4:35 PM, Gustavo Carneiro <gjcarneiro at gmail.com>wrote:

>
>
> 2008/7/31 Gustavo Carneiro <gjcarneiro at gmail.com>
>
>
>>
>> 2008/7/31 Jeremy <jnorman at mines.edu>
>>
>>> Hey all,
>>>
>>> I am working with the Toilers on updating to NS-3 and have a few thoughts
>>> on
>>> the subject of visualization.
>>>
>>> First of all, I agree with using postmortum visualization argument for
>>> many
>>> of the reasons that have already been stated. The most important being
>>> fewer
>>> libraries. This is a big deal for those of us in research who are looking
>>> more and more at cloud computing or cluster computing in any way. Adding
>>> graphics library requirements just makes installation harder and more
>>> confusing.
>>
>>
>> I agree post-mortem is interesting.  I just don't agree post-mortem is
>> _all_ that is interesting. :-)
>>
>>
>>>
>>>
>>> Next, the latest version of iNSpect does compile and did when this
>>> conversation began (in fact the latest version is over a month old). It
>>> is
>>> version 4r2125 and at the bottom of the file list at
>>> http://alamode.mines.edu/~jnorman/toilers/inspect<http://alamode.mines.edu/%7Ejnorman/toilers/inspect>If you would like some
>>> help getting iNSpect to compile, we have documentation that is specific
>>> to
>>> many platforms at http://www.google.com/group/nsinspect. Additionally,
>>> I'd
>>> be glad to help anyone get going.
>>
>>
>> Thanks to your help, it now compiles for me as well.  Thank you.
>>
>>
>>>
>>>
>>> So let me fill everyone in on some of the advances of iNSpect since our
>>> last
>>> conversation. Many of them were specific to the questions at hand.
>>>
>>> Also, iNSpect has finally been made multi-threaded. The most interesting
>>> part of this is that the file readers are multi-threaded as well which
>>> allows the program to read separately from visualizing. The reason that
>>> we
>>> went through all the trouble of doing this was to make iNSpect able to
>>> read
>>> simulation information directly from a pipe and visualize real-time with
>>> the
>>> simulator. The only part left of the real time visualization is to
>>> connect
>>> the standard in to a file stream and get a trace file format that NS-3
>>> and
>>> iNSpect both understand.
>>> Using pipes addresses the issues of disk space and library dependencies
>>> by
>>> separating the two.
>>>
>>> As far as being customizable, we did not create a python/tcl/etc api for
>>> iNSpect, however, we have been working very hard to break iNSpect into
>>> clear
>>> MVC chunks which allow for representation of any information you need.
>>> There
>>> is now a data input API for reading from file streams, pipes, or SQL if
>>> necessary. Also, a model API which allows dynamic non simulation related
>>> information to be added. Finally we have a separate visualization API
>>> which
>>> allows new ways to visualize old data and easy ways to plug in new data.
>>> An example of how to add energy (on/off) information to the simulation is
>>> already up on the google group.
>>>
>>
>>>
>>> So for now, many of the features people want the most are nearly ready
>>> for
>>> use. Right now we are just in a lull because it is summer break on campus
>>> and are short on people. We welcome any help and especially insight into
>>> feature requests/etc to make sure that our tool is actually useful to
>>> people
>>> rather than just us.
>>>
>>> We expect to be wrapping up a lot of loose ends in the features I've
>>> mentioned and fully documenting them in the next month or so. There are
>>> only
>>> two serious steps left before it is a tool I would deem usable for NS-3:
>>> write a module to trace information we need out of the NS-3 API and get
>>> some
>>> more intense user-testing of the code.
>>
>>
>> I have been now trying to fire up iNSpect and my impressions are:
>>
>>   1- Lack of ns-3 integration, as you mention in that last paragraph.  I
>> was unable to get any ns-3 example to display in iNSpect.  So you're working
>> on it.  I get it.  However, I may not have time to wait for it, but that's
>> another matter;
>>
>>   2- Both command line and graphical interfaces are cluttered:
>>
>>       a) In the command line I need to run: ./iNSpect
>> sample/simple_wireless.conf   -l2 sample/simple.tr
>>           I have a problem with the configuration file: I hate
>> configuration files.  Why can't iNSpect just pick some default values and
>> make the customization optional?
>>
>>       b) The GUI has 3 windows, one with the animation, one with controls,
>> yet another with statistics.  Ideally it should be just one window with
>> everything.  Also the buttons are huge.
>>
>>   3- The matter of OpenGL I already discussed a few months back.  Besides
>> my lack of OpenGL coding skills (that's my own problem, I suppose), OpenGL
>> does not allow saving figures into vector graphics formats such as EPS, SVG,
>> or PDF.  A Cairo based renderer easily supports those formats.  On the other
>> hand, Cairo is usually slower than OpenGL for animations, I get that too :|
>>
>>   4- Being 100% C++ is a problem if I wanted to hack on it, as I am tired
>> of so much C++ lately :P  OK, maybe this is another personal quirk, and not
>> applicable to the project as a whole, I don't know.  Need do spend more time
>> coding Python and less C++ ;-)
>>
>
> I forgot one item:
>
>    5- The 'placement' files for wired nodes are also a PITA.  But I
> completely understand why you want it.  Wired simulations in NS-3 have no
> mobility models, and so nodes have no position.  Figuring out an optimum
> layout automatically for nodes with links to other nodes is a complicated
> problem, and one which a tool called graphviz is good at solving.  It also
> has a library, though I am not sure if the layout engine is exported by it,
> I'll check tomorrow.  So ideally a visualizer should be able to layout
> automatically even wired nodes, and get rid of the awful .placement file
> requirement.
>
> --
> Gustavo J. A. M. Carneiro
> INESC Porto, Telecommunications and Multimedia Unit
> "The universe is always one step beyond logic." -- Frank Herbert
>



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

From gjcarneiro at gmail.com  Fri Aug  1 10:54:18 2008
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Fri, 1 Aug 2008 18:54:18 +0100
Subject: [Ns-developers] NS-3 GUI (visualization again)
In-Reply-To: <9f8df64e0808010839r5f1f3f57wce36e499dc94f227@mail.gmail.com>
References: <9f8df64e0807310807p4a0282d5hb6af0d80823e54aa@mail.gmail.com>
	<a467ca4f0807311122o11b4d478pbe5179757d5e4efc@mail.gmail.com>
	<a467ca4f0807311535q42dafb2aub4d5e5378366e1f5@mail.gmail.com>
	<9f8df64e0808010839r5f1f3f57wce36e499dc94f227@mail.gmail.com>
Message-ID: <a467ca4f0808011054r55812792l3f378506e9555084@mail.gmail.com>

2008/8/1 Jeremy <jnorman at mines.edu>

> Gustavo,
>
> Again, great feedback.
>
> 5- The 'placement' files for wired nodes are also a PITA. ...
> >
>
> >From just a quick scan of graphviz I was not able to figure out if there
> was
> a separate library. However, it does have command line tools that might be
> able to be used in the absence of a library. If nothing else, a shell
> script
> could be written and distributed with iNSpect so that graphviz can layout
> the nodes and then have iNSpect run from that automatically. Obviously,
> there are other options that could quite likely be better as well -- even
> maybe creating an interpreter that reads straight from graphviz and a
> command line option that attempts to fork graphviz and pipe information
> back
> into iNSpect?
>

In my Ubuntu system, I have both a graphviz library and graphviz python
bindings.


>
>
> In any event, any of the options are probably going to need to wait a few
> weeks until fall semester starts for the Toilers to do it alone. However, I
> am going to put a ticket into bugzilla so that we at least look into it.
>

I'll probably post something quick made in python soon, then let you use it
(or not) however you see fit.


>
>
> -Jeremy
>
> On Thu, Jul 31, 2008 at 4:35 PM, Gustavo Carneiro <gjcarneiro at gmail.com
> >wrote:
>
> >
> >
> > 2008/7/31 Gustavo Carneiro <gjcarneiro at gmail.com>
> >
> >
> >>
> >> 2008/7/31 Jeremy <jnorman at mines.edu>
> >>
> >>> Hey all,
> >>>
> >>> I am working with the Toilers on updating to NS-3 and have a few
> thoughts
> >>> on
> >>> the subject of visualization.
> >>>
> >>> First of all, I agree with using postmortum visualization argument for
> >>> many
> >>> of the reasons that have already been stated. The most important being
> >>> fewer
> >>> libraries. This is a big deal for those of us in research who are
> looking
> >>> more and more at cloud computing or cluster computing in any way.
> Adding
> >>> graphics library requirements just makes installation harder and more
> >>> confusing.
> >>
> >>
> >> I agree post-mortem is interesting.  I just don't agree post-mortem is
> >> _all_ that is interesting. :-)
> >>
> >>
> >>>
> >>>
> >>> Next, the latest version of iNSpect does compile and did when this
> >>> conversation began (in fact the latest version is over a month old). It
> >>> is
> >>> version 4r2125 and at the bottom of the file list at
> >>> http://alamode.mines.edu/~jnorman/toilers/inspect<http://alamode.mines.edu/%7Ejnorman/toilers/inspect>
> <http://alamode.mines.edu/%7Ejnorman/toilers/inspect>If you would like
> some
> >>> help getting iNSpect to compile, we have documentation that is specific
> >>> to
> >>> many platforms at http://www.google.com/group/nsinspect. Additionally,
> >>> I'd
> >>> be glad to help anyone get going.
> >>
> >>
> >> Thanks to your help, it now compiles for me as well.  Thank you.
> >>
> >>
> >>>
> >>>
> >>> So let me fill everyone in on some of the advances of iNSpect since our
> >>> last
> >>> conversation. Many of them were specific to the questions at hand.
> >>>
> >>> Also, iNSpect has finally been made multi-threaded. The most
> interesting
> >>> part of this is that the file readers are multi-threaded as well which
> >>> allows the program to read separately from visualizing. The reason that
> >>> we
> >>> went through all the trouble of doing this was to make iNSpect able to
> >>> read
> >>> simulation information directly from a pipe and visualize real-time
> with
> >>> the
> >>> simulator. The only part left of the real time visualization is to
> >>> connect
> >>> the standard in to a file stream and get a trace file format that NS-3
> >>> and
> >>> iNSpect both understand.
> >>> Using pipes addresses the issues of disk space and library dependencies
> >>> by
> >>> separating the two.
> >>>
> >>> As far as being customizable, we did not create a python/tcl/etc api
> for
> >>> iNSpect, however, we have been working very hard to break iNSpect into
> >>> clear
> >>> MVC chunks which allow for representation of any information you need.
> >>> There
> >>> is now a data input API for reading from file streams, pipes, or SQL if
> >>> necessary. Also, a model API which allows dynamic non simulation
> related
> >>> information to be added. Finally we have a separate visualization API
> >>> which
> >>> allows new ways to visualize old data and easy ways to plug in new
> data.
> >>> An example of how to add energy (on/off) information to the simulation
> is
> >>> already up on the google group.
> >>>
> >>
> >>>
> >>> So for now, many of the features people want the most are nearly ready
> >>> for
> >>> use. Right now we are just in a lull because it is summer break on
> campus
> >>> and are short on people. We welcome any help and especially insight
> into
> >>> feature requests/etc to make sure that our tool is actually useful to
> >>> people
> >>> rather than just us.
> >>>
> >>> We expect to be wrapping up a lot of loose ends in the features I've
> >>> mentioned and fully documenting them in the next month or so. There are
> >>> only
> >>> two serious steps left before it is a tool I would deem usable for
> NS-3:
> >>> write a module to trace information we need out of the NS-3 API and get
> >>> some
> >>> more intense user-testing of the code.
> >>
> >>
> >> I have been now trying to fire up iNSpect and my impressions are:
> >>
> >>   1- Lack of ns-3 integration, as you mention in that last paragraph.  I
> >> was unable to get any ns-3 example to display in iNSpect.  So you're
> working
> >> on it.  I get it.  However, I may not have time to wait for it, but
> that's
> >> another matter;
> >>
> >>   2- Both command line and graphical interfaces are cluttered:
> >>
> >>       a) In the command line I need to run: ./iNSpect
> >> sample/simple_wireless.conf   -l2 sample/simple.tr
> >>           I have a problem with the configuration file: I hate
> >> configuration files.  Why can't iNSpect just pick some default values
> and
> >> make the customization optional?
> >>
> >>       b) The GUI has 3 windows, one with the animation, one with
> controls,
> >> yet another with statistics.  Ideally it should be just one window with
> >> everything.  Also the buttons are huge.
> >>
> >>   3- The matter of OpenGL I already discussed a few months back.
>  Besides
> >> my lack of OpenGL coding skills (that's my own problem, I suppose),
> OpenGL
> >> does not allow saving figures into vector graphics formats such as EPS,
> SVG,
> >> or PDF.  A Cairo based renderer easily supports those formats.  On the
> other
> >> hand, Cairo is usually slower than OpenGL for animations, I get that too
> :|
> >>
> >>   4- Being 100% C++ is a problem if I wanted to hack on it, as I am
> tired
> >> of so much C++ lately :P  OK, maybe this is another personal quirk, and
> not
> >> applicable to the project as a whole, I don't know.  Need do spend more
> time
> >> coding Python and less C++ ;-)
> >>
> >
> > I forgot one item:
> >
> >    5- The 'placement' files for wired nodes are also a PITA.  But I
> > completely understand why you want it.  Wired simulations in NS-3 have no
> > mobility models, and so nodes have no position.  Figuring out an optimum
> > layout automatically for nodes with links to other nodes is a complicated
> > problem, and one which a tool called graphviz is good at solving.  It
> also
> > has a library, though I am not sure if the layout engine is exported by
> it,
> > I'll check tomorrow.  So ideally a visualizer should be able to layout
> > automatically even wired nodes, and get rid of the awful .placement file
> > requirement.
> >
> > --
> > Gustavo J. A. M. Carneiro
> > INESC Porto, Telecommunications and Multimedia Unit
> > "The universe is always one step beyond logic." -- Frank Herbert
> >
>
>
>
> --
> Curiosity didn't kill the cat, it taught it something it didn't know
> before.
>



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

From gjcarneiro at gmail.com  Fri Aug  1 15:22:22 2008
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Fri, 1 Aug 2008 23:22:22 +0100
Subject: [Ns-developers] NS-3 GUI (visualization again)
In-Reply-To: <a467ca4f0808011054r55812792l3f378506e9555084@mail.gmail.com>
References: <9f8df64e0807310807p4a0282d5hb6af0d80823e54aa@mail.gmail.com>
	<a467ca4f0807311122o11b4d478pbe5179757d5e4efc@mail.gmail.com>
	<a467ca4f0807311535q42dafb2aub4d5e5378366e1f5@mail.gmail.com>
	<9f8df64e0808010839r5f1f3f57wce36e499dc94f227@mail.gmail.com>
	<a467ca4f0808011054r55812792l3f378506e9555084@mail.gmail.com>
Message-ID: <a467ca4f0808011522j62c7138cq8094b2c2bb7ddd01@mail.gmail.com>

2008/8/1 Gustavo Carneiro <gjcarneiro at gmail.com>

>
>
> 2008/8/1 Jeremy <jnorman at mines.edu>
>
>> Gustavo,
>>
>> Again, great feedback.
>>
>> 5- The 'placement' files for wired nodes are also a PITA. ...
>> >
>>
>> >From just a quick scan of graphviz I was not able to figure out if there
>> was
>> a separate library. However, it does have command line tools that might be
>> able to be used in the absence of a library. If nothing else, a shell
>> script
>> could be written and distributed with iNSpect so that graphviz can layout
>> the nodes and then have iNSpect run from that automatically. Obviously,
>> there are other options that could quite likely be better as well -- even
>> maybe creating an interpreter that reads straight from graphviz and a
>> command line option that attempts to fork graphviz and pipe information
>> back
>> into iNSpect?
>>
>
> In my Ubuntu system, I have both a graphviz library and graphviz python
> bindings.
>
>
>>
>>
>> In any event, any of the options are probably going to need to wait a few
>> weeks until fall semester starts for the Toilers to do it alone. However,
>> I
>> am going to put a ticket into bugzilla so that we at least look into it.
>>
>
> I'll probably post something quick made in python soon, then let you use it
> (or not) however you see fit.
>

Work in progress / proof of concept, but the following file patches
examples/csma-bridge.py to make it scan the (wired) topology by ns-3
introspection, creates a graphviz graph (requires python graphviz bindings),
does a "twopi" layout, prints the resulting node coordinates, and finally
generates a postscript file (as demonstration).

This just to demonstrate it is possible ;-)

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ns-3-graphviz.diff
Type: text/x-diff
Size: 1815 bytes
Desc: not available
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20080801/09cb9ecc/ns-3-graphviz-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: topology.ps
Type: application/postscript
Size: 5622 bytes
Desc: not available
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20080801/09cb9ecc/topology-0001.ps

From tomh at tomh.org  Mon Aug  4 14:45:08 2008
From: tomh at tomh.org (Tom Henderson)
Date: Mon, 04 Aug 2008 14:45:08 -0700
Subject: [Ns-developers] handling API changes
In-Reply-To: <48907962.6090402@tomh.org>
References: <48907962.6090402@tomh.org>
Message-ID: <48977864.5050908@tomh.org>

Tom Henderson wrote:
> We've had a lot of traffic recently on dealing with backward
> compatibility and API changes.  I'd like to suggest the following
> proposal, which is basically along the lines of solving this issue with
> documentation (sorry, Gustavo), because of the extra work of maintaining
> a backward compatibility layer.
> 
> I propose to put a file in the top level directory called "changes.txt".
>  This could also be kept as html to add more structure and make it more
> browsable (e.g. ns-2 CHANGES.html):
> http://www.isi.edu/nsnam/ns/CHANGES.html

Since HTML seemed to be easier to read and organize, I checked in a 
CHANGES.html file to the top-level directory.  I'd like to ask all 
developers who check in changes to the ns-3 API to add an entry to this 
file.  There are no strict policies for what needs to go in there; see 
the existing listings for the types of things that would be appropriate 
to list.

- Tom

From mathieu.lacage at sophia.inria.fr  Tue Aug  5 16:53:15 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 05 Aug 2008 16:53:15 -0700
Subject: [Ns-developers] user-space code integration update
Message-ID: <1217980395.26212.40.camel@ns-test>

hi,

Recently, I resumed work on the ns-3-simu branch with a focus towards
helping liu merge his code back into ns-3 and starting to port quagga.
The biggest change in http://code.nsnam.org/mathieu/ns-3-simu is that I
added support for loading in memory unmodified executables with an elf
loader and running them over ns-3. This is implemented in the
src/process/elf-loader.h|cc files through a bunch of tricks to force the
libc elf loader to load the same binary multiple times in memory.

I also added a lot of code to the libc replacement and have gotten
sufficiently far to run the example programs in examples/process.cc and
examples/process-udp-server.cc and examples/process-udp-client.cc. 

The summary is that you can write code such as:
http://code.nsnam.org/mathieu/ns-3-simu/file/fa3ab215a4b1/examples/process-udp-client.cc
http://code.nsnam.org/mathieu/ns-3-simu/file/fa3ab215a4b1/examples/process-udp-server.cc

which compiles as normal executables:
mathieu at ns-test:~/code/ns-3-simu
$ ./build/debug/examples/process-udp-server &
[1] 18125
mathieu at ns-test:~/code/ns-3-simu
$ ./build/debug/examples/process-udp-client localhost
send 1001 bytes
got bytes n=1001
[1]+  Done                    ./build/debug/examples/process-udp-server
mathieu at ns-test:~/code/ns-3-simu$

but which can also be executed within ns-3 itself through the simulation
script:
http://code.nsnam.org/mathieu/ns-3-simu/file/fa3ab215a4b1/examples/process.cc

The output, is quite similar:

mathieu at ns-test:~/code/ns-3-simu$ ./build/debug/examples/process 
send 1001 bytes
got bytes n=1001
mathieu at ns-test:~/code/ns-3-simu$ 

What are the next steps ?
-------------------------

1) need to figure out some c++ initialization problems which make it
impossible to load a c++ program in ns-3 for simulation.

2) need to test the code on more platforms. Right now, the code runs on
my x86-64 ubuntu 7.10 system. I tested it on a fedora 9 32bit x86 system
and on an ubuntu 8.04 x86 32 bit system. I have got reports that it does
not work on debian sid and on fedora 8. Need to setup test systems for
that.

3) figure out a practical plan to go forward with liu's code and quagga.

What will not work and what might work:
---------------------------------------

This code will not work on win32 or osx and I have no plans to add the
code needed to make it work there (patches welcome, though). It could be
made to work on solaris and, more generally, any reasonable elf unix
system (I suspect it won't work on aix) but, clearly, my main target is
linux elf x86 and x86-64.

Mathieu


From raj.b at gatech.edu  Wed Aug  6 12:13:59 2008
From: raj.b at gatech.edu (Raj Bhattacharjea)
Date: Wed, 6 Aug 2008 15:13:59 -0400
Subject: [Ns-developers] user-space code integration update
In-Reply-To: <1217980395.26212.40.camel@ns-test>
References: <1217980395.26212.40.camel@ns-test>
Message-ID: <12d69e490808061213s1442d2e5p24f8614bd6af853a@mail.gmail.com>

On Tue, Aug 5, 2008 at 7:53 PM, Mathieu Lacage
<mathieu.lacage at sophia.inria.fr> wrote:
> hi,
>
> Recently, I resumed work on the ns-3-simu branch with a focus towards
> helping liu merge his code back into ns-3 and starting to port quagga.
> The biggest change in http://code.nsnam.org/mathieu/ns-3-simu is that I
> added support for loading in memory unmodified executables with an elf
> loader and running them over ns-3. This is implemented in the
> src/process/elf-loader.h|cc files through a bunch of tricks to force the
> libc elf loader to load the same binary multiple times in memory.
>
> I also added a lot of code to the libc replacement and have gotten
> sufficiently far to run the example programs in examples/process.cc and
> examples/process-udp-server.cc and examples/process-udp-client.cc.
>
> The summary is that you can write code such as:
> http://code.nsnam.org/mathieu/ns-3-simu/file/fa3ab215a4b1/examples/process-udp-client.cc
> http://code.nsnam.org/mathieu/ns-3-simu/file/fa3ab215a4b1/examples/process-udp-server.cc

When this branch is eventually merged into ns-3-dev, if we ship this
type of "example", we need to identify a different place to put this
kind of code, since it uses native system/socket APIs, and is in fact
not an ns-3 example at all, but a sockets programming example.
Perhaps an examples sub-directory with an appropriate name could be
chosen in the future.

>
> which compiles as normal executables:
> mathieu at ns-test:~/code/ns-3-simu
> $ ./build/debug/examples/process-udp-server &
> [1] 18125
> mathieu at ns-test:~/code/ns-3-simu
> $ ./build/debug/examples/process-udp-client localhost
> send 1001 bytes
> got bytes n=1001
> [1]+  Done                    ./build/debug/examples/process-udp-server
> mathieu at ns-test:~/code/ns-3-simu$
>
> but which can also be executed within ns-3 itself through the simulation
> script:
> http://code.nsnam.org/mathieu/ns-3-simu/file/fa3ab215a4b1/examples/process.cc
>
> The output, is quite similar:
>
> mathieu at ns-test:~/code/ns-3-simu$ ./build/debug/examples/process
> send 1001 bytes
> got bytes n=1001
> mathieu at ns-test:~/code/ns-3-simu$
>
> What are the next steps ?
> -------------------------
>
> 1) need to figure out some c++ initialization problems which make it
> impossible to load a c++ program in ns-3 for simulation.
>
> 2) need to test the code on more platforms. Right now, the code runs on
> my x86-64 ubuntu 7.10 system. I tested it on a fedora 9 32bit x86 system
> and on an ubuntu 8.04 x86 32 bit system. I have got reports that it does
> not work on debian sid and on fedora 8. Need to setup test systems for
> that.
>
> 3) figure out a practical plan to go forward with liu's code and quagga.
>
> What will not work and what might work:
> ---------------------------------------
>
> This code will not work on win32 or osx and I have no plans to add the
> code needed to make it work there (patches welcome, though). It could be
> made to work on solaris and, more generally, any reasonable elf unix
> system (I suspect it won't work on aix) but, clearly, my main target is
> linux elf x86 and x86-64.

AFAIK we've never stated what ns-3's supported platforms should be,
only what it works on now.  Since our stated "supported" platforms in
the README include cygwin and Mac OS X at present, it'd be great to
have the binary-loader code work for these eventually.  Do you foresee
any insurmountable hurdles to making this kind of binary-loader and
real code integration for these other systems?

-- 
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
Systems Analyst
404.894.2955

From mathieu.lacage at sophia.inria.fr  Wed Aug  6 12:46:28 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Wed, 06 Aug 2008 12:46:28 -0700
Subject: [Ns-developers] user-space code integration update
In-Reply-To: <12d69e490808061213s1442d2e5p24f8614bd6af853a@mail.gmail.com>
References: <1217980395.26212.40.camel@ns-test>
	<12d69e490808061213s1442d2e5p24f8614bd6af853a@mail.gmail.com>
Message-ID: <1218051988.22587.74.camel@ns-test>


On Wed, 2008-08-06 at 15:13 -0400, Raj Bhattacharjea wrote:

> When this branch is eventually merged into ns-3-dev, if we ship this
> type of "example", we need to identify a different place to put this
> kind of code, since it uses native system/socket APIs, and is in fact
> not an ns-3 example at all, but a sockets programming example.
> Perhaps an examples sub-directory with an appropriate name could be
> chosen in the future.

sure.

> > This code will not work on win32 or osx and I have no plans to add
> the
> > code needed to make it work there (patches welcome, though). It
> could be
> > made to work on solaris and, more generally, any reasonable elf unix
> > system (I suspect it won't work on aix) but, clearly, my main target
> is
> > linux elf x86 and x86-64.
> 
> AFAIK we've never stated what ns-3's supported platforms should be,
> only what it works on now.  Since our stated "supported" platforms in
> the README include cygwin and Mac OS X at present, it'd be great to
> have the binary-loader code work for these eventually.  Do you foresee
> any insurmountable hurdles to making this kind of binary-loader and
> real code integration for these other systems?

I have no idea how mach-o or pecoff will deal with this kind of trick
and I don't plan to spend time on them. Patches are welcome though.

regards,
Mathieu


From gjcarneiro at gmail.com  Thu Aug  7 05:25:40 2008
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Thu, 7 Aug 2008 13:25:40 +0100
Subject: [Ns-developers] user-space code integration update
In-Reply-To: <1217980395.26212.40.camel@ns-test>
References: <1217980395.26212.40.camel@ns-test>
Message-ID: <a467ca4f0808070525m2a034ed6i5c5b785a8490a02a@mail.gmail.com>

2008/8/6 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> hi,
>
> Recently, I resumed work on the ns-3-simu branch with a focus towards
> helping liu merge his code back into ns-3 and starting to port quagga.
> The biggest change in http://code.nsnam.org/mathieu/ns-3-simu is that I
> added support for loading in memory unmodified executables with an elf
> loader and running them over ns-3. This is implemented in the
> src/process/elf-loader.h|cc files through a bunch of tricks to force the
> libc elf loader to load the same binary multiple times in memory.
>
> I also added a lot of code to the libc replacement and have gotten
> sufficiently far to run the example programs in examples/process.cc and
> examples/process-udp-server.cc and examples/process-udp-client.cc.


For replacing many libc functions (e.g. it works for socket functions), you
can also use LD_PRELOAD to replace weak symbols.  I was wondering, what led
you down this more complicated path instead?

Thanks,

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

From mathieu.lacage at sophia.inria.fr  Thu Aug  7 08:58:09 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Thu, 07 Aug 2008 08:58:09 -0700
Subject: [Ns-developers] user-space code integration update
In-Reply-To: <a467ca4f0808070525m2a034ed6i5c5b785a8490a02a@mail.gmail.com>
References: <1217980395.26212.40.camel@ns-test>
	<a467ca4f0808070525m2a034ed6i5c5b785a8490a02a@mail.gmail.com>
Message-ID: <1218124689.2855.0.camel@ns-test>


On Thu, 2008-08-07 at 13:25 +0100, Gustavo Carneiro wrote:
> 
> 
> 2008/8/6 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
>         hi,
>         
>         Recently, I resumed work on the ns-3-simu branch with a focus
>         towards
>         helping liu merge his code back into ns-3 and starting to port
>         quagga.
>         The biggest change in http://code.nsnam.org/mathieu/ns-3-simu
>         is that I
>         added support for loading in memory unmodified executables
>         with an elf
>         loader and running them over ns-3. This is implemented in the
>         src/process/elf-loader.h|cc files through a bunch of tricks to
>         force the
>         libc elf loader to load the same binary multiple times in
>         memory.
>         
>         I also added a lot of code to the libc replacement and have
>         gotten
>         sufficiently far to run the example programs in
>         examples/process.cc and
>         examples/process-udp-server.cc and
>         examples/process-udp-client.cc.
> 
> For replacing many libc functions (e.g. it works for socket
> functions), you can also use LD_PRELOAD to replace weak symbols.  I
> was wondering, what led you down this more complicated path instead?

because not all symbols are weak and because we don't want to replace
the libc used by ns-3: we want to replace the libc used only by the
simulated programs.

Mathieu


From gjcarneiro at gmail.com  Thu Aug  7 09:17:24 2008
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Thu, 7 Aug 2008 17:17:24 +0100
Subject: [Ns-developers] user-space code integration update
In-Reply-To: <1218124689.2855.0.camel@ns-test>
References: <1217980395.26212.40.camel@ns-test>
	<a467ca4f0808070525m2a034ed6i5c5b785a8490a02a@mail.gmail.com>
	<1218124689.2855.0.camel@ns-test>
Message-ID: <a467ca4f0808070917w41780dd0id933a81251d58ea@mail.gmail.com>

2008/8/7 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

>
> On Thu, 2008-08-07 at 13:25 +0100, Gustavo Carneiro wrote:
> >
> >
> > 2008/8/6 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
> >         hi,
> >
> >         Recently, I resumed work on the ns-3-simu branch with a focus
> >         towards
> >         helping liu merge his code back into ns-3 and starting to port
> >         quagga.
> >         The biggest change in http://code.nsnam.org/mathieu/ns-3-simu
> >         is that I
> >         added support for loading in memory unmodified executables
> >         with an elf
> >         loader and running them over ns-3. This is implemented in the
> >         src/process/elf-loader.h|cc files through a bunch of tricks to
> >         force the
> >         libc elf loader to load the same binary multiple times in
> >         memory.
> >
> >         I also added a lot of code to the libc replacement and have
> >         gotten
> >         sufficiently far to run the example programs in
> >         examples/process.cc and
> >         examples/process-udp-server.cc and
> >         examples/process-udp-client.cc.
> >
> > For replacing many libc functions (e.g. it works for socket
> > functions), you can also use LD_PRELOAD to replace weak symbols.  I
> > was wondering, what led you down this more complicated path instead?
>
> because not all symbols are weak and because we don't want to replace
> the libc used by ns-3: we want to replace the libc used only by the
> simulated programs.


Sure, but does ns-3 use any libc function that you want to override?  Also
it is possible to access the original libc function (via dlsym with
RTLD_NEXT).

But don't worry, what matters is that it's done, I'm certainly not
complaining :-)

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

From mathieu.lacage at sophia.inria.fr  Thu Aug  7 09:35:25 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Thu, 07 Aug 2008 09:35:25 -0700
Subject: [Ns-developers] user-space code integration update
In-Reply-To: <a467ca4f0808070917w41780dd0id933a81251d58ea@mail.gmail.com>
References: <1217980395.26212.40.camel@ns-test>
	<a467ca4f0808070525m2a034ed6i5c5b785a8490a02a@mail.gmail.com>
	<1218124689.2855.0.camel@ns-test>
	<a467ca4f0808070917w41780dd0id933a81251d58ea@mail.gmail.com>
Message-ID: <1218126925.2855.14.camel@ns-test>


On Thu, 2008-08-07 at 17:17 +0100, Gustavo Carneiro wrote:


>         > For replacing many libc functions (e.g. it works for socket
>         > functions), you can also use LD_PRELOAD to replace weak
>         symbols.  I
>         > was wondering, what led you down this more complicated path
>         instead?
>         
>         
>         because not all symbols are weak and because we don't want to
>         replace
>         the libc used by ns-3: we want to replace the libc used only
>         by the
>         simulated programs.
> 
> Sure, but does ns-3 use any libc function that you want to override? 

yes.

>  Also it is possible to access the original libc function (via dlsym
> with RTLD_NEXT).

Yes but I cannot control the callers of the libc functions located in
libstdc++ so, these cannot be changed to use dlsym so, I would need to
detect who is the caller from the callee and call either the original
libc or the ns-3 libc. That makes my head hurt.

The killer, though, with LD_PRELOAD, is that replacing the libc
functions is only part of the problem: you need to be able to virtualize
the data area of all binaries to get a new set of global variables for
each binary. And that requires being able to load the same binary
multiple times in memory which is normally carefully forbidden by the
libc dlopen.

> But don't worry, what matters is that it's done, I'm certainly not
> complaining :-)

There are many other reasons for doing it that way. I believe that I
tried them all and they all failed at some point or another.

Mathieu


From pierresolen.guichard at ens-lyon.fr  Thu Aug  7 00:53:01 2008
From: pierresolen.guichard at ens-lyon.fr (Pierre-Solen Guichard)
Date: Thu, 07 Aug 2008 09:53:01 +0200
Subject: [Ns-developers] Exchanging data between two connectors - not
	through a script
Message-ID: <489AA9DD.4040801@ens-lyon.fr>

Hello everyone,

I am posting to the ns-developers after having posted to ns-users and 
asked a few skilled people around - without much success. I am doing my 
master degree internship (and thesis) and need to implement a particular 
router mechanism.

I'm stuck in programming a connector, namely a Measurement Based 
Admission Control (MBAC) that takes its decision according to data 
obtained from another connector, namely an outgoing queueing system.I 
was doing the AC in the script, which was ok on a single link to 
simulate the behaviour of that mechanism.
 
But I need to simulate more complex topologies and even do simulations 
on adaptive routing and QoS routing, with the same router mechanism - 
thus doing it in a script is no longer satisfactory and I need to be 
able to instantiate that admission control easily. I think there must be 
a very simple way by using an  reference like linkHead_ in a node or 
like fromNode_ or ifaceIn_ in a link/queue but I'missing it. I tried a 
few things but none worked. Any ideas? Thanks in advance!

Pierre S. Guichard



From mathieu.lacage at sophia.inria.fr  Fri Aug  8 13:58:04 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Fri, 08 Aug 2008 13:58:04 -0700
Subject: [Ns-developers] NS-3 UDP / TCP refactoring
In-Reply-To: <4890865F.4070201@clarinet.u-strasbg.fr>
References: <48903C51.3090501@clarinet.u-strasbg.fr>
	<4890865F.4070201@clarinet.u-strasbg.fr>
Message-ID: <1218229084.26170.68.camel@ns-test>

hi sebastien,

I see that no one has replied to this second email, so, I gave your repo
another look and I have to confess that, at first, I was a bit scared
so, I took a step back and tried to figure out what we are trying to
achieve, and what really matters. I hope you won't find this too painful
since I don't know much about ipv6 but, the following will hopefully
make it easier to go forward.

I) the socket API
-----------------

1) The primary means of interaction is AF_INET6 and PF_INET6, both of
which replace AF_INET and PF_INET in socket function calls. So, we can
write the following:
  socket (PF_INET, SOCK_DGRAM, 0); // udp/ipv4
  socket (PF_INET, SOCK_STREAM, 0); // tcp/ipv4
  socket (PF_INET6, SOCK_DGRAM, 0); // udp/ipv6
  socket (PF_INET6, SOCK_STREAM, 0); // tcp/ipv6
  socket (PF_INET, SOCK_RAW, proto); // proto/ipv4
  socket (PF_INET6, SOCK_RAW, proto); // proto/ipv6
  socket (PF_INET, SOCK_RAW, IPPROTO_RAW); // raw/ipv4
  socket (PF_INET6, SOCK_RAW, IPPROTO_RAW); // raw/ipv6

2) a secondary means of interaction is through the so-called ipv4
compatibility:
  socket (PF_INET6, SOCK_DGRAM, 0); // udp/ipv6
  socket (PF_INET6, SOCK_STREAM, 0); // tcp/ipv6

  But we use an ipv4 address to for connect or bind.

You obviously care about supporting both kinds of interactions so, it is
important for you that ipv6 sockets actually support ipv4 addresses.

Is the above correct ?


II) How is the socket function mapped in ns-3 terms ?
-----------------------------------------------------

In ns-3, sockets are created with subclasses of the SocketFactory base
class. Each instance of a SocketFactory creates one type of socket and,
we get a socket factory by writing:
Ptr<Socket> socket = Socket::CreateSocket (node, socketType);

How can we encode the type of socket to create in the socketType ?
We discussed that briefly in our first thread on that topic in june and
I think that the version we seemed to converge upon is to map pairs
family+type to a single string:
  - PF_INET+SOCK_DGRAM = "ns3::Ipv4UdpSocketFactory"
  - PF_INET+SOCK_STREAM = "ns3::Ipv4TcpSocketFactory"
  - PF_INET6+SOCK_DGRAM = "ns3::Ipv6UdpSocketFactory"
  - PF_INET6+SOCK_STREAM = "ns3::Ipv6TcpSocketFactory"

For compatibility, we could easily rename "ns3::Ipv4UdpSocketFactory" to
"ns3::UdpSocketFactory" as an exception but I have to confess that I
don't find this especially exciting.

What the above does not solve, though, is what happens of the protocol
argument which, unfortunately, will be needed if you want to be able to
create ICMP sockets. We could keep extending the above proposal:
  - PF_INET+SOCK_RAW+IPPROTO_ICMP = "ns3::Ipv4RawIcmpSocketFactory"
  - PF_INET6+SOCK_RAW+IPPROTO_ICMP = "ns3::Ipv6RawIcmpSocketFactory"
  - etc.

So, what all this means is that we need a large set of SocketFactory
subclasses for each of these combinations. This, of course, does not
mandate you to implement one type of socket for each combination: you
could conceivably implement this scheme by reusing the same socket type
in multiple socket factories and setting a special bit before returning
the socket to the caller. This brings me to the next part of this email,
the implementation of that scheme.

III) How do we implement all this ?
-----------------------------------

The most obvious implementation is the one you did originally:
copy/paste everything, replace ipv4 by ipv6, et voila: you are done.
Now, clearly, there is a pretty strong motivating factor to at least be
able to reuse the tcp implementation. The biggest question I have here
is whether or not it makes sense to attempt to reuse more than the tcp
implementation and I think that the answer to that question is going to
drive a lot of decisions on how you implement this. I have tried to
figure out what was your answer to that question but I am not sure. I
think that you are trying to reuse much more but the result is not
really overwhelming because you seem to end up duplicating a lot of
important functions with Ipv4 and Ipv6 variants in the Demux for
example, but in a couple of other locations.

So, I personally don't have any strong opinion about this but, I think
that it would be really helpful if you could comment on the above to
explain what you think the goal is.

Now, that I went through all these abstract considerations, here are a
couple of comments on the actual patchset:


1) I find it really weird that you have if (ipv4) else if (ipv6)
statements both in the caller and the callee of TcpHeader. i.e., either
TcpHeader should not have if (ipv4) else (ipv6) statements or the
following should be moved down to TcpHeader::InitializeChecksum and its
signature should be changed to accept Address instead of Ipv4Address.

code taken from tcp-l4-protocol.cc:

- tcpHeader.InitializeChecksum (source, destination, PROT_NUMBER); 
+    if(Ipv4Address::IsMatchingType(source))
+    {
+      tcpHeader.InitializeChecksum (Ipv4Address::ConvertFrom(source), Ipv4Address::ConvertFrom(destination), PROT_NUMBER);
+    }
+    /* add IPv6 code here */
   }

I would tend towards changing the signature of InitializeChecksum to
take Address instead of Ipv4Address.


2) The same questions holds in code like that:

-  Ipv4EndPointDemux::EndPoints endPoints =
-    m_endPoints->Lookup (destination, tcpHeader.GetDestinationPort (),
-                         source, tcpHeader.GetSourcePort (),incomingInterface);
+  EndPointDemux::EndPoints endPoints;
+
+  if(Ipv4Address::IsMatchingType(source))
+  {
+    endPoints = m_endPoints->Lookup (Ipv4Address::ConvertFrom(destination), tcpHeader.GetDestinationPort (),
+                  Ipv4Address::ConvertFrom(source), tcpHeader.GetSourcePort (), cidr);
+  }
+  /* add IPv6 code here */
+

I would tend to say that if you rename Ipv4EndPointDemux to
EndPointDemux, its methods should take Address arguments, and not
Ipv4Address arguments so, the above should be rewritten to move the
IsMatchingType down to the implementation of the Lookup method or,
better, maybe make the implementation of EndPointDemux not know anything
about Ipv4 vs Ipv6. I don't believe that this would be really possible
for Lookup: you will need to demultiplex Lookup into LookupV4 and
LookupV6 but it might well be possible for Allocate* methods if you
remove Allocate(void) and Allocate(uint16_t port)). At this point,
though, you will have to wonder how much code you are really sharing and
figure out whether it makes much sense to use a single shared class or
if you could not simply duplicate Ipv4EndPointDemux into
Ipv6EndPointDemux.

I would tend to do the duplication in this case.

I went through the rest of your patch too quickly to give more comments,
but my gut feeling is that it could be much more productive and easy to
just duplicate everything but the TCP code and simply add some shielding
to the TCP code to make it address-independent. So, at this point, what
I would do is try to give a long hard look at the TCP code to figure out
where it is address-dependent and how we can split this out of it.

I honestly don't really know what the answer is here but I thought you
might find the above helpful.

Mathieu

On Wed, 2008-07-30 at 17:18 +0200, S?bastien Vincent wrote: 
> S?bastien Vincent wrote:
> > Hello,
> >
> > I begin to work on UDP / TCP that could manage both IPv6 and IPv4.
> >
> > My repository is at https://svnet.u-strasbg.fr/hg/ns-3-l4/
> >
> > It is based on ns-3-dev.
> >
> > The changeset 3494:79fd6df66ee6 is the preparation of UdpHeader and 
> > TcpHeader for IPv6 support. The things I have done are :
> > - change Ipv4Address (m_source and m_destination) to Address;
> > - Refactor CalculateHeaderChecksum by testing the m_source type 
> > address and apply the checksum calculation.
> >
> > For IPv6 version the only things to do are to add  in 
> > Udp/TcpHeader::CalculateHeaderChecksum () :
> > "else if(Ipv6Address::IsMatchingAddress(m_source)..." and the specific 
> > IPv6 checksum calculation.
> >
> > Now I will look more specifically in *L4Protocol what things I can do.
> >
> 
> I have setup a preparation for the IPv6 support in *L4Protocol. Tell me 
> if there are too much of "if(IsMatchingType(ipv4) ... else".
> For each part I leave a comment of where put specific IPv6 code.
> 
> I have done something for the replacement of the incomingInterface 
> parameter in *L4Protocol::Receive(). In facts for directed broadcast 
> (like in simple-point-to-point-olsr) we need to have at least the 
> network mask of the receiver IPv4 address. I think it is not the best 
> solution but we remove a class dependency (Ptr<Ipv4Interface>), maybe 
> replace this by a CidrSocketTag.
> 
> I have updated the repository (ns-3-l4), so feedbacks is welcome.
> 
> 
> > Regards,
> > -- 
> > Sebastien
> >
> 


From mathieu.lacage at sophia.inria.fr  Fri Aug  8 14:58:50 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Fri, 08 Aug 2008 14:58:50 -0700
Subject: [Ns-developers] NS-3 UDP / TCP refactoring
In-Reply-To: <1218229084.26170.68.camel@ns-test>
References: <48903C51.3090501@clarinet.u-strasbg.fr>
	<4890865F.4070201@clarinet.u-strasbg.fr>
	<1218229084.26170.68.camel@ns-test>
Message-ID: <1218232730.26170.88.camel@ns-test>


On Fri, 2008-08-08 at 13:58 -0700, Mathieu Lacage wrote:

> In ns-3, sockets are created with subclasses of the SocketFactory base
> class. Each instance of a SocketFactory creates one type of socket and,
> we get a socket factory by writing:
> Ptr<Socket> socket = Socket::CreateSocket (node, socketType);
> 
> How can we encode the type of socket to create in the socketType ?
> We discussed that briefly in our first thread on that topic in june and
> I think that the version we seemed to converge upon is to map pairs
> family+type to a single string:
>   - PF_INET+SOCK_DGRAM = "ns3::Ipv4UdpSocketFactory"
>   - PF_INET+SOCK_STREAM = "ns3::Ipv4TcpSocketFactory"
>   - PF_INET6+SOCK_DGRAM = "ns3::Ipv6UdpSocketFactory"
>   - PF_INET6+SOCK_STREAM = "ns3::Ipv6TcpSocketFactory"
> 
> For compatibility, we could easily rename "ns3::Ipv4UdpSocketFactory" to
> "ns3::UdpSocketFactory" as an exception but I have to confess that I
> don't find this especially exciting.
> 
> What the above does not solve, though, is what happens of the protocol
> argument which, unfortunately, will be needed if you want to be able to
> create ICMP sockets. We could keep extending the above proposal:
>   - PF_INET+SOCK_RAW+IPPROTO_ICMP = "ns3::Ipv4RawIcmpSocketFactory"
>   - PF_INET6+SOCK_RAW+IPPROTO_ICMP = "ns3::Ipv6RawIcmpSocketFactory"
>   - etc.

I should have realized earlier that the above cannot work because the
whole point of a raw socket is to allow the user to freely specify an
arbitrary protocol number, not hardcode it in a string. So, there are
two options here: 
  - define a RawSocket base class and add a SetProtocol method there.
  - add an int protocol argument to SocketFactory::Create and
Socket::CreateSocket.

In the interest of avoiding too much breakage, the former would be the
way to go but it would make it impossible to use these raw sockets with
the OnOffApplication for example. The latter seems more in line with the
socket API but it would have a lot of fallout everywhere we specify the
type of socket to create (especially in the applications and their
helpers).

I don't know if adding support for raw sockets nicely integrated in our
system is worth all this breakage though, so, the former option could be
the way to go. And, in case someone wonders, yes, I would like to
actually implement these raw sockets because I need them at least for
the ns-3-simu branch.

Mathieu


From fw at strlen.de  Sun Aug 10 16:33:59 2008
From: fw at strlen.de (Florian Westphal)
Date: Mon, 11 Aug 2008 01:33:59 +0200
Subject: [Ns-developers] ns-3-nsc updates
Message-ID: <20080810233359.GS5198@Chamillionaire.breakpoint.cc>

Hi All,

just wanted to let you know that i've pushed an update to the Linux
2.6.26 stack to the nsc repository that will make things work on
x86-64.

Summer of Code is wrapping up now, so it would be good if we could
have a talk about merging ns-3-nsc into ns-3-dev.

For reference, the current open items on the todo list are:

* fix 64 bit builds
FreeBSD and OpenBSD stacks don't work yet and i doubt they will
anytime soon. Hopefully not a show stopper, as this has nothing to do
with ns-3. Linux 2.6.18, 2.6.26 and the lwip stack work on x86-64.

* add to nightly regression (and debug those issues)

I don't know exactly what i have to do here 8-)
The known problem is that traces on x86 and x86_64 are slightly
different.

* have a code review to plan to merge

The planned move from scons to waf as the nsc build system has been
scrapped for the time being. This is hopefully not a big deal. I'll
look into removing the dependency on scons (by including
a 'local' scons version in nsc) on Monday.

One final item is documentation, which I'm going to handle this week.

Please let me know if I missed something.

Regards, Florian

From vincent at clarinet.u-strasbg.fr  Tue Aug 12 00:47:25 2008
From: vincent at clarinet.u-strasbg.fr (=?UTF-8?B?U8OpYmFzdGllbiBWaW5jZW50?=)
Date: Tue, 12 Aug 2008 09:47:25 +0200
Subject: [Ns-developers] NS-3 UDP / TCP refactoring
In-Reply-To: <1218229084.26170.68.camel@ns-test>
References: <48903C51.3090501@clarinet.u-strasbg.fr>	
	<4890865F.4070201@clarinet.u-strasbg.fr>
	<1218229084.26170.68.camel@ns-test>
Message-ID: <48A1400D.6070502@clarinet.u-strasbg.fr>

Hi,

OK, I will see it after my holidays.

Regards,
--
Sebastien

Mathieu Lacage a ?crit :
> hi sebastien,
>
> I see that no one has replied to this second email, so, I gave your repo
> another look and I have to confess that, at first, I was a bit scared
> so, I took a step back and tried to figure out what we are trying to
> achieve, and what really matters. I hope you won't find this too painful
> since I don't know much about ipv6 but, the following will hopefully
> make it easier to go forward.
>
> I) the socket API
> -----------------
>
> 1) The primary means of interaction is AF_INET6 and PF_INET6, both of
> which replace AF_INET and PF_INET in socket function calls. So, we can
> write the following:
>   socket (PF_INET, SOCK_DGRAM, 0); // udp/ipv4
>   socket (PF_INET, SOCK_STREAM, 0); // tcp/ipv4
>   socket (PF_INET6, SOCK_DGRAM, 0); // udp/ipv6
>   socket (PF_INET6, SOCK_STREAM, 0); // tcp/ipv6
>   socket (PF_INET, SOCK_RAW, proto); // proto/ipv4
>   socket (PF_INET6, SOCK_RAW, proto); // proto/ipv6
>   socket (PF_INET, SOCK_RAW, IPPROTO_RAW); // raw/ipv4
>   socket (PF_INET6, SOCK_RAW, IPPROTO_RAW); // raw/ipv6
>
> 2) a secondary means of interaction is through the so-called ipv4
> compatibility:
>   socket (PF_INET6, SOCK_DGRAM, 0); // udp/ipv6
>   socket (PF_INET6, SOCK_STREAM, 0); // tcp/ipv6
>
>   But we use an ipv4 address to for connect or bind.
>
> You obviously care about supporting both kinds of interactions so, it is
> important for you that ipv6 sockets actually support ipv4 addresses.
>
> Is the above correct ?
>
>
> II) How is the socket function mapped in ns-3 terms ?
> -----------------------------------------------------
>
> In ns-3, sockets are created with subclasses of the SocketFactory base
> class. Each instance of a SocketFactory creates one type of socket and,
> we get a socket factory by writing:
> Ptr<Socket> socket = Socket::CreateSocket (node, socketType);
>
> How can we encode the type of socket to create in the socketType ?
> We discussed that briefly in our first thread on that topic in june and
> I think that the version we seemed to converge upon is to map pairs
> family+type to a single string:
>   - PF_INET+SOCK_DGRAM = "ns3::Ipv4UdpSocketFactory"
>   - PF_INET+SOCK_STREAM = "ns3::Ipv4TcpSocketFactory"
>   - PF_INET6+SOCK_DGRAM = "ns3::Ipv6UdpSocketFactory"
>   - PF_INET6+SOCK_STREAM = "ns3::Ipv6TcpSocketFactory"
>
> For compatibility, we could easily rename "ns3::Ipv4UdpSocketFactory" to
> "ns3::UdpSocketFactory" as an exception but I have to confess that I
> don't find this especially exciting.
>
> What the above does not solve, though, is what happens of the protocol
> argument which, unfortunately, will be needed if you want to be able to
> create ICMP sockets. We could keep extending the above proposal:
>   - PF_INET+SOCK_RAW+IPPROTO_ICMP = "ns3::Ipv4RawIcmpSocketFactory"
>   - PF_INET6+SOCK_RAW+IPPROTO_ICMP = "ns3::Ipv6RawIcmpSocketFactory"
>   - etc.
>
> So, what all this means is that we need a large set of SocketFactory
> subclasses for each of these combinations. This, of course, does not
> mandate you to implement one type of socket for each combination: you
> could conceivably implement this scheme by reusing the same socket type
> in multiple socket factories and setting a special bit before returning
> the socket to the caller. This brings me to the next part of this email,
> the implementation of that scheme.
>
> III) How do we implement all this ?
> -----------------------------------
>
> The most obvious implementation is the one you did originally:
> copy/paste everything, replace ipv4 by ipv6, et voila: you are done.
> Now, clearly, there is a pretty strong motivating factor to at least be
> able to reuse the tcp implementation. The biggest question I have here
> is whether or not it makes sense to attempt to reuse more than the tcp
> implementation and I think that the answer to that question is going to
> drive a lot of decisions on how you implement this. I have tried to
> figure out what was your answer to that question but I am not sure. I
> think that you are trying to reuse much more but the result is not
> really overwhelming because you seem to end up duplicating a lot of
> important functions with Ipv4 and Ipv6 variants in the Demux for
> example, but in a couple of other locations.
>
> So, I personally don't have any strong opinion about this but, I think
> that it would be really helpful if you could comment on the above to
> explain what you think the goal is.
>
> Now, that I went through all these abstract considerations, here are a
> couple of comments on the actual patchset:
>
>
> 1) I find it really weird that you have if (ipv4) else if (ipv6)
> statements both in the caller and the callee of TcpHeader. i.e., either
> TcpHeader should not have if (ipv4) else (ipv6) statements or the
> following should be moved down to TcpHeader::InitializeChecksum and its
> signature should be changed to accept Address instead of Ipv4Address.
>
> code taken from tcp-l4-protocol.cc:
>
> - tcpHeader.InitializeChecksum (source, destination, PROT_NUMBER); 
> +    if(Ipv4Address::IsMatchingType(source))
> +    {
> +      tcpHeader.InitializeChecksum (Ipv4Address::ConvertFrom(source), Ipv4Address::ConvertFrom(destination), PROT_NUMBER);
> +    }
> +    /* add IPv6 code here */
>    }
>
> I would tend towards changing the signature of InitializeChecksum to
> take Address instead of Ipv4Address.
>
>
> 2) The same questions holds in code like that:
>
> -  Ipv4EndPointDemux::EndPoints endPoints =
> -    m_endPoints->Lookup (destination, tcpHeader.GetDestinationPort (),
> -                         source, tcpHeader.GetSourcePort (),incomingInterface);
> +  EndPointDemux::EndPoints endPoints;
> +
> +  if(Ipv4Address::IsMatchingType(source))
> +  {
> +    endPoints = m_endPoints->Lookup (Ipv4Address::ConvertFrom(destination), tcpHeader.GetDestinationPort (),
> +                  Ipv4Address::ConvertFrom(source), tcpHeader.GetSourcePort (), cidr);
> +  }
> +  /* add IPv6 code here */
> +
>
> I would tend to say that if you rename Ipv4EndPointDemux to
> EndPointDemux, its methods should take Address arguments, and not
> Ipv4Address arguments so, the above should be rewritten to move the
> IsMatchingType down to the implementation of the Lookup method or,
> better, maybe make the implementation of EndPointDemux not know anything
> about Ipv4 vs Ipv6. I don't believe that this would be really possible
> for Lookup: you will need to demultiplex Lookup into LookupV4 and
> LookupV6 but it might well be possible for Allocate* methods if you
> remove Allocate(void) and Allocate(uint16_t port)). At this point,
> though, you will have to wonder how much code you are really sharing and
> figure out whether it makes much sense to use a single shared class or
> if you could not simply duplicate Ipv4EndPointDemux into
> Ipv6EndPointDemux.
>
> I would tend to do the duplication in this case.
>
> I went through the rest of your patch too quickly to give more comments,
> but my gut feeling is that it could be much more productive and easy to
> just duplicate everything but the TCP code and simply add some shielding
> to the TCP code to make it address-independent. So, at this point, what
> I would do is try to give a long hard look at the TCP code to figure out
> where it is address-dependent and how we can split this out of it.
>
> I honestly don't really know what the answer is here but I thought you
> might find the above helpful.
>
> Mathieu
>
> On Wed, 2008-07-30 at 17:18 +0200, S?bastien Vincent wrote: 
>   
>> S?bastien Vincent wrote:
>>     
>>> Hello,
>>>
>>> I begin to work on UDP / TCP that could manage both IPv6 and IPv4.
>>>
>>> My repository is at https://svnet.u-strasbg.fr/hg/ns-3-l4/
>>>
>>> It is based on ns-3-dev.
>>>
>>> The changeset 3494:79fd6df66ee6 is the preparation of UdpHeader and 
>>> TcpHeader for IPv6 support. The things I have done are :
>>> - change Ipv4Address (m_source and m_destination) to Address;
>>> - Refactor CalculateHeaderChecksum by testing the m_source type 
>>> address and apply the checksum calculation.
>>>
>>> For IPv6 version the only things to do are to add  in 
>>> Udp/TcpHeader::CalculateHeaderChecksum () :
>>> "else if(Ipv6Address::IsMatchingAddress(m_source)..." and the specific 
>>> IPv6 checksum calculation.
>>>
>>> Now I will look more specifically in *L4Protocol what things I can do.
>>>
>>>       
>> I have setup a preparation for the IPv6 support in *L4Protocol. Tell me 
>> if there are too much of "if(IsMatchingType(ipv4) ... else".
>> For each part I leave a comment of where put specific IPv6 code.
>>
>> I have done something for the replacement of the incomingInterface 
>> parameter in *L4Protocol::Receive(). In facts for directed broadcast 
>> (like in simple-point-to-point-olsr) we need to have at least the 
>> network mask of the receiver IPv4 address. I think it is not the best 
>> solution but we remove a class dependency (Ptr<Ipv4Interface>), maybe 
>> replace this by a CidrSocketTag.
>>
>> I have updated the repository (ns-3-l4), so feedbacks is welcome.
>>
>>
>>     
>>> Regards,
>>> -- 
>>> Sebastien
>>>
>>>       
>
>
>   


From mathieu.lacage at sophia.inria.fr  Tue Aug 12 12:56:23 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 12 Aug 2008 12:56:23 -0700
Subject: [Ns-developers] [Ns-commits] ns-3-dev
In-Reply-To: <1218570422.0@code.nsnam.org>
References: <1218570422.0@code.nsnam.org>
Message-ID: <1218570983.30906.3.camel@ns-test>

hi,

I screwed up and checked in the changesets below in ns-3-dev. I reverted
them a couple of seconds later.

On Tue, 2008-08-12 at 15:47 -0400, code at nsnam-code.ece.gatech.edu wrote:
> ---- inet raw sockets.
> user: Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
> files: src/internet-stack/internet-stack.cc src/internet-stack/ipv4-l3-protocol.cc src/internet-stack/ipv4-l3-protocol.h src/internet-stack/ipv4-raw-socket-factory-impl.cc src/internet-stack/ipv4-raw-socket-factory-impl.h src/internet-stack/ipv4-raw-socket-impl.cc src/internet-stack/ipv4-raw-socket-impl.h src/internet-stack/wscript src/node/ipv4-raw-socket-factory.cc src/node/ipv4-raw-socket-factory.h src/node/wscript
> url: http://code.nsnam.org/ns-3-dev/rev/fc07f91a5da1
> 
> 
> ---- There might not be any protocol to receive the packet. sockets need a node.
> user: Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
> files: src/internet-stack/ipv4-l3-protocol.cc
> url: http://code.nsnam.org/ns-3-dev/rev/011df1d87b7e
> 
> 
> ---- need a node. must notify listeners.
> user: Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
> files: src/internet-stack/ipv4-raw-socket-impl.cc src/internet-stack/ipv4-raw-socket-impl.h
> url: http://code.nsnam.org/ns-3-dev/rev/9872af91a920
> 
> 
> ---- raw packet example.
> user: Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
> files: examples/csma-raw-ip-socket.cc examples/wscript
> url: http://code.nsnam.org/ns-3-dev/rev/763a4448ce4b
> 
> 
> ---- Make sure received packets still have an ip header when sent back to the user.
> user: Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
> files: src/internet-stack/ipv4-raw-socket-impl.cc
> url: http://code.nsnam.org/ns-3-dev/rev/b70c5aa11ba9
> 
> 
> ---- make sure we set a source address for outgoing packets.
> user: Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
> files: src/internet-stack/ipv4-raw-socket-impl.cc
> url: http://code.nsnam.org/ns-3-dev/rev/65252ab0770b
> 
> 
> ---- icmp ping
> user: Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
> files: examples/csma-ping.cc examples/wscript src/applications/v4ping/v4ping.cc src/applications/v4ping/v4ping.h src/applications/v4ping/wscript src/helper/v4ping-helper.cc src/helper/v4ping-helper.h src/helper/wscript src/internet-stack/icmpv4-l4-protocol.cc src/internet-stack/icmpv4-l4-protocol.h src/internet-stack/icmpv4.cc src/internet-stack/icmpv4.h src/internet-stack/internet-stack.cc src/internet-stack/wscript src/wscript
> url: http://code.nsnam.org/ns-3-dev/rev/b4c4bebae87d
> 
> 
> ---- merge with HEAD
> user: Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
> files: examples/tcp-2way.cc examples/wscript src/helper/wscript
> url: http://code.nsnam.org/ns-3-dev/rev/c523dc211926
> 
> 
> ---- allow attribute setters to fail.
> user: Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
> files: src/core/attribute-accessor-helper.h src/core/attribute-test.cc
> url: http://code.nsnam.org/ns-3-dev/rev/98448c834723
> 
> 
> _______________________________________________


From L.Wood at surrey.ac.uk  Wed Aug 13 08:10:03 2008
From: L.Wood at surrey.ac.uk (Lloyd Wood)
Date: Wed, 13 Aug 2008 16:10:03 +0100
Subject: [Ns-developers] WNS2 workshop programme - 23 October, Athens, Greece
Message-ID: <200808131510.m7DFA6Y01650@cisco.com>

http://www.wns2.org/techprog.shtml

The one-day WNS2 2008 workshop is now finalised. It's in Athens, Greece, on 23 October 2008.
We have eight papers, and a tutorial on ns3 from Dr George Riley. Abstracts of these are at the url above.

WNS2 is being run as part of the ValueTools conference (http://www.valuetools.org/) where registration
for the separate workshops is carried out. There are discounts for ICST, IEEE and ACM members.
WNS2 and ValueTools are being held at a hotel in Athens:
http://www.valuetools.org/conferencelocation.shtml

WNS2 is the only ns-specific conference event this year! You wouldn't want to miss it!

L.

for the WNS2 co-chairs.

Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood at surrey.ac.uk> 


From craigdo at ee.washington.edu  Thu Aug 14 11:47:48 2008
From: craigdo at ee.washington.edu (craigdo@ee.washington.edu)
Date: Thu, 14 Aug 2008 11:47:48 -0700
Subject: [Ns-developers] ns-3 realtime multithreaded simulator
In-Reply-To: <48A1400D.6070502@clarinet.u-strasbg.fr>
References: <48903C51.3090501@clarinet.u-strasbg.fr>	<4890865F.4070201@clarinet.u-strasbg.fr><1218229084.26170.68.camel@ns-test>
	<48A1400D.6070502@clarinet.u-strasbg.fr>
Message-ID: <004501c8fe3e$3ff2e6d0$0302a8c0@VAIO>

Hi all,

Many of you know that I've been working on a multithreaded and real-time
version of the ns-3 simulator implementation.  It's been running for quite
some time with no problems, so I'd like to push it into ns-3-dev in
preparation for the ns-3.2 release.

You can find the code in code.nsnam.org/craigdo/ns-3-emu in the
src/simulator directory.  What I'm talking about is adding the simulator:

  realtime-simulator-impl.h
  realtime-simulator-impl.cc

and a synchronizer (that synchronizes the simulation to real time) base
class and implementation:

  synchronizer.h
  syncrhonizer.cc
  wall-clock-synchronizer.h
  wall-clock-synchronizer.cc


This won't have any effect on existing code and is completely dormant by
default.  If you want to run a simulation in real-time mode, you have to
enable the new implementation:

  GlobalValue::Bind ("SimulatorImplementationType",
    StringValue ("ns3::RealtimeSimulatorImpl"));

This swaps in the real-time simulator implementation and suddenly your
simulations will consume real time.

There is one more piece to the ns-3-emu puzzle that is working fine that you
can expect soon -- a net device to run ns-3 stacks over real networks
(testbeds).  If you are interested in checking that out, you can find it in
src/devices/emulated.  It uses MAC spoofing and promiscuous mode together
with packet sockets to take over a real interface in a host and transmit and
receive ns-3 generated traffic.  It's a good demo to show how you can use
multithreading to work with the new simulator implementation.

Comments are welcome.  If there is not, "a great wailing and gnashing of
teeth," I'll check in the simulator pieces early next week.  :-)

Regards,

-- Craig



From mathieu.lacage at sophia.inria.fr  Fri Aug 15 12:25:51 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Fri, 15 Aug 2008 12:25:51 -0700
Subject: [Ns-developers] ns-3 realtime multithreaded simulator
In-Reply-To: <004501c8fe3e$3ff2e6d0$0302a8c0@VAIO>
References: <48903C51.3090501@clarinet.u-strasbg.fr>
	<4890865F.4070201@clarinet.u-strasbg.fr><1218229084.26170.68.camel@ns-test>
	<48A1400D.6070502@clarinet.u-strasbg.fr>
	<004501c8fe3e$3ff2e6d0$0302a8c0@VAIO>
Message-ID: <1218828351.23615.19.camel@ns-test>


On Thu, 2008-08-14 at 11:47 -0700, craigdo at ee.washington.edu wrote:
> Hi all,
> 
> Many of you know that I've been working on a multithreaded and real-time
> version of the ns-3 simulator implementation.  It's been running for quite
> some time with no problems, so I'd like to push it into ns-3-dev in
> preparation for the ns-3.2 release.
> 
> You can find the code in code.nsnam.org/craigdo/ns-3-emu in the
> src/simulator directory.  What I'm talking about is adding the simulator:
> 
>   realtime-simulator-impl.h
>   realtime-simulator-impl.cc

Would you mind add the virtual keywords on methods inherited from the
base class in realtime-simulator-impl.h ? I know that it is redundant,
that it is impossible to check that you got all of them right, that it
is hard to maintain but, it makes starting in the codebase much easier
for newcomers and we have been doing that for a good while in the rest
of the codebase.

Other than that, looks good to me.

> 
> and a synchronizer (that synchronizes the simulation to real time) base
> class and implementation:
> 
>   synchronizer.h
>   syncrhonizer.cc
>   wall-clock-synchronizer.h
>   wall-clock-synchronizer.cc
> 
> 
> This won't have any effect on existing code and is completely dormant by
> default.  If you want to run a simulation in real-time mode, you have to
> enable the new implementation:
> 
>   GlobalValue::Bind ("SimulatorImplementationType",
>     StringValue ("ns3::RealtimeSimulatorImpl"));
> 
> This swaps in the real-time simulator implementation and suddenly your
> simulations will consume real time.
> 
> There is one more piece to the ns-3-emu puzzle that is working fine that you
> can expect soon -- a net device to run ns-3 stacks over real networks
> (testbeds).  If you are interested in checking that out, you can find it in
> src/devices/emulated.  It uses MAC spoofing and promiscuous mode together
> with packet sockets to take over a real interface in a host and transmit and
> receive ns-3 generated traffic.  It's a good demo to show how you can use
> multithreading to work with the new simulator implementation.
> 
> Comments are welcome.  If there is not, "a great wailing and gnashing of
> teeth," I'll check in the simulator pieces early next week.  :-)
> 
> Regards,
> 
> -- Craig
> 
> 


From mathieu.lacage at sophia.inria.fr  Fri Aug 15 13:10:19 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Fri, 15 Aug 2008 13:10:19 -0700
Subject: [Ns-developers] gsoc wrapup
Message-ID: <1218831019.31409.23.camel@ns-test>

hi,

According to the gsoc timeline,
http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline, we
are nearing the start of the final gsoc evaluations on August 18th. This
means that we should all be ready to look back at what has been
accomplished, and summarize what we have done. Right now, I have not
seen any feedback from hagen for a couple of weeks so, now is the time
to send a final update to the mailing-list before monday. Florian sent a
summary last week and I have exchanged a couple of times with liu on irc
recently.

Based on the information I have right now, it looks like florian's stuff
is on track to be merged pretty soon after a couple of final reviews.

Liu's early work on the netlink implementation is also ready to be
merged in ns-3-simu when I get time to start working on netlink sockets.
Liu's attempts at porting libnl and quagga have also been very
beneficial for the ns-3-simu tree: I have used a number of his early
suggestions (such as, implementing send and sendto by calling sendmsg,
etc.).

Hagen's work seemed to be making progress the last time I heard about it
but, again, that was more than a month ago and I did not see much
activity in the http://code.nsnam.org/pfeifer/ns-3-para/ branch since
july the 22nd.

To summarize, it looks like a lot of work has been accomplished by our 3
students and that a lot of that work is going to be useful for ns-3 so,
it seems that we have been pretty successful !

Before we get to the final evaluation period on monday, I would really
appreciate that each student try to send a short summary of what they
have accomplished over the summer.

regards,
Mathieu


From fw at strlen.de  Sun Aug 17 03:34:01 2008
From: fw at strlen.de (Florian Westphal)
Date: Sun, 17 Aug 2008 12:34:01 +0200
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <1218831019.31409.23.camel@ns-test>
References: <1218831019.31409.23.camel@ns-test>
Message-ID: <20080817103401.GC15575@Chamillionaire.breakpoint.cc>

Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
[..]
> Based on the information I have right now, it looks like florian's stuff
> is on track to be merged pretty soon after a couple of final reviews.

This would be great, please poke me via mail or irc if there should be
showstoppers, i'd really like to see it merged and will be happy to
help.

> Before we get to the final evaluation period on monday, I would really
> appreciate that each student try to send a short summary of what they
> have accomplished over the summer.

We have a port of the Linux 2.6.26 stack available in NSC.
ns-3-nsc (ns-3 with additional code that allows a simulation
to assign nsc real-world network stacks to nodes) will then
generate 'proper' pcap TCP traces that can be examined
with wireshark, tcptrace, etc.
I've put up a page with a few tcptrace plots at http://strlen.de/cradle/.
Using ns-3-nsc (with valgrind mem checker) even revealed an obscure bug
in Linux' TCP syncookie mechanism.

The API provided by NSC was extended to allow a simulator
to retrieve a list of supported sysctl values, to retrieve
the IP local/peer ip addresses of a connection and to
check for 'soft' (e.g.EAGAIN) or 'hard' (e.g. ECONNRESET)
errors returned by a stack.

Thanks to Mathieu Lacage ns-3s attribute system can be used to
set sysctl values of a stack, e.g. one can change the TCP
congestion control algorithm to use, disable tcp timestamps, etc.

Sam Jansen made a lot of improvements to the nsc globaliser,
which made porting Linux 2.6.26 much simpler. Also, thanks to his
efforts the development version of NSC is now available via mercurial.

I'd like to thank Sam for being patient with me when explaining NSCs
internal workings, Mathieu for helping out on the ns-3 side of things
and everyone else that helped along the way.

Florian

From raj.b at gatech.edu  Sun Aug 17 10:08:01 2008
From: raj.b at gatech.edu (Raj Bhattacharjea)
Date: Sun, 17 Aug 2008 13:08:01 -0400
Subject: [Ns-developers] code.nsnam.org rebooted
Message-ID: <12d69e490808171008i29576fe3tca341b77a9721de9@mail.gmail.com>

Looks like it got in its regular funk sometime over the weekend.  It
should be working fine now.

-- 
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
Ph.D. Candidate
Systems Analyst
404.894.2955

From liujatp at gmail.com  Mon Aug 18 07:02:54 2008
From: liujatp at gmail.com (Liu Jian)
Date: Mon, 18 Aug 2008 22:02:54 +0800
Subject: [Ns-developers] gsoc summary reports[quagga-porting]
Message-ID: <200808182202528751560@gmail.com>

hi all,

my Gsoc project is porting quagga routes to ns-3 and summarize some
experience about how to integrate real world application with ns-3. 
During this three months of period, i learnd a lot, increase my code read
/write experience. (more details about my project process at:
http://www.nsnam.org/wiki/index.php/Real_World_Application_Integration )

1, netlink sockets implementation
Before step into porting, netlink socket was needed, since quagga rely
on it. my repo at http://code.nsnam.org/lj/ns-3-netlink.
netlink files at src/node/netlink-xxx.h/cc.

NetlinkSocket is subclass of Socket, and has the similar strcture and implementation. 
files:netlink-socket-address.h/cc, netlink-socket-factory.h/cc,
netlink-socket-helper.h/cc, netlink-socket.h/cc;

The 2 main points of the NetlinkSocket implementation were   
a)netlink message serilize and desirilize
b)netlink message handling.

For a): NetlinkMessage body has different payload due to different message type,
when do this, learn some experience from Header class, adopt simliar interface
functions to implement. 
files:netlink-message.h/cc,netlink-message-route.h/cc 

For b): To simulate how the linux kernel handle the netlink messages, I learn
from linux kernel code and just simply implement the part of the netlink 
mechanism. how the linux do is: user socket send an request to kernel, 
the kernel netlink socket recv it and handle it, then send ack back to 
user-space socket. where in my NetlinkSocket, there was no kernel socket 
exist, when user NetlinkSocket call send() to transfer an message, NetlinkSocket
::HandleMessage do it directly as kernel, then send the ack/response message
back to its own recv-queue, and it can be got when recv() called. 
files:netlink-socket.h/cc.

Netlink was big and complicated, here i just implemented what the quagga used.
Focusing on netlink route protocol: interface address dump/add/del, route entry 
dump/add/del/get, link dump. To show how the netlink message be built in ns-3, 
and to test the socket running, testing codes is at netlink-socket-test.cc.

2,porting(repo at http://code.nsnam.org/lj/quagga-porting.)
the porting is based on ns-3-simu, using the process model. There are two way which 
i do the porting. Before the elfloader, the simu_xxx funtion mapping method is what
i use to port libnl/quagga. at that time, libnl run successfully on ns-3-simu. 
when i was focusing porting zebra, mathieu implement the elfloader, which is genius.
it make porting much easier, just compile real-world program with -fpie, -pie option
and fill the actually function simu_xxx. now i have run libnl successfully on ns-test/
quagga-porting. In the next few days,i will try to run quagga. 

>From the porting process, i tested the netlink socket with the realworld application, 
and studied some skills from the great code. For code wrriting. i just wrote a few 
code:some simu_xx function and definition for porting.
my test at ns-test:/lj/quagga-porting, it run as:
 ./waf --shell;
./build/debug/example/process-libnl nl-addr-dump xml

Before merge the NetlinkSocket, code review/clean is needed, which will also be done
next days. i wish my code will be some useful to ns-3. 

>From this gsoc exprience, i rally learned a lot about code writing and technique, which 
will be my great fortune in the future. At the end of the Gsoc project, i want to thank
ns-3 community give me the chance to do the project, and i would appreciate mathieu for 
helping me a lot and fixing me many problem and explaining me many boring questions. 
Also i will thanks tomh,gjc,joe,fw,etc. they all gave me many good suggestions when 
i met difficulty. 





Liu Jian
2008-08-18

From raj.b at gatech.edu  Tue Aug 19 12:04:34 2008
From: raj.b at gatech.edu (Raj Bhattacharjea)
Date: Tue, 19 Aug 2008 15:04:34 -0400
Subject: [Ns-developers] ns3 simulation cradle dependencies
Message-ID: <12d69e490808191204y59f3cf89q45bd1673926cbb3c@mail.gmail.com>

Is it true that building nsc requires scons, flex, and bison?  It
seems that this is the case.  Before merging then, I suggest that when
"./waf --nsc configure" is run, it checks for these dependencies.

-- 
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
Ph.D. Candidate
Systems Analyst
404.894.2955

From fw at strlen.de  Tue Aug 19 12:17:33 2008
From: fw at strlen.de (Florian Westphal)
Date: Tue, 19 Aug 2008 21:17:33 +0200
Subject: [Ns-developers] ns3 simulation cradle dependencies
In-Reply-To: <12d69e490808191204y59f3cf89q45bd1673926cbb3c@mail.gmail.com>
References: <12d69e490808191204y59f3cf89q45bd1673926cbb3c@mail.gmail.com>
Message-ID: <20080819191733.GF15575@Chamillionaire.breakpoint.cc>

Raj Bhattacharjea <raj.b at gatech.edu> wrote:
> Is it true that building nsc requires scons, flex, and bison?

NSC needs Flex and Bison (for the globaliser).
A local version of scons will be included with NSC
in future releases (already in mercurial tip), so scons
is no longer needed (you can run 'python scons.py' in the
nsc top-level directory).

> seems that this is the case.  Before merging then, I suggest that when
> "./waf --nsc configure" is run, it checks for these dependencies.

OK, i'll add this.

Thanks, Florian

From tomh at tomh.org  Fri Aug 22 06:47:55 2008
From: tomh at tomh.org (Tom Henderson)
Date: Fri, 22 Aug 2008 06:47:55 -0700
Subject: [Ns-developers] Sigcomm demo
Message-ID: <48AEC38B.8040006@tomh.org>

I previously announced that we were conducting a Sigcomm demo this week, 
and this is a brief report on it.  Our table was very well attended, and 
we were able to demo a scenario that showed off several recent and 
experimental features of ns-3:

- a mixed wired/wireless script in both Python and C++
- Mathieu's GTK-based attribute configurator
- Gustavo's mobility visualizer
- Mathieu's ELF loader supporting the running of the ping program on two 
different nodes
- Linux 2.6.18 TCP (Florian and Sam's NSC code) talking to the native 
ns-3 TCP stack ported by Raj
- ns-3 emulation and real-time scheduler; Craig partitioned the topology 
and ran each half in a separate virtual machine, replacing one of the 
simulated CSMA links with a VMware host-only LAN

We had dozens of people stop by and ask questions about the project.  In 
my view, it went very well and I wanted to recognize and thank the above 
people who made it possible.

Thanks,
Tom

From tomh at tomh.org  Fri Aug 22 08:16:44 2008
From: tomh at tomh.org (Tom Henderson)
Date: Fri, 22 Aug 2008 08:16:44 -0700
Subject: [Ns-developers] Sigcomm demo
In-Reply-To: <48AEC38B.8040006@tomh.org>
References: <48AEC38B.8040006@tomh.org>
Message-ID: <48AED85C.7090701@tomh.org>

I put together a small wiki page about the demo, including links to the 
poster that Craig put together for us, and an ns-3 datasheet:
http://www.nsnam.org/wiki/index.php?title=Sigcomm_2008_demo

The code we were using resides in the ns-3-sigcomm repository.

- Tom

From mathieu.lacage at sophia.inria.fr  Fri Aug 22 11:09:34 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Fri, 22 Aug 2008 11:09:34 -0700
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <20080817103401.GC15575@Chamillionaire.breakpoint.cc>
References: <1218831019.31409.23.camel@ns-test>
	<20080817103401.GC15575@Chamillionaire.breakpoint.cc>
Message-ID: <1219428574.5979.12.camel@ns-test>

hi florian,

On Sun, 2008-08-17 at 12:34 +0200, Florian Westphal wrote:
> Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
> [..]
> > Based on the information I have right now, it looks like florian's stuff
> > is on track to be merged pretty soon after a couple of final reviews.
> 
> This would be great, please poke me via mail or irc if there should be
> showstoppers, i'd really like to see it merged and will be happy to
> help.

I did a final review of the code and sent you a couple of comments
privately by email. Modulo a couple of very minor details, the code
looks good for merging to me so, feel free to try to push to ns-3-dev
when you are ready.

My plans for next week are to:
1) add waf support to nsc
2) allow you to enable or disable individual network stacks for the
build: building them all is killing me on my 32bit box.
3) add support to the build system to download either a mercurial nsc
repo or a nsc tarball depending on whether we are in release mode or not

Right now, downloading all of nsc is a bit bottleneck for me, whenever I
do a new clone (and I do a lot of them everyday). So, there are 2
options: either split nsc in multiple repos I can download separately
based on which stacks are enabled and/or try to share the same nsc
download among multiple ns-3-dev clones. I am not sure what the right
solution is but this is really painful for me so, I will try to think
about it some more.


Mathieu



From tomh at tomh.org  Fri Aug 22 12:11:50 2008
From: tomh at tomh.org (Tom Henderson)
Date: Fri, 22 Aug 2008 12:11:50 -0700
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <1219428574.5979.12.camel@ns-test>
References: <1218831019.31409.23.camel@ns-test>	<20080817103401.GC15575@Chamillionaire.breakpoint.cc>
	<1219428574.5979.12.camel@ns-test>
Message-ID: <48AF0F76.7010702@tomh.org>

Mathieu Lacage wrote:
> hi florian,
> 
> On Sun, 2008-08-17 at 12:34 +0200, Florian Westphal wrote:
>> Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>> [..]
>>> Based on the information I have right now, it looks like florian's stuff
>>> is on track to be merged pretty soon after a couple of final reviews.
>> This would be great, please poke me via mail or irc if there should be
>> showstoppers, i'd really like to see it merged and will be happy to
>> help.
> 
> I did a final review of the code and sent you a couple of comments
> privately by email. Modulo a couple of very minor details, the code
> looks good for merging to me so, feel free to try to push to ns-3-dev
> when you are ready.

It would be nice to try to resolve (or log into the tracker) the issues 
quickly if possible so that it could be merged next week.  Raj, can you 
please review as well?

> 
> My plans for next week are to:
> 1) add waf support to nsc
> 2) allow you to enable or disable individual network stacks for the
> build: building them all is killing me on my 32bit box.
> 3) add support to the build system to download either a mercurial nsc
> repo or a nsc tarball depending on whether we are in release mode or not

these would be very helpful

> 
> Right now, downloading all of nsc is a bit bottleneck for me, whenever I
> do a new clone (and I do a lot of them everyday). So, there are 2
> options: either split nsc in multiple repos I can download separately
> based on which stacks are enabled and/or try to share the same nsc
> download among multiple ns-3-dev clones. I am not sure what the right
> solution is but this is really painful for me so, I will try to think
> about it some more.
> 

Something like

./waf configure --with-nsc=path

would be useful, IMO.  If we do that, it seems like we may need to check 
whether nsc version is up to date enough.

Also, do the regression and unit test suites need a flag to remember 
whether nsc has been enabled?

Regarding the merge of code like this, where someone has been working on 
a project for many months with a long change history, should we be 
merging repos with full change history or just producing a final patch 
that is merged to ns-3-dev?  Is it author's discretion whether or not to 
keep forever the private change history?

Tom

From mathieu.lacage at sophia.inria.fr  Fri Aug 22 12:14:33 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Fri, 22 Aug 2008 12:14:33 -0700
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <48AF0F76.7010702@tomh.org>
References: <1218831019.31409.23.camel@ns-test>
	<20080817103401.GC15575@Chamillionaire.breakpoint.cc>
	<1219428574.5979.12.camel@ns-test>  <48AF0F76.7010702@tomh.org>
Message-ID: <1219432473.5979.25.camel@ns-test>


On Fri, 2008-08-22 at 12:11 -0700, Tom Henderson wrote:

> ./waf configure --with-nsc=path
> 
> would be useful, IMO.  If we do that, it seems like we may need to check 
> whether nsc version is up to date enough.

yes

> Also, do the regression and unit test suites need a flag to remember 
> whether nsc has been enabled?

I will look into this.

> 
> Regarding the merge of code like this, where someone has been working on 
> a project for many months with a long change history, should we be 
> merging repos with full change history or just producing a final patch 
> that is merged to ns-3-dev?  Is it author's discretion whether or not to 
> keep forever the private change history?

I would say that it is the author's discretion. 



From fw at strlen.de  Fri Aug 22 13:36:52 2008
From: fw at strlen.de (Florian Westphal)
Date: Fri, 22 Aug 2008 22:36:52 +0200
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <48AF0F76.7010702@tomh.org>
References: <1218831019.31409.23.camel@ns-test>
	<20080817103401.GC15575@Chamillionaire.breakpoint.cc>
	<1219428574.5979.12.camel@ns-test> <48AF0F76.7010702@tomh.org>
Message-ID: <20080822203652.GN26806@Chamillionaire.breakpoint.cc>

Tom Henderson <tomh at tomh.org> wrote:
> Mathieu Lacage wrote:
>> On Sun, 2008-08-17 at 12:34 +0200, Florian Westphal wrote:
>> I did a final review of the code and sent you a couple of comments
>> privately by email. Modulo a couple of very minor details, the code
>> looks good for merging to me so, feel free to try to push to ns-3-dev
>> when you are ready.
>
> It would be nice to try to resolve (or log into the tracker) the issues 
> quickly if possible so that it could be merged next week.  Raj, can you 
> please review as well?

Here is everything in a single patch:
http://www.strlen.de/cradle/ns-3-nsc-aug-22-2008.diff

It should apply cleanly to current ns-3-dev tip.

> Also, do the regression and unit test suites need a flag to remember 
> whether nsc has been enabled?

No, i removed all the nsc changes to the standard examples.
If they look different when nsc is enabled, its a bug.

> Regarding the merge of code like this, where someone has been working on a 
> project for many months with a long change history, should we be merging 
> repos with full change history or just producing a final patch that is 
> merged to ns-3-dev?  Is it author's discretion whether or not to keep 
> forever the private change history?

I already dumped some of the early changesets because I found it annoying
to look through a large history and you see dozens of back-and-forth
commits and reverts. So, personally I'd prefer to have a single commit,
or, if such a large commit is frowned upon, one larger patch that adds
the core files and another patch on top which adds the rest (wscript,
glue code to existing files).

Thanks to all reviewers for spending their time on this,
       Florian

Oh, by the way, I'll be offline next week. I'll work on any problems
and issues that may come up as soon as I get back.

From mathieu.lacage at sophia.inria.fr  Sun Aug 24 12:28:25 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Sun, 24 Aug 2008 21:28:25 +0200
Subject: [Ns-developers] ns-3 nam support
Message-ID: <1219606106.8223.34.camel@mathieu>

hi,

There were lots of question about nam support for ns-3 at the sigcomm
demo: tom managed to convince me to take a shot at this and see what we
could do. See http://code.nsnam.org/mathieu/ns-3-nam

src/contrib/nam-helper.h is the API and it seems to work reasonably well
for point to point links.

I still have some issues with the layout of broadcast links in nam so, I
would welcome input from nam experts. 

Here is what I generate:

V -t * -v 1.13 -a 0
n -t * -a 0 -s 0 -S UP -v circle
n -t * -a 1 -s 1 -S UP -v circle
n -t * -a 2 -s 2 -S UP -v circle
n -t * -a 3 -s 3 -S UP -v circle
X -t * -n 4 -r 5000000 -D 0.002
L -t * -s 4 -d 0
L -t * -s 4 -d 1
L -t * -s 4 -d 2
L -t * -s 4 -d 3

and here is the output I get:
http://faculty.washington.edu/lacage/csma-one-subnet.png

which, honestly, looks pretty bad. Someone would know how to coerce nam
into generating something nicer looking ?

Mathieu


From tomh at tomh.org  Mon Aug 25 08:07:26 2008
From: tomh at tomh.org (Tom Henderson)
Date: Mon, 25 Aug 2008 15:07:26 +0000
Subject: [Ns-developers] ns-3.2 release planning
Message-ID: <W758677912101561219676846@mail.mailsnare.net>

We are about due for another ns-3 release.  I'd like to suggest that we aim for wrapping up development and merging of new features for ns-3.2 by the end of the week, and post a release candidate around the end of the month, with a goal of making the release by mid-September.  Craig has agreed to serve as release manager again.

Here are a few items that I think we should aim for this week:

1) merge nsc; there are a few issues to deal with (final review of Florian's code, Sam to make a new nsc release, build system integration) but as we discussed on the list last week, we are probably close to being ready to merge this code 

2) move ns-3-stat to src/contrib:  the proposed statistics framework could be put into src/contrib for now to gather more feedback from users, and Joe agreed to try to work on this merge for this week

3) real-time scheduler:  Craig plans to merge this very soon

4) bridge issues:  There are a few open bugs regarding the bridge device, for which it would be nice to get closure on this week.  Bugs 274, 268, 286, and 114 are related to this.  

The above plan would slide the following efforts to the ns-3.3 release:  tags rework, IPv4 rework, IPv6 integration, ns-3-emu, and ns-3-simu support

If there are other pieces that people would like to see merged for ns-3.2, please suggest them now.

Thanks,
Tom




From hagen at jauu.net  Mon Aug 25 09:28:26 2008
From: hagen at jauu.net (Hagen Paul Pfeifer)
Date: Mon, 25 Aug 2008 18:28:26 +0200
Subject: [Ns-developers] Parallelization Progress - Status Update
Message-ID: <20080825162819.GB2411@nuttenaction>

This email mainly concern some specialized parallelization topics, therefore
especially George. I will drop a more generic overview, status in ~2 days when
I push my work upstream.

Some words to the real node versus ghost node handling (For your information
George, currently there is no difference in the implementation, only to
differs generator nodes from non-generator nodes. To strip down the code is up
for further releases):

Beside the solution selected in GTNetS where the scenario files are
influenced with the parallelization aspect, NS-3 should does this in a
different way. For example: if a application is added to an node in GTNetS the
return value indicates if the node is a real or ghost node. My solution
selected for NS-3 differs in that way, that you can always add applications to
an node - no matter if this node is a real or ghost. The difference is under
the hood: NS-3 concern these calls as no-ops if it is a ghost and therefore is
fully transparent for the user. No matter if the simulation is parallelized or
not!  Thats my upcoming approach.

GTNetS indicator if a node is ghost is a method called AddApplication(). These
method returns NULL in the case that this node is a ghost, or an pointer in
the case that this node is a real one (scheduled on the local CPU).

There are two challenges in this sector:

First one is that NS-3 allows the user to add/implement their own application
by open a socket for a node and interact directly with lower API (e.g. the
IP/TCP stack implementation). So no uniform "AddApplication" interface is
available. This makes it harder to implement the mentioned feature, because
several places must be touched. To illustrate this: it is fully legal to open
an socket on a ghost node (just for fun), but it is illegal to open this
socket for an active interplay (e.g. to write to the socket). 

Another problem is the time where I calculate the federate distribution.
Currently this is done shortly before the simulation starts. If we want to add
a logic like GTNetS we must do this at the start of the main program. But the
user can call/execute whatever he want before call some ns-3 related methods.
Also, he can call the methods in arbitrary order. So express this in other
words: the scenario file can add applications to nodes who are ghosts-nodes
and the simulation does not even know this at time n that this is a ghost
node. So we must add a additional method so that the user can trigger the
federate calculation at the start of the simulation.  GNetS does this via
"Simualtor s(id);". My suggestion is to add a additional method to trigger the
process to calculate the federates!

The problem is that I don't want to mess with the core logic of NS-3. I want
to prevent major changes in API/Simulation/... But this is an unavoidable
influence where I need information guaranteed before the first couple of
lines (except parseArg()).

To summarize:

I prefer to add an additional method which must be called when run in a
parallelized context: lets call them "ParallelInit()". This is what I do
today. The federate splitting is done in a manner like GTNetS now handles
Ghost (extract from my current scenario file):

  if (federate->isLocalNode(n1n2.Get (1))) {

    PacketSinkHelper sink ("ns3::TcpSocketFactory",
        InetSocketAddress (Ipv4Address::GetAny (), servPort));
    ApplicationContainer apps = sink.Install (n1n2.Get (1));
    apps.Start (Seconds (0.0));

  }


This is *really* similar to the approach GTNetS is doing this. But I will
replace this with a more user transparent version soon as described in the
beginning of this email.

George, do you have some free IRC-time in the next couple of days to clarify
some open questions regarding time synchronization issues? No matter what time
- I will be there!  ;)


Hagen



From mathieu.lacage at sophia.inria.fr  Mon Aug 25 11:56:22 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Mon, 25 Aug 2008 11:56:22 -0700
Subject: [Ns-developers] bridging and wifi
Message-ID: <1219690582.23368.48.camel@ns-test>

hi,

I started trying to implement wifi bridging so, I have, naturally, a
couple of questions. Here is the basic scenario I am trying to test:

  Lan      Wifi

 0  1  2 ********* 3
 |  |  |
 -------

Node 2 is bridging lan to wifi. Node 1 is generating traffic towards
Node 3 so, I expect that traffic to be transparently bridged from lan to
wifi. For simplicity, let's say that wifi network is adhoc. Let's go
through the scenario.

1) node 1 sends ARP request macsrc=mac1, macdst=broadcast on lan
2) node 2 receives ARP request, bridge learns that mac1 is located on
lan0, forwards broadcast to all interfaces, except incoming one.
3) node 2 sends wifi broadcast macsrc=mac1, macdst=broadcast
4) node 3 receives wifi broadcast, sees ARP request macsrc=mac1, sends
reply ARP reply (unicast), macsrc=mac4, macdst=mac1.
8) wifi device on node 3 sends unicast frame, waits for wifi ACK

The problem, here is that no one is ever going to generate the wifi ACK
for this unicast frame: node 2 will probably receive the ARP reply
correctly, forward it back to node 1 through the bridge, but it will
never be able to send a wifi ACK to node 3 because it has no idea that
it should do this. wifi ACKs are generated only for unicast frames
targetted at _oneself_ and node 2 does not know that it is the target of
the unicast frame because its own address is not equal to the
destination of the unicast frame.

At this point, I got a bit stomped and went back to some serious wifi
spec reading and thinking but I still don't really know how that is
expected to work. Gustavo, do you have any idea ?

Mathieu


From gjcarneiro at gmail.com  Mon Aug 25 13:48:35 2008
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Mon, 25 Aug 2008 21:48:35 +0100
Subject: [Ns-developers] bridging and wifi
In-Reply-To: <1219690582.23368.48.camel@ns-test>
References: <1219690582.23368.48.camel@ns-test>
Message-ID: <a467ca4f0808251348n6340bfd8wf5ca84027ad7fb5f@mail.gmail.com>

2008/8/25 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> hi,
>
> I started trying to implement wifi bridging so, I have, naturally, a
> couple of questions. Here is the basic scenario I am trying to test:
>
>  Lan      Wifi
>
>  0  1  2 ********* 3
>  |  |  |
>  -------
>
> Node 2 is bridging lan to wifi. Node 1 is generating traffic towards
> Node 3 so, I expect that traffic to be transparently bridged from lan to
> wifi.



> For simplicity, let's say that wifi network is adhoc.


This is an assumption with serious implications.  I don't think this would
ever work, conceptually, with wifi in adhoc mode because adhoc mode frames
only use two addresses.  It has to be in infrastructure mode, because then
frames have 3 addresses.


> Let's go
> through the scenario.
>
> 1) node 1 sends ARP request macsrc=mac1, macdst=broadcast on lan
> 2) node 2 receives ARP request, bridge learns that mac1 is located on
> lan0, forwards broadcast to all interfaces, except incoming one.
> 3) node 2 sends wifi broadcast macsrc=mac1, macdst=broadcast
> 4) node 3 receives wifi broadcast, sees ARP request macsrc=mac1, sends
> reply ARP reply (unicast), macsrc=mac4, macdst=mac1.
> 8) wifi device on node 3 sends unicast frame, waits for wifi ACK
>
> The problem, here is that no one is ever going to generate the wifi ACK
> for this unicast frame: node 2 will probably receive the ARP reply
> correctly, forward it back to node 1 through the bridge, but it will
> never be able to send a wifi ACK to node 3 because it has no idea that
> it should do this. wifi ACKs are generated only for unicast frames
> targetted at _oneself_ and node 2 does not know that it is the target of
> the unicast frame because its own address is not equal to the
> destination of the unicast frame.
>
> At this point, I got a bit stomped and went back to some serious wifi
> spec reading and thinking but I still don't really know how that is
> expected to work. Gustavo, do you have any idea ?


I think I have an idea.

As I mentioned before, wifi has to be in infrastructure mode, adhoc won't
work (incidentally trying to do bridging in Linux with cards in adhoc mode
is a mistake I often used to make in the past).

The 802.11 frame has a total of four addresses, which have the following
meaning in infrastructure mode (this table comes from somewhere deep in the
802.11 standard):


  /*
   *  To DS    From DS   Address 1    Address 2    Address 3    Address 4
   *----------------------------------------------------------------------
   *    0        0       Destination  Source        BSSID         N/A
   *    0        1       Destination  BSSID         Source        N/A
   *    1        0       BSSID        Source        Destination   N/A
   *    1        1       Receiver     Transmitter   Destination   Source
   */

The ARP response, as transmitted by node 3, is of the type ToDS=1, FromDS=0,
therefore Address 1 is the BSSID (AP netdevice MAC), Address 2 is mac3,
Address 3 is mac1, and Address 4 is not used.  The Access Point (node2) will
receive a frame whose BSSID is itself and so will send a Wifi ACK back to
the source (Address 2 == mac3).

At this point, the promiscuous receive callback in node2 will send back to
the BridgeNetDevice the original source and destination, i.e. Address 2 and
3.  Likewise, when the AP (node2) sends a frame being bridged from node 1 to
node 3, via the new SendFrom API, it should consider the ToDS=0, FromDS=1
line in the table above, and so in this example Address1=mac3,
Address2=mac2, Address3=mac1.

I hope this helps.

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

From mathieu.lacage at sophia.inria.fr  Mon Aug 25 13:58:25 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Mon, 25 Aug 2008 13:58:25 -0700
Subject: [Ns-developers] bridging and wifi
In-Reply-To: <a467ca4f0808251348n6340bfd8wf5ca84027ad7fb5f@mail.gmail.com>
References: <1219690582.23368.48.camel@ns-test>
	<a467ca4f0808251348n6340bfd8wf5ca84027ad7fb5f@mail.gmail.com>
Message-ID: <1219697905.23368.55.camel@ns-test>


On Mon, 2008-08-25 at 21:48 +0100, Gustavo Carneiro wrote:

 
>         For simplicity, let's say that wifi network is adhoc.
> 
> This is an assumption with serious implications.  I don't think this
> would ever work, conceptually, with wifi in adhoc mode because adhoc
> mode frames only use two addresses.  It has to be in infrastructure
> mode, because then frames have 3 addresses.

ok


>         At this point, I got a bit stomped and went back to some
>         serious wifi
>         spec reading and thinking but I still don't really know how
>         that is
>         expected to work. Gustavo, do you have any idea ?
> 
> I think I have an idea.
> 
> As I mentioned before, wifi has to be in infrastructure mode, adhoc
> won't work (incidentally trying to do bridging in Linux with cards in
> adhoc mode is a mistake I often used to make in the past).
> 
> The 802.11 frame has a total of four addresses, which have the
> following meaning in infrastructure mode (this table comes from
> somewhere deep in the 802.11 standard):
> 
> 
>   /*
>    *  To DS    From DS   Address 1    Address 2    Address 3
> Address 4 
> 
> *----------------------------------------------------------------------
>    *    0        0       Destination  Source        BSSID         N/A
>    *    0        1       Destination  BSSID         Source        N/A
>    *    1        0       BSSID        Source        Destination   N/A
>    *    1        1       Receiver     Transmitter   Destination
> Source
>    */
> 
> The ARP response, as transmitted by node 3, is of the type ToDS=1,
> FromDS=0, therefore Address 1 is the BSSID (AP netdevice MAC), Address
> 2 is mac3, Address 3 is mac1, and Address 4 is not used.  The Access
> Point (node2) will receive a frame whose BSSID is itself and so will
> send a Wifi ACK back to the source (Address 2 == mac3).

I more or less reached the same kind of conclusion here but, what
bothers me is that if I make node 3 be the AP and node 2 be a STA, it
won't work, right ?

> At this point, the promiscuous receive callback in node2 will send
> back to the BridgeNetDevice the original source and destination, i.e.
> Address 2 and 3.  Likewise, when the AP (node2) sends a frame being
> bridged from node 1 to node 3, via the new SendFrom API, it should
> consider the ToDS=0, FromDS=1 line in the table above, and so in this
> example Address1=mac3, Address2=mac2, Address3=mac1.



From gjcarneiro at gmail.com  Mon Aug 25 14:05:12 2008
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Mon, 25 Aug 2008 22:05:12 +0100
Subject: [Ns-developers] bridging and wifi
In-Reply-To: <1219697905.23368.55.camel@ns-test>
References: <1219690582.23368.48.camel@ns-test>
	<a467ca4f0808251348n6340bfd8wf5ca84027ad7fb5f@mail.gmail.com>
	<1219697905.23368.55.camel@ns-test>
Message-ID: <a467ca4f0808251405y665b9d1fwec3b9ca570e0ac3d@mail.gmail.com>

2008/8/25 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

>
> On Mon, 2008-08-25 at 21:48 +0100, Gustavo Carneiro wrote:
>
>
> >         For simplicity, let's say that wifi network is adhoc.
> >
> > This is an assumption with serious implications.  I don't think this
> > would ever work, conceptually, with wifi in adhoc mode because adhoc
> > mode frames only use two addresses.  It has to be in infrastructure
> > mode, because then frames have 3 addresses.
>
> ok
>
>
> >         At this point, I got a bit stomped and went back to some
> >         serious wifi
> >         spec reading and thinking but I still don't really know how
> >         that is
> >         expected to work. Gustavo, do you have any idea ?
> >
> > I think I have an idea.
> >
> > As I mentioned before, wifi has to be in infrastructure mode, adhoc
> > won't work (incidentally trying to do bridging in Linux with cards in
> > adhoc mode is a mistake I often used to make in the past).
> >
> > The 802.11 frame has a total of four addresses, which have the
> > following meaning in infrastructure mode (this table comes from
> > somewhere deep in the 802.11 standard):
> >
> >
> >   /*
> >    *  To DS    From DS   Address 1    Address 2    Address 3
> > Address 4
> >
> > *----------------------------------------------------------------------
> >    *    0        0       Destination  Source        BSSID         N/A
> >    *    0        1       Destination  BSSID         Source        N/A
> >    *    1        0       BSSID        Source        Destination   N/A
> >    *    1        1       Receiver     Transmitter   Destination
> > Source
> >    */
> >
> > The ARP response, as transmitted by node 3, is of the type ToDS=1,
> > FromDS=0, therefore Address 1 is the BSSID (AP netdevice MAC), Address
> > 2 is mac3, Address 3 is mac1, and Address 4 is not used.  The Access
> > Point (node2) will receive a frame whose BSSID is itself and so will
> > send a Wifi ACK back to the source (Address 2 == mac3).
>
> I more or less reached the same kind of conclusion here but, what
> bothers me is that if I make node 3 be the AP and node 2 be a STA, it
> won't work, right ?


Right, a wifi netdevice in STA mode cannot be part of bridging.  But it's
like this in real world... I never heard of a Wifi station doing bridging
before...

Luckily we don't have to try to make something better than real world. ;-)

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

From mathieu.lacage at sophia.inria.fr  Mon Aug 25 20:05:06 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Mon, 25 Aug 2008 20:05:06 -0700
Subject: [Ns-developers] ns-3.2 release planning
In-Reply-To: <W758677912101561219676846@mail.mailsnare.net>
References: <W758677912101561219676846@mail.mailsnare.net>
Message-ID: <1219719906.6069.2.camel@mathieu.inria.fr>

On Mon, 2008-08-25 at 15:07 +0000, Tom Henderson wrote:
> We are about due for another ns-3 release.  I'd like to suggest that
> we aim for wrapping up development and merging of new features for
> ns-3.2 by the end of the week, and post a release candidate around the
> end of the month, with a goal of making the release by mid-September.
> Craig has agreed to serve as release manager again.

So, 1), 2) and 3) should be merged before friday 29th. I would like to
make only 1) release critical which means that if 2) or 3) can't make it
on friday, it would be nice if we could proceed with the release anyway.

> Here are a few items that I think we should aim for this week:
> 
> 1) merge nsc; there are a few issues to deal with (final review of
> Florian's code, Sam to make a new nsc release, build system
> integration) but as we discussed on the list last week, we are
> probably close to being ready to merge this code 

I am willing to work on the build issues once the code is merged.

Mathieu


From tjkopena at cs.drexel.edu  Mon Aug 25 22:03:01 2008
From: tjkopena at cs.drexel.edu (Joseph Kopena)
Date: Mon, 25 Aug 2008 22:03:01 -0700
Subject: [Ns-developers] ns-3.2 release planning
In-Reply-To: <W758677912101561219676846@mail.mailsnare.net>
References: <W758677912101561219676846@mail.mailsnare.net>
Message-ID: <13786f330808252203i17416f79lffbf8343f80b1f4f@mail.gmail.com>

On Mon, Aug 25, 2008 at 8:07 AM, Tom Henderson <tomh at tomh.org> wrote:
> 2) move ns-3-stat to src/contrib:  the proposed statistics framework could be put into src/contrib for now to gather more feedback from users, and Joe agreed to try to work on this merge for this week

I played around with this for a little bit today & could not begin to
fathom the errors I was getting from waf.  I think they surpass gcc
for crypticness.  I will discuss with denizens of #ns-3 tomorrow.

Thx

-- 
- joe kopena
right here and now

From tomh at tomh.org  Mon Aug 25 22:23:08 2008
From: tomh at tomh.org (Tom Henderson)
Date: Mon, 25 Aug 2008 22:23:08 -0700
Subject: [Ns-developers] ns-3 nam support
In-Reply-To: <1219606106.8223.34.camel@mathieu>
References: <1219606106.8223.34.camel@mathieu>
Message-ID: <48B3933C.2000006@tomh.org>

Mathieu Lacage wrote:
> hi,
> 
> There were lots of question about nam support for ns-3 at the sigcomm
> demo: tom managed to convince me to take a shot at this and see what we
> could do. See http://code.nsnam.org/mathieu/ns-3-nam
> 
> src/contrib/nam-helper.h is the API and it seems to work reasonably well
> for point to point links.

About a month ago, Jeremy was asking about what trace file format that 
ns-3 could settle upon for use by iNSpect.  I'm wondering whether nam 
format could be extended or tweaked slightly for use by both tools.

Jeremy, what is the suitability of (possibly extended) nam trace formats 
for iNSpect?

Tom

From jnorman at mines.edu  Tue Aug 26 08:42:02 2008
From: jnorman at mines.edu (Jeremy)
Date: Tue, 26 Aug 2008 09:42:02 -0600
Subject: [Ns-developers] ns-3 nam support
In-Reply-To: <48B3933C.2000006@tomh.org>
References: <1219606106.8223.34.camel@mathieu> <48B3933C.2000006@tomh.org>
Message-ID: <9f8df64e0808260842v2e188047m1d00b5c5331d81af@mail.gmail.com>

Tom & Mathieu,

Based on the traces for nam in ns-2, I expect that making it possible for
iNSpect to handle these traces should be relatively minor. I doubt that any
extensions to the format would be very necessary even.

As far as I remember, the nam trace does not handle mobile nodes though. If
that is still correct, we would still need to figure out wireless. Maybe
simply extending nam to include wireless info (movement, etc) would be
enough.

Unfortunately, I personally wont be able to look into this specific issue
very deeply until next week. In the meantime, I will have someone start
looking into this (we have an iNSpect team again).

-Jeremy




On Mon, Aug 25, 2008 at 11:23 PM, Tom Henderson <tomh at tomh.org> wrote:

> Mathieu Lacage wrote:
>
>> hi,
>>
>> There were lots of question about nam support for ns-3 at the sigcomm
>> demo: tom managed to convince me to take a shot at this and see what we
>> could do. See http://code.nsnam.org/mathieu/ns-3-nam
>>
>> src/contrib/nam-helper.h is the API and it seems to work reasonably well
>> for point to point links.
>>
>
> About a month ago, Jeremy was asking about what trace file format that ns-3
> could settle upon for use by iNSpect.  I'm wondering whether nam format
> could be extended or tweaked slightly for use by both tools.
>
> Jeremy, what is the suitability of (possibly extended) nam trace formats
> for iNSpect?
>
> Tom
>



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

From mathieu.lacage at sophia.inria.fr  Tue Aug 26 08:45:51 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 26 Aug 2008 08:45:51 -0700
Subject: [Ns-developers] ns-3 nam support
In-Reply-To: <9f8df64e0808260842v2e188047m1d00b5c5331d81af@mail.gmail.com>
References: <1219606106.8223.34.camel@mathieu> <48B3933C.2000006@tomh.org>
	<9f8df64e0808260842v2e188047m1d00b5c5331d81af@mail.gmail.com>
Message-ID: <1219765551.5069.6.camel@ns-test>


On Tue, 2008-08-26 at 09:42 -0600, Jeremy wrote:

> As far as I remember, the nam trace does not handle mobile nodes
> though. If that is still correct, we would still need to figure out
> wireless. Maybe simply extending nam to include wireless info
> (movement, etc) would be enough. 

nam can already display moving nodes with specific positions and the
file format supports this. nam seems to have serious trouble displaying
mixed topologies (wireless+wired, wired+lan, etc.) though.

Mathieu


From jnorman at mines.edu  Tue Aug 26 08:52:23 2008
From: jnorman at mines.edu (Jeremy)
Date: Tue, 26 Aug 2008 09:52:23 -0600
Subject: [Ns-developers] ns-3 nam support
In-Reply-To: <1219765551.5069.6.camel@ns-test>
References: <1219606106.8223.34.camel@mathieu> <48B3933C.2000006@tomh.org>
	<9f8df64e0808260842v2e188047m1d00b5c5331d81af@mail.gmail.com>
	<1219765551.5069.6.camel@ns-test>
Message-ID: <9f8df64e0808260852m47cdceek662c8676bdfe3a25@mail.gmail.com>

I did not know that, actually.

So if all of that information is already there, then we should have no
problem integrating it into iNSpect.

One of the main goals we originally had with releasing this new version of
iNSpect was to allow mixed topologies, so this would be a great thing to
work on.  Do you, by chance, have any nam traces that include both wired and
wireless or other mixed topologies so we can test this during our nam-trace
implementation?

Jeremy Norman
The Toilers Research Group
Colorado School of Mines
Golden, Colorado, United States



On Tue, Aug 26, 2008 at 9:45 AM, Mathieu Lacage <
mathieu.lacage at sophia.inria.fr> wrote:

>
> On Tue, 2008-08-26 at 09:42 -0600, Jeremy wrote:
>
> > As far as I remember, the nam trace does not handle mobile nodes
> > though. If that is still correct, we would still need to figure out
> > wireless. Maybe simply extending nam to include wireless info
> > (movement, etc) would be enough.
>
> nam can already display moving nodes with specific positions and the
> file format supports this. nam seems to have serious trouble displaying
> mixed topologies (wireless+wired, wired+lan, etc.) though.
>
> Mathieu
>
>

From mathieu.lacage at sophia.inria.fr  Tue Aug 26 08:56:16 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Tue, 26 Aug 2008 08:56:16 -0700
Subject: [Ns-developers] ns-3 nam support
In-Reply-To: <9f8df64e0808260852m47cdceek662c8676bdfe3a25@mail.gmail.com>
References: <1219606106.8223.34.camel@mathieu> <48B3933C.2000006@tomh.org>
	<9f8df64e0808260842v2e188047m1d00b5c5331d81af@mail.gmail.com>
	<1219765551.5069.6.camel@ns-test>
	<9f8df64e0808260852m47cdceek662c8676bdfe3a25@mail.gmail.com>
Message-ID: <1219766176.5069.9.camel@ns-test>


On Tue, 2008-08-26 at 09:52 -0600, Jeremy wrote:

> One of the main goals we originally had with releasing this new
> version of iNSpect was to allow mixed topologies, so this would be a
> great thing to work on.  Do you, by chance, have any nam traces that
> include both wired and wireless or other mixed topologies so we can
> test this during our nam-trace implementation?

I don't have any offhand but I will try to add wireless support to the
ns-3 nam generation. I don't think you can generate one of these with
ns-2 though which is probably why nam sucks so hard.

regards,
Mathieu


From sam.jansen at gmail.com  Tue Aug 26 11:44:42 2008
From: sam.jansen at gmail.com (Sam Jansen)
Date: Tue, 26 Aug 2008 11:44:42 -0700
Subject: [Ns-developers] Network Simulation Cradle 0.4.0 released
Message-ID: <8d28ecc50808261144h1cecb334n9019686862b12d6@mail.gmail.com>

The Network Simulation Cradle version 0.4.0 has now been released. The
download is in the usual place:

	http://research.wand.net.nz/software/nsc.php

NSC is a project that allows real world TCP/IP stacks to be used in
simulation. More information can be found at
http://www.wand.net.nz/~stj2/nsc/.

This version is a major release including all the changes from the Google
Summer of Code project: Linux 2.6.26 support, 64-bit support for the Linux
stacks, a new and improved globaliser, better error reporting and sysctl
support and many other features and bugfixes.

This is the first version intended to be used with the ns-3 network simulator,
though ns-2 is still supported.

Thanks goes to Florian Westphal for his hard work in improving the NSC to allow
better integration into ns-3.

-- 
Sam Jansen <sam.jansen at gmail.com>
WAND Network Research Group and Google.

From lucaanchora at virgilio.it  Wed Aug 27 07:04:19 2008
From: lucaanchora at virgilio.it (lucaanchora@virgilio.it)
Date: Wed, 27 Aug 2008 15:04:19 +0100 (GMT+01:00)
Subject: [Ns-developers] [NS-Developers] Bug in ns-2.33 mac-802_11Ext
Message-ID: <11c047aaa2b.lucaanchora@virgilio.it>

Hi all,
I am using ns-2.33 for some simulations in a vehicular 
environment. The
MAC I am using is mac-802_11Ext and the PHY layer is 
wireless-phyExt.
While running a simple simulation of 50 seconds with a 
50 nodes scenario,
I have noticed that the memory usage of my laptop 
(1GB RAM) grown 
until 40%. I have conducted a profiling activity using 
valgrind tool and I
have noticed that in Mac802_11Ext and TXC classes 
there is a problem
of memory deallocation: for BROADCAST transmissions 
the sender keeps
a pointer to the pkt just sent (TXC::pDATA field) and 
never deallocate it, even
when the PHY layer notifies the MAC that the 
transmission si done (by calling
the function handleTXEndIndication()). 
I put the instruction 
Packet::free(pDATA);
in the function void TXC::
handleTXConfirm() just before the instruction
mac_->bkmgr.handleBKStart
(mac_->cw_);
to address the problem and I have obtained no errors and a 
reduction of
the  memory usage.

Do you think this is a real problem, 
or am I wrong??

Bye
Luca Anchora

From tomh at tomh.org  Wed Aug 27 09:57:15 2008
From: tomh at tomh.org (Tom Henderson)
Date: Wed, 27 Aug 2008 16:57:15 +0000
Subject: [Ns-developers] web server is down
Message-ID: <W5616121216215301219856235@mail.mailsnare.net>

FYI, we're having some problems with the web server this morning (also bugzilla, wiki) and will get it restored as soon as possible.

Tom



From raj.b at gatech.edu  Wed Aug 27 11:04:52 2008
From: raj.b at gatech.edu (Raj Bhattacharjea)
Date: Wed, 27 Aug 2008 14:04:52 -0400
Subject: [Ns-developers] web server is down
In-Reply-To: <W5616121216215301219856235@mail.mailsnare.net>
References: <W5616121216215301219856235@mail.mailsnare.net>
Message-ID: <12d69e490808271104s7bb0070am3bcbc3bff9023fc2@mail.gmail.com>

As an update, the problem is being worked on right now.  I expect the
server will be back up within the next several hours.

-- 
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
Ph.D. Candidate
Systems Analyst
404.894.2955

From raj.b at gatech.edu  Wed Aug 27 12:11:36 2008
From: raj.b at gatech.edu (Raj Bhattacharjea)
Date: Wed, 27 Aug 2008 15:11:36 -0400
Subject: [Ns-developers] web server is down
In-Reply-To: <12d69e490808271104s7bb0070am3bcbc3bff9023fc2@mail.gmail.com>
References: <W5616121216215301219856235@mail.mailsnare.net>
	<12d69e490808271104s7bb0070am3bcbc3bff9023fc2@mail.gmail.com>
Message-ID: <12d69e490808271211i4e32d22fx586ba6a73682edff@mail.gmail.com>

There we are, www.nsnam.org is back up and operational.

On Wed, Aug 27, 2008 at 2:04 PM, Raj Bhattacharjea <raj.b at gatech.edu> wrote:
> As an update, the problem is being worked on right now.  I expect the
> server will be back up within the next several hours.
>
> --
> Raj Bhattacharjea
> Georgia Institute of Technology
> School of Electrical and Computer Engineering
> Ph.D. Candidate
> Systems Analyst
> 404.894.2955
>



-- 
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
Ph.D. Candidate
Systems Analyst
404.894.2955

From raj.b at gatech.edu  Wed Aug 27 14:20:42 2008
From: raj.b at gatech.edu (Raj Bhattacharjea)
Date: Wed, 27 Aug 2008 17:20:42 -0400
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <12d69e490808271352w16de4f4ck7fcdce17acb3d2b0@mail.gmail.com>
References: <1218831019.31409.23.camel@ns-test>
	<20080817103401.GC15575@Chamillionaire.breakpoint.cc>
	<1219428574.5979.12.camel@ns-test> <48AF0F76.7010702@tomh.org>
	<20080822203652.GN26806@Chamillionaire.breakpoint.cc>
	<12d69e490808271352w16de4f4ck7fcdce17acb3d2b0@mail.gmail.com>
Message-ID: <12d69e490808271420r6b8665bajde22b325b29382a9@mail.gmail.com>

On Fri, Aug 22, 2008 at 4:36 PM, Florian Westphal <fw at strlen.de> wrote:
>
> Here is everything in a single patch:
> http://www.strlen.de/cradle/ns-3-nsc-aug-22-2008.diff
>
> It should apply cleanly to current ns-3-dev tip.

It does, and it looks good.  Nothing is a blocker here, but here are
the few small things I see that should be added soon after merging.

InternetStackHelper::SetTcpDefaultType needs documentation.

The two new examples need to have the modeline, gpl, and scenario
description block at the top.

It would be nice if the examples had really copious comments
describing what every few lines was accomplishing.

Maybe you should add your name to the author's list as well for the
files that you significantly touched, but I'm not sure about the rules
on this.

Thanks Florian for all your hard work on NSC over the summer.
--
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
Ph.D. Candidate
Systems Analyst
404.894.2955

From raj.b at gatech.edu  Wed Aug 27 14:49:54 2008
From: raj.b at gatech.edu (Raj Bhattacharjea)
Date: Wed, 27 Aug 2008 17:49:54 -0400
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <20080822203652.GN26806@Chamillionaire.breakpoint.cc>
References: <1218831019.31409.23.camel@ns-test>
	<20080817103401.GC15575@Chamillionaire.breakpoint.cc>
	<1219428574.5979.12.camel@ns-test> <48AF0F76.7010702@tomh.org>
	<20080822203652.GN26806@Chamillionaire.breakpoint.cc>
Message-ID: <12d69e490808271449o6f114224hd0ca3203703a52bf@mail.gmail.com>

There is also a subtle doxygen bug I just noticed in
nsc-tcp-socket-factory-impl.h:26

It redefines the doxygen Tcp group.  The end result is that the
doxygen claims the GTNetS port lives in NscTcpSocketImpl.  I believe
you can remove this defgroup section entirely.

On Fri, Aug 22, 2008 at 4:36 PM, Florian Westphal <fw at strlen.de> wrote:
> Tom Henderson <tomh at tomh.org> wrote:
>> Mathieu Lacage wrote:
>>> On Sun, 2008-08-17 at 12:34 +0200, Florian Westphal wrote:
>>> I did a final review of the code and sent you a couple of comments
>>> privately by email. Modulo a couple of very minor details, the code
>>> looks good for merging to me so, feel free to try to push to ns-3-dev
>>> when you are ready.
>>
>> It would be nice to try to resolve (or log into the tracker) the issues
>> quickly if possible so that it could be merged next week.  Raj, can you
>> please review as well?
>
> Here is everything in a single patch:
> http://www.strlen.de/cradle/ns-3-nsc-aug-22-2008.diff
>
> It should apply cleanly to current ns-3-dev tip.
>
>> Also, do the regression and unit test suites need a flag to remember
>> whether nsc has been enabled?
>
> No, i removed all the nsc changes to the standard examples.
> If they look different when nsc is enabled, its a bug.
>
>> Regarding the merge of code like this, where someone has been working on a
>> project for many months with a long change history, should we be merging
>> repos with full change history or just producing a final patch that is
>> merged to ns-3-dev?  Is it author's discretion whether or not to keep
>> forever the private change history?
>
> I already dumped some of the early changesets because I found it annoying
> to look through a large history and you see dozens of back-and-forth
> commits and reverts. So, personally I'd prefer to have a single commit,
> or, if such a large commit is frowned upon, one larger patch that adds
> the core files and another patch on top which adds the rest (wscript,
> glue code to existing files).
>
> Thanks to all reviewers for spending their time on this,
>       Florian
>
> Oh, by the way, I'll be offline next week. I'll work on any problems
> and issues that may come up as soon as I get back.
>



-- 
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
Ph.D. Candidate
Systems Analyst
404.894.2955

From gjcarneiro at gmail.com  Thu Aug 28 04:59:39 2008
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Thu, 28 Aug 2008 12:59:39 +0100
Subject: [Ns-developers] What's wrong with pybindgen in Cygwin?
In-Reply-To: <9195f1790808280212q7d243b9aib5b1d589951287de@mail.gmail.com>
References: <9195f1790808280212q7d243b9aib5b1d589951287de@mail.gmail.com>
Message-ID: <a467ca4f0808280459h34dda5b9qa02fcf7e6dab0536@mail.gmail.com>

I don't have cygwin installed, but I couldn't reproduce with mingw / g++
3.4.5.

Can you send me the file build/debug/bindings/python/ns3_module_common.cc
(possibly compressed)?  It might help me discover the problem...

Also, this is basically a bug report, bugzilla.nsnam.org is a better place
to submit bug reports.

2008/8/28 Weng Gavin <gavinweng at gmail.com>

> With the new rev 564 of pybindgen in Cygwin(Python 2.5.1), the errors are
> listed as following:
>
> [456/509] cxx: build/debug/bindings/python/ns3_module_common.cc ->
> build/debug/bindings/python/ns3_module_common_3.o
> debug/bindings/python/ns3_module_common.cc: In function `PyObject*
> _wrap_PyNs3ListErrorModel_GetList(PyNs3ListErrorModel*)':
> debug/bindings/python/ns3_module_common.cc:5571: error: no match for
> 'operator=' in 'retval = ns3::ListErrorModel::GetList() const()'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/list.tcc:121: note:
> candidates are: std::list<_Tp, _Alloc>& std::list<_Tp,
> _Alloc>::operator=(const std::list<_Tp, _Alloc>&) [with _Tp = unsigned int,
> _Alloc = std::allocator<unsigned int>]
> debug/bindings/python/ns3_module_common.cc: In function `PyObject*
> _wrap_PyNs3ListErrorModel_SetList(PyNs3ListErrorModel*, PyObject*,
> PyObject*)':
> debug/bindings/python/ns3_module_common.cc:5589: error: no matching
> function for call to `ns3::ListErrorModel::SetList(std::list<unsigned int,
> std::allocator<unsigned int> >&)'
> debug/ns3/error-model.h:215: note: candidates are: void
> ns3::ListErrorModel::SetList(const std::list<uint32_t,
> std::allocator<uint32_t> >&)
> Build failed
>  -> task failed (err #129):
> [bld:///cygdrive/d/Study/WirelessCommunication/NS-3/
> repos/ns-3-dev/bindings/python/ns3_module_common_3.o]
>
> How to solve it?
>
> Best wishes & kind regards from yours sincerely,
> Gavin Weng
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "ns-3-users" group.
> To post to this group, send email to ns-3-users at googlegroups.com
> To unsubscribe from this group, send email to
> ns-3-users+unsubscribe at googlegroups.com<ns-3-users%2Bunsubscribe at googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/ns-3-users?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>


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

From ali.hamidian at eit.lth.se  Thu Aug 28 05:01:38 2008
From: ali.hamidian at eit.lth.se (Ali Hamidian)
Date: Thu, 28 Aug 2008 14:01:38 +0200
Subject: [Ns-developers] Possible bug
Message-ID: <48B693A2.9090106@eit.lth.se>

Hi,

I think there is a bug in ns-2, which can be solved in aodv.cc. In 
AODV::recv, generated packets add the size of an IP header: ch->size() 
+= IP_HDR_LEN. But if the generated packet is a TCP segment, the IP 
header has already been added in tcp.cc (tcpip_base_hdr_size_ = 40). So 
the bug will result in TCP packets being 20 B larger than they should 
be, i.e., first TCP will add 40 B for TCP and IP headers, and then AODV 
will add 20 B for IP header. Moreover, I remember from the past that 
this bug gives an error message when tcp-full.cc is used (e.g., by 
webcache). To solve this in an easy way, in aodv.cc we should add the IP 
header only if the packet is not PT_TCP or PT_ACK. See the attached file.

Kind regards,
Ali


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: aodvBugFix
Url: http://mailman.isi.edu/pipermail/ns-developers/attachments/20080828/f9da7162/aodvBugFix.ksh

From tomh at tomh.org  Thu Aug 28 06:08:13 2008
From: tomh at tomh.org (Tom Henderson)
Date: Thu, 28 Aug 2008 06:08:13 -0700
Subject: [Ns-developers] Possible bug
In-Reply-To: <48B693A2.9090106@eit.lth.se>
References: <48B693A2.9090106@eit.lth.se>
Message-ID: <48B6A33D.1090309@tomh.org>

Ali Hamidian wrote:
> Hi,
> 
> I think there is a bug in ns-2, which can be solved in aodv.cc. In 
> AODV::recv, generated packets add the size of an IP header: ch->size() 
> += IP_HDR_LEN. But if the generated packet is a TCP segment, the IP 
> header has already been added in tcp.cc (tcpip_base_hdr_size_ = 40). So 
> the bug will result in TCP packets being 20 B larger than they should 
> be, i.e., first TCP will add 40 B for TCP and IP headers, and then AODV 
> will add 20 B for IP header. Moreover, I remember from the past that 
> this bug gives an error message when tcp-full.cc is used (e.g., by 
> webcache). To solve this in an easy way, in aodv.cc we should add the IP 
> header only if the packet is not PT_TCP or PT_ACK. See the attached file.
> 
> Kind regards,
> Ali
> 
> 

Ali,
I added it to the tracker.  If there are no other comments, I'll apply 
it before the next release.

Tom

From tomh at tomh.org  Thu Aug 28 06:47:50 2008
From: tomh at tomh.org (Tom Henderson)
Date: Thu, 28 Aug 2008 06:47:50 -0700
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <20080822203652.GN26806@Chamillionaire.breakpoint.cc>
References: <1218831019.31409.23.camel@ns-test>
	<20080817103401.GC15575@Chamillionaire.breakpoint.cc>
	<1219428574.5979.12.camel@ns-test> <48AF0F76.7010702@tomh.org>
	<20080822203652.GN26806@Chamillionaire.breakpoint.cc>
Message-ID: <48B6AC86.1010401@tomh.org>

Florian Westphal wrote:
> Tom Henderson <tomh at tomh.org> wrote:
>> Mathieu Lacage wrote:
>>> On Sun, 2008-08-17 at 12:34 +0200, Florian Westphal wrote:
>>> I did a final review of the code and sent you a couple of comments
>>> privately by email. Modulo a couple of very minor details, the code
>>> looks good for merging to me so, feel free to try to push to ns-3-dev
>>> when you are ready.
>> It would be nice to try to resolve (or log into the tracker) the issues 
>> quickly if possible so that it could be merged next week.  Raj, can you 
>> please review as well?
> 
> Here is everything in a single patch:
> http://www.strlen.de/cradle/ns-3-nsc-aug-22-2008.diff
> 

Florian, here are a few issues that will need to be dealt with during or 
shortly after the merge:

- the code regarding add_default_gateway() is not clean and should be 
added to the tracker as a bug when the merge occurs, if not fixed before 
then

- we need to figure out how to control, in general, the handling of 
compilation options in our unit tests and regression suite (I already 
mentioned this), and we need a unit test or regression test added.  For 
instance, since the available nsc stacks are platform-dependent, I 
wonder what we will check in regression tests (a known-good stack that 
works in all environments, only?)

- some doxygen is missing (e.g., InternetStackHelper::SetTcpDefault())

- it would help to have a chapter in the manual and some words in the 
tutorial about NSC.  The "README.nsc" should migrate somewhere else.

- please remember to modify CHANGES.html and RELEASE_NOTES when you merge.

Otherwise, looks good to me.  Nice job on this project.

Tom

From gavinweng at gmail.com  Thu Aug 28 02:12:08 2008
From: gavinweng at gmail.com (Weng Gavin)
Date: Thu, 28 Aug 2008 17:12:08 +0800
Subject: [Ns-developers] What's wrong with pybindgen in Cygwin?
Message-ID: <9195f1790808280212q7d243b9aib5b1d589951287de@mail.gmail.com>

With the new rev 564 of pybindgen in Cygwin(Python 2.5.1), the errors are
listed as following:

[456/509] cxx: build/debug/bindings/python/ns3_module_common.cc ->
build/debug/bindings/python/ns3_module_common_3.o
debug/bindings/python/ns3_module_common.cc: In function `PyObject*
_wrap_PyNs3ListErrorModel_GetList(PyNs3ListErrorModel*)':
debug/bindings/python/ns3_module_common.cc:5571: error: no match for
'operator=' in 'retval = ns3::ListErrorModel::GetList() const()'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/list.tcc:121: note:
candidates are: std::list<_Tp, _Alloc>& std::list<_Tp,
_Alloc>::operator=(const std::list<_Tp, _Alloc>&) [with _Tp = unsigned int,
_Alloc = std::allocator<unsigned int>]
debug/bindings/python/ns3_module_common.cc: In function `PyObject*
_wrap_PyNs3ListErrorModel_SetList(PyNs3ListErrorModel*, PyObject*,
PyObject*)':
debug/bindings/python/ns3_module_common.cc:5589: error: no matching function
for call to `ns3::ListErrorModel::SetList(std::list<unsigned int,
std::allocator<unsigned int> >&)'
debug/ns3/error-model.h:215: note: candidates are: void
ns3::ListErrorModel::SetList(const std::list<uint32_t,
std::allocator<uint32_t> >&)
Build failed
 -> task failed (err #129):
[bld:///cygdrive/d/Study/WirelessCommunication/NS-3/
repos/ns-3-dev/bindings/python/ns3_module_common_3.o]

How to solve it?

Best wishes & kind regards from yours sincerely,
Gavin Weng

From fw at strlen.de  Fri Aug 29 02:41:04 2008
From: fw at strlen.de (Florian Westphal)
Date: Fri, 29 Aug 2008 11:41:04 +0200
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <12d69e490808271420r6b8665bajde22b325b29382a9@mail.gmail.com>
References: <1218831019.31409.23.camel@ns-test>
	<20080817103401.GC15575@Chamillionaire.breakpoint.cc>
	<1219428574.5979.12.camel@ns-test> <48AF0F76.7010702@tomh.org>
	<20080822203652.GN26806@Chamillionaire.breakpoint.cc>
	<12d69e490808271352w16de4f4ck7fcdce17acb3d2b0@mail.gmail.com>
	<12d69e490808271420r6b8665bajde22b325b29382a9@mail.gmail.com>
Message-ID: <20080829094104.GQ26806@Chamillionaire.breakpoint.cc>

Raj Bhattacharjea <raj.b at gatech.edu> wrote:
> It does, and it looks good.  Nothing is a blocker here, but here are
> the few small things I see that should be added soon after merging.
> 
> InternetStackHelper::SetTcpDefaultType needs documentation.

Hrm, i'm more inclined to remove that method.
Its equivalent to 'SetNscStack("")'. The idea was that there
should be a method to essentially 'disable' NSC and have
the internet stack helper assign the ns-3s TCP model again, like this:

InternetStackHelper internet;
internet.SetNscStack("liblinux2.6.18.so");
internet.Install (nscNodes); // this creates nsc nodes
internet.SetNscStack("");
internet.Install (ns3TcpNodes); // this creates 'normal' ns-3 nodes

> The two new examples need to have the modeline, gpl, and scenario
> description block at the top.
> It would be nice if the examples had really copious comments
> describing what every few lines was accomplishing.

http://code.nsnam.org/fw/ns-3-nsc/rev/3b139bbd751b
http://code.nsnam.org/fw/ns-3-nsc/rev/ddcbdad7b407

Thanks for reviewing,
       Florian

From fw at strlen.de  Fri Aug 29 02:41:57 2008
From: fw at strlen.de (Florian Westphal)
Date: Fri, 29 Aug 2008 11:41:57 +0200
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <48B6AC86.1010401@tomh.org>
References: <1218831019.31409.23.camel@ns-test>
	<20080817103401.GC15575@Chamillionaire.breakpoint.cc>
	<1219428574.5979.12.camel@ns-test> <48AF0F76.7010702@tomh.org>
	<20080822203652.GN26806@Chamillionaire.breakpoint.cc>
	<48B6AC86.1010401@tomh.org>
Message-ID: <20080829094157.GA26009@Chamillionaire.breakpoint.cc>

Tom Henderson <tomh at tomh.org> wrote:
> Florian Westphal wrote:
>> Here is everything in a single patch:
>> http://www.strlen.de/cradle/ns-3-nsc-aug-22-2008.diff
>
> Florian, here are a few issues that will need to be dealt with during or 
> shortly after the merge:
>
> - the code regarding add_default_gateway() is not clean and should be added 
> to the tracker as a bug when the merge occurs, if not fixed before then

No disagreement here, but I'm not sure what the _right_ solution is.
Any ideas?

> - we need to figure out how to control, in general, the handling of 
> compilation options in our unit tests and regression suite (I already 
> mentioned this), and we need a unit test or regression test added.  For 
> instance, since the available nsc stacks are platform-dependent, I wonder 
> what we will check in regression tests (a known-good stack that works in 
> all environments, only?)

nsc doesn't change the behaviour of the ns-3 example files.
What do you want me to do?
As for the nsc stacks, the main problem is that the Linux stacks
that work on both x86 and x86_64 generate different pcap traces
depending on the host architecture (for instance, it will pick different TCP
source ports on x86 vs. _64).

> - some doxygen is missing (e.g., InternetStackHelper::SetTcpDefault())

See my reply to Raj, i think that method should go.
I'll walk through things again and will try to add missing docs for any
methods i have added.

> - it would help to have a chapter in the manual and some words in the 
> tutorial about NSC.  The "README.nsc" should migrate somewhere else.

Where exactly should README.nsc go? Should it move to the wiki instead?
I could try to move contents from the ns-3-nsc wiki page to the manual,
if that is deemed acceptable. 

> - please remember to modify CHANGES.html and RELEASE_NOTES when you merge.

Will do, thanks.
Regards, Florian

From gjcarneiro at gmail.com  Fri Aug 29 07:02:13 2008
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Fri, 29 Aug 2008 15:02:13 +0100
Subject: [Ns-developers] Containers (Was: What's wrong with pybindgen in
	Cygwin?)
Message-ID: <a467ca4f0808290702o12ae17bavcc1ad0a8637c9810@mail.gmail.com>

2008/8/28 Gustavo Carneiro <gjcarneiro at gmail.com>

>
>
> 2008/8/28 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>
>
>>
>> On Thu, 2008-08-28 at 09:34 -0700, Mathieu Lacage wrote:
>>
>> > interesting. It looks like the bug is in gccxml or pybindgen usage of
>> > gccxml: uint32_t should not be converted to unsigned int: you should be
>> > able to detect that you have a typedef here and use the outer typedef
>> > rather than the underlying type.
>>
>> I failed to explain why I think this is a bug in gccxml or pybindgen. If
>> you do what you do right now, what happens is that the typedefs are
>> effectively cast in stone when ./waf --python-scan is run which means
>> that we can't store in our repo the output of ./waf --python-scan
>> because all these typedefs are platform-specific and can all differ
>> subtly from platform to platform.
>>
>
> I agree 100% with you.  However, I am not sure I can fix it.  Further
> investigation lead me to believe this is a bug in gccxml itself.  I reported
> it [1] and await to see what the maintainer thinks.
>
>
> [1] http://www.gccxml.org/Bug/view.php?id=7572
>
>
>>
>>
>> So, the alternatives are either we make ./waf --python-scan not use the
>> underlying types but use the typedef
>
>
> Like I said, nothing I can do in pybindgen side.  All we can hope for right
> now is to force pybindgen to ignore the container types for now, so that at
> least people can build ns-3.
>

OK, I committed what should fix the problem.  The only solution I could come
up with is to ignore unnamed containers and only include typedef'ed
containers.

So basically Python bindings will not be able to use this API (Ipv4Route):

  /**
   * \return A vector of all of the output interfaces of this route.
   */
  std::vector<uint32_t> GetOutputInterfaces (void) const;

But if we do this instead, then it will work:

  typedef std::vector<uint32_t> InterfaceList;
  /**
   * \return A vector of all of the output interfaces of this route.
   */
  InterfaceList GetOutputInterfaces (void) const;


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

From mathieu.lacage at sophia.inria.fr  Fri Aug 29 10:45:06 2008
From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage)
Date: Fri, 29 Aug 2008 10:45:06 -0700
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <20080829094157.GA26009@Chamillionaire.breakpoint.cc>
References: <1218831019.31409.23.camel@ns-test>
	<20080817103401.GC15575@Chamillionaire.breakpoint.cc>
	<1219428574.5979.12.camel@ns-test> <48AF0F76.7010702@tomh.org>
	<20080822203652.GN26806@Chamillionaire.breakpoint.cc>
	<48B6AC86.1010401@tomh.org>
	<20080829094157.GA26009@Chamillionaire.breakpoint.cc>
Message-ID: <1220031906.26600.145.camel@ns-test>


On Fri, 2008-08-29 at 11:41 +0200, Florian Westphal wrote:

> As for the nsc stacks, the main problem is that the Linux stacks
> that work on both x86 and x86_64 generate different pcap traces
> depending on the host architecture (for instance, it will pick different TCP
> source ports on x86 vs. _64).

oh ? Would you care to elaborate ?

Mathieu


From fw at strlen.de  Fri Aug 29 13:51:56 2008
From: fw at strlen.de (Florian Westphal)
Date: Fri, 29 Aug 2008 22:51:56 +0200
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <1220031906.26600.145.camel@ns-test>
References: <1218831019.31409.23.camel@ns-test>
	<20080817103401.GC15575@Chamillionaire.breakpoint.cc>
	<1219428574.5979.12.camel@ns-test> <48AF0F76.7010702@tomh.org>
	<20080822203652.GN26806@Chamillionaire.breakpoint.cc>
	<48B6AC86.1010401@tomh.org>
	<20080829094157.GA26009@Chamillionaire.breakpoint.cc>
	<1220031906.26600.145.camel@ns-test>
Message-ID: <20080829205156.GU26806@Chamillionaire.breakpoint.cc>

Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
> > As for the nsc stacks, the main problem is that the Linux stacks
> > that work on both x86 and x86_64 generate different pcap traces
> > depending on the host architecture (for instance, it will pick different TCP
> > source ports on x86 vs. _64).
> 
> oh ? Would you care to elaborate ?

Sorry, I havn't investigated why its different.
On 2nd glance, the port numbers are the same on 2.6.26 32 and 64 bit
kernels, but differ on 2.6.18 32 vs. 64 bit builds.

Traces are different in any case, e.g. with 2.6.26 the first 100 packets
or so are the same, but then you'll see the push flag set in one of the
traces. (i ran them through tcpdump -r and diff'd the output).

I've put up the traces i get on my box (x86) and on ns-test (x86-64)
here:
http://strlen.de/cradle/trace_32_64/
(please fetch the .bz2 ones; the uncompressed pcaps are for those
that want to take a look at the traces but don't have the bunzip2
unpacker)

I'll see if I can find the cause of this.

Florian

From sam.jansen at gmail.com  Fri Aug 29 14:00:05 2008
From: sam.jansen at gmail.com (Sam Jansen)
Date: Fri, 29 Aug 2008 14:00:05 -0700
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <20080829205156.GU26806@Chamillionaire.breakpoint.cc>
References: <1218831019.31409.23.camel@ns-test>
	<20080817103401.GC15575@Chamillionaire.breakpoint.cc>
	<1219428574.5979.12.camel@ns-test> <48AF0F76.7010702@tomh.org>
	<20080822203652.GN26806@Chamillionaire.breakpoint.cc>
	<48B6AC86.1010401@tomh.org>
	<20080829094157.GA26009@Chamillionaire.breakpoint.cc>
	<1220031906.26600.145.camel@ns-test>
	<20080829205156.GU26806@Chamillionaire.breakpoint.cc>
Message-ID: <8d28ecc50808291400x536ae7a9m903f8630152900f4@mail.gmail.com>

Yes, we need to understand this and fix if possible. I've had
validation of the 64-bit effort on my TODO list for a long time but
haven't got around to it.

There isn't anything obviously wrong; 64-bit runs fine and produces
good-looking results, but there is something subtle creating some
differences that we need to understand. I was planning on doing this
in the next 2 weeks at the absolute latest.

2008/8/29 Florian Westphal <fw at strlen.de>:
> Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>> > As for the nsc stacks, the main problem is that the Linux stacks
>> > that work on both x86 and x86_64 generate different pcap traces
>> > depending on the host architecture (for instance, it will pick different TCP
>> > source ports on x86 vs. _64).
>>
>> oh ? Would you care to elaborate ?
>
> Sorry, I havn't investigated why its different.
> On 2nd glance, the port numbers are the same on 2.6.26 32 and 64 bit
> kernels, but differ on 2.6.18 32 vs. 64 bit builds.
>
> Traces are different in any case, e.g. with 2.6.26 the first 100 packets
> or so are the same, but then you'll see the push flag set in one of the
> traces. (i ran them through tcpdump -r and diff'd the output).
>
> I've put up the traces i get on my box (x86) and on ns-test (x86-64)
> here:
> http://strlen.de/cradle/trace_32_64/
> (please fetch the .bz2 ones; the uncompressed pcaps are for those
> that want to take a look at the traces but don't have the bunzip2
> unpacker)
>
> I'll see if I can find the cause of this.
>
> Florian
>

From tomh at tomh.org  Sat Aug 30 14:46:28 2008
From: tomh at tomh.org (Tom Henderson)
Date: Sat, 30 Aug 2008 14:46:28 -0700
Subject: [Ns-developers] gsoc wrapup
In-Reply-To: <20080829094157.GA26009@Chamillionaire.breakpoint.cc>
References: <1218831019.31409.23.camel@ns-test>
	<20080817103401.GC15575@Chamillionaire.breakpoint.cc>
	<1219428574.5979.12.camel@ns-test> <48AF0F76.7010702@tomh.org>
	<20080822203652.GN26806@Chamillionaire.breakpoint.cc>
	<48B6AC86.1010401@tomh.org>
	<20080829094157.GA26009@Chamillionaire.breakpoint.cc>
Message-ID: <48B9BFB4.7020000@tomh.org>

Florian Westphal wrote:
> Tom Henderson <tomh at tomh.org> wrote:
>> Florian Westphal wrote:
>>> Here is everything in a single patch:
>>> http://www.strlen.de/cradle/ns-3-nsc-aug-22-2008.diff
>> Florian, here are a few issues that will need to be dealt with during or 
>> shortly after the merge:
>>
>> - the code regarding add_default_gateway() is not clean and should be added 
>> to the tracker as a bug when the merge occurs, if not fixed before then
> 
> No disagreement here, but I'm not sure what the _right_ solution is.
> Any ideas?

I think this might be solvable in two steps:
1) keep the existing limitation on single-interface operation in nsc, 
but improve the code that calls to add_default_gateway() by having it 
call a method in Ipv4.
2) remove the limitation on single-interface operation in nsc by having 
it do some kind of prerouting call to the Ipv4 object.

Some of this (esp. 2) is not supported presently on the ns-3 side of 
things so I think it needs to be considered also as part of the ipv4 
improvement project.

I will look at it some more next week.

> 
>> - we need to figure out how to control, in general, the handling of 
>> compilation options in our unit tests and regression suite (I already 
>> mentioned this), and we need a unit test or regression test added.  For 
>> instance, since the available nsc stacks are platform-dependent, I wonder 
>> what we will check in regression tests (a known-good stack that works in 
>> all environments, only?)
> 
> nsc doesn't change the behaviour of the ns-3 example files.
> What do you want me to do?

I mean, there are some stacks that require older gcc versions-- do we 
just want to test only ones that require a commonly available gcc 
version?  i.e. do not put a regression test in for an NSC stack that is 
not likely to be supportable by most users.

> As for the nsc stacks, the main problem is that the Linux stacks
> that work on both x86 and x86_64 generate different pcap traces
> depending on the host architecture (for instance, it will pick different TCP
> source ports on x86 vs. _64).
> 
>> - some doxygen is missing (e.g., InternetStackHelper::SetTcpDefault())
> 
> See my reply to Raj, i think that method should go.
> I'll walk through things again and will try to add missing docs for any
> methods i have added.
> 
>> - it would help to have a chapter in the manual and some words in the 
>> tutorial about NSC.  The "README.nsc" should migrate somewhere else.
> 
> Where exactly should README.nsc go? Should it move to the wiki instead?
> I could try to move contents from the ns-3-nsc wiki page to the manual,
> if that is deemed acceptable. 

If you are interested in maintaining a wiki page on it, I would suggest 
that.  Maybe move the contents of README.nsc into a new "Section 1" on 
the wiki page.

I think it would be nice, longer-term, to have a manual chapter on NSC 
that goes into some detail of what is going on and how to use it, but 
the contents of README.nsc and troubleshooting/porting hints for NSC 
(such as already on your wiki page), future plans, development schedule, 
etc. are good for the wiki, IMO.

Tom