[zeromq-dev] Deadlock between REQ/REP sockets?

Dana Leonard dleonar at gmail.com
Fri May 28 03:40:44 CEST 2010

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 moment.


On Thu, May 27, 2010 at 7:05 PM, Martin Lucina <mato at kotelna.sk> wrote:

> dleonar at gmail.com said:
> > I am prohibited from posting code, so I'll do my best to describe my
> troubles.
> >
> > I've got a IPC client/server setup and I am having problems getting the
> server
> > to respond consistantly. The server has a REP socket open that it uses to
> > listen for client requests. When it receives a request, it creates a new
> P2P
> > socket for that client, spawns a listen thread for that socket, and loops
> back
> > around. The client creates a matching P2P socket and is able to send and
> > receive messages on that socket.
> Are you sending a reply down the REP socket after getting the initial
> request?
> Don't forget that REQ/REP work in lockstep, and you must follow the correct
> send/receive pattern:
> REQ (client): srsrsrsr...
> REP (service): rsrsrsrs...
> Also, why the P2P socket?
> -mato
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100527/b47b54d5/attachment.htm>

More information about the zeromq-dev mailing list