Rarp(обратный протокол определения адреса)
Когда загружается система с локальным диском, она обычно получает свой IP адрес из конфигурационного файла, который считывается с диска. Однако для систем, не имеющих диска, таких как X-терминалы или бездисковые рабочие станции, требуются другой способ определения собственного IP адреса.
Каждая система в сети имеет уникальный аппаратный адрес, который назначается производителем сетевого интерфейса (сетевой платы). Принцип работы RARP заключается в том, что бездисковая система может считать свой уникальный аппаратный адрес с интерфейсной платы и послать RARP запрос (широковещательный фрейм в сеть), где потребует кого-нибудь откликнуться и сообщить IP адрес (с помощью RARP отклика).
Несмотря на то что концепция довольно проста, ее реализация как правило значительно сложнее чем ARP.
RARP запрос является широковещательным, а RARP отклик обычно персональный (Рис.25).
Рис.25
Отправитель широковещательно передает запрос RARP, в котором указывает свой адрес в качестве как машины отправителя, так и машины получателя, заполняя поле аппаратного адреса назначения своим физическим сетевым адресом. Все машины в сети принимают запрос, но только те из них, кто отвечает за поддержку RARP, обрабатывают запрос и посылают ответ; такие машины называют серверами RARP. Для успешного использования RARP в сети должен быть по крайней мере один сервер RARP.
Серверы отвечают на запросы, заполняя поля протокольного адреса назначения, меняя тип сообщения на ответ, и посылая ответ прямо машине, выдавшей запрос. Эта исходная машина принимает ответы от всех серверов RARP, несмотря на то, что ей нужен только первый ответ.
Все взаимодействия между машиной, ищущей свой IP-адрес, и сервером, знающим его, должны осуществляться, используя только одну физическую сеть. Более того, этот протокол позволяет пользователю запрашивать IP-адрес произвольной машины. Поэтому отправитель указывает свой аппаратный адрес помимо аппаратного адреса получателя, а сервер учитывает это при отправке ответа по аппаратному адресу отправителя.
Функцию RARP-сервера в сети выполняет специальная станция, которая может установить соответствие между физическим и логическим адресами станций. Обычно это соответствие устанавливается при помощи специальных динамических таблиц, в которых каждой станции по её физическому адресу ставится в соответствие логический – сетевой адрес. Таким образом, информационное взаимодействие при выполнении протокола RARP состоит из следующих этапов:
Получение RARP запроса от рабочей станции
RARP-сервер определяет значение МАС-адреса
RARP-сервер определяет по таблице значение сетевого адреса
RARP-сервер формирует кадр RARP ответ (reply)
Очевидно, что использование одной рабочей станции в качестве RARP-сервера не может обеспечить достаточной надежности. Станция, которая выполняет данную функцию в сети, может выйти из строя, или может быть слишком перегружена для того, чтобы вовремя ответить на RARP запрос. Поскольку ответ на запрос не будет получен, станция, которая сформировала запрос, будет вынуждена повторять его снова и снова. Единственным выходом из данной ситуации может быть резервирование RARP-сервера.
Простое резервирование (например, дублирование) этих устройств может привести к возникновению дополнительных трудностей. К таким трудностям, в частности, относится возможность возникновения коллизий при одновременном ответе на RARP запрос двумя RARP-серверами. Для разрешения этой проблемы должно быть проведено ранжирование серверов на первичный и вторичные. Для предотвращения коллизий в данном случае может быть использовано две схемы:
Задержка ответа вторичного RARP-сервера на такт
Задержка ответа вторичного RARP-сервера на случайный отрезок времени
При использовании первой схемы в сети может только один вторичный RARP-сервер, который отвечает на RARP запрос только в том случае, если он был послан повторно. Очевидно, что использование данной схемы не позволяет избежать возникновения коллизии в том случае, когда первый запрос был потерян из-за временной перегрузки первичного RARP-сервера или вследствие возникновения проблем в канале передачи на физическом уровне.
При использовании второй схемы в сети могут находиться несколько вторичных RARP-серверов. Каждый из этих вторичных серверов отвечает на RARP запрос по прошествии интервала времени, величина которого определяется случайным образом. Очевидно, что в данном случае, вероятность возникновения коллизий при ответе вторичных серверов существенно уменьшается.