1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/ipc/chromium/src/third_party/libevent/whatsnew-2.0.txt Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,609 @@
1.4 +What's New In Libevent 2.0 so far:
1.5 +
1.6 +1. Meta-issues
1.7 +
1.8 +1.1. About this document
1.9 +
1.10 + This document describes the key differences between Libevent 1.4 and
1.11 + Libevent 2.0, from a user's point of view. It was most recently
1.12 + updated based on features in git master as of August 2010.
1.13 +
1.14 + NOTE: I am very sure that I missed some thing on this list. Caveat
1.15 + haxxor.
1.16 +
1.17 +1.2. Better documentation
1.18 +
1.19 + There is now a book-in-progress that explains how to use Libevent and its
1.20 + growing pile of APIs. As of this writing, it covers everything except the
1.21 + http and rpc code. Check out the latest draft at
1.22 + http://www.wangafu.net/~nickm/libevent-book/ .
1.23 +
1.24 +2. New and Improved Event APIs
1.25 +
1.26 + Many APIs are improved, refactored, or deprecated in Libevent 2.0.
1.27 +
1.28 + COMPATIBILITY:
1.29 +
1.30 + Nearly all existing code that worked with Libevent 1.4 should still
1.31 + work correctly with Libevent 2.0. However, if you are writing new code,
1.32 + or if you want to port old code, we strongly recommend using the new APIs
1.33 + and avoiding deprecated APIs as much as possible.
1.34 +
1.35 + Binaries linked against Libevent 1.4 will need to be recompiled to link
1.36 + against Libevent 2.0. This is nothing new; we have never been good at
1.37 + preserving binary compatibility between releases. We'll try harder in the
1.38 + future, though: see 2.1 below.
1.39 +
1.40 +2.1. New header layout for improved forward-compatibility
1.41 +
1.42 + Libevent 2.0 has a new header layout to make it easier for programmers to
1.43 + write good, well-supported libevent code. The new headers are divided
1.44 + into three types.
1.45 +
1.46 + There are *regular headers*, like event2/event.h. These headers contain
1.47 + the functions that most programmers will want to use.
1.48 +
1.49 + There are *backward compatibility headers*, like event2/event_compat.h.
1.50 + These headers contain declarations for deprecated functions from older
1.51 + versions of Libevent. Documentation in these headers should suggest what's
1.52 + wrong with the old functions, and what functions you want to start using
1.53 + instead of the old ones. Some of these functions might be removed in a
1.54 + future release. New programs should generally not include these headers.
1.55 +
1.56 + Finally, there are *structure headers*, like event2/event_struct.h.
1.57 + These headers contain definitions of some structures that Libevent has
1.58 + historically exposed. Exposing them caused problems in the past,
1.59 + since programs that were compiled to work with one version of Libevent
1.60 + would often stop working with another version that changed the size or
1.61 + layout of some object. We've moving them into separate headers so
1.62 + that programmers can know that their code is not depending on any
1.63 + unstable aspect of the Libvent ABI. New programs should generally not
1.64 + include these headers unless they really know what they are doing, are
1.65 + willing to rebuild their software whenever they want to link it
1.66 + against a new version of Libevent, and are willing to risk their code
1.67 + breaking if and when data structures change.
1.68 +
1.69 + Functionality that once was located in event.h is now more subdivided.
1.70 + The core event logic is now in event2/event.h. The "evbuffer" functions
1.71 + for low-level buffer manipulation are in event2/buffer.h. The
1.72 + "bufferevent" functions for higher-level buffered IO are in
1.73 + event2/bufferevent.h.
1.74 +
1.75 + COMPATIBILITY:
1.76 +
1.77 + All of the old headers (event.h, evdns.h, evhttp.h, evrpc.h, and
1.78 + evutil.h) will continue to work by including the corresponding new
1.79 + headers. Old code should not be broken by this change.
1.80 +
1.81 +2.2. New thread-safe, binary-compatible, harder-to-mess-up APIs
1.82 +
1.83 + Some aspects of the historical Libevent API have encouraged
1.84 + non-threadsafe code, or forced code built against one version of Libevent
1.85 + to no longer build with another. The problems with now-deprecated APIs
1.86 + fell into two categories:
1.87 +
1.88 + 1) Dependence on the "current" event_base. In an application with
1.89 + multiple event_bases, Libevent previously had a notion of the
1.90 + "current" event_base. New events were linked to this base, and
1.91 + the caller needed to explicitly reattach them to another base.
1.92 + This was horribly error-prone.
1.93 +
1.94 + Functions like "event_set" that worked with the "current" event_base
1.95 + are now deprecated but still available (see 2.1). There are new
1.96 + functions like "event_assign" that take an explicit event_base
1.97 + argument when setting up a structure. Using these functions will help
1.98 + prevent errors in your applications, and to be more threadsafe.
1.99 +
1.100 + 2) Structure dependence. Applications needed to allocate 'struct
1.101 + event' themselves, since there was no function in Libevent to do it
1.102 + for them. But since the size and contents of struct event can
1.103 + change between libevent versions, this created binary-compatibility
1.104 + nightmares. All structures of this kind are now isolated in
1.105 + _struct.h header (see 2.1), and there are new allocate-and-
1.106 + initialize functions you can use instead of the old initialize-only
1.107 + functions. For example, instead of malloc and event_set, you
1.108 + can use event_new().
1.109 +
1.110 + (For people who do really want to allocate a struct event on the
1.111 + stack, or put one inside another structure, you can still use
1.112 + event2/event_compat.h.)
1.113 +
1.114 + So in the case where old code would look like this:
1.115 +
1.116 + #include <event.h>
1.117 + ...
1.118 + struct event *ev = malloc(sizeof(struct event));
1.119 + /* This call will cause a buffer overrun if you compile with one version
1.120 + of Libevent and link dynamically against another. */
1.121 + event_set(ev, fd, EV_READ, cb, NULL);
1.122 + /* If you forget this call, your code will break in hard-to-diagnose
1.123 + ways in the presence of multiple event bases. */
1.124 + event_set_base(ev, base);
1.125 +
1.126 + New code will look more like this:
1.127 +
1.128 + #include <event2/event.h>
1.129 + ...
1.130 + struct event *ev;
1.131 + ev = event_new(base, fd, EV_READ, cb, NULL);
1.132 +
1.133 +2.3. Overrideable allocation functions
1.134 +
1.135 + If you want to override the allocation functions used by libevent
1.136 + (for example, to use a specialized allocator, or debug memory
1.137 + issues, or so on), you can replace them by calling
1.138 + event_set_mem_functions. It takes replacements for malloc(),
1.139 + free(), and realloc().
1.140 +
1.141 + If you're going to use this facility, you need to call it _before_
1.142 + Libevent does any memory allocation; otherwise, Libevent may allocate some
1.143 + memory with malloc(), and free it with the free() function you provide.
1.144 +
1.145 + You can disable this feature when you are building Libevent by passing
1.146 + the --disable-malloc-replacement argument to configure.
1.147 +
1.148 +2.4. Configurable event_base creation
1.149 +
1.150 + Older versions of Libevent would always got the fastest backend
1.151 + available, unless you reconfigured their behavior with the environment
1.152 + variables EVENT_NOSELECT, EVENT_NOPOLL, and so forth. This was annoying
1.153 + to programmers who wanted to pick a backend explicitly without messing
1.154 + with the environment.
1.155 +
1.156 + Also, despite our best efforts, not every backend supports every
1.157 + operation we might like. Some features (like edge-triggered events, or
1.158 + working with non-socket file descriptors) only work with some operating
1.159 + systems' fast backends. Previously, programmers who cared about this
1.160 + needed to know which backends supported what. This tended to get quite
1.161 + ungainly.
1.162 +
1.163 + There is now an API to choose backends, either by name or by feature.
1.164 + Here is an example:
1.165 +
1.166 + struct event_config_t *config;
1.167 + struct event_base *base;
1.168 +
1.169 + /* Create a new configuration object. */
1.170 + config = event_config_new();
1.171 + /* We don't want to use the "select" method. */
1.172 + event_config_avoid_method(config, "select");
1.173 + /* We want a method that can work with non-socket file descriptors */
1.174 + event_config_require_features(config, EV_FEATURE_FDS);
1.175 +
1.176 + base = event_base_new_with_config(config);
1.177 + if (!base) {
1.178 + /* There is no backend method that does what we want. */
1.179 + exit(1);
1.180 + }
1.181 + event_config_free(config);
1.182 +
1.183 + Supported features are documented in event2/event.h
1.184 +
1.185 +2.5. Socket is now an abstract type
1.186 +
1.187 + All APIs that formerly accepted int as a socket type now accept
1.188 + "evutil_socket_t". On Unix, this is just an alias for "int" as
1.189 + before. On Windows, however, it's an alias for SOCKET, which can
1.190 + be wider than int on 64-bit platforms.
1.191 +
1.192 +2.6. Timeouts and persistent events work together.
1.193 +
1.194 + Previously, it wasn't useful to set a timeout on a persistent event:
1.195 + the timeout would trigger once, and never again. This is not what
1.196 + applications tend to want. Instead, applications tend to want every
1.197 + triggering of the event to re-set the timeout. So now, if you set
1.198 + up an event like this:
1.199 + struct event *ev;
1.200 + struct timeval tv;
1.201 + ev = event_new(base, fd, EV_READ|EV_PERSIST, cb, NULL);
1.202 + tv.tv_sec = 1;
1.203 + tv.tv_usec = 0;
1.204 + event_add(ev, &tv);
1.205 +
1.206 + The callback 'cb' will be invoked whenever fd is ready to read, OR whenever
1.207 + a second has passed since the last invocation of cb.
1.208 +
1.209 +2.7. Multiple events allowed per fd
1.210 +
1.211 + Older versions of Libevent allowed at most one EV_READ event and at most
1.212 + one EV_WRITE event per socket, per event base. This restriction is no
1.213 + longer present.
1.214 +
1.215 +2.8. evthread_* functions for thread-safe structures.
1.216 +
1.217 + Libevent structures can now be built with locking support. This code
1.218 + makes it safe to add, remove, and activate events on an event base from a
1.219 + different thread. (Previously, if you wanted to write multithreaded code
1.220 + with Libevent, you could only an event_base or its events in one thread at
1.221 + a time.)
1.222 +
1.223 + If you want threading support and you're using pthreads, you can just
1.224 + call evthread_use_pthreads(). (You'll need to link against the
1.225 + libevent_pthreads library in addition to libevent_core. These functions are
1.226 + not in libevent_core.)
1.227 +
1.228 + If you want threading support and you're using Windows, you can just
1.229 + call evthread_use_windows_threads().
1.230 +
1.231 + If you are using some locking system besides Windows and pthreads, You
1.232 + can enable this on a per-event-base level by writing functions to
1.233 + implement mutexes, conditions, and thread IDs, and passing them to
1.234 + evthread_set_lock_callbacks and related functions in event2/thread.h.
1.235 +
1.236 + Once locking functions are enabled, every new event_base is created with a
1.237 + lock. You can prevent a single event_base from being built with a lock
1.238 + disabled by using the EVENT_BASE_FLAG_NOLOCK flag in its
1.239 + event_config. If an event_base is created with a lock, it is safe to call
1.240 + event_del, event_add, and event_active on its events from any thread. The
1.241 + event callbacks themselves are still all executed from the thread running
1.242 + the event loop.
1.243 +
1.244 + To make an evbuffer or a bufferevent object threadsafe, call its
1.245 + *_enable_locking() function.
1.246 +
1.247 + The HTTP api is not currently threadsafe.
1.248 +
1.249 + To build Libevent with threading support disabled, pass
1.250 + --disable-thread-support to the configure script.
1.251 +
1.252 +2.9. Edge-triggered events on some backends.
1.253 +
1.254 + With some backends, it's now possible to add the EV_ET flag to an event
1.255 + in order to request that the event's semantics be edge-triggered. Right
1.256 + now, epoll and kqueue support this.
1.257 +
1.258 + The corresponding event_config feature is EV_FEATURE_ET; see 2.4 for more
1.259 + information.
1.260 +
1.261 +2.10. Better support for huge numbers of timeouts
1.262 +
1.263 + The heap-based priority queue timer implementation for Libevent 1.4 is good
1.264 + for randomly distributed timeouts, but suboptimal if you have huge numbers
1.265 + of timeouts that all expire in the same amount of time after their
1.266 + creation. The new event_base_init_common_timeout() logic lets you signal
1.267 + that a given timeout interval will be very common, and should use a linked
1.268 + list implementation instead of a priority queue.
1.269 +
1.270 +2.11. Improved debugging support
1.271 +
1.272 + It's been pretty easy to forget to delete all your events before you
1.273 + re-initialize them, or otherwise put Libevent in an internally inconsistent
1.274 + state. You can tell libevent to catch these and other common errors with
1.275 + the new event_enable_debug_mode() call. Just invoke it before you do
1.276 + any calls to other libevent functions, and it'll catch many common
1.277 + event-level errors in your code.
1.278 +
1.279 +2.12. Functions to access all event fields
1.280 +
1.281 + So that you don't have to access the struct event fields directly, Libevent
1.282 + now provides accessor functions to retrieve everything from an event that
1.283 + you set during event_new() or event_assign().
1.284 +
1.285 +3. Backend-specific and performance improvements.
1.286 +
1.287 +3.1. Change-minimization on O(1) backends
1.288 +
1.289 + With previous versions of Libevent, if you called event_del() and
1.290 + event_add() repeatedly on a single event between trips to the backend's
1.291 + dispatch function, the backend might wind up making unnecessary calls or
1.292 + passing unnecessary data to the kernel. The new backend logic batches up
1.293 + redundant adds and deletes, and performs no more operations than necessary
1.294 + at the kernel level.
1.295 +
1.296 + This logic is on for the kqueue backend, and available (but off by
1.297 + default) for the epoll backend. To turn it on for the epoll backend,
1.298 + set the EVENT_BASE_FLAG_EPOLL_USE_CHANGELIST flag in the
1.299 + event_base_cofig, or set the EVENT_EPOLL_USE_CHANGELIST environment
1.300 + variable. Doing this with epoll may result in weird bugs if you give
1.301 + any fds closed by dup() or its variants.
1.302 +
1.303 +3.2. Improved notification on Linux
1.304 +
1.305 + When we need to wake the event loop up from another thread, we use
1.306 + an epollfd to do so, instead of a socketpair. This is supposed to be
1.307 + faster.
1.308 +
1.309 +3.3. Windows: better support for everything
1.310 +
1.311 + Bufferevents on Windows can use a new mechanism (off-by-default; see below)
1.312 + to send their data via Windows overlapped IO and get their notifications
1.313 + via the IOCP API. This should be much faster than using event-based
1.314 + notification.
1.315 +
1.316 + Other functions throughout the code have been fixed to work more
1.317 + consistently with Windows. Libevent now builds on Windows using either
1.318 + mingw, or using MSVC (with nmake). Libevent works fine with UNICODE
1.319 + defined, or not.
1.320 +
1.321 + Data structures are a little smarter: our lookups from socket to pending
1.322 + event are now done with O(1) hash tables rather than O(lg n) red-black
1.323 + trees.
1.324 +
1.325 + Unfortunately, the main Windows backend is still select()-based: from
1.326 + testing the IOCP backends on the mailing list, it seems that there isn't
1.327 + actually a way to tell for certain whether a socket is writable with IOCP.
1.328 + Libevent 2.1 may add a multithreaded WaitForMultipleEvents-based
1.329 + backend for better performance with many inactive sockets and better
1.330 + integration with Windows events.
1.331 +
1.332 +4. Improvements to evbuffers
1.333 +
1.334 + Libevent has long had an "evbuffer" implementation to wrap access to an
1.335 + input or output memory buffer. In previous versions, the implementation
1.336 + was very inefficient and lacked some desirable features. We've made many
1.337 + improvements in Libevent 2.0.
1.338 +
1.339 +4.1. Chunked-memory internal representation
1.340 +
1.341 + Previously, each evbuffer was a huge chunk of memory. When we ran out of
1.342 + space in an evbuffer, we used realloc() to grow the chunk of memory. When
1.343 + data was misaligned, we used memmove to move the data back to the front
1.344 + of the buffer.
1.345 +
1.346 + Needless to say, this is a terrible interface for networked IO.
1.347 +
1.348 + Now, evbuffers are implemented as a linked list of memory chunks, like
1.349 + most Unix kernels use for network IO. (See Linux's skbuf interfaces,
1.350 + or *BSD's mbufs). Data is added at the end of the linked list and
1.351 + removed from the front, so that we don't ever need realloc huge chunks
1.352 + or memmove the whole buffer contents.
1.353 +
1.354 + To avoid excessive calls to read and write, we use the readv/writev
1.355 + interfaces (or WSASend/WSARecv on Windows) to do IO on multiple chunks at
1.356 + once with a single system call.
1.357 +
1.358 + COMPATIBILITY NOTE:
1.359 + The evbuffer struct is no longer exposed in a header. The code here is
1.360 + too volatile to expose an official evbuffer structure, and there was never
1.361 + any means provided to create an evbuffer except via evbuffer_new which
1.362 + heap-allocated the buffer.
1.363 +
1.364 + If you need access to the whole bufer as a linear chunk of memory, the
1.365 + EVBUFFER_DATA() function still works. Watch out, though: it needs to copy
1.366 + the buffer's contents in a linear chunk before you can use it.
1.367 +
1.368 +4.2. More flexible readline support
1.369 +
1.370 + The old evbuffer_readline() function (which accepted any sequence of
1.371 + CR and LF characters as a newline, and which couldn't handle lines
1.372 + containing NUL characters), is now deprecated. The preferred
1.373 + function is evbuffer_readln(), which supports a variety of
1.374 + line-ending styles, and which can return the number of characters in
1.375 + the line returned.
1.376 +
1.377 + You can also call evbuffer_search_eol() to find the end of a line
1.378 + in an evbuffer without ever extracting the line.
1.379 +
1.380 +4.3. Support for file-based IO in evbuffers.
1.381 +
1.382 + You can now add chunks of a file into a evbuffer, and Libevent will have
1.383 + your OS use mapped-memory functionality, sendfile, or splice to transfer
1.384 + the data without ever copying it to userspace. On OSs where this is not
1.385 + supported, Libevent just loads the data.
1.386 +
1.387 + There are probably some bugs remaining in this code. On some platforms
1.388 + (like Windows), it just reads the relevant parts of the file into RAM.
1.389 +
1.390 +4.4. Support for zero-copy ("scatter/gather") writes in evbuffers.
1.391 +
1.392 + You can add a piece of memory to an evbuffer without copying it.
1.393 + Instead, Libevent adds a new element to the evbuffer's linked list of
1.394 + chunks with a pointer to the memory you supplied. You can do this
1.395 + either with a reference-counted chunk (via evbuffer_add_reference), or
1.396 + by asking Libevent for a pointer to its internal vectors (via
1.397 + evbuffer_reserve_space or evbuffer_peek()).
1.398 +
1.399 +4.5. Multiple callbacks per evbuffer
1.400 +
1.401 + Previously, you could only have one callback active on an evbuffer at a
1.402 + time. In practice, this meant that if one part of Libevent was using an
1.403 + evbuffer callback to notice when an internal evbuffer was reading or
1.404 + writing data, you couldn't have your own callback on that evbuffer.
1.405 +
1.406 + Now, you can now use the evbuffer_add_cb() function to add a callback that
1.407 + does not interfere with any other callbacks.
1.408 +
1.409 + The evbuffer_setcb() function is now deprecated.
1.410 +
1.411 +4.6. New callback interface
1.412 +
1.413 + Previously, evbuffer callbacks were invoked with the old size of the
1.414 + buffer and the new size of the buffer. This interface could not capture
1.415 + operations that simultaneously filled _and_ drained a buffer, or handle
1.416 + cases where we needed to postpone callbacks until multiple operations were
1.417 + complete.
1.418 +
1.419 + Callbacks that are set with evbuffer_setcb still use the old API.
1.420 + Callbacks added with evbuffer_add_cb() use a new interface that takes a
1.421 + pointer to a struct holding the total number of bytes drained read and the
1.422 + total number of bytes written. See event2/buffer.h for full details.
1.423 +
1.424 +4.7. Misc new evbuffer features
1.425 +
1.426 + You can use evbuffer_remove() to move a given number of bytes from one
1.427 + buffer to another.
1.428 +
1.429 + The evbuffer_search() function lets you search for repeated instances of
1.430 + a pattern inside an evbuffer.
1.431 +
1.432 + You can use evbuffer_freeze() to temporarily suspend drains from or adds
1.433 + to a given evbuffer. This is useful for code that exposes an evbuffer as
1.434 + part of its public API, but wants users to treat it as a pure source or
1.435 + sink.
1.436 +
1.437 + There's an evbuffer_copyout() that looks at the data at the start of an
1.438 + evbuffer without doing a drain.
1.439 +
1.440 + You can have an evbuffer defer all of its callbacks, so that rather than
1.441 + being invoked immediately when the evbuffer's length changes, they are
1.442 + invoked from within the event_loop. This is useful when you have a
1.443 + complex set of callbacks that can change the length of other evbuffers,
1.444 + and you want to avoid having them recurse and overflow your stack.
1.445 +
1.446 +5. Bufferevents improvements
1.447 +
1.448 + Libevent has long included a "bufferevents" structure and related
1.449 + functions that were useful for generic buffered IO on a TCP connection.
1.450 + This is what Libevent uses for its HTTP implementation. In addition to
1.451 + the improvements that they get for free from the underlying evbuffer
1.452 + implementation above, there are many new features in Libevent 2.0's
1.453 + evbuffers.
1.454 +
1.455 +5.1. New OO implementations
1.456 +
1.457 + The "bufferevent" structure is now an abstract base type with multiple
1.458 + implementations. This should not break existing code, which always
1.459 + allocated bufferevents with bufferevent_new().
1.460 +
1.461 + Current implementations of the bufferevent interface are described below.
1.462 +
1.463 +5.2. bufferevent_socket_new() replaces bufferevent_new()
1.464 +
1.465 + Since bufferevents that use a socket are not the only kind,
1.466 + bufferevent_new() is now deprecated. Use bufferevent_socket_new()
1.467 + instead.
1.468 +
1.469 +5.3. Filtered bufferevent IO
1.470 +
1.471 + You can use bufferevent_filter_new() to create a bufferevent that wraps
1.472 + around another bufferevent and transforms data it is sending and
1.473 + receiving. See test/regress_zlib.c for a toy example that uses zlib to
1.474 + compress data before sending it over a bufferevent.
1.475 +
1.476 +5.3. Linked pairs of bufferevents
1.477 +
1.478 + You can use bufferevent_pair_new() to produce two linked
1.479 + bufferevents. This is like using socketpair, but doesn't require
1.480 + system-calls.
1.481 +
1.482 +5.4. SSL support for bufferevents with OpenSSL
1.483 +
1.484 + There is now a bufferevent type that supports SSL/TLS using the
1.485 + OpenSSL library. The code for this is build in a separate
1.486 + library, libevent_openssl, so that your programs don't need to
1.487 + link against OpenSSL unless they actually want SSL support.
1.488 +
1.489 + There are two ways to construct one of these bufferevents, both
1.490 + declared in <event2/bufferevent_ssl.h>. If you want to wrap an
1.491 + SSL layer around an existing bufferevent, you would call the
1.492 + bufferevent_openssl_filter_new() function. If you want to do SSL
1.493 + on a socket directly, call bufferevent_openssl_socket_new().
1.494 +
1.495 +5.5. IOCP support for bufferevents on Windows
1.496 +
1.497 + There is now a bufferevents backend that supports IOCP on Windows.
1.498 + Supposedly, this will eventually make Windows IO much faster for
1.499 + programs using bufferevents. We'll have to see; the code is not
1.500 + currently optimized at all. To try it out, call the
1.501 + event_base_start_iocp() method on an event_base before contructing
1.502 + bufferevents.
1.503 +
1.504 + This is tricky code; there are probably some bugs hiding here.
1.505 +
1.506 +5.6. Improved connect support for bufferevents.
1.507 +
1.508 + You can now create a bufferevent that is not yet connected to any
1.509 + host, and tell it to connect, either by address or by hostname.
1.510 +
1.511 + The functions to do this are bufferevent_socket_connect and
1.512 + bufferevent_socket_connect_hostname.
1.513 +
1.514 +5.7. Rate-limiting for bufferevents
1.515 +
1.516 + If you need to limit the number of bytes read/written by a single
1.517 + bufferevent, or by a group of them, you can do this with a new set of
1.518 + bufferevent rate-limiting calls.
1.519 +
1.520 +6. Other improvements
1.521 +
1.522 +6.1. DNS improvements
1.523 +
1.524 +6.1.1. DNS: IPv6 nameservers
1.525 +
1.526 + The evdns code now lets you have nameservers whose addresses are IPv6.
1.527 +
1.528 +6.1.2. DNS: Better security
1.529 +
1.530 + Libevent 2.0 tries harder to resist DNS answer-sniping attacks than
1.531 + earlier versions of evdns. See comments in the code for full details.
1.532 +
1.533 + Notably, evdns now supports the "0x20 hack" to make it harder to
1.534 + impersonate a DNS server. Additionally, Libevent now uses a strong
1.535 + internal RNG to generate DNS transaction IDs, so you don't need to supply
1.536 + your own.
1.537 +
1.538 +6.1.3. DNS: Getaddrinfo support
1.539 +
1.540 + There's now an asynchronous getaddrinfo clone, evdns_getaddrinfo(),
1.541 + to make the results of the evdns functions more usable. It doesn't
1.542 + support every feature of a typical platform getaddrinfo() yet, but it
1.543 + is quite close.
1.544 +
1.545 + There is also a blocking evutil_getaddrinfo() declared in
1.546 + event2/util.h, to provide a getaddrinfo() implementation for
1.547 + platforms that don't have one, and smooth over the differences in
1.548 + various platforms implementations of RFC3493.
1.549 +
1.550 + Bufferevents provide bufferevent_connect_hostname(), which combines
1.551 + the name lookup and connect operations.
1.552 +
1.553 +6.1.4. DNS: No more evdns globals
1.554 +
1.555 + Like an event base, evdns operations are now supposed to use an evdns_base
1.556 + argument. This makes them easier to wrap for other (more OO) languages,
1.557 + and easier to control the lifetime of. The old evdns functions will
1.558 + still, of course, continue working.
1.559 +
1.560 +6.2. Listener support
1.561 +
1.562 + You can now more easily automate setting up a bound socket to listen for
1.563 + TCP connections. Just use the evconnlistener_*() functions in the
1.564 + event2/listener.h header.
1.565 +
1.566 + The listener code supports IOCP on Windows if available.
1.567 +
1.568 +6.3. Secure RNG support
1.569 +
1.570 + Network code very frequently needs a secure, hard-to-predict random number
1.571 + generator. Some operating systems provide a good C implementation of one;
1.572 + others do not. Libevent 2.0 now provides a consistent implementation
1.573 + based on the arc4random code originally from OpenBSD. Libevent (and you)
1.574 + can use the evutil_secure_rng_*() functions to access a fairly secure
1.575 + random stream of bytes.
1.576 +
1.577 +6.4. HTTP
1.578 +
1.579 + The evhttp uriencoding and uridecoding APIs have updated versions
1.580 + that behave more correctly, and can handle strings with internal NULs.
1.581 +
1.582 + The evhttp query parsing and URI parsing logic can now detect errors
1.583 + more usefully. Moreover, we include an actual URI parsing function
1.584 + (evhttp_uri_parse()) to correctly parse URIs, so as to discourage
1.585 + people from rolling their own ad-hoc parsing functions.
1.586 +
1.587 + There are now accessor functions for the useful fields of struct http
1.588 + and friends; it shouldn't be necessary to access them directly any
1.589 + more.
1.590 +
1.591 + Libevent now lets you declare support for all specified HTTP methods,
1.592 + including OPTIONS, PATCH, and so on. The default list is unchanged.
1.593 +
1.594 + Numerous evhttp bugs also got fixed.
1.595 +
1.596 +7. Infrastructure improvements
1.597 +
1.598 +7.1. Better unit test framework
1.599 +
1.600 + We now use a unit test framework that Nick wrote called "tinytest".
1.601 + The main benefit from Libevent's point of view is that tests which
1.602 + might mess with global state can all run each in their own
1.603 + subprocess. This way, when there's a bug that makes one unit test
1.604 + crash or mess up global state, it doesn't affect any others.
1.605 +
1.606 +7.2. Better unit tests
1.607 +
1.608 + Despite all the code we've added, our unit tests are much better than
1.609 + before. Right now, iterating over the different backends on various
1.610 + platforms, I'm getting between 78% and 81% test coverage, compared
1.611 + with less than 45% test coverage in Libevent 1.4.
1.612 +
