Difference between revisions of "Networking"

Latest revision as of 20:02, 23 January 2023

The page contains technical content relevant for the scope of the application level networking components.

HTTP(s) Endpoints

Documentation about replica components that open listening sockets, so NNS managed nodes can communicate with replica nodes can be found in rs/http_endpoints/README.adoc

Networking Adapters

Networking adapters are processes on the ReplicaOS that run next to the main replica process and can issue outgoing calls to the internet. The intent of an adapter is to serve as proxy which sanitises data received externally. Networking adapters are used by Bitcoin integration and HTTPS outcalls features.
The main replica process uses gRPC for communicating with the co-located adapters via Unix domain sockets.

NNS Managed Firewall Configuration

The IC uses nftables to restrict outgoing and incoming connectios on each IC node. The registry contains relevant topology information which the IC uses to derive nftables rules.

Rust

Crates

The following crates are heavily used by the networking components

tokio, tower, hyper, tonic

@@ Line 1: / Line 1: @@
-== Networking designs ==
+The page contains technical content relevant for the scope of the application level networking components.
+== HTTP(s) Endpoints ==
+Documentation about replica components that open listening sockets, so NNS managed nodes can
+communicate with replica nodes can be found in [https://gitlab.com/dfinity-lab/public/ic/-/tree/master/rs/http_endpoints rs/http_endpoints/README.adoc]
-=== Preventing server overload ===
+== Networking Adapters ==
+Networking adapters are processes on the ReplicaOS that run next to the main replica process and can issue outgoing calls to the internet. The intent of an adapter is to serve as proxy which sanitises data received externally. Networking adapters are used by [[Bitcoin integration]] and [[HTTPS outcalls]] features. <br>
+The main replica process uses [https://docs.rs/tonic/latest/tonic/transport/index.html gRPC] for communicating with the co-located adapters via Unix domain sockets.
+== NNS Managed Firewall Configuration ==
-=== Rust async ===
+The IC uses [https://en.wikipedia.org/wiki/Nftables nftables] to restrict outgoing and incoming connectios on each IC node. The registry contains relevant topology information which the IC uses to derive nftables rules.
-===== Quick Tips =====
+== Rust ==
-* Avoid creating new instances of tokio::runtime::Runtime in situ. Parameterize your component over tokio::runtime::Handle and pass the handle of the top-level runtime in the main function.
+=== Crates ===
-* Avoid blocking the event thread for a long time by calling computationally-expensive or blocking functions in your futures. In case of an HTTP server, it almost always makes sense to off-load the actual request handling to a thread pool.
+The following crates are heavily used by the networking components<br>
-* Avoid calling tokio::runtime::Runtime::block_on in your async components. This makes it impossible to use your components in other async code. It is fine to call block_on from a sync component as long as blocking the thread until a result is available is allowed. For example, calling a gRPC service with requests that have deadline/timeout specified.
+ [https://docs.rs/tokio/latest/tokio/ tokio], [https://docs.rs/tower/latest/tower/ tower], [https://docs.rs/hyper/latest/hyper/ hyper], [https://docs.rs/tonic/latest/tonic/ tonic]
-* Never use tokio::task::block_in_place. Using this function almost always signals that there is an issue with the overall design.
-* Never call std::thread::sleep in async code. If you really have to suspend current task for a while, use tokio::time::sleep instead.
+==See Also==
-* Avoid using sleep (both sync and async) for synchronization, It's often a sign of flawed component communication pattern. Use callbacks, tokio synchronization and communication primitives instead. There are valid use-cases for sleep, but they mostly apply to events happening outside of the current process, e.g., like waiting for a remote service to get back to life.
+* '''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''
-* Never hold std::sync::Mutex or parking_lot::Mutex across .await points. Holding a Mutex across .await points never leads to correct concurrent code. In practice this can easily lead to deadlocks. More information about picking the right mutex can be found in the tokio’s docs.