Understanding ZMQ Blocks: Difference between revisions
Line 39: | Line 39: | ||
=== Separate GR flowgraphs on Same Computer === | === Separate GR flowgraphs on Same Computer === | ||
When the ZMQ blocks are in separate flowgraphs but on the same computer, the IP address should be | When the ZMQ blocks are in separate flowgraphs but on the same computer, the IP address should be <code>127.0.0.1</code> for localhost. It has less overhead than a full IP. | ||
These flowgraphs, using the PUB / SUB pair, are taken from [[Simulation_example:_AM_transmitter_and_receiver]]. | These flowgraphs, using the PUB / SUB pair, are taken from [[Simulation_example:_AM_transmitter_and_receiver]]. |
Revision as of 02:05, 16 January 2021
This tutorial is under construction.
This tutorial presents the GNU Radio ZMQ blocks. It is a set of six Source Blocks and six Sink Blocks. The naming convention follows other source and sink blocks in that a source block provides data entering a GNU Radio flowgraph and a sink block sends data out of the flowgraph. It is a flowgraph-oriented perspective.
From the ZeroMQ website: "ZeroMQ (also known as ØMQ, 0MQ, or zmq) looks like an embeddable networking library but acts like a concurrency framework. It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast."
Prerequisites
Types of ZMQ Blocks
For GNU Radio, the two basic groups of ZMQ blocks are those which transport stream data, and those which transport messages. They are described below.
ZMQ blocks come in pairs:
- PUB - SUB
- PUSH - PULL
- REQ - REP
The PUB, PUSH, and REP blocks are always sink blocks; the others are source blocks. Choosing which pair to use depends on your system architecture.
- The PUB - SUB pair can be compared to broadcasting. The PUBlish sink sends out data which can be received by one or more SUBscribers.
- The PUSH - PULL pair is a point to point link of equal peers.
- The REQ - REP pair is a point to point link which operates in lock-step: one REQuest input gives one REPly output. This case changes the perspective somewhat in that the flowgraph is acting as a server for a remote client.
Data Blocks
ZMQ data blocks transport raw stream data; there is no formatting. The data type and the sample rate are determined by the flowgraph feeding the ZMQ Sink. Therefore the flowgraph or program receiving the data must know those parameters in order to interpret the data correctly.
Message Blocks
Unlike the generic ZeroMQ strings, GNU Radio ZMQ Message Blocks utilize Polymorphic_Types_(PMTs) to encode/decode the data. See also Message_Passing.
Using ZMQ Blocks
The cases described below explain the differences in the block addressing. To conform to port addressing defined by the Internet Assigned Numbers Authority (IANA), private ports can be assigned in the range 49152–65535.
Separate GR flowgraphs on Same Computer
When the ZMQ blocks are in separate flowgraphs but on the same computer, the IP address should be 127.0.0.1
for localhost. It has less overhead than a full IP.
These flowgraphs, using the PUB / SUB pair, are taken from Simulation_example:_AM_transmitter_and_receiver.
Separate GR flowgraphs on Different Computers
If the Source and Sink blocks are on two different computers, then the IP and port number of the Sink block must be specified on each end of that connection. For example, if the Sink is on IP 192.168.1.194:50241 and the Source is on IP 192.168.1.85, both Source and Sink blocks must specify the Sink IP and port (192.168.1.194:50241).
Python Program as a REQ / REP Server
The following Python program receives a string message on its REQ socket, capitalizes the text, and sends the string on its REP socket. The terminology gets confusing here because the incoming REQ came from a GR ZMQ_REP_Message_Sink and is returned to a ZMQ_REQ_Message_Source.
#!/usr/bin/python3 # -*- coding: utf-8 -*- # zmq_REQ_REP_server.py # This server program capitalizes received strings and returns them. # NOTES: # 1) To comply with the GNU Radio view, messages are received on the REQ socket and sent on the REP socket. # 2) The REQ and REP messages must be on separate port numbers. import pmt import zmq _debug = 0 # set to zero to turn off diagnostics # create a REQ socket _PROTOCOL = "tcp://" _SERVER = "127.0.0.1" # localhost _REQ_PORT = ":50246" _REQ_ADDR = _PROTOCOL + _SERVER + _REQ_PORT if (_debug): print ("'zmq_REQ_REP_server' version 20056.1 connecting to:", _REQ_ADDR) req_context = zmq.Context() if (_debug): assert (req_context) req_sock = req_context.socket (zmq.REQ) if (_debug): assert (req_sock) rc = req_sock.connect (_REQ_ADDR) if (_debug): assert (rc == None) # create a REP socket _PROTOCOL = "tcp://" _SERVER = "127.0.0.1" # localhost _REP_PORT = ":50247" _REP_ADDR = _PROTOCOL + _SERVER + _REP_PORT if (_debug): print ("'zmq_REQ_REP_server' version 20056.1 binding to:", _REP_ADDR) rep_context = zmq.Context() if (_debug): assert (rep_context) rep_sock = rep_context.socket (zmq.REP) if (_debug): assert (rep_sock) rc = rep_sock.bind (_REP_ADDR) if (_debug): assert (rc == None) while True: # Wait for next request from client data = req_sock.recv() message = pmt.to_python(pmt.deserialize_str(data)) print("Received request: %s" % message) output = message.upper() # Send reply back to client rep_sock.send (pmt.serialize_str(pmt.to_pmt(output)))