8 Лекция (21.03.2024)

В «сложной» схеме будут присутствовать следующие элементы:

1. Switch

2. Стандарт Ethernet 802.3, который делает 99% работы

3. Стандарт DTIO 568

4. Файл-сервер

5. Сервер базы данных

6. Web-сервер

7. Router

8. Мультиплексор, который соединяет нас с MUX’ом

9. Оператор-связь

Когда мы говорим о работе процессов в этой схеме, подразумевается седьмой уровень модели OSI и протоколы OSI. Один из таких протоколов называется FTP, аналогом которого является файл-сервер. Помимо него, также подразумеваются протоколы HTTP, протокол mail-сервера и т.д.

Т.е., можно сказать, что у нас каждый раз реализация процесса связана с реализацией протокола традиционной системы и такие процессы, как multimedia и real-time являются специальными.

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

Например, у нас есть трансляция телевидения. Если она каким-то образом проигрывается, например, на нашем телевизоре, то мы не можем её смотреть быстрее, потому что будет всё «лететь» и не можем смотреть медленнее, потому что тогда она будет стопориться (останавливаться). Поэтому, мы должны передачу трансляции и доступ во время этой передачи получить за определённое время. Эта задача возможно только в случае наличия мультимедийного сервера.

Если же у нас есть задача, связанная с real-time (получение корректного результата), то у нас должны быть такие расписания и алгоритмы, которые позволяют их модифицировать для того, чтобы выполнялись действия за deadline. Т.е., это в основном вопрос того, как мы делаем schedule. У нас есть расписание доступа к диску, расписание доступа к fred’ам, расписание доступа к процессору. Т.е., мы всё время делим, причём таким образом, чтобы мы попадали в deadline. Это у нас вопрос того, как мы будем делать расписание.

Если же у нас мультимедийная задача, то нужно предъявить определённые требования к:

1. Системам записи на диск, поскольку просто так мы не запишем за deadline

2. Системам, которые позволяют это передавать по сетевым устройствам (Network Management), поскольку мы не передадим за этот deadline

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

В real-time системе применяют два требования:

Во-первых, это латенция реагирования на interapt (interapt latency). Она применяется в том случае, если есть прерывание от какого-то контроллера (контроллера ноги, контроллера руки и т.д.) у этого «робота».

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

В случае с системой multimedia мы должны не только получить результат за deadline, но и доступ к данным за определённый период времени (24-30 фреймов в секунду). Но отсюда возникает проблема. Например, если мы дадим скорость 100 гигабит в секунду, то, с одной стороны нам нужна такая скорость, потому что скорость — это пропускная способность канала и отсюда сплошное волокно, но с другой стороны, она должна быть жестко ограничена и отсюда возникают проблемы quality of service.

Поэтому, скорость 24-30 фреймов в секунду является жёстким требованием, потому что у нас есть несколько видов передачи видео. Есть то, что называют progressive download. Это означает, что мы сбросили куда-то на сервер изображения и далее раздаём их в рамках какой-то более-менее локальной системы. Так работает, например, телевидение, потому что оно сбрасывается на какой-то узел в московском регионе, а оттуда по кабельным системам это раздаётся к нашим домам.

Есть также живая трансляция (lifetime). Это означает, что если мы передаём, например, сообщения, концерты или что-то другое, то это не сбрасывается, а идёт в прямой трансляции.

Поэтому, в обоих случаях есть всегда кто-то, кто передает (трансмиттер), а есть тот, кто проигрывает (ресивер), причём, ресивер проигрывает либо в режиме живых изображений (real-time), либо в режиме download.

Стоит отметить одну проблему, возникающую при проигрывании в режиме download. Она связана с тем, что мы осуществляем к ресиверу random доступ, поскольку мы можем перемотать, остановить трансляцию или потребовать on-demand.

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