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

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

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

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

Реализация TCP/IP

Прежде чем перейти к описанию функционирования модулей протоколов TCP/IP, рассмотрим еще одну структуру данных, называемую управляющим блоком протокола (Protocol Control Block, PCB), который в случае TCP/IP называется Internet PCB, и представлен структурой inpcb, определенной в файле . Вид структуры inpcb показан на рис. 6.28.

Рис. 6.28. Структуры данных протоколов TCP/IP

Эта структура создается для каждого активного сокета TCP или UDP и содержит информацию, необходимую для текущих транзакций протокола, такую как IP-адреса источника и получателя (inp_laddr и inp_faddr), номера портов (inp_lport и inp_fport), маршрутизационной информации (inp_route). TCP создает дополнительный управляющий блок, где хранятся данные, необходимые для работы этого протокола (такие как порядковые номера, номера подтверждений и т.д.)

Управляющие блоки размещаются в виде связанного списка, отдельного для TCP и UDP. Модули протокола имеют в своем распоряжении набор функций для создания, поиска и удаления управляющего блока. Модуль IP демультиплексирует сообщения на основании номера протокола, указанного в заголовке датаграммы, а протокол транспортного уровня, в свою очередь, производит поиск требуемого управляющего блока для доставки данных протоколам более высокого уровня (приложений).

Перейдем теперь к описанию взаимодействия рассмотренных модулей в сетевой подсистеме BSD UNIX (рис. 6.29).

Рис. 6.29. Сетевая подсистема BSD UNIX

Модуль IP

Сетевой интерфейс получает пакеты данных из сети и передает их соответствующему модулю сетевого уровня на основании информации, содержащейся в заголовке кадра уровня канала. В данном разделе мы не будем рассматривать поддержку различных сетевых протоколов, а остановимся только на взаимодействии с протоколом IP. В этом случае полученные пакеты помещаются в очередь приема модуля IP. После этого с помощью программного прерывания вызывается процедура ip_input(), которая поочередно извлекает пакеты из очереди и обрабатывает их. После обработки на основании информации заголовка IP-датаграммы данные либо передаются протоколу транспортного уровня, либо уничтожаются, если в данных обнаружена ошибка, либо передаются другому интерфейсу для последующей отправки фактическому адресату. В последнем случае система выполняет роль шлюза.

Датаграмма считается адресованной данному хосту, если адрес получателя совпадает с одним из адресов интерфейса данного хоста, или адрес получателя является широковещательным (или групповым) адресом данной сети. В случае получения фрагментированной датаграммы модуль производит ее реассемблирование. Для этого отдельные фрагменты собираются в специально организованной очереди, пока не будет сформирована исходная датаграмма. После этого данные передаются транспортному протоколу. Для демультиплексирования модуль IP использует поле Protocol заголовка, которое по существу является индексом таблицы, каждый элемент которой представлен коммутатором протокола, рассмотренного ранее в этой главе. Соответственно модуль IP имеет возможность непосредственно вызвать функцию pr_input() требуемого протокола следующего уровня.

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

□ Производится проверка разрешения шлюзования.[87]87
  Возможность передачи на другой интерфейс определяется установкой соответствующего флага при конфигурации сетевой подсистемы (модуля IP). Например, в операционной системе SCO UNIX за это отвечает настраиваемый параметр ядра ip_forwarding.


[Закрыть] В случае отрицательного результата хост не может выполнять функции шлюза и данные уничтожаются.

□ Производится проверка адреса получателя. Если адрес датаграммы не принадлежит адресному пространству сетей класса А, В или С, такие данные не могут быть переданы.[88]88
  Адреса сетей класса D – групповые (multicast) адреса – используются для создания специальных наложенных сетей (Multicast backbone, Mbone), предназначенных для таких приложений, как видео-, аудиоконференции и т.п. Обработка таких датаграмм выполняется, как правило, специальными демонами отдельно от стандартных функций шлюзования. Если в системе включена поддержка групповых адресов, данные с указанными адресами будут передаваться этим демонам, которые и выполнят логическое шлюзование/передачу.


