Андрей Робачевский - Операционная система UNIX
- Название:Операционная система UNIX
- Автор:
- Жанр:
- Издательство:BHV - Санкт-Петербург
- Год:1997
- Город:Санкт-Петербург
- ISBN:5-7791-0057-8
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Андрей Робачевский - Операционная система UNIX краткое содержание
Книга посвящена семейству операционных систем UNIX и содержит информацию о принципах организации, идеологии и архитектуре, объединяющих различные версии этой операционной системы.
В книге рассматриваются: архитектура ядра UNIX (подсистемы ввода/вывода, управления памятью и процессами, а также файловая подсистема), программный интерфейс UNIX (системные вызовы и основные библиотечные функции), пользовательская среда (командный интерпретатор shell, основные команды и утилиты) и сетевая поддержка в UNIX (протоколов семейства TCP/IP, архитектура сетевой подсистемы, программные интерфейсы сокетов и TLI).
Для широкого круга пользователей
Операционная система UNIX - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
При этом вызов ioctl(2) имеет следующий формат:
#include
struct strioctl my_strioctl
...
strioctl.ic_cmd = cmd;
strioctl.ic_timeout = INFTIM;
strioctl.ic_len = size;
strioctl.ic_dp = (char*)buf;
ioctl(fd, I_STR, &my_strioctl);
При вызове ioctl(2) поле size
устанавливается равным размеру соответствующего примитива TPI, определенного полем cmd
и расположенного в буфере buf
. При возврате из функции поле size
содержит размер примитива, возвращенного поставщиком транспортных услуг и расположенного в буфере buf.
Модуль timod(7M) служит для обработки следующих команд cmd:
Значение cmd | Обработка модулем timod(7M) |
---|---|
TI_BIND |
Команда преобразуется в примитив T_BIND_REQ . При успешном завершении функции ioctl(2) в буфере buf находится примитив T_BIND_ACK . |
TI_UNBIND |
Команда преобразуется в примитив T_UNBIND_REQ . При успешном завершении функции ioctl(2) в буфере buf находится примитив T_OK_ACK . |
TI_GETINFO |
Команда преобразуется в примитив T_INFO_REQ . При успешном завершении функции ioctl(2) в буфере buf находится примитив T_INFO_ACK . |
TI_OPTMGMT |
Команда преобразуется в примитив T_OPTMT_REQ . При успешном завершении функции ioctl(2) в буфере buf находится примитив T_OPTMGMT_ACK . |
Интерфейс DLPI
DLPI определяет интерфейс между протоколами уровня канала данных (data link layer) модели OSI, называемыми поставщиками услуг уровня канала данных и протоколами сетевого уровня, называемыми пользователями услуг уровня канала данных. В качестве примера пользователей услуг уровня канала данных можно привести такие протоколы, как IP, IPX или CLNS. С другой стороны, поставщик услуг уровня канала данных непосредственно взаимодействует с различными сетевыми устройствами, обеспечивающими передачу данных по сетям различной архитектуры (например, Ethernet, FDDI или ATM) и использующими различные физические среды передачи.
Для обеспечения независимости DLPI от конкретной физической сети передачи драйвер уровня канала данных состоит из двух частей: верхней аппаратно-независимой и нижней аппаратно-зависимой. Аппаратно-независимая часть драйвера обеспечивает предоставление общих услуг, определенных интерфейсом DLPI, а также поддержку ряда потенциальных пользователей, представляющих семейства протоколов TCP/IP, NetWare и OSI. Аппаратно-зависимая часть непосредственно взаимодействует с сетевым адаптером.
На рис. 6.34 приведена структура драйвера поставщика услуг уровня канала данных. Обмен данными между аппаратно-независимой частью драйвера и пользователем услуг осуществляется в виде сообщений STREAMS, формат и назначение которых и определяется спецификацией DLPI (т.н. примитивы DLPI).

Рис. 6.34. Структура драйвера уровня канала данных
Во время инициализации и последующей передачи данных аппаратно-независимая часть драйвера вызывает необходимые функции аппаратно-зависимой части. Напротив, при поступлении данных из сети, аппаратно-зависимая часть помещает пакеты данных, или кадры, непосредственно в очередь чтения аппаратно-независимой части. Обе части совместно используют набор переменных и флагов для взаимной синхронизации и контроля передачи.
Пользователь получает доступ к услугам поставщика услуг уровня канала данных через точку доступа к услугам (Service Access Point, SAP), используя сообщения STREAMS для обмена данными. Поскольку один поставщик может иметь несколько пользователей, например IP и IPX, в его задачу входит маршрутизация данных, полученных от физической сети, к нескольким точкам доступа. Для этого каждый пользователь идентифицирует себя с помощью адреса SAP, который сообщает поставщику, используя примитив связывания ( DL_BIND_REQ
) потока с точкой доступа к услугам уровня канала данных.
Поскольку аппаратно-зависимая часть драйвера может обслуживать несколько сетевых адаптеров, каждый сетевой интерфейс идентифицируется точкой физического подключения (Physical Point of Attachment, PPA). При этом спецификация DLPI определяет два типа поставщиков услуг. Поставщик услуг первого типа (style 1) производит назначение PPA, исходя из старшего и младшего номеров используемого специального файла устройства (указанного в вызове open(2) ). Обычно каждый адаптер, обслуживаемый драйвером, ассоциирован со старшим номером, а младший номер используется для создания клонов (см. раздел "Клоны" главы 5). Напротив, поставщик второго типа (style 2) позволяет пользователю явно указать PPA уже после открытия потока с помощью примитива присоединения ( DL_ATTACH_REQ
). Использование поставщиков второго типа является более предпочтительным, например, когда одна физическая сеть поддерживает создание независимых логических, или виртуальных каналов передачи данных (например, каналы ISDN В и D). В этом случае идентификатор PPA, передаваемый примитивом DL_ATTACH_REQ
, содержит также идентификатор логического канала. Схема описанных точек доступа приведена на рис. 6.35.

Рис. 6.35. Доступ к услугам поставщика услуг уровня канала данных
DLPI определяет три различных режима передачи данных (или типов услуг), позволяющих обеспечить различные требования протоколов верхнего уровня и поставщиков услуг уровня канала данных:
1. Режим с предварительным установлением связи
2. Режим без предварительного установления связи с подтверждением
3. Режим без предварительного установления связи без подтверждения
В данном разделе мы остановимся только на режиме без предварительного установления связи без подтверждения. Заметим, что для традиционных технологий локальных сетей используется именно этот тип услуг уровня канала данных.
Поскольку дальнейшее обсуждение будет касаться преимущественно коммуникационной инфраструктуры локальных сетей, кратко остановимся на логическом делении уровня канала данных модель OSI в соответствии со стандартом IEEE 802. Применяемые сегодня технологии локальных сетей существенно отличаются друг от друга, как по физической среде и топологии, так и по способу передачи данных в этой физической среде и формату передаваемых данных. Поэтому стандарт IEEE 802 разделяет протоколы локальных сетей на два логических подуровня:
□ Верхний независимый от среды передачи подуровень, названный уровнем управления логическим каналом (Logical Link Control, LLC), определенный стандартом IEEE 802.2.
□ Нижний зависимый от среды передачи подуровень, названный уровнем управления доступом к среде передачи (Media Access Control, MAC), определенный стандартами IEEE 802.3 для протокола CSMA/CD, IEEE 802.4 для протокола Token Bus и IEEE 802.5 для Token Ring.
Читать дальшеИнтервал:
Закладка: