Мы уже знаем, что физические сетевые адреса являются как низкоуровневыми, так и аппаратно зависимыми, и мы знаем, что каждой машине, использующей TCP/IP, назначен один или несколько 32-битовых IP-адресов, которые независимы от аппаратных адресов машины. прикладные программы всегда используют IP-адрес при указании назначения. ГВМ и шлюзы должны использовать физические адреса для передачи дейтаграмм по базовым сетям; они полагаются на схемы разрешения адресов, такие как ARP, при выполнении связывания.
Обычно IP-адрес машины хранится во внешней памяти, откуда операционная система и берет его при начальной загрузке. Возникает вопрос: "Как бездисковая машина, не имея доступа к внешней памяти, определяет свой IP-адрес?" Эта проблема является критической для бездисковых станций, использующих IP-адрес для взаимодействия с файл-сервером. Более того, так как много бездисковых машин используют стандартные протоколы передачи файлов TCP/IP для получения начального образа при загрузке, они должны получать и использовать IP-адреса до начала работы операционной системы. Эта глава изучает вопрос о том, как получить IP-адреса, и описывает протокол, который используют бездисковые машины.
Чтобы одна программа могла использоваться на нескольких машинах, в состав ее исполняемого образа не должен входить IP-адрес машины. В частности, разработчики пытаются не включать конкретные IP-адреса как в код начальной загрузки, так и в операционную систему, чтобы один и тот же код мог работать на нескольких машинах. Когда такая программа начинает выполняться на бездисковой машине, она должна использовать сеть для взаимодействия с сервером, чтобы получить от него свой IP-адрес. Эта процедура кажется парадоксальной: машина взаимодействует с удаленным сервером для получения адреса, необходимого для взаимодействия.
Но парадокс здесь только кажущийся, так как машина знает, как взаимодействовать. Она может использовать свой физический адрес для взаимодействия в локальной сети. Поэтому машина должна временно применять физическую сетевую адресацию аналогично тому, как операционные системы применяют физическую адресацию памяти при установке таблиц для виртуальной адресации. Как только машина узнает свой межсетевой адрес, она может взаимодействовать со всем интернетом.
Идея, лежащая в основе нахождения IP-адреса, проста: бездисковая машина посылает запрос другой машине, называемой сервером(глава 18 более детально описывает серверы), и ждет, пока сервер не пошлет ответ. Мы будем предполагать, что сервер имеет диск, на котором он хранит базу данных межсетевых адресов. В этом запросе машина, которой нужно узнать свой межсетевой адрес, должна идентифицировать себя уникальным образом, сервер мог найти ее межсетевой адрес и послать ответ. Как посылающая запрос машина, так и отвечающий ей сервер используют физические сетевые адреса в ходе своего короткого взаимодействия. Но откуда бездисковая машина знает физический адрес сервера ? Обычно она его и не знает - она просто широковещательно передает запрос ко всем машинам в локальной сети. Ей отвечают один или более серверов.
Когда бездисковая машина широковещательно передает запрос, она должна уникальным образом идентифицировать себя. Но какую информацию можно включить в запрос, которая бы уникально идентифицировала машину ? Для этой цели может подойти любая уникальная аппаратная идентификация(например, последовательный номер ЦП). Тем не менее, нам нужна идентификация, которую может получить работающая программа. Наша цель - создать один исполняемый код, который может выполняться на любом процессоре. Более того, длина или формат информации, идентифицирующей ЦП, могут отличаться у различных моделей процессоров, а нам хотелось бы иметь сервер, который принимает запросы от всех машин в физической сети, используя один формат.
Разработчики протоколов 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)
Серверы отвечают на запросы, заполняя поля протокольного адреса назначения, меняя тип сообщения на ответ, и посылая ответ прямо машине, выдавшей запрос. Эта исходная машина принимает ответы от всех серверов RARP, несмотря на то, что ей нужен только первый ответ.
Помните, что все взаимодействия между машиной, ищущей свой IP-адрес, и сервером, знающим его, должны осуществляться, используя только одну физическую сеть. Более того, этот протокол позволяет ГВМ запрашивать IP-адрес произвольной машины. Поэтому отправитель указывает свой аппаратный адрес помимо аппаратного адреса получателя, а сервер учитывает это при отправке ответа по аппаратному адресу отправителя. В Ethernetе наличие поля для аппаратного адреса отправителя может показаться лишним, так как эта же информация содержится в заголовке кадра Ethernetа. Тем не менее, не все оборудование Ethernetа позволяет операционной системе получать доступ к заголовку физического кадра.
Как и любое взаимодействие в сети с негарантированной доставкой, запросы RARP могут потеряться или исказиться. Так как RARP использует физическую сеть напрямую, никакое другое протокольное программное обеспечение не будет измерять время до получения ответа или повторно передавать запрос; само программное обеспечение RARP должно решать эти задачи. Вообще RARP используется только для локальных сетей, таких как Ethernet, где вероятность сбоя мала. Тем не менее, если сеть имеет только один сервер RARP, то эта машина может не справиться с такой большой нагрузкой, и ряд пакетов может быть потерян.
Многие бездисковые машины рассчитывают на RARP при загрузке и могут повторять запрос до тех пор, пока они не получат ответа. Другие реализации сообщают, что обнаружена неисправность в сети после нескольких неудачных попыток, чтобы избежать переполнения сети ненужным широковещательным траффиком(т.е. в случае, когда сервер недоступен). В Ethernetе сетевая ошибка менее вероятна, чем перегрузка сервера . Заставляя программное обеспечение RARP часто повторять запрос, можно добиться того, что сервер будет буквально захлестнут волной избыточного траффика. В то же время использование большого времени ожидания ответа гарантирует, что у серверов будет достаточно времени для приема запроса и выдачи ответа.
Главным преимуществом использования группы машин как серверов RARP является то, что это делает систему более надежной. Если один сервер вышел из строя или перегружен и не может ответить, другой ответит на запрос. Поэтому существует большая вероятность того, что средство будет постоянно доступно. Главный же недостаток использования нескольких серверов заключается в том, что когда машина передает широковещательный запрос RARP, сеть становится перегруженной из-за того, что все серверы пытаются на него ответить. В Ethernetе, например, использование нескольких серверов RARP приводит к высокой вероятности возникновения коллизии.
Как разместить средство RARP так, чтобы оно было надежным и доступным, и при этом не было бы нескольких одновременных ответов? Существует по крайней мере две возможности, и обе они используют паузы при ответе. В первом случае, каждой машине, выдающей запросы RARP, назначается основной сервер. Обычно только основной сервер машины отвечает на ее запросы RARP. Все неосновные серверы принимают запрос, но лишь запоминают время его поступления. Если основной сервер недоступен, пославшая запрос машина будет ждать определенное время ответа, а затем повторно пошлет запрос. А неосновной сервер, получив вторую копию запроса RARP вскоре после первой, ответит на него.
Во втором случае используется аналогичная схема, но делается попытка избежать одновременного ответа всеми неосновными серверами. Каждая неосновная машина, принимающая запрос, выжидает случайное время, а затем посылает ответ. При нормальных условиях основной сервер отвечает сразу же, а последующие ответы будут передаваться через некоторое время, поэтому их появление в одно и то же время маловероятно. Когда основной сервер недоступен, запрашивающая машина подбирает небольшое время для паузы перед приемом ответа. При умелом подборе паузы разработчик может добиться того, что запрашивающие машины не будут повторно передавать широковещательного запроса до получения ответа.
При загрузке системы бездисковая машина должна связаться с сервером , чтобы определить свой IP-адрес перед тем, как она начнет взаимодействие, используя TCP/IP. Мы рассмотрели протокол RARP, который использует физическую сетевую адресацию для получения межсетевого адреса машины. Механизм RARP применяет физический аппаратный адрес машины для уникальной идентификации процессора и широковещательной передачи запросов RARP. Серверы в сети принимают сообщение, ищут отображение для него в таблице(предварительно загруженной с диска), и отвечают отправителю. Как только машина принимает свой IP-адрес, она запоминает его в памяти и не использует RARP до тех пор, пока она снова не будет загружать систему.
Детальное описание RARP можно найти в Finlayson et al[RFC 903]. Finlayson [RFC 906] описывает загрузку системы на рабочей станции с использованием протокола TFTP. Comer[1987] описывает пример реализации RARP для операционной системы Xinu.
Глава 19 рассматривает альтернативу RARP, известную как BOOTP. В отличие от схемы определения низкоуровневого адреса, применяемой в RARP, BOOTP построен на основе протоколов более высокого уровня, таких как IP и UDP. Глава 19 сравнивает эти два подхода, рассматривая преимущества и недостатки каждого.
6.1 Сервер RARP может широковещательно передавать ответы RARP всем машинам или передавать каждый ответ только машине, выдавшей этот запрос. Можно ли назвать систему, в которой применяются широковещательные ответы для всех машин, выгодной?
6.2 RARP является узкоспециализированным протоколом в том смысле, что его ответы содержат всего лишь одну часть информации(т.е. запрошенный IP-адрес). Когда бездисковая машина загружается, ей обычно нужно знать время и имя машины помимо межсетевого адреса. Расширьте RARP для поддержки дополнительной информации.
6.3 Насколько больше станут кадры Ethernetа, если к RARP добавить информацию, описанную в предыдущем примере.
6.4 Добавление второго сервера RARP к сети увеличивает надежность. Имеет ли смысл добавить третий сервер? А четвертый ? Почему да или почему нет ?
6.5 Бездисковые рабочие станции одного производителя используют RARP для получения своих IP-адресов, но всегда предполагают, что ответ приходит от файл-сервера рабочей станции. Затем бездисковая машина пытается получить загрузочный образ от этого сервера. Если она не получает ответа, эта рабочая станция входит в бесконечный цикл широковещательной передачи запросов на загрузку. Объясните, как добавление дублирующего сервера RARP к такой конфигурации может привести к переполнению сети широковещательными запросами. Замечание: обратите внимание на сбои питания.
Назад | Содержание | Вперед