Hi André, Looking forward to the pull requests...
-Pieter On Wed, Jan 15, 2014 at 2:32 AM, André Caron <[email protected]> wrote: > Hi Pieter! > > The patch already included the relevant documentation change to > `zmq_socket()` and a new test. I reopened the pull request on the main > development fork. I also tested against the most recent version on my Linux > box. I cleared up some build issues and added the test to the > autoconf-based build. > > I also sent in another pull request as the CMake build was broken because of > a recently deleted file. > > While you take a look at these two pull requests, I'll take a look into the > outbound connect notification since I might be interested in that to get > fixed as well. Do you mind if the notifications get issued whatever the > flow is? It seems to me it would be cleaner if it was symmetric and it > might be interesting for the application to be informed of new peers in > cases where the server is the first to send data; it seems simpler to > implement to boot! > > Cheers, > > André > > > On Tue, Jan 14, 2014 at 3:08 AM, Pieter Hintjens <[email protected]> wrote: >> >> 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 <[email protected]> >> 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 <[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 >> > >> _______________________________________________ >> 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
