-1

I am trying to build a c++ application that must use ZeroMQ to listen to encoded packets being forwarded to port 8080 via UDP on my machine at a rate of 10 [Hz].

How do I setup a zmq socket/server/etc.. such that I can receive and decode the incoming data?

I am on a linux machine, running Ubuntu 16.04

UPDATE + ANSWER: ZMQ does not listen to generic UDP packets, as @tadman stated. Therefore, considering I was unable to modify the system that was sending the packets, this would not be an appropriate use for ZMQ. I ended up using a generic UDP endpoint as @tadman recommended.

Airfield20
  • 254
  • 1
  • 2
  • 13
  • ZeroMQ doesn't listen to UDP packets. It listens to ZeroMQ packets. Those can be TCP, UDP, or whatever depending on what it thinks is best. – tadman May 25 '18 at 21:00
  • @tadman see edit. The messages are being sent via UDP. – Airfield20 May 25 '18 at 21:03
  • ZeroMQ listens for ZeroMQ connections and ZeroMQ connections only. If you need a generic UDP endpoint you'll need to implement that yourself. You could use ZeroMQ for transport here, 10 messages per second is basically nothing, so it can handle it with ease. – tadman May 25 '18 at 21:04
  • @tadman Can you elaborate on "You could use ZeroMQ for transport here" – Airfield20 May 25 '18 at 21:07
  • ZeroMQ is all about low-latency, high-throughput messaging. You could send your audio snippets via ZeroMQ instead of UDP. – tadman May 25 '18 at 22:04
  • After a lot of messing around, I found that UDP in ZeroMQ is at best "experimental" / "incomplete". ZeroMQ has a lot of processing and options to allow error checking and messages to be "dropped", therefore, i recommend that you use ZeroMQ as TCP/IP but you look at noblock options etc, as a lot of these options to ignore errors and wait conditions emulate the speedy characteristics of UDP. – Owl Jan 23 '19 at 16:04
  • For my particular use case, I had no way to modify/control the data being sent via UDP. So I indeed needed a generic UDP endpoint which ZMQ is not suited for. – Airfield20 Feb 12 '19 at 20:36

1 Answers1

3

How do I use ZeroMQ to listen to and parse UDP-data on a specific port ?

Greetings to Dearborn/UoM,
let's first demystify the problem, ok?

ZeroMQ is not a self-isolating tool, it can and does talk or listen to non-ZeroMQ sockets too.

@tadman was right and wrong at the same time.

ZeroMQ doesn't listen to UDP packets. // == True; ( as of known in 2018-Q2, API ~ 4.2.2 )
It listens to ZeroMQ packets. // == False;

Since ZeroMQ native API ~ 4.+, ZeroMQ can both listen and talk to non-ZeroMQ sockets, i.e. your wish may lead to a ZeroMQ Context()-engine working with a plain socket.

If new to ZeroMQ 's design eco-systems, you may like first a brief dis-ambiguation read into the main conceptual differences in the [ ZeroMQ hierarchy in less than a five seconds ] Section, so as to better touch the roots of the problem to solve.

ZeroMQ has udp:// <transport-class>,
can be used for { ZMQ_RADIO | ZMQ_DISH } Archetypes only

While ZeroMQ has the udp:// transport-class ready to use for both unicast and multicast AccessPoint addresses, it is not yet possible to make the Context() instantiate such data-pump for a non-ZeroMQ, plain-socket peers.

ZeroMQ can talk to non-ZeroMQ peers,
yet just over a tcp:// <transport-class>

non-ZeroMQ peers can get connected using a plain socked, redressed ( due to many architecture / API design reasons ) inside the ZeroMQ implementation into a ZeroMQ-compliant Scalable Formal Communication Archetype named ZMQ_STREAM ). This is cool and permits to use homogeneous strategies to handle also these types of communicating peers, yet, there is just a need to use the tcp:// transport-class, if this is necessary.

How to ?

Given your source of the dataflow is under your control, try to make it use ZeroMQ eco-system, since which it can be comfortably served as any other ZeroMQ udp://-cross-connected AccessPoint.

If design or "political" constraints prevent you from doing so, the receiving side cannot be ZeroMQ directly, so decide about making an application-specific protocol gateway, mediating Non-ZeroMQ-udp traffic to any form of ZeroMQ "consumable", be it a ZMQ_STREAM over plain-tcp: ( if decided to make a functionally minimalistic design of the proxy, or decide to equip such proxy straight with any other, smarter ZeroMQ archetype, to communicate on way higher level of comfort with your main data-collector / processor ).

If audio is the intended payload and the accumulating latency is a concern, best also read more details on how easily the main engine can get performance tuned - scaled up the number of IOthreads, wisely mapped ZMQ_AFFINITY and ZMQ_PRIORITY settings - all that can influence the target latency + throughput performance envelopes.

Last, but not least, the 10 [Hz] requirement

this one is indeed a nice part, that will test one's insights into asynchronous process coordination. ZeroMQ main engine ( the Context()-instance(s) ) work in an asynchronous and uncoordinated manner.

This means, there is no direct way to avoid accumulated latency or to inspect any of the Broker-less, per-peer managed, async by desing message-queue buffer, so as to "travel"-"back"-in-time, upon a Hard-Real-Time 10 [Hz] probing.

If this is going to work in a weak / "soft" ( not a strict R/T ) flow-of-time system coordination ( having no control-system stability constraints / critical-system / life-supporting or similar system responsibility, as hard R/T system designs do have ), thus tolerating a certain amount of code-execution related jitter RTT- / [ transport + (re-)processing ]-latencies a smart-designed .poll()-based non-blocking inspections and possibly some fast queue pre-emptying policies may help you get into acceptably fast, soft-RT behaviour to make the 10 [Hz]-monitor robust enough.

So, indeed cool days with ZeroMQ in front of you - Good Luck, Sir. If not already overdue with Project's Plan or deadline coming on Monday, best take a read of a fabulous Pieter HINTJENS' book "Code Connected, Volume 1", where most gems of the Zen-of-Zero are well discussed and inspected for designs.

user3666197
  • 1
  • 6
  • 50
  • 92