[Unbound-users] patch implementing round robin rrsets

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Thijs,

Nice patch. :-)

I would like to accept it, because it is short and helpful and
lightweight. There are the following suggestions below.

The line of interest is this one:
- -		rr = random();

Now it seems that random() locks a mutex on Linux and may produce
improper results on FreeBSD in threads (but still reasonably random).
 So, I want to lock it less.  Also suggest to move the line one
further (behind the variable declaration).
+		rr = (data->count==1)?0:random();

And then hope that on Linux, performance does not degrade
multithreaded (it'll be copying the RR data while other threads lock
this lock).

In general a threadsafe solution with threadlocal storage requires a
lot more work.  An alternative is to be blatantly thread-unsafe (its
non-security related pretty-random numbers anyway), and make a
	static int state = 1;
and use a simple congruent random function, the rand function:
	state = state * 1103515245 + 12345;
	rr = (unsigned)(state/65536) % 32768;
But then I worry about cache-line contention on the int state.

Depending on how this works out, this could end up in the mainline
source, and the code needs to have the BSD license for that.  Or we
can put the patch in the contrib directory of the source tarball
(license of your choice).

Best regards,
   Wouter

On 03/07/2012 12:48 PM, Thijs Kinkhorst wrote:
> Hi all,
> 
> We've created a patch to have unbound randomize the order of the
> returned records if one has an rrset with multiple records of the
> same type (well-known as a round robin configuration and deployed
> widely).
> 
> We're running this in production on our site for a few weeks now.
> Our site has thousands of synchronous users with a host of
> different platforms. To date, nothing has broken. We use nsd as our
> authoritative server and we've enabled DNSSEC.
> 
> The reason for implementing this is that we host some services on
> two IP's, and since we've switched from bind as authoritative and
> recursive server to nsd and unbound a few years ago, one of the
> servers providing the service gets nearly all traffic while the
> second one is idling. This is because neither nsd nor unbound
> randomize the order of rrset contents. Obviously, I've first read
> some of the previous discussions on this list about randomizing the
> round robin return sets. They were a few years ago so the views may
> have changed, but I'd like to add my take to the then-presented
> arguments and why I think this patch improves the situation.
> 
> - Selecting a random IP should be done on the client systems.
> 
> Our users use a wide range of devices, including various Windows
> versions, Mac OS X and Linux. None of these do this by default,
> 'not even' my own Linux workstation. As people bring their own
> device, it's not feasible to change the configuration of all
> devices for this, nor to expect us to convince all OS vendors to
> change this. This behaviour by clients is at least for the
> foreseeable future, a given.
> 
> - Unbound tries its best to keep the rrset ordered.
> 
> A set by definition doesn't have an ordering, so I'm not sure what
> value there is in preserve the order it had when it arrives. What
> does this bring?
> 
> - It's not fast to reorder.
> 
> With our thousands of clients we've not experienced any measurable
> effect in a speed sense of this patch.
> 
> - Randomizing the rrsets is feature creep.
> 
> This is of course subjective, but I dare to disagree: with 10
> insertions and 8 deletions the patch is small by any standard.
> 
> The patch can be found here: 
> http://non-gnu.uvt.nl/debian/squeeze/unbound/40_rrdns That folder
> also contains patched Debian packages that we currently use in 
> production.
> 
> I'm looking forward to your response.
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPV1zdAAoJEJ9vHC1+BF+NZakP/1LutonULslRBdDlvrzYt3bb
7ldFeNPDWVVTYsav5DGuEVx+hrETfuU147acELJfUocOKdbxGcs6aY6EN8Eym5gR
w81BmKvMRo6YB76EpgG34OHUQWAaLKg30juCvqIo2uGpr9teVKr7hAYugwga6Po4
LrHPpzKiFMB80h6PBJ5loHSgPZ1enWQuMw+d6rAuWIH4fhFhVF+qPxeNF18JB1Y2
F5qZiYsdvPEevHKcSVPOFLFx9zqUREBXbFLl8j86V5e6cJz2K9iXFUneVDSolmVX
yWJw7wT+eUSnNwc0HE7sMdWiGpf+D7os7VrlDKUBmP+2MtIZ1A9xeiiUGgatyEFk
+5a9+m+qUnT6GReeoMmeUnvKelo8v1L+6RCChMCvaRlHufueNztC/9AYKqJ6pfdF
IldPD9507wLrrhhUzB6C/jhVa/ofcUlMc0+TcxBK1jeCvUBjz5E5YxAouvafIDNP
zCy9QJREkhO1aQNIogeO4DhI5o7ebDm+l8gGk+5jDdGnu0AjVM6R3H/JtTA+Dffh
uTFaXrWlBuI7e/TYYN+Tr/6eAkV3mLaYgmLI6K3Lu70P34Lj+rtiOvt0cw//TbwN
6eMVCVdB6mPUecZ/WUSmpxcDpRA9CmYao+20wVY1ohWhHWQ8wDmz/WnA6i0+CPny
HhLHGibypy5s09dRvSCQ
=KnDT
-----END PGP SIGNATURE-----