2 ms·

0mq doesn't have a client/server relationship. http://www.zeromq.org/ http://www.zeromq.org/

by JulianMorrison 14y ago

brian_cloutier 14y ago
What does it have?
- JulianMorrison 14y ago
  Peer-to-peer connections analogous to TCP. In the case of pub/sub all subscribers connect to the publisher. http://zguide2.zeromq.org/page:all http://zguide2.zeromq.org/page:all
  - paddyforan 14y ago
    I guess I was wrong about hard-coding the IPs. Maybe? It doesn't have many-to-many baked in, though. That I can see, at least. It looks like I may have been able to make this work, but the setup would be a little complex. ... because a distributed hash table is not complex at all. -_-
    - JulianMorrison 14y ago
      It doesn't have many-to-many but in my experience most things aren't true many-to-many. More like, there are a handful of publishers in the system and each has a handful of subscribers. Suppose your architecture is API -> Web sockets and you want to make it highly scalable, then what I'd do is: 1. Many API -> few relays (use doozerd to keep up to date as to where the relays are and select one randomly, use ZMQ_ROUTER socket type to enqueue API->relay messages). 2. Few Relay -> many web socket (again using doozerd for the web socket nodes to find the relay, and using ZMQ_PUB on the relay and ZMQ_SUB on the web socket nodes).
      - paddyforan 14y ago
        Sounds like it would work, and have great availability and scalability. It just, conceptually, doesn't mesh with how I think about the system. An absolutely aesthetic distinction, I know.
paddyforan 14y ago
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

0mq doesn't have a client/server relationship. http://www.zeromq.org/ http://www.zeromq.org/

brian_cloutier 14y ago

What does it have?

JulianMorrison 14y ago
Peer-to-peer connections analogous to TCP. In the case of pub/sub all subscribers connect to the publisher. http://zguide2.zeromq.org/page:all http://zguide2.zeromq.org/page:all
- paddyforan 14y ago
  I guess I was wrong about hard-coding the IPs. Maybe? It doesn't have many-to-many baked in, though. That I can see, at least. It looks like I may have been able to make this work, but the setup would be a little complex. ... because a distributed hash table is not complex at all. -_-
  - JulianMorrison 14y ago
    It doesn't have many-to-many but in my experience most things aren't true many-to-many. More like, there are a handful of publishers in the system and each has a handful of subscribers. Suppose your architecture is API -> Web sockets and you want to make it highly scalable, then what I'd do is: 1. Many API -> few relays (use doozerd to keep up to date as to where the relays are and select one randomly, use ZMQ_ROUTER socket type to enqueue API->relay messages). 2. Few Relay -> many web socket (again using doozerd for the web socket nodes to find the relay, and using ZMQ_PUB on the relay and ZMQ_SUB on the web socket nodes).
    - paddyforan 14y ago
      Sounds like it would work, and have great availability and scalability. It just, conceptually, doesn't mesh with how I think about the system. An absolutely aesthetic distinction, I know.

paddyforan 14y ago

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