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

Pieter Hintjens ph at imatix.com
Wed Jan 15 19:07:02 CET 2014 

Hi André,

Looking forward to the pull requests...

-Pieter

On Wed, Jan 15, 2014 at 2:32 AM, André Caron <andre.l.caron at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>

More information about the zeromq-dev mailing list