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 <[email protected]>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 <[email protected]> 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 <[email protected]> >> 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 <[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 >> > >> _______________________________________________ >> 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
