При обычной IPC системные вызовы исполняются локально. Данные, предоставленные процессом как параметры системного вызова, копируются в ядро и удерживаются там. Каждый вызов IPC должен возвратить некий результат в адресное пространство вызывающего процесса. Вызывающий процесс не сможет продолжиться до тех пор, пока к нему не вернутся результаты. В течение этого времени он находится в ядре в состоянии ожидания. Период времени между генерацией вызова и получением ответа может сильно варьироваться для различных системных вызовов и зависеть от состояния структуры IPC.
Некоторые
вызовы (например, xxxctl() вследствие команды
IPC_STAT)
отрабатывают быстро, другие (например, вызов semop()) - могут
отнимать очень длительное, если не бесконечное время:
Сначала параметры копируются в ядро (1), а затем возвращаются результаты (2).
Таким образом, системный вызов IPC требует осуществления двух операций копирования между адресными пространствами пользователя и ядра. Обратите внимание на то, что порция копируемых данных (параметры или результаты) может быть очень маленькой (одно целое число, совпадающее с кодом ошибки) или весьма большой (содержимое сообщения IPC).
В дальнейшем помните, что программа dipcd выполняется в пользовательском адресном пространстве и применяет обычные средства взаимодействия с ядром. Не подразумевается также, что пользовательский процесс обязательно выполняется на машине владельца. Под ``данными'' понимаются либо входные параметры, либо результаты.
Удаленный вызов процедур (Remote Procedure Call - RPC) применяется для исполнения системного вызова на удаленном компьютере. Для обеспечения ``прозрачности'' ни один из процессов, использующих DIPC, не должен ``видеть'' какие-либо изменения в сравнении с нормальной (локальной) активностью IPC. К тому же, данные процесса копируются в память ядра. Затем dipcd переносит эти данные в свое адресное пространство и передает их по сети компьютеру, ответственному за обработку запроса. Это должен быть компьютер, на котором структура IPC создана в первую очередь, - в этом случае он называется владельцем данной структуры (см. раздел о владельцах для получения более подробной информации). Удаленный dipcd будет копировать вновь прибывшие данные в пространство ядра машины-владельца. В результате, при такой симуляции системного вызова на целевом компьютере получается три копирования и одно ``задействование'' в сети - для процесса.
После этого системный вызов может исполняться dipcd на удаленном ядре, а результаты будут отсылаться назад тем же самым способом, который описан выше: удаленное ядро будет копировать данные в пользовательское пространство, после чего dipcd сможет передать их по сети; dipcd на стороне оригинального процесса принимает эти данные и передает их своему локальному ядру. Наконец, данные копируются в адресное пространство оригинального процесса:
{Генерация вызова через сеть:
(Запрашивающий компьютер) | (Запрашиваемый компьютер)
процесс-1-> локальное ядро |
| |
+-2-> локальный dipcd --|-3->dipcd владельца-4->удаленное
| ядро
|
Получение результатов: |
локальный~dipcd~<--|-6-dipcd владельца<-5-удаленное
| | ядро
процесс <-8-локальное ядро<-7-+|
Процесс приостанавливается до тех пор, пока результаты не возвратятся.
Как видно, пользовательский процесс взаимодействует лишь с локальным ядром и не отмечает изменений при вызовах подпрограмм IPC System V.
Помните, что передача данных по сети требует дополнительного копирования в ядро и из него. Это происходит вследствие ``дизайна'' сетевой поддержки внутри ядра и поэтому неизбежно.
Следующий алгоритм отображает, как производится решение проблемы удаленного исполнения операций.
ЕСЛИ присутствует dipcd и вызывающий процесс - не dipcd ТО
ЕСЛИ операция поддерживается DIPC ТО
ЕСЛИ операция - в достоверной распределенной структуре и
это - не компьютер владельца ТО исполнить вызов удаленно
КОНЕЦ