Re: [Discuss-gnuradio] asynchronous messaging frameworks

[Tim]

For most applications,
I would suggest building a python native GNU Radio message block to
interact with a graph --
and *not* jumping to thrift or zmq without a reason --
bridging messages and streams over zmq IPC is doable but more work -- in
this case PMT serialization and JSON are the most used message formats -
valid reasons might be if gnu radio is secondary to your app and you
want a large layer of separation, process separation, or remote message
passing
-Tim

On 12/27/2015 11:42 AM, Marcus Müller wrote:
> Hi Daniel,
>
> On 12/27/2015 03:10 PM, Daniel Pocock wrote:
>> Is there any generic documentation about the use of GNU Radio with
>> asynchronous messaging and integration frameworks or would it be useful
>> to build up a wiki page about the topic?
> There's internal asynq messaging in GR (the "light grey" connections
> between blocks); message passing is relatively well-documented in the
> doxygen [1], and there's a bit on it in the guided tutorials[2].
> As everything, it could be better documented :) Documentation patches
> for the doxygen are always as welcome as wiki extensions.
> For the RPC beneath the controlport interface[3] we use Apache Thrift.
> There's also the XMLRPC, but I'm not experienced with that. I hear you
> can develop web-style applications with it easily.
>
> For network and IPC, we basically support zeroMQ, UDP, and of course
> simple Unix mechanisms like FIFOs and everything that can get a file
> descriptor.
>> I came across some pages referring to ZeroMQ support[1], I was also
>> curious about support for Qpid Proton[2] and other AMQP[3] systems.
>> There were some comments elsewhere about people using OpenMAMA[4]
>> (designed for low-latency financial messaging) to transport radar data,
>> among other things.
>>
>> Another possibility that comes to mind is D-Bus[5] support, either at a
>> low-level (other desktop applications controlling the radio or receiving
>> data from the radio) or high level (e.g. a Telepathy Connection
>> Manager[6] implementing one of the various digital messaging
>> solutions[7] or even Morse code)
> I personally don't know of any implementation of adapters for any of
> these; however, writing e.g. a dbus to message passing adapter won't be
> too hard. In fact, it should be but a couple of lines of python, unless
> things get overly involved with business logic etc.
>
> For your App-to-GNU Radio adaption, ZeroMQ pretty much sounds like a
> perfect match. It's leightweight, multi-language, easy to learn.
>> This could be a good way to further empower people familiar with other
>> systems, e.g. there was some question a while ago about how gpredict
>> could integrate with GNU Radio for real-time doppler shift
>> correction[8].  Doing such things over an asynchronous message bus leads
>> to looser coupling, so it is easier to swap components for
>> test/simulation or add more components to the architecture.
> I really cannot stress enough how right you are: GNU Radio definitely
> needs to get as "usable" from an application developer's perspective.
> Easy solutions for sending information to and from applications are most
> of the times sufficient; ZeroMQ definitely has become my tool of choice
> for that. However, at some level of complexity, you start to implement
> remote procedure calling.
> RPC, however, isn't easy. You might really want to stick with
> controlport, which is deeply integrated in GNU Radio, and its thrift
> foundation, if you have the choice.
>
> Best regards,
> Marcus
>
> [1] http://gnuradio.org/doc/doxygen/page_msg_passing.html
> [2]
> https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_Programming_Topics#53-Message-Passing
> [3] http://gnuradio.org/doc/doxygen/page_ctrlport.html
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio