In article <slrne12a29.l1l.dmfh@llanfaethlu.dmfh.cx>,
DMFH <dmfh@n0spam.dmfh.cx.spamn0t> wrote:
>On 2006-03-07, Walter Roberson <roberson@hushmail.com> wrote:

>I'll respectfully disagree with the use of hard-coded IP address, as I've

Sounds like I should give some examples.

>> I would use hard-coded IP addresses:

>> - on systems that made it difficult to resolve IP addresses

For example, if you are working with an operating system that
does not have hostname resolution already written, and does not
offer an API and compiler that would make porting resolution code
to be realistic within the available timeframe.

>> - for code that only had to survive for a short time, where the
>> extra effort of setting up a Domain Name System (DNS) was not
>> worth the effort

>- Your application may not be of a large scope or scale now, nor may you
>have plans for it to be placed into wide use, but it may become so across
>time and be subject to server moves / changes as your infrastructure grows.
>When it comes time to move servers or expand / change the network, you're
>left with the task of manually changing configuration files, or asking
>your network administrators to accommodate change through the use of NAT
>or another technique, which just slows change and creates for more
>complexity.

When you -are- the Systems or Network administrator, you often
end up writing a fair bit of "throw-away code", whose expected lifetime
is 5 minutes to half an hour. If you can get a one-time job done in a 5
line shell script using a hard-coded IP address, then it is unprofitable
to go to the trouble of writing or installing or configuring DNS
(e.g., for a system you are about to scrub the disk on.)


>So how to get the ease of use of a hard-coded address?

>- DNS can be a pain to deal with,

You presume that DNS is available

>so can local host files,

You presume that local host files are available

>and the lookup
>can cost your application time when setting up the initial connection,
>which, if it's a time-critical application, you may not want. Consider the
>use of a local DNS cache on the host like pdnds (for Intel hosts only I
>believe...), or a local instance of bind to cache DNS lookups.

You presume that bind, or bind source and a C compiler, are available
for that system, and that the system API is fairly close to unix,
and that one has time to do the installation. You presume that
someone will be available to maintain the DNS infrastructure.
You presume that the application has the luxary of doing DNS
lookups within its time or packet-count constraints.


>- Thinking strategically forward, consider the use of a load-balancer in
>the form of a commercial appliance, Open Source OS load-balancing, or even
>load-balancing in a network router (Cisco IOS has these features on some
>platforms), which could afford you the use of one well-known IP address
>behind which you could place servers supporting your application. Moving
>the application servers could then be as easy as swapping the load-balancer's
>IP address. Of course, this does add another layer of complexity as well.

You presume that the application servers are under your control
or within your sphere of influence. You presume that the protocol
involved is routable (e.g., not broadcast). You presume that funds
are available with which to purchase that kind of equipment. You
presume that space, electricity, and cooling are available to house
the equipment. You presume that you can get authorization to install
that kind of equipment -- e.g., the local security policy might
be "Only equipment which has been certified as B3 or EAP6 or higher",
or the local administrative policy might be "All programmable devices
*must* be Windows".


I am by no means saying that you should not use hostname resolution
where available and practical within the time and budget constraints:
what I am saying is that there are some situations where forcing
use of hostname resolution would not make sense.


Consider, for example, if you were programming a space probe, where
the launch costs are $30,000 per pound, and where radiation-hardened
electronics must be used. You've been allocated 64 Kb for your
science task. Are you going to use that space to implement DNS
and to expect the probe to do hostname resolution (with 22 hour
round trip times)... or are you going to be thinking about how
someone was able to slip a moon-finding program into less than 100
spare bytes and that, after all, a new address could always be
remotely programmed in the unlikely event that mission control
wanted to renumber the target host... ?