I think an event/subscription based architecture for actual modules makes a lot of sense as well, outside the CAT realm. Take for example, a tone encoder/decoder module. It could connect to the core software, using TCP and establishing a secure, authenticated session, if desired. Then it can subscribe to demodulated audio from the receiver, as well as advertise to the core that it has configuration attributes, and subscribe to any event notifications, such as tone on/off. It can then process the demodulated audio, strip out or insert the tone as necessary, and pass on the data to the next module. It would obviously also be important to be able to decide where the module is inserted in the chain.
On Wed, Jun 30, 2010 at 11:38 AM, Peter G. Viscarola <[email protected]>wrote: > Inline > > Sounds like you are interested in source-based messaging in the manner of > CAN as used in automobiles. Just be aware of the security problems that will > crop up. We do have enough processing power that supporting multiple TCP > sessions and replicating the data probably is easy enough to do and then we > can take advantage of existing security protocols. > > Well, CAN-bus works down through the hardware level. But the same sort of > distributed messaging can be applied, as you said, even with TCP sessions. > > > Further, it probably makes sense to at least consider making this protocol > a "mesh" and not merely "one to many" -- That is, any module can be a > producer or a consumer of events. It makes the registration and switching > more complex, but it allows infinite variety and expandability. > > Yes, you are thinking in terms of CAN. Great when you have administrative > and physical control of all the hardware so you can impose physical security > but that won't fly if we want to distribute applications over the Internet > without building application-specific gateways. > > Depends on what you consider a gateway. Consider that while communications > can be done in a mesh, there will almost certainly need to be a central > registration authority, right? Someplace where producers and consumers go > to "discover" each other - Register the events that they provide, and > discover which events are available for subscription. In other words, a > directory service. This can serve as the necessary authentication point. > (So, Provider A registers that he provides events 1, 2, and 3 with > whatever attributes and characteristics make sense (description, version, > expected frequency... I don't know, whatever). Provider B registers the > provision of events 7 and 8. Now, Consumer X comes along and asks the > directory service what events are available for subscription, and then sends > a request directly to the Providers to register. That registration > information can include a token provided by the directory service, if > consumer authentication with each provider is required). > This is really just a P2P scheme, right? Not unlike bittorrent, for > example. > We're sketching in pencil on a cocktail napkin here, which is cool, as long > as we all agree that's what we're doing... :-) > P > _______________________________________________ > Flexedge mailing list > [email protected] > http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz > This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used > for posting topics related to SDR software development and experimentalist > who are using alpha and beta versions of the software. > _______________________________________________ Flexedge mailing list [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used for posting topics related to SDR software development and experimentalist who are using alpha and beta versions of the software.
