V Международная студенческая научная конференция Студенческий научный форум - 2013

Введение

В наш век информационных технологий, везде используются сети, будь то Интернет, сеть предприятия, или сеть организованная соседскими ребятишками для компьютерных игр. В данной работе нам бы хотелось рассмотреть ещё одно использование сетей – передача так называемых скриншотов (от англ. «screenshot» – снимок экрана) по сети в реальном режиме времени.

Данная задача вытекает из проблемы – бесплатных программ осуществляющих передачу скриншотов по сети от одного компьютера многим в настоящее время существует не так много. Из них, программ основанных на технологиях оптимизирующих нагрузку на сеть и процессор ещё меньше. Ну а если ещё добавить такое требование, как бесплатность программы, то в итоге количество программ отвечающих выше описанным требованиям стремится к нулю, по крайне мере найти такую программу в Интернете не удалось. Однако, как оказалось, создать подобную программу не так уж сложно.

Цель исследования – разработать программу, реализующую передачу скриншотов по сети от одного компьютера многим с учетом оптимизации нагрузки на сеть и на процессор компьютера осуществляющего передачу изображения.

Задачи исследования:

1. Изучить справочную литературу по данной теме.

2. Изучить существующие программы, затрагивающие данную тему.

3. Исследовать некоторую часть сетевых технологий с точки зрения программирования.

4. Создать программу, которая отвечала бы требованиям перечисленным выше.

5. Изучить удобство применения данной программы, сделать вывод.

Программа была разработана с использованием таких сред программирования, как:

• Lazarus (бесплатный аналог Delphi);

• CodeBlocks (бесплатная среда разработки C++);

• Windows Driver Kit (распространяемый Microsoft «пакет», в котором содержатся примеры драйверов и утилиты для их компиляции).

Т.к. все они являются бесплатными, и программа была разработана нами, то требование к бесплатности программы считается выполненным.

Рассматривать применение этой программы будем на примере компьютерного класса.

Объектом исследования являютсятехнологииmirror driver, multicast, quicklz(zlib) и процесс проектирования и реализациипрограмм передачи скриншотов по сети.

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

Исследование было проведено в несколько этапов:

1. Изучение проблемы исследования.

2. Определение цели и задач исследования.

3. Разработка программы.

4. Отладка и тестирование программы.

5. Внедрение программы в учебный процесс.

6. Научное обоснование программы.

Работа состоит из введения, двух глав, заключения, списка литературы

Данная программа была апробирована и используется в учебном процессе в 2 компьютерных кабинета факультета среднего профессионального образования ТГСПА, в одном из этих кабинетов совсем не используется проектор, а вместо него используется представленная программа.

Также программа была предложена преподавателю информатики в МАОУ СОШ № 15 г. Тобольска, где также была задействована на уроках, проводившихся в компьютерном кабинете.

В обоих случаях программа была внедрена с марта 2011 года и используется по настоящее время.

Глава 1. Мультимедиа технологии

1.  
   1. Сущность понятия и история появления мультимедиа – технологий

В самом деле, программа, передающая изображения в реальном режиме времени является подвидом мультимедиа – технологий. Рассмотрим термин «мультимедиа» по Е. Г. Капралову.

Слово «мультимедиа» или словосочетания «мультимедиа-произведение», «мультимедиа-технология» встречаются в разговорной лексике чрезвычайно часто, но не всегда правильно и без четкого понимания сути этих терминов. И причина этого не в том, что термин англоязычный, не нашедший точного и короткого адекватного русского определения, а в том, что даже в англоязычной литературе сами носители языка называют этот термин неудачным определением (ill-defined). Поэтому попытка дать определение понятию «мультимедиа» приводит в лучшем случае к чему-то длинному и непонятному, наприер «новый способ коммуникации, включающий в себя синергию между звуком, образами и текстом» и в худшем — к малопонятному термину «многосреда». По этой причине интереснее взглянуть на такое явление, как «мультимедиа» в историческом плане и рассмотреть перспективы его развития и использования.

Важно отметить, что понятие «мультимедиа» в настоящее время используется даже людьми искусства — художниками, музыкантами (особенно теми, кто применяет в своем творчестве компьютеры). Термин этот ведет свое происхождение из истории развития информатики и напрямую связан с компьютерными технологиями.

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

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

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

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

Рождение первого «мультимедийного» компьютера относят к 1984 г. Это был компьютер с графическим интерфейсом. Компьютер получил известное всем в дальнейшем название Macintosh и был изготовлен фирмой Apple Computer, выпускавшей до этого первые в мире популярные персональные компьютеры — Apple и Apple II. Впервые массовый пользователь получил возможность общаться с компьютером не только с помощью клавиатуры, но и поразившей всех «мыши». Вместо букв на черном экране пользователь увидел «иконки» (закладки), изображающие объекты операционной системы: мусорную корзину; папки, выдвигающиеся наподобие ящиков письменного стола; строки меню; символизирующий человеческую руку курсор.

