Межпроцессное взаимодействие в Linux

1.

Межпроцессное взаимодействие в Linux

2.

Межпроцессное взаимодействие в Linux
1.
Что такое IPC?
2.
Зачем нам нужен IPC?
3.
Различные способы реализации IPC в Linux
Сокеты Unix
Очереди сообщений
Общая память
Пайпы
Сигналы
4.
Демонстрация и разбор кода
5.
Обсуждение дизайна IPC
6.
Проект по IPC
0
1
0
1
0
1
0
1
0
1
Межпроцессное взаимодействие
в Linux (IPC)
Процесс A
Процесс B

3.

Что такое IPC и зачем он нам нужен?
IPC – это механизм, позволяющий двум или более процессам, выполняющимся на одной машине,
обмениваться данными
Обмен данными между процессами, выполняющимися на разных машинах, не называется IPC
Процессы, работающие на одной машине, часто должны обмениваться данными друг с другом, чтобы
реализовать
некоторая функциональность
ОС Linux предоставляет несколько механизмов, с помощью которых процессы пользовательского
пространства могут осуществлять связь друг с другом, каждый механизм имеет свои плюсы и минусы
В этом курсе мы рассмотрим различные способы выполнения IPC в Linux OS.
Методы IPC хорошо подходят для других платформ, таких как windows/MAC OS и т.д., концептуально они
одинаковы.

4.

Что такое IPC и зачем он нам нужен?
IPC
App1
App2
...
AppN
Прикладной
уровень
Пользовательск
ое пространство
Netlink Skts
IOCTLS
Device files
System Calls
OS
Пространство
ядра
Ядро
Драйверы
устройств
CPU
Память
...
Устройст
ва
Архитектура компьютера
Аппаратный
уровень

5.

Методы IPC
Существует несколько способов проведения IPC
Мы рассмотрим каждый из них и постараемся проанализировать плюсы и минусы каждого
Ожидайте несколько вопросов по IPC на технических собеседованиях
Методы IPC :
1. Использование сокетов Unix Domain
2. Использование сетевых сокетов (не рассматривается в этом курсе)
3. Очереди сообщений
4. Общая память
5. Пайпы
6. Сигналы

6.

Что такое процесс?
Когда вы пишете приложение и выполняете его на машине, оно запускается как процесс.
Даже ваша программа "Hello-World" выполняется как процесс
На машине одновременно выполняется несколько процессов - пользовательский процесс или системный процесс
Эг:
Пользовательский процесс
• Браузеры, MS office, IMs, игры, инструменты для редактирования видео и т.д., или любое программное
обеспечение, которое вы запускаете на своей ОС.
Системные процессы
• Менеджер памяти, менеджер дисков, службы ОС, планировщики и т.д.

7.

Терминология
Коммуникационные процессы можно разделить на две категории:
• Серверный процесс
• Клиентский процесс
Сервер - это любой процесс, который получает запрос на связь, обрабатывает его и возвращает результат.
Клиент - это любой процесс, который инициирует запрос на передачу данных.
Сервер никогда не инициирует связь
запрос
Техническ
ий запрос
Процесс
A
Процесс
B
ответ
Клиент
Сервер

8.

Виды связи
Коммуникация между двумя процессами может быть в целом
классифицирована как
Коммуникация на основе STREAM
Общение на основе DATAGRAM
Коммуникация на основе STREAM
Ориентирован на соединение: Выделенное соединение между A и B
2.
Сначала должно быть установлено выделенное соединение, прежде чем
любой фактический обмен данными
3.
Дуплексная связь и надежность
4.
B может отправлять непрерывный поток байтов данных в A, аналогично
поток воды через трубу
5.
Данные поступают в той же последовательности
6.
Следует использовать в тех случаях, когда приемник может переносить LAG, но не
потеря пакетов
7.
Например: Загрузка аудио- или кинофильма или программного обеспечения, хранящегося на диске.
на сервере, электронная почта, сообщения в чате и т.д.
8.
Известный стандартный сетевой протокол, который обеспечивает потоковое
Сервер
коммуникация осуществляется по протоколу TCP
0
1
0
1
0
1
0
1
0
1
1.
Процесс A
труба
Процесс B
Клиент

9.

Виды связи
Коммуникация между двумя процессами может быть в целом
классифицирована как
Коммуникация на основе STREAM
Общение на основе DATAGRAM
Общение на основе DATAGRAM
1.
Нет выделенного соединения между A и B
2.
Данные передаются небольшими фрагментами или единицами, без непрерывности
Поток байтов
3.
Дуплексная связь и ненадежность
4.
Данные могут поступать не по порядку
5.
Следует использовать в тех случаях, когда получатель может выдержать потерю пакетов, но
не журнал
Процесс A
6.
Видео/аудиоконференции в прямом эфире
7.
Известный стандартный протокол на основе сетевых дейтаграмм - UDP
Процесс B
Посмотрите раздел "Ресурсы", где можно найти хорошие обсуждения stack overflow!
Сервер
Клиент

10.

Методы IPC - Сокеты
ОС типа Unix/Linux предоставляют интерфейс Socket для осуществления связи между различными типами объектов.
Интерфейс сокетов - это набор API, связанных с программированием сокетов.
Мы будем использовать эти API для реализации сокетов различных типов
В этом курсе мы узнаем, как реализовать два типа :
Доменные сокеты Unix
• IPC между процессами, выполняющимися в одной системе
Сетевые сокеты
• Связь между процессами, выполняющимися на разных физических машинах, по сети
Сначала мы рассмотрим, как работают сокеты в целом, а затем увидим, как API сокетов можно использовать для
реализации конкретного типа коммуникаций. Для начала давайте создадим некоторую предысторию...

11.

Методы IPC - Сокеты
Шаги программирования сокетов и
связанные с ними API
Шаги
1.
Удалите сокет, если он уже существует
2.
Создайте сокет Unix с помощью функции socket()
3.
Укажите имя сокета
4.
Привяжите сокет с помощью функции bind()
5.
listen()
6.
принять()
7.
Прочитайте данные, полученные от сокета, с
помощью функции recvfrom().
8.
Отправьте результат обратно с помощью функции
sendto()
9.
закрыть сокет данных
10. закрыть сокет соединения
11. Извлеките сокет
12. выход
Прежде чем приступить к выполнению этих шагов, д
Работает машина состояний связи на основе соке
и
различные API сокетов, предоставляемые ОС Linux

12.

Интерфейс системных вызовов Linux
Лекция VDO 1
Модель OSI
Приложения
Интерфейс системных вызовов
socket() accept() connect() sendto() recvfrom() close() select() и т.д.
Я хочу, чтобы служба
ОС/ядро
Аппаратный уровень
Архитектура компьютерных слоев
Хорошо, сэр, вот
Ваши услуги
• Linux предоставляет набор API, называемых
системными вызовами, которые приложение может
вызывать для взаимодействия с базовой ОС.
• Сокетные API - это интерфейс между приложением и
ОС.
• Используя эти API, приложение дает указание ОС
предоставлять свои услуги
• Знакомый пример:
• malloc(), free()

13.

Типы сообщений сокетов
Типы сообщений сокетов
Сообщения (или запросы), которыми обмениваются процессы клиента и сервера, могут быть
подразделяются на два типа:
Сообщения запроса на инициирование соединения
Этот msg используется клиентским процессом для запроса серверного процесса на установление выделенного соединения.
Только после того, как соединение установлено, клиент может отправлять серверу сообщения с запросами на обслуживание.
И
Сообщения о запросах на обслуживание
Клиент может отправить эти сообщения серверу, как только соединение будет полностью установлено.
С помощью этих сообщений клиент запрашивает сервер о предоставлении услуги
• Серверы идентифицируют и обрабатывают оба типа сообщений совершенно по-разному
Клиент
ский
процес
с
1. CIR
2. Установленное соединение
3. SRM
4. Ответ
Сервер
ный
процес
с

14.

Машина состояний взаимодействия клиент-сервер
Машина состояний при обмене данными между
клиентом и сервером на основе сокетов
1.
C1
Когда сервер загружается, он создает сокет для подключения
(также называется "дескриптор файла главного сокета" при использовании функции socket())
M
= socket()
M
2. M - мать всех клиентских дескрипторов. M рождает все клиентские дескрипторы.
Клиентские ручки также называются "data_sockets".
3. После создания клиентских дескрипторов для каждого клиента, сервер выполняет
Общение (фактический обмен данными) с клиентом с помощью
Ручка клиента (а не M).
C1
C2
ручка
4. сервер должен поддерживать базу данных подключенных клиентских ручек или сокетов данных
ручка
Сервер
5. M используется только для создания новых клиентских ручек. M не используется для обмена данными
с уже подключенными клиентами.
6. accept() - это системный вызов, используемый на стороне сервера для создания клиентских дескрипторов.
7. В терминологии Linux дескрипторы называются "файловыми дескрипторами", которые представляют собой целые положительные числа.
Клиентские дескрипторы называются "дескрипторами коммуникационных файлов" или "сокетами данных".
а M называется "дескриптор файла главного сокета" или "сокет подключения".
C2

15.

Системный вызов Linux accept()
принять
()
• Когда сервер получает от нового клиента сообщение с запросом на установление нового соединения,
этот запрос поступает на Master socket, поддерживаемый сервером. Мастер-сокет
активируется.
Когда сервер получает запрос на установление соединения от клиента, он вызывает функцию accept() для установления двунаправленно
Возвращаемым значением системного вызова accept является хэндл клиента или дескриптор файла связи
accept() используется только для связи, ориентированной на соединение, но не для связи без соединения
M
принять()
C1
вызванный
C1
ручка
C2
ручка
Сервер
C2

16.

Виды связи
Коммуникация между двумя процессами может быть в целом
классифицирована как
Коммуникация на основе STREAM
Коммуникация на основе DATAGRAM
Как передаются данные
Связь между двумя процессами можно также классифицировать
следующим образом
Коммуникация, ориентированная на соединение
Связь без подключения
Характер соединения

17.

Типы коммуникации : Ориентированные на соединение и не ориентированные на соединение
Коммуникация,
ориентированная на
соединение
Требование
предварительного
подключения
Без подключения
Общение
Требуется
Не требуется
Надежность
Обеспечивает надежную передачу данных.
Не гарантируется. Если данные будут потеряны в
пути, они будут потеряны навсегда
Перегруженность
Может контролировать перегруженность
Невозможно контролировать перегрузку
Повторная передача
потерянных данных
Осуществимо, например, связь по TCP
Невозможно
Пригодность
Подходит для длительной и устойчивой связи.
Например: аудио- и видеозвонки, прямые
трансляции, загрузка файлов и т.д.
Подходит для бурной передачи.
Например: отправка сообщений чата, электронной
почты и т. д.
Пересылка данных
Байты принимаются в той же последовательности, по тому
же маршруту
Байты поступают в случайной последовательности, по разным
маршрутам
Коммуникация на основе STREAM
Коммуникация на основе дейтаграмм
Тип связи
Клиент
ский
процес
с
Сервер
ный
процес
с

18.

Доменные сокеты Unix
ДОМЕННЫЕ СОКЕТЫ UNIX
Доменные сокеты Unix используются для выполнения IPC между двумя процессами, работающими на
одной машине.
Мы обсудим реализацию Unix Domain Sockets относительно процессов сервера и клиента.
Используя сокеты UNIX Domain, мы можем настроить взаимодействие на основе STREAM или DATAGRAM.
STREAM - Когда необходимо переместить или скопировать большие файлы из одного места в другое, например:
копирование фильма.
ex : непрерывный поток байтов, как поток воды
DATAGRAM - когда небольшие единицы данных необходимо перемещать от одного процесса к другому в системе.

19.

Доменные сокеты Unix -> код Walk
Разбор кода для процесса A (сервер)
Шаги
1.
Удалите сокет, если он уже существует
2.
Создайте сокет Unix с помощью функции socket()
3.
Укажите имя сокета
4.
Привяжите сокет с помощью функции bind()
5.
listen()
6.
принять()
7.
Прочитайте данные, полученные через сокет, с
помощью read().
8.
Отправьте результат с помощью функции write().
9.
закрыть сокет данных
10. закрыть сокет соединения
11. Извлеките сокет
12. выход
Общие шаги для программирования сокетов

20.

Доменные сокеты Unix -> код Walk
Разбор кода для процесса B (клиент)
Шаги
1.
...

21.

Доменные сокеты Unix -> Демонстрация
Демонстрация...

22.

API-интерфейсы сокетной связи
Проектирование высокоуровневых сокетов
Тип сообщения
API на стороне
клиента
API на стороне
сервера
Сообщения о запросе на
инициирование соединения
connect()
принять()
(блокировка)
Сообщения о запросах на
обслуживание
sendmsg(),
sendto(),
write()
recvmsg(),
recvfrom()
read()
(блокировка)

23.

Доменные сокеты Unix -> Наблюдение
Пока сервер обслуживает текущего клиента, он не может принимать новых клиентов
Это недостаток данной конструкции сервера, и нам необходимо устранить это ограничение
Сервер может быть перепроектирован для одновременного обслуживания нескольких клиентов с помощью
концепции мультиплексирования

24.

