Broker 2.8.0 ============ - Add a new ``hub`` primitive that can be used to facilitate endpoint-local publish/subscribe use. Essentially, this is ``publisher`` and ``subscriber`` combined, but with visibility into all locally published messages except for those of the publishing hub. Broker 2.7.0 ============ - Fix a performance bug with metrics where a cluster with a large number (>64) of workers causes the manager to become overloaded and stop processing metrics. - Fragmented websocket frames are now correctly handled. Broker 2.6.0 ============ - Add new feature that allows users to retrieve a status report about the current state of Broker over HTTP in JSON format. This report gives a more detailed picture than the metrics do, including information about attached stores, the current connection state of a cluster, and more. The endpoint for retrieving this report is ``/v1/status/json`` on the same port used for metrics. - Fix a regression where the ``endpoint::peers()`` method was alwas returning a status of ``connected`` for all peers. This is most noticable with zeekctl when collecting and printing peer statuses. - Force static builds with the bundled version of CAF to ensure that all of the dependencies between the various CAF targets are met. Broker 2.5.0 ============ - Add interface include dirs to broker lib targets - Minimize messaging in sim_clock::advance_time - Update CAF submodule for SPCP buffer fix - Fix handling of peer/client errors - Implement graceful disconnect handshake - Add ``synchronous``, ``journal_mode``, ``failure_mode``, and ``integrity_check`` options to the SQLite store backend. - Fix to use IPv6 mode for accept sockets by default - Add support for using Zeek-style port/protocol notation as arguments - Add support for building with GCC 13. Broker 2.4.0 ============ - Fix CMake package file when bundling CAF - Fix a performance bottleneck in Broker-internal caching. - Improve performance with the ``stealing`` scheduler policy. - Fix messaging between clones and proxies that was resulting in an error message being reported. - Fix a bug that prevented Broker nodes to recover from OpenSSL errors. - Fix handling of buffer sizes that caused Broker to stall despite having sufficient capacity. - Add missing error signaling - Fix communication between Broker data stores. Broker 2.3.0 ============ - Broker now requires at least CMake version 3.15.0. - Internally, much of Broker's transport layer has been rearchitected for better maintainability and future functionality extensions. While this remains mostly invisible to users, the changes had to break backwards compability with older Broker versions. - Broker now offers access to its publish/subscribe layer via WebSocket in order to make its data model accessible to third parties without requiring access to Broker itself. A Broker endpoint can be configured to act as a WebSocket server by either setting the environment variable ``BROKER_WEB_SOCKET_PORT``; by setting ``broker.web-socket.port`` on the command line or in the configuration file; or programmatically by calling ``endpoint::web_socket_listen()``. See ``docs/web-socket.rst`` for more information. While still experimental for now, the WebSocket support (incl. the data model) aims to remain stable over time and will become the recommended way for external applications to talk to Broker applications (and hence Zeek). - The Python bindings now provide additional support for immutable (hashable) types. The ``SafeSubscriber`` class and the corresponding ``Endpoint.make_safe_subscriber()`` method ensure that immutable Python types get used, and that the returned values remain read-only. For sets the ``frozenset`` type achieves this; for mapping types it's ``types.MappingProxyType``. The API now also supports the latter two types as inputs. - All CAF dependencies have been removed from public headers, and we now build the bundled CAF version as a static, private utility. Consumers of Broker no longer need to locate CAF headers and we do not install any CAF content alongside Broker anymore, i.e., Broker becomes fully standalone. Where possible, Broker uses recent C++ additions like ``std::variant`` to replace CAF types. For types that have no equivalent, Broker deploys fully opaque handle types. For example, ``broker::worker`` internally wraps a ``caf::actor`` handle. All components in Broker that require access to CAF were grouped into the new namespace ``broker::internal``. We omit all internal headers from an installation, since they would be worthless without the matching CAF headers anyways. This also gives us a clean separation between API artifacts users may interact with and API parts that are reserved for internal use. Broker 2.2.0 ============ - The Python bindings now provide a SafeSubscriber variant of Subscriber as well as a new Endpoint.make_safe_subscriber() method. Both avoid potential problems when deserializing values that accommodate the Broker data model but not Python's. Specifically, Broker allows complex types inside others (e.g., a set of tables), but Python does not support unhashable types for indexing, which'd be required in this scenario. SafeSubscriber employs immutable (hashable) types when translating to Python objects and returns objects that are read-only. If you haven't encountered problems with the Subscriber class, you don't need to change existing code. Broker 3.0 will make this new behavior the default and deprecate the new APIs. In the meantime you can replace make_subscriber() with make_safe_subscriber() to be on the safe side. Broker 2.1.0 ============ - Broker 2.1.0 now depends on CAF 0.18.4 - The RocksDB data store backend was removed as building with it was previously broken/unusable. - Added the ability to output metrics to Prometheus. This can be enabled by setting the BROKER_METRICS_PORT environment variable. Currently the output includes a number of CAF-related metrics and per-process CPU and Memory metrics. Broker 2.0.0 ============ - Broker 2.0.0 now depends on CAF 0.18.0 with a wire format targeting compatibility with Zeek 4.0.x. - CMake 3.5+ is now required to compiler Broker. - Support for the optional Python Bindings now requires at least Python 3.5 - For proper resource management/cleanup, the Python API now requires using Endpoint, Subscriber, StatusSubscriber, and Store objects within a `with` statement or alternatively doing an explicit call to the `reset()` method of subscriber/store objects before the associated Endpoint's `shutdown()` method. Broker 1.4.0 ============ - Adds a new ``broker::store_event`` API that can be used to observe data store modifications. - Adds support for Windows platform. - RocksDB support is now opt-in instead of automatically detected and used at configuration-time. Use the ``--enable-rocksdb`` and ``--with-rocksdb=`` flags to opt-in. Broker 1.3.0 ============ - A C++17-capable compiler and CMake 3.0+ are now required to compile Broker - Broker 1.3.0 depends on CAF 0.17.4. Broker 1.2.x had depended on CAF 0.16.x, whose wire format changed and is now incompatible with CAF 0.17.x. Zeek 3.0.x shipped with Broker 1.2.x, which means Broker 1.3.x cannot be used to communicate with Zeek 3.0.x, only 3.1.x (and possibly later, check for updated release notes for compatibility clarifications). Broker 1.2.0 ============ This release contains breaking API changes (for C++ code, not Python) in order to increase messaging efficiency via reduction of data copying. Specifically: - ``broker::subscriber::get()`` now returns a different, copy-on-write type called ``broker::data_message`` rather than an ``std::pair``. For example this old code:: auto sub = ep.make_subscriber({"/topic/test"}); auto msg = sub.get(); auto& topic = msg.first; auto& data = msg.second can be changed to:: auto sub = ep.make_subscriber({"/topic/test"}); auto msg = sub.get(); auto& topic = broker::get_topic(msg); auto& data = broker::get_data(msg); - ``broker::endpoint::publish(vector)`` now takes a vector of the new ``broker::data_message`` type, not ``std::pair`` - Generally, all type aliases within classes, like ``value_type = std::pair``, have been changed to use the new ``broker::data_message`` type. - The semantics of message forwarding have changed slightly: the first sender of the message is now the one that applies the initial TTL value. Previously, the first receiver would be the one to apply the initial TTL.