[zeromq-dev] XREP/XREQ And Inproc . Clean Shutdown

Antonio Teixeira eagle.antonio at gmail.com
Mon Mar 19 12:10:37 CET 2012

Hello Again :)

Dunno if i should open a new topic but here it goes.
During a test i found a small problem :)

The same client server model. Imagine using REQ the client asks something
from the server.
The message exits the client and arrives at the server while it's under
processing ( on the server ) the client has a fatal error and closes itself.

Now when server tries to respond to the client it will actually block
waiting for the remote peer.

Solutions :

Make a timeout and force an exception to happen on the server but that will
leave the socket in inconsistent state and will not allow me to recv()

Use solution 1 and render a new socket object ... yaikes danger ahead :)

make send(NOBLOCK)

I don't mind losing the message itself since this application was built
using a pessimistic approach and there are alot of fall backs i just want
to prevent the block at the server.

Maybe something like :
-> Oopsy peer not connected give it a few ms ( to make sure that is not a
switch error)
-> still no answer send it to /dev/null :)
-> carry on with the next one :)

Has anyone applied this or how do you guys deal with this on a production
app ?


2012/3/1 john skaller <skaller at users.sourceforge.net>

> On 02/03/2012, at 3:39 AM, Ian Barber wrote:
> >
> > On Thu, Mar 1, 2012 at 3:51 PM, john skaller <
> skaller at users.sourceforge.net> wrote:
> >
> > A server must actually shutdown the reader, loop or poll for a read
> > of EOF, then close the socket. Reading EOF on a shutdown receiver
> > appears to be the only way to ensure delivery of transmitted data.
> > The timeout in the polling or wait loop prevents  rogue clients from
> > choking the server with open sockets.
> >
> >
> > Worth checking with Martin, but I believe this is how it works, as of
> some time last year perhaps. The socket on closing gets handed off to a
> reaper thread to deal with.
> Ah, thank you! Yes, that makes sense. I have seen mention of that
> in the code.
> > Mike Pearce wrote a good paper on how the shutdown is handled:
> http://www.zeromq.org/whitepapers:0mq-termination - it's not TCP
> specific, but might help clarify.
> An excellent paper! Thanks!
> The termination model is quite nice actually.
> --
> john skaller
> skaller at users.sourceforge.net
> http://felix-lang.org
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120319/85a325bf/attachment.htm>

More information about the zeromq-dev mailing list