Мультиплексирование
Мультипле
• Мультиплексирование - это механизм, сксирование
помощью которого процесс сервера может контролировать несколько
клиентов одновременно.
Без мультиплексирования серверный процесс может одновременно обслуживать только одного клиента и не
может обслуживать запросы других клиентов, пока не закончит работу с текущим клиентом.
Благодаря мультиплексированию сервер может одновременно обслуживать несколько подключенных клиентов
Нет мультиплексирования
Как только текущий клиент будет обслужен сервером,
Клиент должен встать в очередь, начиная с последнего
(должен отправить новый запрос на подключение) к
получить другую услугу от сервера
Мультиплексирование
Сервер может обслуживать несколько клиентов одновременно

25.

Мультиплексирование -> выбрать
select()
Одновременный мониторинг активности всех клиентов

26.

Мультиплексирование -> выбрать
Сервер-процесс должен поддерживать клиентские дескрипторы (коммуникационные FD) для выполнения
связь (обмен данными) с подключенными клиентами
Кроме того, серверный процесс должен поддерживать сокет соединения или Master
Сокет FD также (M) для обработки новых запросов на подключение от новых клиентов
Linux предоставляет встроенную структуру данных для хранения набора сокетов в файле
дескрипторы
C1
fd_set
M
Системный вызов select() отслеживает все FD сокета, присутствующие в fd_set
ручка
C2
ручка
Сервер
M, C1,C2
select()
fd_set
Давайте подробно рассмотрим системный вызов select()

27.

Выбрать и принять вместе в действии
Серверный
процесс
Выбор (fd_set)
4 accept()
2 accept()
C1
C2
Comm_fd_2
Comm_fd_1
Мастер ФД
fd_set
Comm_fd_1
Comm_fd_2

28.

Диаграмма машины состояния процесса мультиплексированного сервера

29.

Сокет домена Unix Проект -> Синхронизация данных
Создадим процесс диспетчера таблиц маршрутизации (RTM).
• RTM отвечает за таблицу маршрутизации уровня 3.
• В его обязанности входит поддержание таблицы маршрутизации L3 и отправка уведомлений о любых изме
в содержимом таблицы маршрутизации для подключенных клиентов
• Состояние таблицы маршрутизации должно быть синхронизировано между всеми клиентами в любой мом

30.

Сокет домена Unix Проект -> Синхронизация данных
Общая картина
Клиент
ский
процес
с
Процесс сервера диспетчера маршрутов отправляет CUD
(Создание, обновление и удаление) уведомление всем п
Клиентский процесс)
Давайте обсудим проект шаг за шагом
Процесс
управле
ния
маршрут
ом
CUD
Клиент
ский
процес
с
Клиент
ский
процес
с

31.

Сокет домена Unix Проект -> Синхронизация данных
Процесс Route Manager поддерживает таблицу маршрутизации
Эта таблица управляется администратором
Образец таблицы приведен ниже.
Вы можете самостоятельно выбрать структуру данных для представления и управления этой таблицей
Примечание
Маска - [0,32]
Подсеть назначения
(ключ)
IP-адрес шлюза
OIF
122.1.1.1/32
10.1.1.1
Ethernet1
130.1.1.0/24
10.1.1.1
Ethernet1
126.30.34.0/24
20.1.1.1
Ethernet2
220.1.0.0/16
30.1.2.3
Ethernet3
Операции, выполняемые на столе :
• Вставка - <Направление/маска> <Шлюз IP> <OIF>
• Обновление - <Направление/маска> <новый IP-адрес шлюза> <новый OIF>.
• Удалить - <Направление/маска

32.

Сокет домена Unix Проект -> Синхронизация данных
Каждый раз, когда пользователь выполняет любую операцию CUD над таблицей маршрутизации, процесс сервера Route Manager синхрониз
конкретная операция для всех подключенных клиентов
Когда новый клиент подключается к серверу, сервер отправляет все состояние таблицы этому вновь подключившемуся клиенту
В любой момент времени таблица маршрутизации ДОЛЖНА быть идентичной у менеджера маршрутов и всех подключенных клиентов
Клиент
ский
процес
с
C, <DATA>
Сервер
ный
процес
с
Подсеть
назначения (ключ)
IP-адрес шлюза
OIF
122.1.1.1/32
10.1.1.1
Ethernet1
130.1.1.0/24
10.1.1.1
Ethernet1
126.30.34.0/24
20.1.1.1
Ethernet2
220.1.0.0/16
30.1.2.3
Ethernet3
100.100.100.0/24
50.1.1.1
Ethernet4
Клиент
ский
процес
с
Клиент
ский
процес
с
Подсеть
назначения (ключ)
IP-адрес шлюза
OIF
122.1.1.1/32
10.1.1.1
Ethernet1
130.1.1.0/24
10.1.1.1
Ethernet1
126.30.34.0/24
20.1.1.1
Ethernet2
220.1.0.0/16
30.1.2.3
Ethernet3
100.100.100.0/24
50.1.1.1
Ethernet4
C, <DATA>
C - CREATE (код операции)
DATA - <Dest/mask> <Gw IP> <OIF>
Предоставьте меню для отображения таблицы маршрутизации
Содержание процессов сервера и клиента

33.

Сокет домена Unix Проект -> Синхронизация данных
Код операции может быть Enums :
Предложения по структурам данных :
typedef enum{
СОЗДАТЬ,
UPDATE,
УДАЛИТЬ
} OPCPDE;
Структура, содержащая данные для синхронизации, может быть :
typedef struct _msg_body {
char destination[16];
маска;
char gateway_ip[16];
char oif[32];
} msg_body_t;
Последнее сообщение, которое должно быть синхронизировано с процессом менеджера таблиц м
Должен иметь код операции и тело
typedef struct _sync_msg {
OPCODE op_code;
msg_body_t msg_body;
} sync_msg_t;

34.

Сокетные API
API для программирования сокетов
1.
socket() - Используется для создания соединения/мастер-сокета на стороне сервера. Используется для создания
сокета данных на стороне клиента
2.
select() - Используется для мониторинга нескольких дескрипторов файлов. Может использоваться как на стороне
клиента, так и на стороне сервера. Блокирующий системный вызов. Блокируется до тех пор, пока не поступит
новый запрос на соединение или данные на FD, присутствующие в fd_set.
3.
accept() - Используется на стороне сервера. Используется для принятия запроса на новое соединение от клиента
и установления соединения с ним
4.
bind() - Используется на стороне сервера. Используется процессом серверного приложения для информирования
операционной системы о критериях интересующих пакетов
5.
listen() - Используется на стороне сервера. Используется серверным прикладным процессом для
информирования операционной системы о длине очереди входящих запросов на соединение/запросов данных
от клиентов
6.
read() - Используется на стороне сервера и клиента. Используется процессом сервера/клиента для чтения
данных, поступивших в дескрипторы коммуникационных файлов. По умолчанию этот вызов является
блокирующим. Процесс блокируется, если данные еще не поступили.
7.
write() - Используется для отправки данных на клиент/сервер. Используется на стороне сервера и клиента.
8. close() - Используется для закрытия соединения. Используется как клиентами, так и сервером

