на основі багатоконвеєрної, що реконфігурується обчислювального середовища L-Net

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

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

Архітектура розподіленої системи управління

Узагальнена типова архітектура розподіленої системи управління (РСУ) включає три ієрархічно пов'язаних рівня: операторський рівень, рівень управління і рівень введення-виведення (див. рис.1) .

Основним завданням операторського рівня є надання людино-машинного інтерфейсу (ЧМІ) для забезпечення налаштування та контролю функціонування всієї системи. Рівень управління відповідає за отримання та обробку даних з датчиків, передачу даних на операторський рівень та вироблення керуючих впливів на виконавчі пристрої. Рівень введення-виводу є датчиками і виконавчими пристроями, безпосередньо пов'язаними з об'єктом управління.

Завдання програмного забезпечення, у рамках узагальненої архітектури РСУ, полягає у забезпеченні функціонування операторського рівня та його зв'язку з рівнем управління системи. Отже, основним рівнем при проектуванні ПЗ та вирішенні питань його взаємодії з апаратним забезпеченням є операторський. Програмне забезпечення має максимально ефективно використовувати доступні апаратні ресурси системи і при цьому мати максимальну незалежність від внутрішньої архітектури апаратного забезпечення.

Апаратне забезпечення надає обчислювальні ресурси, пам'ять та середовища передачі даних між вузлами в системі. p align="justify"> При проектуванні загальної архітектури системи не розглядаються конкретні вузли рівня введення-виводу, які будуть до неї підключені при конкретній її реалізації, отже, в узагальненій архітектурі розглядаються операторський рівень і рівень управління. Апаратне забезпечення має бути поширеним, відповідати сучасним стандартам, мати всі необхідні для реалізації архітектури властивості та можливості.

Вимоги до РСУ

Вимоги до РСУ відносяться не тільки до системи в цілому, але і до її апаратної та програмної складових окремо, оскільки конкретні підходи до задоволення цих вимог для цих складових можуть відрізнятися. РСУ має бути насамперед відмовостійкою. Найпростішим методом підвищення стійкості до відмови є резервування (дублювання) функціональних вузлів або їх сукупності. Другою важливою властивістю є масштабованість. Масштабованість ґрунтується на реалізації спеціальних алгоритмів у ПЗ та апаратної можливості заміни та додавання нових вузлів або їх складових частин. При цьому система повинна залишатися простою для її експлуатації, розробки нових вузлів або модулів та модифікації її архітектури.

Огляд архітектури РСУ

Для проведення огляду архітектури РСУ були обрані РСУ Siemens SIMATIC PCS 7 як одна з найбільш затребуваних на ринку та RTS S3 як РСУ, реалізована на базі ОСРВ QNX.

Siemens SIMATIC PCS 7

Архітектура системи має всі властивості узагальненої архітектури РСУ. Як операторські станції виступають комп'ютери на базі процесорної архітектури x86 з ОС Windows і пакетом Siemens WinCC, що надає ЧМІ. Є сервери з базами даних. Станції операторів, інженерні станції та сервери пов'язані локальною мережею на основі Ethernet. Операторський рівень пов'язаний із рівнем управління зарезервованою мережею Industrial Ethernet. На рівні управління знаходяться програмовані логічні контролери (ПЛК) із можливістю резервування за рахунок дублювання функціоналу. Є можливість підключатися до зовнішніх систем та мереж та організувати віддалений доступ до системи.

RTS S3

Ця архітектура аналогічно складається з рівнів узагальненої структури РСУ. Операторські станції засновані на тій же апаратній платформі, що і в SIMATIC РСУ, але можуть перебувати під управлінням як ОС Windows, так і Linux. Інженерні станції поєднані з операторськими. Системою надається єдине середовище розробки програм. Мережа Ethernetз'єднує вузли всередині операторського рівня та сам операторський рівень з рівнем управління з використанням стека протоколів TCP/IP. На рівні управління знаходяться промислові комп'ютери під управлінням ОС QNX із власною базою даних та можливістю резервування шляхом дублювання функціоналу вузла.

Недоліки описаних систем

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

Характеристики та функціональні особливості системи L-Net

При розробці системи L-Net ставилося завдання створити таку систему управління, яка матиме перелічені нижче характеристики:

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

Для побудови системи з вищеописаними характеристиками потрібна операційна система, призначена переважно для створення систем управління та систем, що вбудовуються. Аналіз існуючих операційних систем показав, що найбільш підходящою операційною системою є ОС QNX 6 (Neutrino), яка має дуже ефективні ресурсорозподільні та мережеві можливості. Широкі мережеві можливостізабезпечуються мережним протоколом Qnet. Він вирішує завдання надійності та динамічного балансування навантаження каналів зв'язку, але при цьому не вирішуються проблеми відмовостійкості системи в цілому. В результаті була розроблена інноваційна система управління, заснована на розподіленому багатоконвеєрному обчислювальному середовищі, що реконфігурується. Розроблена система має однорангову архітектуру, що включає три логічні блоки: блок введення-виводу, блок комутаторів загального призначення і блок обчислювального середовища, що реконфігурується (РВС) (див. рис.2).

Основними перевагами даної архітектури є:

• Одноранговий тип
• Децентралізованість
• Масштабованість
• Просторова розподіленість

Функціональні особливості даної архітектури:

• Конвеєрне оброблення даних
• Апаратне резервування
• Розподіл навантаження
• Реконфігурація «на льоту»

На першому рівні архітектури знаходиться блок введення-виводу (I/O), що включає: вузли введення-виводу, комутатор вузлів введення-виводу, інтерфейс введення-виводу, датчики і виконавчі пристрої. Блок відповідає за базові механізми формування керуючих впливів на підставі даних локальних датчиків і даних, отриманих від інших рівнів системи управління. Поставлені завдання розподіляються між працездатними вузлами вводу-виводу на підставі їхньої поточної відносної продуктивності або вручну оператором. Датчики та виконавчі пристрої підключені за допомогою шини до всіх вузлів вводу-виводу в блоці, що дозволяє будь-якому вузлу опитувати будь-який датчик або виробляти вплив на будь-який виконавчий пристрій. Комутатор вузлів введення-виведення забезпечує зв'язок між усіма вузлами введення-виводу для обміну даними між ними та іншими рівнями архітектури системи для отримання керуючих та інформаційних даних. За наявності відповідних апаратних можливостей вузли зв'язуються між собою та з вузлами та комутаторами на інших рівнях системи безпосередньо, що зменшує час реакції в мережі. Прямий зв'язок між вузлами та певна завантаженість вузлів у поточному режимі роботи блоку введення-виведення дозволяє організовувати в блоці конвеєрні обчислення, необхідні для функціонування цього блоку без звернення до зовнішніх обчислювальних потужностей системи управління (РВС), що дозволяє ефективно використовувати вільні ресурси, надані для резервування вузлів блоку введення-виведення на момент відмови.

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

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

Розподіл навантаження

