logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-01-02 14:13:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

add nits

Browse Source
This commit is contained in:
Sasha 2024-07-10 00:58:41 +02:00
parent 642a53932a
commit dca926abea
No known key found for this signature in database
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
informational/req-res-reliability.md
View File

@ -34,7 +34,7 @@ Such use cases can be: recovery from offline state, decrease rate of missed mess
Node health is a metric meant to determine the connectivity state of a light node and its present ability to reliably send and receive messages from the network. Node health is a metric meant to determine the connectivity state of a light node and its present ability to reliably send and receive messages from the network.
We consider this reliability to be dependant on amount of simultaneous connections to responsive service nodes. We consider this reliability to be dependant on amount of simultaneous connections to responsive service nodes.
Unfortunately the more connections light node establishes - the more bandwidth is consumed. Unfortunately the more connections light node establishes - the more bandwidth is consumed.
To address this we suggest following metrics: To address this we suggest following states:
- unhealthy - no connections to service nodes are available regardless of protocol; - unhealthy - no connections to service nodes are available regardless of protocol;
- minimally healthy: - minimally healthy:
- Filter has one service node connection; - Filter has one service node connection;
@ -46,7 +46,7 @@ To address this we suggest following metrics:
### Peers and connection management ### Peers and connection management
#### Pool of reliable service nodes #### Pool of reliable service nodes
Light node should maintain a pool of reliable service nodes for each protocol. Light nodes should maintain a pool of reliable service nodes for each protocol.
In case service node [fails](./req-res-reliability.md#definitions) to serve protocol request from a light node 3 times - light node should drop connection to it and a new service node should be connected and added to the pool instead. In case service node [fails](./req-res-reliability.md#definitions) to serve protocol request from a light node 3 times - light node should drop connection to it and a new service node should be connected and added to the pool instead.
#### Selection of discovered service nodes #### Selection of discovered service nodes
@ -64,7 +64,7 @@ Examples of filtering:
- Light node must connect only to those service nodes that participate in needed shard; - Light node must connect only to those service nodes that participate in needed shard;
#### Continuous discovery #### Continuous discovery
Light node must keep information about service nodes up to date. Light nodes must keep information about service nodes up to date.
For example when a service node is discovered second time, For example when a service node is discovered second time,
we need to be sure to keep connection information up to date in Peer Store. we need to be sure to keep connection information up to date in Peer Store.