[zeromq-dev] Fundamentals of a REQ/REP

[Daniel Hyams]

Ah, I see, that indeed works!

Can I suggest, though, an API that isn't quite so clumsy (zmq_reset(),
say?).  It's certainly not the end of the world to have to close and
reconnect, but that does mean that you have to carry along all of the socket
setup information and redo it.  It seems that  just having a zmq_reset call
to reset the communication pattern to its initial state would be appropriate
for this rather common use case.  I assume that it's just a flag
somewhere....

On Fri, Sep 30, 2011 at 5:03 PM, Chuck Remes <cremes.devlist at mac.com> wrote:

>
> On Sep 30, 2011, at 3:53 PM, Daniel Hyams wrote:
>
> > What I'm about to ask is so basic (very green to sockets and ZMQ), I have
> to be misunderstanding something fundamental :(  But I have been through the
> guide and searched the archives, and have not come up with a good answer for
> this.
> >
> > All I'm trying to do is have a server and client talk back and forth with
> a REQ/REP pattern.  (Client REQ, Server REP).  As long as the server side is
> up, everything is fine.
> >
> > But, what happens on the client end is unsavory, if the server is down.
>  What I would like to happen is for the client to be able to tell the user
> "hey, the server is down, and your request isn't going to happen" if the
> server does not respond to a REQ.  I cannot seem to make this happen....
> >
> > If the client does (in Python):
> >   sock.send("the reqeust")
> >   reply = sock.recv()
> > then this deadlocks when the servers is down, obviously.
> >
> > If the client does:
> >   sock.send("the request")
> >   poller = zmq.Poller();
> >   poller.register(sock.zmq.POLLIN)
> >   socks = dict(poller.poll(1000))
> >   if sock in socks:
> >       reply = sock.recv()
> >   else:
> >       print "The server is not alive"
> >       # oops, now the lockstep send/recv required for a REQ/REP setup is
> broken!
> >       # socket is in the wrong state for a send.
> >
> > Then I get into trouble also, because the socket gets in the wrong
> state...I want to send next, not receive.  But I don't see any way of
> forcing the socket back into a "sending" state.
> >
> > I also tried a PAIR instead of REQ/REP, and did much better with that
> one, but since ZMQ queues messages on the sending end, my server gets all of
> the (undesired) queued up messages upon startup, and the client is not ready
> to receive the resulting replies.
> >
> > So I'm mystified.  Is the answer a ROUTER/DEALER setup?
>
> The answer is to close the socket in the client and reopen it. This will
> "reset" its state. Use that in conjunction with the polling method you wrote
> about and it will be fine.
>
> cr
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Daniel Hyams
dhyams at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111001/5ae487f8/attachment.htm>