The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Каталог документации / Раздел "Сети, протоколы, сервисы" / Оглавление документа

previous up down next index index
Previous: 4.5.15 Диалог в локальных сетях и в Интернет    UP: 4.5.8 Поиск узлов и людей
Down: 5 Диагностика локальных сетей и Интернет
    Next: 4.5.17 Сетевое моделирование

4.5.16 Некоторые другие процедуры Интернет
Семенов Ю.А. (ГНЦ ИТЭФ)

NFS

NFS (network file system, sun microsystems, RFC-1094) обеспечивает прозрачный доступ к удаленным файлам так, что с точки зрения программиста эти файлы выглядят, как местные. При этом даже в написании имен файлов никак не проявляется их истинное местонахождение. NFS является частью операционной системы. Различие работы с местными и удаленными файлами проявляется лишь на системном уровне. Пользователь может почувствовать различие лишь по времени выполнения соответствующих операций обмена. nfs поддерживает операции по созданию, переименованию, копированию и стиранию файлов или каталогов и т.д.

Основой системы NFS является вызов удаленных процедур RPC, схема взаимодействия "клиент-сервер". NFS-сервер получает запросы от клиента в виде UDP-дейтограмм через порт 2049 (Рис. 4.5.16.1).

Рис. 4.5.16.1. Схема реализации nfs-системы клиент-сервер

RPC (Remote Procedure Call, RFC-1057) процедура, разработанная SUN microsystem, в настоящее время используется практически во всех системах, базирующихся на UNIX. RPC - это программа, которая реализует вызов удаленных подпрограмм, способствуя построению распределенных программ. Она позволяет программе, называемой клиентом, послать сообщение серверу. Далее программа-клиент ожидает сообщения-отклика. RPC работает совместно с универсальной системой представления внешней информации XDP (External Data Representation). Сообщение запрос содержит параметры, которые определяют, что должно быть сделано на удаленной ЭВМ. В свою очередь отклик несет в себе информацию о результатах выполнения запроса.

RPC может работать как на TCP, так и UDP транспортных уровнях. Использование RPC-техники упрощает программирование, так как не требует написания сетевых программ. Если используется протокол UDP, все что связано с обработкой тайм-аутов, повторных пересылок и пр. спрятано в внутри системных RPC-модулей. Формат RPC-запроса для UDP-версии показан на рис. 4.5.16.2.

Рис. 4.5.16.2. Формат RPC-запроса

Поле идентификатор процедуры устанавливается программой-клиента, пакет-отклик использует тот же идентификатор, что позволяет контролировать их соответствие. Каждый новый RPC-запрос имеет новый идентификатор. В настоящее время номер версии rpc равен 2. Следующие три поля содержат переменные: номер программы, номер версии и номер процедуры, которые определяют тип запрашиваемой клиентом процедуры. В поле идентификатор клиента может быть записан цифровой код клиента, идентификатор группы или вообще ничего. Поле верификатор используется при пересылке зашифрованных сообщений. Формат параметров процедуры зависит от типа этой процедуры. Размер поля параметров равен длине UDP-дейтограммы минус сумма длин остальных полей, включая верификатор. В случае работы с TCP-сегментами, где длина пакета не определена, между TCP-заголовком и XID вводится 4-x октетное поле длины RPC-сообщения. Формат RPC-отклика для UDP-версии (Рис. 4.5.16.3):

Рис. 4.5.16.3. Формат RPC-отклика

Поле отклик, содержащее 1, указывает на то, что данное сообщение представляет собой отклик на поступивший ранее запрос. Поле статус содержит 0 в случае, если запрос воспринят. Запрос игнорируется при конфликте кодов RPC-версии или неудачной идентификации клиента. Поле флаг результата принимает значение 0 при успешной обработке запроса. Ненулевое значение этого поля указывает на ошибку.

Для записи параметров RPC-запросов, откликов, параметров и результатов выполнения процедуры используется внешнее представление данных (XDR - External Data Representation, RFC-1014). Отправитель, формируя RPC-сообщение, использует XDR-формат, а получатель преобразует данные из этого формата в традиционное представление.

Существует два базовых вида отклика: MSG_ACCEPTED (сообщение принято) и MSG_DENIED (не принято). Факт приема сообщения не означает выполнение запрошенных процедур, поэтому клиенту выдается дополнительная информация о результатах взаимодействия его запроса с удаленной системой. RPC может найти применение при построении больших распределенных информационных систем, баз данных и систем управления. XDR позволяет программисту избежать написания специальных программ преобразования. Например, в разных ЭВМ используются различные форматы представления чисел с плавающей запятой. XDP берет на себя согласование форматов и делает написание прикладных программ машинно-независимым.

