[LAU] Editing zynadsuxfx/yoshimi patches?

[Paul Davis]

On Wed, May 4, 2011 at 9:38 AM, Lieven Moors <lievenmoors at gmail.com> wrote:

> I would like to understand better why this is the case.
> I guess the fundamental reason would be that UDP is an
> unsafe protocol, because it doesn't perform checks on the
> data sent or received. But would't that make it equally unsafe
> in both directions? Isn't this just two osc servers that are
> sending messages towards each other?

there are two issues. one is the issue of UDP not being "reliable".
the other is that OSC messages have no serial number on them. if you
end up sending the same request twice and get two different responses,
you have no idea which one actually came first unless you simply don't
use a reliable transport layer. in that case, the one that arrived
first is the response to the earlier request. but now you've got an
unreliable transport layer.

> I would expect to be reasonably sure that the reply makes it
> from one server to another, just as any other messages would.
> Wouldn't OSC or liblo be totally broken anyway if I couldn't
> rely on this sufficiently?

if you're using OSC with UDP transport, you have absolutely no
guarantee of this. of course, if you are working with a wired LAN,
this is really deeply unlikely to be an issue. but move into a
wireless LAN let alone WAN configurations and the possibility that a
UDP packet will simply fail to arrive gets high enough that you do
have to take it into consideration.

the simple answer, of course, is to use OSC over TCP which I *think*
liblo can do (and if it can't, it should be easy to make it). but this
still doesn't address the ordering issue, because OSC itself has no
concept of serial delivery (or even time).