[zeromq-dev] DEALER/ROUTER question about HWMs
Hi, I'm implementing a DEALER/ROUTER schema in which messages are sent from DEALER to ROUTER only, no messages are sent back. My question is related to HWMs in both sockets. When reaching the SNDHWM in DEALER socket, application will block (this is clear in documentation), however, it is not clear in documentation what happens if the RCVHWM is reached in the ROUTER socket. I'm assuming that if RCVHWM in ROUTER is reached, all the channel (end to end) will eventually block, ie. the DEALER socket will block too. I'm not expecting the ROUTER socket to drop messages once the RCVHWM is reached. Is this assumption correct? How does it behave with several clients? Does the ROUTER create an individual queue for each client or all clients share the same queue? Best regards, Diego A. Fons. -- Diego Andrés Fons Intraway Corp. Solution Developer AR Office: +54 (11) 6040 4000 US Office: +1 (516) 620 3890 Email: diego.f...@intraway.com Visit our website at http://www.intraway.com Proud to be an ISO 9001:2008 certified company ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] DEALER/ROUTER question about HWMs
The behavior is defined here: http://rfc.zeromq.org/spec:28 On Wed, Nov 5, 2014 at 2:20 PM, Diego Fons diego.f...@intraway.com wrote: Hi, I'm implementing a DEALER/ROUTER schema in which messages are sent from DEALER to ROUTER only, no messages are sent back. My question is related to HWMs in both sockets. When reaching the SNDHWM in DEALER socket, application will block (this is clear in documentation), however, it is not clear in documentation what happens if the RCVHWM is reached in the ROUTER socket. I'm assuming that if RCVHWM in ROUTER is reached, all the channel (end to end) will eventually block, ie. the DEALER socket will block too. I'm not expecting the ROUTER socket to drop messages once the RCVHWM is reached. Is this assumption correct? How does it behave with several clients? Does the ROUTER create an individual queue for each client or all clients share the same queue? Best regards, Diego A. Fons. -- Diego Andrés Fons Intraway Corp. Solution Developer AR Office: +54 (11) 6040 4000 US Office: +1 (516) 620 3890 Email: diego.f...@intraway.com Visit our website at http://www.intraway.com Proud to be an ISO 9001:2008 certified company ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] DEALER-ROUTER question
On Fri, Sep 26, 2014 at 3:10 AM, Goswin von Brederlow goswin-...@web.de wrote: Pieter: Would it be possible to put all the examples of the guide into a git project and have them included in the auto compile done for every pull request? The examples are in a subdirectory of the Guide git project, and we could activate Travis CI on that, though with a lot of languages it's unclear how we'd proceed. For C and C++ sure. I'll get around to updating the Guide for V4 at some stage. I've been collecting a lot of the material on my blog already so it's not a huge job, just fiddly. I'm kind of waiting to release CZMQ v3 first so that the C examples can use that. I think it's time to start burying the old ZeroMQ API. This has been a long goal of mine, to raise the high level semantics and get that working among all languages. What is the general opinion about moving classes from CZMQ to libzmq? We're seeing a lot of projects wrapping CZMQ now. If we eventually merge the two projects, we get back to a single target for languages to bind to. This is already where JeroMQ/JZMQ got to as well (a single common high level API) This would be worth a ZeroMQ v5 version upgrade in my opinion. At the same time we can kill the deprecated CZMQ classes, review some of the cute details like reference counting in frames, and so on... it also means we can start to rewrite parts of libzmq itself using the CZMQ style and containers. Sorry, getting ahead of myself here. Problem: we have two separate C APIs which is confusing and harder to package/ship Solution: merge the CZMQ v3 classes into libzmq and deliver as a single package. Discussion: do this after both CZMQ v3 and ZeroMQ v4.1 are released, and stamp this with a V5 label. Leave the old ZeroMQ v2 and v3 APIs in there (forever as far as I'm concerned). -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] DEALER-ROUTER question
On Fri, Sep 26, 2014 at 09:51:50AM +0200, Pieter Hintjens wrote: On Fri, Sep 26, 2014 at 3:10 AM, Goswin von Brederlow goswin-...@web.de wrote: Pieter: Would it be possible to put all the examples of the guide into a git project and have them included in the auto compile done for every pull request? The examples are in a subdirectory of the Guide git project, and we could activate Travis CI on that, though with a lot of languages it's unclear how we'd proceed. For C and C++ sure. I'll get around to updating the Guide for V4 at some stage. I've been collecting a lot of the material on my blog already so it's not a huge job, just fiddly. I'm kind of waiting to release CZMQ v3 first so that the C examples can use that. I think it's time to start burying the old ZeroMQ API. This has been a long goal of mine, to raise the high level semantics and get that working among all languages. What is the general opinion about moving classes from CZMQ to libzmq? We're seeing a lot of projects wrapping CZMQ now. If we eventually merge the two projects, we get back to a single target for languages to bind to. This is already where JeroMQ/JZMQ got to as well (a single common high level API) I love that things are no longer void * but have proper distinct types. What I don't like is the double or tripple indirection the CZMQ classes add. I prefer type safety over polymorphism there. If the two get merged then why not merge the zsock class with the libzqm socket structure. Use it as is for the zsock interface and cast it to void * for the sake of the old API. A true merge and not just layering the czmq API over the old one. This would be worth a ZeroMQ v5 version upgrade in my opinion. At the same time we can kill the deprecated CZMQ classes, review some of the cute details like reference counting in frames, and so on... it also means we can start to rewrite parts of libzmq itself using the CZMQ style and containers. Sorry, getting ahead of myself here. Problem: we have two separate C APIs which is confusing and harder to package/ship Solution: merge the CZMQ v3 classes into libzmq and deliver as a single package. Discussion: do this after both CZMQ v3 and ZeroMQ v4.1 are released, and stamp this with a V5 label. Leave the old ZeroMQ v2 and v3 APIs in there (forever as far as I'm concerned). -Pieter I would like to have a stable libzmq v4.1 soon because we at Q-Leap Networks want to use curve for authentication (requires zmq_msg_gets from 4.1) soon and I would rather have a stable version in the distribution than a git snapshot. Similary Debian Jessie would benefit from a new stable libzmq. I wouldn't feel comfortable in rushing a release with czmq merged into libzmq. This sounds like a fairly large change with lots of breakage till all the details are ironed out. Better to make what we have stable and releasing it before radically changing the lib. My 2c. MfG Goswin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] DEALER-ROUTER question
On Fri, Sep 26, 2014 at 10:37 AM, Goswin von Brederlow goswin-...@web.de wrote: If the two get merged then why not merge the zsock class with the libzqm socket structure. Use it as is for the zsock interface and cast it to void * for the sake of the old API. A true merge and not just layering the czmq API over the old one. For sure. I'd keep the polymophism between e.g. zactor and zsock. However one goal would be to kill and bury the old void * socket type. In CZMQ we've already killed contexts, and I don't see any reason to expose them again. I would like to have a stable libzmq v4.1 soon because we at Q-Leap Networks want to use curve for authentication (requires zmq_msg_gets from 4.1) soon and I would rather have a stable version in the distribution than a git snapshot. Similary Debian Jessie would benefit from a new stable libzmq. We can do that at any point. The current master is in very good shape (it pretty much always is, thanks to not allowing people to make big changes). I wouldn't feel comfortable in rushing a release with czmq merged into libzmq. We're talking about years here. Heck, the Guide isn't even updated for 4.0 yet. This is one of those rare roadmap / vision threads. Concretely all this has to happen first: - release 4.0.5 sometime very soon - release 4.1.0 RC sometime later - update Guide for 4.1 - release CZMQ v3.0 RC I think CZMQ can be sliced in several ways, e.g. the project modeling should go together with zproto into a new project (I think we agreed on a name but I forget what it was now...). Then libzmq should use that. One thing at a time. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] DEALER-ROUTER question
On Fri, Sep 26, 2014 at 11:06:29AM +0200, Pieter Hintjens wrote: This is one of those rare roadmap / vision threads. Concretely all this has to happen first: - release 4.0.5 sometime very soon - release 4.1.0 RC sometime later - update Guide for 4.1 - release CZMQ v3.0 RC I think CZMQ can be sliced in several ways, e.g. the project modeling should go together with zproto into a new project (I think we agreed on a name but I forget what it was now...). Then libzmq should use that. One thing at a time. -Pieter One last thing and then I will get back to work. The zring class in CZMQ I feel is still experimental and I would like to keep that in flux some more, maybe throw it out alltogether and replace it with the equipotent API I mentioned. You didn't give any ETAs but if CZMQ is still a few weeks away that will give plenty of time to get zring and ztimeout into shape and tested. MfG Goswin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] DEALER-ROUTER question
Conceptually I like the idea of czmq folding back into libzmq. While requiring both llibzmq and czmq for a language binding that wraps czmq isn't the end of the world, it is an additional complexity. I very much look forward to the czmq 3.0 release, and I'm hoping to have goczmq feature complete for it. Cheers! Brian On Fri, Sep 26, 2014 at 5:36 AM, Goswin von Brederlow goswin-...@web.de wrote: On Fri, Sep 26, 2014 at 11:06:29AM +0200, Pieter Hintjens wrote: This is one of those rare roadmap / vision threads. Concretely all this has to happen first: - release 4.0.5 sometime very soon - release 4.1.0 RC sometime later - update Guide for 4.1 - release CZMQ v3.0 RC I think CZMQ can be sliced in several ways, e.g. the project modeling should go together with zproto into a new project (I think we agreed on a name but I forget what it was now...). Then libzmq should use that. One thing at a time. -Pieter One last thing and then I will get back to work. The zring class in CZMQ I feel is still experimental and I would like to keep that in flux some more, maybe throw it out alltogether and replace it with the equipotent API I mentioned. You didn't give any ETAs but if CZMQ is still a few weeks away that will give plenty of time to get zring and ztimeout into shape and tested. MfG Goswin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] DEALER-ROUTER question
On Fri, Sep 26, 2014 at 11:36 AM, Goswin von Brederlow goswin-...@web.de wrote: One last thing and then I will get back to work. Ah, work, that mysterious thing we do when we're not talking about it :-) The zring class in CZMQ I feel is still experimental and I would like to keep that in flux some more, maybe throw it out alltogether and replace it with the equipotent API I mentioned. I like the zring API and will be using it a lot to replace the old zhash/zlist mix that lives in various servers. I'm thinking, end of the year for CZMQ v3. What do you think about biting the snake's head off, and replacing ztimeout with zserver as a container for zpeer's? I mean, if this is our use case, why not raise the semantic level until we actually get something tasty? -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] DEALER-ROUTER question
On Fri, Sep 26, 2014 at 01:46:20PM +0200, Pieter Hintjens wrote: On Fri, Sep 26, 2014 at 11:36 AM, Goswin von Brederlow goswin-...@web.de wrote: One last thing and then I will get back to work. Ah, work, that mysterious thing we do when we're not talking about it :-) The zring class in CZMQ I feel is still experimental and I would like to keep that in flux some more, maybe throw it out alltogether and replace it with the equipotent API I mentioned. I like the zring API and will be using it a lot to replace the old zhash/zlist mix that lives in various servers. Do you actually need it? I think the only place where you need a zhash/zlist combo is when the order in which items are added is relevant. If the order isn't relevant then zhash already provides all you need. Can you give some examples? Because in czmq only czertstore used the zhash/zlist combo and didn't even need it. I'm thinking, end of the year for CZMQ v3. What do you think about biting the snake's head off, and replacing ztimeout with zserver as a container for zpeer's? I mean, if this is our use case, why not raise the semantic level until we actually get something tasty? -Pieter ztimeout is another building block for my protocol. It has a somewhat more complex peer structure because it handles heartbeats, message ack, message nack and message resends. There could be a zserver structure that handles just heartbeating by using ztimeout and zpeer. But that probably wouldn't be usefull for since my heartbeats also function as ACKs/NACKs and have to be in a specific format. But maybe that could be handled via callbacks. Still, I like having simple building blocks that are self contained. That way each block can be tested on its own and reimplemented if a better design comes along. They can also be used in different ways. E.g. the gossip protocol should use ztimeout too. MfG Goswin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] DEALER-ROUTER question
On Fri, Sep 26, 2014 at 6:20 PM, Goswin von Brederlow goswin-...@web.de wrote: Do you actually need it? After all the work, that's a sad question. What I see are too-large patches done in I want to try this yet I've not defined a clean problem statement directions, which stress other people, create lots of discussion and other patches, and then ultimately in do we really need it? Having to ask this question is totally, horribly wrong. I've personally spent something like 30-40 hours on the containers, mostly driven by the original zdlist patch. That seems to be about 75% wasted time. This is what the whole process is about. I'm going to ask people who contribute to CZMQ to read the C4 document again and again until this kind of thrashing ends. Anyhow, please don't remove zring, if it ends up being unused, it'll die naturally. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] DEALER-ROUTER question
On Fri, Sep 26, 2014 at 06:34:32PM +0200, Pieter Hintjens wrote: On Fri, Sep 26, 2014 at 6:20 PM, Goswin von Brederlow goswin-...@web.de wrote: Do you actually need it? After all the work, that's a sad question. What I see are too-large patches done in I want to try this yet I've not defined a clean problem statement directions, which stress other people, create lots of discussion and other patches, and then ultimately in do we really need it? Having to ask this question is totally, horribly wrong. I've personally spent something like 30-40 hours on the containers, mostly driven by the original zdlist patch. That seems to be about 75% wasted time. I'm not talking about the doubly linked list part. Just about the doubly linked list + zhash combo part. Both doubly linked list and zhash are usefull on their own as are all the other changes we made with the global destructor, duplicator and comparator. How much of the time was spend on merging zhash support into zring? How much was spend on improving the containers overall? I don't think you spend 75% of the time on the merging and only that small part would be wasted. This is what the whole process is about. I'm going to ask people who contribute to CZMQ to read the C4 document again and again until this kind of thrashing ends. I think I followed that: If the Platform implements pull requests as issues, a Contributor MAY directly send a pull request without logging a separate issue. I think what doesn't quite work right is this: Maintainers SHOULD ask for improvements to incorrect patches and SHOULD reject incorrect patches if the Contributor does not respond constructively. For example in a recent pull request the zlist_goto was objected to, accoring with: To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere. But minutes later the patch was merged instead of waiting for the discussion to conclude and the pull request getting updated with a better patch. I'm not sure how one is supposed to go from a first draft to solve a problem to a release ready solution under the C4 process without this kind of trashing. New features and ideas don't pop up perfect. My solution might not be to your liking. Like you didn't like the zlist_node_t approach or the zring_goto wasn't liked. But my stated problem needs exactly that feature. Finding a solution that is acceptable by everyone takes a few tries. When I try to discuss a possible sollution before submitting code you say: Show me the code. When I show you code you complain about trashing. So I'm a bit lost how you think this should work. Or should I go off on my own, write 10 new classes to solve a complex problem and then after a year submitt them all in one go as finished solution without asking for any feedback along the way? I thought splitting the problem into managable chunks and sending pull request as chunks become ready was better. Release early, release often. Anyhow, please don't remove zring, if it ends up being unused, it'll die naturally. -Pieter You want to add a new but totaly unused class to the next stable release so it can die naturally? If you have a use for the combo of them then that is fine. You added that part to zring so you must have had a reason. I just don't see one at the moment now that zcertstore simply iterates over zhash. I didn't like mixing zdlist and zhash into a single zring class from the start. It wasn't needed with my original patch. MfG Goswin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] DEALER-ROUTER question
On Fri, Sep 26, 2014 at 7:50 PM, Goswin von Brederlow goswin-...@web.de wrote: How much of the time was spend on merging zhash support into zring? Ah, sure. That was a short job and can certainly be kicked out again later. Sorry, my bad. I think what doesn't quite work right is this: ... That 'discuss' part was added at some stage to please people who wanted more review of patches. Me, I don't like long discussions on code and I very dislike blocking code reviews, as they push towards a slower process with larger changes (in fact the larger the patch the easier it passes a code review, often). I'm not sure how one is supposed to go from a first draft to solve a problem to a release ready solution under the C4 process You make dozens or hundreds of cycles starting with blank paper and each time adding part of the API. You start with a minimal piece of code and you add to it little by little. The solution is *always* release ready. That's the whole point. Even if you solve 1 problem cleanly, it's release ready. Look at how zbeacon evolved as an example. It's quite clear. Now compare to e.g. ztree (a class we shipped and then I killed), and you'll see the difference. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] DEALER-ROUTER question.
A quick question for the zeromq experts if I may? Given a DEALER to ROUTER zeromq connection which is able to operate asynchronously; what is the best way to coordinate inbound and outbound message handling such that the DEALER socket is not blocked and an application is able to react and send at a given moment but also to promptly receive? Thanks, Riskybiz. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] DEALER-ROUTER question.
Please read the Guide and work through the examples, it has lots of explanation and examples of how to do this kind of thing. On Thu, Sep 25, 2014 at 10:36 AM, Riskybiz riskybizl...@live.com wrote: A quick question for the zeromq experts if I may? Given a DEALER to ROUTER zeromq connection which is able to operate asynchronously; what is the best way to coordinate inbound and outbound message handling such that the DEALER socket is not blocked and an application is able to react and send at a given moment but also to promptly receive? Thanks, Riskybiz. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] DEALER-ROUTER question
Dear Pieter, As a figurehead of the zeromq project I think you should know that the zguide and its examples, whilst a worthy effort, is actually a barrier to the progress of a learner. As a newcomer to networking my interactions and attempts to learn and use zeromq over the past year has been an unyielding source of issues to be overcome. Anyone else would probably have given up, but I recognise the benefits of the superb technology offered by zeromq. Part of the problem is perhaps that the zguide has been written by experts, where seemingly minor details are glossed over. For example in the hwserver and hwclient code it is not demonstrated how actually to read a message payload from the socket and extract the received message string. It cheats and prints; printf (Received World %d\n, request_nbr); When someone tries this early example the first thing they will experiment with is: How can I customise the message payload and get my own message sent and received? They will be disappointed. They might read on try to figure it out and be baffled by the multiple language bindings, apis and helper files and left wondering; what actually needs to be written to make zeromq work? What is the core underlying zeromq commands which need to be called? What needs to be installed? How do I do that? Where do I find the downloads? I encountered a situation last year when I needed to use the common technique of serialization to pass custom C++ objects over zeromq sockets. While the zguide alludes to the possibility there was nothing to offer assistance in the practical implementation. It took some considerable time, weeks, to sort this out into a functioning prototype. Where a simple functional guide example could have saved time and questions; not just for me but also for any number of other users. I find that the zguide code examples are in themselves problematic. The example code is very sparsely commented. Every line which does something non-trivial or zeromq specific should be explained. I have found examples to be zeromq version specific, operating system specific and requiring modifications to work on Windows. All of these factors just consume time in endeavouring to make them work or debug them with limited understanding of what is actually supposed to be happening. This causes questions and frustrations. CZMQ was recommended as the api to use with 'reference' C language code examples, I lost more time trying to compile CZMQ before realising the practical impossibility of this on Windows despite alluringly providing Visual Studio project files. The lack of working installation instructions was also a barrier. Then afterwards I discover that ROUTER sockets in updated zeromq versions no longer use UUID identities thus anyway invalidating the code example I was endeavouring to get working. More lost time, more questions. No progress. My suggestion is that if you want fewer basic questions asked in the community then please take time to revisit the zguide, its examples and necessary zeromq code resources and make it such that people can easily find the resources they need, confidently learn and demonstrate the examples and functionality for themselves; without enduring endless technical barriers and frustrations. I hope you will view my feedback as constructive. All that said; which part of the guide should I read to solve my DEALER-ROUTER issue, can I be confident that any associated zguide example will actually work and help me to further understand how to solve my own zeromq issues in the future? Riskybiz. Message: 29 Date: Thu, 25 Sep 2014 11:29:01 +0200 From: Pieter Hintjens p...@imatix.com Subject: Re: [zeromq-dev] DEALER-ROUTER question. To: ZeroMQ development list zeromq-dev@lists.zeromq.org Message-ID: CADL5_sjhfSqq_YDJq59pindtY3t15dUpiJVO3wr=qehn+ty...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Please read the Guide and work through the examples, it has lots of explanation and examples of how to do this kind of thing. On Thu, Sep 25, 2014 at 10:36 AM, Riskybiz riskybizl...@live.com wrote: A quick question for the zeromq experts if I may? Given a DEALER to ROUTER zeromq connection which is able to operate asynchronously; what is the best way to coordinate inbound and outbound message handling such that the DEALER socket is not blocked and an application is able to react and send at a given moment but also to promptly receive? Thanks, Riskybiz. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev -- ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev End of zeromq-dev Digest, Vol 81, Issue 25 ** ___ zeromq-dev mailing
Re: [zeromq-dev] DEALER-ROUTER question
Thanks for your answer, and I'm so glad you didn't give up yet. The irony of working on Windows is that while it's touted as a platform for less competent developers, it is in fact much harder to use than Linux, for ordinary development. So my first recommendation to you, if you're not up to getting things working on Windows is to use Ubuntu or similar as a learning box. It is true that we lack a good guide for getting started on Windows. Why don't you try, e.g. this excellent series of articles by Sacha Barber: http://www.codeproject.com/Articles/809849/ZeroMq-sharp-Hello-World In any case, the only way to learn ZeroMQ properly is to (a) get a language kit that works for you and (b) write simple examples, either copying from the Guide or by yourself, and after example number 20 or so, you will start to get it. Cheers Pieter On Thu, Sep 25, 2014 at 3:08 PM, Riskybiz riskybizl...@live.com wrote: Dear Pieter, As a figurehead of the zeromq project I think you should know that the zguide and its examples, whilst a worthy effort, is actually a barrier to the progress of a learner. As a newcomer to networking my interactions and attempts to learn and use zeromq over the past year has been an unyielding source of issues to be overcome. Anyone else would probably have given up, but I recognise the benefits of the superb technology offered by zeromq. Part of the problem is perhaps that the zguide has been written by experts, where seemingly minor details are glossed over. For example in the hwserver and hwclient code it is not demonstrated how actually to read a message payload from the socket and extract the received message string. It cheats and prints; printf (Received World %d\n, request_nbr); When someone tries this early example the first thing they will experiment with is: How can I customise the message payload and get my own message sent and received? They will be disappointed. They might read on try to figure it out and be baffled by the multiple language bindings, apis and helper files and left wondering; what actually needs to be written to make zeromq work? What is the core underlying zeromq commands which need to be called? What needs to be installed? How do I do that? Where do I find the downloads? I encountered a situation last year when I needed to use the common technique of serialization to pass custom C++ objects over zeromq sockets. While the zguide alludes to the possibility there was nothing to offer assistance in the practical implementation. It took some considerable time, weeks, to sort this out into a functioning prototype. Where a simple functional guide example could have saved time and questions; not just for me but also for any number of other users. I find that the zguide code examples are in themselves problematic. The example code is very sparsely commented. Every line which does something non-trivial or zeromq specific should be explained. I have found examples to be zeromq version specific, operating system specific and requiring modifications to work on Windows. All of these factors just consume time in endeavouring to make them work or debug them with limited understanding of what is actually supposed to be happening. This causes questions and frustrations. CZMQ was recommended as the api to use with 'reference' C language code examples, I lost more time trying to compile CZMQ before realising the practical impossibility of this on Windows despite alluringly providing Visual Studio project files. The lack of working installation instructions was also a barrier. Then afterwards I discover that ROUTER sockets in updated zeromq versions no longer use UUID identities thus anyway invalidating the code example I was endeavouring to get working. More lost time, more questions. No progress. My suggestion is that if you want fewer basic questions asked in the community then please take time to revisit the zguide, its examples and necessary zeromq code resources and make it such that people can easily find the resources they need, confidently learn and demonstrate the examples and functionality for themselves; without enduring endless technical barriers and frustrations. I hope you will view my feedback as constructive. All that said; which part of the guide should I read to solve my DEALER-ROUTER issue, can I be confident that any associated zguide example will actually work and help me to further understand how to solve my own zeromq issues in the future? Riskybiz. Message: 29 Date: Thu, 25 Sep 2014 11:29:01 +0200 From: Pieter Hintjens p...@imatix.com Subject: Re: [zeromq-dev] DEALER-ROUTER question. To: ZeroMQ development list zeromq-dev@lists.zeromq.org Message-ID: CADL5_sjhfSqq_YDJq59pindtY3t15dUpiJVO3wr=qehn+ty...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Please read the Guide and work through the examples, it has lots of explanation and examples of how
Re: [zeromq-dev] DEALER-ROUTER question
Dear Riskybiz, I posted several days ago, by recommendation of Pieter, a post about building your first C++ examples with ZeroMQ in windows (and Ubuntu/Mac), with the C++ ZMQCPP binding and using the biicode platform. In this way, even my students at university are able to build the examples in a few minutes without problems. Check it here http://blog.biicode.com/zeromq-cpp-biicode/ If you want serialization, we all agree that you should use an already existing framework/library, instead of developing your own. So the real problem is not about ZMQ at all, but instead, setup, learning and getting started with the serialization framework at the same time as ZMQ. A reference solution could be google protocol buffers. Please read also: http://docs.biicode.com/c++/examples/zmq_protobuf.html Sorry of the self-promotion, but I didnt got any feedback then in the list, and I think that these problems you are describing are really related to the issues we are trying to target in biicode for C/C++ languages. Love to hear your feedback. Diego Diego Rodriguez-Losada CTO Biicode Innovation SL 2014-09-25 15:08 GMT+02:00 Riskybiz riskybizl...@live.com: Dear Pieter, As a figurehead of the zeromq project I think you should know that the zguide and its examples, whilst a worthy effort, is actually a barrier to the progress of a learner. As a newcomer to networking my interactions and attempts to learn and use zeromq over the past year has been an unyielding source of issues to be overcome. Anyone else would probably have given up, but I recognise the benefits of the superb technology offered by zeromq. Part of the problem is perhaps that the zguide has been written by experts, where seemingly minor details are glossed over. For example in the hwserver and hwclient code it is not demonstrated how actually to read a message payload from the socket and extract the received message string. It cheats and prints; printf (Received World %d\n, request_nbr); When someone tries this early example the first thing they will experiment with is: How can I customise the message payload and get my own message sent and received? They will be disappointed. They might read on try to figure it out and be baffled by the multiple language bindings, apis and helper files and left wondering; what actually needs to be written to make zeromq work? What is the core underlying zeromq commands which need to be called? What needs to be installed? How do I do that? Where do I find the downloads? I encountered a situation last year when I needed to use the common technique of serialization to pass custom C++ objects over zeromq sockets. While the zguide alludes to the possibility there was nothing to offer assistance in the practical implementation. It took some considerable time, weeks, to sort this out into a functioning prototype. Where a simple functional guide example could have saved time and questions; not just for me but also for any number of other users. I find that the zguide code examples are in themselves problematic. The example code is very sparsely commented. Every line which does something non-trivial or zeromq specific should be explained. I have found examples to be zeromq version specific, operating system specific and requiring modifications to work on Windows. All of these factors just consume time in endeavouring to make them work or debug them with limited understanding of what is actually supposed to be happening. This causes questions and frustrations. CZMQ was recommended as the api to use with 'reference' C language code examples, I lost more time trying to compile CZMQ before realising the practical impossibility of this on Windows despite alluringly providing Visual Studio project files. The lack of working installation instructions was also a barrier. Then afterwards I discover that ROUTER sockets in updated zeromq versions no longer use UUID identities thus anyway invalidating the code example I was endeavouring to get working. More lost time, more questions. No progress. My suggestion is that if you want fewer basic questions asked in the community then please take time to revisit the zguide, its examples and necessary zeromq code resources and make it such that people can easily find the resources they need, confidently learn and demonstrate the examples and functionality for themselves; without enduring endless technical barriers and frustrations. I hope you will view my feedback as constructive. All that said; which part of the guide should I read to solve my DEALER-ROUTER issue, can I be confident that any associated zguide example will actually work and help me to further understand how to solve my own zeromq issues in the future? Riskybiz. Message: 29 Date: Thu, 25 Sep 2014 11:29:01 +0200 From: Pieter Hintjens p...@imatix.com Subject: Re: [zeromq-dev] DEALER-ROUTER question. To: ZeroMQ development list
Re: [zeromq-dev] DEALER-ROUTER question
need to be called? What needs to be installed? How do I do that? Where do I find the downloads? I encountered a situation last year when I needed to use the common technique of serialization to pass custom C++ objects over zeromq sockets. While the zguide alludes to the possibility there was nothing to offer assistance in the practical implementation. It took some considerable time, weeks, to sort this out into a functioning prototype. Where a simple functional guide example could have saved time and questions; not just for me but also for any number of other users. I find that the zguide code examples are in themselves problematic. The example code is very sparsely commented. Every line which does something non-trivial or zeromq specific should be explained. I have found examples to be zeromq version specific, operating system specific and requiring modifications to work on Windows. All of these factors just consume time in endeavouring to make them work or debug them with limited understanding of what is actually supposed to be happening. This causes questions and frustrations. CZMQ was recommended as the api to use with 'reference' C language code examples, I lost more time trying to compile CZMQ before realising the practical impossibility of this on Windows despite alluringly providing Visual Studio project files. The lack of working installation instructions was also a barrier. Then afterwards I discover that ROUTER sockets in updated zeromq versions no longer use UUID identities thus anyway invalidating the code example I was endeavouring to get working. More lost time, more questions. No progress. My suggestion is that if you want fewer basic questions asked in the community then please take time to revisit the zguide, its examples and necessary zeromq code resources and make it such that people can easily find the resources they need, confidently learn and demonstrate the examples and functionality for themselves; without enduring endless technical barriers and frustrations. I hope you will view my feedback as constructive. All that said; which part of the guide should I read to solve my DEALER-ROUTER issue, can I be confident that any associated zguide example will actually work and help me to further understand how to solve my own zeromq issues in the future? Riskybiz. Message: 29 Date: Thu, 25 Sep 2014 11:29:01 +0200 From: Pieter Hintjens p...@imatix.com Subject: Re: [zeromq-dev] DEALER-ROUTER question. To: ZeroMQ development list zeromq-dev@lists.zeromq.org Message-ID: CADL5_sjhfSqq_YDJq59pindtY3t15dUpiJVO3wr= qehn+ty...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Please read the Guide and work through the examples, it has lots of explanation and examples of how to do this kind of thing. On Thu, Sep 25, 2014 at 10:36 AM, Riskybiz riskybizl...@live.com wrote: A quick question for the zeromq experts if I may? Given a DEALER to ROUTER zeromq connection which is able to operate asynchronously; what is the best way to coordinate inbound and outbound message handling such that the DEALER socket is not blocked and an application is able to react and send at a given moment but also to promptly receive? Thanks, Riskybiz. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev -- ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev End of zeromq-dev Digest, Vol 81, Issue 25 ** ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] DEALER-ROUTER question
and functionality for themselves; without enduring endless technical barriers and frustrations. I hope you will view my feedback as constructive. All that said; which part of the guide should I read to solve my DEALER-ROUTER issue, can I be confident that any associated zguide example will actually work and help me to further understand how to solve my own zeromq issues in the future? Riskybiz. Message: 29 Date: Thu, 25 Sep 2014 11:29:01 +0200 From: Pieter Hintjens p...@imatix.com Subject: Re: [zeromq-dev] DEALER-ROUTER question. To: ZeroMQ development list zeromq-dev@lists.zeromq.org Message-ID: CADL5_sjhfSqq_YDJq59pindtY3t15dUpiJVO3wr=qehn+ty...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Please read the Guide and work through the examples, it has lots of explanation and examples of how to do this kind of thing. On Thu, Sep 25, 2014 at 10:36 AM, Riskybiz riskybizl...@live.com wrote: A quick question for the zeromq experts if I may? Given a DEALER to ROUTER zeromq connection which is able to operate asynchronously; what is the best way to coordinate inbound and outbound message handling such that the DEALER socket is not blocked and an application is able to react and send at a given moment but also to promptly receive? To answere your initial question: Simple case: zmp_poll Complex case: credit based workflow Both of these occur in the guide. Thanks, Riskybiz. MfG Goswin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
