On 22-Nov-21 16:06, Marcel Hellwig via curl-library wrote:
On 22.11.21 21:33, Timothe Litt via curl-library wrote:Why not just put the entries you need into hosts.txt ( Actually /etc/hosts or \Windows\System32\drivers\etc\hosts, or equivalent)?Because I don't know the host names beforehand.Even embedded OSs support this, and the convention is to look there before consulting DNS. This happens behind the system calls that do name resolution, so it's transparent to cURL - and anything else. For GNU systems, this is in glibc (and see /etc/nsswitch.conf for resolution order). Let the OS do its job, don't re-invent the wheel.This supports all the use cases for all applications.Building something custom into cURL only gets you cURL - and when you want to do something else (notify someone via mail, or SMS, or ...) you're back to either doing it via cURL, or trying to force your own name resolution into the next application.I only want curl. Maybe I wasn't clear enough.The device has *no* internet access at all. The only way to connect to the internet is through this application. Linux doesn't own or handle the device.- Marcel
There would seem to be 3 cases:1) you have an initial IP address but don't know what its name will be in a particular installation.
2) you have a name, but don't know what it's address is 3) you have neither until some out-of-band mechanism delivers one or bothIn case 1, it doesn't matter what the name is. Call it "Fred". All an application needs is the IP address.
Case 2 is classic name resolution. The address has to come from somewhere. You can put it in the DNS - but as you don't have internet (or apparently even a local resolver), put it in a file. /etc/hosts is already there
Case 3, nothing is going to happen until the out-of-band mechanism delivers - at which point it reduces to 1 or 2.
/etc/hosts doesn't require internet access. And it doesn't care about what device you use to communicate. It just does name resolution. Assuming a POSIX system, /etc/nsswitch just needs a line like "hosts: files" to tell (g)libc to look to /etc/hosts and not look to dns.
If you're using cURL, you (almost) always end up with an IP address. You can connect to your server by address (in your case, typically an rfc1918 or IPv6 private address). If, as it seems, you want a name, you can call it anything you want in /etc/hosts.
E.g. server 192.168.0.4 or my.strange.server.mydomain.example.net 10.0.0.4 10.12.3.4 2001::123You can update /etc/hosts if the address changes, is discovered later, or is delivered over your private scheme.
If you are providing your own socket and read/write over some proprietary protocol, I don't understand why you need name resolution integrated with cURL's cache. But if what you want to end up with looks like an IP address, /etc/hosts will do the mapping.
If you roll your own, you're going to end up with a name and an address. You'll probably store it in a file of some sort, read the file, and update cURL's cache. This is at least as much work as updating /etc/hosts - which your OS will still have the code to handle. You're not gaining anything by going this route, and what you end up with is much more limited.
You really want to the the OS do it's job. Name resolution is a solved problem - originally via hosts.txt (now /etc/hosts), as well as by DNS, LDAP, and many other technologies. You should spend your creativity doing something more valuable than reinventing solutions.
As for "I only want curl" - I'm sure that's true. Today. But things change. I have decades of examples - from 4-bit embedded computers to mainframes. Customers, product managers, and yes, even engineers, always find reasons to improve the product.
Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed.
OpenPGP_signature
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