Одним із основних завдань системи L-Net є розподіл обчислювального навантаження на вузлах мережі. Розв'язання цього завдання полягає в побудові обчислювальних конвеєрів. Для побудови обчислювального конвеєра попередньо будується графік завдання – схема обміну потоками даних від джерела до одержувача. Як джерело виступають датчики, а як одержувач – виконавчі механізми. Сам обчислювальний конвеєр є відображенням графа завдання (див. рис.3) на граф обчислювальної мережі (див. рис.4) з урахуванням вимог завдання до обчислювальних ресурсів системи та поточного її стану.

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

Відмовостійкість

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

• Реконфігурація за фактом відмови– після виявлення відмови проводяться пошук доступного апаратного забезпечення та його включення до графа завдання.
• Реконфігурація з пасивною готовністю- Що резервує апаратне забезпеченнявизначається заздалегідь, запускається процес, що забезпечує реалізацію вершини графа завдання на вузлі, встановлюються з'єднання, але процес не виробляє обробку даних, якщо не відбулося відмовлення основного вузла.
• Реконфігурація з активною готовністю– вершина графа завдання реалізується на кількох вузлах, які паралельно виконують обробку даних та передають результат.

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

Висновок

Розроблена система L-Net на відміну від існуючих аналогів передбачає використання широкого спектра апаратних характеристик вузлів РСУ за повної їхньої програмної сумісності. Під час роботи вузлів під управлінням однієї операційної системи (QNX Neutrino) забезпечується можливість їх побудови на різних процесорних архітектурах (x86, ARM, MIPS тощо) з різноманітними наборами інтерфейсів та периферійних пристроїв. Реалізація вузлів можлива як настільних, промислових ПК, носимих ПК і одноплатних комп'ютерів. Усі складові комплексу програмного забезпечення РСУ можуть бути запущені на будь-якому її вузлі з ОС QNX, при цьому залишається можливість використання вузлів з іншою операційною системою. Такий підхід дозволяє використовувати кожен вузол для розв'язання задач як операторського рівня, і рівня управління. Отже, є гнучка системавзаємодії між одноранговими вузлами без жорсткої ієрархії рівнів, властивою узагальненій архітектурі РСУ та системам, що використовують цю архітектуру як базову. Одноранговість мережі спрощує процеси розгортання, експлуатації, масштабування та налагодження системи.

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

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

Висновок

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

1. http://kazanets.narod.ru/DCSIntro.htm.
2. http://kazanets.narod.ru/PCS7Overview.htm.
3. http://www.rts.ua/rus/news/678/0/409.
4. Зиль С. QNX Momentics: основи застосування. - СПб: БХВ-Петербург, 2005.
5. Кртен Р. Вступ до QNX Neutrino. Посібник для розробки програм реального часу. - СПб: БХВ-Петербург, 2011.

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

Architecture of a distributed control system based on reconfigurable multi-pipeline computing environment L-Net

Sergey Yu. Potomskiy, Assistant Professor of National Research University «Higher School of Economics».

Nikita A. Poloyko, Fifth-year student of National Research University «Higher School of Economics». Study assistant. Programmer. Field of training: "Control and informatics in the technical systems".

Abstract.Цей матеріал є розвиненим для розповсюдженого системного управління, що базується на reconfigurable multi-pipeline computing environment. Architecture of the system is given. Also, основними характеристиками і функціональними властивостями системи є given too. Articles presents a rationale for the choice of the operating system. Основні переваги системи в comparison with existing similar developments are shown in the article.

Keywords: distributed control system, systems software support, distributed reconfigurable.

Вконтакте

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

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

ІС можна уявити таку, що складається з наступних складових частин (Рис. III-16)

ІІІ.03.2. a Файл-серверні програми.

Це історично перша розподілена архітектура (Мал. III-17). Організується вона дуже просто: на сервері знаходяться лише дані, а все інше відноситься до клієнтської машини. Оскільки локальні мережі досить дешеві, і в силу того, що при такій архітектурі прикладне ПЗ автономне, така архітектура досить часто використовується і зараз. Можна сказати, що це варіант клієнт-серверної архітектури, коли на сервері знаходяться тільки файли даних. Різні персональні комп'ютери взаємодіють лише засобами загального сховища даних, тому програми, написані з розрахунку на один комп'ютер найпростіше адаптувати під таку архітектуру.

Плюси:

Плюси файл-серверної архітектури:

Простота організації;

Не суперечить необхідним вимогам до БД підтримки цілісності і надійності.

Перевантаження мережі;

Непередбачуваність реакцію запит.

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

ІІІ.03.2. b Клієнт-серверні програми.

У цьому випадку має місце розподіл обов'язків між сервером та клієнтом. Залежно від того, як вони розділені розрізняють товстогоі тонкого клієнта.

У моделі "тонкий клієнт" вся робота програми та управління даними виконуються на сервері. Інтерфейс користувача в цих системах "переселяється" на персональний комп'ютер, а саме програмний додатоквиконує функції сервера, тобто. виконує всі процеси програми та керує даними. Модель тонкого клієнта також можна реалізувати там, де клієнти комп'ютери або робочі станції. Мережеві пристрої запускають Internet-броузер і інтерфейс користувача, реалізований усередині системи.

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

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

ІІІ.03.2. c Дво- та трирівневі архітектури клієнт-сервер.

Усі розглянуті вище архітектури є дворівневими. Вони різниться рівень клієнта і рівень сервера. Строго кажучи, ІС складається із трьох логічних рівнів:

· Рівень користувача;

· Рівень програми:

· Рівень даних.

Тому у дворівневій моделі, де задіяні лише два рівні, виникає проблема з масштабованістю та продуктивністю, якщо обрана модель тонкий клієнт, або проблеми пов'язані з управлінням системи, якщо взята модель товстий клієнт. Уникнути цих проблем можна, якщо застосовувати модель, що складається з трьох рівнів, де два з них сервери (Мал. III-21).

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

Таблиця III‑5 Застосування різних типів архітектур

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

ІІІ.03.2. d Архітектура розподілених об'єктів.

p align="justify"> Більш загальний підхід забезпечує архітектура розподілених об'єктів, основними компонентами якої є об'єкти. Вони пропонують набір послуг через свої інтерфейси. Інші об'єкти надсилають запити, у своїй немає різниці між клієнтом і сервером. Об'єкти можуть розташовуватися на різних комп'ютерах у мережі та взаємодіяти за допомогою проміжного ПЗ, за аналогією системної шини, яка дозволяє підключати різні пристрої та підтримувати взаємодію між апаратними пристроями.

Архітектура ODBC включає компоненти:

1. Програма (наприклад, ІС). Воно виконує завдання: запитує з'єднання з джерелом даних, посилає SQL - запити до джерела даних, описує область зберігання та формат для SQL - запитів, обробляє помилки та сповіщає про них користувача, здійснює фіксацію або відкат транзакцій, запитує з'єднання з джерелом даних.

