Brunet code status

18 views
Skip to first unread message

David Wolinsky

unread,
Jun 29, 2011, 5:22:51 PM6/29/11
to aci...@googlegroups.com
Hey all,

I'm done with my portion of 9.6.1 portion of Brunet.

Pierre, could you add your deltas to my testing branch and request a pull?  Or should I just cherrypick all your changes from the last non-Pierre delta from SVPN?

Whereupon we can move towards using github/acisp2p, release 9.6.1, and merge together Archer and SVPN overlay pools.

Cheers,
David

Pierre St Juste

unread,
Jun 29, 2011, 6:08:37 PM6/29/11
to aci...@googlegroups.com
I will add my deltas tonight and request pull.

--
You received this message because you are subscribed to the Google Groups "acis.p2p" group.
To post to this group, send email to aci...@googlegroups.com.
To unsubscribe from this group, send email to acisp2p+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/acisp2p?hl=en.



--
Pierre St Juste

Pierre St Juste

unread,
Jun 30, 2011, 1:18:22 AM6/30/11
to aci...@googlegroups.com
I will need a bit more time to port all of my changes over to the new testing branch (probably a week). So we can probably just push David's testing branch to github/acisp2p as is because I dont want my stuff to be the bottleneck. I will port socialvpn over by the end of next week. Sorry for the delay, I did not realize how big a gap existed between the two branches.
--
Pierre St Juste

Renato Figueiredo

unread,
Jul 1, 2011, 8:06:17 PM7/1/11
to aci...@googlegroups.com
thanks, guys - David, one constraint I have is the TeraGrid'11 presentation in about 2 weeks. If the appliance pool needs an upgrade, I'd like to try it either several days before the conference, or after the conference.

--rf
Dr. Renato J. Figueiredo
Associate Professor
ACIS Lab - ECE - University of Florida
UF Site Director, Center for Autonomic Computing
http://byron.acis.ufl.edu
ph: 352-392-6430

David Wolinsky

unread,
Jul 10, 2011, 12:20:14 AM7/10/11
to aci...@googlegroups.com
Any updates on this?

I think it should be as trivial as importing your patches.  I can go ahead and do that.  I'd like to get this wrapped up, do some large scale testing, do a release, and push it into all the GAs as well as SVPN main.

I wouldn't worry about making sure it is pristine, we can delay a release until after TG / GA finalization (per Professor Figueiredo's request), but I would like to see all the pieces together.  In other words,  I would like to see is SVPN updated in Brunet within the next few days.  I will start working on my paper that will stress test the hell ouf of GroupVPN.  Then we could set Aug 1st as a release target for SVPN and IPOP, which should give plenty of time for bug hunting in other areas of the code that are untouched by GroupVPN.

Cheers,
David

David Wolinsky

unread,
Jul 10, 2011, 12:20:59 AM7/10/11
to aci...@googlegroups.com
Which pool are you focusing on at TG'11?

Cheers,
David

Pierre St Juste

unread,
Jul 10, 2011, 2:31:00 AM7/10/11
to aci...@googlegroups.com
Sorry, I got a bit sidetracked with other priorities, you can go ahead and import my patches, since it will take me a while to do so myself.

David Wolinsky

unread,
Jul 10, 2011, 4:49:05 PM7/10/11
to aci...@googlegroups.com
I ran through the code ... I found two major issues:
1) https://github.com/ptony82/brunet/commit/4990779a89385485f8777305e4d8502ff1ba0a89
Which disables DNS in Linux ... Could you express the state of this in SVPN?
2) https://github.com/ptony82/brunet/commit/f27c2ccd36fa557e7c431ae0d5764b0d99c45d14
While I made a mistake that your approach was going to throw exception, it will not necessarily reveal the actual Nat, since the type is dynamic and won't be revealed the first time you access NatHandler.  I fixed this in the following patch:
https://github.com/davidiw/brunet/commit/a63c06d2629b427c920be19ef52075a16d049d15

With regards to 1), DNS supports the ability to do recursive calls avoiding this DNS server nonsense in Linux.  I recommend you check it out.

Also one issue kept popping up:  you were merging main branch with your branch as opposed to merging your code into the main branch.  This makes jobs like this a pain in the butt as many issues were fixed by both of us:  in the main branch, in your merge branch, and during my cherry picking.  Really it is more a testament to all involved and maybe a best practice:  an individual should always place their deltas at the top of a master branch rather than merging the master branch into their code, that way when adding their features to the actual master branch it is significantly easier.

Last but not least, the completed branch is at https://github.com/davidiw/brunet/tree/testing

Regards,
David

Pierre St Juste

unread,
Jul 10, 2011, 5:19:29 PM7/10/11
to aci...@googlegroups.com
Thank you, I did not keep track of merging into main versus merging into branch. I will keep that in mind for next time. Also, I dont know what you mean by "express the state of this in SVPN"

David Wolinsky

unread,
Jul 10, 2011, 6:25:52 PM7/10/11
to aci...@googlegroups.com
Sorry, that was short term for could you please tell me if this has changed and if you had any ideas / plans in mind on how to remedy it.  That way we can have a uniform method going forward as opposed to a branch of the code with the feature just disabled.

Cheers,
David

Pierre St Juste

unread,
Jul 10, 2011, 8:28:39 PM7/10/11
to aci...@googlegroups.com
For DNS, just leave it the way you have it in the completed branch. The best solution for SocialVPN may be to required dnsmasq and handle multiple DNS servers that way.

For NAT, your temporary patch is good enough because we dont crawl the network for NAT types anyway, I will have to investigate a smarter way to discover NAT information later on.

Overall, I agree with all changes you've made in the completed branch and I will use that branch for my next release of SocialVPN. Thank you.
Reply all
Reply to author
Forward
0 new messages