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.
On Tue, Jun 1, 2010 at 8:06 AM, Martin Sustrik <[email protected]> wrote: > Dana, > > > 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. > > So you want to have: > > 1. central hub to dispatch reuqest and replies > 2. clients that connect to the hub, send requests and receiver replies. > 3. services that connect to the hub, receive requests dispatched by the > hub and send replies back to the hub. Hub then routes the replies to > original requesters. > > Is that your use case? > > Martin > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
