2.3.2. With the new velocity update the node locations according to equations 3 and 4. 2.3.3. Distance between each pair of nodes is calculated using equation (5) and E’ is populated according to equation (6). 2.4. If an agent comes to this site/node (MN j ) 2.4.1. If the visit frequency of agent from a particular node (MN k ) reaches threshold then 18.104.22.168. The agent is killed (since it can be an indication of DoS attack.) 22.214.171.124. A message will be broadcast stating MN k to be compromised. 126.96.36.199. Delete the current trust level view stored at MN j . 2.4.2. Otherwise 188.8.131.52. Update the trust level of the nodes as follows. 184.108.40.206.1. If the agent is found to trust a node (MN k ) (has a positive trust level in its PL) then increment the trust value of (MN k ) in the trust level view of MN j by 0.5. 220.127.116.11.2. If the agent is found to suspect a node (MN k ) (has a negative trust level in its PL) then 18.104.22.168.2.1. Kill that agent. 22.214.171.124.2.2. Decrease the trust level of its owner and learn not to migrate an agent via this node. 2.5. If an agent owned by this node comes back containing at most one suspected node in its PL then 2.5.1. Update the results. 2.5.2. Update the trust level view of the network according to the agent’s PL (increase by 0.5 or decrease by +1) 2.5.3. If a node is found to be suspected then learn to avoid the existing route followed by the agents 2.5.4. Kill the agent (Algorithm – I, steps 1.4 and 1.5). 2.6. If the resulting trust level of any node falls below Trust_threshold value then advertise the node id to be a suspected one to the rest of the nodes. V v ∈
136 C. Chowdhury and S. Neogy 2.7. Whenever a message regarding suspected node id is received from a trusted node, then depending on its trust level, the relevant information would be updated. 2.8. The PL for each agent containing trusted node ids is also formed and kept with the owners. 2.9. Deploy the agents. 3. Stop. In step 1.3 of Agent_code(), the secured way of storing means that we assume the hashcode is stored in a way that is not easily understandable/modifiable by a host platform. For example it can be encrypted by the owner and the hashcode calculation may include the encryption key along with the agent’s code. Moreover we assume that the hashcode calculation and matching part (step 1.4 of algorithm I) is stored in such a (secured) manner that it cannot be changed in transit. Further, in the next step (1.4) if the current host platform (where the agent currently resides) is found to be malicious, then most likely the data part of the agent is changed, not the code. So to save network bandwidth and improve performance of MAS, killing of the agent cannot be suggested rather the agent can be asked to move back to its owner (so that the owner may update its trust level accordingly). Because the PL (kept as part of agent’s data) could also be corrupted. Individual node failures are considered in step 2.1 of MN_code(). But we did not consider the fault tolerance of the nodes. In step 126.96.36.199 and 2.5.2 of MN_code(), the trust value is incremented slowly but decremented rapidly from agent’s feedback. This is done to avoid agent migration to compromised sites under all circumstances. A node learns about a suspected area in the network in steps 188.8.131.52.4 and step 2.5.3.
You've reached the end of your free preview.
Want to read all 12 pages?
- Fall '19
- Computer network, Software agent, Men in Black, Mobile ad hoc network, Mobile agent, The Matrix: Path of Neo