Hi Pieter, >> ...I've made the client and worker threads into processes
PH> Nice. Is there a way to start the multiple processes from a single PH> source file? That will make the REBOL examples compatible with the PH> Guide. Yes. I have a launcher script that does that. PH> When I get frustrated at router sockets silently dropping messages I PH> go into the 0MQ code and add a printf. That is around xrep.cpp:197. The comments about when it silently ignores messages are helpful. Getting ahead of myself, I'm thinking about how I'll debug things like this for real, where I very likely won't want to add probes to zmq. PH> This will at least tell you whether or not there's a problem with the PH> identity/address frame. I imagine that's what it is. I just wasn't sure if there was a good way to trace things outside of zmq itself (i.e. not adding probes in the source). In the broker I can see that the address in the worker queue matches the worker its sending to, but there's no way to know the uuid of the worker in the worker itself, correct? That is, a socket can't get its own dynamic identity via getsockopt. PH> Then, you want to make sure the address matches the worker's address, PH> hasn't been mangled in some form, and that you're using a router PH> socket and not a dealer by mistake. Checked that it's a router, but I've done that before. I need to start a checklist for myself. :) PH> If all that fails, do a sanity check with a minimal case just to prove PH> router sockets work for you. Since I'm updating helpers and things as I go, I did go back and check that the msgqueue+taskwork2+tasksink2 and rrbroker examples still worked, which they do, multipart and all. Thanks! -- Gregg _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
