Zenoh 1.0.0 "Firesong" is ready to rock!
21st October 2024
As a result of an incredible effort from the whole Zenoh team and Zenoh community, we can finally announce that Zenoh 1.0.0 Firesong is out!
This release marks an incredible milestone for Zenoh and comes with a lot of features and improvements:
- API stabilization. Great attention has been given to the API, its revision and rework to provide the necessary level of stability and future extensibility.
- The very first alpha version of the new TypeScript API.
- A full rework of the Shared Memory subsystem in Zenoh, with a new API and more supported topologies.
- Improved batching and jitter performance for high frequency publications.
- Improved protocol for write-side filtering.
Let us take a closer look at what Zenoh 1.0.0 brings to the table.
Improved API approach
Zenoh’s API has been improved in terms of ergonomics, clarity, and composability for future extensibility! +
Zenoh 1.0.0 "Firesong" is ready to rock!
21st October 2024
As a result of an incredible effort from the whole Zenoh team and Zenoh community, we can finally announce that Zenoh 1.0.0 Firesong is out!
This release marks an incredible milestone for Zenoh and comes with a lot of features and improvements:
- API stabilization. Great attention has been given to the API, its revision and rework to provide the necessary level of stability and future extensibility.
- The very first alpha version of the new TypeScript API.
- A full rework of the Shared Memory subsystem in Zenoh, with a new API and more supported topologies.
- Improved batching and jitter performance for high frequency publications.
- Improved protocol for write-side filtering.
Let us take a closer look at what Zenoh 1.0.0 brings to the table.
Improved API approach
Zenoh’s API has been improved in terms of ergonomics, clarity, and composability for future extensibility! The following sections highlight the main changes of the API in the various language bindings. The full migration guide of each language is available here.
Accessors
To better separate the public API from the internal implementation, we have introduced the accessor pattern in the Zenoh API across all language bindings.
See an example in Rust below.
@@ -454,7 +454,7 @@
This addition introduced the need for a way to describe subjects as combinations of multiple attributes of different types (interface, certificate common name, and/or username).
We have addressed this need by reworking the ACL configuration format, making it modular by isolating the rules from the subjects.
This allows the combination of subject attributes, while also avoiding the need to duplicate subject or rule configurations by adding the policies list.
On another note, we have shifted the focus of ACL from actions to messages to make it easier for users to associate the ACL rules to their respective operations exposed via the Zenoh API.
-The get action has been replaced by the Query message, and we completed the array of supported message types in ACL with the addition of publisher Delete and queryable Reply messages.
Following this release, a guide on how to configure ACL is available on the Zenoh reference manual, and the Access Control Rules RFC has been updated.
Batching and jitter
The porting of Zenoh to Tokio in 0.11.0 had as a side effect a change in the batching behaviour as reported by some users.
+The get action has been replaced by the Query message, and we completed the array of supported message types in ACL with the addition of publisher Delete and queryable Reply messages. Filters for liveliness messages are added later on in Zenoh v1.0.3.
Following this release, a guide on how to configure ACL is available on the Zenoh reference manual, and the Access Control Rules RFC has been updated.
Batching and jitter
The porting of Zenoh to Tokio in 0.11.0 had as a side effect a change in the batching behaviour as reported by some users. The issue has been thoroughly investigated resulting in a rework of the batching mechanism in Zenoh 1.0.0. This rework accounts for Tokio peculiarities in timing management and improves the overall jitter performance when publishing at high frequency.
Link selection
Link selection refers to the process of choosing a network Link when transmitting messages. This is done in the Zenoh Transport layer when two Zenoh nodes are operating in multilink mode (i.e. more than one Link has been established).
In Zenoh 0.11.x, the Link selection implementation picks any Link that matches the Reliability of the transmitted message. diff --git a/docs/manual/access-control/index.html b/docs/manual/access-control/index.html index 881110b0..98f5f12f 100644 --- a/docs/manual/access-control/index.html +++ b/docs/manual/access-control/index.html @@ -1,6 +1,6 @@
Access Control
NOTE: This documentation covers the Zenoh 1.0 ACL config. For Zenoh 0.11 ACL config,
+ NOTE: This documentation covers the Zenoh 1.0 ACL config. For Zenoh 0.11 ACL config,
please refer to the Zenoh 0.11 Access Control Rules RFC Access control enables Zenoh instances to filter (allow or deny) messages,
depending on certain characteristics of individual messages and their respective source or destination.
Authentication on the other hand allows Zenoh instances to identify certain characteristics in other instances they connect to,
@@ -54,7 +54,7 @@
]
}
}
- Each rule within the Matched messages are filtered based on the rule’s For instance, the following rule denies all incoming and outgoing subscriptions, publications and deletions on key expressions matching Each rule within the Matched messages are filtered based on the rule’s For instance, the following rule denies all incoming and outgoing subscriptions, publications and deletions on key expressions matching For a more technical analysis of the ACL feature, please refer to the Access Control Rules RFC.Access Control
rules
rules list is identified by a unique id string. Rules apply on matched messages based on their individual characteristics:messages: types of messages to apply the rule on. Supported message types are the following:declare_subscriber)put)delete)declare_queryable)query)reply)flows: applies rule on incoming messages (ingress), outgoing messages (egress), or both directions. If this field is not provided in the config, the rule will apply to both directions by default.key_exprs: the rule applies on messages for which the key matches one of the given key expressions. For more details on key expression matching, see Key Expressions.permission: allow or deny.demo/example/**:{
+rules
rules list is identified by a unique id string. Rules apply on matched messages based on their individual characteristics:messages: types of messages to apply the rule on. Supported message types are the following:declare_subscriber)put)delete)declare_queryable)query)reply)liveliness_token)declare_liveliness_subscriber)liveliness_query): note that its associated replies are Liveliness Token messages.flows: applies rule on incoming messages (ingress), outgoing messages (egress), or both directions. If this field is not provided in the config, the rule will apply to both directions by default.key_exprs: the rule applies on messages for which the key matches one of the given key expressions. For more details on key expression matching, see Key Expressions.permission: allow or deny.demo/example/**:{
"id": "deny pub/sub",
"permission": "deny",
"flows": ["ingress", "egress"],
@@ -107,7 +107,7 @@
In this case, it is important to know decision priority to predict the outcome: explicit deny rule > explicit allow rule > default_permission rule.
For more details on decision priority, please refer to the Priority section of the Access Control Rules RFC."**", "example/*", "example/t$*") and prefer keys (eg: example/test) which are much faster to match.reply does not necessarily have the same key expression as its associated query.scouting and gossip, which is complicated further when factoring the mobility of Zenoh clients in certain use-cases.