С тех пор термин «графический интерфейс пользователя (GUI)» прочно занял свое место в лексиконе компьютерной индустрии, а использующие графику компьютеры сделали возможным массовое их распространение. Создание графического интерфейса стимулировало развитие средств графического отображения. Спустя несколько лет появились цветные графические мониторы (EGA, VGA, SVGA) и изображение стало еще более реалистичным. Вслед за Macintosh возникли и другие, основанные на графическом интерфейсе, операционные системы. Они позаимствовали основные принципы работы с графическими элементами интерфейса у Macintosh, что послужило даже основой для скандалов и судебных разбирательств. Но для массового пользователя графический интерфейс по сегодняшний день не имеет альтернативы, и поэтому практически все современные операционные системы используют его и непрерывно совершенствуют.

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

И наконец, в 1989 г. компания Apple Computer, ставшая признанным лидером компьютерных новшеств, приступила к разработке технологии, позволяющей просматривать на экране компьютера движущееся изображение, названное «цифровым видео», вместе со звуковым сопровождением. Эта технология, выпущенная в свет в 1991 г. под названием QuickTime, и стала фундаментом явления, получившего широчайшее распространение под названием «мультимедиа».

Появление технологии QuickTime произвело огромное впечатление на широкую публику. Компьютер приобрел свойства телевизора и привлекательность его для массового пользователя возросла необычайно. Но если для обычных пользователей QuickTime означает лишь средство для просмотра конечного продукта — в основном различных мультимедиа-компакт-дисков (CD-ROM), то для специалистов — это в первую очередь набор стандартов и форматов, т. е. основа для производства цифрового видео, звука, анимации, графики — всего того, что по-английски называется media content. В последнее время также часто употребляется и еще один термин digital art — художественное творчество с использованием цифровых технологий. [9]

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

- Mpeg (Mpeg-1, Mpeg-2, Mpeg-3, Mpeg-4);

- Flash;

- IP-TV, IP-телефония;

- и др.

Рассмотрим классификацию мультимедиа – технологий, которую даёт Е.С. Чердынцев, в своё учебном пособии «Мультимедийные сети».

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

1.2. Классификация мультимедиа – технологий

Рассмотрим классификацию мультимедиа – технологий по Е.С. Чердынцеву. С точки зрения передачи мультимедиа могут быть классифицированы на передаваемые в реальном времени (Real-Time – RT) или не в реальном времени (Non Real-Time – NRT). Мультимедиа первого типа (RT) требуют ограничений на задержку пакетов, в то время как мультимедиа второго типа (например, текст и изображение) таких ограничений не требуют, но могут иметь жесткие ограничения на наличие ошибок при передаче. Существует два основных подхода к контролю ошибок при передаче мультимедийной информации. Первый основан на автоматическом повторе передачи потерянных или поврежденных пакетов (Automatic Retransmission reQuest – ARQ). Этот подход используется в протоколе транспортного уровня TCP (Transport Control Protocol) в стеке протоколов TCP/IP. Приложения, требующие безошибочной передачи NRT-информации, обычно используют именно этот протокол.

При втором подходе (Forward Error Correction – FEC) передается избыточная информация, позволяющая обнаруживать и исправлять ошибки без повторной передачи пакетов. Такой подход используется в другом протоколе транспортного уровня UDP (User Datagram Protocol) в том же стеке протоколов TCP/IP. Приложения, обменивающиеся мультимедийной информацией, допускающей ошибки (как RT, так и NRT), обычно используют UDP для исключения потерь времени на повторную передачу пакетов.

RT-мультимедиа разделяются на дискретную (Discrete media – DM) и непрерывную (Continuous media – CM), в зависимости от того, передаются ли данные дискретными порциями или непрерывным потоком.

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

Текст

Текст наиболее популярен среди остальных типов мультимедиа. Он представлен в сети Интернет различными формами, включая файлы или сообщения, использующие различные протоколы передачи, такие как FTP (File Transfer Protocol: для передачи двоичных и ASCII-файлов), HTTP (Hyper Text Transfer Protocol: для передачи HTML-страниц) или SMTP (Simple Mail Transfer Protocol: для обмена почтовыми сообщениями). В двоичном виде текст представляется в 7-битной US-ASCII, 8-битной ISO-8859, 16-битной Unicode или 32-битной ISO 10646 кодировочных таблицах, в зависимости от используемого языка и страны. Требования к пропускной способности для текстовой информации в основном зависят от ее размера, который может быть существенно уменьшен при использовании различных схем сжатия информации.

Требования к допустимому уровню ошибок при передаче текста зависят в основном от используемых приложений. Приложения, передающие текстовые файлы, требуют полного отсутствия ошибок передачи и используют протокол TCP. Другие приложения могут допускать некоторый процент ошибочной информации и используют для передачи протокол UDP.

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

