Detecting changes

Whenever changes are being made to entries that causes updates of the topology or neighborhood understanding, the function responsible for these changes must also signal that such changes have been made. This is done by setting one of the the global variables changes_topology or canges_neighborhood to UP. These variables are declared in the olsr.h header-file. Setting changes_topology causes all routes, including MPR calculation and HNA routes as described later, to be recalculated. Setting canges_neighborhood causes MPR selection to be recalculated in addition to all routes and HNA routes. Recalculation of only the HNA routes as explained in section 7.1.3, can be triggered by the global variable changes_hna.

These variables are processed at every scheduler poll in the function olsr_process_changes defined in olsr.h. If routes needs to be recalculated immediately, a function can call the olsr_process_changes function directly. This is necessary in some situations, like when changes have occurred in the neighborhood. If these changes lead to changes in registered MPR selectors, the MPR selector set should be updated prior to processing the next message. And since the message processing functionality holds the mutex used by the scheduler, no scheduler poll will occur, recalculating the MPR set, until all messages in the current packet has been processed. Therefore the function calls olsr_process_changes directly, to ensure that possibly remaining messages are forwarded using updated MPR selectors.