В процессе DHCP DORA сервер предлагает клиенту IP-адрес с сообщением DHCPOFFER. Почему клиент должен снова отправить явное сообщение DHCPREQUEST серверу? Почему бы не отправить туда сообщение DHCPACCEPT и не получить IP-адрес?
Я думаю, что необходимость в обоих сообщениях имеет смысл, если несколько DHCP-серверов предлагают IP-адреса клиенту. Клиент может выбрать любой из предложенных IP-адресов, после чего остальные серверы отзовут свое предложение. Но что, если в моей среде есть только 1 DHCP-сервер?
Краткий ответ: это просто вопрос наименования. Думайте о DHCPREQUEST как о DHCPACCEPT, и вы увидите, что они делают то же самое.
Поведение сервера указано в RFC 2131. Пары сообщений:
DHCPDISCOVER -> DHCPOFFER
DHCPREQUEST -> DHCPACK
Вы предлагаете добавить новое сообщение DHCPACCEPT, которое будет делать именно то, что делает DHCPREQUEST сейчас (обратите внимание, что вы все равно должны установить 'xid', временную метку ...). И это новое сообщение должно по-прежнему соответствовать протоколу типа запрос-ответ, к которому принадлежит DHCP, так что вы получите что-то вроде:
DHCPDISCOVER -> DHCPOFFER
DHCPACCEPT -> DHCPACK
В чем будет преимущество? Вам все еще нужен DHCPACK (это сообщение, которое фактически устанавливает адрес, см. диаграмма состояний для клиента).
Это будет просто новый тип сообщения (например, добавление DHCPEXTENDLEASE, его можно было бы легче читать, но вы добавляете возможные состояния и переходы без особой выгоды). И теоретические DHCPACCEPT, и DHCPEXTENDLEASE уже обрабатываются DHCPREQUEST. Они берут предложение с сервера, добавляют несколько полей (важный шаг) и принимают его. А потом иметь дождаться подтверждения от сервера.