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. > Certainly. That is what multicast is all about. Anyone can blat out state change information and others can listen/use or listen/discard. The only problem is, it is much more difficult to secure that type of messaging, especially if you want to propagate across the Internet. At that point it makes sense to encapsulate and secure the envelope. > > > > 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. > In this case it would be a specific device that would take the multicast messages, compress them, encapsulate them, unicast them across the Internet to a peer, which then performs the inverse process, eventually dumping your messages back out on the new broadcast medium as multicast packets again. > 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. > Why? If you have already adopted the source-based messaging model why not go all the way an just multicast the messages? I don't need to know who needs what information because I just throw the data on the wire, e.g. "Frequency = X" or "PTT = True". Everyone is a consumer. Those that can use it, use it. Those that can't, discard it. If we want more security we can sign the messages so that we know the authenticity of the source. But if you want to go with the more conventional unicast approach then you do need a rendezvous point so that you know who needs what data. > (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). > Yes, that is required for the unicast model but not for the source-based messaging model. > 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… :-) > Absolutely. But already we are talking about two very different approaches. The source-based messaging approach is different but simple. No registration at all. Got something to say? Say it. The place where this breaks down is that it can be easy for someone to source bogus messages, hence my comment about signing messages cryptographically. -- Brian Lloyd, WB6RQN/J79BPL 3191 Western Dr. Cameron Park, CA 95682 [email protected] +1.931.492.6776 (+1.931.4.WB6RQN) _______________________________________________ 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.
