A System V message queue is a kernel-maintained linked list of messages. Each message has a type (a positive long integer) and a data body. Processes can send and receive messages independently — unlike pipes which are strictly one-way byte streams.

Key advantages over pipes for this file-server scenario:

• Message boundaries are preserved — each send/receive is one complete message, not a byte stream.
• Multiple clients can write to one server queue using different message types.
• Selective receive — a process can pick messages of a specific type, ignoring others.
• Bidirectional — the server replies directly to each client’s private queue.

The application has two programs: a server and a client.

The server runs continuously and handles multiple clients at the same time by forking a child process for each request.

Below is a visual showing how server, clients, and message queues relate to each other:

The important design point: every client has its own reply queue. The client passes its queue ID inside the request message so the server knows where to send the reply.

Both request and response messages use a long mtype field. This field controls which process receives the message when multiple messages are in a queue.

Request Message

Response Message Types (Server → Client)

IPC_PRIVATE is a special key that tells the kernel: “create a brand new queue that nobody else knows about yet.” No other process can accidentally connect to it because it has no fixed key.

This solves a key problem: if two clients both tried to receive from a shared response queue, they might steal each other’s messages. With IPC_PRIVATE:

• Each client gets a unique queue ID returned by msgget().
• The client puts this ID in the request so the server knows exactly where to reply.
• No other process knows this ID, so only this client gets the responses.

Before writing server or client code, you define the message structures that both sides share (usually in a header file):

/* svmsg_file.h — shared header for server and client */

#include <sys/msg.h>
#include <fcntl.h>

#define SERVER_KEY   0x1aaaaaa1   /* well-known key for server queue */
#define RESP_MSG_SIZE  8192        /* max bytes of file data per message */

/* Response message types */
#define RESP_MT_FAILURE  1   /* server could not open file */
#define RESP_MT_DATA     2   /* message contains file data  */
#define RESP_MT_END      3   /* end of file, no more data   */

/* Request message: client → server */
struct requestMsg {
    long  mtype;            /* message type (always 1) */
    int   clientId;         /* client's reply queue ID  */
    char  pathname[PATH_MAX]; /* file to serve           */
};
#define REQ_MSG_SIZE  (sizeof(struct requestMsg) - sizeof(long))

/* Response message: server → client */
struct responseMsg {
    long  mtype;                   /* RESP_MT_FAILURE/DATA/END */
    char  data[RESP_MSG_SIZE];     /* file data or error text  */
};

The size argument to msgsnd/msgrcv excludes the leading mtype field. That is why macros like REQ_MSG_SIZE subtract sizeof(long).

In the next part we go deeper into the concurrent server design — how forking works, how zombie processes are prevented, and how SIGCHLD is handled.

1. Why does a SysV message queue file server use IPC_PRIVATE for client reply queues?
2. What are the three response message types used in this application and when is each sent?
3. Why does the client embed its queue ID inside the request message?
4. What is the difference between SERVER_KEY and IPC_PRIVATE?
5. Why must the client delete its queue using atexit() instead of a normal close call?
6. How does the server distinguish between multiple clients if all requests go to one queue?
7. What problem would arise if all clients shared a single response queue?