35.

IPC - техника
Очереди сообщений
1. IPC с использованием очередей сообщений
Процесс
A
(Отправ
итель)
2. Концепции Msgq
Процесс
B
(Приемни
к)
3. API-интерфейсы управления MsgQ
4. Использование MsgQ
DeQueue
Enqueue
5. Разбор кода - шаг за шагом
Msg1
Msg2
Msg3
MsgQ
Msg4

36.

IPC - Техника -> Очередь сообщений
• Linux/Unix OS предоставляет другой механизм, называемый очередью сообщений, для выполнения IPC
• Процессы, работающие на одной машине, могут обмениваться любыми данными с помощью очередей соо
• Процесс может создать новую очередь сообщений или использовать существующую очередь msgQ, создан
процесс
• Очередь сообщений однозначно идентифицируется по ID, никакие два msgQ не могут иметь одинаковый ID
• Очередь сообщений находится и управляется ядром/ОС
• Отправляющий процесс A может отправить данные в очередь сообщений, принимающий процесс B считыв
msg Q
• Процесс, который создает msgQ, называется владельцем или создателем msgQ

37.

IPC - Техника -> Очередь сообщений
Процесс
A
(Отправ
итель)
Процесс
B
Пользовательское пространство
(Приемни
к)
DeQueue
Enqueue
Msg1
Msg2
Msg3
Msg4
MsgQ (ID = "XYZ")
Пространство ядра
• В системе может быть несколько очередей сообщений, созданных несколькими процессами.
• Каждая очередь сообщений идентифицируется уникальным именем, называемым msgQ ID, которое пр

38.

IPC - Техники -> Очередь сообщений -> Создание
1. Создание очереди
сообщений
Процесс может создать новый msgQ или использовать существующий msgQ, используя нижеприведенный A
mqd_t
mq_open (const char *name,
int oflag);
mqd_t
mq_open (const char *name,
int oflag, mode_t mode,
struct mq_attr *attr);
Два варианта API
name - Имя msg Q , например "/server-msg-q".
oflag - Операционные флаги
O_RDONLY : процесс может только читать сообщения из msgQ, но не может записывать в него
O_WRONLY : процесс может только записывать сообщения в msgQ, но не может читать из него
O_RDWR : процесс может записывать и читать сообщения в и из msgQ
O_CREAT : Очередь создается, если она еще не существует
O_EXCL : mq_open() терпит неудачу, если процесс пытается открыть существующую очередь. Это
при самостоятельном использовании. Всегда используется через ИЛИ с флагом O_CREAT
• mode - Разрешения, установленные процессом-владельцем очереди, обычно 0660
• attr - указать различные атрибуты создаваемого msgQ
struct mq_attr {
• Как и максимальный размер, который может увеличить msgQ, должен быть меньше или раве
long mq_flags; /* Флаги: 0 */
/proc/sys/fs/mqueue/msg_max
long mq_maxmsg; /* Макс. # Количество сообщений в очереди
*/
• Максимальный размер msg, который может вместить msgQ, должен быть меньше или равен
long mq_msgsize; /* Максимальный размер сообщения (байт) */
/proc/sys/fs/mqueue/msgsize_max
long mq_curmsgs; /* Количество сообщений, находящихся в очереди */
};
Если mq_open() работает успешно, она возвращает дескриптор файла (хэндл) к msgQ. Используя этот хэндл, мы выполняем все операции над msgQ в течение
всей программы

39.

IPC - Техники -> Очередь сообщений -> Создание
1. Создание очереди
сообщений
Процесс может создать новый msgQ или использовать существующий msgQ, используя нижеприведенный A
Пример 1: Без атрибутов
mqd_t msgq;
if ((msgq = mq_open ("/server-msg-q", O_RDONLY | O_CREAT | O_EXCL, 0660, 0)) == -1) {
perror ("Сервер: mq_open (server)");
выход (1);
}
Пример 2: С атрибутами
mqd_t msgq;
struct mq_attr attr;
attr.mq_flags = 0;
attr.mq_maxmsg = 10;
attr.mq_msgsize = 4096;
attr.mq_curmsgs = 0;
if ((msgq = mq_open ("/server-msg-q", O_RDONLY | O_CREAT | O_EXCL, 0660, &attr)) == -1) {
perror ("Сервер: mq_open (server)");
выход (1);
}

40.

IPC - Техники -> Очередь сообщений -> Закрытие
2. Закрытие очереди
сообщений
Процесс может закрыть msgQ с помощью следующего API:
int
mq_close (mqd_t msgQ);
Возвращаемое значение :
0 - успех
-1 - неудача
После закрытия msgQ процесс не сможет использовать msgQ, пока не откроет его снова с помощью mq_open().
Операционная система удаляет и уничтожает msgQ, если все процессы, использующие msgQ, закрыли его
ОС хранит информацию о том, сколько процессов используют один и тот же msgQ (вызванный mq_open()). Эта конц
называется подсчетом ссылок
msgQ - это ресурс ядра, который используется процессом приложения. Для ресурсов ядра ядро отслеживает
сколько процессов пользовательского пространства используют данный ресурс
Когда ресурс ядра (msgQ в нашем примере) создается процессом appln в первый раз, reference_count = 1
Если другой процесс также вызовет open() на существующем ресурсе ядра (в нашем случае mq_open()) ,
Ядро увеличивает счетчик ссылок на 1
Когда процесс вызывает функцию close() в существующем ресурсе ядра (в нашем случае mq_close()), ядро уменьша
счетчик ссылок на 1
Когда счетчик_ссылок = 0, ядро очищает/разрушает этот ресурс ядра.
Помните, что ресурс ядра может быть чем угодно, это может быть FD сокета, FD msgQ и т.д.

41.

IPC - Techniques -> Message Queue -> Enqueue
3. Записать сообщение
Процесс отправки может поместить сообщение в очередь сообщений, используя нижеприведенный API:
mq_send предназначен для отправки сообщения в очередь, на которую ссылается дескриптор msgQ.
int
mq_send (mqd_t msgQ,
char *msg_ptr,• msg_ptr указывает на буфер сообщения. msg_len - размер сообщения, который должен быть меньше или равен
размер сообщения для очереди.
size_t msg_len,
unsigned int msg_prio);
Возвращаемое значение :
0 - успех
-1 - неудача
msg_prio - приоритет сообщения, представляющий собой неотрицательное число, определяющее приоритет сообщ
Сообщения помещаются в очередь в порядке убывания приоритета сообщений, при этом более старые сообщ
приоритет перед новыми сообщениями.
Если очередь переполнена, mq_send блокирует ее, пока не освободится место в очереди, если только не установлен
для очереди сообщений, в этом случае mq_send немедленно возвращается с errno, установленным в EAGA

