udhcp 상세 정보 (8)-udhcpd.c의 실행 메인 라인

udhcpd에서 각 모듈을 호출하여dhcp 서버 기능을 완성합니다.
udhcpd 실행은 우선 DHCPD_를 읽었습니다.CONF_FILE 구성 파일, 글로벌 변수 서버 완료_config의 초기화 작업입니다.
이후 프로세스의pid 자물쇠를 독점적으로 파일에 기록합니다.그 다음에 인터페이스 이름을 통해 서버 인터페이스 인덱스 MAC 주소와 IP 주소를 읽는 작업을 완성합니다.
데몬을 호출한 후dhcpd의pid를 다시 씁니다.데몬을 호출한 후 서버 프로세스를 백그라운드에서 실행하도록 설정했지만 pid가 바뀌었기 때문에 다시 써야 합니다.파일에 pid를 저장하는 것은dhcp 서버 수호 프로세스의 pid를 쉽게 보기 위해서입니다.
 
그 다음에 전이중 파이프를 만들었습니다.signal_pipe, 신호 SIGUSR1 및 SIGTERM 스냅 함수 설정signa_handler.이후 프로세스가 select를 막습니다.파이프 데이터가 도착하거나 메시지가 오기를 기다립니다.
여기 서버 디자인의 함수는 비교적 교묘합니다. 클라이언트가 장시간 요청을 보내지 않고 서버에서 메모리에 있는 임대 정보를 파일에 쓰려면 어떻게 해야 합니까?서버 프로세스가 select에 막혀서 후속 작업을 진행할 수 없습니다.
서버에서 사용하는 방법은 프로세스에 신호를 보내고 신호 포착 함수에서singalpie 파이프에 신호를 막힘 없이 기록하면 서버가 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) 클라이언트가 재부팅되면 DHCPREQUEST가 아닌 DHCPOFFER를 다시 보냅니다.
 
원래 존재하지 않았던 다른 기능을 실현하려면 스스로 확장해야 한다.코드를 이해하고 RFC2131과 2132를 숙지하는 상황에서 확장은 어렵지 않다.
 
자세한 내용은 를 참조하십시오.
dhcp 프로토콜 유한 상태기
RFC2131:
http://www.ietf.org/rfc/rfc2131.txt
본인은 블로그 글의 판권을 누리고 있으니, 전재하여 출처를 밝혀 주십시오http://blog.csdn.net/baidu20008