Текст книги "Операционная система UNIX"

Автор книги: Андрей Робачевский

сообщить о нарушении

Текущая страница: 38 (всего у книги 39 страниц)

Взаимодействие с прикладными процессами

Рассмотренный ранее программный интерфейс TLI полностью реализует функциональность TPI. Легко заметить соответствие между отдельными функциями TLI и примитивами TPI, приведенными в табл. 6.10. Схема вызова функций TPI и обмена соответствующими примитивами TPI между клиентом и сервером для типичного TCP-сеанса приведена на рис. 6.32.

Рис. 6.32. Функции TLI и примитивы TPI

Программный интерфейс потоков был рассмотрен в главе 5 при обсуждении подсистемы STREAMS. Основными функциями, обеспечивающими передачу и получение сообщений, являются системные вызовы putmsg(2) и getmsg(2). Таким образом, большинство функций TLI, составляющих программный интерфейс доступа прикладных процессов к транспортным протоколам, являются удобной оболочкой (реализованной в виде библиотеки, например, libnsl.so) более фундаментальным системным вызовам putmsg(2) и getmsg(2).

В качестве примера рассмотрим функцию t_connect(3N). Ее реализация может иметь следующий вид:

int t_connect(int fd, struct t_call *sndcall,

struct t_call *recvcall) {

 struct T_conn_req *connreq;

 struct T_conn_con* conncon;

 struct T_ok_ack *okack;

 struct T_error_ack *errack;

 struct strbuf connect, ack, confirm, m_data;

 struct netbuf addr, opt, udata;

 char *buf;

 int flags;

 ...

 /* Сохраним адреса буферов netbuf запроса sndcall */

 addr = sndcall->addr; opt = sndcall->opt;

 udata = sndcall->udata;

 /* Заполним поля структуры strbuf для формирования

    управляющей части (блок M_PROTO) сообщения T_CONN_REQ */

 connect.len =

  sizeof(struct T_conn_req) + addr.len + opt.len;

 connect.maxlen =

  sizeof(struct Т_conn_req) + addr.maxlen + opt.maxlen;

 buf = (char*)malloc(connect.maxlen);

 connect.buf = buf;

 /* Заполним поля заголовка блока M_PROTO сообщения T_CONN_REQ в

    соответствии с форматом структуры T_conn_req */

 connreq = (struct T_conn_req*)buf;

 connreq->PRIM_type = T_CONN_REQ;

 connreq->DEST_length = addr.len;

 connreq->DEST_offset = sizeof (struct T_conn_req);

 buf += sizeof(struct T_conn_req);

 memcpy(buf, addr.buf, addr.len);

 connreq->OPT_length = opt.len;

 connreq->OPT_offset = connreq->DEST_offset + opt.len;

 buf += addr.len;

 memcpy(buf, opt.buf, opt.len);

 /* Заполним поля структуры strbuf для формирования блока данных

    (блок M_DATA) */

 m_data.len = udata.len;

 m_data.maxlen = udata.maxlen;

 m_data.buf = udata.buf;

 /* Отправим запрос Т_CONN_REQ поставщику транспортных услуг

    по потоку fd */

 putmsg(fd, &connect, &m_data, 0);

 /* Подготовимся к приему подтверждения. Выделим максимальный

    размер для получения негативного подтверждения, поскольку

    примитив T_ERROR_ACK занимает больше места */

 ack.len = ack.maxlen = sizeof(struct T_error_ack);

 ack.buf = udata.buf;

 /* Подтверждение является приоритетным, поэтому установим флаг

    RS_HIPRI. До получения подтверждения не предпринимаем

    никаких действий */

 flags = RS_HIPRI;

 getmsg(fd, &ack, (struct strbuf*)0, &flags);

 free(connect.buf);

 okack = (struct T_ok_ack*)ack.buf;

 /* Проверим получено ли положительное или

    негативное подтверждение */

 if (okack->PRIM_type == T_OK_ACK) {

  /* Если подтверждение положительное, подготовимся к получению

     согласия удаленного пользователя на установление связи

     (примитив T_CONN_CON) */

  free(ack.buf);

  if (recvcall != NULL) {

   addr = recvcall->addr;

   opt = recvcall->opt;

   udata = recvcall->udata;

   confirm.len = sizeof(struct T_conn_con) + addr.len + opt.len;

   confirm.maxlen =

    sizeof(struct T_conn_con) + addr.maxlen + opt.maxlen;

   buf = (char*)malloc(confirm.maxlen);

   confirm.buf = buf;

   m_data.len = udata.len;

   m_data.maxlen = udata.maxlen;

   m_data.buf = udata.buf;

   /* Получим примитив T_CONN_CON */

   getmsg(fd, &confirm, &m_data, &flags);

   free(buf);

   conncon = (struct T_conn_con*)confirm.buf;

   if (conncon->PRIM_type == T_CONN_CON) {

    /* Если это действительно согласие, заполним

       структуру rcvcall для пользователя TLI */

    addr.len = conncon->OPT_length;

    opt.len = conncon->OPT_length;

    memcpy(addr.buf, conncon+conncon->RES_offset, addr.len);

    memcpy(opt.buf, conncon+conncon->OPT_offset, opt.len);

    free(confirm.buf);

    /* Все закончилось удачно – возвращаем 0 */

    return 0;

   }

  } else {

   /* В случае отказа мы готовы обработать примитив

      T_DISCON_IND */

   ...

   return -1;

  }

 } else {

  /* Если получен примитив T_ERROR_ACK – обработаем его */

  errack = (struct T_error_ack*)ack.buf;

  ...

  return -1;

 }

}

Подобным образом реализовано большинство функций TLI. Заметим, что в конкретном случае использования транспортного протокола TCP прием и передача данных осуществляются в виде потока, не содержащего каких-либо логических записей. В этом случае не требуется формирование примитивов типа T_DATA_REQ и T_DATA_IND. В то же время, для передачи и получения экстренных данных будут использованы примитивы T_EXDATA_REQ и T_EXDATA_IND. При использовании протокола UDP все данные будут передаваться с помощью примитивов T_UNITDATA_REQ и T_UNITDATA_IND.

Описанная реализация программного интерфейса TLI имеет один существенный недостаток – операции функций не являются атомарными. Другими словами, выполнение функции t_connect(3N) может быть прервано другими процессами, которые могут также связываться с удаленным узлом. Это возможно, поскольку выполнение значительной части операций происходит в режиме задачи. Если для функции t_connect(3N) нарушение атомарности допустимо, то ряд функций, таких, например, как связывание (t_bind(3N)), получение информации (t_open(3N), t_getinfo(3N)) и установка или получение опций протокола (t_optmgmt(3N)) должны быть защищены от возможного нарушения целостности данных по причине прерывания операции. Единственным способом гарантировать атомарность является перевод выполнения критических участков (например, между отправлением примитива и получением подтверждения от поставщика транспортных услуг) в режим ядра. Для этого подсистема STREAMS предлагает механизм обмена управляющими командами с помощью вызова ioctl(2).

Однако с помощью ioctl(2), как было показано в разделе «Подсистема STREAMS» главы 5, можно формировать лишь сообщения типа M_IOCTL. Для преобразования этих сообщений в примитивы TPI служит дополнительный модуль timod(7M), встраиваемый в поток между головным и транспортным модулями. На рис. 6.33 показано местоположение модуля timod(7M) и схематически отображены его функции.

Рис. 6.33. Архитектура доступа к транспортным услугам

Для всех сообщений STREAMS, за исключением сообщений M_IOCTL, которые генерируются головным модулем в ответ на системный вызов ioctl(fd, I_STR, ...), модуль timod(7M) является прозрачным, т.е. он просто передает эти сообщения следующему модулю вниз по потоку без какой-либо обработки. Несколько сообщений M_IOCTL обрабатываются модулем и преобразуются в соответствующие примитивы TPI.

При этом вызов 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:

	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.

Доступ к среде передачи

Общим в наиболее распространенных технологиях локальных сетей является то, что несколько сетевых устройств совместно используют одну и ту же среду передачи данных, и соответственно делят между собой полосу пропускания сети. Для корректного и эффективного использования сетевых ресурсов необходим механизм контроля доступа к физической среде передачи, который и обеспечивается протоколами уровня MAC.