Звук

Звуковая информация представляет собой звуки, преобразованные в цифровой вид с использованием выборок (sampling) и квантизации (quantization).

Оцифрованный звук передается по сети как поток дискретных пакетов. Требования к пропускной способности сети зависят от характеристик звука. Например, голос по телефону сжимается с потерей информации с 12 до 8 бит. Это уменьшает скорость передачи с 96 до 64 Кбит/с.

Звуковая информация не накладывает жестких ограничений на наличие ошибок в процессе ее передачи. Потеря 1…2 % пакетов практически не отражается на ее качестве. Сегодня большинство мультимедийных приложений, использующих звук, имеют встроенный механизм интерполяции потерянных пакетов.

Требования реального времени для звука жестко связаны с ожидаемым уровнем интерактивности участвующих сторон. Некоторые приложения, такие как Интернет-телефония, подразумевающие двустороннее взаимодействие, имеют высокий уровень интерактивности и требуют коротких времен отклика. В этом случае накладываются жесткие ограничения на задержку пакетов для обеспечения приемлемого качества звука. Приложения, использующие такой тип мультимедиа, называют зависимыми от режима реального времени (Real-Time Intolerant – RTI). В большинстве RTI-приложений допускается задержка не более 200 мс. В других приложениях, таких как Интернет-вещание (webcast), использующих одностороннюю передачу звука, уровень интерактивности близок к нулю. Интерактивность в этом случае ограничивается командами пользователя к смене каналов.

Графика и анимация

В эту группу входят как статичные цифровые изображения, так и динамические изображения, такие как flash-презентации. Несжатое цифровое изображение состоит из массива пикселей, где каждый пиксель со своими параметрами хранится в определенном количестве битов памяти. По сравнению с текстом, цифровые изображения требуют намного больше памяти. Например, изображение размером 4 на 6 дюймов при разрешении экрана 480 на 640 пикселей и 24-битном цвете требует около одного мегабайта памяти. Передача такого изображения по сети со скоростью 56,6 Кбит/с занимает около двух минут. Если изображение сжато в 10 раз, требуется уже около 100 Кбайт памяти и передача занимает около 14 секунд. Некоторые схемы сжатия приведены в табл. 1.

Большинство современных схем сжатия имеют прогрессивный характер, что очень важно при передаче изображений по коммуникационным сетям. Когда такое изображение получается, пользователь вначале видит вариант низкого качества, который затем постепенно улучшается. Обычно достаточно принять 5…10 % изображения, чтобы получить общее представление о нем. Прогрессивное сжатие достигается:

• прогрессивным кодированием часто встречающихся фрагментов изображения;

• векторной квантизацией, начиная с оттенков серого цвета с последовательным добавлением цветов;

• пирамидальным кодированием, разбивающим изображение на слои в порядке увеличения разрешения при росте номера слоя.

Таблица 1. Схемы сжатия изображения

Схема сжатия	Комментарии
Graphics Interchange Format (GIF)	Поддерживает до 256 цветов. Использует LZW (Lempel-ZivWelch); сжатие без потерь информации с поддержкой анимации.
Portable Network Graphics (PNG)	Поддерживает любое количество цветов. Использует схему сжатия zlib с адаптивным фильтром сжимаемых блоков. Схема с потерей информации и без поддержки анимации.
Joint Photographic Experts Group (JPEG)	Наилучшим образом подходит для сжатия цветных и черно-белых фотографий с большим количеством цветовых оттенков (или оттенков серого). Этот стандарт сжатия базируется на использовании кодирования по Хауфману и кодов длин серий в процессе дискретного косинусного преобразования коэффициентов блоков изображения. Сжатие происходит с потерей информации. Стандартный JPEG не разрешает чересстрочную развертку, но ее поддерживает прогрессивный формат (Progressive JPEG). Progressive JPEG начинает с укрупненных блоков изображения с последующей их детализацией.
JPEG2000	Подходит для широкого спектра изображений, поэтому используется в портативных цифровых камерах. Использует внедренную технику, основанную на вейвлетах (wavelet), хранящих информацию в потоке данных, а не в блоках. Эта схема также приводит к масштабируемой потере информации.
JPEG-LS	Подходит для однотонных изображений. Схема основана на алгоритме LOCO-I (Low COmplexity LOssless COmpression for Images), разработанном HP. Это схема без потери или практически без потери информации.
Joint Bi-level Image Experts Group (JBIG)	Подходит для черно-белых изображений. Использует схему множественного арифметического кодирования без потери информации.

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

Видео

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

Ограничения на наличие ошибок передачи и передачу в реальном времени аналогичны ограничениям для звука. [14]

