On Wed, Jun 30, 2010 at 10:22 AM, Peter G. Viscarola <[email protected]>wrote:
> > mere drop-in-the-bucket compared to the IF and baseband data streams so > > giving up some protocol efficiency in order to gain programming and > > debugging simplicity is likely to be an overall win. > > > > I agree 100% > > I'm not sure if TCP is the right protocol here, or whether UDP fits better. > But an IP-based mechanism is almost surely the easiest from many different > viewpoints. > One of the things we learned in the IETF is the value of "rough consensus and working code". Getting something to work and then gaining experience with that code tells you a great deal. The beauty of TCP is that it is simpler to use than UDP as you don't need to put packet loss recovery algorithms in your application. Let TCP do that for you. Since it greatly simplifies the application, you can get your application running more quickly and therefore giving you back useful information more quickly. If it turns out you cannot live with the retransmission algorithms in TCP, you are still free to add those into your application with almost no loss of development time. So save the effort up front as it may turn out you just don't need to put in the effort. Many of the failure modes we feared while building the Internet just never came to pass. But instead of coding for them up front, we did what was simple and learned from that what we needed to add. Most bogeymen never materialize. > I'd like to see an event subscription-based replacement to CAT that > > lets a > > developer subscribe to be notified when certain events occur. This > > allows a > > logbook or contesting software programmer to "subscribe" to frequency > > changes, mode changes, transmit, etc. without the need to poll > > constantly > > for data. > > Absolutely agreed. > > What's nice about a subscriber-based model is that it allows simple > expansion of the events produced, without any disruption in the consumer. I > want to see Frequency Changes, I see frequency changes. Later, an event is > added to be informed about callsigns, unless I also subscribe to that event > I just see frequency changes. > That does then cause problems for using TCP as TCP is a 1-to-1 protocol. If you want to multicast events as they occur, then you need to go with a UDP-based approach or you need to set up multiple TCP sessions and replicate. 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. > 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. > > Mr. Lloyd again: > > > > > One of the key issues is the need (or lack of need) to synchronize > > commands/status with IF and baseband data. Must it be isochronous or > > can it > > be asynchronous? So far in my mind it appears asynchronous but I think > > we > > need to come up with usage scenarios that let us test our assumptions > > using > > mind experiments. > > > > Yes, good point. I *think* the events themselves can be asynchronous, but > it's worthy of discussion. Also (if there's a need to ensure time-relevance) > events could be time stamped. The problem with this is, of course, clock > skew if there are multiple producers/consumers. > NTP is your friend. Need better resolution? GPS. > -- 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.
