# Counteracting Selfish Nodes Using Reputation Based System in Mobile Ad Hoc Networks
## 3 Proposed Reputation-Based Scheme
### Design and Modules
#### 3.2.2 The Monitor (C2C Based Detection Mechanism)  
The monitor is the basic component of the proposed scheme, which is responsible for identifying the consumption (send packets), contribution (forward packets for others), and drops packets of each node in the network. Unlike prior methods, in our proposed scheme, the sender, neighbor, and forwarder nodes monitor other nodes in their communication range and calculate the C2C for those nodes in the network. In the following text, three different perspectives from three different nodes viewpoints are discussed while calculating C2C. * Monitoring by the Data Source:  
After a route request (RREQ) and route reply (RREP) process, source node \(S\) (as shown in Figure 1 sends a packet to destination \(D\) via the intermediated node \(F\). It is worth noting that the difference between \(S\) and \(F\) is that \(S\) is the data owner whereas \(F\) is not. Reaching data from \(S\) to \(D\) will benefit both \(S\) and \(D\); for example, suppose \(S\) is the file uploader and \(D\) is the file downloader. However, for \(F\) it is just a community service consuming its battery for the general good. Before delivering the packet to the next-hop \(F\), the sender node \(S\) copies it into a buffer and sets the timer. Due to the broadcast nature of the wireless networks, if the intermediate node \(F\) forwards the packet before the timer expires, the sender node will also receive a copy of it (also called passive acknowledgment). The sender updates the contribution of the forwarder node \(F\) in the C2C table. If the timer expires without a matching packet being received, the sender \(S\) records a packet drop event for \(F\). The monitor then communicates this information to the reputation system for reputation calculation. The process is given in Algorithm 1. * Monitoring by Forwarders:  
After responding to the RREQ of the source node \(S\), the intermediate node \(F\) receives a packet from the sender node. If the sender is a new node, its details are added to the C2C table; otherwise, it is checked in its selfish list. If this node is available in the selfish list, then \(F\) discards the packet. If the sender is not in the selfish list, it updates the consumption node \(S\) (because \(S\) is the data source) and passes it to the reputation module for reputation calculation and threshold checking. Details are given in Algorithm 2. ```
1. Initiate route discovery process
2. Create the RREQ packet
3. Broadcast the RREQ
4. If receive the RREP from the neighbors then
5. Send packet to the next hope, start the timer, and listen to it
6. If overhear the same copy from the next hope then
7. Update the contribution in the C2C table
8. Else
9. Update drop packets
10. End if
11. Else
12. Go to step 2
13. End if
14. Calculate reputation-based on C2C
15. If reputation < threshold then
16. Add next hope to selfish list and go to step 1
17. End if
```  
**Algorithm 1** Reputation calculation for intermediate node (\(F\)) by source node (\(S\))  
Figure 1: Illustration of the proposed scheme, where nodes monitor the C2C of other nodes and calculate the reputation accordingly. * Monitoring by Neighbors: The neighbor node \(M\) can overhear the communication between the sender \(S\) and the forwarder node \(F\). It is notable that \(M\) is a neighbor which only overhears the communication and not acting in the routing path. As the sender node \(S\) sends the packet to the forwarder \(F\), the neighbor node \(M\) saves the overheard copy of the packet in a cache. In the next step, within a certain time threshold, if \(M\) overhears a packet from the forwarder node \(F\), then \(M\) compares this overheard packet with the cached one. If both packets are the same, then \(M\) updates the consumption of the sender node \(S\) and contribution of the \(F\) node in its C2C table. If both packets are not the same, \(M\) updates the consumption of the \(F\) node.