[LCP] Questions regarding message queue

[Paul Gearon]

Hi,

Catching up on a backlog of email, I realized that I missed this one...

On Jul 22, 2007, at 11:45 PM, Ludwig Isaac Lim wrote:
> Hi:
>
>    I have 2 questions regarding message queue IPCs:
>
> 1) What is the standard way of generating a queue id? I
> usually do the following:
>
>     key = ftok(<name of the executable file>,..);
>     id = msgget(key,...);
>
>     I can see problems arising when I move the executable
> to another directory.

Actually, while this is theoretically bad, it will often work.  The  
reason is because the key is generated from the inode of the file.   
If you do a simple mv (as opposed to a cp;rm) then the inode won't  
change, and hence the value will be the same.

>    Does a better alternative exist? Is the code below much
> better
>
>    touch(<name of a temporary file>);
>
>    key = ftok(<name of the temporary file>):
>
>    since "touch" was called prior to ftok, then mostly
> likely, calls to ftok will always be successfull.

Well, there's no "touch" call (unless you use system(3)), but you can  
easily use creat(2) or open(2).  This approach works just fine.

What you're doing here is essentially registering a service for  
clients to connect to.  You need some kind of "address" for this  
service, otherwise clients won't know how to find you.  In the world  
of sockets, this is typically done by using a predefined port  
number.  This is subject to collision, but for well known services  
the port number is reserved for that protocol only (eg. port 80 is  
http).

You should be safe with a name like:
/tmp/my.program.name.and.a.service.number.1234

Anyone colliding with this name is just asking for  
difficulties.  :-)  Besides, the algorithm *can* lead to collisions  
anyway - though these are unlikely.

>    Supposing somebody deletes the temporary file AFTER the
> message queue has been created. Will it affect the message
> queue?

Not the queue itself, but now that the file is gone, it will not be  
possible for any clients to generate the same key again, even if they  
re-create the file (since the inode may be different).  Any clients  
that are already connected to the shared memory won't notice a problem.

> 2) Is message queue always a better alternative to FIFO?
> The only foreseable problem with message queues if the
> message size larger than msgmax. When is FIFO preferred
> over message queues? It seems that FIFO is much better is
> the message size is very large. Any other opinion?

FIFOs are good for transferring data from one process to another,  
particularly large amounts (though if it's big and needs to be  
updated, then consider shared memory, and if it's REALLY big then use  
mmap).  Message queues are a little different:
- Messages have limited size.
- They can be received out of order (controlled with the message type)
- Multiple processes can write to the queue.
- Multiple processes can read from the queue (though this needs to be  
synchronized)

In other words, message queues are good for sending messages.  :-)

Regards,
Paul