InetAddress.getLocalHost() returns different values in different threads

Thread view:

ociardhp - 25 Oct 2007 18:12 GMT

Hi

I've come across an unusual situation where a thread started in the
init method of an applet returns a particular value for
InetAddress.getLocalHost() whereas threads started at a later point in
time return a different value.

The output I see in my logs is as follows:
INFO: 17:41:39 com.cominded.diag.UpstreamProxy@6131844: Thread started
in init running on MSIE6/10.0.1.185
INFO: 17:41:47 com.cominded.diag.UpstreamProxy@6131844: New thread
running on localhost/127.0.0.1
INFO: 17:41:49 com.cominded.diag.UpstreamProxy@6131844: Thread started
in init running on MSIE6/10.0.1.185

This has been a pain to deal with as the applet acts as an RMI server
and client and so connections created by the new thread result in an
AccessControlException. Invoking
System.setProperty("java.rmi.server.hostname", "localhost"); before
taking any RMI action works on OSX/Firefox, but sadly not on Vista/
Firefox. Regardless, I assume creating a thread pool will solve the
problem.

Mostly I'd be interested in an explanation of why InetAddress exhibits
this behaviour. Many thanks to anyone who provides one.

Paul

Reply to this Message

Mark Space - 25 Oct 2007 21:06 GMT

> The output I see in my logs is as follows:
> INFO: 17:41:39 com.cominded.diag.UpstreamProxy@6131844: Thread started
[quoted text clipped - 3 lines]
> INFO: 17:41:49 com.cominded.diag.UpstreamProxy@6131844: Thread started
> in init running on MSIE6/10.0.1.185

There are all legal values for a local IP address. It seems to me that
getLocalHost() is return *all* values in sequence each time it is
called, although I haven't checked the docs. Is there some way to get
all IP addresses or a count of how many IP addresses your localhost has?
If not you just might have to read values until they start to repeat,
then manage the list yourself.

Reply to this Message

Owen Jacobson - 25 Oct 2007 21:47 GMT

> > The output I see in my logs is as follows:
> > INFO: 17:41:39 com.cominded.diag.UpstreamProxy@6131844: Thread started
[quoted text clipped - 10 lines]
> If not you just might have to read values until they start to repeat,
> then manage the list yourself.

I'm not sure I agree. The documentation says:

" If the operation is not allowed, an InetAddress representing the
loopback address is returned."

In networking circles, "the loopback address" is a specific technical
term; without going into too much detail, it seems to me that that
should always return an InetAddress representing an address in
127.0.0.0/8 somewhere, and not 10.0.0.0/8 (even if the machine has
interfaces in that network).

That said, I don't see any reason not to use InetAddress.getByName
("127.0.0.1") [0] if you want to connect to 127.0.0.1 specifically.
The IP specification demands that that be a loopback address.

[0] "The host name can either be a machine name, such as
"java.sun.com", or a textual representation of its IP address.". Yes,
even for getByName. Surprise!

Reply to this Message

Mark Space - 25 Oct 2007 23:18 GMT

> " If the operation is not allowed, an InetAddress representing the
> loopback address is returned."

This seems a crucial bit of information here. It may indicate that the
process getting "127.0.0.1" is experiencing some sort of failure. Maybe
permissions on Vista are different than permissions on OSX? I think you
have an issue not directly to getLocalHost().

I'm not an expert on applets by any means. But I think you should
always be able to connect to the server that the applet downloaded from.

Ponders.... get*Local*Host()? Why do you need your ip address to talk
to a server? Shouldn't you just open a socket to myServer.com and talk
to that?

Reply to this Message

Owen Jacobson - 25 Oct 2007 23:42 GMT

> > " If the operation is not allowed, an InetAddress representing the
> > loopback address is returned."
[quoted text clipped - 3 lines]
> permissions on Vista are different than permissions on OSX? I think you
> have an issue not directly to getLocalHost().

I misread that initially as if it "is allowed"; the rest of my post is
blither since I got that wrong, and can be boiled down to:

"If you need to talk to 127.0.0.1, use 127.0.0.1, not getLocalHost().
Surprise!"

> I'm not an expert on applets by any means. But I think you should
> always be able to connect to the server that the applet downloaded from.
>
> Ponders.... get*Local*Host()? Why do you need your ip address to talk
> to a server? Shouldn't you just open a socket to myServer.com and talk
> to that?

My money's on some form of IPC between applets or something.

Reply to this Message

Joshua Cranmer - 25 Oct 2007 21:55 GMT

> MSIE6/10.0.1.185
> localhost/127.0.0.1
> MSIE6/10.0.1.185
>
> Mostly I'd be interested in an explanation of why InetAddress exhibits
> this behaviour. Many thanks to anyone who provides one.

Looking at your results, the 127.0.0.1 (which is what would be expected)
is provided with the name `localhost' whereas the 10.0.1.185 address is
provided with the name `MSIE6'. I think that the different IP addresses
would be caused ultimately by the fact that it is running in Internet
Explorer. Try running it in Firefox and appletviewer and see what those
results are.

(P.S., as Mark Space pointed out, both of those are still valid loopback
IP addresses.)

Signature

Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Reply to this Message

Daniel Pitts - 25 Oct 2007 22:28 GMT

> Hi
>
[quoted text clipped - 23 lines]
>
> Paul

Two IP address can have the same hostname, and two hostnames can share
an IP address. Generally its up to the DNS server to decide how to
differentiate these. Some DNS servers are designed to round-robin the
IP address in order to better load balance requests.

HTH,
Daniel.

Signature

Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Reply to this Message

InetAddress.getLocalHost() returns different values in different threads

Free Magazines