From mathieu.lacage at sophia.inria.fr Sun Mar 1 00:43:29 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Sun, 01 Mar 2009 09:43:29 +0100 Subject: [Ns-developers] Tracing Rework In-Reply-To: <39D40E947C8840CCA57BF4EE710826BB@CRAIGVAIO> References:

<39D40E947C8840CCA57BF4EE710826BB@CRAIGVAIO> Message-ID: <1235897009.6001.45.camel@mathieu-laptop> One thing I forgot in my comments on the bug report: 'RxStart' + 'Rx' seem to be missing the obvious name symmetry: 'RxStart'+'RxEnd' (same goes for Tx events, of course). Mathieu On Sat, 2009-02-28 at 17:14 -0800, craigdo at ee.washington.edu wrote: > I just stuck an attachment in bugzilla showing what I've done for the > tracing rework to kill bug 443. > > See below > > Comments? > > -- Craig > > > -----Original Message----- > > From: ns-bugs-bounces at ISI.EDU > > [mailto:ns-bugs-bounces at ISI.EDU] On Behalf Of > > code at nsnam.ece.gatech.edu > > Sent: Saturday, February 28, 2009 4:37 PM > > To: ns-bugs at ISI.EDU > > Subject: [Ns-bugs] [Bug 443] Net device pcap traces arent > > consistent with what tcpdump would display > > > > http://www.nsnam.org/bugzilla/show_bug.cgi?id=443 > > > > --- Comment #2 from Craig Dowell > > 2009-02-28 19:37:06 EDT --- > > Created an attachment (id=393) > > --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=393) > > Proposed Changes to Tracing in NetDevices > > > > Significant changes to tracing in all non-bridge net devices. > > > > 1) Splits tracing into MAC-level and PHY-level traces for all devices; > > 2) Adds missing drop traces; > > 3) Adds "Sniffer" and "PromiscSniffer" trace hooks to do > > tcpdump-like traces; > > 4) Sniffer hooks now fire at the correct times; > > 4) Updates helpers to hook new sources. > > > > Note: Most devices are simple enough that everything is > > available in one > > place. Wifi is different. The Sniffer hook in the wifi > > device provides > > Ethernet frames for simple tracing and lives in WifiMac with > > the rest of the > > MAC-level trace sources. Sniffer is available using Pcap calls in the > > WifiHelper. The PromiscSniffer hook in the wifi device > > provides all of the > > low-level wifi packets and lives in WifiPhy with all of the > > PHY-level trace > > sources. PromiscSniffer is available using Pcap calls in the > > YansWifiPhyHelper. > > > > > > -- > > Configure bugmail: > > http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email > > ------- You are receiving this mail because: ------- > > You are on the CC list for the bug. > > _______________________________________________ > > > > From craigdo at ee.washington.edu Sun Mar 1 13:28:53 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Sun, 1 Mar 2009 13:28:53 -0800 Subject: [Ns-developers] Tracing Rework In-Reply-To: <1235897009.6001.45.camel@mathieu-laptop> References:

<39D40E947C8840CCA57BF4EE710826BB@CRAIGVAIO> <1235897009.6001.45.camel@mathieu-laptop> Message-ID: I really prefer to have discussions of any length over email, so allow me to copy your comments from bugzilla to here. > Sorry for not sounding too enthusiastic. Well, I'm not very enthusiastic about this one either. I've thrown away a couple of iterations already. > 1) You can't just add a tx completed event in MacLow. The whole codebase > was designed to not use a tx completed event to 'optimize' that event. > If we find out that we really need to have a tx completed event for > tracing purposes, then, we have to restructure entirely the codebase > because a lot of code is there just to work without a tx completed > event so, if there is one, a lot of code must disappear. This was an attempt to try and make the sources across all of the devices return something reasonably consistent and similarly meaningful. I don't really think this is necessary, BTW. It's obvious that your code doesn't like the idea of a tx complete event, but I wanted to see how bad it would look to plumb in all of the traces in the worst case (wifi being the most complicated device we have). There are actually similar situations in other devices with solutions involving varying amounts of pain. My concern, which led me to trying to implement a tx complete event in the wifi code was the amount of user confusion that could be generated trying to figure out which trace sources are meaningful in what way in which driver. Another source of confusion is that different devices can quite easily pass back packets at different stages of assembly/disassembly when the sources in question are hit (you hit on this tangentially below). I really wanted to prove it; but I'm afraid that trying to realize a real consistency WRT generic traces in specialized devices may just be way more trouble than its worth -- as you are also observing. I believe similar statements have been made here before, BTW. I want to see some kind of structure, but I'm fine with having a set of "standard" trace sources defined -- that are defined to fire at given logical times; and leaving it up to each net device author to decide what subset of these source he or she wants to implement. This standard set would at least give a user a basis to find and use what is available (i.e., I know that I'll most likely find at least one of these standard sources and I know what they do). I'm perfectly fine with removing the tx completed hook from the wifi. I stuck it in, pretty much as a prototype to get a feel for how bad it would be. There is currently no rx start event in csma or point-to-point either, for example. > 2) In wifi-mac.h: please, don't make the traces protected: if you need > to trigger them from subclasses, use a protected Notify method. The same > goes for wifi-phy.h. Do you mean that you want the sources wrapped by a function -- as in, for example, NotifyRxDropTrace ()? That seems like A Good Thing (TM). > 3) WifiNetDevice::SniffPacket ?? You are making an extra copy of the packet > just for tracing, even if there are no connected trace sinks ? This really does > not look like a good idea because it is emulating something really stupid/bad > from linux (which, incidentely, I believe got fixed in recent wifi stacks) and > because its performance cost is a bit horrid. This actually happens all over our code. It is so that various trace sources return some relatively sane number of variations on packet contents. Even in the simplest cases, CSMA, for example could trace a complete packet, a packet without an ethernet trailer, a packet without an ethernet header, a packet with or without an LLC/SNAP header, etc., depending on when a trace is hit. Making a copy of the original packet that came in over the channel allows for only one main variation -- DIX or LLC/SNAP. If this is horrid and should be optimized, it should be done, well, everywhere. Somewhere in this mix we can reach a foolish consistency, but at some level we have to make this usable by mere mortals. > To summarize, 2) appears easily fixable, the part of 3) which makes use of an > ethernet header for tracing looks like a really, _really_ bad idea, and 1) > worries me because it would be a lot of work to adjust the current codebase to > the presence of a tx completed event. I think that the one area that we really want some kind of real consistency is with respect to the pcap traces. The current idea is that there are two main flavors, promiscuous and non-promiscuous. Promiscuous sniffer trace hooks let you do pcap tracing as if you did a tcpdump -i on a particular net device on a particular channel. This seems like a very useful thing and could reduce the number of pcap trace files that are generated all over our system. The other version, the non-promiscuous sniffer is a bit more problematic. Currently, pcap traces written by most of our devices look this way and so I think current users will expect to be able to see it. It can be convenient to see a filtered subset of the frames flowing through the device. This is mostly easy to do in simple net devices where everything is available in one place. Not so much for wifi where complexity issues keep things modularized, and modularity is the enemy of this particular trace source. This is especially visible in the wifi code. It seems very complicated, way more trouble than its worth, to make this work ... correctly. It breaks all kinds of modularity and spans layers. Really ugly. I do need a complete packet that will end up being written to a pcap file, though. The idea here was that this is a very high level thing in the device and that the user really doesn't want to see lots of underlying 802.11 stuff. In fact, the user probably doesn't care about Ethernet frames, really. I just needed some kind of framing to write a pcap file. I did what many implementations of raw packets do and cooked up an ethernet packet out of whole cloth. If you read raw packets from a packet socket on Linux, I believe you will get Ethernet frames, for example. Now, this may be another one of those things that is ugly and more trouble than its worth as well. One alternative is that we can just not support Sniffer tracing on wifi devices as part of a choice of subset of standard trace hooks. I would support this. It does mean that we would move toward making the PromiscSniffer trace the one official standard always-there trace option. This would align us with tcpdump -i, for example. I would resist removing Sniffer from all devices, at least initially, just because of the amount of work in the code and in the documentation to change all references to pcap trace contents. So, Perhaps we could make some policy statements: 1) There is a set of suggested trace sources for net devices. These are currently found in the repo I mentioned and should be documented in the manual. 2) Implementing the complete set of suggested trace sources in a net device is not a requirement. A device author may pick a subset of these sources to implement. 3) The net device author should document what trace sources are implemented and the state the packets are in when they come out of the trace source. For example, raw IP, ethernet header, llc/snap, dix, p2p, wifi, etc. 4) A net device author should implement a PromiscSniffer trace source to allow tcpdump-like functionality in helpers to be called a "standard" net device; but you are always allowed to do whatever you think is right on your own time. I can then 1) Remove the objectionable Sniffer (Ethernet frame) and tx complete trace sources from the wifi device; 2) Remove the unused rx start trace sources from the csma and point-to-point devices; 3) Remove the non-promiscuous sniffer helper code from the wifi-helper and leave yans-wifi-phy hooked to the promisc sniffer; 4) Write some words for the manual on this stuff. This would mean that devices are different with respect to tracing, and initially inconsistent with respect to promiscuous sniffing; so this isn't really a complete resolution of the bug in question for ns-3.4 (sigh). Future work on this subject would involve 1) Adding PromiscSniffer (tcpdump) functionality to the various net devices. 2) Documenting packet contents at the various hooks. 3) Changing the various examples and regressions to use promiscuous sniffers as if someone were doing tcpdump on a real net. 4) Optimizing the packet trace hooks to not copy packets whenever possible. -- Craig > -----Original Message----- > From: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr] > Sent: Sunday, March 01, 2009 12:43 AM > To: craigdo at u.washington.edu > Cc: ns-developers at ISI.EDU > Subject: Re: [Ns-developers] Tracing Rework > > One thing I forgot in my comments on the bug report: 'RxStart' + 'Rx' > seem to be missing the obvious name symmetry: 'RxStart'+'RxEnd' (same > goes for Tx events, of course). > > Mathieu > > On Sat, 2009-02-28 at 17:14 -0800, craigdo at ee.washington.edu wrote: > > I just stuck an attachment in bugzilla showing what I've > done for the > > tracing rework to kill bug 443. > > > > See below > > > > Comments? > > > > -- Craig > > > > > -----Original Message----- > > > From: ns-bugs-bounces at ISI.EDU > > > [mailto:ns-bugs-bounces at ISI.EDU] On Behalf Of > > > code at nsnam.ece.gatech.edu > > > Sent: Saturday, February 28, 2009 4:37 PM > > > To: ns-bugs at ISI.EDU > > > Subject: [Ns-bugs] [Bug 443] Net device pcap traces arent > > > consistent with what tcpdump would display > > > > > > http://www.nsnam.org/bugzilla/show_bug.cgi?id=443 > > > > > > --- Comment #2 from Craig Dowell > > > 2009-02-28 19:37:06 EDT --- > > > Created an attachment (id=393) > > > --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=393) > > > Proposed Changes to Tracing in NetDevices > > > > > > Significant changes to tracing in all non-bridge net devices. > > > > > > 1) Splits tracing into MAC-level and PHY-level traces for > all devices; > > > 2) Adds missing drop traces; > > > 3) Adds "Sniffer" and "PromiscSniffer" trace hooks to do > > > tcpdump-like traces; > > > 4) Sniffer hooks now fire at the correct times; > > > 4) Updates helpers to hook new sources. > > > > > > Note: Most devices are simple enough that everything is > > > available in one > > > place. Wifi is different. The Sniffer hook in the wifi > > > device provides > > > Ethernet frames for simple tracing and lives in WifiMac with > > > the rest of the > > > MAC-level trace sources. Sniffer is available using Pcap > calls in the > > > WifiHelper. The PromiscSniffer hook in the wifi device > > > provides all of the > > > low-level wifi packets and lives in WifiPhy with all of the > > > PHY-level trace > > > sources. PromiscSniffer is available using Pcap calls in the > > > YansWifiPhyHelper. > > > > > > > > > -- > > > Configure bugmail: > > > http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email > > > ------- You are receiving this mail because: ------- > > > You are on the CC list for the bug. > > > _______________________________________________ > > > > > > > > > From raj.b at gatech.edu Mon Mar 2 07:38:26 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Mon, 2 Mar 2009 10:38:26 -0500 Subject: [Ns-developers] [Bug 370] ipv4-interface.h is installed In-Reply-To: References:

Message-ID: <12d69e490903020738u320195e2yeeb0e7362f93c1e0@mail.gmail.com> On Sat, Feb 28, 2009 at 10:04 AM, Gustavo Carneiro wrote: > Hi Raj, I need your permission to commit the patch to fix the P2 bug. > This is a notification that Gustavo has the tree for pushing this fix. Everyone else please refrain from commits while Gustavo has the token. -- 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 Mon Mar 2 07:43:09 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 2 Mar 2009 15:43:09 +0000 Subject: [Ns-developers] [Bug 370] ipv4-interface.h is installed In-Reply-To: <12d69e490903020738u320195e2yeeb0e7362f93c1e0@mail.gmail.com> References:

<12d69e490903020738u320195e2yeeb0e7362f93c1e0@mail.gmail.com> Message-ID: 2009/3/2 Raj Bhattacharjea > On Sat, Feb 28, 2009 at 10:04 AM, Gustavo Carneiro > wrote: > > Hi Raj, I need your permission to commit the patch to fix the P2 bug. > > > > This is a notification that Gustavo has the tree for pushing this fix. > Everyone else please refrain from commits while Gustavo has the > token. Oh, we are dealing with "tokens" now? I thought a DVCS was supposed to save as from this archaic nonsense of us doing work that should be done by computers... :-) Anyway, you can have your token back; I am done. > > > -- > Raj Bhattacharjea > Georgia Institute of Technology > School of Electrical and Computer Engineering > Ph.D. Candidate > Systems Analyst > 404.894.2955 > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From raj.b at gatech.edu Mon Mar 2 08:01:39 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Mon, 2 Mar 2009 11:01:39 -0500 Subject: [Ns-developers] [Bug 370] ipv4-interface.h is installed In-Reply-To: References:

<12d69e490903020738u320195e2yeeb0e7362f93c1e0@mail.gmail.com> Message-ID: <12d69e490903020801i7de67402x6325e5a4dadb53f5@mail.gmail.com> On Mon, Mar 2, 2009 at 10:43 AM, Gustavo Carneiro wrote: > > > 2009/3/2 Raj Bhattacharjea >> >> On Sat, Feb 28, 2009 at 10:04 AM, Gustavo Carneiro >> wrote: >> > Hi Raj, I need your permission to commit the patch to fix the P2 bug. >> > >> >> This is a notification that Gustavo has the tree for pushing this fix. >> ?Everyone else please refrain from commits while Gustavo has the >> token. > > Oh, we are dealing with "tokens" now?? I thought a DVCS was supposed to save > as from this archaic nonsense of us doing work that should be done by > computers... :-) > > Anyway, you can have your token back; I am done. > The logic behind this is testing. The full regression suite on ns-regression takes hours to run; if others commit changes while you are running the regression on your (now stale) copy of ns-3-dev, there is no guarantee that a merged branch (their changes + yours) will now ALSO pass the regression tests. So you would have to pull, merge, and run the test again for a few hours. When you are done, if someone else has pushed changes, you waste more hours waiting for the regression test to finish. It is archaic, but has utility. I don't think any VCS could solve this problem for us. -- 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 Mon Mar 2 08:07:06 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 2 Mar 2009 16:07:06 +0000 Subject: [Ns-developers] [Bug 370] ipv4-interface.h is installed In-Reply-To: <12d69e490903020801i7de67402x6325e5a4dadb53f5@mail.gmail.com> References:

<12d69e490903020738u320195e2yeeb0e7362f93c1e0@mail.gmail.com> <12d69e490903020801i7de67402x6325e5a4dadb53f5@mail.gmail.com> Message-ID: 2009/3/2 Raj Bhattacharjea > On Mon, Mar 2, 2009 at 10:43 AM, Gustavo Carneiro > wrote: > > > > > > 2009/3/2 Raj Bhattacharjea > >> > >> On Sat, Feb 28, 2009 at 10:04 AM, Gustavo Carneiro < > gjcarneiro at gmail.com> > >> wrote: > >> > Hi Raj, I need your permission to commit the patch to fix the P2 bug. > >> > > >> > >> This is a notification that Gustavo has the tree for pushing this fix. > >> Everyone else please refrain from commits while Gustavo has the > >> token. > > > > Oh, we are dealing with "tokens" now? I thought a DVCS was supposed to > save > > as from this archaic nonsense of us doing work that should be done by > > computers... :-) > > > > Anyway, you can have your token back; I am done. > > > > The logic behind this is testing. The full regression suite on > ns-regression takes hours to run; if others commit changes while you > are running the regression on your (now stale) copy of ns-3-dev, there > is no guarantee that a merged branch (their changes + yours) will now > ALSO pass the regression tests. So you would have to pull, merge, and > run the test again for a few hours. When you are done, if someone > else has pushed changes, you waste more hours waiting for the > regression test to finish. Surely running the regression tests on your own host would be enough? I never run regression tests on any remote host. It takes less than a minute on my laptop. > > > It is archaic, but has utility. I don't think any VCS could solve > this problem for us. > > -- > Raj Bhattacharjea > Georgia Institute of Technology > School of Electrical and Computer Engineering > Ph.D. Candidate > Systems Analyst > 404.894.2955 > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From raj.b at gatech.edu Mon Mar 2 08:15:48 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Mon, 2 Mar 2009 11:15:48 -0500 Subject: [Ns-developers] [Bug 370] ipv4-interface.h is installed In-Reply-To: References:

<12d69e490903020738u320195e2yeeb0e7362f93c1e0@mail.gmail.com> <12d69e490903020801i7de67402x6325e5a4dadb53f5@mail.gmail.com> Message-ID: <12d69e490903020815xd922b8fkc781cf092ec01dfb@mail.gmail.com> On Mon, Mar 2, 2009 at 11:07 AM, Gustavo Carneiro wrote: > > > 2009/3/2 Raj Bhattacharjea >> >> On Mon, Mar 2, 2009 at 10:43 AM, Gustavo Carneiro >> wrote: >> > >> > >> > 2009/3/2 Raj Bhattacharjea >> >> >> >> On Sat, Feb 28, 2009 at 10:04 AM, Gustavo Carneiro >> >> >> >> wrote: >> >> > Hi Raj, I need your permission to commit the patch to fix the P2 bug. >> >> > >> >> >> >> This is a notification that Gustavo has the tree for pushing this fix. >> >> ?Everyone else please refrain from commits while Gustavo has the >> >> token. >> > >> > Oh, we are dealing with "tokens" now?? I thought a DVCS was supposed to >> > save >> > as from this archaic nonsense of us doing work that should be done by >> > computers... :-) >> > >> > Anyway, you can have your token back; I am done. >> > >> >> The logic behind this is testing. ?The full regression suite on >> ns-regression takes hours to run; if others commit changes while you >> are running the regression on your (now stale) copy of ns-3-dev, there >> is no guarantee that a merged branch (their changes + yours) will now >> ALSO pass the regression tests. ?So you would have to pull, merge, and >> run the test again for a few hours. ?When you are done, if someone >> else has pushed changes, you waste more hours waiting for the >> regression test to finish. > > Surely running the regression tests on your own host would be enough?? I > never run regression tests on any remote host.? It takes less than a minute > on my laptop. > No. You really should make sure you didn't break the build on the ns-regression farm of machines. We've certainly seen patches which break the build on some, but not all supported architectures. This isn't required during the "open phase" of a release, but during this "maintenance phase" when new features won't be merged but we aren't in a full code freeze, making sure the tree stays stable is the best practice. -- 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 Mon Mar 2 08:24:02 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 2 Mar 2009 16:24:02 +0000 Subject: [Ns-developers] [Bug 370] ipv4-interface.h is installed In-Reply-To: <12d69e490903020815xd922b8fkc781cf092ec01dfb@mail.gmail.com> References:

<12d69e490903020738u320195e2yeeb0e7362f93c1e0@mail.gmail.com> <12d69e490903020801i7de67402x6325e5a4dadb53f5@mail.gmail.com> <12d69e490903020815xd922b8fkc781cf092ec01dfb@mail.gmail.com> Message-ID: 2009/3/2 Raj Bhattacharjea > On Mon, Mar 2, 2009 at 11:07 AM, Gustavo Carneiro > wrote: > > > > > > 2009/3/2 Raj Bhattacharjea > >> > >> On Mon, Mar 2, 2009 at 10:43 AM, Gustavo Carneiro > > >> wrote: > >> > > >> > > >> > 2009/3/2 Raj Bhattacharjea > >> >> > >> >> On Sat, Feb 28, 2009 at 10:04 AM, Gustavo Carneiro > >> >> > >> >> wrote: > >> >> > Hi Raj, I need your permission to commit the patch to fix the P2 > bug. > >> >> > > >> >> > >> >> This is a notification that Gustavo has the tree for pushing this > fix. > >> >> Everyone else please refrain from commits while Gustavo has the > >> >> token. > >> > > >> > Oh, we are dealing with "tokens" now? I thought a DVCS was supposed > to > >> > save > >> > as from this archaic nonsense of us doing work that should be done by > >> > computers... :-) > >> > > >> > Anyway, you can have your token back; I am done. > >> > > >> > >> The logic behind this is testing. The full regression suite on > >> ns-regression takes hours to run; if others commit changes while you > >> are running the regression on your (now stale) copy of ns-3-dev, there > >> is no guarantee that a merged branch (their changes + yours) will now > >> ALSO pass the regression tests. So you would have to pull, merge, and > >> run the test again for a few hours. When you are done, if someone > >> else has pushed changes, you waste more hours waiting for the > >> regression test to finish. > > > > Surely running the regression tests on your own host would be enough? I > > never run regression tests on any remote host. It takes less than a > minute > > on my laptop. > > > > No. You really should make sure you didn't break the build on the > ns-regression farm of machines. We've certainly seen patches which > break the build on some, but not all supported architectures. > > This isn't required during the "open phase" of a release, but during > this "maintenance phase" when new features won't be merged but we > aren't in a full code freeze, making sure the tree stays stable is the > best practice. I think it's a bit overkill except in the final week until release or so. But ok. In any case, I wasn't even aware you could trigger the automated regression hosts to do regression testing _right now_. I always assumed you'd have to way up to 24 hours for the next time it runs by itself. I checked the "Developer FAQ" wiki, but didn't find this information there. We really should start adding information like this to the wiki. Just sending an email is _not_ ok; developers might miss the email, or forget the contents, and we have no time to keep searching email archives. Thanks. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From raj.b at gatech.edu Mon Mar 2 08:25:21 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Mon, 2 Mar 2009 11:25:21 -0500 Subject: [Ns-developers] [Bug 370] ipv4-interface.h is installed In-Reply-To: References:

<12d69e490903020738u320195e2yeeb0e7362f93c1e0@mail.gmail.com> <12d69e490903020801i7de67402x6325e5a4dadb53f5@mail.gmail.com> <12d69e490903020815xd922b8fkc781cf092ec01dfb@mail.gmail.com> <12d69e490903020825x62dc5ea0jbdc8c5d4d6f62316@mail.gmail.com> Message-ID: <12d69e490903020826o754b1a03p6bf7d5af47e0ff08@mail.gmail.com> On Mon, Mar 2, 2009 at 11:25 AM, Raj Bhattacharjea wrote: > On Mon, Mar 2, 2009 at 11:24 AM, Gustavo Carneiro wrote: >> >> >> 2009/3/2 Raj Bhattacharjea >>> >>> On Mon, Mar 2, 2009 at 11:07 AM, Gustavo Carneiro >>> wrote: >>> > >>> > >>> > 2009/3/2 Raj Bhattacharjea >>> >> >>> >> On Mon, Mar 2, 2009 at 10:43 AM, Gustavo Carneiro >>> >> >>> >> wrote: >>> >> > >>> >> > >>> >> > 2009/3/2 Raj Bhattacharjea >>> >> >> >>> >> >> On Sat, Feb 28, 2009 at 10:04 AM, Gustavo Carneiro >>> >> >> >>> >> >> wrote: >>> >> >> > Hi Raj, I need your permission to commit the patch to fix the P2 >>> >> >> > bug. >>> >> >> > >>> >> >> >>> >> >> This is a notification that Gustavo has the tree for pushing this >>> >> >> fix. >>> >> >> ?Everyone else please refrain from commits while Gustavo has the >>> >> >> token. >>> >> > >>> >> > Oh, we are dealing with "tokens" now?? I thought a DVCS was supposed >>> >> > to >>> >> > save >>> >> > as from this archaic nonsense of us doing work that should be done by >>> >> > computers... :-) >>> >> > >>> >> > Anyway, you can have your token back; I am done. >>> >> > >>> >> >>> >> The logic behind this is testing. ?The full regression suite on >>> >> ns-regression takes hours to run; if others commit changes while you >>> >> are running the regression on your (now stale) copy of ns-3-dev, there >>> >> is no guarantee that a merged branch (their changes + yours) will now >>> >> ALSO pass the regression tests. ?So you would have to pull, merge, and >>> >> run the test again for a few hours. ?When you are done, if someone >>> >> else has pushed changes, you waste more hours waiting for the >>> >> regression test to finish. >>> > >>> > Surely running the regression tests on your own host would be enough?? I >>> > never run regression tests on any remote host.? It takes less than a >>> > minute >>> > on my laptop. >>> > >>> >>> No. ?You really should make sure you didn't break the build on the >>> ns-regression farm of machines. ?We've certainly seen patches which >>> break the build on some, but not all supported architectures. >>> >>> This isn't required during the "open phase" of a release, but during >>> this "maintenance phase" when new features won't be merged but we >>> aren't in a full code freeze, making sure the tree stays stable is the >>> best practice. >> >> I think it's a bit overkill except in the final week until release or so. >> But ok. >> >> In any case, I wasn't even aware you could trigger the automated regression >> hosts to do regression testing _right now_.? I always assumed you'd have to >> way up to 24 hours for the next time it runs by itself. >> >> I checked the "Developer FAQ" wiki, but didn't find this information there. >> We really should start adding information like this to the wiki.? Just >> sending an email is _not_ ok; developers might miss the email, or forget the >> contents, and we have no time to keep searching email archives. > > I'll make sure to write up how to do this on the wiki. It was there, albeit not fleshed out: http://www.nsnam.org/wiki/index.php/Developer_FAQ#Testing_code_on_nsnam.org_hosts -- 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 Mon Mar 2 08:59:19 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Mon, 2 Mar 2009 11:59:19 -0500 Subject: [Ns-developers] ns-3.4 release plans In-Reply-To: <12d69e490901071434g1024a72fgdc5dfb74b9184c72@mail.gmail.com> References: <12d69e490901071434g1024a72fgdc5dfb74b9184c72@mail.gmail.com> Message-ID: <12d69e490903020859i75806b65l975144697687affc@mail.gmail.com> I wanted to follow up on the status of the ns-3.4 release. I have included the original email below, and am going to comment inline about the status of the items we proposed for ns-3.4 back in January. On Wed, Jan 7, 2009 at 5:34 PM, Raj Bhattacharjea wrote: > I wish a happy new year to the ns-3 development community!? With the new > year comes new plans, namely those for releasing the next version of ns3, > version 3.4 .? This email is lengthy, so you can catch the short version on > the wiki: > > http://www.nsnam.org/wiki/index.php/Ns-3.4 > > Otherwise, read on. > > ==Release Schedule== > The plan is to have an early merge period through January 27th, during which > proposals for new APIs and features will be reviewed and merged into the > ns-3-dev trunk.? Any remaining features which have been proposed but not > fully reviewed, or for which there is no consensus, can be merged in up > until February 10th. We ended up holding for some issues I had with the random variables changes. In reality, we ended up merging the last new feature for ns-3.4 on February 24, two weeks behind schedule. > > The rest of the month of February will be for maintainance; during this > period only P1 bugs will be fixed, and no API will change.? Behavioral > changes to models not affecting API will be allowed. Looking at the work queue for bugs, it is looking like we will have to slip the schedule by about two weeks to accommodate bug fixes. I am suggesting that we target the end of the maintenance phase (for bug fixes) to March 18. > > From March 1st, release candidates will be released.? The bug count should > ideally be zero during this time, and any remaining bugs discovered will be > ironed out by the the 18th of March, when the final release of ns3.4 is > made. I suggest we push this back to March 19. We have adopted a policy of consider P1 bugs as those which are broken behavior, and will be true blockers which will hold up the _release candidates_; that is, there will be no P1 bugs in ns-3.4-RC1 (otherwise, how is it a candidate for release?). Any bugs found from beating on RC1 will be fixed and posted as RC2, etc. > > More details follow here: > http://www.nsnam.org/wiki/index.php/Ns-3.4#The_ns-3.4_Release_Schedule > This link has been updated to reflect the schedule I propose above. > ==New Features== > > The planned new features for 3.4 are as follows: > > A new tap net device which will allow ns-3 to create a Linux system network > interface through which ns-3 traffic can flow back and forth with the real > world.? It is being adapted by Craig from a prototype version Mathieu has > been utilizing in demonstrations of ns3. This work has been merged. > A system for assigning names to nodes.? Issues of accessing nodes by name, > utilizing names for accessing trace hooks, displaying the names in trace > output, and showing the names in logging output are still being resolved. > Craig is working on this. This work has also been merged. > An upgrade to the waf version used in ns-3, as well as a move to a so called > "allinone" build system.? The system will separate the downloading of > "optional" components (such as pybindgen and nsc) from the regular waf build > process of ns-3.? Gustavo has something in the works. The allinone branch works as promised. > New API for RandomVariables, adding new seeing API and new default seeding > behavior.? Raj is working with Michelle Weigle and Hadi Arbabi on this. This branch has been merged. > A refactoring of the IPv4 routing API.? Tom is working on this. > More support for IPv6 > (http://mailman.isi.edu/pipermail/ns-developers/2008-July/004358.html).? Tom > is working on this. These two items have been deferred to ns-3.5. > Behavioral changes in TCP to be RFC compliant in regards to closedown > behavior (correct FINs and RSTs).? Raj is working on this. > Consistency of trace hooks across NetDevice types. and true PCAP > compatibility (http://www.nsnam.org/bugzilla/show_bug.cgi?id=443).? Craig is > working on this. > Possible addition of some rigorous ns3 system tests which work without > comparing script output against known traces. The above qualify as bug fixes that are being resolved. Please see bugzilla or the bug list for more information: http://www.nsnam.org/wiki/index.php/Ns-3.4#The_ns-3.4_Bug_List -- 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 Mon Mar 2 09:29:31 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 2 Mar 2009 17:29:31 +0000 Subject: [Ns-developers] [Bug 370] ipv4-interface.h is installed In-Reply-To: <12d69e490903020826o754b1a03p6bf7d5af47e0ff08@mail.gmail.com> References: <12d69e490903020738u320195e2yeeb0e7362f93c1e0@mail.gmail.com> <12d69e490903020801i7de67402x6325e5a4dadb53f5@mail.gmail.com> <12d69e490903020815xd922b8fkc781cf092ec01dfb@mail.gmail.com> <12d69e490903020825x62dc5ea0jbdc8c5d4d6f62316@mail.gmail.com> <12d69e490903020826o754b1a03p6bf7d5af47e0ff08@mail.gmail.com> Message-ID: 2009/3/2 Raj Bhattacharjea > On Mon, Mar 2, 2009 at 11:25 AM, Raj Bhattacharjea > wrote: > > On Mon, Mar 2, 2009 at 11:24 AM, Gustavo Carneiro > wrote: > >> > >> > >> 2009/3/2 Raj Bhattacharjea > >>> > >>> On Mon, Mar 2, 2009 at 11:07 AM, Gustavo Carneiro < > gjcarneiro at gmail.com> > >>> wrote: > >>> > > >>> > > >>> > 2009/3/2 Raj Bhattacharjea > >>> >> > >>> >> On Mon, Mar 2, 2009 at 10:43 AM, Gustavo Carneiro > >>> >> > >>> >> wrote: > >>> >> > > >>> >> > > >>> >> > 2009/3/2 Raj Bhattacharjea > >>> >> >> > >>> >> >> On Sat, Feb 28, 2009 at 10:04 AM, Gustavo Carneiro > >>> >> >> > >>> >> >> wrote: > >>> >> >> > Hi Raj, I need your permission to commit the patch to fix the > P2 > >>> >> >> > bug. > >>> >> >> > > >>> >> >> > >>> >> >> This is a notification that Gustavo has the tree for pushing this > >>> >> >> fix. > >>> >> >> Everyone else please refrain from commits while Gustavo has the > >>> >> >> token. > >>> >> > > >>> >> > Oh, we are dealing with "tokens" now? I thought a DVCS was > supposed > >>> >> > to > >>> >> > save > >>> >> > as from this archaic nonsense of us doing work that should be done > by > >>> >> > computers... :-) > >>> >> > > >>> >> > Anyway, you can have your token back; I am done. > >>> >> > > >>> >> > >>> >> The logic behind this is testing. The full regression suite on > >>> >> ns-regression takes hours to run; if others commit changes while you > >>> >> are running the regression on your (now stale) copy of ns-3-dev, > there > >>> >> is no guarantee that a merged branch (their changes + yours) will > now > >>> >> ALSO pass the regression tests. So you would have to pull, merge, > and > >>> >> run the test again for a few hours. When you are done, if someone > >>> >> else has pushed changes, you waste more hours waiting for the > >>> >> regression test to finish. > >>> > > >>> > Surely running the regression tests on your own host would be > enough? I > >>> > never run regression tests on any remote host. It takes less than a > >>> > minute > >>> > on my laptop. > >>> > > >>> > >>> No. You really should make sure you didn't break the build on the > >>> ns-regression farm of machines. We've certainly seen patches which > >>> break the build on some, but not all supported architectures. > >>> > >>> This isn't required during the "open phase" of a release, but during > >>> this "maintenance phase" when new features won't be merged but we > >>> aren't in a full code freeze, making sure the tree stays stable is the > >>> best practice. > >> > >> I think it's a bit overkill except in the final week until release or > so. > >> But ok. > >> > >> In any case, I wasn't even aware you could trigger the automated > regression > >> hosts to do regression testing _right now_. I always assumed you'd have > to > >> way up to 24 hours for the next time it runs by itself. > >> > >> I checked the "Developer FAQ" wiki, but didn't find this information > there. > >> We really should start adding information like this to the wiki. Just > >> sending an email is _not_ ok; developers might miss the email, or forget > the > >> contents, and we have no time to keep searching email archives. > > > > I'll make sure to write up how to do this on the wiki. > > It was there, albeit not fleshed out: > > > http://www.nsnam.org/wiki/index.php/Developer_FAQ#Testing_code_on_nsnam.org_hosts > One thing is not clear, however. If you have a patch to test, you have to commit it first, and only then can you test it, since the regression script takes a branch name, not a repository. Doesn't it kind of defeat the purpose? If a problem is detected in the patch, it will already be too late because it was already committed... I hope we are not supposed to create a new temporary branch for each patch we wish to test. If so, you can expect me to never commit a patch again during a maintenance period. No offense, but I simply don't have time or patience to jump through all these hoops in order to fix a bug. Regards, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From raj.b at gatech.edu Mon Mar 2 11:14:08 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Mon, 2 Mar 2009 14:14:08 -0500 Subject: [Ns-developers] [Bug 370] ipv4-interface.h is installed In-Reply-To: References: <12d69e490903020738u320195e2yeeb0e7362f93c1e0@mail.gmail.com> <12d69e490903020801i7de67402x6325e5a4dadb53f5@mail.gmail.com> <12d69e490903020815xd922b8fkc781cf092ec01dfb@mail.gmail.com> <12d69e490903020825x62dc5ea0jbdc8c5d4d6f62316@mail.gmail.com> <12d69e490903020826o754b1a03p6bf7d5af47e0ff08@mail.gmail.com> Message-ID: <12d69e490903021114i3091c5f5he8756f09546763e8@mail.gmail.com> On Mon, Mar 2, 2009 at 12:29 PM, Gustavo Carneiro wrote: > > One thing is not clear, however.? If you have a patch to test, you have to > commit it first, and only then can you test it, since the regression script > takes a branch name, not a repository.? Doesn't it kind of defeat the > purpose?? If a problem is detected in the patch, it will already be too late > because it was already committed... > > I hope we are not supposed to create a new temporary branch for each patch > we wish to test.? If so, you can expect me to never commit a patch again > during a maintenance period.? No offense, but I simply don't have time or > patience to jump through all these hoops in order to fix a bug. > I see your concern; you've convinced me. I am willing to wait for the nightly test to run to see if someone broke the build on other platforms. Lets say it would be _nice_ if you could test on ns-regression, but it isn't mandatory to bugfix. This practice however will be strictly enforced in the week or so leading up to the release, as you suggest. -- Raj Bhattacharjea Georgia Institute of Technology School of Electrical and Computer Engineering Ph.D. Candidate Systems Analyst 404.894.2955 From ruturajmd at gmail.com Mon Mar 2 06:22:50 2009 From: ruturajmd at gmail.com (Ruturaj Dhekane) Date: Mon, 2 Mar 2009 19:52:50 +0530 Subject: [Ns-developers] Regarding 802.15 MAC Layer Message-ID: <955e31df0903020622l56a5ca1bj173e3e43889aba74@mail.gmail.com> Hi, I am working on a Wireless Sensor Networks based research project. I would like to simulate the WSN nodes. However 802.15.x MAC layer isnt currently available with NS-3. I would like to have some pointers from the developer community regarding writing our own MAC layer. (As in where do I begin, and How?) Would also like to know certain fields in which I might be able to contribute to NS-3 code in general. Thanking You Sincerely.. Ruturaj Final Year, Under-Graduate Computer Science And Engg. Visvesvaraya National Institute Of Technology India. -- [Geekru2] From mathieu.lacage at sophia.inria.fr Mon Mar 2 08:22:23 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 02 Mar 2009 17:22:23 +0100 Subject: [Ns-developers] [Bug 370] ipv4-interface.h is installed In-Reply-To: References:

