Closed yiannisbot closed 5 months ago
Is this something that should be documented at the README file?
Is this something that should be documented at the README file?
I think it should be.
closing this up, as the explanation was added to the README file in #28
From the architectures, they seem to do the same thing (monitor the p2p network and push the metrics into the persistent database).
Links:
Although at first sight both tools seem to be focusing on the same goals, they have significant differences in their use cases and their targets in terms of data collection and metrics.
Armiarma is a network crawler that relies on running discv5 peer discovery service and a libp2p host 24/7 to establish connections. However, significant modifications have been made to connect to as many peers as possible (custom peering module). This way, it tries to identify as many peers as possible in the network periodically. Thus, its focus is mainly on opening and identifying as many peers as possible, rather than maintaining stable connections to other peers in the network.
On the other hand, although Hermes also relies on a continuously running discv5 and libp2p host, it uses the libp2p connection manager for a different purpose to Armiarma (which is to connect to as many peers as possible). In the case of Hermes, the connection manager is used to decide who it connects to (i.e., simulating the behaviour of a standard node). Furthermore, it backs up some of the RPC, which requires keeping the chain db calls on a trusted node. This way, it behaves like a light node to the network, which is honest and beneficial for the rest of the network, allowing us to track all desired networking events from stable connections, while at the same time having a highly customizable tracing system.
cc: @cortze