Async networking and blocking host name resolving / DNS

[zevv]

I believe the current mechanism used for hostname lookups interferes with truly asynchronous networking. The async dial() ends up using the getaddrinfo() C library call, which can show serious blocking behaviour.

This is a common problem in network programming, with no obvious solutions, but it would be nice to offer a truly async experience for the Nim user without unexpected blocking when doing high level networking, like AsyncHttpClient.

Some ideas:

• Can Nim wrap the getaddrinfo() call in a separate thread to do the lookups? This requires threading to be enabled, obviously
• Should Nim implement (a subset of) getaddrinfo() asynchronously in pure Nim?
• Should Nim be able to rely on an external library for lookups, like libc-ares?

[dom96]

This also extends to our handling of asynchronous file reading. Currently asyncfile isn't truly async as far as I remember. I think Node solves this issue by using a separate thread, sadly doing so in Nim is a bit tough.

[euantorano]

I've had a quick look, and it looks like there are a few platform specific APIs to resolve names asynchronously:

• Windows: DnsQueryEx
• glibc: getaddrinfo_a
• OpenBSD: getaddrinfo_async

Some interesting links on the topic:

• https://medium.com/where-the-flamingcow-roams/asynchronous-name-resolution-in-c-268ff5df3081
• https://github.com/clementfarabet/async/blob/master/luv/libuv/src/unix/getaddrinfo.c

[zevv]

My preferred solution would be something like the first option above: wrap the standard getaddrinfo() into a thread, and provide minimal infrastructure for hooking this into asyncdispatch. My only problem is that for this I either need a poll/sleep loop (not nice) or posix pipes (not portable), unless there is some mechanism I don't know about that can connect threads and async. (On IRC, dom96 mentioned FlowVar for this?)

[euantorano]

It looks like that's what getaddrinfo_a does under the hood anyway @zevv, with a threadpool hidden inside the library so we're probably best off creating our own.

[dom96]

@zevv take a look at how I used 'spawn' to read from stdin asynchronously in my Nim in Action chat app: https://github.com/dom96/nim-in-action-code/blob/master/Chapter3/ChatApp/src/client.nim#L42

Currently, checking whether a FlowVar is finished is inefficient, but this will improve. You can use the same tactic to implement this for now.

[2vg]

There is an asyncpipe library created by cheatfate.
It seems to work on major platforms.
Using this, another thread pass the result to pipe, how about waiting for the pipe in the main thread?

[zevv]

Up to now I have been this for my resolving problem, but this is far from optimal:

proc asyncGetAddrInfo*(address: string, port: Port, domain: Domain = AF_INET,
                  sockType: SockType = SOCK_STREAM,
                  protocol: Protocol = IPPROTO_TCP): Future[ptr AddrInfo] =
                  
  var fut = newFuture[ptr AddrInfo]()
  var fv = spawn getAddrInfo(address, port, domain, socktype, protocol)
  
  addTimer(10, false, proc(fd: AsyncFD): bool =
      if fv.isReady():
        fut.complete(^fv)
        return true
    )   

  return fut      

I also deployed a version that uses pipe() to do the signaling, but that is posix-only.

I think there is a missing link between two different subsystems in the Nim libraries: async and threading does not mix well. This is not a Nim-specific problem of course, but it would be nice if Nim could provide the proper mechanisms to do synchronization between threads and async.

What would be required to get portable async pipes into the Nim core libraries, maybe asyncpipe as mentioned by @2vg, or something similar?

[dom96]

I think there is a missing link between two different subsystems in the Nim libraries: async and threading does not mix well.

There is, yeah, this issue is something I want for v1.0. It should go a long way to bridging this gap:
#8080

[zevv]

In case anyone ever needs this, here is my posix-only version using a pipe to signal completion from a thread. status: experimental

proc asyncGetAddrInfo*(address: string, port: Port, domain: Domain = Domain.AF_INET,
                  sockType: SockType = SockType.SOCK_STREAM,
                  protocol: Protocol = Protocol.IPPROTO_TCP): Future[ptr AddrInfo] =
       
  var fut = newFuture[ptr AddrInfo]()

  var fd: array[2, cint]
  if posix.pipe(fd) != 0:
    fut.fail(newException(OSError, osErrorMsg(osLastError())))
  
  addTimer(1000, false, proc(_: AsyncFD): bool =
    var buf = "t"
    discard posix.write(fd[1], addr buf[0], buf.len)
    return true
  )   

  proc aux(address: string, port: Port, fd: cint): ptr AddrInfo =
    var buf = "x"
    try:
      result = getAddrInfo(address, port)
      if result != nil:
        buf = "1"
    except:
      buf = "e"
    discard posix.write(fd, addr buf[0], buf.len)
  
  let fv = spawn aux(address, port, fd[1])

  proc on_read(_: AsyncFd): bool =
    var buf = "x"
    discard posix.read(fd[0], addr buf[0], buf.len)
    if buf == "1":
      let ai = ^fv
      if ai != nil:
        fut.complete ai
      else:
        fut.fail(newException(OSError, "error"))
    elif buf == "t":
      fut.fail(newException(OSError, "timeout"))
    else:
      fut.fail(newException(OSError, "unknown error"))
    unregister fd[0].AsyncFd
    discard close fd[0]
    discard close fd[1]
    return true

  register fd[0].AsyncFd
  addRead(fd[0].AsyncFd, on_read)

  return fut

[treeform]

I just want to say I ran into this as well and wanted to chime in.

• Nodejs appears to have the same issue: unref support for dns requests libuv/libuv#203
• Go seems to have build their own DNS resolver: https://golang.org/pkg/net/#hdr-Name_Resolution
• Rust appear to have their own resolver as a library, not sure if its the default: https://docs.rs/trust-dns-resolver/0.18.1/trust_dns_resolver/

My vote is on a completely async DNS resolver written in Nim, it appears OS resolves have thread blocking problems.

[FedericoCeratto]

Many organizations customize the resolution process in resolv.conf, e.g. in order to use local (stub) caching resolvers, or implement different behaviors.
Language-specific resolvers that ignore the OS can create problems.