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

■ Требуется ли прерывать выполнение запроса RPC к NFS при длительном ожидании ответа.

■ Реализована ли в NFS одна из версий системы безопасности RPC.

Команда mount приводит к отправке на сервер запроса RPC с именем Add Mount Entry (добавить точку монтирования). В ответе на это сообщение протокол монтирования возвращает описатель файла, который клиент будет использовать для идентификации каталога в последующих запросах . Вспомним, что описателем является строка, содержащая идентификатор сервера и соответствующего каталога или файла. Например, когда происходит монтирование /users как локального каталога /usr , в ответе на запрос монтирования будет возвращен описатель файла для каталога /users .

Процедуры, поддерживающие программу mount на сервере, показаны в таблице 15.4.

Таблица 15.4 Процедуры монтирования

В NFS требуется как можно большая независимость сервера. Сервер NFS должен хранить как можно меньше сведений о клиенте, чтобы при крахе клиента или сервера восстановление было простым и безболезненным.

Клиент знает, что сервер NFS берет на себя всю работу по обслуживанию запроса и выводу ответа. Однако часто NFS работает поверх протокола UDP, не обеспечивающего целостности информации. Что делать, если на запрос не приходит ответ? NFS просто повторяет запрос после интервала тайм-аута.

Иногда случается так, что исходный запрос попадает на сервер, но ответ на этот запрос теряется. Для таких случаев сервер NFS не придерживается полной независимости от клиента и кеширует самые последние ответы для вывода их на дублированные запросы.

На какие из запросов следует кешировать ответы? Некоторые операции (например, чтение или просмотр ) являются равномощными (idempotent), т.е. при многократном выполнении они формируют тот же самый результат. Другие операции (например, удаление файла или создание каталога ) — не являются равномощными. При потере исходного результата выполнение повторного запроса на операцию приведет только к бессмысленному сообщению об ошибке. Понятно, что кешировать следует операции, не являющиеся равномощными: это позволит NFS формировать корректный ответ на повторные запросы.

Последней реализацией NFS является версия 3, хотя продолжают успешно применяться реализации версии 2. Программа NFS сервера имеет номер 100003 и, по соглашению, NFS захватывает при инициализации порт 2049.

Когда клиент монтирует каталог, протокол возвращает ему описатель файла (file handle), который должен идентифицировать данный каталог в последующих запросах клиента. Монтируемый каталог может содержать подкаталоги, имеющие, в свою очередь, собственные подкаталоги, и т.д. Возможно, путь к файлу будет содержать несколько уровней вложенности. Например, перед тем как клиент сможет изменить файл:

/usr/john/book/chapter3

необходимо получить описатель данного файла с сервера. Для этого NFS выполняет последовательный поиск (одно перемещение по дереву за каждый запрос). Для нашего файла клиент должен:

■ Послать на сервер запрос на просмотр описателей файлов каталога /users и указать имя John . В ответе будет возвращен описатель каталога /users/john .

■ Послать на сервер запрос на просмотр описателей файлов каталога /users/john и указать имя book . Сервер возвратит описатель для /users/john/book .

■ Послать на сервер запрос на просмотр описателей файлов каталога /users/john/book и указать имя chapter3 . В ответе будет содержаться описатель нужного файла.

Таким образом, для получения описателя файла клиент NFS должен отправить несколько запросов.