I have written and I'm writing a message system where client sends, e.g., the following msg to the server: read <file id> <loc> <len> <addr> <return value> which reads a block of audio from a file to a (shared) memory location. I did not see the return value in your system (and don't figure out how one goes without it). The server sends both the result and the given return value back to the client. The return value could be something which only the client knows, e.g., array index, memory address, text. Something which associates the result with the request. The implementation is too complex to my taste as the messages are combination of raw byte data and string data. Each message starts with <int> which tells the length of the message. I have written a set of routines to assemble and disassemble these messages. I send these messages via pipes/sockets, via shared memory, and whatever. In any case, such message system should be general enough, and the return value brings it to that direction. Hmm... what do you mean by multiclient? Is the writing to the message queue an "atomic" operation for long messages? I use one pipe/socket per client to one server because I suspect only the server can make the long messages "atomic" by interleaving them correctly. Likewise, I use one lock-free shared-memory FIFO per client to one server. Regards, Juhana