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

Министерство общего и профессионального образования Российской Федерации Пензенский государственный университет

ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ РАСПРЕДЕЛЕННЫХ СИСТЕМ НА ОСНОВЕ ЛОКАЛЬНОЙ ВЫЧИСЛИТЕЛЬНОЙ СЕТИ

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

ПЕНЗА 1998

УДК 681.324

П 79 Даны методические указания к выполнению шести лабораторных работ, связанных с проектированием и реализацией распределенных систем на основе локальной вычислительной сети (ЛВС). Целью первой работы является изучение сетевых моделей как средства спецификации, верификации и проектирования систем с параллельными процессами. Цель второй работы - приобретение навыков построения прототипов распределенных систем на основе ЛВС с использованием сетевых моделей. Тематика последних четырех работ связана с использованием протокола IPX. Для работы с IPX рекомендуется использовать библиотеку функций NetWare C Interface for DOS фирмы Novell. При выполнении лабораторных работ могут использоваться языки Паскаль, Си, Си++. Приводится список дополнительных тем лабораторных и курсовых работ. Методические указания подготовлены на кафедре "Вычислительная техника" и предназначены для студентов специальности 22.05, изучающих дисциплину "Системотехника, вычислительные комплексы и сети ЭВС", а также для студентов специальности 22.01, изучающих дисциплину "Вычислительные комплексы, системы и сети". Составитель В.Н.Дубинин Р е ц е н з е н т В.Д.Былкин, канд. техн. наук, доц. кафедры "Периферийные средства вычислительной техники" Пензенского технологического института ВВЕДЕНИЕ В настоящее время широкое распространение получили локальные вычислительные сети (ЛВС), позволяющие интегрировать аппаратные, программные и информационные ресурсы узлов, входящих в сеть [13-14,17]. На основе ЛВС создаются распределенные вычислительные, информационные, управляющие и кон-

2

тролирующие системы различного назначения, а также системы передачи данных [1]. Одна из наиболее распространенных и популярных ныне ЛВС - сеть Ethernet. В качестве метода доступа к среде передачи (коаксиальному кабелю) в ней используется протокол CSMA/CD. Сетевая архитектура ЛВС часто строится на основе протоколов IPX/SPX. Стандарт Ethernet распространяется теперь на такие среды передачи, как оптическое волокно и неэкранированная витая пара. Самый новый из стандартов Ethernet - стандарт 802.3 100BaseT Fast Ethernet, определяющий скорость передачи 100 Мбит/с. К последним разрабатываемым стандартам Ethernet относится стандарт 1000BaseT Gigabit Ethernet, определяющий скорость передачи 1 Гбит/с [18]. Динамика работы распределенных систем характеризуется параллельностью и асинхронностью протекающих в системе процессов, сложностью межпроцессных взаимодействий [11]. Вышеизложенное определяет актуальность данных методических указаний, ориентированных на получение студентами знаний и навыков по проектированию и реализации распределенных систем на основе ЛВС. Методические указания включают описание шести лабораторных работ. Для каждой лабораторной работы приводятся варианты лабораторных заданий. Целью первой работы является изучение сетей Петри и их модификаций как средства спецификации, верификации и проектирования систем с параллельными процессами, построение и исследование сетевой модели конкретной вычислительной системы или системы параллельных процессов. Цель второй работы - приобретение навыков построения прототипов распределенных систем на основе ЛВС с использованием сетевых моделей. Предлагаемая технология создания распределенных систем включает разработку сети процессов, протекающих в системе, и оптимальную "раскладку" процессов по узлам. Для выполнения первых двух лабораторных работ используется комплекс программ для графического моделирования расширенных

3

сетей Петри ("Петрис"), разработанный на кафедре "Вычислительная техника" Пензенского государственного университета [20,24]. Тематика последних четырех работ связана с использованием протокола IPX (Internetwork Packet Exchange) - межсетевого протокола передачи пакетов [11]. Данный протокол используется в сетевом программном обеспечении Novell и является реализацией уровня дейтаграмм. Уровень дейтаграмм соответствует сетевому уровню (network layer) семиуровневой модели вычислительной сети, разработанной Международной организацией стандартизации (МОС). Протокол IPX широко применяется в различных ЛВС, в том числе и в популярной кабельной ЛВС Ethernet. Для упрощения использования протокола IPX в лабораторном практикуме рекомендуется использовать библиотеку функций NetWare C Interface for DOS фирмы Novell, описанную, например, в работе [14]. В случае отсутствия данной библиотеки можно использовать более низкоуровневый интерфейс для работы с функциями протокола IPX , непосредственно загружая в регистр BX код выполняемой функции. При этом необходимо предварительно определить точку входа API драйвера IPX/SPX, используя мультиплексное прерывание INT 2Fh. При выполнении лабораторных работ могут использоваться языки Си и Си++, а также язык Паскаль, поскольку имеется версия библиотеки NetWare C Interface for DOS, адаптированная для языка Паскаль. В результате выполнения работ, связанных с протоколом IPX, студенты должны изучить функции протокола IPX для открытия и закрытия сокетов, приема и передачи дейтаграмм, планирования и отмены событий, приобрести навыки использования данных функций при разработке сетевых приложений, в частности, для реализации процедур передачи данных в ЛВС с использованием механизма квитирования и тайм-аутов. Приводится довольно большой список дополнительных тем лабораторных и курсовых работ, которые при необходимости могут быть детально проработаны.

4

Лабораторная работа N 1 ИССЛЕДОВАНИЕ СЕТЕВЫХ МОДЕЛЕЙ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ С ПАРАЛЛЕЛЬНЫМИ ПРОЦЕССАМИ Цель работы: изучить сети Петри и их модификации, функционирование сетевых моделей, сетевые модели вычислительных систем с параллельными процессами, исследовать их с использованием методов имитационного моделирования и построения графа достижимых маркировок. Порядок выполнения работы 1. Изучить сети Петри и методы их анализа. 2. Изучить основные приемы работы с графическим редактором и интерпретатором, а также конструктором графа достижимых маркировок (ГДМ) сетевых моделей системы "Петрис". 3. Изучить функционирование заданной системы с параллельными процессами. 4. Построить сетевую модель заданной системы с параллельными процессами. 5. Запустить графическую оболочку системы "Петрис". 6. Сформировать в графическом редакторе сетевую модель заданной системы с параллельными процессами. 7. Установить режим пошаговой интерпретации и изучить функционирование сетевой модели, запуская вручную поочередно те или иные переходы. 8. Установить демонстрационный режим автоматической интерпретации и пронаблюдать автоматическое функционирование сетевой модели, состоящее в запуске переходов и передвижении меток на экране монитора.

5

9. Распечатать или срисовать с экрана содержимое файлов таблицы позиций (<имя сети>.POS) и таблицы переходов (<имя сети>.TR). 10. Установить имитационный режим автоматической интерпретации и запустить процесс интерпретации сетевой модели. Число срабатываний переходов положить равным 10 000. 11. Распечатать или срисовать с экрана содержимое полученных в результате выполнения п.10 файлов таблиц статистики о позициях (<имя сети>.PST) и о переходах (<имя сети>.TST). 12. Проанализировать содержимое файлов таблиц статистики о позициях и переходах и сделать выводы о свойствах сетевой модели, а также системы параллельных процессов. 13. Построить ГДМ для заданной сетевой модели с помощью конструктора ГДМ. При построении ГДМ использовать автоматический режим. 14. Распечатать или срисовать с экрана содержимое следующих полученных в результате выполнения п.13 файлов: <имя сети>.MAR - файл достижимых маркировок; <имя сети>.GDS - файл структуры ГДМ. 15. На основе полученных в п.14 данных построить графическое представление ГДМ. 16. Проанализировать полученный ГДМ и сделать выводы о свойствах сетевой модели, а также системы параллельных процессов. 17. Подготовить отчет о проделанной работе. Примечание 1. П.п. 1-4, 8, 15-17 выполняются в домашних условиях. Примечание 2. При облегченном варианте возможно исходное задание не системы параллельных процессов, а ее сетевой модели непосредственно.

6

Содержание отчета 1) Титульный лист; 2) задание; 3) содержательное описание системы с параллельными процессами; 4) графическое представление сетевой модели; 5) описание сетевой модели; 6) таблицы позиций и переходов; 7) таблицы статистики о позициях и переходах; 8) таблицы достижимых маркировок и дуг ГДМ; 9) графическое представление ГДМ; 10) выводы о свойствах сетевой модели и системы с параллельными процессами. Основные сведения и методические указания Структура сетей Петри Сеть Петри (СП) - это двудольный ориентированный граф, включающий вершины двух типов - позиции и переходы [2-3,1011]. Графически позиции изображаются кружками, а переходы прямоугольниками. В позиции может находиться одна или несколько меток, графически отображаемых точками. Число меток в позиции называется маркировкой позиции. Маркировка позиции p обозначается как M(p). Маркировка всех позиций в совокупности называется маркировкой сетевой модели. Маркировка сетевой модели часто представляется вектором маркировки. Начальную маркировку сетевой модели обозначим как M0. Для увеличения описательной и моделирующей мощности в определение сети Петри вводятся модификации. Формальное описание сетевых моделей, используемых в системе "Петрис", можно найти в работах [20,24]. Основная интерпретация сетей Петри для моделирования систем дается в терминах событий и условий. Переходы сетевой модели интерпретируются как события, входные позиции перехода - как условия возникновения события (пред-условия), выходные позиции − как условия, возникающие после совершения события (пост-условия).

7

Функционирование сетей Петри Сетевая модель функционирует, переходя от одной маркировки к другой. Текущая маркировка сети Петри изменяется в результате срабатывания переходов. В один момент времени может сработать только один из разрешенных переходов (какой именно в сетях Петри не определяется). Переход разрешен, если каждая из его входных позиций содержит хотя бы одну метку. При срабатывании перехода маркировка сети изменяется следующим образом: из входных позиций перехода удаляется по одной метке, а в выходные − добавляется по одной. Свойства сетевых моделей Свойства СП подразделяются на две группы: 1) определяющие активность сети; 2) свойства функций маркировок. Маркировка M' достижима в данной сетевой модели из маркировки M, если существует последовательность срабатывания переходов, в результате которой маркировка М меняется на М'. Маркировка M' называется тупиковой, если при этой маркировке нет ни одного разрешенного перехода. Переход t сетевой модели называется живым, если из любой маркировки, достижимой из начальной, существует последовательность срабатывания, включающая переход t. Сетевая модель является живой, если живыми являются все ее переходы. Переход t сетевой модели называется потенциально живым, если существует достижимая от начальной разметки маркировка, при которой переход может сработать. Переход t сетевой модели называется мертвым, если он не является потенциально живым.

8

Позиция сетевой модели называется k-ограниенной (k>0), если для любой достижимой из M0 маркировки M(p) ≤ k. Сетевая модель, в которой все позиции k-ограничены, называется kограниченной. Если сеть 1-ограничена, то она называется безопасной. Основным методом для определения свойств сетевых моделей в данной лабораторной работе является метод построения графа достижимых маркировок (ГДМ). Граф достижимых маркировок Граф достижимых маркировок (ГДМ) сетевой модели N есть ориентированный граф G = (V,E,L), где V − множество вершин, равное множеству достижимых маркировок сетевой модели; Е − множество дуг такое, что (Mi,Mj) ∈ E, если маркировка Mj непосредственно достижима из маркировки Mi; L:E->T − функция разметки дуг именами переходов такая, что L(Mi,Mj)=t, если маркировка Мj непосредственно достижима из маркировки Mi при срабатывании перехода t. Исследование графа достижимых маркировок Анализ свойств сетевой модели по ГДМ дает наиболее полную характеристику ее поведения. Рассмотрим некоторые свойства сетевой модели, которые могут быть получены на основе визуального анализа ГДМ. Маркировка М' достижима в сети N от маркировки М, если в ГДМ имеется путь от вершины, представляющей маркировку М, к вершине, представляющей маркировку М'. Безопасность и ограниченность определяются на основе просмотра множества достигнутых маркировок. Любая достижи-

9

мая в безопасной сети маркировка представляет собой вектор из 0 и 1. Переход t живой при маркировке М, если из любой вершины ГДМ существует путь, содержащий дугу, помеченную t. Переход t условно-живой при маркировке М, если в ГДМ всегда можно найти маршрут, в котором переход t встречался бы сколь угодно большое наперед заданное число раз. Переход t частично-мертвый при маркировке М, если в ГДМ нет такого маршрута, начинающегося из М, в котором переход t встречался бы сколь угодно большое число раз. Переход t мертвый при маркировке М в сети N, если в ГДМ нет пути, где переход t появился бы хотя бы один раз. Тупиковой маркировке в сетевой модели соответствует висячая вершина в ГДМ. Определение свойств сетевой модели на основе результатов интерпретации Под интерпретацией сетевой модели понимается процесс передвижения меток по ее элементам в соответствии с правилами функционирования сети. В ходе интерпретации в системе "Петрис" собирается статистика о позициях и переходах сетевой модели. Интерпретация сетевой модели не всегда позволяет точно определить свойства сетевой модели. Скорее, она позволяет обнаружить невыполнение каких-либо определяемых свойств. Достоверность выводов по результатам интерпретации повышается с увеличением времени моделирования. Примеры интерпретации результатов интерпретации сетевой модели: 1. Если максимальная маркировка какой-либо позиции, зафиксированная в ходе интерпретации, превысила число k, то

10

данная позиция не k-ограниченна и вся сетевая модель не kограниченна. 2. Если какой-либо переход сработал хотя бы один раз, то он не мертвый. 3. Если какой-либо переход давно не срабатывал, то, вероятно, он "умер" и, следовательно, он не живой. Интерпретация свойств сетевых моделей в терминах свойств системы параллельных процессов В качестве примера ниже приведены три правила: 1. Если сетевая модель живая, то представляемая ею система параллельных процессов свободна от тупиковых ситуаций. 2. Если сетевая модель имеет один или несколько не живых переходов, то в представляемой ею системе параллельных процессов возможен частичный (локальный) тупик. 3. Если сетевая модель безопасна, то в представляемой ею системе параллельных процессов исключены всякого рода переполнения. Объекты моделирования Объектом моделирования в данной лабораторной работе являются вычислительные системы с параллельными процессами. Особенности каждого конкретного взаимодействия между параллельными процессами определяются задачей синхронизации. Количество различных задач синхронизации неограниченно. Однако некоторые из них являются типовыми. К ним относятся: взаимное исключение, «производители-потребители», «писатели-читатели», «обедающие философы», изучаемые в данной лабораторной работе [21,23].

11

Практическая работа в системе "Петрис" Подробное описание работы с графическим редактором и интерпретатором можно найти в [20,24].

Запуск и загрузка Загрузочный (выполнимый) модуль графического интерпретатора системы "Петрис" имеет имя petris.exe и находится в каталоге x:\petris. В этом же каталоге находится и загрузочный модуль конструктора ГДМ. Его имя gdm.exe. Вызов графического интерпретатора из текущего каталога производится следующим образом: > petris Вызов конструктора ГДМ из текущего каталога может быть осуществлен следующим образом: > gdm [<имя сети>] В квадратные скобки заключена необязательная конструкция. Конструктор ГДМ функционирует в следующих режимах: - режим автоматического построения ГДМ без отображения промежуточных результатов с записью конечных результатов в файлы; - режим пошагового построения ГДМ с отображением промежуточных результатов; - режим определения пути в построенном ГДМ до частично или полностью заданной маркировки. Структура выходных файлов

12

При описании структуры выходных файлов системы "Петрис" используются следующие обозначения: символ # означает перевод на новую строку, скобки {} определяют многократное повторение синтаксической конструкции, заключенной в эти скобки. Если необходимо, приводятся имя и тип поля файла. Имя поля заключено в круглые скобки, а тип поля - в квадратные. Файл таблицы позиций (<имя сети>.POS) Таблица позиций содержит описание всех позиций сетевой модели, включая имя позиции и ее атрибуты. Строка таблицы описывает одну позицию. Структура файла: Число позиций # { Порядковый номер [Целое] Имя позиции [Символьное(6)] Начальная маркировка [Целое] Ограниченность позиции [Целое] # } Файл таблицы переходов (<имя сети>.TR) Таблица переходов содержит описание всех переходов сетевой модели, включая имя перехода и его атрибуты. Строка таблицы описывает один переход. Структура файла: Число переходов # { Порядковый номер [Целое] Имя перехода [Символьное(6)] Приоритет [Целое] Закон распределения времени задержки [Целое]

13

Первый параметр закона [Вещественное] Второй параметр закона [Вещественное] Номер потока случайных чисел [Целое] Вес (метка) перехода [Целое] Вероятность перехода [Вещественное] Номер статистической таблицы [Целое] # } Файл достижимых маркировок (<имя сети>.MAR) В этом файле хранятся все достижимые маркировки соответствующей сетевой модели. Каждая маркировка представляет собой вектор. Структура файла: Число позиций в маркировке # { Номер маркировки Вектор маркировки # } Файл структуры ГДМ (<имя сети>.GDS) В этом файле хранятся все дуги ГДМ. Каждая дуга определяется своим источником и приемником. Каждая запись файла определяет одну дугу. Структура файла: Число дуг ГДМ # {Номер маркировки-источника дуги Номер перехода Номер маркировки-приемника дуги # } Файл таблицы статистики о позициях (<имя сети>.PST)

14

Структура файла: Число позиций # Имя позиции [Символьное(6)] (NameP) Номер позиции [Целое] (NumP) Текущая маркировка позиции [Целое] (Mark) Максимальная маркировка позиции [Целое] (MaxMark) Число входов в позицию [Целое] (NEntry) Число пустых входов [Целое] (NEmptEntr) Средняя маркировка позиции [Вещественное](AvrM) Среднее время пребывания метки в позиции [Вещественное](AvrT) Время последнего изменения маркировки [Вещественное] (OldT) Сумма произведений dTdM [Вещественное](Sum) # } {

Файл таблицы статистики о переходах (<имя сети>.TST) Структура файла: Число переходов # { Имя перехода [Символьное(6)] (NameT) Номер перехода [Целое] (NumT) Число срабатываний перехода [Целое] (NFireT) Номер последнего срабатывания по счету [Целое] (LFire) Текущее содержимое задержки [Целое] (MT) Максимальное содержимое задержки [Целое] (MaxMT) Среднее содержимое задержки [Вещественное](AvrMT) Среднее время задержки [Вещественное](AvrT)

15

Число непустых прерываний перехода [Целое] (NInterr) Время последнего изменения содержимого временной задержки [Вещественное](OldT) Сумма произведений dTdMT [Вещественное](Sum) # } Варианты заданий 1. Задача взаимного исключения [21,23]. 2. Система параллельных процессов с тупиковой ситуацией [21]. 3. Задача "производитель-потребитель" [21]. 4. Задача "писатели-читатели" [21]. 5. Задача об обедающих философах [21,23]. 6. Альтернативно-битовый протокол [21,23]. Остальные варианты могут быть взяты из [10], где приведены варианты около 20 сетевых моделей.

Лабораторная работа N 2 ПОСТРОЕНИЕ ПРОТОТИПОВ РАСПРЕДЕЛЕННЫХ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ С ИСПОЛЬЗОВАНИЕМ СЕТЕВЫХ МОДЕЛЕЙ Цель работы: приобрести навыки построения прототипов распределенных вычислительных систем (РВС) на основе ЛВС с использованием сетевых моделей. Порядок выполнения работы

16

1. Изучить основные расширения сетей Петри; 2. Изучить работу графического интерпретатора в режиме многомашинной интерпретации сетевых моделей; 3. Изучить принципы построения РВС; 4. Изучить принципы организации конвейерной и параллельной обработки в РВС; 5. Составить сетевую модель, представляющую заданную систему процессов по заданному текстовому описанию; 6. Разбить сетевую модель на фрагменты; 7. Произвести распределение фрагментов по узлам РВС; 8. Запустить графическую оболочку системы "Петрис" на каждом узле РВС; 9. Сформировать на каждом узле РВС с использованием графического редактора фрагмент сетевой модели, соответствующий данному узлу; 10. Запустить на каждом узле РВС графическую интерпретацию сетевых фрагментов в пошаговом режиме; 11. Изучить динамику работы системы процессов в РВС, запуская вручную те или иные переходы; 12. Оформить отчет. Примечание 1. Данная лабораторная работа носит коллективный характер. Перед выполнением работы преподаватель разбивает бригады студентов на группы. В группу входят 3 - 4 бригады. Каждая бригада работает за отдельным компьютером. Группа бригад выполняет п.п.5-7, 11 работы совместно. Примечание 2. П.п. 1 - 7, 12 выполняются в домашних условиях. Содержание отчета

17

1) Тèòóëüíûé лист; 2) задание; 3) структура РВС; 4) текстовое описание системы процессов, протекающих в РВС; 5) сетевая модель системы процессов; 6) разбиение сетевой модели на фрагменты; 7) характеристики РВС (степень параллелизма выполнения процессов).

Основные сведения РВС - это целевая система, представляющая совокупность обрабатывающих узлов с распределенными по ним данными, процессами обработки информации и управления, и взаимодействующих через каналы связи путем обмена сообщениями [1]. Динамика работы РВС характеризуется параллельностью и асинхронностью протекающих в системе процессов, сложностью межпроцессорных взаимодействий [11-12,21,23-24]. В данной лабораторной работе РВС реализуется на аппаратной платформе ЛВС Ethernet, имеющей в простом варианте шинную топологию и предоставляющей пользователю широкий спектр коммуникационных услуг (рис. 1). Ì î í î êàí àë

Óçåë 1

Óçåë 2

•••

Рèñ. 1. Сòðóêòóðà ËÂÑ ñ шèííîé тîïîëîãèåé

18

Óçåë N

В РВС возможна и целесообразна организация конвейерной и параллельной обработки. Конвейерная обработка сводится к одновременному выполнению нескольких процессов, каждый из которых выполняет свой этап обработки данных, организуемых в поток. При этом по завершению "своей" работы над данными процесс передает их для дальнейшей обработки своему последователю. При конвейеризации обработки данные обрабатываются последовательно, а процессы выполняются параллельно (рис. 2). È ñõî äí û å äàí í û å

Ï ðî ì åæóòî ÷í û å äàí í û å Ï ðî öåññ 1

...

Ðåçóëüòàò

Ï ðî öåññ N Î ÷åðåäü N

Î ÷åðåäü 1

Рèñ. 2. Кîíâåйåðíàÿ оáðàáîòêà дàííûõ

Суть параллельной обработки состоит в одновременном выполнении нескольких процессов обработки данных на различных процессорах (ЭВМ, узлах). При этом считается, что данные независимы друг от друга. В качестве основы построения алгоритмов функционирования РВС в целом и каждого узла в отдельности используются сетевые модели системы "Петрис". Технология создания РВС включает разработку сети процессов, протекающих в системе, и оптимальную "раскладку" процессов по узлам РВС. Под процессом понимается система действий, реализующих определенную функцию, и связанную с исполнением программы на процессоре. Сеть процессов отражает отношения между процессами. Основными связями в сети процессов являются последовательная и параллельная связь. Сеть процессов может быть выражена в текстовом виде (в виде программы). Для этого используются символьные

19

операторные скобки SEQ-END и PAR-END. Процессы, заключенные в скобки SEQ-END, выполняются последовательно, а процессы, заключенные в скобки PAR-END, − параллельно. Система процессов, заключенная в скобки PAR-END, считается выполненной, если выполнены все процессы в этих скобках. Скобки PAR-END служат управляющими операторами, причем открывающая скобка PAR служит для запуска параллельных процессов, а закрывающая скобка END − для их синхронизации. Пример системы последовательных процессов SEQ Process 1; Process 2; END Пример системы параллельных процессов: PAR Process 3; Process 4; END Пример системы последовательно-параллельных процессов: SEQ Process 5; PAR Process 6; Process 7; END

20

Process 8; END Для представления циклической структуры используется конструкция: CYCLE-END, а для представления источника заявок − GENERATE. Существует множество критериев оптимальности распределения процессов по узлам РВС, в их числе максимальная степень параллелизма выполнения процессов, минимум накладных расходов на межузловые обмены, минимум стоимости системы и т.д. В лабораторной работе будем использовать первый из перечисленных критериев. Для достижения оптимального размещения в этом случае будем пользоваться следующими правилами: 1) процессы, выполняемые параллельно, целесообразно размещать на разных узлах; 2) процессы, выполняемые последовательно, целесообразно размещать на одном узле. При этом к нулю сводятся накладные расходы на межпроцессный обмен через каналы связи. (Прим.: Это правило недействительно для организации конвейерной обработки). Сеть (система) процессов может быть представлена в виде сетевой модели и реализована в системе "Петрис". Преимущества сетей Петри и их модификаций как алгоритмической основы для построения прототипов РВС заключается в возможности описания параллельных процессов, протекающих в системе; в возможности представления алгоритмов на различных уровнях абстракции; ясности и понятности сетевой модели, что делает ее удобной для использования в учебном процессе. Наличие в сетевой модели ингибиторных дуг ставит ее по вычислительной мощности в один ряд с машинами Тьюринга. Каждый процесс представляется следующим фрагментом сетевой модели, приведенным на рис. 3.

21

p1

t1

p2

Рèñ. 3. Фðàãìåíò сåòåâîé мîäåëè, пðåäñòàâëÿþùèé прîöåññ

На данном рисунке переход t1 - переход, представляющий собственно процесс, позиция p1 - условие готовности процесса к выполнению, позиция p2 - условие окончания выполнения процесса. Для представления цикличности процесса следует совместить позиции p1 и p2. Позиции p1 и p2 в системе "Петрис" могут быть входным и выходным портом соответственно. Для распараллеливания процессов используется фрагмент сетевой модели, представленный на рис. 4. t2

Рèñ. 4. Фðàãìåíò сåòåâîé мîäåëè дëÿ рàñïàðàëëåëèâàíèÿ пðîöåññîâ

На данном рисунке переход t2 соответствует скобке PAR. Для синхронизации параллельных процессов используется фрагмент сетевой модели, представленный на рис. 5.

22

t3

Рèñ. 5. Фðàãìåíò сåòåâîé мîäåëè дëÿ сèíõðîíèçàöèè пðîöåññîâ

На данном рисунке переход t3 соответствует скобке END в системе скобок PAR-END. Источник запросов (данных) определяет фрагмент сетевой модели, представленный на рис. 6.

Рèñ. 6. Фðàãìåíò сåòåâîé мîäåëè дëÿ пðåäñòàâëåíèÿ иñòî÷íèêà зàïðîñîâ

Для возможности взаимодействий (путем передачи меток) сетевых фрагментов, расположенных на различных ПЭВМ, в системе "Петрис" используются входные и выходные порты. Под входным портом понимается граничная позиция модуля, в которую поступают метки из других сетевых модулей. Входной порт не имеет входящих дуг. Выходной порт − это граничная позиция модуля, в которую поступают метки из данного модуля для передачи

23

их другим сетевым модулям. Выходной порт не имеет выходящих дуг. Связь между сетевыми модулями организуется на основе глобальных имен входных и выходных портов. Считается, что метки, поступающие в выходной порт, например, с именем Port1 пересылаются (копируются) во входные порты с именем Port1 всех сетевых модулей. При разбиении сетевой модели на фрагменты следует обратить особое внимание на именование входных и выходных портов, поскольку таким образом определяются межфрагментные связи. На рис. 7 в качестве примера представлен сетевой фрагмент в системе "Петрис", имеющий два входных (port1, port2) и пять выходных (port3 - port7) портов. При этом переход t1 представляет элемент синхронизации, переход t2 − некоторый процесс, переходы t3 и t4 − элементы распараллеливания. Представленному сетевому фрагменту присущ недетерминизм вследствие недетерминированности срабатывания переходов t3 и t4, имеющих общую разделяемую позицию p2. Варианты заданий В качестве исходных данных используются следующие варианты текстовых описаний системы параллельных процессов: Вариант 1

Вариант 2

СYCLE

CYCLE

SEQ

PAR Process 1;

Process 1;

Process 1; Process 2;

PAR Process 2;

SEQ Process 3;

SEQ

Process 4;

Process 3; Process 4; END

Вариант 3 GENERATE

END END

24

Process 2; Process 3;

END

END Process 5; END END

Варианты 1 и 3 рассчитаны на 3-4 узла, вариант 2 - на 4-5 узлов. В варианте 3 используется конвейерная обработка данных.

25

26

Лабораторная работа N 3 РАБОТА С СОКЕТАМИ СЕТЕВОГО ПРОТОКОЛА IPX Цель работы: изучить функции IPXOpenSocket и IPXCloseSocket для работы с сокетами протокола IPX, приобрести навыки использования данных функций при разработке сетевых приложений. Порядок выполнения работы 1. Ознакомиться с типами сокетов и операциями над сокетами (открытие, закрытие) в протоколе IPX. 2. Изучить программный интерфейс функций: IPXInitialize - ИНИЦИАЛИЗАЦИЯ ДРАЙВЕРА ПРОТОКОЛА IPX, IPXOpenSocket - ОТКРЫТЬ СОКЕТ, IPXCloseSocket - ЗАКРЫТЬ СОКЕТ. 3. Написать на языке программирования высокого уровня (Паскаль, Си или Си++) программу для открытия и закрытия сокетов. 4. Произвести эксперимент в ЛВС Ethernet по открытию и закрытию сокетов протокола IPX. 5. Оформить отчет о проделанной работе.

Основные сведения Под сокетом понимается логический порт программы, через который она ведет обмен данными с программами, расположен-

27

ными на других станциях. Для идентификации сокетов используются числовые значения. Над сокетами определены две операции: открытия и закрытия. В одной программе может быть открыто несколько сокетов, причем некоторые из них могут использоваться для передачи, а некоторые − для приема пакетов. Для работы с сокетами используются две функции: IPXOpenSocket и IPXCloseSocket для открытия и закрытия сокета, соответственно. Функция IPXInitialize Данная функция получает адрес точки входа для вызова API драйвера протокола IPX и может использоваться для проверки загрузки драйвера IPX. Интерфейс данной функции определен в библиотеке NetWare C Interface следующим образом: BYTE IPXInitialize(void); Возвращаемые значения: 00h - успешное выполнение; F0h - драйвер IPX не установлен. Интерфейс функции IPXInitialize в библиотеке NetWare C Interface, адаптированной для языка Паскаль, определяется таким образом: function IPXInitialize : Word; При использовании низкоуровневого интерфейса для проверки загруженности драйвера IPX необходимо загрузить в регистр AX значение 7А00h и вызвать мультиплексное прерывание INT 2Fh. Если после возврата из прерывания в регистре AL будет значение FFh, драйвер IPX загружен. Адрес точки входа для вызова API драйвера при этом будет находиться в регистровой паре ES:DI. Если же содержимое регистра AL после возврата из прерывания INT 2Fh будет отлично от FFh, драйвер IPX не загружен.

28

Функция IPXOpenSocket Данная функция используется для открытия сокета. Интерфейс функции для открытия сокета определен в библиотеке функций NetWare C Interface следующим образом: int IPXOpenSocket(BYTE *socketNum, BYTE socketType); Параметры: socketNumber - указатель на двухбайтовый массив, содержащий значение сокета или ноль, если требуется получить динамический сокет. socketType - тип сокета (короткоживущий или долгоживущий). Возвращаемые значения: 00h - сокет успешно открыт; FEh - переполнилась таблица сокетов; FFh - сокет уже был открыт раньше. Сокеты бывают короткоживущие и долгоживущие (кодируются соответственно как 00h и FFh). Короткоживущие сокеты освобождаются (закрываются) автоматически после завершения программы. Долгоживущие сокеты можно закрыть только с помощью специально предназначенной для этого функции IPXCloseSocket. Долгоживущие сокеты закрываются при перезагрузке DOS. Такие сокеты больше всего подходят для использования резидентными программами или драйверами. Сокеты от 0 до 4 000h в сети Novell NetWare зарезервированы и не должны использоваться в программном обеспечении пользователей. Сокеты от 4 000h до 8 000h распределяются динамически. В случае, если динамическое распределение сокетов не используется, а задается свой номер сокета, то необходимо также использовать значения в диапазоне от 4 000h до 8 000h. По умолчанию при загрузке оболочки рабочей станции максимально доступно 20 соке-

29

тов. При соответствующей настройке сетевой оболочки можно увеличить это значение до 150. Пример использования функции IPXOpenSocket (для языка Си): unsigned int NumSock=0x6FE7; ... if (IPXOpenSocket((BYTE*)&NumSock,SHORT_LIVED)==0) cout << "Успешное открытие сокета\n"; ... Интерфейс функции IPXOpenSocket в библиотеке NetWare C Interface, адаптированной для языка Паскаль, определяется таким образом: function IPXOpenSocket (var SocketNumber : Word; SocketType : Byte ) : Word; Низкоуровневый интерфейс функции IPXOpenSocket определяется следующим образом: На входе: BX=00h. AL= Тип сокета (см.выше). DX= Запрашиваемый номер сокета или 0000h, если требуется получить динамический номер сокета. Примечание: Байты номера сокета находятся в перевернутом виде (младшийстарший). На выходе: AL= Код завершения (см.выше). DX =Присвоенный номер сокета. Функция IPXCloseSocket

30

Данная функция закрывает сокет IPX. Интерфейс функции для открытия сокета определен в библиотеке функций NetWare C Interface следующим образом: void IPXCloseSocket(WORD socketNumber); Параметры: socketNumber - указатель на двухбайтовый массив, содержащий значение закрываемого сокета. Данная функция отменяет также все события, определенные блоками ECB, связанные с этим сокетом. Функцию IPXCloseSocket нельзя вызывать из программы ESR. Интерфейс функции IPXCloseSocket в библиотеке NetWare C Interface, адаптированной для языка Паскаль, определяется таким образом: procedure IPXCloseSocket(Socket : Word); Низкоуровневый интерфейс функции IPXCloseSocket определяется следующим образом: На входе: BX=01h. DX= Номер закрываемого сокета. На выходе: Регистры не используются. Методические указания При выполнении лабораторных работ, связанных с протоколом IPX, необходимо загрузить резидентный драйвер протокола IPX ipxodi.com или ipx.com (загружается автоматически при работе с сетевой операционной системой Novell NetWare). При выполнении лабораторных работ рекомендуется использовать библиотеку NetWare C Interface, что упрощает программирование задач. Данная библиотека ориентирована на создание сетевых приложений на языке Си (Си++). Имеется версия библиотеки NetWare C Interface, адаптированная для языка Паскаль. При работе с языком Си (Си++) программный интерфейс пользователя (API) данной библиотеки для работы с коммуникаци-

31

онными функциями протоколов IPX и SPX определен в заголовочном файле nxt.h. В этом файле определены прототипы соответствующих функций и основные структуры данных. Пðè рàáîòå ñ яçûêîì Сè â пðîãðàììó неîáõîäèìî дîáàâèòü слåäóþùóþ сòðîêó: #include Дëÿ вîçìîæíîñòè вêëþ÷åíèÿ зàãîëîâî÷íûõ фàéëîâ бèáëèîòåêè NetWare C Interface кîìïèëÿòîðó сëåäóåò уêàçàòü пîëíîå иìÿ кàòàëîãà, гäå оíè нàõîäÿòñÿ (уñòàíàâëèâàåòñÿ â оïöèÿõ кîìïèëÿòîðà, иñïîëüçóÿ пóíêò мåíþ Directories). Еñëè пðîãðàììà сîñòàâëÿåòñÿ нà яçûêå пðîãðàììèðîâàíèÿ Cи++, тî кîììóíèêàöèîííûå фóíêöèè дîëæíû бûòü оïèñàíû кàê вíåøíèå, иñïîëüçóþùèå сîãëàøåíèÿ об иìåíàõ è пåðåäà÷å пàðàìåòðîâ â сòàíäàðòå Сè, нàïðèìåð: extern "C" int IPXOpenSocket(unsigned char*, unsigned char); Еñëè нåîáõîäèìî, чòîáû пîäîáíûì оáðàçîì бûëè оïèñàíû вñå кîììóíèêàöèîííûå фóíêöèè, оïðåäåëåííûå â зàãîëîâî÷íîì фàéëå nxt.h, тî нåîáõîäèìî â пðîãðàììó нà яçûêå Ñи++ дîáàâèòü сëåäóþùèå сòðîêè: extern "C" { #include } Пðè рàáîòå ñ бèáëèîòåêîé NetWare C Interface нóæíî иñïîëüçîâàòü мîäåëü пàìÿòè Large (уñòàíàâëèâàåòñÿ â оïöèÿõ кîìïèëÿòîðà, иñïîëüçóÿ пóíêò мåíþ Code Generation). Нà сòàäèè рåäàêòèðîâàíèÿ сâÿçåé (лèíêîâêå) тðåáóåòñÿ пîäêëþ÷àòü бèáëèîòå÷íûé фàéë lnit.lib. Пðè рàçðàáîòêå Сè- (Ñè++-) пðîãðàìì рåêîìåíäóåòñÿ иñïîëüçîâàòü мåõàíèçì пðîåêòîâ. Пðè эòîì â пðîåêò вêëþ÷àþòñÿ иñõîäíûå тåêñòû пðîãðàìì è бèáëèîòå÷íûé фàéë lnit.lib. Пðè оòñóòñòâèè бèáëèîòåêè NetWare C Interface мîæíî рàáîòàòü с протоколом IPX, используя низкоуровневый интерфейс. В этом случае с использованием прерывания INT 2Fh необходимо определить адрес точки входа для вызова API драйвера IPX. Для вызова API в регистр BX необходимо загрузить код выполняемой

32

функции. Значения, загружаемые в другие регистру, зависят от выполняемой функции. Все функции и основные структуры данных для работы с протоколом IPX при использовании библиотеки NetWare C Interface, адаптированной для языка Паскаль, описаны в системных модулях ipxspx.pas и nwtypes.pas. Им соответствуют объектные модули ipxspx.tpu и nwtypes.tpu. Данные модули должны быть включены в Паскаль-программу (в начало) директивой uses ipxspx,nwtypes; При использовании библиотеки NetWare C Interface ïåред работой с функциями открытия и закрытия сокетов необходимо произвести инициализацию драйвера IPX с использованием функции IPXInitialize. Разрабатываемая в лабораторной работе программа должна открывать определенный заданием сокет, а затем его закрывать. При вызове функции IPXOpenSocket необходимо анализировать результат ее выполнения и выдавать соответствующее диагностическое сообщение. Для кодировки шестнадцатеричных констант в языке Borland Pascal используется символ $, стоящий перед числом, например, $6FE4. Варианты заданий Номер варианта

Номер сокета

Тип сокета

1

6FE0

Короткоживущий

2

6FE1

Долгоживущий

3

6FE2

Короткоживущий

4

6FE3

Долгоживущий

5

6FE4

Короткоживущий

6

6FE5

Долгоживущий

7

6FE6

Короткоживущий

8

6FE7

Долгоживущий

33

Лабораторная работа N 4 ПРИЕМ И ПЕРЕДАЧА ДЕЙТАГРАММ В ЛОКАЛЬНОЙ ВЫЧИСЛИТЕЛЬНОЙ СЕТИ С ИСПОЛЬЗОВАНИЕМ ПРОТОКОЛА IPX Цель работы: изучить функции IPXSendPacket и IPXListenForPacket для передачи и приема дейтаграмм, приобрести навыки использования данных функций при разработке сетевых приложений. Порядок выполнения работы 1. Изучить структуру пакета IPX, структуру заголовка пакета, структуру сетевого адреса. 2. Изучить структуру блока управления событием (блока ECB), структуру дескриптора фрагмента пакета. 3. Изучить правила организации и оформления подпрограмм обработки события (ESR-подпрограмм). 4. Изучить программный интерфейс функций IPXSendPacket и IPXListenForPacket; 5. Разработать на языке программирования высокого уровня (Паскаль, Си или Си++) программы: а) для посылки пакета; б) для приема пакета. 6. Произвести эксперимент, заключающийся в посылке пакета из одной станции и приема его на другой станции в ЛВС Ethernet. 7.Оформить отчет о проделанной работе.

Основные сведения

34

Дейтаграммный способ передачи данных − это передача данных как отдельных, не связанных между собой пакетов − дейтаграмм (datagram). При дейтаграммном способе не гарантируется ни очередность поступления пакетов получателю, ни надежность доставки пакетов. При этом передающая сторона не знает, получила ли принимающая сторона пакет или не получила. Дейтаграммный способ позволяет передавать данные без предварительных процедур установления соединений. Одно из преимуществ уровня дейтаграмм - возможность посылки пакетов данных одновременно всем станциям сети. Дейтаграммный способ передачи данных на сетевом уровне в ЛВС является основой протокола IPX, используемом в сетевом программном обеспечении Novell. Ниже представлены форматы данных и некоторые функции протокола IPX, используемые при передаче IPX-пакетов. Общий формат пакета IPX 1) заголовок пакета (30 байт); 2) передаваемые данные (0 - 546 байт). Формат заголовка пакета 1) checkSum - контрольная сумма (2 байта); 2) length - общая длина пакета (2 байта); 3) transportControl - счетчик пройденных мостов (1 байт); 4) packetType - тип пакета (1 байт); 5) destination - сетевой IPX-адрес получателя пакета (12 байт); 6) source - сетевой IPX-адрес отправителя пакета (12 байт).

35

Прикладная программа должна установить поля packetType и destination. IPX устанавливает другие поля. Пользователи IPX должны установить поле packetType как 0 или как 4. Формат IPX-адреса 1) network - номер сети (4 байта); 2) node- адрес станции в сети (6 байт); 3) socket - номер сокета (2 байта). Адресация в сети Номер сети кодирует одну из сетей Ethernet или один из сегментов сети. Если сеть содержит мосты, то каждая сеть, подключенная через мост, должна иметь свой уникальный номер. В качестве адреса сети-получателя могут использоваться: • адрес из всех нулей, обозначающий ту же сеть, что и у станцииотправителя; • широковещательный адрес, состоящий из всех единиц, обозначает все подключенные сети; • конкретный адрес одной из сетей. Адрес станции уникален для всех станций сети. В качестве адреса станции-получателя можно использовать: • широковещательный адрес, состоящий из всех единиц, обозначающий все станции (FFFFFFFFFFFFh); • индивидуальный адрес станции, начинающийся с нуля; • групповой адрес, он начинается с единицы и идентифицирует сразу несколько станций. Формат блока ECB

36

1) linkAddress - указатель на следующий ECB (4 байта); 2) ESRAddress - адрес программы ESR в основной памяти (ОП ) (4 байта), [s,r,t]; 3) inUseFlag - флаг состояния ECB (1 байт); 4) completionCode - код завершения запроса (1 байт); 5) socketNumber - сокет для приема или передачи (2 байта), [s,r]; 6) IPXWorkspace - рабочий буфер для IPX (4 байта); 7) driverWorkspace - рабочий буфер для драйвера адаптера (12 байт); 8) immediateAddress - адрес станции для передачи пакета (6 байт), [s]; 9) fragmentCount - количество фрагментов в пакете (2 байта), [s,r]; 10) fragmentDescriptor1 - дескриптор первого фрагмента пакета (6 байт), [s,r]; 11) fragmentDescriptor2 - дескриптор второго фрагмента пакета (6 байт), [s,r]; ... Формат дескриптора фрагмента 1) address - адрес фрагмента в ОП (4 байта); 2) size - размер фрагмента (2 байта). Блок ECB состоит из фиксированной части размером 36 байт и массива дескрипторов, описывающих отдельные фрагменты передаваемого или принимаемого пакета данных. В приведенных выше комментариях, заключенных в квадратные скобки, символ "s" обозначает поля, которые должна уста-

37

новить прикладная программа при использовании блока ECB для отправки пакета, символ "r" - при получении пакета, cимвол "t" для планирования события по часам (времени). Поле ESRAddress содержит полный адрес программного модуля (в формате [сегмент:смещение]), который получает управление при завершении процесса приема или передачи пакета IPX. Этот модуль называется программой обслуживания события ESR (Event Service Routine). Если программа не использует ESR, она должна записать в поле ESRAddress нулевое значение. Поле inUseFlag может служить индикатором совершения события (окончание приема или передачи пакета, а также истечение времени тайм-аута). Перед тем, как вызвать функцию IPX, программа записывает в поле inUseFlag нулевое значение. Пока операция передачи данных, связанная с данным ECB, не завершилась, поле inUseFlag содержит ненулевые значения: FFh - ECB используется для передачи пакета данных; FEh - ECB используется для приема пакета данных, предназначенного программе с определенным сокетом; FDh - ECB используется функциями асинхронного управления ñîáûòèÿìè AES (Asynchronous Event Scheduler), ECB находится в состоянии ожидания истечения заданного временного интервала; FBh - ïàêåò данных принят или передан, но ECB находится во внутренней очереди IPX в ожидании завершения обработки. Программа может постоянно опрашивать поле inUseFlag, ожидая завершения процесса передачи или приема данных. Как только в этом поле окажется нулевое значение, программа может считать, что совершаемая функция выполнена. Результат выполнения можно получить в поле completionCode. Поле immediateAddress содержит адрес станции, которой отправляется пакет, или станции, от которой он получается. Если пакет не получен от станции и не отправлен станции в местной сети, то этим адресом будет адрес межсетевого моста в местной сети.

38

Поле fragmentCount обозначает количество буферов, из которых будет построен исходящий (отправляемый) пакет, или на которые будет разбит принимаемый пакет. Первый дескриптор фрагмента (fragmentDescriptor1) должен описывать буфер достаточно большого размера для помещения туда, по меньшей мере, заголовка пакета, т.е. для пакетов IPX, первый дескриптор фрагмента должен определять буфер длиной (размером) по меньшей мере 30 байт. Прикладная программа может использовать ту же самую структуру ECB для управления событиями, запланированными посредством AES (aсинхронного планировщика событий). Функция IPXListenForPacket Функция IPXListenForPacket предназначена для инициирования процесса приема пакетов из сети. Она передает драйверу IPX подготовленный блок ECB, и тот включает его в свой внутренний список блоков ECB, ожидающих приема пакетов. Одновременно программа может подготовить несколько блоков ECB и для каждого вызвать функцию IPXListenForPacket. Данная функция сразу возвращает управление вызвавшей ее программе, не дожидаясь прихода пакета. Определить момент приема пакета программа может либо анализируя поле inUseFlag блока ECB, либо указав перед вызовом функции адрес программы ESR (в блоке ECB), которая получит управление сразу после прихода пакета. Если программа подготовила для приема пакетов несколько блоков ECB, то для приема пришедшего пакета будет использован один из подготовленных ECB. Однако не гарантируется, что блоки ECB будут использоваться в том порядке, в котором они ставятся на ожидание приема функцией IPXListenForPacket. Если свободных, ожидающих приема пакета, блоков ECB нет, то приходящий пакет будет проигнорирован.

39

После прихода пакета в поле immediateAddress драйвер IPX записывает непосредственный адрес станции, из которой пришел пакет. После приема пакета в поле completionCode могут находиться следующие значения: 00 - пакет принят без ошибок; FFh - указанный в ECB сокет не был предварительно открыт программой; FDh - переполнение пакета: либо количество фрагментов в пакете fragmentCount равно нулю, либо буферы, описанные дескрипторами фрагментов, имеют недостаточный размер для записи принятого пакета; FCh - запрос на прием данного пакета был отменен специальной функцией IPX. Интерфейс функции для приема пакета определен в библиотеке функций NetWare C Interface следующим образом: void IPXListenForPacket(ECB *eventControlBlock); Параметры: eventControlBlock - указатель на блок ECB. Интерфейс той же функции в той же библиотеке, но адаптированной для языка Паскаль, определяется таким образом: procedure IPXListenForPacket (var theECB); Параметры: theECB - блок ECB. Низкоуровневый интерфейс функции IPXListenForPacket определяется следующим образом: На входе: BX = 04h; ES:SI = Указатель на заполненный блок ECB. На выходе: Регистры не используются Функция IPXSendPacket

40

Функция IPXSendPacket подготавливает блок ECB и связанный с ним заголовок пакета для передачи пакета по сети. Она сразу возвращает управление вызвавшей ее программе, не дожидаясь завершения процесса передачи пакета. Определить момент завершения передачи пакета программа может либо анализируя поле inUseFlag блока ECB, либо указав перед вызовом функции адрес программы ESR (в блоке ECB), которая получит управление сразу после завершения процесса передачи пакета. Перед вызовом функции IPXSendPacket необходимо заполнить соответствующие поля блока ECB, подготовить заголовок пакета, заполнив поля packetType, destination.network, destination.node, destination.socket, а также сам передаваемый пакет. Пакет будет передан на станцию, адрес которой указан в поле immediateAddress. Если в этом поле указан адрес моста, пакет будет передан через мост в другую сеть. Результат выполнения передачи пакета можно узнать, проанализировав поле completionCode: 00 - пакет был передан без ошибок; FFh - пакет невозможно передать физически из-за неисправности в сетевом адаптере или в сети; FEh - пакет невозможно доставить по назначению, так как станция с óêàçàííûì адресом не существует или неисправна; FDh - cбойный: либо имеет длину меньше 30 байт, либо первый фрагмент ïàêåòà по размеру меньше размера стандартного заголовка пакета IPX, либо поле количества фрагментов в пакете fragmentCount равно нулю; FCh - запрос на передачу данного пакета был отменен специальной функцией IPX. Интерфейс функции для передачи пакета определен в библиотеке функций NetWare C Interface следующим образом: void IPXSendPacket(ECB *eventControlBlock); Параметры: eventControlBlock - указатель на блок ECB. Интерфейс той же функции в той же библиотеке, но адаптированной для языка Паскаль, определяется таким образом:

41

procedure IPXSendPacket(var theECB); Параметры: theECB - блок ECB. Низкоуровневый интерфейс функции IPXSendPacket определяется следующим образом: На входе: BX=03h; ES:SI = Указатель на заполненный блок ECB. На выходе: Регистры не используются. Функция IPXGetInternetworkAddress С помощью этой функции программа может узнать сетевой адрес станции, на которой она сама работает. Интерфейс данной функции определен в библиотеке функций NetWare C Interface следующим образом: void IPXGetInternetworkAddress(BYTE *networkAddress); Параметры: networkAddress - указатель на 10-байтовый адрес в сети. Эти 10 байт организованы следующим образом: байты 0-3 номер сети, байты 4-9 - номер узла. Интерфейс той же функции в той же библиотеке, но адаптированной для языка Паскаль, определяется таким образом: procedure IPXGetInternetworkAddress(var IPX10byteAddress); Параметры: IPX10byteAddress - 10-байтовый адрес в сети. Низкоуровневый интерфейс функции IPXGetInternetworkAddress определяется следующим образом: На входе: BX = 09h; ES:SI = Указатель на буфер длиной 10 байт, в который будет записан адрес станции, на которой работает данная программа. На выходе: Регистры не используются. Методические указания

42

Для приема и передачи пакетов разрабатываются две отдельные программы. Перед началом приема или передачи пакетов необходимо произвести инициализацию драйвера протокола IPX, открыть необходимые сокеты, заполнить необходимые поля блока ECB и заголовка пакета IPX. После окончания работы программы необходимо закрыть сокеты. Посланное и принятое сообщения должны быть распечатаны. Рекомендуется передавать символьные данные. Для определения адреса области оперативной памяти (ОП) для приема или передачи при использовании языка Borland Pascal необходимо использовать функцию addr (справочную информацию о функциях можно получить подводя курсор к ключевому слову, определяющему функцию, и нажимая комбинацию клавиш Ctrl-F1). На каждом законченном шаге выполнения программы должны выдаваться диагностические сообщения. При использовании языка Borland Pascal блок ECB должен передаваться в процедуру пользователя с описателем var, например: procedure Send(var myECB, ... ); Для использования возможности асинхронной обработки событий необходимо написать соответствующие ESR-программы. Пример ESR-программы на языке Си: void far procESR(void) { asm mov ax,seg Count; // Установка asm mov ds,ax; // регистра DS IPXScheduleIPXEvent(180,tECB); // Перезапуск тайм-аута Count++; // Увеличение счетчика на единицу} При этом адрес кода этой функции следует записать в поле ESRAddress соответствующего блока ECB, например: tECB.ECRAddress=procESR; Для установки регистра сегмента данных можно воспользоваться описателем функции _loadds. При этом приведенная выше ESR-программа может быть сведена к следующему виду: void far _loadds procESR(void)

43

{ IPXScheduleIPXEvent(180,tECB); // Перезапуск тайм-аута Count++; // Увеличение счетчика на единицу} Ниже в качестве примера приводятся алгоритмы процедур приема и передачи дейтаграммы с использованием опросов флагов. Используемые переменные: rECB - блок ECB для приема, sECB блок ECB для передачи, IPXHeader - заголовок пакета IPX.

Алгоритм процедуры приема дейтаграммы Инициализация драйвера IPX (функция IPXInitialize) Открытие сокета для приема (функция IPXOpenSocket) Подготовка rECB для приема (заполнение полей rECB): rECB.ESRAddress := <нулевое значение>; rECB.socketNumber := <номер принимающего сокета> rECB.fragmentCount := 2; -- Число фрагментов rECB.fragmentDescriptor[0].address := <адрес IPX-заголовка в ОП> rECB.fragmentDescriptor[0].size := 30; -- Размер IPX-заголовка rECB.fragmentDescriptor[1].address := <начальный адрес, начиная с которого будет записываться принятое сообщение в ОП> ECB.fragmentDescriptor[1].size := <размер принимаемого сообщения> Постановка rECB в очередь на прием пакета (функция IPXListenForPacket) Ожидание прихода пакета (опрос флага rECB.inUseFlag) Закрытие сокета для приема (функция IPXCloseSocket)

44

Алгоритм процедуры передачи дейтаграммы Инициализация драйвера IPX (функция IPXInitialize) Подготовка заголовка пакета IPX (заполнение полей): IPXHeader.packetType := 00h; -- Тип пакета Для i := 0 до 3 Делать IPXHeader.destination.network[i] := 00h; Для i := 0 до 5 Делать IPXHeader.destination.node[i] := <байт сетевого адреса узла-приемника> IPXHeader.destination.socket[0] := <младший байт номера сокета> IPXHeader.destination.socket[1] := <старший байт номера сокета> Подготовка sECB для передачи (заполнение полей sECB): sECB.ESRAddress := <нулевое значение>; sECB.socketNumber := <номер сокета узла-источника> Для i := 0 до 5 Делать sECB.immediateAddress[i] := <байт сетевого адреса узла-приемника> sECB.fragmentCount := 2; -- Число фрагментов sECB.fragmentDescriptor[0].address := <адрес IPX-заголовка в ОП> sECB.fragmentDescriptor[0].size := 30; sECB.fragmentDescriptor[1].address := <адрес передаваемого сообщения в ОП> sECB.fragmentDescriptor[1].size := <размер сообщения в байтах >

45

Постановка sECB в очередь на передачу пакета (функция IPXSendPacket) Ожидание окончания передачи пакета (опрос флага sECB.inUseFlag) Адресация в учебных лабораториях В лаборатории 7-301 (кафедра ВТ) адрес узла определяется как 0200000xxxyy, где ххх - номер аудитории (301), yy - номер машины в аудитории (число в диапазоне от 1 до 11 в шестнадцатеричном формате). Пример задания сетевого адреса 020000030111 на языке Паскаль: node[0] := $02; node[1] := $00; node[2] := $00; node[3] := $03; node[4] := $01; node[5] := $11; В лаборатории 7-216 (ВЦ) распределение сетевых адресов определено ниже: Номер ПЭВМ

Инвентарный номер

Сетевой адрес

1

13406468

00 60 52 03 25 EF

2

13406467

00 60 52 03 20 D1

3

13406000

00 60 52 03 20 B3

4

13406448

00 60 52 03 25 F8

5

13406449

00 60 52 03 25 F6

6

13406450

00 60 52 03 21 68

7

13406447

00 60 52 03 25 F3

8

13406445

00 60 52 03 20 B5

9

13406446

00 60 52 03 20 E9

Для уточнения сетевых адресов станций можно воспользоваться функцией IPXGetInternetworkAddress.

46

Варианты заданий Номер варианта

Íîìåð ñîêåòà äëÿ ïðèåìà

Íîìåð ñîêåòà äëÿ ïåðåäà÷è

Ñïîñîá êîíòðîëÿ ñîáûòèé Опрос

1

6FE1

6FE5

2

6FE0

6FEE

ESR

3

6FE9

6FE1

Опрос

4

6FE7

6FEA

ESR

5

6FEG

6FEB

Опрос

6

6FE8

6FEC

ESR

7

6FE1

6FE4

Опрос

8

6FED

6FE3

ESR

Лабораторная работа N 5 РЕАЛИЗАЦИЯ МЕХАНИЗМА ТАЙМ-АУТОВ С ИСПОЛЬЗОВАНИЕМ ПРОТОКОЛА IPX Цель работы: изучить функции IPXScheduleIPXEvent и IPXCancelEvent протокола IPX для планирования и отмены событий, приобрести навыки использования данных функций при разработке сетевых приложений (для реализации механизмов таймаутов коммуникационных протоколов). Порядок выполнения работы 1. Изучить программный интерфейс функций IPXScheduleIPXEvent ПЛАНИРОВАТЬ СОБЫТИЕ и IPXCancelEvent - ОТМЕНИТЬ СОБЫТИЕ. 2. Изучить структуру блока управления событием (блока ECB).

47

3. Разработать на языке программирования высокого уровня (Паскаль, Си или Си++) программы: а) для планирования тайм-аута через определенный интервал времени; б) для планирования тайм-аута и его отмены. 4. Произвести эксперимент, заключающийся в планировании тайм-аута и его отмене. 5. Оформить отчет о проделанной работе. Основные сведения Тайм-аут - это ситуация, имеющая место в том случае, когда какой-то процесс ожидает либо наступления какого-нибудь внешнего события, либо окончания предварительно заданного интервала времени, и период ожидания истекает раньше, чем это внешнее событие произойдет. Например, если процесс пересылает сообщение и не обнаруживает до конца предварительно установленного интервала времени никакого подтверждения приема, то он может предпринять соответствующие меры, такие, как повторение передачи сообщения. В глагольной форме этот английский термин (timeout) означает "превышать лимит времени". (см. Толковый словарь по вычислительным системам / Под ред. В.Иллингуорта,Э.Л.Глейзера, И.К.Пайла. - М.:Машиностроение, 1991. - 560 с.) Механизм тайм-аутов заключается в определении предельных временных интервалов ожидания какого-либо события и назначения определенных действий при истечении этого интервала, например, вызова процедур восстановления. Механизм тайм-аутов является одним из основных при восстановлении после ошибок в коммуникационных протоколах. Под временем тайм-аута (иногда называемым просто таймаутом) будем понимать временной интервал, на протяжении которого система будет ожидать совершения какого-либо события.

48

Ожидание системы может быть завершено двумя путями: либо в результате истечения времени тайм-аута (естественное окончание), либо путем отмены ожидания (принудительное окончание). Для реализации механизма тайм-аутов в протоколе IPX определены следующие функции: IPXScheduleIPXEvent и IPXCancelEvent. Функция IPXScheduleIPXEvent Данная функция планирует событие IPX. Интерфейс функции IPXScheduleIPXEvent определен в библиотеке функций NetWare C Interface следующим образом: void IPXScheduleIPXEvent(WORD timeUnits, ECB *eventControlBlock); Параметры: timeUnits - интервал времени; eventControlBlock - указатель на блок ECB. Функция IPXScheduleIPXEvent передает драйверу протокола IPX время задержки и адрес блока ECB для планирования события, определяющего тайм-аут. Затем функция возвращает управление вызывающей прикладной программе. В это время IPX пытается спланировать событие. Параметр timeDelay определяет время ожидания (в шагах таймера) до того, как произойдет запланированное событие. Он должен быть установлен в диапазоне от 0 до 65535 (0000h и FFFFh). Каждый интервал представляет собой один шаг таймера IBM PC, который приблизительно равен 1/18 части секунды. Это позволяет планировать событие вперед до одного часа. Прикладная программа может вызывать данную функцию для перепланирования блока ECB, предварительно подвергнувшегося планированию. Это единственная ситуация, в которой допустимо передавать IPX (AES) блок ECB, который все еще используется. Поле InUseFlag устанавливается как величина (FDh), в то время как AES (Асинхронный планировщик событий) управляет IPXECB. Подпрограмма ESR также может вызывать эту функцию.

49

Прикладная программа никогда не должна использовать данную функцию для передачи адреса блока ECB, который используется IPX в это время для работы с пакетами. Интерфейс функции IPXScheduleIPXEvent в библиотеке NetWare C Interface, адаптированной для языка Паскаль, определяется таким образом: procedure IPXScheduleIPXEvent(timeDelay:Word; var theECB); Низкоуровневый интерфейс функции IPXScheduleIPXEvent определяется следующим образом: Íà âõîäå: BX = 05h AX = Âðåìÿ çàäåðæêè â òèêàõ òàéìåðà; ES:SI = Óêàçàòåëü íà áëîê ECB. Íà âûõîäå: Ðåãèñòðû íå èñïîëüçóþòñÿ

Функция IPXCancelEvent Данная функция отменяет событие, определенное блоком ECB. Интерфейс функции IPXCancelEvent определен в библиотеке функций NetWare C Interface следующим образом: int IPXCancelEvent(ECB *eventControlBlock); Параметры: eventControlBlock - указатель на блок ECB. Возвращаемые значения: 00h - успешное выполнение: F9h - ECB не может быть отменен; FCh - событие отменено; FFh - ECB не используется.

50

Отменяемый блок ECB может контролировать такие действия, как отправка или ожидание пакета, планирование или перепланирование. Интерфейс функции IPXCancelEvent в библиотеке NetWare C Interface, адаптированной для языка Паскаль, определяется таким образом: function IPXCancelEvent(var theECB): Word; Низкоуровневый интерфейс функции IPXCancelEvent определяется следующим образом: На входе: BX = 06h; ES:SI = Указатель на блок ECB На выходе: AL = Код завершения.

Методические указания Необходимо разработать две программы. Первая программа организует тайм-аут, запускает его и после окончания тайм-аута выводит диагностическое сообщение об его окончании. Вторая программа строится на основе первой. Она организует тайм-аут, запускает его с возможностью отмены тайм-аута при нажатии какой-либо клавиши (см. функции keypressed и readkey языка Borland Pascal, а также функции kbhit и getch языка Borland C). Должны выводиться сообщения о естественном или принудительном окончании тайм-аута. Перед работой с функциями IPXScheduleIPXEvent и IPXCancelEvent необходимо заполнить соответствующие поля блока ECB. При работе с библиотекой NetWare C Interface при организации тайм-аутов рекомендуется заполнять также поле SocketNumber блока ECB. При этом сокет SocketNumber должен быть открыт с использованием функции IPXOpenSocket.

51

Варианты заданий Номер варианта

Дëèòåëüíîñòü тàéìàóòà, сåê

Кëàâèøà дëÿ оòìåíû тàéìàóòà

1

3.0

F1

2

5.5

F2

3

4.4

F3

4

4.0

F4

5

5.1

F5

6

3.5

F6

7

3.9

F7

8

3.9

Esc

Лабораторная работа N 6 РАЗРАБОТКА ПРОЦЕДУР ПЕРЕДАЧИ ДАННЫХ В ЛВС С ИСПОЛЬЗОВАНИЕМ МЕХАНИЗМА КВИТИРОВАНИЯ И ТАЙМ-АУТОВ Цель работы: изучить методы передачи данных и механизмы восстановления после ошибок при передаче данных, приобрести навыков разработки и программирования процедур передачи данных и реализации коммуникационных протоколов. Порядок выполнения работы 1. Изучить механизмы восстановления после ошибок при передаче данных (механизм квитирования и механизм тайм-аутов). 2. Разработать на языке программирования высокого уровня (Паскаль, Си или Си++) программы звена передачи данных между

52

двумя станциями ЛВС: программу передачи и программу приема сообщения. 3. Произвести эксперимент, заключающийся в посылке сообщения из одной станции и приема его на другой станции в ЛВС Ethernet в случаях, когда вторая станция включена и когда выключена. 4. Оформить отчет о проделанной работе.

Основные сведения Среда передачи сообщений в вычислительных сетях ненадежна. При этом возможны следующие ошибки: потеря сообщения, искажение сообщения. Механизмы квитирования и тайм-аутов являются основой надежного обмена информацией в вычислительных сетях и используются для восстановления работы после ошибок. Различается передача данных между объектами с квитированием и без квитирования. При передаче данных с квитированием на каждое переданное объектом-отправителем (передатчиком) сообщение при его приеме на стороне объекта-получателя (приемника) в противоположную сторону посылается подтверждение (acknowledgement), называемое также квитанцией. Квитирование используется для достижения следующих целей: 1) для согласования скоростей работы отправителя и получателя. Получатель посылает подтверждение только в том случае, когда он готов принять новое сообщение. В этом случае темп передачи определяется получателем − задерживая отправку квитанции, он задерживает посылку нового сообщения. 2) для осведомления получателя о состоянии полученного сообщения. Например, если сообщение принято без ошибок, посы-

53

лается положительная квитанция (positive acknowledgement ACK+), а если с ошибками - отрицательная квитанция (negative acknowledgement -ACK-). Механизм тайм-аутов при передаче сообщений заключается в определении предельных временных интервалов ожидания приема квитанций и назначения определенных действий при истечении этого интервала, сводящихся, как правило, к запуску процедуры повторной передачи сообщений. Методические указания При разработке сетевых приложений следует разработать, вопервых, данные, в частности, определить структуру и формат сообщений, требуемые блоки ECB, способы адресации сетевых объектов, используемые сокеты. Во-вторых, необходимо разработать алгоритмы работы программы, в частности, алгоритмы обработки событий. Основные типы событий: "Прием пакета", "Окончание передачи пакета", "Тайм-аут". Определим структуру сообщений, используемых в процедурах передачи в данной лабораторной работе. Для обмена используются два типа сообщений: информационный пакет и квитанция. Структура информационного пакета: 1) IPX-заголовок; 2) тип сообщения (информационный пакет); 3) данные. Структура квитанции: 1) IPX-заголовок; 2) тип сообщения (квитанция). Структура звена передачи данных представлена на рис. 8.

54

Ï Å ÐÅ Ä À Ò× È Ê

È í ô î ðì àö è î í í û é ï àê åò

Ï ÐÈ Å Ì Í È Ê

Ñ î î áù åí è å

Ñ î î áù åí è å Òàé ì àóòû

Ê âè òàí ö è ÿ

Рис. 8. Звено передачи данных

Для организации звена передачи данных необходимо написать две программы: одну − для посылки информационных пакетов и приема квитанций (программа SENDER - "передатчик"), а другую − для приема информационных пакетов и посылки квитанций (программа RECEIVER "приемник"). Рекомендуется в каждой программе звена передачи данных, как в "передатчике", так и в "приемнике" использовать по два сокета: один для посылки пакетов (socketForSend), а другой − для приема пакетов (socketForReceive) и два блока ECB - один для передачи пакетов (sECB), а другой − для приема пакетов (rECB). Квитанция отсылается обратно по адресу узла, пославшего информационный пакет. Адрес узла-источника можно определить, используя заголовок принятого IPX-пакета или поле immediateAddress приемного блока ECB. Рекомендуется программы SENDER и RECEIVER оформить в виде библиотечных процедур (модулей), что позволит использовать их при выполнении других лабораторных работ и курсового проекта. В ряде вариантов лабораторного задания требуется оставлять в ОП резидентной программу-приемник Для того, чтобы оставить в ОП текущую программу резидентной, можно воспользоваться функцией keep языка Си. Пример использования данной функции: keep(0, (_SS + (_SP/16) - _psp));

55

