udhcp详解（八）——udhcpd.c的执行主线
udhcpd中调用各个模块完成dhcp服务器功能。
udhcpd执行首先是读入了DHCPD_CONF_FILE的配置文件，完成全局变量server_config的初始化工作。
之后将进程的pid加锁独占性地写入到文件中。再之后通过接口名，完成服务器接口索引MAC地址和IP地址的读取工作。
在调用daemon之后，再次写入dhcpd的pid。调用daemon之后将服务器进程设置为了守护进程在后台执行，但是其pid发生了变化，故此要再次写入。在文件中保存pid，是为了方便地查看到dhcp服务器守护进程的pid。
再之后创建了一个全双工管道，signal_pipe，并且设置了信号SIGUSR1和SIGTERM的捕捉函数signa_handler。之后进程阻塞select。等待管道数据的到来或是报文的到来。
这里服务器设计的函数比较巧妙的，试想一下，若客户端长时间不发送请求过来，而服务器这边我们想将内存中的租赁信息写入到文件中，那么该怎么办？服务器进程阻塞在select导致后续的操作不能够进行。
服务器这边使用的方法是，向进程发送信号，在信号捕捉函数里面向singalpipie管道无阻塞地写入信号，这样，服务器就不会阻塞于select了。同时后续代码也对接收到的数据进行了处理。
if (FD_ISSET(signal_pipe[0], &rfds)) {/*信号到达那么则进行处理*/
if (read(signal_pipe[0], &sig, sizeof(sig)) < 0)
continue; /* probably just EINTR */
switch (sig) {
case SIGUSR1:/*收到SIGUSR1立即写租约*/
LOG(LOG_INFO, "Received a SIGUSR1");
write_leases();
/* why not just reset the timeout, eh */
timeout_end = time(0) + server_config.auto_time;
continue;
case SIGTERM:/*收到SIGTERM服务器立即退出*/
LOG(LOG_INFO, "Received a SIGTERM");
exit_server(0);
}
}
至于服务器后续的一些操作就是正常的状态机的转移操作了，并不难理解。
而客户端那边与服务器大致类似。
最后，说一下，本udhcp的实现版本，和rfc所描述的dhcp差距还是挺大的，它只是简简单单的实现了dhcp功能。很多功能，没有实现，这其中大致有如下几点：
1）只提供了IP地址的动态分配，不支持自动分配和手动分配；
2）服务器在为客户端找到可用IP后，并不使用PING探测该IP的可用性，而是直接使用ARP进行探测，这样当客户端获得服务器分配的IP地址后，就直接使用了，并不再次广播ARP报文；
3）当目前该版本并没有实现对于选项过载的支持，但可以通过扩展实现对其的支持；
不提供DHCP安全功能，DHCP Snooping功能等；
4）客户机永远不会主动释放IP；
5）客户机重启后，直接再次发送DHCPOFFER而不是DHCPREQUEST。
若要实现其他一些它原本就不存在的功能，就的自己进行扩展。在弄懂代码和熟知RFC2131和2132的情况下，扩展其实还是不难的。
更过信息请参见;
dhcp协议有限状态机
RFC2131:
http://www.ietf.org/rfc/rfc2131.txt
本人享有博客文章的版权，转载请标明出处http://blog.csdn.net/baidu20008