ZMQ REP Message Sink: Difference between revisions
(add example flowgraph and Python code) |
(add example flowgraph) |
||
| Line 62: | Line 62: | ||
</pre> | </pre> | ||
=== | === GNU Radio as a server === | ||
If the GNU Radio flowgraph(s) is configured as a server, the REQ message is processed by the flowgraph and a message is sent back in a REP message as the response. See [[ZMQ_REQ_Message_Source#GNU_Radio_as_a_server]] for details. | |||
== Source Files == | == Source Files == | ||
Revision as of 13:52, 13 March 2020
The ZMQ REP Message Sink block receives async messages and sends them to a ZMQ REP socket. This block will connect to a ZMQ REQ Message Source.
The zeromq.org website says:
"The REQ-REP socket pair is in lockstep. The client issues zmq_send() and then zmq_recv(), in a loop (or once if that's all it needs). Doing any other sequence (e.g., sending two messages in a row) will result in a return code of -1 from the send or recv call." Likewise, the server "issues zmq_recv() and then zmq_send() in that order, as often as it needs to."
Parameters
(R): Run-time adjustable
- Address
- ZMQ socket address specifier. The format of the address is
tcp://*:portwhere * should be 127.0.0.1 for localhost.
- Timeout
- Socket timeout in milliseconds, default is 100ms.
Example Flowgraph
Inter-flowgraph
Request/Reply pairs can be used on one, or two separate, flowgraphs to exchange messages.
External Python client (receive only)
An external Python program can receive messages from a ZMQ REP Message Sink block. An example flowgraph and Python code follow.
The Python client code looks like this:
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# The REQest / REPly nomenclature of the GNU Radio message blocks is from
# the perspective of the flowgraph. So, to send a 'request' to GNU Radio, the message
# must be sent as a 'reply' from the Python client, Likewise, a 'reply' from GNU Radio
# must be received as a 'request' to the Python client! Therefore, send on the reply socket
# and receive on the request socket.
#
# The zeromq.org website says:
# "The REQ-REP socket pair is in lockstep. The client issues zmq_send() and then zmq_recv(),
# in a loop (or once if that's all it needs). Doing any other sequence (e.g., sending two messages in a row)
# will result in a return code of -1 from the send or recv call." Likewise, the server "issues zmq_recv()
# and then zmq_send() in that order, as often as it needs to."
#
# To conform to that requirement, a non-standard "kludge" is used (see below).
import zmq
import pmt
def main():
zmq_context = zmq.Context()
zmq_sock = zmq_context.socket(zmq.REQ)
zmq_sock.connect("tcp://127.0.0.1:50247")
while(True):
zmq_sock.send_string("\x01\x00\x00\x00") # this is the non-standard "kludge"
msg = zmq_sock.recv()
print (pmt.to_python(pmt.deserialize_str(msg)))
if __name__ == '__main__':
main()
GNU Radio as a server
If the GNU Radio flowgraph(s) is configured as a server, the REQ message is processed by the flowgraph and a message is sent back in a REP message as the response. See ZMQ_REQ_Message_Source#GNU_Radio_as_a_server for details.
Source Files
- C++ files
- TODO
- Header files
- TODO
- Public header files
- TODO
- Block definition
- TODO

