[zeromq-dev] Deadlock between REQ/REP sockets?
dleonar at gmail.com
Tue Jun 1 13:53:38 CEST 2010
Ok, so the server in our case is really more of a messaging hub. Clients
attach to it so that they can talk to one another without having to create a
nasty web of sockets to one another. We plan on having IPC communication as
well as TCP to remote clients. So the PUB/SUB model doesn't really work for
our case. The heart of the problem really lies in the initial attachment
calls using the REP/REQ model.
The server/hub is running two threads, one waiting for IPC messages and the
other TCP. The client sends a message to the known IPC address and waits for
a reply. The server gets the message, processes it, and sends a reply, then
blocks on recv() again. The client (in this test) receives the reply and
quits. When I leave the server running and execute the client program again,
the server seems to not receive the client message, thus never sends the
reply the client is waiting on. The client times out and quits. After it
quits, the server reports receiving the message and processes it
What could possibly cause this deadlock? I am not manipulating any mutexes
or anything like that myself.
Thanks for the help.
On Fri, May 28, 2010 at 6:35 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> > Right, the server starts with recv() and follows up with a send() before
> > starting at the top of the loop again. The client starts with send() and
> > always follows with a recv(). The P2P socket was in the design made by a
> > co-worker. Some clients need to send messages and don't expect a reply.
> > I suppose we could change this to a PUB/SUB pattern, but I think there
> > may have been other reasons for the P2P that I can't remember at the
> Creating a socket per client seems plain wrong. What 0MQ does for you is
> managing many peers without you having to care about it.
> If what you want is client that sends requests to the server and gets
> replies from it as well as listen to messages published by server,
> simply create a REP and PUB sockets in server and REQ and SUB socket in
> the client.
> That way you can forget about connection management completely. 0MQ will
> do that for you for free.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev