Контрольная работа: Автоматизированная настройка TCPIP BOOTP Динамическая настройка DHCP
Сервер ВООТР, находящийся в локальной сети, может ответить на запрос клиента ВООТР. Будет ли в этом сообщении использоваться IP-адрес клиента?
Иначе говоря, может ли сервер ВООТР послать направленный ответ? Все зависит от реализации сервера ВООТР.
Сервер знает IP-адрес клиента, хранящийся в базе данных конфигурации ВООТР. Почему же он не может использовать этот адрес для посылки направленного ответа клиенту? Дело в том, что в момент отправки сервером запроса ARP на получение аппаратного адреса клиента ВООТР клиент ответить не может. Почему? Потому что он еще не знает своего IP-адреса. Сервер ВООТР получает аппаратный адрес клиента из заголовка канального уровня в сообщении клиента ВООТР. Реализация сервера ВООТР может добавить запись с информацией о клиенте ВООТР в кэш ARP (рис.3 "Изменение кэша ARP сервером ВООТР"). При наличии такой записи сервер ВООТР может использовать направленный ответ.
Модификация кэша ARP используется в реализации ВООТР для BSD Unix.
Если сервер ВООТР не изменяет содержимое кэша ARP, ответ рассылается в широковещательном режиме.
1.3 Потеря сообщений ВООТР
В своей работе ВООТР использует протоколы UDP и IP, не гарантирующие доставки сообщений. В результате возможна потеря, задержка, дублирование или нарушение последовательности сообщений ВООТР. Поскольку контрольная сумма IP обеспечивает проверку целостности только заголовка, но не поля данных, реализация ВООТР может потребовать активизации контрольной суммы UDP, защищающей от ошибок во всем сообщении ВООТР.
При отправке запросов клиент ВООТР устанавливает флаг запрета фрагментации (DF), чтобы упростить обработку ответов ВООТР, а также на случай нехватки памяти для сбора фрагментированных дейтаграмм.
Для борьбы с потерей сообщений в ВООТР используется механизм тайм-аута с повторной передачей. Отправляя запрос, клиент ВООТР запускает таймер.
Если ответ ВООТР будет получен до истечения интервала тайм-аута, отсчет прекращается; в противном случае ВООТР передает запрос заново.
Одновременный запуск нескольких клиентов ВООТР может привести к переполнению сети широковещательными запросами ВООТР. Чтобы этого не произошло, в спецификации ВООТР рекомендуется использовать случайную задержку, начальная продолжительность которой составляет от нуля до четырех секунд. При каждой последующей повторной отправке интервал удваивается до тех пор, пока он не достигнет достаточно большой величины (например, 60 секунд). При достижении верхней границы продолжительность интервала перестает удваиваться, но случайная задержка в итоговом интервале продолжает применяться. Внесение случайной задержки помогает предотвратить одновременное поступление запросов со стороны клиентов ВООТР, повышающих нагрузку на сервер и порождающих конфликты пакетов в Ethernet. Удвоение продолжительности случайного интервала предотвращает перегрузку сети многочисленными широковещательными запросами со стороны многих клиентов ВООТР.
1.4 Формат сообщения ВООТР
На рис.4 "Формат сообщения BOOT" изображена структура сообщения ВООТР. Отдельные поля сообщения описаны в табл.1 "Поля сообщений ВООТР".
|
Поле |
Длина в октетах |
Описание |
|
ор |
1 |
Тип сообщения: 1 - запрос (BOOTREQUEST), 2 - ответ (BOOTREPLY) |
|
htype |
1 |
Тип аппаратного адреса. Значения совпадают со значениями аналогичного поля в пакетах ARP. Например, код 1 соответствует сети Ethernet 10 Мбит/с |
|
hlen |
1 |
Длина аппаратного адреса в октетах. Аппаратные адреса Ethernet и Token Ring имеют длину 6 байт |
|
hops |
1 |
Поле обнуляется клиентом ВООТР. Может использоваться агентом-ретранслятором, работающим на маршрутизаторе, при пересылке сообщений ВООТР |
|
К-во Просмотров: 369
Бесплатно скачать Контрольная работа: Автоматизированная настройка TCPIP BOOTP Динамическая настройка DHCP
|