[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Программирование в Linux" / Оглавление документа

Процессы dipcd

Демон dipcd ``раздваивает'' нужные процессы для выполнения своей задачи. Вы можете видеть, что все процессы имеют свои собственные исходные тексты. Ниже приводится список процессов
dipcd (их осложняют перекрестные ссылки, поэтому для понимания написанного может понадобится ``многопроходное'' чтение):

-

back_end (в dipcd/back_end.c):

Здесь находится функция main() программы dipcd. Только один back_end может присутствовать на каждом компьютере в кластере. back_end и front_end (см. ниже) - это единственные процессы dipcd, которые используют fork() для создания других процессов: back_end запускает систему - он регистрирует себя в ядре, как процесс, ответственный за обработку запросов DIPC, - читает конфигурационный файл, инициализирует переменные и раздваивает задачу front_end. Если машина, на которой он запущен, является арбитражной, то он также раздваивает и арбитражный процесс.

После этого back_end зацикливается на сборе запросов из ядра и связанных с ними данных - в те моменты, когда это возможно. Эти запросы (наряду с другими) могут быть предназначены для чтения распределенной разделяемой памяти и записи в нее, а также могут запрашивать сведения о некоторых структурах IPC. При этом, back_end будет раздваивать процесс employer (см. ниже) для обработки каждого из этих запросов.

-

front_end (в dipcd/front_end.c):

Процесс ответственный за обработку входящих запросов и передачу данных для компьютера по сети. На каждой машине в кластере DIPC может быть только один процесс front_end. Его предназначение объясняется тем, что в сетях TCP/IP для подсоединения к компьютеру вам нужно знать не только IP-адрес соответствующей машины, но и номер порта TCP; dipcd при работе создает неизвестное заранее число процессов и многие из них требуют получения информации по сети. Таким образом, для избавления от проблемы, возникающей, когда каждый процесс использует собственный номер порта TCP, было решено обрабатывать все входящие запросы единственной общей задачей. В результате, каждый процесс ``знает'' номер порта TCP, который должен использоваться для подключения к другому компьютеру с поддержкой DIPC.

Каждый процесс для взаимодействия с другими машинами может подключаться прямо к front_end любого компьютера. (Это не приводит к взаимодействию с referee. См. ниже.) Если входящее соединение предназначено для выполнения полезной нагрузки, то front_end раздваивает рабочий процесс для обработки. В противном случае он только переправляет входящие данные процессу, для которого они предназначены и который может быть employer, ожидающим результатов, или менеджером разделяемой памяти (см. shm_man).

-

referee (в dipcd/referee.c):

Играет важную роль в налаживании порядка в системе. Во всем кластере может быть только один referee, следовательно, он может выполняться только на одном из компьютеров. Для того, чтобы DIPC работала, каждый компьютер должен знать адрес машины, на которой выполняется referee. Подобно случаю с front_end, referee имеет свой собственный номер порта TCP, и прочие процессы могут взаимодействовать непосредственно с ним; referee хранит всю информацию о действующих структурах IPC в нескольких связанных списках (в документации DIPC на них ссылаются, как на арбитражные таблицы). Наличие одних списков связано со структурами IPC, которые уже созданы, а других - со структурами, которые удаленный процесс пытается создать. Такой подход приводит к возложению на referee функции сервера имен DIPC.

В этом случае referee предоставляет механизм ``черного хода'' (используемый в доменных сокетах UNIX), посредством которого процессы могут посылать свои команды и принимать определенную информацию ( См. документацию на программу dipcref (в каталоге tools) для получения дополнительной информации. См. также раздел ``Арбитраж'', находящийся ниже).

-

shm_man (в dipcd/shm_man.c):

Создается на машинах, которые владеют сегментами разделяемой памяти (машины, которые сначала создали соответствующие структуры) как менеджер разделяемой памяти. Имеется по одному процессу shm_man для каждой распределенной разделяемой памяти в системе. Он исполняется задачей employer, которая успешно обработала shmget(); shm_man определяет, кто может читать разделяемую память или записывать в нее и имеет соответствующий счетчик. Он также управляет передачей содержимого разделяемой памяти на нуждающиеся в нем компьютеры. shm_man будет присоединять разделяемую память к себе. Это предохраняет разделяемую память от разрушения, если она удаляется (shmctl() вследствие команды IPC_RMID), а все процессы в машине-создателе отсоединяют ее от себя. Это может привести к осложнениям, если иные процессы на других компьютерах продолжают нуждаться в разделяемой памяти.

Нет необходимости в процессах, раздваиваемых для обработки набора семафоров и очередей сообщений на компьютере, который создал их (т. е. нет sem_man и msg_man). Только в случае с разделяемой памятью вводится управляющий процесс. Это происходит по следующим причинам:

1. При наличии разделяемой памяти требуется дополнительная информация (т.е. список компьютеров, имеющих доступ к памяти для чтения или записи), которая используется в течение длительного времени. Сохранить ее при большом числе процессов не просто.
2. Может возникать более одного запроса - на чтение разделяемой памяти или запись в нее - в одно и то же время. Поэтому необходимо централизованное принятие решений.
3. Разделяемая память должна присоединяться к адресному пространству процесса - чтобы система не могла окончательно удалить ее (см. выше).

-

employer (в dipcd/employer.c):

Запускается для обработки при удаленном исполнении системного вызова (такого, как shmctl()) или для обработки других видов запросов (таких, как запросы на чтение/запись разделяемой памяти). Он соединяется с соответствующим компьютером (например, с тем, на котором структура IPC создана первой) и затем перенаправляет необходимые данные ответственному процессу (например, front_end) - с ожиданиями подтверждений. Он использует механизм тайм-аута для обнаружения возможных сетевых или машинных проблем.

-

worker (в dipcd/worker.c):

Запускается процессом front_end для исполнения запрашиваемых действий. Запросы могут приходить от employer, referee или shm_man и включать исполнение удаленного системного вызова или пересылку содержимого разделяемой памяти из компьютера в компьютер. Для успешного завершения работы worker может подключаться к оригинальной запрашивающей машине и предоставлять соответствующие результаты; worker может обратиться к прокси и оставаться на связи с ним после реализации такого соответствия (См. раздел о прокси для получения более подробной информации).

Партнёры:

Хостинг: