Програмні канали

Традиційним засобом взаємодії та синхронізації процесів в ОС UNIX є програмні канали (pipes). Теоретично програмний канал дозволяє взаємодіяти будь-якого числа процесів, забезпечуючи дисципліну FIFO. Іншими словами, процес, який читає з програмного каналу, прочитає ті дані, які були записані в програмний канал найбільш давно. У традиційній реалізації програмних каналів для зберігання даних використовувалися файли. У сучасних версіях ОС UNIX для реалізації програмних каналів застосовуються інші засоби IPC (зокрема, черги повідомлень).

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

Для створення іменованого програмного каналу (або отримання до нього доступу) використовується звичайний файловий системний виклик open. Для створення неіменованного програмного каналу існує спеціальний системний виклик pipe (історично більш ранній). Проте після отримання відповідних дескрипторів обидва види програмних каналів використовуються одноманітно за допомогою стандартних файлових системних викликів read, write і close.

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

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

9.4.6. Програмні гнізда (sockets)

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

Ці базові можливості були в принципі достатніми для створення мережевих утиліт; зокрема, на їх основі був створений вихідний в ОС UNIX механізм мережевих взаємодій uucp. Проте організація мережевих взаємодій користувацьких процесів була скрутна головним чином тому, що при використанні конкретної мережної апаратури і конкретного мережевого протоколу потрібно виконувати безліч системних викликів ioctl, що робило програми залежними від специфічної мережевого середовища. Був потрібен підтримуваний ядром механізм, що дозволяє приховати особливості цього середовища і дозволити одноманітно взаємодіяти процесам, що виконується на одному комп'ютері, в межах однієї локальної мережі або рознесеним на різні комп'ютери територіально розподіленої мережі. Перше рішення цієї проблеми було запропоновано і реалізовано в UNIX BSD 4.1 у 1982 р. На рівні ядра механізм програмних гнізд підтримується трьома складовими: компонентом рівня програмних гнізд (незалежних від мережевого протоколу і середовища передачі даних), компонентом протокольного рівня (незалежних від середовища передачі даних ) і компонентом рівня управління мережним пристроєм (див. малюнок 9.6).

Рис. 9.6. Одна з можливих конфігурацій програмних гнізд

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

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

Виділяються два типи програмних гнізд - гнізда з віртуальним з'єднанням (у початковій термінології stream sockets) і датаграммним гнізда (datagram sockets). При використанні програмних гнізд з віртуальним з'єднанням забезпечується передача даних від клієнта до сервера у вигляді безперервного потоку байтів з гарантією доставки. При цьому до початку передачі даних повинне бути встановлене з'єднання, яке підтримується до кінця комунікаційної сесії. Датаграммним програмні гнізда не гарантують абсолютної надійною, послідовною доставки повідомлень і відсутності дублікатів пакетів даних - датаграм. Але для використання датаграммной режиму не потрібне попереднє дороге встановлення з'єднань, і тому цей режим в багатьох випадках є кращим.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Черги повідомлень	\|	Функціонування системи планування на підприємстві.

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.013 сек.