Как выбрать «Ключ» для межпроцессного взаимодействия в Linux? - PullRequest
4 голосов
/ 15 января 2010

Добрый день ...

Я делаю домашнюю работу, в которой говорится, что у меня 5 процессов; сервер и остальные клиенты. Предполагается, что каждый процесс запускается из другого исполняемого файла . Я собираюсь реализовать двустороннее решение для передачи сообщений, но вопрос не в передаче сообщений как таковой. Существует ли элегантный способ передачи клавиши между этими различными исполняемыми файлами? т.е. когда я вызываю следующую функцию:

int msgget(key_t key, int msgflg);

Как другие процессы должны знать ключ?

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

Ответы [ 3 ]

10 голосов
/ 15 января 2010

Одно соглашение заключается в использовании ftok () для генерации уникального ключа из man

Функция ftok () использует идентификатор файла по имени путь (который должен ссылаться на существующий, доступный файл) и наименее значимые 8 битов proj_id (который должен быть ненулевым) для генерации key_t тип System V IPC ключ, подходящий для использования с msgget (2), semget (2) или shmget (2).

Полученное значение одинаково для все пути, которые называют один и тот же файл, когда то же значение proj_id используемый. Возвращаемое значение должно быть разные когда (одновременно существующие) файлы или идентификаторы проекта отличается.

1 голос
/ 15 января 2010

Для "глобальных" ресурсов я поддерживаю ответ jspcal ftok(), который он получил передо мной:)

Если у вас есть несколько связанных процессов (то есть родитель и группа детей), и они должны совместно использовать очередь, тогда вы должны вызвать msgget с IPC_PRIVATE, который создаст очередь с неиспользованным ключом и вернет ручка к нему.

1 голос
/ 15 января 2010

AFAIK, вы обычно генерируете псевдослучайный ключ для своей программы и встраиваете его туда. Есть 2 ^ 32 возможных ключей, поэтому вероятность столкновения довольно мала.

Если вам нужно гарантировать отсутствие случайного столкновения, вы обычно используете именованный канал вместо передачи сообщений.

...