[chuck-users] OSC reliability issues

[Bradford Garton]

On Thu, 25 Jan 2007, Spencer Salazar wrote:

> OSC in ChucK, as in most other OSC implementations, uses UDP as its
> transport protocol, which basically means that one's OSC messages
> sent from ChucK are not guaranteed to ever arrive at their
> destination, nor are they guaranteed to arrive in order, nor are they
> guaranteed to arrive only once.  Under heavy load it is very likely
> that the network will drop packets.  Believe it or not this is
> actually desirable for many computer audio applications, as the
> latency overhead of a reliable transport protocol like TCP is often
> too great.

If timing is critical, I wouldn't recommend TCP.  I foold around a bit 
with using TCP to determine ensemble (yay plOrK!) timing, and the variance 
was too much.  UDP worked and I didn't notice as great a packet loss as I 
had expected, although 1) it was a 'closed' network, and 2) my packet 
traffic wasn't high.

If you need to have cake and eat it too, then you can probably use TCP but 
you would need to imbed some kind of time-stamping to allow you to 
compensate for late arrivals, or use UDP with sequence numbers to 
compensate for dropped packets.  This would assume that you put some 
timing 'intelligence' on the receiver end so that it can continue when 
things get messed up.

brad
http://music.columbia.edu/~brad