На основании выше изложенного можно классифицировать нашу программу как мультимедиа – технологию, осуществляющую передачу изображений на удалённые компьютеры по сети, в реальном режиме времени по протоколу UDP с использованием схемы сжатия Portable Network Graphics (PNG). Таким образом на удалённых компьютерах создаётся эффект анимации.

Хотелось бы ещё отметить пережатие осуществляемое в нашей программе – это пережатие реализуемое библиотеками zlib(PNG) и quicklz. Отличие между ними в скорости и качестве пережатия. У zlib существует 9 уровней пережатия, у quicklz 3 уровня пережатия. Чем выше уровень пережатия – тем «сильнее» пережимается информация, однако нагрузка на процессор, конечно же возрастает. Отличие между zlib и quicklz, в скорости пережатия и качестве. QuickLZ обгоняет по скорости(соответственно меньшая нагрузка на процессор) zlib, что хорошо для более медленных ПК, однако немного проигрывает в качестве пережатия.

Итак, благодаря пережатию применяемому в нашей программе уменьшается нагрузка на сеть, т.к. уменьшается размер изображений. Это «качественное» уменьшение нагрузки на сеть. Рассмотрим теперь «количественное» уменьшение нагрузки на сеть.

1.3. Потоковое вещание

Если взять за основу передачи данных протокол TCP, то мы сразу же наткнёмся на ряд проблем. Например, в Windows XP Professional, Windows Vista и в Windows Server существует ограничение на количество одновременных полуоткрытых соединений, оно равно 10. Это ограничение невозможно обойти, не нарушив лицензионного соглашения. Поэтому максимально возможное количество компьютеров, которые могли бы подключиться к серверу равно 10. Кроме того протокол TCP избыточен, т.к. в нём как отмечалось выше существует контроль ошибок. Протокол TCP, осуществляет подключение «точка-точка», т.е. при подключении каждого клиента запрашивающего изображение рабочего стола, будет создан ещё один поток. Получается, что при подключении n компьютеров будет создано n потоков с одинаковым содержанием (изображение рабочего стола в реальном режиме времени, конечно же не будет отличаться для двух потоков) и нагрузка на сеть и процессор передающего компьютера естественно увеличивается в n раз. Вот почему нами был выбран протокол UDP, а если быть точнее протокол потокового вещания Multicast. В нём отсутствуют выше названные минусы, т.к. он и был создан для преодоления их. К примеру, в сеть будет транслироваться всегда один поток. И при подключении одного или сотни клиентов ситуация не изменится с точки зрения передающего компьютера – он всегда будет транслировать в сеть только один поток. Рассмотрим теперь потоковое мультимедиа вещание более подробно.

Потоковое мультимедиа (от. англ. stream media) – это мультимедиа объекты, которые непрерывно получаются пользователем от сервера потокового вещания. Это понятие применимо как к информации, распространяемой через телекоммуникации, так и к информации, которая изначально распространялась посредством потокового вещания (например, радио, телевидение) или непотоковой (например, книги, видеокассеты, аудио CD).

Разработка сетевых протоколов потокового вещания вызывает следующие проблемы:

Датаграмные протоколы, такие как User Datagram Protocol (UDP), отправляют поток медиаинформации как поток отдельных маленьких пакетов. Он прост и эффективен; в то же время, в спецификации протокола нет гарантии доставки данных получателю. Это очень сильно затрудняет поиск и исправление получаемых данных принимающим информацию приложением. При потере данных поток может быть отключен.

Протоколы RTSP, RTP и RTCP специально разрабатывались для передачи мультимедийной информации по сети. Последние два построены на основе UDP.

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

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

Рис. 1. Широковещательная передача данных

При широковещательной передаче одна копия данных передается всем клиентам сервера

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

Multicast позволяет передавать один поток информации группе клиентов по сети. Одной из проблем при реализации подобной схемы потокового вещания является корректная настройка маршрутизаторов для передачи широковещательных пакетов из одного сегмента сети в другой. Если организация, предоставляющая потоковое вещание, имеет контроль над сетью между сервером и клиентами (например, в образовательной, правительственной или корпоративной сети), то протоколы маршрутизации, такие как IGMP и PIM, могут быть использованы для доставки мультимедиа нескольким клиентам из различных сегментов LAN.

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

Протокол Multicast наиболее оптимальный с точки зрения нагрузки на сервер и сеть. [8]

Multicast (англ. групповая передача) – специальная форма широковещания, при которой сетевой пакет одновременно направляется определённому подмножеству адресатов – не одному (unicast), и не всем (broadcast).

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

Технология IP Multicast предоставляет ряд существенных преимуществ по сравнению с традиционным подходом. Например, добавление новых пользователей не влечет за собой необходимое увеличение пропускной способности сети. Значительно сокращается нагрузка на посылающий сервер, который больше не должен поддерживать множество двухсторонних соединений. Использование групповой адресации позволяет обеспечить доступ корпоративных пользователей к данным и сервисам, ранее недоступным, так как для их реализации с помощью обычной адресации потребовались бы значительные сетевые ресурсы.

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

В настоящее время IP Multicast является широко поддерживаемым сетевым стандартом. Все современное сетевое программное обеспечение и аппаратное оборудование поддерживает этот стандарт. Для использования групповой IP-адресации необходима ее поддержка локальной сетью. Что касается глобальной сети, в некоторых случаях допустимо использование «туннелирования» для преодоления участков, эту адресацию не поддерживающих.

Для реализации групповой адресации в локальной сети необходимы: поддержка групповой адресации стеком протокола TCP/IP; программная поддержка протокола IGMP для отправки запроса о присоединении к группе и получении группового трафика; поддержка групповой адресации сетевой картой; приложение, использующее групповую адресацию, например видеоконференция. Для расширения этой возможности на глобальную сеть дополнительно необходима поддержка всеми промежуточными маршрутизаторами групповой адресации и пропускание группового трафика используемыми firewall-ами. В локальной сети можно добиться еще большей оптимизации, используя коммутаторы с фильтрацией группового трафика, автоматически настраивающиеся на передачу трафика только получателям.

Технология IP Multicast использует адреса с 224.0.0.0 до 239.255.255.255. Поддерживается статическая и динамическая адресация. Примером статических адресов являются 224.0.0.1 – адрес группы, включающей в себя все узлы локальной сети, 224.0.0.2 – все маршрутизаторы локальной сети. Диапазон адресов с 224.0.0.0 по 224.0.0.255 зарезервирован для протоколов маршрутизации и других низкоуровневых протоколов поддержки групповой адресации. Остальные адреса динамически используются приложениями.

Для определения членства сетевых устройств в различных группах локальной сети маршрутизатор использует протокол IGMP. Один из маршрутизаторов подсети периодически опрашивает узлы подсети, чтобы узнать, какие группы используются приложениями узлов. На каждую группу генерируется только один ответ в подсети. Для того, чтобы стать членом новой группы, узел получателя инициирует запрос на маршрутизатор локальной сети. Сетевой интерфейс узла-получателя настраивается на прием пакетов с этим групповым адресом. Каждый узел самостоятельно отслеживает свои активные групповые адреса, а когда отпадает необходимость состоять в данной группе, прекращает посылать подтверждения на IGMP-запросы. Результаты IGMP-запросов используются протоколами групповой маршрутизации для передачи информации о членстве в группе на соседние маршрутизаторы и далее по сети.

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

Итак, плюсы режима multicast кратко описаны в начале параграфа, минусы же таковы:

1. Очень старое оборудование не поддерживает группы multicast (такое оборудование на сегодняшний день – большая редкость, но ). Однако на сегодняшний день оборудование даже за 400-500 рублей поддерживает данную технологию.

2. Если на программируемых свитчах сильно ограничены значения MTU и MRU, или даже сам протокол multicast, то необходимо будет связываться с ответственным лицом (системным администратором) для разрешения данной проблемы. Однако это не должно стать большой проблемой в пределах организации.

1.4. Зеркальный драйвер

Рассмотрим ещё одну из основных технологий применяемых в программе – это так называемый «Зеркальный драйвер», или mirror driver. Рассмотрим эту технологию с точки зрения В.А. Лаврова.

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

Идея состоит в том, что операционная система дублирует все графические операции на mirror видеодрайвер. Таким образом, приложение, использующее mirror драйвер, имеет возможность определять любые изменения экрана. Это позволяет минимизировать объем обрабатываемых данных, по сравнению с простым захватом всего изображения экрана.

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

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

Существует ряд улучшений вышеописанных способов, основанных на особенностях ОС Windows. Например, в программе WinVNC используются специальные хуки для определения областей экрана, которые подверглись изменению. Это позволяет существенно уменьшить количество данных, пересылаемых из памяти видеокарты в память компьютера. Но, к сожалению, данный способ не дает 100% гарантии на обнаружение всех изменений экрана.

Для детектирования изменений экрана можно воспользоваться специальным свойством всех ОС Windows, начиная с версии 2000, которое дублирует все вызовы графической подсистемы на mirror видеодрайвер.

На рисунке 2 показаны все необходимые компоненты, требуемые для отображения информации под управлением Windows 2000 и выше.

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

Рис. 2. Структура Видеодрайвера

Эта схема работает следующим образом. Приложение, работающее в User Mode, пытается вывести на экран некоторую информацию. Все графические функции в User Mode выполняются библиотекой GDI32.DLL подсистемы Win32. Библиотека GDI32.DLL не может работать с видеодрайвером напрямую, так как она (как и приложение) работает в третьем кольце защиты. Поэтому для обработки запроса происходит переход в нулевое кольцо, в котором управление передается в графическую библиотеку GDI в Kernel Mode.

