address actual spell checks to make codespell happy.

Signed-off-by: Tomoya Fujita <Tomoya.Fujita@sony.com>

Author: fujitatomoya

codespell_whitelist.txt

@@ -0,0 +1,12 @@
+crate
+CAs
+decypher
+deque
+lets
+medias
+mut
+stdio
+UInt
+WAN
+ws
+WS

content/blog/2020-06-29-zenoh-tidings.md

@@ -35,10 +35,10 @@ The upcoming version of **zenoh** comes with a few improvements and some new fea
 
 **Generalised Peer-to-Peer and Client Communication**. In the upcoming version of **zenoh** an application can decide at runtime to behave like a peer or a client. Peers route information between themselves and can also route on behalf of clients -- in other terms peers can behave like routers. Peers-to-peer communication is supported for arbitrary connectivity graphs and supports cliques as a special case. 
 
-**Closure-based Discovery**. Discovery in **zenoh** is supported by the **scouting** protocol, in order to ease the deployment of system that wants to leverage a clique connectivity, for cases in which multicast is not avaiable, or desirable, we support now a clousure-based discovery. In other terms starting from a single peer, we can discover its closure, or in other terms the peers that can be reached directly or indirectly from this starting point.
+**Closure-based Discovery**. Discovery in **zenoh** is supported by the **scouting** protocol, in order to ease the deployment of system that wants to leverage a clique connectivity, for cases in which multicast is not available, or desirable, we support now a clousure-based discovery. In other terms starting from a single peer, we can discover its closure, or in other terms the peers that can be reached directly or indirectly from this starting point.
 
 **Region-Based Routing**
-The new version of **zenoh** supports region-based routing. As depicted in the diagram below, this really means two things, (1) routing information required to build and maintain our routing tables scales with the size of the region, and (2) each region can decide wether to route over an arbitrary connectivity graph of assume a clique. This approach to routing will greatly improve scalability and performance by allowing to use the most appropriate routing technique within a region.
+The new version of **zenoh** supports region-based routing. As depicted in the diagram below, this really means two things, (1) routing information required to build and maintain our routing tables scales with the size of the region, and (2) each region can decide whether to route over an arbitrary connectivity graph of assume a clique. This approach to routing will greatly improve scalability and performance by allowing to use the most appropriate routing technique within a region.
 ![zenoh-routing](../../img/routing.png)
 
 ## Performances

content/blog/2020-10-08-aithusa.md

@@ -9,7 +9,7 @@ draft: false
 We have been waiting this very moment for several months. Months of patient
 dedication, months of hard and creative work. Months in which each and every
 member of the **zenoh** team  has made his and her best to give our little dragon all
-it needed to succed in the complicated world of Internet Scale Protocols.
+it needed to succeed in the complicated world of Internet Scale Protocols.
 
 Today, at about 11.00 Paris Time **Zenoh Aithusa** Hatched Out!
 
