2

What is performance (I mean latency while sending all messages, maximum fan-out rate for many messages to many receivers) of ZMQ in comparison to "simple" UDP and its multicast implementation?

Assume, I have one static 'sender', which have to send messages to many,many 'receivers'. PUB/SUB pattern with simple TCP transport seems very comfortable to handle such task - ZMQ does many things without our effort, one ZMQ-socket is enough to handle even numerous connections.

But, what I am afraid is: ZMQ could create many TCP sockets in background, even if we don't "see" that. That could create latency. However, if I create "common" UDP socket and will transmit all my messages with multicast - there would be only one socket (multicast), so I think latency problem would be solved. To be honest, I would like to stay with ZMQ and PUB/SUB on TCP. Are my concerns valid?

Morpheus
  • 119
  • 1
  • 11

2 Answers2

1

I don't think you can really compare them in that way. It depends on what is important to you.

  • TCP provides reliability and you as the sender can choose if loss is more important than latency by setting your block/retry options on send.
  • mcast provides network bandwidth saving especially if you network has multiple segments/routers.

Other options in zeromq

  • Use zmq_proxy's to split/share the load of tcp connections
  • Use pub/sub with pgm/epgm which is just a layer over multicast (I use this)
  • Use the new radio dish pattern (with this you have limited subscription options)
James Harvey
  • 912
  • 4
  • 6
  • Thanks for response. I read ZGuide, but I think I didn't find out it well - is ZMQ "intelligent" in creating sockets? I mean, if ZMQ is not greedy to creating too much sockets, if i need ONLY one for ex. to multicast UDP. – Morpheus Jul 13 '18 at 08:18
1

Behind the scenes, a TCP "socket" is identified (simplified) by both the "source" and "destination" - so there will be a socket for each direction you're communicating with each peer (for a more full description of how a socket is set up/identified, see here and here). This has nothing to do with ZMQ, ZMQ will set up exactly as many sockets as is required by TCP. You can optimize this if you choose to use multicast, but ZMQ does not optimize this for you by using multicast behind the scenes, except for PUB/SUB see here.

Per James Harvey's answer, ZMQ has added support for UDP, so you can use that if you do not need or want the overhead of TCP, but based on what you've said, you'd like to stay with TCP, which is likely the better choice for most applications (i.e. we often unconsciously expect the reliability of TCP when we're designing our applications, and should only choose UDP if we know what we're doing).

Given that, you should assume that ZMQ is as efficient as TCP enables it to be with regards to low-level socket management. In your case, with PUB/SUB, you're already using multicast. I think you're good.

Jason
  • 13,606
  • 2
  • 29
  • 40