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

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

ТС состоят из части условий и части действий и имеют вид, представленный в таблице 2.1.

Таблица 2.1 – Структура ТС

Список условий наступления событий (Сi)	Список событий (Еj)
Список действий (Ai)	Порядок действий (ai,j)

 

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

 

2.3 Использование ЯТС для моделирования систем информационного взаимодействия 

 

Посмотрим использования ЯТС на примере. Для этого возьмем протокол TCP

TCP (англ. transmission control protocol — протокол управления передачей) — один из основных протоколов передачи данных интернета, предназначенный для управления передачей данных. Сети и подсети, в которых совместно используются протоколы TCP и IP называются сетями TCP/IP.

В отличие от традиционной альтернативы — UDP, который может сразу же начать передачу пакетов, TCP устанавливает соединения, которые должны быть созданы перед передачей данных. TCP соединение можно разделить на 3 стадии:

• Установка соединения
• Передача данных
• Завершение соединения

 

Состояния сеанса TCP
CLOSED	Начальное состояние узла. Фактически фиктивное
LISTEN	Сервер ожидает запросов установления соединения от клиента
SYN-SENT	Клиент отправил запрос серверу на установление соединения и ожидает ответа
SYN-RECEIVED	Сервер получил запрос на соединение, отправил ответный запрос и ожидает подтверждения
ESTABLISHED	Соединение установлено, идёт передача данных
FIN-WAIT-1	Одна из сторон (назовём её узел-1) завершает соединение, отправив сегмент с флагом FIN
CLOSE-WAIT	Другая сторона (узел-2) переходит в это состояние, отправив, в свою очередь сегмент ACK и продолжает одностороннюю передачу
FIN-WAIT-2	Узел-1 получает ACK, продолжает чтение и ждёт получения сегмента с флагом FIN
LAST-ACK	Узел-2 заканчивает передачу и отправляет сегмент с флагом FIN
TIME-WAIT	Узел-1 получил сегмент с флагом FIN, отправил сегмент с флагом ACK и ждёт 2*MSL секунд, перед окончательным закрытием соединения
CLOSING	Обе стороны инициировали закрытие соединения одновременно: после отправки сегмента с флагом FIN узел-1 также получает сегмент FIN, отправляет ACK и находится в ожидании сегмента ACK (подтверждения на свой запрос о разъединении)

Процесс начала сеанса TCP (также называемый «рукопожатие» (англ. handshake)), состоит из трёх шагов.

1. Клиент, который намеревается установить  соединение, посылает серверу сегмент  с номером последовательности  и флагом SYN.

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

• В случае успеха сервер посылает клиенту сегмент с номером последовательности и флагами SYN и ACK, и переходит в состояние SYN-RECEIVED.

• В случае неудачи сервер посылает клиенту сегмент с флагом RST.

2. Если  клиент получает сегмент с  флагом SYN, то он запоминает номер  последовательности и посылает  сегмент с флагом ACK.

• Если он одновременно получает и флаг ACK (что обычно и происходит), то он переходит в состояние ESTABLISHED.
• Если клиент получает сегмент с флагом RST, то он прекращает попытки соединиться.
• Если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново.

3. Если  сервер в состоянии SYN-RECEIVED получает  сегмент с флагом ACK, то он переходит  в состояние ESTABLISHED.

• В противном случае после тайм-аута он закрывает сокет и переходит в состояние CLOSED.

Процесс называется «трёхэтапным согласованием» (англ. three way handshake), так как несмотря на то что возможен процесс установления соединения с использованием четырёх сегментов (SYN в сторону сервера, ACK в сторону клиента, SYN в сторону клиента, ACK в сторону сервера), на практике для экономии времени используется три сегмента.

Завершение соединения можно рассмотреть в три этапа:

1. Посылка серверу от клиента флага FIN на завершение соединения.
2. Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто.
3. После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.

 

Теперь опишем данный протокол при помощи ТС.

Client	С1	С2	С3	С4
Listen	1	0	0	0
Получен флаг SYN	0	1	1	1
Получен флаг ACK	0	0	1	0
Получен флаг RST	0	0	0	1
Посылка флага SYN.	1
Server!	2	2
Переход в состояние ESTABLISHED			1
Прекращение  соединения				1
Client!				2
Sent!			2
Посылка сегмента ACK		1

 

Server
Состояние Syn-Received	0	0	1	1
Получен флаг SYN	1	1	0	0
Получен флаг ACK	0	0	1	0
Таймаут	0	0	0	1
Есть свободная память	1	0	0	0
Посылка SYN+ACK	1
Посылка RST		1
Переход в состояние  ESTABLISHED			1
Переход в состояние SYN-RECEIVED	2
Переход в состояние CLOSED				1
CLIENT!	3	2		2
SENT!			2

 

 

 

 

SENT	C1	C2	C3	C4
Пакет битый		1
Получен предыдущий пакет			1
Все передано	1
2 копии				1
CLIENT!		1
Отправка пакета			1
SENT!			2
Устранение дубликата				1
CLOSED!	1			2

 

CLOSED
Завершение	1
Получен ACK		1
Получен FIN		1
Отправка FIN	1
CLOSED!	2
Завершение соединение		1
Отправкa ASK		2

 

У нас получилось 4 таблицы: CLIENT, SERVER, SENT, CLOSED.

Таблица CLIENT отвечает за действия и состояние клиента, таблица SERVER отвечает за действия и состояние сервера, таблица SENT отвечает за пересылку пакетов, таблица CLOSED – за завершение соединения.

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

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

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

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

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

Таблицы событий хранятся в БД. Начнем моделирование с таблицы Client, введем первое событие: 1000. Включим автогенерацию:

Рисунок 2.2 – Установка начальных параметров

Запустим моделирование. Система выдает нам следующее сообщение:

Действительно, если просмотреть ТС, то они не полные. Записанные интервалы не покрывают все возможные события, когда наша система генерирует случайным образом все возможные. Посмотрим какое решение предлагает программа:

Из данного результата мы видим, что была осуществлена посылка флага SYN на Server, но результат не был получен, т.к. было сгенерировано событие не описанное в нашей системе. Чтобы решить данную проблему предложено 2 варианта: скорректировать ТС самому, либо добавить недостающие события, предложенные системой, и продолжить моделирование.

Отредактируем ТС сами. Для этого нажмем кнопку «Редактировать ТС(самому)» и у нас откроется таблица Server:

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

 

 

 

 

 

 

 

 

3 ТЕСТИРОВАНИЕ

 

Существует два вида тестирования:

• научное;

• обыденное, практическое (применяемое в учебном процессе). В учебном процессе тесты применяются в основном для проверки качества знаний. До 60-х гг. смысл тестов усматривался в дифференциации студентов по знаниям. После 60-х гг. тесты стали ориентироваться на критериальную дифференциацию (критериально-ориентированные тесты). Тесты могут быть гомогенными (по одному предмету) и гетерогенными (проверяется сумма знаний). Тестирование предполагает системность. В рамках одного вуза оно должно проводиться от момента поступления студентов до момента окончания ими вуза. Это системная работа со своим финансированием и своим штатом. Специалистов по тестированию мало. Вся научная и методическая литература в основном на английском языке. На Западе чем выше уровень развития тестового контроля, тем выше рейтинг вуза. Нидерланды являются центром тестирования. Затем идут Япония, Австралия, США.

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

Цели тестового контроля могут быть следующими:

• обобщающая - повышение качества обучения;

• локальные (конкретные) цели:

1. Объективная оценка объема  знаний студентов.

2. Профориентация и профотбор. Тесты  устанавливают адекватность выбора  профессии абитуриентами.

3. Итоговая аттестация и аккредитация  вузов. В настоящее время в  России созданы с этой целью  группы разработчиков - 5-6 вузов, работающих  по разным специальностям.

4. Выявление структуры знаний  у студентов (схема 5.3). Особенное  внимание уделяется структуре, а  не объему знаний в Японии.