2. Диспетчер пристроїв. Він завантажує драйвера на вимогу додатків, пропонує єдиний інтерфейс усім додаткам, причому інтерфейс адміністратора ODBC однаковий і незалежний від того, з якою СУБД додаток буде взаємодіяти. Диспетчер драйверів, що поставляється Microsoft, є бібліотекою DLL, що динамічно завантажується.

3. Драйвер залежить від СУБД. Драйвер ODBC – це динамічна бібліотека DLLяка реалізує функції ODBC і взаємодіє з джерелом даних. Драйвер – це програма, яка обробляє запит якоїсь функції специфічно для СУБД (може модифікувати запити відповідно до СУБД) та повертає результат додатку. Кожна СУБД, яка підтримує технологію ODBC, має надати розробникам додатків драйвер для цієї СУБД.

4. Джерело даних містить керуючу інформацію, що задається користувачем, інформацію про джерело даних та використовується для доступу до конкретної СУБД. При цьому використовуються засоби ОС та мережевої платформи.

Динамічна модель

Ця модель передбачає багато аспектів, для представлення яких мовою UML використовується як мінімум 5 діаграм див. 2.04.2-2.04.5.

Розглянемо аспект управління. Модель керування доповнює структурні моделі.

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

Можна виділити два основних типи управління у програмних системах.

1. Централізоване управління.

2. Управління, засноване на подіях.

Централізоване управління може бути:

· Ієрархічним- за принципом «виклик-повернення» (саме так найчастіше працює навчальні програми)

· Модель диспетчераяка застосовується для паралельних систем.

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

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

Прикладом такого управління є організація програм у Windows.

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

Користувальницький інтерфейс

Під час розробки моделі інтерфейсу слід враховувати як завдання проектованого ПЗ, а й особливості мозку, пов'язані з сприйняттям інформації.

ІІІ.03.4. a Психофізичні особливості людини, пов'язані зі сприйняттям та обробкою інформації.

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

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

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

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

Короткострокова пам'ять – найвужче місце у системі обробки інформації людини. Її ємність дорівнює 7±2 незв'язаних об'єктів. Незатребувана інформація зберігається у ній трохи більше 30 секунд. Щоб не забути якусь важливу для нас інформацію, ми зазвичай повторюємо її про себе, оновлюючи інформацію у короткостроковій пам'яті. Таким чином, при проектуванні інтерфейсів слід мати на увазі, що переважній більшості складно, наприклад, запам'ятати та ввести на іншому екрані числа, що містять понад п'ять цифр.

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

ІІІ.03.4. b Основні критерії оцінки інтерфейсів

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

1) простоту освоєння та запам'ятовування - конкретно оцінюють час освоєння та тривалість збереження інформації та пам'яті;

2) швидкість досягнення результатів при використанні системи, яка визначається кількістю команд, що вводяться або вибираються, і налаштувань;

3) суб'єктивну задоволеність при експлуатації системи (зручність роботи, стомлюваність тощо).

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

З цього погляду на сьогодні найкращими характеристикамидля користувачів-професіоналів мають інтерфейси з вільною навігацією, а для користувачів-непрофесіоналів - інтерфейси прямого маніпулювання. Давно помічено, що з виконанні операції копіювання файлів за інших рівних умов більшість фахівців використовують оболонки типу Far, а непрофесіонали - «перетягування об'єктів» Windows.

ІІІ.03.4. c Типи інтерфейсів користувача

Розрізняють такі типи інтерфейсів користувача:

Примітивні

Зі вільною навігацією

Прямого маніпулювання.

Інтерфейс примітивний

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

Інтерфейс меню.

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

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

Починають застосовуватися практично мобільні архітектури. Це стосується як систем баз даних, і до додатків Web.

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

У зв'язку з інтенсивним розвитком комунікаційних технологій активно розвиваються мобільні АІС. Розроблено технічні засоби та програмне забезпеченнядля їхнього створення. Завдяки цьому стали розвиватися мобільні системи баз даних. Багато наукових колективів проводять дослідження специфічних особливостей таких систем, створюють різноманітні їх прототипи. Важливим інструментом розробки мобільного програмного забезпечення стали технології Java.

Створено стандарт протоколу бездротового доступупрограм у Web (Wireless Application Protocol - WAP), який вже підтримується деякими моделями стільникових телефонів. На основі WAP та мови XML консорціум W3C розробив мову розмітки для бездротових комунікацій WML (Wireless Markup Language).

У розробках АІС більше уваги приділяли метаданим. Тут робляться кроки у двох напрямках - стандартизація уявлення метаданих та забезпечення їх підтримки у системі.

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

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

Ймовірно, першим стандартом де-факто цієї категорії була мова опису даних CODASYL для баз даних мережевий структури. З пізніших стандартів слід назвати: стандарт мови запитів SQL для реляційних баз даних, що містить визначення так званої інформаційної схеми - сукупності уявлень схем реляційних баз даних; компонент стандарту об'єктних баз даних ODMG, що описує інтерфейси репозиторію об'єктних схем; міжнародний стандарт IRDS (Information Resource Dictionary Systems), що описує системи для створення та підтримки довідників інформаційних ресурсів організації.

Далі слід згадати розроблений консорціумом OMG стандарт CWM (Common Warehouse Metamodel) представлення метаданих сховищ даних, заснований на раніше створеному для більш широких цілей стандарті OIM (Open Information Model) консорціуму MDC (Meta Data Coalition).

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

До стандартів метаданих Web відноситься підмножина мови XML, що використовується для опису логічної структури XML-документів деякого типу. Цей опис називається DTD (Document Type Definition). Крім того, платформа XML включає стандарт XML Schema, що пропонує більш розвинені можливості опису XML-документів. Стандарт RDF (Resource Definition Framework) визначає просту мову представлення знань для опису вмісту XML-документів. Нарешті, стандарт OWL (Ontology Web Language) визначає формальну мову опису онтології, призначений для семантичного Web.

Стандарт мови UML (Unified Modeling Language), що забезпечує представлення метаданих інструментів CASE для об'єктного візуального аналізу та проектування, розроблений консорціумом OMG. Ця мова підтримується у багатьох програмних продуктах CASE. Консорціум OMG також створив стандарт XMI (XML Metadata Interchange) для обміну метаданими між інструментами CASE, що використовують мову UML.

Слід згадати тут також стандарт Дублінського ядра (Dublin Core – DC) – набору елементів метаданих для опису змісту документів різної природи. Цей стандарт швидко набув популярності і знайшов, зокрема, широке застосування в середовищі Web(Див. Розд. 3.3).

Роботи з розвитку існуючих та створення нових стандартів уявлення метаданих для АІС продовжуються. Більше докладні відомостіпро аналізовані стандарти можна знайти в енциклопедії.

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

Оскільки в наші дні розподілені системи набули широкого поширення, розробники ПЗ повинні бути знайомі з особливостями їхнього проектування. Донедавна все великі системи в основному були централізованими, які запускалися на одній головній обчислювальній машині (мейнфреймі) з підключеними до неї терміналами. Термінали практично не займалися обробкою інформації – всі обчислення виконувались головною машиною. Розробникам таких систем не доводилося замислюватися над проблемами розподілених обчислень.

