RoundRobin question

[William Stacey]

And a native monitor lock on the list bumps it slightly to 713ms and a
ReaderWriter lock to around 1578ms.  Assuming some locking semantics are
done anyway, this may not matter.

-- 
William Stacey

"Kevin Darcy" <kcd at daimlerchrysler.com> wrote in message
news:c8bqbl$3db$1 at sf1.isc.org...
> William Stacey wrote:
>
> >Was wondering how round-robin is implemented at a high level.  Does each
rr
> >in the zone have an integer value so that each time a rrset is returned
for
> >say (www.mydomain.com A) each record will have some key that a sort is
run
> >against that record set?  Then the record set is updated so the first rr
> >becomes the last on next sort?  Maybe the first rr get the count value of
> >the rrset so it is forced to the bottom and the rest get a sync starting
at
> >1?  Just curious as was having talk on this with someone and am curious.
> >
> The fallacy here is that true "round robin" actually exists in modern
> versions of BIND. It doesn't. The A records are stored in memory in the
> same order they are read from the zone file, but for both "cyclic" and
> "random" ordering, the first record of every response is always chosen
> at random. The only difference between the two orderings is that the
> second through _nth_ records of the response are given out randomly in
> the case of "random", but according to the stored order, rotated, in the
> case of "cyclic". If you have only 2 A records, the first record is
> random, there is no choice but to present the other record after it, so
> there is no difference whatsoever between "cyclic" and "random".
>
> Note that if you're trying to use A-record ordering for
> load-balancing/failover with more than 2 A records, "cyclic" is
> basically the worst of both worlds: not only do you get the intermittent
> "spiking" associated with random ordering, because the first A record
> (which clients will always use under normal circumstancees) is chosen
> randomly, but in the case of failure, the "next" A record (according to
> the rotated ordering) will get up to twice the normal volume because it
> gets all of the failover traffic. "random" is actually *better* for this
> application, but still sub-optimal.
>
> Why doesn't BIND implement true round robin? Because the developers
> don't want to bother keeping track of state information above and beyond
> the actual ordering of the records themselves (and it would be
> prohibitively expensive to actually rearrange the records in memory
> every time an answer was given). *If* the developers were interested in
> keeping some state around, I'd like to see an implementation of
> "permuted" ordering, where every possible permutation of A records is
> presented with equal frequency. That should eliminate the "spiking"
> problem -- since the first record of each response will get equal (or
> very nearly equal) time -- while at the same time minimizing the
> "failover skewing" problem (since the second record in every response
> will also be evenly spread among the available A records). But I'll get
> off my soapbox now... :-)
>
>
>                                              - Kevin
>
>
>