2. Что такое nrm, arm и abm моды работы hdlc

ВСЕ что было на лекциях хоть про один из этих терминов: Первый побитный протокол придумала IBM. Оно называется SDLC. Из него был сделан HDLC.

Поэтому все остальное будет из инета.

Протокол HDLC (High-Level Data Link Control) – протокол второго уровня модели OSI, разработанный организацией ISO. Этот протокол обеспечивает передачу данных между устройствами в режиме точка-точка или точка-многоточка. 

Существуют две версии этого протокола:

1. Стандартный (разработанный ISO)

2. Cisco HDLC (модифицированный Cisco)

Различие между ними, как видно из иллюстрации, заключается в том, что благодаря наличию поля «protocol» в цисковской реализации, существует возможность инкапсулировать в HDLC фрейм пакеты разных протоколов третьего уровня (IPv4,IPv6,IPX,AppleTalk,…). Разным протоколам третьего уровня соответствуют разные значения поля «protocol», таким образом, получатель фрейма «знает», какому вышестоящему протоколу надо передать содержимое после декапсуляции HDLC фрейма. В случае же использования HDLC ISO, подразумевается, что на интерфейсе маршрутизатора используется только один протокол третьего уровня. 

Существует несколько режимов передачи в HDLC:

• NRM (Normal Response Mode) – передача между двумя устройствами (master и slave). Slave не может начать передачу, пока master не даст команду.

• ARM (Asynchronous Response Mode) – передача между двумя устройствами (master и slave). Slave может начать передачу без разрешения master.

• ABM (Asynchronous Balanced Mode) – коммуникация более 2 устройств. Любое устройство может начать передачу в любое время.

29

1. Понятие protection и понятие security. Опишите суть

Относится к коммутаторам.

У IEEE часть функций, которые они потребовали от сетевых адаптеров, коммутаторов в хард не поместились. И они сказали следующее: любые коммутаторы, у которых не помещаются сетевые адаптеры, должны обеспечивать защиту от несанкционированного доступа. Поэтому ОС вот этих систем занимается одним – защитой от нсд.

Protection - как раз защита от несанкционированного доступа (внутри ОС, то, что она защищает своими средствами).

Security – безопасность (внешние средства: видеонаблюдение, контроль входа, замки). Две разные задачи.

2. Коротко дайте формат фрейма дейтаграммы IP. Что означает адрес 127.0.0.0? Адрес 0.0.0.0? Адрес 255.255.255.255?

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

Дейтаграмма состоит из заголовка и основной части (данных). Биты передаются слева направо и сверху вниз (big-endian порядок). В настоящее время ясно, что лучше было бы использовать обратный (little-endian) порядок, но во время создания протокола это не было очевидно. Так на Intel x86 требуется программное преобразование, как при передаче, так и при приеме.

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

Адрес 0.0.0.0 используется при присоединении сети и инициализации. Он же используется в рутерных таблицах как маршрут по умолчанию. Адрес 255.255.255.255 это broadcast, то есть широковещательная рассылка, то есть я пакет рассылаю всем устройствам. Все системы рутеров уже давным-давно не пропускают broadcast (в «умных» книжках пишут обратное, понятно, да?).

30(32)

1. Протоколы прикладного уровня модели OSI. Протоколы Интернет. Реализация в ОС сетевых устройств

Есть еще протоколы прикладного уровня. 5-6-7 протоколы работают под управлением ядра на серверах (в распределенных ОС), на станциях работают шеллы (shell, оболочки), которые просто передают процесс какому-то серверу. Такая передача в современных системах – балансировщики нагрузки

- VTY (от IBM). vty – протокол виртуального терминала (он похож по целям на протокол Telnet, хотя имплементация другая) удалённого устройства (не удалённый доступ в сессию, а эмулятор терминала удалённого устройства - полностью эмулирую хард и софт) - практически не используется

- telnet (сделали разработчики интернета - арпанет) протокол доступа - уровень session.

- Любая ОС должна содержать специальный продукт, который будет пересылать сообщения между узлами системы. Такой протокол назвали MHS (message handle system), в некоторых ОС он так и называется. Он позволяет иметь агента на рабочей станции, он рассматривает сообщение и передает его на специальное устройство – message transfer agent – который дальше будет поддерживаться операторами связи (серверами) и дальше слать его куда-нибудь, пока не найдет нужный сервер, который связан с хранилищем данных (message store). А из него сообщение получит агент на рабочей станции (так работает SMTP, ….POP3(поп3), т.е протоколы интернета). Такой сервер – это mail сервер, он есть в любой ОС.

- Есть передача файлов – протокол FTAM. FTAM выполнял функцию превращения наших данных в универсальный формат. Будет передача протоколами RPC, будут определенные форматы (XDR называется), протокол передачи фалов назвали FTP, протокол, при помощи которого записываются как файловая система– NFS или NTFS. Так FTAM превратился в FTP+ NFS+ XDR. В составе любой ОС

- Есть специальный протокол DS (directory service) от ISO. Это приложение, которое устанавливает распределенные директории для распределенных объектов и БД

- Следующий протокол, который придумали – SBM – протокол управления (придумали IBM). Его аналог – SNMP (Simple network management protocol)(сделали разработчики интернета). У нас есть агенты (они работают на всех устройствах) (это софт, который работает на всех устройствах, есть на всех уровнях OSI (т.е хардвеерные агенты тоже есть)). Агенты будут сообщать менеджерам что-где происходит.

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

- Суть – мы создадим софт на рабочих станциях, мы все делаем на сетевых устройствах, не на станциях, не на сервере. Агенты snmp входят в состав ОС. IEEE занимается стандартами 1-3 уровней, им на SNMP все равно, его сделали разработчики интернета (прим. читайте никто)

Менеджер snmp - софт, который ставится на рабочей станции (7 уровень) - по сути, сервер управления. Агенты шлют сообщения менеджеру. Менеджер не входит в поставку, его покупайте.

Какая инфа собирается: статистическая (что произошло на порту коммутатора1, какое количество ошибок изернета было на порте 2). Как это будет работать. Агент сидит и спит, менеджер его опрашивает - команды get, set и т.д.

2. Понятие приложений реального времени. Приложении мультимедиа. Требования к сетевым протоколам.

Реальное время

Real time системы – должны отвечать и совершать какие-то определенные действия за определенный период времени, и мы должны за этот промежуток получить корректный результат. Такие системы узко специализированные. Они решают обычно одну задачу, НЕ multi user (для одного пользователя). Они делаются в кач-ве SOC’ов – system on chip = на одном чипе.

Данные системы требуют:

чтобы у нас были специальные контроллеры multi memory unity (MMU) – это их хардвеерная часть

Распределенная память.

• работаем через tlb – табличку распределения физических адресов памяти. Процессор обращается к page table, а дальше через нее получаем физический адрес странички физической. Этот вариант более правильный, есть защита, мы не попадаем куда попало. У нас должен быть специальный management memory unit – это хард, без него будет очень медленно и, вообще, не работать.

В системах real time больше используют третий вариант, но при наличии mmu.

Мультимедиа

Multi media системы – голос, видео – составные части системы. Однако видео – очень необычный вид передачи данных. Видео требует, чтобы мы получили определенные действия – delivery или передача за определенный период времени. Для того, чтобы добиться и того и другого нужно предпринять массу действий.

Считается, что 70% информации - это видео теперь. В чем проблема передачи видео? Здесь возникает понятие потока – стрима. Stream в ос используется в трех вариантах:

4. вопросы performance

5. технология написания драйверов. Передается запрос потоком, он от upper level передается ниже при помощи определенного потока параметров: передаю сначала udp к ip, от ip к драйверам и т.д. до тех пор, пока не дойдем до драйверов адаптера, до канальных протоколов, которые сейчас хардвеерные.

