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
