[zeromq-dev] Notification of peer disconnection for ZMQ_STREAM sockets.

[André Caron]

Thanks Pieter,

I've spent some time fiddling around with the code in order to submit a
patch.

At first glance, it looks like I need to make a change in
"stream_engine.cpp" in order to push an empty message into the session (iff
"options.raw_sock" is true) in the "stream_engine_t::error()" method which
is called on disconnections of all kinds.  Everything else should take care
of itself provided that empty messages don't get caught up somewhere in the
routing back to the application.

I wrote a small test program and it works nicely for ZMQ_STREAM sockets
over the TCP transport on Windows (so far, so good :-)  I'll run the test
suite on my Linux box tomorrow to see if I've broken anything for other
types of sockets.

When I'm confident about my patch, I assume I should send a pull request to
the main development fork?  Would it also be possible to submit a pull
request to the 4.x fork (would probably mean a faster deployment to PyZMQ
which is my primary binding)?

Cheers,

André


On Sat, Jan 11, 2014 at 4:51 AM, Pieter Hintjens <ph at imatix.com> wrote:

> Hi André,
>
> Yes, this would be a good solution. You'll have to ask someone to help
> make the patch, or learn enough to make it yourself.
>
> -Pieter
>
> On Thu, Jan 9, 2014 at 6:05 AM, André Caron <andre.l.caron at gmail.com>
> wrote:
> > Hi there!
> >
> > First and foremost, kudos for all your awesome work on this excellent
> > library :-)
> >
> > I'm experimenting with ZMQ_STREAM sockets and I'm not sure how to handle
> > disconnection of peers.  The man page is pretty clear on how to forcibly
> > disconnect a peer (send 0-length message), but there is no information
> about
> > handling disconnections.  Local tests using a simple Telnet server
> > implementation (pet project to accept control commands via Telnet in
> > ZMQ-based nodes) show me that the program never gets notified if the peer
> > disconnects (at least, zmq_poll never marks the socket as readable).
> >
> > This piece is quite critical because an application that receives
> non-framed
> > messages (such as an HTTP server) maintains per-connection state: in
> > particular, you need to buffer request data until a full request has
> > arrived.  This state must be dropped if the peer disconnects or the
> > connection is lost.
> >
> > Without some means to detect that a connection is no longer usable, ZMQ
> > programs must hold a per-connection timeout, and zmq_poll() using the
> min of
> > all these timeouts and forcibly drop the state for whichever connection
> has
> > expired, and then tell ZMQ to drop that connection.  Apart from
> introducing
> > an unnecessary delay in cleanup, this is quite a bit of work to be
> repeated
> > in each place where we use ZMQ_STREAM sockets... (I'm not hoping to do
> this
> > routinely, it would still be a pain to maintain).
> >
> > It seems to me that ZMQ_STREAM is so close to looking like a real ZMQ
> > socket.  The last thing it needs IMO to be close enough would be to have
> the
> > following behavior on peer-initiated disconnection:
> > - zmq_poll() shows disconnected ZMQ_STREAM sockets as readable; and
> > - zmq_msg_recv() return as zero-length message.
> > This would make for such a smoother experience of bridging ZMQ with
> existing
> > protocols!
> >
> > Any thoughts on this?
> >
> > Cheers,
> >
> > André
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> _______________________________________________
> 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/20140112/dc6dbba5/attachment.htm>