Какой ключ поставить на стороне получателя очередей сообщений Linux? - PullRequest
2 голосов
/ 21 июля 2011

Я создал очередь сообщений, и часть отправителя успешно создает и отправляет сообщение в очередь сообщений.

Я использовал IPC_PRIVATE в качестве ключа msgget() на стороне отправителя.

Теперь мой вопрос: какой ключ использовать в msgget() на стороне получателя?

Использование IPC_PRIVATE на стороне получателя в качестве ключа в msgget() не принимает сообщение и дает сбой.

Следует также упомянуть, что msgsnd() в части отправителя указывает на ошибку (возвращает -1), но при печати с perror() выводом будет Success, и сообщение успешно отправляется в очередь сообщений иможно увидеть с помощью команды ipcs -q на терминале.Я не знаю, почему это происходит.

 if(msgsnd(msqid,&msgp,88,IPC_NOWAIT) == 0)
          {
                  perror("\nsend : msgsnd FAIL");
                  msgctl(msqid,IPC_RMID,buf);
                  return 1;
          }

Вывод: send: msgsnd FAIL: Success

Ответы [ 2 ]

3 голосов
/ 21 июля 2011

Вам нужно будет использовать общее значение ключа между двумя независимыми процессами ... использование IPC_PRIVATE означает, что вы не планируете разделять очередь между двумя процессами, если вторичный процесс не был разветвлен первым процессом.Из-за операции разветвления дочернему элементу будет присваиваться идентификатор очереди из родительского процесса, поэтому использование IPC_PRVATE в этом сценарии вполне допустимо.Но поскольку использование IPC_PRIVATE создает уникальное значение ключа для каждого вызова, в котором он используется, для сценариев, в которых у вас есть два совершенно независимых процесса, таких как отношения сервер / клиент, вам потребуется создать общий ключ ... это можетлибо это «магическое число», которое вы разделяете между всеми процессами, которые уже не используются другой очередью, сегментом совместно используемой памяти и т. д., либо вы можете создать ключ на основе общего файла в файловой системе, используя ftok().

1 голос
/ 21 июля 2011

Этот вопрос является причиной, по которой вам не следует использовать древние очереди сообщений SysV - просто нет хорошего способа получить уникальный ключ. Даже при ftok коллизии достаточно вероятны, поэтому вы должны написать код, чтобы попытаться обойти их. Представьте, что вы никогда не видели интерфейсы SysV IPC и вместо этого используете очереди сообщений POSIX; см man mq_open.

...