Для дальнейшего изучения
Детальное описание RARP можно найти в Finlayson et al[RFC 903]. Finlayson [RFC 906] описывает загрузку системы на рабочей станции с использованием протокола TFTP. Comer[1987] описывает пример реализации RARP для операционной системы Xinu.
Глава 19 рассматривает альтернативу RARP, известную как BOOTP. В отличие от схемы определения низкоуровневого адреса, применяемой в RARP, BOOTP построен на основе протоколов более высокого уровня, таких как IP и UDP. Глава 19 сравнивает эти два подхода, рассматривая преимущества и недостатки каждого.
При загрузке системы бездисковая машина
При загрузке системы бездисковая машина должна связаться с сервером , чтобы определить свой IP-адрес перед тем, как она начнет взаимодействие, используя TCP/IP. Мы рассмотрели протокол RARP, который использует физическую сетевую адресацию для получения межсетевого адреса машины. Механизм RARP применяет физический аппаратный адрес машины для уникальной идентификации процессора и широковещательной передачи запросов RARP. Серверы в сети принимают сообщение, ищут отображение для него в таблице(предварительно загруженной с диска), и отвечают отправителю. Как только машина принимает свой IP-адрес, она запоминает его в памяти и не использует RARP до тех пор, пока она снова не будет загружать систему.
Основные и дублирующие серверы RARP.
Главным преимуществом использования группы машин как серверов RARP является то, что это делает систему более надежной. Если один сервер вышел из строя или перегружен и не может ответить, другой ответит на запрос. Поэтому существует большая вероятность того, что средство будет постоянно доступно. Главный же недостаток использования нескольких серверов заключается в том, что когда машина передает широковещательный запрос RARP, сеть становится перегруженной из-за того, что все серверы пытаются на него ответить. В Ethernetе, например, использование нескольких серверов RARP приводит к высокой вероятности возникновения коллизии.
Как разместить средство RARP так, чтобы оно было надежным и доступным, и при этом не было бы нескольких одновременных ответов? Существует по крайней мере две возможности, и обе они используют паузы при ответе. В первом случае, каждой машине, выдающей запросы RARP, назначается основной сервер. Обычно только основной сервер машины отвечает на ее запросы RARP. Все неосновные серверы принимают запрос, но лишь запоминают время его поступления. Если основной сервер недоступен, пославшая запрос машина будет ждать определенное время ответа, а затем повторно пошлет запрос. А неосновной сервер, получив вторую копию запроса RARP вскоре после первой, ответит на него.
Во втором случае используется аналогичная схема, но делается попытка избежать одновременного ответа всеми неосновными серверами. Каждая неосновная машина, принимающая запрос, выжидает случайное время, а затем посылает ответ. При нормальных условиях основной сервер отвечает сразу же, а последующие ответы будут передаваться через некоторое время, поэтому их появление в одно и то же время маловероятно. Когда основной сервер недоступен, запрашивающая машина подбирает небольшое время для паузы перед приемом ответа. При умелом подборе паузы разработчик может добиться того, что запрашивающие машины не будут повторно передавать широковещательного запроса до получения ответа.
Повторение транзакций RARP
Как и любое взаимодействие в сети с негарантированной доставкой, запросы RARP могут потеряться или исказиться. Так как RARP использует физическую сеть напрямую, никакое другое протокольное программное обеспечение не будет измерять время до получения ответа или повторно передавать запрос; само программное обеспечение RARP должно решать эти задачи. Вообще RARP используется только для локальных сетей, таких как Ethernet, где вероятность сбоя мала. Тем не менее, если сеть имеет только один сервер RARP, то эта машина может не справиться с такой большой нагрузкой, и ряд пакетов может быть потерян.
Многие бездисковые машины рассчитывают на RARP при загрузке и могут повторять запрос до тех пор, пока они не получат ответа. Другие реализации сообщают, что обнаружена неисправность в сети после нескольких неудачных попыток, чтобы избежать переполнения сети ненужным широковещательным траффиком(т.е. в случае, когда сервер недоступен). В Ethernetе сетевая ошибка менее вероятна, чем перегрузка сервера . Заставляя программное обеспечение RARP часто повторять запрос, можно добиться того, что сервер будет буквально захлестнут волной избыточного траффика. В то же время использование большого времени ожидания ответа гарантирует, что у серверов будет достаточно времени для приема запроса и выдачи ответа.
Протокол обратного разрешения адресов(RARP)
Разработчики протоколов TCP/IP сообразили, что есть другая уникально идентифицирующая информация, которая всегда доступна, короче, физический сетевой адрес машины. Использование этого физического адреса как уникальной идентификации имеет два преимущества. Так как ГВМ получает свои физические адреса от сетевого интерфейсного оборудования, такие адреса всегда доступны и не входят в состав кода операционной системы. Так как идентифицирующая информация зависит от сети, а не от модели ЦП, все машины в сети будут поддерживать единообразные, уникальные идентификаторы. Поэтому задача становится обратной по отношению к разрешению адресов: имеется физический сетевой адрес; разработать схему, которая позволяла бы серверу отображать его в межсетевой адрес.
Бездисковая машина использует протокол интернета TCP/IP, называемы RARP(протокол обратного разрешения адресов), для получения своего IP-адреса от сервера. RARP создан на основе протокола ARP из предыдущей главы и использует тот же самый формат сообщений, который приведен на рисунке 5.3. На практике сообщение RARP, посылаемое при запросе межсетевого адреса, является несколько более общим, чем то, что описано выше: оно позволяет машине запрашивать IP-адрес не только себе, но и другим машинам. Оно также допускает несколько типов физических сетей. Как и сообщение ARP, сообщение RARP пересылается с одной машины на другую в поле данных кадра Ethernetа. Кадр Ethernetа, несущий запрос RARP, имеет обычную преамбулу, адреса отправителя и получателя Ethernetа, и поле типа пакета в начале себя. Поле типа содержит значение 8035, что идентифицирует содержимое этого кадра как сообщение RARP. Поле данных кадра содержит 28-октетное сообщение RARP.
Рисунок 6.1 иллюстрирует, как ГВМ использует RARP. Отправитель широковещательно передает запрос RARP, в котором указывает свой адрес в качестве как машины отправителя, так и машины получателя, заполняя поле аппаратного адреса назначения своим физическим сетевым адресом. Все машины в сети принимают запрос, но только те из них, кто отвечает за поддержку RARP, обрабатывают запрос и посылают ответ; такие машины называют серверами RARP. Для успешного использования RARP в сети должен быть по крайней мере один сервер RARP.
-<==-===============================================>-------- ^ | | | | V V V +++++++ +++++++ +++++++ +++++++ + А + + B + + C + + D + +++++++ +++++++ +++++++ +++++++ (a) -----=========================================--------------- | | ^ ^ V | | | +++++++ +++++++ +++++++ +++++++ + А + + B + + C + + D + +++++++ +++++++ +++++++ +++++++ (b)
Рисунок 6. 1 Пример обмена, используя протокол RARP. (a) Машина А посылает широковещательный запрос RARP, указывая себя как машину получателя, и (b) машины, ответственные за поддержку средства RARP(C и D), отвечают прямо А.
Серверы отвечают на запросы, заполняя поля протокольного адреса назначения, меняя тип сообщения на ответ, и посылая ответ прямо машине, выдавшей запрос. Эта исходная машина принимает ответы от всех серверов RARP, несмотря на то, что ей нужен только первый ответ.
Помните, что все взаимодействия между машиной, ищущей свой IP-адрес, и сервером, знающим его, должны осуществляться, используя только одну физическую сеть. Более того, этот протокол позволяет ГВМ запрашивать IP-адрес произвольной машины. Поэтому отправитель указывает свой аппаратный адрес помимо аппаратного адреса получателя, а сервер учитывает это при отправке ответа по аппаратному адресу отправителя. В Ethernetе наличие поля для аппаратного адреса отправителя может показаться лишним, так как эта же информация содержится в заголовке кадра Ethernetа. Тем не менее, не все оборудование Ethernetа позволяет операционной системе получать доступ к заголовку физического кадра.
Сервер RARP может широковещательно
6. 1 Сервер RARP может широковещательно передавать ответы RARP всем машинам или передавать каждый ответ только машине, выдавшей этот запрос. Можно ли назвать систему, в которой применяются широковещательные ответы для всех машин, выгодной?
6.2 RARP является узкоспециализированным протоколом в том смысле, что его ответы содержат всего лишь одну часть информации(т.е. запрошенный IP-адрес). Когда бездисковая машина загружается, ей обычно нужно знать время и имя машины помимо межсетевого адреса. Расширьте RARP для поддержки дополнительной информации.
6.3 Насколько больше станут кадры Ethernetа, если к RARP добавить информацию, описанную в предыдущем примере.
6.4 Добавление второго сервера RARP к сети увеличивает надежность. Имеет ли смысл добавить третий сервер? А четвертый ? Почему да или почему нет ?
6.5 Бездисковые рабочие станции одного производителя используют RARP для получения своих IP-адресов, но всегда предполагают, что ответ приходит от файл-сервера рабочей станции. Затем бездисковая машина пытается получить загрузочный образ от этого сервера. Если она не получает ответа, эта рабочая станция входит в бесконечный цикл широковещательной передачи запросов на загрузку. Объясните, как добавление дублирующего сервера RARP к такой конфигурации может привести к переполнению сети широковещательными запросами. Замечание: обратите внимание на сбои питания.
