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

Pieter Hintjens ph at imatix.com
Tue Jan 14 09:08:47 CET 2014


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
>



More information about the zeromq-dev mailing list