Re: [Discuss-gnuradio] inband packet encoding/decoding daemon

[Eric Blossom]

On Wed, Mar 28, 2007 at 08:19:24PM -0400, George Nychis wrote:
> 
> Eric Blossom wrote:
> >Hi George,
> >
> >(Yes, I know you're waiting for me...  More later on today)
> >
> >On Mon, Mar 26, 2007 at 04:02:48PM -0400, George Nychis wrote:
> >>So from what I understand, a daemon has been suggested for inband packet 
> >>encoding and decoding that is implemented as an m-block which can be 
> >>connected in a flow graph for the encoding/decoding and interfacing with 
> >>the USRP.  Is this correct?
> >
> >Right, except for the flow graph part.
> 
> Actually, let me jump back a second here then... what I want to make sure I 
> understand is how an m-block knows that it needs to connect to the daemon 
> and forward its m-block packets to be converted in to USB packets and they 
> are sent across the wire
> 
> >This
> >would include ways for mblock messages to get sent into the flow
> >graph (similar to gr.message_source) and to convert the output of the
> >flow graph into mblock messages (similar to gr.message_sink).

Just to be keep life sane, let's defer the part of the discussion
about mixed mblocks and flowgraphs for now...

> So I get this part, I get the part about converting the output in to 
> m-block messages, I'm wondering how these m-block messages are picked up by 
> the daemon?  Since we are using some sort of IPC, do we have some sort of 
> queue that these messages just get dumped in and the daemon can pull 
> messages out of the queue and encode+forward them?
> 
> - George

For now ignore the underlying IPC mechanism.  Assume that all
communication is via messages (mb_message) between mblocks (derived
from mb_mblock).  Some of those mblocks may be running in a different
process, or on a different machine, but that doesn't really change
anything.  All we've got are mblocks passing messages to other
mblocks.  In the case of mblocks in different address spaces, we'll
need some kind of rendezvous mechanism, but don't worry about that
now.

I want to get us thinking about the problem at an "all we're doing is
sending and receiving messages" level of abstraction.

If you look in mb_mblock.h, mb_message.h and mb_port.h
[trunk/mblock/src/lib/...], you'll see the interfaces available.  To
send a message given a port p, use p->send(...)  the message will
magically get delivered to whatever mblock is connected to the
other end of the port.

Likewise, when somebody sends an mblock a message, its
mb_mblock::handle_message method will be automagically invoked with
the message (the runtime will ensure that handle_message is not called
reentrantly.  I.e., the mblock doesn't have to worry about threading
issues).  handle_message will look at the contents of the message
(including signal, data, metadata, and which port it came from) and do
whatever it likes.  More than likely it'll perform some kind of
computation and then send one or more messages.

Simple.  Of course there's lot of stuff going on behind the scenes
making this all happen (lots of threads, message queues, data
structures describing who's connected to whom, etc.) but you, as a
writer of mblocks, don't need to worry about any of that.

OK?

Eric