Библиотека Kernel Mode GDI имеет информацию о том, какие из всего набора DDI (Device Driver Interface) функций поддерживаются драйвером дисплея на аппаратном уровне. Если затребованная функция поддерживается, то библиотека GDI вызывает соответствующую DDI функцию в драйвере дисплея. Если требуемая функция не поддерживается, то тогда вызывается программная эмуляция функции. Библиотека Kernel Mode GDI может программно выполнить любую DDI-функцию, она имеет весь необходимый для этого код.

Если драйвер дисплея поддерживает DDI-функцию не полностью, то он может вызывать любую из ENG функций, входящих в состав Kernel Mode GDI для программной эмуляции той ее части, которая не реализована на аппаратном уровне.

Например, приложение вызывает WIN API функцию LineTo. Управление передается в библиотеку GDI32, которая так же, как и приложение, работает в User Mode.

Библиотека User Mode GDI использует программное прерывание INT или команду SYSENTER для передачи управления в библиотеку Kernel Mode GDI. Kernel Mode GDI просматривает таблицу поддерживаемых драйвером дисплея DDI-функций. Если в этой таблице имеется точка входа для DDI-функции DrvLineTo, то библиотека GDI вызывает эту функцию в драйвере дисплея. Если драйвер дисплея по каким-то причинам не может выполнить эту функцию, то он может воспользоваться ее программной эмуляцией, имеющейся в библиотеке Kernel Mode GDI – EngLineTo. После того, как линия нарисована, управление передается обратно в библиотеку Kernel Mode GDI. Эта библиотека осуществляет обратный переход в третье кольцо защиты и передает управление User Mode GDI, которая возвращает управление приложению, вызывавшему API-функцию LineTo.

Примерно таков принцип «отрисовки» изображения операционной системой по запросу приложения.

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

Mirror драйвер может указать любой регион отсечения на виртуальном рабочем столе, включая даже такой, который разделяется между физическими устройствами вывода. GDI посылает для mirror драйвера все графические операции, которые пересекаются с регионом отсечения. Mirror драйвер может установить регион отсечения целиком покрывающий только одно физическое устройство, что гарантируют высокую эффективность отображения всех графический операций этого устройства на mirror драйвер.[11]

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

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

2. Возможность «захвата» не всего экрана, а определённой его части.

3. Драйвер берёт на себя определение координат изменившейся части изображения на экране.

Минусы:

1. Требует установки на компьютере, т.е. необходимы права администратора, для установки и небольшой настройки.

2. Т.к. это драйвер необходима аккуратность при его написании иначе возможны сбои операционной системы(синие экраны и прочее).

3. Отлавливает только изменения произошедшие в подсистеме GDI, в подсистемах Opengl и Directx драйвер без дополнительного, довольно сложного программирования изменений не отлавливает.

Глава 2. Обоснование и создание программы 2.1. Обоснование проблемы исследования и способа её разрешения

Сейчас во многих компьютерных классах используется проектор – с помощью него можно всем обучающимся в классе показывать презентации или обращать внимание с помощью курсора на те или иные места в какой-либо программе, которая изучается на уроке. К примеру: показать курсором, где располагается в программе Microsoft Word меню «Файл» и где располагается элемент этого меню «Сохранить». Действительно, с помощью проектора – это наглядно можно показать всем обучающимся в компьютерном классе, после чего они без труда могут повторить эти действия на компьютерах. И вроде бы никаких минусов у схемы нет, однако на практике компьютерные столы располагаются в классе «буквой Г», т.е. так как показано на рисунке 3.

 

Компьютер учителя

 

Рис.3. Схема компьютерного класса

И теперь очень хорошо видно проблему: обучающиеся, сидящие за крайними двумя компьютерами слева будут сидеть спиной к экрану – и им придётся постоянно поворачивать голову на 180 градусов, чтобы увидеть, что происходит на экране, что довольно неудобно. Если же демонстрируется презентация или учитель курсором показывает, где и какую кнопку надо нажать, а это и вовсе затрудняет понимание. Добавьте к этому ещё и то, что слабо видящих детей сейчас не так уж и мало и приплюсуйте то, что они в 90% случаев не будут просить учителя показать то, что не поняли, потому что плохо видно – и получается, что крайние 2 компьютера являются «ссыльной Камчаткой». Да и с ближайших к ним компьютеров при плохом качестве проектора видно изображение не очень хорошо.

Решением подобных проблем была бы программа, которая передавала снимки экрана с учительского компьютера на компьютеры учеников. Конечно первое, что было сделано – это поиск в Интернете программы, которая могла реализовать подобное без больших нагрузок на компьютеры и сеть. Вообще программ, которые могут передавать скриншоты рабочего стола в «режиме реального времени» (постоянно) достаточно много, это UltraVnc, TightVNC, Remote Administrator, DameWare Utilities. Однако все они реализуют передачу скриншотов только как точка-точка (т.е. в процессе будут участвовать только 2 компьютера, но нашей целью является передача скриншотов с одного компьютера на многие). Поискав в Интернете довольно долго, мы нашли несколько программ, но они либо сильно нагружали компьютер, с которого происходит трансляция скриншотов в сеть, либо сильно нагружали сеть, либо являлись «платными», т.е. за их использование необходимо заплатить, либо имели открытые настройки, которые могли быть случайно изменены обучающимся, нарушив работоспособность программы. Таким образом, было принято решение написать программу, которая была бы лишена описанных выше недостатков.

С помощью представленной программы экран рабочего стола учительского компьютера «копируется» на все компьютеры обучающихся, и они могут не поворачиваться к презентации, а наблюдать за действиями учителя прямо на своих компьютерах.

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

Схема работы программы для сервера и двух компьютеров клиентов представлена на рисунке 4.

Рис.4. Упрощенная схема работы программы

Сейчас программа состоит из 2-ух «модулей». Сервер – это модуль, который представляет собой драйвер и программу для передачи скриншотов в сеть. Клиент – это модуль, который представляет собой программу, для принятия и отображения скриншотов, которые сервер отправляет в сеть.

Если рассматривать случай из примера, приведённого вначале статьи, то сервер устанавливается на компьютер учителя, а клиент на компьютеры учеников. Все настройки клиента располагаются в cfgclient.cfg файле. Это во много раз упрощает работу с клиентом, т.к. можно например, выставить разрешение только для чтения для этого файла, благодаря чему обучающиеся не смогут поменять настройки клиента и нарушить его работоспособность. Или работать с клиентом перенося его в папке на флешке. У пользователя, работающего с клиентом, могут быть любые права (права администратора не нужны).

Большинство настроек сервера располагаются в cfgserv.cfg файле, который находится в папке с сервером, к сожалению, все настройки не могут быть расположены в этом файле, т.к. в программе используется зеркальный драйвер. Для установки зеркального драйвера нужны права администратора. Для использования сервера также необходимы права администратора, однако имея права администратора можно просто разрешить для редактирования одну ветку реестра и одну папку для записи всех пользователей и в дальнейшем права администратора для работы сервера не нужны.

2.2. Основные этапы программирования

В целом программирование состояло из нескольких основных моментов:

• Программирование драйвера.

• Программирование клиент-серверного взаимодействия.

• Программирование удобного интерфейса и защиты клиентской части программы от вмешательства возможных небрежных действий пользователя.

В целом все три шага в той или иной степени были выполнены.

Программирование клиентской и серверной части выполнялось с помощью таких разработок, как: Lazarus, synapse.

Lazarus был выбран потому что это на сегодняшней день это наиболее кроссплатформенная (переносимая между операционными системами) среда программирования на языке Pascal.

Synapse – это разработка облегчающая сетевое программирование на языке Pascal и также поддерживающая операционные системы Windows и Linux.

Основные этапы программирования клиент-серверного взаимодействия

Сервер:

…

//Чтение настроек из конфигурационного файла

AssignFile(f,ExtractFilePath(Application.ExeName)+'cfgserv.cfg');

…

//Запуск на порту 22401 multicast рассылки

sock.bind('0.0.0.0','0');

sock.connect(ip,'22401');

…

//Запуск драйвера

mydriver:=VIDEODRIVER.create;

mydriver.VIDEODRIVER_start(0, 0, mas[1], mas[2], (mas[0]+1));

…

В дальнейшем в сервере организован цикл отправки экрана компьютера в созданную multicast группу.

Клиент:

…

//Чтение настроек из конфигурационного файла

AssignFile(F,ExtractFilePath(Application.ExeName)+'cfgclient.cfg');

…

//Подсоединение к мультикаст рассылки указанной в настройках на порт 22401

Sock.Bind('0.0.0.0','22401');

Sock.AddMulticast(ip);

…

В дальнейшем в клиенте организован цикл принятия и отображение изображения из multicast группы.

Исходный код зеркального драйвера в приложениях.

Заключение

В нашей программе, задействованы следующие технологии:

1. multicast (сетевое вещание);

2. mirror-драйвер (драйвер, предлагаемый компанией Microsoft для снижения нагрузки на компьютер, регистрирует изменения рабочего стола);

3. Quicklz (библиотека сжатия, благодаря ей снижается нагрузка на сеть).

В качестве сред программирования были использованы:

1. Lazarus (бесплатный аналог Delphi);

2. Windows Driver Kit (распространяемый Microsoft «пакет», в котором содержатся примеры драйверов и утилиты для их компиляции).

Все перечисленные технологии являются абсолютно бесплатными.

Характеристики компьютеров: одноядерный Celeron 1.7 Gz, 256 ОЗУ.

