• Antonio Quartulli's avatar
    batman-adv: improved client announcement mechanism · a73105b8
    Antonio Quartulli authored
    The client announcement mechanism informs every mesh node in the network
    of any connected non-mesh client, in order to find the path towards that
    client from any given point in the mesh.
    
    The old implementation was based on the simple idea of appending a data
    buffer to each OGM containing all the client MAC addresses the node is
    serving. All other nodes can populate their global translation tables
    (table which links client MAC addresses to node addresses) using this
    MAC address buffer and linking it to the node's address contained in the
    OGM. A node that wants to contact a client has to lookup the node the
    client is connected to and its address in the global translation table.
    
    It is easy to understand that this implementation suffers from several
    issues:
     - big overhead (each and every OGM contains the entire list of
       connected clients)
     - high latencies for client route updates due to long OGM trip time and
       OGM losses
    
    The new implementation addresses these issues by appending client
    changes (new client joined or a client left) to the OGM instead of
    filling it with all the client addresses each time. In this way nodes
    can modify their global tables by means of "updates", thus reducing the
    overhead within the OGMs.
    
    To keep the entire network in sync each node maintains a translation
    table version number (ttvn) and a translation table checksum. These
    values are spread with the OGM to allow all the network participants to
    determine whether or not they need to update their translation table
    information.
    
    When a translation table lookup is performed in order to send a packet
    to a client attached to another node, the destination's ttvn is added to
    the payload packet. Forwarding nodes can compare the packet's ttvn with
    their destination's ttvn (this node could have a fresher information
    than the source) and re-route the packet if necessary. This greatly
    reduces the packet loss of clients roaming from one AP to the next.
    Signed-off-by: default avatarAntonio Quartulli <ordex@autistici.org>
    Signed-off-by: default avatarMarek Lindner <lindner_marek@yahoo.de>
    Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
    a73105b8
routing.c 45.5 KB