Ниже в качестве примера приведены интерфейсы и алгоритмы процедур приема и передачи äëÿ ñëучая контроля IPX-событий с использование опроса флагов inUseFlag. Интерфейс процедуры RECEIVER Входные параметры: data_ptr − адрес буфера в ОП, куда помещаются принимаемые данные (тип указателя); data_size − размер буфера; Выходные параметры: sourceAddress − сетевой адрес, откуда пришел информационный пакет; cCode − код завершения (=0 − успешное завершение, ненулевое значение определяет причину неудачи, например, = 1 − некорректные входные параметры и т.д.). Интерфейс процедуры SENDER Входные параметры: destinationAddress − сетевой адрес станции, куда будут отправлены данные; data_ptr − адрес буфера в ОП, из которого передаются данные; data_size − размер передаваемых данных; maxRetran − максимальное число попыток повторных передач информационных пакетов; timeOut − время тайм-аута ( в секундах или тиках таймера); Выходные параметры: cCode − код завершения (=0 − успешное завершение, ненулевое значение определяет причину неудачи, например, = 1 − некор-

56

ректные входные параметры, = 2 − исчерпан лимит повторных передач и т.д.). Алгоритм процедуры RECEIVER Открытие сокета для приема информационного пакета Подготовка rECB для приема информационного пакета (заполнение полей rECB) Постановка rECB в очередь на прием пакета (функция IPXListenForPacket) Ожидание прихода информационного пакета (опрос флага rECB.inUseFlag) Анализ принятого информационного пакета Подготовка пакета-квитанции: Подготовка заголовка пакета IPX Установка признака квитанции Подготовка sECB для посылки квитанции (заполнение полей sECB) Постановка sECB в очередь на посылку квитанции (функция IPXSendPacket) Ожидание окончания посылки квитанции (опрос флага sECB.inUseFlag) Закрытие сокета для приема информационного пакета Алгоритм процедуры SENDER Инициализация переменных Открытие сокета для приема квитанции Подготовка информационного пакета: Подготовка заголовка пакета IPX Установка признака информационного пакета

57

Установка поля данных Подготовка блоков ECB: Подготовка rECB для приема квитанции (заполнение полей rECB) Подготовка sECB для посылки информационного пакета (заполнение полей sECB) Подготовка tECB (заполнение полей tECB) Постановка rECB в очередь на прием квитанции (функция IPXListenForPacket) M1: Постановка sECB в очередь на посылку информационного пакета (функция IPXSendPacket) Ожидание окончания посылки информационного пакета (опрос флага sECB.inUseFlag) Планирование тайм-аута: Постановка tECB в очередь ожидания (функция IPXScheduleIPXEvent) Ожидание тайм-аута или прихода квитанции (опрос флагов rECB.inUseFlag и tECB.inUseFlag) Если возник тайм-аут, то -- Обработка тайм-аута {countTran=countTran+1 Если countTran < maxRetran, то Перейти на М1 -- Повторная передача Иначе -- Исчерпан лимит повторных передач { cCode=2 Отменить rECB (функция IPXCancelEvent) Закрытие сокета для приема квитанции Возврат } } Если обнаружен приход квитанции, то

58

-- Обработка прихода квитанции { Отменить tECB (функция IPXCancelEvent) -- Отменить тайм-аут cCode=0 Закрытие сокета для приема квитанции Возврат } Переменные программы sECB - блок ECB, контролирующий посылку пакетов; rECB - блок ECB, контролирующий прием пакетов; tECB - блок ECB, контролирующий окончание времени тайм-аута (используется для планирования тайм-аутов); countTran - счетчик числа повторных передач информационного пакета. Варианты заданий Номер варианта

Мàêñимальное чèñëî пîïûòîê пîâòîðных пåðåäà÷

Вåëè÷èíà тàéì-àóòà, (сåê)

Сïîñîá кîíòðîëÿ тàéì-àóòà

Сïîñîá кîíòðîëÿ сîáûòèÿ “Пðèåì èíôормационного пàêåòà”

Сïîñîá кîíò-ðîëÿ сîáû-òèÿ “Пðè-åì кâèòàíöè è”

Испол ьзование резидентных программ

1

10

3

Опрос

Опрос

Опрос

Нет

2

6

5

ESR

Опрос

Опрос

Нет

3

7

8

Опрос

ESR

Опрос

Нет

4

3

6

Опрос

Опрос

ESR

Нет

5

6

10

ESR

ESR

Опрос

Да

59

6

4

4.5

ESR

Опрос

ESR

Нет

7

7

4

ESR

Опрос

Опрос

Нет

8

6

5

ESR

ESR

ESR

Да

ДОПОЛНИТЕЛЬНЫЕ ТЕМЫ ЛАБОРАТОРНЫХ И КУРСОВЫХ РАБОТ Ниже приводятся дополнительные темы лабораторных и курсовых работ и соответствующие им краткие исходные данные. В зависимости от уровня сложности и степени подготовленности студентов работа выполняется за 2, 4 или более часов. Дифференцирование на лабораторные и курсовые работы определяется степенью сложности работы, а также требованиями учебного плана, предъявляемыми к данной специальности. Целью представленных работ является системотехническое проектирование РВС на основе ЛВС, назначение которой определяется темой и исходными данными. Отчет по работе должен включать титульный лист, задание, структуру системы, алгоритмы системных взаимодействий, структуру и форматы сообщений, структуры данных на узлах, алгоритмы функционирования узлов, описание программ, результаты тестирования и отладки, листинги программ. Графически представляется структура технических средств ЛВС, составляющая основу РВС. Различие вариантов заключается в различном функциональном назначении узлов системы, также отображаемой в графической части. При необходимости представляется также логическая структура проектируемой системы, которая может существенно отличаться от магистральной структуры технических средств (например, кольцевая структура). При представлении алгоритмов системных взаимодействий следует отразить динамику функционирования проектируемой системы. При этом прежде всего отражаются возможные последо-

60

вательности событий и состояний системы. В качестве событий могут выступать: прием сообщений, истечение времени тайм-аута, действия оператора и др. Возможные формы представления алгоритмов функционирования: текстовое описание, временные последовательности событий, сети Петри и их модификации, блоксхемы алгоритмов и другие формы. Структура сообщения определяет все его поля, а также их функциональное назначение, при необходимости приводится тип данных для каждого поля и кодировка полей. Формат сообщения представляет его структуру, расширенную указанием объема занимаемой каждым полем участка памяти (в байтах или битах). Все приводимые ниже варианты условно разбиты по темам. А. Системы контроля и управления ТЕМА A1. Система централизованного контроля, использующая опрос с перекличкой ИСХОДНЫЕ ДАННЫЕ: система централизованного контроля (СЦК) на базе ЛВС предназначена для контроля центральным узлом процессов, протекающих или управляемых периферийными узлами. Периферийные узлы осуществляют съем с датчиков и хранение информации о контролируемых параметрах в буфер (очередь). Центральный узел поочередно через определенный интервал времени опрашивает периферийные узлы (в соответствии со списком опроса) с целью изъятия находящихся в них информационных сообщений. Собранные сообщения центральный узел сохраняет в собственном буфере, причем с каждым информационным сообщением хранится сетевой адрес узла, откуда поступила информация. Собранная с узлов информация анализируется и сравнивается с предельно допустимыми значениями параметров. На периферийных узлах имитируется работа датчиков. Содержимое буфе-

61

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

ТЕМА A2. Система централизованного контроля, использующая широковещательный опрос ИСХОДНЫЕ ДАННЫЕ: исходные данные почти те же, что и у предыдущего варианта. Отличие заключается в том, что для опроса используется широковещательное сообщение. Не используется механизм тайм-аута для восстановления после ошибок. Центральный узел "удовлетворяется" теми ответными сообщениями, которые пришли. ТЕМА А3. Система централизованного управления, использующая опрос с перекличкой ИСХОДНЫЕ ДАННЫЕ: система централизованного контроля (СЦУ) предназначена для управления процессами, протекающими на периферийных узлах. В структуре СЦУ выделяются два типа узлов - центральный (управляющий) узел и периферийные (управляемые) узлы. Центральный узел поочередно через определенный интервал времени опрашивает периферийные узлы (в соответствии с реестром группы) с целью чтения контролируемых им параметров. На основе анализа собранной с периферийных узлов информации центральный узел вырабатывает определенные управляющие сообщения, которые рассылаются периферийным узлам с использованием реестра группы. Периферийные узлы осуществляют съем с датчиков и хранение информации о контролируемых параметрах в буфер. Работа датчиков имитируется на периферийных узлах. Текущие состояния узлов и сообщения отображаются на экранах мониторов.

62

ТЕМА А4. Система централизованного контроля, использующая для опроса петлевой канал ИСХОДНЫЕ ДАННЫЕ: система централизованного контроля (СЦК) на базе ЛВС предназначена для контроля центральным узлом процессов, протекающих или управляемых периферийными узлами. СЦК использует опрос с использованием "петли". В петлевом канале все узлы соединены друг с другом в кольцо, но один из них (центральный) управляет остальными (периферийными). Периферийные узлы осуществляют съем с датчиков и хранение информации о контролируемых параметрах в буфере. Центральный узел через определенный интервал времени посылает по кольцу опросное сообщение с целью съема информации с периферийных узлов. Собранные сообщения центральный узел сохраняет в собственном буфере, причем с каждым информационным сообщением хранится сетевой адрес узла, откуда поступила информация. Собранная с узлов информация анализируется и сравнивается с предельно допустимыми значениями параметров. На периферийных узлах имитируется работа датчиков. Содержимое буферов центрального и периферийного узлов, а также результаты контроля выводятся на экран монитора. Опросное сообщение (ОС) с центрального узла передается по логическому кольцу, образованному узлами системы. При приеме ОС периферийный узел помещает в него значение контролируемого этим узлом параметра и передает ОС следующему по порядку узлу кольца. При возврате ОС центральному узлу цикл опроса считается завершенным. В. Системы анализа функционирования ЛВС ТЕМА В1. Генератор нагрузки ЛВС

63

ИСХОДНЫЕ ДАННЫЕ: генератор нагрузки ЛВС является составной частью системы анализа функционирования ЛВС. Функции генератора: генерация пакетов с заданным интервалом и законом распределения, сбор статистики об интервале ожидания передачи пакета в моноканал. Входные параметры: тип закона распределения межпакетного интервала (постоянный, равномерный, экспоненциальный и т.д.), параметры закона распределения, номер сокета, сетевой адрес узла-приемника, параметры таблицы статистики о межпакетном интервале (нижняя граница первого частотного интервала, ширина частотного интервала, число интервалов). Выходные параметры: числовые статистические характеристики интервала ожидания передачи пакета в моноканал, а именно: статистическое (выборочное) среднее, статистическая (выборочная) дисперсия, таблица статистики, определяющая число попаданий в каждый частотный интервал. На основе таблицы статистики должна строиться гистограмма.

ТЕМА В2. Анализатор последовательности пакетов ЛВС ИСХОДНЫЕ ДАННЫЕ: анализатор последовательности пакетов ЛВС является составной частью системы анализа функционирования ЛВС. Функции анализатора: прием пакетов, статистический анализ интервалов между поступлениями пакетов из ЛВС. Входные параметры: номер принимающего сокета, параметры таблицы статистики о межпакетном интервале (нижняя граница первого частотного интервала, ширина частотного интервала, число интервалов).

64

Выходные параметры: числовые статистические характеристики межпакетного интервала, а именно: статистическое (выборочное) среднее, статистическая (выборочная) дисперсия, таблица статистики, определяющая число попаданий в каждый частотный интервал. На основе таблицы статистики должна строиться гистограмма. С. Системы "клиент-сервер" ТЕМА С1. Система "клиент-сервер" для выполнения арифметических операций ИСХОДНЫЕ ДАННЫЕ: система состоит из узлов двух типов: "сервера" и "клиентов". "Клиент" формирует задание для удаленного выполнения на "сервере". "Сервер" выполняет задание и посылает результат выполнения обратно "клиенту", пославшему задание. Структура запросов к серверу определяется с помощью расширенных форм Бэкуса-Наура (РБНФ) следующим образом: <запрос>::=<функция><параметр 1><параметр 2> <функция>::= + | - | * | / <параметр 1>::= <число> <параметр 2>::= <число> Функции сервера: прием заданий; управление входной очередью заданий: постановка в очередь, выборка из очереди, очистка очереди; решение задания клиента; управление выходной очередью результатов: постановка результатов в очередь, выборка результатов из очереди, очистка очереди. ТЕМА С2. Система "клиент-сервер" для вычисления

65

статистических характеристик ИСХОДНЫЕ ДАННЫЕ: вычисляются статистическое (выборочное) среднее и статистическая (выборочная) дисперсия. Объем выборки задается преподавателем. Структура запросов к серверу определяется с помощью РБНФ следующим образом: <запрос>::= <функция>{<параметр>} <функция>::= статистическое_среднее | статистическая_дисперсия <параметр>::= <число> (см. также тему С1).

ТЕМА С3. Система "клиент-сервер" для работы с удаленными базами данных ИСХОДНЫЕ ДАННЫЕ: на сервере находится база данных (БД) о студентах, состоящая из одной таблицы, имеющей следующую схему: (Фамилия, Номер зачетной книжки, Средний балл зачетной книжки, Любимый предмет). Типы запросов к БД: 1) "Выбрать сведения о студенте с фамилией Х"; 2) "Выбрать фамилии студентов из БД, у которых любимым предметом является предмет Y". Структура запросов к серверу БД определяется с помощью РБНФ следующим образом: <запрос>::= <адрес сервера><закодированный запрос к БД> (см. также тему С1).

66

ТЕМА С4. Система "клиент-сервер" для работы с удаленными базами данных ИСХОДНЫЕ ДАННЫЕ: (см. тему С3) Типы запросов к БД: "Выбрать сведения о студенте, у которого зачетная книжка с номером X"; 2) "Выбрать фамилии студентов из БД, у которых средний бал находится в пределах от Y до Z". 1)

ТЕМА С5. Система "клиент-сервер" для работы с удаленной почтовой службой ИСХОДНЫЕ ДАННЫЕ: на почтовом сервере находятся "почтовые ящики", идентифицируемые целыми числами. Определены следующие операции над почтовым ящиком − запись и чтение. Структура запросов к почтовому серверу определяется следующим образом: <запрос>::= <àäðåñ ñåðâåðà> <номер ящика> <операция> [<записываемая информация>] <операция ::= запись | чтение (см. также тему С1). ТЕМА С6. Система "клиент-сервер" для удаленного выполнения загрузочных модулей ИСХОДНЫЕ ДАННЫЕ: сервер выполняет загрузочные модули, присылаемые клиентом.

67

Структура запросов к серверу определяется следующим образом: <запрос>::= <загрузочный модуль>{<параметр>} При большом размере загрузочного модуля его передачу осуществлять частями. В качестве примера взять загрузочный модуль, выполняющий сложение двух целых чисел (см. также тему С1).

ТЕМА C7. Реализация режима удаленной консоли в ЛВС ИСХОДНЫЕ ДАННЫЕ: режим удаленной консоли предназначен для слежения и управления работой удаленной рабочей станции. РВС состоит из узлов двух типов: "сервера" и "клиентов". Клиент (управляющая станция) формирует задание для удаленного выполнения на сервере (удаленной рабочей станции). Сервер выполняет задание и посылает результат выполнения обратно клиенту, пославшему задание. Программа сервера является резидентной. Выполнение сервером задания в зависимости от заданной функции сводится либо к пересылке области видеопамяти сервера клиенту, либо к заполнению своего буфера клавиатуры данными, выбранными из запроса клиента. ТЕМА С8. Распределенная вычислительная система с архитектурой "клиент-сервер" для нахождения изоморфного вхождения подграфа в граф ИСХОДНЫЕ ДАННЫЕ: РВС предназначена для нахождения в основном графе подграфа, изоморфного заданному. Результатом операции является отношение сопоставления вершин, связывающее каждую вершину заданного подграфа с определенной вершиной основного графа. В случае неудачи возвращается пустое отношение. РВС состоит из узлов двух типов: "сервера" и "клиентов". Клиент формирует задание для удаленного выполнения на

68

сервере. Сервер выполняет задание и посылает результат выполнения обратно клиенту, пославшему задание. Структура запроса клиента: <Запрос>::= <Основной граф><Подграф> При этом основной граф и подграф задаются матрицами смежности, "вытянутыми" по строкам. В качестве результата выполнения операции клиенту посылается вектор сопоставленных вершин основного графа. ТЕМА С9. Распределенная вычислительная система с архитектурой "клиент-сервер" для унификации термов ИСХОДНЫЕ ДАННЫЕ: РВС предназначена для нахождения наиболее общего унификатора (НОУ) двух термов языка Пролог [6]. НОУ представляет собой список пар вида: (<переменная><замещаюший терм>). В случае неудачной унификации НОУ пуст. Структура запроса клиента: <Запрос>::= <Терм 1><Терм 2> Исходное представление термов - списочное, принятое на языке Лисп [16]. Сервер принимает и распаковывает запросы клиента, производит грамматический анализ принятых термов, их перевод во внутреннее списочное представление и унификацию. По завершению унификации формируется строковое (текстовое) представление НОУ, посылаемое в качестве ответа запросившему клиенту. Алгоритм унификации можно найти в [16]. ТЕМА C10. Сервер базы знаний ИСХОДНЫЕ ДАННЫЕ: функции сервера базы знаний: прием запросов клиентов, формирование и поддержка входной очереди запросов, анализ корректности принятых запросов, хранение одной или более продукционных баз знаний (БЗ), выполнение запросов клиентов и получение результата, поддержка диалога с клиентом, формирование и поддержка входной очереди результатов.

69

Структура запроса клиента: <Запрос>::=<Адрес сервера БЗ><Имя БЗ><Цель> <Цель>::=<Имя атрибута>=(<Значение атрибута> | ?) В качестве ответа клиенту в зависимости от типа запроса возвращается либо значение целевого атрибута, либо логический ответ "истина" или "ложь". В качестве имени БЗ выступает имя файла, в котором она хранится. Элементом БЗ является продукционное правило вида [7]: ЕСЛИ <условие>, ТО <действие>.Условия и действия формулируются в терминах двоек типа "атрибутзначение". Действия сводятся к изменению значений атрибутов. Машина логического вывода сервера БЗ функционирует в режимах прямого и обратного вывода (задается преподавателем). Возможен диалог между клиентом и сервером. Инициирующей стороной при этом является сервер, определяющий или уточняющий значения атрибутов, участвующих в логическом выводе. Диалог в этом случае сводится к взаимодействиям типа "вопрос сервера - ответ клиента". Пример программирования машины логического вывода, основанной на продукционной модели представления знаний, можно найти в [8]. D. Системы передачи данных и коммуникационные системы ТЕМА D1. Установление группового соединения ИСХОДНЫЕ ДАННЫЕ: реализовать протокол установления группового соединения (ГС) в ЛВС [15,21]. Перед установлением ГС состав группы неизвестен, известно только число членов группы. Результатом работы процедуры установления ГС является реестр группы, содержащий записи о всех членах группы, их сетевые адреса и полномочия. Введены следующие полномочия: возможность представления нового члена группы; возможность удаления члена группы; возможность завершения ГС; возможность ретрансляции информационного сообще-

70

ния, адресованного группе извне; возможность инициирования создания новой группы; возможность по удалению групп. Полномочия объектам задаются априорно, до установления соединения. 1) Типы сообщений: I_AM_HERE, START.

2)

Состояния протокольного объекта: INITIAL, STARTING, READY, CONNECTED.

ТЕМА D2. Групповая передача данных ИСХОДНЫЕ ДАННЫЕ: групповая передача используется для гарантированной передачи данных априори определенному множеству узлов − группе [22,24]. На узлах имеются реестры − упорядоченные таблицы членов групп. При рассылке используется список рассылки, первоначально совпадающий с соответствующим реестром. Используется широковещательная передача данных в ЛВС. Для исключения квитирования повторно переданного протокольного блока данных (ПБД) теми узлами, от которых квитанции были получены, в структуру ПБД необходимо ввести список адресатов. Принятый пакет квитируется только теми узлами, адреса которых фигурируют в списке адресатов. При приеме квитанции от какого-либо узла, этот узел исключается из текущего списка рассылки. Передача ПБД считается завершенной, если весь список рассылки пуст. Для восстановления после ошибок передач использовать механизм квитирования и тайм-аутов. ТЕМА D3. Децентрализованное управление распределенными данными ИСХОДНЫЕ ДАННЫЕ: программные средства децентрализованного управления распределенными данными (ПСДУРД) должны обеспечить: согласованное начало и завершение работы системы; согласованное изменение распределенных данных (РД); поддержку целостности и консистентности данных; синхронизацию досту-

71

па к данным параллельных транзакций; предотвращение тупиковых ситуаций. Данные в ЛВС распределены с использованием стратегии копирования (дублирования) и находятся в ОП. В основу протокола управления распределенными данными положен двухфазный протокол блокировки [22,24]. На первой фазе работы данного протокола осуществляется захват узлов для выполнения операций обновления распределенной базы данных, а второй − собственно обновление локальной и удаленных баз данных. ТЕМА D4. Синхропримитивы для работы разделяемыми ресурсами ИСХОДНЫЕ ДАННЫЕ: для работы с разделяемыми ресурсами в ЛВС используются два синхропримитива: ЗАНЯТЬ РАЗДЕЛЯЕМЫЕ РЕСУРСЫ и ОСВОБОДИТЬ РАЗДЕЛЯЕМЫЕ РЕСУРСЫ [22]. Синхропримитив ЗАНЯТЬ РАЗДЕЛЯЕМЫЕ РЕСУРСЫ(r) имеет один параметр r − массив кортежей вида (n,a1,a2), где n − имя ресурсной переменной, a1 − число ресурсов данного вида, необходимое для активизации процесса, a2 − число занимаемых единиц ресурса при активизации процесса. Занятие и освобождение ресурсов сводится к переустановке значений ресурсных переменных, распределенных по объектам РВС. При занятии k единиц какого-либо ресурса из соответствующей ресурсной переменной вычитается значение k. Результатом работы примитива являются значения "успешно" и "неуспешно". Успешное занятие ресурсов может произойти только в том случае, когда имеется необходимое для активизации процесса число ресурсов каждого вида. Действия по проверке значений ресурсных переменных и их изменению осуществляются как неделимая операция благодаря их реализации в виде критической секции: ЗАХВАТ РД <Критическая секция> ОСВОБОЖДЕНИЕ РД.

72

Только один из процессов может находиться в своей критической секции. Критическая секция реализуется с использованием семафороподобных примитивов ЗАХВАТ РД и ОСВОБОЖДЕНИЕ РД [22,24]. Синхропримитив ОСВОБОДИТЬ РАЗДЕЛЯЕМЫЕ РЕСУРСЫ имеет один параметр q − массив кортежей вида (n,b), где n − имя ресурсной переменной, b − число возвращаемых единиц ресурса. Освобождение какого-либо ресурса сводится к увеличению значения соответствующей ресурсной переменной на число возвращаемых единиц ресурса. При реализации синхропримитивов использовать программные средства децентрализованного управления распределенными данными (ПСДУРД)[22,24].

ТЕМА D5. Управление группами ИСХОДНЫЕ ДАННЫЕ: станции в ЛВС образуют множество групп [22]. Станция одновременно может входить в несколько групп. Каждый член какой-либо группы имеет список членов этой группы − реестр группы. Для управления статическими группами используются следующие операции: включение и удаление члена группы (элементарного или коллективного), теоретикомножественные операции (объединение, пересечение, разность, дополнение), преобразование иерархической группы в одноуровневую. Реализация операций управления статическими группами основана на манипулировании реестрами групп. Копия реестра группы распределена по всем объектам − членам данной группы. Для корректного обновления копий реестров используется протокол управления распределенными данными, а для реализации функций управления группами − программные средства децентрализованного управления распределенными данными (ПСДУРД)[22,24].

73

ТЕМА D6. Звено передачи данных в ЛВС на основе альтернативно-битового протокола ИСХОДНЫЕ ДАННЫЕ: звено передачи данных (ЗПД) строится на основе альтернативно-битового протокола [21,23]. ЗПД включает узел-передатчик и узел-приемник. Структура протокольного блока данных (ПБД) определяется следующим образом: <ПБД> ::= <тип><÷åòíîñòü>[<данные>] <тип>::= информационный_ПБД | квитанция <четность>::= 0 | 1 Механизм восстановления после ошибок: тайм-ауты и квитирование. ТЕМА D7. Реализация транспортного протокола ИСХОДНЫЕ ДАННЫЕ: реализовать в ЛВС транспортный протокол, соответствующий стандартам Международной организации стандартизации (МОС)[5,9]. Варианты - классы протоколов 0 - 4 задаются преподавателем. ТЕМА D8. Коммуникационная кольцевая структура с передачей маркера ИСХОДНЫЕ ДАННЫЕ: станции ЛВС образуют логическое "кольцо". По "кольцу" передвигается маркер, имеющий поля для адреса и информационного сообщения. Функции маркера - опрос станций на наличие информационных сообщений и перенос этих сообщений адресату. Информационные сообщения и адрес их доставки могут вводиться с клавиату-

74

ры на каждой станции. Если свободный маркер прибывает на станцию, на которой имеется сообщение, то он забирает это сообщение для переноса его адресату. При этом он становится занятым. При прибытии на пункт назначения маркер "разгружается" и становится свободным. Занятый маркер не может забирать сообщения для переноса. На каждой станции имеется сетевой адрес последователя данной станции в "кольце". ТЕМА D9. Волновая передача данных ИСХОДНЫЕ ДАННЫЕ: используемый метод передачи − метод интерференции. Логическая структура системы определяется таблицей связей, хранимой в специальном файле. Соответствие между логической и физической структурой определяется таблицей адресов, хранимой в том же файле. Таблицы связей и адресов идентичны по внутреннему строению для каждого узла. ТЕМА D10. Реализация задачи синхронизации "производитель-потребитель" ИСХОДНЫЕ ДАННЫЕ: РВС должна включать в себя по крайней мере три узла: "производитель", "потребитель" и "буфер". "Производитель" через определенные интервалы времени генерирует сообщения и посылает их в "буфер". "Потребитель" через определенные интервалы времени пытается выбрать сообщение из "буфера". "Буфер" имеет ограниченную емкость памяти на определенное число сообщений. Если буфер полностью заполнен, то "производитель" блокируется до освобождения места в буфере. Если буфер пуст, то "потребитель" блокируется до появления сообщения в буфере. Взаимодействие "производителя" и "потребителя" с "буфером" возможно или на основе опроса, или на основе посылки специальных "извещений" от "буфера", выводящих "производителя" или "потребителя" из состояния блокировки.

75

Е. Системы потоков данных ТЕМА Е1: Функциональный узел РВС, основанной на принципе потока данных ИСХОДНЫЕ ДАННЫЕ: основная функция, выполняемая функциональным узлов (ФУ) − сложение. Число входов − 2. Адрес посылки результата задается при настройке ФУ. Функции ФУ: прием операндов; управление входной очередью операндов: постановка в очередь, выборка из очереди, очистка очереди; выполнение основной функции; управление выходной очередью результатов: постановка результатов в очередь, выборка результатов из очереди, очистка очереди. Тип функции и число входов ФУ могут варьироваться. ТЕМА Е2. Распределенная система, управляемая потоками данных ИСХОДНЫЕ ДАННЫЕ: РВС представляет собой аппаратнопрограммный комплекс, включающий ЛВС, совокупность интерпретаторов графов потоков данных (ГПД) и собственно ГПД, распределенных по узлам ЛВС. Для организации распределенной обработки разрабатывается общий ГПД, в дальнейшем он разрезается и раскладывается по узлам распределенной системы, где осуществляется его интерпретация, в ходе которой выполняются необходимые обмены сообщениями. Потоковая программа представляется с использованием языка Денниса [4]. Структура ячейки команд: 1) код операции; 2) адрес(а) назначения; 3) вентильный код 1; 4) вентильный флаг 1; 5) флаг данных 1; 6) данные 1; 7) вентильный код 2; 8) вентильный флаг 2; 9) флаг данных 2; 10) данные 2.

