А. Робачевский - Операционная система UNIX (1114671), страница 91
Текст из файла (страница 91)
Заметим, что вконкретном случае использования транспортного протокола TCP прием ипередача данных осуществляются в виде потока, не содержащего каких!либологических записей. В этом случае не требуется формирование примитивовтипаи T_DATA_IND. В то же время, для передачи и полученияэкстренных данных будут использованы примитивы T_EXDATA_REQ иПри использовании протокола UDP все данные будут пере!даваться С ПОМОЩЬЮ примитивовИОписанная реализация программного интерфейса ТЫ имеет один сущест!венный недостаток — операции функций не являются атомарными.
Дру!гими словами, выполнение функцииможет быть прерванодругими процессами, которые могут также связываться с удаленным узлом.Это возможно, поскольку выполнение значительной части операций про!исходит в режиме задачи. Если для функциинарушение ато!марности допустимо, то ряд функций, таких, например, как связываниеполучение информациии установкаили получение опций протоколадолжны быть защищеныот возможного нарушения целостности данных по причине прерыванияоперации. Единственным способом гарантировать атомарность являетсяперевод выполнения критических участков (например, между отправлени!ем примитива и получением подтверждения от поставщика транспортныхуслуг) в режим ядра. Для этого подсистема STREAMS предлагает механизмобмена управляющими командами с помощью вызова ioctl(2).Однако с помощьюкак было показано в разделе "ПодсистемаSTREAMS" главы 5, можно формировать лишь сообщения типаДля преобразования этих сообщений в примитивы TPI служит дополни!тельный модульвстраиваемый в поток между головным итранспортным модулями.
На рис. 6.33 показано местоположение модуляи схематически отображены его функции.Для всех сообщений STREAMS, за исключением сообщенийко!торые генерируются головным модулем в ответ на системный вызовI_STR, . . .модульявляется прозрачным, т. е. онпросто передает эти сообщения следующему модулю вниз по потоку безкакой!либо обработки.
Несколько сообщений M_IOCTL обрабатываютсямодулем и преобразуются в соответствующие примитивы TPI.www.books-shop.comГлава 6.486сети в операционнойUNIXПри этом вызов ioctl(2) имеет следующий формат:struct strioctl my strioctl;=== size;= (char *)bufИнтерфейссистемныхвызововРис. 6.33. Архитектура доступа к транспортным услугамПри вызове ioctl(2) поле s i z e устанавливается равным размеру соответст!вующего примитива TPI, определенного полем cmd и расположенного вбуфереПри возврате из функции полесодержит размер прими!www.books-shop.comсети в UNIX System Vтива, возвращенного поставщиком транспортных услуг и расположенногов буфереМодульслужит для обработки следующих командЗначение cmdОбработка модулемКоманда преобразуется в примитив T_BIND_REQ.
При успеш%ном завершении функции ioctl(2) в буфере buf находится при%митивTI_UNBINDTI_GETINFOКоманда преобразуется в примитив T_UNBIND_REQ. При ус%пешном завершении функциив буференаходитсяпримитивКоманда преобразуется в примитивПри успеш%ном завершении функции ioctl(2) в буфере buf находится при%митивКоманда преобразуется в примитивПри ус%пешном завершении функции ioctl(2) в буфере buf находитсяпримитив тАСК.Интерфейс DLPIDLPI определяет интерфейс между протоколами уровня канала данных(data link layer) модели OSI, называемыми поставщиками услуг уровня ка!нала данных и протоколами сетевого уровня, называемыми пользователя!ми услуг уровня канала данных.
В качестве примера пользователей услугуровня канала данных можно привести такие протоколы, как IP, IPX илиCLNS. С другой стороны, поставщик услуг уровня канала данных непо!средственно взаимодействует с различными сетевыми устройствами, обес!печивающими передачу данных по сетям различной архитектуры(например, Ethernet, FDDI или ATM) и использующими различные физи!ческие среды передачи.Для обеспечения независимости DLPI от конкретной физической сетипередачи драйвер уровня канала данных состоит из двух частей: верхнейаппаратно независимой и нижней аппаратно зависимой. Аппаратно неза!висимая часть драйвера обеспечивает предоставление общих услуг, опре!деленных интерфейсом DLPI, а также поддержку ряда потенциальныхпользователей, представляющих семейства протоколов TCP/IP, NetWare иАппаратно зависимая часть непосредственно взаимодействует с сете!вым адаптером.На рис.
6.34 приведена структура драйвера поставщика услуг уровня кана!ла данных. Обмен данными между аппаратно независимой частью драйве!ра и пользователем услуг осуществляется в виде сообщений STREAMS,формат и назначение которых и определяется спецификацией DLPI (т. н.примитивы DLPI).www.books-shop.comГлава 6.в операционной системе UNIXВо время инициализации и последующей передачи данных аппаратно не!зависимая часть драйвера вызывает необходимые функции аппаратно за!висимой части.
Напротив, при поступлении данных из сети, аппаратнозависимая часть помещает пакеты данных, или кадры, непосредственно вочередь чтения аппаратно независимой части. Обе части совместно ис!пользуют набор переменных и флагов для взаимной синхронизации и кон!троля передачи.Рис. 6.34. Структура драйвера уровня канала данныхПользователь получает доступ к услугам поставщика услуг уровня каналаданных через точку доступа к услугам (Service Access Point, SAP), исполь!зуя сообщения STREAMS для обмена данными.
Поскольку один постав!щик может иметь несколько пользователей, например IP и IPX, в его за!дачу входит маршрутизация данных, полученных от физической сети, кнескольким точкам доступа. Для этого каждый пользователь идентифици!рует себя с помощью адреса SAP, который сообщает поставщику, исполь!зуя примитив связывания (DL_BIND_REQ) потока с точкой доступа к услу!гам уровня канала данных.Поскольку аппаратно зависимая часть драйвера может обслуживать не!сколько сетевых адаптеров, каждый сетевой интерфейс идентифицируетсяточкой физического подключения (Physical Point of Attachment, PPA).
Приэтом спецификация DLPI определяет два типа поставщиков услуг. По!ставщик услуг первого типа (style 1) производит назначение РРА, исходяиз старшего и младшего номеров используемого специального файла уст!ройства (указанного в вызовеОбычно каждый адаптер, обслужи!ваемый драйвером, ассоциирован со старшим номером, а младший номериспользуется для создания клонов (см. раздел "Клоны" главы 5). Напро!www.books-shop.com489в UNIX System Vтив, поставщик второго типа (style 2) позволяет пользователю явно указатьРРА уже после открытия потока с помощью примитива присоединенияИспользование поставщиков второго типа является бо!лее предпочтительным, например, когда одна физическая сеть поддержи!вает создание независимых логических, или виртуальных каналов передачиданных (например, каналы ISDN В и D). В этом случае идентификаторРРА, передаваемый примитивом DL_ATTACH_REQ, содержит также иден!тификатор логического канала.
Схема описанных точек доступа приведенана рис. 6.35.Пользовательуслуг уровняканала данныхПользовательуслуг уровняканала данныхПользовательуслуг уровняканала данныхDLPIПоставщикуслуг уровняканала данныхСетевые адаптерыРис. 6.35. Доступ к услугам поставщика услуг уровня канала данныхDLPI определяет три различных режима передачи данных (или типов ус!луг), позволяющих обеспечить различные требования протоколов верхнегоуровня и поставщиков услуг уровня канала данных:1.
Режим с предварительным установлением связи2. Режим без предварительного установления связи с подтверждением3. Режим без предварительного установления связи без подтвержденияВ данном разделе мы остановимся только на режиме без предварительногоустановления связи без подтверждения. Заметим, что для традиционныхтехнологий локальных сетей используется именно этот тип услуг уровняканала данных.Поскольку дальнейшее обсуждение будет касаться преимущественно ком!муникационной инфраструктуры локальных сетей, кратко остановимся налогическом делении уровня канала данных модель OSI в соответствии состандартом IEEE 802.
Применяемые сегодня технологии локальных сетейсущественно отличаются друг от друга, как по физической среде и топо!Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRSɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕɈɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭpiracy@books-shop.com490Глава 6.сети в операционнойUNIXтак и по способу передачи данных в этой физической среде и фор!мату передаваемых данных. Поэтому стандарт IEEE 802 разделяет прото!колы локальных сетей на два логических подуровня:Верхний независимый от среды передачи подуровень, названныйуровнем управленияканалом (Logical Link Control, LLC),определенный стандартом IEEE 802.2.Нижний зависимый от среды передачи подуровень,нем управления доступом к среде передачи (MediaMAC), определенный стандартами IEEE 802.3CSMA/CD, IEEE 802.4 для протокола Token Bus иToken Ring.названный уров!Access Control,для протоколаIEEE 802.5 дляДоступ к среде передачиОбщим в наиболее распространенных технологиях локальных сетей явля!ется то, что несколько сетевых устройств совместно используют одну и туже среду передачи данных, и соответственно делят между собой полосупропускания сети.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
