Alo Sarv
lead developer

Donate via

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary

Wednesday, January 19, 2005

Misc fixes, designing ipfilter engine

The comment on previos blog entry raised some thoughts. While ipfilter engine was planned to be implemented some time in the mysterious future, I realized that we can implement it here and now - we have all the pre-requisites in place, and I don't see any obstacles to it right now. While it's not in current development roadmap, it shouldn't take long to implement it, so we can do it right away and be done with it.

The important thing about it is keeping it generic and extendible. It should be pluginnable to the existing Scheduler API, which simply asks currently loaded ipfilter object to allow (or deny) request to a specific IP address. As such, it would keep both the Scheduler and the IpFilter objects separated, which is a Good Thing. What I'v been pondering about is the exact design of the ipfilter engine.

One idea is this. We create an abstract base class called IpFilterBase, which declares single pure virtual function - bool isAllowed(uint32). That function shall return true if the given ip address is allowed to be connected to (or incoming connection accepted from that ip), false otherwise. Derived classes would then override that method and implement it.

The actual IpFilter implementation would rely on Range API v2, which needs some lookup optimizations before it can provide the speeds we need there.

Using this design, it's possible for any1 to later write a custom ipfilter plugin to override whatever I'm providing by default, simply by deriving a custom class from IpFilterBase, and replacing the IpFilter object in Scheduler with the new one.

My only concern right now is that using the aforementioned virtual function mechanism might become a performance bottleneck (virtual function calls have slight runtime overhead compared to normal functions), because that function shall be called during EVERY incoming and outgoing connection. However, I tend to think this goes into the microoptimizations area, and eventually there are most likely other areas to be optimized instead of some virtual function call.

Hopefully I can get this thing implemented in a few days - I'd say the only hard part is optimizing RangeList lookup - currently it provides only linear complexity lookups. However, I already have few thoughts on how to do this, more on this on tomorrows blog post.

Madcat, ZzZz

Why don't you add a context parameter to IsAllowed(uint32) - in this way a core plugin can communicate some dynamic info to a filter plugin if relevant. Thus the filter becomes a more intelligent entity easier to adapt and extend in the future.
BTW thanx for you work - your site is absolutely amazing!
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?