3 ms·

I believe I looked at that as well. It was six months ago, so forgive me if my memory is a bit off. Looking at the intro, it looks like I have to hardcode the

I believe I looked at that as well. It was six months ago, so forgive me if my memory is a bit off. Looking at the intro, it looks like I have to hardcode the IPs and ports of all of the machines I want to publish or subscribe to. Is that correct? If so, that's a little fragile for my tastes. I like "upgrading servers" by standing up new servers, testing they work, and then changing the floating IP associated with the DNS to point to them instead. And I can hear you say "Aha! Floating IP! Just use that!" but for most cloud providers (I believe), that is billed as external bandwidth, which is not free like internal requests are. Finally, if I want to stand up more servers to scale horizontally, I'd still have to modify my code and redeploy it to all my servers. I think. Unless I'm missing something about how 0mq works. Which I totally could be. On the whole, learning what I needed to learn to make Pastry happen made me a better programmer, too. So if for no other reason than that, I'm glad I did it.

JulianMorrison 14y ago
No more so than with TCP sockets you have to "hard code" the IP connected to. 0mq is low level, it's not going to do routing like Pastry, but you can get away with having one fixed location for a "lookup server" that keeps track of everything else's location (something like the Doozer project, also in Go https://github.com/ha/doozerd https://github.com/ha/doozerd ). Also, 0mq only needs to know the IP of the publisher, for pub-sub.
- paddyforan 14y ago
  Very cool. Where were you six months ago? ;) I was familiar with doozer, but doozer wasn't(/isn't) being actively maintained and it doesn't compile against the latest version of Go, so I'd have to bring it up to speed before I could use it anyways. Not saying it would be harder, but between that and writing the 0mq library (pretty sure one does not exist in Go yet), I'd estimate the work would be more or less equivalent and yield just about the same stability. Seat of the pants guess, but it makes me feel better, at least.
  - JulianMorrison 14y ago
    Heh, thanks. The mailing list suggests http://github.com/4ad/doozer http://github.com/4ad/doozer and http://github.com/4ad/doozerd http://github.com/4ad/doozerd are being maintained as forks of the original. Or there's Zookeeper. Or brew your own central lookup server using 0mq that does the same job of "set a key, get a key, notify subscribers when it changes". It's a single point of failure, but since the system will run fine without it (only lacking topology updates) it's not a hugely problematic one.
    - alexchamberlain 14y ago
      Isn't the lookup server a SPoF?
    - paddyforan 14y ago
      This reply link just appeared for me. Not cool -_- The lookup server is a single point of failure. And while it's not a hugely problematic one, it also is a dedicated machine whose sole purpose is keeping the other machines running. Which feels wrong to me. It probably wasn't the best business decision to invest time in this, and I won't even argue this is the best technical solution. But it's the only technical solution that didn't make me feel like I was working around limitations; things just worked they way they were supposed to. The API servers received an event, they told the WebSockets servers about it. It felt very conceptually pure to me. I'm a sucker for that.
      - JulianMorrison 14y ago
        To get the reply on a deep comment, click "link" first to get the comment as a single page, and "reply" will be there. Doozer is only slightly a SPF, it has high availability by having multi-master replication. It's also not doing a lot of communicating, or a lot of CPU work, and it keeps its data in RAM, so it may be OK for it to live on a non-dedicated machine. Sorry if I come across as criticizing your admittedly cool creation. It was just that you said there weren't alternatives, and I knew of one.
        14y ago

JulianMorrison 14y ago

No more so than with TCP sockets you have to "hard code" the IP connected to. 0mq is low level, it's not going to do routing like Pastry, but you can get away with having one fixed location for a "lookup server" that keeps track of everything else's location (something like the Doozer project, also in Go https://github.com/ha/doozerd https://github.com/ha/doozerd ). Also, 0mq only needs to know the IP of the publisher, for pub-sub.

paddyforan 14y ago
Very cool. Where were you six months ago? ;) I was familiar with doozer, but doozer wasn't(/isn't) being actively maintained and it doesn't compile against the latest version of Go, so I'd have to bring it up to speed before I could use it anyways. Not saying it would be harder, but between that and writing the 0mq library (pretty sure one does not exist in Go yet), I'd estimate the work would be more or less equivalent and yield just about the same stability. Seat of the pants guess, but it makes me feel better, at least.
- JulianMorrison 14y ago
  Heh, thanks. The mailing list suggests http://github.com/4ad/doozer http://github.com/4ad/doozer and http://github.com/4ad/doozerd http://github.com/4ad/doozerd are being maintained as forks of the original. Or there's Zookeeper. Or brew your own central lookup server using 0mq that does the same job of "set a key, get a key, notify subscribers when it changes". It's a single point of failure, but since the system will run fine without it (only lacking topology updates) it's not a hugely problematic one.
  - alexchamberlain 14y ago
    Isn't the lookup server a SPoF?
  - paddyforan 14y ago
    This reply link just appeared for me. Not cool -_- The lookup server is a single point of failure. And while it's not a hugely problematic one, it also is a dedicated machine whose sole purpose is keeping the other machines running. Which feels wrong to me. It probably wasn't the best business decision to invest time in this, and I won't even argue this is the best technical solution. But it's the only technical solution that didn't make me feel like I was working around limitations; things just worked they way they were supposed to. The API servers received an event, they told the WebSockets servers about it. It felt very conceptually pure to me. I'm a sucker for that.
    - JulianMorrison 14y ago
      To get the reply on a deep comment, click "link" first to get the comment as a single page, and "reply" will be there. Doozer is only slightly a SPF, it has high availability by having multi-master replication. It's also not doing a lot of communicating, or a lot of CPU work, and it keeps its data in RAM, so it may be OK for it to live on a non-dedicated machine. Sorry if I come across as criticizing your admittedly cool creation. It was just that you said there weren't alternatives, and I knew of one.
      - 14y ago