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.
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 distributed-system'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 distributed-systems designs.
Related
I am trying to solve the following problem and was wondering what is the best approach to apply?
I'd like to setup a versioned communication via ZeroMQ, which effectively means that any client first makes a handshake stating the version of its messaging protocol and than all subsequent requests are forwarded only to specific set of workers, i.e. the ones which can understand this protocol.
I saw the example of Router/Dealer but there forwarding occurs always to all workers.
IMO this is something like a session, which is established based on handshake and all future requests are made in a particular context. Can this be done with ZeroMQ?
I understand that I can send back some ID to the client and ask it to put in all future requests, but would like to avoid that kind of intrusiveness.
Just a side note: I implement this approach in C++. I don't mind if you answer represents a general idea taking in account features available in either in ZeroMQ C API or cppzmq wrapper. No need to write a fully fledged solution, just how it might be done.
Yes, this seems doable:
With a full respect not to enter into "in-band" signalling via ID/multipart message-processing, one may build the wish-to-have infrastructure using a mix of static and dynamic use of as-is ZeroMQ resources.
Step 0: your central authority handles initial "client" contact / handshaking / identity validation
Step 1: each "client" receives a set of directions, as it's identity/version got approved, based upon 0)
Step 2: ad-hoc instructed "client" may { .connect() | .bind() } with appropriate access-point
Step 3: as an architecture bonus, this can be enjoyed as distributed platform with re-negotiation(s) and node re-discoveries for even more robust, scalable-performance and raised security motivated scenarios
Our own imagination is the only ceiling:
In a few word, one may soon forget about the standard Scalable Formal Communication Patterns, these serve as rather a set of building blocks for ad-hoc defined architectures. That is the biggest power of the ZeroMQ or nanomsg to realise.
May read more on advanced use-cases in this ( and check the book there ... ).
I am looking to use ZeroMQ to facilitate IPC in my embedded systems application, however, I'm not able to find many examples on using multiple 0MQ socket types in the same process.
For example, say I have a process called "antenna_mon" that monitors an antenna. I want to be able to send messages to this process and get responses back - a classic REQ-REP pattern. However, I also have a "cm" process, that publishes configuration changes to subscribers. I want antenna_mon to also subscribe to antenna configuration changes - PUB-SUB.
I found this example of reading from multiple sockets in the same process, but it seems sub optimal, because now you no longer block waiting for messages, you inefficiently check for messages constantly and go back to sleep.
Has anyone encountered this problem before? Am I just thinking about it wrong? Maybe I should have two threads - one for CM changes, one for REQ-REP servicing?
I would love any insights or examples of solving this type of problem.
Welcome to the very nature of distributed computing!
Yes, there are new perspectives one has to solve, once assembling a Project for a multi-agent domain, where more than one process works and communicates with it's respective peers ad-hoc.
A knowledge base, acquired from a soft Real-Time System or embedded systems design experience will help a lot here. If none such available, some similarities might be also chosen from GUI design, where a centerpiece is something like a lightweight .mainloop() scheduler, and most of the hard-work is embedded into round-robin polled GUI-devices and internal-state changes or external MMI-events are marshalled into event-triggered handlers.
ZeroMQ infrastructure gives one all the tools needed for such non-blocking, controllably poll-able ( scaleable, variable or adaptively ad-hoc adjustable poll-timeouts, not to overcome the given, design defined, round-trip duration of the controller .mainloop() ) and transport-agnostic, asynchronously operated, message dispatcher ( with thread-mapped performance scaling & priority tuning ).
What else one may need?
Well, just imagination and a lot of self-discipline to adhere the Zero-Copy, Zero-Sharing and Zero-Blocking design maxims.
The rest is in your hands.
Many "academic" examples may seem trivial and simplified, so as to illustrate just the currently discussed, or a feature demonstrated in some narrow perspective.
Not so in the real-life situations.
As an example, my distributed ML-engine uses a tandem of several PUSH/PULL pipelines for moving state data updates transfers and prediction forcasts + another PUSH/PULL for remote keyboard + a reversed .bind()/.connect() on PUB/SUB for easy broadcasting of distributed agents' telemetry to a remote centrally operated syslog and some additional PAIR/PAIR pipes, as processing requires.
( nota bene: one shall always bear in mind, that robust and error-resilient systems ought avoid to use a default REQ/REP Scaleable Formal Communication Pattern, as there is non-zero probability of falling the pairwise-stepped REQ/REP dual-FSA into an unsalvageable deadlock. Do not hesitate to read more about this smart tool. )
I'm looking for a way to add network emulation to a socket.
The basic solution would be some way to add bandwidth limitation to a connection.
The ideal solution for me would:
Support advanced network properties (latency, packet-loss)
Open-source
Have a similar API as standard sockets (or wraps around them)
Work on both Windows and Linux
Support IPv4 and IPv6
I saw a few options that work on the system level, or even as proxy (Dummynet, WANem, neten, etc.), but that won't work for me, because I want to be able to emulate each socket manually (for example, open one socket with modem emulation and one with 3G emulation. Basically I want to know how these tools do it.
EDIT: I need to embed this functionality in my own product, therefore using an extra box or a third-party tool that needs manual configuration is not acceptable. I want to write code that does the same thing as those tools do, and my question is how to do it.
Epilogue: In hindsight, my question was a bit misleading. Apparently, there is no way to do what I wanted directly on the socket. There are two options:
Add delays to send/receive operation (Based on #PaulCoccoli's answer):
by adding a delay before sending and receiving, you can get a very crude network simulation (constant delay for latency, delay sending, as to not send more than X bytes per second, for bandwidth).
Paul's answer and comment were great inspiration for me, so I award him the bounty.
Add the network simulation logic as a proxy (Based on #m0she and others answer):
Either send the request through the proxy, or use the proxy to intercept the requests, then add the desired simulation. However, it makes more sense to use a ready solution instead of writing your own proxy implementation - from what I've seen Dummynet is probably the best choice (this is what webpagetest.org does). Other options are in the answers below, I'll also add DonsProxy
This is the better way to do it, so I'm accepting this answer.
You can compile a proxy into your software that would do that.
It can be some implementation of full fledged socks proxy (like this) or probably better, something simpler that would only serve your purpose (and doesn't require prefixing your communication with the destination and other socks overhead).
That code could run as a separate process or a thread within your process.
Adding throttling to a proxy shouldn't be too hard. You can:
delay forwarding of data if it passes some bandwidth limit
add latency by adding timer before read/write operations on buffers.
If you're working with connection based protocol (like TCP), it would be senseless to drop packets, but with a datagram based protocol (UDP) it would also be simple to implement.
The connection creation API would be a bit different from normal posix/winsock (unless you do some macro or other magic), but everything else (send/recv/select/close/etc..) is the same.
If you're building this into your product, then you should implement a layer of abstraction over the sockets API so you can select your own implementation at run time. Alternatively, you can implement wrappers of each socket function and select whether to call your own version or the system's version.
As for adding latency, you could have your implementation of the sockets API spin off a thread. In that thread, have a priority queue ordered by time (i.e. this background thread does a very basic discrete event simulation). Each "packet" you send or receive could be enqueued along with a delivery time. Each delivery time should have some amount of delay added. I would use some kind of random number generator with a Gaussian distribution.
The background thread would also have to simulate the other side of the connection, though it sounds like you may have already implemented that part?
I know only Network Link Conditioner for Mac OS X Lion. You should be mac developer to download it, so i cannot put download link there. Only description from 9to5mac.com: http://9to5mac.com/2011/08/10/new-in-os-x-lion-network-link-conditioner-utility-lets-you-simulate-internet-and-bandwidth-conditions/
This answer might be a partial solution for you when using linux:
Simulate delayed and dropped packets on Linux. It refers to a kernel module called netem, which can simulate all kinds of network problems.
If you want to work with TCP connections, having "packet loss" could be problematic since a lot of error-handling (like recovering lost packages) is done in the kernel. Simulating this in a cross-platform way could be hard.
you usually add a network device to your network that throttles the bandwidth or latency, on a port by port basis, you can then achieve what you want just by connecting to the port allocated to the particular type of crappy network you want to test, with no code changes or modifications required.
The easiest ways to do this is just add iptables rules to a Linux server acting as a proxy.
If you want it to work without the separate device, try trickle that is a software package that throttles your network on your client PC. (or for Windows)
You may would like to check WANem http://wanem.sourceforge.net/ . WANEM is Open Source and licensed under the GNU General Public License.
WANem allows the application development team to setup a transparent application gateway which can be used to simulate WAN characteristics like Network delay, Packet loss, Packet corruption, Disconnections, Packet re-ordering, Jitter, etc.
I think you could use a tool like Network Simulator. It's free, for Windows.
The only thing to do is to setup your program to use the right ports (and the settings for the network, of course).
If you want a software only solution that you control, you will have to implement it yourself. I know of no such existing package.
While a wrapper layer over a socket may give you the ability to introduce delay, it won't be sufficient to introduce loss or out of order delivery. In order to simulate those activities, you actually need intercept the data in transit between the two TCP stacks.
The approach I would recommend is to use a tunneling device (say tunX). Routes should be set so the client believes the way to the server is through tunX. Additional code (perhaps running in a different thread) would promiscuously intercept traffic on tunX, and perform your augmented behavior, before forwarding packets over the true physical interface that will get the traffic to your server. The reverse would happen for packets arriving from the server on the physical interface. Those packets would be intercepted by the client code, behavior augmented, before forwarding through tunX.
However, since you are testing client software, I am unclear as to why you would want to embed this code in your released software, unless the software itself is a WAN simulating client.
I am programming a Client/Server application for my project in C++. The whole application protocol was given or discussed by the working group. The main idea is that we have 3 protocols.
Text-protocol: send and receive some information in string format between client and server.
Binary-protocol: client sends continiously some status data to server.
Binary-protocol: client sends continiously some data like sound/video/images/text
All Protocols should run on different ports.
I implemented a Socket-Class, which is responsible to create and listen socket, accept the connection from the client. Also there is a function to receive/send string-based data and receive/send binary-based data.
In the next step I wanted to define 3 Classes. Each of them should be responsible for creating one socket in new Thread and responsible for the protocol, which was defined for that port (s. 1-3). So at the end I will get 3 Sockets (1 Socket for one Port).
My question is, if I think in right direction? Maybe you can recommend my some design patterns for using different application protocols. It would be great if you can recommend me some projects or code, which can be similar with my project.
Thank you.
You should decouple your socket class from the 3 protocol handlers - don't have methods for both text and binary data handling on the Socket or you unintentionally encourage people to mix and match data types over the same socket, which is clearly not what you want.
Your socket should provide simple connect/disconnect, data transmission and receipt functionality, and the decoding and encoding of sent/received data is then done in a different object, likely picked from 3 new classes (one per protocol).
On a general note, I question the use of text data. It's inefficient compared to virtually any serialization library you could name. You could be trading a little extra debuggability for a lot of hard-written data parsing and error checking code, and concomitant CPU cycle wastage. If the text data is fairly simple (not actually structured like XML, say) then this is less of a concern.
Protocol 2. might be implementable using UDP rather than TCP, if the status info is not mission-critical. That's one less connection you'd have to manage.
You might consider using enet. It does reliable and unreliable UDP communications and will do most of the heavy lifting of the communications for you.
Lots of questions, I am sorry!
I am doing a voice-chat (VoIP) application and I was thinking of doing a custom implementation of the IP&UDP headers, along with small, extra information mainly seq number. Sounds alot like RTP yes, but I'm mainly just interested in the seq number or timestamp, and trying to implement my own whole RTP sounds like a nightmare with all the complexity involved and data im not likely to use.
Target OS for the application is windows xp and above. I have read http://msdn.microsoft.com/en-us/library/ms740548%28v=vs.85%29.aspx on the topic of Raw sockets in windows, and now I just want some confirmation.
I also have some general networking questions.
Here's the following questions;
1) According to MSDN, you cannot send custom IP packets with a source that is not on the network list. I understand it from a security PoV, but is there any way around this? My idea was to have for example two clients open UDP communication to a non-NAT protected server, and then have the clients spoof the source-header to make it look like packets come from the server instead of each other, thereby eliminating the need for a server as a relay of data to get through NAT, which would improve latency.
I have heard of winpcap but I don't want each client to have to install any 3rd party apps. Considering the number of DoS attacks surely there must be some way around this, like spoofing the network table the OS uses to check if source-header is legit? Will this trigger anti-virus systems?
I feel it would be really fun to actually toy with IP headers and above instead of just using predefined headers.
2) I've been having issues with free RTP libraries like JRTPLIB(which probably is very good anyway it just dosn't want to work for me) to make them work, more than I could almost tolerate, and am thinking of just writing my own interpretation ontop of UDP. Does application-level protcols like RTP simply build their header directly inside the UDP payload with the actual data afterwards? I suspect this considering the encapsulation process but just want to make sure.
If so, one does not need to create a RAW socket to implement application-level protocol, just an ordinary UDP socket and then your own payload interpretation above?
3) RTP does not give any performance boost compared to UDP since it adds more headers, all it does is making sure packets arrive in a sort-of correct manner based on timestamps and sequence numbers, right?
Is it -really- that usefull to use an RTP implementation for your basic VoIP project needs instead of adding basic sequencing yourself? I realise for video conferencing perhaps you reaally don't want frames to play out of order, but in audio conversations, would you really notice it?
4) If my solution in #1 is not applicable and I would have to use a server as a data relay between clients, would multicast be a good solution to reduce server loads? Is multicast supported enough in routing hardware?
5) It is related to question 1). Why do routers/firewalls allow things like UDP hole punching? For example, two clients first conenct to the server, then the server gives a client port / ip on to other clients, so the clients can talk to each other on those ports.
Why would firewalls allow data to be received from another IP than the one used in making the connection on that very port? Sounds like a big security hole that should easly be filtered? I understand that source IP spoofing would trick it, but this?
6) To set up a UDP session between two parties (the client which is behind NAT, server whic his non-NAT) does the client simply have to send a packet to the server and then the session is allowed through the firewall? Meaning the client can receive too from the server.
Based on article at wiki, http://en.wikipedia.org/wiki/UDP_hole_punching
7) Is SIP dependant on RTP? For some reason I got this impression but I cant find data to back it up. I may plan to add softphone functionality to my VoIP client in the future and want to make sure I have a good foundation (RTP if I really must, otherwise my own UDP interpretation)
Thanks in advance!
1, Raw sockets seems unnecessary for this application
2, Yes
3, RTP runs on top of UDP, of course it adds overhead. In many ways RTP (ignoring RTCP) is pretty much the bare minimum already and if you implemented a half-way decent alternative it would save you a few bytes at best and you wouldn't be able to use any of the many RTP test tools.
7, SIP is completely independent of RTP. SIP is used to Initiate Sessions. SDP is the protocol commonly transported by SIP, and it is SDP that negotiates and controls RTP video/voice voice.