[PATCH gwproxy v1 0/3] Initial work for DNS lookup implementation

[Ahmad Gani <reyuki@gnuweeb.org>]

Hi Chief,

This is initial work of dns lookup feature, The patches aren't final, but
it's enough to get a grasp of what the interface looks like. I've 
provided a temporary entry point main function to test it.

There are 3 patches in this series:
- create net.h and net.c to store network related functionality.
- allow only port string number in service parameter of gwp_dns_queue
- initial work for implementation of C-ares-like getaddrinfo function

I propose to move the utility or helper function (that is commonly used 
in multiple places) to net.h and net.c, e.g., struct gwp_sockaddr is 
useful, and it possibly will be used in multiple places as the project 
expands.

I think it would be better to limit the service field to only contain the
port number, as SOCKS5 always uses a string port number.

in reply to Telegram chat [1]:
> (( It's the only reason we need a dedicated thread for resolving DNS ))

Is it preferred to use the current model (spawning dedicated DNS threads)
and make the behavior of the resolver the same as getaddrinfo (blocking)?
So far I've created the addrinfo interfaces with C-ares style and tested 
it; although, it's still blocking.

I would like to know the numbers for comparison between the thread model 
vs. the asynchronous model. Which approach is best for this scenario/case
(DNS resolution)?

I feel like multi-threading is much faster than single-threading, as it's
executed in true parallel (on a multi-core system) compared to 
concurrently doing things with an event notification mechanism.

My general understanding of parallel and concurrent is derived from this 
definition on the Stack Overflow answer [2]:
> Concurrency is when two or more tasks can start, run, and complete in 
> overlapping time periods. It doesn't necessarily mean they'll ever both
> be running at the same instant. For example, multitasking on
> a single-core machine. Parallelism is when tasks literally run at the 
> same time, e.g., on a multicore processor.

I also noticed that in the C-ares example [3], they recommend using the 
event thread example, and it is similar to the io_uring model in my 
perspective, where the operation is executed internally instead of 
letting the caller poll for readiness with ares_process_fd. Maybe we can 
mimic this aspect? I will remove the callback and make it blocking to 
make it compatible with the current thread model, but let's hear your 
opinion first.

I would like to request at least 40 revisions [4] to ensure I've learned 
something, so please treat me like I'm a dumb AI agent [5] (prompt me 
anything, I need more input!) and please review, thanks!

[1]:
- https://t.me/GNUWeeb/1192156

[2]:
- https://stackoverflow.com/a/1050257/22382954

[3]:
- https://c-ares.org/docs.html#examples

[4]:
- https://t.me/GNUWeeb/625966
- https://lore.kernel.org/lkml/20201104145430.300542-1-jarkko.sakkinen@linux.intel.com/T/

[5]:
- https://www.youtube.com/watch?v=P_O0ynyLOtI

Ahmad Gani (3):
  dnslookup: split common functionality and struct into net.c
  dnslookup: Allow only port string number
  dnslookup: Initial work for implementation of C-ares-like getaddrinfo
    function

 Makefile                |   1 +
 man/gwp_dns_queue.3     |   2 +-
 src/gwproxy/dns.h       |  12 +-
 src/gwproxy/dnslookup.c | 286 +++++++++++++++++++++++++++++++
 src/gwproxy/dnslookup.h | 110 ++++++++++++
 src/gwproxy/dnsparser.c | 362 ++++++++++++++++++++++++++++++++++++++++
 src/gwproxy/dnsparser.h | 188 +++++++++++++++++++++
 src/gwproxy/gwproxy.c   |  29 ----
 src/gwproxy/net.c       | 108 ++++++++++++
 src/gwproxy/net.h       |  27 +++
 10 files changed, 1085 insertions(+), 40 deletions(-)
 create mode 100644 src/gwproxy/dnslookup.c
 create mode 100644 src/gwproxy/dnslookup.h
 create mode 100644 src/gwproxy/dnsparser.c
 create mode 100644 src/gwproxy/dnsparser.h
 create mode 100644 src/gwproxy/net.c
 create mode 100644 src/gwproxy/net.h


base-commit: 0753f2d766e85fcbffc1f83dfd4e67d6206591cb
-- 
Ahmad Gani