Современные теории имитационного моделирования: Лабораторные работы

ЛАБОРАТОРНЫЕ РАБОТЫ ПО СПЕЦИАЛЬНОМУ КУРСУ

«Современные теории имитационного моделирования»

Замятина Е.Б.

2006

Лабораторные работы должны быть выполнены студентами 2 курса магистратуры, которые изучают курс «Современные теории имитационного моделирования» и обучаются по специальности 010501,010500 (направления) «Прикладная математика и информатика». Первые две работы касаются распределённых алгоритмов синхронизации. Студенты должны разработать их и реализовать, используя технологию .NET. Технология .NET, программные средства .NET Remoting являются удобными средствами для реализации этих алгоритмов и программных средств, оптимизирующих распределённый имитационный эксперимент. Третья лабораторная работа посвящена вопросам оптимизации времени выполнения распределённого алгоритма синхронизации, а именно, динамической балансировке загрузки процессоров. Алгоритмы балансировки включают такие этапы, как а) анализ загрузки процессоров; б) выбор объекта имитационной модели, который следует перенести с одного компьютера на другой; в) перемещение объекта. В лабораторной работе предполагается выполнить последний этап – перемещение объекта с одного компьютера на другой. В результате выполнения лабораторных работ студенты должны представить программу, исходные тексты, презентацию своей работы и презентацию использованного ими теоретического материала.

2

ЛАБОРАТОРНАЯ РАБОТА №1.

Разработка и реализация консервативного алгоритма синхронизации По стано вка задач и: Разработать консервативный алгоритм синхронизации с нулевыми сообщениями для имитации взаимодействия покупателя, банка и магазина (пример приведён в [1]: Предположим, что имитационная модель представляет собой совокупность трёх взаимодействующих процессов. Покупатель в магазине делает покупку в кредит. Магазин сообщает о сделке банку, в котором открыт счёт покупателя. Покупатель приходит в банк, чтобы снять со счёта некоторую сумму. Если деньги на счёте есть, он получает эту сумму, если нет, то ему отказывают и рекомендуют пополнить счёт. Р ек о м ен д а ц ия: при выполнении работы использовать программные средства технологии .NET. Описа ние кон сер вативно го алгоритма с н уле вы ми сообщениями Консервативный подход не позволяет выполнять событие до тех пор, пока нет гарантии, что оно является безопасным. Большинство консервативных алгоритмов основано на вычислении LBTS (Lower Bound on the Time Stamp – Нижняя граница временных меток) будущих сообщений, которые могут быть получены логическим процессом. Этот механизм позволяет определить, является ли очередной событие из списка необработанных событий безопасным. Действительно, если консервативный алгоритм определит, что LBTS = 12, то все события из списка необработанных событий с временной отметкой, меньшей 12, являются безопасными и могут быть выполнены. Соответственно, события с временной меткой, большей 12 не могут быть выполнены. Что касается событий, которые имеют временную отметку, равную 12 (LBTS = 12), то их обработка зависит от реализации конкретного консервативного алгоритма и правил, по которому должны обрабатываться события, запланированные на один и тот же момент времени. Будем считать, что логические процессы не содержат событий, запланированных на одно и то же модельное время. 3

Алгор итм с н ул евы ми соо бщ ени ями Первыми консервативными алгоритмами считаются алгоритмы, разработанные Bryant [3], Chandy[4,5], Misra[4,5]. Алгоритм предполагает: − Топология процессов, которые посылают сообщения друг другу, известна и фиксирована. − Каждый логический процесс посылает сообщения с неубывающими временными метками. − Коммуникационная среда обеспечивает доставку сообщений в том порядке, в котором они были посланы. Исходя из этих предположений, можно сделать следующее заключение: − Временная метка сообщения, которое было получено последним на линии связи, является нижней границей временных меток (LBTS) всех будущих сообщений, передаваемых по этой линии связи. − Нижняя временная метка (LBTS) логического процесса определяется как минимальная из всех нижних временных меток, полученных процессом по всем входным линиям связи. Сообщения каждой линии связи находятся в очереди, которая обрабатывается по дисциплине FIFO. Очередь упорядочена также в соответствии с временными метками. Каждая линия связи имеет своё локальное время, которое равно временной отметке первого сообщения в очереди (если таковые имеются) или временной отметке последнего принятого сообщения. Все события, которые планирует сам процесс для себя, находятся в другой очереди. Алгоритм периодически выбирает линию связи с наименьшим временем и, если в ней есть события, то он обрабатывает это событие. Если очередь пуста, то процесс блокируется. Процесс никогда не блокируется при проверке состояния очереди сообщений, которые он планирует для себя. Итак, этот алгоритм гарантирует, что каждый логический процесс будет обрабатывать события в хронологическом порядке.

4

Цель: Необходимо, чтобы события выполнялись в хронологическом порядке. WHILE (не конец моделирования) Ждать пока каждая из очередей содержит хотя бы одно сообщение Удалить сообщение с наименьшей меткой, просмотрев каждую из очередей. Обработать это событие END LOOP Несмотря на то, что алгоритм обеспечивает локальную каузальность, при его выполнении могут возникнуть тупики. Действительно, если нижняя граница временных отметок на всех линиях связи будет меньше, чем необработанные события, то это приведет к ожиданию выполнения другого цикла. Для того, чтобы избежать возникновение тупиков, Chandy и Misra предложили использовать нулевые сообщения. Процесс LPa посылает сообщение с временной меткой Tnull процессу LPb. Этим процесс LPa сообщает процессу LPb, что он не пришлёт процессу сообщение с временной отметкой, меньшей, чем Tnull. Нулевые сообщения не соответствуют каким-либо физическим явлениям моделируемого объекта. Это искусственный приём, используемый для того, чтобы избежать возникновения тупика. Процессы отсылают нулевые сообщения по всем выходным дугам после обработки очередного события. Нулевое сообщение служит дополнительной информацией для того, чтобы определить очередное безопасное событие. Нулевое сообщение обрабатывается как обычное сообщение за исключением того факта, что ни одна переменная процесса и никакое событие не будут запланированы. Локальное время логического процесса продвигается до временной отметки нулевого сообщения. Каким образом процесс определит временную метку нулевого сообщения, которое он отсылает? Значение часов каждой линии связи определяет нижнюю границу временной метки следующего события, которое будет извлечено из буфера этой линии связи. Эта нижняя граница в совокупности со сведениями о выполнении процесса являются исходной информацией для определения нижней границы временных меток для всех посылаемых с выходных дуг сообщений. Fujimoto[2,5] приводит такой пример: если известно, что некоторое обслуживающее устройство обрабатывает 5

заявку в течении T единиц модельного времени, то временная метка любого отсылаемого сообщения по крайней мере на T единиц модельного времени больше, нежели временная метка любого сообщения, которое может появиться в будущем. Как только процесс завершит обработку нулевого или ненулевого сообщения, он вновь посылает нулевое сообщение по выходным дугам. Процесс, получивший нулевое сообщение, обязан вычислить нижнюю границу временной метки и отослать эту информацию свои соседям и т.д. Итак, приведённый выше алгоритм с использованием нулевых сообщений позволяет избавиться от тупиков. Использованная л ит ер а т ур а : 1. Вознесенская Т.В. Математическая модель алгоритмов синхронизации времени для распределённого имитационного моделирования.//В кн. Программные системы и инструменты. Тематический сборник факультета ВМиК МГУ им. Ломоносова №1., стр.56-66 2. В.В. Окольнишников. Представление времени в имитационном моделировании. Вычислительные технологии. Т. 10, №5, Сибирское отделение РАН, 2005, стр. 57-77 3. Bryant, R. E. (1977). Simulation of packet communications. Аrchitecture computer systems. MIT-LCS-TR-188. 4. Chandy, K. M. and J. Misra (1978). “Distributed Simulation: A Case Study in Design and Verification of Distributed Programs.” IEEE Transactions on Software Engineering SE-5(5): 440-452. 5. Chandy, K. M. and J. Misra (1981). “Asynchronous Distributed Simulation via a Sequence of Parallel Computations.” Communications of the ACM 24(4): 198-205. 6. Richard M. Fujimoto. Distributed Simulation Systems. In Proceedings of the 2003 Winter Simulation Conference S. Chick, P. J. Sánchez, D. Ferrin, and D. J. Morrice, eds. pp. 124-134. Реко мендуемые про граммные сред ства и литература : Для выполнения данной лабораторной работы следует использовать языки C# или Visual Basic .NET. Для моделирования объектов банк, покупатель и магазин необходимо применить программные потоки (threads). 6

Многопоточность в .NET Основные средства .NET, относящиеся к использованию программных потоков, сосредоточены в пространстве имен Threading. Таким образом, в программу следует импортировать пространство имен System.Threading. Создание потоков и управление ими осуществляется с помощью класса System.Threading.Thread. Вы можете создать экземпляры объекта Thread двумя способами. Первый - это создание нового потока и получение объекта Thread, позволяющего манипулировать новым потоком. Второй способ получить объект Thread для потока, исполняемого в данный момент, - вызов статического метода Thread.CurrentThread. Методы объекта Thread позволяют управлять активностью или временем жизни потока. Приостановить выполнение потока можно с помощью вызова метод Thread.Sleep, который принимает единственный аргумент, представляющий собой время (в миллисекундах), на которое поток будет приостановлен. Метод Thread.Sleep является статическим и не может быть вызван с экземпляром объекта Thread. Не допускается вызов Thread.Sleep для любого другого потока, кроме исполняемого в текущий момент. Также вызов метода Thread.Sleep может быть осуществлен с двумя особенными параметрами. Первый вызов Thread.Sleep со значением 0. При этом текущий поток освободит неиспользованный остаток своего кванта. При передаче значения Timeout.Infinite поток будет приостановлен на неопределенно долгий срок, пока это состояние потока не будет прервано другим потоком, вызвавшим метод приостановленного потока Thread.Interrupt. Приостановить исполнение потока также может вызов метода Thread.Suspend. Метод Thread.Suspend можно вызвать для потока, исполняемого в текущий момент, или для другого произвольного потока. Любой другой поток способен возобновить выполнение потока, прерванного с помощью Thread.Suspend, используя метод Thread.Resume. Поток завершается автоматически при выполнении всех его команд. Насильно уничтожить поток можно вызовом метода Thread.Abort. Исполняющая среда насильно завершает выполнение потока, генерируя исключение ThreadAbortException. При переключении процессора по окончании выделенного потоку кванта времени, процесс выбора следующего потока, предназначенного для исполнения, осуществляется операционной системой в соответствии с реализованным в ней алгоритмом планирования. У каждого потока есть приоритет, указывающий процессору, как должно планироваться выполнение этого потока по отношению к другим потокам 7

системы. Уровень приоритета потока по умолчанию равен Normal. Для просмотра и установки этого значения служит свойство Thread.Priority. Установщик свойства Thread.Priority принимает аргумент типа Thread.ThreadPriority, который представляет собой перечисление, определяющее значения Highest, AboveNormal, Normal, BelowNormal и Lowest. Реализовать синхронизацию доступа потоков к разделяемым данным можно с помощью стандартных объектов синхронизации Win32 и функций ожидания. Но лучше использовать эквивалентные объекты .NET. Класс System.Monitor позволяет упорядочить обращения к блокам кода с помощью блокировки и освобождения. Для работы с данным объетом используются два метода. Метод Enter во время своего исполнения пытается получить блокировку монитора для объекта. Если у другого потока уже есть эта блокировка, метод блокируется до тех пор, пока блокировка не будет освобождена. Метод Monitor.Exit используется для освобождения блокировки. Класс Mutex - это представление примитива системы Win32 с тем же именем. У данного объекта используются методы WaitOne(захват мьютекса) и Close (освобождение мьютекса) Работа с потоками в VB .NET Для запуска потоков в .NET используется делегат ThreadStart. Код, вызываемый при помощи делегата ThreadStart, не должен иметь параметров и возвращаемого значения, поэтому потоки не могут создаваться для функций (которые возвращают значение) и для процедур с параметрами. Пример создания потока на языке VB .NET показан ниже. 'Класс, метод которого предполагается выполнять в отдельном 'потоке Public Class TestClass Public Sub ThreadSub() Do 'Условие завершения потока 'Тело потока Loop End Sub End Class 'Основной модуль Imports System.Threading Module TestModule Sub Main() Dim objTest As New TestClass

8

Dim lThreadStart As New ThreadStart(AddressOf ojTest.ThreadSub) 'Создание делегата Dim lThread As New Thread(lThreadStart) lThread.Start() 'Запуск потока 'Код основного потока End Sub End Module

Рекомендуемая литература по созданию многопоточных приложений на VB .NET: 1. Петрусос Е. Эффективная работа: Visual Basic .NET.СПб.: Питер, 2002. 928 с. 2. Корнелл Г., Моррисон Дж. Программирование на VB. NET: учебный курс. СПб.: Питер, 2002. 400 с. 3. Эппламан Д. Переход на VB .NET: стратегии, концепции, код. CПб.: Питер, 2002. 464 c. Работа с потоками в С# Пример создания нового потока на языке С# показан ниже. class TestModule { static void WorkerThreadMethod() { //Тело потока } [STAThread] static void Main(string[] args) { ThreadStart worker = new ThreadStart(WorkerThreadMethod); Thread t = new Thread(worker); t.Start(); //'Код основного потока } }

Рекомендуемая литература по созданию многопоточных приложений на C#: 1. Троелсен Э. С# и платформа .NET. СПб.: Питер, 2003. 800 с. 9

2. 3.

Секунов Н.Ю. Разработка приложений на С++ и С#. СПб.: Питер, 2003. 608 с. Шилдт Г. С#. СПб.: Питер, 2003. 512 с. О тч ёт н о ст ь :

В результате выполнения лабораторной работы должны быть представлены следующие материалы: 1. Программа; 2. Исходные тексты; 3. Презентация работы; 4. Презентация, в которой освещаются вопросы реализации консервативных алгоритмов. 5. Предложения по оптимизации алгоритма.

10

ЛАБОРАТОРНАЯ РАБОТА №2

Разработка и реализация консервативного алгоритма синхронизации По стано вка задач и: Разработать оптимистический алгоритм синхронизации для имитации взаимодействия покупателя, банка и магазина[1]: Предположим, что имитационная модель представляет собой совокупность трёх взаимодействующих процессов Покупатель в магазине делает покупку в кредит. Магазин сообщает о сделке банку, в котором открыт счёт покупателя. Покупатель приходит в банк, чтобы снять со счёта некоторую сумму. Если деньги на счёте есть, он получает эту сумму, если нет, то ему отказывают и рекомендуют пополнить счёт. Р ек о м ен д а ц ия: при выполнении работы использовать программные средства технологии .Net. Описа ние оп ти ми стич ес кого алгоритма синхрониза ции Наиболее известный оптимистический алгоритм – алгоритм, разработанный Джефферсоном (Jefferson (1985)). Алгоритм известен под названием Time Warp (алгоритм деформации времени). Когда логический процесс получает событие, имеющее временную отметку меньшую, чем уже обработанные события, он выполняет откат и обрабатывает эти события повторно в хронологическом порядке. Откатываясь назад, процесс восстанавливает состояние, которое было до обработки событий (используются контрольные точки) и отказывается от сообщений, отправленных «откаченными» событиями. Для отказа от этих сообщений разработан изящный механизм антисообщений. Антисообщение – это копия ранее отосланного сообщения. Если антисообщение и соответствующее ему сообщение (позитивное) хранятся в одной и той же очереди, то они взаимно уничтожаются. Чтобы изъять сообщение, процесс должен отправить соответствующее антисообщение. Если соответствующее позитивное сообщение уже обработано, то процесс-получатель откатывается назад. При этом могут поя-

11

виться дополнительные антисообщения. При использовании этой рекурсивной процедуры все ошибочные сообщения будут уничтожены. Для того, чтобы оптимистический алгоритм стал надёжным механизмом синхронизации, необходимо решить 2 проблемы: − Некоторые действия процесса, например, операции ввода-вывода, нельзя «откатить»; − Обсуждаемый алгоритм требует большого количества памяти (для восстановления состояний процессов в контрольных точках, которые создаются независимо от того, произойдёт откат или нет), требуется особый механизм, чтобы освободить эту память. Обе эти проблемы решаются с помощью глобального виртуального времени (GVT). GVT – это нижняя граница временной отметки любого будущего отката. GVT вычисляется с учётом откатов, вызванных сообщениями, поступивших «в прошлом». Таким образом, наименьшая временная метка среди необработанных и частично обработанных сообщений и есть GVT. После того, как значение GVT вычислено, фиксируются операции ввода вывода, выполненные в модельное время, превышающее GVT, а память восстанавливается (за исключением одного состояния для каждого из логических процессов). Вычисление GVT очень похоже на вычисление LBTS в консервативных алгоритмах. Это происходит потому, что откаты вызваны сообщениями или антисообщениями в прошлом логического процесса. Следовательно. GVT – это нижняя граница временной метки будущих сообщений (или антисообщений), которые могут быть получены позже. Использованная литература: 1. Вознесенская Т.В. Математическая модель алгоритмов синхронизации времени для распределённого имитационного моделирования.//В кн. Программные системы и инструменты. Тематический сборник факультета ВМиК МГУ им. Ломоносова №1., стр.56-66 2. В.В. Окольнишников. Представление времени в имитационном моделировании. Вычислительные технологии. Т. 10, №5, Сибирское отделение РАН, 2005, стр. 57-77 3. Richard M. Fujimoto. Distributed Simulation Systems. In Proceedings of the 2003 Winter Simulation Conference S. Chick, P. J. Sánchez, D. Ferrin, and D. J. Morrice, eds. pp. 124-134.

12

Реко мендуемые про граммные сред ства и литература Для выполнения данной лабораторной работы следует использовать языки C# или Visual Basic .NET. Для моделирования объектов банк, покупатель и магазин необходимо применить программные потоки (threads). Рекомендуемая литература по созданию многопоточных приложений на VB .NET: 1. Петрусос Е. Эффективная работа: Visual Basic .NET.СПб.: Питер, 2002. 928 с. 2. Корнелл Г., Моррисон Дж. Программирование на VB. NET: учебный курс. СПб.: Питер, 2002. 400 с. 3. Эппламан Д. Переход на VB .NET: стратегии, концепции, код. CПб.: Питер, 2002. 464 c. Рекомендуемая литература по созданию многопоточных приложений на C#: 1. Троелсен Э. С# и платформа .NET. СПб.: Питер, 2003. 800 с. 2. Секунов Н.Ю. Разработка приложений на С++ и С#. СПб.: Питер, 2003. 608 с. 3. Шилдт Г. С#. СПб.: Питер, 2003. 512 с. О тч ёт н о ст ь: В результате выполнения лабораторной работы должны бать представлены следующие материалы: 1. Программа; 2. Исходные тексты; 3. Презентация работы; 4. Презентация, в которой освещаются вопросы реализации оптимистических алгоритмов. 5. Предложения по оптимизации алгоритма..

13

ЛАБОРАТОРНАЯ РАБОТА №3

Разработка и реализация процедуры перемещения объекта с одного вычислительного узла на другой при выполнении динамической балансировки По стано вка задач и: Разработать процедуру для перемещения объекта с одного компьютера сети на другой. Эта процедура применяется при реализации динамической балансировки. Имитационная модель состоит из логических процессов, взаимодействующих друг с другом. Логические процессы функционируют на двух разных компьютерах и взаимодействуют друг с другом (три на одном, два на другом). Процессы обмениваются сообщениями. Один из логических процессов является центральным координатором. В определённый момент времени он принимает решение о переносе нагрузки с одного компьютера на другой. В результате на указанном центральным координатором компьютере он случайным образом выбирает объект и выполняет процедуру переноса этого объекта на другой компьютер. Р ек о м ен д а ц ия: при выполнении работы использовать программные средства технологии .NET и .NET Remoting. Описа ние алгор итма д ина мич е ско й балансиров ки Обычно практичное и полное решение задачи балансировки загрузки состоит из четырех шагов: 1. Оценка загрузки. 2. Инициация балансировки загрузки. 3. Принятие решений о балансировке. 4. Перемещение объектов. Дисбаланс загрузки может определяться синхронно и асинхронно. При синхронном определении дисбаланса все процессоры прерывают работу в определенные моменты синхронизации и определяют дисбаланс загрузки путем сравнения загрузки отдельного процессора с общей средней загрузкой. При асинхронном определении дисбаланса каждый процессор хранит историю своей загрузки. В этом случае момент синхронизации для определения степени дисбаланса отсутствует. Вычислением объе14

ма дисбаланса занимается фоновый процесс, работающий параллельно с приложением. Большинство стратегий динамической балансировки загрузки можно отнести к классу централизованных или к классу полностью распределенных. При централизованной стратегии специальный процессор собирает глобальную информацию о состоянии всей машины и принимает решение о перемещении задач для каждого процессора. При полностью распределенной стратегии на каждом процессоре выполняется алгоритм балансировки загрузки, обменивающийся информацией о состоянии с другими процессорами. Перемещение происходит только между соседними процессорами. После принятия решений о балансировке происходит перемещение объектов среди процессоров для достижения нового баланса загрузки. При перемещении объекта должна обеспечиваться целостность его состояния. Для перемещения данных объекта обычно используются вспомогательные функции приложения, особенно когда речь идет о сложных структурах данных, таких как списки ссылок или указателей. Балансировка является целью переноса нагрузки. Балансировка и перенос нагрузки используются для повышения производительности распределённой системы моделирования. Из-за разнородности вычислительной среды, один алгоритм может хорошо работать в распределённой системе и плохо в другой. Динамическая балансировка в SPEEDES В распределённой системе имитации SPEEDES рассматриваются 3 политики для динамического переноса нагрузки: • случайный алгоритм (random,R), • основанный на коммуникациях (communication,С), • основанный на загрузке (load,L). Будем в дальнейшем называть эту стратегию балансировки RCLстратегией. Алгоритм переноса объекта или процесса с одного компьютера достаточно сложен. Введение некоторых разумных допущений только незначительно снижает сложность этого алгоритма. Итак , сделаны следующие допущения: • Распределённая система является гетерогенной. • Пользователь может интерактивно взаимодействовать с машиной в любой момент времени. • Количество вычислительных узлов в сети ограничено. • Возможно изменение сети.

15

• Задержки на коммуникацию в сети остаются неизменными. • Издержки на перенос нагрузки с одного на другой процессор соизмерим с физическими размерами этой нагрузки. RCL стратегия использует двухуровневый процесс принятия решений, который объединяет централизованный и децентрализованный подходы. Двухуровневый процесс принятия решений предполагает: Центральный процесс-координатор принимает решение о переносе нагрузки, Каждый отсылающий сообщения процесс ответственен за выбор нагрузки, которую следует перенести. На первом уровне выбирается центральный координатор для того, чтобы среди всех рабочих станций именно он мог принимать решения. Во время процесса переноса нагрузки все рабочие станции приостанавливают свою работу промежуток времени, пока центральный координатор собирает информацию о загрузке процессоров. Координатор анализирует информацию о системе. Эта информация включает сведения о загрузке процессоров и о распределении нагрузки в системе. Координатор, на основании этой информации решает, следует ли предпринимать действия по переносу нагрузки с одного компьютера на другой. Если состояние системы таково, что перенос нагрузки необходим (состояние соответствует критерию переноса нагрузки), центральный координатор начинает процедуру перераспределения нагрузки руководствуясь скоростью работы компьютеров. С другой стороны, если в переносе нагрузки нет необходимости, рабочая станция должна разослать сообщение об этом всем другим хостам. В этом случае действия второго уровня игнорируются, и каждая рабочая станция продолжает обрабатывать свои локальные события. Если, находясь на втором уровне, посылающие данные рабочие станции получат от центрального координатора сигнал о необходимости миграции нагрузки, они начинают процесс выбора части нагрузки для переноса её на другой хост. При выборе используют RCL стратегию. После того, как части нагрузки выбраны на всех пересылающих данные рабочих станциях, начинается процесс миграции (или переноса загрузки). Последовательность шагов, предпринимаемых при миграции нагрузки между двумя хостами, включают упаковку данных и их посылку с посылающей рабочей стации и приём и распаковку у принимающей рабочей станции. В конце каждого шага миграции принимающая рабочая станция рассылает всем остальным сообщение о за-

16

вершении процедуры миграции и о новом размещении данных. После этого каждая рабочая станция продолжает обработку. Использованная литература: 1. Linda F. Wilson and Wei Shen. Experiments In Load Migration And Dynamic Load Balancing In Speedes. Proceedings of the 1998 Winter Simulation Conference.D.J. Medeiros, E.F. Watson, J.S. Carson and M.S. Manivannan, eds, pp.487-490 2. Gengbin Zheng. Achieving High Performance on Extremely Large Parallel Machines: Performance Prediction and Load Balancing; in Ph.D. Thesis, Department of Computer Science, University of Illinois at Urbana-Champaign, 2005, 165p. Доступно на сайте: http://charm.cs.uiuc.edu/ Реко мендуемые про граммные сред ства и литература Технология .NET Remoting Технология .NET Remoting используется для создания распределенных приложений. C помощью данной технологии возможна организация взаимодействия объектов, находящихся в различных доменах приложений (внутри одного процесса, различные процессы на одном компьютере, процессы на разных компьютерах). Логика работы механизма Remoting проста и может быть описана следующим образом. Сервер (приложение предоставляющие свои объекты для использования клиентом) при запуске настраивает Remoting для использования определенного протокола (транспортный протокол, протокол доступа) и регистрирует все классы, к которым он предоставляет доступ. Клиент при необходимости доступа к удаленным объектам также указывает протоколы доступа и посылает запрос на сервер. Сервер в ответ на этот запрос создает у себя затребованный объект и передает его идентификатор клиенту. Клиент создает у себя специальный прокси-класс, который затем и используется, как если бы это был объект в его собственном домене, таким образом клиент может и не подозревать, что работает с удаленным объектом. Для своей работы Remoting использует два вида протоколов: транспортный (TCP, HTTP) и доступа к объектам (бинарный, SOAP). В Remoting объекты могут передаваться либо по значению (by value) либо по ссылке (by reference). При передаче по ссылке передается только идентификатор объекта. Клиент создает специальный прокси-класс, который перенаправляет вызовы методов на сервер и полу17

чает возвращаемые значения. Объект, передаваемый по ссылке, должен наследоваться от объекта MarshalByRefObject. При передаче по значению объект создается на сервере, затем сериализуется и передается клиенту. Для объектов, передаваемых по ссылке, существует два механизма создания объектов: на сервере (server activated) и на клиенте (client activated). Активируемые сервером объекты не создаются на сервере в момент создания клиентом прокси-класса. Вместо этого они создаются в момент первого вызова, или при каждом вызове методов. При этом существуют два типа подобных объектов – Singleton и SingleCall. Первые гарантируют, что реальный экземпляр будет всегда один для всех клиентов. Вторые создают новый объект для каждого вызова метода. Активируемые клиентом объекты, в противоположность активируемым сервером, управляются клиентом. Именно клиент определяет время жизни того или иного экземпляра. Пример приложения .NET Remoting Продемонстрируем работу с .NET Remoting на простом примере. Разработаем класс с единственным методом, который возвращает имя компьютера, на котором он запущен. Для начала работы необходимо реализовать интерфейс удаленного объекта. Данный интерфейс необходимо реализовать в виде отдельной сборки, ссылки на которую необходимо установить как в серверном проекте, так и в клиентском. using System; public interface IRemotingObject { string MachineName {get;} }

Создадим класс, реализуя наш интерфейс и используя передачу по ссылке. using System; namespace RemotingServer { public class RemotingObject : MarshalByRefObject, IRemotingObject { public string MachineName { get { return Environment.MachineName; }

18

} } }

Код сервера представлен ниже. using System; using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Http; namespace RemotingServer { class RemotingServer { [STAThread] static void Main(string[] args) { ChannelServices.RegisterChannel( new HttpChannel(888)); RemotingConfiguration.RegisterWellKnownServiceType( typeof(RemotingObject), "RemotingObject/ro", WellKnownObjectMode.Singleton); Console.WriteLine("Server is running."); Console.WriteLine("Press ENTER to exit"); Console.ReadLine(); } } }

В данном примере мы динамически настраиваем канал связи и регистрируем объект. 888 – это номер http-порта, который будет прослушиваться сервером. Далее мы регистрируем сервер RemotingObject как server activated Singleton-объект, и указываем url, по которому он будет доступен. Полный url объекта будет таким: http://имя_сервера:888/ RemotingObject/ro. Существует еще один способ создания канала и регистрации объектов. Вместо динамической настройки параметров в коде приложения можно дописать секцию в файл конфигурации (application.exe.config). Реализация клиента представлена ниже. using using using using

System; System.Runtime.Remoting; System.Runtime.Remoting.Channels; System.Runtime.Remoting.Channels.Http;

19

namespace RemotingClient { class RemotingClient { [STAThread] static void Main(string[] args) { IRemotingObject ro = (IRemotingObject)Activator.GetObject(typeof( IRemotingObject), "http:// имя_сервера:888/RemotingObject/ro"); Console.WriteLine("Server name is : {0}", ro.MachineName); Console.ReadLine; } } }

На клиенте при помощи статического метода GetObject класса Activator создаем прокси удаленного объекта, вызываем его метод и выводим результат на консоль. Рекомендуемая литература Маклин С., Нафтел Дж., Уильяме К. Microsoft .NET Remoting. М.: Издательско-торговый дом «Русская Редакция», 2003. - 384 с. О тч ёт н о ст ь: В результате выполнения лабораторной работы должны бать представлены следующие материалы: 1. Программа; 2. Исходные тексты; 3. Презентация работы; 4. Презентация, в которой освещаются вопросы реализации оптимистических алгоритмов. 5. Предложения по оптимизации алгоритма.

20