5 ms·

Traditional message queues are actually composed of two rather different subsystem: the queue itself (basically a database) and the networking. I would say we

by rumcajz 13y ago

Traditional message queues are actually composed of two rather different subsystem: the queue itself (basically a database) and the networking. I would say we are on the path of separating the two. ZeroMQ does away with the centralised server holding all the queues. It still has local queues though. nanomsg goes even further and gets rid of queues entirely. What's left it networking buffers, typically implemented at L4 of the network stack.

derefr 13y ago
So, then, what do you get by using nanomsg? Is the value proposition "BSD sockets but less lousy"?
- baq 13y ago
  isn't that a great thing to have in itself?
- rumcajz 13y ago
  Nope. It's a platform for delivering packaged and reusable distributed algorithms, such as request/reply or publish/subscribe. The algorithms handle the issues like message routing, scaling up, handling partial failure etc.
  - derefr 13y ago
    Well, that's what I meant--technically, BSD sockets are themselves supposed to be "a platform for delivering packaged and reusable distributed algorithms". In a friendly, ideal environment (like the Internet of the 1980s), req/rep is "just" TCP/SCTP unicast, pub/sub is "just" UDP multicast, and so on. Issues like "message routing [and] scaling up" are supposed to be handled on the link layer (i.e. using ARP, BGP, etc.); issues like handling partial failure, on the transport layer (if IP stacks weren't stuck in the 70s, we'd have such a thing as multicast TCP, and "send TCP packet to host set, wait for ACK from all hosts, and retransmit to failed hosts" would simply be its obvious send() system-call semantic.) We've just screwed the "friendly, ideal environment' pooch by putting not-very-intelligent NATs and firewalls everywhere. So we have to, sadly, reimplement all these nice things on top of the few things we've kept working: TCP and UDP unicast from clients to "business-leased" IPs with open+addressable ports. The necessity of things like this, UPnP, and TURN/STUN/ICE sadden me sometimes, they really do; they're 100% examples of an inner-platform[1] created because software developers have gone on for so long only touching OSI layer 7, and thinking about the rest of the infrastructure as a black box, that now the application layer is the only place you can solve problems, because the infrastructure will no longer transport your packets if they do anything special below it. So I say, please, look past your abstractions, programmers, and learn what makes the Internet tick! It's worth it to understand what your packets are doing--you might want a property that you can already get by asking something different of a lower layer. Or, even if not, you might just become--as Bret Victor says--very unsatisfied with the state of things. :) Oh, and start here, if anywhere: http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html --- [1] http://en.wikipedia.org/wiki/Inner-platform_effect http://en.wikipedia.org/wiki/Inner-platform_effect
    - rumcajz 13y ago
      You are oversimplifying it. REQ/REP is not the same as TCP, unlike TCP it works with multiple requesters and multiple repliers. Same with other patterns. The main distinction between L4 and scalability layer is that L4 works between 2 nodes, scalability between arbitrary number of nodes. There's the special case of UDP multicast, but the multicast itself feels more like a hack rather than a real L4 protocol.
    - aidenn0 13y ago
      Can we stop using OSI layer numbers for TCP/IP? Why did that ever catch on?
andrewcooke 13y ago
i'm a bit confused here, so forgive me if i've got something muddled up. were zeromq's queues just in-memory? it was never meant to be reliable in the sense that messages were preserved in a database at each socket, was it? alternatively, if i am wrong above, and zeromq was reliable / persistent then why did you drop this? thanks (i've worked on esbs, but not with zmq).
- gnaritas 13y ago
  > were zeromq's queues just in-memory? Yes. > it was never meant to be reliable in the sense that messages were preserved in a database at each socket, was it? No. It's meant to be a fast inter app messaging protocol, it's not a queue, it simply uses some in memory queues internally. It's not a queue, it's an improved socket library, having MQ in the name was clearly a mistake that he's now corrected.
  - sophacles 13y ago
    Or the whole name 0mq can be read to mean no message queue. Which in context of middleware makes sense
    - gnaritas 13y ago
      It can be, but it generally isn't, look around the net and you'll see it's pretty clear that most think it's a message queue and it gets thrown into that mix when the topic comes up. People are always having to explain to others that it isn't a queue, that's bad naming of the product.