42.

IPC - Техники -> Очередь сообщений -> Разрядка
4. Чтение сообщения
Получающий процесс может удалить сообщение из очереди сообщений с помощью следующего API:
mq_receive предназначен для получения сообщения из очереди, на которую ссылается дескриптор msgQ.
int
mq_receive (mqd_t msgQ,
char *msg_ptr,• msg_ptr указывает на пустой буфер сообщения. msg_len - размер буфера в байтах.
size_t msg_len,
Самый старый msg с наивысшим приоритетом удаляется из очереди и передается процессу в буфере, на который ук
unsigned int *msg_prio); msg_ptr.
Возвращаемое значение
n_bytes of recvd msg - успех
-1 - неудача
Если указатель msg_prio не является нулевым, приоритет полученного сообщения сохраняется в целочисленном зн
Поведение mq_receive по умолчанию заключается в блокировке, если в очереди нет сообщений. Однако, если флаг
включена для очереди, и очередь пуста, mq_receive возвращается немедленно с errno, установленным в E
В случае успеха mq_receive возвращает количество байт, полученных в буфере, на который указывает msg_ptr.

43.

IPC - Техники -> Очередь сообщений -> Уничтожение
5. Уничтожение очереди
сообщений
Создающий процесс может уничтожить очередь сообщений, используя нижеприведенный API:
int
mq_unlink (const char *msgQ_name);
mq_unlink уничтожает msgQ (освобождает ресурс ядра).
Должен вызываться, когда процесс вызвал mq_close() для msgQ
возвращает -1 при неудаче, 0 при успехе
Отложите, если другие процессы используют msgQ

44.

IPC - Техники -> Очередь сообщений -> Использование msgQ
6. Использование очереди
сообщений
• IPC-механизм Message Queue обычно поддерживает парадигму N:1, то есть на одну
очередь сообщений может приходиться N отправителей и 1 получатель.
• Несколько отправителей могут открыть один и тот же msgQ, используя имя msgQ, и
записать свои сообщения в одну очередь.
• Процесс-получатель может декеировать сообщения из очереди сообщений, размещенных
различными процессами-отправителями
• Однако процесс получения может одновременно удалять сообщения из разных очередей
сообщений (мультиплексирование с помощью select()).
Очередь сообщений может поддерживать только один клиентский процесс
Клиент может декеировать сообщения из более чем одной очереди сообщений.
Нет ограничений на процессы сервера

45.

IPC - Техники -> Очередь сообщений -> Использование msgQ
6. Использование очереди
сообщений
Процесс
A1
(Отправ
итель)
Enqueue
Процесс
A2
(Отправ
итель)
Msg1
Msg2
Msg3
Msg4
DeQueue
(Приемни
к)
MsgQ
Процесс
A3
(Отправ
итель)
Процесс
B
Процесс
C
(Приемни
к)

46.

IPC - Техника -> Очередь сообщений -> Иллюстрация
Код загрузки :
git clone https://github.com/sachinites/IPC
Dir : IPC/IPC/msgQ
Файлы : sender.c
recvr.c

47.

IPC - техника
Общая память
1. IPC с использованием общей памяти
2. Концепции общей памяти
Процесс
A
(Отправ
итель)
читать
написать
3. API управления общей памятью
4. Использование общей памяти в качестве IPC
5. Проект
ДАТА
Общая память
Процесс
B
(Приемни
к)

48.

IPC - техника -> общая память
Необходимые знания
Чтобы понять концепцию общей памяти, нам сначала нужно разобраться в некоторых основах:
Виртуальное адресное пространство
Виртуальная память
Блок управления программой

49.

Виртуальное адресное пространство и виртуальная память
Что такое виртуальная память и виртуальное адресное пространство?
Виртуальная память - это общий объем памяти, отведенный вашей системой под тот или иной процесс.
Она отличается от физической памяти и зависит от архитектуры компьютера.
Например
Для 32-битной системы общее количество виртуальной памяти составляет 2^32 байта (фиксировано), и эт
Если вы можете расширить физическую память до 4, 8 или 16 Гб (переменная) (верхний предел)
2^32 байта!!! Каждый байт имеет свой адрес. Поэтому в 32-битной системе существует 2^32 виртуальных адреса
Компьютерные программы работают только с виртуальной памятью, то есть ваша программа обращается толь
Ваша программа никогда не знает ничего о физической памяти, все, что она знает, что у нее есть 2 ^ 32 байта ви
для хранения своих данных
Каждому выполняемому процессу выделяется виртуальная память, которая может достигать максимум 2^32 ба
Память, выделенная процессу, называется виртуальным адресным пространством процесса
Каждый процесс, запущенный в 32-битной системе, может использовать максимум 2 ^ 32 байта виртуальной па

50.

Виртуальное адресное пространство и виртуальная память
Блок управления программой
Это диаграммное логическое представление процесса и его расположения в памяти в Linux/Unix OS.
PCB помогает нам понять, как работает виртуальная память процесса во время его выполнения
Давайте посмотрим, как выглядит PCB для процесса linux. ...

51.

Блок управления программой
Стек
Память, выделенная для выполнения процесса. Она не может увеличи
определённый предел
Возможность наращивания штабеля
Блок управления программой
Доступно для роста кучи
& mmap
Куча
данные
Код
Общая доступная память системы. Область кучи расширяется или сжи
Когда процесс malloc Или освобождает память
Динамическая память, выделенная процессу
Память, в которой хранятся глобальные и статические переменные пр
Память, в которой хранится код процесса в текстовом формате, фикси

52.

Блок управления программами
Стек
Возможность наращивания штабеля
Блок управления программой
Доступно для роста кучи
& mmap
int global_var = 10;
int
main(int argc, char **argv){
int i = 0;
char *my_name = "Abhishek";
статический int j = 5;
int *k;
k = malloc(100);
foo(j);
вернуть 0;
}
Куча
данные
Код
VAS = данные + куча + стек

53.

IPC - Техника -> Общая память -> Основы
• Общая память - это часть памяти ядра. Ни один процесс не является владельцем этой памяти.
• В linux при выполнении процесса ему выделяется участок виртуальной памяти системы. Этот кусок
Память называется виртуальным адресным пространством процесса
• Процесс может получить доступ только к тем адресам памяти, которые находятся в его виртуальном адресн
• Если процесс пытается получить доступ к адресу, который находится за пределами его виртуального адресн
(Ошибка сегментации)
• Итак, примите это за правило - процессу не разрешается читать/писать в любую память, которая находится з
область виртуальной памяти
• Виртуальная область памяти процесса увеличивается и уменьшается по мере того, как процесс запрашивает
память
• Заданный адрес, находящийся в области виртуальной памяти процесса P1, не имеет значения для любого др
система
• Давайте изобразим все вышеперечисленные моменты.

