System V and Posix message queues

minceillusionInternet and Web Development

Jul 30, 2012 (5 years and 1 month ago)

570 views

-----------------------------------------------------------------------------------------------------------------------------
-

There are two flavors of message queues... the old System V version (msgsend(), msgget(), etc)
and the newer
Posix

version (
mq_send(), mq_recieve(), etc). The
Posix

version is newer and
more efficient.


Someone must be listening to a socket or you can't use it. A message queue stores the data
until some process reads it. This could be minutes or hours later. Also you could have

several
processes take turns reading a message queue...like the tellers at a bank taking the next
customer from a common queue. If the queue gets too long, add another teller at the bank or
another instance of a server process on your system.

------------
----------------------------------------------------------------------------------------------------------

http://stackoverflow.com/questions/410039/using
-
posix
-
message
-
queues
-
instead
-
of
-
tcp
-
sockets
-
how
-
to
-
establish
-
connection


I have client and server pro
grams 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 ou
t 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
-
kn
own 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 M
Q a while back, but that's rather different). The platform is Linux.

c

connection

client
-
server

posix

message
-
queue


flag

asked Jan 3 '09 at 22:48


John Zwinck

1,708313


94% accept rate




4 Answers

oldest

newest

votes


2


1.

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.

2.

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.

3.

Do you have any other thoughts, including about the likelihood t
hat
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 fro
m 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