Getting IP Address on Linux

[swpalmer]

How can I get the REAL IP address of the machine my app is running on with the Linux JRE??
Everything I try gives me the loopback address (127.0.0.1)
The same methods on Windows or Mac OS X give the expected address (e.g. 192.168.0.44 for my subnet)

Scott

[leknor]

This isn't exactly what you asked but I know a lot of online games that have a matching server don't trust what the client says. The client still sends an IP addr but that is really only the server to compare with what it thinks to IP addr is to determine if the client is firewalled.

[sugarshark]

Did you try
http://java.sun.com/j2se/1.4.2/docs/api/java/net/NetworkInterface.html ?
Gives you a list of all network interfaces and their adresses.

Ole.

Games published by our own members! Check 'em out!

[swpalmer]

I tried something along the lines of:

InetAddress.getAllByName( InetAddress.getLocalHost().getHostAddress() );

and looking for a result that wasn't 127.0.0.1

At the time my code had to be 1.4 compatible, but I can use 1.4 now.. so I'm going to give this a try...

..and it Works!  Thanks!  Problem solved.

[swpalmer]

leknor,

What I am trying to do is discover servers on the same subnet.  I'm no networking expert and I expect there is a better way to do this, but currently I get the IP address and then attempt to connect to the 254 addresses with the same C class address to see if there is a a server at that address.

If anyone has a better method please let me know.

[rreyelts]

What I am trying to do is discover servers on the same subnet.

