On 14 Dec 2013, at 11:46 am, Justin Karneges <[email protected]> wrote:
> ZeroMQ does not resend messages, so while the reconnect/queuing logic > will protect you to some degree, you still need to account for message loss. > > If you're using REQ then you'll need to timeout the request, otherwise > if a request or response message is lost then you'll never be able to > make a request on the socket ever again. So don't just indefinitely > block on a send or receive. Further, ZeroMQ historically hasn't had a > way to get a REQ socket out of the "waiting for response" state in the > event of a timeout other than by closing the socket and starting over. > This means the REQ type is not really usable in production. Better to > use DEALER and format a REQ-compatible message yourself. REP does not > suffer from these problems, so you can keep on using that and have > DEALER talk to REP. Surely REQ is still very useful in production: simply a client making a request. Connect, send request, wait for reply (or timeout) disconnect, job done. In the same way a HTTP connection would give you a single request and response. ? Of course the error handling on the client is to close the REQ socket and make a new one for a new request, but this is still fairly similar to a HTTP request. -Matt _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
