| IP Owner | IP bit manipulation |
| IP From Domain Name | IPv6 |
| Domain Owner | IP Assignment |
| Domain/IP Location | IP Protocol |
| Face IP | Learning More |
| Your Own IP | Books |
| Others’ IP | Links |
| Displaying an IP |
For the third question (who owns this domain) use one of these whois services:
For third question (where is the domain located) use one of these Ip locator services:
In JSP, the following methods may be useful: request.getServerName(), request.getServerPort() and request.getRequestURI()
If you are writing a Applet, you can find out the name of the server indirectly via Applet.getCodeBase. You have to use the URL.getHost method to pull out just the part you want.
If your webserver supports SSI you can get such information via the REMOTE_HOST (URL) REMOTE_ADDR (IP) SERVER_NAME (URL) and SERVER_ADDR (IP) directives.
In Windows, you can use the utility ipconfig /all to display information such as IP, subnet mask, DNS Server IP, host name, physical ethernet 48-bit MAC address, gateway IP and DHCP server IP. In older versions of Windows there is a similar utility called winipconfig. You can spawn this utility from Java with the exec function, and programmatically scan through the output to find what you need. Alternatively, you need to write platform specific JNI code to grab additional information, such as DNS servers, gateways, masks, etc.
There are various utilities that periodically probe to find out your IP address, then notify you if your face IP changes, and also notify the DynDns server.
If you are behind a firewall you may not have access to DNS or reverse DNS lookup. You might experiment by putting the DNS-IP pair in your Windows or NT HOSTS file, or working purely with IPs. Sometimes the receiver requires a DNS name, not just a pure IP. In that case you can provide one with URLConnection.setRequestProperty().
I know of no way to discover your DNS server IPs without resorting to JNI.
Unfortunately, finding out your server’s IP will trip the sandbox security mechanism in an Applet. You could sign the Applet, or you can dance around the problem this way: you get the server name from getCodeBase().getServer(), open a Socket to port 80 and retrieve the local IP address from that Socket. If getServer() returns null, the Applet is running locally, and you could just use localhost namely 127.0.0.1 as the IP address. In Linux you could use localhost@localdomain.
You can find out who owns a domain name at http://www.networksolutions.com/cgi-bin/whois/whois. Unfortunately, you can no longer find out who owns an IP. For that you need arin.net.
If you need finer control than InetAddress gives you, e.g. the ability to select the DNS server, try DNSJava.
To find out your own IP address you could lookup localhost using InetAddress.getByName but that would just give you 127.0.0.1 which is not likely what you really wanted. In Windows, you can spawn ipconfig.exe /renew and capture the IP Address line in the output.
Java maintains a cache for DNS lookup. You can control its behaviour with:
// Controlling DNS caching with System properties // A value of 0 indicates "never cache". // A value of -1 indicates "cache forever". // A plain numeric value means the number of seconds to cache. // cache lookups for 1000 seconds. System.properties.setProperty( "networkaddress.cache.ttl", "1000" ); // cache unsuccessful lookups for 10 seconds. System.properties.setProperty( "networkaddress.cache.negative.ttl", "10" );
For computers not directly attached to the Internet, (e.g. via a proxy server), or on a LAN that has Internet access, but without individual station access, or on an isolated LAN, you don’t need universally unique IP numbers. You can use the ones reserved for local private LAN use. You don’t need to get anyone’s permission to use them such as 192.168.0.1 .. 192.168.255.254
| IP Addresses | |||||
|---|---|---|---|---|---|
| Address
Class |
IP Range | Format | |||
| A large | 0.0.0.0 (null)
1.0.0.1 .. 9.255.255.254
10.0.0.1 .. 10.255.255.254
11.0.0.1 .. 126.255.255.254 127.0.0.1 (localhost) |
| |||
| B medium | 128.0.0.1 .. 172.15.255.254
172.16.0.1 .. 172.31.255.254
172.32.0.1 .. 191.255.255.254 |
| |||
| C small | 192.0.0.1 .. 192.167.255.254
192.168.0.1 .. 192.168.255.254
192.169.0.1 .. 223.255.255.254 |
| |||
Usually a router on a home LAN is 192.168.0.1 and DHCP will assign computers on the LAN to addresses in the range 192.168.0.101… 192.168.0.110, and you assign any static IPs on the LAN in the range 192.168.0.2…192.168.0.10.
The scheme above turned out to be too limiting, so now it is largely ignored, IPs are assigned as bands of consecutive integers on any boundary. This more flexible system is called cidr — classless inter-domain routing. Because we are running out of IPs we have quadrupled their size to 128 bits with IPv6. That oughta hold 'em, 3 followed by 38 zeros of IPs to choose from.
One of the rather terrifying things about the way the Internet is designed is that there is little to stop people from configuring their machines with IPs they have no business using. It becomes trivially easy to steal unused or rarely used IPs, to spoof someone else’s identity, or to spy on someone else’s traffic. The Internet protocols were not designed to deal with malicious teenage hackers, only gentlemanly academics. If engineers built the way computer scientists do, the first woodpecker than came along would destroy civilisation.
The IP protocol can best be understood by looking at the header that goes on each packet. The IP packet header is a bit like the baggage tag you attach to your suitcase before entrusting it to the airline:
| IPv4 Packet Header | ||
|---|---|---|
| Field | Size in bits | Purpose |
| version | 4 | 4 for IP version 4. This allows IPv4 and IPv6 packets to be mixed. |
| hlen | 4 | size of packet header measured in 32-bit chunks. |
| total length | 16 | total size of packet header plus data payload measured in 8-bit chunks (aka bytes or octets). The means the maximum size of a packet including data is 64K. This means the payload of data is at most 65,515 bytes. |
| time to live | 8 | how many more hops/seconds this packet has to live before being discarded as lost or hopelessly late. On each leg of this packet’s journey, this field gets decremented by 1 or the number of seconds of delay at that hop if the delay was greater than one second. |
| header checksum | 16 | digest of just the header to ensure the header has not been scambled in transmission. It has to be recomputed at each hop to account for the new value of the time to live field. Note that the body of the packet is not protected by checksum. That has to be done at a higher level, e.g. UDP or TCP/IP. |
| source IP | 32 | Who sent the packet. When it finally arrives at its destination the receiver will know who it was from. |
| destination IP | 32 | Where the packet is going. On each leg of its journey the routing computer uses this to get the packet a little closer to its final destination. |
| other stuff | 48 | Miscellaneous fields. See details. |
Everything is in big endian byte order.
The sender tosses his packet of data into the Internet, with the header. Computers on the net pass the packet along hoping to get it closer and closer to its destination. Perhaps a dozen hops later it finally arrives. Perhaps it doesn’t. There is nothing in IP protocol to guarantee safe arrival. However, if a packet has to be split up for part of its journey, IP will automatically reassemble the parts.
IP protocol does not sound too promising. Unlikely you will use IP protocol directly. UDP ( via Java classes DatagramPacket and DatagramSocket) and TCP/IP (via Java classes Socket and ServerSocket) protocols are built on top of IP, and FTP and HTTP (via Java class HttpURLConnection) are built on top of TCP/IP.
![]() |
recommend book⇒Internetworking with TCP/IP Vol.1: Principles, Protocols, and Architecture, 4th edition | |||||||||||||||||
| hardcover | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ISBN10: | 0-13-018380-6 | |||||||||||||||||
| ISBN13: | 978-0-13-018380-4 | |||||||||||||||||
| publisher: | Prentice Hall | |||||||||||||||||
| published: | 2000-01-18 | |||||||||||||||||
| by: | Douglas E. Comer | |||||||||||||||||
| How IP, UDP and TCP/IP protocols work. How the domain name to IP translation DNS information in propagated. | ||||||||||||||||||
| ||||||||||||||||||
![]() |
and suggestions to improve this page to Roedy Green : | ||
| Canadian Mind Products | |||
| mindprod.com IP:[65.110.21.43] | |||
| Your face IP:[38.103.63.16] | The information on this page is for non-military use only. | ||
| You are visitor number 59,745. | Military use includes use by defence contractors. | ||
| You can get a fresh copy of this page from: | or possibly from your local J: drive (Java virtual drive/Mindprod website mirror) | ||
| http://mindprod.com/jgloss/ip.html | J:\mindprod\jgloss\ip.html | ||