Сокет

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

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

Інтерфейс сокетів вперше з'явився в BSD Unix. Програмний інтерфейс сокетів описаний в стандарті POSIX.1 І в тій чи іншій мірі підтримується усіма сучасними операційними системами.

Принципи сокетів

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

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

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

Unix domain socket

Unix domain socket (Доменний сокет Unix) та IPC-сокет (сокет між процесами взаємодії) - кінцева точка обміну даними, схожа з Інтернет-сокетом, але не використовує мережевий протокол для взаємодії (обміну даними). Він використовується в операційних системах, що підтримують стандарт POSIX, для взаємодії між процесами. Коректним терміном стандарту POSIX є POSIX Local IPC Sockets.

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

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

Mmap - POSIX-сумісний системний виклик Unix, що дозволяє виконати відображення файлу або влаштування на пам'ять. Є методом введення / виводу через відображення файлу на пам'ять і природним чином реалізує виділення сторінок за запитом, оскільки спочатку вміст файлу не читається з диска і не використовує фізичну пам'ять взагалі. Реальне зчитування з диска проводиться в «лінивому» режимі, тобто при здійсненні доступу до певного місця.

У Linux, Mac OS X і BSD mmap може створювати кілька типів відображень.

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

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

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

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

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

mmap можна використовувати для реалізації між процесами взаємодії (IPC). У сучасних операційних системах mmap зазвичай краще взаємодії через розподілену пам'ять в System V.

Основна відмінність між розподіленою пам'яттю System V (shmem) і введенням-виведенням з розподілом пам'яті (mmap) полягає в тому, що розподілена пам'ять System V постійна: не будучи явно видалені, дані будуть зберігатися в пам'яті і залишатися доступними до тих пір, поки система не буде відключена. Пам'ять mmap не є постійною між запусками програми (тільки якщо відображення не зарезервовано у файлі).

D-Bus

D-Bus - система міжпроцесної взаємодії, яка дозволяє додаткам в операційній системі спілкуватися один з одним.

D-Bus є частиною проекту freedesktop.org. Вона володіє високою швидкістю роботи, не залежить від робочого середовища, працює на POSIX-сумісних операційних системах, також існує версія для Windows (поки що на стадії розробки). Складається з двох частин: демона і низкоуровнего API. У графічному середовищі KDE для цього не так давно використовувався DCOP, але інші настільні середовища (наприклад, GNOME) не мали аналогічних систем.

Існувала можливість комунікації у вигляді CORBA, SOAP або XML-RPC, але CORBA використовує велику кількість ресурсів (KDE і GNOME пройшли етап його використання за час свого існування), а SOAP і XML-RPC призначені для веб-сервісів.

Раніше GNOME використовував Bonobo, заснований на CORBA, але через залежність від GObject, Bonobo не використовувався в інших робочих середовищах, а низька швидкодія CORBA позначалося на швидкості всього середовища.

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

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

Кожен об'єкт може підтримувати один або більше інтерфейсів, які представлені тут у вигляді іменованих груп методів і сигналів - аналогічно інтерфейсам Glib, Qt або Java.

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

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

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

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

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

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

Тому в D-Bus у кожного об'єкта своє, унікальне ім'я, яке виглядає як шлях у файловій системі. Наприклад, об'єкт може бути іменований як/ org/kde/kspread/sheets/3/cells/4/5. Кращі імена, які несуть якусь смислове навантаження, тим не менш, розробники можуть вибрати і ім'я/ com/mycompany/c5yo817y0c1y1c5b, якщо це має сенс для їх застосування.

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

Див. також

• Інтерфейс транспортного рівня