Consider Actor patterns within NetworkPeer.

[ryardley]

More and more it is becoming clear we need to have sophisticated behavior around our net package that is best managed using some of the techniques we have developed within our actor patterns we have used elsewhere.

• Persistent in memory synchronized state for storing connected peers to enable redialing on reboot
• Event based command retries
• Receiving and sending events

Currently we have an actor NetworkPeer encapsulated by an actix actor that was being used to interface with the rest of the system.

graph TD
  N["NetworkManager(Actor)"] --"Sender<NetworkPeerCommand>"--> P[NetworkPeer]
  P --"Receiver<NetworkPeerEvent>"--> N

Loading

For historical reasons we avoided using actix actors here but it doesn't really make sense to maintain the complexity of channels when we use actix actors everywhere else within the codebase.

Evidence for why we need to do this can be seen in the emerging complexity around creating retry behaviour there we pass each channel down in a series of functions where it would be simpler to have this in it's own dialer actor and that actor can send messages back to a swarm actor. You could say we have created a quasi actor model system using channels for managing memory and ownership easily and allowing a more modular approach. This currently is fine as this is the main area of complexity here and is workable in it's current incarnation but when considering the other things we will almost certainly be doing here - we should switch out to conventional patterns that make good use of the message passing abstraction.

Other complex things we will likely need to do in the future:

• Reinitializing connections upon reboot / upgrade
• Store event payloads on kademlia and gossip hashes as IDs
• Get a list of events a new peer has missed
• Store a cannonical event history and order possibly integrating prolly trees

These things wont scale well without decomposition into smaller modular parts which will be easier with the actor model.