I believe that multicast UDP is the standard sort of way for solving this problem. (At least that's what I've done before, and IIRC it's what JINI service discovery is based on). It's really simple (and fast). Your server just broadcasts a small id-string on a pre-determined multicast group on a periodic basis (i.e. once every 250ms). Clients join the group and listen for a second or so to pick up any id-strings being broadcasted. That's it.

God bless,
-Toby Reyelts

[leknor]

I'd have to test to verify this myself but I was looking at packets for the game Tribes Aerial Assult and when you pull up the server list it sends out UDP packets to the IP 255.255.255.255 on a predetermined port. I'm 95% sure those packets are sent to all hosts on the network. The sender's IP is in the source field of the IP header and each client could choose to repond by trying to connect to the source host. I'd think this would be a lot faster then trying to build connections to 254 hosts and waiting for timeouts.

I'd do some research on that above before you trust me as being correct. It's not something I've done but I think it is correct.

EDIT: I'm baseing the above on observed behavior. Like Toby kinda says below, that doesn't mean I'm observing a correct behavior.

[rreyelts]

I'm 95% sure those packets are sent to all hosts on the network.

Yeah, I don't know about the 255.255.255.255 part being valid (multicast groups run from 224.0.0.0 to 239.255.255.255) but that's the UDP broadcast I was just talking about.

Just look at java.net.MulticastSocket. The javadoc has a pretty good explanation.

God bless,
-Toby Reyelts

[sugarshark]

What I am trying to do is discover servers on the same subnet.

I believe that multicast UDP is the standard sort of way for solving this problem. (At least that's what I've done before, and IIRC it's what JINI service discovery is based on). It's really simple (and fast). Your server just broadcasts a small id-string on a pre-determined multicast group on a periodic basis (i.e. once every 250ms). Clients join the group and listen for a second or so to pick up any id-strings being broadcasted. That's it.

Actually with Jini it's more the other way around. The client sends a multicast request for the next lookup service, with it's ip address  in the source address field. The lookup services (the servers) are listening for these requests and will send back a unicast answer.

The 255.255.255.255 isn't a multicast, but a global broadcast.  You can send and receive broadcasts by setting the broadcast property on a DatagramSocket.

Using the global broadcast address usally works but  is regarded as BadStyle^TM.
The real broadcast adress is the highest address of your subnet. So the actual value depends on you netmask. For a class C net, having a netmask of 255.255.255.0,  the broadcast address is x.x.x.255. The host part of their address is: Addresses in this subnet minus one. (256 -1).

A net with a netmask of 255.255.255.224 (only the last five bits of the ip address are host adresses) uses a  broadcast address of (x.x.x.x & 255.255.255.224) + 31.

The differences between broadcasts and multicasts are:

• Broadcasts will not be routed. They are restricted to one subnet. Multicasts can be routed if the router is configured to do so.
  
• Broadcast are read by every network card. To receive a multicast packet you will have to join the corresponding multicast socket beforehand.

If you are to program a server discovery algorithm in Java, take a look at Jini http://www.jini.org. Gives you all this and more. Don't be intimidated by the 'more', the core is very simple to handle.

[leknor]

Here is another idea I remembered while reading shugarshark's reply: http://www.strangeberry.com/java_rendevous.htm It's an implementation of Zeroconf (Apple's Rendevous) in Java.

Games published by our own members! Check 'em out!

[swpalmer]

Thanks guys, I have lots of stuff to read up on now...

I was trying to avoid stuff like having the server broadcast a "here I am" message to clients.  I want the discovery to be entirely client driven.

I know almost nothing about MultiCast and BroadCast stuff.   I think Muticast I don't knwo what is required in terms of setting up a multicast address.. specially if it needs to be done in a dynamic way based on the IP address of the subnet.

I may add some peer-peer services that use JXTA.. (each server might define a peer group, and all severs might belong to a 'server' peer group) but that won't be for a while so I don't want to get involved with that just yet. (I don't even know if my ideas for JXTA make sense yet.)

JINI sounds like it might be my best bet.  Rendezvous is also a possibility.

Great responses as always... thanks again.

[rreyelts]

I was trying to avoid stuff like having the server broadcast a "here I am" message to clients.  I want the discovery to be entirely client driven.

You're not going to make that happen effectively. For example, NetBios is a broadcast protocol, the DHCP boot protocol is broadcast, and other protocols (like DNS) which aren't broadcast, depend upon broadcast protcols (DHCP) to initialize the client with the address of a lookup server. You mention Jini as "the best solution" and it is UDP multicast.

God bless,
-Toby Reyelts

[kevglass]

Does Java allow access to ethernet at all (maybe with this new NetworkInterface stuff? - I don't know about that)?

If so, you could use the ARP table to find the IP addresses of the others on the network, this is of course assuming you are using ethernet at all.

Kev

[swpalmer]

Just to be clear, my current implementation - which creates 254 threads to poll for servers does work.  I just don't like it... it doesn't give me a warm fuzzy feeling.

It would also be much better if I could get the Socket to time out faster.. but apparently you can't set the timeout for establishing the connection, only for I/O after that point.

If I could get that timeout down, then I would use a MUCH smaller pool of threads and have each one check maybe 4 IPs or so.. with a timeout of only a few seconds (e.g. 3) I would have acceptable results.

Looked closer at JINI... doesn't look as good as I hoped.. too complex for my simple application.  I will now look closer at Multicast and Broadcast addresses and how they work exactly...  this all has to work automatically with no configuration by the user.  If someone has to pick a multicast address or something first.. that wrecks it for me.

[rreyelts]

I'd like to re-emphasize that multicasting is the standard means for solving this problem, and the only programs that you see using your "style" are tools like nmap, which solve a different problem (like how to hack into somebody's machine).

If someone has to pick a multicast address or something first.. that wrecks it for me.

No - any number of programs/machines may be multicasting on the same group/port, so there's no real reason for a user to pick a multicast group/port.

You set a static group (ip-address) and port that are the same for both your client and your server. Then you just send and receive packets on that port. You may not be the only person broadcasting on that group/port (it's actually very likely you'll be alone, but it doesn't make any difference), so you need to make sure that you can distinguish your packets from somebody elses packets. That's where that short-id string comes into play. It just lets you know that you are indeed receiving a packet from the service that you're looking for. From that point, you've got the address of the server in the packet, and you can do anything you want. Your server may include a little extra information in the packet, for example, the port on which you should connect, if that is configurable.

God bless,
-Toby Reyelts

[swpalmer]

You set a static group (ip-address) and port that are the same for both your client and your server.

(multicast groups run from 224.0.0.0 to 239.255.255.255)

Ok this is the part that I am unsure about....  the server and client can be running on some arbitrary network... what are the restrictions, if any, for the multicast address that I choose?  (Will it berelated to the netmask?)

I'm thinking that the server will always have a thread that sits around listening on the multicast address/port and it will reply to some sort of 'are you there' request that the client will broadcast with the port number to connect on for standard client connections.

I need to go read some networking stuff... I think then I will have better questions - or if I'm lucky, no questions at all

[rreyelts]

what are the restrictions, if any, for the multicast address that I choose?  (Will it berelated to the netmask?)

None. You just have to pick any valid multicast address - what I listed before.

I'm thinking that the server will always have a thread that sits around listening on the multicast address/port and it will reply to some sort of 'are you there' request that the client will broadcast with the port number to connect on for standard client connections.

That may work well for your application, but it's kind of backwards. Generally speaking, you usually have very few servers on a network, and many clients. So you don't want 10,000 clients all multicasting on your network.

I need to go read some networking stuff... I think then I will have better questions

Honestly, there's just nothing to it. You should be able to write a test client / server in about 30 minutes, having never done it before.

God bless,
-Toby Reyelts

[Kevdog]

In our application we "cheat" and get the the IP address of our clients from an environment variable.  IP_ADDRESS is set before the program runs and our program polls that env variable.  Bit hackish, but it works.