lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #50325] DNS local host list exported functions lack ve


From: Konstantin
Subject: [lwip-devel] [bug #50325] DNS local host list exported functions lack versatility
Date: Thu, 16 Feb 2017 10:30:56 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:51.0) Gecko/20100101 Firefox/51.0

Follow-up Comment #5, bug #50325 (project lwip):

Agree with undocoumented non-static as not a good choice.

I understand it was meant to be implemented so. I just suggest that publishing
already implemented lookup may have its uses, since it does read-only job and
cannot affect performance or stability more than already published addhost and
removehost.

Suppose we are running about 30 minutes, and user program have acquired
hostname-ip pair in a way other than through "dns.c". It wants to inform LwIP
DNS, which seems to be easy through dns_local_addhost, since it allows to
specify both pair parameters (even if the IP is not really "local"). Using
published lookup it could determine, whether it is already on the list or not
(to avoid duplicates). If it wants to get the cached IP, it could use the same
lookup.

Maybe I misunderstand the local list purpose, but it is the only way I have
found to tell LwIP DNS at runtime about hostname-ip pair. The pair user
program is sure of, but DNS had no idea, because user program has got it in
some other way.

Maybe it would be better to solve through other published functions, which
would allow user program to add/remove entries to DNS cache table instead of
DNS local list, this way Add function with TTL specified could be used. But
this latter solution would be much more complicated...

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?50325>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]