Getting local IP address...

[Donn Cave]

Quoth David Bolen <db3l at fitlinxx.com>:
| Mike Fletcher <mfletch at tpresence.com> writes:
|> import socket
|> def getLocalHostIP( remote = ("www.python.org", 80)):
|> 	'''Get the "public" address of the local machine, i.e.
|> 	that address which is connected to the general internet.
|> 	Code by Donn Cave, posted to comp.lang.python'''
|> 	s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
|> 	s.connect( remote )
|> 	ip, localport = s.getsockname()
|> 	s.close()
|> 	return ip
|> 
|> That is actually from a Deja posting, seems to be fairly portable, doesn't
|> rely on parsing obscure Unix command responses, is readable, and is
|> generally quite reliable.
|
| But has a pretty large (IMHO) negative that you are making a wasted
| network connection to an external server that has to spend time
| setting up and tearing down TCP with you for no reason.  That seems a
| pretty high overhead to pay just to determine what is essentially a
| locally configured piece of information.  If you are in charge of your
| own server that you are using I suppose that's one thing, but it seems
| a big waste if you're connecting to someone else's.

I'm not so crazy about this function either, despite that my name appears
in it!  But my problem is that it introduces an external and otherwise
irrelevant dependency on the DNS name www.python.org and its HTTP service.
When I did this in my own application (on BeOS, in MIT Kerberos 5, which
encodes the local IP in the ticket), I used my own primary DNS service
as the target.  This IP address is always known to the local system in
advance and really has to be in service or you're sunk anyway.

Will these connections every time an application wants to determine its
own IP bring the host to its knees?  Give me a break.  This, in a Python
newsgroup!  Compare to the network burden of resolving DNS names, etc.
Waste is bad, but this is a conspicuous but very small cost compared to
huge routine expenses that are buried under DNS lookups, NFS remote mounted
filesystems etc.

Also note, for those who want to do this, if the application already
happens to have an open connection, that's the same thing for free.
And if you don't have an open connection, and you have a dynamic
IP like most PPP, this connection is going to insure that you have
a valid IP before you determine what it is.

| Unfortunately, really determining a local configured address just
| isn't that portable a thing from my experience.  Probably the closest
| would be the SIOCGIFCONF IOCtl (for Unix systems) as previously
| posted.  There is an Windows socket IOCtl that is similar
| (SIO_ADDRESS_LIST_QUERY), but I'm not sure how best to get to it from
| Python, aside from something like a CallDLL approach.
|
| While without an alternative that is portable as the above example
| makes it hard to come out too strong against it, I did want to point
| out that while it may be portable and readable, it has negatives on
| the network side in terms of wasted connections.  I built backbones in
| a prior life, and I sort of cringe to think of tons of user code
| suddenly starting to do stuff like the above :-)

On the bright side, generally it's not necessary to know your own
IP address.  I'm curious why we are seeing this question so often,
what are folks doing out there?

In the final analysis of course it's up to the application author
to decide what will work best.  The thing I do have a strong opinion
about is that it's all too common and just shoddy as all get out
to say ``this works for Linux'' and leave it at that.  It's
particularly ironic when it's Linux, as opposed to Solaris or
Windows.  Linux is so utterly dependent on the hard work of the
GNU folks who have done more for platform independence than anyone.
In a different world where the Sun world, DEC world et al. each had
their own little communities writing software for themselves, Linux
would be a dead dog.  But now that they have a little community of
their own, sometimes it seems to me like they have an attitude about
portability that goes beyond just a lack of experience with other
platforms.  In the old days, I don't know, 10 years ago or thereabouts,
non-commercial UNIX software was very tedious to port.  Things like
POSIX, X/Open and GNU have made life pretty easy, in comparison, but
they only matter because people have cared to write portable code,
possibly at the expense of a few whiz-bang platform specific features.

None of which is exceptionally relevant to the present case, I just
needed to get that off my chest.

	Donn Cave, donn at u.washington.edu