Re: [zeromq-dev] using REQ in a real application
The Guide doesn't say it explicitly, but it does show how to use REQ reliably at some stage (Lazy Pirate pattern). REQ could be made to work better when a peer dies or does not respond within some timeout. I do like the idea of resetting the state when sending a message, this is simple and allows the application to decide the timeouts etc. REP doesn't have this issue. One new thing in ZMTP 3.0 but not yet implemented in libzmq is heartbeating, which would make REQ work better. -Pieter On Fri, Jul 19, 2013 at 4:56 AM, Justin Karneges jus...@affinix.com wrote: On 07/18/2013 04:09 PM, Steven McCoy wrote: On 18 July 2013 16:43, Matt Connolly matt.conno...@me.com mailto:matt.conno...@me.com wrote: What is the correct way to handle the timeout? If the REQ socket is in the receive state, the only way it seems to me is to close the socket and make a new socket with a new connection. Is that right? Yes, REQ and REP are pretty much L-plate http://en.wikipedia.org/wiki/L-plate sockets but also incredibly useful for rapid prototyping of environments. Heading towards production you want to replace with DEALER and ROUTER to remove the fatal blocking states. If that's true, it's not something I recall being at all clear from the guide. It sounds like there are some fixes in the right direction on zmq master at least. Maybe having the state reset itself on every write would be enough for REQ to be used in production without any hacks. Also, I don't think there's any issue with REP is there? One could use REP for a server and DEALER for a client without any gotchas. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] using REQ in a real application
Hi, I have a couple of concerns about using REQ. 1) In order to implement timeouts (which I'd think nearly every application should need), I use the following strategy: a) If I cannot write to the socket after enough time has passed, then I consider the request to have failed and I leave the socket in its current state. b) If I cannot read the response from the socket after enough time has passed, then I consider the request to have failed and I close and recreate the socket. I believe this socket resetting to be necessary so that the REQ state machine is willing to take writes again. Does this seem like the right way to go about timeouts? 2) What does the REQ socket do if it receives a message when it is not in a requesting state? My hope is that it would read messages and throw them away. If there's only exactly one read for every write, then I can envision a situation where the alignment is off and every request gets a wrongly matched response. Putting an id field on each request/response will help detect this, but it wouldn't get you unstuck. What can you say about this? Thanks. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] using REQ in a real application
On 07/18/2013 09:52 PM, Justin Karneges wrote: 2) What does the REQ socket do if it receives a message when it is not in a requesting state? My hope is that it would read messages and throw them away. If there's only exactly one read for every write, then I can envision a situation where the alignment is off and every request gets a wrongly matched response. Putting an id field on each request/response will help detect this, but it wouldn't get you unstuck. What can you say about this? In the currently released versions, the recv() call on the REQ socket will take a message from its pipes in a fair-queued way and hand that to the application. That means if you make a REQ socket and someone connects and sends a message to it, your next recv() will get that message - even if it arrived before the send() call. In zmq master that behavior has changed to drop all messages but the one from the pipe that a request was sent to. And the send() will clear the inbound message queues. Christian ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] using REQ in a real application
On 19 Jul 2013, at 5:52 am, Justin Karneges jus...@affinix.com wrote: Hi, I have a couple of concerns about using REQ. 1) In order to implement timeouts (which I'd think nearly every application should need), I use the following strategy: a) If I cannot write to the socket after enough time has passed, then I consider the request to have failed and I leave the socket in its current state. b) If I cannot read the response from the socket after enough time has passed, then I consider the request to have failed and I close and recreate the socket. I believe this socket resetting to be necessary so that the REQ state machine is willing to take writes again. Does this seem like the right way to go about timeouts? Great questions. I was wondering the same thing. To add another question in here: What is the correct way to handle the timeout? If the REQ socket is in the receive state, the only way it seems to me is to close the socket and make a new socket with a new connection. Is that right? -Matt.___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] using REQ in a real application
On 18 July 2013 16:43, Matt Connolly matt.conno...@me.com wrote: What is the correct way to handle the timeout? If the REQ socket is in the receive state, the only way it seems to me is to close the socket and make a new socket with a new connection. Is that right? Yes, REQ and REP are pretty much L-platehttp://en.wikipedia.org/wiki/L-plate sockets but also incredibly useful for rapid prototyping of environments. Heading towards production you want to replace with DEALER and ROUTER to remove the fatal blocking states. -- Steve-o ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] using REQ in a real application
On 07/18/2013 04:09 PM, Steven McCoy wrote: On 18 July 2013 16:43, Matt Connolly matt.conno...@me.com mailto:matt.conno...@me.com wrote: What is the correct way to handle the timeout? If the REQ socket is in the receive state, the only way it seems to me is to close the socket and make a new socket with a new connection. Is that right? Yes, REQ and REP are pretty much L-plate http://en.wikipedia.org/wiki/L-plate sockets but also incredibly useful for rapid prototyping of environments. Heading towards production you want to replace with DEALER and ROUTER to remove the fatal blocking states. If that's true, it's not something I recall being at all clear from the guide. It sounds like there are some fixes in the right direction on zmq master at least. Maybe having the state reset itself on every write would be enough for REQ to be used in production without any hacks. Also, I don't think there's any issue with REP is there? One could use REP for a server and DEALER for a client without any gotchas. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
