Hi.
Assuming that we are going to adhere to the not-invented-here principle, I
believe that most users of OSC would prefer a continuous retransmission
system for its conceptual and practical simplicity, rather than a recovery
journal.
That said there are numerous protocols from the IETF that handle such
requirements without resorting to TCP. For example SCTP, RUDP, etc. In the
2004 meeting Lazzaro showed how to use the RTP family to tunnel OSC (slides
should still be online at opensoundcontrol.org). Note that he did not
recommend tunneling OSC over RTP-MIDI.
In the AVBC work we put a control for minimum and maximum packet rates on
stream subscriptions. This can be seen as a frequency-bandwidth limitation
on control signals. I believe this mitigates many potential problems
including feedback loops and also provides crude bandwidth management and
advises the clients what peak sample rate the endpoint might actually
support.
Also, for those concerned about bandwidth, it is a simple matter to
implement an adaptive sampling filter that only forwards a message if the
minimum retransmit interval elapses, or if >n bits change in the data
portion--for integer data usually it will be n=0 and for floating point one
can use a moving estimate of the noise to determine when the signal portion
changes. My informal experiments with this found that the approach easily
achieves compression rates of 10:1 or better on typical "gesture" data
streams where the source has a relatively high sample rate (e.g. 1000hz).
Correct implementation of this requires timestamps as does any use of
asynchronous sampling rates.
Finally, the AVB working group has a defined target for how fast their
network audio control system should recover its connection-graph after a
node has been reset. I think its around 10 seconds? This gives a rough
idea of how often the stream subscriptions need to be retransmitted.
but it might be hard to implement for silly (but eventually useful) cases
where we have multiple non-human sources (captors, oscillators, etc) sending
changes to the same target. Moreover, a lost "release" message (failing
hardware, device power off before release) can be disastrous.
is an implied "release" at some short time in the future that can be
deferred by subsequent messages.
concept-if carefully thought through - avoids a lot of problems people
encounter attempting to synchronize state between two or more distributed
systems. In fact in many situations you can avoid polling to try to
synchronize states (an impossibility in practice anyway) altogether.
---
Andy W. Schmeder
email: andy [at] cnmat.berkeley.edu
skype: andy.schmeder
Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev