9P (the Plan 9 File system Protocol)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 15:21, 6 декабря 2016.

9P (англ. the Plan 9 – это сетевой протокол, разработанный для Plan 9 от Bell Labs распределенной операционной системы в качестве средства подключения компонентов системы Plan 9). Файлы являются ключевыми объектами в Plan 9. Они представляют собой окна, сетевые соединения, процессы, почти все остальные доступные в операционной системе. В отличие от NFS, 9P поддерживает кэширование и обслуживание синтетических файлов (например, Proc для представления процессов).

Glenda, the Plan 9 Bunny

9P был пересмотрен для 4-го издания Plan 9 под названием 9P2000, который содержал различные фундаментальные улучшения. Последняя версия операционной системы Inferno также использует 9P2000. Протокол файл Inferno первоначально назывался Стикс, но технически он всегда был вариант 9P.


Реализация сервер 9P для Unix, называемых u9fs, включен в дистрибутив Plan 9. 9P OS X клиент Kernel Extension обеспечивается Mac9P. Драйвер клиента для Linux ядра является частью проекта v9fs. 9P и его производные также нашли применение во встраиваемых средах, таких, как Styx в проекте Brick. Сервер Plan 9 является агентом, который содержит один или более иерархических файловых систем - файловые деревья - которые могут быть доступны в процессах Plan 9. Сервер отвечает на запросы клиентов, чтобы перемещаться по иерархии для создания, удаления, чтения и записи файлов. Сервер представляет собой отдельную машину, которая хранит большое количество файлов пользователей на постоянной информации; такая машина называется, несколько натянуто, файловым сервером. Другая возможность для сервера синтезировать файлы по требованию, осуществляется внутри ядра на основе информации о структурах данных; устройство ядра Proc является частью Plan 9 ядра. Пользовательские программы могут также выступать в качестве серверов. Подключение к серверу является двунаправленным путем передачи данных от клиента к серверу. Там может быть один клиент или несколько клиентов. Процессы, происходящие в группе, системные вызовы, работающие с файлами переводятся на запросы и ответы, передаваемые по подключению к соответствующей службе.

Серверные приложения

Многие из приложений операционной системы Plan 9 могут выступать в качестве серверов 9P. Например:

  • Acme — многооконный текстовый редактор и оболочка операционной системы;
  • Rio — оконная система Plan 9;
  • Plumber — механизм взаимодействия процессов;
  • wikifs: файловая система Plan 9, представляющая вики-страницы в 2 формах: в виде веб-страниц, и в виде текстовых файлов, обрабатываемых Acme.
  • Многие из приложений Plan 9 принимают форму 9P файловых серверов. Примеры включают в себя:
  • ftpfs: клиент, который FTP представляет файлы и директории на удаленном сервере FTP в локальном пространстве имен;
  • wikifs: инструмент для редактирования вики, который представляет собой удаленный вики в виде файлов в локальном пространстве имен;
  • webfs: файловый сервер, который извлекает данные из URL-адресов и представляет содержание и подробности ответов в виде файлов в локальном пространстве имен;

Реализация

Протокол Plan 9 File, 9P, используется для сообщений между клиентами и серверами. Клиент передает запросы (T-сообщения) на сервер, который затем возвращает ответы (R-сообщения) до клиента. Объединенные акты передачи (приема) запроса определенного типа, и приема (передачи) ответа называется сделкой.

Каждое сообщение состоит из последовательности байтов. Двух-, четырех- и восемь байт поля содержат целые числа без знака, выставленные в прямом порядке байтов. Элементы данных большей длины, представлены в двухбайтовом поле, указывающим количество, n, а затем n байтов данных. Текстовые строки представлены таким образом, что с текстом сама хранится как и UTF-8, так и закодированная последовательность символов Unicode. Текстовые строки в сообщениях 9P не NUL-прекращается: n подсчитывает байты данных UTF-8, которые не включаются в окончательный нулевой байт. Характер NUL является неверным во всех текстовых строках в 9P, и поэтому исключены из имен файлов, имена пользователей, и так далее.