Программы RPC-сервера используют большое число портов с нестандартизованными номерами. Для управления использованием этих портов имеется специальная программа (portmapper), которая имеет номер 100000, номер версии -2 и сама пользуется портом номер 111. Распределение номеров портов можно посмотреть с помощью программы:

/usr/etc/rpcinfo -p

program

vers

proto

port

 

[программа

версия

протокол

порт

название программы]

100000

2

tcp

111

portmapper

100000

2

udp

111

portmapper

100029

1

udp

664

keyserv

100005

1

udp

702

mountd (монтирует демон для NFS)

100005

2

udp

702

mountd

100005

1

tcp

705

mountd

100005

2

tcp

705

mountd

100003

2

udp

2049

nfs (сама NFS)

100026

1

udp

714

bootparam

100024

1

udp

717

status

100024

1

tcp

719

status

100021

1

tcp

720

nlockmgr (NFS-менеждер)

100021

1

udp

1031

nlockmgr

100021

3

tcp

724

nlockmgr

100021

3

udp

1032

nlockmgr

100010

1

udp

718

etherstatd

100020

2

udp

1033

llockmgr

100020

2

tcp

729

llockmgr

100021

2

tcp

732

nlockmgr

100021

2

udp

1034

nlockmgr

100011

1

udp

1041

rquotad

100001

2

udp

1042

rstatd

100001

3

udp

1042

rstatd

100001

4

udp

1042

rstatd

100002

1

udp

1043

rusersd

100002

2

udp

1043

rusersd

100012

1

udp

1044

sprayd

100008

1

udp

1045

walld

Отсюда видно, что некоторые программы имеют несколько версий, а каждая комбинация номера программы, версии и протокола имеет свой собственный номер порта. В таблице 4.5.16.1 приведены ссылки на некоторые RPC-программы, используемые с NFS.

Таблица 4.5.16.1. Коды программ, используемых в NFS

Назначение программы

Номер программы

Номер версии

Номер процедуры

Менеджер портов (port mapper)

100000

2

4

NFS

100003

2

15

Монтировщик

100005

1

5

Менеджер блокировки

100021

1,2,3

19

Статус-монитор

100024

1

6

Монтировщик вызывается NFS-клиентом для обеспечения доступа к файловой системе сервера. Взаимодействие с файловой системой производится с помощью указателей файлов (handle), которые для версии 2 требуют 32 байт, а для версии 3 - 64 байт. Хотя NFS с самого начала была сориентирована на применение UDP (что было оправдано для локальных сетей), в настоящее время она в равной мере использует и TCP. Это позволяет NFS работать уже в масштабе всего Интернет. Третья версия NFS предполагает увеличение числа байт на одну команду READ или WRITE с 8192 до 65535 (ограничение, связанное с размером IP-дейтограммы). Увеличена в третьей версии и предельная длина файлов, которая задается уже 64-, а не 32-битным числом.

RLOGIN (RFC-1281) - процедура удаленного доступа, реализованная в 4BSD UNIX. RLOGIN позволяет администратору сети определить список ЭВМ, авторизация и доступ к которым является общими. Пользователь может организовать групповой доступ к разным ЭВМ, где он авторизован, сохраняя для себя возможность общения с любой из машин, не вводя каждый раз пароль. Одной из реализаций RLOGIN является RSH. RSH включает в себя интерпретатор команд. Форма обращения имеет вид: RSH имя_ЭВМ команда. RLOGIN позволяет взаимодействовать как с внутренними, так и с внешними ресурсами сети и с этой точки зрения предоставляет большие возможности чем Telnet.

REXECD представляет собой резидентную управляющую программу (демон), которая позволяет исполнять команды на удаленной ЭВМ в рамках TCP/IP сетей. Команда, выданная одной ЭВМ, может быть выполнена на другой ЭВМ, при этом автоматически, если необходимо, осуществляется процедура авторизации. REXECD использует TCP в качестве транспортной среды. Существуют реализации для сред UNIX, AIX и DOS.

Previous: 4.5.15 Диалог в локальных сетях и в Интернет    UP: 4.5.8 Поиск узлов и людей
Down: 5 Диагностика локальных сетей и Интернет    Next: 4.5.17 Сетевое моделирование




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру