Розподілені системи імітаційного моделювання

Однією з важливих прикладних галузей застосування розосереджених і однорангових мереж, є розподілені системи імітаційного моделювання або симуляції фізичних процесів, зокрема кінематичних характеристик множини об’єктів.

В контексті даної роботи відмінність таких мереж від розглянутих раніше файлообмінних однорангових мереж полягає в зміщенні акценту від швидкості завантаження фіксованої одиниці публікації до зменшення часу затримки відповіді, при чому бажаний ефект може бути досягнутий завдяки одному і тому ж механізму сегментації оверлейних мереж симуляції фізичних процесів.

Для середовищ імітаційного моделювання або симуляції фізичних процесів, зокрема кінематичних характеристик множини об’єктів, доцільно застосовувати додатковий спосіб, який бере до уваги раніше не розглянуту проблему синхронізації характеристик об’єктів в розосереджених мережах.

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

В середині 1990-х років індустрія виробництва комп’ютерних ігор майже одночасно підійшла до двох революційних на той час технологій — жанр симулятора та так званий мультиплеер (від англ. multiplayer — багато гравців).

Жанр симулятора відрізняється від інших поширених ігрових жанрів тим, що основний акцент ігрового процесу поставлено на якомога більшу відповідність реальним об’єктам, діям з ними, взаємодіям між об’єктами симуляції та між гравцями в умовах наближеного до реальності оточуючого середовища. Класичними прикладами в жанрі симуляторів є автомобільні та авіаційні.

Автомобільний симулятор оперує реалістичною моделлю автомобілів, які взаємодіють між собою, покриттям доріг, погодними умовами тощо. Особливу увагу приділяють моделі механічних ушкоджень та характеристик двигунів і трансмісії, розподілу маси в об’ємі об’єктів симуляції, моделюванню взаємодії різних типів шин з різними типами покриття доріг при різних погодних умовах і т.п.

Більш складний піджанр авіаційних симуляторів обов’язково включає так звану «модель польоту», що відповідає за обчислення поведінки літального апарату на основі даних про його просторову конфігурацію, аеродинамічні площини, розташування, тип та потужність двигунів. Враховуються властивості атмосфери в залежності від часу доби, сезону, висоти, типу земної поверхні тощо, а також вносяться реалістичні атмосферні ефекти турбулентності та термальні колони.

Технологія мультиплееру дозволяє кільком гравцям взаємодіяти в одному і тому самому ігровому контексті, такому як спільний сюжет, спільне місце дії, спільне керування одним і тим самим об’єктом тощо.

Поєднання цих двох технологій дозволило на сьогоднішній день створити велику кількість успішних програмних продуктів не тільки розважального напрямку, але і професійних комп’ютеризованих тренувальних середовищ.

Перші спроби створення мультиплеерних ігор базувалися на можливостях зв’язку, доступних для персональних комп’ютерів. Здебільшого це були телефонні модеми, які давали можливість з’єднання на швидкостях від 1.2 до 14.4 Кбіт/сек із середнім часом відповіді в ненавантаженому каналі близько 200-500 мс.

Альтернативою модемному з’єднанню, яка дозволяла підключення більш, ніж 2 гравців одночасно, були локальні мережі того часу, переважна кількість яких була побудована на протоколах, розроблених компанією Novell. Хоча такі локальні мережі дозволяли знизити час затримки відповіді до десятків мілісекунд, вони були практично відсутні в домашньому секторі.

З розвитком технологій зв’язку та дедалі ширшим проникненням мережі Інтернет в усі сфери людської діяльності, стандартом де-факто для сучасних комп’ютерних ігор стала можливість мультиплееру в локальній мережі або на виділених серверах через мережу Інтернет.

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

Ця проблема полягає в тому, що середній час затримки відповіді програмного забезпечення на віддаленому вузлі на команду локального вузла в переважній більшості випадків значно вище, ніж природний час реакції гравця (або час на необхідну дію в симуляторі) при зміні ігрової обстановки.

Якщо при використанні локальних мереж по технології Ethernet при умові відсутності побічного трафіку час затримки відповіді становить 1-2 мсек, то час затримки відповіді від сервера в мережі Інтернет залежить від багатьох факторів. По-перше, це тип та швидкість клієнтського підключення. Наприклад, користувацький асиметричний доступ ADSL на швидкості 512 Кбіт/сек дає затримку проходження пакету даних порядка 10-20 мсек за рахунок буферизації даних при модуляції та демодуляції сигналу.

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

В симуляторах рухомих об’єктів (транспортні або авіаційні засоби) кожен клієнт періодично відправляє на сервер дані про своє місцезнаходження, кінематичний стан та контекст управління. Сервер в реальному масштабі часу оброблює отримані дані, та формує поточний стан ігрового контексту, який періодично відсилається клієнтам.

Можлива ситуація, коли значення затримки проходження даних від сервера до клієнтів значно коливаються, що спричиняє порушення синхронізації ігрового контексту, при цьому на кожному клієнті відображається свій контекст, який за кінематичними параметрами відрізняється від усіх інших (рис.4.13).

Рисунок 4.13. Затримка передавання сигналу в автомобільному симуляторі: ліворуч — позиційні дані від клієнтів до сервера, праворуч — оновлення позицій суперників

Розробники ігрових протоколів намагаються подолати цю проблему. Наприклад, мультиплеер ігри Need For Speed: Porsche Unleashed передбачає два режими оновлення ігрового контексту — позиційний та так званий «обмін вводом» («Input Exchange»). В позиційному режимі в мережу відсилаються оновлення контексту, які містять інформацію про розташування та орієнтацію автомобілів у просторі, тоді як в режимі обміну вводом в оновленнях міститься інформація про натискання керуючих клавіш та стан ігрових контролерів всіх інших гравців, а позиція і ігровий контекст обчислюються локально і незалежно на кожному клієнті.

Режим «обмін вводом» дозволяє за рахунок невеликого збільшення об’єму обчислень зменшити затримку і порушення синхронізації ігрового контексту. Повністю проблему це не вирішує, але дозволяє зменшити затримку до середнього рівня реакції гравця на не-швидкісних лініях зв’язку.

VATSIM (Virtual Air Traffic SIMulator) — середовище глобальної симуляції повітряного руху. Клієнти мережі VATSIM підключаються в одному з трьох режимів — спостерігач, авіадиспетчер або пілот. Відповідно відрізняються програмне забезпечення та спектр виконуваних в ігровому процесі функцій.

Мережа VATSIM складається з кількох територіально розосереджених серверів, взаємозв’язаних між собою для синхронізації ігрового контексту. З клієнтської точки зору, учасник мережі бачить дії та положення інших учасників незалежно від того, чи підключені вони до того самого сервера, що і перший учасник, чи до інших.

Одночасно в мережі VATSIM присутні до 1500 клієнтських підключень, хоча технологічні обмеження на максимальну кількість не оголошені. Протокол взаємодії в мережі є модифікованою версією протоколу FSD (Flight Simulator Daemon, який було розроблено в 1990-х роках) з додаванням авторизації програмного забезпечення по цифровому підпису.

VATSIM не містить центрального серверу, є територіально-розосередженою мережею гібридного типу, концентраторами якої виступають «сервери» а рядовими вузлами — віртуальні пілоти та диспетчери. Як таку її можна розглядати як класичну прикладну реалізацію ІТ із залученням елементів однорангових мереж.

Серверні компоненти VATSIM вимагають досить високої полоси пропускання трафіку для організації зв’язку з іншими серверами: за офіційними вимогами — до 10 МБіт/с гарантованого каналу, тоді як клієнтські підключення без врахування обміну голосовими повідомленнями вимагають ширину каналу порядку одиниць кілобайт за секунду.

Однак навіть за умови гарантованого каналу проблема часу відповіді та порушень синхронізації ігрового контексту властива також і мережі VATSIM. Причиною цього є не тільки природна затримка проходження сигналу, але і специфіка самого протоколу FSD, який передбачає оновлення просторового положення та кінематичних характеристик літального апарату в ігровому контексті мережі лише кожні 5 секунд.

Для нормального функціонування та симуляції всесвітнього повітряного руху цивільної авіації така затримка історично склалася для зменшення навантаження по трафіку на сервери VATSIM, оскільки оновлення просторових координат та кінематичних характеристик становлять більшу частину трафіку мережі. На сьогоднішній день, навіть коли швидкості доступу до мережі Інтернет у кінцевих користувачів значно збільшилися у порівнянні з початком життєвого циклу протоколу FSD, збільшення частоти оновлення просторово-кінематичних характеристик літальних апаратів VATSIM вважається недоцільним — в мережі практично відсутні штатні ситуації, які потребують коротшого часу реакції віртуальних пілотів та диспетчерів.

