Analysis of the Application Case of the Routing Protocol

For the network, we use the routing protocol for effective network optimization. Next, we will elaborate on the application solutions for the routing protocol of the ovv. We hope that you can get reference from the following articles. In order to avoid wasting bandwidth and energy, determining whether the next hop is within its transmission range and the next hop wants to receive this package is very beneficial for the sender of a data packet. to verify that the next hop is receiving data, the local connection must be monitored. notifications that cannot send data to neighbors must be immediately notified that the route path of the source node is truncated; otherwise, the node continues to send data packets, this is a waste of resources. In the routing protocol, RERR is used to notify the source node and all nodes on the disconnected link. Because other solutions are not effective immediately, so now all the application solutions use Hello messages. Unfortunately, Hello messages have poor performance in many common joints [3, 10 ｡

Comparison of the application scheme of the routing protocol in the last 8 days

There are a lot of Routing Protocol application solutions, including Mad-hoc [8], AODV-UCSB [2], AODV-UU [9], and AODV-UIUC [6]. Each application solution is independently improved and designed, but they do the same operation and many internal operations ｡

The earliest publicly available and effective put is Mad-hoc. The Mad-hoc application solution relies entirely on the user layer and uses the Snoop policy to determine the put event. Unfortunately, it has many bugs (bugs ), it leads to incorrect execution of the Protocol. These problems are related to its use of ARP. Another feature defect of the Mad-hoc application is the proper queuing of data packets during route searching.. Mad-hoc is no longer actively studied, supported or valid ｡

The first release of the AODV-UCSB was the use of kernel modification policies. AODV-UCSB applications were developed before Netfiler was developed. We found that it encountered many intermittent problems, which originated from our particular post-modification. some unpredictable problems. After Netfilter is mature, AODV-UCSB is updated with Nerfilter. AODV-UCSB uses the AODV-UUv0.4's Netfilter kernel module. With these kernel modules, all the packets of interest can be processed through the user layer daemon process, as described in section2.3. In addition, the description of the basic Octa version is as follows, A large number of Hello messages are available. These include receiving a variety of Hello messages before the neighbor connection. This avoids routing to the neighbor based on a single false message reception ｡

AODV-UU uses a similar AODV-UCSB design. It is also the use of kernel modules to use the netfilter mounting function. The main Protocol logic is established in the user layer daemon process. AODV-UU is also used for NS-2 simulation. allow all real application code to run in this simulation environment. The author also adds many additional features, it is not a draft of some routing protocols, but an increase in the performance of Hello messages [10] (for example, one-way link support and signal quality at the first end of the received packet, AODV-UU also includes Internet gateway and a variety of network interface support. Since the AODV-UU has been good proof of its advantages, and can run on the simulation machine, A large number of modifications are effective for future function expansion (such as multicast and subnetworks )｡

Kernel-Oscar utilizes Netfilter and all the routing protocol logic are in the Kernel module. Therefore, the daemon process at the user layer is not used. This enhances its application performance, during packet processing, no packets need to be transferred from the kernel to the user layer. This application scheme also supports Internet gateway, multiple network interfaces and a basic multicast protocol. When a specific Wireless hardware is used, the proc file also monitors the signal strength of the neighbor ｡

AODV-UIUC applications use the Netfilter package through adhocsupplibrary Library (ASL) [6]. This design is very similar to AODV-USCB and AODV-UU, in addition to its strict distinction between routing and forwarding functions, the routing protocol logic replaces the user-layer daemon, while routing and forwarding are processed in the kernel, because the forwarding packet is processed immediately and almost no packet passes through the kernel to the user layer ｡

All the applications discussed use the Hello hour to determine the local connection and detection link disconnection. In addition, all applications (out of the Mad-hoc) support extended routing ring search and optimized local repair [11].

Conclusion

In this article, we have analyzed the possible design of a Routing Protocol application. We first defined several events not supported by the routing function. We checked the advantages of the three policies that determine these messages. and disadvantages. This analysis supports the conclusion of our user-layer daemon process that contains small kernel modules. Finally, I have listed the effective design of the application. We hope that the message in this article will help researchers understand the outdated phenomenon in the development of the application of adhoc routing protocol? (Trade-offs). Furthermore, the description of the design structure and the characteristics of each other application can help to support deciding which application solution is suitable for their needs ｡