BIG BIG BIG Problem with IPC Messages Queue ... Help Please !

BIG BIG BIG Problem with IPC Messages Queue ... Help Please !

Post by Lemaire Beno? » Wed, 19 Jun 2002 22:17:52



Hi !

I have a really huge problem with IPC message queues, I spent hours to find
the problem but in vain.
This is for a project for school and it's pretty urgent, so if anyone of you
could help it would be really nice !
In fact I have two app : standard.C and client.C
standard acts like a server for many clients.
standard at init, create the message queue and go in an infinite loop to
handle all the incoming messages.
client at init get the id to the message queue, and display a menu telling
what action we want to do (an action will send a message in the message
queue, for the server to read it, and then display the menu back).
However the client should also be able to receive messages from the server
or somewhere else. So it should have an infinite handle message loop as the
server.
However to be able to display the menu and to do that infinite loop, I had
the idea (and I don't see how to do it else, but that's not where the
problem come from anyway) to fork the client at the begining, so that in the
father i'll display the menu, and in the son i'll only have my infinite
message handle loop.
So that's good ...
When I send messages from client that are destinated to the server, it works
perfectly. However when I send a message from the server to the client, it
DOESN'T WORK !!! In fact it's when I kill the server (and the message
queue), that the messages the client should have displayed are actually
displayed !
So it bugs like shit, I spent like 10hours on it in vain, I got a big
headache, and I really really need help, so pleeeasse help if you are able
to.
Here are two extracts from client.C and standard.C, where the problems come
from.

If you think you can help me but need more details and explanations (and the
full litlle sources), you can
reach me by ICQ : 14261556.

Thanks a lot to anyone !

Benoit.

Extract from standard.C :
STANDARDMESSAGE stMsg;
int l;

stMsg.type = STANDARDACLIENT;

/* infinite loop to handle messages*/
for (;;)
{
   /* Message from client to standard */
  if (msgrcv(shmid, (MESSAGE*)&msg, sizeof(MESSAGE) - sizeof(long),
CLIENTASTANDARD, 0) != -1){
/* ask for connection*/
if (msg.typeDemande == DEMANDEACCESSTANDARD)
{
   if (msgsnd(shmid, (STANDARDMESSAGE*)&stMsg, sizeof(STANDARDMESSAGE) -
sizeof(long), 0) == -1)
{ perror("MSGSND STANDARD"); exit(1); }

.....

Extract from client.C :
void Init()
{
  key_t cle;
  curClient = (INFOSCLIENT*)malloc(sizeof(INFOSCLIENT));
  curClient->nomClient = "NONAME";
  curClient->numeroPoste = rand()%10000;

/************************/
/* IPC INIT */
/************************/
if((msgid=msgget(STANDARDKEY,0666))==-1)
{
  perror("Erreur lors de la recuperation de l'identificateur externe");
  exit(1);

Quote:}

/* We fork the process to be able to get message and still display the menu
in the father process */
/* We are in the son process */
if (fork() == 0)
{
  STANDARDMESSAGE msg;

  for (;;)
  {
     if (msgrcv(msgid, (STANDARDMESSAGE*)&msg, sizeof(STANDARDMESSAGE) -
sizeof(long),   STANDARDACLIENT, 0) != -1)
    {
        printf("INFO MESSAGE FROM STANDARD");
     }

     else
     {
         if (errno != ENOMSG)
         {  if (errno == EIDRM) perror("MESSAGE QUEUE DELETED"); exit(1); }
     }
  }
 }

Quote:}

 
 
 

1. I have a BIG, BIG,BIG problem with DOSEMU 0.98.5.

Hello,

Please can some one help me with this:

I have Red Hat 5.2, kernel 2.0.36, dosemu 0.98.5.
When i start DOSEMU then the config.sys and autoexec.bat will not load into
the computer his memory in DOSEMU.
I have placed the config.sys and the autoexec.bat on c:\
I have set the var. $_emusys = "sys" and $_emubat = "bat" into the
dosemu.conf.

But it will not work, can some one help me, what do i wrong?

Greatings Jarno

2. xxgdb

3. Big Big Big CORE Image !!

4. How configure the x server?

5. Big, Big Very BIG SCSI DISK

6. How to setup a debian package on a different distribution

7. Big big problem..Help me!!!

8. locked workstations

9. big disk problems - or: big-disk problems?

10. Big Drives....Big Problems

11. Big File Big Problem

12. big ignorant needs big help