54.

Память ядра
• Ядро имеет свою собственную память, называемую памятью ядра. Ядро использует собственную память для с
Таймеры, управление памятью пользовательского процесса, прерывания и многое другое!
• Ни один процесс пользовательского пространства не является владельцем этой памяти ядра
• Пользовательский процесс может запросить у ядра создание области памяти ядра
• Эта область памяти ядра находится вне виртуального адресного пространства любого процесса, поэтому ни од
может обращаться к этой памяти напрямую
• Благодаря подходу с использованием общей памяти приложение(я) может получить доступ к памяти ядра
Пользовательский процесс запущенApp1
на
система
Базовая ОС
App2
App3
Пользовательское пространство
Память ядра
Кернелспаке

55.

Доступ процесса пользовательского пространства к памяти ядра
Стек
Начальный адрес памяти ядра : k, конечный адрес k'
Размер памяти ядра для доступа: k' - k байт
Процесс запрашивает у ОС расширение своего
виртуального адресного пространства на k' -k байт, то есть в
VAS процесса добавляется k' -k новых адресов из
глобальной VAS
Для этого используется системный вызов mmap()
Теперь адреса в этой вновь созданной области
отображаются ОС (подкачка) на соответствующие адреса
памяти ядра
Фактические данные/контент продолжают находиться в
памяти ядра, а не в новой области mmap
Возможность наращивания штабеля
Блок управления программой
A'
mmap
A
Доступно для роста кучи
& mmap
Куча
данные
Код
Память ядра
K
Кернелспаке
K'

56.

