Documentation updates (#67)

This commit is contained in:
Tanya S 2024-06-13 14:29:47 +02:00 committed by GitHub
parent b268caaa08
commit 97ee6d7d18
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
6 changed files with 13 additions and 13 deletions

View File

@ -43,7 +43,7 @@ done
🎯**Goals**:
- Connect a different nodes(s) to the network for some ad hoc test.
- Connect a different node(s) to the network for some ad hoc test.
- See how the network reacts to a node with different configuration.
👀**Observability**:

View File

@ -1,8 +1,8 @@
# Connect external light node
By using [go-waku-light](https://github.com/alrevuelta/go-waku-light), you can connect one or multiple light clients to the network. This utility can be configured to send messages at a given rate using a given peer as `ligh-push`. It will register a RLN membership at startup. Bear in mind that it should be configured with the same contract and `user-message-limit` as the waku nodes. You should modify the `lightpush-peer`.
By using [go-waku-light](https://github.com/alrevuelta/go-waku-light), you can connect one or multiple light clients to the network. This utility can be configured to send messages at a given rate using a given peer as `light-push`. It will register a RLN membership at startup. Bear in mind that it should be configured with the same contract and `user-message-limit` as the waku nodes. You should modify the `lightpush-peer`.
Note that if you spin up multiple service like this using the same `priv-key` some of the transactions registering the RLN membership may fail due to the nonce being repeated. This can be fixed by using multiple keys or waiting for the registration to be completed before spinning up the next process.
Note that if you spin up multiple services like this using the same `priv-key` some of the transactions registering the RLN membership may fail due to the nonce being repeated. This can be fixed by using multiple keys or waiting for the registration to be completed before spinning up the next process.
- ⚠️ change `lightpush-peer` to the node you wish. Note that the multiaddress is logged by every peer at startup.
@ -54,4 +54,4 @@ done
- Check the logs of the node you provided as `lightpush-peer`.
- Check grafana metrics at `localhost:3001`.
- Check that the RLN membership was registered in the block explorer `localhost:300`.
- Check that the RLN membership was registered in the block explorer `localhost:3000`.

View File

@ -28,7 +28,7 @@ Once configured, start all containers:
docker-compose --compatibility up -d
```
After couple of minutes, everything should be running at:
After a couple of minutes, everything should be running at:
- `http://localhost:3000` Block explorer
- `http://localhost:3001` Grafana metrics
@ -57,4 +57,4 @@ Now that we have the network deployed we can use it. Hereunder we describe how t
- Connect external light node:
- Register memberships:
⚠️ For every use case, ensure that your node is configured in the same way as the rest of the nodes, otherwise message may be lost. Note that it can be also an intended test, seeing how the network reacts to other nodes connecting to it.
⚠️ For every use case, ensure that your node is configured in the same way as the rest of the nodes, otherwise messages may be lost. Note that it can be also an intended test, seeing how the network reacts to other nodes connecting to it.

View File

@ -1,7 +1,7 @@
# Inject traffic
In order to inject traffic into the network, we can use the REST API of each nwaku node. We have a simple dockerized script in [rest-traffic](https://github.com/alrevuelta/rest-traffic), that can perform this task. In the following command we run a docker container, connected to the waku-simulator network. This script will inject a message every `delay-seconds` with a size of `msg-size-kbytes` into a given `pubsub-topic`. Note that in `multiple-nodes` you can configure the nodes that will publish messages, where `[1..5]` will publish to node 1, 2, 3, 4, 5. You can publish to a single node (eg node 1) by using `[1..1]`.
In order to inject traffic into the network, we can use the REST API of each nwaku node. We have a simple dockerized script in [rest-traffic](https://github.com/alrevuelta/rest-traffic), that can perform this task. In the following command we run a docker container, connected to the waku-simulator network. This script will inject a message every `delay-seconds` with a size of `msg-size-kbytes` into a given `pubsub-topic`. Note that in `multiple-nodes` you can configure the nodes that will publish messages, where `[1..5]` will publish to node 1, 2, 3, 4, 5. You can publish to a single node (e.g. node 1) by using `[1..1]`.
```jsx
docker run -it --network waku-simulator_simulation alrevuelta/rest-traffic:d936446 \
@ -11,7 +11,7 @@ docker run -it --network waku-simulator_simulation alrevuelta/rest-traffic:d9364
--multiple-nodes="http://waku-simulator_nwaku_[1..5]:8645"
```
Note that the REST API doesnt allow to publish messages exceeding the rate limit, so this tool cant be used to tests beyond the rate limits.
Note that the REST API doesnt allow to publish messages exceeding the rate limit, so this tool cant be used to test beyond the rate limits.
🎯**Goals**:

View File

@ -2,7 +2,7 @@
The [waku-simulator](https://github.com/waku-org/waku-simulator) tool allows simulating a waku network with a set of interconnected [nwaku](https://github.com/waku-org/nwaku) nodes with the following features:
- Configurable amount of nodes. Limits depends on the machine and upper bounded at around 200.
- Configurable amount of nodes. Limits depend on the machine and are upper bounded at around 200.
- Runs in a single machine, using `docker-compose` to orchestrate the containers.
- It uses discv5 for peer discovery, using a common bootstrap node.
- It runs a custom ad hoc network, isolated from the existing waku networks.
@ -12,8 +12,8 @@ The [waku-simulator](https://github.com/waku-org/waku-simulator) tool allows sim
- It exposes each nodes API, so that it can be used to inject traffic into the network.
- Simple to run. Everything is automated. Requires two commands to run.
The main goals of `waku-simulator` includes but is not limited to:
The main goals of `waku-simulator` include but are not limited to:
* Test new features in an end to end setup with multiple nodes.
* Use as a long-lived running network on latest master, to anticipate to breaking changes.
* Use as a long-lived running network on latest master, to anticipate breaking changes.
* Explore waku's limits by using different loads and configurations.
* Offer a tool to debug problems in a controled and easy to replicate environment.
* Offer a tool to debug problems in a controlled and easy to replicate environment.

View File

@ -1,7 +1,7 @@
# Register memberships
The [go-waku-light](https://github.com/alrevuelta/go-waku-light) tool can be used as well to register multiple RLN memberships. This can be useful to stress test the nodes, forcing a large amount of memberships. Set `amount` to the amount of memberships that you want to register. Note that it takes some time, since memberships are registered one after the other. You can spin up multiple service like this, but in that case you must provide different `priv-key` to each. Note that this memberships are kind of thrown away and not used to send messages.
The [go-waku-light](https://github.com/alrevuelta/go-waku-light) tool can be used as well to register multiple RLN memberships. This can be useful to stress test the nodes, forcing a large amount of memberships. Set `amount` to the amount of memberships that you want to register. Note that it takes some time, since memberships are registered one after the other. You can spin up multiple services like this, but in that case you must provide different `priv-key` to each. Note that these memberships are kind of thrown away and not used to send messages.
```jsx
docker run --network waku-simulator_simulation alrevuelta/go-waku-light:07b8f32 \