From dae3b91ebc53f2806e1ffabc5eb1130e18bf40a6 Mon Sep 17 00:00:00 2001 From: Pavel Boyko Date: Fri, 30 Oct 2009 13:00:24 +0300 Subject: [PATCH] [aodv] Cosmetics --- .../manet/aodv/aodv-routing-protocol.cc | 2 +- src/routing/manet/aodv/aodv.h | 39 +++++++++++-------- 2 files changed, 23 insertions(+), 18 deletions(-) diff --git a/src/routing/manet/aodv/aodv-routing-protocol.cc b/src/routing/manet/aodv/aodv-routing-protocol.cc index 277515734..aeb07b0b5 100644 --- a/src/routing/manet/aodv/aodv-routing-protocol.cc +++ b/src/routing/manet/aodv/aodv-routing-protocol.cc @@ -465,7 +465,7 @@ RoutingProtocol::NotifyInterfaceUp (uint32_t i) Ptr wifi = dev->GetObject (); if (wifi == 0) return; - Ptr mac = wifi->GetMac ()->GetObject (); + Ptr mac = wifi->GetMac (); if (mac == 0) return; diff --git a/src/routing/manet/aodv/aodv.h b/src/routing/manet/aodv/aodv.h index 569382848..96587e236 100644 --- a/src/routing/manet/aodv/aodv.h +++ b/src/routing/manet/aodv/aodv.h @@ -36,9 +36,9 @@ * This model implements the base specification of the Ad hoc on demand distance vector (AODV) * protocol. Implementation is based on RFC3561. * - * Class aodv::RoutingProtocol implements all functionality of service packet exchange and inherit from - * Ipv4RoutingProtocol. Base class defines two virtual functions for packet routing and forwarding. The first, - * RouteOutput(), is used for locally originated packets, and the second, RouteInput(), is used for forwarding + * Class aodv::RoutingProtocol implements all functionality of service packet exchange and inherits Ipv4RoutingProtocol. + * Base class defines two virtual functions for packet routing and forwarding. The first one, + * RouteOutput(), is used for locally originated packets, and the second one, RouteInput(), is used for forwarding * and/or delivering received packets. * * Protocol operation depends on the many adjustable parameters. Parameters for this functionality are attributes of @@ -46,34 +46,39 @@ * protocol features, such as broadcasting HELLO messages, broadcasting data packets and so on. * * AODV discovers routes on demand. Therefore, our AODV model buffer all packets, while a route request packet (RREQ) - * is disseminated. We implement a packet queue in aodv-rqueue.cc. In reality, smart pointer to packet, Ipv4RoutingProtocol::ErrorCallback, + * is disseminated. We implement a packet queue in aodv-rqueue.cc. Smart pointer to packet, Ipv4RoutingProtocol::ErrorCallback, * Ipv4RoutingProtocol::UnicastForwardCallback and IP header are stored in this queue. The packet queue implements garbage collection of old - * packets and a queue limit. + * packets and a queue size limit. * * Routing table implementation support garbage collection of old entries and state machine, defined in standard. * It implements as a STL map container. The key is a destination IP address. * * Some moments of protocol operation aren't described in RFC. This moments generally concern cooperation of different OSI model layers. * We use following heuristics: - * 1) This AODV implementation can detect the presence of unidirectional links,and avoid them if necessary. - * If the node we received a RREQ for is a neighbor we are probably facing a unidirectional link... This is feature can be disable. + * + * 1) This AODV implementation can detect the presence of unidirectional links and avoid them if necessary. + * If the node we received a RREQ for is a neighbor we are probably facing a unidirectional link... + * This heuristic is taken from AODV-UU implementation and can be disabled. + * * 2) Protocol operation strongly depends on broken link detection mechanism. We implements two such heuristics. - * Firstly, this implementation support HELLO messages. However HELLO messages are not a good way to do neighbor sensing + * First, this implementation support HELLO messages. However HELLO messages are not a good way to do neighbor sensing * in a wireless environment (at least not over 802.11). Therefore, you may experience bad performance when running over wireless. * There are several reasons for this: - * a) HELLO messages are broadcasted. In 802.11, broadcasting is done at a lower bit rate than unicasting, + * -# HELLO messages are broadcasted. In 802.11, broadcasting is done at a lower bit rate than unicasting, * thus HELLO messages travel further than data. - * b) HELLO messages are small, thus less prone to bit errors than data transmissions. - * c) Broadcast transmissions are not guaranteed to be bidirectional, unlike unicast transmissions. - * Secondly, we use layer 2 feedback. Link considered to be broken, if frame transmission results in a transmission failure for all retries. - * This mechanism meant for active links and work much more faster, than first method. + * -# HELLO messages are small, thus less prone to bit errors than data transmissions. + * -# Broadcast transmissions are not guaranteed to be bidirectional, unlike unicast transmissions. + * Second, we use layer 2 feedback when possible. Link considered to be broken, if frame transmission results in a transmission + * failure for all retries. This mechanism meant for active links and work much more faster, than first method. + * Layer 2 feedback implementation relies on TxErrHeader trace source, currently it is supported in AdhocWifiMac only. + * * 3) Duplicate packet detection. We use special class dpd::DuplicatePacketDetection for this purpose. * * Following optional protocol optimizations aren't implemented: - * 1) Expanding ring search. - * 2) Local link repair. - * 3) RREP, RREQ and HELLO message extensions. - * This technique require direct access to IP header, which contradict assertion from AODV RFC that AODV works over UDP. Our model use UDP + * - Expanding ring search. + * - Local link repair. + * - RREP, RREQ and HELLO message extensions. + * This techniques require direct access to IP header, which contradict assertion from AODV RFC that AODV works over UDP. Our model use UDP * for simplicity, but this disable us to implement protocol optimizations. We don't use low layer raw socket, because they are not portable. * */