Correct. For an update, the attachment process seems to be working much better with the P2P socket thread disabled (pthread_create() commented out). Perhaps the IPC message handler was not getting CPU time to process the message somehow and was only swapped in once the client quit. I am now finding seg faults coming from zmq_engine.cpp, line 119 according to GDB. Currently investigating this.<br>
<br>
<div class="gmail_quote">On Tue, Jun 1, 2010 at 8:06 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>> Ok, so the server in our case is really more of a messaging hub. Clients<br>> attach to it so that they can talk to one another without having to<br>> create a nasty web of sockets to one another. We plan on having IPC<br>
> communication as well as TCP to remote clients. So the PUB/SUB model<br>> doesn't really work for our case. The heart of the problem really lies<br>> in the initial attachment calls using the REP/REQ model.<br>
<br></div>So you want to have:<br><br>1. central hub to dispatch reuqest and replies<br>2. clients that connect to the hub, send requests and receiver replies.<br>3. services that connect to the hub, receive requests dispatched by the<br>
hub and send replies back to the hub. Hub then routes the replies to<br>original requesters.<br><br>Is that your use case?<br>
<div>
<div></div>
<div class="h5"><br>Martin<br>_______________________________________________<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>