Problem running IPC(Msg Q) on two terminals

Hi,

I am trying to run two processes one to send and other to receive few messages using message queue(SYS V). When I run two process on same terminal my program is working fine.

./receiver & ./sender

If I try to run receiver on one terminal tab and sender on other terminal-tab, the processes are not working correctly. The receiver is keep on waiting or blocked even though i send messages from other terminals.

I am not sure if its the terminal issue, or my program issue, I am using MobaXterm terminal.

Can any one please try these below programs and let me know if you are facing the same issue or is something wrong with my program.

below is code

receiver.c
===========

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

#include <stdio.h>
#include <sys/ipc.h>
#include <sys/msg.h>
#include <stdlib.h>
#include "queue.h"

void report_and_exit(const char* msg)
{
	 perror(msg);
	 exit(-1); /* EXIT_FAILURE */
}
int main() {
	 //key_t key= ftok(PathName, ProjectId); /* key to identify the queue */
	 key_t key= ftok("./MSGQ1", ProjectId); /* key to identify the queue */
	 if (key < 0) 
		 report_and_exit("key not gotten...");
	 int qid = msgget(key, 0666 | IPC_CREAT); /* access if created already */
	 if (qid < 0) 
		 report_and_exit("no access to queue...");
	 int types[] = {3, 1, 2, 1, 3, 2}; /* different than in sender */
	 int i;
	 for (i = 0; i < MsgCount; i++) {
		 queuedMessage msg; /* defined in queue.h */
		 //if (msgrcv(qid, &msg, sizeof(msg), types[i], MSG_NOERROR | IPC_NOWAIT) < 0)
		 if (msgrcv(qid, &msg, sizeof(msg), types[i], 0) < 0)
		 puts("msgrcv trouble...");
		 printf("%s received as type %i\n", msg.payload, (int) msg.type);
	 }
	 /** remove the queue **/
	 if (msgctl(qid, IPC_RMID, NULL) < 0) /* NULL = 'no flags' */
	 report_and_exit("trouble removing queue...");
	 return 0;
}


sender.c
=========

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#include <stdio.h>
#include <sys/ipc.h>
#include <sys/msg.h>
#include <stdlib.h>
#include <string.h>
#include "queue.h"
void report_and_exit(const char* msg) {
 perror(msg);
 exit(-1); /* EXIT_FAILURE */
}

int main() {
// key_t key = ftok(PathName, ProjectId);
   key_t key = ftok("./MSGQ1", ProjectId);
 if (key < 0) report_and_exit("couldn't get key...");
 int qid = msgget(key, 0666 | IPC_CREAT);
 if (qid < 0) report_and_exit("couldn't get queue id...");
 char* payloads[] = {"msg1", "msg2", "msg3", "msg4", "msg5", "msg6"};
 int types[] = {1, 1, 2, 2, 3, 3}; /* each must be > 0 */
 int i;
 for (i = 0; i < MsgCount; i++) {
 /* build the message */
 queuedMessage msg;
 msg.type = types[i];
 strcpy(msg.payload, payloads[i]);
 /* send the message */
 msgsnd(qid, &msg, sizeof(msg), IPC_NOWAIT); /* don't block */
 printf("%s sent as type %i\n", msg.payload, (int) msg.type);
 }
 return 0;
}


queue.h
========

1
2
3
4
5
6
7
8
9
#define ProjectId 123
#define PathName "queue.h" /* any existing, accessible file would do */
#define MsgLen 4
#define MsgCount 6
typedef struct {
 long type; /* must be of type long */
 char payload[MsgLen + 1]; /* bytes in the message */
} queuedMessage;
not working correctly

That's pretty vague.

I haven't tried your code, but the only possible problem I can imagine is that the terminals aren't set to the same current directory.
Last edited on
I think dutch has it.

> key_t key = ftok("./MSGQ1", ProjectId);

Do something like this, which doesn't depend (so much) on the invoking environment.
key_t key = ftok("/tmp/MSGQ1", ProjectId);

> That's pretty vague
dutch, when i run my receiver on other terminal it just waits , but will not receive any messages when i send.

> I can imagine is that the terminals aren't set to the same current directory.
I am in the same directory on both the terminals, do i still need to make something.

@dutch and @salem, thanks for pointing out, I changed my file location to /tmp/MSGQ1, still it does not work.
But I found out something, when i create a file either by touch /tmp/MSGQ1 or vi /tmp/MSGQ1 on a terminal this cannot be seen by other terminal this happens only with /tmp directory, not with my home directory.

But in both the cases, i am not able receive messages sent by other terminals.

if you look at the time stamps of /tmp/MSGQ1 one is created at 10.36 and other is created at 10.42 , i have issued touch command on two terminals.

terminal -1
-bash-4.1$ ls -l /tmp/MSGQ1
-rw-r--r-- 1 MaverPC eng 0 Apr 20 10:42 /tmp/MSGQ1

terminal -2
-bash-4.1$ ls -l /tmp/MSGQ1
-rw-r--r-- 1 MaverPC eng 0 Apr 20 10:36 /tmp/MSGQ1

I have even changed my permission to 0777 , but still no use.
Last edited on
Is this a remote connection?
> -rw-r--r-- 1 MaverPC eng 0 Apr 20 10:42 /tmp/MSGQ1
> -rw-r--r-- 1 MaverPC eng 0 Apr 20 10:36 /tmp/MSGQ1
It seems like when you're ssh'ing into your remote machine, what you're actually getting is a new instance of some chroot jail ( https://en.wikipedia.org/wiki/Chroot ) or other virtualisation technology.

Each connection you make, you get a whole new machine to play with (or so it would seem).

Is anything preserved on the remote when you log out? Or do you connect, upload, compile, test in every connection you make.

If you upload sender.c in one terminal, and receiver.c in the other, can you see both files when you do an 'ls'? If you can't, each terminal is a virtualised environment. What you do in one has no effect at all on the other.
@dutch
> Is this a remote connection?

Yes.

@salem
Yes, i can see the files in my home directory on both terminals, but when i create files on /tmp on one terminal, other terminal cannot see it.


OK, so make the absolute path be your home directory then.
@dutch and @salem,

Thanks for pointing me in right direction, yes your guess is 100% right.

when I try the same programs on standalone machine, it work without any problem.

Not sure how each terminals are different on remote ; i dint dig up much.
It makes sense for every user to have their own /tmp (including it seems multiple copies of yourself).

/tmp is world-writable, so it comes with a whole bunch of privacy and security caveats.
Topic archived. No new replies allowed.