Абревіатура IPC розшифровується як interprocess communication, тобто взаємодія процесів. Зазвичай під цим розуміється передача повідомлень різних видів між процесами в будь-якій операційній системі. При цьому можуть використовуватися різні форми синхронізації, необхідної сучасними видами взаємодії, здійснюваними, наприклад, через пам'ять, що розділяється.
В процесі розвитку операційних систем сімейства Unix за останні 30 років методи передачі повідомлень еволюціонували в такий спосіб:
■ Канали (pipes - глава 4) були першою широко використовується формою взаємодії процесів, мають доступ усі програми і користувачеві (з інтерпретатора команд). Основним недоліком каналів є неможливість їх використання між процесами, що не мають загального батька (ancestor), але цей недолік був усунутий з появою іменованих каналів (named pipes), або каналів FIFO (глава 4).
■ Черги повідомлень стандарту System V (System V message queues - глава 4) були додані до ядер System V на початку 80-х. Вони можуть використовуватися для передачі повідомлень між процесами на одному вузлі незалежно від того, чи є ці процеси родинними. Незважаючи на що зберігся префікс «System V», більшість сучасних версій Unix, включаючи і ті, які не походять від System V, підтримують ці черги.
ПРИМІТКА
Відносно процесів Unix термін «спорідненість» означає, що у процесів є загальний предок. Мається на увазі, що процеси, які є родичами, були створені цим процесом-предком за допомогою однієї або декількох «вилок» (forks). Найпростішим прикладом буде виклик fork деяким процесом двічі, що призведе до створення двох породжених процесів. Тоді можна говорити про спорідненість цих процесів між собою. Природно, кожен породжений процес є родичем породив. Батько може подбати про можливості взаємодії з породженим процесом (створивши канал або чергу повідомлень) перед викликом fork, і цей об'єкт IPC буде успадкований породженим процесом. Більш докладно про спадкування об'єктів IPC розказано в табл. 1.4. Потрібно також відзначити, що всі процеси Unix теоретично є нащадками процесу init, який запускає все необхідне в процесі завантаження системи (bootstrapping). З практичної точки зору відлік споріднення процесів краще вести з оболонки (login shell) і всіх процесів, нею створених. У розділі 9 розказано про сеансах і родинних відносинах процесів більш докладно.
ПРИМІТКА
Примітки на кшталт цього будуть використовуватися нами для того, щоб уточнювати особливості реалізації, давати історичні довідки і корисні поради.
■ Черги повідомлень Posix (Posix message queues - глава 5) були додані в стандарт Posix (1003.1b-1993, про який більш детально розказано в розділі 1.7). Вони можуть використовуватися для взаємодії споріднених і неспоріднених процесів на будь-якому вузлі.
■ Віддалений виклик процедур (remote procedure calls - RPC, частина 5) з'явився в 80-х в якості засобу для виконання функцій на одній системі (сервері) програмою, виконуваної на іншій системі (клієнта). Це засіб було розроблено в якості альтернативи для спрощення мережевого програмування. Оскільки між клієнтом і сервером зазвичай передається інформація (передаються аргументи для виклику функції і повертаються значення) і оскільки віддалений виклик процедур може використовуватися між клієнтом і сервером на одному вузлі, RPC можна також вважати однією з форм передачі повідомлень.
Цікаво також поглянути на еволюцію різних форм синхронізації в процесі розвитку Unix:
■ Найперші програми, яким була потрібна синхронізація (найчастіше для запобігання одночасного зміни вмісту файлу декількома процесами), використовували особливості файлової системи, Деякі з яких описані в розділі 9.8,
■ Можливість блокування записів (record locking - глава 9) була додана до ядер Unix на початку 80-х і стандартизована в версії Posix.1 в 1988.
■ Семафори System V (System V semaphores - глава 11) були додані разом з можливістю спільного використання пам'яті (System V shared memory - глава 14) і одночасно з чергами повідомлень System V (початок 80-х). Ці IPC підтримуються більшістю сучасних версій Unix.
■ Семафори Posix (Posix semaphores - глава 10) і колективна пам'ять Posix (Posix shared memory- глава 13) були також додані в стандарт Posix (1003.1b-1993, який раніше згадувався в зв'язку з чергами повідомлень Posix).
■ Взаємні виключення і умовні змінні (mutex, conditional variable - глава 7) представляють собою дві форми синхронізації, певні стандартом програмних потоків Posix (Posix threads, Pthreads - 1003.1с-1995). Хоча зазвичай вони використовуються для синхронізації між потоками, їх можна застосовувати і при організації взаємодії процесів.
■ Блокування читання-запису (read-write locks - глава 8) являють собою додаткову форму синхронізації. Вона ще не включена в стандарт Posix, але, ймовірно, скоро буде.
1.2. Процеси, потоки і загальний доступ до інформації
У традиційній моделі програмування Unix в системі можуть одночасно виконуватися кілька процесів, кожному з яких виділяється власний адресний простір. Це ілюструє рис. 1.1.
Мал. 1.1. Спільне використання інформації процесами
1. Два процесу в лівій частині спільно використовують інформацію, що зберігається в одному з об'єктів файлової системи. Для доступу до цих даних кожен процес повинен звернутися до ядра (використовуючи функції read, write, lseek, write, lseek і аналогічні). Деяка форма синхронізації потрібно при зміні файлу, для виключення перешкод при одночасній записи в файл декількома процесами і для захисту процесів, які читають з файлу, від тих, які пишуть в нього.
2. Два процесу в середині малюнка спільно використовують інформацію, що зберігається в ядрі. Прикладами в даному випадку є канал, чергу повідомлень або семафор System V. Для доступу до спільно використовуваної інформації в цьому випадку будуть використовуватися системні виклики.
3. Два процесу в правій частині використовують загальну область пам'яті, до якої може звертатися кожен з процесів. Після того як буде отриманий доступ до цієї області пам'яті, процеси зможуть звертатися до даних взагалі без допомоги ядра. У цьому випадку, як і в першому, процесам, які використовують спільну пам'ять також потрібна синхронізація.
Зверніть увагу, що ні в одному з цих випадків кількість взаємодіючих процесів не обмежується двома. Будь-який з описаних методів працює для довільного числа взаємодіючих процесів. На малюнку ми зображуємо тільки два для простоти.
потоки
Хоча концепція процесів в системах Unix використовується вже дуже давно, можливість використовувати кілька потоків всередині одного процесу з'явилася відносно недавно. Стандарт потоків Posix.1, званий Pthreads, був прийнятий в 1995 році. З точки зору взаємодії процесів все потоки одного процесу мають загальні глобальні змінні (тобто потокової моделі властиве використання загальної пам'яті). Однак потокам потрібна синхронізація доступу до глобальних даними. Взагалі, синхронізація, не будучи власне формою IPC, часто використовується спільно з різними формами IPC для управління доступом до даних.
У цій книзі описано взаємодію між процесами і між потоками. Ми припускаємо наявність середовища, в якій підтримується багатопотокове програмування, і будемо використовувати вирази типу «якщо канал порожній, викликає потік блокується до тих пір, поки який-небудь інший потік не зробить запис в канал». Якщо система не підтримує потоки, можна в цьому реченні замінити «потоки» на «процеси» і вийде класичне визначення блокування в Unix, що виникає при зчитуванні з пустого каналу командою read. Однак в системі, яка підтримує потоки, блокується тільки потік, що запитав дані з пустого каналу, а всі інші потоки процесу будуть продовжувати виконуватися. Записати дані в канал зможе інший потік цього ж процесу або будь-якої потік іншого процесу.
У додатку Б зведені деякі основні характеристики потоків і дано опис п'яти основних функцій Pthread, використовуваних в програмах цієї книги.
1.3. Живучість об'єктів IPC
Можна визначити живучість (persistence) будь-якого об'єкта IPC як тривалість його існування. На рис. 1.2 зображені три можливі групи, До яких можуть бути віднесені об'єкти по живучості.
Мал. 1.2. Живучість об'єктів IPC
1. Об'єкт IPC, живучість якого визначається процесом (process-persistent), існує до тих пір, поки не буде закритий останнім процесом, в якому він ще відкрите. Прикладом є неіменовані і іменовані канали (pipes, FIFO).
2. Об'єкт IPC, живучість якого визначається ядром (kernel-persistent), існує до перезавантаження ядра або до явного видалення об'єкта. Прикладом є черги повідомлень стандарту System V, семафори і колективна пам'ять. Живучість черг повідомлень Posix, семафорів і розділяється пам'яті повинна визначатися по крайней мере ядром, але може визначатися і файлової системою в залежності від реалізації.
3. Об'єкт IPC, живучість якого визначається файлової системою (filesystem-persistent), існує до тих пір, поки не буде видалений явно. Його значення зберігається навіть при перезавантаженні ядра. Черги повідомлень Posix, семафори і пам'ять із загальним доступом володіють цією властивістю, якщо вони реалізовані через які відображаються файли (так буває не завжди).
Слід бути акуратним при визначенні живучості об'єкту IPC, оскільки вона не завжди очевидна. Наприклад, дані в каналі (pipe) обробляються ядром, але живучість каналів визначається процесами, а не ядром, тому що після того, як останній процес, яким канал був відкритий на читання, закриє його, ядро \u200b\u200bскине всі дані і видалить канал. Аналогічно, хоча канали FIFO і володіють іменами в файлової системі, живучість їх також визначається процесами, оскільки всі дані в такому каналі скидаються після того, як останній процес, в якому він був відкритий, закриє його.
У табл. 1.1 зведена інформація про живучість перерахованих раніше об'єктів IPC.
Таблиця 1.1. Живучість різних типів об'єктів IPC
| Тип IPC | живучість визначає |
|---|---|
| Програмний канал (pipe) | процес |
| Іменований канал (FIFO) | процес |
| Взаємне виключення Posix (mutex) | процес |
| Умовна змінна Posix (condition variable) | процес |
| Блокування читання-запису Posix (lock) | процес |
| Блокування записи fcntl | процес |
| Черга повідомлень Posix (message queue) | ядро |
| Іменований семафор Posix (named semaphore) | ядро |
| Семафор Posix в пам'яті (memory-based semaphore) | процес |
| Колективна пам'ять Posix (shared memory) | ядро |
| Черга повідомлень System V | ядро |
| Семафор System V | ядро |
| ядро | |
| Сокет TCP (TCP socket) | процес |
| Сокет UDP (UDP socket) | процес |
| Доменний сокет Unix (Unix domain socket) | процес |
Зверніть увагу, що жоден тип IPC в цій таблиці не володіє живучістю, яка визначається файлової системою. Ми вже згадали про те, що три типи об'єктів IPC в стандарті Posix можутьмати цей тип живучості в залежності від реалізації. Очевидно, що запис даних в файл забезпечує живучість, яка визначається файлової системою, але зазвичай IPC таким чином не реалізуються. Велика частина об'єктів IPC не призначена для того, щоб існувати і після перезавантаження, бо її не переживають процеси. Вимога живучості, яка визначається файлової системою, швидше за все, знизить продуктивність даного типу IPC, а зазвичай одним із завдань розробника є саме забезпечення високої продуктивності.
1.4. простори назв
Якщо два неспоріднених процесу використовують будь-якої вид IPC для обміну інформацією, об'єкт IPC повинен мати ім'я або ідентифікатор, щоб один з процесів (званий зазвичай сервером - server) міг створити цей об'єкт, а інший процес (зазвичай один або кілька клієнтів - client) міг звернутися до цього конкретного об'єкта.
Програмні канали (pipes) іменами не володіють (і тому не можуть використовуватися для взаємодії між несумісними процесами), але каналах FIFO зіставляються імена в файлової системі, які є їхніми ідентифікаторами (тому канали FIFO можуть використовуватися для взаємодії неспоріднених процесів). Для інших типів IPC, що розглядаються в наступних розділах, використовуються додаткові угоди про іменування (naming conventions). Безліч можливих імен для певного типу IPC називається його простором імен (name space). Простір імен - важливий термін, оскільки для всіх видів IPC, за винятком простих каналів, ім'ям визначається спосіб зв'язку клієнта і сервера для обміну повідомленнями.
У табл. 1.2 зведені угоди про іменування для різних видів IPC.
Таблиця 1.2. Простору імен для різних типів IPC
| Тип IPC | Простір імен для створення або відкриття | Ідентифікатор після відкриття | Posix.1 1996 | Unix 98 |
|---|---|---|---|---|
| Канал | (Без імені) | дескриптор | ||
| FIFO | Файл (pathname) | дескриптор | ||
| Взаємне виключення Posix | (Без імені) | Покажчик типу pthread_mutex_t | ||
| Умовна змінна Posix | (Без імені) | Покажчик типу pthread_cond_t | ||
| (Без імені) | Покажчик типу pthread_rwlock_t | |||
| Блокування записів fcntl | ім'я файлу | дескриптор | ||
| Колективна пам'ять Posix | Posix-ім'я IPC | дескриптор | ||
| Черга повідомлень System V | ключ key_t | Ідентифікатор IPC System V | ||
| Семафор System V | ключ key_t | Ідентифікатор IPC System V | ||
| Колективна пам'ять System V | ключ key_t | Ідентифікатор IPC System V | ||
| Двері (doors) | ім'я файлу | дескриптор | ||
| Віддалений виклик процедур (RPC) Sun | Програма / версія | Дескриптор (handle) RPC | ||
| сокет TCP | IP-адреса і порт TCP | дескриптор | .1g | |
| сокет UDP | IP-адреса і порт TCP | дескриптор | .1g | |
| Доменний сокет Unix (domain socket) | Повне ім'я файлу | дескриптор | .1g |
Тут також зазначено, які форми IPC містяться в стандарті Posix.1 1996 року і які були включені в стандарт Unix 98. Про обох цих стандартах більш докладно розказано в розділі 1.7. Для порівняння ми включили в цю таблицю три типи сокетів, які докладно описані в. Зверніть увагу, що інтерфейс сокетів (Application Program Interface - API) стандартизується робочою групою Posix.1g і повинен в майбутньому стати частиною стандарту Posix.1.
Хоча стандарт Posix. 1 і дає можливість використання семафорів, їх підтримка не є обов'язковою для виробників. У табл. 1.3 зведені функції, описані в стандартах Posix.1 і Unix 98. Кожна функція може бути обов'язковою (mandatory), невизначеною (not defined) або необов'язковою (додаткової - optional). Для необов'язкових функцій ми вказуємо ім'я константи (наприклад, _POSIX_THREADS), яка буде визначена (зазвичай в заголовки
Таблиця 1.3. Доступність різних форм IPC
| Тип IPC | Posix.1 1996 | Unix 98 |
|---|---|---|
| програмний канал | обов'язковий | обов'язковий |
| FIFO | обов'язковий | обов'язковий |
| Взаємне виключення Posix | _POSIX_THREADS | обов'язковий |
| Умовна змінна Posix | _POSIX_THREADS | обов'язковий |
| Взаємні виключення і умовні змінні між процесами | _POSIX_THREADS_PROCESS_SHARED | обов'язковий |
| Блокування читання-запису Posix | (He визначено) | обов'язковий |
| Блокування записів fcntl | обов'язковий | обов'язковий |
| Черга повідомлень Posix | _POSIX_MESSAGE_PASSING | _XOPEN_REALTIME |
| семафори Posix | _POSIX_SEMAPHORES_ | _XOPEN_REALTIME |
| Пам'ять із загальним доступом Posix | _POSIX_SHARED_MEMORY_OBJECTS | _XOPEN_REALTIME |
| Черга повідомлень System V | (He визначено) | обов'язковий |
| Семафор System V | (He визначено) | обов'язковий |
| Пам'ять із загальним доступом System V | (He визначено) | обов'язковий |
| Двері (doors) | (He визначено) | (Не визначений) |
| Віддалений виклик процедур Sun | (He визначено) | (Не визначений) |
| Відображення пам'яті mmap | _POSIX_MAPPED_FILES або POSIX_SHARED_MEMORY_OBJECTS | обов'язковий |
| Сигнали реального часу (realtime signals) | _POSIX_REALTIME_SIGNALS | _XOPEN_REALTIME |
1.5. Дія команд fork, exec і exit на об'єкти IPC
Нам потрібно досягти розуміння дії функцій fork, exec і _exit на різні форми IPC, які ми обговорюємо (остання з перерахованих функцій викликається функцією exit). Інформація з цього питання зведена в табл. 1.4.
Більшість функцій описані далі в тексті книги, але тут потрібно зробити кілька зауважень. По-перше, виклик fork з многопоточного процесу (multithreaded process) призводить до безладу в безіменних змінних синхронізації (взаємних винятки, умовних змінних, блокування і семафорах, що зберігаються в пам'яті). Розділ 6.1 книги містить необхідні деталі. Ми просто відзначимо на додаток до таблиці, що якщо ці змінні зберігаються в пам'яті із загальним доступом і створюються з атрибутом загального доступу для процесів, вони будуть доступні будь-якому процесу, який може звертатися до цієї області пам'яті. По-друге, три форми IPC System V не можуть бути відкриті або закриті. З лістингу 6.6 і вправ 11.1 і 14.1 видно, що все, що потрібно знати, щоб отримати доступ до цих трьох форм IPC, - це ідентифікатор. Тому вони доступні всім процесам, яким відомий цей ідентифікатор, хоча для семафорів і пам'яті із загальним доступом потрібно якась особлива обробка.
Таблиця 1.4. Дія fork, exec і _exit на IPC
| Тип IPC | fork | exec | _exit |
|---|---|---|---|
| Неіменовані і іменовані канали | Породжений процес отримує копії всіх дескрипторів батьківського процесу | Всі відкриті дескриптори залишаються відкритими, якщо для них не встановлено біт FD_CLOEXEC | Всі відкриті дескриптори закриваються, дані з програмного каналу і FIFO видаляються після останнього закриття |
| Черги повідомлень Posix | Породжений процес отримує копії всіх відкритих батьківських процесів | Всі відкриті дескриптори черг повідомлень закриваються | |
| Черги повідомлень System V | Не діє | Не діє | Не діє |
| Взаємні виключення і умовні змінні Posix | Загальний доступ, якщо використовується колективна пам'ять з атрибутом поділу між процесами | Зникає, якщо не знаходиться в пам'яті, що, яка залишається відкритою і має атрибут поділу | |
| Блокування читання-запису Posix | Зникає, якщо не зберігається в пам'яті, що, яка залишається відкритою і має атрибут поділу | Зникає, якщо не зберігається в пам'яті, що, яка залишається відкритою і має атрибут поділу | |
| Семафори Posix, що зберігаються в пам'яті | Загальний доступ, якщо використовується пам'ять із загальним доступом і атрибутом поділу між процесами | Зникає, якщо не зберігається в пам'яті, що, яка залишається відкритою і має атрибут поділу | Зникає, якщо не зберігається в пам'яті, що, яка залишається відкритою і має атрибут поділу |
| Іменовані семафори Posix | Всі відкриті в батьківському процесі залишаються відкритими в породженому | Всі відкриті закриваються | Всі відкриті закриваються |
| Семафори System V | Всі значення semadj в породженому процесі встановлюються в 0 | Всі значення semadj передаються новій програмі | Всі значення semadj додаються до значення відповідного семафора |
| Блокування записів fcntl | Блокування в батьківському процесі не успадковуються породженим процесом | Блокування не змінюються до тих пір, поки не закриється дескриптор | Все несброшенная блокування, встановлені процесом, знімаються |
| відображення пам'яті | Відображення пам'яті скидаються (unmap) | ||
| Колективна пам'ять Posix | Відображення пам'яті батьківського процесу зберігаються в породженому | Відображення пам'яті скидаються | Відображення пам'яті скидаються |
| Колективна пам'ять System V | Приєднані сегменти розділяється пам'яті залишаються приєднаними в породженому процесі | Приєднані сегменти розділяється пам'яті від'єднуються | |
| Двері (doors) | Породжений процес отримує копії всіх відкритих дескрипторів батьківського процесу, але тільки батьківський процес є сервером при активізації дверей через дескриптори | Всі дескриптори дверей повинні бути закриті, тому що вони створюються з встановленим бітом FD_CLOEXEC | Всі відкриті дескриптори закриваються |
1.6. Обробка помилок: функції-обгортки
У будь-якій реальній програмі при будь-якому виклику потрібна перевірка повертається на наявність помилки. Оскільки зазвичай робота програм при виникненні помилок завершується, ми можемо скоротити обсяг тексту, визначивши функції-обгортки (wrapper functions), які здійснюють власне виклик функції, перевіряють повертається значення і завершують роботу при виникненні помилок. Відповідно до угод імена функцій-обгорток збігаються з іменами самих функцій, за винятком першої букви, яка робиться у верхньому регістрі, наприклад
Приклад функції-обгортки приведений в лістингу 1.1
Лістинг 1.1. Функція-обгортка до функції sem_post390 if (sem_post (sem) \u003d\u003d -1)
391 err_sys ( "sem_post error");
Якщо в тексті ви зустрінете ім'я функції, що починається з великої літери, знайте: це наша власна функція-обгортка. Вона викликає функцію з тим же ім'ям, що починається з малої літери. Функція-обгортка призводить до завершення роботи процесу з висновком повідомлення про помилку, якщо така виникає.
При описі вихідного коду, включеного до книги, ми завжди говоримо про функції, що викликається найнижчого рівня (наприклад, sem_post), а не про функції-обгортці (наприклад, Sem_post). Аналогічно в алфавітному покажчику наведено імена самих функцій, а не обгорток до них.
ПРИМІТКА
Вищенаведений формат вихідного коду використовується у всьому тексті. Все непусті рядки нумеруються. Текст, який описує розділи коду, починається з номерів першої і останньої рядків на порожньому полі зліва. Іноді перед абзацом тексту присутній короткий заголовок, набраний напівжирним шрифтом, що викладає основний зміст описуваного коду.
На початку коду вказується ім'я вихідного файлу. В даному прикладі - це файл wrapunix.c в каталозі lib. Оскільки вихідний код всіх прикладів цієї книги поширюється вільно (див. Передмову), ви можете легко знайти потрібний файл. Компіляція, виконання і особливо зміна цих програм в процесі читання книги - кращий спосіб вивчити концепції взаємодії процесів.
Хоча може здатися, що використовувати такі функції-обгортки не дуже вигідно, ви позбудетеся від цієї помилки в главі 7, де ми виявимо, що функції для роботи з потоками (thread functions) не надавали значення стандартної змінної Unix errno при виникненні помилки; замість цього код помилки просто повертається функцією. Це означає, що при виконанні функції pthread ми повинні кожен раз виділяти пам'ять під змінну, зберігати в ній повертається функцією значення, а потім встановлювати значення змінної errno рівним цієї змінної, перш ніж викликати функцію err_sys (лістинг В.4). Щоб не захаращувати текст фігурними дужками, ми використовуємо оператор мови Сі «кома» (comma) і поєднуємо присвоювання значення змінної errno і виклик err_sys в одному операторі, як в наступному прикладі:
if ((n \u003d pthread_mutex_lock (& \u200b\u200bndone_mutex))! \u003d 0) errno \u003d n, err_sys ( "pthread_mutex_lock error");
Альтернативою є визначення нової функції обробки помилок, що приймає код помилки в якості аргументу. Однак ми можемо зробити цей фрагмент коду набагато більш читабельним, записавши
Pthread_mutex_lock (& \u200b\u200bndone_mutex);
де використовується наша власна функція-обгортка, наведена в лістингу 1.2.
Лістинг 1.2. Реалізація обгортки до функції pthread_mutex_lock126 Pthread_mutex_lock (pthread_mutex_t * mptr)
129 if ((n \u003d pthread_mutex_lock (mptr)) \u003d\u003d 0)
132 err_sys ( "pthread_mutex_lock error");
ПРИМІТКА
Акуратно використовуючи можливості мови Сі, ми могли б застосовувати макроси замість функцій, що збільшило б швидкість виконання програм, але ці функції-обгортки рідко бувають (якщо взагалі бувають) вузьким місцем.
Наша угода про заміну першої літери імені функції на заголовну є компромісом. Розглядалося багато інших форм запису: використання префікса е (), суфікса _е і т. Д. Наш варіант здається найменш відволікаючим увагу і одночасно дає візуальне вказівку на те, що викликається якась інша функція.
Цей метод має побічну корисна властивість: перевіряються помилки, які повертаються функціями, код повернення яких зазвичай ігнорується, наприклад close і pthread_ mutex_lock.
Далі в тексті книги ми будемо використовувати ці функції-обгортки, якщо тільки не буде потрібно явно перевірити наявність помилки і обробити її довільним чином, відмінним від завершення процесу. Ми не наводимо в книзі вихідний код для всіх обгорток, але він знаходиться у вільному доступі в Інтернеті (див. Передмову).
значення errno
При виникненні помилки в функції Unix глобальної змінної errno присвоюється позитивне значення, яке вказує на тип помилки; при цьому функція зазвичай повертає значення -1. Наша функція err_sys виводить відповідне коду помилки повідомлення (наприклад, Resource temporarily unavailable - ресурс тимчасово недоступний, - якщо змінна errno має значення EAGAIN).
Функція привласнює значення змінної errno тільки при виникненні помилки. У разі нормального завершення роботи значення цієї змінної не визначено. Всі позитивні значення відповідають констант з іменами з заголовних букв, які починаються часткою з Е, що визначаються зазвичай в заголовки
При роботі з декількома потоками в кожному з них повинна бути власна змінна errno. Виділення змінної кожному потоку відбувається автоматично, проте зазвичай це вимагає вказівки компілятору на те, що повинна бути можливість повторного входу в програму. Здається це за допомогою ключів -D_REENTRANT або -D_POSIX_C_SOURCE \u003d 199506L або аналогічних. Часто в заголовку
Далі в тексті ми використовуємо вислови на кшталт «функція mq_send повертає EMSGSIZE», які означають, що функція повертає помилку (зазвичай повертається значення при цьому дорівнює -1) і привласнює змінної errno значення зазначеної константи.
1.7. стандарти Unix
В даний час стандарти Unix визначаються Posix і The Open Group.
Posix
Назва Posix утворено від «Portable Operating System Interface», що означає приблизно «інтерфейс переносяться операційних систем». Це не один стандарт, а ціле сімейство, розроблене Інститутом інженерів з електротехніки та електроніки (Institute for Electrical and Electronics Engineers - IEEE). Стандарти Posix були також прийняті в якості міжнародних стандартів ISO (International Organization for Standardization, Міжнародна організація по стандартизації) і IEC (International Electrotechnical Commission, Міжнародна електротехнічна комісія), або ISO / IEC. Стандарти Posix пройшли кілька стадій розробки.
■ Стандарт IEEE 1003.1-1988 (317 сторінок) був першим стандартом Posix. Він визначав інтерфейс взаємодії мови С з ядром Unix-типу в наступних областях: примітиви для реалізації процесів (виклики fork, exec, сигнали і таймери), середа процесу (ідентифікатори користувачів, групи процесів), файли і каталоги (всі функції введення-виведення) , робота з терміналом, бази даних системи (файли паролів і груп), формати архівів tar і cpio.
ПРИМІТКА
Перший стандарт Posix вийшов в робочому варіанті під назвою IEEEIX в 1986 році. Назва Posix було запропоновано Річардом Штолманом (Richard Stallman).
■ Потім вийшов стандарт IEЕЕ 1003.1-1990 (356 сторінок). Він одночасно був і міжнародним стандартом ISO / IEC 9945-1: 1990. У порівнянні з версією 1988 року зміни в версії 1990 року було мінімальними. До заголовку було додано: «Part 1: System Application Program Interface (API)» ( «Частина 1: Системний інтерфейс розробки програм (API) [Мова С])», і це означало, що стандарт описував програмний інтерфейс (API) мови С.
■ IEEE 1003.2-1992 вийшов в двох томах загальним обсягом близько 1300 сторінок, і його заголовок містив рядок «Part 2: Shell and Utilities» (Частина 2: «Інтерпретатор і утиліти»). Ця частина визначала інтерпретатор (заснований на Bourne shell в Unix System V) і близько ста утиліт (програм, зазвичай викликаються з інтерпретатора - від awk і basename до vi і УАСС). У цій книзі ми будемо посилатися на цей стандарт під ім'ям Posix. 2.
■ IEEE 1003.1b-1993 (590 сторінок) спочатку був відомий як IEEE P1003.4. Цей стандарт був доповнення до стандарту 1003.1-1990 і включав розширення реального часу, розроблені робочою групою Р1003.4: синхронізацію файлів, асинхронний ввід-висновок, семафори, управління пам'яттю, планування виконання (scheduling), годинник, таймери і черги повідомлень.
■ IEEE 1003.1, видання 1996 (743 сторінки), включає 1003.1-1990 (базовий інтерфейс API), 1003.1b-1 993 (розширення реального часу), 1003.1-1995 (Pthreads - програмні потоки Posix) і 1003.1i-1995 (технічні поправки до 1003.1b). Цей стандарт також називається ISO / IEC 9945-1: 1996 В нього були додані три розділи про потоках і додаткові розділи, що стосуються синхронізації потоків (взаємні виключення і умовні змінні), планування виконання потоків, планування синхронізації. У цій книзі ми називаємо цей стандарт Posix.1.
ПРИМІТКА
Понад чверть з 743 сторінок стандарту представляли собою додаток, назване «Rationale and Notes» ( «Обгрунтування і примітки»). Це обгрунтування містить історичну інформацію і пояснення причин, за якими деякі функції були чи не були включені в стандарт. Часто обгрунтування виявляється не менш корисним, ніж власне стандарт.
На жаль, стандарти IEEE не є вільно доступними через Інтернет. Інформація про те, де можна замовити книгу, дана в бібліографії під посиланням. Зверніть увагу, що семафори були визначені в стандарті розширень реального часу, окремо від взаємних виключень і умовних змінних (які були визначені в стандарті Pthreads), що пояснює деякі відмінності в інтерфейсах API цих коштів.
Нарешті, зауважимо, що блокування читання-запису не є частиною стандартів Posix. Про це більш детально розказано в главі 8.
В майбутньому планується вихід нової версії IEEE 1003.1, що включає стандарт P1003.1g, мережеві інтерфейси (сокети і XTI), які описані в першому томі цієї книги.
У передмові стандарту Posix.1 1996 затверджується, що стандарт ISO / IEC 9945 складається з наступних частин:
1. Системний інтерфейс розробки програм (API) (мова С).
2. Інтерпретатор і утиліти.
3. Адміністрування системи (в розробці).
Частини 1 і 2 представляють собою те, що ми називаємо Posix.1 і Posix.2.
Робота над стандартами Posix постійно триває, і авторам книг, з ними пов'язаних, доводиться займатися стрільбою по рухомій мішені. Про поточний стан стандартів можна дізнатися на сайті http://www.pasc.org/standing/sd11.html.
The Open Group
The Open Group (Відкрита група) була сформована в 1996 році об'єднанням X / Open Company (заснована в 1984 році) і Open Software Foundation (OSF, заснований в 1988 році). Ця група є міжнародний консорціум виробників і споживачів з промисловості, уряду і освітніх установ. Їх стандарти теж виходили в декількох версіях:
■ У 1992 році був опублікований четвертий випуск (Issue 4), а в 1994 році - друга його версія (Issue 4, Version 2). Остання відома також під назвою Spec 1170, де магічне число 1170 є сумою кількості інтерфейсів системи (926), заголовків (70) і команд (174). Є і ще дві назви: X / Open Single Unix Specification (Єдина специфікація Unix) і Unix 95.
■ У березні 1997 року було оголошено про вихід другої версії Єдиної специфікації Unix. Цей стандарт програмного забезпечення називається також Unix 98, і саме так ми посилаємося на цю специфікацію далі в тексті книги. Кількість інтерфейсів в Unix 98 зросла з 1 170 до 1434, хоча для робочої станції ця кількість сягає 3030, оскільки до цього числа включається CDE (Common Desktop Environment - загальне оточення робочого столу), яке, в свою чергу, вимагає системи X Window System і призначеного для користувача інтерфейсу Motif. Детально про це написано в книзі. Корисну інформацію можна знайти на веб-http://www.UNIX-systems.org/version2.
ПРИМІТКА
З цього сайту можна вільно скачати єдину специфікацію Unix практично повністю.
Версії Unix і переносимість
Практично всі версії Unix, з якими можна зіткнутися сьогодні, відповідають якому-небудь варіанту стандарту Posix.1 або Posix.2. Ми говоримо «якого-небудь», тому що після внесення змін до Posix (наприклад, Додавання розширень реального часу в 1993 і потоків в 1996) виробникам зазвичай потрібно рік або два, щоб підігнати свої програми під ці стандарти.
Історично більшість систем Unix є нащадками або BSD, або System V, але відмінності між ними поступово стираються, у міру того як виробники переходять до використання стандартів Posix. Основні відмінності лежать в області системного адміністрування, Оскільки жоден стандарт Posix на даний момент не описує цю область.
У більшості прикладів цієї книги ми використовували операційні системи Solaris 2.6 і Digital Unix 4.0B. Справа в тому, що на момент написання книги (кінець 1997 - початок 1998 року) тільки ці дві операційні системи підтримували System V IPC, Posix IPC та програмні потоки Posix (Pthreads).
1.8. Коментар до прикладів IPC
Найчастіше для ілюстрації різних функцій в книзі використовуються три шаблону (моделі) взаємодії:
1. Сервер файлів: додаток клієнт-сервер, причому клієнт посилає серверу запит з ім'ям файлу, а сервер повертає клієнтові його вміст.
2. Виробник-споживач: один або кілька потоків або процесів (виробників) поміщають дані в буфер загального користування, а інші потоки або процеси (споживачі) виробляють з цими даними різні операції.
3. Збільшення послідовного номера: один або кілька потоків або процесів збільшують загальний для всіх індекс. Число це може зберігатися в файлі із загальним доступом або в спільно використовуваної області пам'яті.
Перший приклад ілюструє різні форми передачі повідомлень, а інших два - різноманітні види синхронізації і використання розділяється пам'яті.
Таблиці 1.5, 1.6 і 1.7 є свого роду путівник по розробляються нами програмами на різні теми, викладені в книзі. У цих таблицях коротко описані самі програми і вказані номери відповідних лістингів.
1.9. резюме
Взаємодія процесів традиційно є однією з проблемних областей в Unix. У міру розвитку системи пропонувалися різні рішення, і жодне з них не було досконалим. Ми розділяємо IPC на чотири основних типи.
1. Передача повідомлень (канали, FIFO, черги повідомлень).
2. Синхронізація (взаємні виключення, умовні змінні, блокування читання-запису, семафори).
3. Колективна пам'ять (неіменованого і іменована).
4. Виклик процедур (двері в Solaris, RPC Sun).
Ми розглядаємо взаємодію як окремих потоків одного процесу, так і декількох незалежних процесів.
Живучість кожного типу IPC визначається або процесом, або ядром, або файлової системою в залежності від тривалості його існування. При виборі типу IPC для конкретного застосування потрібно враховувати його живучість.
Іншим властивістю кожного типу IPC є простір імен, що визначає ідентифікацію об'єктів IPC процесами і потоками, що використовують його. Деякі об'єкти не мають імен (канали, взаємні виключення, умовні змінні, блокування читання-запису), інші мають іменами в рамках файлової системи (канали FIFO), треті характеризуються тим, що в розділі 2 названо «іменами IPC стандарту Posix», а четверті - ще одним типом імен, який описаний в розділі 3 (ключі або ідентифікатори IPC стандарту System V). Зазвичай сервер створює об'єкт IPC з деяким ім'ям, а клієнти використовують це ім'я для отримання доступу до об'єкта.
У вихідних кодах, наведених в книзі, використовуються функції-обгортки, описані в розділі 1.6, що дозволяють зменшити обсяг коду, забезпечуючи, тим не менш, перевірку повернення помилки для будь-якої функції, що викликається. Імена всіх функцій-обгорток починаються з великої літери.
Стандарти IEEE Posix - Posix.1, що визначає основи інтерфейсу С Unix, і Posix.2, що визначає основні команди, - це ті стандарти, до яких рухаються більшість виробників. Однак стандарти Posix в даний час швидко поглинаються (включаються в якості частини) і розширюються комерційними стандартами, зокрема The Open Group (Unix 98).
Таблиця 1.5. Версії моделі клієнт-сервер
| лістинг | опис |
|---|---|
| 4.1 | Два каналу між батьківським і породженим процесами |
| 4.5 | Використовує popen і cat |
| 4.6 | Використовує два каналу FIFO між батьківським і породженим процесами |
| 4.7 | Два каналу FIFO між незалежним сервером і неспоріднених клієнтом |
| 4.10 | Канали FIFO між незалежним послідовним сервером і декількома клієнтами |
| 4.12 | Програмний канал або FIFO: формування записів в потоці байтів |
| 6.7 | Дві черги повідомлень System V |
| 6.12 | Одна чергу повідомлень System V з декількома клієнтами |
| 6.16 | Одна чергу повідомлень System V для кожного клієнта; клієнтів кілька |
| 15.15 | Передача дескриптора через двері |
Таблиця 1.6. Версії моделі виробник-споживач
| лістинг | опис |
|---|---|
| 7.1 | Взаємне виключення, кілька виробників, один споживач |
| 7.5 | Взаємне виключення і умовна змінна, кілька виробників, один споживач |
| 10.8 | Іменовані семафори Posix, один виробник, один споживач |
| 10.11 | Семафори Posix в пам'яті, один виробник, один споживач |
| 10.12 | Семафори Posix в пам'яті, кілька виробників, один споживач |
| 10.15 | Семафори Posix в пам'яті, кілька виробників, декілька споживачів |
| 10.18 | Семафори Posix в пам'яті, один виробник, один споживач: кілька буферів |
Таблиця 1.7. Версії програми зі збільшенням послідовного номера
| лістинг | опис |
|---|---|
| 9.1 | Індекс в файлі, без блокування |
| 9.3 | Індекс в файлі, блокування за допомогою fcntl |
| 9.9 | Індекс в файлі, блокування з використанням функції open |
| 10.10 | Індекс в файлі, блокування за допомогою іменованого семафора Posix |
| 12.2 | Індекс в загальній пам'яті mmap, блокування за допомогою іменованого семафора Posix |
| 12.3 | Індекс в загальній пам'яті mmap, блокування за допомогою семафора Posix в пам'яті |
| 12.4 | Індекс в неіменованого загальної пам'яті 4.4BSD, блокування за допомогою іменованого семафора Posix |
| 12.5 | Індекс в загальній пам'яті SVR4 / dev / zero, блокування за допомогою іменованого семафора Posix |
| 13.6 | Індекс в загальній пам'яті Posix, блокування за допомогою семафора Posix в пам'яті |
| А.19 | Вимірювання продуктивності: блокування взаємним винятком між потоками |
| А.22 | Вимірювання продуктивності: блокування читання-запису між потоками |
| А.23 | Вимірювання продуктивності: блокування між потоками за допомогою семафорів Posix в пам'яті |
| А.25 | Вимірювання продуктивності: блокування між потоками за допомогою іменованих семафорів Posix |
| А.28 | Вимірювання продуктивності: блокування між потоками за допомогою семафорів System V |
| А.29 | Вимірювання продуктивності: блокування між потоками за допомогою fcntl |
| А.33 | Вимірювання продуктивності: блокування між процесами за допомогою взаємних виключень |
вправи
1. На рис 1.1 зображені два процеси, які звертаються до одного файлу. Якщо обидва процеси тільки дописують дані до кінця файлу (можливо, довгого), який потрібен буде тип синхронізації?
2. Вивчіть заголовки
3. Доповніть табл. 1.3 використовуваними вами функціями, підтримуваними Unix-системами.
ГЛАВА 2
2.1. Вступ
З наявних типів IPC наступні три можуть бути віднесені до Posix IPC, тобто до методів взаємодії процесів, що відповідає стандарту Posix:
■ черги повідомлень Posix (глава 5);
■ семафори Posix (глава 10);
■ колективна пам'ять Posix (глава 13).
Ці три види IPC мають загальні властивості, і для роботи з ними використовуються схожі функції. У цьому розділі мова піде про загальні вимоги до повних іменах файлів, які використовуються в якості ідентифікаторів, про прапори, що вказуються при відкритті або створенні об'єктів IPC, і про дозволи на доступ до них.
Повний список функцій, які використовуються для роботи з даними типами IPC, наведено в табл. 2.1.
Таблиця 2.1. Функції Posix IPC
| черги повідомлень | семафори | спільна пам'ять | |
|---|---|---|---|
| заголовки | |||
| Функції для створення, відкриття та видалення | mq_open mq_close mq_unlink | sem_open sem_close sem_unlink sem_init sem_destroy | shm_open shm_unlink |
| операції управління | mq_getattr mq_setattr | ftruncate fstat | |
| операції IPC | mq_send mq_receive mq_notify | sem_wait sem_trywait sem_post sem_getvalue | mmap munmap |
2.2. імена IPC
У табл. 1.2 ми відзначили, що три типу IPC стандарту Posix мають ідентифікатори (імена), відповідають вимогам цього стандарту. Ім'я IPC передається через перший аргумент однієї з трьох функцій: mq_open, sem_open і shm_open, причому воно не обов'язково має відповідати реальному файлу в файлової системі. Стандарт Posix.1 накладає на імена IPC наступні обмеження:
■ Ім'я повинно відповідати існуючим вимогам до імен файлів (не перевищує в довжину РАТНМАХ байтів, включаючи завершальний символ з кодом 0).
■ Якщо ім'я починається із слеша (/), виклик будь-який з цих функцій призведе до звернення до однієї і тієї ж черги. В іншому випадку результат залежить від реалізації.
■ Інтерпретація додаткових Слеш в імені залежить від реалізації.
Таким чином, для кращої переносимості імена повинні починатися із слеша (/) і не містити в собі додаткові Слеш. На жаль, ці правила, в свою чергу, призводять до проблем з перенесенням.
В системі Solaris 2.6 потрібна наявність початкового слеша і забороняється використання додаткових. Для черзі повідомлень, наприклад, при цьому створюються три файли в каталозі / tmp, причому імена цих файлів починаються с.MQ. Наприклад, якщо аргумент функції mq_open має вигляд /queue.1234, то створені файли будуть мати імена /tmp/.MQDqueue.1234, /tmp/.MQLqueue.1234 і /tmp/.MQPqueue.1234. У той же час в системі Digital Unix 4.0B просто створюється файл із зазначеним при виконанні функції ім'ям.
Проблема з перенесенням виникає при вказівці імені з єдиним слешем на початку: при цьому нам потрібно мати дозвіл на запис в кореневій каталог. Наприклад, черга з ім'ям /tmp.1234 допустима стандартом Posix і не викличе проблем в системі Solaris, але в Digital Unix виникне помилка створення файлу, якщо дозволу на запис в кореневій каталогу програми немає. Якщо ми вкажемо ім'я /tmp/test.1234, проблеми в Digital Unix і аналогічних системах, створюють файл з зазначеним ім'ям, Пропадуть (передбачається існування каталогу / tmp і наявність у програми дозволу на запис в нього, що зазвичай для більшості систем Unix), проте в Solaris використання цього імені буде неможливо.
Для вирішення подібних проблем з перенесенням слід визначати ім'я в заголовку за допомогою директиви #define, щоб забезпечити легкість його зміни при перенесенні програми в іншу систему.
ПРИМІТКА
Розробники прагнули дозволити використання черг повідомлень, семафорів і розділяється пам'яті для існуючих ядер Unix і в незалежних бездискових системах. Це той випадок, коли стандарт виходить надто загальним і в результаті викликає проблеми з перенесенням. Відносно Posix це називається «як стандарт стає нестандартним».
Стандарт Posix.1 визначає три макросу:
які приймають єдиний аргумент - покажчик на структуру типу stat, вміст якої задається функціями fstat, lstat і stat. Ці три макросу повертають ненульове значення, якщо зазначений об'єкт IPC (черга повідомлень, семафор або сегмент розділяється пам'яті) реалізований як особливий вид файлу і структура stat посилається на цей тип. В іншому випадку макрос повертає 0.
ПРИМІТКА
На жаль, користі від цих макросів мало, тому що немає ніяких гарантій, що ці типи IPC реалізовані як окремі види файлів. Наприклад, в Solaris 2.6 все три макросу завжди повертають 0.
Всі інші макроси, використовувані для перевірки типу файлу, мають імена, що починаються з S_IS, і приймають завжди єдиний аргумент: поле st_mode структури stat. Оскільки макроси, використовувані для перевірки типу IPC, приймають аргументи іншого типу, їх імена починаються з S_TYPEIS.
функція px_ipc_name
Існує й інше рішення згаданої проблеми з перенесенням. Можна визначити нашу власну функцію px_ipc_name, яка додає необхідний каталог як префікс до імені Posix IPC.
char * px_ipc_name (const char * name);
/ * Повертає покажчик при успішному завершенні, NULL при виникненні помилки * /
ПРИМІТКА
Так виглядають листинги наших власних функцій, тобто функцій, які не є стандартними системними. Зазвичай включається заголовки unpipc.h (лістинг B.1).
аргумент паті(Ім'я) не повинен містити Слеш. Тоді, наприклад, при виклику px_ipc_name ( "test1") буде повернуто покажчик на рядок / test1 в Solaris 2.6 або на рядок / tmp / test1 в Digital Unix 4.0B. Пам'ять для повертається рядки виділяється динамічно і звільняється викликом free. Можна встановити довільне значення змінної оточення PX_IPC_NAME, щоб задати інший каталог за замовчуванням.
У лістингу 2.1 приведений наш варіант реалізації цієї функції.
Лістинг 2.1. Функція px_ipc_name в нашій реалізації.ПРИМІТКА
Можливо, в цьому лістингу ви в перший раз зустрінетеся з функцією snprintf. Значна частина існуючих програм використовують замість неї функцію sprintf, проте остання не виробляє перевірки переповнення приймального буфера. На відміну від неї snprintf отримує в якості другого аргументу розмір приймального буфера і згодом запобігає його переповнення. Умисне переповнення буфера програми, що використовує sprintf, протягом багатьох років використовувалося хакерами для злому систем.
Функція snprintf ще не є частиною стандарту ANSI З, але планується її включення в оновлений стандарт, який називається С9Х. Проте багато виробників включають її в стандартну бібліотеку С. Скрізь в тексті ми використовуємо функцію snprintf в нашому власному варіанті, що забезпечує виклик sprintf, якщо в системній бібліотеці функція snprinft відсутня.
3 px_ipc_name (const char * name)
6 if ((dst \u003d malloc (РАТН_МАХ)) \u003d\u003d NULL)
8 / * є можливість задати інше ім'я каталогу за допомогою змінної оточення * /
9 if ((dir \u003d getenv ( "PX IPC_NAME")) \u003d\u003d NULL) (
11 dir \u003d POSIX_IPC_PREFIX; / * З "config.h" * /
13 dir \u003d "/ tmp /"; /* за замовчуванням */
16 / * ім'я каталогу має закінчуватися символом "/" * /
17 slash \u003d (dir \u003d\u003d "/")? "": "/";
18 snprintf (dst, PATH_MAX, "% s% s% s", dir, slash, name);
19 return (dst); / * Для звільнення цього покажчика можна викликати free () * /
2.3. Створення та відкриття каналів IPC
Всі три функції, які використовуються для створення або відкриття об'єктів IPC: mq_open, sem_open і shm_open, - приймають спеціальний прапор oflag в якості другого аргументу. Він визначає параметри відкриття запитуваної об'єкта аналогічно другому аргументу стандартної функції open. Всі константи, з яких можна формувати цей аргумент, наведені в табл. 2.2.
Таблиця 2.2. Константи, що використовуються при створенні і відкритті об'єктів IPC
| опис | mq_open | sem_open | shm_open |
|---|---|---|---|
| тільки читання | О_RDONLY | О_RDONLY | |
| тільки запис | О_WRONLY | ||
| Читання і запис | О_RDWR | О_RDWR | |
| Створити, а то й існує | О_CREAT | О_CREAT | О_CREAT |
| Що виключає створення | О_EXCL | О_EXCL | О_EXCL |
| без блокування | О_NONBLOCK | ||
| Скоротити (truncate) існуючий | O_TRUNC |
Перші три рядки описують тип доступу до створюваного об'єкту: тільки читання, тільки запис, читання і запис. Черга повідомлень може бути відкрита в будь-якому з трьох режимів доступу, тоді як для семафора вказівку цих констант не потрібно (для будь-якої операції з семафором потрібен доступ на читання і запис). Нарешті, об'єкт розділяється пам'яті не може бути відкритий тільки на запис.
Вказівка \u200b\u200bінших прапорів з табл. 2.2 не є обов'язковим.
O_CREAT - створення черги повідомлень, семафори або сегмента розділяється пам'яті, якщо такий ще не існує (див. Також прапор O_EXCL, що впливає на результат).
При створенні нової черги повідомлень, семафори або сегмента розділяється пам'яті виникне потреба у вказівках по принаймні одного додаткового аргументу, що визначає режим. Цей аргумент вказує біти дозволу на доступ до файлу і формується шляхом побітового логічного складання констант з табл. 2.3.
Таблиця 2.3. Константи режиму доступу при створенні нового об'єкта IPC
Ці константи визначені в заголовку
Як і з новоствореним файлом, при створенні черги повідомлень, семафори або сегмента розділяється пам'яті їм присвоюється ідентифікатор користувача, відповідає чинному (effective) код користувача процесу. Ідентифікатор групи семафора або сегмента розділяється пам'яті встановлюється рівним чинному групового ідентифікатором або групового ідентифікатора, встановленому за замовчуванням для системи в цілому. Груповий ідентифікатор черги повідомлень завжди встановлюється рівним чинному групового ідентифікатором (на с. 77-78 розповідається про групових і призначених для користувача ідентифікатори більш докладно).
ПРИМІТКА
Здається дивним наявність різниці в установці групового ідентифікатора для різних видів Posix IPC. Груповий ідентифікатор нового файлу, що створюється за допомогою функції open, встановлюється рівним або дійсному кодом процесу, або кодом каталогу, в якому створюється файл, але функції IPC не можуть заздалегідь припускати, що для об'єкта IPC створюється реальний файл в файловій системі.
O_EXCL - якщо цей прапор вказано одночасно з O_CREAT, функція створює нову чергу повідомлень, семафор або об'єкт розділяється пам'яті тільки в тому випадку, якщо такої не існує. Якщо об'єкт уже існує і вказані прапори O_CREAT | O_EXCL, повертається помилка EEXIST.
Перевірка існування черги повідомлень, семафори або сегмента розділяється пам'яті і його створення (у разі відсутності) повинні проводитися тільки одним процесом. Два аналогічних прапора є і в System V IPC, вони описані в розділі 3.4.
O_NONBLOCK - цей прапор створює чергу повідомлень без блокування. Блокування зазвичай встановлюється для зчитування з порожньою черзі або записи в повну чергу. Про це більш детально розказано в підрозділах, присвячених функціям mq_send і mq_receive розділу 5.4.
O_TRUNC - якщо вже існуючий сегмент загальної пам'яті відкритий на читання і запис, цей прапор вказує на необхідність скоротити його розмір до 0.
На рис. 2.1 показана реальна послідовність логічних операцій при відкритті об'єкта IPC. Що саме мається на увазі під перевіркою дозволів доступу, ви дізнаєтеся в розділі 2.4. Інший підхід до зображеного на рис. 2.1 представлений в табл. 2.4.
Мал. 2.1. Логіка відкриття об'єкта IPC
Зверніть увагу, що в середньої рядку табл. 2.4, де заданий тільки прапор O_CREAT, ми не отримуємо ніякої інформації про те, чи був створений новий об'єкт або відкритий існуючий.
Таблиця 2.4. Логіка відкриття об'єкта IPC
| аргумент oflag | Об'єкт не існує | Об'єкт уже існує |
|---|---|---|
| Немає спеціальних прапорів | Помилка, errno \u003d ENOENT | |
| O_CREAT | OK, створюється новий об'єкт | OK, відкривається існуючий об'єкт |
| O_CREAT | O_EXCL | OK, створюється новий об'єкт | Помилка, errno \u003d EEXIST |
2.4. Дозволи IPC
Нова чергу повідомлень, іменований семафор або сегмент розділяється пам'яті створюється функціями mq_open, sem_open і shm_open, за умови, що аргумент oflag містить константу O_CREAT. Згідно табл. 2.3, будь-якого з даних типів IPC присвоюються певні права доступу (permissions), аналогічні дозволами доступу до файлів в Unix.
При відкритті існуючої черги повідомлень, семафори або сегмента розділяється пам'яті тими ж функціями (в разі, коли не вказано прапор O_CREAT або зазначено O_CREAT без O_EXCL і об'єкт вже існує) проводиться перевірка дозволів:
1. Перевіряються біти дозволів, присвоєні об'єкту IPC при створенні.
2. Перевіряється запитаний тип доступу (O_RDONLY, O_WRONLY, O_RDWR).
3. Перевіряється діючий ідентифікатор користувача викликає процесу, діючий груповий ідентифікатор процесу і додаткові групові ідентифікатори процесу (останні можуть не підтримуватися).
Більшістю систем Unix виробляються такі конкретні перевірки:
1. Якщо діючий ідентифікатор користувача для процесу є 0 (привілейований користувач), доступ буде дозволений.
2. Якщо діючий ідентифікатор користувача процесу збігається з ідентифікатором власника об'єкта IPC: якщо відповідний біт дозволу для користувача встановлений, доступ дозволений, інакше в доступі відмовляється.
Під відповідним бітом дозволу ми маємо на увазі, наприклад, біт дозволу на читання, якщо процес відкриває об'єкт тільки для читання. Якщо процес відкриває об'єкт для запису, повинен бути встановлений відповідно біт дозволу на запис для власника (user-write).
3. Якщо діючий ідентифікатор групи процесу або один з додаткових групових ідентифікаторів процесу збігається із груповим ідентифікатором об'єкта IPC: якщо відповідний біт дозволу для групи встановлено, доступ буде дозволений, інакше в доступі відмовляється.
4. Якщо відповідний біт дозволу доступу для інших користувачів встановлений, доступ буде дозволений, інакше в доступі буде відмовлено.
Ці чотири перевірки проводяться в зазначеному порядку. Отже, якщо процес є власником об'єкта IPC (крок 2), доступ дозволяється або забороняється на основі одних тільки дозволів користувача (власника). Дозволи групи при цьому не перевіряються. Аналогічно, якщо процес не є власником об'єкта IPC, але належить до потрібної групи, доступ дозволяється або забороняється на основі дозволів групи - дозволу для інших користувачів при цьому не перевіряються.
ПРИМІТКА
Згідно табл. 2.2, функція sem_open не використовує прапори O_RDONLY, O_WRONLY, O_RDWR. У розділі 10.2, однак, буде сказано про те, що деякі реалізації Unix мають на увазі наявність прапора O_RDWR, тому що будь-яке звернення до семафора має на увазі читання і запис його значення.
2.5. резюме
Три типу Posix IPC - черги повідомлень, семафори і колективна пам'ять - ідентифікуються їх повними іменами. Вони можуть бути або не бути реальними іменами файлів в файлову систему, і це викликає проблеми з перенесенням. Рішення проблеми - використовувати власну функцію px_ipc_name. При створенні або відкритті об'єкта IPC потрібно вказати набір прапорів, аналогічних вказаним при використанні функції open. При створенні нового об'єкта IPC потрібно вказати дозволу для нього, використовуючи ті ж константи S_xxx, що і для функції open (табл. 2.3). При відкритті існуючого об'єкта IPC проводиться перевірка дозволів процесу, аналогічна перевірці при відкритті файлу.
вправи
1. Яким чином біти установки ідентифікатора користувача (set-user-ID, SUID) та установки ідентифікатора групи (set-group-ID) (розділ 4.4) програми, що використовує Posix IPC, впливають на перевірку дозволів, описану в розділі 2.4?
2. Коли програма відкриває об'єкт IPC, як вона може визначити, чи був створений новий об'єкт IPC або виробляється звернення до існуючого об'єкту?
ГЛАВА 3
3.1. Вступ
З наявних типів IPC наступні три можуть бути віднесені до System V IPC, тобто до методів взаємодії процесів, що відповідає стандарту System V:
■ черги повідомлень System V (глава 6);
■ семафори System V (глава 11);
■ спільна пам'ять System V (глава 14).
Термін «System V IPC» говорить про походження цих коштів: вперше вони з'явилися в Unix System V. У них багато спільного: схожі функції, за допомогою яких організовується доступ до об'єктів; також схожі форми зберігання інформації в ядрі. У цьому розділі описуються загальні для трьох типів IPC риси.
Інформація про функції зведена в табл. 3.1.
Таблиця 3.1. Функції System V IPC
ПРИМІТКА
Інформація про історію розробки і розвитку функцій System V IPC не надто легко доступна. надає наступну інформацію: черги повідомлень, семафори і колективна пам'ять цього типу були розроблені в кінці 70-х в одному з філіалів Bell Laboratories в місті Колумбус, штат Огайо, для однієї з версій Unix, призначеної для внутрішнього використання. Версія ця називалася Columbus Unix, або CB Unix. Вона використовувалася в так званих системах підтримки операцій - системах обробки транзакцій - для автоматизації управління і ведення записів в телефонній компанії. System V IPC були додані в комерційну версію Unix System V. приблизно в 1983 році.
3.2. Ключі типу key_t і функція ftok
У табл. 1.2 було відзначено, що в іменах трьох типів System V IPC використовувалися значення key_t. заголовки
Функція ftok перетворює існуюче повне ім'я та цілочисельний ідентифікатор в значення типу key_t (зване ключем IPC - IPC key):
key_t ftok (const char * Pathname, int id);
// Повертає ключ IPC або -1 при виникненні помилки
Насправді функція використовує повне ім'я файлу і молодші 8 біт ідентифікатора для формування целочисленного ключа IPC.
Ця функція діє в припущенні, що для конкретного додатка, що використовує IPC, клієнт і сервер використовують один і той же повне ім'я об'єкта IPC, що має якесь значення в контексті програми. Це може бути ім'я демона сервера або ім'я файлу даних, використовуваного сервером, або ім'я ще якогось об'єкта файлової системи. Якщо клієнту і серверу для зв'язку потрібно тільки один канал IPC, ідентифікатором можна привласнити, наприклад, значення 1. Якщо потрібно кілька каналів IPC (наприклад, один від сервера до клієнта і один в зворотну сторону), ідентифікатори повинні мати різні значення: наприклад, 1 і 2. Після того як клієнт і сервер домовляться про повну імені та ідентифікатор, вони обидва викликають функцію ftok для отримання однакового ключа IPC.
Більшість реалізацій ftok викликають функцію stat, а потім об'єднують:
■ інформацію про файлову систему, до якої відноситься повне ім'я pathname (Поле st_dev структури stat);
■ номер вузла (i-node) в файлової системі (поле st_ino структури stat);
■ молодші 8 біт ідентифікатора (який не повинен дорівнювати нулю).
З комбінації цих трьох значень зазвичай виходить 32-розрядний ключ. Немає ніякої гарантії того, що для двох різних шляхів з одним і тим же ідентифікатором вийдуть різні ключі, оскільки кількість біт інформації в трьох перерахованих елементах (ідентифікатор файлової системи, номер вузла, ідентифікатор IPC) може перевищувати число біт в цілому (див. Вправу 3.5 ).
ПРИМІТКА
Номер вузла завжди відмінний від нуля, тому більшість реалізацій визначають константу IPC_PRIVATE (розділ 3.4) дорівнює нулю.
Якщо вказане повне ім'я не існує або недоступне викликає процесу, ftok повертає значення -1. Пам'ятайте, що файл, ім'я якого використовується для обчислення ключа, не повинен бути одним з тих, які створюються і видаляються сервером в процесі роботи, оскільки кожен раз при створенні заново ці файли отримують, взагалі кажучи, інший номер вузла, а це може змінити ключ , що повертається функцією ftok при черговому виклику.
приклад
Програма в лістингу 3.1 приймає повне ім'я як аргумент командного рядка, викликає функції stat і ftok, потім виводить значення полів st_dev і st_ino структури stat і виходить ключ IPC. Ці три значення виводяться в шістнадцятковому форматі, тому легко бачити, як саме ключ IPC формується з цих двох значень і ідентифікатора 0x57.
Лістинг 3.1. Отримання і висновок інформації про фото і створеного ключа IPC7 err_quit ( "usage: ftok");
9 printf ( "st_dev: & lx, st_ino:% Ix, key:% x \\ n",
10 (u_long) stat.st_dev, (u_long) stat.st_ino,
Виконання цієї програми в системі Solaris 2.6 призведе до наступних результатів:
solaris% ftok / etc / system
st_dev: 800018, st_ino: 4a1b, key: 57018a1b
solaris% ftok / usr / tmp
st_dev: 800015, st_ino: 10b78, key: 57015b78
solaris% ftok /home/rstevens/Mail.out
st_dev: 80001f, st_ino: 3b03, key: 5702fb03
Очевидно, ідентифікатор визначає старші 8 біт ключа; молодші 12 біт st_dev визначають наступні 12 біт ключа, і нарешті, молодші 12 біт st_ino визначають молодші 12 біт ключа.
Мета цього прикладу не в тому, щоб згодом розраховувати на такий спосіб формування ключа з перерахованої інформації, а в тому, щоб проілюструвати алгоритм комбінації повного імені та ідентифікатора конкретною реалізацією. В інших реалізаціях алгоритм може бути іншим.
ПРИМІТКА
У FreeBSD використовуються молодші 8 біт ідентифікатора, молодші 8 біт st_dev і молодші 16 біт st_ino.
Врахуйте, що відображення, яке виробляється функцією ftok, - одностороннє, оскільки частина біт st_dev і st_ino не використовуються. за даному ключу не можна визначити повне ім'я файлу, задане для обчислень.
3.3. структура ipc_perm
Для кожного об'єкта IPC, як для звичайного файлу, в ядрі зберігається набір інформації, об'єднаної в структуру.
uid_t uid; / * Ідентифікатор користувача власника * /
gid_t gid; / * Ідентифікатор групи власника * /
uid_t cuid; / * Ідентифікатор користувача творця * /
gid_t cgid; / * Ідентифікатор групи творця * /
mode_t mode; / * Дозволу читання-запису * /
ulong_t seq; / * Послідовний номер каналу * /
key_t key; / * Ключ IPC * /
Ця структура разом з іншими перейменованими константами для функцій System V IPC визначена в файлі
3.4. Створення та відкриття каналів IPC
Три функції getXXX, використовувані для створення або відкриття об'єктів IPC (табл. 3.1), приймають ключ IPC (типу key_t) в якості одного з аргументів і повертають цілочисельний ідентифікатор. Цей ідентифікатор відрізняється від того, який передавався функції ftok, як ми незабаром побачимо. У додатку є дві можливості завдання ключа (перший аргумент функцій getXXX):
1. Викликати ftok, передати їй повне ім'я та ідентифікатор.
2. Вказати як ключ константу IPCPRIVATE, що гарантує створення нового унікального об'єкта IPC.
Послідовність дій ілюструє рис. 3.1.
Мал. 3.1. Обчислення ідентифікаторів IPC по ключам
Всі три функції getXXX (табл. 3.1) приймають в якості другого аргументу набір прапорів oflag, задає біти дозволів читання-запису (поле mode структури ipc_perm) для об'єкта IPC і визначає, чи створюється новий об'єкт IPC або виробляється звернення до вже існуючого. Для цього є такі правила.
■ Ключ IPC_PRIVATE гарантує створення унікального об'єкта IPC. Ніякі можливі комбінації повного імені та ідентифікатора не можуть привести до того, що функція ftok поверне в якості ключа значення IPC_PRIVATE.
■ Встановлення біта IPC_CREAT аргументу oflag призводить до створення нового запису для зазначеного ключа, якщо вона ще не існує. Якщо ж виявляється існуюча запис, повертається її ідентифікатор.
Одночасна установка бітів IPC_CREAT і IPC_EXCL аргументу oflagпризводить до створення нового запису для зазначеного ключа тільки в тому випадку, якщо такий запис ще не існує. Якщо ж виявляється існуюча запис, функція повертає помилку EEXIST (об'єкт IPC вже існує).
Комбінація IPC_CREAT і IPC_EXCL щодо об'єктів IPC діє аналогічно комбінації O_CREAT і O_EXCL для функції open.
Установка тільки біта IPC_EXCL без IPC_CREAT ніякого ефекту не дає.
Логічна діаграма послідовності дій при відкритті об'єкта IPC зображена на рис. 3.2. У табл. 3.2 показаний альтернативний погляд на цей процес.
Мал. 3.2. Діаграма відкриття об'єкта IPC
Зверніть увагу, що в середньої рядку табл. 3.2 для прапора IPC_CREAT без IPC_EXCL ми не отримуємо ніякої інформації про те, чи був створений новий об'єкт або отриманий доступ до існуючого. Для більшості додатків характерно створення сервером об'єкта IPC із зазначенням IPC_CREAT (якщо байдуже, чи існує вже об'єкт) або IPC_CREAT | IPC_EXCL (якщо потрібна перевірка існування об'єкта). Клієнт взагалі не вказує прапорів, припускаючи, що сервер вже створив об'єкт.
ПРИМІТКА
Функції System V IPC на відміну від функцій Posix IPC визначають свої власні константи IРС_ххх замість використання O_CREAT і OEXCL, прийнятих стандартною функцією open (табл. 2.2).
Зверніть також увагу на те, що функції System V IPC поєднують константи IРС_ххх з битами дозволів (описаними в наступному розділі) в єдиному аргументі oflag, тоді як для функції open і для Posix IPC характерна наявність двох аргументів: oflag, в якому задаються прапори виду О_ххх , і mode, що визначає біти дозволів доступу.
Таблиця 3.2. Логіка створення і відкриття об'єктів IPC
| аргумент oflag | Ключ не існує | ключ існує |
|---|---|---|
| Спеціальні прапори не встановлені | Помилка, errno \u003d ENOENT | OK, відкриття існуючого об'єкта |
| IPC_CREAT | OK, створюється новий запис | OK, відкриття існуючого |
| IPC CREAT | IPC_EXCL | OK, створюється новий запис | Помилка, errno \u003d EEXIST |
3.5. Дозволи IPC
При створенні нового об'єкта IPC за допомогою однієї з функцій getXXX, викликаної з прапором IPC_CREAT, в структуру ipc_perm заноситься наступна інформація (розділ 3.3):
1. Частина бітів аргумента oflag задають значення поля mode структури ipc_perm. У табл. 3.3 наведені біти дозволів для трьох типів IPC (запис \u003e\u003e 3 означає зрушення вправо на три біта).
2. Поля cuid і cgid отримують значення, рівні діючим ідентифікаторів користувача і групи викликає процесу. Ці два поля називаються ідентифікаторами творця.
3. Поля uid і gid структури iрс_perm також встановлюються рівними чинним ідентифікаторів викликає процесу. Ці два поля називаються ідентифікаторами власника.
Таблиця 3.3. Значення mode для дозволів читання-запису IPC
| Число (вісімкове) | черга повідомлень | семафор | колективна пам'ять | опис |
|---|---|---|---|---|
| 0400 | MSG_R | SEM_R | SHM_R | Користувач - читання |
| 0200 | MSG_W | SEM_A | SHM_W | Користувач - запис |
| 0040 | MSG R \u003e\u003e 3 | SEM_R \u003e\u003e 3 | SHM_R \u003e\u003e 3 | Група - читання |
| 0020 | MSG_W \u003e\u003e 3 | SEM_A \u003e\u003e 3 | SHM_W \u003e\u003e 3 | Група - запис |
| 0004 | MSG_R \u003e\u003e 6 | SEM_R \u003e\u003e 6 | SHM_R \u003e\u003e 6 | Інші - читання |
| 0002 | MSG_W \u003e\u003e 6 | SEM_A \u003e\u003e 6 | SHM_W \u003e\u003e 6 | Інші - запис |
Ідентифікатор творця змінюватися не може, тоді як ідентифікатор власника може бути змінений процесом за допомогою виклику функції ctlXXX для даного механізму IPC з командою IPC_SET. Три функції ctlXXX дозволяють процесу змінювати біти дозволів доступу (поле mode) об'єкта IPC.
ПРИМІТКА
У більшості реалізацій визначено шість констант: MSG_R, MSG_W, SEM_R, SEM_A, SHM_R і SHM_W, показані в табл. 3.3. Константи ці визначаються в заголовних файлах
, і . Однак стандарт Unix 98 не вимагає їх наявності. Суфікс А в SEM_A означає «alter» (зміна). Трійка функцій getXXX не використовують стандартну маску створення файлу Unix. Дозволи черги повідомлень, семафори і розділяється пам'яті встановлюються в точності рівними аргументу функції.
Posix IPC не дає творцеві IPC можливості змінити власника об'єкта. У Posix немає аналогів команди IPC_SET. Однак в Posix IPC ім'я об'єкта належить файлової системи, і тому власник може бути змінений привілейованим користувачем за допомогою команди chown.
Коли будь-який процес робить спробу доступу до об'єкта IPC, проводиться двоетапна перевірка: перший раз при відкритті файлу (функція getXXX) і потім кожен раз при зверненні до об'єкта IPC:
1. При установці доступу до існуючого об'єкта IPC за допомогою однієї з функцій getXXX проводиться первинна перевірка аргументу oflag, що викликає функцію процесу. Аргумент не повинен вказувати біти доступу, не встановлені в поле mode структури ipc_perm (нижній квадрат на рис. 3.2). Наприклад, процес-сервер може встановити значення члена mode для своєї черги вхідних повідомлень, скинувши біти читання для групи і інших користувачів. Будь-який процес, який спробував вказати ці біти в аргументі oflag функції msgget, отримає помилку. Треба відзначити, що від цієї перевірки, виробленої функціями getXXX, мало користі. Вона має на увазі наявність у викликає процесу інформації про те, до якої групи користувачів він належить: він може бути власником файлу, може належати до тієї ж групи або до інших користувачам. Якщо створює процес скине деякі біти дозволів, а викликає процес спробує їх встановити, функція getXXX поверне помилку. Будь-який процес може повністю пропустити цю перевірку, вказавши аргумент oflag, рівний 0, якщо заздалегідь відомо про існування об'єкта IPC.
2. При будь-якої операції з об'єктами IPC проводиться перевірка дозволів для процесу, цю операцію запитувача. Наприклад, кожен раз коли процес намагається помістити повідомлення в чергу за допомогою команди msgsnd, виробляються нижченаведені перевірки (при отриманні доступу наступні етапи пропускаються).
□ привілейований користувач доступ надається завжди.
□ Якщо діючий ідентифікатор користувача збігається зі значенням uid або cuid об'єкта IPC та встановлено відповідний біт дозволу доступу в поле mode об'єкта IPC, доступ буде дозволений. Під відповідним бітом дозволу доступу мається на увазі біт, що дозволяє читання, якщо викликає процес запитує операцію читання для даного об'єкта IPC (наприклад, отримання повідомлення з черги), або біт, що дозволяє запис, якщо процес хоче здійснити її.
□ Якщо діючий ідентифікатор групи збігається зі значенням gid або cgid об'єкта IPC та встановлено відповідний біт дозволу доступу в поле mode об'єкта IPC, доступ буде дозволений.
□ Якщо доступ не був дозволений на попередніх етапах, перевіряється наявність відповідних встановлених бітів доступу для інших користувачів.
3.6. Повторне використання ідентифікаторів
Структура ipc_perm (розділ 3.3) містить змінну seq, в якій зберігається порядковий номер каналу. Ця змінна є лічильник, що заводяться ядром для кожного об'єкта IPC в системі. При видаленні об'єкта IPC номер каналу збільшується, а при переповненні скидається в нуль.
ПРИМІТКА
У цьому розділі ми описуємо характерну для SVR4 реалізацію. Стандарт Unix 98 не виключає використання інших варіантів.
У лічильнику виникає потреба з двох причин. По-перше, згадаємо про дескрипторах файлів, що зберігаються в ядрі для кожного з відкритих файлів. Вони зазвичай представляють собою невеликі цілі числа, що мають значення тільки всередині одного процесу - для кожного процесу створюються власні дескриптори. Прочитати з файлу з дескриптором 4 можна тільки в тому процесі, в якому є відкритий файл з таким дескриптором. Чи є відкриті файли з тим же дескриптором в інших процесах - значення не має. На відміну від дескрипторів файлів ідентифікатори System V IPC встановлюються для всієї системи, а не для процесу.
Ідентифікатор IPC повертається однією з функцій getXXX: msgget, semget, shmget. Як і дескриптори файлів, ідентифікатори представляють собою цілі числа, які мають на відміну від дескрипторів однакове значення для всіх процесів. Якщо два неспоріднених процесу (клієнт і сервер) використовують одну чергу повідомлень, її ідентифікатор, що повертається функцією msgget, повинен мати один і той же цілочисельне значення в обох процесах, щоб вони отримали доступ до однієї і тієї ж черги. Така особливість дає можливість будь-якому процесу, створеному зловмисником, спробувати прочитати повідомлення з черги, створеної іншою програмою, послідовно перебираючи різні ідентифікатори (якби вони представляли собою невеликі цілі числа) і сподіваючись на існування відкритої в поточний момент черги, доступною для читання всім . Якби ідентифікатори представляли собою невеликі цілі числа (як дескриптори файлів), ймовірність знайти правильний ідентифікатор становила б близько 1/50 (припускаючи обмеження в 50 дескрипторів на процес).
Для виключення такої можливості розробники засобів IPC вирішили розширити можливий діапазон значень ідентифікатора так, щоб він включав взагалі все цілі числа, а не тільки невеликі. Розширення діапазону забезпечується шляхом збільшення значення ідентифікатора, що повертається зухвалому процесу, на кількість записів в системній таблиці IPC кожен раз, коли відбувається повторне використання однієї з них. Наприклад, якщо система налаштована на використання не більше 50 черг повідомлень, при першому використанні першого запису процесу буде повернутий ідентифікатор 0. Після видалення цієї черги повідомлень при спробі повторного використання першого запису в таблиці процесу буде повернутий ідентифікатор 50. Далі він буде приймати значення 100, 150 і т. д. Оскільки seq зазвичай визначається як довге ціле без знака (ulong - см. структуру ipc_perm в розділі 3.3), повернення до вже використовувалися ідентифікаторів відбувається, коли запис в таблиці буде використана 85899346 раз (2³² / 50 в припущенні, що ціле є 32-розрядних).
Другою причиною, по якій знадобилося ввести послідовний номер каналу, є необхідність виключити повторне використання ідентифікаторів System V IPC через невеликий термін. Це допомагає гарантувати те, що достроково завершив роботу і згодом перезапущена сервер не стане використовувати той же ідентифікатор.
Ілюструючи цю особливість, програма в лістингу 3.2 виводить перші десять значень ідентифікаторів, що повертаються msgget.
Лістинг 3.2. Ідентифікація черги повідомлень десять разів поспіль7 msqid \u003d Msgget (IPC_PRIVATE, SVMSG_MODE | IPC_CREAT);
8 printf ( "msqid \u003d% d \\ n", msqid);
9 Msgctl (msqid, IPC_RMID, NULL);
При черговому проходженні циклу msgget створює чергу повідомлень, a msgctl з командою IPC_RMID як аргумент видаляє її. Константа SVMSG_MODE визначається в нашому заголовки unpipc.h (лістинг В.1) і задає дозволу за замовчуванням для черги повідомлень System V. Висновок програми буде мати такий вигляд:
При повторному запуску програми ми побачимо наочну ілюстрацію того, що послідовний номер каналу - це змінна, що зберігається в ядрі і продовжує існувати і після завершення процесу.
3.7. Програми ipcs і ipcrm
Оскільки об'єктів System V IPC не пов'язана із імена в файлової системі, ми не можемо переглянути їх список або видалити їх, використовуючи стандартні програми ls і rm. Замість них в системах, що підтримують ці типи IPC, надаються дві спеціальні програми: Ipcs, що виводить різну інформацію про властивості System V IPC, і ipcrm, що видаляє чергу повідомлень System V, семафор або сегмент розділяється пам'яті. Перша з цих функцій підтримує близько десятка параметрів командного рядка, які керують відображенням інформації про різні типи IPC. Другий (ipcrm) можна задати до шести параметрів. Детальну інформацію про них можна отримати в довідковій системі.
ПРИМІТКА
Оскільки System V IPC НЕ стандартизуется Posix, ці команди не входять в Posix.2. Вони описані в стандарті Unix 98.
3.8. обмеження ядра
Більшості реалізацій System V IPC властиво наявність внутрішніх обмежень, що накладаються ядром. Це, наприклад, максимальна кількість черг повідомлень або обмеження на максимальну кількість семафорів в наборі. Характерні значення цих обмежень наведено в табл. 6.2, 11.1 і 14.1. Велика частина обмежень успадкована від вихідної реалізації System V.
ПРИМІТКА
Розділ 11.2 книги і глава 8 описують реалізацію черг повідомлень, семафорів і розділяється пам'яті в System V. Деякі з цих обмежень описані вже там.
На жаль, деякі з накладених обмежень досить жорсткі, оскільки вони успадковані від вихідної реалізації, що базувалася на системі з невеликим адресним простором (16-розрядний PDP-11). На щастя, більшість систем дозволяють адміністратору змінювати деякі з встановлених за замовчуванням обмежень, але необхідні для цього дії специфічні для кожної версії Unix. У більшості випадків після внесення змін потрібне перезавантаження ядра. На жаль, в деяких реалізаціях для зберігання деяких параметрів до сих пір використовуються 16-розрядні цілі, а це вже встановлює апаратні обмеження.
У Solaris 2.6, наприклад, таких обмежень 20. Їх поточні значення можна вивести на екран, використовуючи команду sysdef. Врахуйте, що замість реальних значень будуть виведені нулі, якщо відповідний модуль ядра не завантажено (тобто засіб не було раніше використано). Це можна виключити, додавши до файлу / etc / system будь-який з нижченаведених операторів. Файл / etc / system зчитується в процесі перезавантаження системи:
set msgsys: msginfo_msgseg \u003d значення
set msgsys: msginfo_msgssz \u003d значення
set msgsys: msginfo_msgtql \u003d значення
set msgsys: msginfo_msgmap \u003d значення
set msgsys: msginfo_msgmax \u003d значення
set msgsys: msginfo_msgmnb \u003d значення
set msgsys: msginfo_msgmni \u003d значення
set semsys: seminfo_semopm \u003d значення
set semsys: seminfo_semume \u003d значення
set semsys: seminfo_semaem \u003d значення
set semsys: seminfo_semmap \u003d значення
set semsys: seminfo_semvmx \u003d значення
set semsys: seminfo_semmsl \u003d значення
set semsys: seminfo_semmni \u003d значення
set semsys: seminfo_semmns \u003d значення
set semsys: seminfo_semmnu \u003d значення
set shmsys: shminfo_shmmin \u003d значення
set shmsys: shminfo_shmseg \u003d значення
set shmsys: shminfo_shmmax \u003d значення
set shmsys: shminfo_shmmni \u003d значення
Останні шість символів імені зліва від знака рівності є змінними, перераховані в табл. 6.2, 11.1 і 14.1.
У Digital Unix 4.0B програма sysconfig дозволяє дізнатися чи змінити безліч параметрів і обмежень ядра. Нижче наведено висновок цієї команди, запущеної з параметром -q. Команда виводить поточні обмеження для підсистеми ipc. Деякі рядки у висновку, що не мають відношення до засобів IPC System V, були опущені:
alpha% / Sbin / sysconfig -q ipc
Для цих параметрів можна вказати інші значення за замовчуванням, змінивши файл / etc / sysconfigtab. Робити це слід за допомогою програми sysconfigdb. Цей файл також зчитується в процесі початкового завантаження системи.
3.9. резюме
Першим аргументом функцій msgget, semget і shmget є ключ IPC System V. Ці ключі обчислюються по повному імені файлу за допомогою системної функції ftok. Як ключ можна також вказати значення IPCPRIVATE. Ці три функції створюють новий об'єкт IPC або відкривають існуючий і повертають ідентифікатор System V IPC - ціле число, яке потім використовується для розпізнавання об'єкта в інших функціях, що мають відношення до IPC. Ці ідентифікатори мають сенс не тільки в рамках одного процесу (як дескриптори файлів), але і в рамках всієї системи. Вони можуть повторно використовуватися ядром, але лише через деякий час.
З кожним об'єктом System V IPC пов'язана структура ipc_perm, що містить інформацію про нього, таку як ідентифікатор користувача власника, ідентифікатор групи, дозволу читання і запису і ін. Однією з відмінностей між System V і Posix IPC є те, що для об'єкта IPC System V ця інформація доступна завжди (доступ до неї можна отримати за допомогою однієї з функцій XXXctl з аргументом IPC_STAT), а в Posix IPC доступ до неї залежить від реалізації. Якщо об'єкт Posix IPC зберігається в файлової системі і ми знаємо його ім'я в ній, ми можемо отримати доступ до цієї інформації, використовуючи стандартні засоби файлової системи.
При створенні нового або відкритті існуючого об'єкта System V IPC функції getXXX передаються два прапора (IPC_CREAT і IPC_EXCL) і 9 біт дозволів.
Без сумніву, найголовнішою проблемою у використанні System V IPC є наявність штучних обмежень у більшості реалізацій. Обмеження накладаються на розмір об'єктів, причому вони беруть свій початок від найперших реалізацій. Це означає, що для інтенсивного використання коштів System V IPC додатками потрібна зміна обмежень ядра, а внесення цих змін до кожної системі здійснюється по-різному.
вправи
1. Прочитайте про функції msgctl в розділі 6.5 і змініть програму в лістингу 3.2 так, щоб виводився не лише ідентифікатор, але і поле seq структури ipc_perm.
2. Безпосередньо після виконання програми лістингу 3.2 ми запускаємо програму, що створює дві черги повідомлень. Припускаючи, що ніякі інші програми не використовували черги повідомлень з моменту завантаження системи, визначте, які значення будуть повернуті функцією msgget в якості ідентифікаторів черг повідомлень.
3. У розділі 3.5 було відзначено, що функції getXXX System V IPC не використовують маску створення файлу. Напишіть тестову програму, що створює канал FIFO (за допомогою функції mkfifо, описаної в розділі 4.6) і черга повідомлень System V, вказавши для обох дозвіл 666 (в вісімковому форматі). Порівняйте дозволу для створених об'єктів (FIFO і черги повідомлень). Перед запуском програми переконайтеся, що значення umask відмінно від нуля.
4. Серверу потрібно створити унікальну чергу повідомлень для своїх клієнтів. Що краще: використовувати будь-яке постійне ім'я файлу (наприклад, ім'я сервера) в якості аргументу функції ftok або використовувати ключ IPC_PRIVATE?
5. Змініть лістинг 3.1 так, щоб виводився тільки ключ IPC і шлях до файлу. Запустіть програму find, щоб вивести список всіх файлів вашої файлової системи, і передайте висновок вашої щойно створеної програмі. Скільком іменах файлів буде відповідати один і той же ключ?
6. Якщо у вашій системі є програма sar (system activity reporter - інформація про активність системи), запустіть команду
На екран буде виведено кількість операцій в секунду з чергами повідомлень і семафора, заміряли кожні 5 секунд 6 разів.
Примітки:
IPC - це, поняття, пов'язане з, але є сенс розібратися в тому, що це таке, більш докладно.
Зміст:
теоретична сторінка
Кожен хоч трохи уявляє собі роботу звичайної операційної системи.
А тепер уявіть, що звична для нас робота нашої ОС перетворилася в свого злого двійника, який не просто не схожий на свій оригінал, але ще і виконує всі свої обов'язки.
Такий розвиток подій цілком могло відбуватися, якби не було вбудовано в нашу систему IPC.
Якщо добре вивчити питання про залежність програм один від одного, то можна зрозуміти, що додатків, що не залежать один від одного, досить мала кількість.
Це цілком логічно, так як для високого коефіцієнта роботи будь-якої системи просто необхідна між складовими.
Наприклад, коли у людини в роботі виникає питання, який залежить від його роботи, він бере потрібну йому інформацію з якогось джерела, будь то людина або будь-який інший джерело.
Хоч «ядро» нашого комп'ютера шукати інформацію в якомусь певному джерелі, принцип роботи по суті той же.
Принцип роботи
Для правильного функціонування системи додатків в обов'язковому порядку потрібна безперервна комунікація між, або вони самі зобов'язані надавати потрібну інформацію на вимогу процесів.
Саме через таку потреби в постійному обміні інформацією з додатками, в операційну систему вбудовується не мала кількість механізмів, які відповідають за підтримання постійного і безпомилкового потоку інформації.
Такі механізми або програми носять назву «межпроцессорной взаємодія» - з перекладу Inter-process Communication (IPC).
важливо: IPC - це механізм або програма, яка забезпечує стабільний взаємний обмін даними у потоків інформації процесу / процесорів.
працює дана програма безпосередньо в самій операційній системі, і є основою для передачі будь-якої інформації.
Приклади роботи IPC
Ще до розвитку мережевих технологій актуальним стало питання про необхідність в передачі інформації від процесора до процесора, які працюють на одному комп'ютері.
Існує просто величезна кількість прикладів, коли дана програма була використана в досить примітивних, на сьогоднішній час, механізмах.
Розглянемо один з ключових прикладів, який наочно покаже всю важливість IPC навіть в дуже простих і ранніх системах, що вже говорити про його потреби на сьогоднішній день.
Більш старі версії сучасного IPC були присутні ще в MS-DOS.
В процесі розвитку технологій, коли мережеві технології і системи тільки починали свій довгий шлях розвитку, стала з'являтися потреба в механізмах створюють взаємозв'язок процесорів, які реалізується, що складаються в одній мережі.
У той час вирішення даного питання було дуже проблематичним.
Справа в тому, що такий зв'язок могла проводити обмін даними, якщо тільки їх платформи або операційні системи ставилися до однакових моделей.
У сучасній мережі дані проблеми вже давно нікого не турбують. Ось вам короткий наочний приклад роботи в таких мережах.
Дані процеси виконуються на двох різних комп'ютерах, в двох різних місцях:
- браузер у вас в системі;
- сервер - в будь-який інший системі або абсолютно в будь-якому місці.
І ви абсолютно не задається питанням, яка у серверів операційна система.
Торкаючись загальний принцип роботи таких форм як IPC, і не тільки таких, як вона, використовується в основному концепція «клієнт-сервер».
Зрозуміло, що «клієнт» - це програма, яка запитує інформацію, а запит інформації йде вже до «серверу» - з додатком яке надає потрібну інформацію.
загальний стан речей
Розглянувши всі можливості і приклади використання межпроцессорного взаємодії, ви самі можете переконатися в тому, що дане забезпечення просто необхідно для роботи операційної системи, до якої ми так звикли.
Нижче будуть перераховані області взаємодії IPC, як в одній системі, так і в багатокористувацької мережі.
На сьогоднішній день вимоги до операційних систем збільшується пропорційно з ростом рівня технологій.
Даний ріст викликаний тим, що кожен день на наші операційні системи виходить все більше і більше якихось доповнень які в свою чергу покращують характеристики нашого комп'ютера.
Але мало хто знає, що сучасні операційні системи, які підтримують, повинні мати в собі такі програми або механізми, які забезпечують синхронізацію процесорів без взаємовиключення і з мінімальними затримками.
Дані критерії мають дуже високу важливість в роботі нашого комп'ютера.
Якщо говорити про ідеальну багатозадачній системі, то всі процеси, що виконується в ній, повинні бути незалежні один від одного, тобто бути асинхронними.
У реальності така «ідеальна» система неможлива, так як рано чи пізно виникають ситуації, коли процесам необхідний доступ до деяких загальних ресурсів.
Для отримання даної можливості, на рівні операційної системи водяться спеціальні ресурси, які надають їм таку можливість.
Але тут, звичайно ж, не без винятків. При виконанні паралельних процесів можуть виникати проблеми.
наприклад: при спільній роботі, Кожен процес, який звертається до даних, що розділяються, унеможливлює для всіх інших процесів одночасне звернення до цих даних - даний феномен називається взаємовиключення.
Три основних види IPC
- локальний
Цей вид IPC повністю прив'язаний до свого комп'ютера, робота здійснюється тільки в межах однієї системи (комп'ютера).
Він є основним і обов'язковим для роботи процесів забезпечують передачу даних по системі, а саме для каналів, черг повідомлень і розділяється пам'яті.
Через свою обмеженість, в плані комунікаційного простору, дані IPC, можуть працювати лише в межах своєї.
Але завдяки такому обмеженню для них можуть використовуватися більш швидкі і прості інтерфейси.
- віддалений
Щоб забезпечити взаємодію в межах системи з одним процесором або між програмами на різних процесорах, з'єднаних через одну мережу, використовуються спеціальні механізми, які надають віддалене IPC.
- високорівнева
Останній і, мабуть, один з найважчих у використанні вид IPC - високорівнева.
Даний вид є пакет програмного забезпечення.
Цей пакет даних створює так званий «проміжний шар», який надає можливість спілкування між системної платформою і додатком.
Забезпечення коректної роботи обміну даних
Разом зі своєю основною функцією, забезпечення взаємодій процесорів, кошти ICP підключені до вирішення проблем, що виникають при організації паралельних обчислень.
Ось приклади їх області діяльності:
1 Доонкурентние ситуації між процесами.Можемо уявити собі ідеальну систему, в якій проходить лише одна дія, це зчитування даних з одного файлу. Дана система перебувати в повному спокої до тих пір, поки одного з процесів не знадобитися змінити даний файл. У такому випадку між процесами виникає «конкурентна ситуація». Це можна порівняти з камінчиком в якомусь механізмі.
2 Черга послідовного запису інформації. Для того щоб надати користувачам можливість швидкого і надійного запису даних, створюються спеціальні черги. Я думаю вам відомо, що таке чергу. Але насправді створюється не одна, а дві черги. Відрізняються дані черзі від справжніх тільки тим, що одна з них використовується тільки для читання, а інша вже дозволяє нам записувати потрібну інформацію. Дана чергу створюється з метою запобігання тупиків, які ми обговоримо трохи нижче.
А як щодо тих процесів, які вимагають невід'ємною швидкості свого рішення?
Раніше, коли створювали згадані вище черзі, виникла проблема, при якій деякі процеси могли довго чекати своєї черги, в той час, коли цей процес був неотлагаемим.
Через деякий час була придумана ідея створення черг, які здійснювали такий розпорядок процесів, які не заважали основним або більш важливим процесам.
Також, існує термін, який і в теорії, і на практиці обгрунтований своєю назвою - це глухий кут.
Його особливість в тому, що хоч процеси вже звільнилися, вони не можуть переходити на наступний щабель для завершення процесу.
Якщо простіше пояснити, то на практиці виходить наступне: у нас є процес X, коли він отримує доступ до файлу X, він починає чекати, коли звільнитися файл Y, для завершення своєї роботи. Але разом з ними процес Y, отримавши доступ до файлу Y, чекає, поки звільниться файл X.
Дані процеси замикаються між собою в даний момент і чекають взаємного звільнення файлу, при цьому, не звільняючи свій файл.
Такого «замикання» можна уникнути, якщо користувач подбати про те, щоб ресурси були пронумеровані.
Також вони повинні бути побудовані строго в висхідному порядку номерів.
Сучасні приклади роботи ICP
Щоб наочно зобразити взаємодію програм на одному комп'ютері, існує знайомий нам ресурс - буфер обміну.
Не дивуйтеся, наш старий добрий буфер обміну також є однією з механізмів IPC.
А принцип його роботи полягає у наступному: виділений вами текст з текстового редактора після виділення поміщається в або в ту ж програму для верстки.
Ви самі можете переконатися, що сліди механізмів межпроцессорного взаємодії можна виявити навіть в дрібних деталях.
Було безліч спроб створення програм або механізмів, які забезпечили б швидку і ефективну передачу інформації між процесорами.
Хоч було створено досить багато подібних засобів, безліч з них до цих пір збереглися або послужили в якості основи для майбутніх моделей.
Варто зауважити, що багато з них були реалізовані в Windows 9x, а ще більшу кількість в Windows NT / 2000.
Хотілося б звернути вашу увагу на той факт, що існування універсального способу обміну даними, який був би корисний у всіх ситуаціях, просто неможливо.
В яку б середу не потрапив користувач - все рівно якийсь із способів буде краще, хоч великої різниці в нормальних умовах, між ними і немає.
Але можемо вас запевнити в тому, що після цієї статті вас більше не утруднить орієнтування в ресурсах, пов'язаних з IPC або вибір того чи іншого методу роботи, зважуючи всі плюси і мінуси.
Для тих людей, які думають, що розвитку в даній технології не провіщає, є один факт, який змінить вашу думку.
Програми та механізми, які пов'язані з IPC, безпосередньо пов'язані з операційною системою. Тобто, ефективність і надійність даних ресурсів буде зростати в міру поліпшення роботи.
Багато користувачів локальних мереж часто не підозрюють що їх диски є мережевими ресурсами до яких можна підключиться, згадуються як приховані адміністративні та загальні ресурси C $, ADMIN $, FAX $, IPC $, PRINT $. Їх потрібно відключити якщо вони вам не потрібні!
Види загальних мережевих ресурсів в Windows XP / 200
За замовчуванням в Windows XP / 2000 можуть бути створені такі приховані адміністративні загальні ресурси:
- кореневі розділи або томи C $ ( D $, E $, F $ і т.д.);
- кореневої каталог операційної системи ADMIN $;
- загальний ресурс FAX $;
- загальний ресурс IPC $;
- загальний ресурс PRINT $.
Для кореневих розділів і томів в якості імені загального ресурсу використовується ім'я диска, до якого додається символ « $ ». Наприклад, для доступу до дисків C і D будуть створені спільні ресурси C $ і D $.
Кореневої каталог операційної системи ( % SYSTEMROOT%) - це каталог, в котом встановлена \u200b\u200bопераційна система Windows. Загальний ресурс ADMIN $ надає адміністраторам доступ до цієї папки по мережі.
Загальний ресурс FAX $ використовується користувачами для відправки факсів. У цій папці кешуються файли і титульні сторінки, що знаходяться на файловому сервері.
Загальний ресурс IPC $ використовується при організації тимчасових підключень, що створюються додатками для обміну даними за допомогою іменованих каналів. Як правило, він застосовується для віддаленого адміністрування серверів в мережі.
Загальний ресурс PRINT $ використовується для віддаленого адміністрування принтерів.
Якщо видалити приховані адміністративні ресурси, створені операційною системою ( наприклад, ADMIN $ або C $), То після перезавантаження комп'ютера або перезапуску служби «Сервер» вони будуть створені повторно. Якщо видалити приховані адміністративні ресурси, створені користувачами, то після перезавантаження комп'ютера вони повторно створені не будуть. Microsoft Windows XP Home Edition не створює приховані адміністративні загальні ресурси.
Підключення до загальних мережних ресурсів в Windows XP / 2000
Для підключення до прихованих адміністративним і загальних мережних ресурсів можна використовувати стандартну команду Windows XP / 2000 net use:
Команда net use використовується для підключення і відключення від мережевих ресурсів і для виведення відомостей про поточні підключених до таких ресурсів. Якщо мережевий ресурс є поточним диском або його використовує будь-яку працює додаток, відключитися від такого ресурсу неможливо.
Нижче наводиться приклад використання команди net use для підключення до стандартного загального ресурсу C $, Комп'ютера під управлінням Windows 2000, с повним ім'ям Pro2000, розташованого в локальної мережі:
Команда net use виконана успішно під ім'ям користувача Адміністратор і порожнім паролем! У більшості випадків після установки Windows, Пароль на обліковий запис з ім'ям Адміністратор, створювану за замовчуванням, забувають або просто не хочуть ставити, а буває так, що під час установки створювалася інша адміністративна обліковий запис, а обліковий запис з ім'ям Адміністратор, створена за замовчуванням, залишилася без уваги!
C: \\\u003e cd / d q: Q: \\\u003e dir Том в пристрої Q не має мітки. Серійний номер тому: 407D-A72A Вміст папки Q: \\ 13.03.2012 8:46 0 AUTOEXEC.BAK 13.03.2012 8:57 Documents and Settings 17.06.2012 8:34 Intel 01.04.2012 4:02 MySoft 17.06.2012 11: 35 NC 18.06.2012 10:10 OpenSSL-Win32 18.06.2012 10:08 Program Files 25.06.2012 15:48 PUBLIC 18.05.2012 10:53 rms 29.04.2012 10:48 Temp 11.06.2012 22:28 WINDOWS 1 файлів 0 байт 10 папок 1 919 221 760 байт вільно Q: \\\u003e
Після підключення ресурсу C $ і його асоціації з буквою диска, ресурс C $ буде доступний у вашому провіднику і з ним можна буде працювати так, як зі звичайним локальним диском, ну, а далі все буде залежати від ваших здібностей і фантазії ...
УВАГА!!! Загальні ресурси будуть доступні тільки в тому випадку коли включена / запущена служба "Сервер", а якщо ви не збираєтеся расшарівать свої ресурси, то краще її не просто зупинити, а відключити зовсім. Служба "Сервер" - Забезпечує підтримку загальний доступ до файлів, принтерів і іменованих каналах для даного комп'ютера через мережеве підключення. Якщо служба зупинена, такі функції не вдасться виконати. Якщо дана служба недозволена, не вдасться запустити будь-які явно залежні служби.
Наведений вище приклад наочно демонструє вразливість неприкритих мережевих ресурсів і облікового запису Адміністратор, створену за замовчуванням з порожнім паролем! Щоб уникнути утворення подібних щілин і як результат регулярної перевстановлення Windows з подальшим переданням анафемі Білла Гейтса потрібно просто спочатку прикривати, так би мовити, всі щілини і діри !!!
Відключення / видалення загальних мережевих ресурсів
Найпростіший спосіб це відключити службу "Сервер", але, деякі служби та програми потребують її підтримки, в такому випадку відключення служби "Сервер" нам не підходить.
Для відключення адміністративних і загальних мережевих ресурсів ( C $, ADMIN $, FAX $, IPC $, PRINT $) В Windows XP / 2000 потрібно:
ПРИМІТКА! У Windows 2000 параметр AutoShareWks додавати не потрібно.
Після перезавантаження ПК будуть видалені всі загальні мережеві ресурси, за винятком одного IPC $, його не можна видалити:
Особливий загальний ресурс IPC $
Являє собою ресурс спільного доступу до іменованих каналів, які забезпечують зв'язок між програмами. Використовується для віддаленого адміністрування комп'ютера і для перегляду загальних ресурсів комп'ютера. Цей ресурс не можна видалити.
Особливий загальний ресурс IPC $ обов'язковий для роботи служби серверів і не може бути видалений. Переглянути список поточних загальних мережевих ресурсів можна командою net share
Повторимося, що воізбежаніе утворення щілин в загальних мережевих ресурсах і як результат регулярної перевстановлення Windows з подальшим переданням анафемі Білла Гейтса потрібно просто спочатку прикривати, так би мовити, всі щілини і діри !!!
Що таке IPC $? Я чув, що через нього можливий віддалений злом? Чи потрібно відключати цей ресурс, якщо так, то як це зробити?
IPC $, або Inter-Process Communication, являє собою спеціальний адміністративний ресурс, призначений для створення іменованих каналів. За допомогою останніх комп'ютери обмінюються в Мережі різної службовою інформацією. IPC $ також служить для дистанційного керування сервером (рис. 10.1).
Мал. 10.1.Включення мережевої служби обміну інформацією IPC $
Щоб вирішити, відключати даний ресурс чи ні, необхідно врахувати наступне:
| Якщо це робоча станція, якій потрібно управляти віддалено, краще не відключати;
| Якщо робоча станція не вимагає віддаленого адміністрування, можна і відключити;
| Якщо це сервер, то відключати і зовсім не варто, так як до нього буде неможливо достукатися по мережі.
Відключається IPC $ через CMD командою net share ipc $ / delete (після перезавантаження даний ресурс все одно сам включається, тому можна написати відповідний BAT-файл і помістити його в автозавантаження).
Мій комп'ютер знаходиться в локальній мережі. Необхідно зробити так, щоб машина надавала відкриті для загального доступу ресурси, і разом з тим так, щоб приховані загальні ресурси C $, D $ і ін. Були недоступні. Як це зробити?
Все, що вам необхідно зробити, - це створити параметр AutoshareWks типу DWORD c нульовим значенням в наступному розділі:.
Що таке спуффінг і як від нього захиститися?
Фактично, спуффінг - це підміна. В даному випадку мається на увазі IP-спуф-фінг, тобто підміна IP. Підміна, при якій зловмисний користувач, скориставшись чужим IP-адресою, що знаходиться в межах довіреної зони IP-адрес, або вповноваженим зовнішнім адресою, видає себе за об'єкт, якому можна довіряти. Найчастіше для захисту від IP-спуффінга застосовують метод прив'язки IP-адреси до адреси мережевої карти (MAC-адресу), але і цей спосіб недосконалий: в даний час відомі утиліти, які підміняють поточний MAC.
Що таке сніффінг і чи існують від нього конкретних заходів захисту?
У найпростішому випадку під сніффінгом мається на увазі перехоплення пакетів по Мережі. Більш конкретно: сниффер переводить мережеву карту (Там, де він встановлений) в так званий "нерозбірливий режим", завдяки якому машина зловмисника захоплює всі мережеві пакети, навіть ті, які їй не призначені. Приклад сніффер - Cain & Abel. В якості захисту при побудові локальної мережі можна порекомендувати використання світчей (комутатор), а не хабів (концентратор), а також використання протоколів, які не передають дані у відкритому вигляді (SSH, SSL, Kerberos). Але і в цьому випадку може бути перехоплення пакетів з допомогою просунутих технік (наприклад, ARP Poizoning).
Що таке фішинг і чи можна від нього захиститися?
Фішинг являє собою техніку обману відвідувачів сайту. Суть: відвідувач заходить на сайт, дуже схожий на оригінал, заповнює графи, що вимагають введення конфіденційної інформації (Номер кредитної картки, пароль і т. Д.). Далі вся ця інформація відправляється зловмисникові, який створив цей лже-сайт. Інструменти захисту від фішингу можна знайти в новітніх версіях інтернет-оглядачів, а також в антивірусних пакетах і міжмережевих екранах. Однак ж слід визнати, що і до цього дня ефективного способу захисту від фішингу не існує. Головний інструмент захисту в даному випадку - це пильність користувача.
Відомо, що багато вірусів підміняють системні файли своїми. Як визначити цю підміну?
Щоб завжди бути в курсі подібних "витівок", необхідно включити функцію повідомлення про захист файлів. Робиться це шляхом внесення в реєстр за адресою HKEY_ LOCAL_MACHINE \\ Software \\ Microsoft \\ Windows \\ CurrentVersion \\ Sys-temFileProtection параметра типу DWORD ShowPopups рівного 1.
Як в IE очистити після успішної реєстрації паролі?
В Internet Explorer інтегрована досить зручна річ - автозаповнення і запам'ятовування пароля. Щоб стерти після успішної реєстрації паролі, досить зробити наступне: в IE зайти в Сервіс\u003e Властивості оглядача\u003e Зміст\u003e Особисті дані\u003e Заповнити форму,потім натиснути кнопку Очистити паролі.
Яким чином я можу приховати адреси відвіданих сайтів, які автоматично висвічуються в адресному рядку, коли я вводжу новий адресу?
Подібні сліди можна ліквідувати, видаливши відповідні записи реєстру за адресою. Примітка: тут же зберігаються і інші сліди, такі як історія доступу до віддалених носіїв C $, D $ для LAN, історія того, що ви набирали в пошукових формах, і т.д.
Після перевірки «Касперського» з'ясувалося, що в системі змінена головна запис. Що це може бути і як відновити первісний стан завантажувального запису (рис. 10.2)?
Мал. 10.2.Перевірити завантажувальні записи?
Швидше за все, змінений завантажувач - наслідки boot-вірусу, хоча не виключено, що завантажувач змінився і не через вірусної інфекції. Відновити завантажувач можна з консолі відновлення: для цього необхідно завантажитися в Recovery Console і прописати команди fix mbr і fix boot. Завантажитися в Recovery Console можна через завантажувальний ХР-диск, вибравши Repair Windows XP instaLLation ®і Recovery ConsoLe ©.Однак відновлення таким чином - не найкращий спосіб. У більшості випадків завантажувач все ж не відновлюється. Рішення подібних проблем під силу лише спеціалізованим ПО, як яскравий приклад якого можна привести ADINF32.
Підкажіть, де в «Антивірус Касперського 7.0» прописуються поновлення. А то при перевстановлення системи доведеться завантажувати всі оновлення знову.
Оновлення - папка з базами розташовується за адресою and Set-tings \\ All Users \\ Application Data \\ Kaspersky Lab \\ AVP7 \\ Bases.
З огляду на результати численних тестів, можна сказати, що жоден з нині існуючих браузерів не є безпечним на 100%. Тим часом деякі з продуктів все ж можна вважати досить безпечними. Одним з таких продуктів є Opera.
Ситуація така: мій комп'ютер в локальній мережі і вихід в Інтернет у мене через картку. Ліміт старої картки вичерпаний, але ввести нові логін і пароль можливості немає, так як при спробі входу на будь-якої веб-сайт не з'являється вікно аутентифікації з сервером (всі настройки проксі-сервера правильні). Як повернути вікно введення логіна і пароля?
Щоб знову з'явилося вікно аутентифікації, необхідно видалити старий логін і пароль через оснащення Облікові записи користувачів(Рис. 10.3) - для цього треба зайти в меню Пуск? виконати,введіть команду control userpasswords2, у вікні натисніть Додатково? Управління паролями? Вилучити.
При завантаженні системи «Антивірус Касперського», який раніше працював без збоїв, чомусь перестав запускатися; при спробі примусового запуску він теж сам відключається. Що це може бути і як з цим боротися?
Швидше за все, ваша система інфікована вірусом, який відключає "Антивірус Касперського". Подібна "зараза", швидше за все, налаштована на відключення та інших популярних антивірусних продуктів. Вихід - завантажитися з чистого середовища, наприклад з завантажувального диска (Windows LiveCD). Далі, як варіант, під цим середовищем перевірити систему антивірусом, що не вимагає установки (такий антивірус може бути запущений з флешки, як приклад - популярний продукт Dr.Web CureIt Сканер (рис. 10.4), який можна завантажити з офіційного сайту Dr.Web) .
Мал. 10.3.управління паролями
Мал. 10.4.Сканер CureIt в дії
перевірив свій жорсткий диск «Касперський» і в дистрибутивах Panda Titanium виявив справжнісінький вірус! Як бути?
Швидше за все, файл нічим не інфікований, і піднімати тривогу не варто. більшість антивірусних програм час від часу спрацьовують при перевірці файлів інших антивірусів.
Я початківець системний адміністратор і хотів би дізнатися вашу думку про те, яку з серверних операційних систем можна вважати найбільш надійною і продуктивної?
Мій міжмережевий екран постійно повідомляє про тих, хто прийшов звідкись пакетах з прапором «syn». Що це означає?
Швидше за все, вашу машину хтось або щось (мережевий черв'як, наприклад) сканує. Сканування, як правило, є підготовкою до атаки. Тому вам є над чим замислитися.
