Author: Robert Black Date: To: exim-users Subject: Re: split the load?
On Nov 22, 9:29am, Philip Hazel wrote: > Subject: Re: split the load?
> On Thu, 21 Nov 1996, Warner Losh wrote:
>
> > It doesn't matter if you get the results back randomly or not. If you
> > pick randomly from them, you are guaranteed to still have a random
> > distribution. If you pick randomly from a non-random set, you have a
> > random distribution. Therefore, it is irrelevant the order that DNS
> > gives you the MX records in. Picking one of these at random is the
> > right thing to do. If someone wants you to give precidence to one of
> > these hosts, then by definition, that someone must change the MX
> > precidence to be a lower value.
>
> It's not quite "pick one at random". You have to put them into a random
> order so that you can try them in turn until one works.
>
> I think I'm convinced that "randomizing" is perhaps a better thing to
> do. A *simple* scheme would not be expensive, but I know that I don't
> know enough about random numbers to want to get involved in trying to
> ensure true randomness. We are talking here about "randomizing" a small
> number of objects, often just two, probably never more than 10.
>
> At the relevant time, Exim is scanning the list of RRs returned by the
> nameserver, and inserting them into a list in order of their MX values.
> The current rule is "insert before the entry with a higher MX value".
> It would have to be changed by the addition of an extra rule such as
> "If there are a group of entries with the same MX value, choose at
> random where to insert." If there are n such entries, then there are n+1
> possible places to insert. What is the best *cheap* way of getting a
> random number between 0 and n? Is something like "take the last m bits
> of the time of day modulo (n+1)" good enough for this purpose?
Hmm, that would work on any architecture which returns something meaningful in
the tv_usec field. If you really want to be paranoid you could xor it with the
process id and a simple integer counter just in case any architecture always
returns zero in this field.
You could then randomise the order by doing something like looping over the
list of MX records of the current priority and swapping each in turn with one
of the others in the list picked at random.
