Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (495)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Getting IP Address on Linux  (Read 3425 times)
0 Members and 1 Guest are viewing this topic.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Posted 2003-05-20 23:42:03 »

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

Offline leknor

Junior Member




ROCK!!!


« Reply #1 - Posted 2003-05-21 01:25:38 »

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

Junior Member




Sugar to the sharks.


« Reply #2 - Posted 2003-05-21 09:35:44 »

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.

I used to think that the brain was the most wonderful organ in my body.  
Then I realized who was telling me this.
-- Emo Phillips
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #3 - Posted 2003-05-21 14:24:53 »

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.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #4 - Posted 2003-05-21 15:10:19 »

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.

Offline rreyelts

Junior Member




There is nothing Nu under the sun


« Reply #5 - Posted 2003-05-21 15:55:16 »

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


About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Offline leknor

Junior Member




ROCK!!!


« Reply #6 - Posted 2003-05-21 15:55:35 »

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

Junior Member




There is nothing Nu under the sun


« Reply #7 - Posted 2003-05-21 16:09:07 »

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



About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Offline sugarshark

Junior Member




Sugar to the sharks.


« Reply #8 - Posted 2003-05-23 06:34:50 »

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

I used to think that the brain was the most wonderful organ in my body.  
Then I realized who was telling me this.
-- Emo Phillips
Offline leknor

Junior Member




ROCK!!!


« Reply #9 - Posted 2003-05-23 09:51:45 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #10 - Posted 2003-05-23 13:41:45 »

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.

Offline rreyelts

Junior Member




There is nothing Nu under the sun


« Reply #11 - Posted 2003-05-23 16:38:54 »

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

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Offline kevglass

JGO Kernel


Medals: 164
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #12 - Posted 2003-05-23 17:11:59 »

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

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #13 - Posted 2003-05-24 14:19:51 »

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.

Offline rreyelts

Junior Member




There is nothing Nu under the sun


« Reply #14 - Posted 2003-05-24 14:57:19 »

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

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #15 - Posted 2003-05-24 18:26:14 »

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

Quote
(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 Smiley

Offline rreyelts

Junior Member




There is nothing Nu under the sun


« Reply #16 - Posted 2003-05-24 18:49:39 »

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

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Offline Kevdog

Junior Member





« Reply #17 - Posted 2003-07-30 22:30:43 »

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.

There are only 10 types of people, those who understand binary and those who don't!
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Dwinin (29 views)
2014-09-12 09:08:26

Norakomi (57 views)
2014-09-10 13:57:51

TehJavaDev (76 views)
2014-09-10 06:39:09

Tekkerue (38 views)
2014-09-09 02:24:56

mitcheeb (58 views)
2014-09-08 06:06:29

BurntPizza (45 views)
2014-09-07 01:13:42

Longarmx (30 views)
2014-09-07 01:12:14

Longarmx (35 views)
2014-09-07 01:11:22

Longarmx (36 views)
2014-09-07 01:10:19

mitcheeb (40 views)
2014-09-04 23:08:59
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!