[Закрыть]

□ Определяется дальнейший маршрут передачи датаграммы.

□ Если дальнейший путь датаграммы проходит через тот же интерфейс, с которого она была получена, и хост-отправитель расположен в той же сети, ему отправляется сообщение ICMP REDIRECT.

□ Производится вызов функции ip_output(), выполняющей передачу датаграммы хосту-адресату или соседнему шлюзу для дальнейшей передачи.

При выполнении этих функций модуль IP может обнаружить несколько ошибочных ситуаций, например, отсутствие маршрута для датаграммы или невозможность передачи данных из-за переполнения в сети. В этих случаях модуль формирует соответствующее сообщение ICMP и передает его отправителю датаграммы. Эти сообщения ICMP и причины их отправки приведены в табл. 6.9.

Таблица 6.9. Сообщения ICMP

DESTINATION UNREACHABLE	Невозможно доставить датаграмму. Причин может быть несколько: 1. Отсутствует маршрут к сети 2. Отсутствует маршрут к хосту 3. Для передачи необходима фрагментация, но в заголовке установлен флаг DF (Don't Fragment)
SOURCE QUENCH	Переполнение сети. Шлюз передает это сообщение, запрашивая отправителя на уменьшение скорости передачи данных
TIME EXCEEDED	Тайм-аут. Причины могут быть две: 1. Истекло время жизни датаграммы в сети (TTL=0) 2. Произошел тайм-аут реассемблирования, т.е. через определенный промежуток времени получены не все фрагменты датаграммы

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

Функция ip_output() может быть вызвана и модулем транспортного протокола (UDP или TCP). Каким образом это происходит, описано в следующем разделе.

Модуль UDP

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

Итак, IP-модуль направляет датаграмму модулю UDP, вызывая функцию udp_input(), адрес которой был получен из соответствующего коммутатора протокола. Сначала функция udp_input() проверяет правильность контрольной суммы и допустимость установленных полей заголовка. Если указанные проверки закончились неудачно, пакет «молчаливо» уничтожается. Далее определяется получатель пакета. Для этого на основании адресов и номеров портов отправителя и получателя производится поиск соответствующего управляющего блока протокола.[89]89
  Функции udp_input() передается целиком датаграмма, включающая заголовок IP, заголовок UDP и данные протоколов верхнего уровня (приложений). Помимо того что эта информация необходима для определения адресата, по заголовку IP вычисляется контрольная сумма UDP. Такой подход гарантирует максимальную точность доставки данных нужному приложению.


[Закрыть] В системе могут существовать несколько управляющих блоков с одинаковым номером локального порта, но с различными адресами и/или номерами портов отправителя. В этом случае выбирается блок, для которого найдено лучшее совпадение по всем четырем параметрам. Конечно, лучшим является точное совпадение, но если такового не найдено, будет выбран блок с совпадающим номером локального порта, но неуказанным адресом и/или номером порта отправителя. Таким образом, управляющий блок, у которого не указаны часть или все четыре параметра, является получателем всех пакетов, для которых не найдено лучшего совпадения.[90]90
  Возможность создания таких получателей «по умолчанию» используется в сетевом суперсервере inetd, который прослушивает все запросы и при необходимости запускает требуемый сервис (например FTP или Telnet). Это позволяет избежать запуска серверов без необходимости и тем самым сократить потребление ресурсов.


[Закрыть]

Если управляющий блок найден, данные и адрес отправителя помещаются в буфер приема сокета, связанного с управляющим блоком. В противном случае генерируется сообщение ICMP PORT UNREACHABLE.

Передача данных от приложения инициируется системным вызовом sendto(2), который на уровне сокета преобразуется в вызов функции udp_usrreq() с запросом PRU_SEND. Если передача инициирована системным вызовом sendto(), то вместе с данными передается адрес получателя. Если же данные были переданы с помощью системного вызова send(2), то адрес получателя определяется из управляющего блока, где он был сохранен предшествующим вызовом connect(2).[91]91
  Протокол UDP не предусматривает предварительного установления связи с получателем данных. Поэтому, в отличие от TCP, вызов connect(2) не приводит к формированию управляющих сообщений и обмену ими между сторонами. В данном случае он служит лишь для сохранения адреса получателя в управляющем блоке.


[Закрыть]

Фактическая передача осуществляется функцией udp_output(), которая формирует заголовок пакета, устанавливает значения его полей и вычисляет контрольную сумму. После этого производится вызов уже рассмотренной ранее функции ip_output().

Модуль TCP

Как следует из предшествующего описания TCP, этот транспортный протокол обеспечивает гораздо более высокое качество передачи, чем UDP. Соответственно, его реализация также является гораздо более сложной. В предыдущих разделах уже встречались различные алгоритмы, используемые при реализации протокола. В этом разделе мы остановимся на одном важном механизме TCP – его таймерах.

Поскольку корректное функционирование протокола во многом зависит от порядка обмена управляющими сегментами, каждый канал обслуживается набором таймеров, позволяющих восстановить работу по тайм-ауту в случае потери управляющих пакетов. Эти таймеры хранятся в соответствующем управляющем блоке протокола TCP и, при их установке, обслуживаются[92]92
  Обслуживание таймера заключается в уменьшении установленного значения и уведомлении модуля, когда значение таймера становится равным нулю.


[Закрыть] каждые 500 миллисекунд функцией tcp_slowtimo().

Для обеспечения передачи данных используются два таймера. Первый из них – таймер повторной передачи (retransmit timer). Этот таймер запускается при передаче сегмента, если он уже не был запущен. Если подтверждение получено, и отсутствуют неподтвержденные данные – таймер останавливается. Если же такие данные существуют, значение таймера присваивается равным начальному, и таймер запускается снова. Если значение таймера становится равным нулю, наиболее старые неподтвержденные данные передаются повторно (как минимум один полный сегмент), а таймер запускается снова, но уже с большим значением. Скорость увеличения значения таймера (timer backoff) определяется по специальной таблице и имеет экспоненциальный характер.

Второй таймер – это persist-таймер (таймер сохранения). Этот таймер обеспечивает защиту от потери управляющих сообщений, содержащих значения окна. В случае, если отправитель готов передать данные, но анонсированное получателем окно слишком мало (равно нулю или меньше определенного значения), и отсутствуют неподтвержденные данные (т. е. таймер повторной передачи не включен), включается таймер сохранения. Если таймер срабатывает (его значение становится равным нулю), а обновленное значение так и не получено, отправитель передает максимально допустимый объем данных, определяемый текущим окном. Если же в этом случае значение текущего окна равно нулю (нулевое окно), то передается пробный сегмент (window probe), содержащий один октет данных, и таймер запускается снова. Если сообщение с обновленным значением окна было утеряно, или получатель по-прежнему отказывается изменить его размер, будет получено подтверждение, содержащее текущее значение окна. Такая ситуация, когда получатель не может принимать дополнительные данные, может продлиться достаточно долго. Например, пользователь может приостановить терминальный вывод и уйти на обед. В этом случае отправитель будет периодически посылать пробные сегменты, а его окно будет по-прежнему закрыто.

Следующий таймер, который мы рассмотрим, – keepalive-таймер. Этот таймер предназначен для мониторинга каналов, по которым не передаются данные, и которые возможно в действительности прекратили свое существование, например, из-за аварийного останова одной из систем. Если за определенный промежуток времени данные по каналу переданы не были, модуль TCP отправляет пробный сегмент keepalive, ожидая в ответ либо подтверждения (это означает, что задержка в передаче данных временная), либо сообщения сброса канала (RST). Если получен сегмент RST, канал будет закрыт. Если после нескольких попыток, не будет получен отклик, канал будет уничтожен.

Последний таймер из рассматриваемых, это 2MSL-таймер (2MSL – двойное максимальное время жизни сегмента в сети). Модуль TCP запускает этот таймер, когда производится завершение связи, и уже отправлено подтверждение полученному сегменту FIN. При этом отправитель не знает, получено ли его подтверждение. Поэтому он некоторое время ждет возможного повторного получения сегмента FIN, чтобы в свою очередь повторить подтверждение. Таймер запускается при переходе коммуникационного узла канала в состояние TIME-WAIT, и после его срабатывания соответствующий управляющий блок удаляется. Заметим, что это ожидание не блокирует процесс, выполнивший системный вызов close(2) сокета, отвечающего за данный канал. Другими словами, управляющий блок может существовать еще некоторое время после закрытия дескриптора сокета.

Поддержка сети в UNIX System V

Многие из аспектов реализации поддержки сети в BSD UNIX справедливы и для архитектуры сетевых протоколов UNIX System V. Однако сам механизм обеспечения взаимодействия модулей существенно отличается. Для поддержки сети в UNIX System V используется подсистема STREAMS, рассмотренная в главе 5.

Подсистема ввода/вывода, основанная на архитектуре STREAMS, позволяет в полной мере отразить уровневую структуру коммуникационных протоколов, когда каждый уровень имеет стандартные интерфейсы взаимодействия с другими (верхним и нижним) уровнями, и может работать независимо от конкретной реализации протоколов на соседних уровнях. Архитектура STREAMS полностью соответствует этой модели, позволяя создавать драйверы, которые являются объединениями независимых модулей.

Обмен данными между модулями STREAMS также соответствует характеру взаимодействия отдельных протоколов: данные передаются в виде сообщений, а каждый модуль выполняет требуемую их обработку. На рис. 6.30 приведена схема реализации протоколов TCP/IP в UNIX System V. Используя терминологию предыдущей главы, можно отметить, что модуль IP является гибридным мультиплексором, позволяя обслуживать несколько потоков, приходящих от драйверов сетевых адаптеров (в данном случае Ethernet и FDDI), и несколько потоков к модулям транспортных протоколов (TCP и UDP), а модули TCP и UDP – верхними мультиплексорами, обслуживающими прикладные программы, такие как сервер маршрутизации routed(1M), сервер удаленного терминального доступа telnetd(1M), сервер FTP ftpd(1M), а также программы-клиенты пользователей (например talk(1)).

Рис. 6.30. Реализация протоколов TCP/IP на основе архитектуры STREAMS

Анализ программного обеспечения сетевой поддержки показывает, что как правило сетевые и транспортные протоколы, составляющие базовый стек TCP/IP, поставляются одним производителем, в то время как поддержка уровней сетевого интерфейса и приложений может осуществляться продуктами различных разработчиков. Соответственно, можно выделить два основных интерфейса взаимодействия, стандартизация которых позволяет обеспечить совместную работу различных компонентов программного обеспечения. Первый интерфейс определяет взаимодействие транспортного уровня и уровня приложений и называется интерфейсом поставщика транспортных услуг (Transport Provider Interface, TPI). Второй интерфейс устанавливает правила и формат сообщений, передаваемых между сетевым уровнем и уровнем сетевого интерфейса, и называется интерфейсом поставщика услуг канала данных (Data Link Provider Interface, DLPI).

Вообще говоря, сетевая архитектура, основанная на архитектуре STREAMS, позволяет обеспечить поддержку любого стека протоколов, соответствующего модели OSI. Поэтому выражаясь более точно, перечисленные интерфейсы определяют взаимодействие транспортного уровня и уровня сеанса, и уровня канала и сетевого уровня, соответственно. Эти рассуждения проиллюстрированы на рис. 6.31.[93]93
  Говоря еще более строго, данные интерфейсы определены самой моделью OSI. Однако в данной главе мы остановимся на практической реализации этих интерфейсов в подсистеме STREAMS.


[Закрыть]

Рис. 6.31. Интерфейсы взаимодействия модулей протоколов

Интерфейс TPI

TPI представляет собой интерфейс предоставления услуг транспортного уровня OSI модели как с предварительным установлением соединения (connection mode), так и без установления соединения (connectionless mode). Стандартизация этого интерфейса позволяет изолировать особенности реализации транспортного уровня от потребителя этих услуг и, тем самым, предоставить возможность разработки программного обеспечения, независимо от конкретного протокола и услуг им предоставляемых.

TPI определяет набор и формат сообщений, с помощью которых протоколы верхнего уровня взаимодействуют с модулем транспортного протокола. Таким образом, TPI является интерфейсом между поставщиком транспортных услуг (transport provider) и пользователем этих услуг (transport user). Эти сообщения определяют транспортные примитивы (transport primitive), или команды, и могут иметь следующий формат:

□ Сообщение состоит из блока типа M_PROTO, за которым может следовать несколько блоков M_DATA. Блок M_PROTO содержит управляющую информацию, включая тип команды и ее аргументы. В блоках M_DATA передаются ассоциированные с командой данные прикладной программы.

□ Сообщение состоит из одного блока M_PCPROTO, который содержит управляющую информацию, включая тип команды и ее аргументы.

□ Сообщение состоит из одного или более блоков M_DATA, в которых передаются данные прикладной программы.

Таблица 6.10. Основные управляющие сообщения TPI

T_BIND_REQ	M_PROTO	Запрос на связывание. Этот примитив инициируется пользователем транспортных услуг и запрашивает связывание потока с адресом протокола. Сообщение состоит из одного блока M_PROTO, который содержит значение адреса и заказанное максимальное число запросов, ожидающих обслуживания со стороны пользователя. Последний параметр игнорируется для транспортных услуг без предварительного установления связи. Блок M_PROTO содержит следующие поля:
		PRIM type	Тип примитива – T_BIND_REQ
		ADDR_length	Размер адреса протокола
		ADDR_offset	Смещение адреса в блоке M_PROTO
		CONIND_number	Максимальное число запросов, ожидающих обслуживания
T_BIND_ACK	M_PCPROTO	Подтверждение получения запроса на связывание. Этот примитив отправляется пользователю транспортных услуг и означает, что поток был связан с адресом протокола, заказанное максимальное число ожидающих запросов допустимо и поток был активизирован. Сообщение состоит из одного блока M_PCPROTO, содержащего значения указанных параметров. Заметим, что возвращаемый адрес может не совпадать с адресом, указанным в запросе T_BIND_REQ. Блок M_PROTO содержит следующие поля:
		PRIM_type	Тип примитива – T_BIND_ACK
		ADDR_length	Размер адреса протокола
		ADDR_offset	Смещение адреса в блоке M_PROTO
		CONIND_number	Максимальное число запросов, ожидающих обслуживания
T_UNBIND_REQ	M_PROTO	Запрос на уничтожение связывания. Этот примитив инициируется пользователем транспортных услуг и запрашивает у поставщика уничтожение ранее созданного связывания потока с адресом протокола и деактивизацию потока.
T_CONN_REQ	M_PROTO	Запрос на установление связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи. Он инициируется пользователем транспортных услуг и запрашивает установление связи с указанным адресатом. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих прикладные данные, определенные пользователем. Заметим, что протокол TCP не позволяет передавать прикладные данные вместе с запросом. Блок M_PROTO содержит значение адреса получателя и опции, связанные с этим примитивом. Блок M_PROTO содержит следующие поля:
		PRIM_type	Тип примитива – T_CONN_REQ
		DEST_length	Размер адреса протокола
		DEST_offset	Смещение адреса получателя в блоке M_PROTO
		ОРТ_length	Размер опций
		ОРТ_offset	Смещение опций в блоке M_PROTO
T_CONN_IND	M_PROTO	Индикация установления связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи и свидетельствует о том, что удаленным пользователем с указанным адресом был сделан запрос на установление связи. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих прикладные данные, определенные пользователем. Блок M_PROTO содержит значение адреса удаленного пользователя, отправившего запрос на установление связи, а также опции, связанные с этим примитивом. Блок M_PROTO содержит следующие поля:
		PRIM_type	Тип примитива – T_CONN_IND
		SRC_length	Размер адреса протокола
		SRC_offset	Смещение адреса отправителя в блоке M_PROTO
		OPT_length	Размер опций
		OPT_offset	Смещение опций в блоке M_PROTO
		SEQ_number	Идентификатор соединения
T_CONN_RES	M_PROTO	Ответ на запрос на установление связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи и свидетельствует о том, что поставщик транспортных услуг принимает предшествующий запрос на установление связи. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих прикладные данные, определенные пользователем. Блок M_PROTO содержит указатель на очередь чтения потока, который будет обрабатывать запрос. Блок M_PROTO содержит следующие поля:
		PRIM_type	Тип примитива – T_CONN_RES
		QUEUE_ptr	Указатель на очередь потока, который должен быть использован в качестве узла созданного соединения
		OPT_length	Размер опций
		OPT_offset	Смещение опций в блоке M_PROTO
		SEQ_number	Идентификатор соединения
T_CONN_CON	M_PROTO	Подтверждение установления связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи. Он отправляется пользователю транспортных услуг в качестве подтверждения установления связи с удаленным пользователем. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих прикладные данные, определенные пользователем. Блок M_PROTO содержит значение размера адреса, сам адрес удаленного пользователя, обслуживающего соединение, а также опции, связанные с этим примитивом. Блок M_PROTO содержит следующие поля:
		PRIM_type	Тип примитива – T_CONN_CON
		RES_length	Размер адреса протокола
		RES_ offset	Смещение адреса удаленного узла в блоке M_PROTO
		OPT_length	Размер опций
		ОРТ_offset	Смещение опций в блоке M_PROTO
Т_DISCON_REQ	M_PROTO	Запрос на разрыв связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи. Он инициируется пользователем транспортных услуг и свидетельствует либо об отказе пользователем в установлении связи, либо о желании пользователя разорвать уже существующее соединение для данного потока. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих прикладные данные, определенные пользователем. Блок M_PROTO содержит следующие поля:
		PRIM_type	Тип примитива – T_DISCON_REQ
		SEQ_number	Идентификатор соединения
Т_DISCON_IND	M_PROTO	Индикация разрыва связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи и свидетельствует о том, что удаленный пользователь либо отказывает в установлении связи, либо желает разорвать существующее соединение. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих прикладные данные, определенные пользователем. Блок M_PROTO содержит следующие поля:
		PRIM_type	Тип примитива – T_DISCON_IND
		DISCON_reason	Причина разрыва связи
		SEQ_number	Идентификатор соединения
Т_ORDREL_REQ	M_PROTO	Запрос на «аккуратное» прекращение связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи и указывает поставщику транспортных услуг, что пользователь завершил передачу данных. При этом соединение переходит в симплексный режим, позволяя пользователю принимать данные от удаленного узла. Сообщение состоит из одного блока M_PROTO.
Т_ORDREL_IND	M_PROTO	Индикация «аккуратного» прекращения связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи и отправляется пользователю транспортных услуг, свидетельствуя о том, что удаленный пользователь соединения завершил передачу данных. При этом соединение переходит в симплексный режим, позволяя пользователю передавать данные удаленному узлу. Сообщение состоит из одного блока M_PROTO.
T_UNIDATA_REQ	M_PROTO	Запрос на передачу данных. Этот примитив применим только для транспортных услуг без предварительного установления связи и отправляется пользователем транспортных услуг в качестве запроса на передачу дата– граммы. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих прикладные данные пользователя. Блок M_PROTO содержит значение размера адреса и сам адрес получателя датаграммы, а также опции, связанные с этим примитивом. Блок M_PROTO содержит следующие поля:
		PRIM_type	Тип примитива – T_UNIDATA_REQ
		DEST_length	Размер адреса протокола
		DEST_offset	Смещение адреса получателя в блоке M_PROTO
		OPT_length	Размер опций
		ОРТ_offset	Смещение опций в блоке M_PROTO
Т_UNITDATA_IND	M_PROTO	Индикация получения данных. Этот примитив применим только для транспортных услуг без предварительного установления связи и указывает пользователю, что поставщиком транспортных услуг получена датаграмма от удаленного узла. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих прикладные данные пользователя. Блок M_PROTO содержит значение адреса отправителя датаграммы, а также опции, связанные с этим примитивом. Блок M_PROTO содержит следующие поля:
		PRIM_type	Тип примитива – T_UNIDATA_IND
		SRC length	Размер адреса протокола
		SRC_offset	Смещение адреса отправителя в блоке M_PROTO
		OPT_length	Размер опций
		ОРТ_offset	Смещение опций в блоке M_PROTO
T_UDERROR_IND	M_PROTO	Сообщение об ошибке датаграммы. Этот примитив применим только для транспортных услуг без предварительного установления связи и указывает пользователю, что датаграмма с указанным адресом получателя и опциями вызвала ошибку. Сообщение состоит из одного блока M_PROTO, содержащего размер адреса и сам адрес получателя, опции, а также код ошибки, зависящий от конкретного транспортного протокола. Блок M_PROTO содержит следующие поля:
		PRIM_type	Тип примитива – T_UDERROR_IND
		DEST_length	Размер адреса протокола
		DEST_offset	Смещение адреса отправителя в блоке M_PROTO
		OPT_length	Размер опций
		OPT_offset	Смещение опций в блоке M_PROTO
ERROR_type	Код ошибки
T_DATA_REQ	M_PROTO	Запрос на передачу данных. Этот примитив применим только для транспортных услуг без предварительного установления связи и информирует поставщика транспортных услуг, что сообщение содержит пакет данных интерфейса (Transport Interface Data Unit, TIDU). Одно или более таких сообщений формируют пакет данных протокола TSDU. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих прикладные данные пользователя. Блок M_PROTO содержит флаг MORE_flag, указывающий, является ли следующее сообщение T_DATA_REQ частью того же TSDU. На основании этого флага поставщик транспортных услуг компонует транспортные пакеты TSDU. Передача данных с помощью запросов T_DATA_REQ позволяет сохранить границы записи при передаче. Заметим, что протоколом TCP данная возможность не поддерживается.
T_DATA_IND	M_PROTO	Индикация получения данных. Этот примитив применим только для транспортных услуг без предварительного установления связи и информирует пользователя, что сообщение содержит пакет данных интерфейса TIDU. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих прикладные данные удаленного пользователя. Блок M_PROTO содержит флаг MORE_flag, позволяющий пользователю определить границы TSDU.
Т_EXDATA_REQ	M_PROTO	Запрос на передачу экстренных данных. Этот примитив аналогичен T_DATA_REQ, но служит для передачи экстренных данных. Протокол TCP поддерживает передачу экстренных данных с помощью функции t_snd(3N) с аргументом flags, содержащим флаг T_EXPEDITED и, возможно, T_MORE.
T_EXDATA_IND	M_PROTO	Индикация получения экстренных данных. Этот примитив аналогичен T_DATA_IND, но служит для передачи пользователю экстренных данных.
T_OK_ACK	M_PCPROTO	Положительное подтверждение. Этот примитив сообщает пользователю транспортных услуг, что предшествующий примитив, инициированный им, был успешно принят поставщиком транспортных услуг. В то же время, получение подтверждения не означает, что поставщиком были совершены какие-либо действия, связанные с предыдущим примитивом. Сообщение состоит из одного блока M_PCPROTO в котором хранится тип подтвержденного примитива CORRECT_prim.
T_ERROR_ACK	M_PCPROTO	Сообщение об ошибке. Этот примитив сообщает пользователю услуг, последний примитив, инициированный им, вызвал ошибку. Получение этого примитива может рассматриваться как отрицательное подтверждение, свидетельствующее, что никаких действий, связанных с ошибочным примитивом, не было предпринято. Сообщение состоит из одного блока M_PCPROTO, содержащего тип примитива, вызвавшего ошибку, код TLI и код системной ошибки UNIX. Блок M_PCPROTO содержит следующие поля:
		PRIM_type	Тип примитива – T_ERROR_ACK
		ERROR_prim	Тип ошибочного примитива
		TLI_error	Код ошибки TLI
		UNIX_error	Код системной ошибки UNIX
T_INFO_REQ	M_PCPROTO	Запрос на получение параметров транспортного протокола. Этот примитив служит для запроса пользователем значений размеров различных параметров протокола, а также информации о текущим состоянии поставщика транспортных услуг. Сообщение состоит из одного блока M_PCPROTO.
T_INFO_ACK	M_PCPROTO	Параметры транспортного протокола. Этот примитив служит для передачи пользователю ранее запрошенных с помощью T_INFO_REQ параметров транспортного протокола. Сообщение состоит из одного блока M_PCPROTO, содержащего информацию, часть из которой возвращается функцией t_open(3N), рассмотренной в разделе «Программный интерфейс сокетов» ранее в этой главе. Блок M_PCPROTO состоит из следующих полей:
		PRIM_type	Тип примитива – T_INFO_ACK
		TSDU_size	Определяет максимальный размер пакета данных протокола TSDU
		ETSDU_size	Определяет максимальный размер пакета экстренных данных протокола ETSDU
		CDATA_size	Определяет максимальный объем данных, передаваемых при установлении связи. Соответствует полю connect структуры info функции t_open(3N)
		DDATA_size	Определяет максимальный объем данных, передаваемых при разрыве связи. Соответствует полю discon структуры info функции t_open(3N)
		ADDR_size	Определяет максимальный объем транспортного протокола. Соответствует полю addr структуры info функции t_open(3N)
		OPT_size	Определяет размер опций для данного протокола. Соответствует полю options структуры info функции t_open(3N)
		TIDU_size	Определяет размер пакета данных интерфейса TIDU
		SERV_type	Определяет тип транспортных услуг, предоставляемых поставщиком. Соответствует полю servtype структуры info функции t_open(3N)
		CURRENT_state	Определяет текущее состояние поставщика транспортных услуг
		PROVIDER_flag	Определяет дополнительные характеристики поставщика транспортных услуг
T_OPTMGMT_REQ	M_PROTO	Управление опциями протокола. Этот примитив позволяет пользователю получить или установить опции протокола. Сообщение состоит из одного блока M_PROTO, включающего следующие поля:
		PRIM_type	Тип примитива – T_OPTMGMT_REQ
		OPT_length	Размер опций
		ОРТ_offset	Смещение опций в блоке M_PROTO
		MGMT_flags	Флаги, определяющие характер запроса пользователя: T_NEGOTIATE – установить опции, указанные пользователем. В результате опции, установленные поставщиком, могут отличаться от заказанных; T_CHECK – проверить, поддерживаются ли опции, указанные пользователем, поставщиком; T_DEFAULT – возвратить значения опций протокола.
T_OPTMGMT_ACK	M_PCPROTO	Положительное подтверждение. Этот примитив подтверждает завершение операции с опциями протокола, заказанными пользователем. Сообщение состоит из одного блока M_PROTO, включающего те же поля, что и T_OPTMGMT_REQ.