From c9389f03c38d6d486ed194d240de7b404c815ede Mon Sep 17 00:00:00 2001 From: NagyZoltanPeter <113987313+NagyZoltanPeter@users.noreply.github.com> Date: Wed, 2 Oct 2024 13:48:57 +0200 Subject: [PATCH 1/2] fix: Addressing comments on the descritpion of DOS protection configuration (#222) * Addressing comments on the descritpion of DOS protection configuration * Incorporate review suggestions, added full notion of argument examples --- docs/guides/nwaku/config-options.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/guides/nwaku/config-options.md b/docs/guides/nwaku/config-options.md index dcad83c..0b3154b 100644 --- a/docs/guides/nwaku/config-options.md +++ b/docs/guides/nwaku/config-options.md @@ -157,11 +157,11 @@ Here are the available node configuration options, along with their default valu | `websocket-secure-key-path` | | Secure websocket key path: '/path/to/key.txt' | | `websocket-secure-cert-path` | | Secure websocket Certificate path: '/path/to/cert.txt' | -## Non relay, request-response protocol DOS protection configuration +## Non-relay, request-response protocol DOS protection configuration | Name | Default Value | Description | | ---------------------------- | ------------- | ------------------------------------------------------ | -| `rate-limit` | | This is a repeatable option. Each one of them can describe spefic rate limit configuration for a particular protocol.
\:volume/period\
- if protocol is not given, settings will be taken as default for un-set protocols. Ex: `80/2s`
-Supported protocols are: `lightpush`\|`filter`\|`px`\|`store`\|`storev2`\|`storev3`
-volume must be an integer value, representing number of requests over the period of time allowed.
-period\ must be an integer with defined unit as one of `h`\|`m`\|`s`\|`ms`
- `storev2` and `storev3` takes precedence over `store` which can easy set both store protocols at once.
- In case of multiple set of the same protocol limit, last one will take place.
- if config is not set it means unlimited requests are allowed.
-filter has a bit different approach. It has a default setting applied if not overridden. Rate limit setting for filter will be applied per subscriber-peers, not globally - it must be considered when changing the setting.

Examples:
- `100/1s` - default for all protocols if not set otherwise.
-`lightpush:0/0s` - lightpush protocol will be not rate limited.
-`store:130/1500ms` - both store-v3 and store-v2 will apply 130 request per each 1500ms separately.
-`px:10/1h` PeerExchange will serve only 10 requests in every hour.
-`filter:8/5m` - will allow 8 subs/unsubs/ping requests for each subscribers within every 5 min. | +| `rate-limit` | | This is a repeatable option. Each can describe a specific rate limit configuration for a particular protocol.
Formatted as:`:volume/period`
- if protocol is not given, settings will be taken as default for un-set protocols. Ex: `80/2s`
-Supported protocols are: `lightpush`\|`filter`\|`px`\|`store`\|`storev2`\|`storev3`
-volume must be an integer value, representing number of requests over the period of time allowed.
-period\ must be an integer with defined unit as one of `h`\|`m`\|`s`\|`ms`
- `storev2` and `storev3` takes precedence over `store` which can easy set both store protocols at once.
- In case of multiple set of the same protocol limit, last one will take place.
- if config is not set, - which is the default - means unlimited requests are allowed.
-filter has a bit different approach. It has a default setting applied if not overridden. Rate limit setting for filter will be applied per subscriber-peers, not globally - it must be considered when changing the setting.

Examples:
`--rate-limit="100/1s"` - default for all protocols if not set otherwise.
`--rate-limit="lightpush:0/0s"` - lightpush protocol will not be rate-limited.
`--rate-limit="store:130/1500ms"` - both store-v3 and store-v2 will apply 130 request per each 1500ms separately.
`--rate-limit="px:10/1h"` PeerExchange will serve only 10 requests every hour.
`--rate-limit="filter:8/5m"` - will allow 8 subs/unsubs/ping requests for each subscriber within every 5 min. | :::tip To configure your node using the provided configuration options, have a look at the [Node Configuration Methods](/guides/nwaku/config-methods) guide. From 1b2affe15ea4371ed3a03969cef375bc064d3455 Mon Sep 17 00:00:00 2001 From: gabrielmer <101006718+gabrielmer@users.noreply.github.com> Date: Thu, 3 Oct 2024 10:34:21 +0300 Subject: [PATCH 2/2] Adding num-shards-in-network config option to documentation (#224) --- docs/guides/nwaku/config-options.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/guides/nwaku/config-options.md b/docs/guides/nwaku/config-options.md index 0b3154b..9b599b9 100644 --- a/docs/guides/nwaku/config-options.md +++ b/docs/guides/nwaku/config-options.md @@ -68,6 +68,7 @@ Here are the available node configuration options, along with their default valu | `keep-alive` | `false` | Enable keep-alive for idle connections: true\|false | | `pubsub-topic` | | Default pubsub topic to subscribe to. Argument may be repeated. **Deprecated!** Please use `shard` and/or `content-topic` instead | | `shard` | | Shard to subscribe to. Argument may be repeated | +| `num-shards-in-network` | | Number of shards in the network. Used to map content topics to shards when using autosharding | | `content-topic` | | Default content topic to subscribe to. Argument may be repeated | | `reliability` | `false` | Enable experimental reliability protocol true\|false |