# Change Log The format is based on [Keep a Changelog](http://keepachangelog.com/). This project will adhere to [Semantic Versioning](http://semver.org/), following the release of version 1.0.0. ## [Unreleased] - ReleaseDate Eliminated the Baggage API- store associated metadata some other way. If it's really necessary, `provide_any` will be implemented atop Tunnel. Upgraded Fred to 6.0.0-beta.2 for support of clustered TLS Redis. This will be changed to 6.0 when a non-prerelease build is available. Upgraded Quinn to 9.3 for UDP GSO and UDP GRO support; this update broke several internal API assumptions and may lead to further simplifications around incoming connection and (bi/uni)stream handling. ## [0.7.0] - 2022-10-29 ### Hybrid Eventually-Consistent Tunnel Repositories (0.6.0-alpha.1) Tunnels are now considered "snocat tunnels" immediately after connection, and their metadata is now an immutable `HashMap>`. The "Baggage" trait still exists, but is deprecated for future removal. `ModularDaemon` now provides tokio::sync::Broadcast-based event subscriptions which can be used for monitoring of tunnel lifecycles. These are not guaranteed-reliable- any listeners that lag too far behind may miss a message if the buffer fills before they are processed; Such misses will notify with a "Lagged" error on the receiver-side. To avoid this, ensure that a task processes messages as soon as possible and pushes them into a work queue as-needed with minimal processing, and that work is handled on a separate task. Tunnels are now registered to the provided `TunnelRegistry` only after they have authenticated successfully. Tunnels which fail authentication are never considered "registered", and thus never enter the registry or process requests. This is a change from the prior model which allowed a tunnel's registry record to be mutated post-write. Mutation is allowed via the `SharedAttributeRegistry` trait but no provided reference registry implements this functionality. A CRDT-based table could feasibly allow distributed, eventually consistent mutability of attributes in the future, but the design is in flux. #### Reduction of Registry content Tunnel Registries now purely track externally-viewable tunnel state, instead of tracking a local-and-remote set of items; Stored entries are allowed to be out-of-date, which reduces consistency requirements to allow for use of non-transactional databases. A Redis implementation is provided which allows for "last-named-wins" semantics of tunnel registration via feature flag `redis-store`. This may be placed behind caching layers to allow for reduced registrations, but the provided cache - recursively defined as a registry composing two others - lacks some ID semantics needed for proper, timely cleanup of cached resource instances. Integration tests can be run with `./.scripts/run-integration-tests.sh` or providing `integration-redis` as a feature flag during test execution. An in-memory implementation based upon DashMap is provided which has the same last-entry-wins semantics as the Redis implementation in order to facilitate database mocking in integration testing. #### Daemon Peer Tracking A new, guaranteed-locally-consistent in-memory store of tunnels now handles tunnels active within the current daemon context. This is exposed as a read-only view via the `ModularDaemon::peers(&self)` method, with the implementation mechanism hidden behind a set of accessors on `PeersView`. Tunnels are tracked only after name registration, and are inserted or removed prior to the asynchronous calls for Registry updates. Tunnels which fail authentication never reach a "registered" state and are thus never included in the peer tracker nor the `TunnelRegistry`. #### Inner Loop Simplification Tunnel lifecycle handling code within `ModularDaemon` has been dramatically simplified: Generic `TTunnel` on ModularDaemon has been moved to a generic parameter upon the `ModularDaemon::run` method, and internal functions are parameterized upon it. An RAII wrapper utilizing `DropKick` now provides deregistration and closure of tunnels instead of intercepting potential exit points, as [AsyncDrop](https://rust-lang.github.io/async-fundamentals-initiative/roadmap/async_drop.html) is still in the preliminary planning stages by the associated Rust initiative. This allows us to encode deregistration logic within the wrapper type, ensuring that the daemon does not miss a path so long as the compiler itself is correct. #### Service and ServiceRegistry modifications `Service` and `ServiceRegistry` now work with instances of (or references to) `ArcTunnel` in lieu of `TunnelId`. `MappedService` is now a `struct` instead of a `trait`, and acts as a wrapper type which implements `Service` by mapping the result to a phantom type stored on the instance. Remapping from one mapped type to another can be performed with `MappedService::new(MappedService::into_inner(s))`. `Service` is now implemented for the following reference types: - `&S` - `&mut S` - `Box` - `Rc` - `Arc` ## [0.5.0-alpha.6] - 2022-03-04 ### Generic Tunnel Registries and Services The majority of `ModularDaemon` module types have switched from dynamic to generic dispatch. If you still require dynamic dispatch, you may continue to use it, but associated types will need to be specified depending on which module is being implemented, though effort has been made to allow boxing of the `TunnelRegistry`'s associated types via `Any`. #### Associated Errors This genericization change also comes with benefits to library users' error handling: Several types now include `Error` associated types, which allow specification of implementation-specific error types for the various modules. `Service` is now accessed via `MappedService`, which handles translation from `Service`-specific `Error` types to those known by an owning `ServiceRegistry`. This allows `Service` instances to- for example- use `thiserror` to describe internal failure classes, while an application's `ServiceRegistry` could use `anyhow::Error`, automatically translating to the registry's error types in the process. The implementor of the `ServiceRegistry` could, alternatively, make an error type specific to their implementation, and implement `From` for the `Error` types of each service they expect to support. General "mapping" behaviour is intended to be supported later, but trait changes will likely follow, so avoid tight coupling with the current structure of `MappedService`. #### `TunnelRegistry` behavioural changes Tunnel Registries can now track tunnels to which they do not have reference access. This is meant to allow for registries which span multiple processes or machines, wherein a Tunnel can be known but not owned by the current registry instance. A registry should, in general, only have access to - or alter - tunnels it owns. ### Tunnel unification refactoring Tunnel is now a hybrid trait of uplink and downlink. `TunnelUplink` and `TunnelDownlink` are traits, and sidedness is split off into its own trait. The hybrid tunnel allows any number of accesses to the incoming stream, but they are exclusive, and will await an async Mutex- possibly until the tunnel in question has been closed. Tunnel traits now exist which specify behaviour for monitoring link closure events, and a means of forcing closure of a tunnel on command. This behaviour is currently only implemented for `QuinnTunnel`. Tunnels implement a new "Baggage" trait which allows attachment of arbitrary data to tunnel types, shared between all handles to that tunnel instance. This data is not networked, and is dropped with the last tunnel handle. _It is strictly illegal to store a tunnel handle in any tunnel's baggage_. ### Daemon System Revamped networking system to use a `ModularDaemon` for both client and server management. The Protocol is now P2P-capable and uses connection sidedness rather than server or client identity. ### Miscellaneous - `Dropkick` utility added for drop notifications. - Dependency `triggered` dropped in favor of `tokio_util::sync::CancellationToken`. - `ModularDaemon` has been moved from `snocat::server::modular` to `snocat::common::daemon`. ## [0.1.2] - 2021-03-01 Add release and changelog management mechanisms ## [0.1.1] - 2021-03-01 Add crate repository metadata ## [0.1.0] - 2021-02-26 Initial release [Unreleased]: https://github.com/Microsoft/snocat/compare/snocat-v0.7.0...HEAD [0.7.0]: https://github.com/Microsoft/snocat/compare/snocat-v0.5.0-alpha.6...snocat-v0.7.0 [0.5.0-alpha.6]: https://github.com/Microsoft/snocat/compare/snocat-v0.1.2...snocat-v0.5.0-alpha.6 [0.1.2]: https://github.com/Microsoft/snocat/compare/v0.1.1...snocat-v0.1.2 [0.1.1]: https://github.com/microsoft/snocat/compare/855fc4beacf4f568a08e848193fba65e6e840fd1...v0.1.1 [0.1.0]: https://github.com/microsoft/snocat/compare/b8d28e83c0bf7010d86eaddcdd212fe72848f6bb...855fc4beacf4f568a08e848193fba65e6e840fd1