UDP: Destination port = 204 9

UDP: Length = 124

UDP: No checksum

UDP:

RPC: -- SUN RPC header --

RPC:

RPC: Transaction id = 641815012

RPC: Type = 0 (Call)

RPC: RPC version = 2

RPC: Program = 100003 (NFS), version = 2

RPC: Procedure = 4 (Look up file name)

RPC: Credentials: authorization flavor = 1 (Unix)

RPC: len = 32, stamp = 642455371

RPD: machine = atlantis

RPC: uid = 0, gid = 1

RPC: 1 other group id(s) :

RPC: gid 1

RPC: Verifier: authorization flavor = 0 (Null)

RPC: [Verifier: 0 byte(s) of authorization data]

RPC:

RPC: [Обычное завершение заголовка 'SUN RPC'.]

RPC:

NFS: -- SUM NFS --

NFS:

NFS: [Параметры для процедуры 4 (Look up file name) follow]

NFS: File handle = 0000070A00000001000A0000000091E3

NFS: 5E707D6A000A0000000044C018F294BE

NFS: File name = README

NFS:

NFS: [Обычное завершение 'SUN NFS'.]

NFS:

Рис. 15.6. Формат сообщения RPC с запросом к NFS

Заметим, что запрос RPC имеет тип сообщения 0. Ответ будет иметь тип 1. Протокол RPC периодически обновляется, поэтому в сообщении указывается версия RPC (в нашем случае это версия 2).

Вызывающая сторона использует мандат Unix, определяющий реальные идентификаторы пользователя и группы (userid и groupid). Имеется дополнительный идентификатор группы. Штампом служит произвольный идентификатор, созданный вызывающей стороной. Поле проверочных сведений аутентификации имеет оттенок 0 (не обеспечивает никакой дополнительной информации). NFS часто реализуется с частичной аутентификацией, поскольку более полная зашита снижает производительность.

За идентификатором программы 100003 (NFS) и процедуры 4 (просмотр имен файлов) следуют параметры: описатель файла (file handle) и имя файла.

Описатель файла — это специальный идентификатор, связанный с каталогом или файлом сервера. В версии 2 протокола RPC описатель файла представлен строкой фиксированной длины в 32 бита, в версии 3 он задается строкой переменной длины с максимальной длиной в 64 бита. В запросе указан файл README, расположенный в каталоге, идентифицированном описателем файла.

Поля в сообщении запроса кодируются по правилам форматирования XDR (см. следующий раздел).

Мы можем получить представление о работе XDR, рассмотрев некоторые шестнадцатеричные коды в сообщении запроса:

Тип сообщения = 0, кодируется (в шестнадцатеричных значениях) как:

00 00 00 00

Версия RPC = 2, кодируется как:

00 00 00 02

Машина = atlantis, кодируется как:

(длина строки =8) atlantis

00 00 00 08 61 74 6С 61 6E 74 69 73

RPC: -- SUN RPC header --

RPC:

RPC: Transaction id = 641815012

RPC: Type = 1 (Reply)

RPC: Status = 0 (Accepted)

RPC: Verifier: authorization flavor = 0 (Null)

RPC: [Verifier: 0 byte(s) of authorization data]

RPC: Accept status = 0 (Success)

RPC:

RPC: [Обычное завершение заголовка 'SUN RPC' .]

RPC:

NFS: -- SUN NFS --

NFS:

NFS: Proc = 4 (Look up file name)

NFS: Status = 0 (OK)

NFS: File handle = 0000070A00000001000A000000005AC9

NFS:               3298621C000A0000000044C018F294BE

NFS: File type = 1 (Regular file)

NFS:  Mode = 0100644

NFS:  Type = Regular file

NFS:  Owner's permissions = rw-

NFS:  Group's permissions = r-

NFS:  Others; permissions = r-

NFS: Link count = 1, UID = 303, GID = 1

NFS: File size = 130, Block size = 8192, No. of blocks = 2

NFS: File system id = 1802, File id = 23241

NFS: Access time = 23-Oct-95 16:35:01 GMT

NFS: Modification time = 20-Oct-95 12:10:43 GMT

NFS: Inode change time = 20-Oct-95 12:10:43 GMT

NFS:

NFS: [Обычное завершение 'SUN NFS'.]

NFS:

Рис. 15.7. Формат сообщения RPC с ответом от NFS

В показанном на рис. 15.7 ответе присутствует тот же идентификатор транзакции. Указана нулевая аутентификационная информация. Запрос был принят, и его обработка завершилась успешно. Ответ содержит много полезной информации о файле README: