PS I noticed this comment in pub.cpp -- I'm wondering if tearing down
the sockets will clean up this problem? (I don't own the thread, so I
can't wait for completion on the socket.)
// The pipe is full...
// When this happens, we simply return an error.
// This makes REP sockets vulnerable to DoS attack when
// misbehaving requesters stop collecting replies.
// TODO: Tear down the underlying connection (?)
On Jun 10, 2010, at 4:16 PM, Matt Weinstein wrote:
> Folks,
>
> I'm using a ZMQ_REQ socket to send a query to a server, and I need to
> timeout if the response isn't received on time.
>
> The best way would seem to be to zmq::poll with a timeout (not working
> for me at present, see my prior email). Alternatively I could use
> ZMQ_NOBLOCK and a sleep loop, but that's ugly.
>
> In any event, after I go away I'm left with a socket that's in the
> wrong state for the next request, which may arrive before the last
> request. I don't see any way of resetting a socket, so I'm presuming
> my best bet is to tear down the socket and use a new one for the next
> request?
>
> Meanwhile, what happens to the server at the other end of the request,
> still holding pieces of state through a zmq::queue via a ZMQ_XREP
> socket?
>
> I'm presuming tearing down the ZMQ_REQ side will just purge the
> relevant data, and the reply will go into the ether? Or will the
> server get an EFSM or some such when it tries to send() back on its
> REP stream?
>
> RSVP,
>
> Thanks!
>
> Matt
>
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
