# My Smartphone tattles: Considering Popularity of Messages in Opportunistic Data Dissemination
## 6 Keetchi--Case Studies
### Use Case 1: Meeting in the Office  
When people meet in an office, they usually do so for quite a long time (e.g., an hour). Epidemic will make sure that any two devices exchange their summary vectors and data. Since there is enough time, Epidemic will successfully exchange all messages and, after the re-sync period has expired, will try to re-sync again. This re-sync is not necessary in this case and will waste a lot of resources, but there is no way Epidemic can recognise this situation.  
In contrast, Keetchi starts sending messages directly via broadcast to all devices in the room. More popular messages are sent first, followed by less popular ones (randomly). Since the communication neighbourhood is not changing, it will slow down its sending (recall the _backoff increment factor_), slide its sending distribution down to the least popular items and will eventually stop sending messages. If no new people enter the room, Keetchi will not re-start sending messages. Some of the messages Keetchi sends might be duplicated (refer to Section 5 and Keetchi's mechanism of randomly selecting messages). However, this happens only sporadically. If some new people enter the room, Keetchi will restart sending messages.  
The time Keetchi needs to send all messages in the first round (when the meeting starts) depends on its initial inter-packet interval. We can however determine the number of bytes sent by both Epidemic and Keetchi(see Figure 6a). This is an example of three people meeting with 100 unique packets each. The exact number of bytes exchanged by Epidemic depends on its parameter re-sync period, which can be configured to be high (for very slow mobility scenarios) or low (for very fast mobility scenarios). In this example, the default value of the original Epidemic publication has been considered (300 s). It is evident that in this scenario Keetchi needs between two and three times fewer bytes to exchange the same information.  
**Disseminating popular messages.** If we assume that some part of the messages of the three nodes in our scenario were popular, we can analyse when exactly they will arrive at the other nodes. Epidemic does not take popularity into account and the popular messages will be forwarded at some random time to the other nodes in the room. Keetchi does consider it actively, but non-deterministically (refer to Section 5), so we observe first mostly popular messages being exchanged, then slowly mixing them with  
Figure 6: Behaviour of Keetchi vs. Epidemic in use Case 1 and use Case 2. (**a**) Use Case 1: The induced traffic of Epidemic depends on the total contact length, while Keetchi exchanges data only once in this scenario. (**b**) Use Case 2: While both protocols experience severe problems (due to short contacts), the total number of received packets of Keetchi is much higher than for Epidemic. Furthermore, Keetchi exchanges packets in both directions, while Epidemic works better in one than the other direction.  
unpopular ones and then finally unpopular ones. Thus, in the case this scenario is shorter than assumed here, Keetchi will exchange more popular messages than Epidemic.