<div>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.</div>

<div> </div>
<div>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 accordingly.</div>

<div> </div>
<div>What could possibly cause this deadlock? I am not manipulating any mutexes or anything like that myself.</div>
<div> </div>
<div>Thanks for the help.<br><br></div>
<div class="gmail_quote">On Fri, May 28, 2010 at 6:35 AM, Martin Sustrik <span dir="ltr"><<a href="mailto:sustrik@250bpm.com">sustrik@250bpm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Dana,<br>
<div class="im"><br>> Right, the server starts with recv() and follows up with a send() before<br>> starting at the top of the loop again. The client starts with send() and<br>> always follows with a recv(). The P2P socket was in the design made by a<br>
> co-worker. Some clients need to send messages and don't expect a reply.<br>> I suppose we could change this to a PUB/SUB pattern, but I think there<br>> may have been other reasons for the P2P that I can't remember at the moment.<br>
<br></div>Creating a socket per client seems plain wrong. What 0MQ does for you is<br>managing many peers without you having to care about it.<br><br>If what you want is client that sends requests to the server and gets<br>
replies from it as well as listen to messages published by server,<br>simply create a REP and PUB sockets in server and REQ and SUB socket in<br>the client.<br><br>That way you can forget about connection management completely. 0MQ will<br>
do that for you for free.<br><font color="#888888"><br>Martin<br></font>
<div>
<div></div>
<div class="h5">_______________________________________________<br>zeromq-dev mailing list<br><a href="mailto:zeromq-dev@lists.zeromq.org">zeromq-dev@lists.zeromq.org</a><br><a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br>
</div></div></blockquote></div><br>