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

André Caron andre.l.caron at gmail.com
Wed Jan 15 02:32:52 CET 2014 

Hi Pieter!

The patch already included the relevant documentation change to
`zmq_socket()` and a new test.  I reopened the pull request on the main
development fork.  I also tested against the most recent version on my
Linux box.  I cleared up some build issues and added the test to the
autoconf-based build.

I also sent in another pull request as the CMake build was broken because
of a recently deleted file.

While you take a look at these two pull requests, I'll take a look into the
outbound connect notification since I might be interested in that to get
fixed as well.  Do you mind if the notifications get issued whatever the
flow is?  It seems to me it would be cleaner if it was symmetric and it
might be interesting for the application to be informed of new peers in
cases where the server is the first to send data; it seems simpler to
implement to boot!

Cheers,

André


On Tue, Jan 14, 2014 at 3:08 AM, Pieter Hintjens <ph at imatix.com> wrote:

> Please start by making all patches to libzmq, where we can test them
> safely. When they are stable and if they qualify as "fixing an issue"
> we can backport them to zeromq4-x.
>
> I closed the issue and pull request, you can reopen them on libzmq and
> we'll merge them. We then need a test case (or you can add to the
> existing tests/test_stream.cpp test case).
>
> Thanks
> Pieter
>
> On Tue, Jan 14, 2014 at 2:32 AM, André Caron <andre.l.caron at gmail.com>
> wrote:
> > Provided you accept this patch, how should I proceed in order to get this
> > fix included in the next pyzmq release?
> >
> > Thanks,
> >
> > André
> >
> >
> >
> > On Mon, Jan 13, 2014 at 8:30 PM, André Caron <andre.l.caron at gmail.com>
> > wrote:
> >>
> >> Hi Pieter,
> >>
> >> Created issue #48 (https://github.com/zeromq/zeromq4-x/issues/48) and
> sent
> >> pull request #49 (https://github.com/zeromq/zeromq4-x/pull/49) to
> zeromq4-x.
> >>
> >> As for the null message, I don't think it's a problem.  You can probably
> >> signal all new connections using a null message provided appropriate
> >> documentation.  In the meantime, I'll ignore null messages sent from
> unknown
> >> peers (those from whom I haven't heard of yet).
> >>
> >> Cheers,
> >>
> >> André
> >>
> >>
> >> On Mon, Jan 13, 2014 at 6:48 AM, Pieter Hintjens <ph at imatix.com> wrote:
> >>>
> >>> If you want a patch to the 4.0 fork you can make a test case and an
> >>> issue. I can then backport it. Otherwise it'll come to libzmq master
> >>> (= 4.1).
> >>>
> >>> One thing about receiving a null message; we'd thought at some stage
> >>> to use this to (also) signal a new connection ready, for outgoing
> >>> ZMQ_STREAM connections. This isn't really contradictory with what
> >>> you're doing, and worth keeping in mind.
> >>>
> >>> On Mon, Jan 13, 2014 at 4:36 AM, André Caron <andre.l.caron at gmail.com>
> >>> wrote:
> >>> > 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
> >>> >
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > 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
> >>
> >>
> >
> >
> > _______________________________________________
> > 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/20140114/226652fd/attachment.htm>

More information about the zeromq-dev mailing list