InetAddress.getLocalHost() returns different values in different threads

[ociardhp]

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

 

[Mark Space]

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

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.

 

[Owen Jacobson]

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.

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!

 

[Joshua Cranmer]

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.)

 

[Daniel Pitts]

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

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.

 

[Mark Space]

" 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?

 

[Owen Jacobson]

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 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.