[Discuss-gnuradio] weekend coding adventure: message passing, new blocks, and integrating grblock

[Josh Blum]

All the work is on my next branch, see here:
http://gnuradio.org/cgit/jblum.git/log/?h=next

##################################################
# Write gnuradio blocks in python
##################################################
This work, formally known as grblock was on my github. The project has
now been integrated into gnuradio-core on my next branch.

So basically, all of the facilities of a gr_block are now available in
python. Overload work, scheduler integration, stream tags, and also the
message passing I will mention below. See this wiki page for relevant
docs and examples.

http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython

##################################################
# Useful message passing
##################################################
I have create a message passing framework that fits in with the existing
gnuradio. Basically, each block can accept messages, and can post
messages to other blocks. The coordination of who can post messages to
who is handled by the the msg_connect() call which is the message
equivalent of the connect() call used on streams.

Messages can be used to pass arbitrary serialized data between two
blocks. The unit of message passing is the same as the stream tags,
which is the pmt library. See gruel/pmt.h for basic usage.

I have also extended the pmt blob type (memory container type) to manage
memory. This allows blocks to pass messages with bulk data; effectively
allowing for a mac/packet layer inside of gnuradio.

##################################################
# New blocks - gr_blob_to_stream/gr_stream_to_blob
##################################################
These blocks provide a cross over between the streaming domain in
gnuradio and a kind of packet-based stream of message blobs.

This is useful for testing the various blocks mentioned below:

##################################################
# New blocks - gr_blob_to_socket/gr_socket_to_blob
##################################################
These blocks read and write sockets (TCP or UDP) and output/input a
stream of message blobs. This has a few advantages of the current UDP
source/sink:

- respects packet boundaries, each blob corresponds to a packet.
Consider integration with gstreamer or VLC's udp socket streamers
- implements TCP as well, which can offer backpressure when
communicating between flowgraphs

##################################################
# New blocks - digital packet framer/deframer
##################################################
Basically that horrid packet framer in tunnel.py. I took the same packet
utils, its the same code, but the important distinction:

- the packet framer input messages
- the packet deframer outputs messages

The blocks are in grc if anyone cares to play.

##################################################
# New blocks - tuntap
##################################################
A tuntap interface with message input and message output, also available
in grc. This is the thing that implements the tunnel in tunnel.py Sorry,
linux only, unless someone wants to take a whack it for mac os, or
windows (however you do that).

##################################################
# Conclusions
##################################################
The message passing and making blocks in python work supersedes the need
for the old style message queues as the gateway between c++ and python.

Someone could make the equivalent of tunnel.py in GRC using the new
packet framer/deframer and tuntap block. The implementation would be
clearer and smarter.

Feedback and testing is welcome!
-Josh