Первым по известности в ряду этих протоколов стоит CSMA/CD (Carrier Sense Multiple Access with Collision Detection). При этом методе доступа сетевые устройства конкурируют между собой за право передачи по принципу "кто успел – тот и съел". Основной принцип заключается в том, что сетевое устройство может начать передачу данных, только если сеть свободна. Однако при этом возникают ситуации, называемые коллизиями, когда два сетевых устройства начинают передавать данные одновременно. Естественно в этом случае данные не могут быть использованы, и на время коллизии сеть становится недоступной. Время коллизии может быть сокращено, если передающее устройство продолжает «слушать» сеть. Можно сформулировать следующие правила работы CSMA/CD:

1. Если сеть свободна, сетевое устройство может начать передачу, в противном случае, устройство продолжает "слушать" сеть.

2. Если в процессе передачи устройством обнаружена коллизия, устройство должно передать короткий неформатированный сигнал, чтобы гарантировать, что остальными устройствами коллизия также обнаружена, после чего немедленно прекратить передачу.

3. После передачи неформатированного сигнала устройство ожидает случайный промежуток времени, после чего начинает передачу, если сеть свободна.

Передача данных в CSMA/CD осуществляется в виде пакетов, или кадров, для которых существуют два основных формата в соответствии со спецификацией Ethernet 2.0 и стандартом IEEE 802.3. Последний был разработан на основе спецификации Ethernet, однако форматы кадров несколько различаются, как это показано на рис. 6.36 и 6.37.

Рис. 6.36. Формат кадра Ethernet

Рис. 6.37. Формат кадра IEEE 802.3

Существенным различием между двумя форматами является то, что поле "тип пакета" (Ethertype) кадра Ethernet используется для обозначения размера кадра в случае IEEE 802.3. В кадре Ethernet это поле идентифицирует сетевой протокол, использующий данный кадр. К счастью, значения идентификаторов протоколов превышают 1500 – максимальный размер данных кадра, поэтому драйвер может легко определить используемый формат.

Другой, также часто используемый метод доступа, используемый в кольцевых топологиях сетей, заключается в передаче между сетевыми устройствами, подключенными к кольцу, маркера – небольшого пакета, играющего роль эстафетной палочки (например, в сетях Token Ring). Пока ни одно из устройств не передает данные, маркер, циркулирующий в кольце, имеет флаг "свободный". При необходимости передачи устройство дожидается свободного маркера, изменяет его флаг на "занятый" и передает пакет данных сразу же за маркером. Поскольку теперь в сети отсутствует свободный маркер, все остальные устройства должны воздержаться от передачи. При этом устройство, которому адресованы данные, при получении скопирует их в свой буфер. Занятый маркер совершает круг и возвращается к передавшему пакет устройству. Последнее извлекает из сети маркер и пакет данных, изменяет флаг маркера на "свободный" и вновь передает его в кольцо. Таким образом, ситуация возвращается к исходной.

Технология FDDI, также использует метод передачи маркера, правда, несколько отличающийся от только что описанного. Основное отличие заключается в том, что устройство сразу же после передачи пакета помещает свободный маркер. Если какое-либо устройство желает передать данные, оно может воспользоваться этим маркером, также поместив новый свободный маркер вслед за переданным пакетом. Таким образом, в кольце может одновременно существовать несколько пакетов, что повышает эффективность использование пропускной способности сети.

Формат кадров в сетях Token Ring определяется двумя стандартами – IEEE 802.5 и FDDI. Однако за исключением октета контроля доступа эти форматы не отличаются друг от друга. Формат кадра IEEE 802.5 приведен на рис. 6.38.

Рис. 6.38. Формат кадра IEEE 802.5

Протокол LLC

Протокол LLC обеспечивает большую часть услуг уровня канала данных. Этот протокол был разработан на основе другого протокола уровня канала данных – HDLC, однако обладает меньшей функциональностью по сравнению со своим родителем.

Формат кадра LLC представлен на рис. 6.39. Основными полями заголовка кадра являются DSAP и SSAP, которые определяют адреса точек доступа (SAP) соответственно отправителя и получателя данных. Кадр LLC также может содержать дополнительный заголовок SNAP (Sub-Network Access Point), также называемый адресом логической точки доступа (Logical SAP, LSAP).

