Question

I have client and server programs which now communicate via TCP. I’m trying out using POSIX message queues instead (in cases where the client and server are on the same machine, of course). My hope is that it will improve performance (specifically via reduced latency).

I’ve worked out most of it, but am not sure about one thing: how to establish the ‘connection.’ The server accepts connections from multiple clients concurrently, so I’m tempted to emulate the TCP connection establish process like so:

1. Server opens a queue with a well-known name and reads from it continuously (it can use select(2) as with TCP).
2. Client opens three queues: two with arbitrary names (including some uniqueness such as PID to avoid collisions), and one with the well-known name used by the server.
3. Client posts a ‘connect’ message to the server’s queue, including the client’s queue names (one is designated for client-to-server traffic and the other for the converse).
4. Server opens the queues named in the client’s connect message and begins to read (select) from the client-to-server one.
5. Client closes the server queue with the well-known name. Two-way communication proceeds using the two queues named by the client (one for each direction).

You can probably see how this scheme is similar to the common TCP method, and that’s no accident. However, I’d like to know:

1. Can you think of a better way to do it?
2. Do you see any potential problems with my method?
3. Do you have any other thoughts, including about the likelihood that using message queues instead of TCP on the same machine will actually improve performance (latency)?

Keep in mind that I haven’t used POSIX message queues before (I did use IBM WebSphere MQ a while back, but that’s rather different). The platform is Linux.

Answer 1

I ended up implementing it basically as I described, with a few enhancements:

• In step 2, I used GUIDs for the queue names instead of incorporating the client’s PID.
• In step 4, I added the sending of an ‘accept’ message from server to client.
• When either side wishes to end communication, it sends a ‘disconnect’ message.

The handshaking is simpler than TCP, but seems sufficient.

As for latency: it’s much better. Roughly 75% less latency using POSIX message queues instead of TCP on the same machine. My messages are on the order of 100 bytes each.