Всі сучасні програмні системи можна розділити на три великі класи.

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

2. Вбудовані системи, призначені для роботи на одному процесорі або на інтегрованій групі процесорів. До них відносяться системи управління побутовими пристроями, різними приладами та ін.

3. Розподілені системи, в яких програмне забезпечення виконується на слабко інтегрованій групі процесорів, що працюють паралельно, пов'язаних через мережу. До них відносяться системи банкоматів, що належать якомусь банку, видавничі системи, системи ПЗ колективного користування та ін.

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

Виділено шість основних параметрів розподілених систем.

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

2. Відкритість.Це можливість розширювати систему шляхом додавання нових ресурсів. Розподілені системи – це відкриті системи, До яких підключають апаратне та програмне забезпечення від різних виробників.

3. Паралельність.У розподілених системах кілька процесів можуть одночасно виконуватись на різних комп'ютерах у мережі. Ці процеси можуть (але не обов'язково) взаємодіяти один з одним під час виконання.

4. Масштабованість.У принципі, всі розподілені системи є масштабованими: щоб система відповідала новим вимогам, її можна нарощувати за допомогою додавання нових обчислювальних ресурсів. Але на практиці нарощування може обмежуватися мережею, що об'єднує окремі комп'ютери системи. Якщо підключити багато нових машин, пропускна здатністьмережі може виявитися недостатньою.

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

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

Зрозуміло, розподіленим системам властивий ряд недоліків.

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

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

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

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

При обговоренні переваг та недоліків розподілених систем визначається низка критичних проблем проектування таких систем (табл. 9.1).

Таблиця 9.1. Проблеми проектування розподілених систем

Завдання розробників розподілених систем – спроектувати програмне чи апаратне забезпечення те щоб надати всі необхідні характеристики розподіленої системи. А для цього потрібно знати переваги та недоліки різних архітектуррозподілених систем. Тут виділяється два родинні типи архітектур розподілених систем.

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

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

У розподіленій системі різні системні компоненти можуть бути реалізовані різними мовами програмування і виконуватися різних типахпроцесорів. Моделі даних, представлення інформації та протоколи взаємодії – все це не обов'язково буде однотипним у розподіленій системі. Отже, для розподілених систем необхідне таке програмне забезпечення, яке могло б керувати цими різнотипними частинами та гарантувати взаємодію та обмін даними між ними. Проміжне програмне забезпеченнявідноситься саме до такого класу ПЗ. Воно перебуває хіба що посередині між різними частинами розподілених компонентів системи.

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

У попередньому розділі нами було розглянуто сильнопов'язані багатопроцесорні системи із загальною пам'яттю, загальними структурамиданих ядра та загальним пулом, з якого процеси викликаються на виконання. Часто, однак, буває бажано з метою забезпечення спільного використанняресурсів розподіляти процесори таким чином, щоб вони були автономні від операційного середовища та умов експлуатації. Нехай, наприклад, користувачеві персональної ЕОМ потрібно звернутися до файлів, що знаходяться на більшій машині, але зберегти при цьому контроль над персональною ЕОМ. Незважаючи на те, що окремі програми, такі як uucp, підтримують передачу файлів через мережу та інші мережеві функції, їх використання не буде приховано від користувача, оскільки користувач знає про те, що він працює в мережі. Крім того, слід зазначити, що програми, подібні текстовим редакторам, з віддаленими файлами, як із звичайними, не працюють. Користувачі повинні мати стандартний набір функцій системи UNIX і, за винятком можливої ​​втрати у швидкодії, не повинні відчувати перетину машинних кордонів. Так, наприклад, робота системних функцій open та read з файлами на віддалених машинахне повинна відрізнятися від їхньої роботи з файлами, що належать локальним системам.

Архітектура розподіленої системи представлена ​​на малюнку 13.1. Кожен комп'ютер, показаний малюнку, є автономним модулем, що з ЦП, пам'яті і периферійних пристроїв. Відповідність моделі не порушується навіть незважаючи на те, що комп'ютер не має локальної файлової системи: він повинен мати периферійні пристрої для зв'язку з іншими машинами, а всі його файли можуть розташовуватися і на іншому комп'ютері. Фізична пам'ять, доступна кожній машині, залежить від процесів, виконуваних інших машинах. Цією особливістю розподілені системи відрізняються від сильнопов'язаних багатопроцесорних систем, розглянутих у попередньому розділі. Відповідно, ядро ​​системи на кожній машині функціонує незалежно від зовнішніх умов експлуатації розподіленого середовища.

Малюнок 13.1. Модель системи із розподіленою архітектурою

Розподілені системи, добре описані у літературі, традиційно поділяються на такі категорії:

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

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

Абсолютно "прозорі" розподілені системи, у яких для звернення до файлів, розташованих на інших машинах, достатньо вказівки їх стандартних складових імен; розпізнавання цих файлів як віддалених входить у обов'язки ядра. Маршрути пошуку файлів, зазначені в їх складових іменах, перетинають машинні межі в точках монтування, скільки б таких точок не було сформовано при монтуванні файлових систем на дисках.

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

Архітектура периферійної системи показана на малюнку 13.2. Мета такої конфігурації полягає у підвищенні загальної продуктивності мережі за рахунок перерозподілу виконуваних процесів між центральним та периферійними процесорами. У кожного з периферійних процесорів немає інших локальних периферійних пристроїв, крім тих, які йому потрібні для зв'язку з центральним процесором. Файлова система та всі пристрої знаходяться у розпорядженні центрального процесора. Припустимо, що всі процеси користувача виконуються на периферійному процесорі і між периферійними процесорами не переміщуються; будучи одного разу передані процесору, вони перебувають у ньому досі завершення. Периферійний процесор містить полегшений варіант операційної системи, призначений для обробки локальних звернень до системи, управління перериваннями, розподілу пам'яті, роботи з мережними протоколами та драйвером пристрою зв'язку з центральним процесором.

При ініціалізації системи на центральному процесорі ядро ​​лініями зв'язку завантажує кожному з периферійних процесорів локальну операційну систему. Будь-який процес, що виконується на периферії, пов'язаний з процесом-супутником, що належить центральному процесору(див.); коли процес, що протікає на периферійному процесорі, викликає системну функцію, яка потребує послуг виключно центрального процесора, периферійний процес зв'язується зі своїм супутником і запит надходить на обробку на центральний процесор. Процес-супутник виконує системну функцію та посилає результати назад на периферійний процесор. Взаємини периферійного процесу зі своїм супутником схожі на відносини клієнта та сервера, докладно розглянуті нами у розділі 11: периферійний процес виступає клієнтом свого супутника, який підтримує функції роботи з файловою системою. При цьому віддалений процес-сервер має лише одного клієнта. У розділі 13.4 ми розглянемо процеси-сервери з кількома клієнтами.

Малюнок 13.2. Конфігурація периферійної системи

Малюнок 13.3. Формати повідомлень

Коли периферійний процес викликає системну функцію, яку можна обробити локально, ядру немає потреби надсилати запит процесу-супутнику. Так, наприклад, для отримання додаткової пам'яті процес може викликати для локального виконання функцію sbrk. Однак, якщо потрібні послуги центрального процесора, наприклад, щоб відкрити файл, ядро ​​кодує інформацію про параметри, що передаються викликаної функції, і умови виконання процесу в якесь повідомлення, що посилається процесу-супутнику (Малюнок 13.3). Повідомлення включає в себе ознаку, з якої випливає, що системна функція виконується процесом-супутником від імені клієнта, параметри, що передаються, і дані про середовище виконання процесу (наприклад, користувальницький і груповий коди ідентифікації), які для різних функцій різні. Частина повідомлення, що залишилася, являє собою дані змінної довжини (наприклад, складове ім'я файлу або дані, призначені для запису функцією write).

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

Для того, щоб пояснити, як працює периферійна система, розглянемо ряд функцій: getppid, open, write, fork, exit і signal. Функція getppid досить проста, оскільки вона пов'язана з простими формами запиту та відповіді, якими обмінюються периферійний та центральний процесори. Ядро на периферійному процесорі формує повідомлення, що має ознаку, з якого випливає, що функцією, що запитується, є функція getppid, і посилає запит центральному процесору. Процес-супутник на центральному процесорі читає повідомлення з периферійного процесора, розшифровує тип системної функції, виконує її та отримує ідентифікатор свого батька. Потім він формує відповідь і передає його периферійного процесу, що знаходиться в стані очікування на іншому кінці лінії зв'язку. Коли периферійний процесор отримує відповідь, він передає його процесу, що спричинив системну функцію getppid. Якщо ж периферійний процес зберігає дані (такі, як ідентифікатор процесу-батька) у локальній пам'яті, йому взагалі доведеться зв'язуватися зі своїм супутником.

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

Малюнок 13.4. Виклик функції open із периферійного процесу

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

Єдиною функцією, яка потребує внесення змін під час роботи на центральному процесорі, є системна функція fork. Коли процес виконує цю функцію на ЦП, ядро ​​вибирає йому периферійний процесор і посилає повідомлення спеціальному процесу - серверу, інформуючи останній у тому, що збирається розпочати вивантаження поточного процесу. Припускаючи, що сервер прийняв запит, ядро ​​за допомогою функції fork створює новий периферійний процес, виділяючи запис у таблиці процесів та адресний простір. Центральний процесор вивантажує копію процесу, що викликав функцію fork, на периферійний процесор, затираючи щойно виділений адресний простір, породжує локальний супутник зв'язку з новим периферійним процесом і посилає на периферію повідомлення необхідність ініціалізації лічильника команд нового процесу. Процес-супутник (на ЦП) є нащадком процесу, що спричинив функцію fork; периферійний процес з технічної точки зору виступає нащадком процесу-сервера, але за логікою є нащадком процесу, що викликав функцію fork. Процес-сервер немає логічного зв'язку з нащадком після завершення функції fork; єдине завдання сервера полягає у наданні допомоги при розвантаженні нащадка. Через сильний зв'язок між компонентами системи (периферійні процесори не мають автономії) периферійний процес і процес-супутник мають один і той же код ідентифікації. Взаємозв'язок між процесами показаний на Рисунку 13.5: безперервною лінією показано зв'язок типу "батько-нащадок", пунктиром - зв'язок між рівноправними партнерами.

Малюнок 13.5. Виконання функції fork на центральному процесорі

Коли процес виконує функцію fork на периферійному процесорі, він посилає повідомлення своєму супутнику на ЦП, який виконує після цього всю вищеописану послідовність дій. Супутник вибирає новий периферійний процесор і робить необхідні приготування до вивантаження образу старого процесу: посилає периферійному процесу-батькові запит на читання його образу, у відповідь який на іншому кінці каналу зв'язку починається передача даних, що запитуються. Супутник зчитує переданий образ і переписує його периферійному нащадку. Коли вивантаження образу закінчується, процес-супутник виконує функцію fork, створюючи свого нащадка на ЦП, і передає значення лічильника команд на периферійному нащадку, щоб останній знав, з якого адреси починати виконання. Очевидно, було б краще, якби нащадок процесу-супутника призначався периферійному нащадку як батько, проте в нашому випадку породжені процеси отримують можливість виконуватися і на інших периферійних процесорах, а не тільки на тому, на якому вони створені. Взаємозв'язок між процесами після завершення функції fork показано на малюнку 13.6. Коли периферійний процес завершує свою роботу, він посилає відповідне повідомлення процесу-супутникові і той також завершується. Від процесу-супутника ініціатива завершення роботи виходити не може.

Малюнок 13.6. Виконання функції fork на периферійному процесорі

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

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

алгоритм sighandle /* алгоритм обробки сигналів */

if (поточний процес є чиїмось супутником або має прототип)

if (сигнал ігнорується)

if (сигнал надійшов під час виконання системної функції)

поставити сигнал перед процесом-супутником;

надіслати повідомлення про сигнал периферійного процесу;