Характеристики среды тестирования – сеть 100 Мбит; 2,5 кадров в секунду.

Показатели сервера:

• нагрузка по сети 12% (в «холостом» режиме, когда за компьютером никто не работает, в противном случае – 3-4%);

• нагрузка процессора 0-1%.

Показатели клиентов:

• нагрузка по сети равна нагрузке сервера;

• нагрузка процессора: максимальная нагрузка 33%, минимальная 6%, большую часть времени в среднем 15%.

Показатели могут варьироваться, если увеличивать или уменьшать сжатие.

Таким образом, преимуществом предложенной программы является:

• бесплатность;

• минимум настроек;

• небольшая нагрузка на сеть и процессор компьютеров участвующих в процессе работы программы.

Кроме того нами разработан mirror драйвер и для 64 разрядных операционных систем: Windows 7, Windows Vista, Windows Server, однако из-за политики Microsoft «О обязательной подписи драйверов для 64 разрядных систем» использовать его без дополнительных ухищрений не получится.

На основании выше изложенного мы считаем цель работы выполненной, а именно – разработать программу, реализующую передачу скриншотов по сети от одного компьютера многим и отвечающую следующим требованиям:

• применение технологий multicast, quicklz (zlib), в качестве оптимизации нагрузки на сеть;

• применение технологии mirror driver, в качестве оптимизации нагрузки на процессор компьютера осуществляющего передачу изображения.

При достижении данной цели были выполнены все задачи поставленные в начале исследования.

Кроме того, данная программа используется в учебном процессе в двух компьютерных кабинета факультета среднего профессионального образования ТГСПА, в одном из этих кабинетов совсем не используется проектор, а вместо него используется представленная программа.

Также программа была предложена преподавателю информатики в МАОУ СОШ № 15 г. Тобольска, где и задействована на некоторых уроках, проводящихся в компьютерном кабинете.

В обоих случаях программа была внедрена примерно с марта 2011 года и с успехом используется по сегодняшний день.

Литература

1. Khanvilkar S. et al. Multimedia Networks and Communication // Electrical Engineering Handbook / edited by W.K. Chen. – [S. l.]: Academic Press, 2004. – P. 401–425.

2. Leon-Garcia A. and Widjaja I. Communication Networks: Fundamental Concepts and Key Architectures. – [S. l.]: McGraw-Hill, 2000. – 932 p.

3. Perkins C. RTP: Audio and Video for the Internet. – [S. l.]: Addison Wesley, 2003. – 432 p.

4. Андерсен, Бент Б. Мультимедиа в образовании / Бент Б. Андерсен, Катя ван ден Бринк – М. : Дрофа, 2007. – 224 с.

5. Бердников К. В., Тикунов В. С. Данные, информация, знания в картогра- фии и геоинформатике / / Изв. Русского геогр. общ-ва. — 1992. — Т. 124. — Вып. 4 . - С . 369-374.

6. Берлянт А.М. Виртуальные геоизображения. — М.: Научный мир, 2001.- 56 с.

7. Википедиа. Multicast: [Электронный ресурс]. URL: http://ru.wikipedia.org/wiki/Multicast. (Дата обращения: 01.06.2012).

8. Википедиа. Потоковое мультимедиа: [Электронный ресурс]. URL: http://ru.wikipedia.org/wiki/Потоковое_мультимедиа. (Дата обращения: 01.06.2012).

9. Капралов Е. Г., Кошкарев А. В., Тикунов В. С. и др. Геоинформатика. В 2-х кн. Учебн. для вузов. Под ред. В.С.Тикунова. 2-е изд., перер. и доп. М.: Академия, 2008. Кн. 1, 384 с., с цв. ил.; Кн. 2, 384 с.

10. Катунин, Г. П. Основы мультимедиа. Звук и видео / Г. П. Катунин : монография. – Новосибирск, СибГУТИ, 2006. – 389 с.

11. Лавров В. А. Использование Mirror драйвера для записи всех изменений экрана компьютера в файл видеоформата FBR // Вестник ТГУ. Серия «Математика. Кибернетика. Информатика». Томск: Изд-во Том. ун-та. Декабрь 2004. № 284. - С. 190-193.

12. Лавров В. А. Написание своего Mirror видео драйвера // Вестник ТГУ. Серия «Математика. Кибернетика. Информатика». Томск: Изд-во Том. ун-та. Декабрь 2004. № 284. - С. 194 – 197

13. Чепмен, Найджел. Цифровые технологии мультимедиа / Найджел Чепмен, Дженни Чепмен. 2-е изд.– М. : Диалектика, 2005. – 624 стр., с ил.

14. Чердынцев Е.С. Ч-45 Мультимедийные сети: учебное пособие / Е.С. Чердынцев; Томский политехнический университет. – Томск: Изд-во Томского политехнического университета, 2012. – 97 с.

Код для цитирования: Скопировать