Here’s a pattern I see in the plot:
It has stepwise shape, where it is flat for a period and then spikes up a little with a flurry of activity in the console. The period is about 45-60 minutes.
My guess that this periodic “waking up” is finding out who on the routing table is still active, clearing out inactive entries and acquiring some replacements via the still-active entries.
So as a first attempt at the sliding window I mentioned earlier in the topic, as a way of getting closer to a list of active nodes (and not merely nodes that existed at some time) would be to:
-
Collect the time when each node in the routing table was last heard from.
-
Drop from the (plotting) data file those members that haven’t been heard from in less than an hour.
-
Force a rebuild (by restarting the vault) of the routing table on a period well under an hour: 10 minutes, say.
Since the boot cache is not yet active, my understanding is that a newly (re)started vault has only the config file to use to rebuild its routing table. So each restart is starting from exactly the same data. Since all the vaults in the test network are (presumably) initializing from the droplets in the default config file, which (again, presumably) have built routing tables much bigger than the typical community vault (I’m seeing 64 entries right now, but I would expect a droplet to have much more tahn that), and since my vault will (presumably) learn a random selection of the entries in some droplets’ routing tables, then such a sliding window of ten minutes* should eventually collect all active nodes.
Note: Or a double-sliding window: ten minutes for each rebuild, but if a node doesn’t show up in n restarts then it is dropped.
