Двухэтапный процесс начальной загрузки

В протоколе ВООТР используется двухэтапный процесс начальной загрузки. При этом клиенту не передается образ содержимого памяти для выполнения, а только информация, необходимая для получения этого образа. Поэтому, чтобы получить образ содержимого памяти, клиент должен воспользоваться другим протоколом (например, описанным в главе 26, "Приложения: передача файлов и удаленный доступ к ним (FTP, TFTP, NFS)", протоколом TFTP). Хотя двухэтапный процесс может показаться излишним, он позволяет провести четкую границу между процессом конфигурации устройства и хранением данных. Сервер протокола ВООТР не обязательно должен запускаться на той же машине, где хранятся образы содержимого памяти. Чаще всего сервер протокола ВООТР получает информацию из простой базы данных, в которой находится информация только об именах файлов, содержащих образ содержимого оперативной памяти.

Разделение конфигурационных данных и программ начальной загрузки является весьма важным моментом, поскольку это позволяет администраторам сконфигурировать большое число машин так, чтобы они работали одинаково и независимо друг от друга. Для этого в ответное сообщение протокола ВООТР введено специальное поле имени загрузочного файла. Предположим, что в локальной сети существует несколько рабочих станций с разным типом аппаратного обеспечения, при загрузке которых пользователи могут запустить либо систему UNIX, либо одну из локальных операционных систем. Поскольку рабочие станции имеют разную аппаратную архитектуру, для них нельзя создать один загрузочный файл, содержащий образ памяти. Для решения этой проблемы используется поле имени загрузочного файла ВООТР-запроса. При отправке запроса рабочая станция может поместить в него некое обобщенное имя, например "unix", что означает следующее: "Я хочу загрузить операционную систему UNIX на этой машине". Получив такой запрос, сервер протокола ВООТР обращается к своей конфигурационной базе данных и преобразует обобщенное имя в имя загрузочного файла, содержащего образ памяти системы UNIX, который соответствует типу аппаратного обеспечению клиента. При формировании ответа на запрос сервер помещает в поле имени загрузочного файла полностью определенное имя этого файла. Конечно, конфигурационная база данных также позволяет автоматизировать процесс начальной загрузки рабочей станции. Если клиент помещает в поле имени загрузочного файла нули, то сервер протокола ВООТР подбирает соответствующий этой машине файл образа оперативной памяти. Преимущество метода автоматической начальной загрузки заключается в том, что она позволяет пользователям определять обобщенные имена файлов, которые работают на любой машине. Таким образом, пользователям не нужно запоминать конкретные имена файлов в зависимости от структуры аппаратного обеспечения.

Поле, определяемое производителем

В поле, формат которого определяется производителем оборудования, помещается дополнительная информация, передаваемая сервером клиенту. Хотя структура этого поля довольно замысловатая, в ней легко разобраться. Первые четыре октета этого поля называются магическим сигналом (magic cookie) и определяют формат остальных элементов. В описанном в этом разделе стандартном формате используется значение магического сигнала 99.130.83.99 (в точечном десятичном представлении). После магического сигнала следует список элементов, каждый из которых содержит однооктетное поле типа, необязательное однооктетное, поле длины и состоящее из нескольких октетов поле значения3. В стандарте определено несколько типов, которые имеют заранее определенные, фиксированные значения длины (табл. 23.1). Поле длины должно обязательно присутствовать для типов 1 и 2, и отсутствовать для типов 0 и 255.


Хотя компьютер может получить информацию о маске подсети с помощью ICMP-запроса, в действующем стандарте рекомендуется, чтобы серверы протокола ВООТР включали эту информацию в каждое ответное сообщение. В результате этого отпадает необходимость в дополнительных ICMP-сообщениях для определения маски подсети.

Во всех дополнительных элементах, помещаемых в поле, определяемое производителем оборудования, также используется TLV-кодирование. Каждый элемент состоит из октета типа, октета длины и значения. В табл. 23.3 перечислены возможные варианты, причем некоторые из них имеют переменную длину.

Похожие статьи Меню Опрос Фото Популярное