Глава 1 Введение ───────────────────────────────────────────────────────────── О сетевой файловой системе (NFS) Сетевой фон Функционирование сети Архитектура сети и уровни протоколов Как NFS вписывается в сеть Архитектура NFS Поток запросов Примеры работы NFS Прозрачность NFS Интерфейсы NFS Особенности NFS Об этом руководстве Структура данного руководства Терминология Соглашения, принятые в данном руководстве О сетевой файловой системе (NFS) ───────────────────────────────────────────────────────────── Сетевая файловая система SCO NFS является программным продук- том, позволяющим производить монтирование каталогов в сети и трактовать удаленные файлы как локальные. NFS разработана корпо- рацией Sun Microsystems в качестве стандарта обмена данными между различными машинами и операционными системами. При поддержке кор- порации Lachman Associates система NFS была реализована в опера- ционной среде UNIX и XENIX. Настоящее руководство предназначено для программистов, созда- ющих прикладные программы, которые пользуются услугами NFS. Дан- ный раздел описывает особенности и архитектуру NFS и содержит план изложения материала в руководстве. Тем читателям, которые впервые знакомятся с сетевыми понятиями и терминами, мы рекомен- дуем прочитать раздел целиком. Опытные же сетевые программисты могут пропустить раздел "Сетевой фон", проглядеть разделы "Архи- тектуры NFS" и "Особенности NFS" и прочитать раздел "Об этом ру- ководстве". Сетевой фон ───────────────────────────────────────────────────────────── Поскольку NFS функционирует в сети, вам следует познакомиться с принципами работы сети и механизмом передачи данных по сети. Функционирование сети ───────────────────── Распределенная сеть машин, такая как на Рисунке 1-1, может обеспечить более агрегированную производительность вычислительно- го оборудования по сравнению с большой ЭВМ. Сетевая обработка данных вообще более эффективна, нежели централизованная обработ- ка. Тем не менее, даже в сетевой среде совместное использование программ и данных может быть связано с некоторыми трудностями. Для этого нужно либо копировать файлы на каждую машину, работаю- щую с ними, либо регистрировать пользователей на той удаленной машине, где эти файлы расположены. Регистрация в сети требует времени, а многократное копирование одного и того же файла приво- дит в дальнейшем к несоответствию между собой тех копий, в кото- рые вносились изменения. Для того, чтобы решить эту проблему, была разработана распре- деленная файловая система, позволяющая клиентским системам обра- щаться к файлам, принадлежащим удаленной системе. Клиентские ма- шины запрашивают ресурсы других машин, называемых серверами. Сер- верная машина открывает доступ к конкретным файловым системам, а клиентские машины монтируют эти системы как локальные. Таким об- разом, пользователи работают с удаленными файлами словно они рас- положены на локальной машине. ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ │ рабочая станция 2 │ │ рабочая станция 3 │ │ рабочая станция 4 │ └─────────┬─────────┘ └─────────┬─────────┘ └─────────┬─────────┘ │ │ │ ┌─────────┴─────────────────────┴─────────────────────┴─────────┐ │ Ethernet │ └──────────────────────────┬────────────────┬────────────┬──────┘ │ │ │ ┌─────────┴─────────┐ ┌───┴────┐ ┌────┴────┐ │ рабочая станция 1 │ │ сервер │ │ принтер │ └─────────┬─────────┘ └───┬────┘ └─────────┘ │ ┌───┴──────┐ ─┴─ ─┴─ ─┴─ / \ / \ / \ \ / \ / \ / │ ─── │ │ ─── │ │ ─── │ │ │ │ диск │ │ │ \ / \ / \ / ─── ─── ─── Рисунок 1-1. Пример сети Архитектура сети и уровни протоколов Если машина работает в сети, может возникнуть ряд проблем: * Аппаратура может выйти из строя. * Сеть может быть перегружена. * Данные могут быть потеряны, запорчены или продублированы. Вследствие количества и сложности возникающих проблем, решаю- щие их протоколы делятся на уровни: нижние - ближе к аппаратуре, высшие - ближе к пользователю. Каждый уровень протокола относится к отдельной задаче и поддерживает все ниже расположенные уровни. Количество уровней и задач, решаемых на каждом из уровней, зави- сит от определения этих уровней. Ниже рассматривается несколько примеров протоколов и делается их сравнительная оценка. OSI Международная организация стандартов (ISO) располагает семиу- ровневым протоколом, который носит название "Справочная модель открытого межсистемного взаимодействия" (OSI) (Рисунок 1-2). Про- токол OSI также служит основой для протокола X.25. ┌──────────────────┬────────────────────────────────────────┐ │ Уровень │ Функциональное назначение │ ╞══════════════════╪════════════════════════════════════════╡ │ 7 │ Проблемно-ориентированный │ ├──────────────────┼────────────────────────────────────────┤ │ 6 │ Представление данных │ ├──────────────────┼────────────────────────────────────────┤ │ 5 │ Сеансовый │ ├──────────────────┼────────────────────────────────────────┤ │ 4 │ Транспортный │ ├──────────────────┼────────────────────────────────────────┤ │ 3 │ Сетевой │ ├──────────────────┼────────────────────────────────────────┤ │ 2 │ Канальный │ ├──────────────────┼────────────────────────────────────────┤ │ 1 │ Физический │ └──────────────────┴────────────────────────────────────────┘ Рисунок 1-2. Модель ISO Уровни функционируют следующим образом: Проблемно-ориентированный Определяет перечень выводимых со- уровень общений и действий, предпринимае- мых при их получении. Уровень представления Выполняет все необходимые преоб- данных разования данных. Сеансовый уровень Реализует сеанс связи с другими машинами. Транспортный уровень Принимает данные от сеансового уровня и разбивает их на порции меньшего размера для сетевого уровня. Сетевой уровень Определяет размер порции передачи данных по сети, маршрут передачи, контролирует перегрузку сети. Канальный уровень Проверяет ошибки передачи данных, передает данные, свободные от ошибок, на сетевой уровень. Физический уровень Имеет дело с физической передачей данных через канал. TCP/IP Протокол управления передачей с межсетевым взаимодействием (TCP/IP) имеет четыре программных уровня, выполненные в виде надстройки над аппаратным уровнем. Эта модель описана на Рисунке 1-3. ┌──────────────────┬────────────────────────────────────────┐ │ Уровень │ Функциональное назначение │ ╞══════════════════╪════════════════════════════════════════╡ │ 4 │ Проблемно-ориентированный │ ├──────────────────┼────────────────────────────────────────┤ │ 3 │ Транспортный │ ├──────────────────┼────────────────────────────────────────┤ │ 2 │ Межсетевой │ ├──────────────────┼────────────────────────────────────────┤ │ 1 │ Сетевой интерфейс │ └──────────────────┴────────────────────────────────────────┘ Рисунок 1-3. Модель TCP/IP Уровни функционируют следующим образом: Уровень сетевого Принимает и передает данные по интерфейса сети. Межсетевой уровень Обеспечивает межмашинную связь. Транспортный уровень Обеспечивает связь между приклад- ными программами. Проблемно-ориентированный Обращается к межсетевому уровню, уровень посылает и получает данные. Соотношение моделей На Рисунке 1-4 показано соотношение моделей ISO и TCP/IP. ┌─────────────────────────┬──────────────────────────┐ │ ISO │ TCP/IP │ ├───────┬─────────────────┼──────────────────┬───────┤ │Уровень│ Функциональное │ Функциональное │Уровень│ │ │ назначение │ назначение │ │ ╞═══════╪═════════════════╪══════════════════╪═══════╡ │ 7 │ Проблемно- │ │ │ │ │ ориентированный │ Проблемно- │ │ ├───────┼─────────────────┤ │ │ │ 6 │ Представление │ │ 4 │ │ │ данных │ │ │ ├───────┼─────────────────┤ ориентированный │ │ │ 5 │ Сеансовый │ │ │ ├───────┼─────────────────┼──────────────────┼───────┤ │ 4 │ Транспортный │ Транспортный │ 3 │ ├───────┼─────────────────┼──────────────────┼───────┤ │ 3 │ Сетевой │ Межсетевой │ 2 │ │ │ ├──────────────────┼───────┤ ├───────┼─────────────────┤ Сетевой интерфейс│ 1 │ │ 2 │ Канальный │ │ │ ├───────┼─────────────────┼──────────────────┼───────┤ │ 1 │ Физический │ Аппаратный │ - │ └───────┴─────────────────┴──────────────────┴───────┘ Рисунок 1-4. Семейства протоколов Как NFS вписывается в сеть NFS располагается на проблемно-ориентированном уровне модели TCP/IP. Она должна вписываться в архитектуру сетевых услуг и не допускать операционную систему в сеть. Таким образом, NFS служит интерфейсом, позволяющим множеству машин и операционных систем играть роли клиента и сервера, но не является распределенной опе- рационной системой. Цель NFS - сделать все необходимые диски доступными. Отдель- ные рабочие станции имеют доступ ко всей информации, располагаю- щейся в любом месте сети. Принтеры и суперкомпьютеры также могут использоваться в сети. Архитектура NFS ───────────────────────────────────────────────────────────── Данная версия сетевой файловой системы (NFS) состоит из моди- фицированного ядра ОС XENIX или UNIX, набора библиотечных подп- рограмм и служебных команд. Эти компоненты образуют следующую ар- хитектуру: * Основу составляют удаленные процедурные вызовы и механизм внешнего представления данных (RPC/XDR). RPC реализует связь с удаленными службами средствами, по- добными механизму вызова процедур, который существует во многих языках программирования. В рамках RPC вызывающий процесс может обратиться к сервер- ному процессу с запросом на исполнение процедуры так, как будто он запускает процедуру в своем собственном адресном пространстве (как в локальной модели). Поскольку вызывающий процесс и сервер выступают в качестве двух самостоятельных процессов, им нет необходимости существовать на одной и той же физической машине. Механизм RPC реализован в виде библиотеки процедур и требо- ваний к передаче данных, объединенных в понятии XDR (внеш- нее представление данных). Как RPC, так и XDR являются мо- бильными средствами, обеспечивающими межпроцессную связь на одной машине или по сети с помощью стандартной библиотеки ввода-вывода. Таким образом, программисты получают стандар- тизированный доступ к этим средствам, не заботясь о конк- ретных способах их реализации. * Сетевые приложения, базирующиеся на RPC/XDR. Механизм совместного использования файлов, администратор защиты и средства удаленного исполнения команд служат при- мерами сетевых приложений, реализуемых на базе RPC/XDR. * Средства разработки пользовательских сетевых приложений. Библиотеки RPC/XDR, программа rpgcen и материал настоящего руководства обеспечивают основу для разработки распределен- ных приложений. Поток запросов ───────────────────────────────────────────────────────────── На Рисунке 1-5 показан поток запросов, поступающих от клиента к серверу, содержащему запрашиваемые данные на локальном диске. Блоки с файловыми системами соответствуют функциям операционной системы, обеспечивающим доступ к данным на присоединенных систе- мами дисках. системные вызовы │ v ┌───────────┐ ┌─────┐ │ серверная │ │ FSS │ ┌─────>│ система │ └─┬┬┬─┘ │ └─────┬─────┘ ┌──────────┘│└────────────┐ │ │ v │ │ │ │ ┌──────────┐ v v │ v │ файловые │┌───────────┐┌───────────┐ ┌─────┴─────┐┌───────────┐ │ системы ││ локальные ││ удаленные │ │ серверный ││ локальные │ │ потенци- ││ файловые ││ файловые │ │ процесс ││ файловые │ │ ального ││ системы ││ системы │ └───────────┘│ системы │ │ будущего │└─────┬─────┘└────┬──────┘ ^ └─────┬─────┘ └──────────┘ │ │ │ │ v │ │ v ─── v │ ─── / \ ┌──────┐ ┌──┴───┐ / \ \ / │ RPC/ │ │ RPC/ │ \ / │ ─── │ │ XDR │ │ XDR │ │ ─── │ │ │ └──┬───┘ └──────┘ │ │ \ / │ ^ \ / ─── │ │ ─── v │ ─────────────────────────┴─────────── Ethernet ───────────────────────────────────── Рисунок 1-5. Поток запросов Если обращение реализуется через локальную файловую систему, запросы адресуются к данным, расположенным на тех устройствах, которые подключены к клиентской машине. Если обращение идет через удаленную файловую систему, запрос обрабатывается уровнями RPC и XDR в сети. В текущей версии используются протоколы UDP/IP и Ethernet. На серверном конце запросы обрабатываются уровнями RPC и XDR и поступают к серверу NFS. Примеры работы NFS Наилучшими примерами работы NFS являются монтирование удален- ной файловой системы и экспортирование файловой системы. Монтирование удаленной файловой системы Предположим, что пользователю нужно прочитать текст руководс- тва, отсутствующий на его машине (с именем Mars), но имеющийся на машине с именем Docserv. По этому сценарию Mars является клиен- том, а Docserv - сервером. Чтобы смонтировать файловую систему, пользователю нужно зарегистрироваться на машине Mars как супер- пользователь и ввести: mars# /etc/mount -f NFS docserv:/usr/man /usr/man Все пользователи на машине Mars могут теперь для считывания разделов руководства использовать команду man. Поскольку команда mount открывает доступ к разделам руководс- тва из каталога /usr/man, она очевидно использует копии, хранящи- еся на машине Docserv. Если пользователь после монтирования уда- ленной системы запустит команду df, на экране появится примерно следующее: / (/dev/dsk/cld0s0 ): 1636 blocks 1424 i-nodes /usr (/dev/dsk/cld0s2 ): 5368 blocks 4480 i-nodes /usr/man (docserv:/usr/man ): 36364 blocks 0 i-nodes Экспортирование файловой системы Предположим, что двум пользователям из разных систем нужно поработать вместе над программным проектом. Исходный текст нахо- дится на машине первого пользователя (Senior) в каталоге /usr/proj. Первый пользователь должен стать суперпользователем и отредактировать файл /etc/exports на машине Senior, указав ката- лог и машины, имеющие право к нему обращаться. Так, например, для того, чтобы разрешить машине Junior обращаться к каталогу /usr/proj, поместите в файл /etc/exports следующую строку: /usr/proj junior Если первому пользователю не удается скорректировать файл /etc/exports, пользователи, работающие на машине Junior, при по- пытке удаленного монтирования каталога /usr/proj получат сообще- ние "permission denied" (в разрешении отказано). NFS только обеспечивает доступ к файлам. Слежение за парал- лельной работой выполняет система управления работой с исходным текстом (SCCS) или другая подобная система. Более подробно о SCCS см. в "Справочном руководстве программиста по XENIX'у". Прозрачность NFS Версия NFS, реализованная в ОС XENIX и UNIX, отличается неза- висимостью (прозрачностью) по следующим параметрам: * Тип файловой системы: операционная система взаимодействует одинаково с широким спектром разнотипных файловых систем. * Размещение файловой системы: поскольку интерфейс для работы с локальной и с удаленной файловой системой один и тот же, размещение данных файловой системы не зависит от ее распо- ложения. * Тип операционной системы: механизм RPC обеспечивает взаимо- действие в сети разнотипных операционных систем и делает тем самым тип операционной системы удаленного сервера не имеющим значения. * Тип машины: механизм XDR обеспечивает взаимодействие в од- ной и той же сети машин разных типов, благодаря чему тип машины теряет значение. * Тип сети: RPC и XDR могут быть реализованы в составе раз- личных сетевых и межсетевых протоколов, в связи с чем тип сети тоже теряет значение. Развитие системы NFS может идти за счет использования некото- рых преимуществ ОС XENIX и UNIX. В частности, добавление клиента (или сервера) в сеть может происходить путем использования одной стороны интерфейса NFS. Преимущество такого метода состоит в идентичности клиентской и серверной сторон; таким образом, любая машина может стать клиентом, сервером или обоими одновременно. Пользователи, которые работают на клиентских машинах, располагаю- щих дисками, могут функционировать в NFS в режиме совместного ис- пользования ресурсов, не обращаясь к системному администратору и не устанавливая другую систему на своей рабочей станции. Интерфейсы NFS NFS обеспечивает работу следующих интерфейсов: * Интерфейс с операционной системой В данной версии NFS используется стандартный интерфейс с ОС XENIX и UNIX, благодаря чему обеспечивается совместимость с существующими приложениями. * Логический интерфейс с файловой системой (FSS) Интерфейс этого типа представляет собой набор подпрограмм, работающих внутри ядра и отделяющих операции файловой сис- темы от семантики их реализации. Выше границы этого интер- фейса осуществляются функции операционной системы по работе с обобщенными файловыми объектами. Ниже идет реализация файлового объекта из наборов данных файловой системы. Ин- терфейс FSS обеспечивает интеграцию в ядре поддержки файло- вых систем NFS с минимальными изменениями. * Интерфейс с сетевой файловой системой (NFS) Удаленная файловая система описывает и реализует интерфейс NFS с помощью механизма RPC. Интерфейс NFS сам по себе является открытым и может использо- ваться каждым, кто желает включить в сеть клиента или сервера NFS. Интерфейс описывает традиционные операции файловой системы: чтение каталогов, создание и удаление файлов, чтение и запись в файлы, чтение и установку атрибутов файла. Он разработан таким образом, что файловые операции адресуют файл по неинтерпретируе- мому идентификатору, начальному адресу и длине в байтах. Для серверов NFS предусмотрены команды запуска функции (mountd) и обслуживания раздела файловой системы в сетевой среде (/etc/exports). Клиент получает доступ к файловым системам в сети после выполнения команд mount. Сервер трактует каждую транзакцию (обработку запроса) незави- симо от других и не стремится отслеживать информацию о клиентах, завершении выполнения транзакций и внесении изменений в файлы. Так, например, операция open в том смысле, который она может иметь по отношению к серверу, отсутствует. Поскольку эта операция используется в интерфейсе с ОС XENIX и UNIX, информация по ней запоминается клиентом для использования в последующей работе с NFS. Такая "нестатическая" природа сервера порождает проблему, когда работающая под управлением ОС XENIX или UNIX прикладная программа разрывает связь (unlink) с открытым файлом. Это обычно делается для того, чтобы создать видимость временного файла, уда- ляемого автоматически в момент завершения выполнения программы. Если файл обслуживается сетевой файловой системой (NFS), функция unlink выполнит его удаление, поскольку сервер "не помнит" о том, что файл открыт. В результате все последующие действия над файлом закончатся неудачей. Чтобы избежать возникновения подобных ситуа- ций, операционная система клиента должна их предвидеть, переиме- новывать файл и разрывать связь с новым файлом по завершении программы. В нашем случае на сервере останутся ненужные "времен- ные" файлы; эти файлы можно периодически удалять в процессе соп- ровождения файловой системы. Другим примером взаимодействия NFS с ОС XENIX и UNIX в "нес- татическом" режиме является команда mount. В этих операционных системах клиент NFS "строит" свое представление о файловой систе- ме, расположенной на локальных устройствах, используя команду mount. Для клиента также естественно в начале работы с NFS запро- сить доступ к файловой системе, работающей в сети, с помощью ко- манды mount расширенного формата. Выполнение этой команды не при- водит к смене состояния сервера, поскольку она только запрашивает данные, необходимые для установления контакта между клиентом и сервером. Команда mount может быть исполнена в любой момент, но обычно ее исполнение входит составной частью в процедуру инициа- лизации клиента. Соответствующая команда umount для сервера игра- ет роль только информационного сообщения, но изменяет условия функционирования клиента в рамках работающих в сети файловых сис- тем. Главным преимуществом такой работы сервера является его ошиб- коустойчивость по отношению к различным отказам, имеющим место со стороны клиента, сервера и сети в целом (см. раздел "Особенности NFS"). Сервер NFS может выступать клиентом другого сервера NFS. Тем не менее, он не может выступать посредником между клиентом и дру- гим сервером. Вместо этого клиенту следует запросить перечень удаленных монтирований, выполненных под управлением сервера, и попытаться воспользоваться ими. Решение о запрещении использова- ния серверов в качестве "посредников" основывается на нескольких факторах: * Наличие посредника снижает быстродействие системы. * Наличие посредника усложняет процедуру управления доступом. Гораздо проще потребовать от клиента и сервера установления прямых отношений. * Запрещение "посредничества" служит предотвращению циклич- ности в осуществлении функций. Защита файлов в NFS базируется на использовании механизмов, встроенных в RPC. Несмотря на то, что NFS работает в операционной среде XENIX и UNIX, она поддерживает не все операции над файлами, принятые в этих системах. Для удаленных файловых систем, например, не под- держивается абстракция "специальный файл" как файл устройства, поскольку взаимодействие с устройствами чрезвычайно усложнило бы интерфейс NFS. Другие факты несоответствия являются следствием "нестатичности" натуры сервера. Так, например, в NFS на удалении не поддерживаются блокировка файлов и режим append_mode. Эти ус- луги предоставляются другими, "прозрачными" сетевыми средствами. Решение о неиспользовании тех или иных особенностей NFS моти- вируется желанием сохранить "нестатическую" природу сервера и описать простой, обобщенный интерфейс. Открытость интерфейсов RPC и NFS означает, что потребители и пользователи, нуждающиеся в по- вышенных характеристиках, могут реализовать их "рядом" или "внут- ри" NFS. Особенности NFS ───────────────────────────────────────────────────────────── NFS имеет ряд особенностей: * Стандарт информационного обмена NFS играет роль стандарта информационного обмена между раз- личными машинами и операционными системами. * "Прозрачный" доступ к информации Вы можете непосредственно обращаться к нужным вам файлам без указания сетевого адреса расположения данных. Создается впечатление, что нет никакой разницы между чтением из файла и записью в файл, находящийся на локальном диске, и теми же операциями по отношению к файлу, расположенному на диске из другого здания. Информация действительно распределена по сети. * Легкая расширяемость Распределенная система должна иметь архитектуру, позволяю- щую встраивать новые программные технологии, не затрагивая существующие. Руководствуясь этим принципом, NFS расширяет состав сетевых функций, не прибегая к услугам новой сетевой операционной системы. Это значит, что NFS при этом не тре- бует расширения функциональных возможностей операционной среды в сетевой части, а предлагает обновляемый набор про- токолов информационного обмена. * Легкость управления сетью ОС XENIX и UNIX располагают удобным набором команд сопро- вождения, имеющих длинную историю развития. NFS предостав- ляет некоторые новые утилиты управления сетью, сохраняя большую часть существовавших ранее утилит. * Надежность Протокол файлового сервера предусматривает, что клиенты на рабочих станциях могут продолжать свою работу даже в случае отказа сервера и его перезагрузки. Продолжение работы после перезагрузки достигается за счет отказа от учета возможных сбоев серверного оборудования. С другой стороны, в случае отказа клиента от сервера или администратора не требуется никаких действий для продолже- ния нормальной работы. Если сервер или сеть выходят из строя, необходимо только, чтобы клиенты постарались завер- шить свою работу с NFS до тех пор, пока сервер или сеть не восстановят свою работоспособность. Подобная ошибкоустойчи- вость системы особенно важна для сетей гетерогенного типа, большинство из которых не контролируются оперативным персо- налом и могут включать в себя нетестируемые системы, зачас- тую перезагружаемые без предупреждения. * Высокая производительность Гибкость NFS позволяет строить системы с различной произво- дительностью и эффективностью. Так, например, оснащение серверов большими, высокопроизводительными дисками и лише- ние клиентов возможности иметь собственные диски повысит производительность системы в целом при меньших затратах по сравнению с вариантом, когда имеется множество машин с не- большими и недорогими дисками. Кроме того, можно распреде- лить информацию файловой системы между множеством серверов и достичь тем самым эффекта многопроцессорной системы. Ко- пии файлов, доступных только для чтения, во избежание воз- никновения узких мест можно хранить на нескольких серверах. В NFS возможны некоторые улучшения производительности за счет использования "быстрых путей поиска" (fast paths) для часто выполняемых операций, асинхронного обслуживания од- новременно поступающих запросов, буферизации дисковых бло- ков. Буферизация и чтение с продвижением имеют место как у клиента, так и у сервера, не меняя состояние последнего. Запись результатов (регистрация) позволяет и клиенту, и серверу по мере необходимости сбрасывать на диск критичес- кую информацию, уменьшая тем самым губительные последствия непредвиденных сбоев; клиент не освобождает занимаемые ин- формацией блоки до тех пор, пока сервер не подтвердит, что информация переписана. Об этом руководстве ───────────────────────────────────────────────────────────── Цель настоящего руководства состоит в изложении материала, иллюстрирующего с помощью примеров и процедур процесс написания программ, которые используют возможности сетевой файловой систе- мы. Больший эффект от освоения материала получат те пользователи, которые уже владеют опытом программирования на языке Си, ибо NFS написана на Си. Вам следует также ознакомиться с протоколом SCO TCP/IP. Структура данного руководства Изложение материала в главах подчинено принципу перехода от общего к частному. Характеристика последующих глав руководства: * Глава 2, "Использование NFS", разъясняет моменты, связанные с получением информации о системе, удаленным исполнением команд и компиляцией RPC-программ. * Глава 3, "Использование удаленных обращений к процедурам (RPC)", описывает механизм RPC, использование его различных уровней, взаимодействие RPC с XDR, дает примеры выполнения общих задач и детальное описание каждой подпрограммы RPC. * Глава 4, "Использование протокола XDR", разъясняет моменты, связанные с использованием библиотечных функций XDR, а так- же детально описывает каждую процедуру XDR. Терминология В настоящем разделе описываются основные термины, используе- мые в данном руководстве. Приложение Программа или набор программ, исполняемых на машине клиента, называется приложением. Клиент Host-машина, использующая сетевые ресурсы, именуется клиен- том. См. также "Host" и "Сервер". Host может быть и сервером, и клиентом одновременно. Информация файловой системы Информация, образующая структуру и содержимое файловой систе- мы. Операции файловой системы Текст программы, реализующей операции над файлами. Host Любая машина в сети именуется host, независимо от того, явля- ется ли она клиентом, сервером или и тем и другим вместе. См. также "Клиент" и "Сервер". Сервер Host-машина, предоставляющая ресурсы сети, называется серве- ром. См. также "Клиент" и "Host". Host может быть и сервером, и клиентом одновременно. Гнездо Гнездо - гибкая и мощная подсистема, поддерживающая взаимо- действие процессов (IPC) в распределенной среде. Этот интерфейс в ОС XENIX и UNIX включает в себя программный интерфейс и базис для IPC как внутри host'а, так и в сети. См. также "Host". Нестатичность Если сервер не должен запоминать информацию между двумя тран- закциями, это называется "нестатичность". Подразумевается инфор- мация о клиентах, выполненных транзакциях и рабочих файлах. Пользователь Лицо, зарегистрировавшееся на клиентской машине. Соглашения, принятые в данном руководстве Имена каталогов и файлов в тексте даны курсивом. Первое появление термина в тексте так же выделяется курсивом. Переменные и параметры команд даются курсивом. Вводимые команды выделяются шрифтом. Элементы командной строки, заключенные в квадратные скобки ( [ ] ), являются необязательными. Многоточие (...) означает, что в командной строке может поя- виться более одного элемента. Названия нажимаемых клавиш заключаются в угловые скобки. Так, например, управляющая клавиша обозначается . Ответы системы даются разрядкой. Заглавные буквы в скобках, например (NC), следующие за именем команды, hostname(NC), относятся к разделу справочного руководс- тва "SCO NFS Reference Guide", содержащему полные сведения о ко- манде.