6. Поток передачи мультимедийных данных, имеется в виду видео, все остальное не инересует. Мы видим не глазами (ауф), а видим головой (ауф х2). Наша голова воспринимает данные только с определенной скоростью – 25-30 фреймов в секунду в процессе передачи.

Требования

Любая передача мультимедиа очень объемна. Потому что, если передавать в hd tv (высокого разрешения 24.47), то 100минутный фильм = 15 гб. Это очень много, при учете даже современной передачи через оптоволокно, т.к. это передается всем. Скорость передачи должны быть определенная – средний фрейм 800 на 600 пикселей (битов) и на 24 (цвет каждого пикселя, который мы должны передать), все это перемножить и поделить на 30, то скорость передачи должна быть 345 мегабит в секунду. И еще здесь добавляется play back.

Требования к мультимедийным серверам:

• Поскольку везде 345 мегабит в секунду не везде можно обеспечить, займемся компрессией – сжимать данные, чтобы передать больше. Любе устройство, передающее мультимедиа, должно уметь compression и decompression.

Компрессия бывает с полным и неполным восстановлением. Полное нам не надо, потому что мы не передаем данные, а видео. Алгоритм mpeg – умеет передавать до 15 мбит в сек.

• Должны иметь мультимедийные расписания, то есть расписания с перехватом, иначе не уложимся в эти 25-30 фреймов в секунду. Нужен rt linux, его нет и начинают искать выход из ситуации. Любая ос должна обрабатывать запросы такие переодически. Это значит, что раз в доле милисекунды идет кусочек информации - периодический процесс. При этом ос поддерживает функцию quality of service, то есть ос поддерживает определенную скорость:

• ОС делает это в варианте best effort (оно есть у всех ос) – стараюсь очень сильно отдать тебе все-все ресурсы, чтоб ты выполнил требования по скорости, однако ни одна ос так не работает, потому что любая ос приберегает какое-то кол-во ресурсов для задач, которые могут появиться.

• Есть вариант soft cost – я раздам процессам приоритеты динамически. У винды для процессов высокий приоритет от 16 до 32. Но такое не прокатит с системой мультимедиа. Soft cost не гарантирует скорость, я гарантирую давать тебе приоритеты и пропускать тебя быстрее других. Осуществляется при помощи shaping, polling, обработка буферов.

• Hard cost – ос гарантирует вам скорость. Для такой гарантии нам нужна определенная пропускная способность (необходимая для передачи мультимедиа), delay должны быть как-то фиксированы и считается в битах, jitter (дрожание, которое возникает при передаче данных), которое может возникать при разной работе софта и харда (определение ошибок или еще чем-то занят) – мы не моем гарантировать, что у нас будет всегда одна заявленная скорость (между фреймами дрожания быть не должно, иначе эти фреймы «встанут»), reliability (надежность) – мы не можем передавать стрим еще раз.

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

• Для того, чтобы передавать с перемотками надо иметь спец. сетевые протоколы. Такие протоколы прикладные.

• Admission control protocol – его нет как протокола «для всех». Это спецификация для каждого вида устройства своя. «Я обращаюсь к коммутатору. Говорю: дай мне буфер, если у тебя он есть. Дай мне кредит. И буду передавать, только если кредит дается, тогда я выдержу временные характеристики» - так работают коммутаторы в data центрах. С помощью спец. средств там есть возможность переключаться вас на любой порт, буфер любого порта вас обслужит.

• Все процессоры должны иметь CPU scheduling, и он должен быть real time, удовлетворял требованиям передачи мультимедиа. В первую очередь мы не можем вводить динамические приоритеты, они все фиксированы, иначе мы не успеем в периодические процессы.

• У нас есть диски и подсистемы ввода-вывода. Если мы передаем 15 гб фильм. Хорошо бы куда-нибудь записать, в частности диска мультимедийного сервера и от туда делать стриминг. Но тогда вся подсистема ввода-вывода должна иметь спец. алгоритмы.