<12d69e490903020738u320195e2yeeb0e7362f93c1e0@mail.gmail.com> <12d69e490903020801i7de67402x6325e5a4dadb53f5@mail.gmail.com> Message-ID: <1236010943.10216.24.camel@mathieu-laptop> On Mon, 2009-03-02 at 16:07 +0000, Gustavo Carneiro wrote: > Surely running the regression tests on your own host would be enough? > I > never run regression tests on any remote host. It takes less than a > minute > on my laptop. Yes, I don't think normal development requires more than regression tests working on your machine: we have the daily email output of the regression test to tell us we have screwed up the system, and we can use it to be notified that we have to debug something serious. What I personally usually do is: 1) in normal development, build debug and optimized versions, run regressions for both 2) close to the release, build debug and optimized versions for a set of known compilers: 3.4.6, 4.0.x, 4.1.x, 4.2.x In my experience, the above is sufficient to cover 95% of portability problems (especially 3.4.6 and 4.0.x). For 2), I had some trivial scripts to do this for me at some point but I lost them. If there is interest in this, I can re-generate them. Mathieu From mathieu.lacage at sophia.inria.fr Mon Mar 2 08:12:26 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 02 Mar 2009 17:12:26 +0100 Subject: [Ns-developers] Tracing Rework In-Reply-To: References:

<39D40E947C8840CCA57BF4EE710826BB@CRAIGVAIO> <1235897009.6001.45.camel@mathieu-laptop> Message-ID: <1236010346.10216.17.camel@mathieu-laptop> On Sun, 2009-03-01 at 13:28 -0800, craigdo at ee.washington.edu wrote: [snip] > > 2) In wifi-mac.h: please, don't make the traces protected: if you need > > to trigger them from subclasses, use a protected Notify method. The same > > goes for wifi-phy.h. > > Do you mean that you want the sources wrapped by a function -- as in, for > example, NotifyRxDropTrace ()? That seems like A Good Thing (TM). yes, indeed. > > 3) WifiNetDevice::SniffPacket ?? You are making an extra copy of the > packet > > just for tracing, even if there are no connected trace sinks ? This really > does > > not look like a good idea because it is emulating something really > stupid/bad > > from linux (which, incidentely, I believe got fixed in recent wifi stacks) > and > > because its performance cost is a bit horrid. > > This actually happens all over our code. It is so that various trace > sources return some relatively sane number of variations on packet contents. > Even in the simplest cases, CSMA, for example could trace a complete packet, > a packet without an ethernet trailer, a packet without an ethernet header, a > packet with or without an LLC/SNAP header, etc., depending on when a trace > is hit. Making a copy of the original packet that came in over the channel > allows for only one main variation -- DIX or LLC/SNAP. If this is horrid > and should be optimized, it should be done, well, everywhere. I don't mind the packet copy itself: I mind the following addition of an ethernet header because: 1) it's horrid to make a wifi device look like an ethernet device. A real bad linux idea, and, one I believe decent and recent linux drivers don't do anymore (I could be wrong here though). 2) it's horribly inefficient to add the ethernet header because it is the addition of the ethernet header which will trigger a deep copy. The previous call to Copy itself is really cheap so, it's not a big deal. What I would support is a Copy of the packet before the wifi header is removed because that would be both efficient and result in traces which do not contain an ethernet header but contain a wifi header (but, in this case, you would not need a copy anymore). It might be possible to partially implement this by replacing RemoveHeader by PeekHeader in MacLow::ReceiveOk and calling a trace hook in the right location in this function (to filter out some unwanted packets). That would not be all the filtering done by a real pcap trace on a real linux system, but, well... > The other version, the non-promiscuous sniffer is a bit more problematic. > Currently, pcap traces written by most of our devices look this way and so I > think current users will expect to be able to see it. It can be convenient > to see a filtered subset of the frames flowing through the device. This is > mostly easy to do in simple net devices where everything is available in one > place. Not so much for wifi where complexity issues keep things > modularized, and modularity is the enemy of this particular trace source. > This is especially visible in the wifi code. It seems very complicated, way > more trouble than its worth, to make this work ... correctly. It breaks all > kinds of modularity and spans layers. Really ugly. Agreed. > I can then > > 1) Remove the objectionable Sniffer (Ethernet frame) and tx complete trace > sources from the wifi device; > > 2) Remove the unused rx start trace sources from the csma and point-to-point > devices; > > 3) Remove the non-promiscuous sniffer helper code from the wifi-helper and > leave yans-wifi-phy hooked to the promisc sniffer; > > 4) Write some words for the manual on this stuff. I think that the above would be fine. > 4) Optimizing the packet trace hooks to not copy packets whenever possible. As I said before, calling Packet::Copy is not a big deal. Mathieu From gjcarneiro at gmail.com Tue Mar 3 03:32:32 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 3 Mar 2009 11:32:32 +0000 Subject: [Ns-developers] Regression testing (Was: [Bug 370] ipv4-interface.h is installed) Message-ID: 2009/3/2 Raj Bhattacharjea > On Mon, Mar 2, 2009 at 12:29 PM, Gustavo Carneiro > wrote: > > > > One thing is not clear, however. If you have a patch to test, you have > to > > commit it first, and only then can you test it, since the regression > script > > takes a branch name, not a repository. Doesn't it kind of defeat the > > purpose? If a problem is detected in the patch, it will already be too > late > > because it was already committed... > > > > I hope we are not supposed to create a new temporary branch for each > patch > > we wish to test. If so, you can expect me to never commit a patch again > > during a maintenance period. No offense, but I simply don't have time or > > patience to jump through all these hoops in order to fix a bug. > > > > I see your concern; you've convinced me. I am willing to wait for the > nightly test to run to see if someone broke the build on other > platforms. Lets say it would be _nice_ if you could test on > ns-regression, but it isn't mandatory to bugfix. > > This practice however will be strictly enforced in the week or so > leading up to the release, as you suggest. Thanks. But I am noticing a new problem now. I run the ns-3-run-tests.sh script with a -m option, to send email with the results, but the script still keeps running in the foreground. Since the wiki page says it can take several hours to complete, I need to be able to logout, but if I hit Ctrl-C the regression testing is aborted. nohup script & does not work because I have no write permission to the file system. I was expecting the tests to run in background when -m option is given. > > > -- > Raj Bhattacharjea > Georgia Institute of Technology > School of Electrical and Computer Engineering > Ph.D. Candidate > Systems Analyst > 404.894.2955 > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From tomh at tomh.org Tue Mar 3 05:53:43 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 03 Mar 2009 05:53:43 -0800 Subject: [Ns-developers] ns-3.4 release plans In-Reply-To: <12d69e490903020859i75806b65l975144697687affc@mail.gmail.com> References: <12d69e490901071434g1024a72fgdc5dfb74b9184c72@mail.gmail.com> <12d69e490903020859i75806b65l975144697687affc@mail.gmail.com> Message-ID: <49AD3667.6010800@tomh.org> Raj Bhattacharjea wrote: >> From March 1st, release candidates will be released. The bug count should >> ideally be zero during this time, and any remaining bugs discovered will be >> ironed out by the the 18th of March, when the final release of ns3.4 is >> made. > > I suggest we push this back to March 19. We have adopted a policy of > consider P1 bugs as those which are broken behavior, and will be true > blockers which will hold up the _release candidates_; that is, there > will be no P1 bugs in ns-3.4-RC1 (otherwise, how is it a candidate for > release?). Any bugs found from beating on RC1 will be fixed and > posted as RC2, etc. Raj, I'm OK with slipping the release two weeks if it means that we will get all of the outstanding P1 bugs in your list fixed. However, I think we should carefully consider whether additional bugs that come in will keep slipping the release further. There is another option to slipping, which is to list open bugs as "known issues", and perhaps even to later do a small maintenance release. So, I would suggest that we try not to slip the release further unless a major issue comes up that can't be fixed by April 1. - Tom From gjcarneiro at gmail.com Tue Mar 3 06:48:15 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 3 Mar 2009 14:48:15 +0000 Subject: [Ns-developers] Request to commit -fvisbility=hidden python bindings patch Message-ID: Hi Raj, May I commit the patch at [1] for ns 3.4? It decreases python bindings size (from 6 to 5 MB) and decreases its loading time (didn't measure, but the documentation [2] claims it to be so...). Regards, [1] http://www.nsnam.org/bugzilla/show_bug.cgi?id=515 [2] http://gcc.gnu.org/wiki/Visibility -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From vivekmrathod at gmail.com Tue Mar 3 06:12:04 2009 From: vivekmrathod at gmail.com (vivek rathod) Date: Tue, 3 Mar 2009 19:42:04 +0530 Subject: [Ns-developers] how to get involved in ns-3 Message-ID: <8be4676d0903030612o198bb026pb4d0017814cc784f@mail.gmail.com> Hello all, i am new to ns 2/ ns3 . i want to get to the development side of ns-3. i have good knowledge and implementations skills in c++ and python. could you please tell me where to start. if there is some detailed resource for new developers please send me the link. thank you vivek From tomh at tomh.org Tue Mar 3 08:18:48 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 03 Mar 2009 08:18:48 -0800 Subject: [Ns-developers] how to get involved in ns-3 In-Reply-To: <8be4676d0903030612o198bb026pb4d0017814cc784f@mail.gmail.com> References: <8be4676d0903030612o198bb026pb4d0017814cc784f@mail.gmail.com> Message-ID: <49AD5868.2030000@tomh.org> vivek rathod wrote: > Hello all, > > i am new to ns 2/ ns3 . i want to get to the development side of ns-3. i > have good knowledge and implementations skills in c++ and python. > > could you please tell me where to start. if there is some detailed resource > for new developers please send me the link. > > thank you > > vivek Vivek, For starters, you can browse this page: http://www.nsnam.org/contributing.html and also our wiki, tutorial, and manual. If you are looking for a project idea, we have listed several on our GSOC page: http://www.nsnam.org/wiki/index.php/Gsoc2009 - Tom From tomh at tomh.org Tue Mar 3 10:15:39 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 03 Mar 2009 10:15:39 -0800 Subject: [Ns-developers] Tracing Rework In-Reply-To: <1236010346.10216.17.camel@mathieu-laptop> References:

<39D40E947C8840CCA57BF4EE710826BB@CRAIGVAIO> <1235897009.6001.45.camel@mathieu-laptop> <1236010346.10216.17.camel@mathieu-laptop> Message-ID: <49AD73CB.9060609@tomh.org> > >> I can then >> >> 1) Remove the objectionable Sniffer (Ethernet frame) and tx complete trace >> sources from the wifi device; >> >> 2) Remove the unused rx start trace sources from the csma and point-to-point >> devices; >> >> 3) Remove the non-promiscuous sniffer helper code from the wifi-helper and >> leave yans-wifi-phy hooked to the promisc sniffer; >> >> 4) Write some words for the manual on this stuff. > > I think that the above would be fine. I agree with the above and with just documenting that there is a preferred list of trace sources for net devices but some devices only support a subset of the recommended sources. For the wifi promiscuous trace, it would be helpful to document that what is being traced corresponds to tcpdump "monitor" mode; namely, control and management frames are being captured. I think what you were trying to do with the ethernet header may be equivalent to the default "non-monitor" mode when tcpdump is run on a wireless interface. I think it is fine to just support monitor mode because there is much more information and because wireshark and tcpdump can display these extra frame traces. It would be useful to test, before you are done, that wireshark and tcpdump can still handle the promiscuous packet traces generated. Also, + .AddTraceSource ("PhyTxBackoff", + "Trace source indicating a packet has been delayed by the CSMA backoff process", + MakeTraceSourceAccessor (&CsmaNetDevice::m_phyTxBackoffTrace)) I thought you previously agreed that this trace source should be a mac level source? - Tom From tomh at tomh.org Tue Mar 3 10:21:16 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 03 Mar 2009 10:21:16 -0800 Subject: [Ns-developers] Regarding 802.15 MAC Layer In-Reply-To: <955e31df0903020622l56a5ca1bj173e3e43889aba74@mail.gmail.com> References: <955e31df0903020622l56a5ca1bj173e3e43889aba74@mail.gmail.com> Message-ID: <49AD751C.6070801@tomh.org> Ruturaj Dhekane wrote: > Hi, > > I am working on a Wireless Sensor Networks based research project. I would > like to simulate the WSN nodes. However 802.15.x MAC layer isnt currently > available with NS-3. > > I would like to have some pointers from the developer community regarding > writing our own MAC layer. (As in where do I begin, and How?) This is a piece of documentation that needs to be written. For starters, I would recommend starting by cloning the SimpleNetDevice and SimpleChannel found in src/node directory, and rename it to something else. This net device and channel simply pass packets between nodes. The next step might be to add a new header. A new header class needs to be written. the UDP header implementation (src/internet-node/ directory) probably is a simple-enough example of this. After some semblance of a header is being serialized to and from the packets, you can start to think of adding more logic and detail to the models; perhaps add a Phy class. For wireless channels, however, you will probably want to study the structure of the wifi netdevice before too long. > > Would also like to know certain fields in which I might be able to > contribute to NS-3 code in general. > > WPAN would be helpful since there seems to be a lot of interest. There is an ns-2 implementation from CUNY that might be portable. Also, see the earlier mail about GSOC project ideas. Tom From tomh at tomh.org Tue Mar 3 10:29:22 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 03 Mar 2009 10:29:22 -0800 Subject: [Ns-developers] how to get involved in ns-3 In-Reply-To: References: <8be4676d0903030612o198bb026pb4d0017814cc784f@mail.gmail.com> <49AD5868.2030000@tomh.org> Message-ID: <49AD7702.10000@tomh.org> > Hi Tom, > > on the contribution page, i found 3 tutorials, > > > * Marc Greis's tutorial > * Pedro Vale Estrela's help page > > * ns-3 for beginners > These were listed as examples of "user contributed" tutorials. I will update this web page shortly to avoid any confusion. In short, you probably want to look at the tutorials listed below. We have a project tutorial and manual available at: http://www.nsnam.org/tutorials.html Gustavo also contributed a tutorial recently (posted on the same page). Also, Mathieu and I just completed a tutorial yesterday that we will link from that page. Hope that helps, Tom From raj.b at gatech.edu Tue Mar 3 10:32:07 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Tue, 3 Mar 2009 13:32:07 -0500 Subject: [Ns-developers] Regression testing (Was: [Bug 370] ipv4-interface.h is installed) In-Reply-To: References: Message-ID: <12d69e490903031032y360ed9fawa80e3dc0eadb3b74@mail.gmail.com> On Tue, Mar 3, 2009 at 6:32 AM, Gustavo Carneiro wrote: > > > 2009/3/2 Raj Bhattacharjea >> >> On Mon, Mar 2, 2009 at 12:29 PM, Gustavo Carneiro >> wrote: >> > >> > One thing is not clear, however.? If you have a patch to test, you have >> > to >> > commit it first, and only then can you test it, since the regression >> > script >> > takes a branch name, not a repository.? Doesn't it kind of defeat the >> > purpose?? If a problem is detected in the patch, it will already be too >> > late >> > because it was already committed... >> > >> > I hope we are not supposed to create a new temporary branch for each >> > patch >> > we wish to test.? If so, you can expect me to never commit a patch again >> > during a maintenance period.? No offense, but I simply don't have time >> > or >> > patience to jump through all these hoops in order to fix a bug. >> > >> >> I see your concern; you've convinced me. ?I am willing to wait for the >> nightly test to run to see if someone broke the build on other >> platforms. ?Lets say it would be _nice_ if you could test on >> ns-regression, but it isn't mandatory to bugfix. >> >> This practice however will be strictly enforced in the week or so >> leading up to the release, as you suggest. > > Thanks. > > But I am noticing a new problem now.? I run the ns-3-run-tests.sh script > with a -m option, to send email with the results, but the script still keeps > running in the foreground.? Since the wiki page says it can take several > hours to complete, I need to be able to logout, but if I hit Ctrl-C the > regression testing is aborted.? nohup script & does not work because I have > no write permission to the file system.? I was expecting the tests to run in > background when -m option is given. > If you want to use nohup, I believe everyone has write permissions in the /tmp directory: cd /tmp nohup /usr/local/bin/ns-3-run-tests.sh -r ... -m ... & I think you can also use screen instead of nohup to accomplish this, but I am not very well versed in using that tool. -- 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 Tue Mar 3 10:43:12 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Tue, 3 Mar 2009 13:43:12 -0500 Subject: [Ns-developers] ns-3.4 release plans In-Reply-To: <49AD3667.6010800@tomh.org> References: <12d69e490901071434g1024a72fgdc5dfb74b9184c72@mail.gmail.com> <12d69e490903020859i75806b65l975144697687affc@mail.gmail.com> <49AD3667.6010800@tomh.org> Message-ID: <12d69e490903031043i4a21b86fq34d11b1835bae53b@mail.gmail.com> On Tue, Mar 3, 2009 at 8:53 AM, Tom Henderson wrote: > Raj Bhattacharjea wrote: > >>> From March 1st, release candidates will be released. ?The bug count >>> should >>> ideally be zero during this time, and any remaining bugs discovered will >>> be >>> ironed out by the the 18th of March, when the final release of ns3.4 is >>> made. >> >> I suggest we push this back to March 19. ?We have adopted a policy of >> consider P1 bugs as those which are broken behavior, and will be true >> blockers which will hold up the _release candidates_; ?that is, there >> will be no P1 bugs in ns-3.4-RC1 (otherwise, how is it a candidate for >> release?). ?Any bugs found from beating on RC1 will be fixed and >> posted as RC2, etc. > > Raj, > I'm OK with slipping the release two weeks if it means that we will get all > of the outstanding P1 bugs in your list fixed. ?However, I think we should > carefully consider whether additional bugs that come in will keep slipping > the release further. ?There is another option to slipping, which is to list > open bugs as "known issues", and perhaps even to later do a small > maintenance release. ?So, I would suggest that we try not to slip the > release further unless a major issue comes up that can't be fixed by April > 1. I like this idea. We should triage bugs that keep coming in, and at some point we'll have to draw a line and acknowledge that there are known issues in the release, but make the release anyway, since we can't hold up forever. A maintenance release like ns-3.2.1 sounds like a good idea. -- 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 Tue Mar 3 10:46:24 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Tue, 3 Mar 2009 13:46:24 -0500 Subject: [Ns-developers] Request to commit -fvisbility=hidden python bindings patch In-Reply-To: References: Message-ID: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com> On Tue, Mar 3, 2009 at 9:48 AM, Gustavo Carneiro wrote: > Hi Raj, > > May I commit the patch at [1] for ns 3.4?? It decreases python bindings size > (from 6 to 5 MB) and decreases its loading time (didn't measure, but the > documentation [2] claims it to be so...). Looks good, go ahead. -- 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 Tue Mar 3 10:50:22 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Tue, 3 Mar 2009 13:50:22 -0500 Subject: [Ns-developers] Request to commit -fvisbility=hidden python bindings patch In-Reply-To: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com> References: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com> Message-ID: <12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com> On Tue, Mar 3, 2009 at 1:46 PM, Raj Bhattacharjea wrote: > On Tue, Mar 3, 2009 at 9:48 AM, Gustavo Carneiro wrote: >> Hi Raj, >> >> May I commit the patch at [1] for ns 3.4?? It decreases python bindings size >> (from 6 to 5 MB) and decreases its loading time (didn't measure, but the >> documentation [2] claims it to be so...). > > Looks good, go ahead. BTW, I guess the result of yesterday's discussion regarding regression testing / bug 370 is that maintainers DON'T need permission to push changes during this phase. We will however, transition to that mode of operation at some point in the future, say the last week or two of this month -- Raj Bhattacharjea Georgia Institute of Technology School of Electrical and Computer Engineering Ph.D. Candidate Systems Analyst 404.894.2955 From craigdo at ee.washington.edu Tue Mar 3 11:10:22 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 3 Mar 2009 11:10:22 -0800 Subject: [Ns-developers] Request to commit -fvisbility=hidden pythonbindings patch In-Reply-To: <12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com> References: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com> <12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com> Message-ID: <92AC04275A0F4B71A641CFF2CED17415@CRAIGVAIO> > BTW, I guess the result of yesterday's discussion regarding regression > testing / bug 370 is that maintainers DON'T need permission to push > changes during this phase. We will however, transition to that mode > of operation at some point in the future, say the last week or two of > this month I found there were two periods when it was extremely helpful to lock down the dev repo and run *all* the tests before continuing. It's not as critical at other times ... 1) When major merges were happening -- I called this merge week. We really want to demonstrate that a new feature is going run on all of our supported platforms (yes, including Cygwin and osx ppc, not just on a subset of compilers). We want to make sure that new bits will run properly and not break existing code. It's really impossible to determine this against a moving target. I had times in which virtually everyone was committing changes to this or that module while we were trying to merge something new in. It's extremely painful at a minimum. I believe you have had the pleasure of experiencing this kind of thing, Raj :-) 2) During the code freeze/RC period. We are really striving for stability here. It is a really, really bad sign for the system to be broken in any way during this time. It would be bad for RC-n to come due and to have the release manager run the tests and discover that the system was broken the week before by a "bug fix." I think the release manager really needs help from the developers to make sure this doesn't happen; and I think we should start helping out perhaps a week before RC1 by starting to run all of these tests when we make changes. More testing eyes make for less catastrophic problems, so to speak. FWIW -- Craig From gjcarneiro at gmail.com Tue Mar 3 11:16:55 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 3 Mar 2009 19:16:55 +0000 Subject: [Ns-developers] Request to commit -fvisbility=hidden pythonbindings patch In-Reply-To: <92AC04275A0F4B71A641CFF2CED17415@CRAIGVAIO> References: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com> <12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com> <92AC04275A0F4B71A641CFF2CED17415@CRAIGVAIO> Message-ID: 2009/3/3 > > > BTW, I guess the result of yesterday's discussion regarding regression > > testing / bug 370 is that maintainers DON'T need permission to push > > changes during this phase. We will however, transition to that mode > > of operation at some point in the future, say the last week or two of > > this month > > I found there were two periods when it was extremely helpful to lock down > the dev repo and run *all* the tests before continuing. It's not as > critical at other times ... Craig, I don't understand what you mean by "*all* the tests". We have automated regression testing on several platforms and compilers. What more can we do manually, and why can't that manual work be done automatically by the build farm? > > > 1) When major merges were happening -- I called this merge week. We really > want to demonstrate that a new feature is going run on all of our supported > platforms (yes, including Cygwin and osx ppc, not just on a subset of > compilers). We want to make sure that new bits will run properly and not > break existing code. It's really impossible to determine this against a > moving target. I had times in which virtually everyone was committing > changes to this or that module while we were trying to merge something new > in. It's extremely painful at a minimum. I believe you have had the > pleasure of experiencing this kind of thing, Raj :-) > > 2) During the code freeze/RC period. We are really striving for stability > here. It is a really, really bad sign for the system to be broken in any > way during this time. It would be bad for RC-n to come due and to have the > release manager run the tests and discover that the system was broken the > week before by a "bug fix." I think the release manager really needs help > from the developers to make sure this doesn't happen; and I think we should > start helping out perhaps a week before RC1 by starting to run all of these > tests when we make changes. More testing eyes make for less catastrophic > problems, so to speak. Since we have regression testing, perhaps what we need is just to add more regression tests, as needed, not manually test things before releases. The main advantage of nightly regression tests is that you find out the next day if your commit broke something. If you only test for releases then it becomes much harder to determine what commit broke things, and how to fix. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From ruben at net.t-labs.tu-berlin.de Tue Mar 3 11:35:41 2009 From: ruben at net.t-labs.tu-berlin.de (Ruben Merz) Date: Tue, 03 Mar 2009 20:35:41 +0100 Subject: [Ns-developers] Request to commit -fvisbility=hidden pythonbindings patch In-Reply-To: <92AC04275A0F4B71A641CFF2CED17415@CRAIGVAIO> References: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com> <12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com> <92AC04275A0F4B71A641CFF2CED17415@CRAIGVAIO> Message-ID: <49AD868D.2010708@net.t-labs.tu-berlin.de> craigdo at ee.washington.edu wrote: >> BTW, I guess the result of yesterday's discussion regarding regression >> testing / bug 370 is that maintainers DON'T need permission to push >> changes during this phase. We will however, transition to that mode >> of operation at some point in the future, say the last week or two of >> this month > > I found there were two periods when it was extremely helpful to lock down > the dev repo and run *all* the tests before continuing. It's not as > critical at other times ... > > 1) When major merges were happening -- I called this merge week. We really > want to demonstrate that a new feature is going run on all of our supported > platforms (yes, including Cygwin and osx ppc, not just on a subset of > compilers). We want to make sure that new bits will run properly and not > break existing code. It's really impossible to determine this against a > moving target. I had times in which virtually everyone was committing > changes to this or that module while we were trying to merge something new > in. It's extremely painful at a minimum. I believe you have had the > pleasure of experiencing this kind of thing, Raj :-) I don't have lots of experience with this kind of issues, so maybe there is something I'm missing... Why don't you use a separate branch when this kind of merge happens? I.e. having a merge branch where you selectively apply and test each new feature separately? Best, Ruben > 2) During the code freeze/RC period. We are really striving for stability > here. It is a really, really bad sign for the system to be broken in any > way during this time. It would be bad for RC-n to come due and to have the > release manager run the tests and discover that the system was broken the > week before by a "bug fix." I think the release manager really needs help > from the developers to make sure this doesn't happen; and I think we should > start helping out perhaps a week before RC1 by starting to run all of these > tests when we make changes. More testing eyes make for less catastrophic > problems, so to speak. > > FWIW > > -- Craig > > From gjcarneiro at gmail.com Tue Mar 3 12:05:31 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 3 Mar 2009 20:05:31 +0000 Subject: [Ns-developers] Request to commit -fvisbility=hidden pythonbindings patch In-Reply-To: <49AD868D.2010708@net.t-labs.tu-berlin.de> References: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com> <12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com> <92AC04275A0F4B71A641CFF2CED17415@CRAIGVAIO> <49AD868D.2010708@net.t-labs.tu-berlin.de> Message-ID: 2009/3/3 Ruben Merz > > craigdo at ee.washington.edu wrote: > >> BTW, I guess the result of yesterday's discussion regarding regression > >> testing / bug 370 is that maintainers DON'T need permission to push > >> changes during this phase. We will however, transition to that mode > >> of operation at some point in the future, say the last week or two of > >> this month > > > > I found there were two periods when it was extremely helpful to lock down > > the dev repo and run *all* the tests before continuing. It's not as > > critical at other times ... > > > > 1) When major merges were happening -- I called this merge week. We > really > > want to demonstrate that a new feature is going run on all of our > supported > > platforms (yes, including Cygwin and osx ppc, not just on a subset of > > compilers). We want to make sure that new bits will run properly and > not > > break existing code. It's really impossible to determine this against a > > moving target. I had times in which virtually everyone was committing > > changes to this or that module while we were trying to merge something > new > > in. It's extremely painful at a minimum. I believe you have had the > > pleasure of experiencing this kind of thing, Raj :-) > > I don't have lots of experience with this kind of issues, so maybe there > is something I'm missing... Why don't you use a separate branch when > this kind of merge happens? I.e. having a merge branch where you > selectively apply and test each new feature separately? That is a great idea if: 1) the branch is common for all developers to-be-merged patches 2) nightly regression tests also test that branch > > > Best, > Ruben > > > 2) During the code freeze/RC period. We are really striving for > stability > > here. It is a really, really bad sign for the system to be broken in any > > way during this time. It would be bad for RC-n to come due and to have > the > > release manager run the tests and discover that the system was broken the > > week before by a "bug fix." I think the release manager really needs > help > > from the developers to make sure this doesn't happen; and I think we > should > > start helping out perhaps a week before RC1 by starting to run all of > these > > tests when we make changes. More testing eyes make for less catastrophic > > problems, so to speak. > > > > FWIW > > > > -- Craig > > > > > > > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From raj.b at gatech.edu Tue Mar 3 13:41:02 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Tue, 3 Mar 2009 16:41:02 -0500 Subject: [Ns-developers] Request to commit -fvisbility=hidden python bindings patch In-Reply-To: References: Message-ID: <12d69e490903031341y7a6e3389n646b0ba373227397@mail.gmail.com> On Tue, Mar 3, 2009 at 9:48 AM, Gustavo Carneiro wrote: > Hi Raj, > > May I commit the patch at [1] for ns 3.4?? It decreases python bindings size > (from 6 to 5 MB) and decreases its loading time (didn't measure, but the > documentation [2] claims it to be so...). > > Regards, > > [1] http://www.nsnam.org/bugzilla/show_bug.cgi?id=515 > [2] http://gcc.gnu.org/wiki/Visibility Do the python bindings need a rescan following this change? I am getting cryptic errors out of a fresh copy of ns-3-dev that seem to go away after I run ./waf --python-scan . -- Raj Bhattacharjea Georgia Institute of Technology School of Electrical and Computer Engineering Ph.D. Candidate Systems Analyst 404.894.2955 From craigdo at ee.washington.edu Tue Mar 3 14:37:11 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 3 Mar 2009 14:37:11 -0800 Subject: [Ns-developers] Request to commit -fvisbility=hidden pythonbindings patch In-Reply-To: <49AD868D.2010708@net.t-labs.tu-berlin.de> References: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com> <12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com> <92AC04275A0F4B71A641CFF2CED17415@CRAIGVAIO> <49AD868D.2010708@net.t-labs.tu-berlin.de> Message-ID: <2FD1445B51AC41F79B620AAA2B7A2435@CRAIGVAIO> > I don't have lots of experience with this kind of issues, so > maybe there > is something I'm missing... Why don't you use a separate branch when > this kind of merge happens? I.e. having a merge branch where you > selectively apply and test each new feature separately? We are merging private branches into the main development branch, which then becomes a release candidate, which then becomes a release. It is the main development branch we want to make sure works. It's hard to test a moving target, so during the time when lots of things are being merged into ns-3-dev, it is useful to have some controls in place regarding who is doing what. Now, you could take a snapshot of the development branch and call it a pre-release branch, but then you run into coherency problems, with bug fixes applied to one branch and not the other, or bug fixes in one branch depending on other things not applied to the other. It's up to the release manager how he wants to deal with this. I chose to have one real working branch named ns-3-dev. -- Craig From craigdo at ee.washington.edu Tue Mar 3 14:41:05 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 3 Mar 2009 14:41:05 -0800 Subject: [Ns-developers] Request to commit -fvisbility=hiddenpythonbindings patch In-Reply-To: References: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com><12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com><92AC04275A0F4B71A641CFF2CED17415@CRAIGVAIO> Message-ID: > Craig, I don't understand what you mean by "*all* the tests". We have > automated regression testing on several platforms and > compilers. What more > can we do manually, and why can't that manual work be done > automatically by > the build farm? Cygwin is a supported platform but there is no way to test it since there is no VM. There are examples that are not part of the main regression test suite since manual configuration or intervention is required (emu, tap). There are contrib pieces that need to be run and output interpreted (Joe's statistics stuff). There is the wifi-ad-hoc experiment stuff that needs to be run to make sure it didn't get broken. I'm sure there are more, but this is just off the top of my head. Tom is really good at finding stuff like this :-) We should have fully automated tests, but we just aren't there yet. -- Craig From ruben at net.t-labs.tu-berlin.de Tue Mar 3 14:59:08 2009 From: ruben at net.t-labs.tu-berlin.de (Ruben Merz) Date: Tue, 03 Mar 2009 23:59:08 +0100 Subject: [Ns-developers] Request to commit -fvisbility=hiddenpythonbindings patch In-Reply-To: References: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com><12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com><92AC04275A0F4B71A641CFF2CED17415@CRAIGVAIO> Message-ID: <49ADB63C.7010301@net.t-labs.tu-berlin.de> craigdo at ee.washington.edu wrote: >> Craig, I don't understand what you mean by "*all* the tests". We have >> automated regression testing on several platforms and >> compilers. What more >> can we do manually, and why can't that manual work be done >> automatically by >> the build farm? > > Cygwin is a supported platform but there is no way to test it since there is > no VM. There are examples that are not part of the main regression test > suite since manual configuration or intervention is required (emu, tap). > There are contrib pieces that need to be run and output interpreted (Joe's > statistics stuff). There is the wifi-ad-hoc experiment stuff that needs to > be run to make sure it didn't get broken. I'm sure there are more, but this > is just off the top of my head. Tom is really good at finding stuff like > this :-) What is the wifi-ad-hoc experiment stuff? Ruben > We should have fully automated tests, but we just aren't there yet. > > -- Craig > > From craigdo at ee.washington.edu Tue Mar 3 16:24:51 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Tue, 3 Mar 2009 16:24:51 -0800 Subject: [Ns-developers] Request to commit -fvisbility=hiddenpythonbindings patch In-Reply-To: <49ADB63C.7010301@net.t-labs.tu-berlin.de> References: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com><12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com><92AC04275A0F4B71A641CFF2CED17415@CRAIGVAIO> <49ADB63C.7010301@net.t-labs.tu-berlin.de> Message-ID: <5CE778835A754628895372FB13FE4A63@CRAIGVAIO> > What is the wifi-ad-hoc experiment stuff? examples/wifi-adhoc.cc Questions about why it takes so long to run, or whether it is broken or not pop up on the list every once in a while. -- Craig From ruben at net.t-labs.tu-berlin.de Wed Mar 4 01:35:36 2009 From: ruben at net.t-labs.tu-berlin.de (Ruben Merz) Date: Wed, 04 Mar 2009 10:35:36 +0100 Subject: [Ns-developers] wifi-adhoc.cc (was Re: Request to commit -fvisbility=hiddenpythonbindings patch) In-Reply-To: <5CE778835A754628895372FB13FE4A63@CRAIGVAIO> References: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com><12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com><92AC04275A0F4B71A641CFF2CED17415@CRAIGVAIO> <49ADB63C.7010301@net.t-labs.tu-berlin.de> <5CE778835A754628895372FB13FE4A63@CRAIGVAIO> Message-ID: <49AE4B68.1000309@net.t-labs.tu-berlin.de> craigdo at ee.washington.edu wrote: >> What is the wifi-ad-hoc experiment stuff? > > examples/wifi-adhoc.cc > > Questions about why it takes so long to run, or whether it is broken or not > pop up on the list every once in a while. So, is there anything that could/should be done about it: documentation? more explicit logging? a test to check it is not broken? a rewrite? Any other suggestion? Ruben > -- Craig > > -- Ruben Merz Deutsche Telekom Laboratories http://www.net.t-labs.tu-berlin.de/people/ruben_merz.shtml From timo.bingmann at student.kit.edu Wed Mar 4 02:43:49 2009 From: timo.bingmann at student.kit.edu (Timo Bingmann) Date: Wed, 4 Mar 2009 11:43:49 +0100 Subject: [Ns-developers] Tracing Rework In-Reply-To: References: <1235897009.6001.45.camel@mathieu-laptop> Message-ID: <200903041143.49266.timo.bingmann@student.kit.edu> Hello guys, am I correct that these trace sources are supposed to provide a common interface for all net devices? And this common interface is then used to create different types of tcpdump files. I noticed that you added a phyRxDropTrace to YansWifiPhy. I did the same in my testing code, but obviously I was more interested in the reason why the packet was dropped. The reason is indicated to the callback via an enum parameter. Beyond the drop reason there is a lot of interesting information that should also be passed to the trace callback. So how does this match up with your work on a common trace interface? Does that mean there are two subsequent trace sources calls: m_phyRxDropTrace(packet); m_phyRxDropTraceDetailed(packet, reason, rxPower, snr, ...); ? I for my part believe that there should be a common set of (optional) relative trace paths / names: MacTxStart, MacRxEnd, PhyRxDrop, PhyRxEnd. However the parameters must be adaptable to whatever interesting information the device has to export. These parameters must then be reconciled (i.e. dropped) in the helper module implementing the tcpdump output callback. Greetings Timo From gjcarneiro at gmail.com Wed Mar 4 02:55:47 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 4 Mar 2009 10:55:47 +0000 Subject: [Ns-developers] Request to commit -fvisbility=hidden python bindings patch In-Reply-To: <12d69e490903031341y7a6e3389n646b0ba373227397@mail.gmail.com> References: <12d69e490903031341y7a6e3389n646b0ba373227397@mail.gmail.com> Message-ID: 2009/3/3 Raj Bhattacharjea > On Tue, Mar 3, 2009 at 9:48 AM, Gustavo Carneiro > wrote: > > Hi Raj, > > > > May I commit the patch at [1] for ns 3.4? It decreases python bindings > size > > (from 6 to 5 MB) and decreases its loading time (didn't measure, but the > > documentation [2] claims it to be so...). > > > > Regards, > > > > [1] http://www.nsnam.org/bugzilla/show_bug.cgi?id=515 > > [2] http://gcc.gnu.org/wiki/Visibility > > Do the python bindings need a rescan following this change? I am > getting cryptic errors out of a fresh copy of ns-3-dev that seem to go > away after I run ./waf --python-scan . No re-scanning is needed, but the bindings .cc files need to be regenerated. Unfortunately the build system does not trigger a rebuild of the bindings when the required pybindgen version changes. As a work around, just rm -rf build/debug/bindings. Sorry about that. -- 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 Wed Mar 4 06:54:22 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 4 Mar 2009 14:54:22 +0000 Subject: [Ns-developers] Request to commit -fvisbility=hidden python bindings patch In-Reply-To: References: <12d69e490903031341y7a6e3389n646b0ba373227397@mail.gmail.com> Message-ID: 2009/3/4 Gustavo Carneiro > > > 2009/3/3 Raj Bhattacharjea > >> On Tue, Mar 3, 2009 at 9:48 AM, Gustavo Carneiro >> wrote: >> > Hi Raj, >> > >> > May I commit the patch at [1] for ns 3.4? It decreases python bindings >> size >> > (from 6 to 5 MB) and decreases its loading time (didn't measure, but the >> > documentation [2] claims it to be so...). >> > >> > Regards, >> > >> > [1] http://www.nsnam.org/bugzilla/show_bug.cgi?id=515 >> > [2] http://gcc.gnu.org/wiki/Visibility >> >> Do the python bindings need a rescan following this change? I am >> getting cryptic errors out of a fresh copy of ns-3-dev that seem to go >> away after I run ./waf --python-scan . > > > No re-scanning is needed, but the bindings .cc files need to be > regenerated. Unfortunately the build system does not trigger a rebuild of > the bindings when the required pybindgen version changes. As a work around, > just rm -rf build/debug/bindings. Sorry about that. > regression build farm showed it was a different problem. Apparently, gcc 4.x doesn't always support -fvisibility=hidden. Maybe it's a platform specific flag. In any case, should be fixed now, although I'm still waiting for confirmation from the build farm. > > > -- > Gustavo J. A. M. Carneiro > INESC Porto, Telecommunications and Multimedia Unit > "The universe is always one step beyond logic." -- Frank Herbert > -- 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 Wed Mar 4 07:36:23 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 04 Mar 2009 16:36:23 +0100 Subject: [Ns-developers] api breakage: bug 482 In-Reply-To: <1235562457.11372.18.camel@diese.inria.fr> References: <1235562457.11372.18.camel@diese.inria.fr> Message-ID: <1236180983.15903.15.camel@diese.inria.fr> it appears that we have most votes for: - StaticMobilityModel -> ConstantPositionMobilityModel - StaticSpeedMobilityModel -> ConstantVelocityMobilityModel - ConstantAccelerationMobilityModel Raj: are you ok if I push this fairly safe but potentially painful (for users) change sometime this week or next week ? Is there someone who is going to hate me for breaking their application code ? Mathieu On Wed, 2009-02-25 at 12:47 +0100, Mathieu Lacage wrote: > hi, > > This is an email asking for input on how to fix bug 482. Two options: > > 1) rename existing classes and add a new one: > - StaticMobilityModel -> ConstantPositionMobilityModel > - StaticSpeedMobilityModel -> ConstantSpeedMobilityModel > - ConstantAccelerationMobilityModel > > 2) add a new class: > - StaticAccelerationMobilityModel > > I don't care at all which option should be chosen but gustavo seems to > like 1) better which will break API while 2) won't break any API. Unless > there are dissenting voices, I would tend to follow him. Opinions ? Dear > RM ? > > Mathieu > From mathieu.lacage at sophia.inria.fr Wed Mar 4 08:01:37 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 04 Mar 2009 17:01:37 +0100 Subject: [Ns-developers] creating mercurial repos on code.nsnam.org Message-ID: <1236182497.15903.19.camel@diese.inria.fr> hi, I just noticed that recent versions of mercurial now support ssh-based remote repository creation: -bash-3.2$ hg init ssh://mathieu at code.nsnam.org/repositories/mathieu/ns-3-xml -bash-3.2$ hg push ssh://mathieu at code.nsnam.org/repositories/mathieu/ns-3-xml pushing to ssh://mathieu at code.nsnam.org/repositories/mathieu/ns-3-xml searching for changes alternatively the following also would work: -bash-3.2$ hg clone . ssh://mathieu at code.nsnam.org/repositories/mathieu/ns-3-xml regards, Mathieu From mathieu.lacage at sophia.inria.fr Wed Mar 4 08:09:46 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 04 Mar 2009 17:09:46 +0100 Subject: [Ns-developers] xml config store Message-ID: <1236182986.15903.28.camel@diese.inria.fr> hi, By popular demand, I hacked together support for global and default values, and xml input and output in ConfigStore: http://code.nsnam.org/mathieu/ns-3-xml The API: int main (...) { CommandLine cmd; cmd.Parse (...); ConfigStore config; config.ConfigureEarly (); ... topology creation config.ConfigureLate (); Simulator::Run (); } The above can be controlled from the command-line: ./build/debug/examples/csma-broadcast --ns3::ConfigStore::FileFormat=Xml --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::Filename=config.txt ./build/debug/examples/csma-broadcast --ns3::ConfigStore::FileFormat=Xml --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::Filename=config.txt and the file looks like this (full example attached to this email): ... ... Of course, you can write your own configuration file to specify only a subset of the above in any order, of course. I don't really have enough time to add the necessary code to GtkConfigStore to display the global and default values from ConfigureEarly and to add a dtd/xml schema so, I would tend to leave these as an exercise for interested users/developers. Mathieu -------------- next part -------------- From gjcarneiro at gmail.com Wed Mar 4 08:16:46 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Wed, 4 Mar 2009 16:16:46 +0000 Subject: [Ns-developers] creating mercurial repos on code.nsnam.org In-Reply-To: <1236182497.15903.19.camel@diese.inria.fr> References: <1236182497.15903.19.camel@diese.inria.fr> Message-ID: 2009/3/4 Mathieu Lacage > hi, > > I just noticed that recent versions of mercurial now support ssh-based > remote repository creation: > > -bash-3.2$ hg init > ssh://mathieu at code.nsnam.org/repositories/mathieu/ns-3-xml > -bash-3.2$hg push > ssh://mathieu at code.nsnam.org/repositories/mathieu/ns-3-xml > pushing to ssh://mathieu at code.nsnam.org/repositories/mathieu/ns-3-xml > searching for changes > > > alternatively the following also would work: > -bash-3.2$ hg clone . > ssh://mathieu at code.nsnam.org/repositories/mathieu/ns-3-xml Personally, I already knew this for a long time [1], but doesn't doing this trigger that huge email to the commits list with all the changesets? [1] the reason was that when I complained that it was bad that mercurial incompatibly changed repository file storage format in a micro version upgrade, I was told I should have been doing the hg clone . remote-url trick instead of manually copying the files, to avoid the problem. -- 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 Wed Mar 4 08:26:47 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 04 Mar 2009 17:26:47 +0100 Subject: [Ns-developers] creating mercurial repos on code.nsnam.org In-Reply-To: References: <1236182497.15903.19.camel@diese.inria.fr> Message-ID: <1236184007.26232.2.camel@diese.inria.fr> On Wed, 2009-03-04 at 16:16 +0000, Gustavo Carneiro wrote: > > alternatively the following also would work: > -bash-3.2$ hg clone . > ssh://mathieu at code.nsnam.org/repositories/mathieu/ns-3-xml > > Personally, I already knew this for a long time [1], but doesn't doing > this trigger that huge email to the commits list with all the > changesets? yes, but, is that a problem (it's not for me) ? > > [1] the reason was that when I complained that it was bad that > mercurial incompatibly changed repository file storage format in a > micro version upgrade, I was told I should have been doing the hg > clone . remote-url trick instead of manually copying the files, to > avoid the problem. yes, copying mercurial repos _across_ machines is a tricky business. > Mathieu From craigdo at ee.washington.edu Wed Mar 4 09:30:51 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 4 Mar 2009 09:30:51 -0800 Subject: [Ns-developers] wifi-adhoc.cc In-Reply-To: <49AE4B68.1000309@net.t-labs.tu-berlin.de> References: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com><12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com><92AC04275A0F4B71A641CFF2CED17415@CRAIGVAIO> <49ADB63C.7010301@net.t-labs.tu-berlin.de> <5CE778835A754628895372FB13FE4A63@CRAIGVAIO> <49AE4B68.1000309@net.t-labs.tu-berlin.de> Message-ID: > >> What is the wifi-ad-hoc experiment stuff? > > > > examples/wifi-adhoc.cc > > > > Questions about why it takes so long to run, or whether it > is broken or not > > pop up on the list every once in a while. > > So, is there anything that could/should be done about it: > documentation? > more explicit logging? a test to check it is not broken? a > rewrite? Any > other suggestion? There are a few issues here that I think run much deeper than adding a few lines of code, or even writing some words. - We are using most of the example programs to do double-duty as regression tests. This is not a good long-term solution for testing. We need a "real" test strategy, test harness and test programs to fully exercise our system. The examples should be treated as examples. - There really isn't any strategy for what kind of examples should be present to lead users through the system. IMO, ideally, the example programs should be tied to a tutorial and documentation system; and what the examples do and how they behave should be very thoroughly explained. - If I remember correctly, only three of those example programs have any kind of documentation associated with them and this is all in the single tutorial. Many of the examples are really mostly smoke-test programs that show a little about how to use a facility. - There should be some kind of "directory" documentation pointing to examples indexed by common tasks. For example, if someone wants to learn how to do real experiments on a wifi network, they should be able to go to our documentation and look up wifi. There, they should find tutorials on how to understand some simple examples, and find a path that progresses them to eventually work with something like wifi-adhoc and explain what it does, why it may take a long time to run, and how they can make a few simple changes. So, in order to sort this out I think we need to work on defining a test strategy and stop using examples as test programs. Then I think this becomes primarily a documentation issue. We need some consistent kind of documentation structure in which to document and "tutorialize" the resulting examples, with some real strategy on what kind of examples we need and how they tie into a larger picture. The problem, of course, is that I just described dedicated an ns-3 world with test and documentation organizations filled with test engineers and writers. We don't have these people. Perhaps the best thing to do is to find fairly dedicated maintainers for a test system and documentation. A couple of us have been trying to keep some level of dox and tests in place, but we are very wanting in those departments. Regards, -- Craig From craigdo at ee.washington.edu Wed Mar 4 09:59:02 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 4 Mar 2009 09:59:02 -0800 Subject: [Ns-developers] Tracing Rework In-Reply-To: <200903041143.49266.timo.bingmann@student.kit.edu> References: <1235897009.6001.45.camel@mathieu-laptop> <200903041143.49266.timo.bingmann@student.kit.edu> Message-ID: <4E6A1A63A4BD4CAF990C96544981A03C@CRAIGVAIO> > am I correct that these trace sources are supposed to provide > a common interface for all net devices? And this common > interface is then used to create different types of tcpdump files. I think we just decided that there should be a set of standard trace source names across net devices. It is up to the net device author which of these trace sources he or she wants to implement. Two of these trace sources are used for pcap tracing: Sniffer and PromiscSniffer. "Sniffer" has some problems, so "PromiscSniffer" is the "standard" and corresponds to what kinds of packets would be displayed in a tcpdump. Helpers turn the sniffed packets into pcap files as they currently do. > I noticed that you added a phyRxDropTrace to YansWifiPhy. I > did the same in my testing code, but obviously I was more > interested in the reason why the packet was dropped. The > reason is indicated to the callback via an enum parameter. > Beyond the drop reason there is a lot of interesting > information that should also be passed to the trace callback. This touches on one of the issues I've been wrestling with: what it is that actually comes over the callback. There are conflicting goals. On one hand, the whole point of the tracing system is to allow you to trace whatever it is you feel is appropriate, and pass whatever information in whatever form you need in the callback. The other is usability. In many of our devices, we've been trying to make the common trace hooks behave similarly. The tricky part is to get the balance between usability and usefulness right :-) The previous incarnation of the tracing hooks clearly didn't provide enough information. There were hooks called, "Drop" that were sometimes called in the tx path, sometimes called in the rx path and sometimes not called at all. There clearly was a need to do more. So the 64,000 euro question is: how far can we take this today. I've come to the conclusion that a statement of basic policy and the definition and implementation of a reasonable set of the trace hooks is about as much as I can do in the next couple of days. > So how does this match up with your work on a common trace > interface? Does that mean there are two subsequent trace > sources calls: > m_phyRxDropTrace(packet); > m_phyRxDropTraceDetailed(packet, reason, rxPower, snr, ...); > ? This lines up with what I was thinking. The name "PhyRxDrop" is a standard name indicating rough enough semantics that a user of a net device might suspect this trace source is implemented and of interest to her. Since, as I mentioned in another email, the contents of the packet passed back may be in various states of assembly and disassembly, you cannot just blindly use this trace source. You have got to figure out what passed to you in the callback. This could just as easily mean, "what list of parameters with what contents" as it could mean, "packets with llc/snap header and no Ethernet header." For example, I think it would be okay to see (pseudocode): CsmaNetDevice::m_phyRxDropTrace (packet); // with some implied reason for dropping a packet and YansWifiPhy::m_phyRxDropTrace (packet, SOME_WIFI_REASON, rxPower, ...); It's just that I really don't have the time to think through each trace source in the system and figure out what the useful set of parameters should be. > I for my part believe that there should be a common set of > (optional) relative trace paths / names: MacTxStart, > MacRxEnd, PhyRxDrop, PhyRxEnd. Sounds good. > However the parameters must be adaptable to whatever > interesting information the device has to export. > These parameters must then be reconciled (i.e. dropped) in > the helper module implementing the tcpdump output callback. I think this is in the spirit of the ns-3 tracing system. Regards, -- Craig From tjkopena at cs.drexel.edu Wed Mar 4 10:10:08 2009 From: tjkopena at cs.drexel.edu (Joseph Kopena) Date: Wed, 4 Mar 2009 13:10:08 -0500 Subject: [Ns-developers] NAT model for ns3--Gsoc2009 idea In-Reply-To: References: Message-ID: <13786f330903041010w7fafc968hb99acd6a78f5178c@mail.gmail.com> On Wed, Mar 4, 2009 at 3:31 AM, kaushik saurabh wrote: > *ns-3 reference manual > *ns-3 tutorial > *doxygen documentation > *linux networking > *and trying to parse the source code of ns-3, which i hv downloaded from > mercurial. > > I need some some help that is > Do u think, i should add some more things to my ToDo list?? > > If u think, there is something else i should go through, > and u would like to suggest me some more readings, > please do so! Hi Kaushik, Those all look like good places to start with ns-3. Getting a good handle on writing scripts and developing applications or other components will help a lot when it comes time to come up with technical ideas and a plan to include in your GSOC application. On that note though, I want to note for everyone that GOSC organizations will not be announced for a few weeks yet, and we won't know until then whether or not we will have funding for any students. Of course, either way, we are always happy to have more and more people continue to use and develop ns-3. Thx! -- - joe kopena right here and now From nbaldo at cttc.es Wed Mar 4 01:46:51 2009 From: nbaldo at cttc.es (Nicola Baldo) Date: Wed, 04 Mar 2009 10:46:51 +0100 Subject: [Ns-developers] EURASIP Journal: Special Issue on Simulators and Experimental Test-beds Design and Development for Wireless Networks Message-ID: <49AE4E0B.7080407@cttc.es> Given all the discussions we had at WNS3, I think that some of you might be interested in the following CFP... Regards, Nicola -------------------------------------------------------------------------------------------------/ Our apologies if you receive multiple copies of this CFP. -------------------------------------------------------------------------------------------------/ EURASIP JOURNAL ON WIRELESS COMMUNICATIONS AND NETWORKING (WCN) SIMULATORS AND EXPERIMENTAL TESTBEDS DESIGN AND DEVELOPMENT FOR WIRELESS NETWORKS The manuscripts are due June 1st, 2009 The CFP can be found directly at: http://www.hindawi.com/journals/wcn/si/setb.html ---------------------------------------------------------------------------------------------------------------------------------- Call for Papers In the context of wireless networking, performance evaluation of protocols and distributed applications is generally conducted through simulation or experimentation campaigns. An efficient and accurate simulation of wireless networks raises various issues which generally need to be addressed from several research domains simultaneously. As examples, we can consider the wireless physical layer modeling and simulation, the support of large-scale networks, the simulation of complex RF systems such as MIMO ones, the emulation of wireless nodes or the interconnection of simulators, experimental testbeds, and so forth. The aim of this Special Issue is to bring together academic and industry researchers and practitioners from both the wireless networking and the simulation communities to discuss current and future trends in simulation or experimentation techniques, models, and practices for the future communication system and to foster interdisciplinary collaborative research in this area. The guest editors seek high-quality papers on aspects of wireless network simulation, and value both theoretical and practical research contributions. Topics of interest include, but are not limited to: * Radio medium modeling and cross-layer simulation * Scalability, large-scale networks support * Validation of simulators and simulation results * Simulators benchmarking and comparisons * Fluid-flow simulation for assessing QoS in large-scale networks * Support of new emerging technologies (WiMax, 3.5G, Wireless Mesh Networks, 802.11x, etc.) in simulators * Support of advanced RF systems (Multi-carrier schemes, MIMO, smart-antenna) in simulators * Wireless node simulation or emulation * Interoperability of simulators, emulators, and experiments * Support of distributed physical layer schemes (distributed signal processing; cooperative schemes) * Distributed simulation, and scalability of simulators * Implementation of simulators * Experimental testbeds for wireless networks * Methodology for protocol and distributed application performance evaluation * SDR techniques, cognitive radio approaches, dynamic spectrum access testbeds, and simulators as well as modeling * Simulation and testbeds for cooperative communication protocols Before submission, authors should carefully read over the journal's Author Guidelines, which are located at http://www.hindawi.com/journals/wcn/guidelines.html. Prospective authors should submit an electronic copy of their complete manuscript through the journal Manuscript Tracking System at http://mts.hindawi.com/, according to the following timetable: Manuscript Due: June 1, 2009 First Round of Reviews: September 1, 2009 Publication Date: December 1, 2009 Lead Guest Editor * Faouzi Bader , Centre Tecnol?gico de Telecomunicaciones de Cataluya (CTTC), PMT, Spain Guest Editors * Guillame Chelius , Institut National de Recherche en Informatique et en Automatique (INRA), France * Christian Ibars , Centre Tecnol?gico de Telecomunicaciones de Cataluya (CTTC), PMT, Spain * Mohamed Ibnkahla , Department of Electrical and Computer Engineering, Queen's University, Canada * Nikos Passas , Department of Informatics and Telecommunications, University of Athens, Greece * Arnd-Ragnar Rhiemeier , Defence Electronics, EADS Deutschland GmbH, Germany From tjkopena at cs.drexel.edu Wed Mar 4 11:21:22 2009 From: tjkopena at cs.drexel.edu (Joseph Kopena) Date: Wed, 4 Mar 2009 14:21:22 -0500 Subject: [Ns-developers] NAT model for ns3--Gsoc2009 idea In-Reply-To: References: <13786f330903041010w7fafc968hb99acd6a78f5178c@mail.gmail.com> Message-ID: <13786f330903041121o228f3c8em11a78a774c7ac969@mail.gmail.com> On Wed, Mar 4, 2009 at 1:35 PM, kaushik saurabh wrote: > can u just tell me little more on >>Getting a good handle on writing scripts >>developing applications or other components > > Is it that i should also focus on how to write good scripts as well..??? Hi Kaushik, I mean scripts in the sense of ns-3 simulations, which you can setup & run from either C++ or python. An important foundation for understanding the whole system and thinking about a project is simply being comfortable with creating new simulations---varying network topologies & devices, applications, etc. A simple point perhaps, but an important one. -- - joe kopena right here and now From roideuniverse at gmail.com Tue Mar 3 10:14:00 2009 From: roideuniverse at gmail.com (kaushik saurabh) Date: Tue, 3 Mar 2009 23:44:00 +0530 Subject: [Ns-developers] how to get involved in ns-3 In-Reply-To: <49AD5868.2030000@tomh.org> References: <8be4676d0903030612o198bb026pb4d0017814cc784f@mail.gmail.com> <49AD5868.2030000@tomh.org> Message-ID: On Tue, Mar 3, 2009 at 9:48 PM, Tom Henderson wrote: > vivek rathod wrote: > >> Hello all, >> >> i am new to ns 2/ ns3 . i want to get to the development side of ns-3. i >> have good knowledge and implementations skills in c++ and python. >> >> could you please tell me where to start. if there is some detailed >> resource >> for new developers please send me the link. >> >> thank you >> >> vivek >> > > Vivek, > For starters, you can browse this page: > http://www.nsnam.org/contributing.html > and also our wiki, tutorial, and manual. > > If you are looking for a project idea, we have listed several on our GSOC > page: > http://www.nsnam.org/wiki/index.php/Gsoc2009 > > - Tom > Hi Tom, on the contribution page, i found 3 tutorials, - Marc Greis's tutorial - Pedro Vale Estrela's help page - ns-3 for beginners if i dont read all the 3, and go with ns-3 for beginers, wiki and manual, i will be missing some important points , mentioned in the other 2 of them? -- Greetings, roide :) From roideuniverse at gmail.com Tue Mar 3 10:49:26 2009 From: roideuniverse at gmail.com (kaushik saurabh) Date: Wed, 4 Mar 2009 00:19:26 +0530 Subject: [Ns-developers] how to get involved in ns-3 In-Reply-To: <49AD7702.10000@tomh.org> References: <8be4676d0903030612o198bb026pb4d0017814cc784f@mail.gmail.com> <49AD5868.2030000@tomh.org> <49AD7702.10000@tomh.org> Message-ID: On Tue, Mar 3, 2009 at 11:59 PM, Tom Henderson wrote: > > Hi Tom, >> >> on the contribution page, i found 3 tutorials, >> >> * Marc Greis's tutorial >> * Pedro Vale Estrela's help page >> >> * ns-3 for beginners >> < >> http://www-sop.inria.fr/mistral/personnel/Eitan.Altman/COURS-NS/n3.pdf> >> > > These were listed as examples of "user contributed" tutorials. I will > update this web page shortly to avoid any confusion. In short, you probably > want to look at the tutorials listed below. > > We have a project tutorial and manual available at: > http://www.nsnam.org/tutorials.html > > Gustavo also contributed a tutorial recently (posted on the same page). > Also, Mathieu and I just completed a tutorial yesterday that we will link > from that page. > > Hope that helps, > Tom > hi, obviously that will help.i will go through all of them. There is one particular question i wanted to ask. i was thinking about the gsoc-2009 idea of NAT ipv4 implementation, and then extend it. As the idea states there is no support for NAT in ns-3, and i think there should be some kind of NAT support.! Can u just point me, which areas i should focus on while goint through the tutorials, and manuals, and exactly what area of code i should hit, when going through the source code of ns-3. Just a small hint would be enough for me! -- Greetings, roide :) From roideuniverse at gmail.com Wed Mar 4 00:31:09 2009 From: roideuniverse at gmail.com (kaushik saurabh) Date: Wed, 4 Mar 2009 14:01:09 +0530 Subject: [Ns-developers] NAT model for ns3--Gsoc2009 idea Message-ID: hi to ns-3 developers, i was interested in this idea of developing Nat model for ns-3. In order to write my application on this topic /* i m still in very early stages, and this is what i hv planned to do. */ i m going through *ns-3 reference manual *ns-3 tutorial *doxygen documentation *linux networking *and trying to parse the source code of ns-3, which i hv downloaded from mercurial. I need some some help that is Do u think, i should add some more things to my ToDo list?? If u think, there is something else i should go through, and u would like to suggest me some more readings, please do so! thanx. -- Greetings, roide From roideuniverse at gmail.com Wed Mar 4 11:29:01 2009 From: roideuniverse at gmail.com (kaushik saurabh) Date: Thu, 5 Mar 2009 00:59:01 +0530 Subject: [Ns-developers] NAT model for ns3--Gsoc2009 idea In-Reply-To: <13786f330903041121o228f3c8em11a78a774c7ac969@mail.gmail.com> References: <13786f330903041010w7fafc968hb99acd6a78f5178c@mail.gmail.com> <13786f330903041121o228f3c8em11a78a774c7ac969@mail.gmail.com> Message-ID: On Thu, Mar 5, 2009 at 12:51 AM, Joseph Kopena wrote: > On Wed, Mar 4, 2009 at 1:35 PM, kaushik saurabh > wrote: > > can u just tell me little more on > >>Getting a good handle on writing scripts > >>developing applications or other components > > > > Is it that i should also focus on how to write good scripts as well..??? > > Hi Kaushik, > > I mean scripts in the sense of ns-3 simulations, which you can setup & > run from either C++ or python. An important foundation for > understanding the whole system and thinking about a project is simply > being comfortable with creating new simulations---varying network > topologies & devices, applications, etc. A simple point perhaps, but > an important one. > > -- > - joe kopena > right here and now > yes. from where i see, this looks like a important one! :) -- Greetings, roide From roideuniverse at gmail.com Wed Mar 4 10:35:57 2009 From: roideuniverse at gmail.com (kaushik saurabh) Date: Thu, 5 Mar 2009 00:05:57 +0530 Subject: [Ns-developers] NAT model for ns3--Gsoc2009 idea In-Reply-To: <13786f330903041010w7fafc968hb99acd6a78f5178c@mail.gmail.com> References: <13786f330903041010w7fafc968hb99acd6a78f5178c@mail.gmail.com> Message-ID: On Wed, Mar 4, 2009 at 11:40 PM, Joseph Kopena wrote: > On Wed, Mar 4, 2009 at 3:31 AM, kaushik saurabh > wrote: > > *ns-3 reference manual > > *ns-3 tutorial > > *doxygen documentation > > *linux networking > > *and trying to parse the source code of ns-3, which i hv downloaded from > > mercurial. > > > > I need some some help that is > > Do u think, i should add some more things to my ToDo list?? > > > > If u think, there is something else i should go through, > > and u would like to suggest me some more readings, > > please do so! > > Hi Kaushik, > > Those all look like good places to start with ns-3. Getting a good > handle on writing scripts and developing applications or other > components will help a lot when it comes time to come up with > technical ideas and a plan to include in your GSOC application. > > On that note though, I want to note for everyone that GOSC > organizations will not be announced for a few weeks yet, and we won't > know until then whether or not we will have funding for any students. > Of course, either way, we are always happy to have more and more > people continue to use and develop ns-3. > > Thx! > > -- > - joe kopena > right here and now > hi joe, can u just tell me little more on >Getting a good handle on writing scripts >developing applications or other components Is it that i should also focus on how to write good scripts as well..??? -- Greetings, roide From rbhattacharjea at gmail.com Thu Mar 5 08:25:33 2009 From: rbhattacharjea at gmail.com (raj bhattacharjea) Date: Thu, 5 Mar 2009 11:25:33 -0500 Subject: [Ns-developers] api breakage: bug 482 In-Reply-To: <1236180983.15903.15.camel@diese.inria.fr> References: <1235562457.11372.18.camel@diese.inria.fr> <1236180983.15903.15.camel@diese.inria.fr> Message-ID: <12d69e490903050825l16cb0283h12ffe2904b71870f@mail.gmail.com> On Wed, Mar 4, 2009 at 10:36 AM, Mathieu Lacage wrote: > it appears that we have most votes for: > > ?- StaticMobilityModel -> ConstantPositionMobilityModel > ?- StaticSpeedMobilityModel -> ConstantVelocityMobilityModel > ?- ConstantAccelerationMobilityModel > > Raj: are you ok if I push this fairly safe but potentially painful (for > users) change sometime this week or next week ? Is there someone who is > going to hate me for breaking their application code ? > > Mathieu > Yes; please also make sure to check in something about the renaming in the CHANGES.html file. -- Raj Bhattacharjea Georgia Institute of Technology School of Electrical and Computer Engineering Ph.D. Candidate Systems Analyst 404.894.2955 From mk.banchi at gmail.com Thu Mar 5 15:07:57 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Fri, 06 Mar 2009 00:07:57 +0100 Subject: [Ns-developers] Problems with ObjectFactory Message-ID: <49B05B4D.3050609@gmail.com> Hi all, i have some problems with ObjectFactory. I'm using it in a new Helper class to set a MSDU aggregator: MsduAggregatorHelper::SetAggregatorType (std::string aggregatorType, ...) { ... m_aggregator.SetTypeId (aggregatorType); ... } MsduAggregatorHelper::Install (...) { ... Ptr aggregator = m_aggregator.Create (); ... } If i try to use this helper from a script an error occurs: Requested constructor for ns3::Node but it does not have one. The error is originated in IidManager::GetConstructor () method. I have verified that m_aggregator.SetTypeId ("ns3::MsduStandardAggregator"); doens't fail. The method ObjectFactory::Create instead fails. That's strange...even if i call ObjectFactory::SetTypeId () with "ns3::MsduStandardAggregator" as parameter, it's looking for a constructor for ns3::Node. Any idea? Thanks, Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org id-msn: mb11684 at hotmail.com PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3410 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090306/169eb5dc/smime.bin From mathieu.lacage at sophia.inria.fr Fri Mar 6 00:00:34 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 06 Mar 2009 09:00:34 +0100 Subject: [Ns-developers] Problems with ObjectFactory In-Reply-To: <49B05B4D.3050609@gmail.com> References: <49B05B4D.3050609@gmail.com> Message-ID: <1236326434.3381.0.camel@diese.inria.fr> On Fri, 2009-03-06 at 00:07 +0100, Mirko Banchi wrote: > Hi all, > > i have some problems with ObjectFactory. I'm using it in a new Helper > class to set a MSDU aggregator: > > MsduAggregatorHelper::SetAggregatorType (std::string aggregatorType, ...) > { > ... > m_aggregator.SetTypeId (aggregatorType); > ... > } > > MsduAggregatorHelper::Install (...) > { > ... > > Ptr aggregator = m_aggregator.Create (); > ... > > } > > If i try to use this helper from a script an error occurs: > > Requested constructor for ns3::Node but it does not have one. > > The error is originated in IidManager::GetConstructor () method. > > I have verified that > > m_aggregator.SetTypeId ("ns3::MsduStandardAggregator"); > > doens't fail. The method ObjectFactory::Create instead fails. > > That's strange...even if i call ObjectFactory::SetTypeId () with > "ns3::MsduStandardAggregator" as parameter, it's looking for a > constructor for ns3::Node. > > Any idea? yes, it's an easy one :) You need to add a call to AddConstructor () in MsduStandardAggregator::GetTypeId > > Thanks, > Mirko > From gjcarneiro at gmail.com Fri Mar 6 03:48:15 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 6 Mar 2009 11:48:15 +0000 Subject: [Ns-developers] no space left on device Message-ID: Heads up: "no space left on device" means lack of disk space on one of the regression testing hosts, not a bug in ns-3-dev... 2009/3/6 > Fri Mar 6 02:50:08 PST 2009 > > download.py success > Regression testing for machine: ns-regression > Linux 2.6.24-19-server x86_64 > g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3) > ----------------------------- > SUCCESS: waf -d debug configure; ./waf --valgrind --regression passed on > ns-3-dev > SUCCESS: waf -d optimized configure; ./waf --valgrind --regression passed > on ns-3-dev > > Regression testing for machine: ns-regression > Linux 2.6.24-19-server x86_64 > g++-3.4 (GCC) 3.4.6 (Ubuntu 3.4.6-6ubuntu5) > ----------------------------- > SUCCESS: waf -d debug configure; ./waf --regression passed on ns-3-dev > > Regression testing for machine: ns-ubuntu-intrepid > Linux 2.6.27-2-generic i686 > g++ (Ubuntu 4.3.2-1ubuntu11) 4.3.2 > ----------------------------- > [632/654] regression-test (test-csma-bridge) > [633/654] regression-test (test-csma-broadcast) > [634/654] regression-test (test-csma-multicast) > [635/654] regression-test (test-csma-one-subnet) > [636/654] regression-test (test-csma-packet-socket) > [637/654] regression-test (test-csma-ping) > [638/654] regression-test (test-csma-raw-ip-socket) > [639/654] regression-test (test-csma-star) > [640/654] regression-test (test-dynamic-global-routing) > Entering directory `/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/build' > PASS test-csma-bridge > PASS test-csma-broadcast > PASS test-csma-multicast > PASS test-csma-one-subnet > PASS test-csma-packet-socket > PASS test-csma-ping > PASS test-csma-raw-ip-socket > ---------- > Traces differ in test: test-csma-star > Reference traces in directory: > /tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev-ref-traces/csma-star.ref > Traces in directory: > /tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/build/debug/regression/traces/csma-star.ref > Run the following command for details: > diff -u > /tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev-ref-traces/csma-star.ref > /tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/build/debug/regression/traces/csma-star.ref > Or re-run regression testing with option -v > ---------- > FAIL test-csma-star > Traceback (most recent call last): > File "/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/waf", line 127, in > > Scripting.prepare(t, cwd, VERSION, wafdir) > File > "/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/.waf-1.5.3-ee19efc5fb177979684a69740de63fc8/wafadmin/Scripting.py", > line 123, in prepare > prepare_impl(t,cwd,ver,wafdir) > File > "/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/.waf-1.5.3-ee19efc5fb177979684a69740de63fc8/wafadmin/Scripting.py", > line 116, in prepare_impl > main() > File > "/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/.waf-1.5.3-ee19efc5fb177979684a69740de63fc8/wafadmin/Scripting.py", > line 186, in main > bld.compile() > File > "/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/.waf-1.5.3-ee19efc5fb177979684a69740de63fc8/wafadmin/Build.py", > line 149, in compile > self.save() > File > "/tmp/ns-commits/tests/tmp/ns-3-allinone/ns-3-dev/.waf-1.5.3-ee19efc5fb177979684a69740de63fc8/wafadmin/Build.py", > line 94, in save > cPickle.dump(data,file,-1) > IOError: [Errno 28] No space left on device > FAILURE: waf -d debug configure; ./waf --regression failed on > ns-ubuntu-intrepid > _______________________________________________ > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From mk.banchi at gmail.com Fri Mar 6 04:15:16 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Fri, 06 Mar 2009 13:15:16 +0100 Subject: [Ns-developers] Problems with ObjectFactory In-Reply-To: <1236326434.3381.0.camel@diese.inria.fr> References: <49B05B4D.3050609@gmail.com> <1236326434.3381.0.camel@diese.inria.fr> Message-ID: <49B113D4.6000001@gmail.com> > yes, it's an easy one :) > > You need to add a call to AddConstructor () in > MsduStandardAggregator::GetTypeId > I have already this...:( MsduStandardAggregator::GetTypeId appears like this: TypeId MsduStandardAggregator::GetTypeId (void) { static TypeId tid = TypeId ("ns3::MsduStandardAggregator") .SetParent () .AddConstructor () .AddAttribute ("MaxAmsduSize", "Max length in byte of an A-MSDU", UintegerValue (7935), MakeUintegerAccessor (&MsduStandardAggregator::m_maxAmsduLength), MakeUintegerChecker ()) ; return tid; } I don't know the reason but seems that m_tid field in ObjectFactory (returned by TypeId::LookupByName method) contains an uid referring to ns3::Node. Regards, Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org id-msn: mb11684 at hotmail.com PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3410 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090306/3ae7e2d6/smime.bin From mathieu.lacage at sophia.inria.fr Fri Mar 6 04:23:44 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Fri, 06 Mar 2009 13:23:44 +0100 Subject: [Ns-developers] Problems with ObjectFactory In-Reply-To: <49B113D4.6000001@gmail.com> References: <49B05B4D.3050609@gmail.com> <1236326434.3381.0.camel@diese.inria.fr> <49B113D4.6000001@gmail.com> Message-ID: <1236342224.3381.4.camel@diese.inria.fr> On Fri, 2009-03-06 at 13:15 +0100, Mirko Banchi wrote: > > yes, it's an easy one :) > > > > You need to add a call to AddConstructor () in > > MsduStandardAggregator::GetTypeId > > > > I have already this...:( > MsduStandardAggregator::GetTypeId appears like this: > > TypeId > MsduStandardAggregator::GetTypeId (void) > { > static TypeId tid = TypeId ("ns3::MsduStandardAggregator") > .SetParent () > .AddConstructor () > .AddAttribute ("MaxAmsduSize", "Max length in byte of an A-MSDU", > UintegerValue (7935), > MakeUintegerAccessor > (&MsduStandardAggregator::m_maxAmsduLength), > MakeUintegerChecker ()) > ; > return tid; > } > > I don't know the reason but seems that m_tid field in ObjectFactory > (returned by TypeId::LookupByName method) contains an uid referring to > ns3::Node. uh, weird. You are saying that: TypeId::LookupByName ("ns3::MsduStandardAggregator").GetName () returns "ns3::Node" ? Maybe you should try to add NS_OBJECT_ENSURE_REGISTERED (MsduStandardAggregator) in msdu-standard-aggregator.cc Are you sure that GetTypeId is declared a static member of MsduStandardAggregator ? Mathieu From tazaki at sfc.wide.ad.jp Thu Mar 5 22:50:21 2009 From: tazaki at sfc.wide.ad.jp (Hajime Tazaki) Date: Fri, 06 Mar 2009 15:50:21 +0900 Subject: [Ns-developers] About real-world application integration Message-ID: Hi All, Now I'm working GNU Zebra bridge function to ns-3. #Note that not for Quagga, but I believe that quagga also works. Is there anyone who works on this topic? First of all, I tried to use the following branch [1] http://code.nsnam.org/lj/quagga-porting/ but it seems not to be worked. So I integrate [1,2,3,4] based on [2] branch. Although there is a lot of issues to fix, such as - Focusing on only my software (modified zebra) which use only ICMP6 and UDP6. - IP{v4,v6} construction can be reorganized as doing in "tomh/ns-3-ip" - routing table in ns3 can handle longest match prefix - performance is not so good (max node is 100?) - make patches for HEAD branch - and, etc... but current snapshot of this work is available at http://www.sfc.wide.ad.jp/~tazaki/hg/hgwebdir.cgi/ns-3-simu_zebra_ipv6/ Currently I can run simulation about 50nodes with Tree Discovery procotol(draft-thubert-tree-discovery) and OLSRv1 with IPv6 extension with this repo. Any comments and suggestions are appreciate. [2] http://code.nsnam.org/mathieu/ns-3-simu/ [3] https://svnet.u-strasbg.fr/hg/ns-3-ipv6/ [4] http://code.nsnam.org/gjc/ns-3-pyviz regards, hajime From tomh at tomh.org Sun Mar 8 22:10:19 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 08 Mar 2009 22:10:19 -0700 Subject: [Ns-developers] About real-world application integration In-Reply-To: References: Message-ID: <49B4A4BB.8010302@tomh.org> > > [1] http://code.nsnam.org/lj/quagga-porting/ > [2] http://code.nsnam.org/mathieu/ns-3-simu/ > [3] https://svnet.u-strasbg.fr/hg/ns-3-ipv6/ > [4] http://code.nsnam.org/gjc/ns-3-pyviz > Hajime, My goal is to support this entire combination that you cite ([1]-[4]), and support quagga via the process API under development in [2]. My understanding of the status of this is that the loader in [2] must be finished, and then the netlink extensions begun in [1] must next be completed. Presently, my main focus in March will be the ipv4 rework and also then the IPv6 merge [3]. Then, once item [2] is finished, I will prioritize finishing [1]. > http://www.sfc.wide.ad.jp/~tazaki/hg/hgwebdir.cgi/ns-3-simu_zebra_ipv6/ > > Currently I can run simulation about 50nodes with Tree > Discovery procotol(draft-thubert-tree-discovery) and OLSRv1 > with IPv6 extension with this repo. > > Any comments and suggestions are appreciate. I will try to review this later this week. Perhaps you can also review the proposed IPv4 rework (planned for ns-3.5) when the time comes later this month? Regards, Tom From tomh at tomh.org Sun Mar 8 22:19:52 2009 From: tomh at tomh.org (Tom Henderson) Date: Sun, 08 Mar 2009 22:19:52 -0700 Subject: [Ns-developers] xml config store In-Reply-To: <1236182986.15903.28.camel@diese.inria.fr> References: <1236182986.15903.28.camel@diese.inria.fr> Message-ID: <49B4A6F8.1000301@tomh.org> Mathieu Lacage wrote: > hi, > > By popular demand, I hacked together support for global and default > values, and xml input and output in ConfigStore: > > http://code.nsnam.org/mathieu/ns-3-xml > > The API: > > int main (...) > { > CommandLine cmd; > cmd.Parse (...); > > ConfigStore config; > config.ConfigureEarly (); > > ... topology creation > > config.ConfigureLate (); > > Simulator::Run (); > } > > The above can be controlled from the command-line: > > ./build/debug/examples/csma-broadcast --ns3::ConfigStore::FileFormat=Xml > --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::Filename=config.txt > ./build/debug/examples/csma-broadcast --ns3::ConfigStore::FileFormat=Xml > --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::Filename=config.txt > > and the file looks like this (full example attached to this email): > > > > > value="wifia-6mbs"/> > ... > value="ns3::DefaultSimulatorImpl"/> > > > > > ... > path="/$ns3::NodeListPriv/NodeList/2/$ns3::Node/$ns3::ArpL3Protocol/CacheList/0/$ns3::ArpCache/MaxRetries" value="3"/> > path="/$ns3::NodeListPriv/NodeList/2/$ns3::Node/$ns3::ArpL3Protocol/CacheList/0/$ns3::ArpCache/PendingQueueSize" value > ="3"/> > > > Of course, you can write your own configuration file to specify only a > subset of the above in any order, of course. > > I don't really have enough time to add the necessary code to > GtkConfigStore to display the global and default values from > ConfigureEarly and to add a dtd/xml schema so, I would tend to leave > these as an exercise for interested users/developers. > > Mathieu > Mathieu, Thanks for this extension, which seemed to be a popular suggestion at Simutools last week. I would be in favor of merging this for ns-3.4 (if review and testing works out), and then moving this feature out of contrib/ into the main tree for ns-3.5 (plus, updating GtkConfigStore at that time). Suggested name changes: - config.ConfigureEarly (); + config.ConfigureDefaults (); - config.ConfigureLate (); + config.ConfigureAttributes (); From tazaki at sfc.wide.ad.jp Mon Mar 9 05:26:41 2009 From: tazaki at sfc.wide.ad.jp (Hajime Tazaki) Date: Mon, 09 Mar 2009 21:26:41 +0900 Subject: [Ns-developers] About real-world application integration In-Reply-To: <49B4A4BB.8010302@tomh.org> References: <49B4A4BB.8010302@tomh.org> Message-ID: Hi Tom, Thanks for the response. At Sun, 08 Mar 2009 22:10:19 -0700, Tom Henderson wrote: > > http://www.sfc.wide.ad.jp/~tazaki/hg/hgwebdir.cgi/ns-3-simu_zebra_ipv6/ > > > > Currently I can run simulation about 50nodes with Tree > > Discovery procotol(draft-thubert-tree-discovery) and OLSRv1 > > with IPv6 extension with this repo. > > > > Any comments and suggestions are appreciate. > >I will try to review this later this week. Perhaps you can also review >the proposed IPv4 rework (planned for ns-3.5) when the time comes later >this month? Okay, I'll try to review too. regards, hajime From mathieu.lacage at sophia.inria.fr Mon Mar 9 11:59:08 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 09 Mar 2009 19:59:08 +0100 Subject: [Ns-developers] xml config store In-Reply-To: <49B4A6F8.1000301@tomh.org> References: <1236182986.15903.28.camel@diese.inria.fr> <49B4A6F8.1000301@tomh.org> Message-ID: <1236625148.7523.13.camel@mathieu-laptop> On Sun, 2009-03-08 at 22:19 -0700, Tom Henderson wrote: > Simutools last week. I would be in favor of merging this for ns-3.4 (if > review and testing works out), and then moving this feature out of testing done. > contrib/ into the main tree for ns-3.5 (plus, updating GtkConfigStore at > that time). ok. > > Suggested name changes: > > - config.ConfigureEarly (); > + config.ConfigureDefaults (); > > - config.ConfigureLate (); > + config.ConfigureAttributes (); done. Mathieu From mathieu.lacage at sophia.inria.fr Mon Mar 9 12:04:01 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 09 Mar 2009 20:04:01 +0100 Subject: [Ns-developers] how to get involved in ns-3 In-Reply-To: References: <8be4676d0903030612o198bb026pb4d0017814cc784f@mail.gmail.com> <49AD5868.2030000@tomh.org> <49AD7702.10000@tomh.org> Message-ID: <1236625441.7523.16.camel@mathieu-laptop> On Wed, 2009-03-04 at 00:19 +0530, kaushik saurabh wrote: > On Tue, Mar 3 > Can u just point me, which areas i should focus on while goint through the > tutorials, and manuals, > and exactly what area of code i should hit, when going through the source > code of ns-3. > > Just a small hint would be enough for me! The IPv4 stack is implemented in src/internet-stack/ipv4-l3-protocol.cc in case you have not figured it out already. (sorry for this very late answer) Mathieu From mathieu.lacage at sophia.inria.fr Tue Mar 10 06:57:05 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 10 Mar 2009 14:57:05 +0100 Subject: [Ns-developers] api breakage: bug 482 In-Reply-To: <12d69e490903050825l16cb0283h12ffe2904b71870f@mail.gmail.com> References: <1235562457.11372.18.camel@diese.inria.fr> <1236180983.15903.15.camel@diese.inria.fr> <12d69e490903050825l16cb0283h12ffe2904b71870f@mail.gmail.com> Message-ID: <1236693425.18078.10.camel@mathieu-laptop> On Thu, 2009-03-05 at 11:25 -0500, raj bhattacharjea wrote: > > it appears that we have most votes for: > > > > - StaticMobilityModel -> ConstantPositionMobilityModel > > - StaticSpeedMobilityModel -> ConstantVelocityMobilityModel > > - ConstantAccelerationMobilityModel > Yes; please also make sure to check in something about the renaming > in the CHANGES.html file. done Mathieu From tomh at tomh.org Tue Mar 10 09:59:10 2009 From: tomh at tomh.org (Tom Henderson) Date: Tue, 10 Mar 2009 16:59:10 +0000 Subject: [Ns-developers] request for GSOC mentors Message-ID: We're seeing a lot of student interest already in the Google Summer of Code program, to which we're reapplying this month. I've also been adding lots of ideas for possible student projects to the wiki: http://www.nsnam.org/wiki/index.php/Gsoc2009 However, we really need some more mentors to step forward at this time, either to agree to mentor one of the project ideas listed, or to contribute other ideas for which you'd be willing to mentor a student. We need to understand how many projects, and what types of projects, we can mentor. If you have some expertise in some aspect of networking, and familiarity with ns-3, please consider volunteering as a mentor, and contact Joe Kopena. Thanks, Tom From craigdo at ee.washington.edu Wed Mar 11 00:10:28 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Wed, 11 Mar 2009 00:10:28 -0700 Subject: [Ns-developers] Request to push tracing changes In-Reply-To: <12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com> References: <12d69e490903031046j15c96051y7c43ced585f31cf9@mail.gmail.com> <12d69e490903031050heffe7fbkbc0507b2edd733c0@mail.gmail.com> Message-ID: <299EBCCCB3D04526B6AAF86101C45C7D@CRAIGVAIO> Hi All, Regarding the never-ending bug 443, I have queued up a new version of the tracing rework in http://code.nsnam.org/craigdo/ns-3-tracing for your perusal. >From previous list mail, we seemed to agree on a policy: 1) There is a set of suggested trace sources for net devices. 2) Implementing the complete set of suggested trace sources in a net device is not a requirement. A device author may pick a subset of these sources to implement. 3) The net device author should document what trace sources are implemented and the state the packets are in when they come out of the trace source. For example, raw IP, Ethernet header, llc/snap, dix, p2p, wifi, etc. 4) A net device author should implement a PromiscSniffer trace source to allow tcpdump-like functionality in helpers to be called a "standard" net device; but you are always allowed to do whatever you think is right on your own time. In furtherance of this policy I did the following to the tracing code: 1) Removed the objectionable Sniffer (Ethernet framed) and tx complete trace sources from the wifi device; 2) Removed the unused rx start trace sources from the csma and point-to-point devices; 3) Removed the non-promiscuous sniffer helper code from the wifi-helper and left yans-wifi-phy hooked to the promisc sniffer; 4) Added PromiscSniffer (tcpdump) functionality to the various net devices. 5) Changed helpers very slightly to make life a little easier as a result of the above. 6) Changed the documented examples (second, third) to use promiscuous sniffers as if someone were doing tcpdump on a real net device These changes are queued for review/push in http://craigdo/ns-3-tracing I am asking for permission to push these changes into ns-3-dev, and the resulting updated (verified) reference traces into ns-3-dev-ref-traces. This will introduce required documentation changes which I will address before ns-3.4 is out the door. Regards, -- Craig From mathieu.lacage at sophia.inria.fr Wed Mar 11 08:30:36 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 11 Mar 2009 16:30:36 +0100 Subject: [Ns-developers] request for GSOC mentors In-Reply-To: References: Message-ID: <1236785436.658.13.camel@mathieu-laptop> I wanted to add a couple of FAQ entries about this: 1) What is a mentor supposed to do ? A mentor is supposed to do daily management and mentoring of a student. This means, helping with technical and planning problems. For ns-3, mentors are expected to provide expertise in the field which is directly related to the student's project. Expertise in core ns-3 development is not required since the ns-developers mailing-list is there to helper answer potentially problematic questions and problems but familiarity with ns-3 concepts would probably be necessary. 2) How is a mentor supposed to manage a student ? Students are expected to work from home: students from all over the world apply for gsoc so, you can't expect them to move over to where you live/work for 3 or 4 months. Of course, you, as a mentor, are responsible for picking the students you are willing to mentor and a location criterion is perfectly acceptable if there are multiple qualified students and if you wish to pick one who is located closest to your timezone, or your geographical area or your city or your office. 3) What is the daily overhead of being a mentor for a student ? It really depends on the student, the mentor, and the project, of course, but 1 hour a day is generally considered the minimum realistic cost of mentoring a student. 4) What do you get from this, as a mentor ? gsoc will pay to the ns-3 project 500 USD per mentor. Generally, part of that money is given back to each mentor (only part because there are some tax issues) but the ns-3 project has still been unable to actually get the money from google from last year's gsoc I think (tom, please, correct me if I am wrong). Money is thus unlikely to be a deciding factor for a mentor. What is more motivating is usually that the mentor has vested interest in seeing a specific feature being developed and integrated so, mentors usually get a new feature they really want. The ns-3 project, on the other hand, is focused on convincing new contributors to work on the project, long term. Success is thus usually defined as seeing a student and/or mentor stay around after the completion of the gsoc project. On Tue, 2009-03-10 at 16:59 +0000, Tom Henderson wrote: > We're seeing a lot of student interest already in the Google Summer of > Code program, to which we're reapplying this month. I've also been > adding lots of ideas for possible student projects to the wiki: > http://www.nsnam.org/wiki/index.php/Gsoc2009 > > However, we really need some more mentors to step forward at this > time, either to agree to mentor one of the project ideas listed, or to > contribute other ideas for which you'd be willing to mentor a student. > We need to understand how many projects, and what types of projects, > we can mentor. > > If you have some expertise in some aspect of networking, and > familiarity with ns-3, please consider volunteering as a mentor, and > contact Joe Kopena. > > Thanks, > Tom > > > From mathieu.lacage at sophia.inria.fr Wed Mar 11 09:54:59 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Wed, 11 Mar 2009 17:54:59 +0100 Subject: [Ns-developers] About real-world application integration In-Reply-To: References: Message-ID: <1236790499.658.31.camel@mathieu-laptop> hi, On Fri, 2009-03-06 at 15:50 +0900, Hajime Tazaki wrote: > Hi All, > > Now I'm working GNU Zebra bridge function to ns-3. > #Note that not for Quagga, but I believe that quagga also > works. This sounds really cool ! > > Is there anyone who works on this topic? I work on this when I have time. More below. > > First of all, I tried to use the following branch > > [1] http://code.nsnam.org/lj/quagga-porting/ > > but it seems not to be worked. So I integrate [1,2,3,4] > based on [2] branch. ok. > > > Although there is a lot of issues to fix, such as > - Focusing on only my software (modified zebra) which use > only ICMP6 and UDP6. > - IP{v4,v6} construction can be reorganized as doing in > "tomh/ns-3-ip" > - routing table in ns3 can handle longest match prefix > - performance is not so good (max node is 100?) > - make patches for HEAD branch > - and, etc... > > but current snapshot of this work is available at > > http://www.sfc.wide.ad.jp/~tazaki/hg/hgwebdir.cgi/ns-3-simu_zebra_ipv6/ > > Currently I can run simulation about 50nodes with Tree > Discovery procotol(draft-thubert-tree-discovery) and OLSRv1 > with IPv6 extension with this repo. > > Any comments and suggestions are appreciate. The bad news is that the ns-3-simu branch can't be merged in ns-3-dev as-is because it has many problems and because ns-3-dev has many problems so, your work can't be merged in ns-3-dev today. The good news is that we have plans to address all these issues: 1) First, we need to complete the ipv4 API/implementation rework. 2) Then, we need to merge the ipv6 work 3) Then, we need to fix some fundamental issues in the ELF loader in ns-3-simu 4) Then, we need to merge the netlink code 5) Finally, we can merge the missing pieces to make quagga and zebra work. 1) is current planned for the second half of march (i.e., starting next week). My hope is that tom and myself can complete a mergeable version just after we release 3.4 so that we can merge this in early may. 2) would, ideally, be worked on after 1) is completed but I don't plan to work on it myself other than review code from sebastien. 3) is something I have been working on since december in my spare time. It is basically a re-implementation of an ELF loader for i386 and x86-64 linux. This should fix a number of very hard to track bugs in the current implementation which can be seen by very-hard-to-reproduce random segfaults. 4) and 5) seem to be mostly what you have started doing. I glanced at your tree and it seems that you have started doing 4) and 5) which is great because no one is working on it so, if you can keep improving the libc implementation located in src/process-manager, this will help us move fast once I have completed 3. So, my initial reaction is that what you are doing is great, I think that there is no real overlap with other people if you work only on the src/process-manager code, and I will do a more thorough review of your code sometime next week (I am supposed to be away from email this week :). thanks a lot for working on this, and for sharing your efforts with us, Mathieu From tazaki at sfc.wide.ad.jp Wed Mar 11 22:34:38 2009 From: tazaki at sfc.wide.ad.jp (Hajime Tazaki) Date: Thu, 12 Mar 2009 14:34:38 +0900 Subject: [Ns-developers] About real-world application integration In-Reply-To: <1236790499.658.31.camel@mathieu-laptop> References: <1236790499.658.31.camel@mathieu-laptop> Message-ID: Hi Mathieu, At Wed, 11 Mar 2009 17:54:59 +0100, Mathieu Lacage wrote: >The bad news is that the ns-3-simu branch can't be merged in ns-3-dev >as-is because it has many problems and because ns-3-dev has many >problems so, your work can't be merged in ns-3-dev today. Not so bad. >The good news is that we have plans to address all these issues: > >1) First, we need to complete the ipv4 API/implementation rework. >2) Then, we need to merge the ipv6 work >3) Then, we need to fix some fundamental issues in the ELF loader in >ns-3-simu >4) Then, we need to merge the netlink code >5) Finally, we can merge the missing pieces to make quagga and zebra >work. > >1) is current planned for the second half of march (i.e., starting next >week). My hope is that tom and myself can complete a mergeable version >just after we release 3.4 so that we can merge this in early may. > >2) would, ideally, be worked on after 1) is completed but I don't plan >to work on it myself other than review code from sebastien. > >3) is something I have been working on since december in my spare time. >It is basically a re-implementation of an ELF loader for i386 and x86-64 >linux. This should fix a number of very hard to track bugs in the >current implementation which can be seen by very-hard-to-reproduce >random segfaults. > >4) and 5) seem to be mostly what you have started doing. > >I glanced at your tree and it seems that you have started doing 4) and >5) which is great because no one is working on it so, if you can keep >improving the libc implementation located in src/process-manager, this >will help us move fast once I have completed 3. So, my initial reaction >is that what you are doing is great, I think that there is no real >overlap with other people if you work only on the src/process-manager >code, and I will do a more thorough review of your code sometime next >week (I am supposed to be away from email this week :). Okay, thanks. First of all, I can review 1)'s work from the 4) 5)'s point of view. Most of this work has already done by him, Liu Jian. I've just added some function into this. regards, hajime From raj.b at gatech.edu Fri Mar 13 08:58:08 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Fri, 13 Mar 2009 11:58:08 -0400 Subject: [Ns-developers] ns-3.4 : Final Steps Message-ID: <12d69e490903130858s62eabaf9y138d697da12f79aa@mail.gmail.com> Alright everyone, we are down to less than a week before we plan on making release candidates for ns-3.4! There are currently still 10 "blocker" level bugs in the tracker. I think we can successfully get these knocked out by Wednesday, since it is my intention to not make a release candidate until there are no broken behavior bugs that we know of in ns-3.4. I want to summarize and coordinate this last round of "blocker" level bug fixing briefly here on the list. They break down into the following categories: =====TCP====== These make up a whopping 6 out of 10 of the remaining bugs (bugs 198, 424, 425, 426, 427, 499). I have set up a repository to track the fixes: http://code.nsnam.org/raj/ns-3-tcp So far, the tree takes care of 198 and 499. There is a patch that will probably go in unmodified for 425 in the tracker. The rest of the bugs will be fixed by Monday, when I'll merge my changes from the temporary raj/ns-3-tcp branch. I have a handle on all of the bugs and am confident there will be no slipping. ======Documentation====== There is 1 bug about the tutorial going stale (504). I suspect that Craig will get to updating this during the code freeze which starts Wednesday. I am fine with documentation fixes during the code-freeze and RC process. ======Tracing====== There are 2 bugs related to tracing (443 and 505). The main one is the trace source rework of bug 443. It is queued up for merge at: http://code.nsnam.org/craigdo/ns-3-tracing This needs a little review, and I have not seen any further comments from others. I will be taking a look at the changes today, and providing feedback to Craig. I suspect the changes should be ready for merge as-is, probably Monday. The one linger question I have is about bug 505, which is blocked on the rework; I am not sure we can converge on a solution quickly enough after the tracing work is put in. ======Wifi Model / Tap Interaction====== There is one bug (510) concerning contradictory behavior in one of Mathieu's Wifi MAC model. There was some lengthy discussion about how the behavior might need to change to support the emu/ Tap bridging use cases. The final consensus seems to be simply to fix the contradictory behavior, and then worry about how to make Tap work later. If this is the case, we'll merge this one liner on Monday (replacing one "true" with "false"). In summary, the TCP fixes are being worked on, and will be merged Monday. The main tracing rework and the Wifi inconsistency look like they can be merged as well on Monday. This would leave the auxiliary tracing issue (505) and the tutorial update work to be completed. The tracing issue will have to be solved quickly before Wednesday, while documentation / tutorial / etc fixes can be checked in throughout the RC process. I hope this roadmap to ns-3.4 RC1 makes sense to everyone. If we are not on the same page, lets get some discussion going on the matter. -- Raj Bhattacharjea Georgia Institute of Technology School of Electrical and Computer Engineering Ph.D. Candidate Systems Analyst 404.894.2955 From tomh at tomh.org Fri Mar 13 16:22:24 2009 From: tomh at tomh.org (Tom Henderson) Date: Fri, 13 Mar 2009 16:22:24 -0700 Subject: [Ns-developers] ns-3.4 : Final Steps In-Reply-To: <12d69e490903130858s62eabaf9y138d697da12f79aa@mail.gmail.com> References: <12d69e490903130858s62eabaf9y138d697da12f79aa@mail.gmail.com> Message-ID: <49BAEAB0.2050900@tomh.org> Raj Bhattacharjea wrote: > ======Tracing====== > There are 2 bugs related to tracing (443 and 505). The main one is > the trace source rework of bug 443. It is queued up for merge at: > http://code.nsnam.org/craigdo/ns-3-tracing > This needs a little review, and I have not seen any further comments > from others. I will be taking a look at the changes today, and > providing feedback to Craig. I suspect the changes should be ready > for merge as-is, probably Monday. The one linger question I have is > about bug 505, which is blocked on the rework; I am not sure we can > converge on a solution quickly enough after the tracing work is put > in. I reviewed this again and have a few comments, which I discussed with Craig: - try to provide the trace source that George wanted for the NetAnim animator - look at bug 505; see if it is resolved - update CHANGES.html before the RC Otherwise, it seems ready to me. > > ======Wifi Model / Tap Interaction====== > There is one bug (510) concerning contradictory behavior in one of > Mathieu's Wifi MAC model. There was some lengthy discussion about how > the behavior might need to change to support the emu/ Tap bridging use > cases. The final consensus seems to be simply to fix the > contradictory behavior agree >, and then worry about how to make Tap work > later. Regarding this part, I've asked Craig to also try to address bug 520 (a P2 bug) before the RC. Several users including myself are blocked by this. Tom From mk.banchi at gmail.com Sat Mar 14 05:42:23 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Sat, 14 Mar 2009 13:42:23 +0100 Subject: [Ns-developers] How to maintain a repository for merge Message-ID: <49BBA62F.9020201@gmail.com> Hi all, i'm working to 802.11e/n support and i'd like to know how you prefer i maintain my mercurial repository in order to make a possible future merge easier than possible. Could a tag for every milestone be enough? Or do you prefer a single repository for each feature? at http://code.nsnam.org/mirko/ns-3-80211n/ you can find the code. Thank you all, Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org id-msn: mb11684 at hotmail.com PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3410 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090314/9c7f76a6/smime.bin From tomh at tomh.org Sat Mar 14 08:36:21 2009 From: tomh at tomh.org (Tom Henderson) Date: Sat, 14 Mar 2009 08:36:21 -0700 Subject: [Ns-developers] How to maintain a repository for merge In-Reply-To: <49BBA62F.9020201@gmail.com> References: <49BBA62F.9020201@gmail.com> Message-ID: <49BBCEF5.5090303@tomh.org> Mirko Banchi wrote: > Hi all, > > i'm working to 802.11e/n support and i'd like to know how you prefer i > maintain my mercurial repository in order to make a possible future > merge easier than possible. Could a tag for every milestone be enough? > Or do you prefer a single repository for each feature? > > at http://code.nsnam.org/mirko/ns-3-80211n/ > you can find the code. > > Thank you all, > > Mirko > I would suggest the following: - try to keep your repository in sync with ns-3-dev - work with the maintainer to ask how he or she would like to proceed. For instance, do you agree on features, API, and general design? Can you define some merge points or milestones? The maintainer should be able to help with overall schedule and merge considerations, deciding on whether separate repos are needed for each mergeable chunk, etc. In your case, are you at the "agree on features, API, and general design stage" still? I recall that you had asked some questions in your earlier post: http://mailman.isi.edu/pipermail/ns-developers/2008-December/004973.html and I am not sure what discussions you may have had at wns3 about some of these issues. Can you suggest some natural milestones in the development that might make smaller and earlier merges possible? - Tom From mk.banchi at gmail.com Sat Mar 14 10:21:07 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Sat, 14 Mar 2009 18:21:07 +0100 Subject: [Ns-developers] How to maintain a repository for merge In-Reply-To: <49BBCEF5.5090303@tomh.org> References: <49BBA62F.9020201@gmail.com> <49BBCEF5.5090303@tomh.org> Message-ID: <49BBE783.1000703@gmail.com> Tom Henderson ha scritto: > Mirko Banchi wrote: >> Hi all, >> >> i'm working to 802.11e/n support and i'd like to know how you prefer i >> maintain my mercurial repository in order to make a possible future >> merge easier than possible. Could a tag for every milestone be enough? >> Or do you prefer a single repository for each feature? >> >> at http://code.nsnam.org/mirko/ns-3-80211n/ >> you can find the code. >> >> Thank you all, >> >> Mirko >> > > I would suggest the following: > > - try to keep your repository in sync with ns-3-dev > > - work with the maintainer to ask how he or she would like to proceed. > For instance, do you agree on features, API, and general design? Can you > define some merge points or milestones? The maintainer should be able > to help with overall schedule and merge considerations, deciding on > whether separate repos are needed for each mergeable chunk, etc. > > In your case, are you at the "agree on features, API, and general design > stage" still? I recall that you had asked some questions in your > earlier post: > http://mailman.isi.edu/pipermail/ns-developers/2008-December/004973.html > and I am not sure what discussions you may have had at wns3 about some > of these issues. > > Can you suggest some natural milestones in the development that might > make smaller and earlier merges possible? > > - Tom > At the moment my repository includes these new features: Edca mechanism Frame aggregation (A-MSDU) Clearly some examples and docs will be added. For now i could suggest this possible milestones: 1. Edca mechanism and Frame Aggregation (A-MSDU) (current) 2. Block ack mechanism 3. Frame aggregation (A-MPDU) 4. Support for transmission of multiple frames in the same txop. What do you think about? Regards, Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org id-msn: mb11684 at hotmail.com PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3410 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090314/973d97ec/smime.bin From mk.banchi at gmail.com Sun Mar 15 12:19:47 2009 From: mk.banchi at gmail.com (Mirko Banchi) Date: Sun, 15 Mar 2009 20:19:47 +0100 Subject: [Ns-developers] How to maintain a repository for merge In-Reply-To: <1237141616.6391.1.camel@mathieu-laptop> References: <49BBA62F.9020201@gmail.com> <1237141616.6391.1.camel@mathieu-laptop> Message-ID: <49BD54D3.2050701@gmail.com> Mathieu Lacage ha scritto: > it would be really helpul for review if you could send the list of files > you have modified, and the list of files you have added. > > Mathieu > Added files: src/devices/wifi/qsta-wifi-mac.h src/devices/wifi/qsta-wifi-mac.cc src/devices/wifi/qap-wifi-mac.h src/devices/wifi/qap-wifi-mac.cc src/devices/wifi/edca-txop-n.h src/devices/wifi/edca-txop-n.cc src/devices/wifi/edca-parameter-set.h src/devices/wifi/edca-parameter-set.cc src/devices/wifi/msdu-aggregator.h src/devices/wifi/msdu-aggregator.cc src/devices/wifi/msdu-standard-aggregator.h src/devices/wifi/msdu-standard-aggregator.cc src/devices/wifi/amsdu-subframe-header.h src/devices/wifi/amsdu-subframe-header.cc src/helper/msdu-aggregator-helper.h src/helper/msdu-aggregator-helper.cc Modified files: src/devices/wifi/wifi-mac-header.h src/devices/wifi/wifi-mac-header.cc src/devices/wifi/mac-tx-middle.h src/devices/wifi/mac-tx-middle.cc src/devices/wifi/wifi-mac-queue.h src/devices/wifi/wifi-mac-queue.cc In a short time i'll add also examples and docs. This about milestone "MsduAggregation" that includes: Edca mechanism Frame aggregation (only A-MSDU) I'll add for each milestone in my repository http://code.nsnam.org/mirko/ns-3-80211n one tag. If you prefer other ways to make merging easier feel free to tell me. Planned milestones are: -Frame aggregation (A-MSDU). -Block ack mechanism. -Frame aggregation (A-MPDU). -Transmission of multiple frames in the same Txop. Mirko -- Mirko Banchi e-mail: mk.banchi at gmail.com e-mail: mk.banchi at virgilio.it id-jabber: mk.banchi at jabber.org id-msn: mb11684 at hotmail.com PGP key fingerprint: 308F BFB1 4E67 2522 C88E DC69 7631 52ED 32A5 6456 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3410 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090315/b6e00835/smime.bin From boyko at iitp.ru Sun Mar 15 05:34:38 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Sun, 15 Mar 2009 15:34:38 +0300 Subject: [Ns-developers] Mac48Address operator < cosmetics Message-ID: <200903151534.39042.boyko@iitp.ru> Hi all, First 4 lines of this method (node/mac48-address.cc by Mathieu) seem to be meaningless: bool operator < (const Mac48Address &a, const Mac48Address &b) { uint8_t aP[6]; uint8_t bP[6]; a.CopyTo (aP); b.CopyTo (bP); for (uint8_t i = 0; i < 6; i++) { if (a.m_address[i] < b.m_address[i]) { return true; } else if (a.m_address[i] > b.m_address[i]) { return false; } } return false; } Mathieu, if you agree, please remove CopyTo (or remove friend in class declaration and use copy). Thanks, Pavel Boyko researcher IITP RAS From mathieu.lacage at sophia.inria.fr Mon Mar 16 00:15:22 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Mar 2009 08:15:22 +0100 Subject: [Ns-developers] Mac48Address operator < cosmetics In-Reply-To: <200903151534.39042.boyko@iitp.ru> References: <200903151534.39042.boyko@iitp.ru> Message-ID: <1237187722.31135.8.camel@diese.inria.fr> On Sun, 2009-03-15 at 15:34 +0300, Pavel Boyko wrote: > Hi all, > > First 4 lines of this method (node/mac48-address.cc by Mathieu) seem to be > meaningless: the internal buffer of the Mac48Address class is not public, hence the need for the two copies. If you really wish to avoid them (can you actually see this code in a real performance profile ?), you would need to make operator < a friend of Mac48Address and modify the code to access the internal buffer. Feel free to send a patch and, if you do, please, attach it to www.nsnam.org/bugzilla regards, Mathieu From mathieu.lacage at sophia.inria.fr Mon Mar 16 00:24:46 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Mar 2009 08:24:46 +0100 Subject: [Ns-developers] ns-3.4 : Final Steps In-Reply-To: <12d69e490903130858s62eabaf9y138d697da12f79aa@mail.gmail.com> References: <12d69e490903130858s62eabaf9y138d697da12f79aa@mail.gmail.com> Message-ID: <1237188286.31135.13.camel@diese.inria.fr> On Fri, 2009-03-13 at 11:58 -0400, Raj Bhattacharjea wrote: > ======Tracing====== > There are 2 bugs related to tracing (443 and 505). The main one is > the trace source rework of bug 443. It is queued up for merge at: > http://code.nsnam.org/craigdo/ns-3-tracing > This needs a little review, and I have not seen any further comments > from others. I will be taking a look at the changes today, and > providing feedback to Craig. I suspect the changes should be ready > for merge as-is, probably Monday. The one linger question I have is > about bug 505, which is blocked on the rework; I am not sure we can > converge on a solution quickly enough after the tracing work is put > in. I reviewed the src/devices/wifi part of the last version: there are a couple of uneeded changes: and wifi-net-device.h: void SniffPacket (Ptr packet, Mac48Address to, Mac48Address from, uint16_t type); wifi-net-device.cc: +#include "ns3/ethernet-header.h" +#include "ns3/ethernet-trailer.h" and, in wifi-net-device.cc: are you sure you need the copy below ? - m_promiscRx (this, packet, llc.GetType (), from, to, type); + m_promiscRx (this, packet->Copy (), llc.GetType (), from, to, type); Mathieu From mathieu.lacage at sophia.inria.fr Mon Mar 16 01:48:51 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Mar 2009 09:48:51 +0100 Subject: [Ns-developers] About real-world application integration In-Reply-To: <1236790499.658.31.camel@mathieu-laptop> References: <1236790499.658.31.camel@mathieu-laptop> Message-ID: <1237193331.31135.36.camel@diese.inria.fr> hi, On Wed, 2009-03-11 at 17:54 +0100, Mathieu Lacage wrote: > code, and I will do a more thorough review of your code sometime next > week (I am supposed to be away from email this week :). So, I did look at your code :) A couple of random comments: 1) you checked in a couple of emacs-generated files: /scratch/process-zebra.cc~, scratch/process-zebra.py~ 2) I see a couple of patches to the ipv6 code: it would be nice if you could contribute these back to sebastien separately. 3) In src/node/node.cc, what is the use of this extra tag ? Where is it used ? + SocketRecvIfTag tag; + tag.SetRecvIf (device->GetIfIndex()); + packet->AddTag (tag); + 4) I see a couple of patches to src/process-manager/* which could be merged in ns-3-simu right now, so, it would be nice if you could try to split them from the rest to try to minimize the number of differences between your tree and ns-3-simu. For example, the following looks like a good idea and I would be happy to take patches to add them to http://code.nsnam.org/mathieu/ns-3-simu diff -r 89718962b257 -r 6066282751f1 src/process-manager/alloc.cc --- a/src/process-manager/alloc.cc Fri Feb 27 23:57:07 2009 +0900 +++ b/src/process-manager/alloc.cc Wed Mar 11 15:03:07 2009 +0900 @@ -54,6 +54,7 @@ : m_defaultMmapSize (1<<15) { NS_LOG_FUNCTION (this); + memset(m_buckets, 0, sizeof(m_buckets)); } KingsleyAlloc::~KingsleyAlloc () { this too: diff -r cc696412ba7e -r 9bd77de2052c src/process-manager/unix-datagram-socket-fd.cc --- a/src/process-manager/unix-datagram-socket-fd.cc Fri Feb 27 23:58:01 2009 +0900 +++ b/src/process-manager/unix-datagram-socket-fd.cc Fri Mar 06 13:25:32 2009 +0900 @@ -181,7 +181,7 @@ Thread *current = Current (); NS_LOG_FUNCTION (this << current); NS_ASSERT (current != 0); - uint32_t old_ifindex; + uint32_t old_ifindex = 0; as well as: - process->alloc = new StupidAlloc (); - // process->alloc = new KingsleyAlloc (); + process->alloc = new KingsleyAlloc (); and, I assume that this made a bit difference for you: - std::vector > > openFiles; + __gnu_cxx::hash_map > openFiles; but, oh, look at src/internet-stack/sgi-hashmap.h: would you mind move it to src/core and use this one instead ? The following looks a bit gratuituous: diff -r 89718962b257 -r 6066282751f1 src/process-manager/process-manager.cc --- a/src/process-manager/process-manager.cc Fri Feb 27 23:57:07 2009 +0900 +++ b/src/process-manager/process-manager.cc Wed Mar 11 15:03:07 2009 +0900 @@ -109,12 +109,12 @@ { NS_LOG_FUNCTION (this); GarbageCollectDeadProcessesAndThreads (); - for (std::vector::iterator i = m_processes.begin (); i != m_processes.end (); ++i) + for (std::vector::iterator i = m_processes.begin (); i != m_processes.end ();) { struct Process *process = *i; DeleteProcess (process); + i = m_processes.erase (i); } - m_processes.clear (); This would be nice rewritten with the coding style in mind: + if(current->process->openFiles.find(fd) != current->process->openFiles.end()) + return fd; i.e.: if () { // do stuff } again, thanks for your work, Mathieu From tazaki at sfc.wide.ad.jp Mon Mar 16 02:59:56 2009 From: tazaki at sfc.wide.ad.jp (Hajime Tazaki) Date: Mon, 16 Mar 2009 18:59:56 +0900 Subject: [Ns-developers] About real-world application integration In-Reply-To: <1237193331.31135.36.camel@diese.inria.fr> References: <1236790499.658.31.camel@mathieu-laptop> <1237193331.31135.36.camel@diese.inria.fr> Message-ID: Hi, Thanks for your valuable comments. #even though my source is nasty, a lot of hard coding... Please find my comments in line. At Mon, 16 Mar 2009 09:48:51 +0100, Mathieu Lacage wrote: >> code, and I will do a more thorough review of your code sometime next >> week (I am supposed to be away from email this week :). > >So, I did look at your code :) A couple of random comments: > >1) you checked in a couple of emacs-generated >files: /scratch/process-zebra.cc~, scratch/process-zebra.py~ Thanks. Already fixed and pushed at my repo. >2) I see a couple of patches to the ipv6 code: it would be nice if you >could contribute these back to sebastien separately. Okay. I'll try to. >3) In src/node/node.cc, what is the use of this extra tag ? Where is it >used ? > >+ SocketRecvIfTag tag; >+ tag.SetRecvIf (device->GetIfIndex()); >+ packet->AddTag (tag); >+ This tag is used in unix-datagram-socket.cc to emulate "IPV6_RECVPKTINFO" sockopt. + if(msg->msg_controllen > 0){ + Cmsg cmsg = Cmsg (msg); + if (IsRecvPktInfo ()) + { + struct in6_pktinfo pkt; + + SocketRecvIfTag tag; + bool found; + found = packet->FindFirstMatchingTag (tag); + NS_ASSERT (found); + + pkt.ipi6_ifindex = tag.GetRecvIf (); + memcpy(&pkt.ipi6_addr, msg->msg_name, sizeof(pkt.ipi6_addr)); + cmsg.Add (SOL_IPV6, IPV6_PKTINFO, sizeof (struct in6_pktinfo), (const uint8_t*)&pkt); + } + cmsg.Finish (); + } Modifying in node.cc isn't good idea, but I can't find any other suitable place to do it. Do you have any good idea? >4) I see a couple of patches to src/process-manager/* which could be >merged in ns-3-simu right now, so, it would be nice if you could try to >split them from the rest to try to minimize the number of differences >between your tree and ns-3-simu. For example, the following looks like a >good idea and I would be happy to take patches to add them to >http://code.nsnam.org/mathieu/ns-3-simu Okay, I'll try it later. Do you mind if I'll send patches for this modification? Or using bugzilla is better? >diff -r 89718962b257 -r 6066282751f1 src/process-manager/alloc.cc >--- a/src/process-manager/alloc.cc Fri Feb 27 23:57:07 2009 +0900 >+++ b/src/process-manager/alloc.cc Wed Mar 11 15:03:07 2009 +0900 >@@ -54,6 +54,7 @@ > : m_defaultMmapSize (1<<15) > { > NS_LOG_FUNCTION (this); >+ memset(m_buckets, 0, sizeof(m_buckets)); > } > KingsleyAlloc::~KingsleyAlloc () > { I can make a patch. >this too: >diff -r cc696412ba7e -r 9bd77de2052c >src/process-manager/unix-datagram-socket-fd.cc >--- a/src/process-manager/unix-datagram-socket-fd.cc Fri Feb 27 >23:58:01 2009 +0900 >+++ b/src/process-manager/unix-datagram-socket-fd.cc Fri Mar 06 >13:25:32 2009 +0900 >@@ -181,7 +181,7 @@ > Thread *current = Current (); > NS_LOG_FUNCTION (this << current); > NS_ASSERT (current != 0); >- uint32_t old_ifindex; >+ uint32_t old_ifindex = 0; I can make a patch, too. >as well as: > >- process->alloc = new StupidAlloc (); >- // process->alloc = new KingsleyAlloc (); >+ process->alloc = new KingsleyAlloc (); > >and, I assume that this made a bit difference for you: > >- std::vector > > openFiles; >+ __gnu_cxx::hash_map > openFiles; > >but, oh, look at src/internet-stack/sgi-hashmap.h: would you mind move >it to src/core and use this one instead ? I don't mind, I just wanna use hash_map, but I wasn't sure how I can do it, so just trid to do same as src/internet-cache/arp-cache.h. BTW, using hash_map comes from oprofile output to improve performance, but it makes not so big differences. >The following looks a bit gratuituous: > >diff -r 89718962b257 -r 6066282751f1 >src/process-manager/process-manager.cc >--- a/src/process-manager/process-manager.cc Fri Feb 27 23:57:07 2009 >+0900 >+++ b/src/process-manager/process-manager.cc Wed Mar 11 15:03:07 2009 >+0900 >@@ -109,12 +109,12 @@ > { > NS_LOG_FUNCTION (this); > GarbageCollectDeadProcessesAndThreads (); >- for (std::vector::iterator i = m_processes.begin >(); i != m_processes.end (); ++i) >+ for (std::vector::iterator i = m_processes.begin >(); i != m_processes.end ();) > { > struct Process *process = *i; > DeleteProcess (process); >+ i = m_processes.erase (i); > } >- m_processes.clear (); I can make a patch, too. >This would be nice rewritten with the coding style in mind: > >+ if(current->process->openFiles.find(fd) != >current->process->openFiles.end()) >+ return fd; > >i.e.: >if () > { > // do stuff > } Okay, I read http://www.nsnam.org/codingstyle.html right now. Is "indent -gnu {all files}" good enough? regards, hajime From mathieu.lacage at sophia.inria.fr Mon Mar 16 03:11:09 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Mar 2009 11:11:09 +0100 Subject: [Ns-developers] About real-world application integration In-Reply-To: References: <1236790499.658.31.camel@mathieu-laptop> <1237193331.31135.36.camel@diese.inria.fr> Message-ID: <1237198269.31135.121.camel@diese.inria.fr> On Mon, 2009-03-16 at 18:59 +0900, Hajime Tazaki wrote: > >3) In src/node/node.cc, what is the use of this extra tag ? Where is it > >used ? > > > >+ SocketRecvIfTag tag; > >+ tag.SetRecvIf (device->GetIfIndex()); > >+ packet->AddTag (tag); > >+ > > This tag is used in unix-datagram-socket.cc to emulate > "IPV6_RECVPKTINFO" sockopt. > > + if(msg->msg_controllen > 0){ > + Cmsg cmsg = Cmsg (msg); > + if (IsRecvPktInfo ()) > + { > + struct in6_pktinfo pkt; > + > + SocketRecvIfTag tag; > + bool found; > + found = packet->FindFirstMatchingTag (tag); > + NS_ASSERT (found); > + > + pkt.ipi6_ifindex = tag.GetRecvIf (); > + memcpy(&pkt.ipi6_addr, msg->msg_name, sizeof(pkt.ipi6_addr)); > + cmsg.Add (SOL_IPV6, IPV6_PKTINFO, sizeof (struct in6_pktinfo), (const uint8_t*)&pkt); > + } > + cmsg.Finish (); > + } > > Modifying in node.cc isn't good idea, but I can't find any > other suitable place to do it. Do you have any good idea? I see: it's weird that I did not see the ipv6 part of the patch. To make sure I don't forget anything, would you mind send me a list of files you have modified and files you have added ? Anyway, I think you can leave this in for now: the tagging code is going to undergo changes for the ipv4 rework so, this will probably be solved during in the ipv4 rework. > >4) I see a couple of patches to src/process-manager/* which could be > >merged in ns-3-simu right now, so, it would be nice if you could try to > >split them from the rest to try to minimize the number of differences > >between your tree and ns-3-simu. For example, the following looks like a > >good idea and I would be happy to take patches to add them to > >http://code.nsnam.org/mathieu/ns-3-simu > > Okay, I'll try it later. > Do you mind if I'll send patches for this modification? > Or using bugzilla is better? you can: - create a mercurial repo with only the patches you want to send me and I will pull from this repo, review, and push in mathieu/ns-3-simu - or send me raw patches by email (mercurial has a patchbomb extension: http://www.selenic.com/mercurial/wiki/index.cgi/PatchbombExtension) > >and, I assume that this made a bit difference for you: > > > >- std::vector > > openFiles; > >+ __gnu_cxx::hash_map > openFiles; > > > >but, oh, look at src/internet-stack/sgi-hashmap.h: would you mind move > >it to src/core and use this one instead ? > > I don't mind, I just wanna use hash_map, but I wasn't sure > how I can do it, so just trid to do same as > src/internet-cache/arp-cache.h. > > BTW, using hash_map comes from oprofile output to improve > performance, but it makes not so big differences. If it makes no real difference, then, maybe we can drop this ? I really have never tried to profile the behavior of the process-manager code so, I have no idea how it behaves: I would tend to trust you if you did profile it and if you think it is worth being done :) > >The following looks a bit gratuituous: > > > >diff -r 89718962b257 -r 6066282751f1 > >src/process-manager/process-manager.cc > >--- a/src/process-manager/process-manager.cc Fri Feb 27 23:57:07 2009 > >+0900 > >+++ b/src/process-manager/process-manager.cc Wed Mar 11 15:03:07 2009 > >+0900 > >@@ -109,12 +109,12 @@ > > { > > NS_LOG_FUNCTION (this); > > GarbageCollectDeadProcessesAndThreads (); > >- for (std::vector::iterator i = m_processes.begin > >(); i != m_processes.end (); ++i) > >+ for (std::vector::iterator i = m_processes.begin > >(); i != m_processes.end ();) > > { > > struct Process *process = *i; > > DeleteProcess (process); > >+ i = m_processes.erase (i); > > } > >- m_processes.clear (); > > I can make a patch, too. I meant that I don't really understand what this patch is doing: it seems that it's really doing the same thing as before, only differently. > >This would be nice rewritten with the coding style in mind: > > > >+ if(current->process->openFiles.find(fd) != > >current->process->openFiles.end()) > >+ return fd; > > > >i.e.: > >if () > > { > > // do stuff > > } > > Okay, > I read http://www.nsnam.org/codingstyle.html right now. > > Is "indent -gnu {all files}" good enough? I honestly have no idea. I usually do all the coding style formatting by hand. The emacs gnu mode helps but it does not do everything. Mathieu From tazaki at sfc.wide.ad.jp Mon Mar 16 03:40:13 2009 From: tazaki at sfc.wide.ad.jp (Hajime Tazaki) Date: Mon, 16 Mar 2009 19:40:13 +0900 Subject: [Ns-developers] About real-world application integration In-Reply-To: <1237198269.31135.121.camel@diese.inria.fr> References: <1236790499.658.31.camel@mathieu-laptop> <1237193331.31135.36.camel@diese.inria.fr> <1237198269.31135.121.camel@diese.inria.fr> Message-ID: At Mon, 16 Mar 2009 11:11:09 +0100, Mathieu Lacage wrote: >Anyway, I think you can leave this in for now: the tagging code is going >to undergo changes for the ipv4 rework so, this will probably be solved >during in the ipv4 rework. I see. >> >4) I see a couple of patches to src/process-manager/* which could be >> >merged in ns-3-simu right now, so, it would be nice if you could try to >> >split them from the rest to try to minimize the number of differences >> >between your tree and ns-3-simu. For example, the following looks like a >> >good idea and I would be happy to take patches to add them to >> >http://code.nsnam.org/mathieu/ns-3-simu >> >> Okay, I'll try it later. >> Do you mind if I'll send patches for this modification? >> Or using bugzilla is better? > >you can: > - create a mercurial repo with only the patches you want to send me >and I will pull from this repo, review, and push in mathieu/ns-3-simu > > - or send me raw patches by email (mercurial has a patchbomb >extension: >http://www.selenic.com/mercurial/wiki/index.cgi/PatchbombExtension) Okay, thanks. I'll tell you when I can prepare it. >> >and, I assume that this made a bit difference for you: >> > >> >- std::vector > > openFiles; >> >+ __gnu_cxx::hash_map > openFiles; >> > >> >but, oh, look at src/internet-stack/sgi-hashmap.h: would you mind move >> >it to src/core and use this one instead ? >> >> I don't mind, I just wanna use hash_map, but I wasn't sure >> how I can do it, so just trid to do same as >> src/internet-cache/arp-cache.h. >> >> BTW, using hash_map comes from oprofile output to improve >> performance, but it makes not so big differences. > >If it makes no real difference, then, maybe we can drop this ? I really >have never tried to profile the behavior of the process-manager code so, >I have no idea how it behaves: I would tend to trust you if you did >profile it and if you think it is worth being done :) I agree. Although this modification makes efficiency, I will drop this. >> >The following looks a bit gratuituous: >> > >> >diff -r 89718962b257 -r 6066282751f1 >> >src/process-manager/process-manager.cc >> >--- a/src/process-manager/process-manager.cc Fri Feb 27 23:57:07 2009 >> >+0900 >> >+++ b/src/process-manager/process-manager.cc Wed Mar 11 15:03:07 2009 >> >+0900 >> >@@ -109,12 +109,12 @@ >> > { >> > NS_LOG_FUNCTION (this); >> > GarbageCollectDeadProcessesAndThreads (); >> >- for (std::vector::iterator i = m_processes.begin >> >(); i != m_processes.end (); ++i) >> >+ for (std::vector::iterator i = m_processes.begin >> >(); i != m_processes.end ();) >> > { >> > struct Process *process = *i; >> > DeleteProcess (process); >> >+ i = m_processes.erase (i); >> > } >> >- m_processes.clear (); >> >> I can make a patch, too. > >I meant that I don't really understand what this patch is doing: it >seems that it's really doing the same thing as before, only differently. Ah, sorry. When DeleteProcess is called, and threads is not empty, DeleteProcess hook SIGKILL in the context of DoDispose(), and delivered to simu_exit(). Then process is removed from m_processes before returning DeleteProcess(). So if there is multiple processes in m_processes, it might be problem. This patch try to fix this. >> Is "indent -gnu {all files}" good enough? > >I honestly have no idea. I usually do all the coding style formatting by >hand. The emacs gnu mode helps but it does not do everything. Okay, thanks. regards, hajime From mathieu.lacage at sophia.inria.fr Mon Mar 16 04:46:08 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Mar 2009 12:46:08 +0100 Subject: [Ns-developers] How to maintain a repository for merge In-Reply-To: <49BD54D3.2050701@gmail.com> References: <49BBA62F.9020201@gmail.com> <1237141616.6391.1.camel@mathieu-laptop> <49BD54D3.2050701@gmail.com> Message-ID: <1237203968.31135.266.camel@diese.inria.fr> On Sun, 2009-03-15 at 20:19 +0100, Mirko Banchi wrote: > Added files: All the code looks great ! Comments below. > > src/devices/wifi/qsta-wifi-mac.h > src/devices/wifi/qsta-wifi-mac.cc The above looks good: do you think you could come up with a way of sharing the common code between nqsta-wifi-mac and qsta-wifi-mac ? It seems that the association state handling is fairly similar: maybe it could be pushed in a common base class StaWifiMac which delegates some work to the two subclasses NqstaWifiMac and QstaWifiMac ? The same would also hold for NqapWifiMac and QapWifiMac. Note that I am not saying that you _must_ do this because I suspect that there are some very subtle differences which might make this very painful so, I am just asking that you try to see if it is feasible without making the code unreadable. > src/devices/wifi/qap-wifi-mac.h > src/devices/wifi/qap-wifi-mac.cc This signature does not make me very happy: void ForwardDown (Ptr packet, Mac48Address from, Mac48Address to, WifiMacHeader const *qosHeader = 0); In the past, we have had a lot of debates about function arguments with default values: I know that some disagree with me, but, please, don't use them here: I find that they make it harder for me to follow which methods are called. In this case, I think that you should add two extra arguments to ForwardDown: a tid and a qospolicy and just make them unconditional and make the callers pass the right values. Also, the following can't possibly work: + if (qosHeader != 0) + { ... + } + else + { + uint8_t tid = GetTidForPacket (packet); + if (tid < 8) + { + hdr.SetQosTid (tid); + uint8_t ac = MapTidToAc (qosHeader->GetQosTid ()); ooh, qosHeader is 0... The two functions uint8_t GetTidForPacket (Ptr packet) and uint8_t MapTidToAc (uint8_t tid) could be moved to src/devices/wifi/qos-utils.h or something similar, although, really, not a big deal. > src/devices/wifi/edca-txop-n.h > src/devices/wifi/edca-txop-n.cc Although I see that you use this only for debugging, the m_accessClass field looked pretty bad: ideally, EdcaTxopN would not need to know which class it belongs to. The other thing I am a bit nervous about is m_typeOfStation which I see is used in MapSrcAddress and MapDstAddress. Clearly, using a string comparison against a magic string value here looks fairly bad. If you really must parameterize behavior based on a parameter value, please, use an enum instead of a string here. Anyway, I would be mostly curious to know what other behaviors MapSrcAddress and MapDstAddress could implement. > src/devices/wifi/edca-parameter-set.h > src/devices/wifi/edca-parameter-set.cc The two files above don't look quite right: serializing all these integer arguments in a single string blob looks a bit horrible. It seems to me that each of these parameter could be changed directly as an attribute of the EdcaTxopN class and, then, QstaWifiMac and QapWifiMac could export a set of attributes such as VO_EdcaTxopN, VI_EdcaTxopN, etc. This would allow you to kill the whole EdcaParameterSet class as well as make it easier for users to specify a new value for these attributes (they would not have to learn your serialization format). > src/devices/wifi/msdu-aggregator.h > src/devices/wifi/msdu-aggregator.cc I can't really comment on your aggregation API but, MsgAggregator::Deaggregate: + //a new packet is created + Packet *deaggregatedPacket = new Packet (buffer, hdr.GetLength ()); + Ptr p (deaggregatedPacket); Use Create (buffer, ...) instead of operator new which will get the reference counting right. The above is leaking a count so, you are leaking a packet each time you get there. (for reference, look at Create<> in src/core/ptr.h to see the critical bit you missed :) > src/devices/wifi/msdu-standard-aggregator.h > src/devices/wifi/msdu-standard-aggregator.cc nothing to say here. > src/devices/wifi/amsdu-subframe-header.h > src/devices/wifi/amsdu-subframe-header.cc both look good. > src/helper/msdu-aggregator-helper.h > src/helper/msdu-aggregator-helper.cc I have to confess that I am, again, uneasy about the string-based AC control in this API, but the real issue here is the DynamicCast in Install. It would be really nice to be able to avoid it and one way to do this would be to do what we do for the PHY layer where the creation of the PHY object is delated to a WifiPhyHelper class in src/helper/wifi-helper.h. I think that you could create a similar WifiMacHelper class with a set of subclasses, some of which could export extra information to build the msdu aggregators for the Qos MACs. i.e., class WifiMacHelper { public: virtual Ptr *Create (void); }; class WifiHelper { public: NetDeviceContainer Install (const WifiPhyHelper &phy, const WifiMacHelper &mac, NodeContainer c) const; ... }; and: class NqapWifiMacHelper : public WifiMacHelper { void SetDcaAttribute (name, value, ...); }; class NqstaWifiMacHelper : public WifiMacHelper { ... }; class AdhocWifiMacHelper : public WifiMacHelper { ... }; class QapWifiMacHelper : public WifiMacHelper { void SetMsduAggregator (...); void SetEdcaAttribute (type, name, value, ...); }; class QstaWifiMacHelper : public WifiMacHelper { void SetMsduAggregator (...); void SetEdcaAttribute (type, name, value, ...); }; Of course, you could decrease the number of subclasses with this: class NqosWifiMacHelper : public WifiMacHelper { void SetType (std::string typeid); ... }; class QosWifiMacHelper : public WifiMacHelper { void SetType (std::string typeid); ... }; (either of these option would be fine with me) Ideally, you would also pass an enum-based AC to SetMsduAggregator instead of the string-based AC. > Modified files: > src/devices/wifi/wifi-mac-header.h > src/devices/wifi/wifi-mac-header.cc both look ok to me as-is. > src/devices/wifi/mac-tx-middle.h > src/devices/wifi/mac-tx-middle.cc looks good to me modulo coding style (http://www.nsnam.org/codingstyle.html). For example: + for (; i != m_qosSequences.end (); i++) + delete [] i->second; should be written as: for () { // XXX } + else + { also, wrong indentation: + retval = 0; + std::pair newSeq (hdr->GetAddr1 (), new uint16_t[16]); > src/devices/wifi/wifi-mac-queue.h > src/devices/wifi/wifi-mac-queue.cc the above looks good to me modulo: + Ptr Dequeue (WifiMacHeader *hdr, uint8_t index, Mac48Address addr); the index argument should probably be an enum instead and the documentation for this function should probably try to explain why it is needed. this is really cool: keep up the good work ! Mathieu From mathieu.lacage at sophia.inria.fr Mon Mar 16 04:49:19 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Mar 2009 12:49:19 +0100 Subject: [Ns-developers] About real-world application integration In-Reply-To: References: <1236790499.658.31.camel@mathieu-laptop> <1237193331.31135.36.camel@diese.inria.fr> <1237198269.31135.121.camel@diese.inria.fr> Message-ID: <1237204159.31135.268.camel@diese.inria.fr> On Mon, 2009-03-16 at 19:40 +0900, Hajime Tazaki wrote: > >> > { > >> > NS_LOG_FUNCTION (this); > >> > GarbageCollectDeadProcessesAndThreads (); > >> >- for (std::vector::iterator i = m_processes.begin > >> >(); i != m_processes.end (); ++i) > >> >+ for (std::vector::iterator i = m_processes.begin > >> >(); i != m_processes.end ();) > >> > { > >> > struct Process *process = *i; > >> > DeleteProcess (process); > >> >+ i = m_processes.erase (i); > >> > } > >> >- m_processes.clear (); > >> > >> I can make a patch, too. > > > >I meant that I don't really understand what this patch is doing: it > >seems that it's really doing the same thing as before, only differently. > > Ah, sorry. > > When DeleteProcess is called, and threads is not empty, > DeleteProcess hook SIGKILL in the context of DoDispose(), > and delivered to simu_exit(). Then process is removed from > m_processes before returning DeleteProcess(). > > So if there is multiple processes in m_processes, it might > be problem. This patch try to fix this. I am really very sorry but I don't understand the problem this patch is solving. Could you try to outline for me the exact scenario which is problematic with the previous version ? Mathieu From mathieu.lacage at sophia.inria.fr Mon Mar 16 06:53:24 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Mar 2009 14:53:24 +0100 Subject: [Ns-developers] 802.11s code review Message-ID: <1237211604.31135.393.camel@diese.inria.fr> hi, 2 weeks ago, at the ns-3 workshop (http://www.nsnam.org/wiki/index.php/Wns3-2009), Kirill Andreev presented a 802.11s implementation for ns-3 (http://forge.wenos.ru/hgprojects/ns3dev/). There is really a _lot_ of new code here so, I have done a relatively high-level first review and did not look at very many details. I have explicitely CCed gustavo because I think he could helpfully comment on the code and my own comments below (more specifically, comment 3): 1) I found routing-table-test.cc which, I think, is awesome. It would make sense to make it a test just like src/devices/wifi/wifi-test.cc which is run in an automated way with "./waf check". 2) There are a bunch of coding style issues: http://www.nsnam.org/codingstyle.html summarizes some (but not all) constraints: the goal is really to try to make all of the ns-3 code look the same and make it impossible to figure out who wrote the code by just looking at its indentation and layout. A few quick examples: uint32_t L2RoutingNetDevice::GetIfIndex() const { NS_LOG_FUNCTION_NOARGS (); return m_ifIndex; } should be left-aligned: uint32_t L2RoutingNetDevice::GetIfIndex() const { NS_LOG_FUNCTION_NOARGS (); return m_ifIndex; } this if statement: if (!Mac48Address::IsMatchingType (routingPort->GetAddress ())) NS_FATAL_ERROR ("Device does not support eui 48 addresses: cannot be added to bridge."); should use braces, even for a single-line statement: if (!Mac48Address::IsMatchingType (routingPort->GetAddress ())) { NS_FATAL_ERROR ("Device does not support eui 48 addresses: cannot be added to bridge."); } This inline method declaration (WifiBeaconTimingElement): uint16_t TIMESTAMP_TO_U16(Time x) { return ((uint16_t)((x.GetMicroSeconds() >> 8)&0xffff)); }; should not be inline. i.e., it should be declared here and the implementation moved to the .cc file to maximize the readability of the header. (Of course, its name should follow the MixedCamel convention rather than ALL_UPPER_CASE). enum dot11sPathSelectionProtocol is declared in src/devices/wifi/mesh-configuration-element.h which is a bit un-intuitive: it would be nice if the name of the enum had at least some sort of relationship as to which header it is defined in. The same goes for DestinationAddressUnit defined in mesh-wifi-preq-information-element.h: maybe making it an inner class of the outer WifiPreqInformationElement class would help. I know some people will think I am way too anal about this but, well, that's fine: it's just my job to make everyone miserable :) 3) src/devices/l2-routing/l2-routing-main/l2-routing-net-device.h looks like a more generic version of src/devices/bridge-net-device.cc which delegates l2 forwarding decisions to another class. I wonder if it would be possible to, instead, delegate the forwarding/routing decisions to a subclass through a virtual method from a base class: class L2RoutingNetDevice : public NetDevice { // check device capabilities, register receive callback, // manage associated BridgeChannel, call DoAddPort to notify subclass void AddPort (...); uint32_t GetNPorts (void) const; // Note: it might make sense to add EnablePort and Disable port, just like Hwmp::EnablePort and Hwmp::DisablePort. If so, AddPort should return a port index and Enable and Disable port should take that index. private: // called by ::AddPort virtual void DoAddPort (Ptr dev) = 0; virtual uint32_t DoGetNPorts (void) = 0; // called by ::ReceiveFromDevice and ::Send virtual void DoRoute (Ptr from, Mac48Address src, Mac48Address dst, Ptr p, uint8_t protocol) = 0; }; class HwmpNetDevice : public L2RoutingNetDevice { private: // implement all these methods. virtual void DoAddPort (Ptr dev); virtual uint32_t DoGetNPorts (void); virtual void DoRoute (Ptr from, Mac48Address src, Mac48Address dst, Ptr p, uint8_t protocol); // keep track of the port list. std::vector > m_ports; }; class LearningBridgeNetDevice : L2RoutingNetDevice { private: // implement all these methods. virtual void DoAddPort (Ptr dev); virtual uint32_t DoGetNPorts (void); virtual void DoRoute (Ptr from, Mac48Address src, Mac48Address dst, Ptr p, uint8_t protocol); // keep track of the port list. std::vector > m_ports; }; 4) I remember one of the questions during the wns3 workshop was related to tags and how to remove them. I can see that, in hwmp.cc, they are removed with RemoveAllTags which could be problematic. I don't think we have a better way to handle this for now but the plan is to solve this problem as part of the ipv4-rework over the next 2 weeks (so, as soon as I am done with this review, I will work on fixing this issue to solve your problem here :) 5) Why are MeshWifiMac::SetPrepReceivedCallback, SetPerrReceivedCallback, SetPeerStatusCallback, etc. virtual ? Do you have subclasses of MeshWifiMac ? 6) What happens in MeshWifiMac if one of the packets to forward does not have an HwmpTag ? Is this tag mandatory to make MeshWifiMac work ? If so, maybe it should be renamed MeshWifiMacTag. 7) What is a WifiPeerManager ? What is the purpose of WifiPeerManager::AttachPorts ? I don't see this method being called from anywhere so, I wonder what it's used for. Mathieu From gjcarneiro at gmail.com Mon Mar 16 08:07:57 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 16 Mar 2009 15:07:57 +0000 Subject: [Ns-developers] 802.11s code review In-Reply-To: <1237211604.31135.393.camel@diese.inria.fr> References: <1237211604.31135.393.camel@diese.inria.fr> Message-ID: 2009/3/16 Mathieu Lacage > hi, > > 2 weeks ago, at the ns-3 workshop > (http://www.nsnam.org/wiki/index.php/Wns3-2009), Kirill Andreev > presented a 802.11s implementation for ns-3 > (http://forge.wenos.ru/hgprojects/ns3dev/). > > There is really a _lot_ of new code here so, I have done a relatively > high-level first review and did not look at very many details. I have > explicitely CCed gustavo because I think he could helpfully comment on > the code and my own comments below (more specifically, comment 3): > > 1) I found routing-table-test.cc which, I think, is awesome. It would > make sense to make it a test just like src/devices/wifi/wifi-test.cc > which is run in an automated way with "./waf check". > > 2) There are a bunch of coding style issues: > http://www.nsnam.org/codingstyle.html summarizes some (but not all) > constraints: the goal is really to try to make all of the ns-3 code look > the same and make it impossible to figure out who wrote the code by just > looking at its indentation and layout. A few quick examples: > > uint32_t > L2RoutingNetDevice::GetIfIndex() const > { > NS_LOG_FUNCTION_NOARGS (); > return m_ifIndex; > } > > should be left-aligned: > > uint32_t > L2RoutingNetDevice::GetIfIndex() const > { > NS_LOG_FUNCTION_NOARGS (); > return m_ifIndex; > } > > this if statement: > > if (!Mac48Address::IsMatchingType (routingPort->GetAddress ())) > NS_FATAL_ERROR ("Device does not support eui 48 addresses: cannot be > added to bridge."); > > should use braces, even for a single-line statement: > > if (!Mac48Address::IsMatchingType (routingPort->GetAddress ())) > { > NS_FATAL_ERROR ("Device does not support eui 48 addresses: cannot > be added to bridge."); > } > > This inline method declaration (WifiBeaconTimingElement): > > uint16_t TIMESTAMP_TO_U16(Time x) > { > return ((uint16_t)((x.GetMicroSeconds() >> 8)&0xffff)); > }; > > should not be inline. i.e., it should be declared here and the > implementation moved to the .cc file to maximize the readability of the > header. (Of course, its name should follow the MixedCamel convention > rather than ALL_UPPER_CASE). > > enum dot11sPathSelectionProtocol is declared in > src/devices/wifi/mesh-configuration-element.h which is a bit > un-intuitive: it would be nice if the name of the enum had at least some > sort of relationship as to which header it is defined in. The same goes > for DestinationAddressUnit defined in > mesh-wifi-preq-information-element.h: maybe making it an inner class of > the outer WifiPreqInformationElement class would help. > > I know some people will think I am way too anal about this but, well, > that's fine: it's just my job to make everyone miserable :) > > 3) src/devices/l2-routing/l2-routing-main/l2-routing-net-device.h looks > like a more generic version of src/devices/bridge-net-device.cc which > delegates l2 forwarding decisions to another class. I wonder if it would > be possible to, instead, delegate the forwarding/routing decisions to a > subclass through a virtual method from a base class: > > class L2RoutingNetDevice : public NetDevice > { > // check device capabilities, register receive callback, > // manage associated BridgeChannel, call DoAddPort to notify subclass > void AddPort (...); > uint32_t GetNPorts (void) const; > > // Note: it might make sense to add EnablePort and Disable port, just > like Hwmp::EnablePort and Hwmp::DisablePort. If so, AddPort should > return a port index and Enable and Disable port should take that index. > private: > // called by ::AddPort > virtual void DoAddPort (Ptr dev) = 0; > virtual uint32_t DoGetNPorts (void) = 0; > // called by ::ReceiveFromDevice and ::Send > virtual void DoRoute (Ptr from, Mac48Address src, > Mac48Address dst, Ptr p, uint8_t protocol) = 0; > }; > > class HwmpNetDevice : public L2RoutingNetDevice > { > private: > // implement all these methods. > virtual void DoAddPort (Ptr dev); > virtual uint32_t DoGetNPorts (void); > virtual void DoRoute (Ptr from, Mac48Address src, > Mac48Address dst, Ptr p, uint8_t protocol); > > // keep track of the port list. > std::vector > m_ports; > }; > > class LearningBridgeNetDevice : L2RoutingNetDevice > { > private: > // implement all these methods. > virtual void DoAddPort (Ptr dev); > virtual uint32_t DoGetNPorts (void); > virtual void DoRoute (Ptr from, Mac48Address src, > Mac48Address dst, Ptr p, uint8_t protocol); > > // keep track of the port list. > std::vector > m_ports; > }; OK, here's my first superficial comment. First of all, I was not present at the NS conference, so I am really out of context, looking at this for the first time. I really do not understand why you need an inner learning bridge inside a .11s mesh point netdevice. I do not understand what the concept of "port" inside a netdevice means. Last time I saw a .11s draft (a couple of years ago), I saw nothing of this sort; all I saw was a tree formed by mesh portal announcements, and routing was either "send to the mesh portal" or "discover route using AODV-like or OLSR-like protocol", nothing at all like learning bridge was used for intra-mesh forwarding. So without understanding this "port" concept, I really cannot comment on this. Perhaps the 802.11s standard has evolved, but I wouldn't know because I am not following... One major comment I would have is, stop calling classes L2This and L2That. Layer 2 is too broad a term to be used in this context. Maybe Ieee802Xxx, or MeshXxx. Another major comment on style is that the "design patterns" guys usually say it is bad to design too much inheritance-oriented. Here I see LearningBridgeNetDevice --> L2RoutingNetDevice --> NetDevice. The design patterns gurus often say you should use aggregation instead of inheritance when possible. So ask yourselves, could the same problem be solved via aggregation instead of inheritance without noticeably complicating things? > > 4) I remember one of the questions during the wns3 workshop was related > to tags and how to remove them. I can see that, in hwmp.cc, they are > removed with RemoveAllTags which could be problematic. I don't think we > have a better way to handle this for now but the plan is to solve this > problem as part of the ipv4-rework over the next 2 weeks (so, as soon as > I am done with this review, I will work on fixing this issue to solve > your problem here :) > > 5) Why are MeshWifiMac::SetPrepReceivedCallback, > SetPerrReceivedCallback, SetPeerStatusCallback, etc. virtual ? Do you > have subclasses of MeshWifiMac ? > > 6) What happens in MeshWifiMac if one of the packets to forward does not > have an HwmpTag ? Is this tag mandatory to make MeshWifiMac work ? If > so, maybe it should be renamed MeshWifiMacTag. > > 7) What is a WifiPeerManager ? What is the purpose of > WifiPeerManager::AttachPorts ? I don't see this method being called from > anywhere so, I wonder what it's used for. > > Mathieu > > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From boyko at iitp.ru Mon Mar 16 08:39:01 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Mon, 16 Mar 2009 18:39:01 +0300 Subject: [Ns-developers] 802.11s code review In-Reply-To: <1237211604.31135.393.camel@diese.inria.fr> References: <1237211604.31135.393.camel@diese.inria.fr> Message-ID: <200903161839.02116.boyko@iitp.ru> Mathieu, Gustavo, thank you very much for reviewing our code. All your comments seem reasonable, some of them are already fixed. The others are added to our bug tracker. Just now we are making major refactoring of the architecture and code (don't panic, most of the code remains the same), so I kindly ask you to pause review for 1-2 weeks. By the end of this week I will send you the module architecture description (can I do this on nsnam wiki?) for review. I hope it will answer your questions about bridging, ports, peer management, etc. Best regards, Pavel Boyko, researcher at IITP RAS On Monday 16 March 2009 16:53:24 Mathieu Lacage wrote: > hi, > > 2 weeks ago, at the ns-3 workshop > (http://www.nsnam.org/wiki/index.php/Wns3-2009), Kirill Andreev > presented a 802.11s implementation for ns-3 > (http://forge.wenos.ru/hgprojects/ns3dev/). > > There is really a _lot_ of new code here so, I have done a relatively > high-level first review and did not look at very many details. I have > explicitely CCed gustavo because I think he could helpfully comment on > the code and my own comments below (more specifically, comment 3): > > 1) I found routing-table-test.cc which, I think, is awesome. It would > make sense to make it a test just like src/devices/wifi/wifi-test.cc > which is run in an automated way with "./waf check". > > 2) There are a bunch of coding style issues: > http://www.nsnam.org/codingstyle.html summarizes some (but not all) > constraints: the goal is really to try to make all of the ns-3 code look > the same and make it impossible to figure out who wrote the code by just > looking at its indentation and layout. A few quick examples: > > uint32_t > L2RoutingNetDevice::GetIfIndex() const > { > NS_LOG_FUNCTION_NOARGS (); > return m_ifIndex; > } > > should be left-aligned: > > uint32_t > L2RoutingNetDevice::GetIfIndex() const > { > NS_LOG_FUNCTION_NOARGS (); > return m_ifIndex; > } > > this if statement: > > if (!Mac48Address::IsMatchingType (routingPort->GetAddress ())) > NS_FATAL_ERROR ("Device does not support eui 48 addresses: cannot be > added to bridge."); > > should use braces, even for a single-line statement: > > if (!Mac48Address::IsMatchingType (routingPort->GetAddress ())) > { > NS_FATAL_ERROR ("Device does not support eui 48 addresses: cannot > be added to bridge."); > } > > This inline method declaration (WifiBeaconTimingElement): > > uint16_t TIMESTAMP_TO_U16(Time x) > { > return ((uint16_t)((x.GetMicroSeconds() >> 8)&0xffff)); > }; > > should not be inline. i.e., it should be declared here and the > implementation moved to the .cc file to maximize the readability of the > header. (Of course, its name should follow the MixedCamel convention > rather than ALL_UPPER_CASE). > > enum dot11sPathSelectionProtocol is declared in > src/devices/wifi/mesh-configuration-element.h which is a bit > un-intuitive: it would be nice if the name of the enum had at least some > sort of relationship as to which header it is defined in. The same goes > for DestinationAddressUnit defined in > mesh-wifi-preq-information-element.h: maybe making it an inner class of > the outer WifiPreqInformationElement class would help. > > I know some people will think I am way too anal about this but, well, > that's fine: it's just my job to make everyone miserable :) > > 3) src/devices/l2-routing/l2-routing-main/l2-routing-net-device.h looks > like a more generic version of src/devices/bridge-net-device.cc which > delegates l2 forwarding decisions to another class. I wonder if it would > be possible to, instead, delegate the forwarding/routing decisions to a > subclass through a virtual method from a base class: > > class L2RoutingNetDevice : public NetDevice > { > // check device capabilities, register receive callback, > // manage associated BridgeChannel, call DoAddPort to notify subclass > void AddPort (...); > uint32_t GetNPorts (void) const; > > // Note: it might make sense to add EnablePort and Disable port, just > like Hwmp::EnablePort and Hwmp::DisablePort. If so, AddPort should > return a port index and Enable and Disable port should take that index. > private: > // called by ::AddPort > virtual void DoAddPort (Ptr dev) = 0; > virtual uint32_t DoGetNPorts (void) = 0; > // called by ::ReceiveFromDevice and ::Send > virtual void DoRoute (Ptr from, Mac48Address src, > Mac48Address dst, Ptr p, uint8_t protocol) = 0; > }; > > class HwmpNetDevice : public L2RoutingNetDevice > { > private: > // implement all these methods. > virtual void DoAddPort (Ptr dev); > virtual uint32_t DoGetNPorts (void); > virtual void DoRoute (Ptr from, Mac48Address src, > Mac48Address dst, Ptr p, uint8_t protocol); > > // keep track of the port list. > std::vector > m_ports; > }; > > class LearningBridgeNetDevice : L2RoutingNetDevice > { > private: > // implement all these methods. > virtual void DoAddPort (Ptr dev); > virtual uint32_t DoGetNPorts (void); > virtual void DoRoute (Ptr from, Mac48Address src, > Mac48Address dst, Ptr p, uint8_t protocol); > > // keep track of the port list. > std::vector > m_ports; > }; > > 4) I remember one of the questions during the wns3 workshop was related > to tags and how to remove them. I can see that, in hwmp.cc, they are > removed with RemoveAllTags which could be problematic. I don't think we > have a better way to handle this for now but the plan is to solve this > problem as part of the ipv4-rework over the next 2 weeks (so, as soon as > I am done with this review, I will work on fixing this issue to solve > your problem here :) > > 5) Why are MeshWifiMac::SetPrepReceivedCallback, > SetPerrReceivedCallback, SetPeerStatusCallback, etc. virtual ? Do you > have subclasses of MeshWifiMac ? > > 6) What happens in MeshWifiMac if one of the packets to forward does not > have an HwmpTag ? Is this tag mandatory to make MeshWifiMac work ? If > so, maybe it should be renamed MeshWifiMacTag. > > 7) What is a WifiPeerManager ? What is the purpose of > WifiPeerManager::AttachPorts ? I don't see this method being called from > anywhere so, I wonder what it's used for. > > Mathieu From mathieu.lacage at sophia.inria.fr Mon Mar 16 08:50:13 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Mar 2009 16:50:13 +0100 Subject: [Ns-developers] 802.11s code review In-Reply-To: References: <1237211604.31135.393.camel@diese.inria.fr> Message-ID: <1237218613.31135.416.camel@diese.inria.fr> On Mon, 2009-03-16 at 15:07 +0000, Gustavo Carneiro wrote: > > > 2009/3/16 Mathieu Lacage > I really do not understand why you need an inner learning bridge > inside a .11s mesh point netdevice. I do not understand what the The idea would not be to have an inner learning bridge within a mesh device: it would be to reuse the glue between a node and the forwarding/learning function of a learning bridge and move that common/reused clue in a NetDevice intermediate base class such that both the learning bridge and the routing device share this code. > concept of "port" inside a netdevice means. Last time I saw a .11s > draft (a couple of years ago), I saw nothing of this sort; all I saw > was a tree formed by mesh portal announcements, and routing was either > "send to the mesh portal" or "discover route using AODV-like or > OLSR-like protocol", nothing at all like learning bridge was used for > intra-mesh forwarding. So without understanding this "port" concept, > I really cannot comment on this. Perhaps the 802.11s standard has > evolved, but I wouldn't know because I am not following... I believe, that within the context of this code, a 'port' is merely a network card which the layer-2 routing protocol will manage. What is central to this code seems to be the idea that you don't have to run the same layer-2 routing protocol over all network cards. Note, that, of course, you could chose to implement the routing protocol on top of the netdevices, at a layer logically equivalent to ip and arp, instead of within one of the netdevices. I am not sure what would be the pros and cons of this solution. Well, I can see that it would be simpler to understand the code but, I don't understand enough about this to know what would be the cons. Well, actually, you probably know why the BridgeNetDevice is a NetDevice subclass instead of being an aggregate to the Node which manages all incoming packets and devices, right ? Would you mind spell this out for me ? (yes, I am asking because I can't remember) > > One major comment I would have is, stop calling classes L2This and > L2That. Layer 2 is too broad a term to be used in this context. > Maybe Ieee802Xxx, or MeshXxx. Yes, the current naming is somewhat confusing. > > Another major comment on style is that the "design patterns" guys > usually say it is bad to design too much inheritance-oriented. Here I > see LearningBridgeNetDevice --> L2RoutingNetDevice --> NetDevice. The > design patterns gurus often say you should use aggregation instead of > inheritance when possible. So ask yourselves, could the same problem > be solved via aggregation instead of inheritance without noticeably > complicating things? Well, I sort of already asked myself this question: the current code is really not very trivial to follow and I can see a lot of duplication with the bridge code/API so, I would see value in avoiding both the code duplication and simplifying a bit the code paths to avoid another level of indirection. Right now, the l2routingnetdevice duplicates code from bridgenetdevice and duplicates information from its associated l2routingprotocol: an l2routingprotocol can't really exist without an associated l2routingnetdevice. Mathieu From mathieu.lacage at sophia.inria.fr Mon Mar 16 08:51:32 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Mon, 16 Mar 2009 16:51:32 +0100 Subject: [Ns-developers] 802.11s code review In-Reply-To: <200903161839.02116.boyko@iitp.ru> References: <1237211604.31135.393.camel@diese.inria.fr> <200903161839.02116.boyko@iitp.ru> Message-ID: <1237218692.31135.417.camel@diese.inria.fr> On Mon, 2009-03-16 at 18:39 +0300, Pavel Boyko wrote: > Just now we are making major refactoring of the architecture and code > (don't panic, most of the code remains the same), so I kindly ask you to pause > review for 1-2 weeks. By the end of this week I will send you the module Ok. > architecture description (can I do this on nsnam wiki?) for review. I hope it Yes, of course. > will answer your questions about bridging, ports, peer management, etc. Great ! Mathieu From gjcarneiro at gmail.com Mon Mar 16 09:07:25 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 16 Mar 2009 16:07:25 +0000 Subject: [Ns-developers] 802.11s code review In-Reply-To: <1237218613.31135.416.camel@diese.inria.fr> References: <1237211604.31135.393.camel@diese.inria.fr> <1237218613.31135.416.camel@diese.inria.fr> Message-ID: 2009/3/16 Mathieu Lacage > On Mon, 2009-03-16 at 15:07 +0000, Gustavo Carneiro wrote: > > > > > > 2009/3/16 Mathieu Lacage > > > I really do not understand why you need an inner learning bridge > > inside a .11s mesh point netdevice. I do not understand what the > > The idea would not be to have an inner learning bridge within a mesh > device: it would be to reuse the glue between a node and the > forwarding/learning function of a learning bridge and move that > common/reused clue in a NetDevice intermediate base class such that both > the learning bridge and the routing device share this code. > > > concept of "port" inside a netdevice means. Last time I saw a .11s > > draft (a couple of years ago), I saw nothing of this sort; all I saw > > was a tree formed by mesh portal announcements, and routing was either > > "send to the mesh portal" or "discover route using AODV-like or > > OLSR-like protocol", nothing at all like learning bridge was used for > > intra-mesh forwarding. So without understanding this "port" concept, > > I really cannot comment on this. Perhaps the 802.11s standard has > > evolved, but I wouldn't know because I am not following... > > I believe, that within the context of this code, a 'port' is merely a > network card which the layer-2 routing protocol will manage. What is > central to this code seems to be the idea that you don't have to run the > same layer-2 routing protocol over all network cards. I am still no following. I thought a .11s MAC layer would have its own private instance of a routing agent. Why would you have one routing agent managing more than one .11s card? Is that described in the .11s draft, or any other standard? > > > Note, that, of course, you could chose to implement the routing protocol > on top of the netdevices, at a layer logically equivalent to ip and arp, > instead of within one of the netdevices. I am not sure what would be the > pros and cons of this solution. Well, I can see that it would be simpler > to understand the code but, I don't understand enough about this to know > what would be the cons. > Well, actually, you probably know why the > BridgeNetDevice is a NetDevice subclass instead of being an aggregate to > the Node which manages all incoming packets and devices, right ? Would > you mind spell this out for me ? (yes, I am asking because I can't > remember) The BridgeNetDevice is a (virtual) netdevice because it makes interaction with IPv4 much simpler. You can assign a single IPv4 address to this virtual interface. When IP sends packets to BridgeNetDevice, the packet is flooded to the entire bridged network, and IP routing works correctly because there is only one interface representing the entire bridged network segment. The alternative would be to define a new API to tell IPv4 something like "look, this, this, and that netdevice all are on the same L2 network, so when you send packets send to all of them, not just one". I think a BridgeNetDevice is a simpler approach to the problem. That this is the approach followed by Linux [1] lends weight to this opinion. [1] http://www.linuxfoundation.org/en/Net:Bridge > > > > One major comment I would have is, stop calling classes L2This and > > L2That. Layer 2 is too broad a term to be used in this context. > > Maybe Ieee802Xxx, or MeshXxx. > > Yes, the current naming is somewhat confusing. > > > > Another major comment on style is that the "design patterns" guys > > usually say it is bad to design too much inheritance-oriented. Here I > > see LearningBridgeNetDevice --> L2RoutingNetDevice --> NetDevice. The > > design patterns gurus often say you should use aggregation instead of > > inheritance when possible. So ask yourselves, could the same problem > > be solved via aggregation instead of inheritance without noticeably > > complicating things? > > Well, I sort of already asked myself this question: the current code is > really not very trivial to follow and I can see a lot of duplication > with the bridge code/API so, I would see value in avoiding both the code > duplication and simplifying a bit the code paths to avoid another level > of indirection. Right now, the l2routingnetdevice duplicates code from > bridgenetdevice and duplicates information from its associated > l2routingprotocol: an l2routingprotocol can't really exist without an > associated l2routingnetdevice. > > Mathieu > > > -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From tazaki at sfc.wide.ad.jp Mon Mar 16 09:15:56 2009 From: tazaki at sfc.wide.ad.jp (Hajime Tazaki) Date: Tue, 17 Mar 2009 01:15:56 +0900 Subject: [Ns-developers] About real-world application integration In-Reply-To: <1237198269.31135.121.camel@diese.inria.fr> References: <1236790499.658.31.camel@mathieu-laptop> <1237193331.31135.36.camel@diese.inria.fr> <1237198269.31135.121.camel@diese.inria.fr> Message-ID: At Mon, 16 Mar 2009 11:11:09 +0100, Mathieu Lacage wrote: >I see: it's weird that I did not see the ipv6 part of the patch. To make >sure I don't forget anything, would you mind send me a list of files you >have modified and files you have added ? Followings are modified/added files in my repository. Diff is based on rev 4583 of code.nsnam.org/mathieu/ns-3-simu changeset: 4583:ed8a51921025 tag: tip user: Mathieu Lacage date: Wed Dec 03 07:38:46 2008 +0100 summary: typo .hgignore bindings/python/ns3_module_helper.py bindings/python/ns3_module_node.py examples/process-quagga.cc examples/third.cc examples/wifi-wired-bridging.cc examples/wscript scratch/process-zebra.cc scratch/process-zebra.py src/applications/icmpv6-test-error/icmpv6-test-error.cc src/applications/icmpv6-test-error/icmpv6-test-error.h src/applications/icmpv6-test-error/waf src/applications/icmpv6-test-error/wscript src/applications/ping6/ping6.cc src/applications/ping6/ping6.h src/applications/ping6/waf src/applications/ping6/wscript src/applications/radvd/config-interface.cc src/applications/radvd/config-interface.h src/applications/radvd/radvd.cc src/applications/radvd/radvd.h src/applications/radvd/wscript src/applications/tcp-echo6/tcp-echo6-client.cc src/applications/tcp-echo6/tcp-echo6-client.h src/applications/tcp-echo6/tcp-echo6-server.cc src/applications/tcp-echo6/tcp-echo6-server.h src/applications/tcp-echo6/waf src/applications/tcp-echo6/wscript src/applications/udp-echo6/udp-echo6-client.cc src/applications/udp-echo6/udp-echo6-client.h src/applications/udp-echo6/udp-echo6-server.cc src/applications/udp-echo6/udp-echo6-server.h src/applications/udp-echo6/waf src/applications/udp-echo6/wscript src/contrib/nam-helper.cc src/contrib/nam-helper.h src/contrib/visualizer/core.py src/contrib/wscript src/devices/bridge/bridge-net-device.cc src/devices/bridge/bridge-net-device.h src/devices/csma/csma-net-device.cc src/devices/csma/csma-net-device.h src/devices/emu/emu-net-device.cc src/devices/emu/emu-net-device.h src/devices/point-to-point/point-to-point-net-device.cc src/devices/point-to-point/point-to-point-net-device.h src/devices/tap/host-tap-net-device.cc src/devices/tap/host-tap-net-device.h src/devices/tap/tap-net-device.cc src/devices/tap/tap-net-device.h src/devices/wifi/dca-txop.cc src/devices/wifi/mac-low.cc src/devices/wifi/mac-rx-middle.cc src/devices/wifi/mac-tx-middle.cc src/devices/wifi/nqap-wifi-mac.cc src/devices/wifi/nqsta-wifi-mac.cc src/devices/wifi/wifi-net-device.cc src/devices/wifi/wifi-net-device.h src/devices/wifi/wifi-phy-state-helper.cc src/devices/wifi/wifi-remote-station-manager.cc src/devices/wifi/yans-wifi-channel.cc src/devices/wifi/yans-wifi-phy.cc src/helper/icmpv6-test-error-helper.cc src/helper/icmpv6-test-error-helper.h src/helper/internet-stackv6-helper.cc src/helper/internet-stackv6-helper.h src/helper/ipv6-address-helper.cc src/helper/ipv6-address-helper.h src/helper/ipv6-interface-container.cc src/helper/ipv6-interface-container.h src/helper/netlink-socket-helper.cc src/helper/netlink-socket-helper.h src/helper/ping6-helper.cc src/helper/ping6-helper.h src/helper/radvd-helper.cc src/helper/radvd-helper.h src/helper/tcp-echo6-helper.cc src/helper/tcp-echo6-helper.h src/helper/udp-echo6-helper.cc src/helper/udp-echo6-helper.h src/helper/wscript src/internet-stack/arp-cache.cc src/internet-stack/arp-cache.h src/internet-stack/icmpv6-header.cc src/internet-stack/icmpv6-header.h src/internet-stack/icmpv6-l4-protocol.cc src/internet-stack/icmpv6-l4-protocol.h src/internet-stack/icmpv6-socket-factory-impl.cc src/internet-stack/icmpv6-socket-factory-impl.h src/internet-stack/icmpv6-socket-impl.cc src/internet-stack/icmpv6-socket-impl.h src/internet-stack/internet-stackv6.cc src/internet-stack/internet-stackv6.h src/internet-stack/ipv6-end-point-demux.cc src/internet-stack/ipv6-end-point-demux.h src/internet-stack/ipv6-end-point.cc src/internet-stack/ipv6-end-point.h src/internet-stack/ipv6-extension-demux.cc src/internet-stack/ipv6-extension-demux.h src/internet-stack/ipv6-extension-header.cc src/internet-stack/ipv6-extension-header.h src/internet-stack/ipv6-extension.cc src/internet-stack/ipv6-extension.h src/internet-stack/ipv6-impl.cc src/internet-stack/ipv6-impl.h src/internet-stack/ipv6-interface.cc src/internet-stack/ipv6-interface.h src/internet-stack/ipv6-l3-protocol.cc src/internet-stack/ipv6-l3-protocol.h src/internet-stack/ipv6-l4-protocol.cc src/internet-stack/ipv6-l4-protocol.h src/internet-stack/ipv6-loopback-interface.cc src/internet-stack/ipv6-loopback-interface.h src/internet-stack/ipv6-option-demux.cc src/internet-stack/ipv6-option-demux.h src/internet-stack/ipv6-option-header.cc src/internet-stack/ipv6-option-header.h src/internet-stack/ipv6-option.cc src/internet-stack/ipv6-option.h src/internet-stack/ipv6-socket-impl.cc src/internet-stack/ipv6-socket-impl.h src/internet-stack/ipv6-static-routing.cc src/internet-stack/ipv6-static-routing.h src/internet-stack/ndisc-cache.cc src/internet-stack/ndisc-cache.h src/internet-stack/ndisc-ipv6-interface.cc src/internet-stack/ndisc-ipv6-interface.h src/internet-stack/router-prefix.cc src/internet-stack/router-prefix.h src/internet-stack/tcp-header.cc src/internet-stack/tcp-header.h src/internet-stack/tcp-socket-impl.cc src/internet-stack/tcp6-l4-protocol.cc src/internet-stack/tcp6-l4-protocol.h src/internet-stack/tcp6-socket-factory-impl.cc src/internet-stack/tcp6-socket-factory-impl.h src/internet-stack/tcp6-socket-impl.cc src/internet-stack/tcp6-socket-impl.h src/internet-stack/udp-header.cc src/internet-stack/udp-header.h src/internet-stack/udp6-l4-protocol.cc src/internet-stack/udp6-l4-protocol.h src/internet-stack/udp6-socket-factory-impl.cc src/internet-stack/udp6-socket-factory-impl.h src/internet-stack/udp6-socket-impl.cc src/internet-stack/udp6-socket-impl.h src/internet-stack/wscript src/mobility/wscript src/node/icmp-socket.cc src/node/icmp-socket.h src/node/icmpv6-socket-factory.cc src/node/icmpv6-socket-factory.h src/node/ipv6-address.cc src/node/ipv6-address.h src/node/ipv6-route.cc src/node/ipv6-route.h src/node/ipv6.cc src/node/ipv6.h src/node/mac48-address.cc src/node/mac48-address.h src/node/net-device.h src/node/netlink-attribute.cc src/node/netlink-attribute.h src/node/netlink-ipv6-routing-table.cc src/node/netlink-ipv6-routing-table.h src/node/netlink-message-route.cc src/node/netlink-message-route.h src/node/netlink-message.cc src/node/netlink-message.h src/node/netlink-socket-address.cc src/node/netlink-socket-address.h src/node/netlink-socket-factory.cc src/node/netlink-socket-factory.h src/node/netlink-socket-test.cc src/node/netlink-socket.cc src/node/netlink-socket.h src/node/node.cc src/node/simple-net-device.cc src/node/simple-net-device.h src/node/socket.cc src/node/socket.h src/node/tcp6-socket-factory.cc src/node/tcp6-socket-factory.h src/node/udp6-socket-factory.cc src/node/udp6-socket-factory.h src/node/wscript src/process-manager/alloc.cc src/process-manager/cmsg.cc src/process-manager/cmsg.h src/process-manager/fiber-context-pthread.c src/process-manager/fiber-context-ucontext.c src/process-manager/libc-global-variables.c src/process-manager/libc-simu.c src/process-manager/libc.c src/process-manager/libc.h src/process-manager/process-manager.cc src/process-manager/process.h src/process-manager/simu-fcntl.h src/process-manager/simu-fd.cc src/process-manager/simu-stdio.cc src/process-manager/simu-stdio.h src/process-manager/simu-unistd.h src/process-manager/simu.cc src/process-manager/unix-datagram-socket-fd.cc src/process-manager/unix-socket-fd.cc src/process-manager/unix-socket-fd.h src/process-manager/unix-stream-socket-fd.cc src/process-manager/utils.cc src/process-manager/waiter.cc src/wscript wscript wutils.py Currently, there is a lot of nonsense diff in this modification (e.g. only diff comment paragraph), sorry. regards, hajime From tazaki at sfc.wide.ad.jp Mon Mar 16 09:45:19 2009 From: tazaki at sfc.wide.ad.jp (Hajime Tazaki) Date: Tue, 17 Mar 2009 01:45:19 +0900 Subject: [Ns-developers] About real-world application integration In-Reply-To: <1237204159.31135.268.camel@diese.inria.fr> References: <1236790499.658.31.camel@mathieu-laptop> <1237193331.31135.36.camel@diese.inria.fr> <1237198269.31135.121.camel@diese.inria.fr> <1237204159.31135.268.camel@diese.inria.fr> Message-ID: At Mon, 16 Mar 2009 12:49:19 +0100, Mathieu Lacage wrote: > >On Mon, 2009-03-16 at 19:40 +0900, Hajime Tazaki wrote: > >> >> > { >> >> > NS_LOG_FUNCTION (this); >> >> > GarbageCollectDeadProcessesAndThreads (); >> >> >- for (std::vector::iterator i = m_processes.begin >> >> >(); i != m_processes.end (); ++i) >> >> >+ for (std::vector::iterator i = m_processes.begin >> >> >(); i != m_processes.end ();) >> >> > { >> >> > struct Process *process = *i; >> >> > DeleteProcess (process); >> >> >+ i = m_processes.erase (i); >> >> > } >> >> >- m_processes.clear (); >> >> >> >> I can make a patch, too. >> > >> >I meant that I don't really understand what this patch is doing: it >> >seems that it's really doing the same thing as before, only differently. >> >> Ah, sorry. >> >> When DeleteProcess is called, and threads is not empty, >> DeleteProcess hook SIGKILL in the context of DoDispose(), >> and delivered to simu_exit(). Then process is removed from >> m_processes before returning DeleteProcess(). >> >> So if there is multiple processes in m_processes, it might >> be problem. This patch try to fix this. > >I am really very sorry but I don't understand the problem this patch is >solving. Could you try to outline for me the exact scenario which is >problematic with the previous version ? Let me show you gdb stack of this problem. This stack was reproduced by previous version. #12 0xb7b4c630 in ns3::ProcessManager::DeleteProcess (this=0x80add28, process=0x87d5e10) #13 0xb7b4cab7 in ns3::ProcessManager::GarbageCollectDeadProcessesAndThreads (this=0x80add28) #14 0xb7b4f0ff in ns3::ProcessManager::Schedule (this=0x80add28) #15 0xb7b4fa52 in ns3::ProcessManager::ScheduleFromInterrupt (this=0x80add28, thread=0x87d8ab8) #16 0xb7b77e98 in ns3::UtilsSendSignal (process=0x87d8520, signum=9) #17 0xb7b4c564 in ns3::ProcessManager::DeleteProcess (this=0x80add28, process=0x87d8520) #18 0xb7b4fc14 in ns3::ProcessManager::DoDispose (this=0x80add28) #19 0xb77d28ed in ns3::Object::Dispose (this=0x80839f8) #20 0xb7936757 in ~NodeListPriv (this=0x80839b8) #21 0xb77d2187 in ns3::Object::MaybeDelete (this=0x80839b8) #22 0x0805f102 in ns3::Object::Unref (this=0x80839b8) #23 0xb7938f0e in ns3::Ptr::operator= (this=0xb7f195a0, o=@0xbfd3a040) #24 0xb793818c in ns3::NodeListPriv::Delete () #25 0xb7885592 in Notify (this=0x8083888) #26 0xb786038a in ns3::EventImpl::Invoke (this=0x8083888) #27 0xb788d3f7 in ns3::RealtimeSimulatorImpl::Destroy (this=0x8083a38) When the destroy event of simulator is happened, DeleteProcess is called twice for each process. and DeleteProcess in GarbageCollectDeadProcessesAndThreads() remove process entry from m_processes even though it was called from DoDispose(). So after one loop in DoDispose(), contents of m_processes would be changed. In that case, single process in a node made no problem. OTOH, when we install multiple processes into single node, as ApplicationContainer apps = process.Install (node); ApplicationContainer apps2 = process2.Install (node); #this is a typical case when we use zebra m_processes becomes to have a 2 entry in vector. But..... I become to think that this modification doesn't solve fundamentals. Should it avoid call DeleteProcee() twice? What do you think? regards, hajime From boyko at iitp.ru Mon Mar 16 09:51:46 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Mon, 16 Mar 2009 19:51:46 +0300 Subject: [Ns-developers] 802.11s code review In-Reply-To: References: <1237211604.31135.393.camel@diese.inria.fr> <1237218613.31135.416.camel@diese.inria.fr> Message-ID: <200903161951.47130.boyko@iitp.ru> Gustavo, On Monday 16 March 2009 19:07:25 Gustavo Carneiro wrote: > I am still no following. I thought a .11s MAC layer would have its own > private instance of a routing agent. Why would you have one routing agent > managing more than one .11s card? Is that described in the .11s draft, or > any other standard? No, unfortunately 11s draft doesn't describe coordinated operation of the several wireless interfaces on the single mesh point. However, single interface mesh points don't look promising for our needs, you can find some very basic discussion even here: http://en.wikipedia.org/wiki/History_of_wireless_mesh_networking So we have decided to extend 11s draft model from the very start. One can obviously use single interface configuration in your simulation if you wish to exactly follow 11s. The way we propose to model multi-interface mesh point is really very similar to 'plain' bridging. The main difference is that our virtual mesh point device can (and do) _change_ packets it forwards from/to its interfaces, e.g. adding routing information. We don't subclass (and even use) BridgeNetDevice for this reason (using, however, BridgeChannel class). Regards, Pavel From craigdo at ee.washington.edu Mon Mar 16 10:05:13 2009 From: craigdo at ee.washington.edu (craigdo@ee.washington.edu) Date: Mon, 16 Mar 2009 10:05:13 -0700 Subject: [Ns-developers] ns-3.4 : Final Steps In-Reply-To: <1237188286.31135.13.camel@diese.inria.fr> References: <12d69e490903130858s62eabaf9y138d697da12f79aa@mail.gmail.com> <1237188286.31135.13.camel@diese.inria.fr> Message-ID: > > ======Tracing====== > > There are 2 bugs related to tracing (443 and 505). The main one is > > the trace source rework of bug 443. It is queued up for merge at: > > http://code.nsnam.org/craigdo/ns-3-tracing > > This needs a little review, and I have not seen any further comments > > from others. > > I reviewed the src/devices/wifi part of the last version: Thanks for getting to this so quickly, Mathieu. > there are a > couple of uneeded changes: > > and wifi-net-device.h: > void SniffPacket (Ptr packet, Mac48Address to, > Mac48Address from, uint16_t type); > > wifi-net-device.cc: > +#include "ns3/ethernet-header.h" > +#include "ns3/ethernet-trailer.h" Done and done. > and, in wifi-net-device.cc: are you sure you need the copy below ? > > - m_promiscRx (this, packet, llc.GetType (), from, to, type); > + m_promiscRx (this, packet->Copy (), llc.GetType (), from, to, > type); This was not necessary. It prompted me to do a sweep through the devices looking for packet copies and I found a few other instances and fixed them as well. I updated CHANGES.html, so ... Raj, how do you want to proceed with merging this. There will be massive trace file changes, so it is probably best if you just let me have ns-3-dev for a couple of hours and let me get everything tested, consistent and then plugged back together. Sound good? -- Craig From gjcarneiro at gmail.com Mon Mar 16 10:34:59 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 16 Mar 2009 17:34:59 +0000 Subject: [Ns-developers] 802.11s code review In-Reply-To: <200903161951.47130.boyko@iitp.ru> References: <1237211604.31135.393.camel@diese.inria.fr> <1237218613.31135.416.camel@diese.inria.fr> <200903161951.47130.boyko@iitp.ru> Message-ID: 2009/3/16 Pavel Boyko > Gustavo, > > On Monday 16 March 2009 19:07:25 Gustavo Carneiro wrote: > > I am still no following. I thought a .11s MAC layer would have its own > > private instance of a routing agent. Why would you have one routing > agent > > managing more than one .11s card? Is that described in the .11s draft, > or > > any other standard? > > No, unfortunately 11s draft doesn't describe coordinated operation of the > several wireless interfaces on the single mesh point. However, single > interface mesh points don't look promising for our needs, you can find some > very basic discussion even here: > http://en.wikipedia.org/wiki/History_of_wireless_mesh_networking > > So we have decided to extend 11s draft model from the very start. One can > obviously use single interface configuration in your simulation if you wish > to > exactly follow 11s. > > The way we propose to model multi-interface mesh point is really very > similar > to 'plain' bridging. The main difference is that our virtual mesh point > device > can (and do) _change_ packets it forwards from/to its interfaces, e.g. > adding > routing information. We don't subclass (and even use) BridgeNetDevice for > this > reason (using, however, BridgeChannel class). Not saying what you are doing is wrong, but in my opinion we shouldn't indistinctly mix code implementing a standard with code implementing a research architecture. Maybe it's just me, but I find it just too confusing (as evidenced by the number of emails I had to send to clear my doubts). In my humble opinion, it would be much better if multi-interface support was completely separate from .11s, and be conceptually "above" the netdevice. In a different module, even. Refactoring the 'src/devices/bridge' module to support mesh bridging could be an option, I think. At least I don't see anything wrong with it in principle... Regards, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From rbhattacharjea at gmail.com Mon Mar 16 11:26:45 2009 From: rbhattacharjea at gmail.com (raj bhattacharjea) Date: Mon, 16 Mar 2009 14:26:45 -0400 Subject: [Ns-developers] ns-3.4 : Final Steps In-Reply-To: References: <12d69e490903130858s62eabaf9y138d697da12f79aa@mail.gmail.com> <1237188286.31135.13.camel@diese.inria.fr> Message-ID: <12d69e490903161126g7e0b0204yaa82c45edb36e26@mail.gmail.com> On Mon, Mar 16, 2009 at 1:05 PM, wrote: > > Raj, how do you want to proceed with merging this. ?There will be massive > trace file changes, so it is probably best if you just let me have ns-3-dev > for a couple of hours and let me get everything tested, consistent and then > plugged back together. ?Sound good? > Go ahead. I'll stay out of your way with the TCP changes until you are done. Thanks! -- Raj Bhattacharjea Georgia Institute of Technology School of Electrical and Computer Engineering Ph.D. Candidate Systems Analyst 404.894.2955 From ruben at net.t-labs.tu-berlin.de Mon Mar 16 11:31:45 2009 From: ruben at net.t-labs.tu-berlin.de (Ruben Merz) Date: Mon, 16 Mar 2009 19:31:45 +0100 Subject: [Ns-developers] 802.11s code review In-Reply-To: References: <1237211604.31135.393.camel@diese.inria.fr> <1237218613.31135.416.camel@diese.inria.fr> <200903161951.47130.boyko@iitp.ru> Message-ID: <49BE9B11.4020101@net.t-labs.tu-berlin.de> Dear Pavel, Gustavo On 3/16/09 6:34 PM, Gustavo Carneiro wrote: > 2009/3/16 Pavel Boyko > >> Gustavo, >> >> On Monday 16 March 2009 19:07:25 Gustavo Carneiro wrote: >>> I am still no following. I thought a .11s MAC layer would have its own >>> private instance of a routing agent. Why would you have one routing >> agent >>> managing more than one .11s card? Is that described in the .11s draft, >> or >>> any other standard? >> No, unfortunately 11s draft doesn't describe coordinated operation of the >> several wireless interfaces on the single mesh point. However, single >> interface mesh points don't look promising for our needs, you can find some >> very basic discussion even here: >> http://en.wikipedia.org/wiki/History_of_wireless_mesh_networking >> >> So we have decided to extend 11s draft model from the very start. One can >> obviously use single interface configuration in your simulation if you wish >> to >> exactly follow 11s. >> >> The way we propose to model multi-interface mesh point is really very >> similar >> to 'plain' bridging. The main difference is that our virtual mesh point >> device >> can (and do) _change_ packets it forwards from/to its interfaces, e.g. >> adding >> routing information. We don't subclass (and even use) BridgeNetDevice for >> this >> reason (using, however, BridgeChannel class). > > > Not saying what you are doing is wrong, but in my opinion we shouldn't > indistinctly mix code implementing a standard with code implementing a > research architecture. Maybe it's just me, but I find it just too confusing > (as evidenced by the number of emails I had to send to clear my doubts). Yep, I agree too. There should be a clear distinction between what is really standard compliant (i.e. defined in the standard) and what is (a) inferred from the standard because it was not clearly defined in the standard (b) research stuff. From my point of view, this distinction should be made clear in the code (though I don't have a clear idea how) and in the documentation. Ruben > In my humble opinion, it would be much better if multi-interface support was > completely separate from .11s, and be conceptually "above" the netdevice. > In a different module, even. Refactoring the 'src/devices/bridge' module to > support mesh bridging could be an option, I think. At least I don't see > anything wrong with it in principle... > > Regards, > From Amine.Ismail at sophia.inria.fr Mon Mar 16 01:56:17 2009 From: Amine.Ismail at sophia.inria.fr (Mohamed Amine Ismail) Date: Mon, 16 Mar 2009 09:56:17 +0100 Subject: [Ns-developers] Wimax compile error Message-ID: <200903160956.17808.Amine.Ismail@sophia.inria.fr> Dear Dan, Our WiMAX module for ns-3 has been successfully compiled using the gcc-4.2 and gcc-3.4. We have some problem with other compiler version. you can use the following command to compile the code with a particular version of gcc: CXX="gcc path" ./waf configure; ./waf example: CXX="/usr/bin/gcc-4.2" ./waf configure; ./waf Best Regards, Amine >Dear Mathieu, >I try to compile wimax from ns-3 development tree. >I got the compile error that confused me. >I guess it could be class constructor initialization >error. but I don't find where this error is. >Could you please help me to say why wimax-ss-net-device.cc >is not compilable? >The error message is below. >Looking forward to hearing from you soon, >Best Regards, >Dan From raj.b at gatech.edu Mon Mar 16 13:31:51 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Mon, 16 Mar 2009 16:31:51 -0400 Subject: [Ns-developers] ns3::RandomVariable In-Reply-To: <6955346121364463167@unknownmsgid> References: <6955346121364463167@unknownmsgid> Message-ID: <12d69e490903161331l699e3fb4x4b81c9379cba117e@mail.gmail.com> I am moving the discussion onto the developer's list, so please "reply all" for further correspondence. See my comments inline below. On Thu, Mar 12, 2009 at 9:41 AM, Pascal Kesseli wrote: > Dear Mr Bhattacharjea > > > > Currently, we are developing a RTP traffic generator for NS3 as our > bachelor?s thesis. While programming, we encountered the issue that some > classes, e.g. ns3::RandomVariable, are not derived from ns3::Object. Thus, > they cannot be used with ns3::Ptr, as the required Ref- and Unref-methods The current design does something like what ns3::Ptr does, just "under the covers" and without using Ptr objects. Let me try and explain: There are the publicly visible RandomVariable subclasses which you know and interact with regularly to get numbers from a certain distribution. If you look at the code however, you will see that these classes are just wrappers for underlying "Impl" classes. That is, e.g. UniformVariable forwards its relevant calls to UniformVariableImpl. The wrapper class, in addition to forwarding calls, knows how to copy the underlying Impl, so that the user experiences value semantics. This was done so that anonymous temporary RandomVariables could be passed around as parameters: DoSomething(UniformVariable(1,3)); In summary, the user visible classes, i.e. RandomVariable subclasses, are in some sense pointers that manage an underlying Impl. > are not present. Doing so would be necessary for our project, as we want our > traffic generator to be configured with various RandomVariable parameters, > preferably passed as ns3::Ptr references (and stored polymorphically in an > ns3::Ptr reference). The classes in fact already have polymorphic semantics, just without the explicit "Ptr": RandomVariable x = UniformVariable(1,2); RandomVariable y = ParetoVariable(...); etc... I know this looks weird (you may be wondering "where is the * or Ptr on the LHS and the new or Create<> on the RHS"), but it is what we have in ns-3, in the specific case of the RNGs. Note that none of our other classes really use these semantics. The RandomVariable class is kind of a pointer already, able to hold any of the Impl classes, and the whole effect provides this slightly odd value semantic. > > > > Can you suggest a possible solution for this situation? And, by the way, how You should be able to achieve exactly what you desire using ns-3 as-is; for an example of a traffic generator which takes RandomVariable subclasses as parameters (without using Ptr), see the OnOff application. It achieves the effect by using the ns-3 attributes/TypeId system, but you could just as easily have methods like: MyApplication::SetRNG(RandomVariable x) And then call this like: Ptr app; RandomVariable ranvar = ExponentialVariable(10); app->SetRNG(ranvar); > do you feel about using third party (header-only) libraries, as e.g. Boost > and its shared_ptr in such situations? > I think there was some discussion about using Boost or other ready-made smart pointer solutions a long time ago. Personally, I think our Ptr solution keeps out an additional external build dependency, and it is tailored to do exactly what we require in ns-3. -- 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 Mon Mar 16 15:13:42 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Mon, 16 Mar 2009 22:13:42 +0000 Subject: [Ns-developers] ns3::RandomVariable In-Reply-To: <12d69e490903161331l699e3fb4x4b81c9379cba117e@mail.gmail.com> References: <6955346121364463167@unknownmsgid> <12d69e490903161331l699e3fb4x4b81c9379cba117e@mail.gmail.com> Message-ID: 2009/3/16 Raj Bhattacharjea > I am moving the discussion onto the developer's list, so please "reply > all" for further correspondence. See my comments inline below. > > On Thu, Mar 12, 2009 at 9:41 AM, Pascal Kesseli > wrote: > > Dear Mr Bhattacharjea > > > > > > > > Currently, we are developing a RTP traffic generator for NS3 as our > > bachelor?s thesis. While programming, we encountered the issue that some > > classes, e.g. ns3::RandomVariable, are not derived from ns3::Object. > Thus, > > they cannot be used with ns3::Ptr, as the required Ref- and Unref-methods > > The current design does something like what ns3::Ptr does, just "under > the covers" and without using Ptr objects. Let me try and explain: I should point out that there is a fundamental difference between Ptr and the RandomVariable classes. With Ptr, when you copy a pointer variable the original object is not copied. With a RandomVariable variable, copying the variable will trigger a under-the-hood copy of the underlying XxxImpl. Mathieu, correct me if I'm wrong (possible :) But perhaps the difference does not matter in this case. After all, a RandomVariable object is supposed to generate a series random numbers, and they are supposed to be independent. So it should not matter whether you generate two random numbers from a single RandomVariable object or one number from one RandomVariable A and another one from a RandomVariable B, where B is a copy of A. > > > There are the publicly visible RandomVariable subclasses which you > know and interact with regularly to get numbers from a certain > distribution. If you look at the code however, you will see that > these classes are just wrappers for underlying "Impl" classes. That > is, e.g. UniformVariable forwards its relevant calls to > UniformVariableImpl. The wrapper class, in addition to forwarding > calls, knows how to copy the underlying Impl, so that the user > experiences value semantics. This was done so that anonymous > temporary RandomVariables could be passed around as parameters: > > DoSomething(UniformVariable(1,3)); > > In summary, the user visible classes, i.e. RandomVariable subclasses, > are in some sense pointers that manage an underlying Impl. > > > are not present. Doing so would be necessary for our project, as we want > our > > traffic generator to be configured with various RandomVariable > parameters, > > preferably passed as ns3::Ptr references (and stored polymorphically in > an > > ns3::Ptr reference). > > The classes in fact already have polymorphic semantics, just without > the explicit "Ptr": > > RandomVariable x = UniformVariable(1,2); > RandomVariable y = ParetoVariable(...); > etc... > > I know this looks weird (you may be wondering "where is the * or Ptr > on the LHS and the new or Create<> on the RHS"), but it is what we > have in ns-3, in the specific case of the RNGs. Note that none of our > other classes really use these semantics. > > The RandomVariable class is kind of a pointer already, able to hold > any of the Impl classes, and the whole effect provides this slightly > odd value semantic. > > > > > > > > > Can you suggest a possible solution for this situation? And, by the way, > how > > You should be able to achieve exactly what you desire using ns-3 > as-is; for an example of a traffic generator which takes > RandomVariable subclasses as parameters (without using Ptr), see the > OnOff application. It achieves the effect by using the ns-3 > attributes/TypeId system, but you could just as easily have methods > like: > > MyApplication::SetRNG(RandomVariable x) > > And then call this like: > > Ptr app; > RandomVariable ranvar = ExponentialVariable(10); > app->SetRNG(ranvar); > > > > do you feel about using third party (header-only) libraries, as e.g. > Boost > > and its shared_ptr in such situations? > > > > I think there was some discussion about using Boost or other > ready-made smart pointer solutions a long time ago. Personally, I > think our Ptr solution keeps out an additional external build > dependency, and it is tailored to do exactly what we require in ns-3. Absolutely! /me loves ns3/ptr.h :-) -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert From Guangyu.Pei at boeing.com Mon Mar 16 17:25:18 2009 From: Guangyu.Pei at boeing.com (Pei, Guangyu) Date: Mon, 16 Mar 2009 17:25:18 -0700 Subject: [Ns-developers] Allow GNU Scientific Library (GSL) in ns-3? Message-ID: Hi, I am wondering what is the preferred way of linking other libraries such as GNU Scientific Library (GSL) http://www.gnu.org/software/gsl/ in ns-3? I encountered a case in which I need more math tools than standard functions defined in math.h. In particular, I try to implement theoretical 802.11b CCK symbol error probabilities defined in equation (18) and (17) of paper by Pursley and Royster: "Properties and Performance of the IEEE 802.11b Complementary-Code-Key Signal Sets", IEEE Transactions on Communications, vol, 57, No.2, Feb. 2009. To evaluate these equation numerically, more advanced math library such as GSL becomes handy. What will be the ns-3 policy for linking non-standard library such as GSL? I really appreciate your help and comments, Thanks, Gary From raj.b at gatech.edu Mon Mar 16 18:00:31 2009 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Mon, 16 Mar 2009 21:00:31 -0400 Subject: [Ns-developers] ns-3.4 Daily Status for Monday, March 16, 2008 Message-ID: <12d69e490903161800i7bb7f7d7o2348103c08ea8b30@mail.gmail.com> Dear All, I am going to start doing these daily updates regarding the upcoming release. The bulk of the information will be kept up-to-date here: http://www.nsnam.org/wiki/index.php/Ns-3.4 I will keep emailing out this link along with status changes. News: ===== None. Bugs: ===== There are 10 P1 bugs in the tracker, and 5 lower priority P2 bugs: http://www.nsnam.org/wiki/index.php/Ns-3.4#The_ns-3.4_Bug_List Progress / Closed Bugs: ======================= Since the last email, no additional bugs have been closed. http://mailman.isi.edu/pipermail/ns-developers/2009-March/005455.html Craig is however, merging the tracing work (and a one line fix for bug 510), I expect by early tomorrow (Tuesday), and as soon as he is done, I will be merging the TCP fixes. There is still one critical bug that will remain after that, that will hopefully be resolved quickly. New Bugs: ========= None. Next Steps: =========== The first release candidate will be posted on Thursday, March 19. A full schedule of upcoming milestones can be found here: http://www.nsnam.org/wiki/index.php/Ns-3.4#The_ns-3.4_Release_Schedule -- Raj Bhattacharjea Georgia Institute of Technology School of Electrical and Computer Engineering Ph.D. Candidate Systems Analyst 404.894.2955 From tjkopena at cs.drexel.edu Mon Mar 16 19:52:18 2009 From: tjkopena at cs.drexel.edu (Joseph Kopena) Date: Mon, 16 Mar 2009 22:52:18 -0400 Subject: [Ns-developers] Allow GNU Scientific Library (GSL) in ns-3? In-Reply-To: References: Message-ID: <13786f330903161952k701b6095od307d63640c1f005@mail.gmail.com> On Mon, Mar 16, 2009 at 8:25 PM, Pei, Guangyu wrote: > I am wondering what is the preferred way of linking other libraries such > as GNU Scientific Library (GSL) http://www.gnu.org/software/gsl/ in > ns-3? Gary, If you mean how to do this within the build system, there was a thread on the ns-3-users list a little while ago that talked about it. Search for "link a library." It's from November 2008. You can also look in the contributed and examples wscript files, e.g. for the configurator or DB support in the stats package for examples. [1] http://groups.google.com/group/ns-3-users -- - joe kopena right here and now From Guangyu.Pei at boeing.com Mon Mar 16 21:32:36 2009 From: Guangyu.Pei at boeing.com (Pei, Guangyu) Date: Mon, 16 Mar 2009 21:32:36 -0700 Subject: [Ns-developers] Allow GNU Scientific Library (GSL) in ns-3? In-Reply-To: <13786f330903161952k701b6095od307d63640c1f005@mail.gmail.com> References: <13786f330903161952k701b6095od307d63640c1f005@mail.gmail.com> Message-ID: > -----Original Message----- > From: Joseph Kopena [mailto:tjkopena at cs.drexel.edu] > Sent: Monday, March 16, 2009 7:52 PM > To: Pei, Guangyu > Cc: ns-developers at isi.edu > Subject: Re: [Ns-developers] Allow GNU Scientific Library > (GSL) in ns-3? > > On Mon, Mar 16, 2009 at 8:25 PM, Pei, Guangyu > wrote: > > I am wondering what is the preferred way of linking other libraries > > such as GNU Scientific Library (GSL) > http://www.gnu.org/software/gsl/ > > in ns-3? > > Gary, > > If you mean how to do this within the build system, there was > a thread on the ns-3-users list a little while ago that > talked about it. > Search for "link a library." It's from November 2008. > > You can also look in the contributed and examples wscript files, e.g. > for the configurator or DB support in the stats package for examples. > > [1] http://groups.google.com/group/ns-3-users Thanks for the pointers. I found the example of linking libxml2. I assume this is the preferred approach. Gary From mathieu.lacage at sophia.inria.fr Tue Mar 17 00:13:08 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 17 Mar 2009 08:13:08 +0100 Subject: [Ns-developers] ns3::RandomVariable In-Reply-To: References: <6955346121364463167@unknownmsgid> <12d69e490903161331l699e3fb4x4b81c9379cba117e@mail.gmail.com> Message-ID: <1237273988.26000.10.camel@diese.inria.fr> On Mon, 2009-03-16 at 22:13 +0000, Gustavo Carneiro wrote: > > > Currently, we are developing a RTP traffic generator for NS3 as our > > > bachelor?s thesis. While programming, we encountered the issue that some > > > classes, e.g. ns3::RandomVariable, are not derived from ns3::Object. > > Thus, > > > they cannot be used with ns3::Ptr, as the required Ref- and Unref-methods > > > > The current design does something like what ns3::Ptr does, just "under > > the covers" and without using Ptr objects. Let me try and explain: > > > I should point out that there is a fundamental difference between Ptr and > the RandomVariable classes. With Ptr, when you copy a pointer variable the > original object is not copied. With a RandomVariable variable, copying the > variable will trigger a under-the-hood copy of the underlying XxxImpl. > Mathieu, correct me if I'm wrong (possible :) It is a bit more subtle. An example will make this clearer: // in this example, the two random variables share the same // distribution parameters but not the same seed so, they // will generate independent streams of random values which // share the same statistical properties RandomVariable a = UniformVariable (...); RandomVariable b = a; a.GetValue (); b.GetValue (); // in this example, the two random variables share the same // distribution parameters and the same seed so they will // generate the same random values all the time RandomVariable a = UniformVariable (...); a.GetValue (); RandomVariable b = a; b.GetValue (); This is not very pretty and intuitive but, given all the constraints we have already, this is the best we could do I think. > But perhaps the difference does not matter in this case. After all, a > RandomVariable object is supposed to generate a series random numbers, and > they are supposed to be independent. So it should not matter whether you > generate two random numbers from a single RandomVariable object or one > number from one RandomVariable A and another one from a RandomVariable B, > where B is a copy of A. I can't claim I know much about this but I think that the two cases you describe here are different from a statistical perspective: two random values coming from the same RandomVariable are independent but two random values coming from different RandomVariable objects are not necessarily independent which is bad. Mathieu From boyko at iitp.ru Tue Mar 17 03:11:56 2009 From: boyko at iitp.ru (Pavel Boyko) Date: Tue, 17 Mar 2009 13:11:56 +0300 Subject: [Ns-developers] 802.11s code review Message-ID: <200903171311.57623.boyko@iitp.ru> Dear Gustavo and Ruben, On Monday 16 March 2009 21:31:45 you wrote: > Yep, I agree too. There should be a clear distinction between what is > really standard compliant (i.e. defined in the standard) and what is (a) > inferred from the standard because it was not clearly defined in the > standard (b) research stuff. Right, this is exactly what keeps us busy now, I am sorry for confusing you. After refactoring we'll have 'devices/mesh' module with a protocol independent framework for level 2 mesh and 'devices/mesh/802.11s' module implementing .11s draft protocols. Our research stuff (and this _is_ the thing we are really interested in :) is supposed to appear then as 'devices/mesh/foo', 'devices/mesh/bar', etc. modules. Is that ok? Regards, Pavel From gjcarneiro at gmail.com Tue Mar 17 03:36:55 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 17 Mar 2009 10:36:55 +0000 Subject: [Ns-developers] 802.11s code review In-Reply-To: <200903171311.57623.boyko@iitp.ru> References: <200903171311.57623.boyko@iitp.ru> Message-ID: 2009/3/17 Pavel Boyko > > Dear Gustavo and Ruben, > > On Monday 16 March 2009 21:31:45 you wrote: > > Yep, I agree too. There should be a clear distinction between what is > > really standard compliant (i.e. defined in the standard) and what is (a) > > inferred from the standard because it was not clearly defined in the > > standard (b) research stuff. > > Right, this is exactly what keeps us busy now, I am sorry for confusing > you. > After refactoring we'll have 'devices/mesh' module with a protocol > independent > framework for level 2 mesh and 'devices/mesh/802.11s' module implementing > .11s > draft protocols. Our research stuff (and this _is_ the thing we are really > interested in :) is supposed to appear then as 'devices/mesh/foo', > 'devices/mesh/bar', etc. modules. Is that ok? That sounds good. Also don't forget to rename the L2Xxx stuff to something more specific. I mean, for instance UMTS is L2 too, and I don't suppose your framework applies to UMTS networks... ;-) And, I forgot to answer one of Mathieu's questions, to share or not to share the LearningBridge functionality. In my humble opinion, the LearningBridge forwarding algorithm is rather trivial to code, and is probably not worth the trouble of refactoring to reuse it in different contexts. In my opinion, some times copy-paste is not evil, sometimes it simplifies things, makes the code easier to follow because you don't have to jump so much around into different classes/functions. 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 Tue Mar 17 08:45:04 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 17 Mar 2009 16:45:04 +0100 Subject: [Ns-developers] About real-world application integration In-Reply-To: References: <1236790499.658.31.camel@mathieu-laptop> <1237193331.31135.36.camel@diese.inria.fr> <1237198269.31135.121.camel@diese.inria.fr> Message-ID: <1237304704.4276.1.camel@diese.inria.fr> On Tue, 2009-03-17 at 01:15 +0900, Hajime Tazaki wrote: > >I see: it's weird that I did not see the ipv6 part of the patch. To make > >sure I don't forget anything, would you mind send me a list of files you > >have modified and files you have added ? > > Followings are modified/added files in my repository. [...] > Currently, there is a lot of nonsense diff in this > modification (e.g. only diff comment paragraph), sorry. I understand that you have merged multiple repositories, so, mercurial gives you a lot of changes unrelated to yours, but, I can't go through all these files to figure out what you have changed. What I really want to know is what changes you have made yourself to your repository, beyond the more or less mechanical merging of other repositories. Mathieu From mathieu.lacage at sophia.inria.fr Tue Mar 17 08:49:22 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 17 Mar 2009 16:49:22 +0100 Subject: [Ns-developers] About real-world application integration In-Reply-To: References: <1236790499.658.31.camel@mathieu-laptop> <1237193331.31135.36.camel@diese.inria.fr> <1237198269.31135.121.camel@diese.inria.fr> <1237204159.31135.268.camel@diese.inria.fr> Message-ID: <1237304962.4276.4.camel@diese.inria.fr> On Tue, 2009-03-17 at 01:45 +0900, Hajime Tazaki wrote: > Let me show you gdb stack of this problem. This stack was > reproduced by previous version. > > #12 0xb7b4c630 in ns3::ProcessManager::DeleteProcess (this=0x80add28, process=0x87d5e10) > #13 0xb7b4cab7 in ns3::ProcessManager::GarbageCollectDeadProcessesAndThreads (this=0x80add28) > #14 0xb7b4f0ff in ns3::ProcessManager::Schedule (this=0x80add28) > #15 0xb7b4fa52 in ns3::ProcessManager::ScheduleFromInterrupt (this=0x80add28, thread=0x87d8ab8) > #16 0xb7b77e98 in ns3::UtilsSendSignal (process=0x87d8520, signum=9) > #17 0xb7b4c564 in ns3::ProcessManager::DeleteProcess (this=0x80add28, process=0x87d8520) > #18 0xb7b4fc14 in ns3::ProcessManager::DoDispose (this=0x80add28) > #19 0xb77d28ed in ns3::Object::Dispose (this=0x80839f8) > #20 0xb7936757 in ~NodeListPriv (this=0x80839b8) > #21 0xb77d2187 in ns3::Object::MaybeDelete (this=0x80839b8) > #22 0x0805f102 in ns3::Object::Unref (this=0x80839b8) > #23 0xb7938f0e in ns3::Ptr::operator= (this=0xb7f195a0, o=@0xbfd3a040) > #24 0xb793818c in ns3::NodeListPriv::Delete () > #25 0xb7885592 in Notify (this=0x8083888) > #26 0xb786038a in ns3::EventImpl::Invoke (this=0x8083888) > #27 0xb788d3f7 in ns3::RealtimeSimulatorImpl::Destroy (this=0x8083a38) > > When the destroy event of simulator is happened, > DeleteProcess is called twice for each process. > > and DeleteProcess in GarbageCollectDeadProcessesAndThreads() > remove process entry from m_processes even though it was > called from DoDispose(). > > So after one loop in DoDispose(), contents of m_processes > would be changed. In that case, single process in a node > made no problem. > > > OTOH, when we install multiple processes into single node, as > > ApplicationContainer apps = process.Install (node); > ApplicationContainer apps2 = process2.Install (node); > > #this is a typical case when we use zebra > m_processes becomes to have a 2 entry in vector. > ok. > > But..... > > > I become to think that this modification doesn't solve > fundamentals. Should it avoid call DeleteProcee() twice? > > What do you think? How about moving the call to erase just after the assignment to the local variable 'process' and before the call to DeleteProcess ? Something like this: > { > NS_LOG_FUNCTION (this); > GarbageCollectDeadProcessesAndThreads (); >- for (std::vector::iterator i = m_processes.begin >(); i != m_processes.end (); ++i) >+ for (std::vector::iterator i = m_processes.begin >(); i != m_processes.end ();) > { > struct Process *process = *i; >+ i = m_processes.erase (i); > DeleteProcess (process); > } >- m_processes.clear (); Mathieu From gjcarneiro at gmail.com Tue Mar 17 08:55:13 2009 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Tue, 17 Mar 2009 15:55:13 +0000 Subject: [Ns-developers] ns3::RandomVariable In-Reply-To: <1237273988.26000.10.camel@diese.inria.fr> References: <6955346121364463167@unknownmsgid> <12d69e490903161331l699e3fb4x4b81c9379cba117e@mail.gmail.com> <1237273988.26000.10.camel@diese.inria.fr> Message-ID: 2009/3/17 Mathieu Lacage > On Mon, 2009-03-16 at 22:13 +0000, Gustavo Carneiro wrote: > > > > > Currently, we are developing a RTP traffic generator for NS3 as our > > > > bachelor?s thesis. While programming, we encountered the issue that > some > > > > classes, e.g. ns3::RandomVariable, are not derived from ns3::Object. > > > Thus, > > > > they cannot be used with ns3::Ptr, as the required Ref- and > Unref-methods > > > > > > The current design does something like what ns3::Ptr does, just "under > > > the covers" and without using Ptr objects. Let me try and explain: > > > > > > I should point out that there is a fundamental difference between Ptr and > > the RandomVariable classes. With Ptr, when you copy a pointer variable > the > > original object is not copied. With a RandomVariable variable, copying > the > > variable will trigger a under-the-hood copy of the underlying XxxImpl. > > Mathieu, correct me if I'm wrong (possible :) > > It is a bit more subtle. An example will make this clearer: > > // in this example, the two random variables share the same > // distribution parameters but not the same seed so, they > // will generate independent streams of random values which > // share the same statistical properties > RandomVariable a = UniformVariable (...); > RandomVariable b = a; > a.GetValue (); > b.GetValue (); > > // in this example, the two random variables share the same > // distribution parameters and the same seed so they will > // generate the same random values all the time > RandomVariable a = UniformVariable (...); > a.GetValue (); > RandomVariable b = a; > b.GetValue (); > > This is not very pretty and intuitive but, given all the constraints we > have already, this is the best we could do I think. I see. So we should avoid calling GetValue () at all costs during initial scenario configuration... > > > > > But perhaps the difference does not matter in this case. After all, a > > RandomVariable object is supposed to generate a series random numbers, > and > > they are supposed to be independent. So it should not matter whether you > > generate two random numbers from a single RandomVariable object or one > > number from one RandomVariable A and another one from a RandomVariable B, > > where B is a copy of A. > > I can't claim I know much about this but I think that the two cases you > describe here are different from a statistical perspective: two random > values coming from the same RandomVariable are independent but two > random values coming from different RandomVariable objects are not > necessarily independent which is bad. Experiment does not confirm what you say, that values coming different RV are no independent: -------------- import ns3 ns3.RandomVariable.UseGlobalSeed(1,2,3,4,5,6) A = ns3.NormalVariable(10, 5) B = ns3.NormalVariable(10, 5) print A.GetValue() #print B.GetValue() print A.GetValue() ----------- $ python test.py 8.60002591724 7.26575189265 Uncommenting the B.GetValue() line: $ python test.py 8.60002591724 12.1591665241 7.26575189265 The values from A are unchanged whether B is used or not, so it seems that A is independent from B. -- 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 Tue Mar 17 11:58:25 2009 From: mathieu.lacage at sophia.inria.fr (Mathieu Lacage) Date: Tue, 17 Mar 2009 19:58:25 +0100 Subject: [Ns-developers] ns3::RandomVariable In-Reply-To: References: <6955346121364463167@unknownmsgid> <12d69e490903161331l699e3fb4x4b81c9379cba117e@mail.gmail.com> <1237273988.26000.10.camel@diese.inria.fr>