Доступ процесса пользовательского пространства к памяти ядра
Стек
A' - A = K' - K
Данные в памяти ядра не перемещаются, манипулируется
только сопоставление адресов
A и A' - адреса адресного пространства виртуальной памяти
процесса
A отображается на K, A' отображается на K'
Когда процесс обращается к адресу B, где A <= B < A', то
механизм подкачки Linux переводит B в B', где K <= B' < K'
Для каждого адреса между [A,A'], существует
соответствующий адрес в [K,K']. Это называется
отображением адресов
Возможность наращивания штабеля
Блок управления программой
A'
mmap
A
Доступно для роста кучи
& mmap
Куча
данные
Память ядра
K
Кернелспаке
K'
Код
Когда отображение выполнено, процесс может читать/писать

57.

Доступ процесса пользовательского пространства к памяти ядра
Стек
Возможность наращивания штабеля
VAS = Data + Heap + Stack + mmap
Блок управления программой
A'
mmap
A
Доступно для роста кучи
& mmap
Куча
данные
Код
Память ядра
K
Кернелспаке
K'

58.

Доступ процесса пользовательского пространства к памяти ядра
Стек
Возможность наращивания штабеля
Два или более процессов могут одновременно выполнять
это отображение с одним и тем же сегментом памяти ядра.
Таким образом, память ядра разделяется между
несколькими процессами пользовательского пространства,
поэтому она называется общей памятью.
Если один процесс изменяет/обновляет содержимое общей
области памяти, изменения видны другим процессам,
которые отобразили ту же область памяти
Таким образом, фактическая передача данных между
процессами отсутствует, следовательно, этот подход лучше
всего подходит для обмена большими файлами между
процессами
Процессы должны размонтировать область памяти, как
только они завершат использование общей области памяти
Блок управления программой
A'
mmap
A
Доступно для роста кучи
& mmap
Куча
данные
Код
Память ядра
K
Кернелспаке
K'

59.

Доступ процесса пользовательского пространства к памяти ядра
Стек
Несколько процессов пользовательского пространства, отображаемых на
Один и тот же общий сегмент памяти ядра
Возможность наращивания штабеля
Стек
Возможность наращивания штабеля
Блок управления програм
Блок управления программой
B
A'
mmap
mmap
B'
A
Доступно для роста кучи
& mmap
Доступно для роста кучи
& mmap
Куча
Куча
Память ядра
данные
Код
K
Кернелспаке
K'
данные
Код

60.

Ограничения при использовании общей памяти в качестве IPC
• Рекомендации по использованию IPC с общей памятью :
• Подход IPC с общей памятью используется в сценарии, где :
• За обновление общей памяти отвечает только один процесс (процесс-издатель).
• Остальные процессы читают только общую память (процессы подписчиков).
• Частота обновления общей памяти процессом-издателем не должна быть очень высокой
• Например, процесс издателя обновляет общую память, когда пользователь настраивает что-то
программное обеспечение
• Если несколько процессов пытаются обновить общую память одновременно, это приводит к тому, что
к конфликту "запись - запись":
Нам нужно справиться с этой ситуацией с помощью синхронизации на основе взаимного исключения
Синхронизация достигается за счет снижения производительности
Поскольку мы переводим потоки в спящий режим (в дополнение к их естественному преимущественному использов
предотвращение одновременного доступа к критической секции

61.

Ограничения при использовании общей памяти в качестве IPC
• Когда процесс издателя обновляет общую память:
Подписчики не будут знать об этом обновлении
Поэтому после обновления общей памяти издателю необходимо отправить уведомление всем подписчикам
в котором говорится, что "общая память была обновлена".
После получения этого уведомления подписчики могут читать обновленную общую память и обновлять свои внутренние
структуры данных, если таковые имеются
Уведомление представляет собой небольшое сообщение и может быть отправлено с помощью других механизмов IPC, таких как
Доменные сокеты Unix или очереди сообщений
Таким образом, IPC, использующие общую память, должны быть подкреплены/поддержаны другими типами IPC
Уведомление об обновлении
Процесс
B1
(Подписчик
)
2
Уведомление об обновлении
Процесс A
(Издатель)
1
Процесс
B2
(Подписчик
)
написать
читать
читать
3
2
ДАТА
Общая память
3

62.

API-интерфейсы общей памяти

63.

API-интерфейсы общей памяти
1. Создание или открытие области общей
памяти
int
shm_open (const char *name, int oflag, mode_t mode);
Создание нового объекта общей памяти внутри ядра
возвращает целое число, представляющее дескриптор файла для данного объекта обще
возвращает -1, если вызов не удался
oflag - Следуя флагам, поддерживается ИЛИ-перестановка одного или нескольких флаго
O_CREAT -- создание общей памяти, если она еще не существует
O_RDONLY - открыть объект общей памяти в режиме только для чтения
O_WRONLY - открыть объект общей памяти в режиме "только запись".
O_RDWR - открыть объект общей памяти в режиме чтения-записи
O_APPEND - Новые данные должны быть добавлены к существующему содержим
O_TRUNC - Если указано, усекает объект общей памяти, если он уже существует,
снова обнулить байт
• Если флаг O_EXCL используется вместе с флагом O_CREAT, то shm_open терпит не
объект общей памяти уже существует с таким же именем
mode - если разделяемая память создается процессом заново, то mode - это
права доступа к файлам, применяемые к этому объекту памяти
Имя общей памяти
Eg "/Data_segment"
Eg :
int shmfd =
shm_open("/datasegment", O_CREAT | O_RDWR | O_TRUNC,
• Вновь созданный объект общей памяти имеет размер ноль байт
0660);
• Его можно сделать нужного размера с помощью системного вызова ftruncate

64.

API-интерфейсы общей памяти
2. Установка размера объекта общей памяти
int
ftruncate (int shm_fd, size_t new_size);
Изменение размера объекта общей памяти на новый размер
Возвращает -1 при неудаче
Должен вызываться после shm_open, если это необходимо.

65.

API-интерфейсы общей памяти
3. Отображение общей памяти в виртуальное
адресное пространство процесса
#include <sys/mman.h
void *
mmap (void *addr, size_t length, int prot, int flags, int fd, off_t offset);
Смещение - это место в общей памяти
объект, с которого начинается отображение; мы будем использовать
значение ноль для смещения и отобразить общую память
объект, начинающийся с самого начала
fd - это, конечно же, дескриптор файла для
общей памяти, полученной от
ранний вызов shm_open
MAP_SHARED.
что означает, что обновления отображаемых
общей памяти видны всем остальным процессам немедленно
PROT_READ | PROT_WRITE
длина объекта общей памяти
которые должны быть нанесены на карту
Начальный адрес VAS процесса, где
Объект общей памяти должен начать отображение
Рекомендуется передавать как NULL. Пусть ОС сама решает.
В случае успеха mmap возвращает указатель на местополо
Его виртуальное адресное пространство, в котором находи
была нанесена на карту.
В случае ошибки, MAP_FAILED, что равно (void *) -1,
возвращается, а в errno устанавливается причина ошибки.

66.

API-интерфейсы общей памяти
4. Развертка общей памяти
int
munmap (void *addr, size_t length);
addr - Адрес в виртуальном адресном пространстве процесса, куда была отображена общая память (начальный конец отображения)
(Возвращаемое значение mmap())
длина - длина отображения, которое мы хотим удалить
Разблокирует объект общей памяти в месте, на которое указывает addr и которое имеет размер, длину
Возвращает -1 при неудаче, 0 при успехе
Он не уничтожает общую память, а только уничтожает отображение между общей памятью
в пространстве ядра и виртуальной памяти процесса

67.

API-интерфейсы общей памяти
5. shm_unlink
int
shm_unlink (const char *name);
Деассоциируйте общую память с ее именем
Это эквивалентно тому, что общей памяти с таким же именем не существует.
больше. Имя должно быть доступно для связывания с новым экземпляром общей памяти
возвращает -1 при ошибке, 0 при успехе
6. закрытие дескриптора файла общей памяти
int
close (int shm_fd)
уменьшить количество ссылок на объект общей памяти, хранящийся в пространстве ядра
Если количество ссылок уменьшается до нуля, общая память и ее содержимое уничтожаются (в некоторых системах продолжа
пока система не будет перезагружена)
возвращает -1 при ошибке, 0 при успехе

68.

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

69.

Демонстрация IPC с общей памятью
Исходный код: git clone http://github.com/sachinites/IPC
Путь к директории : cd IPC/IPC/SHM/Demo
Файлы : writer.c - создание и добавление содержимого в общую память
reader.c - Чтение содержимого из общей памяти, созданной writer.c
shm_demo.c - состоит из функций и подпрограмм для работы с общей памятью
Код Walk ...

70.

Проект по IPC с общей памятью
• Мы расширим проект, который вы сделали по доменным сокетам Unix.
• В проекте Unix domain socket серверный процесс менеджера таблиц маршрутизации синхронизирует таблицу
подключенных клиентов с помощью IPC сокетов Unix Domain.
• В этом проекте серверный процесс менеджера таблиц маршрутизации также поддерживает другую таблицу, н
синхронизирует его со всеми подписавшимися клиентами, используя Shared Memory IPC
• Давайте обсудим проект шаг за шагом. Функциональность проекта Previous останется прежней, без изменени

71.

Проект по IPC с общей памятью
Клиент
ский
процес
с
A
Память
процесса
Процес
с
сервер
а RTM
C, <MAC>
IPC : сокет домена Unix
Клиент
ский
процес
с
B
Общая память
Мак (ключ)
(Память процесса)
IP
(Общая память)
01:00:5e:01:01:01
225.1.1.1
01:00:5f:02:01:01
232.1.2.3
01:00:6e:04:02:01
100.1.2.4
01:03:5e:03:01:01
190.132.22.123
01:13:3f:03:02:01
Память
процесса
Мак (ключ)
(Память процесса)
01:00:5e:01:01:01
01:00:5e:01:01:01
01:00:5f:02:01:01
01:00:5f:02:01:01
01:00:6e:04:02:01
01:00:6e:04:02:01
01:03:5e:03:01:01
01:03:5e:03:01:01
01:13:3f:03:02:01
Клиент
ский
процес
с
C
122.1.2.3
<Код операции>, <ДАННЫЕ>
C - CREATE
D - УДАЛИТЬ
DATA - <Мак-адрес>
Обеспечьте возможность отображения таблицы Mac
Содержание процессов сервера и клиента

72.

Проект по IPC с общей памятью
Все процессы - сервер и клиенты - хранили в своей внутренней структуре данных только ключ общей памяти (Mac-адрес).
Процесс сервера добавляет Данные - ip-адрес в общей памяти, соответствующий mac-адресу (ключу)
Затем серверный процесс синхронизирует только mac-адрес (ключ shm) с остальными подключенными клиентами, используя сокеты домена Unix.
Клиент, получив новый ключ (mac-адрес), сохраняет mac-адрес в своем приватном списке. Используя этот mac-адрес в качестве ключа
Они также могут получить доступ к соответствующему ip-адресу, который был добавлен процессом Server в общую память
Когда новые клиенты подключаются к серверу, помимо таблицы маршрутизации, сервер также синхронизирует весь список локальных mac-адресов с новым клиент
Синхронизация с помощью доменных сокетов Unix
Mac1
Mac2
Mac3
mac4
Серверн
ый
процесс
менедж
ера
маршру
тизации
Mac1
Mac2
Mac3
mac4
Клиентс
кий
процесс
Добавить IP-адрес
IP1
IP2
IP3
IP4
Общая память
Считывание shm с помощью Mac-адреса
как ключи общей памяти

73.

IPC - техника
Сигналы
1. Что такое сигналы?
2. Типы сигналов
3. Захват сигналов
4. Использование сигналов в качестве IPC

74.

IPC - Техника -> Сигналы
Определение
Системное сообщение, передаваемое от одного процесса к другому, обычно не используемое для переда
но вместо этого используется для удаленного управления партнерским процессом.
Eg :
Судья в крикете сигнализирует, что бэтсмен выбыл из игры. Это пример сигнала, а не передачи данных
Сигналы обычно представляют собой небольшие сообщения (1 или 2 байта). Получателю необходимо инте
App1
App2
Пользовательское пространство
OS
Сигналы работает от :
ОС -> Приложение
Между приложениями
От приложения к ОС - нет

75.

IPC - Техники -> Сигналы -> Ловля сигналов и рутина обработчика сигналов
Когда процесс получает сигнал, может произойти одно из трех событий:
1
Выполнить стандартное действие сигнала
Например : Когда процесс получает сигнал
SIGTERM, процесс завершается по
умолчанию
По умолчанию
2
Процесс выполняет свою обработку при
получении сигнала, выполняя процедуру
обработчика сигнала
Например: когда процесс получает сигнал
SIGTERM, он может захотеть напечатать на
экране сообщение о прощании или записать
свою внутреннюю структуру данных в файл
для автономной отладки, прежде чем он
умрет.
3
Процесс игнорирует
сигнал
игнорировать
персонализированный
Несколько моментов о подпрограммах обработчика сигналов :
• Подпрограмма обработчика сигналов - это специальная функция, которая вызывается, когда процесс получает сигнал.
• Нам нужно зарегистрировать рутину в зависимости от типа сигнала (то есть процесс должен вызывать функцию F при получении сигнала S)
• Процедуры обработчика сигналов выполняются с наивысшим приоритетом, отменяя нормальный ход выполнения процесса

76.

IPC - Техника -> Сигналы
Хорошо известные сигналы в Linux
• SIGINT - прерывание (т.е. Ctrl-C)
• SIGUSR1 и SIGUSR2 - сигналы, определяемые пользователем
• SIGKILL - посылается процессу из ядра при вызове kill -9 на pid.
Этот сигнал не может быть пойман процессом.
• SIGABRT - вызывается функцией abort() самим процессом. Не может быть заблокирован.
Процесс завершается.
• SIGTERM - поднимается при вызове kill. Может быть пойман процессом для выполнения определенного п
• SIGSEGV - ошибка сегментации, выдаваемая ядром процессу при обращении к недопустимой памяти.
• SIGCHILD - каждый раз, когда дочерняя программа завершает работу, родительской программе посылае
Получив этот сигнал, родитель должен выполнить системный вызов wait(), чтобы прочитать статус ребе
Чтобы понять этот сигнал, нужно разобраться с функцией fork().

77.

IPC - Техника -> Отправка сигналов
Три способа генерации сигналов в Linux
1. Передача сигнала от ОС к процессу (ctrl - C и т.д.)
2. Отправка сигнала от процесса A к самому себе (с помощью
raise() )
3. Отправка сигнала от процесса A к процессу B (с помощью
kill() )
Мы рассмотрим примеры каждого...

78.

IPC - Техники -> Программирование сигналов -> Отлов сигналов
1. Процесс может отлавливать сигнал, полученный от ОС, и выполнять определенную пользователем функ
Получено
#include <signal.h>
/* Регистрация определяемой пользователем функции ctrlC_signal_handler
который будет вызван при нажатии ctrl + C*/
сигнал (SIGINT, ctrlC_signal_handler);
статическая пустота
ctrlC_signal_handler(int sig){
printf("Ctrl-C pressed\n");
printf("Bye Bye\n");
exit(0);
}

79.

IPC - Техника -> Программирование сигналов -> raise()
2. Процесс может послать сигнал самому себе с помощью функции raise()
int
raise (int signo);
• Сигнал, обозначенный signo, при поднятии с помощью функции raise() поступает в сам процесс

80.

IPC - Техника -> Программирование сигналов -> kill()
3. Процесс может послать сигнал другому процессу с помощью функции kill()
int
kill (int process_id, int signo);
• Процесс отправки должен знать идентификатор процесса-получателя, чтобы послать сигнал.
Kill_sender.c
Kill_recv.c
• 5939 - pid процесса kill_recv.c
• SIGUSR1, SIGUSR2 зарезервированы для сигналов, определяемых пользователем

81.

Проект по сигналам
Мы будем продолжать расширять наш проект
До сих пор, когда новый клиент подключается к процессу сервера, сервер
синхронизирует всю таблицу маршрутизации и таблицу ARP с этим новым подключенным
клиентом
используя сокеты Unix Domain Sockets и общую память соответственно
Клиент
ский
процес
с
A
• Теперь, когда клиент подключается к серверному процессу, и синхронизация завершается, этот новый
клиент
отправляет свой собственный идентификатор процесса ( getpid() ) серверному процессу
менеджера маршрутизации, используя сокеты домена unix
• Сервер хранит идентификаторы процессов всех клиентов в списке или что-то в этом роде
Процес
с
сервер
• Теперь добавьте выбор в меню на стороне сервера, выбирая, какой сервер промывать
а RTM
вся таблица маршрутизации и ARP-таблица находятся в общей памяти
Клиент
ский
процес
с
B
2112
• После промывки сервер посылает сигнал SIGUSR1 всем подключенным клиентам.
PIDs
используя их пиды с помощью kill(). Получив этот сигнал, клиенты должны
чтобы очистить свои собственные копии таблицы маршрутизации и ARP-таблицы.
2111
2112
2132
• Кроме того, всякий раз, когда клиент разрывает соединение с сервером в unix-домене,
Клиент должен очистить все свои таблицы, которые он обслуживает. Перед закрытием
соединение, клиент должен отправить последнее сообщение серверу, сервер, имеющий
получивший последнее сообщение, должен удалить pid этого клиента из своего списка
Клиент
ский
процес
с
C

82.

IPC - техника
Мультиплексирование
Как один процесс может получать данные от нескольких IPC-механизмов одновременно?
У нас есть процесс, который может получать данные асинхронно из :
Сетевой сокет
Сокет домена Unix
Консоль
Очередь сообщений
Как разработать такой процесс, который будет принимать данные, отправленные любым
обрабатывать его?

83.

IPC - Техника -> Мультиплексирование
Серверный
процесс
Очередь сообщений
Если вы заметили, сетевые сокеты, сокеты Unix
& Очереди сообщений имеют дескрипторы файло
Мы уже изучали мультиплексирование в
контекст сокетов
В этом случае просто добавьте все дескрипторы файлов
fd_set и вызовите select() для этого набора
select() будет разблокирован, если сервер получит данн
на любом FD через любой механизм IPC
Просто!!!
fd_set = сокеты данных сетевых клиентов + Master Network skt
+
сокет данных клиентов домена unix + соедине
+
ФД всех очередей сообщений
+
0 (консоль)