Различные части dipcd используют структуру, называемую ``сообщением'' (не путайте с сообщениями IPC) для передачи любой информации между собой. В эти сообщения включаются: IP-адреса отправителя и получателя, локальный pid отправителя, функция для реализации, необходимые аргументы и т.д. В некоторых случаях может потребоваться больше данных, чем вмещает структура message - такая информация может ``сопровождать'' сообщение. Содержимое сообщения IPC или структуры msgid_ds, использующееся в msgctl() вследствие команды IPC_SET, - это два примера данных, которые посылаются после сообщения dipcd.
Каждое сообщение имеет поле запроса, которое определяет процесс ``назначения''.
Оно может принимать значения REQ_DOWORK - для рабочих, REQ_SHMMAN
- для менеджера разделяемой памяти и
REQ_REFEREE - для арбитра.
Ответные сообщения содержат в своих полях запроса REQS_DOWORK,
RES_SHMMAN либо RES_REFEREE - в зависимости от того, какой из процессов
отвечает данным сообщением.
TCP/IP или UDP/IP сокеты являются главным средством передачи информации от машины к машине; dipcd должен быть проинформирован о том, какой из этих протоколов в первую очередь использовать с помощью опций командной строки при запуске.
Доменные сокеты UNIX используются для коммуникаций между задачами dipcd, которые всегда выполняются на одном компьютере. Применение сокетов в каждом из случаев унифицирует процесс обмена данными между этими процессами. Сокеты UNIX создаются в домашнем каталоге dipcd.
Процессы, которые устанавливают сокеты TCP/IP - это referee и front_end. Все внутримашинные коммуникации должны вызывать один из них. Процессы, которые устанавливают доменные сокеты UNIX - это employer (для приема каждого результата от front_end на локальной машине), referee (для реализации механизма ``черного хода''), менеджер разделяемой памяти (для приема запросов, связанных с распределенной разделяемой памятью, которой он управляет, а также для реализации механизма ``черного хода'') и worker, когда он переходит к исполнению системного вызова semop(). В случаях с shm_man и employer все данные от других компьютеров первоначально посылаются в TCP/IP сокет front_end, а он копирует их в доменные сокеты UNIX. Доменный сокет UNIX referee доступен локально с помощью средства dipcref. Процесс worker принимает файловый дескриптор, соответствующий межсетевому сокету, когда раздваивается процессом front_end; таким образом, он может непосредственно взаимодействовать с удаленными процессами. Прокси принимают данные от front_end посредством сокетов UNIX.
Имя доменного сокета UNIX для employer назначается примерно так: сначала следует строка DIPC, затем идет тип структуры IPC (SEM - для семафоров, MSG - для очередей сообщений и SHM - для разделяемой памяти) плюс соответствующий структуре IPC ключ и, наконец, идентификатор процесса employer. Это делает имя сокета уникальным, поэтому результаты могут быть отосланы назад ``правильному'' employer. Например, DIPC_SEM.45.89 - дается employer с идентификатором процесса 89, который обрабатывает запрос семафора. Набор семафоров имеет ключевой номер 45. Имя сокета менеджера разделяемой памяти также назначается аналогичным способом, за исключением того, что оно не включает число, соответствующее его идентификатору процесса, так как некоторые процессы могут потребовать связать их без указания таких номеров. Фактически процессы, запрашивающие доступ к разделяемой памяти, не осведомлены о процессе, который управляет этой памятью (См. в разделе о прокси, как эти процессы устанавливают доменные сокеты UNIX).
Некоторые процессы должны использовать сокеты TCP/IP в большинстве случаев информационного обмена (например, между shm_man и front_end, который выполняется на компьютере-читателе разделяемой памяти или писателе), поскольку они обычно находятся на различных компьютерах. Однако бывает, что оба процесса располагаются на одной машине. Для поддержки общих алгоритмов при этом также применяются сокеты TCP/IP, но на сей раз адреса заменяются на так называемые разворачивающие адреса.