Edit

kc3-lang/libevent/whatsnew-2.2.txt

Branch :

  • Show log

    Commit

  • Author : Cœur
    Date : 2024-04-30 15:59:58
    Hash : eec47a67
    Message : Fix typos (#1634)

  • whatsnew-2.2.txt
  •                          What's new in Libevent 2.2
                                 Azat Khuzhin
    
    0. Before we start
    
    0.1. About this document
    
      This document describes the key differences between Libevent 2.1 and
      Libevent 2.2. It's a work in progress.
    
      For better documentation about libevent, see the links at
      http://libevent.org/
    
      Libevent 2.2 would not be possible without the generous help of numerous
      contributors.  For a list of who did what in Libevent 2.2, please see the
      CONTRIBUTORS.md!
    
    0.2. Where to get help
    
      Try looking at the other documentation too.  All of the header files have
      documentation in the doxygen format; this gets turned into nice HTML and
      linked to from the libevent.org website.
    
      You can ask the questions by creating an issue on github.
    
      Note, that the following communication channels had been deprecated:
      - #libevent IRC channel at irc.oftc.net
      - libevent-users@freehaven.net mailing list
    
    0.3. Compatibility
    
      Our source-compatibility policy is that correct code (that is to say, code
      that uses public interfaces of Libevent and relies only on their documented
      behavior) should have forward source compatibility: any such code that worked
      with a previous version of Libevent should work with this version too.
    
      We don't try to do binary compatibility except within stable release series,
      so binaries linked against any version of Libevent 2.1 will probably need to
      be recompiled against Libevent 2.2 if you want to use it. It is probable that
      we'll break binary compatibility again before Libevent 2.2 is stable.
    
    1. Core New APIs and features
    
    1.1. "Prepare" and "check" watchers
    
      Libevent now has a new mechanism for hooking into the event loop: "prepare" and
      "check" watchers.  A "prepare" watcher is a callback that fires immediately
      before polling for I/O. A "check" watcher is a callback that fires immediately
      after polling and before processing any active events. This may be useful for
      embedding other libraries' event loops (e.g. UI toolkits) into libevent's. It's
      also useful for monitoring server performance. For example, if you measure the
      time between "prepare" and "check," that is the polling duration; the difference
      between the expected and actual polling duration provides an indication of
      kernel scheduling delay. And if you measure the time between "check" and the
      next "prepare" (in the next iteration of the event loop), that is a good
      approximation of the amount of time handling events; this provides a convenient
      way to monitor whether any event handlers are blocking or otherwise performing
      heavy computation.
    
      The watcher API is defined in <event2/watch.h>. A concrete example of how
      watchers can help monitor server performance is available in
      "sample/watch-timing.c".
    
    1.2. Ability to configure read/write buffer sizes for evbuffer/bufferevents
    
      This allows to increase the IO throughtput.
    
      Here is some numbers for the single max read in evbuffer impact:
        function client() { becat "$@" | pv > /dev/null; }
        function server() { cat /dev/zero | becat -l "$@"; }
    
      Plain bufferevent:
    
      - 40K
        $ server -R $((40<<10)) & client -R $((40<<10))
        700MiB/s
    
      - 16K *default now*
        $ server & client
        1.81GiB/s
    
      - 4K
        $ server -R $((4<<10)) & client -R $((4<<10))
        1.05GiB/s
    
      With OpenSSL (-S):
    
      - 40K *default now*
        $ server -S -R $((40<<10)) & client -S -R $((40<<10))
        900MiB/s
    
      - 16K *default now*
        $ server -S & client -S
        745MiB/s
    
      - 4K
        $ server -S -R $((4<<10)) & client -S -R $((4<<10))
        593MiB/s
    
      So as you can see without openssl 16K is faster then 40K/4K, while for
      openssl 40K is still faster then 16K (I guess that this is due to with
      openssl SSL_read() more at time, while with plain we have some
      allocations splits in evbuffer and maybe due to some buffer in openssl)
    
    1.3. New backend for windows - wepoll
    
      wepoll is a epoll replacement on windows.
    
      wepoll features, from the official project page [1]:
      - Can poll 100000s of sockets efficiently.
      - Fully thread-safe.
      - Multiple threads can poll the same epoll port.
      - Sockets can be added to multiple epoll sets.
      - All epoll events (EPOLLIN, EPOLLOUT, EPOLLPRI, EPOLLRDHUP) are supported.
      - Level-triggered and one-shot (EPOLLONESTHOT) modes are supported
      - Trivial to embed: you need only two files.
    
        [1]: https://github.com/piscisaureus/wepoll
    
      The default backend on Windows is still select, just because it is well
      tested, and there is no other reasons. That said, that there is no know
      issues with wepoll, so please, use it and report any issues!
    
    1.4. Unix sockets under Windows
    
      Since Windows 10 there is support for unix domain sockets, and Libevent also
      supports this, via evutil_socketpair().
    
    1.5. Priority inheritance for pthreads
    
      Now you can use
      evthread_use_pthreads_with_flags(EVTHREAD_PTHREAD_PRIO_INHERIT) to use
      priority inheritance.
    
    1.6. signalfd support
    
      Linux-specific signal handling backend based on signalfd(2) system call, and
      public function event_base_get_signal_method() to obtain an underlying kernel
      signal handling mechanism.
    
    2. HTTP New APIs and features
    
    2.1. Support for custom HTTP methods
    
      Libevent HTTP code now supports defining custom HTTP methods. It is done
      through a callback:
    
        #define EVHTTP_REQ_CUSTOM      ((EVHTTP_REQ_MAX) << 1)
        static int ext_method_cb(struct evhttp_ext_method *p)
        {
          if (p == NULL)
            return -1;
          if (p->method) {
            if (strcmp(p->method, "CUSTOM") == 0) {
              p->type = EVHTTP_REQ_CUSTOM;
              p->flags = 0;   /*EVHTTP_METHOD_HAS_BODY*/
              return 0;
            }
          } else {
            if (p->type == EVHTTP_REQ_CUSTOM) {
              p->method = "CUSTOM";
              return 0;
            }
          }
        }
    
      And to register this callback with http server you can use:
        evhttp_set_ext_method_cmp(http, ext_method_cb);
    
      Or registering callback with one client only:
        evhttp_connection_set_ext_method_cmp(evcon, ext_method_cb);
    
    2.2. Separate timeouts for read/write/connect phase in HTTP
    
      New API:
    
      - client:
        evhttp_connection_set_connect_timeout_tv() -- for connect
        evhttp_connection_set_read_timeout_tv()    -- for read
        evhttp_connection_set_write_timeout_tv()   -- for write
    
      - server:
        evhttp_set_read_timeout_tv()  -- for read
        evhttp_set_write_timeout_tv() -- for write
    
      It also changes a logic a little, before there was next fallbacks which
      does not handled in new API:
      - HTTP_CONNECT_TIMEOUT
      - HTTP_WRITE_TIMEOUT
      - HTTP_READ_TIMEOUT
    
      And introduce another internal flag (EVHTTP_CON_TIMEOUT_ADJUSTED) that
      will be used in evrpc, which adjust evhttp_connection timeout only if it
      is not default.
    
    2.3. Add callback support for error pages
    
      Now there is evhttp_set_errorcb(), that could be used to change error pages
      of your http server.
    
      This can be used for multi lingual support, or to overcome some browser
      limitations (for example Microsoft Internet Explorer may display its own
      error pages if ones sent by an HTTP server are smaller than certain sizes)
    
    2.4. Minimal WebSocket server implementation for evhttp
    
      Adds few functions (for more details see event2/ws.h) to use evhttp-based
      webserver to handle incoming WebSockets connections. We've tried to use both
      libevent and libwebsockets in our application, but found that we need to have
      different ports at the same time to handle standard HTTP and WebSockets
      traffic. This change can help to stick only with libevent library.
    
      Implementation was inspired by modified Libevent source code in ipush project
      [1].
    
        [1]: https://github.com/sqfasd/ipush/tree/master/deps/libevent-2.0.21-stable
    
      Also, WebSocket-based chat server was added as a sample.
    
    2.5. evhttp_bound_set_bevcb()
    
      Like evhttp_set_bevcb(), but for evhttp_bound_socket, and callback of
      evhttp_set_bevcb() will not be called if evhttp_bound_set_bevcb() returns
      bufferevent.
    
    2.6. evhttp max simultaneous connection limiting
    
      When the max connection limit is enabled and the limit is reached, the server
      will respond immediately with 503 Service Unavailable. This can be used to
      prevent servers from running out of file descriptors. This is better than
      request limiting because clients may make more than one request over a single
      connection. Blocking a request does not necessarily close the connection and
      free up a socket.
    
      There are two new API:
    
      - evhttp_set_max_connections()
      - evhttp_get_connection_count()
    
    2.7. Support for Unix Domain Sockets in evhttp
    
      This can be done using evhttp_connection_base_bufferevent_unix_new()
    
      There are no standard for encoding a unix socket in an url. nginx uses:
    
          http://unix:/path/to/unix/socket:/httppath
    
      The second colon is needed to delimit where the unix path ends and where
      the rest of the url continues.
    
    3. Bufferevents
    
    3.1. SSL layer
    
      SSL layer has gained Mbed-TLS support, it is implemented in a different
      library - event_mbedtls (remember that for OpenSSL, event_openssl should be
      used).
    
      LibreSSL is also supported, but you don't need separate library for this,
      since LibreSSL is compatible with OpenSSL.
    
      The library known to work with OpenSSL 3.0 as well, though the performance
      with 3.0 is worser.
    
      Some changes in API, the following had been deprecated:
      - bufferevent_openssl_get_allow_dirty_shutdown()
      - bufferevent_openssl_set_allow_dirty_shutdown()
      - bufferevent_mbedtls_get_allow_dirty_shutdown()
      - bufferevent_mbedtls_set_allow_dirty_shutdown()
    
      And instead, the following should be used:
      - bufferevent_ssl_set_flags()
      - bufferevent_ssl_clear_flags()
      - bufferevent_ssl_get_flags()
    
      Also there is new flag BUFFEREVENT_SSL_BATCH_WRITE, that allows to avoid
      Nagle effect in SSL.
    
    4. DNS layer
    
    4.1. TCP support
    
      Libevent now has support for DNS requests via TCP.
    
      By default, requests are done via UDP. In case truncated response is received
      new attempt is done via TCP connection.
    
      2 new macros DNS_QUERY_USEVC and DNS_QUERY_IGNTC had been added to force all
      requests to be done via TCP and to disable switch to TCP in case of truncated
      responses.
    
      Possibility for DNS server to listen and receive requests on TCP port also
      had been added.
    
      Fallback to TCP in case of truncated DNS requests is done automatically.
      To imitate the old behaviour macros DNS_QUERY_IGNTC should be used. To
      force all DNS requests to be done via TCP one should use the flag
      DNS_QUERY_USEVC. Names DNS_QUERY_IGNTC, DNS_QUERY_USEVC were chosen to
      imitate similar flags in c-ares and glibc.
    
    4.2. New evdns options
    
      - evdns-udp-size - allows to configure maximum allowed size of UDP DNS
        messages
    
      - probe-backoff-factor - backoff factor of probe timeout
    
      - max-probe-timeout - maximum timeout between two probe packets will change
        initial-probe-timeout when this value is smaller
    
      And also evdns now can handle CNAME.
    
    4.3. evdns now has ability to not add default nameservers
    
      By default evdns adds "127.0.0.1" if there is no other nameservers.
    
      Two new options had been added:
    
      - DNS_OPTION_NAMESERVERS_NO_DEFAULT
    
        Do not "default" nameserver (i.e. "127.0.0.1:53") if there is no nameservers
        in resolv.conf, (iff DNS_OPTION_NAMESERVERS is set)
    
      - EVDNS_BASE_NAMESERVERS_NO_DEFAULT
    
        If EVDNS_BASE_INITIALIZE_NAMESERVERS isset, do not add default
        nameserver if there are no nameservers in resolv.conf (just set
        DNS_OPTION_NAMESERVERS_NO_DEFAULT internally)
    
    5. Listeners new flags
    
      - LEV_OPT_BIND_IPV6ONLY - bind only to IPv6
    
      - LEV_OPT_BIND_IPV4_AND_IPV6 -- bind to both to IPv4 and IPv6
    
    10. Building
    
    10.1. autotools is deprecated, use cmake
    
      Building with autotools/automake is considered as deprecated, instead, cmake
      is recommended.
    
      CMake is crossplatform so you don't need to support multiple files for
      various operation systems, like before.
    
      Libevent has find_package() support, and this is very flexible way of using
      the library in your project, since it is very easy to use even local builds
      (for more information read more about CMake User Registry).
    
    10.2. Building libevent as a sub-project using GNU Auto* tools
    
      Some projects will choose to include libevent in their source distribution,
      and build libevent as a sub-project.  This may be effected by putting the
      line:
    
       AC_CONFIG_SUBDIRS([path/to/libevent])
    
      in the master configure.ac file for the master project.
    
      There are cases where the master project will want to pass in additional
      flags for CFLAGS, CPPFLAGS, or LDFLAGS.  Since these variables are reserved
      for the user, and AM_CFLAGS, AM_CPPFLAGS, and AM_LDFLAGS are reserved for
      each package, libevent offers the following variables for a master package
      to tell libevent that there are additional compile/link values:
    
       LIBEVENT_CFLAGS
       LIBEVENT_CPPFLAGS
       LIBEVENT_LDFLAGS
    
      A master package can set these variables in its configure.ac file.
    
      Here's an example:
    
      configure.ac:
      ...
      EXTRA_CFLAGS=...
      EXTRA_CPPFLAGS=...
      EXTRA_LDFLAGS=...
      ...
      dnl ac_configure_args is undocumented but widely abused, as here,
      dnl to modify the defaults of the libevent subpackage, by prefixing
      dnl our changes to the child configure arguments already assembled.
      dnl User-supplied contradictory choices should prevail thanks to
      dnl "last wins".
      ac_configure_args=" --disable-openssl${ac_configure_args}"
      ac_configure_args=" --disable-shared${ac_configure_args}"
      ac_configure_args=" --disable-libevent-regress${ac_configure_args}"
      ac_configure_args=" --disable-libevent-install${ac_configure_args}"
      ac_configure_args=" --enable-silent-rules${ac_configure_args}"
      ac_configure_args=" --enable-function-sections${ac_configure_args}"
      ac_configure_args=" LIBEVENT_CFLAGS='${EXTRA_CFLAGS}'${ac_configure_args}"
      ac_configure_args=" LIBEVENT_CPPFLAGS='${EXTRA_CPPFLAGS}'${ac_configure_args}"
      ac_configure_args=" LIBEVENT_LDFLAGS='${EXTRA_LDFLAGS}'${ac_configure_args}"
      AC_CONFIG_SUBDIRS([libevent])
      ...
    
      The space after the initial '"' is significant.
    
    11. Continuous Integration
    
      Now Libevent uses github actions for CI, previously we had travis-ci for
      linux/macos and appveyor for win32 (removed in #951), and also I used testing
      vagrant for some time, but it had been moved into a separate repository
      (8c1838be). But actually this is not required anymore since github actions
      supports:
      - linux
      - freebsd
      - windows
      - osx
      - openbsd
      - and also tests under Thread/Address/Undefined sanitizers
    
      So no need to test something locally before releases.
    
      One thing that worth to mention, now, CI depends on public workers, and they
      are pretty limited, so it take some time to run the whole CI.
    
    12. Documentation
    
      Now documentation is automatically deployed to https://libevent.org/doc/