Каждое сообщение 9P начинается с поля размера с четырьмя байтами, задающие длину в байтах полного сообщения, включая четыре байта самого поля размера. Следующий байт представляет тип сообщения, одна из констант в перечислении в инклюднике <fcall.h>. Следующие два байта являются определения тегов, описанных ниже. Остальные байты являются параметрами различных размеров. В описаниях сообщений, число байтов в поле дается в скобках после имени поля.

  • Параметр Обозначение [n], где n не является постоянной величиной представляет параметр переменной длины: n, а затем n байтов данных, формирующих параметр.
  • Обозначения строки [s] (с использованием литералы символов) представляет собой сокращенную s, а затем s байтов UTF-8 строк текста. (Системы могут выбрать, чтобы уменьшить набор юридических символов, чтобы уменьшить синтаксические проблемы, например, чтобы удалить косую черту из компонентов имени, но протокол не имеет такого ограничения.

Plan 9 имена могут содержать любые печатные символы (то есть, любой символ вне шестнадцатеричном 00 . -1f и 80-9F), за исключением косой черты) сообщения транспортируются в виде байта, чтобы обеспечить независимость машины; описывает процедуры, которые преобразовывают и из этой формы в машинно-зависимой структуры C. 9P отправляет следующие сообщения между клиентами и серверами. Эти сообщения соответствуют точкам входа в VFS Plan 9, что любой сервер 9P должен реализовать. В приведенном ниже перечне указано сообщение, само действие и Man-страница на официальном сайте Plan 9:

  • version - Согласование версий протокола (Negotiate protocol version)
  • error - Возвращение ошибки (Return an error)
  • flush - Прерывание сообщения (Abort a message)
  • auth, attach - Сообщения для установки соединения (Messages to establish a connection)
  • walk - Смена каталога, передвижение дереву каталогов (Descend a directory hierarchy)
  • create, open - Подготовка обработчика для операций ввода-вывода над существующим или новым файлом (Prepare a fid for I/O on an existing or new file)
  • read, write - Передача данных из файла или в файл (Transfer data from and to a file)
  • clunk - Закрытие обработчика (fid), такой обработчик становится недействительным (Forget about a fid)
  • remove Удаление файла с сервера (Remove a file from a server)
  • stat, wstat - Запрос атрибутов файла или их изменение (Inquire or change file attributes)

Программирование

9p.jpg

Основным языком программирования является диалект языка ANSI Си, который отличается встроенной поддержкой Unicode и многими другими полезными расширениями. Например: - формирование структур - инициализация массивов. Реализованы кроссплатформенная компиляция и отладка, успешно портированы Perl, Python, Scheme, noweb, Haskell, Newsqueak, Go и ML. В качестве IDE используется редактор Acme.


Права доступа

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

Когда владелец пытается сделать что-то в файле, то с владельцем, группой и др. он запрашивает разрешение, и проводятся консультации, и если кто-то из них предоставляет запрашиваемое разрешение, то операция разрешается. Для кого-то, кто не является собственником, но является членом группы файла, группа и др. консультации разрешаются. Для всех остальных, используются другие разрешения. Каждый набор разрешений говорит, разрешено ли чтение, разрешена ли запись и разрешено ли выполнение. Права доступа сохраняются в битах низкого порядка в режиме файла: владелец чтение / запись / разрешение на выполнение представлены как 1 в битах 8, 7 и 6 соответственно (с использованием 0 на номер низкого порядка). Права доступа группы находятся в битах 5, 4 и 3, а остальные разрешения находятся в битах 2, 1 и 0.

Режим файл содержит несколько дополнительных атрибуты помимо разрешений:

  • если бит 31 (DMDIR) установлен, то файл является директорией;
  • если бит 30 (DMAPPEND) установлен, то файл добавляют (смещение игнорируется в записи);
  • если бит 29 (DMEXCL) установлен, то файл, исключающий использование (только один клиент может открыть его, в то время);
  • если бит 27 (DMAUTH) установлен, то файл представляет собой файл аутентификации и устанавливается AUTH сообщений;
  • если бит 26 (DMTMP) установлен, то содержимое файла (или директории) не включено в ночные архивы. (28 бит пропускается по историческим причинам.)

Эти биты воспроизводятся, из верхней немного вниз, в типе байта QID: QTDIR, QTAPPEND, QTEXCL, (пропуская один бит) QTAUTH и QTTMP. Имя QTFILE, считается равным нулю и определяет значение типа для обычного файла.

Ссылки

  1. Организация работы сетей в Plan 9: [Электронный ресурс]: Bell-Labs / Дата обращения 29.11.2016. - Режим доступа: http://doc.cat-v.org/plan_9/4th_edition/papers/net/
  2. Руководство по 9P : [Электронный ресурс]: The Plan 9 / Дата обращения 29.11.2016. - Режим доступа: http://www.cs.bell-labs.com/magic/man2html/5/0intro
  3. Описание архитектуры Styx для распределённых систем : [Электронный ресурс]: 4th-edition / Дата обращения 29.11.2016. - Режим доступа: http://doc.cat-v.org/inferno/4th_edition/styx