Robert Elz <kre@munnari.OZ.AU> writes:

> Instead ...
> 
>   | For getaddrinfo(), the TTL is returned in a new field added to the
>   | addrinfo struct.
> 
> is all that is needed.   Any application planning to make use of the
> extra information is going to require code updates anyway.   Simply
> having it switch to getaddrinfo() and drop all uses of gethostby*()
> is going to be a minor change - assuming it hasn't already been done
> for IPv6 support.
> 
> The only reason to keep using gethostby*() at all is for legacy systems
> where getaddrinfo() doesn't exist - but those systems also can't be
> assumed to have the new TTL availability - so really, any application
> that finds itself ever needing to use gethostby*() cannot make use of
> the extra info anyway.

Good point.  I was thinking that it would be easier for applications
to just pick up h_ttl (which they could detect using configure), but
that was muddle-headed.  As you say, if you have to change the app,
you might as well change to getaddrinfo() anyhow.

>   | If the TTL is not defined, as is the case when the answer comes from
>   | /etc/hosts or from NIS, then the returned TTL is set to -1, with
>   | appropriate macros to be used by calling code.
> 
> I'm not sure I like that part - just pick a defined value and set it
> to that - 0 may be OK (/etc/hosts lookups are always going to be
> pretty cheap, NIS, well, who cares?) but perhaps some other small
> value would be just as good (30 seconds) ?
> 
> That avoids the need to special case code to deal with this.

I understand what you are saying, but to me they really feel like
different cases.  I can imagine that an application would want to deal
differently with the case of no TTL information.  I feel that if we
are able to make it distinct, we shouldn't hide it.

Or, at least, there should be some way to distinguish the cases.  So
another possibility would be to add another flag to ai_flags:
AI_TTLUNKNOWN.  Then if the TTL were unknown, set the ai_ttl field to
zero, and set AI_TTLUNKNOWN in ai_flags (as well as AI_TTLVALID).
That would permit applications to either distinguish the case of an
unknown TTL, or not worry about it and just go with the zero TTL.

Any thoughts on that approach?

Ian