-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code Rewrite #65
Code Rewrite #65
Conversation
Hello! This is huuuuge change. I see there changes to different features / parts and it would be hard for me and take lot of time to read and review whole change as is. I do not have such many time for igmpproxy project, so please split changes into smaller independent pieces, put them into separare pull request, so they can be reviewed and merged independently. It would really helps me to process all your changes more effectively (e.g. there are some documentation changes which I can merge immediately, but due to how github works, only whole pull request can be merged). One big pull request with one big git commit is really hard to proces. |
I understand that it's huge, but like said it is a rewrite of the code base. It will be very difficult if not impossible to split it over multiple PRs, because it all ties together. It is as in Franks Herbert's words: Rot in the core spreads outward. I started out by investigating how I could fix my own issue with interfaces on freebsd and in doing so I discovered that the whole procedure of building interface had to be rewritten were it to be fixed the right way. What may be an option is to have this rewrite split off into it's own branch, I would definitely like to see people try the new rewrite I did. Something will surely come up. :) To give you an idea of the simplification involved. Go look at current version of callout.c. The new queuing algorithm is just this: Place a new timer in the right position according to order of execution and aging the queue boggles down to just this: Execute any expired (or about to be expired by .5s) timer and the main event loop now has to eveluate just this: Just set the timeout to 1s - the time spent since last age. And if it is past aging time or near aging by .01s we age and reset timeout. This few simple steps took over 200 lines of code using flawed logic and mathematics before my rewrite. The new algorithm is simple and fairly accurate (for a single threaded process), only on very slow or busy systems the timer execution may overshoot by a second. I see no need in complicating it more than this to run aging twice per timer resolution. |
Really try to separate changes to more commits (or pull requests) to have it smaller. You wrote that SIGHUP handler code would just few lines, and that is great! Also I cannot see how documentation change needs to be bound together with other changes. Really try to deliver code in smaller changes. Otherwise it took me too much time to process all these changes. |
I have thought about this a little and I think I can get away with first introducing the changes in the main event loop timing and timer queue. And maybe introduce a few new short still unused functions like reloadconfig / rebuildifvc. For this the call to rebuildIfVc() in the main loop will need to be removed, but it is not doing anything useful at the moment anyways. Next I can create a PR for introducing the changed dynamic interfaces code, this will be fairly large that's unavoidable. Finally I can do the new configuration options and documentation. |
I would be happy with anything which split one big change into more smaller which could be reviewed / commented / read and merged separately. |
Closing this PR and opening new one for changes to timing. |
Rewrite of the base code to fix issues #62 #32 #64
Overview of changes:
All this will make the code base much more flexible and readable. The above was achieved while in total 60 lines less code are required. The main event loop timing and timer functions were probably some of the worst I have ever come across. The following snippet of debug logging I did with the old timing says it all. Rebuild timer jumps from 60 secs to 38, within one sec after timers were added. This was because all sorts of weird calculations were being made instead of just maintaining an execution queue in the right order. In turn this was causing timers to execute out of order and/or early.
rebuildtimer: 22 60
About to call timeout 20 (#0)
SENT Membership query from 192.168.1.254 to 224.0.0.1
Sent membership query from 192.168.1.254 to 224.0.0.1. Delay: 10
Created timeout 23 (#0) - delay 10 secs
(Id:23, Time:10)
(Id:22, Time:28)
Created timeout 24 (#2) - delay 87 secs
(Id:23, Time:10)
(Id:22, Time:28)
(Id:24, Time:87)
rebuildtimer: 22 38
TODO:
Currently only changing of downstream interfaces is supported and this relies on normal aging of routes (stream will continue until route ages). This is because the actual relinking of routetable to changed interfaces is not yet implemented. This will be my next step in the rewrite.