[Issue] Requester not sending cover traffic if topology unavailable

[ststefa]

Describe the issue

I have an interesting behaviour this morning. The requester-client reported

Aug 26 00:25:37 he6 nym-client[341683]:  2022-08-25T22:25:37.997Z ERROR client_core::client::topology_control > failed to get network mixnodes - There was an issue with the validator api request - There was an issue with the REST request - error sending request for url (https://validator.nymtech.net/api//v1/mixnodes/active): error trying to connect: tcp connect error: Connection timed out (os error 110)
Aug 26 00:25:37 he6 nym-client[341683]:  2022-08-25T22:25:37.997Z WARN  client_core::client::topology_control > There's only a single validator API available - it won't be possible to use a different one

Then followed 1 hour of repeatedly

Aug 26 00:32:58 he6 nym-client[341683]:  2022-08-25T22:32:58.363Z WARN  client_core::client::real_messages_control::real_traffic_stream > No valid topology detected - won't send any loop cover message this time

...over 200k times total.

Then everything went back to normal by itself. Probably the topology became reachable again. My gut feeling tells me that the requester probably did not try to obtain the topology in that hour.

Of course that eats up a lot of space. But this is not my point.

The thing is that the requester appeared to be working normally in that timeframe, e.g.

Aug 26 00:29:50 he6 nym-network-requester[430109]:  2022-08-25T22:29:50.256Z INFO  nym_network_requester::core           > Starting proxy for 149.154.167.92:443 (currently there are 5 proxies being handled)
Aug 26 00:30:20 he6 nym-network-requester[430109]:  2022-08-25T22:30:20.589Z INFO  nym_network_requester::core           > Proxy for 149.154.167.92:443 is finished  (currently there are 4 proxies being handled)

So that means that the requester continues to emit requests even if not generating cover traffic. My OS metrics correlate with this. I am not sure whether this is a security concern or not.

Expected behaviour

Maybe the requester should stop emitting traffic if it's unable to send cover traffic?

Steps to Reproduce

• Run requester
• Force unreachable network topology (e.g. by iptables)

Which area of Nym were you using?

• Application: network-requester + client
• OS: Debian bullseye
• Version: 1.0.2

[gyrusdentatus]

This issue really needs to be addressed. It's been there forever... could it also be creating the problem with CPU going totally crazy with eating up resources?