Order of addresses returned by socket.gethostbyname_ex()

[Tomas Lidén]

In what order are the addresses returned by socket.gethostbyname_ex()?

We know that gethostbyname() is indeterministic but hope that
gethostbyname_ex() has a specified order.

Best regards,
Tomas

 

[Steven D'Aprano]

In what order are the addresses returned by socket.gethostbyname_ex()?

We know that gethostbyname() is indeterministic but hope that
gethostbyname_ex() has a specified order.

Did you want a particular order, or just any deterministic order?

Have you considered sorting the addresses yourself?

 

[Tomas Lidén]

Did you want a particular order, or just any deterministic order?

Have you considered sorting the addresses yourself?

In this particular case we have a host with several connections (LAN,
WIFI, VmWare adapters etc). When using gethostbyname() we got a VmWare
adapter but we wanted to get the LAN (or the "best" connection to our
server). With gethostbyname_ex() the ordering seemed to become LAN,
Wifi, etc and that's good for us. But we don't know if this holds on
other platforms (we're running on Windows 7).

A cross-platform deterministic order would be excellent for us.

/Tomas

 

[Cameron Simpson]

| On 22 Aug, 10:15, Steven D'Aprano <steve
| (e-mail address removed)> wrote:
| > On Mon, 22 Aug 2011 04:37 pm Tomas Lidén wrote:
| > > In what order are the addresses returned by socket.gethostbyname_ex()?
| >
| > > We know that gethostbyname() is indeterministic but hope that
| > > gethostbyname_ex() has a specified order.
| >
| > Did you want a particular order, or just any deterministic order?
| >
| > Have you considered sorting the addresses yourself?
|
| In this particular case we have a host with several connections (LAN,
| WIFI, VmWare adapters etc). When using gethostbyname() we got a VmWare
| adapter but we wanted to get the LAN (or the "best" connection to our
| server). With gethostbyname_ex() the ordering seemed to become LAN,
| Wifi, etc and that's good for us. But we don't know if this holds on
| other platforms (we're running on Windows 7).
|
| A cross-platform deterministic order would be excellent for us.

It would not surprise me if the order was related to the order a scan of
the system interfaces yields information, and I would imagine that may
be influenced by the order in which the interfaces were initialised.

So getting the LAN first may merely be fortuitous.
I wouldn't rely on it, especially if interfaces come and go.

What if you queried your routing table instead? Usually there's just one
default route, and hopefully it would be configured to use the "best"
interface.

Cheers,
--
Cameron Simpson <[email protected]> DoD#743
http://www.cskk.ezoshosting.com/cs/

If you give me six lines written by the most honest man, I will find
something in them to hang him. - Cardinal Richilieu

 

[Chris Angelico]

What if you queried your routing table instead? Usually there's just one
default route, and hopefully it would be configured to use the "best"
interface.

I wouldn't necessarily trust even this, on Windows. I've lately had
the most insane trouble getting my XP laptop to function properly as a
proxy - LAN connection has the default gateway, wifi has only
192.168.* - and Windows kept on trying to send DNS queries out on the
wireless connection, and then wondered why it didn't get a result.

Explicit is better than implicit. Instead of using the order, have a
config file that chooses the one(s) you want by name or IP address. Of
course, if you're on Unix/Linux, you can use the interface name (eth0,
eth1, etc) with a fair degree of reliability.

ChrisA

 

[Roy Smith]

In what order are the addresses returned by socket.gethostbyname_ex()?

We know that gethostbyname() is indeterministic but hope that
gethostbyname_ex() has a specified order.

Why would you hope that? Or maybe a better question is, why would you
expect that? In general, all name resolution calls return results in
arbitrary order. In some cases, results are intentionally changed on
every call (i.e. round-robin) in an attempt at load sharing.

What kind of ordering were you hoping for?

 

[Tomas Lidén]

It would not surprise me if the order was related to the order a scan of
the system interfaces yields information, and I would imagine that may
be influenced by the order in which the interfaces were initialised.

So getting the LAN first may merely be fortuitous.
I wouldn't rely on it, especially if interfaces come and go.

We did try to disable/enable the interfaces in different orders, but
always got the same return order from gethostbyname_ex(). So it looked
pretty stable (on that specific OS). There's been some testing on
Linux as well, but since this should be used in a general cross
platform tool we wanted to check the exact behaviour of the method.

What if you queried your routing table instead? Usually there's just one
default route, and hopefully it would be configured to use the "best"
interface.

Hmm... perhaps. How would you do that?
/Tomas

 

[Tomas Lidén]

Explicit is better than implicit. Instead of using the order, have a
config file that chooses the one(s) you want by name or IP address. Of
course, if you're on Unix/Linux, you can use the interface name (eth0,
eth1, etc) with a fair degree of reliability.

The config file solution is not suitable, I think. This code should
run in a general cross platform application (Texttest), and we do not
want each user of that system to be forced to edit a config file..

/Tomas

 

[Roy Smith]

In this particular case we have a host with several connections (LAN,
WIFI, VmWare adapters etc). When using gethostbyname() we got a VmWare
adapter but we wanted to get the LAN (or the "best" connection to our
server).

Figuring out which is the best connection is a decidedly non-trivial
problem. You could try some heuristic like "pick the address which has
the same network number as me". But, what if you're multi-homed as
well, and the target has addresses on more than one of the networks
you're connected to? Not to mention that even enumerating all of your
own connections is non-trivial.

With gethostbyname_ex() the ordering seemed to become LAN,
Wifi, etc and that's good for us. But we don't know if this holds on
other platforms (we're running on Windows 7).

You can't count on the ordering being anything in particular. It's a
lost cause. You may think you can find patterns, and then write your
application to depend on those, and you will eventually get burned.

A cross-platform deterministic order would be excellent for us.

"A cross-platform deterministic X would be excellent" is a true
statement for almost any value of X. Many people have wasted much of
their lives trying to achieve that goal, for various Xs.

 

[Tomas Lidén]

Why would you hope that?  Or maybe a better question is, why would you
expect that?  In general, all name resolution calls return results in
arbitrary order.  In some cases, results are intentionally changed on
every call (i.e. round-robin) in an attempt at load sharing.

What kind of ordering were you hoping for?

See previous posts.

Basically I was asking about the contract for this method.. hoping
that it is deterministic.
Our testing indicated that the interfaces are returned in a specific
order, but we want to know if this is really the case (on all
platforms).

/Tomas

 

[Roy Smith]

Basically I was asking about the contract for this method.. hoping
that it is deterministic.

The contract for socket.gethostbyname_ex() is described at
http://docs.python.org/library/socket.html#socket.gethostbyname_ex. It
says:

"Translate a host name to IPv4 address format, extended interface.
Return a triple (hostname, aliaslist, ipaddrlist) where hostname is the
primary host name responding to the given ip_address, aliaslist is a
(possibly empty) list of alternative host names for the same address,
and ipaddrlist is a list of IPv4 addresses for the same interface on the
same host (often but not always a single address). gethostbyname_ex()
does not support IPv6 name resolution, and getaddrinfo() should be used
instead for IPv4/v6 dual stack support."

That's it. It says nothing about ordering, so nothing about ordering
should be inferred.

Our testing indicated that the interfaces are returned in a specific
order, but we want to know if this is really the case (on all
platforms).

No, it is not.

 

[Paul Kölle]

Am 22.08.2011 13:37, schrieb Roy Smith:

"A cross-platform deterministic X would be excellent" is a true
statement for almost any value of X. Many people have wasted much of
their lives trying to achieve that goal, for various Xs.

So true..., QOTW +1

 

[Tomas Lidén]

OK - thank you all for your contributions.
/T

 

[Steven D'Aprano]

Tomas Lidén wrote:

In this particular case we have a host with several connections (LAN,
WIFI, VmWare adapters etc). When using gethostbyname() we got a VmWare
adapter but we wanted to get the LAN (or the "best" connection to our
server).

Define "best" connection.

If I tell you that my server has the following 6 connections:

Wifi1, LAN4, LAN1, LAN2, Wifi2, LAN5

which one is "best"?

Once you have an algorithm for deciding which connection is "best" for
everybody, then you can check whether gethostbyname_ex uses that algorithm,
or some other one.

 

[Terry Reedy]

See previous posts.

Basically I was asking about the contract for this method..

The doc "Return a triple (hostname, aliaslist, ipaddrlist) where
hostname is the primary host name responding to the given ip_address,
aliaslist is a (possibly empty) list of alternative host names for the
same address, and ipaddrlist is a list of IPv4/v6 addresses for the same
interface on the same host (most likely containing only a single address)."

hoping that it is deterministic.

As far as I can see, that is not in the contract.

Our testing indicated that the interfaces are returned in a specific
order, but we want to know if this is really the case (on all
platforms).

Even if it were so now, a patch could change things.

 

[Nobody]

In what order are the addresses returned by socket.gethostbyname_ex()?

We know that gethostbyname() is indeterministic but hope that
gethostbyname_ex() has a specified order.

It doesn't. In fact, the order of the IP addresses may have been
deliberately randomised (by the resolver and/or DNS server) in order to
provide a simple form of load balancing.