Factomd P2P/Network flow diagram

Who

Factomize
Core Committee
Core Developer
This was one of the areas I was struggling to understand for quite a while and it wasn't until I was 90% done with this diagram that it finally 'clicked' what the difference between P2P Peer, Peer, and SimPeer is and where to separate program from network messages. I'll try my best to relay that.

The diagram covers the flow of messages via channels for the peer to peer network. There is one Controller and multiple Peers. Each Peer has its own Connection, which isn't accessed directly but rather through the Controller.

Q: I don't see any Election/Consensus/Commit/Reveal/Database messages. Where are they?
A: They are inside the payload of Parcels. The NetworkProcessNet clouds at the right side are the ones that get the payload, delivered inside a "FactomMessage"

Q: If I don't care about networking, how much of this do I need to know?
A: Essentially nothing, it's a fairly self-contained system. Providing you don't need to disconnect or connect to Peers, you can rely on this system to deliver messages to the appropriate Peer and return their response. If you do need to interact, you can do it via the Controller's CommandChannel

Please note that for the built-in simulation, the factomd node generates "SimPeer" instead of regular Peers. Instead of using the Controller/Connection, SimPeers directly connect to other SimPeers by setting the peer1.BroadcastOut = peer2.BroadcastIn and sending SimPackets, bypassing the network entirely.

Now that that's out of the way, here's the diagram:
TCP.png
I tried to keep the style similar-ish to my other works and I hope that it's intuitive.

Direct link
Source link on draw.io

Clouds are once again areas I didn't go into detail. I'm planning on detailing the NetworkProcessNet in a further post.
Dot-Outlined areas are the entities responsible for this behavior.
Green boxes are Golang channels. The title bar consists of entity.channelname, type, capacity as they are defined with default values.
Top Level Containers are specific functions responsible for reading or sending on channels. I included the function name (minus parameters passed) in the title bar, so you can search the codebase to find out what they do in detail
Containers inside Top Level Containers are either subfunctions or just "steps" that I thought were worth noting.
Lists inside Top Level Containers are the ones with dashed separators and [*] in the title. They're a list of valid message types.

Arrows going to and from channels denote a message being added or read from a channel. I tried to label them as best as I could with the actual message type sent along the path, where asterisks denote multiple types.
Olive arrows mean there's a loop where the Controller adds a message to multiple or all Connections.

The giant orange double ended arrow in the P2PProxy is the place where a SimPeer differs from a regular Peer. Everything to the left of the orange arrow is not in place for a simulated peer.

Still confused? It's a fairly convoluted process and the diagram is definitely a bit hard to understand. That's why I made another one that details two of the basic types of flow, an incoming packet and a control panel command. Each arrow is labeled with the channel being used and the structure sent along it.
TCP-Big.png
Direct link
 
Top