[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: glibc's getaddrinfo() sort order



On Wed, Sep 19, 2007 at 04:52:35AM +1000, Anthony Towns wrote:
> Ah, that'll be because the ordering's simply rotating, rather than being
> random: so we're assuming from A > B,C,D > E and getting:
> 	ABCDE -> ABCDE
> 	BCDEA -> ABCDE
> 	CDEAB -> ACDBE
> 	DEABC -> ADBCE
> 	EABCD -> ABCDE
> which biasses B to being in second place, C in third, and D in fourth,
> simply because all but twice, B is ahead of C and D in the input because
> it's just being rotated, not shuffled.

In fact you can take this further, to the point where getaddrinfo()
is actively unbalancing the load. Suppose you have addresses:

	F1.00.00.02 (a)
	F1.00.00.03 (b)
	01.00.00.02 (c)
	01.00.00.03 (d)

Then your longest matching prefix will be either with a and b or c and d.
In that case, you get:

	DNS   a/b match  c/d match
	~~~~  ~~~~~~~~~  ~~~~~~~~~
	abcd  abcd       cdab
	bcda  bacd       cdba
	cdab  abcd       cdab
	dabc  abdc       dcab

Which will give three times the load to a and c compared to b and d.

And note that applies to IPv6 as well as IPv4, presuming the DNS presents
IPs in the simplest round-robin fashion.

Cheers,
aj

Attachment: signature.asc
Description: Digital signature


Reply to: