This is the archive for the IRC chat on 2008/05/06. Full transcript is below, notes follow.
Participating: Florian, George, Hagen, Joe, Liu, Mathieu
Major discussion points:
- Liu working on detailed understanding of network functionality used by Quagga
- Some discussion of attribute paths
- Mathieu returned from vacation, and questioned the relaxation value of vacations with children
* Now talking on #ns-3 * Topic for #ns-3 is: gsoc: send questions to ns-developers (http://mailman.isi.edu/mailman/listinfo/ns-developers) if no one answers here * Topic for #ns-3 set by mathieu_ at Wed Mar 26 12:09:23 2008 <riley> Ok, that sounds great. I'm going to step out of the room for a brief meeting...back in 5 mins... <hgn> because I must understand how tags are organized and where to hook the rx/tx functionality <LJ__> Lacage: hi, coming <hgn> riley: great! than I will do this! ;) <tjkopena> hi all <tjkopena> so, I think everyone I expected to be here is here---riley is stepping out for a meeting, tom said he would not make it, and sam was not sure <hgn> ... but wait, where is fw_? ;) <hgn> fw_: ping <fw_> hgn: pong <lacage> fw_ never sleeps <tjkopena> lacage, how was your vacation? <riley> I'm back.... <hgn> lacage: yes, he do - but at times where everybody sleeps normaly! ;) <hgn> s/do/does/ <tjkopena> in any event, LJ__, fw_, I saw that you posted material to the wiki <LJ__> hi <tjkopena> liu, did you get to talk w/ tom about quagga? <LJ__> post some info about the gsoc project yet <hgn> tjkopena: I will also post some stuff (but I was at vacation too ;) <tjkopena> hgn, sounds good, glad you got to hook up w/ george <hgn> tjkopena: ACK <LJ__> have asked some question about quagga running, but still have doubts <riley> Yes, we chatted this morning. I will try to set up periodic (daily?) chats with Hagen. <LJ__> fw:have you push you code in ns-repo yet? <fw_> LJ__: no, im queueing my stuff on hg.strlen.de for now <tjkopena> cool; hgn, you may have read the transcript from last week, but the goal of the wiki content is just to lay out a (fairly simple) plan, document for the community what's going on, and track progress & lessons <hgn> tjkopena: k <lacage> LJ__, before you start working on code for the ns-3-simu branch, I think that it would be really nice to try to outline the architecture of quagga in a small 2p document <tjkopena> hgn, tom or lacage can both auth you to edit the wiki once you register for an account <hgn> riley: daily is ok, I will join ns3 daily <tjkopena> lacage, agreed <riley> hgn: We can coordinate this later off-line <hgn> ack <lacage> LJ__, I see that the wiki contains some basic stuff about quagga which is great <LJ__> lacage: i will do that. actually simple introduction about it has been added in project wiki <lacage> LJ__, yes. <lacage> LJ__, what would be missing are things like: <lacage> 1) what type of sockets does it use ? <tjkopena> li__, how did you build that list of system calls (just curious)? <lacage> 2) how does it use them ? does it use select on them ? <LJ__> Lacage:tom adviced me to start by one protocol <lacage> 3) when it uses threads, how are they used ? <LJ__> Lacage:select used <lacage> LJ__, yes. so, you can try to start with answering these questions for a specific protocol <lacage> LJ__, yes, select is used but you do not know how <lacage> LJ__, it could be used to select on actual hard disk files <lacage> LJ__, rather than sockets <LJ__> lacage:yes, i will add detail imformation <lacage> for 3), the kind of thing you want to know is: how many threads are used ? what is the purpose of each thread ? What kind of thread synchronization primitives are used ? <lacage> LJ__, I think that once you have a better understanding of how quagga works for a single protocol, you will find it trivial to go ahead and make it use ns-3-simu <lacage> tjkopena, I learned the hard way that vacations with a baby are not really vacations :) <tjkopena> :) <riley> lacage: The same applies to vacations with a teen-ager :) <LJ__> lacage:now there was a problem, i was not clear about how to running quagga, i mean running on PC as routing protocol <hgn> riley: got email, thanks <lacage> LJ__, I see. <lacage> riley, I can imagine <LJ__> i thought there may need PCs when testing <lacage> LJ__, could you not use a couple of virtual machines ? <lacage> LJ__, but you are right, it might be complicated <lacage> LJ__, tom might have experience with that so, I suspect that you could ask him about it <hgn> or setup some linux uml machines <lacage> LJ__, however, what I had in mind was more a static analysis of the code <LJ__> but the goal is to run them in ns3 <lacage> hgn, yes, but it is still relatively painful to setup each machine correctly and make them talk to each other. <lacage> LJ__, what we could do is look at that code together if you want to <lacage> to get started on the static analysis of the code <lacage> call this 'reverse engineering' :) <LJ__> thanks <lacage> do you want to do this now ? <lacage> or at a later time ? <tjkopena> isn't it like midnight there (for liu)? <hgn> tjkopena: then it is the perfect time! ;) <LJ__> lacage:you mean analysis the code?i have checked the syscalls which may be implemented in ns_simu <lacage> LJ__, yes, the analysis <lacage> LJ__, basically, reading the code :) <tjkopena> on another topic: I think it would be worthwhile to have all of us---except perhaps mathieu, he might be excused---go through the exercise of creating a couple simple simulations in NS-3, sometime in the next few weeks <LJ__> tjkopena:23:27:) <tjkopena> I think that'd be a reasonable "community bonding" activity, along w/ background research everyone seems to be doing, to learn more about the whole system <riley> tjokpena: I'm pretty sure I know how to make an ns-3 sim as well, and hope to be "excused" :) <lacage> LJ__, I could recommend a great book about this if you have a couple of hours during the day <tjkopena> I don't think it would be advisable or good to have all these different parts being worked on without a familiarity with the basics <hgn> riley: ;) <LJ__> lacage:great <tjkopena> riley, of course :) you might want to play w/ the tracing system, and possibly attributes if you haven't though <lacage> "Find the bug : a book of incorrect programs" by Adam Barr <tjkopena> tracing in particular is "informative" to actually try and use <lacage> LJ__, chapter 2 is awesome <lacage> tjkopena, you mean that it is informative to fall in the same pitfalls every user falls in ? :/ <tjkopena> it is informative to be dazed and confused, lost in a terribly wrong attribute path of your own making <lacage> LJ__, it is a small book so, I suspect that you should be able to get through chapter 2 relatively quickly <lacage> tjkopena, but you don't have to now that ns-3-doc has been merged :) <hgn> lacage: as I did yesterday in olsrd: the hash function for ipv4 was some bit-twiddling, but the ipv6 hashing was <hgn> lacage: const char * const tmp = (const char *)&address->v6; <hgn> lacage: hash = ntohl(*tmp); <hgn> lacage: ;) <hgn> lacage: I submited a patch and the awnser was: "Yes, for IPv6 it was - ahemm - very simple." <tjkopena> lacage, what is the best writeup for the tracing system right now? <tjkopena> not a list of sources, but the general structure <tjkopena> s/structure/syntax/ <lacage> tjkopena, there is no doc on the syntax of paths <lacage> tjkopena, and I suspect that this will stay that way <lacage> tjkopena, I think that the idea is that you should never have to deal with them by hand <lacage> I mean, to have to construct them by hand <lacage> tjkopena, this is why I gave up on my earlier proposal to make the syntax more coherent and easier to explain <tjkopena> how can you avoid that if you're setting parameters and such? <lacage> tjkopena, you take the path from the doxygen and append the attribute name <lacage> I think that what is really missing is a way to get the Config code to generate a useful human-readable report of the attribute setting/trace connection process <tjkopena> but that doesn't document some things, for example /nodes/*/ <lacage> to figure out what goes wrong when you try to use a path <lacage> tjkopena, you mean, /NodeList/*/ ? <tjkopena> yes, but note that the generated comments use /nodes/ <tjkopena> and your paper in progress using something else I think <lacage> tjkopena, ns-3-dev generates this: /NodeList/[i]/DeviceList/[i]/$ns3WifiNetDevice/RemoteStationManager/$ns3AarfWifiManager <lacage> see http://www.nsnam.org/doxygen/classns3_1_1_aarf_wifi_manager.html <tjkopena> where are you seeing that? <tjkopena> I am looking at doc/introspected-doxygen.h <lacage> ahhh <tjkopena> which I had not looked at until today <lacage> _someone_ might have checked in a non-empty version of that file <lacage> ./waf check should re-generate it <tjkopena> and when I saw nodes I thought maybe it had changed again... (I had just pulled changes) <tjkopena> yes, that seems to be the case <lacage> LJ__, so, do you want to schedule a small meeting to attempt to go through the quagga codebase ? <LJ__> that would be fine. <lacage> LJ__, when do you want to do this ? <lacage> LJ__, I think that we need to plan 1h <lacage> tjkopena, you probably had not run waf check since your update... <tjkopena> no, I had not <tjkopena> but had run waf; why is that dependent on check? <lacage> tjkopena, waf magic <lacage> utils/print-introspected-doxygen yourself if you prefer :) <tjkopena> just noting that it's unexpected behavior <lacage> tjkopena, I know. but I never cared enough about it to deal with it <lacage> tjkopena, patch welcome :) <lacage> LJ__, shall I be around tomorrow ? <tjkopena> touche; I will add it to my list <LJ__> lacage:just skip the book you recommend <LJ__> i will go through the code, give detail info about the syscall used <lacage> tjkopena, make sure you talk to gjc about this: I am sure he will have input. <tjkopena> ok, I have to run; mathieu, will hopefully be on later to talk tracing, as related to the stat framework <tjkopena> thx <LJ__> at the same time, i need to run it sucessfully firstly <lacage> tjkopena, ok <lacage> LJ__, I don't think you really need to run it to start reading the code seriously