Кратко

  • RFC 3074 отображал идентификатор клиента или аппаратный адрес в одно из 256 значений и по общей карте определял DHCP-сервер, который должен обслужить запрос.
  • Документ учитывал недоступного либо лишённого адресов назначенного участника, бесхозные бакеты, неверное время клиента и подменённую карту. Хеш подтверждал правило, но не живую способность обслуживать.

DHCPDISCOVER передаётся широковещательно, поэтому его могут услышать и обслужить несколько серверов. BOOTP-реле способно размножить запрос по всем настроенным направлениям. В феврале 2001 года B. Volz, S. Gonczi, T. Lemon и R. Stevens опубликовали RFC 3074, чтобы убрать лишние ответы: после общей исходной настройки каждый участник независимо получал одинаковое решение «обслуживать / не обслуживать».

Входом служил Service Transaction ID. При наличии Client Identifier требовалось использовать его; иначе hlen задавал длину, а chaddr предоставлял не более шестнадцати байтов. Указанный алгоритм Pearson выдавал число от 0 до 255. Сервер получал 32-октетный Hash Bucket Assignment: установленный бит обязывал его обслужить запрос с соответствующим результатом.

Согласование было настоящим. Одинаковые вход, таблица перемешивания и HBA приводили к одному ответственному без постоянного обмена. Реле могло использовать пары Server-ID/бакет для выбора направления. Клиентам DHCP менять поведение не требовалось.

Но функция не читала текущее состояние. Она не проверяла процесс, маршрут, согласованность базы аренд или наличие подходящего свободного адреса. STID описывал транзакцию, HBA — административную ответственность. Ни то ни другое не было датчиком готовности.

RFC прямо описывает назначенный сервер, который недоступен или исчерпал подходящие адреса. Необязательный Delayed Service разрешает обычно исключённому серверу ответить через S секунд после первой попытки. Первоначальный расчёт не объявляется ложным; после его безрезультатного окна меняется допустимое действие.

Источник времени тоже условен. Ненулевое поле secs следует использовать, но некоторые клиенты реализуют его неправильно. Сервер может запомнить первый отклонённый запрос и измерить промежуток до повтора с тем же transaction ID. В первом случае это заявление клиента, во втором — соединение двух наблюдений. Причину молчания ответственного они не доказывают.

Без Delayed Service карта действует строго. Неназначенный бакет приводит к полному игнорированию транзакции, что в некоторых условиях может быть намеренным. Покрытие поэтому имеет собственный статус: идеальная программа может безошибочно вычислить значение, которое никто не обслуживает.

Процент нагрузки также не является мгновенным измерением. На коротком интервале фактическая доля отклоняется от настройки и приближается к ней с ростом числа запросов. Хеш не видит CPU, очередь, задержку или свободные адреса. Он распределяет идентификаторы, которым нужна достаточная вариативность, но не обязательная уникальность.

Конфигурация входит в исполняемую цепочку. HBA может поступать из файла, реестра Windows NT, EEPROM или согласованного алгоритма и передаваться внутри другого протокола. RFC не даёт собственной защиты. Передаваемую карту необходимо защищать от подмены: изменение бакетов способно отказать в сервисе части или всем клиентам. Одинаковый код не спасает расходящиеся или совместно подменённые карты.

RFC 2131 дополняет контекст: клиент ожидает несколько ответов, а DHCP работает под местной административной политикой. После DISCOVER остаются OFFER, выбор, REQUEST, ACK и применение конфигурации. RFC 3074 оптимизирует право начать ответ, а не гарантирует цепь. RFC 1542 описывает реле, но не доказывает внедрение алгоритма на конкретном устройстве.

Позднейший RFC 7031 назвал несогласованную конфигурацию партнёров частой проблемой и вынес балансировку за пределы ядра DHCPv6 failover. Это не ретроспективный отчёт о внедрении RFC 3074. Он лишь сохраняет различие между распределением входа, синхронизацией состояния и восстановлением после отказа.

Running-Code Primacy выстраивает квитанции: источник STID, бакет, покрытие, сервер, доступность, адрес, поздний перехват, OFFER, выбор, REQUEST, ACK и рабочая конфигурация. Reality Layers отделяет символическую определённость рассчитанного владельца от исполняемого результата. Эти поздние рамки не принадлежат авторам RFC или IETF.

RFC 3074 точно отвечал, кто должен попробовать первым. Его достижение — воспроизводимое распределение без постоянных переговоров. Но присутствие, ёмкость, целостность и успех оставались фактами, которые нужно наблюдать отдельно.

Источники