Операционная система UNIX - Андрей Робачевский

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

Итак, приведем некоторые управляющие сообщения DLPI, используемые в режиме без предварительного установления связи и без подтверждения. В табл. 6.12 приведено их краткое описание.

Таблица 6.12. Примитивы DLPI

Примитив DLPI Тип сообщения Значение DL_BIND_REQ M_PROTO Запрос на связывание. Этот примитив инициируется пользователем услуг и запрашивает связывание потока с точкой доступа и его активизацию. Следует иметь в виду, что активным считается поток, для которого поставщик услуг может передавать или принимать пакеты данных. Таким образом, PPA, ассоциированная с данным потоком, должна быть инициализирована до завершения обработки запроса на связывание (другими словами, поставщик гарантирует, что при получении пользователем подтверждения связывания DL_BIND_ACK инициализация PPA завершилась успешно. Сообщение состоит из одного блока M_PROTO, который содержит значение адреса SAP, тип услуги и ряд других параметров, обсуждение которых выходит за рамки данной книги. DL_BIND_ACK M_PCPROTO Подтверждение получения запроса на связывание. Этот примитив отправляется пользователю услуг и означает, что поток был связан с адресом SAP и был активизирован. Сообщение состоит из одного блока M_PCPROTO, в частности, содержащего значение адреса SAP. DL_ATTACH_REQ M_PROTO Запрос на подключение к PPA. Этот примитив инициируется пользователем услуг уровня канала данных и запрашивает у поставщика ассоциацию потока с указанной PPA. Этот запрос является необходимым для поставщика второго типа (style 2) для указания физической среды, по которой будут передаваться данные. Сообщение состоит из одного блока M_PROTO, в котором пользователь передает значение идентификатора PPA. Формат этого идентификатора определяется поставщиком. Пользователь должен указать, как минимум, физическую среду передачи. Для сетей, где несколько независимых каналов передачи мультиплексируются в одном физическом носителе, идентификатор также должен содержать информацию о конкретном канале передачи данных. Примером технологий, обеспечивающих такое мультиплексирование являются ISDN (каналы В и D) и ATM (коммутируемые и постоянные виртуальные каналы — SVC и PVC). DL_INFO_REQ M_PCPROTO Запрос на получение параметров потока. Этот примитив служит для запроса пользователем значений размеров различных параметров потока, активизированного поставщиком DLPI, а также информации о текущем состоянии интерфейса. Сообщение состоит из одного блока M_PCPROTO. DL_INFO_ACK M_PCPROTO Параметры транспортного протокола. Этот примитив служит для передачи пользователю ранее запрошенных с помощью DL_INFO_REQ параметров. Сообщение состоит из одного блока M_PCPROTO, содержащего информацию, часть из которой приведена ниже: dl_max_sdu — определяет максимальное число октетов данных пользователя, которое может быть передано в одном кадре. (Максимальный размер SDU поставщика услуг.) dl_min_sdu — определяет минимальный размер SDU. dl_addr_length — определяет максимальную длину адреса DLSAP поставщика. Этот адрес, помимо адреса SAP может также включать физический адрес интерфейса и ряд других полей (иерархический адрес). dl_addr_offset — указывает смещение адреса DLSAP в блоке M_PCPROTO. dl_mac_type — указывает тип среды передачи, поддерживаемой потоком DLPI. См. значение поля mac_type структуры DL_sap_t ранее в этой главе. dl_current_state — указывает текущее состояние потока. dl_service_mode — определяет тип услуги, обеспечиваемой потоком DLPI. dl_provider_style — определяет тип поставщика услуг (style 1 или style 2). dl_brdcst_addr_length — определяет размер физического широковещательного адреса. dl_brdcsr_addr_offset — указывает смещение значения адреса DLSAP в блоке M_PCPROTO. DL_UNITDATA_REQ M_PROTO Запрос на передачу данных. Этот примитив применим только для услуг уровня канала данных без предварительного установления связи и отправляется пользователем услуг в качестве запроса на передачу кадра. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих данные пользователя. Блок M_PROTO содержит значения размера адресов и сам адрес получателя кадра, а также приоритет из диапазона, определенного поставщиком. DL_UNITDATA_IND M_PROTO Индикация получения данных. Этот примитив применим только для услуг уровня канала данных без предварительного установления связи и указывает пользователю, что поставщиком услуг получен кадр от удаленного узла. Сообщение состоит из одного блока M_PROTO, за которым может следовать один или несколько блоков типа M_DATA, содержащих данные пользователя. Блок M_PROTO содержит значения адресов отправителя и получателя кадра. DL_OK_ACK M_PCPROTO Положительное подтверждение. Этот примитив сообщает пользователю услуг уровня канала данных, что предшествующий примитив, инициированный им, был успешно принят поставщиком услуг. Примитив DL_OK_ACK передается только для примитивов, нуждающихся в подтверждении. DL_ERROR_ACK M_PCPROTO Сообщение об ошибке. Этот примитив сообщает пользователю услуг, что последний примитив, инициированный им, вызвал ошибку. Получение этого примитива может рассматриваться как отрицательное подтверждение, свидетельствующее, что никаких действий, связанных с ошибочным примитивом, не было предпринято. Сообщение состоит из одного блока M_PCPROTO, содержащего тип примитива, вызвавшего ошибку, код DLPI и, если возможно, код системной ошибки UNIX. DL_UDERROR_IND M_PROTO Сообщение об ошибке кадра. Этот примитив применим только для услуг уровня канала данных без предварительного установления связи и указывает пользователю, что его запрос на передачу DL_UNITDATA_REQ вызвал ошибку и не может быть выполнен. Сообщение состоит из одного блока M_PROTO, содержащего размер адреса и сам адрес получателя, а также код ошибки.

Заключение

В этой главе описана организация сетевой поддержки UNIX. Рассмотрение не выходило за рамки обсуждения семейства протоколов TCP/IP, хотя архитектура сетевого доступа операционной системы позволяет обеспечить поддержку практически любых протоколов. В этом отношении большей гибкостью обладает сетевая подсистема UNIX System V, основанная на архитектуре STREAMS.

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

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

Во второй части главы была описана внутренняя архитектура сетевых подсистем в BSD UNIX и UNIX System V. Хотя эти вопросы наиболее интересны разработчикам драйверов и других подсистем ядра, более пристальный взгляд на взаимодействие компонентов операционной системы может помочь и администраторам в решении их проблем, и пользователям в оценке качества работы их систем для уверенного обсуждения этой темы с системным администратором.