az> As for >>> This sounds like an application problem, not a 0MQ problem
az> [0MQ] It's more designed to support some az> kind of historical data flow, where you don't want to lose even one az> message. What it can be? E.g. wheather data from sensors, e.g. quotes az> from stock exchange. But it is not very much suitable when you deal az> with something like: "place a bet" , "create a purchase order", "book hotel az> room". Agree? 0MQ has different sockets, with different semantics, so you can decide whether it's important not to lose messages, when to block, etc. There are also (an ever-growing set of) socket options and features like zmq_socket_monitor to track and control things. Is 0MQ suitable for your examples? Yes, I think it absolutely is. In your case, when you hit your timeout, why not close the socket (setting LINGER to 0) and connect again? -- Gregg _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
