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 <[email protected]> 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 <[email protected]> > 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 > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
