Implementation overview

Implementing relatively large projects in C can often be quite messy, but when the project is done by one person, consistent coding-styles and design principals can be achieved.

Throughout the code some main design principals are followed:

• Modularity - All code that can bee seen as a generic mechanism used by other entities should be implemented as modular as possible. This, in many cases, means that entities using these functions should dynamically register themselves with the function. An example of this is the scheduling functionality. Entities that wishes to generate messages on a regular interval should register a message generation function with the scheduler to be called regularly on a given interval.

  This kind of modularity becomes very important when dealing with plugins as described in chapter 8. Plugins are code that is loaded at runtime to extend a program.

• Consistent data-structures - In a table-driven protocol most of the computing done will be processing on tables. This means that most of the code will be related to lists of different kinds. Regardless of what kind of data structuring scheme is being used, this should be consistent. This means that as far as reasonable, all tables should have the same structure.

• IP transparency - The daemon should be able to operate on either IPv4 or IPv6 addresses. This means that the compiled code should be able to run in either IPv4 or IPv6 mode. So all functions and data-types treating IP addresses must be implemented to handle both 32-bit IPv4 addresses and 128-bit IPv6 addresses. This should be as transparent as possible, meaning that as much as possible (and reasonable) of the code should work on both IPv4 and IPv6 addresses. In cases where separate functions are made for IPv4 and IPv6 operation, a wrapper function should be implemented.

• Readable code - The code should be easy to read for an outsider. This is probably not always accomplished as a coder often tends to have an incredibly subjective view of his/her own code.

• Platform independent code - Platform dependent code should be separated from the rest of the code in a modular fashion, and it should be made available through a well defined interface. This way, implementing those functions for other platforms should be as easy as possible.

Figure: olsrd main overview.

The OLSR daemon implementation is illustrated in figure 5.1. The different entities are explained briefly here. They will be reviewed in detail in later sections.

• Socket parser - The socket parser checks for incoming traffic using a select(2) loop. It then calls the function associated with the sockets that has incoming data. Sockets and their corresponding functions are registered at run-time.

• Packet parser - The packet parser receives all incoming OLSR traffic. Even though the parser has several responsibilities, it basically has three options when it comes to treating a message:
  • Discard the packet. This is done if the packet is found to be invalid.
  • Process the packet according to given instructions. To do this, the parser has to be capable of treating this message-type.
  • Forward the packet according to the default forwarding algorithm. This is done if the packet is valid but the parser has no knowledge of this message-type.

  The entity to which a received message is sent, is responsible for updating the information repositories needed if the information is considered fresh enough and has not already been processed.

  Parse functions for messages are registered with the packet parser at run-time.

• Information repositories - The tables are the heart of a table driven routing protocol. Here fresh information is kept and all calculations of routes and packets are done based on these repositories.

  In these tables the information needed to at minimum describe the current state of the network, and this nodes immediate links, is kept. The various packet parsing functions both update these tables and relies on information in these tables to be able to process the messages. The forwarding functionality in particular, relies on the duplicate table which is a cache of all recent processed and/or forwarded packets.

  All these tables are regularly timed out. This means that entries no longer considered valid are removed. Whenever these databases are updated in a way that changes the understanding of the network topology, the routes are recalculated.

• Scheduler - The event scheduler runs different events at different intervals. To transmit a message at a given interval, one can register a packet generation function with the scheduler. Timing out of tables is also triggered by the scheduler. To maintain an information repository that is timed out on a regular basis, one can register a timeout function with the scheduler.

  The scheduler runs in a thread of its own and shared memory is protected using a mutex so that the packet creation entity does not have to consider synchronization and memory-protection.