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

[Eric Blossom]

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.

There are three cases:

  (1) only a flow graph (the way it is today)
  (2) only mblocks (one of the future ways)
  (3) mblocks + flowgraphs (the other future way)

In case (3), I'm thinking that we have a mblock class that knows how
to embedded a flow graph (and all the machinery) within itself.  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).

The basic idea is that there is a small piece of code that knows about
both abstractions and how to bridge between them.

> The goal would be the only have 1 of these running, correct?  That way only 
> one is interfacing with the USRP at a time.

Yes.  One daemon.

> If this is true, what kind of IPC mechanism are we looking at?  GNU Radio 
> is also compatible on Windows and if we want to keep compatibility we have 
> to be careful here.

Probably shared memory and mutexes and/or condition variables.

For systems where that doesn't work, then we serialize everything and
push it through sockets.

> I could start designing and laying this out.

I think that's premature.  I know that you are looking for something
to get to work on.  Please bear with me at least until tomorrow.
I'm right now figuring out what needs to happen to have the mblock
code be ready (at least ready enough), that we could have a real
design discussion about the host side of the new USRP interface.

Thanks!
Eric