else ( /* периферійний процес */

/* надійшов сигнал під час виконання системної функції чи ні */

надіслати сигнал процесу-супутнику;

алгоритм satellite_end_of_syscall /* завершення системної функції, спричиненої периферійним процесом */

вхідна інформація: відсутня

вихідна інформація: відсутня

if (під час виконання системної функції надійшло переривання)

надіслати периферійному процесу повідомлення про переривання, сигнал;

else /* виконання системної функції не переривалося */

надіслати відповідь: увімкнути прапор, що показує надходження сигналу;

Рисунок 13.7. Обробка сигналів у периферійній системі

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

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

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

3. Якщо після отримання сигналу процес-супутник перериває виконання системної функції (longjmp), він інформує про це периферійний процес і повідомляє йому номер сигналу.

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

Рисунок 13.8. Переривання під час виконання системної функції

Припустимо, наприклад, що периферійний процес викликає функцію читання з терміналу, пов'язаного з центральним процесором, і зупиняє роботу на час виконання функції процесом-супутником (Рисунок 13.8). Якщо користувач натискає клавішу переривання (break), ядро ​​ЦП посилає процес-супутнику відповідний сигнал. Якщо супутник перебував у стані приостанова в очікуванні введення з терміналу порції даних, він негайно виходить із цього стану та припиняє виконання функції read. У своїй відповіді на запит периферійного процесу супутник повідомляє код помилки та номер сигналу, що відповідає перериванню. Периферійний процес аналізує відповідь і оскільки в повідомленні йдеться про надходження сигналу переривання, відправляє сигнал самому собі. Перед виходом із функції read периферійне ядро ​​здійснює перевірку надходження сигналів, виявляє сигнал переривання, що надійшов від процесу-супутника, та обробляє його звичайним порядком. Якщо в результаті отримання сигналу переривання периферійний процес завершує свою роботу за допомогою функції exit, ця функція бере турботу про знищення процесу-супутника. Якщо периферійний процес перехоплює сигнали переривання, він викликає функцію користувачаобробки сигналів і після виходу з функції read повертає користувачеві код помилки. З іншого боку, якщо супутник виконує від імені периферійного процесу системну функцію stat, він не перериватиме її виконання при отриманні сигналу (функції stat гарантований вихід з будь-якого призупину, оскільки для неї час очікування ресурсу обмежений). Супутник доводить виконання функції остаточно і повертає периферійному процесу номер сигналу. Периферійний процес посилає сигнал самому собі та отримує його на виході із системної функції.

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

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

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

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

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

Для ідентифікації віддалених файлів у цих системах використовується один із наступних двох шляхів. В одних системах до складу ім'я файлу додається спеціальний символ: компонента імені, що передує цьому символу, ідентифікує машину, решта імені - файл, що знаходиться на цій машині. Так, наприклад, складове ім'я

"sftig!/fs1/mjb/rje"

ідентифікує файл "/fs1/mjb/rje", що знаходиться на машині "sftig". Така схема ідентифікації файлу відповідає угоді, встановленому програмою uucp щодо передачі файлів між системами типу UNIX. В іншій схемі видалені файли ідентифікуються додаванням до імені спеціального префікса, наприклад:

/../sftig/fs1/mjb/rje

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

Малюнок 13.9. Формулювання запитів до файлового сервера (процесора)

Всю частину розділу, що залишилася, ми присвятимо розгляду моделі системи, що використовує зв'язок типу Newcastle, в якій ядро ​​не займається розпізнаванням віддалених файлів; ця функція повністю покладається на підпрограми зі стандартної Бібліотеки, що виконують у цьому випадку роль системного інтерфейсу. Ці підпрограми аналізують першу компоненту імені файлу, обох описаних способах ідентифікації містить ознаку віддаленості файлу. У цьому полягає відступ від закладеного порядку, у якому бібліотечні підпрограми займаються синтаксичним розбором імен файлів. На малюнку 13.9 показано, як формулюються запити до файлового серверу. Якщо файл локальний, ядро ​​локальної системи обробляє запит звичайним способом. Розглянемо зворотний випадок:

open("/../sftig/fs1/mjb/rje/file", O_RDONLY);

Підпрограма open із Сі-бібліотеки аналізує перші дві компоненти складеного імені файлу та дізнається, що файл слід шукати на віддаленій машині "sftig". Щоб мати інформацію про те, чи був раніше у процесу зв'язок з даною машиною, підпрограма заводить спеціальну структуру, в якій запам'ятовує цей факт, і у разі негативної відповіді встановлює зв'язок із файловим сервером, що працює на віддаленій машині. Коли процес формулює свій перший запит на дистанційну обробку, віддалений сервер підтверджує запит, у разі потреби веде запис у поля користувальницького та групового кодів ідентифікації та створює процес супутник, який виступатиме від імені процесу-клієнта.

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

Більш делікатним питанням є отримання роботи з віддаленими файлами прав суперкористувача. З одного боку, клієнт-суперкористувач не повинен мати ті ж права щодо віддаленої системи, щоб не вводити в оману засоби захисту віддаленої системи. З іншого боку, деякі програми, якщо їм не надати права суперкористувача, просто не зможуть працювати. Прикладом такої програми є програма mkdir (див. Розділ 7), що створює новий каталог. Віддалена система не дозволила б клієнту створювати новий каталог, оскільки видалення права суперкористувача не діють. Проблема створення віддалених каталогів є серйозною підставою для перегляду системної функції mkdir у бік розширення її можливостей у автоматичному встановленні всіх необхідних користувачеві зв'язків. Тим не менш, отримання setuid-програмами (до яких відноситься і програма mkdir) прав суперкористувача по відношенню до віддалених файлів все ще залишається загальною проблемою, яка потребує свого вирішення. Можливо, що найкращим вирішенням цієї проблеми було б встановлення файлів додаткових характеристик, що описують доступ до них з боку віддалених суперкористувачів; на жаль, це потребувало б внесення змін до структури дискового індексу (у частині додавання нових полів) і породило б занадто великий безлад у існуючих системах.

Якщо підпрограма open завершується успішно, локальна бібліотека залишає про це відповідну позначку в доступній для користувача структурі, що містить адресу мережного вузла, ідентифікатор супутника, дескриптор файлу та іншу аналогічну інформацію. Бібліотечні підпрограми read і write встановлюють, виходячи з дескриптора, чи є файл віддаленим, і у разі позитивної відповіді надсилають супутникові повідомлення. Процес-клієнт взаємодіє зі своїм супутником у всіх випадках звернення до системних функцій, що потребують послуг віддаленої машини. Якщо процес звертається до двох файлів, розташованих на одній і тій же віддаленій машині, він користується одним супутником, але якщо файли розташовані на різних машинах, використовуються вже два супутники: по одному на кожній машині. Два супутники використовуються й у тому випадку, коли до файлу на віддаленій машині звертаються два процеси. Викликаючи системну функцію через супутника, процес формує повідомлення, що включає номер функції, ім'я шляху пошуку та іншу необхідну інформацію, аналогічну тій, яка входить в структуру повідомлення в системі з периферійними процесорами.

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

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

Перевага зв'язку типу Newcastle полягає в тому, що звернення процесу до віддалених файлів стає прозорим (непомітним для користувача), при цьому в ядро ​​системи ніяких змін вносити не потрібно. Однак, даної розробки притаманний і ряд недоліків. Насамперед, за її реалізації можливе зниження продуктивності системи. У зв'язку з використанням розширеної Сі-бібліотеки розмір використовуваної кожним процесом пам'яті збільшується, навіть якщо процес не звертається до віддалених файлів; бібліотека дублює функції ядра і вимагає більше місця в пам'яті. Збільшення розміру процесів призводить до подовження тривалості періоду запуску і може викликати велику конкуренцію за ресурси пам'яті, створюючи умови для більш частого розвантаження та підкачування завдань. Локальні запити будуть виконуватися повільніше через збільшення тривалості кожного звернення до ядра, уповільнення може загрожувати і обробці віддалених запитів, витрати на пересилання яких по мережі збільшуються. Додаткова обробка віддалених запитів на рівні користувача збільшує кількість перемикань контексту, операцій з вивантаження і підкачування процесів. Нарешті, щоб звертатися до віддалених файлів, програми мають бути перекомпільовані з використанням нових бібліотек; старі програми та поставлені об'єктні модулі без цього працювати з віддаленими файлами не зможуть. Всі ці недоліки відсутні в системі, яка описується в наступному розділі.

Термін "прозорий розподіл" означає, що користувачі, що працюють на одній машині, можуть звертатися до файлів, що знаходяться на іншій машині, не усвідомлюючи того, що цим вони перетинають машинні межі, подібно до того, як на своїй машині вони при переході від однієї файлової У системі до іншої перетинають точки монтування. Імена, за якими процеси звертаються до файлів, що знаходяться на віддалених машинах, схожі на імена локальних файлів: відмітні символи у них відсутні. У конфігурації, показаній на Рисунку 13.10, каталог "/usr/src", що належить машині B, "вмонтований" у каталог "/usr/src", що належить машині A. Така конфігурація є зручною в тому випадку, якщо в різних системах передбачається використовувати один і той же вихідний кодсистеми, що традиційно знаходиться в каталозі "/usr/src". Користувачі, що працюють на машині A, можуть звертатися до файлів, розташованих на машині B, використовуючи звичний синтаксис написання імен файлів (наприклад: "/usr/src/cmd/login.c"), і ядро ​​вже вирішує питання, є файл видаленим або ж локальним. Користувачі, що працюють на машині B, мають доступ до своїх локальних файлів (не підозрюючи про те, що до цих файлів можуть звертатися і користувачі машини A), але, в свою чергу, не мають доступу до файлів, що знаходяться на машині A. Звичайно , можливі й інші варіанти, зокрема, такі, у яких всі віддалені системи монтуються в корені локальної системи, завдяки чому користувачі отримують доступ до всіх файлів у всіх системах.

Малюнок 13.10. Файлові системи після віддаленого монтування

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

Цікава проблема пов'язана з іменами шляхів, що включають ".." Якщо процес робить поточним каталог з віддаленої файлової системи, подальше використання імені символів ".." швидше поверне процес у локальну файлову систему, ніж дозволить звертатися до файлів, розташованим вище поточного каталогу. Повертаючись знову до Рисунку 13.10, відзначимо, що коли процес, що належить машині A, вибравши попередньо як поточний каталог "/usr/src/cmd", розташований у віддаленій файловій системі, виконає команду

поточним каталогом стане кореневий каталог, що належить машині A, а не машині B. Алгоритм namei, що працює в ядрі віддаленої системи, отримавши послідовність символів "..", перевіряє, чи є процес агентом процесу-клієнта, і в разі позитивної відповіді встановлює, Чи трактує клієнт поточний робочий каталог як корінь віддаленої файлової системи.

Зв'язок із віддаленою машиною приймає одну з двох форм: виклик віддаленої процедури або виклик віддаленої системної функції. У першій формі кожна процедура ядра, що має справу з індексами, перевіряє, чи вказує індекс на віддалений файл, і якщо це так, надсилає на віддалену машину запит на виконання зазначеної операції. Ця схемаприродно вписується в абстрактну структуру підтримки файлових систем різних типів, описану в заключній частині розділу 5. Таким чином, звернення до віддаленому файлуможе ініціювати пересилання через мережу кількох повідомлень, кількість яких визначається кількістю поданих операцій над файлом, з відповідним збільшенням часу відповіді на запит з урахуванням прийнятого в мережі часу очікування. Кожен набір віддалених операцій включає, принаймні, дії з блокування індексу, підрахунку посилань і т. п. В цілях удосконалення моделі пропонувалися різні оптимізаційні рішення, пов'язані з об'єднанням декількох операцій в один запит (повідомлення) і з буферизацією найважливіших даних (Див. ).

Малюнок 13.11. Відкриття віддаленого файлу

Розглянемо процес, що відкриває віддалений файл "/usr/src/cmd/login.c", де "src" - точка монтування. Виконуючи синтаксичний аналіз імені файлу (за схемою namei-iget), ядро ​​виявляє, що файл видалений, і посилає на машину, де він знаходиться, запит на отримання заблокованого індексу. Отримавши бажану відповідь, локальне ядро ​​створює у пам'яті копію індексу, що кореспондує з віддаленим файлом. Потім ядро ​​проводить перевірку наявності необхідних правдоступу до файлу (на читання, наприклад), надіславши на віддалену машину ще одне повідомлення. Виконання алгоритму openпродовжується у повній відповідності з планом, наведеним у розділі 5, з надсиланням повідомлень на віддалену машину при необхідності, до повного закінчення алгоритму та звільнення індексу. Взаємозв'язок між структурами даних ядра після завершення алгоритму open показано на малюнку 13.11.

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

При другій формі зв'язку з віддаленою машиною (виклик віддаленої системної функції) локальне ядро ​​виявляє, що системна функція має відношення до віддаленого файлу, і посилає вказані в її виклик параметри на віддалену систему, яка виконує функцію і повертає результати клієнту. Машина клієнта отримує результати виконання функції та виходить із стану виклику. Більшість системних функцій може бути виконано з використанням тільки одного мережного запиту з отриманням відповіді через досить прийнятний час, але таку модель вписуються не всі функції. Так, наприклад, після отримання деяких сигналів ядро ​​створює для процесу файл з ім'ям "core" (глава 7). Створення цього файлу не пов'язане з конкретною системною функцією, а завершує виконання кількох операцій, таких як створення файлу, перевірка прав доступу та виконання низки операцій запису.

У випадку із системною функцією open запит на виконання функції, що посилається на віддалену машину, включає частину імені файлу, що залишилася після виключення компонент імені шляху пошуку, що відрізняють віддалений файл, а також різні прапори. У розглянутому прикладі з відкриттям файлу "/usr/src/cmd/login.c" ядро ​​посилає на віддалену машину ім'я "cmd/login.c". Повідомлення також включає в себе розпізнавальні дані, такі як код користувача і груповий ідентифікації, необхідні для перевірки прав доступу до файлів на віддаленій машині. Якщо з віддаленої машини надходить відповідь, що свідчить про успішне виконання функції open, локальне ядро ​​вибирає вільний індекс у пам'яті локальної машини і позначає його як індекс віддаленого файлу, зберігає інформацію про віддалену машину та віддалений індекс і заведений порядок виділяє новий запису таблиці файлів. У порівнянні з реальним індексом на віддаленій машині індекс, що належить локальній машині, є формальним, що не порушує конфігурацію моделі, яка в цілому співпадає зі конфігурацією, яка використовується при виклику віддаленої процедури (Малюнок 13.11). Якщо функція, що викликається процесом, звертається до віддаленого файлу за його дескриптором, локальне ядро ​​дізнається з індексу (локального) про те, що файл віддалений, формулює запит, що включає в себе викликану функцію, і посилає його на віддалену машину. У запиті міститься покажчик на віддалений індекс, яким процес-супутник зможе ідентифікувати сам віддалений файл.

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

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

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

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

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

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

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

Малюнок 13.12. Концептуальна схема взаємодії з віддаленими файлами на рівні ядра

У цьому розділі нами було розглянуто три схеми роботи з розміщеними на віддалених машинах файлами, що трактують видалені файлові системи як розширення локальної. Архітектурні різницю між цими схемами показані на Рисунку 13.12. Всі вони у свою чергу відрізняються від багатопроцесорних систем, описаних у попередньому розділі, тим, що тут процесори не використовують фізичну пам'ять разом. Система з периферійними процесорами складається з сильнопов'язаного набору процесорів, що спільно використовують файлові ресурси центрального процесора. Зв'язок типу Newcastle забезпечує прихований (прозорий) доступ до віддалених файлів, але не засобами ядра операційної системи, а завдяки використанню спеціальної Сі-бібліотеки. Тому всі програми, що передбачають використовувати зв'язок даного типу, повинні бути перекомпільовані, що загалом є серйозним недоліком цієї схеми. Відстань файлу позначається за допомогою спеціальної послідовності символів, що описують машину, на якій розташований файл, і це є ще одним фактором, що обмежує мобільність програм.

У "прозорих" розподілених системах доступу до віддалених файлів використовується модифікація системної функції mount. Індекси в локальній системі містять позначку про те, що вони відносяться до віддалених файлів, і локальне ядро ​​посилає на віддалену систему повідомлення, що описує потрібну системну функцію, її параметри і віддалений індекс. Зв'язок у "прозорій" розподіленій системі підтримується у двох формах: у формі виклику віддаленої процедури (на віддалену машину надсилається повідомлення, що містить перелік операцій, пов'язаних з індексом) та у формі виклику віддаленої системної функції (повідомлення описує функцію, що запитується). У заключній частині розділу розглянуті питання, що стосуються обробки дистанційних запитів за допомогою процесів-супутників і серверів.

*1. Опишіть реалізацію системної функції exit у системі з периферійними процесорами. У чому різниця між цим випадком і тим, коли процес завершує свою роботу з отримання неперехопленого сигналу? Як ядру слід зберегти дамп вмісту пам'яті?

2. Процеси що неспроможні ігнорувати сигнали типу SIGKILL; поясніть, що відбувається у периферійній системі, коли процес отримує такий сигнал.

*3. Опишіть реалізацію системної функції exec у системі з периферійними процесорами.

*4. Як центральному процесору слід проводити розподіл процесів між периферійними процесорами для того, щоб збалансувати загальне навантаження?

*5. Що станеться у тому випадку, якщо у периферійного процесора не виявиться достатньо пам'яті для розміщення всіх вивантажених на нього процесів? Яким чином повинні проводитися вивантаження та підкачування процесів у мережі?

6. Розглянемо систему, в якій запити до віддаленого файлового сервера надсилаються у разі виявлення імені файлу спеціального префікса. Нехай процес викликає функцію execl("/../sftig/bin/sh", "sh", 0); Модуль, що виконується, знаходиться на віддаленій машині, але повинен виконуватися в локальній системі. Поясніть, яким чином віддалений модуль переноситься до локальної системи.

7. Якщо адміністратору потрібно додати до існуючої системи зв'язку типу Newcastle нові машини, то як про це найкраще поінформувати модулі Сі-бібліотеки?

