Jędrzej Stuczyński
d8c84cc4d6
* wip * wip: wrap node's sphinx key with a manager * wip: choosing correct key for packet processing * further propagation of key rotation information * attaching key rotation information to reply surbs * added basic key rotation information to mixnet contract * wip: introducing cached queries for key rotation info from nym api * unified nym-api contract cache refreshing * finish packet decoding * multi api client + retrieving rotation id * rotating sphinx key files * logic for migrating config file * wip: putting new sphinx keys to self described endpoints * processing loop of KeyRotationController * fixed sphinx key loading * rotating bloomfilters * wired up KeyRotationController * flushing bloomfilters to disk and loading * most of nym-node changes * post rebase fixes * fixes due to backwards compatible hostkeys * split http state.rs file * dont use deprecated fields * fixed backwards compatible deserialisation of host information * split up node describe cache * added a dedicated CacheRefresher listener to perform full refresh outside the set interval * controlling announced sphinx keys within nym-api * retrieving rotation id when pulling topology * split nym-nodes http handlers * v2 nym-api endpoints to retrieve nodes with additional metadata information * bug fixes... * additional bugfixes and guards against stuck epoch * testnet manager: set first nym-api as the rewarder * fixed host information deserialisation * fixed panic during first key rotation * post rebase fixes * clippy * more guards against stuck epochs * added helper method to reset node's sphinx key * instantiate mixnet contract with custom key rotation validity * additional bugfixes and debugging nym-api deadlock * passing shutdown to nym apis client * remove dead test * post rebasing fixes * missing MixnetQueryClient variants * remove usage of deprecated methods in sdk example * fix: incorrect method signature * post rebasing fixes * attempt to retrieve key rotation id before doing any config migration work * ignore tests relying on networking behaviour * allow networking failures in certain tests
Nym Network Monitor
Monitors the Nym network by sending itself packages across the mixnet.
Network monitor is running two tokio tasks, one manages mixnet clients and another manages monitoring itself. Monitor is designed to be driven externally, via an HTTP api. This means that it does not do any monitoring unless driven by something like locust. This allows us to tailor the load externally, potentially distributing it across multiple monitors.
Client manager
On start network monitor will spawn C clients, with 10 being the default. Random client is dropped every T, defaults to 60 seconds, and a new one is created. Clients chose a random gateway to connect to the mixnet. Meaning that on average all gateways will be tested in NUMBER_OF_GATEWAYS/N*T, assuming at least one request per client per T.
Network monitor API
Swagger UI is available at /v1/ui/, ie http://localhost:8080/v1/ui/
Driving the monitor with Locust
- Head over to https://locust.io/ and get
locust - Start everything
# Start the network monitor
cargo run --release
# Start locus in a separate terminal
python -m locust -H http://127.0.0.1:8080 --processes 4
- Head over to http://127.0.0.1:8089/ and start a testing run
Usage
Usage: nym-network-monitor [OPTIONS]
Options:
-C, --clients <N_CLIENTS> Number of clients to spawn [default: 10]
-T, --client-lifetime <CLIENT_LIFETIME> Lifetime of each client in seconds [default: 60]
--port <PORT> Port to listen on [default: 8080]
--host <HOST> Host to listen on [default: 127.0.0.1]
-t, --topology <TOPOLOGY> Path to the topology file
-e, --env <ENV> Path to the environment file
-m, --mixnet-timeout <MIXNET_TIMEOUT> [default: 10]
--generate-key-pair
--private-key <PRIVATE_KEY>
-h, --help Print help
-V, --version Print version