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

14.9.1 Протокол TFTP

Сеанс TFTP начинается запросами Read Request (запрос чтения) или Write Request (запрос записи). Клиент TFTP начинает работу после получения порта, посылая Read Request или Write Request на порт 69 сервера. Сервер должен идентифицировать различные номера портов клиентов и использовать их для последующей пересылки файлов. Он направляет свои сообщения на порт клиента. Пересылка данных производится как обмен блоками данных и сообщениями ACK.

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

14.9.2 Элементы данных протокола TFTP

В 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 (октет).

14.9.3 Варианты TFTP

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

14.9.4 Сценарий TFTP

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

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

14.10 Дополнительная литература

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

Глава 15 RPC и NFS

15.1 Введение

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

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

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

15.1.1 Назначение NFS

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

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

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

15.1.2 Соотношения между NFS, RPC и XDR

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

Стандарт внешнего представления данных (eXternal Data Representation — XDR) является важной частью архитектуры RPC. XDR включает язык описания типов данных и методы их кодирования в стандартный формат. Это позволяет производить обмен данными между компьютерами различных типов, например между хостами Unix, PC, Macintosh, системами VAX VMS компании Digital Equipment Corporation и большими ЭВМ компании IBM.

15.1.3 RPC как стандарт Интернета

Компания Sun Microsystems опубликовала RFC с описанием RPC в 1988 г., a NFS — в 1989 г. Однако Sun контролировала эти протоколы вплоть до 1995 г., пока не появились новые версии. С этого момента ответственность за RFC архитектуры ONC перешла к комитету IETF, а сама архитектура была принята в качестве стандарта для процессов Интернета. Sun взаимодействовала с консорциумом X/Open при разработке новой версии NFS.

15.1.4 Реализации NFS и RPC

NFS и RPC были реализованы многими разработчиками систем Unix, а также перенесены во многие лицензированные операционные системы. Например, IBM VM, IBM MVS и DEC VAX VMS могут работать как файловые серверы NFS.

Некоторые разработчики объединили программное обеспечение клиента и сервера NFS с собственными продуктами TCP/IP, в то время как другие предоставляли NFS за дополнительную плату. Во многих продуктах NFS содержится программная библиотека для RPC.