- rumcajz 13y ago
  In ZeroMQ it was in user-space memory. Now it's in kernel-space (TCP rx/tx buffers). That actually makes it a little more reliable as tx buffers are not necessarily dropped when the application fails.

by rumcajz 13y ago

derefr 13y ago

So, then, what do you get by using nanomsg? Is the value proposition "BSD sockets but less lousy"?

baq 13y ago
isn't that a great thing to have in itself?
rumcajz 13y ago
Nope. It's a platform for delivering packaged and reusable distributed algorithms, such as request/reply or publish/subscribe. The algorithms handle the issues like message routing, scaling up, handling partial failure etc.
- derefr 13y ago
  Well, that's what I meant--technically, BSD sockets are themselves supposed to be "a platform for delivering packaged and reusable distributed algorithms". In a friendly, ideal environment (like the Internet of the 1980s), req/rep is "just" TCP/SCTP unicast, pub/sub is "just" UDP multicast, and so on. Issues like "message routing [and] scaling up" are supposed to be handled on the link layer (i.e. using ARP, BGP, etc.); issues like handling partial failure, on the transport layer (if IP stacks weren't stuck in the 70s, we'd have such a thing as multicast TCP, and "send TCP packet to host set, wait for ACK from all hosts, and retransmit to failed hosts" would simply be its obvious send() system-call semantic.) We've just screwed the "friendly, ideal environment' pooch by putting not-very-intelligent NATs and firewalls everywhere. So we have to, sadly, reimplement all these nice things on top of the few things we've kept working: TCP and UDP unicast from clients to "business-leased" IPs with open+addressable ports. The necessity of things like this, UPnP, and TURN/STUN/ICE sadden me sometimes, they really do; they're 100% examples of an inner-platform[1] created because software developers have gone on for so long only touching OSI layer 7, and thinking about the rest of the infrastructure as a black box, that now the application layer is the only place you can solve problems, because the infrastructure will no longer transport your packets if they do anything special below it. So I say, please, look past your abstractions, programmers, and learn what makes the Internet tick! It's worth it to understand what your packets are doing--you might want a property that you can already get by asking something different of a lower layer. Or, even if not, you might just become--as Bret Victor says--very unsatisfied with the state of things. :) Oh, and start here, if anywhere: http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html --- [1] http://en.wikipedia.org/wiki/Inner-platform_effect http://en.wikipedia.org/wiki/Inner-platform_effect
  - rumcajz 13y ago
    You are oversimplifying it. REQ/REP is not the same as TCP, unlike TCP it works with multiple requesters and multiple repliers. Same with other patterns. The main distinction between L4 and scalability layer is that L4 works between 2 nodes, scalability between arbitrary number of nodes. There's the special case of UDP multicast, but the multicast itself feels more like a hack rather than a real L4 protocol.
  - aidenn0 13y ago
    Can we stop using OSI layer numbers for TCP/IP? Why did that ever catch on?

andrewcooke 13y ago

i'm a bit confused here, so forgive me if i've got something muddled up. were zeromq's queues just in-memory? it was never meant to be reliable in the sense that messages were preserved in a database at each socket, was it? alternatively, if i am wrong above, and zeromq was reliable / persistent then why did you drop this? thanks (i've worked on esbs, but not with zmq).

gnaritas 13y ago
> were zeromq's queues just in-memory? Yes. > it was never meant to be reliable in the sense that messages were preserved in a database at each socket, was it? No. It's meant to be a fast inter app messaging protocol, it's not a queue, it simply uses some in memory queues internally. It's not a queue, it's an improved socket library, having MQ in the name was clearly a mistake that he's now corrected.
- sophacles 13y ago
  Or the whole name 0mq can be read to mean no message queue. Which in context of middleware makes sense
  - gnaritas 13y ago
    It can be, but it generally isn't, look around the net and you'll see it's pretty clear that most think it's a message queue and it gets thrown into that mix when the topic comes up. People are always having to explain to others that it isn't a queue, that's bad naming of the product.
rumcajz 13y ago
In ZeroMQ it was in user-space memory. Now it's in kernel-space (TCP rx/tx buffers). That actually makes it a little more reliable as tx buffers are not necessarily dropped when the application fails.