76

Разработать интерпретатор потоковых программ. На конкретных примерах произвести тестирование интерпретатора в одномашинном и многомашинном вариантах. ТЕМА Е3. Интерпретатор диаграмм потоков данных специального вида для распределенной обработки в ЛВС ИСХОДНЫЕ ДАННЫЕ: для представления распределенной обработки используются диаграммы потоков данных (ДПД) специального вида, основанные на сетевом формализме (СФ) [22,24]. Основные элементы ДПД: буфера (очереди), глобальные и локальные управляющие переменные, процессы. Процедуры процессов пишутся на языке высокого уровня и являются резидентными. В процедурах переходов используются примитивы работы с очередями: "Включить сообщение в очередь", "Выбрать сообщение из очереди", "Создать копию сообщения", "Удалить сообщение". Интерпретатор ДПД находит разрешенный процесс и запускает его. Процесс является разрешенным, если разрешены все его входы. Вход является разрешенным, если число сообщений в очереди или значение управляющей переменной больше или равно весу соответствующей входной дуги. При активизации процесса сообщения из входных очередей передвигаются в выходные, значения входных переменных уменьшаются на соответствующую величину, а выходных − увеличиваются. Разработать интерпретатор ДПД. На конкретных примерах произвести тестирование интерпретатора ДПД в одномашинном и многомашинном вариантах. F. Системы распределенного вывода и вычисления логических запросов ТЕМА F1. Вывод в И-ИЛИ-деревьях

77

ИСХОДНЫЕ ДАННЫЕ: Реализовать в ЛВС вывод на основе ИИЛИ-деревьев. Общее И-ИЛИ-дерево разбиваться на поддеревья, поддеревья распределяются на отдельные узлы РВС, где интерпретируются. Взаимосвязь между поддеревьями в сети осуществляется с помощью портов. Структура дерева представляется с помощью специального языка, синтаксис которого c использованием РБНФ представлен ниже: <дерево> ::= {<связка вершины>} <связка вершины> ::= <тип вершины><номер вершины > [:{(<номер вершины-потомка> | OUT <номер выходного порта>)}]; <тип вершины>::= AND | ОR | TRUE | FALSE <номер вершины>::= <целое> <номер выходного порта>::=/<номер сокета> Режимы функционирования системы : диалоговый и автоматический.

ТЕМА F2. Распределенный интерпретатор логических программ ИСХОДНЫЕ ДАННЫЕ: распределенный интерпретатор логических программ (РИЛП) предназначен для параллельной интерпретации логических программ в ЛВС с шинной топологией с использованием групповых передач данных[22,24]. Для представления логических программ используется подмножество языка Пролог[6]. РИЛП представляет распределенную вычислительную систему, состоящую из однотипных узлов. Каждый узел строит свое поддерево доказательства общей цели. Результаты доказательства внешней цели используются для преобразования "внешней" целевой вершины во внутреннюю вершину типа ИЛИ. Логический вывод представляется как построение дерева доказательства в РВС.

78

При этом каждый интеллектуальный член группы (ИЧГ) в РВС, представленный интерпретатором и логической программой, строит свои поддеревья. Построение поддерева продолжается до тех пор, пока не встретится подцель, которую не удалось доказать на основе локальных клозов и которая отмечена как "внешняя". В этом случае ИЧГ посылает всем другим ИЧГ той же группы данную подцель для доказательства. Предусмотрены два типа ответов на внешнюю цель: результаты унификации доказательства. Результат унификации − наиболее общий унификатор (НОУ) или их совокупность. Данный тип ответа необходим для детектирования константных унификаций. Пустой НОУ определяет отрицательный результат. Результатом доказательства являются значения "успех" и "неудача", а также подстановки, при которых достигается "успех". После получения результатов унификации инициирующий ИЧГ пытается найти вершину-"правого брата" "внешней" вершины, для которой может быть инициирован процесс построения поддерева. Данная вершина должна удовлетворять условию независимости от "внешней" вершины, то есть она не должна иметь с ней общих переменных, или, в случае наличия общих переменных, они должны быть конкретизированы константами. Результаты доказательства внешней цели используются для преобразования "внешней" целевой вершины во внутреннюю вершину типа ИЛИ, причем последователи-листья этой вершины образуются из полученных ответов. В процессе интерпретации возможно принудительное прекращение всех параллельных вычислений, связанных с доказательством некоторой внешней цели, путем групповой передачи специального "гасящего" сообщения. На конкретных примерах произвести тестирование интерпретатора в одномашинном и многомашинном вариантах. ТЕМА F3. Распределенная интерпретация логических запросов, основанных на временной логике ИСХОДНЫЕ ДАННЫЕ: используется разновидность временной логики с "ветвящимся" временем [19]. Временные логические опе-

79

раторы − ALL ("всегда"), POT ("возможно"), INEV ("неизбежно"), SOME ("возможно некоторое время"). Логическая структура РВС задается с помощью таблицы соответствия логических имен (идентификаторов или номеров) и сетевых адресов узлов, одинаковой для всех узлов, а также таблиц предшественников и последователей, индивидуальных для каждого узла. На узлах находятся информационные массивы, имеющие одинаковую структуру, но индивидуальные для каждого узла. C каждого узла может быть введен логический запрос вида <Номер узла>:<Формула временной логики>. Формула временной логики может содержать вложенные временные логические операторы. При вычислении логических запросов возможен параллелизм двух типов − параллелизм независимых логических запросов и параллелизм операций при выполнении логического запроса. Копии интерпретатора логических запросов распределяются на все узлы РВС. Разработать интерпретатор логических запросов и проверить интерпретации. логических запросов в РВС на конкретных примерах в одномашинном и многомашинном вариантах. G. Разное ТЕМА G1: Конвейерная обработка в ЛВС ИСХОДНЫЕ ДАННЫЕ: реализовать в ЛВС конвейерное вычисление суперпозиции функций: Cos(Sin(X+3)^2)). Каждый узел конвейера выполняет только один тип операции. На каждом узле возможно образование входных очередей сообщений на обработку. Для генерации значений X используется отдельный узел, направляющий полученное сообщение в начало конвейера. При определении интервала генерации значений Х используется генератор случайных чисел.

80

ТЕМА G2: Распределенная интерпретация сетей Петри ИСХОДНЫЕ ДАННЫЕ: суть распределенной интерпретации СП заключается в том, что общая сетевая модель разрезается на части (фрагменты), каждый из которых распределяется на отдельный узел, где локально интерпретируется [20]. Взаимосвязь отдельных фрагментов осуществляется через граничные позиции (порты) путем передачи меток. На всех узлах РВС находятся копии одного и того же интерпретатора СП. Сетевые модели на узлах представляются в виде двух матриц: матриц связей типа "позиция-переход" и "переход-позиция" [2-3], а также вектора начальной маркировки и таблицы выходных портов, в которых указаны сетевые адреса и номера позиций фрагментов-приемников. Режимы функционирования системы (могут рассматриваться как подварианты задания): асинхронный (как в системе "Петрис"[20]) и тактированный. В асинхронном режиме фрагменты функционируют независимо один от другого в том смысле, что моменты срабатывания переходов в различных фрагментах не синхронизированы. В тактированном режиме момент срабатывания переходов во фрагментах связан с приходом синхронизирующего сообщения. При этом в структуре РВС выделяется специальный узел − генератор синхросообщений, посылающий в широковещательном режиме через определенные интервалы времени специальные синхросообщения. Разработать интерпретатор СП и проверить интерпретацию СП в РВС на конкретных примерах в одномашинноом и многомашинном вариантах. БИБЛИОГРАФИЧЕСКИЙ СПИСОК 1. Лорин Г. Распределенные вычислительные системы. - М.: Радио и связь, 1984. - 296 с. 2. Питерсон Дж. Теория сетей Петри и моделирование систем. -М.:Мир, 1984. - 263 с.

81

3. Котов В.Е. Сети Петри. - М.: Наука,1984. - 158 с. 4. Майерс Г. Архитектура современных ЭВМ: В 2-х кн. Кн.2. - М.: Мир, 1985. - 312 с. 5. Ротанов С.В. Классы транспортного протокола МОС // Автоматика и вычислительная техника.- 1986. - N 1. - C.24-29 6. Клоксин У., Ìåëëèø К. Программирование на языке Пролог. - М.: Мир,1987. - 336 с. 7. Представление и использование знаний / Под ред. Х.Óýíî, М.Исидзука. - М. : Мир, 1989. - 220 с. 8. Сойер Б., Фостер Д. Программирование экспертных систем на Паскале : Ïåð. с англ. - М. : Финансы и статистика, 1990. 191 с. 9. Блэк Ю. Сети ЭВМ: Протоколы, стандарты, интерфейсы. -М.: Мир,1990. 10. Моделирование вычислительных структур на системном уровне: Метод. указания к выполнению лабораторных работ / Составители: В.П.Кулагин, А.В.Никишин. - Пенза: Пенз. политехн. ин-т, 1990. - 44 с. 11. Кулагин В.П. Анализ параллельных процессов на основе сетевых моделей: Учеб. пособие. - Пенза: Пенз. политехн. ин-т, 1991. - 88 с. 12. Дубинин В.Н., Зинкин С.А. Спецификация и верификация процессов обмена информацией в вычислительных системах и сетях: Учеб.пособие. - Пенза: Пенз. политехн.ин-т, 1992. - 95 с. 13. Фролов А.В., Фролов Г.В. Локальные сети персональных компьютеров. Использование протоколов IPX, SPX, NETBIOS.- М.: "ДИАЛОГ-МИФИ", 1993. - 160 с. - (Библиотека системного программиста; Т.8) 14. Фролов А.В., Фролов Г.В. Локальные сети персональных компьютеров. Работа с сервером Novell NetWare.- М.: "ДИАЛОГ-МИФИ", 1993. - 168 с. - (Библиотека системного программиста; Т.9)

82

15. Дубинин В.Н., Москалянов Е.В. Установление коллективного соединения в ëîêàëüíîé вычислительной сети / Пензенский гос. техн. ун-т. - Пенза, 1995. - 42 с. -Деп. в ВИНИТИ 12.04.95, N 1000-В953. 16. Программирование на языке Лисп: Методические указания к âûïîëíåíèþ лабораторных работ / Составитель В.Н.Дубинин. - Пенза: Изд-во Пенз. гос. техн. ун-та, 1996. - 46 с. 17. Гусева А.И. Работа в локальных сетях NetWare 3.124.1: Учебник.- М.: "ДИАЛОГ-МИФИ", 1996. - 288 с. 18. Бадди Шипли. Ethernet - испытание на живучесть // LAN Magazine / Русское издание. Журнал сетевых приложений. 1996. - т.2, N 4. - С.61-65 19. Дубинин В.Н. Вычисление логических запросов, основанных на временной ëîãèêå/ Пензенский гос. техн. ун-т. Пенза, 1996. - 54 с. -Деп в ВИНИТИ 14.02.96, N 488-В96 20. Дубинин В.Н. ПЕТРИС − комплекс программ для графического моделирования расширенных сетей Петри / Пензенский гос. техн. ун-т. - Пенза, 1996. - 34 с. -Деп в ВИНИТИ 23.07.96, N 2502-В96 21. Зинкин С.А., Дубинин В.Н. Сетевые спецификации, моделирование и проектирование вычислительных комплексов, систем и сетей: Учеб. пособие в 2-х кн. Кн.1 - Пенза: Изд-во Пенз. гос. техн. ун-та, 1996. - 322 с. 22. Дубинин В.Н. Децентрализованное управление распределенными данными в локальной вычислительной сети: спецификация, моделирование, реализация и применение в распределенных вычислениях / Пензенский гос. техн. ун-т. - Пенза, 1997. - 78 с. -Деп в ВИНИТИ 10.06.97, N 1946-B97 23. Дубинин В.Н., Зинкин С.А. Языки логического программирования в проектировании вычислительных систем и сетей: Учеб. пособие. - Пенза: Изд-во Пенз. гос. техн. ун-та, 1997. - 88 с. 24 Зинкин С.А., Дубинин В.Н. Сетевые спецификации, моделирование и проектирование вычислительных комплексов,

83

систем и сетей: Учеб. пособие в 2-х кн. Кн.2. - Пенза: Изд-во Пенз. гос. ун-та. - В печати

84

СОДЕРЖАНИЕ Введение ...................……...……………………….…..... 3 Лабораторная работа N 1. Исследование сетевых моделей вычислительных систем с параллельными процессами …................................................................…....….…. 5 Лабораторная работа N 2. Построение прототипов распределенных вычислительных систем с использованием сетевых моделей..................................................... 19 Лабораторная работа N 3. Работа с сокетами сетевого протокола IPX ......................................................... 30 Лабораторная работа N 4. Прием и передача дейтаграмм в ЛВС с использованием протокола IPX .......... 38 Лабораторная работа N 5. Реализация механизма таймаутов с использованием протокола IPX ...……....…. 53 Лабораторная работа N 6. Разработка процедур передачи данных в ЛВС с использованием механизма квитирования и таймаутов ............................................. 59 Дополнительные темы лабораторных и курсовых работ .................................................................... 67 Библиографический список ......…………….......… 92

Слова для вклеивания в рисунки

85

Рис. 7. Сетевой фрагмент в системе «Петрис» port1 port1 port2 port2 port3 port3 port4 port4 port5 port5 port6 port6 port7 port7 t1 t1 t2 t2 t3 t3 t4 t4 p1 p1 p2 p2 port1 port1 port2 port2 port3 port3 port4 port4 port5 port5 port6 port6 port7 port7 t1 t1 t2 t2 t3 t3 t4 t4 p1 p1 p2 p2 Рис. 7. Сетевой фрагмент в системе «Петрис»

86