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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
