Am 30.06.2010 um 16:58 schrieb Brian Lloyd: > 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.
Yep, yep, and yep ;-) And it's easy to implement asynchronous, event-based computing schemes: Grab open source RabbitMQ, http://www.rabbitmq.com, and you're in the game within an hour. Now we only need to convince the application developers ... 73, Frank DG1SBG _______________________________________________ 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.
