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

[André Caron]

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140113/1ae8263b/attachment.htm>