On Sat, 2006-07-22 at 10:40 -0700, lazzaro wrote: > > Dave Robillard <[EMAIL PROTECTED]> wrote: > > > > OSC can go over TCP to avoid the packet loss issue (and messed up > > ordering which can be extremely annoying as well). liblo's TCP > > support > > needs some work though. > > > This comment illustrates an advantage for using RTP MIDI > to send MIDI over lossy networks. The recovery journal in > RTP MIDI supports graceful recovery from the loss of an arbitrary > number of packets upon the receipt of the first packet after the > loss (also works for reordering). Journalling is a feed-forward > process, > no retransmission is used -- thus, no head-of-line-blocking latency > issues as one has when running media over TCP.
Sure, for MIDI. MIDI has a lot of built-in semantics you can use to accomplish things like this, but OSC doesn't. As Loki pointed out, MIDI is no OSC (eg it sucks) :) You could do it on a per-app basis (since you actually know something about the information being transmitted), but a parallel to RTP MIDI can't really be done for OSC (TCP isn't the only solution though, it just happens to be what's around and obvious to use. You can wrap OSC in pretty much anything (and still be totally conformant)) I don't see it as much of a problem anyway. At least in all my use cases, there's realtime crucial data (eg what MIDI tends to do, controllers, notes, etc) and there's data that just needs to get there sanely. The nice thing about the realtime stuff is that lost messages don't really matter, all you care about is the most recent one anyway. I need to do a bit of work on liblo to get TCP working better, but I'm just going to use UDP for the former (realtime) and TCP for the latter (reliable). (On the local machine there's more fun possibilities like a POSIX message queue backend for liblo or similar, but that's an aside I'm just curious about at the moment) -DR-