*8. Під час виконання функції exec ядро ​​затирає адресний простір процесу, включаючи бібліотечні таблиці, використовувані зв'язком типу Newcastle для стеження за посиланнями на віддалені файли. Після виконання функції процес повинен зберегти можливість звернення до цих файлів за їхніми старими дескрипторами. Опишіть реалізацію цього моменту.

*9. Як показано в розділі 13.2, виклик системної функції exit у системах із зв'язком типу Newcastle призводить до посилки повідомлення процесу-супутнику, що змушує останній завершити свою роботу. Це робиться на рівні бібліотечних підпрограм. Що відбувається, коли локальний процес отримує сигнал, що спонукає його завершити свою роботу як ядра?

*10. Як у системі зі зв'язком типу Newcastle, де видалені файли ідентифікуються додаванням до імені спеціального префікса, користувач може, вказавши як компонент імені файлу ".." (батьківський каталог), перетнути віддалену точку монтування?

11. З глави 7 відомо про те, що різні сигнали спонукають процес скидати дамп вмісту пам'яті в поточний каталог. Що має статися у тому випадку, якщо поточним є каталог із віддаленої файлової системи? Яку відповідь ви дасте, якщо в системі використовується зв'язок типу Newcastle?

*12. Які наслідки для локальних процесів мало б видалення із системи всіх процесів-супутників чи серверів?

*13. Подумайте над тим, як у "прозорій" розподіленій системі слід реалізувати алгоритм link, параметрами якого можуть бути два імені віддалених файлів, а також алгоритм exec, пов'язаний із виконанням кількох внутрішніх операцій читання. Розгляньте дві форми зв'язку: виклик віддаленої процедури та виклик віддаленої системної функції.

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

Малюнок 13.13. Конфігурація з термінальним сервером

*15. Коли користувач реєструється в системі, дисципліна термінальної лінії зберігає інформацію про те, що термінал є операторським, що веде групу процесів. Тому, коли користувач на клавіатурі терміналу натискає клавішу "break", сигнал переривання отримують всі процеси групи. Розглянемо конфігурацію системи, де всі термінали фізично підключаються до однієї машині, але реєстрація користувачів логічно реалізується інших машинах (Малюнок 13.13). У кожному окремому випадку система створює віддалений термінал getty-процес. Якщо запити до віддаленої системи обробляються за допомогою набору процесів-серверів, слід зазначити, що під час процедури відкриття сервер зупиняється в очікуванні підключення. Коли виконання функції open завершується, сервер повертається назад до серверного пулу, розриваючи свій зв'язок з терміналом. Яким чином здійснюється розсилання сигналу про переривання, викликаного натисканням клавіші "break", на адреси процесів, що входять до однієї групи?

*16. Поділ пам'яті – це особливість, властива локальним машинам. З логічного погляду, виділення загальної області фізичної пам'яті (локальної чи віддаленої) можна здійснити й у процесів, що належать різним машинам. Опишіть реалізацію цього моменту.

*17. Розглянуті в розділі 9 алгоритми вивантаження процесів та підкачування сторінок за зверненням припускають використання локального пристрою вивантаження. Які зміни слід внести в ці алгоритми, щоб створити можливість підтримки віддалених пристроїв вивантаження?

*18. Припустимо, що у віддаленої машині (чи мережі) стався фатальний збій і локальний протокол мережного рівня зафіксував цей факт. Розробте схему відновлення локальної системи, яка звертається до віддаленого сервера із запитами. Крім того, розробте схему відновлення серверної системи, що втратила зв'язок із клієнтами.

*19. Коли процес звертається до віддаленого файлу, не виключена можливість, що у пошуках файлу процес обійде кілька машин. Як приклад візьмемо ім'я "/usr/src/uts/3b2/os", де "/usr" - каталог, що належить машині A, "/usr/src" - точка монтування кореня машини B, "/usr/src/uts /3b2" - точка монтування кореня машини C. Прохід через кілька машин до місця кінцевого призначення називається "мультіскачком" (multihop). Однак, якщо між машинами A і C існує безпосередній мережевий зв'язок, пересилання даних через машину B було б неефективним. Опишіть особливості реалізації "мультискачка" у системі зі зв'язком Newcastle та у "прозорій" розподіленій системі.