3

If you are programming an application which is heavily using the network (e.g. pings, dns resolves, etc), is it better to use IP addresses in the code (e.g. if making a folder path on a server - //192.183.181.182/test/test1 for example), or hostnames?

I am assuming IP addresses as they tend to be static in the enterprise, and hostnames can have aliases etc to a single IP address. Is this a valid reason to prefer IP addresses?

Thanks

Mike Pennington
  • 41,899
  • 19
  • 136
  • 174
GurdeepS
  • 65,107
  • 109
  • 251
  • 387
  • Why are you trying to avoid using of handy hostnames? Have you already experienced some issue with them? – zerkms Apr 19 '11 at 23:06

4 Answers4

6

The problem with using hardcoded IP addresses is that if you need to change it, you need to change the code, while if you use hostnames, if you need to change it, you can change where the hostname points, without touching the code :)

jcarlosn
  • 398
  • 1
  • 4
  • 2
    Also, there's no particular performance benefit to using hard coded IP addresses. – Jim Mischel Apr 19 '11 at 23:07
  • 2
    @Jim Mischel: well, it actually is. If DNS server falls down - the programm will fail too. As well as dns resolve takes a time to be performed. – zerkms Apr 19 '11 at 23:08
  • I would assume you would separate this concern as you would any other, whether you decided to go IP or qualified name, so changes to code would involve a Constants file... I would suggest maybe a map of both, with a failsafe check to use dns first, then fallback to IP... but that's just me ;) – Dan Apr 19 '11 at 23:14
  • 1
    @zerkms, a company that allows their DNS resolution to fail in anything other than a major catastrophe has bigger problems than application response time. DNS is *the linchpin* of corporate IT infrastructure... it was designed to be a distributed, redundant system, and should be deployed that way. – Mike Pennington Apr 19 '11 at 23:17
  • @Mike Pennington: it all good while is written on the paper, in real life it could be different cases, when dns can fall down and dns can respond slowly. Btw, on ssh servers it is a common case to turn off dns resolution. – zerkms Apr 19 '11 at 23:20
  • @zerkms, I've been operating live systems and networks since the early 90s. Rationalize the decision as you like, but the bottom line is that if that application becomes business critical, your design decision to hard-code an IP in compiled code would cost the company operational and capital expenditures that could have been better-solved by someone fixing a broken DNS deployment; and that is a problem everyone will need a solution to. If you must, leave the hard-coded IP in a seperate config file, and we could disagree peacefully. – Mike Pennington Apr 19 '11 at 23:27
  • @zerkms: Internal DNS resolution *might* take 100 ms. The first time you do it after rebooting your machine. Then, assuming you'll be using that network name frequently, it will be in the client's DNS resolver cache. And if that's too slow, then you have other, much more serious, problems. – Jim Mischel Apr 20 '11 at 05:02
  • @Jim Mischel: it would be true if linux had dns resolver cache installed as default ;-) Anyway, I just noticed that it is *very common* to turn off dns resolution in sshd. – zerkms Apr 20 '11 at 05:05
  • @zerkms, you keep throwing this datapoint around about sshd and disabled DNS. I ask, "so what?". It seems to be comparing aples and oranges to me. The code we are talking about would make a connection to something else... It is another thing entirely to recieve random connections from all over the globe, which have the closest authorative DNS on a different continent (meaning maybe 75ms round trip delay). – Mike Pennington Apr 21 '11 at 09:23
3

Fully agreeing with jcarlosn above, and throwing in my $0.02 as a network infrastructure guy...

As a network engineer, I could go on for quite some time about the number of instances where I've seen people mistakenly hard-code an IP into an application, and the suffering that happens for years because the company has to contort the growth of IT infrastructure around that original assumption of a hardcoded ip and a subnet in some particular facility. This has an impact on operational and capital expenses of the company.

Also consider what happens when that app is deployed on hundreds of PCs, and has now become business critical to your company and business partners.

Please use DNS names, or if you feel you must use an ip for some bizarre reason... use a local application config file as suggested in another post. Please understand though that a config file doesn't change the corporate downtime for a business-critical app to get migrated to a new IP address. If your desktop people are good, they can probably rewrite an application config file as quickly as you could migrate a DNS name... if you work for a company with no real scripting skills in the desktop deployment dept, please reconsider using DNS with no longer than a 30 minute TTL on that A record.

Mike Pennington
  • 41,899
  • 19
  • 136
  • 174
2

There are valid reasons for both. Multi-homed servers can cause issues when using names (as you mention), but IP addresses aren't necessarily stable either- especially in a DHCP environment that's not using reservations (more common than you might think).

If it were me, I'd put the path/hostname/IP in config- then you can change to whatever's needed without rebuilding the code. If you're doing name lookups yourself internally, just make sure your code is prepared for either an IP or a hostname.

nitzmahone
  • 13,720
  • 2
  • 36
  • 39
  • you raise a fair point about multihomed servers, but you assume that multi-homing requires a seperate IP address. A few years ago, that was true, but [switch chassis clustering](http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9336/prod_qas0900aecd806ed74b.html) and LACP have obsoleted much of the need for multiple IP addresses on a server IMHO – Mike Pennington Apr 19 '11 at 23:14
  • Just sharing what I've been bitten with on my own projects. If he doesn't control the configuration of the target server and DNS, he's at the mercy of whatever's there. Just because it's a stupid way to set the server up doesn't mean it hasn't been done. :) – nitzmahone Apr 19 '11 at 23:22
  • since you're willing to put hardcoded IPs in a config file, we can peacefully disagree; although I would still advocate a DNS name. I'd be inclined to start a holy crusade against someone who compiles an IP into application code. :-) – Mike Pennington Apr 19 '11 at 23:36
  • Don't get me wrong- I'd opt for the hostname every time and twice on Sunday, but if you're dealing with a government or other large bureaucratic org, where getting a simple misconfiguration fixed can take weeks of paperwork and hassle, best to have the escape hatch of accepting an IP. :) – nitzmahone Apr 19 '11 at 23:43
1

IPv4 addresses (32bit addresses) are supposed to become obsolete in 2012, (I think they made a movie about that, with earthquakes and tsunamis.)

There are already no new IPv4 addresses available for sale.

The new standard, IPv6, uses.much longer addresses.

Let the user decide, if he/she has a hostname, store that. However, hostname may have more than 1 IP address.

If user provides an IP address (v4 or v6), store that.

If you get q MAC address, store that.

Explain the users pros and cons (e.g. names ate more static).

Danny Varod
  • 17,324
  • 5
  • 69
  • 111