Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

Каждый блок (за исключением последнего) должен иметь размер в 512 октетов данных и завершаться EOF (конец файла). Если длина файла кратна 512, то заключительный блок содержит только заголовок и не имеет никаких данных. Блоки данных нумеруются от единицы. Каждый ACK содержит номер блока данных, получение которого он подтверждает.

В TFTP существуют пять типов элементов данных:

■ Read Request (RRQ, запрос чтения)

■ Write Request (WRQ, запрос записи)

■ Data (DATA, данные)

■ Acknowledgment (ACK, подтверждение)

■ Error (ERROR, ошибка)

Сообщение об ошибке указывает на события, подобные таким: "файл не найден" или "для записи файла на диске нет места".

Каждый заголовок TFTP начинается операционным кодом, идентифицирующим тип элемента данных протокола (Protocol Data Unit — PDU). Форматы PDU показаны на рис. 14.6.

Рис. 14.6.Форматы элементов данных TFTP

Отметим, что длина Read Request и Write Request меняется в зависимости от длины имени файла и полей режима, каждое из которых представляет собой текстовую строку ASCII, завершенную нулевым байтом. В поле режима могут присутствовать netascii (сетевой ASCII) или octet (октет).

Улучшенный вариант TFTP разрешает согласование параметров через предварительные запросы чтения и записи. Его основная цель — позволить клиенту и серверу согласовывать между собой размер блока, когда он больше 512 байт (для увеличения эффективности пересылки данных).

Работу протокола TFTP можно проиллюстрировать простым сценарием. На рис. 14.7 показано, как в TFTP реализуется чтение удаленного файла. После отправки запрашиваемой стороной блока данных она переходит в режим ожидания ACK на посланный блок и, только получив этот ACK, посылает следующий блок данных.

Рис. 14.7.Чтение удаленного файла в TFTP

Протокол FTP определен в RFC 959, a TFTP — в RFC 1350.

За последние десять лет компьютерное оборудование существенно изменилось. Вместо подключенных к центральному компьютеру неинтеллектуальных терминалов появились сложные настольные системы, серверы и локальные сети.

Пользователи быстро поняли преимущества персональных систем, но вместе с тем возникла необходимость доступа к общесетевой информации и совместно используемым, или разделяемым, принтерам. Это привело к появлению должности сетевого администратора — лица, ответственного за конфигурирование, обслуживание и резервное копирование. Современный системный администратор должен координировать переход на новые версии программного обеспечения, отслеживать использование ресурсов, планировать резервное копирование информации и конфигурировать сетевые параметры большого числа компьютеров.

За несколько лет многие организации пришли к необходимости перевода сетевых операционных систем в режим разделения ресурсов и централизации управления. Чуть позже вычисления клиент/сервер подняли уровень сетевого взаимодействия до прикладных приложений.

Компания Sun разработала сетевую файловую систему (Network File System — NFS) для поддержки разделения ресурсов служб рабочих станций Unix в локальных сетях. NFS делает удаленный каталог с файлами частью локальной структуры каталогов — конечные пользователи и программы обращаются к удаленным файлам так же, как и к файлам из каталогов локально подключенного диска. NFS дает множество преимуществ.

Например, на сервере можно хранить единственную копию программного обеспечения или важных данных, которая доступна всем пользователям сети. Изменения будут проводиться в одном месте (на сервере), а не на каждой из рабочих станций пользователей. На рис. 15.1 показана локальная сеть с одним центральным сервером, обеспечивающим службу NFS.

Рис. 15.1.Сервер NFS в локальной сети

NFS работает поверх вызовов удаленных процедур (Remote Procedure Call — RPC). RPC был разработан в начале использования приложений клиент/сервер. В этой главе мы познакомимся со службами NFS и архитектурой открытых сетевых вычислений (Open Network Computing — ONC), на основе которой реализуется RPC.