Рис. 6.39. Формат кадра LLC

Инкапсуляция IP

При работе в локальной сети на базе технологии CSMA/CD возможны два варианта инкапсуляции датаграмм IP в кадры уровней LLC и MAC.

Первый заключается в использовании кадров Ethernet 2.0. В этом случае поле данных (1500 октетов) полностью принадлежит IP-датаграмме, a SAP адресуется полем "тип пакета", которое содержит значение параметра Ethertype – индекса протокола верхнего уровня. В случае IP это значение равно 0x0800. Значения Ethertype для других протоколов приведены в табл. 6.11.

Таблица 6.11. Значение Ethertype для некоторых протоколов

0x0000–0x05DC	Поле Length IEEE 802.3
0x0800	Internet IP (IPv4)
0x0806	ARP
0x6003	DEC DECNET Phase IV Route
0x8137	Novell IPX

Второй вариант предполагает использование формата IEEE 802.3. В этом случае IP-датаграмма инкапсулируется в кадр LLC, а адресация SAP осуществляется в заголовке SNAP с помощью идентификатора Ethertype. При этом поля DSAP и SSAP не используются, и их значения устанавливаются равными 0xAA. Заметим, что в этом случае максимальный размер IP-датаграммы составляет 1492 октета.

При передаче данных TCP/IP в сетях Token Ring используется формат кадра IEEE 802.5, инкапсулирующий кадр LLC с заголовком SNAP, как описано выше.

Внутренняя архитектура

Как уже говорилось, драйвер, реализующий поставщика услуг уровня канала данных, состоит из двух частей: аппаратно-зависимой и аппаратно-независимой. Соответственно драйвер хранит отдельные структуры данных, необходимые для работы этих частей. Архитектура драйвера приведена на рис. 6.40.

Рис. 6.40. Архитектура драйвера DLPI

Для каждого обслуживаемого драйвером сетевого адаптера создается отдельная структура данных DL_bdconfig_t, описывающая характеристики адаптера и содержащая необходимую для управления адаптером информацию, а также статистику, являющуюся частью MIB (Management Information Base). Эта структура используется аппаратно-независимой и зависимой частями совместно, в том числе и для передачи определенной информации между ними.

В частности, эта структура содержит следующие поля:

major	Старший номер устройства, связанного с данным сетевым адаптером
io_start	Адрес начала области ввода/вывода
io_end	Адрес конца области ввода/вывода
mem_start	Адрес начала базовой памяти
mem_end	Адрес конца базовой памяти
irq_level	Уровень прерывания
шах_saps	Максимальное число точек доступа (SAP)
flags	Флаги состояния адаптера
mib	Список статистических данных

Поле flags может включать следующие флаги:

BOARD_PRESENT	Устанавливается драйвером после успешной инициализации адаптера
BOARD_DISABLED	Устанавливается драйвером при неудачной инициализации адаптера. Этот флаг также может быть установлен, если драйвер определит нарушения в функционировании адаптера
TX_BUSY	Указывает на отсутствие ресурсов, например отсутствие необходимых буферов для передачи кадра
TX_QUEUED	Указывает на наличие кадров, ожидающих передачи

Для каждого подключенного пользователя услуг, или, другими словами, для каждой активной SAP драйвер создает структуру данных DL_sap_t, описывающую тип и характеристики точки доступа. Приведем описание некоторых полей этой структуры:

state	Состояние SAP. Возможные состояния определены интерфейсом DLPI. Исходное состояние точки доступа DL_UNBOUND
sap_addr	Уникальный адрес (идентификатор) SAP
flags	Флаги, определяющие дополнительные характеристики SAP
read_q	Указатель на очередь чтения потока, связанного с SAP
write_q	Указатель на очередь записи потока, связанного с SAP
mac_type	Тип используемого протокола доступа и формат используемого кадра. Возможные значения включают:
	DL_CMACD	IEEE 802.3
	DL_ETHER	Ethernet 2.0
	DL_TPB	IEEE 802.4
	DL_TPR	IEEE 802.5
	DL_HDLC	ISO HDLC
	DL_FDDI	FDDI
