From Nsnam
Jump to: navigation, search

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:

  • Misc
    • 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 ( 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 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
<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