В той же час стає неможливим виконувати синхронні польоти пілотажних груп в близьких пілотажних формаціях. Наприклад, у фронтальній формації з трьох літаків, кожен з яких одночасно з усіма перетинає спільну нормаль до траєкторії польоту, програмне забезпечення кожного віртуального пілота отримує дані про просторово-кінематичні характеристики інших двох пілотів із затримкою щонайменше на 5 секунд (рис.4.14).

Рисунок 14. Порушення синхронізації ігрового контексту в мережі VATSIM: ліворуч — реальне положення літаків, в центрі — вигляд ігрового контексту з точки зору 1-го пілота, праворуч — вигляд ігрового контексту з точки зору 3-го пілота

Якщо навантаження по трафіку на розосереджену мережу симуляції повітряного (або будь-якого іншого транспортного) руху дійсно накладає обмеження на частоту передавання оновлень кінематичних параметрів, середовище симулятора на клієнтському боці вимушене інтерполювати попередні параметри на весь час до отримання наступних.

У випадку VATSIM, передаються такі кінематичні параметри: територіальні довгота та широта, висота, швидкість, курс, крен, диферент та ознака посадки-зупинки. В результаті повітряне судно, яке виконує маневр розвороту або вирівнювання перед посадкою, може бути зображене як таке, що раптово пересувається в латеральній площині або «занурюється» під покриття злітно-посадочної полоси (рис.4.15).

Рисунок 4.15. Реальні та інтерпольовані траєкторії проходження глісади в мережі VATSIM

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

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

В такому випадку інформація про них буде відправлена в додатковому блоці, що дасть можливість партнерам по мережі симулятора точніше передбачати кінематичні характеристики, застосовуючи математичні методи інтерполяції, наприклад, метод Рунге-Кутта.

В симуляторах з передбаченою можливістю ігрового процесу в нелінійному часі (тобто довільне уповільнення або прискорення течії ігрового часу) створення мультиплеерних режимів довго вважалося неможливим, або пов’язаним із значними труднощами.

Нами запропоновано спосіб, який дозволяє реалізувати ігровий процес в нелінійному часі завдяки відмові від традиційного підходу до мультиплеерного режиму реального часу.

На сьогоднішній день переважна більшість мультиплеерних серверів та систем реалізує модель реального часу в ігровому контексті, коли всі дії та зміни від кожного гравця оброблюються як такі, що трапилися щойно, і сповіщення про це негайно відсилається всім іншим гравцям або тим гравцям, які знаходяться в області видимості першого.

При використання такого підходу учасник мережі симуляції не має можливості поставити ігровий процес на своєму клієнті на паузу, або прискорити чи уповільнити плин часу, або відключитися від мережі без того, щоб не порушити цілісність ігрового контексту. В 1990-х роках розробники мультиплеерних ігор по різному вирішували цю проблему. Наприклад, в іграх від idSoftware, таких як цикл Doom, Heretic та перші випуски Quake, запит паузи на одному з клієнтів в режимі мультиплеера автоматично призупиняв гру на всіх інших. Parallax Software при розробці ігор серії Descent взагалі заборонили тимчасове призупинення ігри в режимі мультиплеера.

Принцип дії системи обчислення ігрового контексту для синхронізації об’єктів з використанням «матриці реальності» зображений на рис.4.16.

Рисунок 4.16. Принцип дії системи обчислення ігрового контексту

Система обчислення ігрового контексту, що буде створена за таким методом, вирішує вищенаведену проблему відмовою від моделі реального часу. Натомість кожен клієнт, що підключається до системи, має можливість створити ігровий об’єкт з будь-якою відносною датою в межах зарані заданого системного часового проміжку. Всі дії об’єкту, його кінематичні характеристики та зміни внутрішнього стану будуть записані системою в БД, так звану «матрицю реальності», до того моменту ігрового часу, коли гравець припинить з’єднання.

Після оновлення матриці реальності будь-який інший гравець, що створює об’єкт в області видимості попереднього та досить близького проміжку часу, отримає від системи ігровий контекст, в якому буде присутній попередній об’єкт, а всі його дії будуть відтворені в ігровому контексті у відповідності до внутрішнього масштабу часу. Відповідно, всі дії, характеристики та зміни стану кожного наступного ігрового об’єкту будуть також записані до матриці реальності.

Учасники мережі симуляції, що приєднуються до системи, будуть мати можливості або створення нового ігрового об’єкту, або використання існуючого з того моменту, коли до системи надійшло його останнє оновлення перед відключенням попереднього гравця.

Така система може бути в подальшому реалізована як платформа для мультиплеерного середовища космічного симулятора OrbiterSim, який відзначається необхідністю надзвичайно широких меж керування динамічним часом.

Поиск по сайту: