Содержание к диссертации
Введение
ГЛАВА 1. Существующие методы 13
1.1. Методы передачи данных видеонаблюдения по компьютерным сетям 14
1.2. Методы тестирования ЛВС Ethernet 18
1.3. Методы сбора технологических данных в промышленных сетях 24
1.4. Цели и задачи диссертационной работы 29
ГЛАВА 2. Имитационное моделирование и тестирование сети ethernet 34
2.1. Введение 34
2.2. Сервер динамического слежения за работоспособностью сети 36
2.3. Моделирование работы сегмента сети Ethernet 49
2.3.1. Имитационная модель 49
2.3.2. Время доступа к моноканалу 52
2.3.3. Влияние длины пакета на передачу данных 56
2.3.4. Имитация работы реально существующих сегментов 60
2.3.5. Использование результатов тестирующей программы для выбора имитационной модели 62
2.3.6. Тестирование сегмента сети Ethernet 64
2.4. Моделирование Ethernet-коммутатора 64
2.5. Результаты 67
ГЛАВА 3. Модели и методы сбора технологических данных в промышленных сетях типа «ведущий- ведомый» б9
3.1. Введение 69
3.2. Имитационное моделирование передачи данных в промышленных сетях на основе метода доступа к шине типа "ведущий-ведомый" 72
3.2.1. Основные объекты имитационной модели 73
3.2.2. Набор команд 78
3.2.3. Моделирование передачи данных 78
3.2.4. Система моделирования 82
3.2.5. Результаты моделирования 88
3.3. Промышленная сеть с неравномерным распределением прав ведущих (LabiNet) 91
3.3.1. Сравнение централизованных и децентрализованных методов разграничения доступа к среде 91
3.3.2. Описание протокола LabiNet 96
3.3.2.1. Первый уровень: «мастер - ведомый» 96
3.3.2.2. Второй уровень: «мастер-арбитр - мастер» 98
3.3.2.3. Третий уровень: «мастер-маршрутизатор - мастер-арбитр» 102
3.3.3. Система команд 104
3.4. Результаты 106
ГЛАВА 4. Методы передачи данных видеонаблюдения и технологического контроля в распределенных цифровых системах 107
4.1. Введение 107
4.2. Выбор протокола передачи данных 112
4.3. Регулирование скорости передачи видео данных 116
4.3.1. Регулирование по принципу "запрос-ответ" 117
4.3.2. Ограничение скорости передачи в зависимости от скорости чтения 119
4.3.3. Регулирование клиентом интервала между кадрами, отправляемыми сервером 121
4.4. Программно-аппаратный комплекс видеонаблюдения и технологического контроля "Pandora" 124
4.5. Передача видео и аудио данных 129
4.6. Проведение эксперимента по передаче данных видеонаблюдения 13$
4.7 Результаты 141
Заключение 142
Библиографический список 144
- Методы передачи данных видеонаблюдения по компьютерным сетям
- Сервер динамического слежения за работоспособностью сети
- Основные объекты имитационной модели
- Ограничение скорости передачи в зависимости от скорости чтения
Введение к работе
Актуальность темы
Развитие цифровых сетей передачи данных открывает новые возможности в построении систем удаленного мониторинга. Пропускная способность каналов связи в настоящее время позволяет вести видео контроль над удаленными объектами в реальном масштабе времени, поэтому одним из основных требований, предъявляемых к современным цифровым системам видеонаблюдения, является возможность передачи изображений с видеокамер по компьютерной сети. Использование этой возможности дает значительный экономический эффект при организации видеонаблюдения на территориально распределенных объектах, а также в многопользовательских системах, когда изображение с одной камеры необходимо просматривать со значительно удаленных друг от друга рабочих мест. Основные трудности заключаются в способах передачи видеосигналов по цифровым сетям вследствие большого объема передаваемых данных, необходимого для видеонаблюдения в реальном масштабе времени. Кроме передачи видеопотоков по сети значительную роль играют процессы компрессии/декомпрессии видеоизображений. Поэтому, если в глобальных сетях (Интернет) решающую роль при передаче видеоданных играет пропускная способность канала, то в ЛВС зачастую слабым звеном оказываются ограниченные вычислительные мощности отдельных компьютеров. При этом возникает необходимость в алгоритмах регулирования процессов передачи данных с целью обеспечения экономного и эффективного использования каналов связи в задачах видеонаблюдения.
При организации видеонаблюдения на объектах с целью обеспечения безопасности или контроля над технологическими процессами возникает задача сопоставления данных видеонаблюдения с показаниями различных датчиков и измерительных приборов: электронных термометров, манометров, считывателей кодов электронных пропусков, датчиков движения, открывания
дверей, срабатывания сигнализации и т.д. (далее - технологические данные). Обычно технологические параметры получаются с помощью микроконтроллеров, которые передают их по промышленной сети в центр сбора и обработки данных. При этом большое внимание уделяется надежности системы и задаче минимизации времени реакции системы на какое-либо событие, поэтому важен способ передачи данных и распределения канала между множеством передающих устройств. Сведение задач видеонаблюдения и технологического контроля в рамки одной системы позволяет синхронизовать видео и технологические данные во времени, помогает удаленному пользователю быстрее воссоздать точную картину происходящего на объекте.
Объединение задач видеонаблюдения и технологического контроля приводит к необходимости использования общих каналов связи и протоколов передачи данных. Задачи технологического контроля, в отличие от задач видеонаблюдения, налагают повышенные требования к надежности канала связи и гарантированности доставки данных. Особое внимание следует уделить способу отображения данных из локальных промышленных сетей в цифровые сети глобального масштаба.
Постановка задачи
В работе рассматривается передача данных в информационной системе, основными составляющими которой являются:
видеосерверы, захватывающие изображение с подключенных к ним камер и осуществляющие отображение данных из локальных промышленных сетей в цифровые сети глобального масштаба;
видеоклиенты, отображающие видеоизображения и данные технологического контроля, полученные от видеосерверов;
контроллеры, получающие путем опроса своих датчиков технологические данные и передающие их видеосерверам;
промышленная сеть, объединяющая контроллеры между собой и с видеосервером;
компьютерная сеть, объединяющая видеосерверы и видеоклиенты, поддерживающая передачу данных по протоколам семейства IP.
В работе не рассматриваются способы получения данных от датчиков, сами датчики и содержимое программ контроллеров. Считается, что у контроллеров существует постоянная потребность в передаче данных. Не рассматриваются типы видеокамер, способ оцифровки телевизионного сигнала и алгоритмы компрессии видеоданных. Под видеоизображением подразумевается последовательность цифровых растровых изображений (видеокадров).
Цель работы заключается в разработке методов передачи информации, обеспечивающих эффективное использование каналов передачи данных при выполнении задач видеонаблюдения и сбора технологических данных в распределенных многопользовательских системах. При этом ставились следующие задачи: построение имитационной модели сети Ethernet для исследования поведения ЛВС при интенсивной передаче данных, разработка инструмента для идентификации модели ЛВС; имитационное моделирование протоколов передачи данных в промышленных сетях и разработка механизмов разграничения доступа к передающей среде, обеспечивающих наиболее быстрое получение данных по запросу извне; разработка алгоритмов передачи видео и технологической информации, обеспечивающих регулируемое использование каналов передачи данных.
Методы исследования
Решение рассматриваемых в диссертационной работе задач базируется на применении методов математического моделирования и программирования.
8 Научная новизна
Разработаны алгоритмы передачи данных видеонаблюдения в реальном масштабе времени по протоколу TCP/IP в распределенных многопользовательских системах.
Разработаны алгоритмы динамического контроля над
работоспособностью сетевого оборудования ЛВС большого размера.
Путем компьютерного имитационного моделирования получены зависимости числа коллизий и потерянных пакетов от длины передаваемых пакетов и числа передающих устройств при максимальной нагрузке на сегмент сети Ethernet.
Разработаны методы построения имитационных моделей реальных сегментов сети Ethernet. Предлагается метод тестирования сети Ethernet, основанный на сравнении результатов имитационного моделирования и результатов работы реальной ЛВС.
Разработаны универсальные правила моделирования передачи данных в промышленных сетях типа «ведущий-ведомый».
Предложен новый протокол передачи данных в промышленных сетях, объединяющий достоинства централизованного и децентрализованного методов разграничения доступа устройств к каналу передачи данных.
Практическая ценность
Использование возможности передачи изображений с видеокамер по компьютерной сети дает значительный экономический эффект при организации видеонаблюдения на территориально распределенных объектах, а также в многопользовательских системах, когда изображение с одной камеры необходимо просматривать со значительно удаленных друг от друга рабочих мест. В работе предлагаются принципы программной организации передачи видеопотоков реального времени по распределенной сети, состоящей из множества видеосерверов и компьютеров-клиентов, с использованием
9 протокола TCP/IP, обеспечивающие регулирование скорости передачи данных
в зависимости от пропускной способности сети и вычислительных ресурсов
серверов и клиентов. Разработанные методы позволяют экономно и
предсказуемо использовать ресурсы компьютерной сети, на которую
возлагаются задачи видеонаблюдения.
Разработанный инструмент идентификации модели ЛВС (сервер динамического слежения за работоспособностью сети) может использоваться сетевыми администраторами компьютерных сетей большого размера для автоматизации сбора информации о структуре сети и параметрах ее работы. Программа контролирует работу устройств, подключенных к локальной сети (определяет время их включения и отключения), а также появление новых сетевых устройств по различным протоколам (TCP/IP и NetBIOS), что делает практически невозможной скрытную работу в сети; определяет случаи несогласованного использования IP-адресов, вычисляет устройства с настройками, мешающими правильной работе сети. Предложенный метод тестирования, основанный на сравнении результатов имитационного моделирования и результатов работы реальной ЛВС, имеет большое практическое значение при определении качества ЛВС. Разработанные методы могут также использоваться для предсказания результатов изменений, проводимых в сети.
При разработке промышленной сети важно заранее оценить, отвечает ли выбранное решение различным требованиям, налагаемым на сеть областью ее применения. Предложенная система имитационного моделирования передачи данных в промышленных сетях имеет практическое применение для определения соответствия проекта промышленной сети возлагаемым на него задачам. Разработанные методы позволяют оптимально выбирать не только параметры конкретного протокольного решения, но и сам протокол передачи данных.
Предложенный протокол передачи данных в промышленных сетях оптимизирует процесс сбора данных из сегмента промышленной сети в один
10 «узел», выступающий в роли «центра управления» или маршрутизатора в
соседние сегменты, интранет- или интернет-пространство. Наиболее выгодным
нам представляется использование данного протокола в системах со многими
узлами управления, отвечающими за работу определенной части устройств
(микроконтроллеры, контролирующие процесс в соответствии с алгоритмом,
или пульты управления операторов), и одним или несколькими «центрами
управления» (в роли которых выступают компьютеры), ответственными за
работу всей системы в целом. Такая комбинация позволяет, с одной стороны,
широко использовать относительно дешевые вычислительные ресурсы
компьютера, а, с другой стороны, обеспечивает достаточный уровень
отказоустойчивости (выход из строя «центра управления» не приведет к
прекращению работы всей сети).
Объединение системы сбора и обработки технологических данных и
системы видеонаблюдения позволяет комплексно решать задачи видео и
технологического мониторинга в реальном масштабе времени. Изначально
заложенные в систему механизмы передачи данных по цифровым сетям делают
ее легко масштабируемой, позволяют создавать территориально
распределенные, многопользовательские системы контроля.
Апробация работы
Сервер динамического слежения за работоспособностью сети используется сетевыми администраторами Пермского университета для контроля над конфигурацией ЛВС. На программу получено свидетельство об официальной регистрации программы для ЭВМ №2001610181.
Работы по имитационному моделированию сегмента сети Ethernet и промышленных сетей представлены на третьей и четвертой всероссийской научной internet-конференции «Компьютерное и математическое моделирование в естественных и технических науках» (г. Тамбов, 2001,2002гг.)
Методы передачи видеоинформации, сбора и передачи технологических данных реализованы в цифровой системе видео и технологического мониторинга "PANDORA" ЗАО НПО «Лаби».
По протоколу "LabiNet" организована связь между контроллерами сбора технологических данных и видеосерверами системы "PANDORA" ЗАО НПО «Лаби».
Система видеонаблюдения "Pandora" оценена дипломом II степени в конкурсе «Системы охранного телевидения и наблюдения», проводившемся на международной выставке «Охрана и безопасность» в Санкт-Петербурге, 2003 г.
На защиту выносятся следующие результаты.
1. Алгоритмы и программа динамического контроля над
работоспособностью сетевого оборудования ЛВС большого размера.
Данные имитационного компьютерного моделирования интенсивной передачи данных в сегменте сети Ethernet.
Методы построения имитационных моделей реальных сегментов сети Ethernet. Метод тестирования сети Ethernet, основанный на сравнении результатов имитационного моделирования и результатов работы реальной ЛВС.
Методы и программа имитационного моделирования передачи данных в промышленных сетях, функционирующих на основе метода доступа «ведущий-ведомый» и метода передачи маркера.
Новый протокол передачи данных в промышленных сетях, оптимизированный под задачи быстрого получения технологических параметров по запросу из центра контроля.
Алгоритмы передачи данных видеонаблюдения в реальном времени по протоколу TCP/IP в распределенных многопользовательских системах.
Метод регулирования клиентом скорости передачи видеокадров от сервера клиенту в зависимости от пропускной способности сети, скорости
12 декомпрессии видеокадров клиентом, нагрузки на процессор компьютера-клиента.
8. Программно-аппаратный комплекс «Распределенная
многопользовательская цифровая система видеонаблюдения и технологического контроля Pandora».
Структура диссертации
Диссертация состоит из четырех глав, заключения, библиографического списка и трех приложений.
В первой главе приведен обзор существующих методов передачи данных видеонаблюдения и сбора технологических данных, проведено сравнение методов тестирования сети Ethernet, раскрывается содержание поставленных задач.
В первой части главы 2 рассматривается программа «Сервер динамического слежения за работоспособностью сети», во второй части описывается имитационная модель сегмента сети Ethernet, предлагаются методы построения моделей реальных сегментов, приводится пример тестирования реального сегмента сети.
Третья глава посвящена передаче данных в промышленных сетях. Рассматриваются способы моделирования промышленных сетей, представлена разработанная система моделирования передачи данных в промышленных сетях типа «ведущий-ведомый». На основе проведенных исследований предлагается новый протокол передачи данных.
В четвертой главе рассматриваются методы передачи данных видеонаблюдения в реальном масштабе времени, предлагаются алгоритмы регулирования скорости передачи видеоданных и способы объединения задач видеонаблюдения и технологического контроля. Описана реализация предложенных алгоритмов в программно-аппаратном комплексе видеонаблюдения и технологического контроля "Pandora".
Методы передачи данных видеонаблюдения по компьютерным сетям
Стандартные методы передачи видеопотоков по компьютерным сетям основываются на использовании протокола UDP [4]. Протокол UDP не гарантирует качество доставки и правильность порядка передачи данных, однако требует меньшей пропускной способности канала и позволяет организовывать одновременную передачу данных множеству клиентов (multicast). Правильность порядка передачи данных реализуется на уровне приложения за счет буферизации входящего трафика и его пересортировки. Потерянные пакеты обычно не пересылаются, вместо этого используются алгоритмы восстановления потерянной информации за счет избыточного кодирования [39] и добавления в кодированное изображение маркеров синхронизации [45]. В [39] показано, что потери UDP-пакетов происходят не только в каналах связи, но и в буферах входных данных компьютеров-клиентов вследствие нехватки вычислительных ресурсов для обработки всех входящих данных. Для уменьшения потерь UDP-пакетов предлагаются различные механизмы регулирования скорости передачи видеоданных и качества компрессии видеоизображений. В зависимости от возможностей канала связи и компьютеров-клиентов меняются параметры работы компрессора видеосервера [42] или, при маршрутизации видеопотока из скоростного магистрального канала в «медленный» сегмент сети, состоящий из компьютеров с низкой вычислительной способностью, ухудшается качество исходного компрессированного видеопотока [35].
Интенсивная неконтролируемая передача данных по UDP в канале с недостаточной пропускной способностью приводит к агрессивному захвату всего канала, что может нарушить передачу данных по TCP протоколу (осуществляемую другими приложениями по общему каналу связи). Поэтому при передаче данных по UDP необходимы механизмы, обеспечивающие «дружественность» протоколу TCP [42]. Условие равномерного распределения канала между различными приложениями выполняется автоматически, если вести передачу видеоданных по протоколу TCP, в котором изначально заложены механизмы адаптации к пропускной способности канала, регулирования скорости передачи в зависимости от числа теряемых пакетов, подавления перегрузок канала. Однако использование протокола TCP требует дополнительных механизмов для выполнения требований, предъявляемых к системам видеонаблюдения реального времени [31]. Дело в том, что протокол TCP обеспечивает гарантированность доставки, и если весь объем видеоданных не может быть передан через канал связи или обработан клиентом, на сервере возникают очереди передаваемых данных, появление которых ведет к росту задержки передачи видеоизображений, что недопустимо. В [44] предлагается частично изменить протокол TCP на стороне клиента для организации задержки отправки подтверждений о приеме данных. Это позволяет избежать возникновения состояния перегрузки канала, для выхода из которого протоколу TCP требуется значительное время. Для того чтобы не допустить роста очереди передаваемых данных в [40] предлагается отбрасывать (не ставить в очередь передачи) часть видеокадров, количество отбрасываемых кадров определяется на стороне сервера по данным, получаемым от механизма подавления перегрузок протокола TCP. В рассмотренных подходах не учитывается возникновение задержки видеоинформации в приемных буферах клиента. При низких вычислительных ресурсах процесс декомпрессии видеопотока занимает значительную долю процессорного времени, клиент не успевает декомпрессировать все получаемые данные и поэтому читает из буфера приема медленнее, чем туда поступают данные. Это приводит к периодическим приостановкам передачи данных сервером, низкой скорости и «рывкам» выводимого на экране клиента видеоизображения. Проблема может быть «решена» разделением задач получения данных из сети и их декомпрессии: клиент получает все данные, но только часть из них декомпрессирует. В этом случае канал связи будет частично занят бесполезной передачей данных, что не экономно по отношению к сетевым ресурсам. Возникает задача в разработке таких алгоритмов регулирования передачи видеоданных, которые учитывали бы не только возможности канала связи, но и ресурсы компьютеров-клиентов [19]. Следует отметить, что выбор протокола TCP в качестве основного в интегрированной системе видеонаблюдения и технологического контроля автоматически выполняет требование гарантированности доставки технологических данных. Задачу передачи технологических данных можно обобщить до передачи любых данных, потеря даже части которых недопустима. Для примера приведем проблему, подробно описанную в [41]: при организации системы дистанционного обучения, в которой в реальном масштабе времени студентам передается видеоизображение происходящего в удаленной аудитории, выяснилось, что вследствие потери качества изображения (при компрессии/декомпрессии) невозможно использование большинства иллюстративного материала. Решение проблемы заключается в передаче файлов иллюстраций отдельно от видеопотоков. Очевидно, что потери данных при передаче этих файлов недопустимы. Основными критериями оценки качества распределенной системы цифрового видеонаблюдения являются: Величина временной задержки т между каким-либо событием, произошедшим перед видеокамерой, и моментом его отображения на экране клиента; Количество кадров/с п, отображаемых на экране клиента. Оба параметра тип зависят от пропускной способности сети и вычислительных ресурсов сервера и клиента. Следует подчеркнуть, что кроме передачи видеопотоков по сети, значительную роль играют процессы компрессии/декомпрессии видео. Поэтому, если в глобальных сетях (Интернет) решающую роль играет пропускная способность канала, то в ЛВС зачастую слабым звеном оказываются ограниченные вычислительные мощности отдельных компьютеров. При этом возможна ситуация, когда по ЛВС от сервера до клиента будет передаваться больше данных, чем клиент в состоянии обработать, что нерационально с точки зрения экономного использования сетевых ресурсов. В то же время, чрезмерное ограничение скорости передачи данных может сильно ухудшить качественные характеристики системы видеонаблюдения.
Сервер динамического слежения за работоспособностью сети
Для получения как можно большего объема информации об устройствах контроль над их работой необходимо вести по нескольким протоколам одновременно. Было решено использовать два наиболее распространенных в локальных сетях протокола - ТСРЯР и NetBIOS.
Чтобы обнаружить устройство, работающее по протоколу ТСРЯР, а также проконтролировать его работоспособность, проще всего использовать ICMP протокол. Алгоритм стандартной команды ping требует от 1 мс до 2 с на проверку одного ІР-адреса. Время порядка 2 с необходимо в случае, когда устройство не отвечает, что дает возможность убедиться, что ответный пакет действительно не прошел. При проверке сетей большого размера суммарное время обмена пакетами достигает значительных величин. К примеру, при проверке сети ПГУ необходимо за каждый проход программы проверять порядка двух тысяч IP-адресов, причем примерно 70% этих адресов не используется. Таким образом, на проверку 2000 IP-адресов с учетом того, что рабочими являются только 30%, мы получаем время порядка 2000 0.7 2=2800 с = 46 мин. При такой скорости проверки ее результаты теряют свою актуальность, так как для подключения устройства к сети (и последующего отключения) необходимо гораздо меньшее время. Ограничение списка проверяемых устройств может уменьшить время проверки, но увеличит вероятность того, что какое-то устройство появится по неизвестному нам ІР-адресу. Поэтому был разработан новый алгоритм проверки сетевых устройств по ІСМР-запросам, который заключается в том, что за один раз посылается группа из 254 пакетов, каждый из которых имеет собственный ІР-адрес назначения. В результате, всего за 2 с проверяется вместо одного сетевого устройства вся подсеть, то есть 254 устройства. Общее время, необходимое на проверку всех IP-адресов, принадлежащих ПГУ, снижается таким образом.
Активный обмен пакетами с сетевыми устройствами неизбежно приводит к увеличению сетевого трафика. В данном проекте ICMP-пакеты имеют размер 32 байта. Режим проверки таков, что раз в 10 мин за время около 50 с проверяется около 2000 устройств. Можно грубо оценить нагрузку как 32 2000=64000 байт/мин, что составляет 8.5 кбит/с. Стандартная ЛВС имеет пропускную способность 10-100 Мбит/с, таким образом, увеличение нагрузки на сеть незначительно и составляет доли процента.
Контролируя работу сети только по ІСМР протоколу, мы упускаем из виду те компьютеры, на которых протокол TCP/IP не установлен. На практике это происходит, когда протокол не установлен, либо же специально удален для обеспечения скрытной работы пользователя в сети. В обоих случаях пользователь может вести работу по NetBIOS протоколу. Необходимость выявлять компьютеры, работающие по этому протоколу, приводит к некоторым проблемам. Дело в том, что в ОС UNIX есть возможность работы по NetBIOS поверх ТСРЯР, но отсутствует поддержка протокола NetBEUI. С помощью NetBIOS поверх TCP/IP мы опять же теряем из виду компьютеры, где TCP/IP не установлен, кроме того, активное определение сетевого имени рабочей станции требует довольно много времени и повышает сетевой трафик, так как при этом используются пакеты широковещательной рассылки. Исходя из этого, было решено создать некоторого рода NetBIOS браузер. С помощью библиотеки "рсар" (GNU, v. 1.21, 97/10/15, Калифорнийский университет) организовывается перехват всех пакетов широковещательной и групповой рассылки, из них выделяются пакеты NetBIOS протокола, и при разборе пакетов определяются NetBIOS-имена и MAC-адреса источников пакетов. Данный алгоритм позволяет пассивно, не нагружая запросами сеть, собрать через определенное количество времени информацию о соответствии сетевых имен всех работающих компьютеров и их МАС-адресов и, кроме того, определить появление рабочей станции практически одновременно с ее выходом в сетевое окружение.
При создании данной системы необходимо было учитывать быстрое развитие сетевых технологий. Поэтому одно из главных требований заключалось в том, что система должна быть гибкой и легко расширяемой другими подпрограммами. Это достигается тем, что вся информация о происходящем заносится в базу данных (в данном проекте используется СУБД Oracle 8). В дальнейшем любой модуль проекта независимо от того, старый он или новый, может работать с данными, хранимыми в таблицах СУБД. Итак, функциями сервера динамического слежения за работоспособностью сети являются: контроль над работой устройств, подключенных к локальной сети, временем их включения и отключения (осуществляется с помощью обмена пакетами с сетевыми устройствами по ICMP протоколу); обработка всех сетевых пакетов широковещательной рассылки с целью распознавания NetBIOS-имён рабочих станций (которые идентифицируются МАС-адресом сетевой карты); определение доменных имен рабочих станций; организация хранения полученных данных на сервере Oracle; организация доступа к таблицам базы данных через запросы SQL с целью выдачи результатов в систематизированном виде, поиска, сортировки и других действий над данными, выполняемыми средствами сервера Oracle; вывод информации в удобочитаемом виде. При организации сервера динамического слежения за работоспособностью сети было принято решение разделить его на несколько частей: программ, которые работали бы независимо друг от друга. Таких программ три: "monitord", "pingerd" и "netbiosd". Все они являются "демонами" и запускаются одной программой, обеспечивающей их нахождение в одной рабочей группе. Задачами программы "monitord" является периодический запуск программы "pingerd" и анализ результатов, полученных программами "netbiosd" и "pingerd" (рис.2.1). Основное время процесс находится в ожидании, лишь один раз в десять минут посылается сигнал SIGUSR1. Однако при появлении сигнала SIGUSR2, запускается функция анализа полученных данных. Данные, помещенные в память программами "netbiosd" и "pingerd", сравниваются с содержимым базы данных, обрабатываются, и результаты анализа заносятся в базу данных. На рисунках 2.3-2.11 изображены диаграммы, описывающие на языке UML процесс анализа полученных данных.
Основные объекты имитационной модели
Очевидным представляется выделение двух типов объектов: «шина» и «устройство». Из определения сети следует, что имитационная модель должна содержать как минимум три объекта: «шина» и два «устройства»: «ведущее» и «ведомое».
Передача данных имитируется как генерация транзакта («сетевого пакета», состоящего из заголовка и блока данных) в «устройстве» в соответствии с описанной для него «программой»; переход транзакта на обработку к «шине»; переход транзакта на обработку всем «устройствам», «подключенным» к «шине». За единицу модельного времени принята длительность передачи по сети одного байта. Время задержки транзакта в «шине» определяется суммой размеров заголовка пакета и блока данных и скоростью передачи данных. Время обработки транзакта в «устройстве» задается для каждого «устройства» в отдельности.
На рис.3.1 приведена упрощенная диаграмма классов, построенная на языке UML. При передаче транзакта на обработку к «шине» «устройство» вызывает метод передать(). В течение обработки транзакта «шиной», она последовательно вызывает у всех «устройств» методы начать_прием_пакета(), закончить_прием_заголовка() и закончить_прием_данных() в моменты завершения передачи первого байта, заголовка пакета и блока данных соответственно (рис.3.2).
Каждому «устройству» ставится в соответствие определенная «шина», к которой оно «подключено». Изначально все устройства подключены к одной «шине». Моделирование разрыва линии передачи данных может быть организовано путем создания в определенный момент модельного времени нового объекта типа «шина», идентичного существующему, и перераспределения «устройств» между двумя «шинами». При этом восстановление целостности линии моделируется в обратном порядке: перераспределением «устройств» и уничтожением одной из «шин». Данный алгоритм можно упростить, если учесть тот факт, что большинство промышленных сетей строится на основе интерфейса RS-485, который допускает только последовательное соединение устройств, поэтому возникновение разрыва возможно только между двумя соседними устройствами. Таким образом шину, объединяющую N устройств, можно представить как совокупность N-1 сегментов (рис. 3.3). При этом к каждому устройству оказываются подключенными 1-2 сегмента (в зависимости от того, является ли устройство последним в цепочке). При имитации передачи пакета транзакт переходит на обработку уже не к «шине», а к подключенным к «устройству» «сегментам», функциями которых является передача транзакта следующим «устройствам» и «сегментам» (рис.3.4). Разрыв шины моделируется как прекращение функционирования «сегмента». «Устройство» может принадлежать к одному из двух типов: ведущее или ведомое. Для ведущего «устройства» задается список опрашиваемых «устройств», определяются функции посылки запроса и передачи маркера ведущего. Независимо от типа «устройства», оно должно «уметь» отвечать на запросы (рис.3.5). Основной проблемой при моделировании работы сетей на основе различных протоколов является их отличие в системах команд и методах передачи маркера. Для унификации системы моделирования разработан минимальный набор команд, с помощью которого можно имитировать работу устройства в сети: "write" - запись N байт в удаленное «устройство» (при получении «пакета», содержащего эту команду, «устройство-получатель» отвечает на нее передачей «устройству-отправителю» «пакета» подтверждения - "rcptok" -заданной длины); "read" - запрос N байт у удаленного «устройства» («устройство» отвечает на нее передачей «ответа» - "answer", - длина которого равна сумме длины заголовка, заданной перед началом моделирования, и числа запрашиваемых байт); "grant" - передача маркера от одного ведущего к другому. Для имитации передачи команд записи, не требующих подтверждения, используется «широковещательный» адрес ("255").
Ограничение скорости передачи в зависимости от скорости чтения
Избежать простоя процесса декомпрессии можно следующим образом. Так как мы используем протокол ТСРЯР, то время окончания приема кадра клиентом примерно совпадает с моментом окончания передачи этого кадра на сервере. Следовательно, можно избежать ожидания сервером нового запроса. При этом по событию окончания передачи предыдущего кадра сервер должен начать передачу нового кадра. При использовании этого метода, клиент уже не посылает запрос на получение кадра, а вместо этого единожды "подписывается" на получение потока кадров. Чтобы пояснить, как происходит регуляция скорости в этом случае, рассмотрим одну из особенностей работы ТСРЯР (рис.4.4).
С точки зрения программной реализации видеосервера процесс передачи данных по сети выглядит как запись этих данных в соответствующий сокет (дескриптор соединения). При этом данные помещаются в буфер передачи, расположенный на сервере, и, далее, средствами протокола перемещаются в буфер приема, находящийся на клиенте. Программа клиента получает данные в процессе чтения из буфера приема. Если программа клиента будет читать из буфера приема медленнее, чем сервер будет записывать данные в свой буфер передачи, буфер приема заполнится, вслед за этим заполнится буфер передачи, и попытка записи в него новых данных будет приводить к ошибке. Таким образом, уменьшение скорости чтения клиентом из буфера чтения приводит к уменьшению скорости передачи новых кадров сервером и наоборот, увеличение скорости чтения ведет к увеличению скорости передачи.
Основная трудность при реализации этого метода заключается в ограничении скорости чтения из буфера клиента. Рассмотрим упрощенную схему архитектуры программы-клиента (рис.4.5). Для обработки видео с одной камеры мы запускаем два потока, выполняющихся параллельно: TCP-клиент и декомпрессор. TCP-клиент ведет чтение данных из буфера, группировку их в кадры и передачу кадров декомпрессору. Декомпрессор осуществляет декомпрессию кадров и вывод их на экран. Для обработки видео с двух и более камер запускается по одному потоку декомпрессии на каждую из камер и общий поток чтения данных из всех сокетов соединений. Когда какой-либо поток декомпрессии не успевает обрабатывать все поставляемые ему кадры, поток чтения должен приостановить чтение из соответствующего сокета. Чтение можно приостановить после получения какой-то части следующего кадра, или по окончании приема кадра, передаваемого декомпрессору. В первом случае, при возобновлении чтения нам придется вычитать остатки возможно уже устаревшего кадра (при высокой скорости захвата кадров на сервере и низкой скорости обработки кадров на клиенте). Во втором случае, кадр, полученный нами после возобновления чтения, также будет устаревшим, так как сервер по событию окончания передачи одного кадра автоматически начнет передачу следующего. В том и другом случае будет возникать задержка между событием и его отображением. Кроме того, вследствие неравномерности распределения вычислительных ресурсов компьютера-клиента между процессами, при высокой нагрузке на процессор скорость обработки кадров декомпрессором меняется в широких пределах, что приводит к "рывкам" выводимого на экран видеопотока. Регулирование клиентом интервала между кадрами, отправляемыми сервером Для того чтобы усреднить время задержки и по возможности уменьшить его, к механизму неявного регулирования клиентом скорости передачи с видеосервера, мы добавили возможность явного регулирования клиентом интервала между кадрами, отправляемыми сервером. В зависимости от суммарной нагрузки на процессор и от скоростей обработки кадров декомпрессорами клиент указывает серверу максимальную скорость передачи Rs (в кадрах/с) для каждой из камер. Например, если сервер захватывает с какой-нибудь камеры RG кадров/с, но клиент, в силу недостаточности своих вычислительных ресурсов, может отобразить только RD кадров/с (RD RG), серверу следует прореживать (по команде клиента) кадры, записываемые в сокет соединения этого клиента до Rs кадров/с (RS RQ), вне зависимости от скорости чтения данных клиентом. Предлагается следующий метод определения клиентом величины Rs. Мы считаем, что Rs должна указываться серверу в зависимости от скорости приема кадров TCP-клиентом (Re), скорости обработки кадров декомпрессором (RD) и средней суммарной загрузки процессора (L). Регулирование производится дискретно, с интервалом Т (порядка нескольких секунд), при этом новое значение Rs определяется исходя из значения Rs, вычисленного на предыдущем шаге и текущей нагрузки процессора.
