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:
select(2)
as with TCP).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:
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.
Can you think of a better way to do it?
Perhaps have a look at fifos (aka named pipes). They are like network sockets but for the local machine. They are uni-directional so you might need to create two, one for each direction. Your question does lack any reason of why you are making this change specifically. There is nothing wrong with using sockets for process to process communication. They are bi-directional, efficient, widely supported and do give you the freedom to separate the processes between machines later.
Do you see any potential problems with my method?
System V message queues and fifo named pipes are both absolutely fine. Fifo pipes are like regular pipes so you can read() and write() with minimal code changes. System V message queues require putting the data into a structure and invoking msgsnd(). Either approach would be fine however.
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)?
My other thoughts are that as you said, you need to develop a technique so each client has a unique identifier. One approach would be to add the pid to the structure you pass across or to negotiate a unique id with the parent / master at the beginning. The other thing to note is that the benefit of System V message queues are that you listen for "selective" messages so you could ideally use one queue from the server to all the clients, with each client waiting for a different message.
I have no idea about which technique gives you the most optimal throughput in your software. It really might not be worth using System V message queues but only you can make that decision.
Philluminati