@@ -96,7 +96,7 @@ Another goody coming with Zenoh Aithusa is the [DDS plugin](https://github.com/e
 ## What's Next
 In the weeks to come we will be releasing:
 
-- **Zenoh-pico**. A C-based [client stack for zenoh](https://github.com/eclipse-zenoh/zenoh/wiki/Zenoh--For-Microcontrollers) targeting the most constrained environemnts.
+- **Zenoh-pico**. A C-based [client stack for zenoh](https://github.com/eclipse-zenoh/zenoh/wiki/Zenoh--For-Microcontrollers) targeting the most constrained environments.
 
 - **Language Bindings**. More bindings are coming up including Go-Lang and Java APIs.
 

content/blog/2021-04-28-ROS2-integration.md

@@ -255,5 +255,5 @@ You can also test this with the "teleop" demos provided [here](https://github.co
 [**--JE**](https://github.com/JEnoch)
 
 [^1]: **Why 1 domain per robot ?**  
-In most of the cases, you don't need the robots to communicate with each other. But if you let them use the same `ROS_DOMAIN_ID`, their DDS entities in the robots will anyway exchange discovery information with each other leading to a lot of unecessary traffic that could be problematic over wireless communications (as seen in our previous blog). The simplest way to avoid such traffic is to use distinct domains. Other solutions could be specific network configuration, or specific DDS configuration.
+In most of the cases, you don't need the robots to communicate with each other. But if you let them use the same `ROS_DOMAIN_ID`, their DDS entities in the robots will anyway exchange discovery information with each other leading to a lot of unnecessary traffic that could be problematic over wireless communications (as seen in our previous blog). The simplest way to avoid such traffic is to use distinct domains. Other solutions could be specific network configuration, or specific DDS configuration.
 

content/blog/2021-09-28-IAC-experiences-from-the-trenches.md

@@ -118,7 +118,7 @@ For this purpose, we recently introduced a new option in the zenoh/DDS bridge:
    - *"float"* is the maximum frequency in Hertz; if publication rate is higher, downsampling will occur when routing.
  
 This option can be used multiple times for different frequency per-topic.  
-For instance, if we want such limtations (topic names are fictitious):  
+For instance, if we want such limitations (topic names are fictitious):  
  - from the racecar, we want to re-publish over zenoh those topics with a maximum frequency for each:
    - `position`: 10Hz
    - `speed`: 10Hz

content/blog/2021-10-04-zenoh-pico-guide.md

@@ -223,7 +223,7 @@ The scarce memory and flash resources in microcontrollers stresses out the impor
 
 |                                |   |   | **reel_board (Zephyr)** |   |   | **nucleo-f767zi (Zephyr)** |   |   | **ESP32-D0WDQ6 (Arduino)** |
 |--------------------------------|---|---|:-----------------------:|---|---|:--------------------------:|---|---|:--------------------------:|
-|       **Build-in Flash**       |   |   |           1MiB          |   |   |            2MiB            |   |   |            4MiB            |
+|       **Built-in Flash**       |   |   |           1MiB          |   |   |            2MiB            |   |   |            4MiB            |
 | **Empty Binary (Zephyr-only)** |   |   |       68166 bytes       |   |   |        127344 bytes        |   |   |        385859 bytes        |
 |          **Zenoh Publisher**   |   |   |       164654 bytes      |   |   |        186942 bytes        |   |   |        423161 bytes        |
 

content/blog/2022-06-09-zenoh-pico-above-and-beyond.md

@@ -30,7 +30,7 @@ Protocols used today to build these systems, such as MQTT, DDS, CoAP and even HT
 
 # Zenoh API for constrained devices
 
-APIs should provide a minimal set of well defined and composable primitives. That's easily said but takes a deep understanding of the problem space and the patience necessary to refine the solution. In Zenoh, we went through a careful thought process in order to understand the abstractions and primitives that must or must not be provided to the users, hiding irrelevant details while not reducing its expressiveness. As a result, Zenoh-Pico provides exactly the same set of primitives as provided by the Zenoh Rust-implementation and its binding, making in fact 99% of Zenoh-C source-code copyable into Zenoh-Pico code.
+APIs should provide a minimal set of well defined and composable primitives. That's easily said but takes a deep understanding of the problem space and the patience necessary to refine the solution. In Zenoh, we went through a careful thought process in order to understand the abstractions and primitives that must or must not be provided to the users, hiding irrelevant details while not reducing its expressiveness. As a result, Zenoh-Pico provides exactly the same set of primitives as provided by the Zenoh Rust-implementation and its binding, making in fact 99% of Zenoh-C source-code copiable into Zenoh-Pico code.
 
 > “(Software design is) a craft...and it has a lot to do with valuing simplicity over complexity. Many people do have a tendency to make things more complicated than they need to be.”
 
@@ -277,7 +277,7 @@ Except for the session opening and closing, Zenoh offers the lowest overhead in
 
 Still, the most important operation is publishing data, and **Zenoh overhead in the wire is 98%, 75% and 64% smaller when compared to OPC-UA, XRCE-DDS and MQTT**. In doing so, Zenoh is considerably less expensive if we consider long-lived sessions that periodically publish information (e.g., IoT sensoring systems making use of Low Throughput Networks). 
 
-As for the keep-alives, in Zenoh they are not sent if any message is transmitted between the session peers in the corresponding lease window, making its overhead non-existent for periodic publishers.
+As for the keep-alive, in Zenoh they are not sent if any message is transmitted between the session peers in the corresponding lease window, making its overhead non-existent for periodic publishers.
 
 ## Flash Memory Overhead
 Flash memory might be an extremely restrictive element in constrained devices like IoT devices, not comprising more than 1MB of flash memory. This means that all the compiled software (including the user code and libraries), firmware and any other data the device can download needs to fit in such a small amount of space.

content/blog/2023-01-17-zenoh-wireshark.md

@@ -28,7 +28,7 @@ Fear not, as now you have a **Zenoh protocol dissector that you can use with Wir
 # How to Install the Zenoh Protocol Dissector?
 Zenoh’s dissector is written in Lua to make it easy to install on any of the Wireshark supported platforms –  Wireshark has a built-in Lua interpreter. As such,  the installation process is as simple as copying the `zenoh.lua` file to the [Wireshark plugin folder](https://www.wireshark.org/docs/wsug_html_chunked/ChPluginFolders.html).
 
-We recommend cloning the [Zenoh protocol dissector Github repository](https://github.com/ZettaScaleLabs/zenoh-dissector) and creating a symbolic link of `zenoh.lua` file to the Wireshark plugin folder. In this way, everytime you fetch the latest changes from the Github repository, it will immediately update the file already being loaded by Wireshark.
+We recommend cloning the [Zenoh protocol dissector Github repository](https://github.com/ZettaScaleLabs/zenoh-dissector) and creating a symbolic link of `zenoh.lua` file to the Wireshark plugin folder. In this way, every time you fetch the latest changes from the Github repository, it will immediately update the file already being loaded by Wireshark.
 
 ```bash
 git clone https://github.com/ZettaScaleLabs/zenoh-dissector <WORKING_DIR>/zenoh-dissector

content/blog/2023-03-21-zenoh-vs-mqtt-kafka-dds.md

@@ -20,7 +20,7 @@ Zenoh community as this evaluation answers a couple of questions we are asked qu
 High performance has always been one of the main goals of Zenoh. While  Zenoh\'s performance is provided for each release (see
 [here](https://zenoh.io/blog/2022-09-30-zenoh-bahamut/#improved-performance),
 [here](https://zenoh.io/blog/2022-04-14-rust-async-eval/), and
-[here](https://zenoh.io/blog/2021-07-13-zenoh-performance-async/)), so far there were no peformance evaluations that
+[here](https://zenoh.io/blog/2021-07-13-zenoh-performance-async/)), so far there were no performance evaluations that
 compared Zenoh with other technologies. Yet, this was a question commonly asked on Zenoh's discord server and on github.
 In this blog, we'll present an evaluation conducted by the [National Taiwan
 University](https://www.ntu.edu.tw/english/) where Zenoh\'s

content/blog/2023-06-05-charmander2.md

@@ -88,7 +88,7 @@ let mut formatter = temperatures::formatter();
 let ke = zenoh::keformat!(formatter, factory = 5, sensor = 42).unwrap();
 ```
 
-- Or use it to parse incoming KEs to extract the informations you actually care about:
+- Or use it to parse incoming KEs to extract the information you actually care about:
 
 ```rust
 let parsed = temperatures::parse(ke).unwrap();