## 3 D2 HCP (Distributed Dynamic Host Configuration Protocol)
### _Timers_  
The wireless and mobile nature of MANET means that there are situations in the networks where messages are lost, or delayed in getting to its destination more than the estimated time. Therefore, we expose below a series of timers used to solve such situations:  
* _SERVER_DISCOVERY_TIMER_: After sending the message, the client node will start this timer when it gets to the state WAITING_REPLY. During this time the node is waiting for SERVER_OFFER messaged of possible close by nodes belonging to a network. The longer the timer runs, the more time it will dedicate to receiving messages of this kind, thus there will be more to process and, therefore, it is easier to get an address block. But it also means increasing the latency to obtain an IP address. If this timer expires and the client node has not received any SERVER_OFFER, there has been a message loss, or perhaps there are no server nodes, it will send a new SERVER_DISCOVERY. This action is repeated a maximum number of times (SDISCOVERY_MAX_RETRY) and, if it goes on without receiving messages, it will initiate its own network. * _SERVER_OFFER_TIMER_: After the SERVER_OFFER message, the node goes into the WAITING_POLL state, and starts this timer. When it expires, the state will change to IDLE. * _SERVER_POLL_TIMER_: As soon as the SERVER_POLL message is sent, the node client will wait for the IP_ASSIGNED message for the time that this timer should determine. If this message does not come, the SERVER_POLL will be re-transmitted up to a maximum number of attempts, defined as SPOLL_MAX_RETRY. If the maximum number of attempts is exceeded, it will begin the configuration process again. * _IP_RANGE_REQUEST_TIMER_: The server node who sends an IP_RANGE_REQUEST message to another node of the network initiates this timer at that moment. As with the SERVER_POLL_TIMER, if this timer expires, the IP_RANGE_REQUEST message will be forwarded up to a maximum number of attempts, given by RREQUEST_MAX_RETRY. Figure 8: IP_RANGE_RETURN message format. * _ACCEPTED_OFFER_TIMER_: This timer is activated after sending an IP_ASSIGNED message or an IP_RANGE_RETURN message. During this time, the server node cannot reply to requests of SERVER_POLL or IP_RANGE_REQUEST type. This restriction will arise after the timer expires (the offer expired without being accepted), or on having detected that a node with the first IP address of the offered ones has entered the network (the offered address block was accepted). It is necessary to bear in mind that although it could not assign IP address, the server node will keep on answering SERVER_DISCOVERY requests giving the value 0 to the field R (READY) in the SERVER_OFFER message. In this way, the node client is informed of the existence of the server, although it should not be capable of assigning IP address immediately. * _NODE_DOWN_TIMER_: When OLSR erases the route towards a node, it is not eliminated immediately from the \(Free\_IP\_Blocks\) table. In its place, this timer is initiated. If before the timer expires it manages to discover a route to the node, that means that it disappeared momentarily, but it did not leave the network. Therefore, the elimination is cancelled on the \(Free\_IP\_Blocks\) table. In case the timer expires and a route has not been recovered, the node is assumed to be lost and its entry is eliminated from the \(Free\_IP\_Blocks\) table, updating those who match. * _INIT_TABLE_TIMER_: On receiving the \(Free\_IP\_Blocks\) auto-configuration table in the IP_ASSIGNED message, the client node activates this timer. During that time, the table contains nodes so that OLSR does not have a well-known route yet. After the timer expires, the nodes from the \(Free\_IP\_Blocks\) table that do not have entries in the OLSR route table are verified: these nodes are eliminated (updating the corresponding entries), since they are nodes that belonged to the network on having received the table, and have left it before OLSR knew of its existence.