service_mode	Режим передачи данных. В локальных сетях обычно используется режим без установления связи без подтверждения DL_CLDLS
provider_style	Тип поставщика услуг: DL_STYLE1 или DL_STYLE2
bd	Указатель на структуру DL_bdconfig_t, связанную с сетевым адаптером
next_sap	Указатель на следующую точку доступа в списке активных SAP
max_spdu	Максимальный размер данных, которые могут быть переданы в кадре
min_spdu	Минимальный размер данных, которые могут быть переданы в кадре

Дополнительные характеристики SAP хранятся в поле flags, которое может включать следующие флаги:

RAWCSMACD	Указывает, что через SAP передаются только кадры формата IEEE 802.3
SNAPCSMACD	Указывает, что через SAP передаются кадры формата LLC SNAP
PROMISCUOUS	Указывает, что SAP работает в режиме отсутствия фильтрации кадров (promiscuous mode), при котором SAP получает копии всех кадров независимо от адреса точки доступа, которой они предназначаются. Данный режим применяется, например, при создании приложений мониторинга уровня канала данных
PRIVILEGED	Указывает, что управление точкой доступа требует привилегий суперпользователя

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

ifInOctets	Общее число октетов, полученных адаптером
ifOutOctets	Общее число октетов, переданных адаптером
ifOutUcastPkts	Число переданных однонаправленных (unicast) пакетов
ifOutNUcastPkts	Число переданных групповых (multicast) и широковещательных (broadcast) пакетов
ifInDiscards	Число полученных, но отброшенных правильных пакетов
ifInUcastPkts	Число полученных однонаправленных (unicast) пакетов
ifInNUcastPkts	Число полученных групповых (multicast) и широковещательных (broadcast) пакетов
ifInErrors	Число пакетов, полученных с ошибкой
ifUnknownProtos	Число полученных пакетов, которые были отброшены из-за неправильной SAP адресата
ifOutQlen	Число пакетов, находящихся в очереди на передачу
ifOutErrors	Число пакетов, переданных с ошибкой
etherCollisions	Число коллизий

Аппаратно-независимая часть драйвера обрабатывает все запросы, поступающие от пользователя услуг уровня канала данных. Для этого в драйвере определены следующие функции (часть из них являются стандартными точками входа STREAMS):

DLopen()	Точка входа xxopen(). Эта функция инициализирует SAP, связанную с данным потоком. Функция проверяет наличие флага BOARD_PRESENT и в случае его отсутствия возвращает ошибку.
DLclose()	Точка входа xxclose(). Эта функция сбрасывает текущее состояние SAP и устанавливает его равным DL_UNBOUND.
DLwput()	Точка входа xxput() для очереди записи. Эта функция интерпретирует примитивы DLPI и вызывает соответствующие процедуры драйвера. В случае, если примитив содержит команду уровня канала данных, например, запрос на передачу датаграммы, вызывается функция DLcmds(), которая производит формирование кадра и вызов функции передачи кадра аппаратно-зависимой части драйвера. В случае, когда примитив содержит команду ioctl(2), вызывается функция DLioctl().
DLrsrv()	Точка входа xxservice() для очереди чтения. Функция DLrecv() помещает каждый кадр, полученный от аппаратно-зависимой части драйвера, в очередь чтения потока, ассоциированного с адресуемой SAP. В зависимости от формата кадра (протокола MAC) вызывается соответствующая процедура, извлекающая данные и помещающая их в сообщение DL_UNITDATA_IND (для услуги без предварительного установления связи и без подтверждения), которое направляется вверх по потоку пользователю услуг. Кроме того, DLrsrv() просматривает список активных SAP для возможного копирования сообщения в очереди потоков, имеющих тот же адрес точки доступа. Поскольку функция DLrecv() помещает кадр в очередь первого найденного потока с требуемым адресом SAP (см. описание функции ниже), описанное поведение DLrsrv() гарантирует, что все пользователи услуг уровня канала данных, зарегистрировавшие один и тот же адрес SAP, получат свою копию пакета данных.
DLrecv()	Функция обработки полученного пакета. Эта функция определяет формат пакета и помещает его в очередь потока, ассоциированную с адресуемой SAP. Обычно эта функция вызывается функцией обработки прерывания при получении очередного кадра данных от сетевого адаптера.