As already mentioned above, Gossip Protocols are executed periodically, that is, in cycles. That's what the word cycle in the simulator means. It will rotate in every cycle. Don't worry if don't understand it. You'll see how it works really soon.
Ok, and what about the equation? The equation is an aproximation. It will show you how many cycles the gossip protocol needs to spread the information to every node. If you want to see a converge simulator that takes into account packet loss, node failures, etc. Take a look here.
Ok, let's start playing the simulator. Select a node. Go ahead, click on any of them. The node should be red now because it's infected, as defined in one of the most influential papers .
This node wants to share the information. But what nodes should it share with? click on 'show paths'. Those are the nodes it is linked to. So, does each node have a partial view of the other nodes? It could have a complete list but that would make the protocol difficult to scale (think of thounsands/millions of nodes). Please read  if you want to learn more.
Go on to the next part
Ok. It will send the info to those nodes, right? No! The number of nodes is set by the fanout property. Click on 'Random selection' to see the nodes it's going to share the info with. If you click several times, you'll see that they're selected randomly.
Great! Now, let's send the info. Click in "Send Message".
Once a message arrives to the destination, that node is infected too. As we've already mentioned, once a node is infected, it will try to share the information again with other nodes.
Click on "Send Message" again.
Cool!, right? Every infected node tries to share the information.
It's time to see it in action. Press "Restart" to clear everything then click on any node and press "Play".
How many cycles did it take?It's likely that the number of cycles the equation predicts won't be the same. Don't worry! That's normal. Keep in mind that the nodes are selected randomly so a node could posibly be selected twice.
Gossip Protocols are scalable because in general, it takes O(logN) rounds in order to reach all nodes. Also each node sends only a fixed number of messages regardless of the number of nodes in the network. A node does not wait for acknowledgments, and it doesn’t take any recovery action if an acknowledgment does not arrive. . A system can easily scale to millions of processes. Updates spread in expected time that grows logarithmic with the number of participating nodes, even in the face of node failures and message loss.
We're going to see this in action but let's restart the simulator.
Change the nodes to 80 and press "Apply". Ohh.. Did you see it?
We've doubled the number of nodes and, according to the equation, it will take only once more cycle. That's cool, right?
Let's see this in action. Select a node and click play
Now, let's try it with 120. Wow! So for 40 nodes it takes 2.66 cycles and 3.45 for 120. That's pretty cool. It means it scales logarithmically.
Gossip Protocols have the ability to operate in networks with irregular and unknown connectivity . They work really well in these situations because a node shares the same information several times to different nodes. So, if a node is not accesible, the information is shared anyways via a different route. In other words, there are many routes by which information can flow from its source to its destinations
Ok, let's see it. As before, restart the simulator first.
We're going to delete some links. This means that some nodes are not going to be able to communicate with some nodes.
Click on a node and on "Show Paths". Then click "Delete" and start clicking on some paths.
We're going to repeat the same but with more nodes. Now this is very important Press "Delete" again to disable it because otherwise you will remove nodes too. That's something we'll take a look at in the next step.
Ok. Repeat it with more nodes and the select one node and press "Play"
Pretty cool, right? It converges even though some nodes weren't visible to some others.
No node plays a specific role in the network so a failed node will not prevent other nodes from continuing to send messages . Each node can join or leave whenever it pleases without seriously disrupting the system’s overall quality of service . However, these protocols are not robust in all circumstances such as, for example, with Byzantine errors. If the problem is related to a malfunctioning or malicious node then gossip is not robust at all.
Ok, let's see how this works. As before, restart the simulator first.
Now we're going to delete some nodes. When a node detects that other is down, it will share that information in the next cycle.
Press "Delete" and start clicking on some nodes to delete them.
Once you're done, press "Delete" again to disable it. Then select one node to infect it and press "Play"
Yeaah! It converges again even though some nodes were down.
If you take a look at the code, you won't see a real implementation of a Gossip protocol. This is because there is no reason for it. The goal of this simulator is to help people understand how they work not how they're implemented. If we really wanted to do it, we would need to implement a transport layer to mimic tcp or udp. The best idea would be to use the messages as transport layer. In my github, you can see a real implementation in clojure here&here
In the simulator, all the nodes seem to be synchronized as if there was one global cycle. This happens in the simulator because is easier for the visualization. However, this is NOT what happens in a real gossip protocol where each node has its own cycle and there is not synchronization at all.
How do the nodes know about each other? That's a good question!
There are several ways depending on the implementation. For example, in HyParView , when a node wishes to join the overlay, it must know another node that already belongs to the overlay. That node is called the contact node. In Gossip protocolsi, when two nodes exchange information, they also exchange the list of nodes thet have. In that way, the view that each node has is updated in every cycle.
 Ken Birman. The Promise, and Limitations, of Gossip Protocols. SIGOPS Oper. Syst. Rev., 41(5):8–13, October 2007
 A. Demers, D. Greene, C. Hauser, W. Irish, J. Larson, S. Shenker, H. Sturgis, D. Swinehart, and D. Terry. “Epidemic Algorithms for Replicated Database Maintenance.” In Proc. Sixth Symp. on Principles of Distributed Computing, pp. 1–12, Aug. 1987. ACM.
 JELASITY, M., GUERRAOUI, R., KERMARREC, A.-M., AND VAN STEEN, M. 2004. The peer sampling service: Experimental evaluation of unstructured gossip-based implementations. In Middleware 2004, H.-A. Jacobsen, Ed. Lecture Notes in Computer Science, vol. 3231. Springer-Verlag, 79–98.
 S. Voulgaris, M. Jelasity, M. van Steen, A Robust and Scalable Peer-to-Peer Gossiping Protocol,Lecture Notes in Computer Science (LNCS), vol. 2872 (Springer, Berlin/Heidelberg, 2004), pp. 47–58. doi:10.1007/b104265
 J. Leita ̃o, J. Pereira, and L. Rodrigues. Hyparview: a membership protocol for reliable gossip-based broadcast. In Proceedings of the Internacional Conference on Dependable Systems and Networks (DSN), Edinburgh, UK, June 2007.