gevent.resolver_ares – c-ares based hostname resolver

class Resolver(hub=None, use_environ=True, **kwargs)

Bases: object

Implementation of the resolver API using the c-ares library.

This implementation uses the c-ares library to handle name resolution. c-ares is natively asynchronous at the socket level and so integrates well into gevent’s event loop.

In comparison to gevent.resolver_thread.Resolver (which delegates to the native system resolver), the implementation is much more complex. In addition, there have been reports of it not properly honoring certain system configurations (for example, the order in which IPv4 and IPv6 results are returned may not match the threaded resolver). However, because it does not use threads, it may scale better for applications that make many lookups.

There are some known differences from the system resolver:

  • gethostbyname_ex and gethostbyaddr may return different for the aliaslist tuple member. (Sometimes the same, sometimes in a different order, sometimes a different alias altogether.)
  • gethostbyname_ex may return the ipaddrlist in a different order.
  • getaddrinfo does not return SOCK_RAW results.
  • getaddrinfo may return results in a different order.
  • Handling of .local (mDNS) names may be different, even if they are listed in the hosts file.
  • c-ares will not resolve broadcasthost, even if listed in the hosts file.
  • This implementation may raise gaierror(4) where the system implementation would raise herror(1).
  • The results for localhost may be different. In particular, some system resolvers will return more results from getaddrinfo than c-ares does, such as SOCK_DGRAM results, and c-ares may report more ips on a multi-homed host.

Caution

This module is considered extremely experimental on PyPy, and due to its implementation in cython, it may be slower. It may also lead to interpreter crashes.

Next page: gevent.backdoor – Interactive greenlet-based network console that can be used in any process