Re: [zeromq-dev] When unreliability is desired
I've pushed the changes: https://github.com/LindleyF/libzmq Note that this just builds---I doubt very much that it works yet. Here are the changes: https://github.com/LindleyF/libzmq/commit/c5f576e20db663bc724536786ef31a9482fe2fbe I wasn't sure what to do about the copyright notice so I left the Crossroads text mostly in place, with a note that I modified it for 0MQ. On Thu, Dec 19, 2013 at 2:55 PM, Pieter Hintjens p...@imatix.com wrote: Wow, that's fantastic. I'm really eager to get my hands on another wire protocol to turn into a neat little stack of RFCs! (I'm sure this is the sign of a deeply troubled mind. :-) On Thu, Dec 19, 2013 at 6:18 PM, Lindley French lindl...@gmail.com wrote: Well, I've got it building. I have no idea if it works because I don't fully understand the design, and I'm pretty sure just commenting out the encoder/decoder related lines was the wrong thing to do, but it builds now, and that's a first step. The machine I'm on can't push and pull from github so I won't be able to upload the changes to my fork just yet. I should be able to get that done in a day or so. On Thu, Dec 19, 2013 at 3:12 AM, Pieter Hintjens p...@imatix.com wrote: On Wed, Dec 18, 2013 at 8:33 PM, Lindley French lindl...@gmail.com wrote: Come to think of it, the way that library is structured, it would be easy enough to use it on top of ZMQ. Therefore it may not be reasonable to integrate it anyway. Yes. My point was really not about pros or cons of libraries, rather solving one problem at a time, and getting a minimal plausible first step down. I'd really enjoy seeing a raw UDP transport that we can hack on. I'm hoping some unsung genius can pull off the impossible and bring that code in from XS, even in basic form. Once we have something we can improve it... -Pieter ___ 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 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] When unreliability is desired
I've opened a github issue for this: https://github.com/zeromq/libzmq/issues/807 On Sat, Jan 4, 2014 at 12:04 PM, Lindley French lindl...@gmail.com wrote: I've pushed the changes: https://github.com/LindleyF/libzmq Note that this just builds---I doubt very much that it works yet. Here are the changes: https://github.com/LindleyF/libzmq/commit/c5f576e20db663bc724536786ef31a9482fe2fbe I wasn't sure what to do about the copyright notice so I left the Crossroads text mostly in place, with a note that I modified it for 0MQ. On Thu, Dec 19, 2013 at 2:55 PM, Pieter Hintjens p...@imatix.com wrote: Wow, that's fantastic. I'm really eager to get my hands on another wire protocol to turn into a neat little stack of RFCs! (I'm sure this is the sign of a deeply troubled mind. :-) On Thu, Dec 19, 2013 at 6:18 PM, Lindley French lindl...@gmail.com wrote: Well, I've got it building. I have no idea if it works because I don't fully understand the design, and I'm pretty sure just commenting out the encoder/decoder related lines was the wrong thing to do, but it builds now, and that's a first step. The machine I'm on can't push and pull from github so I won't be able to upload the changes to my fork just yet. I should be able to get that done in a day or so. On Thu, Dec 19, 2013 at 3:12 AM, Pieter Hintjens p...@imatix.com wrote: On Wed, Dec 18, 2013 at 8:33 PM, Lindley French lindl...@gmail.com wrote: Come to think of it, the way that library is structured, it would be easy enough to use it on top of ZMQ. Therefore it may not be reasonable to integrate it anyway. Yes. My point was really not about pros or cons of libraries, rather solving one problem at a time, and getting a minimal plausible first step down. I'd really enjoy seeing a raw UDP transport that we can hack on. I'm hoping some unsung genius can pull off the impossible and bring that code in from XS, even in basic form. Once we have something we can improve it... -Pieter ___ 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 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] When unreliability is desired
On Sat, Jan 4, 2014 at 6:04 PM, Lindley French lindl...@gmail.com wrote: I've pushed the changes: https://github.com/LindleyF/libzmq Note that this just builds---I doubt very much that it works yet. Looks good for a start. I wasn't sure what to do about the copyright notice so I left the Crossroads text mostly in place, with a note that I modified it for 0MQ. I've asked Martin Lucina for permission to use our standard model of putting all attribution in AUTHORS. For the rest of the header, it's fair to use the This file is part of 0MQ. text, without further attribution to XS (when XS forked from ZeroMQ, that was likewise how it went on all sources.) I'm wondering if, for all transports, it wouldn't be useful to have an interface enumeration method in libzmq (much as we're doing in zbeacon now). -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
On Wed, Dec 18, 2013 at 8:33 PM, Lindley French lindl...@gmail.com wrote: Come to think of it, the way that library is structured, it would be easy enough to use it on top of ZMQ. Therefore it may not be reasonable to integrate it anyway. Yes. My point was really not about pros or cons of libraries, rather solving one problem at a time, and getting a minimal plausible first step down. I'd really enjoy seeing a raw UDP transport that we can hack on. I'm hoping some unsung genius can pull off the impossible and bring that code in from XS, even in basic form. Once we have something we can improve it... -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
Well, I've got it building. I have no idea if it works because I don't fully understand the design, and I'm pretty sure just commenting out the encoder/decoder related lines was the wrong thing to do, but it builds now, and that's a first step. The machine I'm on can't push and pull from github so I won't be able to upload the changes to my fork just yet. I should be able to get that done in a day or so. On Thu, Dec 19, 2013 at 3:12 AM, Pieter Hintjens p...@imatix.com wrote: On Wed, Dec 18, 2013 at 8:33 PM, Lindley French lindl...@gmail.com wrote: Come to think of it, the way that library is structured, it would be easy enough to use it on top of ZMQ. Therefore it may not be reasonable to integrate it anyway. Yes. My point was really not about pros or cons of libraries, rather solving one problem at a time, and getting a minimal plausible first step down. I'd really enjoy seeing a raw UDP transport that we can hack on. I'm hoping some unsung genius can pull off the impossible and bring that code in from XS, even in basic form. Once we have something we can improve it... -Pieter ___ 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] When unreliability is desired
Wow, that's fantastic. I'm really eager to get my hands on another wire protocol to turn into a neat little stack of RFCs! (I'm sure this is the sign of a deeply troubled mind. :-) On Thu, Dec 19, 2013 at 6:18 PM, Lindley French lindl...@gmail.com wrote: Well, I've got it building. I have no idea if it works because I don't fully understand the design, and I'm pretty sure just commenting out the encoder/decoder related lines was the wrong thing to do, but it builds now, and that's a first step. The machine I'm on can't push and pull from github so I won't be able to upload the changes to my fork just yet. I should be able to get that done in a day or so. On Thu, Dec 19, 2013 at 3:12 AM, Pieter Hintjens p...@imatix.com wrote: On Wed, Dec 18, 2013 at 8:33 PM, Lindley French lindl...@gmail.com wrote: Come to think of it, the way that library is structured, it would be easy enough to use it on top of ZMQ. Therefore it may not be reasonable to integrate it anyway. Yes. My point was really not about pros or cons of libraries, rather solving one problem at a time, and getting a minimal plausible first step down. I'd really enjoy seeing a raw UDP transport that we can hack on. I'm hoping some unsung genius can pull off the impossible and bring that code in from XS, even in basic form. Once we have something we can improve it... -Pieter ___ 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 mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
On Tue, Dec 17, 2013 at 11:30 PM, Lindley French lindl...@gmail.com wrote: It would be really neat if we could integrate something like http://feclib.sourceforge.net/documentation.html into this. Not sure how that possibility would work license-wise, though. I'd recommend against looking at existing libraries unless they are compelling answers to a problem we've not been able to solve any other way. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
Any particular reason? The natural extension of that philosophy is that I shouldn't bother looking at ZeroMQ because it's an existing library and I might be able to solve my problems other ways. On Wed, Dec 18, 2013 at 6:13 AM, Pieter Hintjens p...@imatix.com wrote: On Tue, Dec 17, 2013 at 11:30 PM, Lindley French lindl...@gmail.com wrote: It would be really neat if we could integrate something like http://feclib.sourceforge.net/documentation.html into this. Not sure how that possibility would work license-wise, though. I'd recommend against looking at existing libraries unless they are compelling answers to a problem we've not been able to solve any other way. -Pieter ___ 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] When unreliability is desired
On Wed, Dec 18, 2013 at 7:22 PM, Lindley French lindl...@gmail.com wrote: Any particular reason? The natural extension of that philosophy is that I shouldn't bother looking at ZeroMQ because it's an existing library and I might be able to solve my problems other ways. Yes, many reasons. The main one is complexity. You can read http://hintjens.com/blog:19 and our contribution process, RFC 22, which requires that every patch be a minimal solution to an agreed problem. Importing libraries breaks that rule and needs to happen with great care when we're sure the tradeoffs are worth it. Technically, additional dependencies make packaging ZeroMQ a horrid process. If you can solve whatever problem you have without using ZeroMQ, why would you use ZeroMQ? -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
Yes, many reasons. The main one is complexity. You can read http://hintjens.com/blog:19 and our contribution process, RFC 22, which requires that every patch be a minimal solution to an agreed problem. Importing libraries breaks that rule and needs to happen with great care when we're sure the tradeoffs are worth it. Whether or not FEC functionality is needed is the relevant question. If that is agreed to be a problem, whether the solution comes from a library or new code is a separate issue. Technically, additional dependencies make packaging ZeroMQ a horrid process. Large dependencies, sure. Small dependencies that can be added just as a few additional source files (license permitting) shouldn't be a big deal. If you can solve whatever problem you have without using ZeroMQ, why would you use ZeroMQ? The same reason I use any library---to save time, and effort, and because I understand that there's no point reinventing the wheel if someone already has functionality I can leverage in a tested, working condition. On Wed, Dec 18, 2013 at 2:05 PM, Pieter Hintjens p...@imatix.com wrote: On Wed, Dec 18, 2013 at 7:22 PM, Lindley French lindl...@gmail.com wrote: Any particular reason? The natural extension of that philosophy is that I shouldn't bother looking at ZeroMQ because it's an existing library and I might be able to solve my problems other ways. Yes, many reasons. The main one is complexity. You can read http://hintjens.com/blog:19 and our contribution process, RFC 22, which requires that every patch be a minimal solution to an agreed problem. Importing libraries breaks that rule and needs to happen with great care when we're sure the tradeoffs are worth it. Technically, additional dependencies make packaging ZeroMQ a horrid process. If you can solve whatever problem you have without using ZeroMQ, why would you use ZeroMQ? -Pieter ___ 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] When unreliability is desired
Come to think of it, the way that library is structured, it would be easy enough to use it on top of ZMQ. Therefore it may not be reasonable to integrate it anyway. On Wed, Dec 18, 2013 at 2:31 PM, Lindley French lindl...@gmail.com wrote: Yes, many reasons. The main one is complexity. You can read http://hintjens.com/blog:19 and our contribution process, RFC 22, which requires that every patch be a minimal solution to an agreed problem. Importing libraries breaks that rule and needs to happen with great care when we're sure the tradeoffs are worth it. Whether or not FEC functionality is needed is the relevant question. If that is agreed to be a problem, whether the solution comes from a library or new code is a separate issue. Technically, additional dependencies make packaging ZeroMQ a horrid process. Large dependencies, sure. Small dependencies that can be added just as a few additional source files (license permitting) shouldn't be a big deal. If you can solve whatever problem you have without using ZeroMQ, why would you use ZeroMQ? The same reason I use any library---to save time, and effort, and because I understand that there's no point reinventing the wheel if someone already has functionality I can leverage in a tested, working condition. On Wed, Dec 18, 2013 at 2:05 PM, Pieter Hintjens p...@imatix.com wrote: On Wed, Dec 18, 2013 at 7:22 PM, Lindley French lindl...@gmail.com wrote: Any particular reason? The natural extension of that philosophy is that I shouldn't bother looking at ZeroMQ because it's an existing library and I might be able to solve my problems other ways. Yes, many reasons. The main one is complexity. You can read http://hintjens.com/blog:19 and our contribution process, RFC 22, which requires that every patch be a minimal solution to an agreed problem. Importing libraries breaks that rule and needs to happen with great care when we're sure the tradeoffs are worth it. Technically, additional dependencies make packaging ZeroMQ a horrid process. If you can solve whatever problem you have without using ZeroMQ, why would you use ZeroMQ? -Pieter ___ 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] When unreliability is desired
It would be really neat if we could integrate something like http://feclib.sourceforge.net/documentation.html into this. Not sure how that possibility would work license-wise, though. On Fri, Dec 13, 2013 at 2:11 PM, Pieter Hintjens p...@imatix.com wrote: We should ignore the encoder classes as they are specific to TCP and hacked for PGM (frame format was the same originally). Each protocol should have its own framing spec and implementation. On Thu, Dec 12, 2013 at 8:04 PM, Steven McCoy steven.mc...@miru.hk wrote: On 7 December 2013 00:34, lindl...@gmail.com wrote: I'll take a look at tipc. I've been using the pgm classes as a reference so far. They appear to use v1_encoder while tcp uses v2_encoder. If you can get a nice clean framework setup independent of the TCP/Unix socket setup I think many others and myself included would like to experiment adding many different types of protocol to 0mq. I have many on my wish list. -- Steve-o ___ 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 mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
On 17 December 2013 17:30, Lindley French lindl...@gmail.com wrote: It would be really neat if we could integrate something like http://feclib.sourceforge.net/documentation.html into this. Not sure how that possibility would work license-wise, though. Google's QUIC includes XOR FEC as their studies have shown little requirement for full on Reed Solomon encoding. OpenPGM includes Reed Solomon FEC as studies have shown it dramatically improves performance for large number of receivers. However Microsoft went ahead and implemented an incompatible scheme to everyone else so nothing works out-of-the-box. -- Steve-o ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
Microsoft often does such things. Anyway, one of the goals of a pure UDP transport is to work well over one-way physical links, so the ability to hedge one's bets with FEC seems quite worthwhile as an option. On Tue, Dec 17, 2013 at 6:14 PM, Steven McCoy steven.mc...@miru.hk wrote: On 17 December 2013 17:30, Lindley French lindl...@gmail.com wrote: It would be really neat if we could integrate something like http://feclib.sourceforge.net/documentation.html into this. Not sure how that possibility would work license-wise, though. Google's QUIC includes XOR FEC as their studies have shown little requirement for full on Reed Solomon encoding. OpenPGM includes Reed Solomon FEC as studies have shown it dramatically improves performance for large number of receivers. However Microsoft went ahead and implemented an incompatible scheme to everyone else so nothing works out-of-the-box. -- Steve-o ___ 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] When unreliability is desired
We should ignore the encoder classes as they are specific to TCP and hacked for PGM (frame format was the same originally). Each protocol should have its own framing spec and implementation. On Thu, Dec 12, 2013 at 8:04 PM, Steven McCoy steven.mc...@miru.hk wrote: On 7 December 2013 00:34, lindl...@gmail.com wrote: I'll take a look at tipc. I've been using the pgm classes as a reference so far. They appear to use v1_encoder while tcp uses v2_encoder. If you can get a nice clean framework setup independent of the TCP/Unix socket setup I think many others and myself included would like to experiment adding many different types of protocol to 0mq. I have many on my wish list. -- Steve-o ___ 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] When unreliability is desired
On 7 December 2013 00:34, lindl...@gmail.com wrote: I'll take a look at tipc. I've been using the pgm classes as a reference so far. They appear to use v1_encoder while tcp uses v2_encoder. If you can get a nice clean framework setup independent of the TCP/Unix socket setup I think many others and myself included would like to experiment adding many different types of protocol to 0mq. I have many on my wish list. -- Steve-o ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
I've created a JIRA issue: https://zeromq.jira.com/browse/LIBZMQ-589 Next I'll try to figure out how to properly apply C4 to this process. I'm more familiar with gitflow, and while C4 appears to be pretty much the same thing except with forks instead of branches, I'm sure there are subtleties. On Sat, Dec 7, 2013 at 4:23 AM, Arnaud Loonstra arn...@sphaero.org wrote: On 12/07/2013 12:15 AM, Lindley French wrote: Is there a better place for discussion of this effort? I do have a lot of questions. The latest one is about encoder_t etc. This appears to have changed significantly recently, and I'm not entirely sure how to adapt the Crossroads code to match. Is there documentation on its latest design somewhere? No please continue your quest out in the open. I would like to keep track as well. Do you have a repository online somewhere? Arnaud. -- w: http://www.sphaero.org t: http://twitter.com/sphaero g: http://github.com/sphaero i: freenode: sphaero_z25 ___ 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] When unreliability is desired
We have moved the issue tracker to github and you may want to create new issues there. No urgency, it'll be a gradual migration. The process is... not the same as gitflow. The subtleties will become clear to you over time. It's far more aimed at learning, and less at organization, as a goal. -Pieter On Sun, Dec 8, 2013 at 6:34 PM, Lindley French lindl...@gmail.com wrote: I've created a JIRA issue: https://zeromq.jira.com/browse/LIBZMQ-589 Next I'll try to figure out how to properly apply C4 to this process. I'm more familiar with gitflow, and while C4 appears to be pretty much the same thing except with forks instead of branches, I'm sure there are subtleties. On Sat, Dec 7, 2013 at 4:23 AM, Arnaud Loonstra arn...@sphaero.org wrote: On 12/07/2013 12:15 AM, Lindley French wrote: Is there a better place for discussion of this effort? I do have a lot of questions. The latest one is about encoder_t etc. This appears to have changed significantly recently, and I'm not entirely sure how to adapt the Crossroads code to match. Is there documentation on its latest design somewhere? No please continue your quest out in the open. I would like to keep track as well. Do you have a repository online somewhere? Arnaud. -- w: http://www.sphaero.org t: http://twitter.com/sphaero g: http://github.com/sphaero i: freenode: sphaero_z25 ___ 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 mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
I'll recreate the issue there. I can see how C4 could be considered more democratic and less authoritarian than git flow since anyone can fork for stabilization (equivalent to creating a release branch in git flow). I also see how it could be less error-prone to create a feature fork rather than a feature branch. But fundamentally I don't see any significant differences in the two processesboth go from features/bugfixes, to a probably-good-but-unblessed state, to a stabilization (bugfix and testing only) state, to a released state. On Dec 8, 2013, at 2:06 PM, Pieter Hintjens p...@imatix.com wrote: We have moved the issue tracker to github and you may want to create new issues there. No urgency, it'll be a gradual migration. The process is... not the same as gitflow. The subtleties will become clear to you over time. It's far more aimed at learning, and less at organization, as a goal. -Pieter On Sun, Dec 8, 2013 at 6:34 PM, Lindley French lindl...@gmail.com wrote: I've created a JIRA issue: https://zeromq.jira.com/browse/LIBZMQ-589 Next I'll try to figure out how to properly apply C4 to this process. I'm more familiar with gitflow, and while C4 appears to be pretty much the same thing except with forks instead of branches, I'm sure there are subtleties. On Sat, Dec 7, 2013 at 4:23 AM, Arnaud Loonstra arn...@sphaero.org wrote: On 12/07/2013 12:15 AM, Lindley French wrote: Is there a better place for discussion of this effort? I do have a lot of questions. The latest one is about encoder_t etc. This appears to have changed significantly recently, and I'm not entirely sure how to adapt the Crossroads code to match. Is there documentation on its latest design somewhere? No please continue your quest out in the open. I would like to keep track as well. Do you have a repository online somewhere? Arnaud. -- w: http://www.sphaero.org t: http://twitter.com/sphaero g: http://github.com/sphaero i: freenode: sphaero_z25 ___ 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 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] When unreliability is desired
On Sun, Dec 8, 2013 at 10:01 PM, lindl...@gmail.com wrote: I'll recreate the issue there. Sure, we're going to have overlapping trackers for a while (different ranges of issue numbers) so there's no problem. I can see how C4 could be considered more democratic and less authoritarian than git flow since anyone can fork for stabilization (equivalent to creating a release branch in git flow). I also see how it could be less error-prone to create a feature fork rather than a feature branch. But fundamentally I don't see any significant differences in the two processesboth go from features/bugfixes, to a probably-good-but-unblessed state, to a stabilization (bugfix and testing only) state, to a released state. Perhaps we can catch up this thread later when you've used C4 for a while and seen how it works. We for sure use stabilization forks as gitflow uses branches, but that's only a small part of C4. The rest is about reducing barriers to learning, as a group, in a number of small but specific ways. The code emerges as we learn, and is our primary tool for learning more, rather than being the one-way product of educated minds. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
On 12/07/2013 12:15 AM, Lindley French wrote: Is there a better place for discussion of this effort? I do have a lot of questions. The latest one is about encoder_t etc. This appears to have changed significantly recently, and I'm not entirely sure how to adapt the Crossroads code to match. Is there documentation on its latest design somewhere? No please continue your quest out in the open. I would like to keep track as well. Do you have a repository online somewhere? Arnaud. -- w: http://www.sphaero.org t: http://twitter.com/sphaero g: http://github.com/sphaero i: freenode: sphaero_z25 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
Is there a better place for discussion of this effort? I do have a lot of questions. The latest one is about encoder_t etc. This appears to have changed significantly recently, and I'm not entirely sure how to adapt the Crossroads code to match. Is there documentation on its latest design somewhere? On Thu, Dec 5, 2013 at 4:13 PM, Charles Remes li...@chuckremes.com wrote: Feel free to rubber duck with the list as much as you want. :) cr On Dec 5, 2013, at 3:08 PM, Lindley French lindl...@gmail.com wrote: Disregard the question about timers, it appears this was a change made to Crossroads IO after the fork. I found the relevant commit: https://github.com/crossroads-io/libxs/commit/2df873a435ff139cf9d1b10b666d75e6dc6da442#diff-45c9686e09ed422318a2da658745dedd I will revert the code to the 0MQ way of doing things for now. On Thu, Dec 5, 2013 at 3:48 PM, Lindley French lindl...@gmail.com wrote: I'm trying to make sure I understand how the timer_ids work, since these were not in the Crossroads IO code. It appears several classes define timer_id constants as anonymous enums. Furthermore, the values of these constants don't appear to follow any particular pattern, *except* that constants with the same name (same purpose?) are assigned the same value. Therefore, I expect I ought to adopt tx_timer_id and rx_timer_id from pgm_sender without changing their values for udp_sender etc. Am I understanding this correctly? On Thu, Dec 5, 2013 at 3:06 PM, Lindley French lindl...@gmail.comwrote: It appears that at some point, activate_in was renamed to restart_input, and likewise with output. I'm assuming there are no functional changes other than the names in the UDP case. It also appears that zap_msg_available() can be ignored for now. Let me know if I'm wrong about these. On Thu, Dec 5, 2013 at 2:01 PM, Lindley French lindl...@gmail.comwrote: Okay, I'm working on porting the UDP stuff to the latest ZMQ now. Most of the changes necessary are purely a matter of namespace, but there are a few others that seem to reflect design changes in ZMQ since XS was forked. These are the ones I'm not immediately sure how to solve: 1) The XS UDP code references encoder_t and decoder_t, but ZMQ has v1_encoder_t and v2_encoder_t etc instead. 2) i_engine appears to have three pure virtual methods that are not defined in the XS code: restart_input, restart_output, and zap_msg_available(). Any suggestions how to resolve these? On Thu, Dec 5, 2013 at 10:52 AM, Lindley French lindl...@gmail.comwrote: Thanks, I found it. I don't see any reason given as to why UDP support was reverted, though. Are there issues with the code, philosophical objections, etc? On Wed, Dec 4, 2013 at 5:16 PM, Ivan Pechorin ivan.pecho...@gmail.com wrote: UDP support was reverted in libxs just before 1.2.0 release: check the commits history on github around June 13th, 2012. 05.12.2013 6:48 пользователь Lindley French lindl...@gmail.com написал: Can you clarify where in the Crossroads IO library the UDP transport code lives? I've downloaded the 1.2.0 tarball here: http://download.crossroads.io/libxs-1.2.0.tar.gz but so far, I don't see a UDP transport in that code. I also checked the github version: https://github.com/crossroads-io/libxs but I don't see it there either. On Wed, Nov 27, 2013 at 11:26 AM, Charles Remes li...@chuckremes.com wrote: That defunct library (crossroads io) has the code that you want. That lib was a fork of zeromq, so moving the UDP transport from that library to zeromq should be easy (for varying degrees of easy). Once it makes it into zeromq, it will be supported. On Nov 27, 2013, at 9:50 AM, Lindley French lindl...@gmail.com wrote: I've never used ZeroMQ before so writing up a new transport would be just a bit ambitious right now. (I did write something in Java last year that, in retrospect, was solving basically the same problem as ZeroMQ so I have some familiarity with the problem space.) I'm also leery of adopting a defunct library for a new project. I'll keep the udp transport option in mind. On Tue, Nov 26, 2013 at 1:18 PM, Pieter Hintjens p...@imatix.comwrote: Hi Lindley, The right solution would be to make a UDP transport for ZeroMQ. It's not a trivial project but could start with, for instance, just pub/sub (like PGM). It might be worth looking at Crossroads.io for that, which is abandoned but had afair a UDP transport, and shared the same original codebase with ZeroMQ. -Pieter On Tue, Nov 26, 2013 at 6:15 PM, Lindley French lindl...@gmail.com wrote: I have a networking application that I'd like to use ZeroMQ in. However, my use-case demands minimum latency even at the expense of lost messages. I'm weary of using ZeroMQ's TCP transport because if packets are dropped, TCP will block further messages until it has retransmitted the last one, and I don't want that behavior. I don't mind FEC codes
Re: [zeromq-dev] When unreliability is desired
This is the best place for discussions. The encoder classes are for TCP only. If you do try to port the UDP transport, my advice is to do it in many little steps, so we can all get involved. Start with an empty class if needed. The tipc classes in libzmq may be a help. On Sat, Dec 7, 2013 at 12:15 AM, Lindley French lindl...@gmail.com wrote: Is there a better place for discussion of this effort? I do have a lot of questions. The latest one is about encoder_t etc. This appears to have changed significantly recently, and I'm not entirely sure how to adapt the Crossroads code to match. Is there documentation on its latest design somewhere? On Thu, Dec 5, 2013 at 4:13 PM, Charles Remes li...@chuckremes.com wrote: Feel free to rubber duck with the list as much as you want. :) cr On Dec 5, 2013, at 3:08 PM, Lindley French lindl...@gmail.com wrote: Disregard the question about timers, it appears this was a change made to Crossroads IO after the fork. I found the relevant commit: https://github.com/crossroads-io/libxs/commit/2df873a435ff139cf9d1b10b666d75e6dc6da442#diff-45c9686e09ed422318a2da658745dedd I will revert the code to the 0MQ way of doing things for now. On Thu, Dec 5, 2013 at 3:48 PM, Lindley French lindl...@gmail.com wrote: I'm trying to make sure I understand how the timer_ids work, since these were not in the Crossroads IO code. It appears several classes define timer_id constants as anonymous enums. Furthermore, the values of these constants don't appear to follow any particular pattern, *except* that constants with the same name (same purpose?) are assigned the same value. Therefore, I expect I ought to adopt tx_timer_id and rx_timer_id from pgm_sender without changing their values for udp_sender etc. Am I understanding this correctly? On Thu, Dec 5, 2013 at 3:06 PM, Lindley French lindl...@gmail.com wrote: It appears that at some point, activate_in was renamed to restart_input, and likewise with output. I'm assuming there are no functional changes other than the names in the UDP case. It also appears that zap_msg_available() can be ignored for now. Let me know if I'm wrong about these. On Thu, Dec 5, 2013 at 2:01 PM, Lindley French lindl...@gmail.com wrote: Okay, I'm working on porting the UDP stuff to the latest ZMQ now. Most of the changes necessary are purely a matter of namespace, but there are a few others that seem to reflect design changes in ZMQ since XS was forked. These are the ones I'm not immediately sure how to solve: 1) The XS UDP code references encoder_t and decoder_t, but ZMQ has v1_encoder_t and v2_encoder_t etc instead. 2) i_engine appears to have three pure virtual methods that are not defined in the XS code: restart_input, restart_output, and zap_msg_available(). Any suggestions how to resolve these? On Thu, Dec 5, 2013 at 10:52 AM, Lindley French lindl...@gmail.com wrote: Thanks, I found it. I don't see any reason given as to why UDP support was reverted, though. Are there issues with the code, philosophical objections, etc? On Wed, Dec 4, 2013 at 5:16 PM, Ivan Pechorin ivan.pecho...@gmail.com wrote: UDP support was reverted in libxs just before 1.2.0 release: check the commits history on github around June 13th, 2012. 05.12.2013 6:48 пользователь Lindley French lindl...@gmail.com написал: Can you clarify where in the Crossroads IO library the UDP transport code lives? I've downloaded the 1.2.0 tarball here: http://download.crossroads.io/libxs-1.2.0.tar.gz but so far, I don't see a UDP transport in that code. I also checked the github version: https://github.com/crossroads-io/libxs but I don't see it there either. On Wed, Nov 27, 2013 at 11:26 AM, Charles Remes li...@chuckremes.com wrote: That defunct library (crossroads io) has the code that you want. That lib was a fork of zeromq, so moving the UDP transport from that library to zeromq should be easy (for varying degrees of easy). Once it makes it into zeromq, it will be supported. On Nov 27, 2013, at 9:50 AM, Lindley French lindl...@gmail.com wrote: I've never used ZeroMQ before so writing up a new transport would be just a bit ambitious right now. (I did write something in Java last year that, in retrospect, was solving basically the same problem as ZeroMQ so I have some familiarity with the problem space.) I'm also leery of adopting a defunct library for a new project. I'll keep the udp transport option in mind. On Tue, Nov 26, 2013 at 1:18 PM, Pieter Hintjens p...@imatix.com wrote: Hi Lindley, The right solution would be to make a UDP transport for ZeroMQ. It's not a trivial project but could start with, for instance, just pub/sub (like PGM). It might be worth looking at Crossroads.io for that, which is abandoned but had afair a UDP transport, and shared the same original codebase with ZeroMQ. -Pieter On Tue, Nov 26, 2013 at 6:15 PM, Lindley French lindl...@gmail.com wrote: I
Re: [zeromq-dev] When unreliability is desired
I'll take a look at tipc. I've been using the pgm classes as a reference so far. They appear to use v1_encoder while tcp uses v2_encoder. Sent from my iPhone On Dec 6, 2013, at 6:37 PM, Pieter Hintjens p...@imatix.com wrote: This is the best place for discussions. The encoder classes are for TCP only. If you do try to port the UDP transport, my advice is to do it in many little steps, so we can all get involved. Start with an empty class if needed. The tipc classes in libzmq may be a help. On Sat, Dec 7, 2013 at 12:15 AM, Lindley French lindl...@gmail.com wrote: Is there a better place for discussion of this effort? I do have a lot of questions. The latest one is about encoder_t etc. This appears to have changed significantly recently, and I'm not entirely sure how to adapt the Crossroads code to match. Is there documentation on its latest design somewhere? On Thu, Dec 5, 2013 at 4:13 PM, Charles Remes li...@chuckremes.com wrote: Feel free to rubber duck with the list as much as you want. :) cr On Dec 5, 2013, at 3:08 PM, Lindley French lindl...@gmail.com wrote: Disregard the question about timers, it appears this was a change made to Crossroads IO after the fork. I found the relevant commit: https://github.com/crossroads-io/libxs/commit/2df873a435ff139cf9d1b10b666d75e6dc6da442#diff-45c9686e09ed422318a2da658745dedd I will revert the code to the 0MQ way of doing things for now. On Thu, Dec 5, 2013 at 3:48 PM, Lindley French lindl...@gmail.com wrote: I'm trying to make sure I understand how the timer_ids work, since these were not in the Crossroads IO code. It appears several classes define timer_id constants as anonymous enums. Furthermore, the values of these constants don't appear to follow any particular pattern, *except* that constants with the same name (same purpose?) are assigned the same value. Therefore, I expect I ought to adopt tx_timer_id and rx_timer_id from pgm_sender without changing their values for udp_sender etc. Am I understanding this correctly? On Thu, Dec 5, 2013 at 3:06 PM, Lindley French lindl...@gmail.com wrote: It appears that at some point, activate_in was renamed to restart_input, and likewise with output. I'm assuming there are no functional changes other than the names in the UDP case. It also appears that zap_msg_available() can be ignored for now. Let me know if I'm wrong about these. On Thu, Dec 5, 2013 at 2:01 PM, Lindley French lindl...@gmail.com wrote: Okay, I'm working on porting the UDP stuff to the latest ZMQ now. Most of the changes necessary are purely a matter of namespace, but there are a few others that seem to reflect design changes in ZMQ since XS was forked. These are the ones I'm not immediately sure how to solve: 1) The XS UDP code references encoder_t and decoder_t, but ZMQ has v1_encoder_t and v2_encoder_t etc instead. 2) i_engine appears to have three pure virtual methods that are not defined in the XS code: restart_input, restart_output, and zap_msg_available(). Any suggestions how to resolve these? On Thu, Dec 5, 2013 at 10:52 AM, Lindley French lindl...@gmail.com wrote: Thanks, I found it. I don't see any reason given as to why UDP support was reverted, though. Are there issues with the code, philosophical objections, etc? On Wed, Dec 4, 2013 at 5:16 PM, Ivan Pechorin ivan.pecho...@gmail.com wrote: UDP support was reverted in libxs just before 1.2.0 release: check the commits history on github around June 13th, 2012. 05.12.2013 6:48 пользователь Lindley French lindl...@gmail.com написал: Can you clarify where in the Crossroads IO library the UDP transport code lives? I've downloaded the 1.2.0 tarball here: http://download.crossroads.io/libxs-1.2.0.tar.gz but so far, I don't see a UDP transport in that code. I also checked the github version: https://github.com/crossroads-io/libxs but I don't see it there either. On Wed, Nov 27, 2013 at 11:26 AM, Charles Remes li...@chuckremes.com wrote: That defunct library (crossroads io) has the code that you want. That lib was a fork of zeromq, so moving the UDP transport from that library to zeromq should be easy (for varying degrees of easy). Once it makes it into zeromq, it will be supported. On Nov 27, 2013, at 9:50 AM, Lindley French lindl...@gmail.com wrote: I've never used ZeroMQ before so writing up a new transport would be just a bit ambitious right now. (I did write something in Java last year that, in retrospect, was solving basically the same problem as ZeroMQ so I have some familiarity with the problem space.) I'm also leery of adopting a defunct library for a new project. I'll keep the udp transport option in mind. On Tue, Nov 26, 2013 at 1:18 PM, Pieter Hintjens p...@imatix.com wrote: Hi Lindley, The right solution would be to make a UDP transport for ZeroMQ. It's not a trivial project but could start with, for instance,
Re: [zeromq-dev] When unreliability is desired
Thanks, I found it. I don't see any reason given as to why UDP support was reverted, though. Are there issues with the code, philosophical objections, etc? On Wed, Dec 4, 2013 at 5:16 PM, Ivan Pechorin ivan.pecho...@gmail.comwrote: UDP support was reverted in libxs just before 1.2.0 release: check the commits history on github around June 13th, 2012. 05.12.2013 6:48 пользователь Lindley French lindl...@gmail.com написал: Can you clarify where in the Crossroads IO library the UDP transport code lives? I've downloaded the 1.2.0 tarball here: http://download.crossroads.io/libxs-1.2.0.tar.gz but so far, I don't see a UDP transport in that code. I also checked the github version: https://github.com/crossroads-io/libxs but I don't see it there either. On Wed, Nov 27, 2013 at 11:26 AM, Charles Remes li...@chuckremes.comwrote: That defunct library (crossroads io) has the code that you want. That lib was a fork of zeromq, so moving the UDP transport from that library to zeromq should be easy (for varying degrees of easy). Once it makes it into zeromq, it will be supported. On Nov 27, 2013, at 9:50 AM, Lindley French lindl...@gmail.com wrote: I've never used ZeroMQ before so writing up a new transport would be just a bit ambitious right now. (I did write something in Java last year that, in retrospect, was solving basically the same problem as ZeroMQ so I have some familiarity with the problem space.) I'm also leery of adopting a defunct library for a new project. I'll keep the udp transport option in mind. On Tue, Nov 26, 2013 at 1:18 PM, Pieter Hintjens p...@imatix.com wrote: Hi Lindley, The right solution would be to make a UDP transport for ZeroMQ. It's not a trivial project but could start with, for instance, just pub/sub (like PGM). It might be worth looking at Crossroads.io for that, which is abandoned but had afair a UDP transport, and shared the same original codebase with ZeroMQ. -Pieter On Tue, Nov 26, 2013 at 6:15 PM, Lindley French lindl...@gmail.com wrote: I have a networking application that I'd like to use ZeroMQ in. However, my use-case demands minimum latency even at the expense of lost messages. I'm weary of using ZeroMQ's TCP transport because if packets are dropped, TCP will block further messages until it has retransmitted the last one, and I don't want that behavior. I don't mind FEC codes or other strategies to improve reliability by sending more data up-front, but I do not need complete reliability and I want to avoid retransmission of messages, or at the least avoid blocking later messages if earlier ones need to be retransmitted. Is there an existing ZeroMQ transport that will provide the behavior I want? I was thinking maybe epgm would do the trick, even though I don't really need multicast. Ideally, I'd want a transport that uses pure UDP for messages, perhaps with some TCP behind the scenes for out-of-band handshaking. I may end up just using UDP myself for the time-critical messages, and ZeroMQ for less critical data, but I'd prefer to avoid multiple-API creep. ___ 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 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 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 mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
It appears that at some point, activate_in was renamed to restart_input, and likewise with output. I'm assuming there are no functional changes other than the names in the UDP case. It also appears that zap_msg_available() can be ignored for now. Let me know if I'm wrong about these. On Thu, Dec 5, 2013 at 2:01 PM, Lindley French lindl...@gmail.com wrote: Okay, I'm working on porting the UDP stuff to the latest ZMQ now. Most of the changes necessary are purely a matter of namespace, but there are a few others that seem to reflect design changes in ZMQ since XS was forked. These are the ones I'm not immediately sure how to solve: 1) The XS UDP code references encoder_t and decoder_t, but ZMQ has v1_encoder_t and v2_encoder_t etc instead. 2) i_engine appears to have three pure virtual methods that are not defined in the XS code: restart_input, restart_output, and zap_msg_available(). Any suggestions how to resolve these? On Thu, Dec 5, 2013 at 10:52 AM, Lindley French lindl...@gmail.comwrote: Thanks, I found it. I don't see any reason given as to why UDP support was reverted, though. Are there issues with the code, philosophical objections, etc? On Wed, Dec 4, 2013 at 5:16 PM, Ivan Pechorin ivan.pecho...@gmail.comwrote: UDP support was reverted in libxs just before 1.2.0 release: check the commits history on github around June 13th, 2012. 05.12.2013 6:48 пользователь Lindley French lindl...@gmail.com написал: Can you clarify where in the Crossroads IO library the UDP transport code lives? I've downloaded the 1.2.0 tarball here: http://download.crossroads.io/libxs-1.2.0.tar.gz but so far, I don't see a UDP transport in that code. I also checked the github version: https://github.com/crossroads-io/libxs but I don't see it there either. On Wed, Nov 27, 2013 at 11:26 AM, Charles Remes li...@chuckremes.comwrote: That defunct library (crossroads io) has the code that you want. That lib was a fork of zeromq, so moving the UDP transport from that library to zeromq should be easy (for varying degrees of easy). Once it makes it into zeromq, it will be supported. On Nov 27, 2013, at 9:50 AM, Lindley French lindl...@gmail.com wrote: I've never used ZeroMQ before so writing up a new transport would be just a bit ambitious right now. (I did write something in Java last year that, in retrospect, was solving basically the same problem as ZeroMQ so I have some familiarity with the problem space.) I'm also leery of adopting a defunct library for a new project. I'll keep the udp transport option in mind. On Tue, Nov 26, 2013 at 1:18 PM, Pieter Hintjens p...@imatix.comwrote: Hi Lindley, The right solution would be to make a UDP transport for ZeroMQ. It's not a trivial project but could start with, for instance, just pub/sub (like PGM). It might be worth looking at Crossroads.io for that, which is abandoned but had afair a UDP transport, and shared the same original codebase with ZeroMQ. -Pieter On Tue, Nov 26, 2013 at 6:15 PM, Lindley French lindl...@gmail.com wrote: I have a networking application that I'd like to use ZeroMQ in. However, my use-case demands minimum latency even at the expense of lost messages. I'm weary of using ZeroMQ's TCP transport because if packets are dropped, TCP will block further messages until it has retransmitted the last one, and I don't want that behavior. I don't mind FEC codes or other strategies to improve reliability by sending more data up-front, but I do not need complete reliability and I want to avoid retransmission of messages, or at the least avoid blocking later messages if earlier ones need to be retransmitted. Is there an existing ZeroMQ transport that will provide the behavior I want? I was thinking maybe epgm would do the trick, even though I don't really need multicast. Ideally, I'd want a transport that uses pure UDP for messages, perhaps with some TCP behind the scenes for out-of-band handshaking. I may end up just using UDP myself for the time-critical messages, and ZeroMQ for less critical data, but I'd prefer to avoid multiple-API creep. ___ 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 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 mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
I'm trying to make sure I understand how the timer_ids work, since these were not in the Crossroads IO code. It appears several classes define timer_id constants as anonymous enums. Furthermore, the values of these constants don't appear to follow any particular pattern, *except* that constants with the same name (same purpose?) are assigned the same value. Therefore, I expect I ought to adopt tx_timer_id and rx_timer_id from pgm_sender without changing their values for udp_sender etc. Am I understanding this correctly? On Thu, Dec 5, 2013 at 3:06 PM, Lindley French lindl...@gmail.com wrote: It appears that at some point, activate_in was renamed to restart_input, and likewise with output. I'm assuming there are no functional changes other than the names in the UDP case. It also appears that zap_msg_available() can be ignored for now. Let me know if I'm wrong about these. On Thu, Dec 5, 2013 at 2:01 PM, Lindley French lindl...@gmail.com wrote: Okay, I'm working on porting the UDP stuff to the latest ZMQ now. Most of the changes necessary are purely a matter of namespace, but there are a few others that seem to reflect design changes in ZMQ since XS was forked. These are the ones I'm not immediately sure how to solve: 1) The XS UDP code references encoder_t and decoder_t, but ZMQ has v1_encoder_t and v2_encoder_t etc instead. 2) i_engine appears to have three pure virtual methods that are not defined in the XS code: restart_input, restart_output, and zap_msg_available(). Any suggestions how to resolve these? On Thu, Dec 5, 2013 at 10:52 AM, Lindley French lindl...@gmail.comwrote: Thanks, I found it. I don't see any reason given as to why UDP support was reverted, though. Are there issues with the code, philosophical objections, etc? On Wed, Dec 4, 2013 at 5:16 PM, Ivan Pechorin ivan.pecho...@gmail.comwrote: UDP support was reverted in libxs just before 1.2.0 release: check the commits history on github around June 13th, 2012. 05.12.2013 6:48 пользователь Lindley French lindl...@gmail.com написал: Can you clarify where in the Crossroads IO library the UDP transport code lives? I've downloaded the 1.2.0 tarball here: http://download.crossroads.io/libxs-1.2.0.tar.gz but so far, I don't see a UDP transport in that code. I also checked the github version: https://github.com/crossroads-io/libxs but I don't see it there either. On Wed, Nov 27, 2013 at 11:26 AM, Charles Remes li...@chuckremes.comwrote: That defunct library (crossroads io) has the code that you want. That lib was a fork of zeromq, so moving the UDP transport from that library to zeromq should be easy (for varying degrees of easy). Once it makes it into zeromq, it will be supported. On Nov 27, 2013, at 9:50 AM, Lindley French lindl...@gmail.com wrote: I've never used ZeroMQ before so writing up a new transport would be just a bit ambitious right now. (I did write something in Java last year that, in retrospect, was solving basically the same problem as ZeroMQ so I have some familiarity with the problem space.) I'm also leery of adopting a defunct library for a new project. I'll keep the udp transport option in mind. On Tue, Nov 26, 2013 at 1:18 PM, Pieter Hintjens p...@imatix.comwrote: Hi Lindley, The right solution would be to make a UDP transport for ZeroMQ. It's not a trivial project but could start with, for instance, just pub/sub (like PGM). It might be worth looking at Crossroads.io for that, which is abandoned but had afair a UDP transport, and shared the same original codebase with ZeroMQ. -Pieter On Tue, Nov 26, 2013 at 6:15 PM, Lindley French lindl...@gmail.com wrote: I have a networking application that I'd like to use ZeroMQ in. However, my use-case demands minimum latency even at the expense of lost messages. I'm weary of using ZeroMQ's TCP transport because if packets are dropped, TCP will block further messages until it has retransmitted the last one, and I don't want that behavior. I don't mind FEC codes or other strategies to improve reliability by sending more data up-front, but I do not need complete reliability and I want to avoid retransmission of messages, or at the least avoid blocking later messages if earlier ones need to be retransmitted. Is there an existing ZeroMQ transport that will provide the behavior I want? I was thinking maybe epgm would do the trick, even though I don't really need multicast. Ideally, I'd want a transport that uses pure UDP for messages, perhaps with some TCP behind the scenes for out-of-band handshaking. I may end up just using UDP myself for the time-critical messages, and ZeroMQ for less critical data, but I'd prefer to avoid multiple-API creep. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
Disregard the question about timers, it appears this was a change made to Crossroads IO after the fork. I found the relevant commit: https://github.com/crossroads-io/libxs/commit/2df873a435ff139cf9d1b10b666d75e6dc6da442#diff-45c9686e09ed422318a2da658745dedd I will revert the code to the 0MQ way of doing things for now. On Thu, Dec 5, 2013 at 3:48 PM, Lindley French lindl...@gmail.com wrote: I'm trying to make sure I understand how the timer_ids work, since these were not in the Crossroads IO code. It appears several classes define timer_id constants as anonymous enums. Furthermore, the values of these constants don't appear to follow any particular pattern, *except* that constants with the same name (same purpose?) are assigned the same value. Therefore, I expect I ought to adopt tx_timer_id and rx_timer_id from pgm_sender without changing their values for udp_sender etc. Am I understanding this correctly? On Thu, Dec 5, 2013 at 3:06 PM, Lindley French lindl...@gmail.com wrote: It appears that at some point, activate_in was renamed to restart_input, and likewise with output. I'm assuming there are no functional changes other than the names in the UDP case. It also appears that zap_msg_available() can be ignored for now. Let me know if I'm wrong about these. On Thu, Dec 5, 2013 at 2:01 PM, Lindley French lindl...@gmail.comwrote: Okay, I'm working on porting the UDP stuff to the latest ZMQ now. Most of the changes necessary are purely a matter of namespace, but there are a few others that seem to reflect design changes in ZMQ since XS was forked. These are the ones I'm not immediately sure how to solve: 1) The XS UDP code references encoder_t and decoder_t, but ZMQ has v1_encoder_t and v2_encoder_t etc instead. 2) i_engine appears to have three pure virtual methods that are not defined in the XS code: restart_input, restart_output, and zap_msg_available(). Any suggestions how to resolve these? On Thu, Dec 5, 2013 at 10:52 AM, Lindley French lindl...@gmail.comwrote: Thanks, I found it. I don't see any reason given as to why UDP support was reverted, though. Are there issues with the code, philosophical objections, etc? On Wed, Dec 4, 2013 at 5:16 PM, Ivan Pechorin ivan.pecho...@gmail.comwrote: UDP support was reverted in libxs just before 1.2.0 release: check the commits history on github around June 13th, 2012. 05.12.2013 6:48 пользователь Lindley French lindl...@gmail.com написал: Can you clarify where in the Crossroads IO library the UDP transport code lives? I've downloaded the 1.2.0 tarball here: http://download.crossroads.io/libxs-1.2.0.tar.gz but so far, I don't see a UDP transport in that code. I also checked the github version: https://github.com/crossroads-io/libxs but I don't see it there either. On Wed, Nov 27, 2013 at 11:26 AM, Charles Remes li...@chuckremes.com wrote: That defunct library (crossroads io) has the code that you want. That lib was a fork of zeromq, so moving the UDP transport from that library to zeromq should be easy (for varying degrees of easy). Once it makes it into zeromq, it will be supported. On Nov 27, 2013, at 9:50 AM, Lindley French lindl...@gmail.com wrote: I've never used ZeroMQ before so writing up a new transport would be just a bit ambitious right now. (I did write something in Java last year that, in retrospect, was solving basically the same problem as ZeroMQ so I have some familiarity with the problem space.) I'm also leery of adopting a defunct library for a new project. I'll keep the udp transport option in mind. On Tue, Nov 26, 2013 at 1:18 PM, Pieter Hintjens p...@imatix.comwrote: Hi Lindley, The right solution would be to make a UDP transport for ZeroMQ. It's not a trivial project but could start with, for instance, just pub/sub (like PGM). It might be worth looking at Crossroads.io for that, which is abandoned but had afair a UDP transport, and shared the same original codebase with ZeroMQ. -Pieter On Tue, Nov 26, 2013 at 6:15 PM, Lindley French lindl...@gmail.com wrote: I have a networking application that I'd like to use ZeroMQ in. However, my use-case demands minimum latency even at the expense of lost messages. I'm weary of using ZeroMQ's TCP transport because if packets are dropped, TCP will block further messages until it has retransmitted the last one, and I don't want that behavior. I don't mind FEC codes or other strategies to improve reliability by sending more data up-front, but I do not need complete reliability and I want to avoid retransmission of messages, or at the least avoid blocking later messages if earlier ones need to be retransmitted. Is there an existing ZeroMQ transport that will provide the behavior I want? I was thinking maybe epgm would do the trick, even though I don't really need multicast. Ideally, I'd want a transport that uses pure UDP for messages, perhaps with some TCP behind the
Re: [zeromq-dev] When unreliability is desired
Feel free to rubber duck with the list as much as you want. :) cr On Dec 5, 2013, at 3:08 PM, Lindley French lindl...@gmail.com wrote: Disregard the question about timers, it appears this was a change made to Crossroads IO after the fork. I found the relevant commit: https://github.com/crossroads-io/libxs/commit/2df873a435ff139cf9d1b10b666d75e6dc6da442#diff-45c9686e09ed422318a2da658745dedd I will revert the code to the 0MQ way of doing things for now. On Thu, Dec 5, 2013 at 3:48 PM, Lindley French lindl...@gmail.com wrote: I'm trying to make sure I understand how the timer_ids work, since these were not in the Crossroads IO code. It appears several classes define timer_id constants as anonymous enums. Furthermore, the values of these constants don't appear to follow any particular pattern, *except* that constants with the same name (same purpose?) are assigned the same value. Therefore, I expect I ought to adopt tx_timer_id and rx_timer_id from pgm_sender without changing their values for udp_sender etc. Am I understanding this correctly? On Thu, Dec 5, 2013 at 3:06 PM, Lindley French lindl...@gmail.com wrote: It appears that at some point, activate_in was renamed to restart_input, and likewise with output. I'm assuming there are no functional changes other than the names in the UDP case. It also appears that zap_msg_available() can be ignored for now. Let me know if I'm wrong about these. On Thu, Dec 5, 2013 at 2:01 PM, Lindley French lindl...@gmail.com wrote: Okay, I'm working on porting the UDP stuff to the latest ZMQ now. Most of the changes necessary are purely a matter of namespace, but there are a few others that seem to reflect design changes in ZMQ since XS was forked. These are the ones I'm not immediately sure how to solve: 1) The XS UDP code references encoder_t and decoder_t, but ZMQ has v1_encoder_t and v2_encoder_t etc instead. 2) i_engine appears to have three pure virtual methods that are not defined in the XS code: restart_input, restart_output, and zap_msg_available(). Any suggestions how to resolve these? On Thu, Dec 5, 2013 at 10:52 AM, Lindley French lindl...@gmail.com wrote: Thanks, I found it. I don't see any reason given as to why UDP support was reverted, though. Are there issues with the code, philosophical objections, etc? On Wed, Dec 4, 2013 at 5:16 PM, Ivan Pechorin ivan.pecho...@gmail.com wrote: UDP support was reverted in libxs just before 1.2.0 release: check the commits history on github around June 13th, 2012. 05.12.2013 6:48 пользователь Lindley French lindl...@gmail.com написал: Can you clarify where in the Crossroads IO library the UDP transport code lives? I've downloaded the 1.2.0 tarball here: http://download.crossroads.io/libxs-1.2.0.tar.gz but so far, I don't see a UDP transport in that code. I also checked the github version: https://github.com/crossroads-io/libxs but I don't see it there either. On Wed, Nov 27, 2013 at 11:26 AM, Charles Remes li...@chuckremes.com wrote: That defunct library (crossroads io) has the code that you want. That lib was a fork of zeromq, so moving the UDP transport from that library to zeromq should be easy (for varying degrees of easy). Once it makes it into zeromq, it will be supported. On Nov 27, 2013, at 9:50 AM, Lindley French lindl...@gmail.com wrote: I've never used ZeroMQ before so writing up a new transport would be just a bit ambitious right now. (I did write something in Java last year that, in retrospect, was solving basically the same problem as ZeroMQ so I have some familiarity with the problem space.) I'm also leery of adopting a defunct library for a new project. I'll keep the udp transport option in mind. On Tue, Nov 26, 2013 at 1:18 PM, Pieter Hintjens p...@imatix.com wrote: Hi Lindley, The right solution would be to make a UDP transport for ZeroMQ. It's not a trivial project but could start with, for instance, just pub/sub (like PGM). It might be worth looking at Crossroads.io for that, which is abandoned but had afair a UDP transport, and shared the same original codebase with ZeroMQ. -Pieter On Tue, Nov 26, 2013 at 6:15 PM, Lindley French lindl...@gmail.com wrote: I have a networking application that I'd like to use ZeroMQ in. However, my use-case demands minimum latency even at the expense of lost messages. I'm weary of using ZeroMQ's TCP transport because if packets are dropped, TCP will block further messages until it has retransmitted the last one, and I don't want that behavior. I don't mind FEC codes or other strategies to improve reliability by sending more data up-front, but I do not need complete reliability and I want to avoid retransmission of messages, or at the least avoid blocking later messages if earlier ones need to be retransmitted. Is there an existing ZeroMQ transport that will provide the behavior I want? I was thinking
Re: [zeromq-dev] When unreliability is desired
Can you clarify where in the Crossroads IO library the UDP transport code lives? I've downloaded the 1.2.0 tarball here: http://download.crossroads.io/libxs-1.2.0.tar.gz but so far, I don't see a UDP transport in that code. I also checked the github version: https://github.com/crossroads-io/libxs but I don't see it there either. On Wed, Nov 27, 2013 at 11:26 AM, Charles Remes li...@chuckremes.comwrote: That defunct library (crossroads io) has the code that you want. That lib was a fork of zeromq, so moving the UDP transport from that library to zeromq should be easy (for varying degrees of easy). Once it makes it into zeromq, it will be supported. On Nov 27, 2013, at 9:50 AM, Lindley French lindl...@gmail.com wrote: I've never used ZeroMQ before so writing up a new transport would be just a bit ambitious right now. (I did write something in Java last year that, in retrospect, was solving basically the same problem as ZeroMQ so I have some familiarity with the problem space.) I'm also leery of adopting a defunct library for a new project. I'll keep the udp transport option in mind. On Tue, Nov 26, 2013 at 1:18 PM, Pieter Hintjens p...@imatix.com wrote: Hi Lindley, The right solution would be to make a UDP transport for ZeroMQ. It's not a trivial project but could start with, for instance, just pub/sub (like PGM). It might be worth looking at Crossroads.io for that, which is abandoned but had afair a UDP transport, and shared the same original codebase with ZeroMQ. -Pieter On Tue, Nov 26, 2013 at 6:15 PM, Lindley French lindl...@gmail.com wrote: I have a networking application that I'd like to use ZeroMQ in. However, my use-case demands minimum latency even at the expense of lost messages. I'm weary of using ZeroMQ's TCP transport because if packets are dropped, TCP will block further messages until it has retransmitted the last one, and I don't want that behavior. I don't mind FEC codes or other strategies to improve reliability by sending more data up-front, but I do not need complete reliability and I want to avoid retransmission of messages, or at the least avoid blocking later messages if earlier ones need to be retransmitted. Is there an existing ZeroMQ transport that will provide the behavior I want? I was thinking maybe epgm would do the trick, even though I don't really need multicast. Ideally, I'd want a transport that uses pure UDP for messages, perhaps with some TCP behind the scenes for out-of-band handshaking. I may end up just using UDP myself for the time-critical messages, and ZeroMQ for less critical data, but I'd prefer to avoid multiple-API creep. ___ 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 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 mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
UDP support was reverted in libxs just before 1.2.0 release: check the commits history on github around June 13th, 2012. 05.12.2013 6:48 пользователь Lindley French lindl...@gmail.com написал: Can you clarify where in the Crossroads IO library the UDP transport code lives? I've downloaded the 1.2.0 tarball here: http://download.crossroads.io/libxs-1.2.0.tar.gz but so far, I don't see a UDP transport in that code. I also checked the github version: https://github.com/crossroads-io/libxs but I don't see it there either. On Wed, Nov 27, 2013 at 11:26 AM, Charles Remes li...@chuckremes.comwrote: That defunct library (crossroads io) has the code that you want. That lib was a fork of zeromq, so moving the UDP transport from that library to zeromq should be easy (for varying degrees of easy). Once it makes it into zeromq, it will be supported. On Nov 27, 2013, at 9:50 AM, Lindley French lindl...@gmail.com wrote: I've never used ZeroMQ before so writing up a new transport would be just a bit ambitious right now. (I did write something in Java last year that, in retrospect, was solving basically the same problem as ZeroMQ so I have some familiarity with the problem space.) I'm also leery of adopting a defunct library for a new project. I'll keep the udp transport option in mind. On Tue, Nov 26, 2013 at 1:18 PM, Pieter Hintjens p...@imatix.com wrote: Hi Lindley, The right solution would be to make a UDP transport for ZeroMQ. It's not a trivial project but could start with, for instance, just pub/sub (like PGM). It might be worth looking at Crossroads.io for that, which is abandoned but had afair a UDP transport, and shared the same original codebase with ZeroMQ. -Pieter On Tue, Nov 26, 2013 at 6:15 PM, Lindley French lindl...@gmail.com wrote: I have a networking application that I'd like to use ZeroMQ in. However, my use-case demands minimum latency even at the expense of lost messages. I'm weary of using ZeroMQ's TCP transport because if packets are dropped, TCP will block further messages until it has retransmitted the last one, and I don't want that behavior. I don't mind FEC codes or other strategies to improve reliability by sending more data up-front, but I do not need complete reliability and I want to avoid retransmission of messages, or at the least avoid blocking later messages if earlier ones need to be retransmitted. Is there an existing ZeroMQ transport that will provide the behavior I want? I was thinking maybe epgm would do the trick, even though I don't really need multicast. Ideally, I'd want a transport that uses pure UDP for messages, perhaps with some TCP behind the scenes for out-of-band handshaking. I may end up just using UDP myself for the time-critical messages, and ZeroMQ for less critical data, but I'd prefer to avoid multiple-API creep. ___ 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 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 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] When unreliability is desired
I've never used ZeroMQ before so writing up a new transport would be just a bit ambitious right now. (I did write something in Java last year that, in retrospect, was solving basically the same problem as ZeroMQ so I have some familiarity with the problem space.) I'm also leery of adopting a defunct library for a new project. I'll keep the udp transport option in mind. On Tue, Nov 26, 2013 at 1:18 PM, Pieter Hintjens p...@imatix.com wrote: Hi Lindley, The right solution would be to make a UDP transport for ZeroMQ. It's not a trivial project but could start with, for instance, just pub/sub (like PGM). It might be worth looking at Crossroads.io for that, which is abandoned but had afair a UDP transport, and shared the same original codebase with ZeroMQ. -Pieter On Tue, Nov 26, 2013 at 6:15 PM, Lindley French lindl...@gmail.com wrote: I have a networking application that I'd like to use ZeroMQ in. However, my use-case demands minimum latency even at the expense of lost messages. I'm weary of using ZeroMQ's TCP transport because if packets are dropped, TCP will block further messages until it has retransmitted the last one, and I don't want that behavior. I don't mind FEC codes or other strategies to improve reliability by sending more data up-front, but I do not need complete reliability and I want to avoid retransmission of messages, or at the least avoid blocking later messages if earlier ones need to be retransmitted. Is there an existing ZeroMQ transport that will provide the behavior I want? I was thinking maybe epgm would do the trick, even though I don't really need multicast. Ideally, I'd want a transport that uses pure UDP for messages, perhaps with some TCP behind the scenes for out-of-band handshaking. I may end up just using UDP myself for the time-critical messages, and ZeroMQ for less critical data, but I'd prefer to avoid multiple-API creep. ___ 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 mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
On 11/27/2013 04:50 PM, Lindley French wrote: I've never used ZeroMQ before so writing up a new transport would be just a bit ambitious right now. (I did write something in Java last year that, in retrospect, was solving basically the same problem as ZeroMQ so I have some familiarity with the problem space.) I'm also leery of adopting a defunct library for a new project. I'll keep the udp transport option in mind. I'm also very interested in an udp transport for the exact same reasons. I would be writing such transport if I had time and/or resources to do so. It shouldn't be too hard I guess. How much would it take? Could anybody elaborate on that? Arnaud. -- w: http://www.sphaero.org t: http://twitter.com/sphaero g: http://github.com/sphaero i: freenode: sphaero_z25 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
That defunct library (crossroads io) has the code that you want. That lib was a fork of zeromq, so moving the UDP transport from that library to zeromq should be easy (for varying degrees of easy). Once it makes it into zeromq, it will be supported. On Nov 27, 2013, at 9:50 AM, Lindley French lindl...@gmail.com wrote: I've never used ZeroMQ before so writing up a new transport would be just a bit ambitious right now. (I did write something in Java last year that, in retrospect, was solving basically the same problem as ZeroMQ so I have some familiarity with the problem space.) I'm also leery of adopting a defunct library for a new project. I'll keep the udp transport option in mind. On Tue, Nov 26, 2013 at 1:18 PM, Pieter Hintjens p...@imatix.com wrote: Hi Lindley, The right solution would be to make a UDP transport for ZeroMQ. It's not a trivial project but could start with, for instance, just pub/sub (like PGM). It might be worth looking at Crossroads.io for that, which is abandoned but had afair a UDP transport, and shared the same original codebase with ZeroMQ. -Pieter On Tue, Nov 26, 2013 at 6:15 PM, Lindley French lindl...@gmail.com wrote: I have a networking application that I'd like to use ZeroMQ in. However, my use-case demands minimum latency even at the expense of lost messages. I'm weary of using ZeroMQ's TCP transport because if packets are dropped, TCP will block further messages until it has retransmitted the last one, and I don't want that behavior. I don't mind FEC codes or other strategies to improve reliability by sending more data up-front, but I do not need complete reliability and I want to avoid retransmission of messages, or at the least avoid blocking later messages if earlier ones need to be retransmitted. Is there an existing ZeroMQ transport that will provide the behavior I want? I was thinking maybe epgm would do the trick, even though I don't really need multicast. Ideally, I'd want a transport that uses pure UDP for messages, perhaps with some TCP behind the scenes for out-of-band handshaking. I may end up just using UDP myself for the time-critical messages, and ZeroMQ for less critical data, but I'd prefer to avoid multiple-API creep. ___ 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 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] When unreliability is desired
On Wed, Nov 27, 2013 at 5:26 PM, Charles Remes li...@chuckremes.com wrote: That defunct library (crossroads io) has the code that you want. That lib was a fork of zeromq, so moving the UDP transport from that library to zeromq should be easy (for varying degrees of easy). Once it makes it into zeromq, it will be supported. Indeed... the code should be rapidly usable. License compatible. I'll help once/if the code is ported; it'll need documentation and protocol specs. A UDP transport would be... awesome! -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] When unreliability is desired
I have a networking application that I'd like to use ZeroMQ in. However, my use-case demands minimum latency even at the expense of lost messages. I'm weary of using ZeroMQ's TCP transport because if packets are dropped, TCP will block further messages until it has retransmitted the last one, and I don't want that behavior. I don't mind FEC codes or other strategies to improve reliability by sending more data up-front, but I do not need complete reliability and I want to avoid retransmission of messages, or at the least avoid blocking later messages if earlier ones need to be retransmitted. Is there an existing ZeroMQ transport that will provide the behavior I want? I was thinking maybe epgm would do the trick, even though I don't really need multicast. Ideally, I'd want a transport that uses pure UDP for messages, perhaps with some TCP behind the scenes for out-of-band handshaking. I may end up just using UDP myself for the time-critical messages, and ZeroMQ for less critical data, but I'd prefer to avoid multiple-API creep. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] When unreliability is desired
Hi Lindley, The right solution would be to make a UDP transport for ZeroMQ. It's not a trivial project but could start with, for instance, just pub/sub (like PGM). It might be worth looking at Crossroads.io for that, which is abandoned but had afair a UDP transport, and shared the same original codebase with ZeroMQ. -Pieter On Tue, Nov 26, 2013 at 6:15 PM, Lindley French lindl...@gmail.com wrote: I have a networking application that I'd like to use ZeroMQ in. However, my use-case demands minimum latency even at the expense of lost messages. I'm weary of using ZeroMQ's TCP transport because if packets are dropped, TCP will block further messages until it has retransmitted the last one, and I don't want that behavior. I don't mind FEC codes or other strategies to improve reliability by sending more data up-front, but I do not need complete reliability and I want to avoid retransmission of messages, or at the least avoid blocking later messages if earlier ones need to be retransmitted. Is there an existing ZeroMQ transport that will provide the behavior I want? I was thinking maybe epgm would do the trick, even though I don't really need multicast. Ideally, I'd want a transport that uses pure UDP for messages, perhaps with some TCP behind the scenes for out-of-band handshaking. I may end up just using UDP myself for the time-critical messages, and ZeroMQ for less critical data, but I'd prefer to avoid multiple-API creep. ___ 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
